文本分块策略对比：从固定窗口到语义分块

可视化演示

对比展示RAG四种分块策略：固定窗口（等长切分）、滑动窗口（重叠区域）、递归字符（分隔符优先级）、语义分块（Embedding相似度跳变检测）。

分块的初心——为什么不能把整本书喂给 AI

假如你要在家里办一场 20 人的聚会，冰箱里躺着一整只羊。你会怎么做？老练的主厨不会把整只羊塞进烤箱——烤不熟，也分不均。他会先拆解：羊排拿来烤，腿肉拿来炖，剩下的剁成肉馅做丸子。每道菜用到的那部分，恰好是它该有的分量。这个“拆解备菜”的动作，就是今天的主角——文本分块。

大语言模型虽然博学，但它的“工作记忆”（上下文窗口）有字数上限，不可能一次读完你上传的几百页 PDF。RAG（检索增强生成）的思路是：先把文档切成许多小块存入向量数据库，用户提问时，系统只检索最相关的几块拼给模型看。分块的好坏，直接决定“检索”这一步是百发百中还是大海捞针。

为什么不能随便切？第二个动机是检索粒度：块太粗，一块里混了五六个话题，检索时“相关”和“跑题”的内容粘在一起，稀释了相关性；块太细，一个完整观点被劈成碎片，检索永远只能捞到半句话。第三个动机是成本：大模型按 token 计费，块越大，每次问答塞进去的 token 越多，账单越贵。于是有了一个最基本的公式——文档总长 L 除以块大小 S，得到块数 N。

备菜的核心不是“切得整齐”，而是“切得合适”。理解了分块的初心，接下来我们看看市面上四种主流“刀法”，以及它们各自的脾气和适用场景。

固定窗口分块——用尺子量着切

有些食堂大厨切豆腐，先拿尺子比好，一刀一刀，每块整整齐齐 5 厘米。固定窗口分块就是这个思路：不管文本内容是什么，一律按固定长度下刀。文档从左到右，数够 S 个字符就切一刀，然后接着数，再切一刀，像一台没有感情的切菜机。

技术上它是最朴素的实现：设块大小为 S，第 i 块就是文本区间 [i·S, (i+1)·S)。优点是极简单——一个循环就能写完；速度快，不用理解文本；结果可预测，块数固定，成本好估算。很多团队把它当作 RAG 工程的基线（Baseline），先跑通全链路再说。

最大缺点是切断语义。一句话可能从中间被劈开，前半句在上一块、后半句在下一块；检索时只找到后半句，模型读到的是一个没头没尾的残句。这就像一刀切在了豆腐花纹的正中间——花纹断了，卖相和口感都打了折扣。

适用场景：日志、固定格式的流水记录，或者对检索质量要求不高、只想快速验证的 Demo。它简单可靠，但别指望它“懂”文本。用尺子切豆腐方便省事，但你没法保证花纹完整——碰到花纹，只能叹气。

滑动窗口分块——刀锋带着重叠切

老练的肉贩切五花肉时，不会每次把刀完全挪开再下刀，而是让刀锋与上一刀保持一点重叠——确保肉皮上的纹理不会被接缝切断。滑动窗口分块的灵感正来源于此：固定块大小 S，但每刀只向前推进 stride 个字符，让相邻两块共享一段重叠区 O。

这样做的收益很明显：一个恰好被“骑”在边界上的知识点，会在下一块中以完整形态再出现一次，检索时无论命中哪一块，都能拿到完整信息。代价同样肉眼可见——冗余。同样的内容被存了两遍，向量库体积变大，Embedding 和存储成本上升；检索时还可能同时返回两块“看起来几乎一样”的结果。overlap 设得越大，冗余越严重。

适用场景：对话流、新闻正文等上下文高度连贯、没有自然章节边界的文本。合理的 overlap 一般取块大小的 10%~20%，既能防断裂，又不至于太浪费。刀锋重叠虽然会多切几刀，但保证了关键花纹不会断在两刀之间。

递归字符分块——顺着纹理切

有经验的大厨分解一只鸡，绝不会抡起砍刀硬剁骨头，而是先找到关节，轻轻一拧就拆开了。递归字符分块就是文本世界的“关节大师”：它不按固定长度硬切，而是顺着文本的天然结构逐层拆解——先按段落分，段落太大再按句子分，句子还太大就按子句、按词分。

具体做法是准备一组按优先级排列的分隔符：段落符（两个换行）、换行符、句号、空格。切分函数 f(t) 这样工作：如果 t 的长度还没超过阈值 S，就直接收下；否则用当前最高优先级的分隔符把 t 劈开，然后对每一片子串递归调用 f。LangChain 的 RecursiveCharacterTextSplitter 就是这一思路的著名实现。

优势是尊重结构：段落、句子通常不会被人为切断，每个块内部的语义相对完整。缺陷是它依赖分隔符的“成色”：如果文档本身没有清晰分隔符——比如一行行滚动的服务器日志——它就退化成固定窗口，甚至因递归开销而更慢。

适用场景：Markdown 文档、技术博客、合同条款这类“天生有结构”的文本。顺着纹理下刀，肉不碎、语义也不散。

语义分块——按菜品备料

顶级私房菜的主厨备菜，从来不是按重量称好就完事，而是按“这道菜要做什么”来归堆：做鱼的放一盆，做肉的放一盆，炖汤的药材放一袋。这种“按意思归类”的分块方式，就是基于 Embedding 的语义分块。

