大模型RAG能力对比：检索效果、生成质量与成本怎么统一看
大模型RAG能力对比，不能只把几个模型接上同一个知识库跑几条问题就下结论。
检索增强生成（RAG，先检索资料再让模型回答）的效果由检索和生成两段共同决定，对比时必须先固定语料、切分方式和评估标准，否则数字没有可比性。
先拆开看：RAG能力由哪几段决定
一个RAG系统通常分三步：文档切分和向量化、按问题检索相关片段、把片段交给大模型生成答案。
对比不同模型时，最容易犯的错是把检索差异算到生成模型头上。
可以用一个简单判断：如果同一个问题换模型后，检索到的片段完全一样，但答案质量不同，差异在生成端；
如果检索片段本身就不一样，先查切分长度、向量模型和相似度阈值，不要急着换大模型。
检索端看两个指标：召回率，即标准答案所在的片段有没有被检索出来；
排序质量，即正确片段是否排在前面。
生成端看忠实度，即答案是否只依据检索片段，不额外编造。
对比前要固定的测试条件
要让大模型RAG能力对比有参考价值，至少固定下面几项：
- 测试语料：同一批文档、同一版本，避免一边用产品手册一边用网页抓取内容。
- 切分参数：块大小和重叠长度保持一致，例如统一用
chunk_size=500、chunk_overlap=50，否则检索粒度不同。 - 向量模型：对比生成模型时不要同时更换嵌入模型，否则召回差异无法归因。
- 提示词模板：要求模型“仅根据以下片段回答，找不到就说不知道”，所有模型用同一份。
- 测试题集：覆盖事实查找、多片段归纳、无答案拒答三类问题，每类至少十几条。
如果条件允许，把检索结果和最终答案分开保存。
这样出现问题时能快速判断是“没检索到”还是“检索到了但答错”。
一套可执行的对比流程
第一步，准备标准答案。
为每道测试题标注答案所在文档和片段编号，以及预期答案要点。
没有标准答案的题只能做主观对比，不适合算召回率。
第二步，只跑检索。
用同一套切分和向量模型，记录每个问题返回的前K个片段，例如 top_k=5。
计算正确片段是否出现在前5条中，得到召回率。
第三步，固定检索结果跑生成。
把同一批检索片段分别交给不同大模型，要求按统一格式输出答案。
记录答案是否包含标准要点、是否出现片段之外的信息。
第四步，记录成本和延迟。
统计每道题的平均输入token、输出token和响应时间。
RAG的输入通常包含多个片段，长上下文模型的成本差异会被放大，不能只看单价。
第五步，汇总判断。
可以按下面的条件做取舍：
- 召回率低但生成忠实度高：优先优化切分、向量模型或增加
top_k，而不是换生成模型。 - 召回率高但答案经常编造：检查提示词约束，再对比生成模型的忠实度。
- 两者都合格但成本超预算：考虑减小片段数量、压缩上下文或换更小的生成模型。
常见误区与边界
只看模型榜单的RAG分数。
公开榜单的语料和切分方式与你的业务不同，分数高不代表在你的文档上召回好。
用同一组问题反复调参后再对比。
调参用的题和最终评估的题要分开，否则结果偏乐观。
忽略无答案问题。
RAG系统能不能在资料不足时明确说“不知道”，比答对多少题更能反映可靠性。
对比时至少保留一部分知识库中不存在答案的问题。
把延迟全部归给大模型。
检索、重排序和网络请求都会占时间，对比生成模型时应只统计模型调用段。
验证对比结果是否可信
做完对比后，抽查一批答案，确认每条答案都能在检索片段中找到依据。
如果答案正确但依据片段不对，说明评估标准可能过松。
还可以把同一批测试题隔一段时间重跑一次，观察结果是否稳定；
波动过大时，先检查检索是否受文档更新或索引状态影响。
大模型RAG能力对比的结论应该写成条件式：在什么语料、什么切分、什么提示词下，哪个模型在召回、忠实度和成本上更合适。
脱离这些条件直接说某个模型RAG能力更强，参考价值有限。
