RAG 如何选择 chunksize 和 splitter？

面对RAG落地的种种细节，很多人都在纠结chunksize到底该怎么设。本文从text2vec模型的原理出发，先做假设，再用HuixiangDou的真实数据进行验证，最终给出chunksize的合理上下界。核心观点其实很简单：关键是要让分词后的长度与模型输入（比如512）对齐，这样才能把模型的编码能力用足。至于chunksize，它只是splitter的一个附属选项。相比默认参数，精细调参能改善大约2%的F1指标，但要是chunksize用错了，可能导致10%的下降——这个差距，值得重视。

text2vec 和 autoencoder

现实世界里，绝大多数数据都是未标注的，甚至根本没法标注。我们希望神经网络也能“理解”这些数据，然后通过微调或结构改造，把这种理解能力迁移到下游任务上。自编码器（autoencoder）就是这类无监督学习的一种经典范式。

上图是autoencoder的基本结构[1]，它由两部分组成：

• 编码器
  ：负责从无监督数据Input中提取表征h

• 解码器
  ：尝试把h还原为原始输入，得到Output

Loss自然来自Input和Output的差异，最终h的信息量应该和Input一致。

在text2vec模型训练里（比如RetroMAE[2]），编码器常用BERT[3]，解码器则用Transformer的单层decoder。下游业务中，解码器会被丢弃，只保留编码器来提取特征。

拿BCEmbedding[4]举例：输入经过tokenize，填充或截断到512长度，然后执行模型推理。

但用户输入的词元（token）不可能恰好是512个，这就会造成编码能力的浪费（填充部分）或者原始信息缺失（截断部分）。所以，text2vec的调参目标其实很明确：

测试数据

HuixiangDou（豆哥）是一个运行在群聊场景里的领域知识助手。它的工作流程是这样的：

1. 运行前，用领域知识文档（比如word、pdf、markdown等）创建知识库base，并配置先验阈值throttle；
2. 运行期间，针对用户的每句话query，计算它与知识库的得分score = text2vec(base, query)，低于throttle的问题会被当作LLM chat里的history或者指代消歧的背景，不会触发RAG。

这个拒答过程其实和面部识别很像——都是通过计算特征距离来找到最近或最远的底库。

本文使用的知识库是OpenMMLab相关的9个repo中的所有markdown、txt和pdf文档，一共1150个。文档长度平均值5063，中位数2925。query来自OpenMMLab用户群和ncnn开发者群，累计2302条问题，并通过人工标注来判定问题与知识库是否相关。测试脚本和数据已经开源在GitHub上。

测试结果

1. 对text2vec来说，chunksize选多大合适？

对BCE，推荐范围是(512, 1500)；对BGE推荐(423, 1240)。豆哥目前用的是832。

看下图：x轴是chunksize，y轴是不同throttle下的最优F1 score，两条曲线代表不同的splitter方法。可以明显看到，低于512的chunksize都达不到最优F1。

豆哥创建知识库时，要先把这1150份文档切分成片段、编码成tokens。假设这些tokens长度符合正态分布。如果分布的均值和模型一样是512，那么分布右侧的片段就会因截断而丢失信息，分布左侧的则需要填充到512。通过在embedding.tokenizer和ChineseTextSplitter上调试，我们找到了对应的chunksize数值。

考虑到输入缺失对精度的影响更大，所以选取更小的chunksize让分布左移，能缓解信息缺失，从而得到更好的F1 score。左移多少取决于数据的真实分布。在BCE上通过暴搜验证：当chunksize=640，throttle=0.44时，F1上涨了0.5，达到了75.88。

2. 应该选择哪种splitter？

前面的左值测试已经显示出ChineseTextSplitter的优势。更严谨地说，固定chunk_size=768，从统计角度对比三种splitter的切分结果：

• 基于换行符的CharacterTextSplitter实际上没实现切分；
• RecursiveCharacterTextSplitter和ChineseTextSplitter长度分布不同：ChineseTextSplitter对中文场景做了特定优化，遇到没有中文语义的文档（比如CMakeLists.txt）会放弃切分，直接返回原始输入。

简单总结：中文场景优选ChineseRecursiveTextSplitter，英文场景推荐RecursiveCharacterTextSplitter，尽量避免直接用CharacterTextSplitter。

3. BCE还是BGE？

前面验证右值时，已经给出了HuixiangDou在BCE和BGE[5]上的精度结果：75.39 vs 72.23。本文没有观察到二者在结构上有显著差异，考虑到BGE模型更大，推测BCE的训练数据与豆哥更匹配。不过，BGE提供了完整的复现过程、论文和源码，对于注重数据隐私的业务，BGE更适合做微调和难例挖掘。

总结

本文基于HuixiangDou的真实数据，给出了text2vec模型chunksize的上下界，同时提供了选择splitter和text2vec模型的依据。当然，这次验证还不够全面，需要覆盖更多领域（比如电力）和任务类型（比如图文混合检索），我们会继续探索。另外需要说明的是，为了让机器人“有问必答”、避免太高冷，豆哥源码实际关注的是recall而不是F1，所以实际阈值会偏低一些。