RAG系统文本切块优化：解决答案不完整与检索失效的工程实践

1. 从一次失败的RAG问答说起：为什么答案总是“半截话”？

最近在帮一个团队调试他们的RAG（检索增强生成）系统，遇到了一个非常典型又令人头疼的问题。用户问：“公司最新的差旅报销政策中，关于国际航班的经济舱报销标准是什么？” 系统返回的答案开头看起来挺对：“根据公司2024年发布的《差旅费用管理办法》第三章第十二条规定，国际航班经济舱报销标准为……” 但话到这里就戛然而止，最关键的具体金额、舱位等级限制、是否需要提前审批这些信息全都没有。用户当然不满意，这答案说了等于没说，就像听人讲故事讲到最精彩处突然“且听下回分解”，让人抓狂。

我们检查了召回的相关文档片段，发现问题根源不在大模型（LLM），也不在向量检索的精度，而恰恰出在文档处理的第一步—— 文本切块（Chunking） 。系统召回的三个关键片段里，第一个片段是政策文件的标题和总则，第二个片段包含了问题中的“第三章第十二条”开头部分，但关于报销金额的具体条款，恰好被切分到了第三个片段，而第三个片段因为与查询的语义相似度稍低，在重排序环节被排到了后面，最终未能进入生成上下文。于是，大模型拿到的就是一段“残缺”的上下文，它很“诚实”地基于已有的不完整信息生成了答案，结果就是话说了一半。

这绝不是个例。在RAG项目实践中，“切块”这个看似基础、甚至常被轻视的预处理环节，往往是导致检索翻车、答案质量低下的罪魁祸首。很多人把精力都花在调优嵌入模型、测试不同向量数据库、或者设计复杂的重排序策略上，却忽略了如果源头——文本块——本身是“破碎”的、不完整的，那么后续所有精密的检索和生成都成了“垃圾进，垃圾出”。今天，我们就来深挖一下这个“沉默的杀手”，聊聊为什么切块会让我们的话只说“半截”，以及如何系统地解决它。

2. 文本切块：不只是“切豆腐”，更是信息单元的守护

文本切块，顾名思义，就是把长文档（如PDF、Word、网页文章）切割成较小片段的过程，以便后续进行向量化嵌入和检索。听起来很简单，对吧？但这里的“简单”恰恰是最大的陷阱。最常见的两种切块策略是 固定长度重叠切分 和 按分隔符切分 ，而问题往往就隐藏在这两种策略的粗暴应用之中。

2.1 固定长度切分的“断句之殇”

固定长度切分（如每个块512个token，重叠100个token）因其实现简单、易于批量处理而大受欢迎。LangChain、LlamaIndex等框架都提供了开箱即用的工具。但它的致命伤在于 无视语义和语法边界 。

想象一下，你正在读一本小说，每页只给你看固定的10行，并且每两页之间重复3行。如果这10行刚好在“凶手是……”这句话中间截断，你永远也猜不到凶手是谁。在技术文档、法律合同、政策文件中，这种情况同样可怕。

一个来自专利文档的真实案例： 我们处理一份关于“一种石墨烯复合材料制备方法”的专利说明书。固定长度切分后，一个文本块以这句话结尾：“……其中，所述氧化石墨烯的浓度为5mg/mL至”，下一个块的开头是“20mg/mL，超声处理时间为30-60分钟。”。如果用户查询“氧化石墨烯的浓度范围”，向量检索模型可能会分别计算与这两个片段的相似度。第一个片段“浓度为5mg/mL至”虽然不完整，但包含了关键词“浓度”和数字“5mg/mL”，其向量表示可能与查询高度相关而被召回。而第二个片段“20mg/mL”虽然完成了范围描述，但单独看“20mg/mL”这个短语，与“浓度范围”这个查询的语义关联可能较弱，在检索时排名靠后甚至被过滤掉。于是，大模型得到的上下文只有“浓度为5mg/mL至”，它无法凭空编造“20mg/mL”，生成的答案自然是不完整的。

