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