RAG 系统常常流程完整却效果不佳，答案明明在文档中却无法召回。人们常归咎于模型，但真正的症结往往被忽略——文档切分。本文深入剖析了切分策略如何决定 RAG 的知识理解深度，并提供了可操作的优化思路，帮助从根本上解决这类“玄学”问题。
智能速览
RAG 的效果瓶颈通常不在于模型，而在于文档切分策略。
固定长度切分会破坏文档的语义完整性和结构。
好的切分应保证每个 chunk 都能被人单独读懂。
应根据不同文档类型（如技术文档、FAQ）定制切分方案。
Reranker 无法弥补切分阶段造成的语义信息丢失。
精华内容
想要提升 RAG 效果，与其盲目堆砌模型，不如回归本源，重新审视那个看似基础却至关重要的环节：文档切分。
切分的根本作用
RAG 系统中，模型从未见过完整的原始文档，它接触的永远是被提前切分好的信息碎片。这一事实常常被忽略，却是理解诸多问题的关键。如果切分出的 chunk 本身就无法支撑对问题的理解，那么无论模型多么强大，都无法给出准确答案。因此，切分策略直接决定了 RAG 系统知识库的“颗粒度”和“可理解性”，是后续所有步骤效果的基础。
常见的切分误区
许多项目默认采用固定长度切分，例如每 500 token 一段，这种方法只考虑了模型限制，完全忽略了文档自身的语义结构，极易切断上下文。另一个极端是将 chunk 切得过细，这会使其包含的语义信息严重不足，导致召回大量看似相关却无用的碎片。此外，盲目添加 overlap 虽意图保留上下文，但若使用不当，会在向量库中引入大量冗余，反而干扰检索结果。
有效切分的原则
一个有效的切分策略，核心原则是确保每个 chunk 本身“可以被人单独读懂”。这意味着不仅要语法完整，更要语义完整，能让读者明白其主旨、问题和前提。实现这一点，就必须尊重原文结构，避免“一刀切”。例如，技术文档可按标题层级切分，客服问答则以一问一答为独立单元，流程描述应保证一个完整流程在同一段内，而规范条款则需保留其上下文关联。
实践与验证
在验证切分效果时，可以采用一个简单直接的方法：随机抽取文档，手工进行切分，以此建立对“好 chunk”的直觉。同时，针对答案明确的问题，让系统只返回召回的 chunk 而不生成答案。如果人工阅读这些碎片后仍难以回答，那么问题根源大概率在于切分，而非模型。利用在线工具快速对比不同切分方案的效果，比全量入库更高效。
RAG 的成功并非总在于更先进的模型，而常取决于对基础环节的精细打磨。将文档切分视为一个需要持续优化的核心工程问题，远比追逐参数更有价值。或许，下一个突破点就隐藏在对一个 chunk 的重新定义里。