注意 ：这里重叠（Overlap）机制的设计本意是缓解这个问题，但如果重叠部分太小（比如只重叠几十个词），它仍然无法保证一个完整的语义单元被包含在同一个块中。重叠部分更像是一个“缓冲区”，而非“完整性保证”。

2.2 按分隔符切分的“结构依赖”

另一种常见方法是按自然分隔符切分，比如换行符（ \n\n ）、句号（ . ）、标题标记（ ## ）等。这比固定长度更符合人类阅读习惯，但它 强依赖于文档本身具有清晰、一致的结构格式 。

格式不一致的灾难 ：许多从网页爬取或扫描OCR得到的文档，其段落分隔可能用单个换行符（ \n ）、多个空格或HTML标签混合表示。一个简单的按 \n\n 切分，可能会把原本是一段的长内容错误地保持在一起，或者把连续的短句错误地切开。

列表和表格的克星 ：这是重灾区。一个产品参数表格，如果按行切分，那么“型号：A001， 电压：220V， 电流：10A”可能会被切成三个毫无意义的块。用户问“A001型号的电流是多少？”，检索系统几乎不可能从“电流：10A”这个孤立的片段中理解“A001”这个上下文。

语义分隔符的缺失 ：有些逻辑段落之间并没有明确的分隔符。比如技术文档中连续的操作步骤，或者法律条文中的但书条款（“但是……除外”）。按句号切分会把“但是”之后的内容单独成块，完全扭曲了原意。

实操心得： 永远不要假设你的文档是“干净”的。在决定使用分隔符策略前，必须对文档样本进行人工审查，了解其真实结构。一种混合策略是：先尝试用分隔符（如标题、章节）进行粗切，然后在每个粗块内部，对于过长的部分再采用固定长度+重叠的方式进行细切。这需要在完整性和检索效率之间取得平衡。

2.3 超越基础切分：语义切分的理想与现实

既然固定长度和分隔符都有缺陷，一个很自然的想法是： 能不能让机器像人一样，根据语义完整性来切分？ 这就是语义切分（Semantic Chunking）的概念。它通常利用句子嵌入模型，计算句子或小段落之间的相似度，在语义发生较大转变的地方进行切割。

理想很丰满，现实却很骨感。纯粹的语义切分面临巨大挑战：

计算开销大 ：需要先对文档进行分句，然后为每个句子计算嵌入，再通过聚类或相似度计算来寻找边界，比规则切分慢几个数量级。

阈值难以确定 ：“语义变化多大才算需要切分？” 这个阈值因文档类型、领域而异，需要大量调优。

长上下文连贯性问题 ：有些文档部分（如论证过程、故事叙述）本身就是由多个语义上渐进变化的句子组成的，强行在变化点切分，反而破坏了逻辑流。

因此，在实践中， 语义切分通常不是替代方案，而是增强方案 。一个可行的工程化路径是“递归切分”：先按较大的分隔符（如章节）切分，得到较大的“父块”；然后利用轻量级的语义判断（如，基于 MiniLM 等小模型计算相邻段落嵌入的余弦相似度），如果相似度低于某个阈值，则在此处进行二次切分，形成更小的“子块”。这样既兼顾了效率，又在一定程度上尊重了语义边界。

3. “半截话”如何拖垮整个RAG管道？

一个不合适的文本块，就像供应链中一个有缺陷的零件，它的影响会沿着RAG管道逐级放大，最终导致终端产品（生成的答案）失败。我们来拆解一下这个连锁反应。

3.1 对向量检索（召回）的直接影响

向量检索的核心是计算查询（Query）的嵌入向量与文档块（Chunk）嵌入向量之间的相似度（如余弦相似度）。当文本块不完整时：

信息密度稀释 ：一个包含“问题开头+答案前半部分”的块，其向量表示是这段“半截话”所有词汇信息的混合。当用户查询指向完整的答案时，这个“稀释”了的向量可能无法在向量空间中占据一个与查询高度相关的位置。

