为 LLM 与检索管线准备 PDF

为什么不能只抽取原始文本

任何 PDF 库都能用几行代码把文档的文字给你，对于一份单栏备忘录，那确实够了。除此之外都不够，原因有三个，每一个都在消耗检索质量。

第一是阅读顺序。原始抽取按字形绘制的顺序返回文本，在双栏页面上这会把两栏交错在一起。你有一半的 chunk 会变成在无关段落之间来回跳的句子碎片，它们嵌入到向量空间中一个什么也不对应的点上。

第二是边界。没有标题，除了字符数就没有别的可切之处，于是 chunk 会从句子中间和表格中间断开；而一个从解释中途开始的 chunk 无法被单独理解——而这恰恰是被检索出来的 chunk 必须做到的事。

第三是表格。以原始文本抽取出来的表格会变成一串数字，完全没有标明它们各自来自哪一列。读到这些的模型照样会回答你的问题，只不过答案是错的。

Markdown 给管线带来什么

Markdown 在这里是个好的中间格式，理由与它好不好看毫无关系。

• 标题提供语义化的 chunk 边界，于是一个 chunk 是一个小节，而不是一千字符的窗口。
• 标题路径为每个 chunk 提供上下文——你可以在嵌入前加上「第 3 章 › 速率限制 › 突发行为」，这在同一个词于不同小节含义不同的文档上，能可测量地提升检索效果。
• 竖线表格保持行列的对应关系，读到被检索出的表格时，模型能分辨哪个数字属于哪个表头。
• 它很紧凑。Markdown 用每个元素几个字符的代价承载结构，而 HTML 或 JSON 布局格式会把 token 花在对模型毫无信息量的标记上。
• 当前所有模型在训练中都见过海量的这种格式，因此在提示词里不需要任何解释。

分块的具体做法

在转换后的文档上行得通的做法是：先按标题切分，只有在某一节过大时才退回到长度上限。

在多数文档类型上都站得住的粗略参数：

绝不要切开一张表

这是多数管线都会违反的规则，因为一个朴素的切分器根本不知道自己正处在表格中间。

一张 GFM 表格从中间切开会产生两个 chunk，而两个都不是有效表格：前一个有表头和若干行，后一个只有行、完全没有表头。后者比无用更糟，因为里面的数字没有标签，模型会靠猜给它们贴上标签。

在分块前先检测表格块，并让每一块保持完整，即使因此产生一个超出目标大小的 chunk。如果某张表确实大到一个 chunk 装不下，就在每一片里重复表头行。

扫描件放在哪个位置

扫描件没有文字，因此没有可分块的东西。必须先做文字识别——而它的输出有一些管线必须考虑的性质，因为识别是估计而非誊录。

尤其是两点。置信度逐页变化，因此一份文档可能有四十页近乎完美、三页不可靠；如果你的识别步骤会给出逐页置信度，请把它带进 chunk 的元数据，以便对低置信度的回答做标记。另一点是，读不出的词会被直接丢弃而不是标出，于是文本看起来通顺完整，缺失的却恰恰是引擎最吃力的部分——往往是人名、编号和数字。

凡是出错会有后果的场景，识别出的文本都应当被当作需要与原件核对的线索，而不是记录依据。

建立语料索引之前该检查什么

建索引是昂贵、缓慢且难以撤销的一步，所以先在样本上花二十分钟很值得。挑五份彼此差异明显的文档转换出来，把 Markdown 读一遍。

• 标题构成合理的层级了吗？如果一片扁平，你的切分器无处下手，整个语料都会退回固定长度的窗口。
• 表格活下来了吗？挑两三张，把列数与原文对照。
• 多栏页面的阅读顺序对吗？交错的栏，看一眼就很明显，一旦索引完成就再也看不见了。
• 有没有空的或几乎为空的转换结果？那些是扫描件，需要走另一条路径。
• 同样的样板内容是否在每份文档里重复？重复的页眉页脚会变成近似重复的 chunk，在检索结果里把真正的内容挤出去。

隐私这一维度，并非附带

RAG 语料恰恰是用组织最不愿交给第三方的文档搭起来的：合同、内部报告、客户记录、尚未发表的研究。

值得有意识地决定：你的管线里哪些步骤会把这些文档送出去。转换不必是其中之一——在浏览器里运行的转换器在文件本就所在的机器上处理它，因此转换这一步不会给链条增加任何一方。后续步骤会不会，是另一个决定——但那是一个你可以单独作出的决定。