ARTICLE · 1095143
847份文档里298份是扫描件:打败RAG的从来不是模型,是人类杂乱无章的原始数据
落地复盘 · 数据治理847份文档里298份是扫描件：打败RAG的从来不是模型，是人类杂乱无章的原始数据
上一篇讲了部署踩的坑，这篇讲更头疼的——数据。模型再强，喂进去的是垃圾，吐出来的也是垃圾。我们花了三周洗数据，才让RAG正常回答问题。
落地复盘系列 · 第02篇 · 全文约5000字，阅读约9分钟
说明：本文涉及的项目数据为脱敏处理，文档数量、类型分布均为真实统计，但具体文件名、发文单位已做模糊化。仅用于经验分享。
写在前面上一篇讲完部署，有人问我：为什么RAG老是答非所问？为什么问个政策它给我扯别的？答案很简单：喂给它的文档，本身就是一锅粥。我们那个项目847份文档，我花了整整三周洗数据。OCR错的、重复的、版本混乱的、加密打不开的、扫描歪了的——每一个都是坑。这篇就讲讲，真实的政企数据到底有多乱，以及我们是怎么把它洗干净的。
先看看甲方给的"原始数据包"长什么样
上一篇说过，我们这个知识库子模块，甲方是政务服务中心。方案里写的是"接入政策法规、办事指南、常见问答共约800份文档"。听起来挺正常对吧？
真正拿到数据那天，我通过VPN连上甲方的文件服务器，把847个文件下载下来，解压完一看，人都傻了。
我统计了一下：
847份里，真正能直接用的原生PDF只有423份，刚过一半。剩下的424份，每一份都要处理。
第一个坑：298份扫描件，OCR出来一半是乱码
扫描件是最大的坑。方案里写的是"支持扫描件OCR识别"，我们用的是PaddleOCR，实验室里测的时候，用的都是清晰的扫描件，准确率98%。到了现场才知道，真实的政务扫描件是什么样的。
那298份扫描件，是各个科室这几年慢慢攒的，有的是2019年扫描的，用的还是一台老扫描仪，分辨率只有200DPI；有的是扫描的时候纸放歪了，歪了十几度；有的是红头文件，红色印章盖住了正文；有的是传真件，纸上有一道一道的黑条纹；还有几份干脆是照片拍的——用手机对着文件拍的，手抖，模糊。
PaddleOCR跑了一晚上，第二天看结果：298份里，有137份OCR出来基本能用，但有错字；有89份OCR出来一半是乱码——就是那种你认识每个字但连起来不知道说什么的；还有72份，OCR出来的文本长度只有原文的三分之一，等于根本没识别出来。
这里有个真相：OCR准确率这个数字，在演示环境和真实环境是两回事。实验室里用清晰扫描件测98%，真实场景里能到80%就不错了。尤其是中文公文——长句子、专业术语、表格、印章遮挡——OCR错一个字，后面RAG检索就偏了。
我们后来做了几件事：第一，把分辨率低于300DPI的扫描件筛出来，让甲方重新扫描；第二，加了一个OCR后处理步骤——用大模型对OCR结果做纠错，就是把OCR出来的乱七八糟的文字喂给7B模型，让它"根据上下文修正错别字"，效果意外的好；第三，歪的扫描件先做透视矫正，PaddleOCR自带这个功能，但我们之前没开。
这三步搞完，89份乱码里救回来大概60份，剩下29份实在救不回来，让甲方重新提供电子版。就这，花了一周。
第二个坑：156份重复文档，版本比你想的乱得多
扫描件的问题刚解决，又发现一个更隐蔽的问题——重复文档。
我们做了个简单的MD5哈希去重，发现有156份文档内容是重复的。但问题是，重复不等于一样。我点开对比了几份，发现政务文档的版本管理是真的乱：
比如《企业开办流程指南》，文件名一样，但有三个版本：2023版、2024修订版、2025最新版。内容大改了——2023版说要跑三个窗口，2024版说两个，2025版说一网通办零跑腿。三个版本都在文件夹里，没有任何命名规范。我们要是全入库了，用户问"企业开办要跑几个窗口"，RAG可能从2023版里召回，告诉他跑三个——这不是误导吗？
还有一种更隐蔽：文件名不同，内容一样。比如《关于优化营商环境的通知》和《营商环境优化措施》，其实是同一个文件，只是一个是红头版一个是网页版。
最后我们怎么处理的？写了个脚本，先按文件名聚类，再按内容相似度（embedding余弦相似度>0.92）聚类，把疑似重复的列出来。但哪些保留最新版，机器判断不了——最后拉了个Excel，让甲方业务科的人一份一份确认。光确认这个，又花了五天。
教训：数据去重这件事，技术只能做初筛，最终判断必须靠人。你以为去重是写个脚本跑一下，实际上是要业务方坐下来一份一份看。这一步省不掉，省了后面全是雷。
第三个坑：86份Word文档，格式比内容还重要
Word文档是另一类问题。86份Word，看起来是原生文本应该好处理，但实际入库后发现，RAG召回的内容经常缺头少尾。
查了一下才知道，政务Word文档的格式特别乱：有的用样式标题，有的直接打回车加加粗当标题；有的目录是自动生成的，有的是手动敲的；还有的正文里插了文本框、批注、修订记录——我们的解析器用PyMuPDF，对Word是先转PDF再解析，结果文本框里的内容丢了，批注被当成正文了。
最典型的一个：有份办事指南，正文写着"请到A窗口办理"，但旁边文本框里写着"2025年5月起改到B窗口"。文本框内容丢了，RAG就召回了旧地址，用户跑到A窗口发现搬了，投诉电话直接打到信息中心。
这个坑花了三天：换了python-docx直接解析Word，把文本框、表格、页眉页脚全部提取出来，再按段落重组。但重组后的顺序也不对——文本框在原文里是浮动的，你不知道它该插在哪。最后还是靠规则：如果文本框内容包含"窗口""地址""时间""电话"这种关键词，就拼到正文最后面。
第四个坑：Excel办事指南，表格切开后全散了
24份Excel，是最头疼的。政务办事指南很多都是表格形式：左边列事项名称，右边列申请材料、办理时限、窗口电话。
我们一开始的处理方式是：Excel转成文本，然后按段落切chunk。结果切出来的内容是这样的："申请材料 办理时限 窗口电话 身份证 3个工作日 027-xxxxxxx 营业执照 5个工作日 027-xxxxxxx"——表格结构全丢了，RAG根本不知道哪行对应哪列。
后来改成：Excel每一行单独作为一个chunk，列名作为metadata。就是说，"企业开办"这一行，存的时候带上{"事项类型":"企业登记","申请材料":"身份证、营业执照","办理时限":"3个工作日"}。这样用户问"企业开办要什么材料"，召回的就是结构化的一行，不会乱。
但这又引入新问题：chunk太小了。一行办事指南就几十个字，embedding的时候上下文不够，检索准确率反而降了。我们又调了策略：每个chunk是一个完整的事项，把表头和这一行拼在一起，大约200-300字，刚好。
最后洗数据花了多久？三周
我盘了一下时间：
第一周：OCR问题处理，重新扫描+矫正+纠错，处理298份扫描件。第二周：去重和版本治理，156份重复文档，甲方业务方确认。第三周：Word和Excel格式修复，文本框提取、表格结构化。
三周，21天。这三周里模型一行代码没改，架构一个模块没动，就是在跟文档死磕。但效果是立竿见影的：洗数据之前，随机抽50个问题测试，准确率大概40%——一半问题答非所问或者说"未找到相关信息"。洗完之后，同样的50个问题，准确率到了82%。
82%这个数字不算高，但已经能过验收了。剩下的18%，是那些文档里确实没写清楚的——比如"这个证明到底要不要开"，连窗口人员自己都说不清，AI更说不清。
聊聊我学到了什么
做RAG的人都听过一句话："garbage in, garbage out"。但真正在项目里被这句话教育，是这三周的事。
第一，数据治理不是上线前的准备工作，它本身就是交付物的一部分。我们合同额156万，光数据清洗就占了大概三分之一的工期和人力。方案里写"数据治理"四个字，评委看了觉得你考虑周全，真做起来才知道这四个字下面是几百份文档的人肉清洗。
第二，不要迷信"一键入库"。市面上很多RAG平台宣传"拖进去就能用"，那是对干净的数字文档说的。真实的政企文档，扫描件、旧版本、格式混乱，你不花时间洗，它就给你答错。这部分时间，方案里必须留出来，不能假设甲方给你的数据是干净的。
第三，让业务方参与数据确认，比你自己闷头改强一百倍。版本对不对、地址改没改、哪个窗口搬了，这些事你作为FDE是判断不了的。你要做的是把问题整理成表格，让业务方花两天时间签字确认。这不是推卸责任，是专业——因为后面出了问题，你有据可查。
现在回头看：RAG效果不好，90%的问题不在模型、不在向量库、不在chunk大小，而在数据。用户说"AI好傻"的时候，往往不是模型不行，是它读到的文档本身就是乱的。模型只是忠实地把混乱的文档，组织成了一段通顺但错误的回答。
这就是为什么我后来做项目，第一件事不是搭架构，是先要数据样本——拿50份真实文档看看，再评估工期。数据不干净，后面全白搭。
下篇预告
等保三级测评：我们的系统为什么被测评师连续打回三次
下一篇讲等保测评。日志字段不对、权限控制太粗、传输没加密、弱口令——这些技术方案里不会写但测评必查的东西，我们一个个踩过来。一个政务AI系统，技术再好，过不了等保就是不能上线。
这是一个关于AI大模型落地交付的真实复盘系列。不讲发布会上的突破，不讲技术博客里的完美架构。只讲我这一年做FDE（前置部署工程师），在政务、教育、医疗项目现场真实踩过的坑。每一篇都是真实故事，每一个数字都对应真实经历。
AI 落地复盘系列 · 第 02 篇记录真实踩坑，沉淀一线经验