RAG - 文档怎么切才能有最好的效果

RAG现在已然是企业知识库的首选方案，但很多公司费了九牛二虎之力搭建好一套RAG之后，实际用起来却发现经常十问九不中。最后排查下来的原因，多半都不是模型不行，而是文档被切坏了。

RAG 这条链路里，加载、切分、向量化、检索、增强生成，每一步都可能出错。其中最容易被忽视、却往往决定上限的环节，就是切分。它直接影响了检索时能不能把正确答案所在的那段文字，干净、完整地送到大模型手里。

不过，切分策略远不止"固定长度切一刀"那么简单。下面就一个一个说清楚。

很多人入门时做的第一件事，就是给切分器设一个固定长度，比如 500 字，然后让程序按这个长度把文档切成片段。这个做法看起来省事，但它常常把语义单元直接腰斩。

比如一段讲"Transformer 注意力机制的三个变体"的文字，第一部分在某个 chunk 的末尾，第二部分在下一个 chunk 的开头。检索时，向量相似度只能匹配到其中一个 chunk，另一个 chunk 里关键的信息就彻底丢了。最终大模型拿到的上下文残缺不全，回答自然驴唇不对马嘴。

这里面更深层的问题是：RAG 的检索模型是在连续的向量空间里工作，它理解的"相似"是语义上的，而不是位置上的。你切出来的每一个片段，都独立成为一个检索单元。如果这个单元本身语义就不完整，向量表达也会失真，排序时很容易被挤到后面去。

所以切分这个环节，本质是在决定"哪些文字会作为一个整体被检索和喂给模型"。它不但影响检索召回率，还直接影响最终答案的准确与连贯。把切分做好，往往比换一个更强的嵌入模型收益更大。

在讨论最新进展之前，有必要先把业界已经摸索出来的七种主流方案梳理清楚。每一种都有自己的适用场景和软肋，了解它们，才能在做技术选型时心中有数。

2.1 固定长度滑窗切分

这是最朴素的方法。设定一个固定大小，比如 512 个 token，然后从头按这个窗口往后滑，两个窗口之间可以稍有重叠，避免边界处语义割裂。

优点很简单：实现成本几乎为零，处理速度快，适合对实时性要求很高的初步实验。缺点也摆在明面上：不管句子、段落、标题、表格，统统按长度一刀切，语义完整性完全靠运气。

适用场景更多是临时验证原型的时候，或者处理那种本身就没结构、纯流式的短文本，比如聊天记录、日志。

2.2 句子窗口检索

既然固定长度会切断句子，那很自然的改进就是：以句子为单位切分，然后取若干句子作为一个窗口，窗口之间同样可以有重叠。

具体实现通常是先用分句工具把文档拆成句子列表，再按固定句数滑窗。一个窗口里至少能保证每个句子是完整的，不容易出现半个句子的悲剧。

比纯粹固定长度好一截，但它仍然不知道文档的结构层次，不知道哪里是标题、哪里是段落。遇到表格或代码块，可能也会被拆得乱七八糟。比较适合处理结构简单的长文本，如新闻稿、博客文章这类连续叙述性内容。

2.3 文档结构感知切分

这一步开始真正考虑文档本身的层级关系。很多文档本身就是有结构的：一级标题、二级标题、段落、列表、代码块。结构感知切分就是利用这些已有信息，在标题边界等自然断层处切分，并且把标题信息保留下来，作为这个片段的一部分。

举个例子，一段关于"梯度下降优化器"的文字，会在切分时带上祖先标题："机器学习 / 模型训练 / 优化器"。这样即使把它从原文档里抽出来，读者（也就是大模型）也能知道这段内容属于哪个大主题。

优点非常明显：检索出来的片段自带上下文坐标，不容易跑偏。而且切分边界天然合理，不会切断高层次的语义块。缺点是需要文档本身有良好结构，如果是杂乱的 PDF 转换后的文本，这套做法可能根本无从下手。

2.4 语义切分

前面几种方法都依赖人为设定的规则或现成结构，而语义切分则让模型去判断"这里该不该切"。

原理是用嵌入模型把整篇文档的每一小段都编码成向量，然后计算相邻片段之间的语义相似度。当相似度突然大幅下降时，就认为语义发生变化，是一个合理的切分点。这一步本质上是在找出文档中主题切换的地方。

相比固定长度，语义切分能更好地保持每个片段内部的话题一致性，检索时噪声会明显减少。但它依然有局限：切分颗粒度受模型对"相似度陡降"的敏感度影响，而且对于没有明显主题过渡的叙述性段落，效果会打了折扣。

2.5 层级 / 父子切分

这一策略把切分和检索拆成两步来处理。简单说就是：先用较大的粒度做初步检索，再用更细的粒度去喂给大模型。

大块的"父块"包含较完整的上下文，比如一整节，用来在检索阶段做向量匹配，它的语义描述更全面，不容易漏召。小块的"子块"则是父块内部进一步切细的段落或句子。检索时匹配到父块后，实际送给大模型的是其对应的子块，或者直接送整个父块但把检索重点标出来。

