RAG 文档有哪些切分策略，如何确定块大小？

核心回答

RAG 文档切分要在“检索能定位”和“片段足以回答”之间取舍。 常见策略有四类：

1. 固定长度切分：按字符数或 Token 数分块，适合快速建立基线。
2. 递归切分：优先按段落、句子等边界切分，超长部分再继续细分。
3. 结构化切分：依据标题、条款、函数或表格等文档结构组织片段。
4. 语义切分：根据相邻内容的语义变化确定边界，同时限制块的最小和最大长度。

确定块大小时，先明确长度单位与 Embedding 输入上限，再看问题需要多大的证据单元。块太小，容易拆开前提和结论；块太大，会混入多个主题，增加检索噪声与生成成本。通常先保留自然边界，超长部分递归细分，再用同一批业务问题比较块大小和重叠量，检查证据召回、答案质量、延迟与成本。

例如运维手册中的适用版本、触发条件和恢复步骤应能一起取回。需要“小块定位、大段阅读”时，可以用父子块，把写入索引的子块与交给模型阅读的父段落分开。

几种策略怎样取舍

• 固定长度切分：按字符数或 Token 数截断，可配滑动窗口重叠。实现简单、便于建立基线，但边界可能落在句子、条件或列表中间。
• 递归切分：按优先级尝试段落、换行、句子等分隔符，遇到超长单元再继续细分。适合结构不完全规范的通用文本；中文要考虑句号、逗号等边界，不能只依赖空格。
• 结构化切分：Markdown 按标题，法规按条款，代码按函数或类。表格应保留表头与数据行的对应关系；超大表格需要分组或拆行时，也要给每块补足列名和必要说明。结构边界仍要受长度预算约束。
• 语义切分：根据相邻句子或段落的语义变化确定边界，适合主题切换明显、结构较弱的文本。它增加了离线计算与维护成本，还需要约束过小块和过大块，是否优于结构化切分要实测。

切分后还要保留来源、章节路径、页码、版本和父块标识。标题中有“Redis 超时处理”，正文却只写“上述配置”时，可以把必要标题加入块内容；仅存入元数据而没有参与编码，不会自动改变该块的向量。

怎样确定块大小和重叠

先明确长度单位，再确定预算。 chunk_size=500 不一定表示 500 Token，例如按 len 计长的分割器统计的是字符。应按目标 Embedding 模型的分词方式检查实际输入，把参与编码的标题、指令和正文一起计入，避免超限报错或被静默截断。生成阶段还要为系统提示、问题、对话历史和输出预留空间，不能让召回片段占满上下文窗口。

再看问题需要多大证据单元。 运维知识库中，查一个配置项可以用较小块；解释故障的触发条件和恢复步骤，就需要连同前提一起保留。可以依据真实段落长度选择几组候选大小，抽查条件句、列表、跨页段落和表格是否被拆坏。

重叠主要用于缓解边界断裂，不必固定为某个比例。重叠过多会增加向量数量，还可能让多个近似重复块占满 Top-K。评测时既看答案依据是否找全，也看去重后保留了多少有效信息。

若小块容易命中、但不足以回答，可以按下图取回父段落：

%%{init: {"themeVariables": {"fontSize": "16px"}, "flowchart": {"nodeSpacing": 16, "rankSpacing": 30, "padding": 10}}}%%
flowchart TB
    Q[用户问题] --> C[检索子块索引]
    C -->|父块标识| P[取回对应父段落]
    P --> D[去重并检查上下文预算]
    D --> A[生成有依据的答案]

父子块可以同时保留定位精度与上下文，但父段落仍可能过长，也有额外存储与读取成本。

最后做受控评测。 固定语料、问题集、Embedding、检索参数和生成配置，比较切分方案。问题集应标注所需证据，并覆盖事实问答、流程、多段条件和无答案问题。检索侧看证据覆盖与相关性，生成侧看正确性、引用和证据支持，同时记录上下文 Token、索引规模与延迟。切分方案变化后，重新生成受影响块的向量，并记录切分和索引版本，才能回放差异。

追问

增大 Top-K 能代替合理切分吗？

不一定。它可能补回相邻信息，也会带来更多重复和噪声。应先检查缺的是哪条证据，再选择邻块扩展、父子块或调整边界，而不是把更多候选直接拼进 Prompt。

Embedding 支持长输入，还需要切分吗？

通常仍值得切分。输入长度上限说明模型能接收多长文本，并不保证整篇文档形成的单个向量能精确定位每个知识点；是否使用整篇、章节或子块，仍需按查询粒度评测。

对应教程

参考资料