你的RAG卡在第三步:文档解析搞砸了,后面全白搭

我的判断是，你的RAG卡在实在不行再走这一步：文档解析搞砸了，后面全白搭真正重要的不是把道理讲完整，而是把读者下一步能做什么说清楚。

说起来挺让人沮丧的。

你花了两周时间把 RAG 跑通了。Embedding 模型调好了，向量数据库搭好了，检索链路也接上了。Demo 测起来一切正常——问一个问题，答案返回来，像那么回事。

然后你把真实文档接进去了。

一份 PDF 合同，表格密密麻麻的那种。问「这份合同里 A 公司的付款周期是多久」，RAG 返回了一串乱码一样的答案，表格列全串了，数字不知道从哪一格读出来的。

你开始调 Chunk Size。调了。换了 Embedding 模型。换 Embedding 模型。调检索阈值。调了。

还是不准。

问题根本不在 Embedding，不在向量数据库，不在检索策略。

问题出在文档解析这一步——在你把 PDF 扔进向量数据库之前，那一步就已经把表格结构撕碎了。

为什么 PDF 和表格是工业级 RAG 的第一道坎

先说清楚一件事：Demo 阶段几乎没人遇到这个问题。

因为 Demo 用的都是干净的 Markdown 文件，或者纯文本段落，结构规整，没有任何复杂格式。Embedding 模型处理一段干净文本，几乎不会出错。

但真实世界不是 Markdown。

真实世界的文档是这样的：

财务报告：跨页大表格，合并单元格，多级表头
合同：扫描件 PDF，歪斜角度，印章覆盖
技术手册：图文混排，左图右文，截图嵌入
审批表单：手写字体，表格线不完整，关键数字靠框线分隔而非真实单元格

这些文档丢进一个普通解析器，表格会变成什么？

行变成一坨字符串，列对应关系完全丢失。Embedding 模型拿到的是一堆语义破碎的文本碎片，它在语义上不可能理解「这是表格的第三列而不是第二列」。

因为表格的结构信息在解析那一步就已经丢失了，后面无论怎么调 Embedding 都不可能把它找回来。

这就是工业级 RAG 和 Demo RAG 的本质区别：

Demo 阶段处理的是干净文本，工业级 RAG 处理的是真实世界的脏文档。

最小可用的解析方案

不是所有人都有资源搭一套企业级文档解析 pipeline。先说最小可用的方案，能跑起来，能验证，能迭代。

工具一：Marker（推荐起步）

Marker 是一个开源的 PDF 解析工具，核心优势是把 PDF 转成 Markdown 的同时，保留表格结构、公式和图片说明。它对扫描件的 OCR 支持也比较稳定。

适合场景：合同、报告、扫描件这类以文字和表格为主的 PDF。

工具二：LlamaParse

LlamaParse 来自 LlamaIndex 团队，对复杂表格的解析质量比通用解析器高一个档次。它输出的结构化数据更干净，适合后续做 RAG 以外的结构化分析。

适合场景：对表格解析质量要求更高的知识库场景，尤其是财务、审计、供应链类文档。

两个工具的核心区别：

Marker 更通用，上手更快，适合快速验证；LlamaParse 对复杂表格的解析更精准，但配置成本略高。

最小验证步骤：

不管用哪个工具，解析完之后不要直接扔进向量数据库。先打开解析结果，肉眼扫一遍——重点看三类内容是否正常：

表格：列对齐，行对应，数字没串位
公式：LaTeX 公式有没有被截断或乱码
扫描件文字：OCR 识别的准确率是否可接受

肉眼验证过了，再进向量数据库。这一步看起来笨，但能省掉后面调 Embedding 调半天还找不到根因的痛苦。

解析质量怎么验证

验证解析质量有一个土办法，但管用：

对照法。

找一份真实文档，人工读一遍文档里表格 A 的内容，记下几个关键值（比如某行的付款周期、某列的设备型号）。然后把同一个问题扔给 RAG，看它返回的值和你人工记住的是否一致。

不一致的地方，90% 是解析出了问题，而不是 Embedding 或检索出了问题。

这个验证方法比任何评估指标都直观。它让你在调系统之前，先确认「原材料」是不是对的。

如果解析质量长期不稳定，可以考虑在解析 pipeline 里加一层结构化输出：用 LLM 把解析结果再转成 JSON 或 CSV，保留原始表格的行列对应关系，再入向量库。

代价是解析时间更长，适合对精度要求极高的场景（合同审核、财务审计），不适合需要秒级响应的场景。

RAG 查不准，先问这三个问题

当 RAG 返回结果不准的时候，大多数人的排查顺序是这样的：

换 Embedding 模型
调 Chunk Size
加 Rerank
换向量数据库

但正确的排查顺序应该是：

先看这里，文档解析是否正确保留了关键信息？

打开解析后的 Markdown 或文本文件，找到原始文档里那个「正确答案」所在的位置，看它是不是还保持原来的结构。这一步过滤掉 80% 的「RAG 查不准」问题。

再看一眼，Chunk 切分是否把关键上下文切碎了？

如果答案需要跨段落甚至跨页的信息，但切分的时候刚好在中间断了，检索阶段根本不可能把完整上下文召回。这种情况要调 Overlap 或者改用按文档结构切分。

还有这个，Embedding 是否真的理解了这个领域？

通用 Embedding 模型在通用文本上表现稳定，但在垂直领域（医疗、法律、供应链）上可能出现语义偏差。如果前两步排查完还是不准，可以试试在同领域语料上微调的 Embedding，或者直接上秦无网.

大多数人的问题是：在第一步就卡住了，但花了全部时间在第三步调 Embedding。

回到那个让人沮丧的场景

你花了两周把 RAG 跑通，把 Embedding 调了三遍，把向量数据库换了两家。

然后真实文档一进来，全崩了。

你开始怀疑模型能力，开始怀疑向量检索，开始怀疑是不是自己的提示词不够好。

其实问题在更前面——在文档进向量数据库之前，那一步就决定了后面所有努力的起点质量。

解析搞砸了，后面全白搭。

这不是你的 Embedding 不够好，是文档解析那个环节，从一开始就没有被认真对待过。

工业级 RAG 的能力，是从文档解析开始的。

以上，既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，如果想第一时间收到推送，也可以给我个星标⭐～谢谢你看我的文章，我们，下次再见。