很多团队的 RAG 项目都经历过同一个循环：检索结果不对，换 embedding 模型；还是不对，调 chunk 大小；再不行，加 rerank；指标纹丝不动，最后归咎于模型能力不够。但如果把排查顺序倒过来，从 chunk 往回追，你会发现问题往往不在检索层，而在切片之前——文档根本没有被处理成模型能读懂的形态。
这篇文章按工程排查的思路，把 RAG 数据管道里四个常被跳过的故障点拆开讲：预处理缺失、OCR 质量、版本冗余、敏感字段入库，末尾给一条参考管道的伪流程，再算一算脱敏和压缩对存储、token 成本的实际影响。这些判断和处理方式，来自丑梨数据在做私有化文档处理管道时积累的一线经验。
现象：检索层的调参为什么救不了数据层
先对齐一个前提。RAG 的效果上限，在文档进入向量库的那一刻就大致定了。检索层的任何优化——换模型、调 chunk、加 rerank——都是在既定数据质量的天花板下面腾挪。chunk 本身是坏的，检索层做得再精细，也只是在坏数据里挑相对好的那段。
判断问题出在数据层还是检索层，有个简单办法：拿评测集里答错的 case，人工去向量库里翻原始 chunk。如果翻出来的内容本身残缺、错乱，或者压根是另一个版本的过期文件，那继续调检索层就是白费劲，得回头治数据。
下面按管道顺序讲四个故障点。
故障点一：切片之前，预处理根本没做
最常见的默认管线是 load → split → embed，中间几乎什么都没有。拿它去处理企业文档，问题立刻暴露：PDF 里混着扫描页；表格藏在图片里，切片后被当成无意义的图注；双栏排版被按行线性切开，左右两栏的内容在同一个 chunk 里交错；页眉页脚每个 chunk 都带一份“公司机密，请勿外传”。
这些 chunk 进了向量库，嵌入向量自然是偏的。版式文件里还有 OFD 这类国内特有的格式，很多开源解析器直接不支持，硬转 PDF 又会丢结构。
预处理这一层该干的活其实很明确：格式归一（含 OFD 与扫描件）、版面分析还原阅读顺序和标题层级、表格转成带结构的文本、剥离页眉页脚和水印。这一步做到位，后面切片粒度怎么调才有意义。
故障点二：扫描件的 OCR，垃圾进垃圾出
扫描件和图片型 PDF 是重灾区。低分辨率、印章遮挡关键字段、盖章后重新扫描造成的字形畸变，都会让 OCR 输出错误率飙升。
更隐蔽的一点是：OCR 错字对人是可读的——“北亰”你也能猜出是北京——但对 embedding 模型是实打实的语义偏移。错字密集的 chunk，和正确表述在向量空间里的距离被拉远，检索自然就飘。而且这种误差不会在人工抽检里暴露，因为抽查的人看得懂。
工程上的对策：入库前按 OCR 置信度分档，低置信页面走二次增强（去噪、超分、版面重切）再提文本；金额、日期、编号这类关键字段做交叉校验。原则就一条：别把 OCR 输出当成可信文本直接切片。
故障点三：版本冗余 chunk，把检索结果搅浑
企业文件系统的真实状态是：同一份合同存了五个版本，会议纪要被复制到八个目录，改个标题就另存一份。M-Files 委托 Vanson Bourne 做过一项全球调查：96% 的员工表示难以找到文档的最新版本，83% 曾因找不到已有文档而重新创建一份。这些重复文档全部切片入库后，存储翻倍只是小事。
真正的问题是近重复 chunk 在召回里挤占名额：问一条合同条款，top-10 里五个是旧版本的近似段落，过期内容和有效答案互相稀释，rerank 也未必救得回来。
对策分两步。存量治理：跑一次全量去重，内容哈希粗筛完全相同的文件，再用 SimHash 或嵌入相似度阈值处理“改动不大”的近似版本，结合文件名和时间元数据保留最新。增量防控：入库管道里内置去重环节，新文件先比后进。
故障点四：敏感字段跟着文档进了索引
身份证号、银行卡号、手机号，本来就是文档里价值最高的信息。切片入库后，它们变成了可被检索的内容——权限做得粗一点，就是全员可查。这等于把散落在合同里的个人信息，聚合成了一个能被一句话问出来的数据库。
再往外一层是影子 AI：员工嫌内部系统不好用，直接把带客户信息的文档贴进公网 AI 工具。IBM《2025 数据泄露成本报告》给出的数字是：五分之一的企业曾因员工私用 AI 工具导致数据泄露，这类企业的平均泄露成本比同行高出 67 万美元；而遭遇过泄露的组织里，63% 还没有成文的 AI 治理政策。
工程上的位置很关键：脱敏必须放在切片之前，因为入库的就是脱敏后的 chunk。身份证、银行卡这类结构化字段用规则加校验位可靠识别，按策略遮蔽或替换；需要还原的场景，可逆映射的密钥要单独管理，和知识库的访问权限分开。
一条健康的入库管道长什么样
把四个故障点串起来，参考伪流程如下：
文档接入
→ 格式识别（PDF / OFD / Office / 扫描件 / 图片）
→ 版式解析：还原标题层级、阅读顺序、表格结构
→ 扫描件走 OCR：分辨率增强 → 版面分析 → 文本提取 → 置信度分档
→ 清洗：剥离页眉页脚水印、修正高频 OCR 错字、补全表格语义
→ 脱敏：检测身份证号 / 银行卡号 / 手机号等字段，按策略遮蔽或替换
→ 去重：内容哈希粗筛 → 近重复检测 → 按版本元数据保留最新
→ 压缩：降体积、降图片 token，保持版式保真
→ 切片：按语义边界切，附带来源、版本、时间等元数据
→ 嵌入入库
每个环节都该有独立指标：预处理看版式还原率，OCR 看字准与置信度分布，去重看近重复率，脱敏看字段命中率。管道可观测，才谈得上持续改进——这也是判断一个 RAG 数据方案成熟度的基本标准。
脱敏与压缩：存储和 token 的账怎么算
存储这一头，Komprise 的客户调研显示，企业 NAS 上 60%-70% 的数据超过 90 天未被访问，却占着最贵的主存储。RAG 上线后还要再叠一层副本和向量索引，开销继续放大。
token 这一头，文档里的图片类内容（扫描页、图表截图）以多模态方式进模型时，消耗相当可观，常被成本估算漏掉。
如果压缩做在入库之前，两笔账一起省。目前把压缩、脱敏、去重做成一条私有化管道的方案不算多，国内可以关注两类：压缩引擎如智压通 SmartSlim（产品页见此），覆盖 PDF、图片、OFD、扫描件等格式，压缩体积可降 60%-80%，且全程在本机完成；面向 RAG 场景的还有 RAG 数据工程基座，把预处理、脱敏、去重、切片串成流水线，图片类内容按 GPT-4o 口径实测 token 成本能省 85.9%。当然，具体效果要拿自己的文档实测，尤其抽几张压缩前后的关键页对比一下版式。
自建还是找现成的：该看的维度
不管自建还是选型，考察维度是通用的，列成一张框架表：
| 维度 | 要看什么 |
|---|---|
| 格式覆盖 | 是否含 OFD、扫描件、图片型 PDF，而非只有纯文本 PDF |
| 版式保真 | 压缩与解析后，版式、印章、表格能否还原 |
| OCR 质量 | 是否有置信度分档与二次增强，而非一跑了之 |
| 脱敏能力 | 字段类别、可配置性、是否在切片之前执行 |
| 去重策略 | 近重复检测的算法与版本保留逻辑 |
| 部署边界 | 是否全程本地运行，数据不出内网 |
| 衔接成本 | 是否只管入库前环节，能接现有向量库 |
最实用的验证方式：拿自己业务里最典型的 100 份真实文档跑一遍，逐环节查看中间产物。这比任何参数表和演示视频都靠谱。
立即体验
- RAG 数据工程基座（私有化部署、预处理与脱敏流水线）：https://www.uglypear.com/
- 智压通 SmartSlim 产品页（压缩引擎、桌面版、SDK 与 API）：https://www.uglypear.com/products/
- 丑梨数据技术博客（压缩与数据工程实操持续更新）：https://www.uglypear.com/blog/
常见问题
Q：怎么快速判断我的 RAG 问题出在数据层还是检索层？
A：从评测集里挑答错的 case，人工去向量库里翻它命中的原始 chunk。内容残缺、OCR 错字密集或版本过期，就是数据层的问题；内容完好但召回了不相关段落，才轮到调检索层。
Q：OFD 这类版式文件能进 RAG 管道吗？
A：可以，前提是走专门的版式解析而不是硬转 PDF。压缩环节也支持保真处理，官方实测 443 页 OFD 文档端到端 124 秒，章面与版式可保留。
Q：脱敏放在切片之后做行不行？
A：不建议。入库的就是脱敏后的 chunk，切片之后再脱敏意味着敏感字段已经过了一道向量化，中间产物本身就是泄露面。脱敏应放在切片之前。
Q：压缩过的文档做检索，质量会下降吗？
A：保真模式不动底层版式结构，只优化冗余数据，文本内容本身不受影响；图片类内容按 GPT-4o 口径 token 成本还能省 85.9%。建议入库前抽几页关键页放大确认。
Q：已经自建了向量库，这条管道怎么接？
A：管道只负责入库之前的环节——预处理、OCR、脱敏、去重、压缩，产出的结构化文本接进现有向量库即可，不需要推倒重来。