企业官网建设流程全解析

做 RAG 不评测，等于闭着眼睛调参：一份从原理到落地的完整测评指南

先说个直白的场景：本地把 RAG 跑通了，Demo 演示效果惊艳，一问一个准。结果换到真实业务数据上，用户随便问了几个刁钻问题，回答就开始答非所问、自说自话，甚至把不存在的文档内容“脑补”得栩栩如生。这时候你翻开日志，检索召回率看着还行，生成结果却完全跑偏——问题出在哪，根本说不清楚。

这就是典型的“没做评测”的后果。RAG 系统不是一个单点模型，它是“检索器 + 生成器 + 数据管道”的组合系统，每一个环节都可能出问题。你改一个 chunk 切分参数，线上表现好了还是坏了，如果没有量化指标，全靠肉眼观察和用户反馈，那基本等于闭着眼睛调参。这篇内容我就把 RAG 评测这件事从头到尾讲清楚：评什么、怎么评、用什么工具、怎么让评测结果真正指导迭代。

1. 为什么 RAG 必须走评测这条路

做 RAG 的人有一个共识：跑通容易，跑好极难。这背后的本质原因是 RAG 系统的“不确定链条”太长了，出问题的环节多到超出想象。文档解析可能丢内容，切片可能把语义切碎，向量化模型可能和业务领域不匹配，检索召回可能把正确答案排到第 5 位，生成模型可能根本不参考检索到的上下文，直接凭“记忆”发挥。

这些环节里的每一个，都需要一个客观量化指标来评估它的状态。评测的意义不是走形式，而是把系统从一个“感觉还行”的黑盒，变成“各部分指标清晰可见”的白盒。

我见过最典型的反面案例：某个团队花了两周调 Embedding 模型和切片大小，每次改完手工拿十几个问题去试，感觉“好像好了一点”，就继续往下走。结果一个月后复盘，发现检索召回率其实一直没提升，真正改善的是生成模型的提示词写得更详细了。评测缺失导致他们的优化方向完全跑偏，白白浪费了大量时间。

评测还有一层更实际的作用：回归保护。RAG 系统是会“退化”的。你今天升级了 Embedding 模型，明天换了生成模型，后天调整了数据预处理逻辑，任何一步都可能让原本正常的问答能力集体失灵。没有评测基线，你根本发现不了这种退化；有了自动评测，跑一遍评估集，所有分数变化一目了然。

所以评测的对象不只是“最终回答质量”，而是 RAG 链路上每一个可量化的节点。理想情况下，评测应该拆分成检索环节、生成环节、端到端三个层面，各评各的，再把结果串起来分析。这样才能准确定位问题：是没找到，还是找到了没用上，还是用上了但没答对。

2. 检索环节怎么评：召回率、命中率与排序质量

2.1 检索评测的三个核心指标

先解决一个问题：怎么判断检索器找回来的内容到底好不好。最理想的状态当然是“正确答案相关的内容全部排在最前面”，但现实往往不会这么完美。常用的指标是 Recall@K、Hit Rate@K 和 MRR（Mean Reciprocal Rank）。

Recall@K 看的是“前 K 条结果里包含了多少比例的相关内容”。举个例子，一个业务问题对应文档中有 3 段关键内容，你的检索器返回前 5 条结果，其中包含 2 段关键内容，那 Recall@5 就是 2/3，约 66.7%。这个指标反映的是检索器的“查全能力”——相关的东西有没有漏掉。

Hit Rate@K 更简单，它只关心“前 K 条结果里，至少包含一条相关内容就算命中”。比如测试集有 100 个问题，前 3 条结果里有相关内容的占 72 个，Hit Rate@3 就是 72%。它不关心召回了多少，只关心“至少找到了一条”。

MRR 则考虑排序位置。如果正确答案排在第一，记 1 分；排在第二，记 1/2；排在第三，记 1/3。取所有查询的平均值。这个指标惩罚“找到了但排太后”的情况，适合对排序质量敏感的检索场景。

