RAG答错别急着换模型：文档预处理才是效果分水岭-北京尧图网络

1. 为什么模型背了锅RAG 答错的真实归因RAG 答错的时候绝大多数人的第一反应是换模型。从 7B 换到 14B从 14B 换到 70B再不行就上闭源 API账单翻了几倍效果可能只提升了几个百分点。我见过太多团队在这个循环里反复横跳最后把问题归结为“模型能力不够”。但如果你把整条链路拆开看一个 RAG 系统的回答质量模型只占其中一环。检索到的内容对不对、文档解析出来的文本干不干净、切分后的 chunk 有没有把语义切断、embedding 有没有把关键信息编码进去——这些环节里任何一个出问题后面换再大的模型也救不回来。用一句话概括就是垃圾进垃圾出。这个道理听起来简单但实际操作中文档进入系统之前的那段流程恰恰是最容易被忽视的。大家把精力花在调 prompt、换模型、加 rerank 上却很少有人回头看看那份 PDF 解析出来之后表格是不是变成了乱码那份 Word 文档里的标题层级是不是全丢了那份扫描件 OCR 之后错字率是不是高得离谱我做过一个粗略的统计在我经手的 RAG 项目里回答质量不达预期的案例中超过六成的问题根源在文档预处理阶段而不是模型本身。这个比例可能因场景而异但方向是明确的文档进入系统之前的那段路才是 RAG 效果的分水岭。这篇文章就是围绕这个判断展开的。我会把文档从原始文件到进入向量库的完整链路拆开逐段讲清楚每个环节在做什么、容易在哪里出问题、怎么排查、怎么修。适合正在做 RAG 项目但效果卡住的同学也适合刚开始搭知识库、想少走弯路的开发者。不需要你精通 NLP但需要对 RAG 的基本流程有个概念。2. 文档进入系统之前的完整链路拆解2.1 从原始文件到向量库的五个阶段一份文档从硬盘上的文件变成向量库里的一条记录中间要经过五个阶段。很多人只关注最后两个阶段前面三个基本是“能跑就行”问题就出在这里。第一阶段是格式解析。PDF、Word、Excel、PPT、HTML、Markdown、扫描件每种格式的解析难度完全不同。PDF 是最麻烦的因为它本质上是一个排版格式不是内容格式。文字在 PDF 里是按坐标定位的解析器需要推断阅读顺序。表格更麻烦PDF 里的表格没有结构信息解析器只能靠线条和间距去猜。第二阶段是内容清洗。解析出来的原始文本里会有大量噪音页眉页脚、页码、水印、乱码、多余的空格和换行、重复的段落。这些东西如果不清理会直接进入后续环节污染检索结果。第三阶段是结构化处理。把线性文本还原成有层级的内容识别标题、正文、列表、表格、代码块。这一步决定了后续切分时能不能保持语义完整。第四阶段是切分。把长文档切成适合 embedding 的小块。切分策略直接影响检索命中率切大了语义模糊切小了上下文丢失。第五阶段是向量化与入库。用 embedding 模型把文本块转成向量存入向量数据库同时保留元数据用于过滤和溯源。这五个阶段里前三个阶段是“文档进入系统之前”的部分也是本文的重点。后两个阶段虽然也重要但前提是前面的输入是干净的。2.2 为什么预处理阶段最容易被跳过预处理阶段被跳过原因很现实它不出现在 demo 里。你搭一个 RAG demo拿几篇干净的 Markdown 文档解析、切分、embedding、检索、生成跑通了效果还不错。于是你觉得这套流程没问题开始往里面灌真实数据。结果 PDF 解析出来一堆乱码表格变成了数字堆扫描件 OCR 错字连篇。这时候你第一反应是“模型不行”而不是“文档没处理好”。另一个原因是预处理没有标准答案。切分切多大清洗洗到什么程度结构化做到什么粒度这些问题没有统一的最优解取决于你的文档类型和查询场景。没有标准答案的事情大家就倾向于用默认值而默认值往往是最粗糙的。还有一个原因是预处理的效果很难量化。检索命中率可以算回答准确率可以评但“文档解析质量”怎么衡量没有现成的指标大家就不去衡量不去衡量就不去优化。2.3 一个真实的翻车案例我接手过一个企业知识库项目文档主要是产品手册和售后工单格式以 PDF 和 Word 为主。团队用的是当时比较主流的方案PDF 用某个开源解析库Word 用 python-docx切分用固定长度 512 字符embedding 用某个通用模型。上线之后用户反馈最多的问题是“答非所问”。比如问“XX 型号的保修期是多久”系统检索到的内容里确实有“保修期”三个字但回答出来的却是另一个型号的保修政策。团队一开始以为是模型幻觉换了两个模型问题依旧。我让他们把检索到的原始 chunk 打出来看问题一目了然PDF 解析出来的文本里表格全部变成了按行排列的纯文本型号和保修期之间的对应关系完全丢失。检索时命中了“保修期”这个词但周围的上下文里混着好几个型号模型只能猜。这不是模型的问题是文档解析阶段把结构化信息压平了。后来我们重新做了表格解析把每个型号和对应的保修期绑定成一个独立的 chunk问题就解决了。模型没换prompt 没改只是把文档进入系统之前的那段路修好了。3. 格式解析不同文档类型的坑与解法3.1 PDF 解析的三种路线与选型逻辑PDF 解析是文档预处理里最复杂的一环。市面上的方案大致分三类各有各的适用场景。第一类是基于规则的传统解析库。这类工具通过分析 PDF 内部的文字对象、字体信息、坐标位置来推断阅读顺序和段落结构。优点是速度快、资源消耗低、对纯文本 PDF 效果好。缺点是遇到复杂排版多栏、表格、图文混排就容易出错对扫描件完全无能为力。第二类是基于 OCR 的解析方案。先把 PDF 每页转成图片再用 OCR 识别文字。优点是通吃所有 PDF包括扫描件。缺点是速度慢、错字率取决于 OCR 质量、表格结构还原困难。而且 OCR 出来的文本没有字体信息标题和正文区分不了。第三类是近年来出现的基于深度学习的文档理解模型。这类模型能同时处理文字、版面、表格结构输出带层级和表格结构的结构化内容。优点是效果好尤其是表格和复杂版面。缺点是需要 GPU、推理速度慢、部署成本高。选型逻辑很简单先看你的文档里有没有扫描件再看有没有复杂表格最后看预算和延迟要求。纯文本 PDF 用第一类就够了有扫描件就必须上 OCR表格多且结构重要就考虑第三类。不要一上来就追求最贵的方案也不要为了省钱用完全不适合的方案。3.2 Word 与 Excel 的结构化解析要点Word 文档看起来比 PDF 好处理因为它的底层是结构化的 XML。但很多人用 python-docx 只取paragraph.text把样式信息全丢了。标题、正文、列表、表格全部变成一样的纯文本后续切分时完全不知道哪里是章节边界。正确的做法是解析时保留样式信息。paragraph.style.name能告诉你这是 Heading 1 还是 Normal表格可以用document.tables单独提取。标题信息在切分时非常有用你可以按标题层级来切保证每个 chunk 属于同一个章节。Excel 的坑又不一样。Excel 是二维表格但很多业务表格是“人类可读”的不是“机器可读”的。比如合并单元格、多级表头、注释行混在数据里。直接按行读取出来的东西根本没法用。处理 Excel 的关键是先理解表格的语义结构。表头在哪一行有没有合并单元格哪些列是维度哪些列是指标这些信息决定了你怎么把一行数据转成一段自然语言描述。比如一行“型号 A | 保修期 12 个月 | 保修范围主板”应该转成“型号 A 的保修期为 12 个月保修范围为主板”而不是把三个单元格用空格拼起来。3.3 扫描件与图片文档的 OCR 处理策略扫描件的处理核心是 OCR但 OCR 只是第一步。识别出来的文本没有段落结构你需要根据行间距、缩进、字体大小如果 OCR 能提供来推断段落边界。OCR 的错字率是个大问题。通用 OCR 对印刷体效果不错但遇到表格、公式、特殊符号就容易出错。如果文档里有大量专业术语可以考虑用领域词典做后处理纠错。另一个技巧是保留 OCR 的置信度信息低置信度的词在后续检索时可以降权或标记出来。还有一个容易被忽视的点扫描件的图片质量直接影响 OCR 效果。如果原始扫描件分辨率低、有倾斜、有噪点先做图像预处理去噪、纠偏、二值化再送 OCR效果会好很多。这一步多花的时间比后面换模型省下的时间划算得多。3.4 解析质量的自检清单解析完之后不要直接进入下一步。花十分钟做个体检能避免后面几小时的排查。检查项检查方法合格标准文本完整性随机抽 5 页对比原文和解析结果无大段缺失无乱码阅读顺序检查多栏文档的解析结果文字顺序符合人类阅读习惯表格结构找一个有表格的页面表格行列对应关系正确标题识别检查章节标题是否被标记标题与正文可区分特殊字符搜索公式、符号、单位无异常转义或丢失页眉页脚检查是否混入正文已清理或可过滤这个清单看起来简单但能筛掉大部分低级问题。我见过太多项目解析出来的文本里混着页码和页眉检索时经常命中这些噪音模型被误导得莫名其妙。4. 内容清洗与结构化把噪音挡在门外4.1 清洗规则的设计与优先级清洗不是越狠越好。洗得太狠可能把有用的信息也洗掉了洗得太轻噪音会污染检索。关键是要分清哪些是确定的噪音哪些是可能有用但需要处理的内容。确定的噪音包括页眉页脚、页码、水印文字、重复的版权声明、解析产生的乱码字符。这些可以直接删。可能有用但需要处理的内容包括脚注、参考文献、图表标题、代码块。这些不能直接删但也不能和正文混在一起。脚注可以单独存成元数据图表标题可以附加到对应的表格或图片描述上。清洗规则要有优先级。先处理确定的噪音再处理格式问题多余空格、换行、全角半角最后处理语义层面的问题重复段落、无关内容。顺序反了的话后面的规则可能会被前面的噪音干扰。4.2 标题层级还原与章节切分标题层级是切分的地图。如果解析阶段保留了标题信息这一步就简单了按标题层级构建一棵树每个叶子节点就是一个自然的切分单元。如果解析阶段没保留标题信息就需要从文本特征去推断。常见的启发式规则包括短行且独立成行、以数字编号开头、字体加粗或放大、前后有空行。这些规则不完美但比盲目按长度切分好得多。标题还原的粒度要适中。太粗一个章节几千字切出来的 chunk 太大太细每个小节都切成独立 chunk上下文丢失。我的经验是切到二级或三级标题比较合适具体取决于文档的层级深度和每个章节的平均长度。4.3 表格与图片的结构化表示表格是 RAG 里最容易丢信息的地方。纯文本化之后行列对应关系没了模型只能靠猜。正确的做法是把表格转成结构化表示常见的有三种第一种是Markdown 表格。适合小表格行列清晰embedding 模型对 Markdown 格式的表格有一定理解能力。缺点是列多了之后每行的文本会很长embedding 效果下降。第二种是键值对展开。把每一行转成“列名值”的形式比如“型号A保修期12 个月保修范围主板”。这种方式对 embedding 友好检索时容易命中。缺点是行数多了之后chunk 数量会膨胀。第三种是自然语言描述。把表格内容转成一段话比如“型号 A 的保修期为 12 个月保修范围为主板型号 B 的保修期为 24 个月保修范围为主板和屏幕”。这种方式最接近人类的表达习惯检索效果通常最好但生成描述需要额外的处理逻辑。图片的处理类似。如果图片里有文字先 OCR如果是图表考虑用多模态模型生成描述如果是装饰性图片直接跳过。图片描述要和周围的正文关联起来不能孤立存在。4.4 元数据提取让检索多一个维度元数据是检索时的过滤器。同样的查询加上元数据过滤命中率能提升一大截。常见的元数据包括文档来源、文档类型、创建时间、所属部门、产品型号、版本号。这些信息在解析阶段就能提取存到向量库的 metadata 字段里。检索时可以根据查询意图做过滤比如用户问“最新版的保修政策”就可以按版本号或时间过滤。元数据提取的关键是和业务场景对齐。不是所有能提取的字段都有用要选那些用户查询时可能用来筛选的维度。提取太多维护成本高提取太少过滤能力弱。我的建议是先提取三到五个核心字段上线后根据实际查询日志再调整。5. 切分策略决定检索命中率的关键一步5.1 固定长度切分的适用边界固定长度切分是最简单的策略按字符数或 token 数切每段 512 或 1024段间留一点重叠。很多人用它是因为它简单不需要理解文档结构。但固定长度切分有个致命问题它会在语义边界之外切断文本。一个完整的论述被切成两半前半段在 chunk A后半段在 chunk B。检索时命中了 chunk A但缺少后半段的上下文模型回答时就会断章取义。固定长度切分不是不能用而是有适用边界。它适合那些结构松散、没有明显章节划分的文档比如聊天记录、日志、短评。对于有明确结构的文档手册、论文、合同固定长度切分是在浪费文档本身的结构信息。5.2 语义切分的实现思路语义切分的核心思想是在语义边界处切而不是在字符数边界处切。最简单的语义切分是按段落切。段落本身就是作者划分的语义单元按段落切天然保持了语义完整。缺点是段落长度不均匀有的段落只有一句话有的段落上千字。进阶的做法是按标题层级切。前面说的标题还原就是为这个服务的。每个叶子节点是一个语义单元切出来的 chunk 自带章节上下文。再进阶的做法是用 embedding 相似度来检测语义边界。计算相邻句子的 embedding 相似度相似度骤降的地方就是语义边界。这种方法效果好但计算成本高适合对质量要求极高的场景。实际操作中我通常用标题层级段落长度上限的组合策略优先按标题切标题下按段落切段落超过长度上限时再按句子切。这样既保持了语义完整又控制了 chunk 大小。5.3 重叠窗口的设置与计算重叠窗口是为了解决“边界信息丢失”的问题。如果 chunk A 和 chunk B 之间没有重叠恰好切在关键信息中间检索时可能两边都命中不全。加上重叠之后关键信息至少在一个 chunk 里是完整的。重叠大小怎么定经验值是 chunk 大小的 10% 到 20%。chunk 是 512 token重叠就设 50 到 100 token。太小起不到作用太大浪费存储和检索资源。但重叠不是万能的。如果切分点本身就不合理比如切在表格中间加再多重叠也救不回来。重叠是补救措施不是解决方案。先把切分点选好再用重叠兜底。5.4 切分效果的快速验证方法切分完之后怎么知道切得好不好我常用一个简单的方法随机抽 10 个 chunk读一遍问自己三个问题。第一个问题这个 chunk 单独拿出来能不能看懂它在说什么如果看不懂说明上下文丢失太多。第二个问题这个 chunk 里有没有完整的语义单元如果一句话被切成两半说明切分点选得不好。第三个问题这个 chunk 里有没有无关内容如果混入了页眉页脚或其他章节的内容说明清洗或切分有问题。这三个问题不需要任何工具十分钟就能做完。如果 10 个 chunk 里有 3 个以上有问题说明切分策略需要调整。6. 常见问题与排查技巧实录6.1 检索命中但回答错误的排查路径“检索到了相关内容但回答还是错的”这是最常见的症状。排查路径如下第一步把检索到的 chunk 原文打出来逐字读一遍。很多时候问题一眼就能看出来chunk 里有多个相似实体模型分不清或者关键信息被截断了模型只能猜。第二步检查 chunk 的元数据。如果元数据里有版本号、时间、来源看看检索到的 chunk 是不是过期版本或错误来源。第三步检查查询和 chunk 的匹配方式。如果是关键词匹配看看是不是只匹配到了表面词没有匹配到语义。如果是向量匹配看看 embedding 模型是否适合当前领域。第四步如果前三步都没问题再考虑模型和 prompt。这时候换模型或调 prompt 才是有意义的。6.2 表格数据检索失效的修复方案表格数据检索失效通常是因为表格被压平成了纯文本行列对应关系丢失。修复方案分三步第一步重新解析表格保留行列结构。如果原解析器不支持换一个支持表格结构提取的工具。第二步把表格转成适合检索的格式。小表格用 Markdown大表格用键值对展开或自然语言描述。第三步给表格 chunk 加上元数据比如表名、列名、所属章节。检索时可以用这些元数据做过滤或重排。我做过一个对比测试同一份产品参数表压平处理后的检索命中率是 40% 左右结构化处理后的命中率能到 85% 以上。差距非常明显。6.3 多栏 PDF 阅读顺序错乱的解决多栏 PDF 的阅读顺序错乱是因为解析器按坐标排序时把左右两栏的文字混在了一起。解决方法有两种一种是换用支持版面分析的解析工具。这类工具能识别分栏结构按栏分别提取文字。另一种是在解析后做后处理。根据文字的 x 坐标聚类把同一栏的文字归到一起再按 y 坐标排序。这个方法需要一些调参但对特定版式的文档效果不错。如果文档版式固定后处理方案的成本更低。如果版式多样还是换工具更省心。6.4 常见问题速查表症状可能原因排查方法修复方案检索命中但回答错误chunk 内有多个相似实体打印 chunk 原文切分时按实体拆分表格数据检索不到表格被压平检查 chunk 是否含表格结构结构化表格表示多栏 PDF 顺序错乱解析器按坐标排序检查解析后文本顺序换工具或后处理扫描件错字多OCR 质量差抽查 OCR 结果图像预处理领域词典检索结果重复重叠窗口过大检查 chunk 重叠比例降低重叠到 10%长文档检索不全切分粒度过粗检查 chunk 平均长度按标题层级细切元数据过滤失效元数据未提取或格式不对检查向量库 metadata重新提取并入库6.5 几个反直觉的实操心得第一个心得清洗过度比清洗不足更危险。我见过一个项目清洗规则写得太激进把所有的数字和单位都当噪音删了结果产品参数全没了。清洗规则要保守宁可留一点噪音不要误删有用信息。第二个心得切分粒度不是越细越好。切得太细每个 chunk 只有一两句话检索时命中率高但上下文不足模型回答时缺乏依据。切得太粗检索时命中率低但上下文丰富。平衡点取决于你的查询类型事实型查询适合细切分析型查询适合粗切。第三个心得embedding 模型的选择要和切分策略匹配。有些 embedding 模型对长文本效果好有些对短文本效果好。切分粒度变了embedding 模型可能也要跟着换。不要一套配置用到底。第四个心得文档预处理的效果要用检索指标来验证不要凭感觉。解析完觉得“看起来还行”切分完觉得“应该没问题”这些都是主观判断。用一组标准查询测一下命中率用数据说话。7. 把功夫花在进入系统之前回到开头那个判断RAG 答错的时候先别急着换模型。模型是整条链路的最后一环它只能基于检索到的内容来回答。如果检索到的内容本身就是错的、残缺的、混乱的再强的模型也变不出正确答案。文档进入系统之前的那段路包括格式解析、内容清洗、结构化处理、切分策略每一步都在决定最终进入向量库的内容质量。这段路走好了后面的事情会顺很多这段路走歪了后面怎么调都是事倍功半。我在实际项目中的体会是把 60% 的优化精力花在文档预处理上剩下 40% 花在检索和生成上整体效果比反过来分配要好得多。预处理是地基地基不稳上面盖什么都是危房。最后分享一个小技巧每次调整预处理策略后不要只看整体效果要分文档类型看效果。PDF 的命中率提升了但 Word 的下降了说明你的策略对某类文档过拟合了。分类型监控才能找到真正通用的策略。

RAG答错别急着换模型：文档预处理才是效果分水岭

相关推荐

Formula One 9.0 工业级表格控件深度解析与COM集成实战

Python写模型，Java扛服务：AI落地的真实分工

RAGFlow企业知识库选型与部署实战：DeepDoc解析、GraphRAG与Dify对比

更多资讯

C++格式化输出三套体系：printf、cout与std::format深度对比

以太坊三棵树设计解析：MPT与状态存储优化

NY8B062F嵌入式选型与ADC/PWM工程实践指南

PDF在线阅读器源码：Canvas渲染与移动端Range分片实现

以太坊三棵树架构解析与MPT优化实践

多目标优化中的决策变量关系建模与算法设计

今日更新

PLFM_RADAR：从被动告警到主动感知的微服务健康监控系统

SPI隔离设计实战：MAX14431BAEE+与STM32F407工业级应用

数字隔离器如何根治SPI通信地环路干扰：MAX14431与TM4C129实战

本周精选

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

本月热门

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

读完文章，想聊聊您的网站？