这种两阶段的设计让检索和生成分别使用了最合适的粒度，能同时兼顾召回率和最终上下文的质量。当然代价是存储和索引的复杂度上来了，毕竟要多维护一层父子关系。

2.6 智能体切分

前面这些策略，要么靠规则，要么靠模型输出一个断点位置。能不能把切分这件事交给大模型自己来做呢？这就是智能体切分，也叫 LLM 驱动切分。

它可以输出两种形态的结果。

第一种是输出自然断点位置。你把文档给 LLM，让它分析内容后直接告诉你："在第 3 段末尾切一刀，在第 5 段末尾再切一刀。"LLM 会结合语义、结构、话题完整性，给出最优的拆解方案，相当于一个高级版的语义切分。

第二种是抽取独立事实命题。也就是把一大段文字里隐含的每一条独立知识都抽出来，变成一句句自包含的陈述句。比如 "Transformer 由 Vaswani 等人在 2017 年提出""自注意力机制计算的是序列内所有位置的加权和"，每一条都不依赖上下文就可以独立理解。这些命题就是最小粒度的检索单元，检索精度极高。

智能体切分的上限非常高，但慢也是真的慢，而且每一次调用都会有额外消耗。目前更适合对质量要求极高、可以接受离线处理的场景，直接拿来做实时索引还有一定距离。

2.7 多模态与表格保留切分

很多企业文档里，表格是信息密度最高的部分。传统的文本切分往往把表格转成行不成行、列不成列的纯文本，检索时几乎没有招架之力。

多模态表格保留切分不会粗暴地把表格拍成文字。它的核心机制是两阶段处理。

索引阶段，会用 LLM 为表格生成一个精炼的摘要，比如"该表格列出了近年各模型的参数规模与训练成本"，把这个摘要进行向量化，参与检索匹配。这样一来，语义搜索可以轻松定位到这张表。

但生成阶段喂给大模型的不是摘要，而是原始的 Markdown 或 HTML 格式的表格本身。这时候模型读到的是完整的行列结构、数字、表头，意味着它可以精确回答"哪个模型参数最大""训练成本是多少"之类的问题。

这种做法把结构化数据的检索匹配精度和最终答案的准确度同时保住了，非常适合财报、论文、技术手册这类文档。

这周刚发布的 PixelRAG，直接把前面所有讨论的"文档切分"这个大前提给绕开了。

UC Berkeley、Princeton、EPFL 和 Databricks 的研究团队提出，只要把网页渲染成截图，用视觉语言模型直接"看"图，就不再需要任何 HTML 转文本、解析、清洗、切分这些步骤。

在回答为什么会这样时，他们给出了一个很清晰的失败归因分析。基于 Wikipedia 的 SimpleQA 基准测试，RAG 回答出错大致有三个来源：

第一是 Parser loss，占比 36.6%。这是 HTML 转纯文本的过程中，结构化信息被破坏得如此彻底，以至于索引里根本没有包含答案的 chunk。

第二是 Rank loss，占比 55.2%。答案其实还在文档里，但因为维基百科页面里那些关键词密集的 infobox 信息框向量匹配得分极高，把真正包含答案的段落挤到了排名 20 以外，检索阶段就名落孙山。

第三是 Reader loss，占比 8.2%。正确答案确实被检索出来喂给模型了，但由于结构丢失、上下文扭曲，模型把信息归属或细节给理解错了。

PixelRAG 的解决方法非常直接：用 Playwright 把页面渲染成固定宽度截图，切成小图块，向量化存储，检索时把匹配到的图块直接送给视觉语言模型。整个过程不需要理解 HTML、不需要设计切分规则。

在 SimpleQA 上，它的准确率达到 78.8%，而最强的文本方法只有 71.6%；表格类查询上，则是 48.8% 对 42.5%，虽然领先，但差距其实比纯文本任务要小一些。论文给出的总体结论是，PixelRAG 相对文本 RAG 最多能提升 18.1% 的准确率。

成本方面也很吸引人：一次搜索用到的 prompt token 从千万级骤降到 360 万，而文本检索用了 3750 万，成本能降低 2 到 4 倍。这种方法目前要依赖 Qwen3-VL-4B 级别及以上的视觉语言模型才能发挥优势，小模型反而会落后文本检索超过 12.5 个百分点。另外，像素级别固定高度切片会不会把表格或段落直接切碎，也是一个待解决的开放问题。

回头看看，RAG 切分这件事，从最初的固定 500 字一刀切，到一步步发展到语义感知、父子分离、LLM 自主决策，再到如今跳出文本桎梏直接"看"页面，这条路走得比想象中要远。

但所有这些进步，最终都指向一个很朴素的原则：你要喂给模型的那一段上下文，必须是语义完整、结构清晰、边界自然的。不管用哪种策略，只要这个原则守住了，RAG 的表现就不会太差。

📌 点击「阅读原文」查看最近24小时更多AI热点新闻、社媒焦点、大V深度分享

👆 关注公众号，获取定期推送的最新最重磅AI信息