三个指标各有侧重，建议同时使用。实际测试中经常会发现一个现象：Hit Rate 很高但 MRR 很低，说明检索器“能找到东西但排序不对”，这时候应该优先优化重排序（Rerank）策略，而不是换 Embedding 模型。

2.2 构建检索评测集

评测集的质量决定了指标的可信度。构造检索评测集有一个常见的误区：直接在已有问答对里，把“问题 + 标准答案对应的文档片段”当作正例。这样做有个问题——标准答案对应的内容不一定是检索器应该找到的内容，尤其当答案经过摘要或推理时。

更合理的做法是：对于每个测试问题，人工标注 2～3 段“支持该问题回答的文档片段”。如果业务数据量大，可以做抽样标注；如果做了人工标注，至少要保证标注标准统一，避免一个人标得宽、一个人标得窄。

正例之外，负例同样重要。现代检索评测还建议加入“无答案问题”集合。设计一批故意超出知识库范围的问题，检索器正确的行为应该是“召回率极低”，从而触发系统的拒答逻辑。如果这些问题也能召回一堆不相关内容，说明检索器的阈值设置有问题。这个集合在真实业务中价值很大——可以大幅减少系统瞎编的概率。

2.3 切分粒度对检索评测的干扰

有个隐蔽的坑会在评测中反复出现：查询问题的标准答案涉及一段话中连续的几个句子，你按 200 字切块，这段内容恰好横跨两个块，于是正确答案的语义被切成了两半。这时候检索器不是“没找到”，而是“内容根本没被完整保存下来”。

这就是为什么检索评测分数异常波动时，第一件事不是怀疑模型，而是先检查切分策略。常见的缓解方案是“重叠切分”——相邻切片之间保留一定重叠字符，确保跨边界的内容至少在一整块中出现。但重叠会带来新的问题：召回结果冗余、去重困难。实测下来，重叠率在 10%～15% 之间是比较合理的起点，具体要结合文档类型和句子长度微调。

3. 生成环节怎么评：忠实性、相关性与完整性

检索评测只是前半场。真正决定用户体感的是“生成环节”——模型拿到检索结果之后，能不能给出一个靠谱的回答。这里最容易出现一个让你头疼的问题：检索结果明明有正确答案，生成模型却绕开它，自己发挥了一通原创内容。这就是典型的“忠实性”问题。

3.1 三个生成维度的定义与判断逻辑

评估生成回答，我建议从三个维度切入：忠实性（Faithfulness）、答案相关性（Answer Relevance）、上下文相关性（Context Relevance）。

忠实性判断的是“回答内容是否基于检索到的上下文”，有没有无中生有。判断逻辑很简单：把回答里的每一条事实陈述，逐条去上下文中找依据。有依据，算忠实；没依据，算不忠实。这是 RAG 评测里最重要的一环，也是防止“幻觉”扩散的关键防线。

答案相关性看的是“回答到底有没有解决用户的问题”。有些回答内容完全正确、来得有依据，但答非所问——用户问的是方案对比，它给你整个方案的背景介绍。相关性上就是低分。

上下文相关性单独针对检索结果评估：检索到的内容跟问题是否相关。这一步其实在检索评测里就有涉及，但在生成环节再评一次的意义在于——生成模型如果拿到了不相关上下文，很可能被误导，所以我们要清楚到底是因为检索不行，还是因为生成模型不会利用。

这三个维度之间有内在优先级：如果上下文不相关，那忠实性和答案相关性大概率都崩；如果上下文相关但回答不忠实，那是生成模型的问题；如果回答忠实但用户觉得没用，那是相关性没做好。评测结果出来之后，先看这三个维度的组合模式，基本就能定位到问题出在哪个环节。

3.2 无金标准时的评估方案：LLM 打分与规则校验

