文本分块 chunk_size 没有统一最优值，需根据文档类型和查询类型动态调整。中文场景推荐 256-512 token，英文场景推荐 512-1024 token，但固定尺寸无法适配所有查询，多尺寸逐级 chunk 策略可提升检索准确率。

快速处理思路

根据文档类型选择初始 chunk_size 范围，再结合 overlap 参数进行微调。对话和 FAQ 类内容使用 256-512 token，普通说明文使用 768-1024 token，技术手册和法律合同使用 1024-1536 token，代码和数学公式使用 1536-2048 token。重叠窗口设置为 chunk_size 的 10%-20%，例如 512 token 对应 60-100 token 重叠。

为什么会这样

不存在能适配所有查询的单一 chunk 大小，不同查询类型对应的最优 chunk 尺寸差异明显。AI21 的实验数据显示，事实型查询用 100 token 的小 chunk 才能精准命中，理解型查询需要 500 token 以上的大 chunk 才能匹配到关键上下文。固定尺寸 chunk 在某一查询上表现良好，往往无法适配另一查询，最优性能相比任何固定尺寸 chunk 有 20%-30% 的准确率优势，部分数据集甚至超过 40%。

分步处理

第一步，分析文档特征。检查文档类型是对话转录、技术手册还是法律合同，中文文档需注意语义单元更细碎，平均词长约 2.3 字/词，标点密度高。第二步，设置初始 chunk_size。中文场景从 256-512 token 开始，英文场景从 512-1024 token 开始。第三步，配置 chunk_overlap。设置为 chunk_size 的 10%-25%，避免关键信息被切断。第四步，测试检索效果。使用代表性查询测试 Top-K 召回率，对比不同 chunk_size 的表现。第五步，考虑分层检索。使用 LangChain 的 ParentDocumentRetriever 实现双层检索架构，小块提高检索精度，大块保留完整语义。

怎么验证是否生效

使用测试查询集对比不同 chunk_size 的召回率，记录 Top-1 和 Top-5 召回结果。检查检索返回的 chunk 是否包含完整语义单元，关键信息是否被切断。观察 LLM 生成答案的完整性，是否存在因上下文缺失导致的信息遗漏。对于技术文档，验证代码块、函数定义是否保持完整结构。对于法律合同，验证条款是否被完整召回，违约责任等关键内容是否语义完整。

常见坑

全局硬编码陷阱：将所有文档统一设为 chunk_size=512，无视语言特性和文档类型差异。OCR 噪声盲区：扫描件经 OCR 后含乱码和换行错位，不预清洗直接切分会把噪声与正文强耦合。代码块断裂风险：技术文档中函数定义和异常堆栈需上下文完整，过小的 chunk_size 可能截断闭合结构。表格处理问题：跨页表格切分后表头丢失，下半段 chunk 只剩数据无上下文。Overlap 设置随意：未做实验对比就设定 overlap 值，可能导致冗余或信息割裂。

常见问题

chunk_size 设置多少最合适？

没有统一最优值，需根据文档类型和查询类型调整。中文常用 256-512 token，英文常用 512-1024 token，但固定尺寸无法适配所有查询。

chunk_overlap 应该设多少？

建议设置为 chunk_size 的 10%-25%，例如 512 token 对应 60-100 token 重叠，过大会浪费存储资源，过小会切断语义。

为什么固定 chunk_size 效果不好？

不同查询类型对应的最优 chunk 大小差异明显，事实型查询需要小 chunk，理解型查询需要大 chunk，单一尺寸无法覆盖所有场景。

如何避免关键信息被切断？

设置合理的 chunk_overlap，使用语义边界识别分块，或采用 ParentDocumentRetriever 等分层检索架构平衡精度与信息量。

参考来源

CSDN 博客 - RAG 文本拆分 (Chunk 分割) 全维度优化方案：平衡信息完整性与检索精度

AI21 实验数据 - chunk 大小没有最优解！多尺寸逐级 chunk 如何提升 RAG 准确率

LangChain 文档 - ParentDocumentRetriever 双层检索架构

斯坦福大学 2023 年研究 - 分块策略对 RAG 召回率的影响

RAGFlow API 中文手册 - chunk_size 参数设置指南