RAG 怎么评估？凭感觉调是调不出来的
数据截至 2026-07，价格与限额以各官网为准。
RAG 系统调不好，八成不是因为你选错了框架或者向量库，而是因为你根本没有一把尺子——改了分块大小、换了嵌入模型、加了重排之后，你说不清效果到底是变好了还是只是这次运气好。没有可复现的评估集和固定指标，所有调优都是在赌博。
先承认一个几乎人人都有的误解：很多团队觉得”评估”是大厂才需要的工程奢侈品，自己项目小，人工试十来个问题看看回答顺不顺眼就够了。这个想法在 demo 阶段确实成立，但它撑不到上线后第二个月。原因很实在——人工试问题这件事，问题集本身在漂。你今天想到的十个问题和上周不是同一批，你看回答时的心情、期待、耐心也不一样。于是就出现了最典型的困境：改了参数，感觉好像好了一点，但没人敢下结论；回滚了，又觉得好像也没差。团队开始用”体感”吵架，谁嗓门大谁的方案赢。
这篇讲怎么把这把尺子造出来，以及诚实地说清楚这把尺子有多准。如果你还不清楚 RAG 的基本流程，建议先看RAG 是什么。
一、先把错误拆开：是检索错了还是生成错了
评估 RAG 最关键的一步认知，是别把它当成一个黑盒去打分。RAG 至少有两段可以出错，而这两段的修法完全不同：
- 检索段错了：该找的材料压根没被找回来，或者找回来一堆不相关的段落。这时候不管你换多贵的生成模型都救不回来——模型手里没有正确答案的原料。
- 生成段错了：材料明明就在上下文里，模型却答偏了、编了、或者只回答了问题的一半。这时候优化检索毫无意义。
现实中大量的调优时间浪费，就是因为把这两段混在一起看。用户反馈”回答不准”，团队第一反应是换个更强的模型，跑了两周发现没改善，回头一查才发现是文档解析阶段就把表格搞乱了，检索回来的片段本身就是垃圾。
可操作的做法：拿到一条坏 case，先别看回答，先把这次检索出来的原始片段打印出来自己读一遍。问自己一个问题——**如果我是模型，只拿这几段材料，我能答对吗？**能，那是生成段的问题；不能，那是检索段的问题。这个动作花不了两分钟，但能省掉几天的方向性浪费。把这个判断固化成日志，每次问答都记下检索到的片段 ID 和最终回答，坏 case 就能自动归因。
二、评估集从哪来：从三十条真实问题开始
很多人卡在第一步，觉得建评估集是个大工程，需要标注团队。其实起步远比想象中轻。
最好的问题来源是真实用户已经问过的问题，不是你自己编的。如果系统还没上线，就去翻客服工单、内部群聊记录、售前答疑文档，那里堆着大量真问题。编出来的问题有个通病——它们都太”标准”了，措辞规整、意图清晰，而真实用户会打错字、会一次问两件事、会用只有他们公司才懂的黑话。用编的问题评出来的高分，上线后会被现实打脸。
起步阶段建议这么攒：
- 规模：三十到五十条就能开始跑出有意义的对比，不用等到几百条才动手。样本少的时候，指标波动会大一些，但足以发现”这次改动明显把某类问题搞坏了”这种量级的信号。
- 构成：刻意混进几类难题——需要跨多篇文档才能回答的、答案在表格或扫描件里的、知识库里根本没有答案的（考模型会不会硬编）、以及问法很口语化的。全是简单题的评估集，分数好看但没有诊断价值。
- 标注：每条问题至少记两样东西——期望答案要点（不用写成完整段落，列出必须命中的几个事实点即可）和该被检索到的文档来源。后者常被省略，但它正是拆分检索段/生成段错误的依据。
- 冻结：评估集一旦定下来就别随手改。要加新问题就新开一版并记录版本号，否则你会陷入”分数涨了但其实是题变简单了”的自欺。
三、该看哪四类维度
指标不必多，起步阶段盯住下面四类维度就够用了。这四类正好对应上一节说的两段拆分——前两类查生成，后两类查检索：
- 答案是否忠于检索到的材料。也就是回答里的每个断言，能不能在检索回来的片段中找到依据。这一项直接对应”模型有没有编”。分数低通常意味着提示词没有约束住模型，或者检索材料太少导致模型自己补齐。
- 答案是否真的回答了问题。忠实不等于有用——模型可以完全照抄材料，但答的是另一件事，或者绕了半天没给结论。这一项查的是相关性。
- 检索回来的片段中有多少是真正有用的。如果每次召回十段但只有一段相关，那就是在给模型灌噪声，既费 token 又容易带偏。
- 该被找到的材料有没有被找回来。这一项要用到你在评估集里标注的”应命中来源”。它是最容易被忽略、但对最终效果影响最大的一项——漏召回是无声的失败，你从回答上看不出来，只会觉得”模型好像不知道这事”。
这四类维度在不同评估工具里的命名和计算方式不完全一样，具体指标名与实现细节以你所用工具的官方文档当前版本为准，这篇不逐字复述。真正重要的是理解它们各自在诊断什么：看到某一项掉下去，你应该知道去改哪一段。
另外提醒一句，别一上来就追求绝对分数。RAG 评估的价值主要在纵向对比——同一套评估集、同一套指标，改动前后跑两遍看差值。至于”忠实度 0.82 算不算高”，跨项目之间几乎没有可比性，取决于你的语料难度和评估集构成。
四、评估工具怎么加挂到现有框架上
好消息是，评估这件事不需要你换框架。按瓶颈选型的思路里有一条很明确：如果你的瓶颈在评估，做法是在已有框架上加挂 RAGAS，而不是推倒重来去选一个”评估更好”的框架。
这一点值得展开说，因为它和很多人的直觉相反。框架选型的讨论里，大家习惯把 LangChain、LlamaIndex、RAGFlow、Haystack 摆在一起排名次，但这几个框架的差异主要落在别的地方——LangChain 和 LlamaIndex 的分工是生态广度与数据索引深度之别，RAGFlow 的差异化在版面感知的文档解析。评估是一层横切能力，它不该绑死在某个框架上。
落地时的建议顺序：
- 先把问答链路的中间产物暴露出来。评估工具需要拿到四样东西：问题、检索到的上下文片段、模型的最终回答、以及你标注的参考答案。如果你的代码里检索结果是藏在链路内部的局部变量，第一步就是把它返回出来或记进日志。这一步的改造量通常比接评估工具本身还大。
- 离线跑，别接生产流量。评估过程本身要调用大模型打分，成本和延迟都不适合放在用户请求链路里。做成一个独立脚本，读评估集、跑一遍、输出一张表。
- 把结果落成文件并纳入版本管理。每次跑完存一份带时间戳和参数快照的结果（分块大小、嵌入模型、top-k、重排开关等）。三个月后你会非常感谢这个习惯——它能回答”我们当初为什么把分块调成现在这个大小”这种没人记得住的问题。
- 接进 CI 或者定期任务。哪怕只是每周手动跑一次，也比改一次跑一次强，因为定期跑能发现”没改代码但分数掉了”的情况（比如底层模型悄悄升级、知识库被人塞进了脏数据）。
五、评估会顺带暴露的架构问题
跑起评估之后，你大概率会发现一些原本以为不存在的问题。这些发现本身就是评估最大的回报。
分块策略的锅比想象中大。当”该被找回的材料没被找回”这项分数低，很多人第一反应是换嵌入模型，但更常见的原因是分块把一个完整语义切断了——表格的表头和数据行被切进不同块，或者一段定义的前半句在上一块。语料如果是扫描版 PDF、财报、版式复杂的法律文书这类传统文本解析器搞不定的东西，问题往往从解析这一步就开始了，这时候该动的是解析和分块，不是检索参数。
噪声召回比漏召回更隐蔽。检索精度那一项分数低时，系统表面上还能用，只是回答开始变得啰嗦、偶尔跑题。调小 top-k 或者加一层重排常常立竿见影，但前提是你得先从指标上看到它。
向量库的选择通常不是瓶颈。检索延迟和召回质量是两件事——有第三方评测称 Qdrant 在 100 万以上向量规模下可以做到 50 毫秒以内的检索，这是第三方口径而非官方指标，但它至少说明主流向量库在常见数据规模下速度不是问题。如果你的评估分数不好，先别急着换库，向量数据库选型影响的更多是运维成本和扩展路径。
延迟也该纳入评估表。同样有第三方基准提到，LangChain 的 LCEL 语法能做复杂的查询重写，但相比 LlamaIndex 的直接检索会多出约 15% 到 20% 的延迟开销——这同样是第三方基准口径，不是官方数据，具体表现以你自己的链路实测为准。重点在于思路：查询重写、多路召回、重排这些手段都会加分也都会加延迟，评估表里如果只有质量列没有耗时列，你会不知不觉把系统调成一个又准又慢的东西。
六、诚实说局限：这把尺子有多准
必须把话说清楚，否则你会对评估结果产生过度信任。
第一，大部分自动指标是用大模型当裁判的。这意味着裁判本身会波动、会有偏好（比如偏爱更长更完整的回答），也会犯错。同一批数据跑两遍分数可能就有小幅差异。应对办法是：固定裁判模型和温度参数，关注差值而不是绝对值，差异很小的时候不要下结论。
第二，评估集永远覆盖不全。三十条问题跑出来的高分，不代表第三十一个用户问的那个刁钻问题也能答好。评估集要持续从线上真实失败案例里补充，把每一次用户投诉都变成一条新样本，这是它唯一的成长方式。
第三，指标好不等于用户满意。用户还在意语气、格式、有没有给出处、要不要在不确定时说”我不知道”。这些通常得靠人工抽查补上。合理的分工是：自动指标扫全量、抓回归，人工抽查看体验、定标准。
第四，评估本身有成本。每跑一次全量评估都要消耗不少 token 调用。评估集别一开始就攒到几百条，也别每次改个提示词就跑全量——可以先跑一个二十条的快速子集做筛选，确定方向有效再跑全量确认。
七、常见坑
- 改多个变量再跑评估：同时改了分块、嵌入模型和 top-k，分数涨了也不知道是谁的功劳。一次只动一个。
- 评估集里混进了知识库的原句：有些人直接从文档里摘句子当问题，这类问题嵌入相似度天然极高，检索几乎必中，分数虚高得离谱。
- 忘了留”知识库里没有答案”的问题：不考这一类，你就永远不知道系统会不会在没有依据时硬编。
- 只在开发环境跑：知识库内容会变，开发环境的索引往往是几个月前的快照，评出来的结论未必适用于线上。
- 把评估当一次性任务：跑一轮出了报告就归档，三个月后没人记得怎么复现。评估的价值来自持续跑。
- 误以为换框架能解决评估问题：框架的关注度差距很大——按第三方统计，截至 2026 年 1 月，GitHub 上 LangChain 约 12.5 万 star，LlamaIndex 约 4.65 万，但 star 只反映关注度，不代表在你的语料和场景上效果更好，更不代表它自带一把适合你的尺子。生产上常见的组合本来就是混着用（比如 LlamaIndex 做 ingestion 与索引、LangChain 做编排、LangGraph 做 agent 工作流），评估层加挂在上面就行。框架选型的完整思路见RAG 框架怎么选。
小结
RAG 调优的门槛不在技术难度，在于你有没有一把不会漂的尺子。先把错误拆成检索段和生成段，再从三十条真实问题起步建一个冻结的评估集，盯住忠实度、答案相关性、检索精度、检索召回这四类维度做纵向对比。评估是横切能力，不需要换框架，在现有链路上加挂 RAGAS 这类工具即可，改造重点是先把检索中间结果暴露出来。同时要清醒：大模型当裁判会波动、评估集覆盖不全、指标好不等于用户满意，自动指标扫全量、人工抽查看体验，两者缺一不可。一句话——不追求评估体系一步到位，但一定要有，从今天跑第一轮基线开始。