严格意义上，生成质量最准确的评估方式是人工打分，但成本太高——需要多个标注者、统一的标准尺度和大量的时间。现实工程中，绝大多数团队采用“LLM 打分 + 规则校验”的半自动方案。

LLM 打分的基本思路是：把“问题、检索到的上下文、生成回答”一起丢给一个评估模型，让评估模型按指定维度打分。同时候跑一些硬性规则校验，比如生成回答是否超过了上下文长度、是否输出了一大段跟问题无关的模板化内容、是否把“不知道”三个字写成了长篇大论。规则校验负责抓明显的结构性问题，LLM 打分负责评估语义层面的质量。

一个值得注意的细节：评估模型的选型会影响分数。同一个回答，用某个模型打分可能给 8 分，换一个模型可能只给 6 分。这不是评估模型有问题，而是不同模型的判断偏好不同。我的实际建议是：评估模型可以不强求用最大最强的型号，但必须在你的业务场景上先做一次“评估一致性测试”——拿 50 条结果，让评估模型打分，再人工复核打分是否合理。如果一致性低于 80%，说明评估维度定义还不对，需要重新写打分提示词。

3.3 LLM 评估者的常见偏见

在这几年的踩坑经验里，有个现象很普遍：评估模型在面对“回答很流畅、很自信但有事实错误”的内容时，容易给高分。原因在于很多 LLM 打分器天然偏好“流利、结构完整”的文本，对事实错误不够敏感，尤其是当错误很细微、融入在长段落中时。

解决方案有两类。第一类：在让 LLM 打分之前，先让它完成一个独立的“事实抽取与核对”任务，把回答拆成事实点，逐条标记“支持/不支持/未提及”，再根据标记比例计算忠实性分数。第二类：在评分提示词里明确要求“忽略风格，聚焦事实正确性”，并给几个低分示例。实测下来，前者更稳，但耗时更长；后者实现成本低，但对边界情况的处理不如前者精细。

还有一类狡猾的错误是“上下文有相关内容，但生成模型把它用错了场景”。比如上下文里有一句话提到“A 方案在低延迟场景下表现较好”，生成模型却直接回答“A 方案表现较好”，把限定条件丢了。这种错误人工容易发现，但 LLM 打分器有时会漏掉。我做生成评测时，会额外加一条“条件保持”检查——把上下文中的限定词、前提条件提取出来，检验回答是否完整保留。这个细节在技术文档类知识库里尤其重要。

4. 端到端评测：整体视角下的综合分与拒答策略

单独的检索评测和生成评测解决了“定位问题”，但业务方真正关心的是“整体效果”。端到端评测就是把完整链路跑一遍，看最终产出到底能不能用。

4.1 端到端评测集的构造思路

端到端评测集的构造比检索评测集更丰富一些，通常包含四类样本：

第一类：有标准答案的事实性问题。比如“某某产品的退货政策是什么”，标准答案来自知识库原文。这类问题适合自动比对语义相似度，或者由 LLM 评估相关性。

第二类：有标准答案但需要整合多段信息的问题。这类问题考察的是 RAG 系统的“多跳”能力，比如“某某功能的配置要求以及支持的平台版本”，答案需要拼接多段内容。这类问题最容易暴露切分策略的缺陷和生成模型的信息整合能力不足。

第三类：主观性或开放性问题的近似答案集。知识库原始文档没有明确答案，只有参考答案。这类问题一般需要人工判断或者用“多参考答案”的对比评估方式。

第四类：无答案问题。这类的核心价值是考验系统的拒答能力——不应该有答案的时候，系统必须明确拒绝，而不是硬编。拒答策略正确的系统会把这类问题的相关度压到很低，然后走拒答流程；错误的状态是模型强行编造一个看似合理的答案。

4.2 拒答策略与评估指标联动

拒答评估不能只看“回答是否拒绝”，还要看拒答时机和拒答方式。一个合格的拒答流程应该包含：检索判断 → 相关度阈值 → 生成拒答话术。评测时需要注意两点：

