夜雨聆风RAG 检索差的真凶 · PDF 解析
不是模型不行，不是检索算法不行，是入库前的那一步解析。A/B 双库实测 + 入库 SOP，一次讲清。
垃圾进，垃圾出——分段质量决定 RAG 效果的天花板
EDITOR NOTE
本文摘要RAG 检索差的真凶：不是模型，是入库前的 PDF 解析。A/B 实测 + 入库 SOP，一次讲清。
01
PART
问题复现
REPRODUCE · 知识库搭好了，用起来总差口气
前段时间我在 FastGPT 上搭了一个财报问答知识库，想验证一个一直没空细究的问题：为什么很多团队的知识库「看起来搭好了，用起来总是差口气」。
真实需求：用财务数据搭一个问答知识库，我准备测试的数据文档是贵州茅台 2025 年年度报告的财务部分——财报是 PDF 解析里最典型的「硬骨头」：表格密度高、数值颗粒度细，三张主表动辄跨页。截取 18 页（主要会计数据 + 审计报告 + 合并资产负债表 / 利润表 / 现金流量表），上传 FastGPT 知识库，默认分段，建库、训练、索引，一路顺利，没有任何报错。
然后我问了第一个问题：
贵州茅台 2025 年度的营业收入是多少？
模型开始一本正经地输出。数字是有的，但和原文对不上；再问一句「2025 年末公司的负债合计是多少」，这次干脆答非所问，把资产端的项目搬了过来。
让人崩溃的是，这份 PDF 是文字版，不是扫描件——在阅读器里用鼠标选中、复制，都完全正常。营业收入 168,838,102,514.79 元，明明白白写在第二页「主要会计数据」表格的第一行；负债合计 49,875,590,112.37 元，就在资产负债表里。数据就在库里，模型就是拿不对。
PDFlux 解析过的 md 格式导入知识库后能正确索引到：
不是模型不行，不是检索算法不行 是你喂给它的「料」从入库那一刻起就已经坏了。如果你也遇到过类似的场景——知识库搭建得无可挑剔，问答效果却时好时坏，简单问题能答、涉及表格数字就翻车——这篇文章可以给你解答。
下面拆开讲清楚：PDF 进知识库到底发生了什么；主流解析方法为什么容易掉链子；以及一套我现在自己在用的 PDF 入库 SOP。
02
PART
原因分析
ANALYSIS · 绘制指令、八步链路与效果上限
很多人对 PDF 有个根深蒂固的误解，以为它像 Word 一样「存着文字和段落」。实际上，PDF 内部存储的是一条条绘图指令：「在坐标 (503, 688) 处，用 8.5 号字、白色，绘制字形 m」。你看到的每一行文字、每一条表格线，都是阅读器根据这些指令实时渲染出来的。PDF 之于文字，就像图纸之于房子：图纸精确记录了每面墙的位置，但「哪三面墙围成卧室」这个信息，只存在于看图的人脑中。
做个实验进行测试：随手打开一份带表格的 PDF，选中一张表，复制，粘贴到记事本里。大概率你会得到一堆行列错乱的文字--这就是「绘制指令」被强行读成「文字流」的后果。人眼看着完好的表格，复制出来是碎的，因为结构信息从来就没有被存储过。
具体来说，PDF 不知道：
哪些字形属于同一个表格、同一行、同一列 阅读顺序是先左栏还是先右栏，横排还是竖排 哪个段落跨页了，哪条表格线只是行分隔、哪条是表边界 哪些重复出现的文字是页眉页脚，不属于正文 哪行字是大标题、哪行是正文
PDF 是为「人眼阅读和打印」发明的格式，不是为机器检索设计的格式
文档进知识库不是「整存整取」。一份 PDF 要变成可检索的知识，要走过一条完整的处理链路：
文档解析 -> OCR -> 结构还原 -> Markdown输出 -> 清洗 -> 切分 -> 入库 -> 检索
每道工序都可能产生损耗，而上游的损耗会被下游成倍放大。
① 文档解析：把绘制指令读成文本
解析器按坐标顺序读字，而文档是按视觉逻辑组织的。于是每页顶部的「贵州茅台酒股份有限公司 2025 年年度报告」和页脚的「57/143」，会被当成正文读出来；双栏文档的左右栏可能串行。我在实测里数过，18 页的文档，页眉页脚混入了几十处--它们不但污染所在分段，还会在检索「贵州茅台」「年度报告」这类词时制造大量虚假命中。
② OCR：只对扫描件生效，且只解决「识字」
文字版 PDF 直接走文本层；扫描件和图片型 PDF 才需要 OCR。要强调的是：OCR 解决的是「把图变成字」，不等于「把文档变成结构」--识别率再高的 OCR，吐出来的如果还是一串线性文本，表格行列、标题层级、阅读顺序的问题一个都不会少。很多同学以为「我做过 OCR 了，解析就没事了」，这是最常见的误区之一。
③ 结构还原：把线性文本重建成文档树
这是决定财报场景成败的一步。资产负债表在 PDF 里视觉上是「货币资金 | 51,690,610,946.50 | 59,295,822,956.89」这样规整的一行；线性化之后变成「货币资金 1 51,690,610,946.50 59,295,822,956.89」--科目、附注编号、本期值、上期值挤成一串，相邻行的数字互相污染。更隐蔽的是单元格内换行：我在实测里抓到一个典型 case，科目「筹资活动产生的现金流量净额」因为单元格内换行，在文本层里被拆成两截，直接搜完整科目名，搜不到。
④ Markdown 输出：给知识库一个「友好格式」
结构还原的结果需要一个载体输出。为什么是 Markdown？因为它是主流知识库工具的原生分段依据：标题层级天然对应分段边界，表格有标准语法，后续切分和检索都能「读懂」结构。输出成纯文本，前面还原的结构等于白做。
使用 PDFlux 解析的效果：
导出成 md 格式后结构没有丢失，非常清晰：
⑤ 清洗：去掉不参与语义的内容
页眉页脚、页码、水印文字、目录里的点线--这些内容对检索毫无贡献，混进去只会制造噪音。理想情况下在切分前剔除；很多解析方案没有这一步，只能靠知识库的分段规则「碰运气」。
⑥ 切分：把长文档切成可检索的分段
FastGPT 这类系统按「分隔符 + 长度上限」切段。输入是干净文本时，切出来的段落语义完整、向量表征准确；输入是乱文本时，切分器只能按长度硬切--于是出现「孤儿数字段」（整段只有几个数字，没有科目名）、「标题正文分家」（标题进了 A 段、内容在 B 段）、「半张表」（前几列在段 A，合计行在段 B）。
⑦ 入库 + ⑧ 检索：后面的一切都取决于前面
向量化、相似度检索、重排，本质都是在「已经切好的分段」里找答案。检索不会发明内容，embedding 也无法把一段乱码表征成「营业收入的准确数值」。
跨页问题值得单独说一句，它是 ③ 和 ⑥ 的复合伤害：茅台的合并资产负债表横跨 4 页，合并现金流量表横跨 3 页。解析按页处理，一张表从第 8 页断到第 9 页，断口处的行要么丢失、要么散落进两个互不相干的分段。
这是一种沉默的数据丢失 不专门核对根本发现不了。
垃圾进，垃圾出--分段质量决定了整个 RAG 系统的上限 后面你去调 top-k、调相似度阈值、换 embedding 模型、加重排，本质上都是在天花板下面挣扎。这就是为什么同一套 FastGPT 配置，喂不同的预处理结果，效果能差出一个档次。
03
PART
对比实验
EXPERIMENT · A/B 双库实测与方案盘点
道理讲完，拿实战数据说话：
文档
贵州茅台 2025 年年度报告（巨潮资讯网公开下载），截取 18 页财务部分
A 库
PDF 直接上传 FastGPT，默认分段--模拟「大多数人的默认做法」
B 库
先用 PDFlux 把同一份 PDF 解析成 Markdown，再上传 FastGPT
控制变量
两库索引模型、检索参数完全一致
测试集
12 个问题，覆盖五类场景
设计思路说明：正文类问题（审计机构、签字会计师）作为对照组--两库内容相同，理论上都该答对，差距应该只出现在表格和跨页题上；如果对照组都翻车，说明实验配置有问题。
先看最基础的单点数值题：「2025 年度营业收入是多少？」
打开 FastGPT 的搜索测试，返回的片段里确实有 168,838,102,514.79 这个数--单看「命中率」，A 库是合格的。但点开片段看内容，问题就来了：数值和相邻科目的数字混排在一起，本期上期两列数据糊成一串，科目归属要靠猜。
检索层面的「命中」，不等于生成层面的「可用」 大模型从这样一段文本里取数，取错列、错行是大概率事件--回看开篇的翻车，营业收入答错，根子就在这。
第二层真相在跨页题上：「2025 年末负债合计是多少？」标准答案 49,875,590,112.37 元，位于资产负债表跨页断口之后。A 库的搜索测试没有返回任何包含这个数值的片段。这次连「命中但乱」都做不到，是彻头彻尾的未命中--跨页拆散让内容在分段层面就不存在了，检索算法无辜，纯粹是「库里没有」。
真实的说，A 库并非完全不可用：正文类问题表现正常--「审计机构是哪家」（天健会计师事务所）、「签字会计师是谁」（李青龙、梁正勇、曾志）都能命中并正确回答。
差距集中在表格数值和跨页内容上，而这恰恰是财报问答这类场景的核心需求。这个现象本身也是个重要提示：如果你的知识库问答「简单问题都对、复杂表格全错」，问题几乎一定出在解析，而不是模型。
实验之前，我也盘点过手头能用的解析方案，大概三类，各有各的坑：
第一类：开源文本抽取库
PyPDF2、pdfplumber 这类。它们做的事情是「把文本层读出来」，定位是轻量通用。对纯文字文档够用；但它们不做（或只做很浅的）结构还原--表格靠启发式猜，跨页合并基本不管，标题层级靠字号猜且经常猜错。我准备实验问题时用 pdfplumber 读这份年报，连「筹资活动产生的现金流量净额」这样的科目名都被换行拆断，完整短语检索不到。这不是库的 bug，是「文本抽取」和「文档结构识别」本来就是两件事。
第二类：知识库平台自带的文件解析
胜在零门槛，上传即用。局限同样明显：解析是入库流程的附属步骤，以「能读出文字」为目标，不保证表格完整、不管跨页合并，更没有清洗环节。对规章制度、FAQ 这类简单文档完全够用；对报表类文档，就是本文实验展示的样子。
第三类：通用 OCR 服务
如果文档是扫描件，很多人的第一反应是「找个 OCR 识别一下」。如 2.2 节所说，OCR 只解决「识字」，不解决「结构」--识别输出的依然是线性文本，表格行列、阅读顺序、标题层级的问题原样保留，只是从「图片里的乱」变成了「文本里的乱」。
它们都停在链路的第 ①② 步，而 RAG 真正需要的，是走完 ③④⑤（结构还原、Markdown 输出、清洗）的完整链路 这也是我在给 B 库选解析方案时的核心标准--不是「识别率多高」，而是「能不能把文档结构完整地交到切分环节手上」。
TOOL
本文选用的解析方案PDFlux -- PDF Data Extraction，官方站点 pdflux.com
为了让我的 RAG 前置文档数据清晰、结构合理，我选了 PDFlux。PDFlux 的定位是高精度提取 PDF / 图片 / 扫描件中的表格和文本，官方口径表格提取准确率可达 99%，尤其擅长财务报表--正好是本实验最刁钻的部分。识别引擎是自研的 FinOCR，针对金融文档里最常见的低分辨率扫描件、印章遮挡、水印干扰做了专门优化，模糊扫描、无框线表格也能识别。庖丁科技本身就是从金融文档智能起家的，这条产品线在财报场景的行业纵深体现得很明显。
更关键的是它的「文档全景结构识别」能力，恰好覆盖了 2.2 节链路里的关键工序：物理对象检测、跨页（栏）对象合并、阅读顺序调整、文档逻辑结构识别，最终输出带层级的 Markdown。对照本文的诊断，四步正好回应四个损耗点：
病因和药理对上了，这才是我选它的原因 --先诊断出问题，再找恰好解决这些问题的工具，而不是反过来先选工具再找理由。
如果你想先上手感受一下：PDFlux 有 Web 版（webtool.pdflux.com，扫码登录即可体验）、客户端和小程序，适合零散文档的交互式处理--识别结果可视化核对，可手动框选修正；面向生产系统提供 SaaS API 和私有化部署。建议直接拿一份自己的真实报表试一次，比看十篇评测都直观。
用 API 把 18 页年报解析成 Markdown 后，我没有直接入库，而是先做了一轮程序化验收--这一步本身就是 SOP 的一部分。方法很朴素：把 12 个问题的标准答案数值整理成清单，写几行脚本在 Markdown 里逐个检索，再统计表格语法行数、标题层级数，和原文结构对照：
硬数值全覆盖
12 个测试问题涉及的标准答案数值，7 个硬数值（营业收入、货币资金、归母净利润、流动资产合计、流动负债合计、负债合计、期末现金及现金等价物余额）全部完整存在于 Markdown 中
结构完整
全文 481 行规整的 Markdown 表格语法、36 个层级标题，三张主表全部是连续完整的表格
断词修复
那个在原文本层被换行拆断的「筹资活动产生的现金流量净额」，在 Markdown 里是完整的
然后走完全相同的入库流程：上传 FastGPT、默认 Markdown 分段、同样的索引模型和检索参数，再跑同一组问题：
单点数值题
命中，数值坐在规整的表格行里，科目、本期、上期各归各位
跨页题「负债合计」
这次命中了--资产负债表在 Markdown 里是连续完整的表格，跨页断口在解析阶段就被合并掉了，「库里没有」的问题从根上消失
最有说服力的是对话环节。保持应用配置完全不变，只把关联知识库从 A 换成 B，问开篇同样两个问题：营业收入张口就来，精确到分；负债合计 49,875,590,112.37，一字不差；并且每次回答都带着清晰的来源引用，可溯源到具体分段。
两库对比一句话总结：差距不在检索算法，不在大模型，只在入库前那一步解析。
A 库 · 直接上传
检索命中了也不敢用--数值混排、跨页未命中
B 库 · 解析后入库
检索命中且直接可用--数值精确、来源可溯
04
PART
实践方案
PLAYBOOK · 可直接照抄的 PDF 入库 SOP
实验做完，我把这套流程固化成了 SOP，你可以直接抄作业。
任何 PDF 入库前，抽查 3-5 页（必须包含至少一页复杂表格、一页跨页表格），过一遍这四个判断：
PDF -> 专业解析(输出 Markdown) -> 抽查复核 -> 入库切分 -> 检索测试验收
↓ 不合格
人工修正 / 更换解析方案
两个要点：第一，「抽查复核」不能省--工具再准也有边界 case，PDFlux 也支持手动框选调整表格，但入库前的人工抽查永远是最后一道质量闸门；第二，「检索测试验收」用你平台的搜索测试功能跑几个真实问题，别等用户来当测试员。这两步我在实验里都实际做了：数值逐项对照、每题检索验证。
不吹不黑，给一个诚实的判断标准。
直接上传就够的场景：纯文字文档、几乎没有表格、对召回精度要求不高--产品 FAQ、规章制度、会议纪要这类。解析带来的边际收益有限，别为了解析而解析。
必须上专业解析的场景：
① 报表类文档
财务报表、运营数据、研究报告--答案藏在表格单元格里，线性化即报废
② 扫描件 / 图片型 PDF
文本层根本没有内容，不 OCR 就是空库，而且 OCR 之后依然要走结构还原。这个场景比文字版 PDF 更隐蔽--上传不报错、建库不报错，但扫描页在库里的内容是空的，检索时安静地返回「未找到」
③ 复杂版式
双栏论文、招股书、政府公文--乱序和层级丢失的重灾区
④ 业务系统批量接入
需要稳定、结构化、可校验的输出，而不是「看运气」
如果粘出来是乱的，你的知识库拿到的就是这份乱的 一个 10 秒自测法：把 PDF 里最复杂的一张表格复制粘贴到记事本--区别只是你看没看见。
个人零散文档，用网页工具交互式处理就够了；但 RAG 建设者面对的往往是几百上千份文档，人工点点点不现实，这时候要走 API。PDFlux 的 SaaS API 流程很简单，三步（token 在 saas.pdflux.com 的「API 密钥」页直接获取）：
# ① 上传文件，自动触发全景结构识别，记下返回的 uuid
curl --location 'https://saas.pdflux.com/api/v1/saas/upload' \
--header 'Authorization: Bearer <你的token>' \
--form 'file=@"年报节选.pdf"' \
--form 'force_update="true"'
# ② 轮询解析状态，直到返回 "parsed"： 2(解析完毕:0待解析/1解析中/-1异常)
curl --location 'https://saas.pdflux.com/api/v1/saas/document/<uuid>' \
--header 'Authorization: Bearer <你的token>'
# ③ 取 Markdown 结果，直接作为知识库输入
curl --location 'https://saas.pdflux.com/api/v1/saas/document/<uuid>/markdown' \
--header 'Authorization: Bearer <你的token>' \
-o '年报节选.md'
这三步套个循环、加个失败重试，就是一条「PDF 进、Markdown 出」的批量预处理流水线；下游接 FastGPT 的开放 API 自动建库，全程无人值守。本文实验的 18 页测试集就是这么处理的。
经过这次实验，我总结 RAG 前处理工具的四条硬标准：表格能不能整表还原、跨页能不能合并、输出是不是知识库友好的格式（Markdown）、有没有 API 支持批量。拿这四条去测你手头的真实文档，合格的就用--不用迷信参数，你的文档说了算。
前三条决定质量上限，第四条决定能不能进生产
CRITERIA05
PART
实验复盘
REVIEW · 结论立住了，按角色给建议
回到开头的翻车。同样的 FastGPT、同样的模型、同样的应用配置、同样的问题，只把「PDF 直接入库」换成「PDFlux 解析成 Markdown 再入库」：营业收入精确到分，负债合计一字不差，来源引用清清楚楚。真实文档、真实入库、真实检索--经过 PDFlux 处理的文档，检索效果确实立住了。
最后按角色给三条可立刻执行的建议：
本文没有讲任何高深的检索优化技巧，但它可能是你做检索优化之前最该先做的一步：垃圾进，垃圾出；好料进，基线就有了。向量模型、重排、混合检索这些优化，全都建立在「分段本身是好的」这个前提上--前提不成立，优化就是在流沙上盖楼。
INTERNAL SUMMARY
知识库问答效果不稳定，先别急着调参。如果抽查出来的分段是一团糊掉的线性文本，问题根本不在检索，而在入库之前的那一步。
随手抽查一个含表格的分段，看看它长什么样。
///
END
总结
SUMMARY · 六个核心要点
RAG 效果的天花板在入库前就定了--PDF 是为打印设计的格式，不是为检索设计的数据格式；解析质量决定分段质量，分段质量决定检索上限，调参优化都在天花板下面。
① PDF 不含结构信息
内部存储的是绘制指令而非文档结构，表格行列、标题层级、阅读顺序从未被存储；直接入库，等于把「看起来完好」的视觉内容交给只能读文本流的系统
② 链路前半段最易被跳过
解析、OCR、结构还原、Markdown、清洗这五步，常被「直接上传」一笔带过，却决定切分与检索的质量；OCR 只解决识字，不等于结构还原
③ 实测结论
A 库数值题「命中但不可用」、跨页题彻底未命中；B 库全部命中、答案精确、来源可溯；差距不在模型与检索，只在入库前那一步解析
④ 入库前判断四问
解析结果是否清晰？表格是否完整？文本顺序是否正常？是否便于后续切分？
⑤ 场景判断
纯文字、低精度要求（FAQ、制度、纪要）直接上传即可；报表类、扫描件、复杂版式、批量接入，必须走专业解析
⑥ 工具选型四条标准
表格能否整表还原、跨页能否合并、输出是否为 Markdown、有无 API 批量；前三条定质量上限，第四条定生产可行性
垃圾进，垃圾出；好料进，基线就有了
如果你觉得今天这篇有收获，欢迎点赞、在看、转发三连，我们下篇见
THANKS FOR READING