让大模型只付一次"理解费"：D-RAC 如何把任意企业文档变成检索友好的知识块
做企业 RAG 的都懂一个痛：知识库里什么都有——PDF、Word、PPT、扫描件——而每种格式都像一把锁，把内容锁在多栏版式、页眉页脚和密密麻麻的表格里。用 PyMuPDF 一提，阅读顺序全乱；上 OCR 流水线，表格被碾成碎片；让大模型直接 agentic chunking 吧，钱包先扛不住，输出 token 价格是输入的 4 到 8 倍，模型还得把全文重新生成一遍。
Yellow.ai 的这篇 D-RAC 论文（arXiv 2609.24220）给出了一个我觉得相当务实的答案：多模态大模型只出动一次，把文档转成检索友好的 Markdown；之后的切块全程是 ID 级别的"规划"，文本一个字都不重新生成。 结果很能打——chunking 阶段输出 token 砍掉 95.7%，成本降 77.8% 到 85.6%，时间降 75%，检索指标还反超了 agentic 基线。
核心摘要：这篇论文把自己之前的 W-RAC（网页检索感知切块）框架扩展到任意文档格式。思路一句话：所有格式先归一化成 PDF（因为几乎所有格式都有确定性的 PDF 渲染路径），再用单次多模态 LLM 把页面渲染图转成"检索感知"的 Markdown——表格逐行改写成自包含句子、标题层级显式重建——之后的解析、分节、chunk 规划全部沿用 W-RAC 的确定性机制。在 236 篇文档、795 页的 RAG-Multi-Corpus PDF 子集上，72 分钟完成全语料转换与切块，零错误，产出 1,748 个检索就绪 chunk。我的定位判断：这不是底层突破，而是一次漂亮的工程整合，但整合得很有章法，成本账算得非常清楚，值得做企业 RAG 的人细读。
- 论文链接：https://arxiv.org/abs/2609.24220
- 作者：Uday Allu, Abhivanth Sivaprakash, Pratik Singh, Aman Manocha
- 机构：Yellow.ai AI Research Team
- 发表日期：2026-09-21
- 代码与数据：https://github.com/udayallu/RAG-Multi-Corpus
为什么现有路子都不够用
作者把传统路径的坑列得很清楚，我挑几个最扎心的说。
规则提取（PyMuPDF、pdfminer 那一系）的问题是老生常谈：多栏页面的阅读顺序错乱，页眉页脚混进正文，表格退化成位置模糊的碎片。标题层级只能靠字体大小这种启发式猜，稍微花哨点的版式就翻车。
布局模型和 OCR 流水线（LayoutLM、Docling 这类）理解能力强一些，但输出还是网格表格。问题在于——表格单元格的语义是依赖行列头的，单元格一旦被拆出来塞进 chunk，行列头落在别的 chunk 里，这条数据对稠密检索来说就是死数据。
agentic chunking 呢？让前沿 LLM 直接读提取文本、边修复边分块，质量确实高，但代价是输出 token 最大化：模型不仅要做决策，还得把全文重新生成一遍。更烦的是每次想换个 chunking 策略（调 chunk 大小、换租户策略），都得全额再付一次生成费。
说实话，看到这组对比的时候我的第一反应是：这个成本账其实大家心里都有数，只是很少有人把它量化得这么干净。论文给出的核心洞察也直白：理解是贵的，但只需要理解一次；切块是便宜的，应该可以无限次重做。
D-RAC 流水线：一次理解，永久复用
图1：D-RAC 的四阶段流水线。任意格式文档先归一化为 PDF，渲染成 200 DPI 页面图像后由多模态 LLM 批量转成 Markdown；随后确定性解析成 ID 可寻址单元，递归分节，最后由 LLM 只做 ID 级的 chunk 规划，本地重建为逐字文本块并索引。
整个流水线的设计哲学可以用一句话概括：多模态模型只在 Stage 2 接触文档内容一次，之后所有环节要么完全确定性，要么只操作元素 ID。
Stage 1：PDF 归一化。 这个选择挺聪明的。DOCX、PPTX、XLSX、HTML 甚至扫描件，都有忠实且确定性的 PDF 渲染路径——office 格式用 headless LibreOffice，HTML 用 print-to-PDF。与其给每种格式写一个解析器，不如全归一到 PDF 这个"通用视觉交换格式"上。每页渲染成 200 DPI PNG，任意维度压到 1,568 像素以内以匹配视觉编码器限制。这一步是纯本地操作，每文档 1–7 秒。
Stage 2：多模态 Markdown 转换。 页面按 5 页一批发给多模态 LLM（论文用的是 Gemma-3 27B/12B，走 AWS Bedrock），最多 5 批并行。转换 prompt 里塞了几条针对检索的硬规则，这是全文最值钱的部分：
- 逐字保留所有文本，不总结不跳过；
- 表格转散文：禁用 Markdown 表格语法，每行改写成一条自包含句子，以列头为上下文；
- no-merge 纪律：不同行绝不合并。两行数据 (Policy Term=16, PPT=8) 和 (Policy Term=20, PPT=10) 必须生成两个独立句子，绝不能偷懒写成"16 或 20 年"——后者在检索时会混淆不同的产品配置；
- 图像抑制：logo、图表、装饰图直接省略，不让模型瞎编 caption 污染索引；
- 标题用 Markdown 的 #/##/### 显式输出，重建被 PDF 提取破坏的层级；
- 每页内容前加
<!-- Page N -->注释保留溯源信息。
Stage 3：确定性解析与分节。 Markdown 被解析成 ID 可寻址元素——h1、h2、p1、p2……元素超过规划预算（每次 LLM 调用 60 个元素）就在标题边界递归切分。每个分节还带上祖先标题链作为上下文，代价只有几十个输入 token，但规划器因此知道自己在文档树里的位置。
Stage 4：LLM chunk 规划与重建。 这里是最妙的一步。LLM 看到的只有元素 ID、截断预览和层级元数据，返回的是 ID 列表，比如 [["h1","h2","p1","p2"], ["h1","h3","p3","p4","p5"]]。规划要求每个 chunk 聚合 3–8 个内容块、跨 chunk 复用 header ID 提供上下文、每个内容 ID 恰好覆盖一次——覆盖率程序化验证，漏掉的 ID 自动收进回退 chunk，保证无损。最后本地把 ID 映射回逐字文本，每个 chunk 前缀完整面包屑（如 Plan Overview >> Eligibility >> Age Limits），然后嵌入索引。
等等，你发现没有——这意味着 chunking 阶段 LLM 的输出 token 里根本不含散文，只有 ID 数组。幻觉面被压到零：chunk 文本不可能被静默篡改，因为模型根本没机会生成它。
表格规范化：检索友好的关键一招
图2：表格规范化的具体例子。上方是 PDF 中渲染的原始保险条款表格（Policy Term / Premium Payment Term / Income Period 三列两行），下方是 D-RAC 转换后的输出——每行变成一条自包含的完整句子，列头信息被织进句子内部。
这张图把 D-RAC 的检索感知转换讲透了。原始表格里"16 years"这个单元格本身毫无意义，它的语义全靠行和列的交点。稠密向量检索对这种结构的敌意是出了名的——chunk 边界一旦切错，单元格就和它的列头天各一方。
D-RAC 的做法是把每行重写成"For a Policy Term of 16 years, the Premium Payment Term is 8 years and the Income Period is 25 years"这样的完整句子。每条表格事实变成可独立嵌入、独立检索的语句。作者管合并多行的行为叫"静默的精度杀手"——这个命名我很认同，查"20 年保单"却召回一条同时断言 16 和 20 年的句子，grounding 就废了。
还有一个工程上很实在的好处：转换后的 Markdown 和元素 ID 是持久化工件。以后想调 chunk 大小、加实体感知分组、改租户策略，只需秒级的 ID 级重规划，不用重新转换、不用重新 OCR。昂贵的理解费付一次，便宜的切块费随改随付。
实验：成本、速度、检索质量三线都赢
语料与配置
评测用 RAG-Multi-Corpus 基准的 PDF 子集，覆盖五个虚构企业领域，共 236 篇文档、795 页：
| 组织 | 领域 | PDF 数 | 页数 |
|---|---|---|---|
| Aventro Motors | 汽车 | 50 | 133 |
| Cendara University | 学术教育 | 40 | 221 |
| CloudWay-24 | 云服务 | 37 | 103 |
| Velvera Technologies | 企业技术 | 38 | 123 |
| ZX Bank | 银行金融 | 71 | 215 |
| 总计 | — | 236 | 795 |
另外拿一份 503 页的金融招股说明书做可扩展性压力测试。配置：AWS Bedrock，temperature 0.1，转换每批最多 8,192 输出 token，chunk 规划每次调用 16,384 token。检索性能用 762 条标注查询评测（CloudWay-24 无标注，覆盖其余 4 个组织）。
吞吐：72 分钟吃完整语料
转换阶段（Gemma-3 27B）全语料耗时 3,758 秒，约 62.6 分钟；加上 chunk 规划总共 71.7 分钟，236 篇文档零错误。每页转换成本稳定在 3.9–5.5 秒——这个稳定性本身就说明瓶颈在 API 延迟而不是内容复杂度。503 页的压力测试：27B 转换 21.6 分钟，12B 只要 13.4 分钟，单页成本与小文档一致，线性扩展没问题。
chunk 规划阶段更快：全语料 542 秒，只占转换时间的 14%，平均每文档 2.3 秒。503 页文档拆出 5,060 个元素，95 个并行分节调用 68.7 秒搞定规划。最终产出 1,748 个 chunk，平均 581–846 字符，恰好落在稠密检索器偏好的区间——而且这个大小是自然涌现的，没有硬性限制。
检索质量：从最难的输入出发，反超最占便宜的基线
三个系统同台：Fixed-size（PyMuPDF 提取 + 1,000 字符固定分块 + 200 重叠）、Agentic（基准自带的参考 chunk，来自语料的干净结构化源）、D-RAC（从渲染 PDF 页面出发——最难的输入路径）。
| 系统 | R@6 | R@3 | MRR | NDCG@6 |
|---|---|---|---|---|
| Fixed-size | 0.717 | 0.666 | 0.602 | 0.764 |
| Agentic | 0.795 | 0.726 | 0.682 | 0.793 |
| D-RAC | 0.798 | 0.743 | 0.690 | 0.801 |
D-RAC 在全部 7 项总体指标上匹配或超过 agentic chunking。注意这个对比其实不太"公平"——偏向 agentic 那边：人家的参考 chunk 来自干净源数据，D-RAC 却要从渲染页面重建一切。就这样还能赢，说明"单次多模态转换 + ID 级规划"这条路的质量上限是够的。
分查询类型看更有意思。边界敏感的查询收益最大：Temporal 类 R@6 从 fixed-size 的 0.73 涨到 0.85，Comparative 从 0.72 到 0.79，Analytical 从 0.56 到 0.61。这些正是最容易被粗暴切块切碎的查询类型。不过也要说实话——Boolean 查询上 agentic 仍保持优势（R@6 0.86 vs D-RAC 0.82，MRR 0.68 vs 0.60），Descriptive 的 R@6 也是 agentic 略高。D-RAC 并非全维度碾压。
成本账：省下来的钱会复利
这是我最想单独拎出来讲的部分，因为数字太干净了。
chunking 阶段 token 消耗对比：
| 方法 | 输入 token | 输出 token |
|---|---|---|
| Agentic | 325,855 | 270,454 |
| D-RAC | 264,954 | 11,714 |
输出 token 减少 95.7%。agentic 的成本结构里 77–87% 花在输出 token 上（毕竟输出单价是输入的 4–8 倍），D-RAC 把这一项直接打到几美分。换成美元：
- GPT-4.1 定价下：$2.815 → $0.624，降 77.8%
- Gemini 2.5 Pro 定价下：$3.112 → $0.448，降 85.6%
时间上，agentic 处理同语料要 2,167.5 秒，D-RAC 只要 541.8 秒，降 75%。
再算一笔规模账：100 万页的企业语料全量重建索引，agentic 的 chunking 成本约 $3,540，D-RAC 约 $785。而且注意——这还只是单次重建。企业知识库的 chunking 策略是经常要调的，agentic 每次调都要全额重付生成费，D-RAC 每次只付 ID 级规划的几美分。这个差距会随重建次数复利放大。
我的判断
这篇论文最值钱的地方，是把"理解"和"切块"彻底解耦了，而且解耦的接口设计得很干净：持久化的 Markdown + ID 可寻址元素。一次多模态转换之后，整个下游世界都是确定性的、可检查的、便宜的。这种"昂贵的一次性理解 + 廉价的无限次重组"的分层，我觉得会成为生产级文档摄取系统的标配思路。
也得泼几盆冷水。
没有独立消融实验。no-merge 纪律、图像抑制、父标题上下文这些设计决策，全靠定性论证，没有逐一去掉后的定量数据。表格散文化到底贡献了多少检索增益？不知道。
"格式无关性"这个最大的卖点没被实验验证。评测全部用原生 PDF，Stage 1 的归一化是恒等操作。DOCX/PPTX 经 LibreOffice 转换后的端到端质量？没测。扫描件呢？也没测。论文标题里的 "Universal" 目前还是个承诺而非结论。
基准是虚构组织的 795 页语料，Temporal 查询只有 24 条，统计功效弱；相关性判定靠 60% 内容词重叠的启发式，不是人工标注。这些都让数字的成色打点折扣。
还有个小问题：转换质量完全押在多模态 LLM 身上。批次失败虽然能降级为错误标记，但这条路径下的检索质量损失没被量化。
如果你在做企业 RAG 的文档摄取，我的建议是：流水线架构（PDF 归一化 → 检索感知转换 → ID 级规划）可以直接抄，表格逐行散文化的规则值得立刻用起来——这个技巧不依赖他们的整套系统，单独摘出来就能改善你现有索引的表格检索质量。但端到端接入非 PDF 格式之前，自己补一组 DOCX/扫描件的转换质量测试，别信论文没测过的部分。
觉得有启发的话，欢迎点赞、在看、转发。跟进最新AI前沿，关注我