直接给结论：没有万能 chunk size，但对结构化的产品/技术文档，按标题（Markdown 标题层级）分块在我这组测试里综合表现最好，固定长度最差，语义分块召回最高但贵且慢。下面是数据。

测试是怎么搭的

我手头有份内部产品手册，约 4.2 万字，标题层级清晰（一级到三级），混了表格和代码块。我想给它建个问答机器人，但纠结分块策略，干脆做了组对比。

搭机器人这事我没写代码，用的那种拖拽配置就能接知识库的智能体平台，知识库的分块方式可以选，正好拿来当实验台。我准备了 30 个真实问题（从客服历史里抠的），人工标好每个问题对应文档里哪几段是标准答案。

评测指标三个：

• 命中率：检索回来的 chunk 里，包含标准答案的比例。

• 答案完整度：人工打分，答案是否被切碎（1-5 分）。

• 平均检索 token：召回内容塞进上下文的平均 token 量，关系到成本。

三种分块跑下来的数据

同一份文档、同一组 30 题，只换分块方式：

几个比数字更值钱的观察

固定长度 256 字是真的不行。 命中率 63%，而且因为太短，一个完整的操作步骤会被拦腰切断，检索回来半句话，模型只能瞎补。别图省事用小固定值。

重叠（overlap）确实有用，但治标。 512 字加 50 字重叠，把被切断的句子救回来一些，命中率从 78% 提到 81%。代价是 token 涨、内容冗余。能用结构分块就别靠重叠硬扛。

按标题分块的性价比最高。 我这份文档标题规整，按二三级标题切，每块天然是一个完整语义单元——一个功能点、一段步骤。命中率 89%，token 还比固定 512 低，因为没那么多冗余。但前提是你的文档真有规整的标题层级，那种一篇到底没小标题的散文，这招直接失效。

语义分块召回最高，但我没全量上。 命中率 91% 确实漂亮，可它建库时每段都要算嵌入再决定切点，4 万字的文档建库等了挺久，更新一次重切一次。我们文档周更，算下来不划算。最后只在那份几乎不变的"API 参考"上用了语义分块，周更的手册用按标题。

我最后的选法

不是选一个用到死，是按文档类型分：

• 有清晰标题层级的（手册、Wiki）→ 按标题分块。

• 几乎不更新、要求高召回的（API 文档、法规）→ 语义分块。

• 实在没结构的纯文本 → 固定 512 + 50 重叠，将就。

还有个没测进去的变量是表格。表格被任何按字数的策略切都会烂，我后来是把大表格单独拎出来转成"每行一条问答"再入库的，这个另说。

底层模型和向量化我用的是讯飞 MaaS 提供的现成接口，模型即服务，没自己搭嵌入服务和推理机。

你们 RAG 的 chunk size 一般定多少？有没有上过更细的动态分块、效果如何，评论区甩数据。