关键信息丢失 ：答案的核心部分（如具体的数字、关键条件）如果被切到另一个块，那么即使用户查询非常精准，检索系统也可能因为无法从第一个块中找到足够的信号而错过它。这就是我们开篇案例的情况。

增加噪声干扰 ：不完整的块可能包含一些与核心语义无关的“碎片化”词汇，这些词汇的嵌入噪声会干扰向量表示，降低检索精度。

3.2 对关键词检索（如BM25）的协同伤害

在先进的RAG架构中，通常会采用 多路召回 策略，即同时使用向量检索和关键词检索（如BM25）。BM25基于词频统计，对“答案后半部分”所在的块，如果它包含了查询中未出现的独特关键词（如“20mg/mL”），它仍然有可能被BM25召回，因为BM25看重的是词项本身。这看起来是个补救措施，对吗？

但问题在于 融合与重排序 。假设向量召回了一个相关性分数为0.8的“半截话”块A，BM25召回了一个相关性分数为0.7的“后半截”块B。在融合阶段（如加权求和、RRF），块A的排名可能仍然高于块B。即使通过复杂的重排序模型（如 Cohere Reranker , BGE Reranker ），这些模型虽然能更好地理解上下文关联，但如果输入给重排序模型的候选文档集里，块A和块B是作为两个独立的、语义不连贯的文本片段输入的，重排序模型也很难推断出“B是A的延续”这一关系，从而可能无法将B的排名提升到足够靠前的位置。最终，进入大模型上下文窗口的，可能还是那几个不完整的块。

3.3 对大模型（LLM）生成的致命一击

这是最后一环，也是最直观的一环。大模型再强大，也无法进行“无中生有”的创造（在要求事实准确性的RAG场景下）。它的工作模式是根据给定的上下文（Context）和指令（Prompt），生成最可能的下文。

上下文矛盾与混淆 ：如果给大模型的多个块之间信息矛盾（例如，一个块说流程是A->B->C，另一个被切碎的块只显示了B->C，缺少A），大模型可能会产生混淆，生成逻辑错误的答案。

“最可能”不等于“正确” ：当上下文是“浓度为5mg/mL至”，大模型基于其训练数据，可能会补全一个它认为“最可能”的范围，比如“100mg/mL”。这完全错误，但却符合语言模型补全句子的行为模式。

指令遵循的局限性 ：即使你在Prompt中强调“严格基于上下文回答”，当上下文本身是残缺的，大模型最好的情况就是像我们开篇的例子那样，复述已有的不完整信息然后停止。它无法超越上下文。

一个更深层的教训是 ：我们常常责怪大模型“胡言乱语”（幻觉），但在RAG系统中，有相当一部分幻觉其实是由上游不完整、低质量的检索上下文所“诱导”出来的。修复切块问题，是减少RAG幻觉最有效的手段之一。

4. 工程化解决方案：从“切割”到“构建”信息单元

认识到问题后，我们该如何构建一个健壮的文本切块流程？这不再是一个简单的“切割”动作，而是一个需要根据文档类型、业务场景精心设计的“信息单元构建”过程。

4.1 策略选择：没有银弹，只有组合拳

首先，放弃寻找一种“万能”切分方法的幻想。应该根据文档类型建立不同的处理管道（Pipeline）。

文档类型

推荐切分策略

理由与注意事项

技术手册/API文档

按标题层级递归切分

结构清晰，标题（H1, H2, H3）是天然的信息单元边界。保留标题作为块元数据，有助于检索和生成。

法律合同/政策文件

按条款/条目切分

以“第X条”、“第X款”、“1.”、“(a)”等作为分隔符。确保每个完整的条款在一个块内，这是法律语义完整性的最低要求。

学术论文/长篇文章

混合策略 ：先按章节/摘要/引言/结论切分，章节内再按固定长度（较大）切分，并设置较大重叠。

