你有没有试过复制一份PDF里的表格粘贴到Excel里？
多半会得到一堆散乱的文字碎片，行列全乱了，数字和标题对不上号。这不是软件的bug，而是PDF这种格式天生的毛病。它从设计之初就是给人眼看的排版格式，不是给机器读的语义格式。文字在PDF里是按几何坐标摆放的，不是按阅读顺序存储的。
这件事放在企业知识库里会变得更麻烦。想象一家银行要把几百份产品手册、费率表、保险条款喂给AI客服系统，这些文档里全是多栏排版、密密麻麻的表格、还有各种字体大小不一的标题。如果AI读不懂这些内容的结构，那它给用户的回答很可能是错的。
这就是Yellow.ai团队这篇论文要解决的问题。他们给这套系统起名叫D-RAC，全称是Document Retrieval-Aware Chunking。
先搞懂：为什么"读PDF"比"读网页"难这么多
论文团队之前做过一个叫W-RAC的项目，专门处理网页内容。网页有个好处，它是HTML写的，标签清清楚楚，标题就是标题标签，段落就是段落标签，机器解析起来毫不费力。基于这个结构，W-RAC实现了一个很聪明的设计：不让AI重新生成文字内容，而是让AI给内容"贴标签"，指出哪几段应该分到一个知识块里。这样AI输出的东西极少，只是一串ID编号，不是大段文字，省钱又快。
**这套方法把网页处理的效率提升了一大截：输出token减少84.6%，成本降低51.7%，延迟减少约60%。**
但问题来了，企业里真正堆积如山的文档不是网页，是PDF、是Word文档、是PPT、是扫描件。这些格式里根本没有HTML那种清晰的标签结构，W-RAC那套"贴ID标签"的巧妙做法在PDF面前直接失灵，因为你压根没有可以贴标签的结构。
传统处理PDF的办法大概分三条路。第一条是用PyMuPDF、pdfplumber这类工具硬提取文字，快是快，但读出来的顺序经常是乱的，多栏排版一读就串行，表格变成一堆用空格隔开的数字。第二条路是上LayoutLM这种专门做版面分析的模型，效果好一些，但遇到保险宣传册、产品单页这种不按常理排版的文档还是会翻车，而且表格提取出来还是网格状，一个单元格的数字脱离了行列标题，压根看不懂它是什么意思。
*LayoutLM：一种专门用来理解文档图像版面结构的深度学习模型，能识别文字块的位置关系*
第三条路是让大模型直接读取提取出来的乱文字，让它自己重新组织成语义连贯的知识块，这就是所谓的"agentic chunking"（智能体式分块）。
*agentic chunking：让大语言模型直接阅读文档原文并重新生成语义完整的文本片段，作为检索系统的最小单元*
这条路效果不错，但代价极高。因为AI要一边修复提取时留下的错误，一边把整篇文档重新写一遍，这意味着极大的输出量，而输出token的价格通常是输入token的4到8倍。
这就是D-RAC团队面对的真实困境：结构好的格式，可以用便宜的方法处理；结构差的格式，只能用昂贵的方法处理。他们想问的问题是，能不能找到一个折中点，既拿到PDF里被藏起来的结构，又不用为此付出天价的token账单。
D-RAC的核心思路：先"拍照"，再"转录"，然后才轮到分块
D-RAC的解法说起来其实不复杂，四个步骤。
第一步是格式归一化。不管你丢进来的是DOCX、PPTX、XLSX、扫描图片还是原生PDF，系统先把它统统转换成PDF。这一步完全不需要AI，用LibreOffice这类开源工具就能搞定，纯粹是机械转换，不会丢失任何视觉信息。转换完之后，每一页PDF被渲染成一张200 DPI的PNG图片，尺寸压缩到不超过1568像素，正好匹配主流视觉模型能吃下的输入规格。
这一步背后的逻辑值得琢磨一下。企业里的文档格式五花八门，如果为每种格式单独写一套解析器，那工程量会指数级增长，而且总会有奇奇怪怪的格式漏网。但几乎所有办公文档格式都能被稳定地渲染成PDF，这是个已经被验证过无数次的成熟技术路径。选择PDF作为"通用视觉中转站"，本质上是把"支持N种格式"的问题，简化成了"支持1种格式转换到另1种格式"的问题。
这就好比一个国际机场处理来自世界各地的乘客。如果机场要为每个国家的护照单独设计一套核验流程，那系统会复杂到崩溃。但如果所有乘客都先换发一张统一制式的登机牌,后续的安检、登机、行李托运就都能用同一套流程处理。如果不这么做，每种文档格式都得单独维护一套解析代码，任何一种格式升级了内部结构，这套代码就得跟着重写，而PDF渲染这条路走通了之后,新格式来了只需要确认它能不能转成PDF，其他一概不用管。
第二步是最关键的一步：多模态Markdown转换。
*多模态LLM：能够同时理解图像和文字的大语言模型，这里指Gemma-3系列模型，可以直接"看"PDF页面图片并输出结构化文字*
系统把渲染好的页面图片，每5页打包成一批，送进多模态大模型（论文里用的是Gemma-3 27B和12B），最多5批并行处理。这个模型的任务只有一个，把图片里的内容转录成结构清晰、适合检索的Markdown文本。
这里有几条硬性规则特别值得说一说。第一条是逐字保留，不许总结、不许跳过任何文字内容。第二条是表格处理规则，绝对禁止用Markdown表格语法，每一行数据都要被改写成一句独立完整的话，用列标题当作上下文。比如一张保单条款表，"保单期限16年"对应"缴费期8年"，就要写成"当保单期限为16年时，缴费期为8年，领取期为25年"这样一句完整的话，而不是拆成表格格子。
*retrieval-aware normalization：检索感知的规范化处理，指转换出的内容格式要专门为后续的向量检索和语义匹配优化，而不是追求视觉还原度*
更重要的是,系统明确禁止把不同行的数据合并成"16年或20年"这种模糊表述。论文里管这个叫"no-merge discipline"（禁止合并原则），理由很直接：如果把两种不同的保单配置写成一句"或"字连接的话，用户查询其中一种配置的时候，检索系统会把这句混淆的话当成答案召回，导致AI给出貌似相关实则错误的信息。
这个细节让我想起小时候查字典时最讨厌的一种词条，一个词同时给出好几个互相矛盾的释义，却不告诉你哪个释义对应哪种用法。数据一旦被模糊合并，看起来信息量没少，但实际上每一条都不再能被精确定位和使用了。如果不做这个"不合并"的约束，表面上省了几句话的转录成本，但检索出来的答案会掺杂错误信息，用户十有八九会被误导，这个代价远比多写几句话大得多。
除了表格，转换规则里还提到要彻底忽略图片、Logo、图表这些装饰性图形，不做任何描述。这也是有意为之，因为让AI去"看图说话"很容易产生幻觉式的描述，与其让错误信息混进检索库，不如干脆不提。标题层级也要显式还原成Markdown的#、##、###符号，这是PDF原文里靠字体大小隐含表达、但提取时最容易丢失的关键结构信息。
转换完成后还有一道确定性的后处理，清理掉代码块标记、残留的图片引用，用规则兜底把漏网的表格语法转成逐行叙述。哪怕某一批页面转换失败了，系统也只是在文中插入一个错误标记，不会让整份文档处理中断。
第三步和第四步：把W-RAC那套"贴ID标签"的省钱魔法接回来
一旦文档变成了结构清晰的Markdown，后面的流程就和W-RAC完全一致了。
系统会把Markdown解析成一个个带编号的元素，标题元素叫h1、h2……内容段落叫p1、p2……这一步是纯粹的确定性解析，不需要AI参与。
如果一份文档元素太多，超过了60个元素的处理上限，系统会启动一套递归切分算法，优先在最粗粒度的标题层级切分，切出的每一段都控制在预算内，切不下去再往更细的标题层级下钻，遇到完全没有标题的区域就用固定长度兜底切分。相邻的过小片段还会被合并，避免产生太多零碎的AI调用。
这里有个设计细节很巧妙，叫"父标题上下文"。每一段被切分出来的内容，都会带着它在文档层级里的"祖先标题链"，比如"产品说明 > 资格条件 > 年龄限制"这样一条路径。这样AI在规划怎么分块的时候，哪怕只看到这一小段内容，也能知道它在整份文档里处于什么位置，而不需要把上下文内容重新发给AI，只花几十个token就能传递清楚层级信息。
最后一步是AI规划分块，这也是整个流程里唯一需要AI"动脑子"的地方，而且AI的输出被严格限制成只有ID数组，不允许输出任何原文内容。像`[["h1","h2","p1","p2"], ["h1","h3","p3","p4","p5"]]`这样的格式，AI只需要告诉系统"这几个编号应该分到一组"，具体这几个编号对应的原文是什么，系统会在本地直接拼回去，一个字都不用AI重新生成。
*chunk：检索增强生成系统里，被切分出来、独立存入向量数据库的一个文本片段，是检索的最小单位*
系统还会用程序自动核验，确保每一个内容编号都恰好出现在一个分块里，没被漏掉的内容会被自动归到一个兜底分块里，从而保证零遗漏。
这套设计的精髓在于，AI只被用在它真正不可替代的地方：从图片里读出结构、把表格改写成人话。除此之外的所有环节，包括切分、规划编号、拼接文本，全部是确定性的、可复现的、可审查的程序逻辑。
打个比方，这就像一家出版社在编书。真正需要资深编辑动脑筋的环节，是判断哪几段内容应该合并成一个章节、章节标题怎么起。至于排版、页码编号、目录生成这些机械性工作，完全可以交给排版软件自动完成，没必要每次都请编辑重新誊写一遍全书。如果让编辑每次都手抄一遍全文再重新分段，不仅慢得离谱，抄错字的风险也会直线上升。
实测结果：236份文档、795页，72分钟，零错误
论文团队在一个叫RAG-Multi-Corpus的基准测试集上做了验证，覆盖汽车、学术、云服务、企业科技、银行五个行业，236份PDF文档，共795页。
*RAG-Multi-Corpus：论文团队自建的多格式、多领域检索评测基准，模拟真实企业知识库内容*
转换阶段用Gemma-3 27B模型，整个语料库耗时3758秒（约62.6分钟）完成转换，加上分块规划一共71.7分钟，全程零错误。五个行业的转换速度稳定在每页3.9到5.5秒之间，说明起主导作用的是API调用延迟，而不是文档内容复杂度。团队还专门找了一份503页的金融招股书做压力测试，用27B模型转换耗时21.6分钟，12B模型只要13.4分钟，每页耗时和小文档基本持平,证明这套流程可以线性扩展，不会随文档变长而急剧变慢。
分块规划阶段更快，整个语料库只花了542秒，是转换耗时的14%，平均每份文档2.3秒。5584个元素最终被规划成1748个知识块，平均每块705个字符，零分块错误。
真正的重头戏是检索效果和成本的对比。论文拿三套系统做了正面比较：一套是最传统的PyMuPDF硬提取加固定长度切分，一套是完全用大模型重写全文的agentic chunking，一套就是D-RAC。
| 系统 | Recall@6 | Recall@3 | MRR | NDCG@6 |
| 固定长度切分（传统提取） | 0.717 | 0.666 | 0.602 | 0.764 |
| Agentic chunking | 0.795 | 0.726 | 0.682 | 0.793 |
| **D-RAC** | **0.798** | **0.743** | **0.690** | **0.801** |
*Recall@6：检索系统在返回前6条结果时，能覆盖到多少比例的标准答案支持事实，数值越高代表召回越全*
*MRR：平均倒数排名，衡量正确答案平均排在第几位，数值越高说明正确答案排得越靠前*
D-RAC在所有指标上都追平甚至超过了agentic chunking，而agentic chunking的参考分块是直接从"干净的结构化原始文档"生成的，D-RAC却是从"最难处理的渲染PDF页面图片"这种更恶劣的输入起步，最终结果反而不落下风。
分类型看，时间类查询（Temporal）上D-RAC的Recall@6达到0.85，固定长度切分只有0.73；对比类查询（Comparative）D-RAC是0.79对0.72；分析类查询（Analytical）是0.61对0.56。这些恰好都是最依赖分块边界是否合理、表格是否读得准的查询类型，也印证了D-RAC那套"逐行转叙述、禁止合并"的表格处理策略确实起了作用。布尔类查询（是非题）是唯一agentic chunking还占优势的类别。
真正的杀手锏：成本降了多少
论文测算了chunking阶段的token消耗，这是最能说明问题的一组数字。
| 项目 | Agentic Chunking | D-RAC |
| 输入token | 325,855 | 264,954 |
| 输出token | 270,454 | **11,714** |
**D-RAC把输出token从27万降到了1.17万，降幅达95.7%。**
这个差距为什么这么悬殊？因为agentic chunking要把整篇文档重新写一遍当作输出，而D-RAC的AI只输出一串ID数组，压根不涉及文字生成。
*token：大语言模型计费和处理文本的基本单位，通常几个字符对应一个token，输出token的定价通常远高于输入token*
换算成实际花费，用GPT-4.1的价格跑一遍236份文档的分块任务，agentic chunking要花2.815美元，D-RAC只要0.624美元，降低77.8%。换成Gemini 2.5 Pro，价差更大，从3.112美元降到0.448美元，降低85.6%。
这个成本差距背后藏着一个更深的逻辑：**文档一旦被转换成Markdown并持久化存储下来，以后想调整分块策略，比如改变分块大小目标、按实体重新分组，只需要重新跑一遍规划步骤，几十秒的ID级AI调用就能搞定，完全不需要再碰一次原始PDF。**
而agentic chunking没有这个"一次转换、反复复用"的能力，只要你想换一种分块策略，就得把全文重新生成一遍，每次都是全价支付。这就像装修房子时,如果你把水电线路的走向图纸完整保留下来，以后想调整家具布局只需要看图规划就行；但如果没有留图纸，每次想挪个柜子都得把墙砸开重新排查线路走向。D-RAC相当于把"读懂文档结构"这件最贵的事情只做一次,并且把结果存了下来，后续所有的策略调整都是在这份存档上做轻量级操作。
论文里还做了个推演，如果把这套逻辑放大到100万页的企业级语料库，用GPT-4.1计算,chunking成本能从大约3540美元降到785美元，而且这个省钱效应会在每一次重新索引时反复发生，因为agentic chunking的重新生成成本是不会消失的。
Q&A Q1：D-RAC是什么？ A：D-RAC是Yellow.ai团队提出的企业文档检索增强分块方案，它先把任意文档格式统一转成PDF，再用一次多模态大模型转换成检索优化的Markdown，最后用轻量级AI规划分块边界，全程只需一次AI阅读文档内容。
Q2：D-RAC和之前的W-RAC有什么关系？
A：W-RAC是针对网页HTML的分块方案，依赖HTML本身的清晰结构。D-RAC把这套"ID规划、不重写文本"的思路扩展到PDF等企业文档格式，前面多加了PDF归一化和多模态转换两个步骤，后续流程和W-RAC完全一致。
Q3：D-RAC相比让AI直接重写文档分块，能省多少钱？
A：D-RAC把分块阶段的输出token减少了95.7%，按GPT-4.1定价计算成本降低77.8%，按Gemini 2.5 Pro定价计算降低85.6%，同时分块耗时减少75%，检索效果不降反升。
