先给结论RAG 答不准七成问题出在分块上不在模型。我前后调了三周一个客服知识库召回准确率从六成多爬到九成,真正动效果的就两件事——chunk 切多大和切的边界在哪。我一开始切错在哪第一版我图省事按固定 500 字硬切不管语义切到哪算哪。结果一段安装步骤被从第 3 步中间劈成两块用户问装到一半报错怎么办召回回来的那一块只有第 4、5 步前因全丢了模型只能瞎接。换成 1000 字大块召回是全了但又出新毛病一块里塞了三个不相关的小标题向量被稀释成一锅平均味问得很具体时反而召不回来——因为这块的向量谁都不像。我后来定的几条按结构切别按字数切。先用标题、空行、列表项这些天然边界断开再在大段落里按字数兜底。这一步对带小标题的文档收益最大。chunk 控制在 300–500 字。我这套问答类知识库400 字左右最稳纯条款类合同、政策可以小到 200一条一块。重叠留 50–100 字。相邻块头尾叠一点防止答案正好卡在切口上。代价是索引体积涨了约两成但召回断头的情况基本没了。一个反直觉的坑我以为块越小越精准于是切到 150 字试了一版结果更差。块太碎单块信息量不够召回回来五六块拼在一起模型还得自己重组逻辑反而更容易拼错。后来才明白块大小要跟你一个问题通常需要多少上下文对齐不是越小越好。还有个脏细节中文别用按 token 的英文分块器默认参数它对中文标点不敏感我有一批 FAQ 被切在了顿号中间售前、售后、退换被劈成售前、售和后、退换离谱。换成对中文友好的分隔符列表才好。取舍调分块是个体力活没有一套参数通吃所有文档。我现在的做法是新接一个知识库先抽 20 条真实问题做召回测试看召回片段是不是真包含答案再回头调块大小。比盲调省事得多。平台层面我用的是一个能直接配 RAG 知识库的智能体工具分块策略它给了几档预设省得我自己写切分脚本但参数还得自己按文档调。底层模型我挂讯飞 MaaS调现成 embedding 和对话 API没自建算力省下来的精力都花在调分块上了。
