分块大小不是固定值，关键在于匹配文档类型。从512改到256，客服知识库准确率飙升18%，但技术文档反而需要更大分块。
核心内容：
盲目使用默认分块大小是常见误区
客服QA与长技术文档的最佳分块策略截然相反
通过实验数据揭示分块大小的核心影响机制
我做过最蠢的一件事：知识库搭好后，跑了三个月，各种调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分钟。不是模型不行。是你的分块在跟你的文档打架。
[登录查看剩余 70% 内容](javascript:void (0);)
大模型RAG什么是RAG知识库rag实践
分享：
用微信扫描二维码
用微信扫描二维码
用微信扫描二维码
用微信扫描二维码
53AI，企业落地大模型首选服务商
产品：场景落地咨询+大模型应用平台+行业解决方案
承诺：免费POC验证，效果达标后再合作。零风险落地应用大模型，已交付160+中大型企业
上一篇：顶级AI 检索服务商Exa ，如何用 Zilliz Cloud服务Agent 检索需求下一篇：分类、抽取、Rerank：小模型最容易落地的三个方向
返回列表
相关资讯
2026-07-18 你给AI喂的"企业记忆"，可能全是假的2026-07-17 RAG 怎么评估呢？RAG 评估体系5 个指标让你的知识库从「盲飞」到「可量化」2026-07-17 RAG 工程里的上下文剪枝：如何减少 68% 的上下文2026-07-15 RAG 最难的不是向量库，而是知识链路2026-07-14 别再手调 RAG 了，让 Loop 自己找配置2026-07-14 9.7k Stars，阿里内部跑了几年的向量数据库开源了，不用起服务，import 就能用2026-07-13 AI知识库从零到一：个人wiki+企业RAG方案2026-07-10 千万文档级 RAG 如何逼近零幻觉
联系获取
联系获取
160+中大型企业正在使用53AI
[立即咨询](javascript:void(0))[预约演示](javascript:void(0))
把握AI发展的机遇，共同探索、共同进步 2025-01-22如何打造基于GenAI的员工服务机器人 2025-01-22