第一，相关度阈值调太高，会导致大量低相关但部分有用的内容被拒掉，用户体感是“系统怎么老说不知道”；调太低，又会绕过拒答机制，让模型硬答，引发“幻觉”风险。必须结合测试集的 Hit Rate 分布做校准。

第二，拒答话术本身也需要评估。有些系统拒答做得太硬，直接说“不知道”然后结束；好的拒答应该说明“知识库里没有相关内容”，并引导用户换一种方式提问或建议补充文档。这类细节可以纳入端到端评测的相关性评分里。

端到端评测还有一个工程上的好处：它可以直接对接“人工抽检”流程。自动评测跑完之后，抽 10%～20% 的结果给业务方人工看一遍，既能验证自动评分是否合理，也能积累错误标注。这些标注样本回头再进评估集，就是一笔越滚越大的资产。

5. 评测集怎么建：从零到可用的完整流程

评测集是整个评测体系的灵魂，也是最大的工作量所在。很多团队在评测上止步不前，就是因为不知道这个数据集怎么从零开始搭。我把自己的踩坑经验总结成一套八步流程。

5.1 八步建集法

第一步，收集真实用户问题。从线上日志里捞，或者让业务方提供他们真实关心的疑问。没有线上日志的新项目，可以先用竞品分析、行业常见问题列表作为替代。注意：这一步严禁让开发者凭空编造问题，编造的题目往往和真实场景脱节。

第二步，去重与改写。同一个意思的问题保留一种表达，但要注意保留“问法的不均匀性”——有些人问得很口语化，有些人问得很书面。全部统一成规范问法会让评测集太理想化，失去测试价值。

第三步，划分难度。把问题分成简单、中等、困难三档。简单问题有直接对应的单段答案；中等问题需要检索到两三个片段；困难问题要么涉及深层推理，要么需要多步检索。评测集必须包含三档，否则测试结果会严重失真。

第四步，标注答案与依据片段。对于每个问题，标注标准答案，并标出在知识库中支撑答案的文档片段 ID。这一步最耗时，但不可跳过。没有依据片段，检索评测就是空谈。

第五步，构造无答案问题。设计一批知识库之外的问题，验证拒答能力。注意无答案问题的“迷惑性”要强，不能设计成“明显与知识库无关”的离谱问题，而是要与知识库有一定相关性，但答案确实不存在。

第六步，构造边界问题。这类问题极其重要但常被忽略——它们处于“知识库有相关内容但没有直接答案”的灰色地带。比如用户问“这个功能是否支持批量操作”，文档里只描述了单个操作流程，没有明确说明批量的支持情况。边界问题的处理质量往往最能体现 RAG 系统的成熟度。

第七步，小规模试标。先标 50 条，跑通评测流程，检查评估集是否存在标注歧义、是否有问题本身就存在逻辑缺陷。试标确认没问题后，再规模化标注。

第八步，持续扩充与版本管理。评测集不是一次性资产。每次新增业务文档时，都要同步扩充评测集，并把评测集纳入版本管理，与模型版本、数据版本做好对应。评测集的变化本身也需要评审，防止评测集被“调参”调坏。

5.2 无标注人员的替代方案

很多团队没有专职标注人员，这时候建议采用“弱监督 + 人工抽验”的方式。操作路径是：先用自动方式从文档里生成一批“问题-答案-依据片段”三元组，具体做法是让 LLM 根据文档片段生成问答对，再利用“答案是否能在片段中找到依据”这一点做自动回滤。这样生成出来的数据质量参差不齐，但经过人工抽验和修正后，可以作为首版评测集。

首版评测集的目标不是完美，而是“能跑”。先有评测，再谈迭代。哪怕评测集只有 100 条，也比你手工拿十几个问题试来试去强得多。

6. 评测执行的工程化实现与看板搭建

建好了评测集，接下来就是怎么把它变成一条可持续运转的流水线。

6.1 离线评测的推荐流程