兼顾宏观结构（章节）和微观连续性（段落）。重叠部分要足够大，以确保关键论证过程不被切断。

对话记录/会议纪要

按说话者或话题转折切分

使用“发言人：”标识或时间戳作为分隔。对于长发言，可结合语义相似度进行二次切分。

结构化数据（表格）

整表或按行组切分，切忌按单单元格切分

将整个表格或一个逻辑行组（如一个产品的所有参数）作为一个块。可以同时生成表格的文本描述（如“下表展示了产品型号与参数的对应关系”）作为块的补充文本。

4.2 工具与实现：LangChain和LlamaIndex的进阶用法

以常用的 LangChain 为例，不要只使用简单的 CharacterTextSplitter 。它的 RecursiveCharacterTextSplitter 是一个更好的起点，因为它允许你定义一个分隔符优先级列表（例如 ["\n\n", "\n", "。", "；", "，", " ", ""] ），它会尝试按优先级递归切分，直到块大小符合要求。这比单一分隔符更健壮。

但更重要的是 自定义分割函数 。对于特定格式的文档，你需要编写自己的切分逻辑。

from langchain.text_splitter import RecursiveCharacterTextSplitter, TextSplitter

from typing import List

import re

class PatentClaimSplitter(TextSplitter):

"""针对专利权利要求书的专用切分器"""

def split_text(self, text: str) -> List[str]:

# 1. 首先，按独立权利要求切分（通常以“1.”，“2.”开头，后跟一个完整句子）

claim_pattern = r'(\d+\.\s[^。]+?。)' # 简化示例，匹配“数字. 内容。”

claims = re.findall(claim_pattern, text)

chunks = []

for claim in claims:

# 2. 如果单个权利要求太长，再按从属关系分句（“根据权利要求1所述...”）

if len(claim) > self._chunk_size:

# 这里可以进一步按“；”或“其中”等切分，并确保重叠

sub_sentences = re.split(r'[；]', claim)

# 处理子句，确保大小和重叠...

processed_sub_chunks = self._merge_sentences_by_size(sub_sentences)

chunks.extend(processed_sub_chunks)

else:

chunks.append(claim)

return chunks

def _merge_sentences_by_size(self, sentences: List[str]) -> List[str]:

# 一个辅助函数，将句子列表按chunk_size和chunk_overlap合并成块

# ... 具体实现略 ...

pass

# 使用示例

doc_text = "1. 一种装置，包括部件A、部件B。2. 根据权利要求1所述的装置，其特征在于，所述部件A由材料X制成。"

splitter = PatentClaimSplitter(chunk_size=200, chunk_overlap=50)

chunks = splitter.split_text(doc_text)

print(chunks)

# 输出可能：['1. 一种装置，包括部件A、部件B。', '2. 根据权利要求1所述的装置，其特征在于，所述部件A由材料X制成。']

对于 LlamaIndex ，它提供了更高级的 Node 概念，并内置了 SentenceSplitter 、 TokenTextSplitter 以及基于语义的 SemanticSplitterNodeParser 。在构建索引时，选择合适的 NodeParser 至关重要。

4.3 元数据与关联：让碎片重新链接

即使切分了，我们也要想办法在检索时还原关联。这就是 元数据（Metadata） 和 父子索引（Parent-Child Index） 的价值。

丰富元数据 ：为每个文本块附加丰富的元数据，例如：

source : 源文件名。

page_num : 在PDF中的页码。

section_title : 所属章节标题。

chunk_seq : 块在原文中的顺序号。

parent_id : 指向更大语义单元（如整个章节）的ID。

父子索引策略 ：这是应对“半截话”的高级技巧。你可以创建两种索引：

子节点索引 ：对细粒度的文本块（如按句子或小段）进行向量化索引。这保证了检索的召回率。

