：RAG 文本分块策略与语义完整性)
📚 本文收录于「流浪」的系列专栏
| 🐧Linux系统 | ⚙️C++ |
| 📊数据结构与算法 | 🐍Python |
| 🔗LangChain & LangGraph | 🗄️MySQL 数据库 |
| 🌿Git 工具 | 🌐计算机网络 |
| 🤖LLM | 💯大厂面试、八股 |
| 📚学习筑基专栏 |
🏠 博客主页：流浪 ｜ 📝 原创首发于 CSDN
篇十九解决的是「文档怎么变成结构化文本」——PDF 的绘图指令被还原成带标题、带表格的 Markdown。文本到手之后还差一步才能入库：一本教材几百页、一份说明书几十页，整篇丢进检索和生成都不现实。本篇拆 RAG 的第二个环节——文本分块：它为什么躲不开，六种策略各自是什么脾气，以及六种放在一张表上该怎么选。
一、文本分块是什么
1.1 定义：从整篇到片段
文本分块（Text Chunking / Splitting），顾名思义，就是把原始的可能非常庞大的文本资料（一篇长篇报告、一本电子书、一个复杂的网页）通过分割器（Splitter）分割成一系列更小、更易于处理的文本片段（Chunks）的过程。
更准确的说法是：分块就是在生成嵌入之前，把大段文本拆成更小语义单元的过程。
1.2 检索器搜的是块，不是文档
这是整篇最需要拎出来的一句话：检索器真正搜索的对象是这些分块，而不是整篇文档。
分块做得好，文档中的内容就能被干净地捕获，上下文得以保留，LLM 能做出有意义的推理；分块做得差，语义被割裂，召回结果里全是似是而非的噪声。
1.3 一个教学例子：按 8 个字符切一句话
原始文本：
西红柿炒鸡蛋是一道经典的家常菜，酸甜开胃、做法简单，而且营养丰富。每个块字数都很整齐，但没有一块能独立回答「这道菜有什么特点」。
这里的 8 只是教学用数值，用来放大刀法的效果，工程上不会这么配；它要说明的是「切割发生在哪里」这件事本身有多关键。
分块不是「把长文本切短」这么简单，它决定了「什么能被检索到」——答案如果正好跨了两个块，再强的检索器也把被打散的两半拼不回来。
二、为什么需要分块
2.1 应对模型限制
大语言模型有上下文长度限制（例如 8K、128K token），超过限制的文本无法一次处理。分块确保输入给 LLM 的每一段信息都在其「消化能力」范围之内——不是模型不够强，而是再长的窗口也容不下一整本教材。
2.2 提升检索精度
与用户问题相关的内容往往只存在于文本的某个段落中。用小分块检索，比用整篇文档检索更精准：查询论文的某一个片段，却把整篇论文塞过去给模型，干扰信息太多了——向量算的是整体相似度，篇幅越长，与目标那一小段的相关性被摊得越薄。
2.3 降低成本
只把检索命中的相关块送入大模型，而不是整个长文本，可直接减少 token 消耗。这条在生产环境里最实在：同一次问答，送入 3 个块和送入 300 页，账单差出一个量级。
分块是在上下文完整性、检索精度、token 成本三者之间取值，不是越细越好，也不是越粗越好。
三、六种分块策略
六种分别是固定大小分块（含重叠窗口）、句子分块、语义分块、递归分块、基于文档结构的分块、基于 LLM 的分块。每种按「原理 → 优点 → 缺点 → 示例」展开。
3.1 固定大小分块与 Overlap
1 原理
将文本按固定长度（字符数或 token 数）切分，每个块大小一致，可能通过重叠保留上下文连贯性。例如每 256 个字符切一块、相邻块之间重叠 20 个字符，用来减少边界信息丢失。
2 优点
无需复杂算法，代码实现高效；块大小一致，便于批量处理和向量化；适合大规模文本处理，能有效降低计算成本。
3 缺点
语义割裂——可能在句子或概念中间切分，破坏上下文完整性；信息冗余——重叠区域重复存储和计算；适用性受限——对结构化文本（如代码、技术文档）效果较差。
4 Overlap 是什么
在切分文档块时，让相邻的块之间有一部分重叠的内容。
它的优势是语义连贯性好，几乎不会出现一句话被切成两半导致 AI 看不懂的情况；劣势是冗余度高，存储成本增加——同样的内容存了好几遍，检索时也可能搜到重复信息。
教材给的例子很形象：给高等数学教材建知识库，如果死板地每 10 页撕下来装订成一份，很可能一个复杂公式在第 10 页结尾写了一半，推导过程落在第 11 页开头。改用滑动窗口，让每一份都包含前一份的最后 2 页，翻到第 11–20 页时，开头还能看到第 9–10 页的衔接内容。
固定大小是最省事的默认值，但默认值不等于决策：它解决不了「切在哪」的问题，只能靠重叠窗口把伤害降下来。
3.2 句子分块
1 原理
按句子边界（句号、问号、感叹号、换行等）切分成独立句子。它需要处理歧义——「Mr.」「Dr.」中的点号不是句子结束。
2 优点
简单快速，基于标点符号和规则，计算开销极小；保持句内完整性，不会切断一个句子的主谓宾结构；标准化，绝大多数语言处理任务（分词、词性标注、句法分析）以句子为基本单位。
3 缺点
无法合并相关句子，「今天很热。开了空调。」会被分开，丢失上下文关联；对标点错误敏感，文本缺少句号或误用标点会导致分割失败；处理缩写困难，需要特殊规则识别「U.S.」「e.g.」这类写法。
4 示例
原文：Dr. Smith is here. He lives in U.S.A. Is it 3 p.m. already? Let's go! 1. Dr. Smith is here. 2. He lives in U.S.A. 3. Is it 3 p.m. already? 4. Let's go!切出四句，注意「Dr.」不是句子的分割符——规则写得糙一点，第 1 句就会被拆成「Dr.」和「Smith is here.」两块废料。
句子分块保证的是「句内完整」，保证不了「句间关联」：语义上紧挨着的两句，依然会被扔进两个不同的块。
3.3 语义分块
1 原理与处理过程
根据句子、段落、主题等有语义内涵的单位创建嵌入，如果第一个段的嵌入与第二个段的嵌入具有较高的余弦相似度，则这两段形成一个块。
处理过程是：先把文本拆成句子或段落，把每个单元转成向量，计算相邻单元的相似度，相似度高就合并，不高就当作一个新块的开头。它依赖一个阈值来判断相似度是否显著下降，而这个阈值在不同类型的文档中往往需要不同的参数。
2 优点
语义完整性最好，保留自然语义结构，提升检索准确性；减少跨块信息丢失——「因为温度升高导致冰川融化。海平面因此上升。沿海城市面临威胁。」这三句是一条完整因果链，语义分块会把它们留在同一个块里；适应自然语言结构，按段落和话题转换切分，读起来像原文的小章节。
3 缺点
计算成本高，要算句子嵌入和相似度矩阵；块大小不统一，有的块只有一个句子，有的块可能超过模型上下文限制；对噪声敏感，格式混乱、标点错误或话题频繁跳跃时边界检测会失败；依赖嵌入模型质量；实现复杂度较高，需要调相似度阈值。
4 示例
原文：苹果是一种水果。它富含维生素C。但"苹果"也是一家科技公司。 块1：苹果是一种水果。它富含维生素C。 块2：但"苹果"也是一家科技公司。前两句是「水果」话题，第三句跳到「公司」话题，语义分块按话题切换点下刀，每个块内部逻辑都是完整的。
语义分块第一次把「切在哪」交给语义而不是规则，代价是先算一遍嵌入，还要按文档类型调阈值。
3.4 递归分块
1 原理
先按主题或段落初步划分，再对超长块递归细分，直至满足大小限制。它融合了结构化与非结构化两种处理逻辑：与固定大小分块不同的是，递归分块会尽量保持语言的自然流畅性，并保留完整的内容语义。
2 优点
保持语义边界优先，尽可能按段落、句子这类自然边界切分；自适应块大小，既不会像固定大小那样切断单词或句子，也不会像纯语义分块那样产出超大块。
3 缺点
对格式依赖高，文档完全没有换行符（如某些 PDF 扫描件）时，效果退化成普通固定长度切分；缺乏深度理解，一个长段落前半讲 A 话题、后半讲 B 话题，只要总长没超标就会被切在一起；存在长尾截断，单个句子本身超过块上限时，最终还是会被从某个空格或字符处切断。
4 示例
原文： 你好。今天天气不错。 明天会下雨。 块大小上限 8 字符： 第 1 层（按换行）：块1 = 你好。今天天气不错。（12 > 8，不合格） 第 2 层（对块1按句号）： 块1.1：你好。（4 ≤ 8） 块1.2：今天天气不错。（8 ≤ 8） 块2：明天会下雨。（7 ≤ 8） 结果：你好。 / 今天天气不错。 / 明天会下雨。递归分块是规则方法里最实用的一个：它把自然边界用到了极致，但仍然感知不到话题转换——这是它和语义分块的分水岭。
3.5 基于文档结构的分块
1 原理
利用文档本身的标记语言语法（Markdown 的井号标题、HTML 的区块类标签、LaTeX 的分节命令）或特定文件格式属性，把文档划分成逻辑独立的单元。
它不再追求「块的大小」，而是追求「块的完整性」——每一块通常对应文档中的一个章节、一个子项或一个完整的表格。
这种切法适用于文档有清晰结构的情况，但很多时候文档结构比想象中复杂，章节内容大小不一，很容易超过块的大小限制，需要结合递归拆分再做合并处理。
2 优点
保持结构完整性，避免关键信息被切断；信息组织性强，特别适合法律合同、学术论文这类对格式和层级有严格要求的文档；提升检索精度，用户针对某个章节提问时能直接定位到对应逻辑单元。
3 缺点
依赖文档质量，纯文本无结构就失效；块大小可能不均，一个章节可能大到超出模型输入限制；实现有一定复杂度，需要高质量解析器识别标题、段落、表格；解析可能存在误差，多层子标题识别错一层，分块就全盘错位。
3.6 基于 LLM 的分块
1 原理
利用大语言模型（如 GPT、Claude、Llama）智能确定文本切分边界。它不依赖固定分隔符、字符数或预定义规则，而是通过向 LLM 提供提示（prompt），让模型根据语义理解、主题连贯性、逻辑结构自主决定在哪里切分以及如何合并句子。
2 优点
语义完整性最强，能理解深层语义、主题转换、逻辑转折；适应复杂文档，对法律合同、学术论文、文学作品效果远超规则方法；可定制化，提示词能控制块的大小、粒度、风格；能处理边界歧义（缩写、列表、引用）；合并能力强，不仅会切，还能把多个短句并成一个语义块。
3 缺点
成本高昂，调 API 要付费，处理大量文档费用可观，本地部署也要 GPU；延迟较大，推理速度比规则方法慢得多，不适合实时或大规模离线处理；依赖提示质量，需要反复调试；输出存在不确定性，结果不可完全复现；受上下文限制，超长文本要先粗切，可能丢失全局信息；还可能判错边界，把紧密相关的段落分开。
3.7 分块体验工具
ChunkViz
4 示例
原文：养猫可以降低压力。研究表明，与猫互动能减少皮质醇水平。猫的呼噜声甚至有治愈效果。 不过，养猫也需要承担责任。你需要定期清理猫砂盆。还要给猫打疫苗和驱虫。另外，猫可能会抓坏家具。 提示词：请将以下文本按照语义连贯性切分成多个块。每个块应包含一个完整的主题。用"==="分隔块。只输出分块结果。 结果：前 3 句 = 减压主题块，其余 = 责任主题块。LLM 分块质量最高也最贵，通常只用在「答错有代价」的知识库上——医疗、法律这类场景才值这个钱。
四、六种策略怎么选
4.1 四条选型线
1 文档结构清晰
Markdown、HTML、法律合同、论文这类文档，直接按文档结构分块——格式已经把边界画好了，没必要再去猜。
2 文档话题频繁切换
新闻聚合、论坛帖子、多主题报告这类内容，话题说换就换，走语义分块才不会把两段话糊在一起。
3 构建高质量知识库
专家系统、医疗问答、法律助手这类场景，块的质量直接决定回答能不能用，值得上基于 LLM 的分块。
4 纯文本、来源不可控
用户上传的 TXT、OCR 出来的结果，既没有可靠结构，又不想引入额外模型或 API，希望轻量实现，递归分块是最稳的选择。
4.2 组合才是常态
实际落地基本不是单选：长文档先按结构切开，超标的章节交给递归拆分；对需要语义边界的场景，再叠加语义细分。「结构分块 + 语义细分」是最常见的一组搭档。
先用文档形态定主策略，再用成本预算决定要不要叠加语义或 LLM 细分——这是唯一一条能同时解释六种策略的选型线。
五、本篇小结
六种刀法排成一条代价递增的链：固定大小最省事、句子分块守句内、语义分块看话题、递归用规则逼近结构、文档结构直接用原生边界、LLM 让模型直判。越往后单个块的质量越高，代价是要交的计算或者使用费越多。
上一篇保证了「文本能被抽出来」，本篇保证了「抽出来的文本切得能用」——结构分块尤其依赖解析器的输出，标题层级识别错一层，按标题切出来的块就全跟着错位。
切完之后，每个块仍然只是一段字符串，检索系统读不懂字符串。把文本块转成可以比较的数值向量、以及「两块像不像」该怎么量，是构建阶段的下一环。
六、文末面试题
RAG 里常用的文本切块策略有哪些？工程上怎么选？
答:四种主流——固定长度（按字符/token 硬切，最简单最快，适合原型和杂乱纯文本）、递归切块（按段落→句子→单词分层递归，是 LangChain、LlamaIndex 的默认方案，也是企业 RAG 的性价比首选）、语义切块（用嵌入相似度识别话题边界，精度最高但慢且贵）、以及文档结构切块（按标题层级切，只适合有结构的文档）。落地最优组合是「递归切块 + 10%~20% 重叠」做通用基线，高精度业务再叠加语义切块；生产环境不允许零重叠切块。
【真题·转述自 CSDN《【AI面试临阵磨枪-40】文本切块(Chunking)策略：固定长度、语义切块、递归切块、重叠设计》、阿里云开发者社区《详解RAG五种分块策略，技术原理、优劣对比与场景选型之道》】chunk_size 和 chunk_overlap 怎么定？有没有通用值？
答:经验法则是——块要能覆盖一个完整的命题（一条公司规定、一个操作步骤），业界通常几百到一两千 token；重叠取块大小的 10% ~ 20%，太小容易切掉关键句，太大则让向量库无意义膨胀。可以展开成一档一档讲：100~200 token 检索精准度高但上下文丢失严重，适合事实型问答；300~500 是通用知识库的推荐默认；600~800 上下文完整但噪声变多，适合长文档摘要；1000 以上检索明显不准，不建议做默认值。终极答案是没有银弹，必须在自己的数据集上做网格搜索，看哪组参数的 Recall@K 最高。
【真题·转述自 CSDN《2026最新RAG面试题集：45问覆盖全链路》、CSDN《【AI面试临阵磨枪-40】文本切块(Chunking)策略》】为什么要设 Overlap？是不是重叠越大越好？chunk_overlap 能不能设成 0？
答:Overlap 解决的是「关键信息正好落在边界被切两半」导致的漏召——没有它，一个跨边界的句子会变成两块都不完整的碎片。但它不是越大越好：20% 的重叠大约会多出 25% 的块，索引时间、向量库体积、查询成本跟着涨；到 50% 更糟，会产生大量近似重复的块，两者同时排进 top-K，白占上下文窗口。工程上的补救是先去重再送模型。所以重叠不能设 0，也不能贪大。
【真题·转述自 Learnixo·RAG Chunking Strategy Interview Q&A、CSDN《2026最新RAG面试题集：45问覆盖全链路》】分块太大或太小，分别会导致什么后果？
答:太小会导致语义支离破碎，检索出来的片段可能缺主语或前置条件，模型看了也是一头雾水；太大则会混入大量无关噪声，既干扰生成时的注意力，又把嵌入向量的特征摊薄导致检不出来，同时 token 费用大幅上涨。可以分档说：100~200 token 精准度高但上下文丢失严重，300~500 最通用，600~800 上下文完整但噪声变多，1000 以上不建议做默认值。
【真题·转述自 CSDN《2026最新RAG面试题集：45问覆盖全链路》、CSDN《【AI面试临阵磨枪-40】文本切块(Chunking)策略》（】为什么多数 RAG 框架默认给的是递归字符切分？它什么时候不够用？
答:因为递归切分在成本和语义之间取值最均衡——先按大分隔符（换行、段落）切，超长再退到句子、再到词，几乎不引入额外算力开销，所以主流框架都把它做成默认，常见配置是 400~512 token 配 10%~20% 重叠。它不够用的地方有三处：文本没有稳定分隔符（如压缩成一坨的无换行扫描文本）时会退化成硬切；同一段落里话题漂移它感知不到；单句本身超过上限时仍会被粗暴截断。
【真题·转述自 Firecrawl·Best Chunking Strategies for RAG (and LLMs) in 2026、CSDN《【AI面试临阵磨枪-40】文本切块(Chunking)策略》】NVIDIA 的切分评测里，页级切分表现怎么样？它能当通用方案吗？
答:NVIDIA 的实验结论是页级切分（Page-level）在多样性数据集上平均准确率最高、约 0.648，且方差最小。但它只对有稳定页码结构的文档成立，块大小完全取决于页面排版，遇到超长页会突破上下文预算，也和段落、章节这类语义边界对不上。所以它是「特定文档类型上的强基准」，不适合当跨文档类型的通用默认。
【真题·转述自 Firecrawl·Best Chunking Strategies for RAG (and LLMs) in 2026、CSDN《2026最新RAG面试题集：45问覆盖全链路》】召回的文档是对的，但答案总差半截——答案跨了两个块，怎么修？
答:按复杂度递增有三条路。第一条是加大重叠：答案稳定跨边界时，20% 重叠通常能让至少一个块把它罩住。第二条是父文档检索（Parent Document Retrieval）：把小块拿去做嵌入匹配保证精准，命中之后不返回小块本身，而是返回它所属的完整父段落或父章节给模型生成，也就是常说的父子索引。第三条是加窗口：检索仍用小块，取回时向前后各扩若干句。选哪条看三件事——文档有没有清晰段落结构（有则用父文档）、答案是不是短而具体（是则加重叠）、用户问法的答案长度是不是差异很大（是则用窗口扩展）。
【真题·转述自 Learnixo·RAG Chunking Strategy Interview Q&A、CSDN《2026最新RAG面试题集：45问覆盖全链路》】语义分块和递归分块怎么选？什么时候值得为语义分块买单？
答:区别在「谁决定边界」——递归分块靠分隔符层级，优先打通段落、句子这类自然边界，纯字符串运算，速度快；语义分块要在索引时给每个句子算嵌入来检测话题漂移，处理开销比递归分块高一个量级。买单的判断标准有两条：一是文档集值不值，临床指南、监管文件、章节密度差异大的长论文属于「检索质量比成本重要」，值得上；日更几千篇或文档本身很短的高吞吐流水线相反，调优好分隔符的递归分块能拿到九成质量、只花很少的钱。二是话题漂移是不是频繁，漂移越频繁，规则类刀法越吃亏。
【真题·转述自 Learnixo·RAG Chunking Strategy Interview Q&A、CSDN《【AI面试临阵磨枪-40】文本切块(Chunking)策略：固定长度、语义切块、递归切块、重叠设计》】表格、列表、代码块这类结构化内容在分块时怎么处理？
答:结构化内容几乎能把所有切块策略搞崩，做法是先把它们标成不可分割的整体，再让普通文本走通用流程：表格整表作为一个块，绝不切割，并在块前面加一句说明这张表讲什么的文字前缀；列表必须把标题和条目留在同一块，中间断开条目就丢了它的主语；代码块只在函数或类边界处切，不在函数体中间切。工程上加一道预处理，扫出 Markdown 表格和代码围栏标记成整体，剩余文本再交给递归分块。
【真题·转述自 Learnixo·RAG Chunking Strategy Interview Q&A、CSDN《2026最新RAG面试题集：45问覆盖全链路》】按 Markdown 标题做文档结构分块，实际落地会遇到什么问题？
答:三个坎——一是依赖文档质量，纯文本或排版混乱的文档直接失效；二是块大小极不均匀，一个章节可能大到超过模型输入限制；三是标题层级要靠解析器认，多层子标题错认一层，分块就全盘错位。落地做法是「结构分块打底 + 递归兜底」：先按标题切成逻辑单元，超标的单元再交给递归拆分，过碎的相邻小节再做合并，同时把标题路径写进元数据，便于生成时回溯上下文。
【真题·转述自 阿里云开发者社区《详解RAG五种分块策略，技术原理、优劣对比与场景选型之道》、CSDN《【AI面试临阵磨枪-40】文本切块(Chunking)策略》】基于 LLM 的分块值得用吗？成本到底贵在哪？
答:贵在两处——一是算力，文本要整篇过一遍模型推理，文档量大时费用可观，延迟也远高于规则方法；二是不可控，结果对提示词敏感、输出带随机性，不完全可复现，决策过程也说不清。它的适用范围因此偏窄：非结构化文本（访谈记录、会议纪要、用户评论）和需要高级语义分析的跨领域整合场景。反过来说，文档本身格式规范、体量又大的知识库，用结构分块或递归切分就够了，不必上大模型。
【真题·转述自 阿里云开发者社区《详解RAG五种分块策略，技术原理、优劣对比与场景选型之道》、Learnixo·RAG Chunking Strategy Interview Q&A】生产环境的分块有哪些常见踩坑？
答:四条最常见的：
- 一是只做固定长度不递归，语义割裂严重、问答乱答；
- 二是不开重叠，边界关键信息丢失，召回直接缺一块；
- 三是语义切块的阈值乱设，块过碎或块过大都没救；
- 四是统一尺寸不做自适应，长句被硬截断。
此外还有一条铁律——生产环境不允许零重叠切块，重叠是所有策略的标配。
【真题·转述自 CSDN《【AI面试临阵磨枪-40】文本切块(Chunking)策略：固定长度、语义切块、递归切块、重叠设计》、CSDN《2026最新RAG面试题集：45问覆盖全链路》】
💬结语：六种刀法没有对错，只有成本账：结构清晰的省事只看形态，不清晰的才轮到语义和模型兜底。你的知识库用的是哪一把？评论区聊聊，关注流浪，LLM 系列持续更新。
