在RAG系统中，chunk_size和overlap的设置没有绝对的“黄金标准”，但是我认为核心思想应该是：从通用推荐值出发，根据文档类型和语言特性进行调整，并通过实验验证找到最适合你特定场景的参数。（就像线程池的核心线程数的设置一样）
通用起点推荐推荐
首先，我们设置的chunk_size和overlap的单位都是字符数，并不是token数！这个需要注意。 我们从token的角度来说的话，chunk_size一般我们建议先从512或1024个token开始设置（部分模型的token数是512的限制，如bge-small-zh，而百炼上的text-embedding-v3、text-embedding-v4都是8192个token）。 而一个token大概是在1.5-2个汉字之间，在3-4个英文字符之间，所以，如果是纯中文文档，可以设置500-1000左右的chunkSize，英文文档的话，可以设置2000-3000左右的chunkSize 那么overlap的话，可以根据chunksize来取一个10%-20%的比例。 chunkSize不建议太小，也不建议太大： 1. chunk_size 过小 (<300字符)：容易导致语义碎片化，丢失关键上下文。（用了父子分片虽然能缓解这个问题，但是也可能会带来上下文过长的问题） 2. chunk_size 过大 (>1024字符)：会包含过多无关信息，稀释核心语义，降低检索精度，并增加大模型的上下文负担和成本。 3. overlap 为0：极易在切分边界处丢失信息，导致相邻的块语义断裂。
按文档类型调整
当然，不同的文档类型对上下文的需求不同，因此需要差异化设置。下表为你提供了更具体的实操建议： | 文档类型 | 推荐 | 推荐 | 核心考量 | | --- | --- | --- | --- | | 纯文本/文章 | 256 - 512 | 32 - 64 | 保持段落连贯，避免信息碎片化。 | | 技术文档/代码 | 384 - 512 | 64 | 确保函数、类或代码块的完整性，避免被截断。 | | 法律/合同文件 | 320 - 512 | 48 - 64 | 保持条款和逻辑推理的上下文，中文法律条文在320时效果可能更佳。 | | FAQ/知识库 | 300 - 600 | 30 - 60 | 追求查询精准，每个块应聚焦于一个独立的问答对或事实。 | | 长文本/论文 | 512 - 1024 | 100 - 200 | 需要更大的上下文来理解复杂的论证和证据链。 |
项目中的分段设置方式
我在项目中，是这么干的。我先根据markdown的标题分段（实际你自己可以按照段落、特殊符号都可以。），跑一下这个markdown文件一共会被分成多少个段，假如说是2000个。 那么如果我认为最差的情况是，一个分段被chunkSize拆分后会导致无法召回，那么假如我要求召回率能在95%的话，那么我就是可以接受100个分段无法召回。 那么我就可以通过调整我的chunkSize，然后去计算下有多少个chunk是带有parentChunkId这个metadata的，有这个的说明他是被二次拆封过的，最差的情况是可能会无法召回。 数据怎么看，运行单元测试就行了，不需要实际上线跑。如MarkdownHeaderParentTextSplitterTest 因为我的示例文档是拆分成1894个分段，chunkSize设置为1000，刚好能有90个左右的被二次切分的父分段。所以选择了1000。
A/B 测试与验证
初始值配置之后，还可以做AB测试，可以准备50-100个有代表性的真实用户问题，并标注好每个问题对应的正确答案所在的文档片段。 使用你的测试集，对比不同参数组合的效果。例如，可以测试 chunk_size 为 [256, 512, 768] 和 overlap 比例为 [10%, 20%] 时的检索准确率。 分析那些没有检索到正确答案的查询。是因为相关片段被切碎了？还是因为块太大导致关键信息被稀释？