best model for rag

做 RAG 的人常卡在同一个地方：检索链路搭完了，模型换一个效果就变，可到底该按什么标准挑，谁也说不清。榜单看的是通用能力，你的语料、你的问法它一个都没覆盖。这篇不讲原理，只给一套能落地的挑法：两类模型分别看哪几个维度、评测集怎么攒、结果怎么读、什么情况下该换回小模型或本地部署。

做 RAG 的人常卡在同一个地方：检索链路搭完了，模型换一个效果就变，可到底该按什么标准挑，谁也说不清。榜单看的是通用能力，你的语料、你的问法它一个都没覆盖。这篇不讲原理，只给一套能落地的挑法。

两类模型分别看哪几个维度、评测集怎么攒、结果怎么读、什么情况下该换回小模型或本地部署，下面按这个顺序讲。先记住一件事：RAG 里有两个模型，它们的职责完全不同，别用一个标准去挑。

RAG 里有两个模型，别混着挑

生成模型负责把召回片段读成答案，看的是长上下文里抓重点、按格式答、不硬编；向量模型负责把语料和问题映射到同一空间，看的是中文语义、专有名词、长片段截断后的表现。这两件事的失败模式不一样，评测方法自然也不一样。

最典型的误判是：召回明明没把正确段落捞回来，却怪生成模型答得不好，于是去换更大的模型。召回没上来，换多大的生成模型都是在读错材料，答案只会更流畅地跑偏。反过来，向量模型再好，生成模型不会看长材料也白搭。

• 生成模型重点看长上下文里抓重点、按指定格式输出、材料里没有时会不会硬编
• 向量模型重点看中文语义、专有名词和缩写、长片段被截断后的表现
• 具体有哪些可选，去 /embeddings 和 /models 看当时的清单，别记死型号
• 两类模型的选型顺序是先向量后生成：召回不对，生成模型再强也没用

先攒一套自己的评测集，再谈选哪个

不管候选模型有多少，你都得先有一把自己的尺子。通用榜单上那些题，你的语料一道都没覆盖。评测集不用大，三五十条就够跑出趋势，关键是它得来自你的真实场景。

1. 抽题从真实提问里抽 30 到 50 条，覆盖三类：能直接在文档里找到答案的、需要跨两三个片段拼的、文档里根本没有的。第三类专门看它会不会瞎编。
2. 标注每条标出正确答案所在的那一段。向量模型的评测就靠这个判断召回对不对，没有标注就只能凭感觉。
3. 换成口语别只写书面语问题，把同事平时在群里怎么问的原话抄进去。口语提问才是真实分布，书面语测出来的结果会偏乐观。
4. 记版本把切分方式、模型名称、检索参数都记下来。换了其中任何一样，都用同一套题重跑，否则改动前后没法比。

同一批题跑几组组合，结果怎么读

评测最容易犯的错是同时换两样东西，最后不知道效果变化是谁带来的。正确做法是控制变量：固定检索参数只换生成模型跑一轮，再固定生成模型只换向量模型跑一轮，两组分开看。

看结果时关注三件事：召回命中率、答案有没有超出材料的编造、以及单次问答的延迟和消耗。命中率没有明显差别时，优先选便宜、快、上下文够长的那个，别为了榜单上的一点差距多花钱。

• 固定检索参数，只换生成模型跑一轮，记录答案质量
• 固定生成模型，只换向量模型跑一轮，记录召回命中率
• 单独统计编造率：材料里没有的内容被写进答案的比例
• 把延迟和消耗一起记下来，效果差不多的选开销低的
• 评测口径参考 /benchmarks 与 /tools/quality-check，保持一致才好纵向对比

如果几组结果咬得很紧、看不出差别，说明你的评测集还不够难，或者这个问题在当前语料上本来就不敏感。这时候别硬选，先回去补几道跨片段、带专有名词的难题。各家模型的实际开销和额度，到 /price-watch 核对当时的数字。

这些情况下，换模型不是第一选择

换模型是最容易想到的动作，但不是每次都该做。下面几种情况，先查别的地方，往往比换模型有效得多。

还有一类情况是问题本身太模糊：用户问得笼统，任何模型都答不好。这时候该做的是把问题引导清楚，而不是换模型。判断标准很简单：把召回片段人工读一遍，如果你自己都拼不出答案，那问题不在模型。

上线前过一遍这张清单

选完模型不等于结束，上线前还得把可观测和降级准备好。RAG 是个多环节链路，出问题时你得能定位到是哪一环变了。

1. 记版本评测集、切分策略、模型名称都记版本，改一处能定位到是哪一步变了。
2. 设超时与重试给生成调用设超时和重试，模型服务抖动时不要让整个问答卡死；换算口径见 /tools 里的工具。
3. 准备降级路径主模型不可用时切到备选，宁可答案朴素一点，也别整个功能打不开。
4. 记日志把每次问答的召回片段、模型名、耗时记进日志，出问题时才有东西可复盘。