离线评测建议用脚本驱动，核心流程包括四个阶段：

先做“数据集准备与加载”，确认当前评测集的版本和覆盖范围；然后“执行检索”，分别计算检索结果和检索指标；接着“执行生成”，在检索结果基础之上生成回答；最后“评估与汇总”，用评估器给生成结果打分，汇总所有指标，输出报告。

整个流程应该设计成一条命令行即可跑完的操作，并在执行结束之后自动生成一份 JSON+Markdown 格式的报告。报告里至少包含：各维度的平均分、中位数与分布，分难度档位的交叉结果，以及失败案例的详细信息。

这里有一个工程实现上的关键建议：评测流程中所有中间产物都要落盘保存。检索结果的数据、生成回答的原始文本、评分明细，全部保留。这样做的目的是——当你看板上某个指标异常时，你能随时回溯到具体样本，逐条分析原因，而不是面对一个冷冰冰的平均分。

6.2 评测看板的指标呈现逻辑

看板不是简单的数字展示，而是要服务于“定位问题”和“监控回归”两个目的。建议做成三层：

第一层是总览层，展示核心指标的趋势变化：召回率、MRR、忠实性、答案相关性，按时间维度画趋势图。每次调参、升级、换模型前后都会在趋势图上留下一个节点。

第二层是切片层，支持按问题难度、业务子领域、文档类型做下钻分析。很多问题在总览平均值上不明显，但一切到具体业务子域就原形毕露。比如某个领域的文档全是专业术语，跨语言、跨简称的情况非常普遍，切片分析能让你一眼发现这个子域的检索指标异常。

第三层是案例层，直接展示失败案例原文和各类打分结果。这一层看起来最“土”，但价值最高——它把抽象的指标还原成具体可读的信息，便于定位问题背后是切分策略、检索排序还是生成提示词的原因。

在线评测也不要完全忽略。RAG 系统上线之后，可以通过用户反馈按钮、会话日志等渠道收集真实体验数据。离线评测负责“控制变量下的质量检测”，在线数据负责“贴近真实场景的体验反馈”，两者结合才能形成完整的评测闭环。

6.3 评测流程避坑清单

有几个容易翻车的地方提前说清楚：

第一，评估集不隔离。测试集里混入了调参时用过的样本，会让分数虚高，而且这种虚高很难察觉。评测集、开发集、调参集必须物理隔离。

第二，评测代码和业务代码耦合。业务逻辑一改动，评测脚本也受影响，导致评测结果不纯净。建议单独建一个评测仓库，业务代码的变动不应该影响评测环境的稳定性。

第三，评估模型版本不固定。上周用某个评估模型打的分，这周换了版本，分数分布直接漂移，基线却被覆盖了。强烈建议：评估模型版本做锁定，就像锁定依赖库的版本一样。

第四，只跑一个 K 值。固定用 K=3 或 K=5，不做多 K 对比。实际评测应该输出 Recall@1、@3、@5 多组数据，因为不同业务场景对召回深度要求不同，固定 K 值会误导判断。

7. 测评工具与评估模型选型：直接可抄的作业

评测工具选型是很多团队纠结的点。我先按使用场景给出推荐，再说说底层逻辑。

7.1 工具包选型与对比

如果是做快速实验验证，建议优先用开源的 RAG 评估库，这类库核心指标齐备，支持直接调用评估模型打分。它的优势是上手快、指标标准，但个性化维度定义会有约束。

如果追求流程深度定制，专业评测框架如 TruLens 支持自定义评估器和多维度追踪，适合对评测逻辑有特殊要求的团队，代价是学习成本略高。

如果用的是大型开发框架，通常自带检索评测能力，与索引、查询链路深度集成。它们的问题是不太适合脱离框架单独评测，且往往不支持迁移到其他生态。

如果倾向于在云端平台做模型托管与评测，可以在模型服务平台上完成评测任务，适合以人工交互为主、偏好可视化界面、不想维护评测基础设施的团队。