它的大致流程是：先把文本按句切碎，用 Embedding 模型把每个句子编码成一个向量（一串代表语义的数字）；然后计算相邻两句向量的余弦相似度——相似度高，说明话题在延续；相似度低，说明话题发生转折，就在这个“低谷”处下刀。于是每一块内部的句子都围绕同一主题，而块与块之间井水不犯河水。

有了相似度序列后，设定一个阈值 θ，凡是相邻相似度低于 θ 的位置就是候选切分点。这种方法产出的块，内部语义高度内聚，检索质量通常是四种策略中最高的。代价也最贵：需要额外调用 Embedding 模型为每个句子推理一次，长文档处理速度慢、成本高，阈值还需要反复调。

适用场景：FAQ、论文、产品文档等“话题边界清晰”的高质量文本，以及检索质量直接决定业务体验的场景。慢工出细活，说的就是它。

参数调优——火候与刀工的平衡

刀工再好，火候不对菜也废。分块策略选得再好，参数设得离谱，效果照样翻车。参数调优是分块工程从“能用”到“好用”的那段路。

三个核心旋钮：chunk_size（块大小）决定单刀宽度，越大单块信息越全但噪声越多，越小纯度越高但上下文越容易碎；chunk_overlap（重叠大小）决定块与块的衔接，越大上下文越连贯但冗余越重；分隔符选择则决定递归和语义方法的边界质量。三者互相牵制，改一个往往要重新评估全局。

这个公式最直观的提醒是：overlap 从 10% 涨到 30%，块数会明显增加，存储与 Embedding 成本跟着上升。因此参数调优不能拍脑袋，要用真实的检索评测集反复实验，对比 Recall@k 等指标——好厨师靠试菜，好的分块参数靠实验数据说话。

经验上，多数知识库文档的块大小在 300~800 token 之间，overlap 在 10%~20%。但记住：一切以你的数据实测为准。好厨师从不迷信菜谱，而是反复试菜。

选型指南——什么菜配什么刀

中式厨房里，切肉的、切鱼的、切水果的刀通常是分开的——没有哪把刀能包打天下，分块策略也一样。关键在于看“食材”和“菜谱”。

三个决策维度。文档类型：结构化的 Markdown、合同、论文，优先递归字符分块，因为它们的天然边界明显；对话、新闻这类流式文本，用滑动窗口保持上下文；话题庞杂的 FAQ 或百科，语义分块的收益最大。业务需求：实时性要求高（比如在线文档实时问答），要避开慢速的语义分块；准确率要求高，则预算允许时优先语义分块。链路协同：下游 Embedding 模型的窗口长度、检索器的类型、大模型的上下文大小，都会反过来约束块大小。

实践上最稳健的路径是“先简单后复杂”：先用固定窗口跑通基线、把链路装好，再针对检索质量瓶颈，换成递归字符或语义分块，用 A/B 数据证明收益。不要一上来就上最贵的方案——你不知道钱花在了哪里。

备菜没有标准答案，但懂了每种刀法的脾气，你就能在灶台前从容不迫。

AI 应用场景

Python 演示

# 文本分块策略演示import re  def fixed_window(text, size=50):    """按固定长度切分"""    return [text[i:i + size] for i in range(0, len(text), size)]  def sliding_window(text, size=50, overlap=10):    """滑动窗口, 相邻块有重叠"""    stride = size - overlap    return [text[i:i + size] for i in range(0, len(text), stride)]  def recursive_split(text, separators=("\n\n", "\n", "。", " "), max_size=50):    """递归字符分块: 按优先级从段落切到词"""    chunks = []    _recursive(text, separators, max_size, chunks)    return chunks  def _recursive(text, seps, max_size, chunks):    """递归辅助函数"""    if len(text) <= max_size:        chunks.append(text)        return    for sep in seps:        parts = text.split(sep)        if len(parts) > 1:            for p in parts:                _recursive(p, seps, max_size, chunks)            return    chunks.append(text)  def semantic_split(text, max_size=40):    """简化版语义分块: 按句子聚合到接近块大小"""    sentences = re.split(r"(?<=[。！？])", text)    chunks, cur = [], ""    for s in sentences:        if len(cur) + len(s) <= max_size:            cur += s        else:            if cur:                chunks.append(cur)            cur = s    if cur:        chunks.append(cur)    return chunks  if __name__ == "__main__":    sample = ("今天天气很好。我们一起去公园。公园里有很多花。"              "下午回家。我开始写代码。代码跑通了。")    print("固定窗口:", fixed_window(sample, size=15))    print("滑动窗口:", sliding_window(sample, size=15, overlap=5))    print("递归字符:", recursive_split(sample, max_size=15))    print("语义分块:", semantic_split(sample, max_size=15))

1. def fixed_window(text, size=50):定义固定窗口分块函数，默认块大小 50 字符
2. return [text[i:i + size] for i in range(0, len(text), size)]按固定步长 size 切片，一块接一块，毫无重叠
3. stride = size - overlap滑动窗口的步长：块大小减去重叠量，重叠越大步长越小
4. for sep in seps:递归字符分块的入口：从最高优先级的分隔符开始尝试
5. parts = text.split(sep)用当前分隔符把文本劈成若干子串
6. if len(cur) + len(s) <= max_size:句子还能塞进当前块就继续塞，塞不下就另起一块
7. chunks.append(cur)一个块攒满后，把它收进结果列表

常见误区

面试题