RAG分块大小怎么定?召回质量实测对比

先把结论甩出来:大部分中文文档场景,chunk 控制在300-500 字、overlap 给 50-80 字,召回质量最稳。太小了语义碎、太大了噪声多,两头都不讨好。下面是我用同一份知识库跑出来的对比数据,场景不一样结论会偏,但这个区间能少踩一半坑。起因:客服机器人答非所问上个月帮公司搭了个内部客服答疑的小助手,把三百多页的产品手册 一堆历史工单灌进去做 RAG。第一版我图省事,直接按 1000 字硬切。结果上线那天就翻车——同事问退款多久到账,检索回来的 chunk 里塞了退款政策、发票说明、还有半段无关的物流条款,大模型被一堆杂信息带跑,回了句正确但绕的废话。我盯着召回出来的片段看了半天,反应过来:块太大,一个 chunk 里混了好几个主题,向量被平均掉了,语义反而模糊。于是我把分块大小当成变量,老老实实跑了组对比。实测:同一份知识库,只改 chunk 大小测试集是我手攒的 50 条真实问题(同事问过的),embedding 用的 bge-large-zh,检索 top-5,人工标注每条命中没有。指标看两个:Recall5(答案片段有没有被捞回来)和答案相关性(把召回片段喂给大模型后,回答靠不靠谱,1-5 分人打)。chunk 大小overlapRecall5答案相关性(1-5)我的体感128 字00.713.2片段太碎,一句话被切两半,上下文丢了256 字300.843.9短问答还行,稍长的逻辑就断384 字600.924.4综合最好,语义完整又不啰嗦512 字800.904.3跟 384 差不多,长段落略占优1024 字00.783.1噪声多,主题串味,就是第一版翻车的配置看表就明白了。128 字那行 Recall 不算最低,但答案相关性掉得厉害——能捞回相关片段,可片段本身缺头少尾,大模型拿到半句话也救不回来。1024 字那行更典型,Recall 和相关性双低,一个块装太多东西,检索精度和生成质量一起拉胯。384 和 512 这俩其实咬得很死,差距在统计噪声范围内。我后来的取法是:FAQ、短问答类的偏 384;手册、长流程、合同条款这种本身段落就长的,给到 512 甚至 600,免得把一个完整步骤拦腰切断。一个反直觉的点:overlap 不是越大越好我一开始以为 overlap 给越多越保险,试了把 384 配 150 字 overlap,Recall 没怎么涨,索引量倒是膨胀了快四成,检索还慢了一点。后来 overlap 压回 60 左右就够用了——目的只是别让句子在边界处被切断,不是真要重复一大段。落地这套配置时偷的懒调参折腾了大概两个下午。真正让我没在工程上再耗时间的,是我没自己写切分、建索引、串检索那套管线。我用了个拖一拖配一配、不用写代码就能搭智能体的平台,把手册传上去挂成私有知识库,chunk 大小和 overlap 直接在配置面板里填数,改一版重建一次索引点一下就行。我那两个下午基本全花在看召回片段、标注对错上,没碰底层代码。说句实话,这玩意儿也不是万能。那个小助手第一版回答特别干,像背条款,我又额外配了几句人设提示词才像个人。而且它擅长的是把检索、调模型、发布这些杂活包圆,真正决定效果好坏的还是你喂进去的知识库质量和这个 chunk 参数——切不好,平台再顺也白搭。(模型这块我直接走的讯飞星辰MaaS,现成大模型 API 调用,没自己部署算力,省了一摊运维。)最后留个问题:你们的文档要是那种带大量表格、代码块的技术文档,按字数切肯定会把表格切烂,这种结构化内容你们是怎么分块的?我现在用的是按 Markdown 标题层级切,但表格还是偶尔会断,评论区聊聊你们的招。