完整题目
在构建RAG或文本处理系统时，如何进行有效的文本分块（chunking）？请讨论不同的分块策略和考量因素
本文目录
答案要点
- 分块策略类型（固定长度、滑动窗口、语义分块等）及适用场景
- 分块大小的权衡（粒度vs语义完整性）
- 边界处理策略（句子/段落保持）
- 实际工程中的考量因素（计算成本、检索效果、下游任务）
- 百度场景下的特殊优化（中文分词、长文档处理）
核心分块策略
1. 固定长度分块
- 按token数或字符数硬切分（如512 tokens）
- 优点：简单、对齐向量索引、便于批处理
- 缺点：可能切断语义，边界信息丢失
2. 滑动窗口分块
- 把零重叠、短窗口和较长窗口作为候选，用同一评测集比较边界证据完整率、召回与成本
- 保证上下文连续性，减少边界效应
- 代价：存储和计算成本上升
3. 语义分块（推荐）
- 基于句子/段落边界切分，保持语义完整
- 可用NLP工具（spaCy、NLTK）或模型判断语义边界
- 中文场景需特别注意：按标点切分优于按字符切分
4. 结构化分块
- 按文档结构切分：标题→章节→段落
- 适合PDF、Markdown等结构化文档
- 保留层级元信息，支持多级检索
关键考量因素
| 维度 | 权衡点 |
|---|---|
| 粒度 | 小块（100-300）检索精准但碎片化；大块（1000+）语义完整但噪声多 |
| Embedding模型 | 匹配模型最大长度（如text-embedding-ada-002是8191，但有效信息通常在前512） |
| 检索阶段 | 粗排用大chunk保召回，精排用小chunk保精准 |
| 计算成本 | 分块数直接影响向量库规模和推理延迟 |
| 业务场景 | 问答场景倾向小chunk；摘要/分析场景倾向大chunk |
百度场景的特殊实践
- 中文优化：基于LTP/Jieba做句子切分，避免英文空格切分的陷阱
- 长文档处理：论文/报告类采用"摘要+正文"双层分块，先检索章节再定位细节
- 动态分块：根据内容类型自适应调整（代码块保留完整、正文按段落切分）
实际建议：从固定长度+滑动窗口快速验证，再逐步引入语义分块优化。
换一种问法，检查是否真正理解
场景切入
假设你在做电商客服的RAG系统，用户问‘这款手机怎么样’，系统需要从产品手册中找答案。但手册很长，你打算怎么把文档切成合适的片段，让检索又快又准？
层层追问
做RAG的时候文本分块你会怎么处理？……如果直接按固定长度切，可能会切断句子，有什么改进？……那有没有办法让分块更智能，比如保持语义完整？
直球架构
聊一下文本分块策略。从固定长度、滑动窗口到语义分块，你怎么选？考虑哪些因素？比如分块大小、边界处理、计算成本，还有中文场景的特殊性。
练习口述回答 · 约4分钟
- RAG分块本质是信息密度与语义完整性的取舍
- 三种主流策略的适用边界
- 业务场景驱动的分块设计
- 落地风险与混合策略
- 延伸点：动态分块与多级检索
这道题其实问的是，在[[RAG]]系统里，怎么把文档切成合适的小块，既让检索能精准命中，又不把语义切碎。说白了，就是信息密度和语义完整性之间的取舍。
先说几种常见的[[分块]]策略，以及它们各自该在什么场景用。固定长度分块，就是按token数硬切，比如512个token一段。好处是简单，向量索引对齐也方便，但问题很明显，可能一句话被拦腰切断，检索时上下文就丢了。[[滑动窗口]]分块会让相邻块保留一部分重叠，可能减少边界信息丢失，但代价是存储、计算与去重成本上升。窗口大小仍应作为候选变量，用同一评测集比较后再定。真正落地的话，这两种其实更适合英文或者短文本场景，中文用它们很容易出问题。
语义分块是我更推荐的，就是按句子或段落边界切，保持语义完整。中文场景里，用标点符号切分比按字符切分靠谱得多，因为中文不像英文天然有空格。举个例子，客服退款场景里，用户问“我的退款为什么还没到”，如果切块把“退款”和“还没到”分到两段，检索召回就偏了。用语义分块就能保证整句在一起，匹配更准。
结构化分块适合有层次结构的文档，比如PDF或Markdown，按标题、章节、段落来切，保持层级信息。这样检索时可以先定位章节，再找细节，效率高。
这里有个关键权衡：分块粒度。小块比如100-300 token，检索精准但容易碎片化，适合问答；大块比如1000+ token，语义完整但噪声多，适合摘要或分析。具体用多大，得看下游任务和[[Embedding]]模型的最大长度。比如text-embedding-ada-002虽然支持8191 token，但有效信息往往在前512，切太大反而浪费。
实际工程里，我通常不会只用一种策略。比如处理企业SOP文档，我会先用结构化分块按章节切，再对每个章节用语义分块按段落切，这样既保留了文档结构，又保证了段落语义完整。检索时粗排用大块保召回，精排用小块保精准，配合[[Rerank]]效果更好。
落地风险也很明显。前提是分块策略要和检索方式匹配。如果只做向量检索，语义分块比固定长度好；但如果混合了[[BM25]]关键词检索，固定长度分块反而可能因为词频统计更均匀而表现更好。常见失败场景是，分块切得太碎，导致检索时上下文丢失，生成结果出现[[Hallucination]]。上线我会特别关注分块数对[[向量库]]规模和推理延迟的影响，分块数太多，检索延迟会飙升。
另外，我现在比较关注动态分块，就是根据内容类型自适应调整。比如代码块保留完整，正文按段落切，甚至用模型判断语义边界。这个方向如果能做好，能进一步减少人工调参的工作量。
所以整体上，我更倾向从固定长度加滑动窗口快速验证，再逐步引入语义分块优化，最后根据业务场景做定制。