本地 RAG 答不准，先别换模型：按这 7 条排一遍 · Skills

「我把文档喂进去了，但它还是答不准」——这是本地知识库最常见的抱怨。我的经验是：先别急着换更大的模型，按下面七条从上往下排一遍，通常前三条就能解决大半问题。

1. 先看检索到了什么，而不是模型答了什么

RAG 出错，绝大多数是没搜到，不是搜到了不会答。先把检索结果单独打出来看一眼：用户问「差旅报销标准」，检索回来的三块内容里有没有那段条款？

如果没搜到，后面换什么模型都没用。这一步省掉，后面全是瞎猜。

固定 500 字一切是最省事、也最容易出问题的做法：一个条款被从中间劈开，两半各自都答不上问题。

更稳的做法：先按标题层级分块，块太长再按句子二次切，相邻块之间留 10%~15% 的重叠。中文文档尤其要注意——PDF 转出来的文本经常有奇怪的换行，先做一次清洗再切，不然「报销」和「标准」会分到两行、被当成两个词。

这是中文场景最常踩的坑。很多默认配置用的是英文小模型，中文句子进去得到的是一堆接近随机的向量，检索等于乱搜。

换成多语言模型（bge-m3、gte-multilingual 这一类）之后，效果往往是「从完全不能用到能用」的差别，比调任何参数都大。改完记得重建索引——换 embedding 模型不重建，等于白换。

向量检索擅长语义相近，但对「合同编号 HD-2026-0417」这种精确串几乎无能为力——它会给你一堆语义相似但编号不对的片段。

把向量检索和关键词检索（BM25）的结果合并，是性价比最高的一次升级。大多数向量库都支持，配置成本十分钟。

混合检索召回 20 条，再让重排模型（reranker）给这 20 条按相关性重新排序，只把前 3 条喂给模型。召回要广、精排要准，这两件事用同一个模型做是勉强的。

这一步的收益很实在：上下文更短、更准，模型答错的概率和 token 成本一起降。

要求模型每句话都标注来自哪个片段，并在界面上显示来源。这不只是为了可信——引用是最省事的质检手段。答案一错，你一眼就能看出是检索错了还是模型编的。

同时给一条逃生通道：检索不到就直说「没找到」，不要让模型硬答。硬答的语气和真答一样自信，这才是知识库最危险的地方。

最后也是最重要的一条：准备 20 条「我知道正确答案是什么」的问题，覆盖你真实的提问类型。每次改配置就跑一遍，记录命中率。

没有这个，你所有的调优都是凭感觉——调完觉得变好了，可能只是因为你连着问了三道恰好能答的题。有了它，改动是好是坏十分钟内见分晓，也才谈得上持续优化。

做完上面七条还是不行，再考虑换。而且先换大的重排模型或embedding 模型往往比换生成模型更划算——生成模型只负责把找到的内容说清楚，它背不了检索的锅。