当RAG被PDF拖垮：Red Hat工程师给出的破局思路

如果你觉得RAG做不好，是模型不够强，那可能方向就错了。Red Hat 工程师 Cedric Clyburn 用一场演讲抛出一个反直觉观点：真正限制大语言模型落地的，不是生成能力，而是我们如何“结构化”那些混乱的文档。

真正的瓶颈不是模型，而是那堆没人想碰的PDF

Cedric一上来就把问题点破：为什么企业里的大语言模型项目总是卡在“看起来很简单”的地方？不是推理、不是什么新架构，而是文档。PDF、扫描件、混合表格、非结构化文本——这些才是现实世界的数据形态。

他抛出的核心判断非常直接：如果你连文档里的真实结构都没搞清楚，后面所有RAG、Agent、Copilot，都是在沙滩上盖楼。所谓“先进的文档处理”，并不是把PDF转成一大段文本，而是尽可能保留原始语义结构：段落、标题、表格之间的关系。

这也是他反复强调的一点：提取什么不重要，理解什么才重要。

从“暴力切块”到结构优先，中间地带在哪里？

Cedric提到一个很多团队都踩过的坑：要么用传统OCR/解析工具，结果结构丢失严重；要么直接把整篇文档塞进向量库，再靠chunking硬切。

问题在于，chunking本质是一种妥协。它假设“文本越小越好检索”，但完全忽略了文档本身的逻辑边界。标题和正文被拆散，表格被打碎，问答时模型只能“猜”。

他提出的“中间地带”，正是像 Docling 这样的工具：在进入RAG之前，先对文档进行结构化理解。不是简单抽文本，而是明确告诉模型：这是表，这是节，这是上下文关系。换句话说，是先让数据更像数据库，再交给LLM。

Chunkless RAG：不是新名词，而是新思路

在演示部分，Cedric展示了一个听起来很激进的概念：chunkless RAG。不是完全不分块，而是不再以“字符长度”为中心，而是以“文档结构”为核心。

通过 Docling 这类工具，系统可以直接基于结构化后的内容进行检索与问答，而不是在一堆随机切片里碰运气。结果是，回答更稳定、上下文更完整，调参成本也更低。

这背后隐含的观点很重要：RAG 的上限，取决于你对原始数据的尊重程度。数据被破坏得越早，模型就越像在做阅读理解猜谜。

规模与成本，才是决定技术能否活下去的因素

Cedric最后把话题拉回现实：当你只有几十个PDF时，几乎任何方案都能跑；但当数量变成几百、几千，甚至几十万份文档，事情就完全不同了。

结构化处理是否可扩展？成本是否可控？能否作为流水线的一部分长期运行？这些问题，比模型参数量重要得多。

他强调，开源生态里已经有不少可选方案，但关键不在“用哪个”，而在于你是否从一开始就把文档当成“系统性问题”来看，而不是一次性的预处理脚本。

总结

这场分享最大的价值，不是介绍了某个工具，而是帮AI从业者校准了一个认知：RAG失败，往往不是因为模型不聪明，而是我们给它的世界太混乱。

如果你正在做企业级LLM应用，现在就该回头看看自己的数据管道——文档是如何被解析、被切分、被检索的？是否保留了人类写作时的结构意图？

一个值得思考的问题是：在下一轮RAG演进中，真正拉开差距的，会不会不是更大的模型，而是谁先把“非结构化”这件事，做得足够认真？

关键词： 检索增强生成， 大语言模型， RAG， 文档结构化， Docling

事实核查备注： 需要核查：Cedric Clyburn 的职位描述（Red Hat 开源工程师）；Docling 工具的具体功能表述；chunkless RAG 是否为演讲中的原始用语