我的实际建议是：从简单开源库起步，把评测流程跑通；一旦发现指标维度不够用，再迁移到更灵活的框架。评测体系的重点不在工具多高级，而在流程是否稳定、指标是否可信。

7.2 评估模型选型的实战经验

评估模型选择的核心原则是：稳定优先，能力其次。你要是今天换一个评估模型，明天又换一个，分数就是一团乱麻，对比毫无意义。

具体到业务里，如果线上生成模型用的是一个闭源商用模型，建议评估模型也尽量选择相近生态的闭源模型，保证评分稳定性和一致性；如果线上生成模型是开源自部署模型，评估模型也取向开源阵营，比如选择开源社区公认的强模型担任评估器。

另外一个容易被忽视的点是：强模型和弱模型各自适合测什么。强评估模型对事实性错误的敏感度高，适合做生成质量评估；弱评估模型打分一致性波动较大，但做检索排序类相对评估时反而够用。对绝大多数团队来说，初期没必要在评估模型上追求最强。固定版本、固定提示词、跑出稳定的基线，远比追求单次打分的极限准确率有价值。

7.3 评估提示词写法要点

同一款评估模型，提示词写法不同，打分结果能相差 20%。写评分提示词时几个关键规则值得记住：

维度必须单一。一次让模型评一个维度。很多评测工具支持一次输出多维度分，但实测下来，多维度同时评估会出现维度之间相互干扰的现象。

输出格式必须强约束。要求模型输出 JSON 格式，字段包含分数和理由，并对分数区间做严格说明。先让模型说理由、再给分，比直接给分要稳。

示例必须有正反两类。只给高分示例会让模型产生分数锚定，给出的分数普遍偏高；给出明确的低分反例，分数分布会更合理。

评估提示词写好后，还要做一轮人工校准。比例建议不低于 10%，最少建议 50 条。校准后发现偏差大的，立刻调整提示词，直到偏离率降到两成以内再放心批量使用。

8. 几类高发问题与排查路径

评测跑起来之后，你一定会遇到指标奇怪的情况，这里挑几个具有代表性的清单梳理一下。

8.1 检索指标好但生成分数低

这是最普遍的情况。检索的 Recall@5 达到 85%，但忠实性分数只有 60%。问题基本锁定在生成环节：要么是提示词没有强约束“根据上下文回答”，要么是生成模型能力不够，要么是上下文过长，相关信息淹没在大量不相关内容里。

排查顺序建议先看提示词，再看上下文长度，最后才考虑换生成模型。尤其注意一个陷阱：如果检索返回的 Top 5 里只有第 5 条是相关文档，前面全是噪声，生成模型即使有强约束也容易注意力分散。这种情况下，优化方向应该回到检索排序本身，而不是继续硬调生成提示词。

8.2 忠实性分数高但答案相关性低

这条路径指向的问题往往是“检索到的内容是相关主题，但不是用户问的那个具体问题”。举个例子：用户问某个功能的开启步骤，检索到了功能介绍文档，生成模型忠实复述了功能介绍，但用户真正要的是操作步骤。

这种问题单纯在生成环节调提示词解决不了，需要回看评测集中该问题的标注——如果依据片段本身就没标对，那说明检索器在当前索引结构下找不到更精细的内容块。解决路径是调整切分粒度，或者引入更细粒度的子索引。

8.3 无答案问题被硬答

这类问题最危险，因为它直接破坏用户信任。通常原因有两个方向：一个原因是检索器的相似度阈值过低，无答案问题也召回了几个低相关的片段；另一个原因是生成提示词里没有规定“上下文不相关内容时拒绝回答”的行为边界。

对应的排查路径是：查无答案问题的检索结果平均分，如果普遍高于阈值，就得校准相关度阈值；如果检索分数正常但生成器还是硬答，那就得重写提示词，并且要加上“基于给定资料回答，若资料无法回答问题，请明确说明”这类约束性表述。

