3.2.3 按固定长度切块、按语义切块、按结构切块分别适合什么场景？

先给结论：这三种切法没有谁天然更高级，关键是它们各自解决的问题不同。

很多时候，系统切不好，不是因为“没用最先进的策略”，而是因为用错了切块思路。

先把三种切法说清楚

1. 按固定长度切块

最典型的做法是按字符数、token 数或近似长度，把文档均匀切成一批片段。

它的特点是：

• 实现简单
• 成本低
• 对文档结构依赖小

但缺点也很明显：

• 容易切断完整语义
• 标题和正文可能被拆开
• 规则前提和例外条件可能被分到不同块

2. 按语义切块

这类做法的目标，是尽量让每个 chunk 在语义上相对完整。

常见思路包括：

• 按句子组合
• 按段落边界
• 按语义相近的句群

它的优点是：

• 更容易保留完整意思
• 比固定长度切法更像“自然知识单元”

但缺点是：

• 实现复杂度更高
• 边界有时不稳定
• 文档结构太乱时效果未必稳定

3. 按结构切块

这类做法更依赖原始文档本身的结构，比如：

• 标题层级
• 小节边界
• FAQ 问答对
• 表格
• 代码中的函数、类、模块

它的优点是：

• 更贴近原始文档真实组织方式
• 更适合保留章节、标题、问答对和代码边界

但前提是：

• 原始结构要足够清楚
• 解析质量要足够稳定

三种切法各自最适合什么

固定长度切块更适合什么场景

更适合：

• 文档结构不稳定
• 只是先做一个可运行基线
• 需要快速验证整条 RAG 链路
• 数据格式来源非常杂，很难统一恢复结构

它的优势在于：先把系统跑起来。

但它通常更像一个起点，不太像长期最优方案。

语义切块更适合什么场景

更适合：

• 正文质量较高
• 段落和句子边界比较可信
• 用户问题通常更细，依赖局部解释
• 你希望每个 chunk 更像一个独立可读的小知识单元

这类场景里，语义切块往往能比固定长度切法更自然地保留完整意思。

结构切块更适合什么场景

更适合：

• 文档标题层级清楚
• FAQ、手册、制度文档边界明确
• 代码文档、API 文档、技术文档结构稳定
• 你后面希望引用能更贴近章节、问题项或函数边界

如果原始结构本来就强，结构切块通常会比纯长度切法更稳。

三种切法最容易各自失败在哪里

固定长度切块最容易失败在

• 切断语义
• 制造半句话 chunk
• 让模型总是缺前提

语义切块最容易失败在

• 依赖文本质量
• 边界不够稳定
• 面对格式很乱的文档时效果波动大

结构切块最容易失败在

• 原始解析错了
• 标题层级恢复不准
• 表面上有结构，实际结构已经被模板噪声污染

所以真正的问题通常不是“选哪种最先进”，而是“当前数据能不能支撑这种切法”。

一个更贴近实际的选择思路

很多系统更现实的做法，不是三选一，而是：

• 先有一个通用的长度切块基线
• 再对结构明确的文档改成结构切块
• 对正文质量好的内容补语义切块

也就是说，成熟系统常常不是只用一种 splitter，而是按数据类型分流。

一个简单示意

document_types = {
    "faq": "按问答对和标题切块",
    "policy_doc": "优先按章节和小节切块",
    "messy_pdf": "先按固定长度做基线切块",
    "well_written_article": "优先按段落和语义边界切块",
}

这个示意想表达的是：

切块方式本身就应该是数据分流设计的一部分，而不是一个全局统一常量。

怎么判断当前更该换哪种切法

如果你经常看到这些现象，通常更该考虑从固定长度往结构或语义切：

• 规则句经常被切断
• 召回结果看起来像碎片
• 模型回答经常漏掉前提和限制条件

如果你经常看到这些现象，通常说明结构切法还没站稳：

• 标题恢复经常错
• FAQ 边界经常识别错
• 同一小节被拆得反而比长度切法更乱

这时往往不是结构切法不对，而是前面的解析质量还没准备好。

一句话总结

固定长度切块、语义切块、结构切块，各自适合的问题不同。更好的选择标准，不是“哪种听起来更高级”，而是“当前数据的结构质量、问题粒度和后续链路，到底更需要哪一种边界定义”。