父节点索引 ：对更大粒度的文本单元（如完整段落、章节）建立索引（可以是向量索引，也可以是关键词索引）。 在检索时，先通过子节点索引找到最相关的细粒度片段。然后，通过 parent_id 找到其所属的父节点。最后，将 父节点的完整内容 （或者父节点加上其相邻的子节点）作为上下文送给大模型。这样，即使检索到的子节点是“半截话”，我们也能通过父节点找回完整的语境。

实操心得： 元数据的填充尽可能自动化。可以利用文档解析工具（如 Unstructured , PDFPlumber ）提取标题、页码等信息。父子关系的建立通常需要在切分逻辑中显式定义。

4.4 后处理与验证：不可或缺的质量关卡

切分流程的最后，必须有一个验证环节。

人工抽查 ：定期对不同类型文档的切分结果进行人工审查，检查块边界的合理性。重点关注列表、表格、代码段和长句的切分情况。

自动化启发式检查 ：

括号/引号不匹配 ：检查块的首尾是否有未闭合的括号( () , [] , {} )或引号。这是一个强烈的“半截话”信号。

句子不完整 ：检查块是否以逗号、连接词（“而且”、“但是”）等开头，或者以冠词、介词等结尾。

关键实体断裂 ：使用NER工具检查人名、机构名、产品型号是否被切分到两个块中。

检索模拟测试 ：构造一批典型查询，运行检索，查看返回的文本块是否完整地回答了查询。这是最直接的端到端验证。

5. 从“切块”到“知识构建”：面向检索的预处理思维

最终，我们要提升一个认知：RAG中的文本预处理，目标不是“把文档切小”，而是“为检索构建合适大小的知识单元”。这要求我们具备面向检索的思维。

以终为始，从查询出发 ：思考你的用户最常问什么样的问题？是事实型（某个参数是多少？）、是流程型（如何操作某一步？）、还是概念型（XX是什么？）。针对事实型查询，需要确保一个事实（及其直接上下文）在一个块内；针对流程型，需要确保一个完整的步骤序列在一个块内。

块大小不是固定的 ： chunk_size=512 不是金科玉律。对于密集的表格、代码，块可以更小；对于连贯的论述文、故事，块可以更大（比如1024甚至2048）。关键在于保持一个“语义自洽性”。

重叠不是万能胶 ：重叠是为了防止信息在边界丢失，但它会增加存储和计算成本，且不能解决所有问题。对于语义跳跃大的地方，重叠再多也无济于事。重叠量的设置需要实验，通常建议在块大小的10%-20%之间。

接受不完美，建立兜底机制 ：即使设计再精良，面对海量多样化的文档，切分错误仍会发生。因此，RAG系统需要一些兜底策略：

在Prompt中要求模型“承认无知” ：当上下文明显不完整时，指示模型回答“根据提供的信息，无法确定……”

设计重排序策略时考虑块间关联 ：可以尝试将相邻的块在重排序前进行简单拼接，作为一个新的候选送入重排模型，看看是否能提升排名。

实施多轮检索（Query Rewriting/HyDE） ：当首次检索结果不理想时，利用大模型对原查询进行改写或生成假设性答案（HyDE），用新的查询向量进行二次检索，有时能召回不同的、更完整的块。

在我经历的这个差旅政策案例中，我们最终的解决方案是：首先使用基于正则表达式匹配“第X章”、“第X条”的切分器，确保每个条款独立成块；然后，对于条款内容过长的，再按句号切分，但设置一个较大的重叠（150个token），并强制要求如果切分点出现在“其中”、“但是”、“包括以下情形”等关键词之后，则必须将切分点前移，确保这些关键引导词之后的列举内容完整地保留在同一个块中。调整后，同样的问题，系统召回了完整的政策条款，生成的答案包含了全部关键信息。

文本切块，这个RAG流水线的“第一步”，恰恰是决定系统上限的“关键一步”。它不需要多么高深的算法，但需要极大的耐心、对业务文档的深刻理解以及严谨的工程实践。别再让你的RAG系统因为“半截话”而翻车了，从重新审视和设计你的切块策略开始吧。