知识库

知识库分块不是越小越好——改了分块大小，准确率跳了18%

2026 年 7 月 7 日

分块大小不是固定值，关键在于匹配文档类型。从512改到256，客服知识库准确率飙升18%，但技术文档反而需要更大分块。核心内容： 1. 盲目使用默认分块大小是常见误区 2. 客服QA与长技术文档的最佳分块策略截然相反 3. 通过实验数据揭示分块大小的核心影响机制

我做过最蠢的一件事：知识库搭好后，跑了三个月，各种调Prompt、换Embedding模型、加Rerank——准确率一直在70%上下晃。从来没想过改一个参数。

分块大小。

从512改到256，同一批测试问题，准确率跳了18个点。

不是模型的锅。是分块。

一、为什么没人怀疑分块？

因为大多数RAG平台的默认分块大小就是512。LlamaIndex默认512，LangChain默认400-1000，各厂商SaaS平台也差不多。

默认值看起来很合理——一个段落差不多就是500个字。于是所有人都默认接受了。

但这里面藏着一个假设：你的文档，是按500字一段来写的吗？

客服知识库不是。它是这样的：

Q：怎么退保？ A：退保流程：1.登录APP→2.我的保单→3.选择要退保的保单→4.点击「退保」按钮→5.填写退保原因→6.确认提交。退保金额按照保单现金价值计算，具体金额以系统显示为准。

这条记录总共不到100个字。用512分块，它会跟前后好几条Q&A挤在同一个小块里。

当客户搜索「退保能退多少钱」，Embedding模型面对的是一个混了退保流程、投保规则、理赔说明的大杂烩。它怎么知道你究竟要什么？

▲ 分块大小的核心洞察

分块大小决定的是「每个检索单元的语义纯度」。太大了，一个块里混了太多主题；太小了，一个完整的意思被拆得支离破碎。两者都会让检索「跑偏」。

二、512→256：一个实验

我把同一个知识库（1200条客服Q&A）用四种分块大小各建了一遍索引：

分块大小	Top-3命中率	Top-1命中率	平均回复相关度
1024 tokens	61%	38%	2.8/5
512 tokens	71%	47%	3.2/5
256 tokens	89%	68%	4.3/5
128 tokens	82%	59%	3.9/5

测试集：100个真实客户问题，涵盖退保、理赔、投保、续费四类。

▲ 客服Q&A分块实验对比

256是明显的甜点。再小到128，命中率反而下降——因为一条完整的Q&A被切成了两半，检索时只能命中一半。

三、但技术文档是反过来的

同一个实验，我换了一批知识库——300篇技术运维文档（每篇2000-5000字的长文）。

分块大小	Top-3命中率	Top-1命中率	平均回复相关度
1024 tokens	84%	62%	4.1/5
512 tokens	76%	51%	3.5/5
256 tokens	68%	42%	3.0/5
128 tokens	55%	31%	2.5/5

▲ 技术文档分块实验对比

技术文档的最佳分块是1024，不是256。为什么？因为技术文档的一个完整知识点（比如「Nginx配置反向代理的完整步骤」）通常需要800-1200个字才能讲清楚。切成256，一个完整步骤被拆成4-5块，检索时只能命中其中一块，上下文全丢了。

四、不同文档类型的「黄金分块大小」

做完两组实验，我总结了一个规律：分块大小应该匹配文档的「语义单元」大小。

文档类型	典型语义单元	推荐分块大小	说明
客服Q&A	单条Q&A（50-200字）	256	一条Q&A一个块，不混
技术文档	一个完整步骤/章节	1024	保证步骤完整性
产品条款	一个条款项（200-500字）	512	条款项不拆分
法律合同	一个条款（300-800字）	512	法律条款不宜拆分
新闻资讯	一个段落（100-300字）	256	段落即语义单元
API文档	一个接口说明	512	接口参数+示例不拆

▲ 不同文档类型的黄金分块大小

五、怎么找到你的「黄金分块大小」

不要抄别人的参数。5步找到你自己的最佳值：

1. 准备测试集：20-50个真实用户问题 + 标准答案

2. 选4个分块大小：128 / 256 / 512 / 1024（覆盖小到大）

3. 各建一遍索引：同一个知识库，4个向量库

4. 跑测试集：每个问题检索Top-3，记录命中率和相关度

5. 选命中率最高的：不要迷信「越小越好」或「越大越好」

▲ 5步找到黄金分块大小

整个流程不超过5分钟。但结果是你自己的数据验证出来的，不是抄别人的参数。

我们一个做保险客服的朋友，用的就是这套方法，在512和256之间做了一轮对比——256命中率比512高了18个百分点。而另一个做SaaS文档的朋友，从512改到1024反而提升了。他在微信上跟我说：「原来我一直在用文档检索的配置跑客服场景。」

六、一个容易被忽略的参数：overlap

分块大小之外，还有一个影响很大的参数：overlap（重叠量）。

overlap是相邻两个块之间共享的文本。比如chunk_size=256, overlap=20，意味着每个块的结尾20个字会在下一个块的开头重复。

overlap的价值：防止关键信息刚好落在两个块的分界线上。

我见过最惨的情况：客户问「等待期内出险怎么赔」，知识库里正好有一段讲等待期——但「等待期」三个字在块A的最后，「内出险赔付规则」在块B的开头。两个块各搜出来了一半，但都不完整。检索结果排在第三页。

▲ overlap重叠量说明

推荐值：chunk_size的10%左右。 256的块用20-30的overlap，512的块用50。太小了防不住边界截断，太大了浪费存储且稀释语义纯度。

七、总结

分块大小是RAG最被低估的参数。很多人花几周调Prompt、换模型、加Rerank，效果不明显。把这个参数改成适合你场景的值，20个问题，5分钟。

不是模型不行。是你的分块在跟你的文档打架。

立即咨询 JOTO

JOTO 提供覆盖企业智能体规划与搭建、AI 平台私有化部署、RAG 知识工程、AI 安全治理、FDE 驻场共创及持续运营优化的全周期 AI 落地服务，帮助企业把验证中的 AI 能力转化为安全、可控、可持续迭代的生产力。联系 JOTO 获取 AI 落地咨询

想把这些做法用到你的业务里?

留下你的场景和痛点,我们帮你判断从哪一步开始。

联系我们

知识库分块不是越小越好——改了分块大小，准确率跳了18%

立即咨询 JOTO

想把这些做法用到你的业务里?

Start your enterprise AI rollout

Tell us what you need