8.4 切分策略改动后指标集体波动

切分粒度对 RAG 的影响是全局性的，调完切片大小后检索和生成分数都会变化，这时候容易让人困惑。核心的判断依据是看“是针对回答关键信息密度的变化”还是“单纯的语义碎片化”。

把切片调大，上下文信息更完整但噪声更多，检索召回分数可能微降，生成忠实性反而提升。把切片调小，检索精确度可能提升，但跨句子信息被切断的风险增大，生成回答的完整性会下降。评测的价值在这里体现得最充分——没有评测，你只能凭感觉判断“这次改动到底对不对”。

9. 用评测结果指导迭代的机制

评测的终极目标是让迭代有章可循，而不是出了一堆漂亮的指标。若要让评测真正推动系统优化向正确的方向前进，有三个机制值得建立。

9.1 建立“评测先行”的开发纪律

凡是涉及时改变 RAG 链路的行为，都要遵循固定流程：先跑评测，得到当前基线；再实施改动；改完立刻重跑评测；最后对比改动前后的差异。如果分数没有提升甚至下降，就回滚并换方向。

很多团队的迭代之所以反复横跳，就是因为每次改动都凭直觉和局部观察，导致整个系统的演化失去方向。评测先行能把每次改动都变成一次实验，而不是一次赌博。

9.2 用诊断树定位问题层级

拿到指标变化后，用三层诊断树快速圈定问题范围。最上的第一层看端到端整体回答质量是否达标；第二层对比检索分数与生成分数，判断下滑源头在检索还是生成；第三层针对定位到的环节，进一步细分判断是数据预处理、切片策略还是模型本身的问题。

这个诊断树逻辑应该固化在团队的认识里，甚至在评测报告里自动输出建议排查的方向。它不负责给出精确答案，但能大幅缩小排查范围，避免团队在错误方向上消耗精力。

9.3 失败样本池沉淀

每次评测中发现的失败样本，都进入“失败样本池”。然后定期做结构化分类，标记失败类型。久而久之，这个样本池就是团队最核心的知识资产。

后续优先级判断很简单：根据出现频率与业务影响评选出 TOP 问题，然后有针对性地去优化。这样做的好处是研发资源永远花在最痛的地方，而不是花在评测者觉得“看起来应该优化”的地方。

10. 最后一层：评测体系本身也需要被评测

做了很长一段时间评测之后，我得出一个体会。评测体系看起来是“为了保证质量而存在的工具”，但它本身也有漂移风险。这种风险主要体现在三方面：评估集污染、评估模型偏移、指标与体验脱节。

评估集污染，指的是长期反复使用同一批样本后，系统在潜意识里对这批数据产生适应，分数缓缓拔高，但真实效果并没有同幅上升。应对方法是定期扩充、轮换评估集样本。

评估模型偏移，指的是评估模型或者提示词的无意调整，导致分数分布变化。这种问题只能靠版本锁存来规避。升级评估模型的时候按流程走，要把新旧评估器在同一个数据集上各跑一遍对比分布，确认没有显著漂移再切换。

指标与体验脱节是三者中最隐蔽的：指标全部向好但用户仍然抱怨。通常是因为评测集不能完整覆盖真实用户的长尾分布。信号出现时，及时从在线日志中补样本，而不是无视用户反馈继续看漂亮指标。

在我实际做完各种 RAG 系统之后，最大的感受是：评测不是一个阶段性的动作，也不是为了漂亮的指标而存在。它本质上是一个连续的系统——感知系统状态的那双眼睛。一开始做 RAG 评估可能会觉得繁琐，特别是面对人工标注时。但坚持跑一段时间之后，你会发现在它带来的稳定感和方向感面前，这些成本都值得。

如果你正在做 RAG 而还没有建立评测体系，我建议你先从最小集起步：50 个测试问题、两个维度、一条评测命令行。跑起来之后再加维度、增样本、做看板。评测这件事，先起步比什么都重要。