AI 评测技术调研:从模型、RAG 到 Agent

AI 应用的每次调整，都需要回答一个问题：这次变化究竟带来了什么影响？更换模型可能提升回答质量，也可能削弱某些任务的表现；修改 Prompt 可能解决当前问题，却引入新的错误；接入知识库、工具和 Skill 后，系统的能力边界与失败方式也会随之变化。

要判断这些变化，不能只依赖几个演示案例，还需要一套能够持续运行、支持比较和定位问题的评测方法。本文按照评测概述、模型评测、RAG 评测、Agent 评测和开源案例五个部分展开，梳理各类评测的对象、指标与实施方式，并结合 One-Eval 和 OpenJudge 分析评测工具的设计思路。

01评测概述

.1.1 评测是什么

评测是按照事先约定的标准，检查系统在一组任务上的表现。它既要给出质量判断，也要说明判断依据，让后续优化有明确的方向。

开展评测之前，需要先确定三个要素：测试哪些任务、什么结果算合格、用什么方法判断。分类任务可以核对标签，代码任务可以运行测试，开放式问答则需要结合准确性、完整性和实用性等标准。任务不同，适合的判定方式也不同。

随着 AI 应用从文本生成扩展到检索和工具执行，评测范围也需要相应扩大。模型评测主要观察输出；RAG 还要检查答案依据；Agent 则需要验证实际操作、交付物和环境状态。例如，回复“文件已经生成”只是一个文本结果，文件是否存在、内容是否正确，仍然需要另行确认。

一次完整的评测可以概括为：定义任务与标准 → 准备样本和环境 → 执行被测系统 → 收集结果与过程记录 → 判分和分析。

.1.2 为什么需要评测

AI 应用通常处于持续变化之中：模型版本会升级，Prompt 会调整，知识库会更新，工具接口和业务流程也会变化。这些修改往往同时影响多个场景，少量手动体验很难覆盖全部影响。

回归评测可以把已有能力转化为可重复检查的任务。在修复失败样本后，重新执行原本表现正常的样本，才能判断局部改进是否伴随其他能力的退化。

对于 Agent，同一任务还可能产生不同执行路径。一次成功只能说明该次运行达到了要求，稳定性需要通过多样本、重复执行和异常场景共同验证。

因此，评测应该成为版本迭代的一部分：先建立基线，再比较变更，随后检查线上效果，并将新发现的问题补充到评测集中。观测记录发生了什么，评测判断这些行为是否符合要求，两者结合才能支持持续改进。

.1.3 评测的分类与关系

按照被测对象，可以将本文讨论的评测分为模型、RAG 和 Agent 三类。

这三类评测并不彼此独立。RAG 的回答质量受到模型能力影响，Agent 又可能通过 RAG 获取任务所需的信息。一个完整应用可能需要同时开展三类评测：用端到端结果判断整体效果，再通过各环节的指标定位原因。

02模型评测

.2.1 模型评测是什么

模型评测的出发点，是确认模型能否在给定条件下完成目标任务。对于应用开发，评测结果最终需要支持具体决策，例如选用哪个模型、是否采用新的 Prompt，以及微调后是否值得发布。

这类判断需要把任务、输入条件和评分规则固定下来，再观察不同方案的差异。否则，模型回答看起来更流畅，可能只是表达方式发生了变化，并不意味着正确率或业务可用性有所提高。

大模型能力具有明显的场景差异。知识问答表现较好的模型，未必擅长修改工程代码；数学能力较强的模型，也可能在格式约束和多轮指令遵循上出错。同时，自然语言允许多种正确表达，很多任务不能只靠字符串匹配判分。因此，模型评测通常需要组合多类任务，并按任务特点选择验证方式。

.2.2 模型能力维度与代表性评测基准

选择基准之前，应先明确希望观察的能力。近年常用的基准已从知识问答扩展到复杂推理、真实代码修改、可验证的指令遵循、图文理解与工具交互。下表按任务特点选取代表性项目；它们并非同一种“总分考试”，其中一些测模型输出，另一些同时考察运行框架和外部环境。

这些基准的任务形式和执行条件不同，分数不能直接横向等同。特别是软件工程、工具使用和多轮交互任务，其结果还受到运行框架、工具配置和执行预算的影响。对于持续更新的基准，还需要记录数据版本与时间窗口；较新的题目能够降低部分污染风险，但不能保证完全没有污染。

.2.3 公共评测基准的适用边界与数据污染

公开评测集便于复现和比较，但题目、答案及相关解析也可能进入模型的训练数据。模型在评测前接触过高度相似的内容，就可能依靠记忆而获得较高成绩，使分数高估对新问题的处理能力。

不过，榜单表现与实际体验不一致，不能直接归因于数据污染。业务任务与基准的分布差异、Prompt 配置、工具条件和评分方式，都可能导致两者出现偏离。

更合理的做法是把公共基准作为初筛依据，再使用贴近实际需求的任务进行验证。业务评测集应尽量独立于日常调参样本，并定期补充新问题，避免团队在反复优化中只适应少量已知题目。

.2.4 如何建自己的业务评估集

业务评测集首先要覆盖真实任务。可以从用户请求、历史失败记录和业务流程中抽样，按照任务类型、频率、难度及风险分层，再为样本补充参考答案或验收要求。

起步时可以整理 50—200 条具有代表性的样本，用于建立初步基线。这个数量只是便于启动的规模，是否足够还取决于业务复杂度和希望识别的改进幅度。对于小幅分数变化，几十条样本通常不足以支持稳定判断。

评分规则应尽量具体。分类和信息提取可以检查标签、字段和值，代码可以运行测试，摘要和开放式问答则可以拆成事实准确、要点完整、符合指令等检查项。先明确这些要求，再决定由程序、模型裁判还是人工执行判定。

使用 LLM-as-a-Judge 时，需要给出清晰的评分说明与正反例，并通过人工复核检查其判断。早期可以抽查 10%—20% 的样本作为工作起点，再根据样本数量、误判情况和任务风险调整。复核应同时覆盖随机样本、争议样本和关键失败样本，不能仅凭固定抽查比例认定裁判可靠。

评测集还应保存版本、样本来源和适用条件。用于开发调优的数据与用于最终验收的数据适当分开，才能降低对测试集反复拟合的风险。

03RAG评测

.3.1 RAG评测是什么

RAG 将外部资料引入生成过程，一次请求通常会经过问题理解、检索、重排、上下文组织和回答生成。因此，评测需要同时检查资料获取和资料使用：系统是否找到了足够的依据，模型是否据此给出了符合要求的答案。

与一般搜索相比，RAG 还需要考虑检索结果是否适合后续生成。某个片段与问题主题相关，并不代表它包含回答所需的具体条件；多个片段各自有用，组合后也可能出现重复、冲突或时效不一致。

例如，用户询问“订单发货后还能修改收货地址吗”，系统给出了肯定答复。错误可能来自没有检索到修改条件，也可能是有效规则排在上下文截断位置之后，或者模型忽略了“仅限揽收前”的限制。如果同时取回新旧版本规则，还需要检查最终采用的是哪一个版本。

因此，RAG 评测可以分为三个层面：检索层检查资料覆盖与排序，生成层检查答案的依据、相关性和完整性，端到端层再综合观察任务效果、引用可用性、延迟与成本。

.3.2 评估指标分类

3.2.1 检索侧

3.2.1.1 预测指标

这里的预测指标用于判断检索结果中相关内容的数量与覆盖范围，暂不考虑它们的具体排列位置。计算之前，需要先约定相关性的判定标准，以及以文档、段落还是 Chunk 作为统计单位。

精确率 (Precision@K)

Precision@K 表示前 K 个检索结果中，相关结果所占的比例：

例如，返回的前 5 个片段有 3 个与问题相关，则 Precision@5 为 60%。该指标可以帮助判断模型接收到的候选资料中，无关内容占了多大比例。

它的上限与可用相关片段数量有关。如果知识库中某问题只有 2 个相关片段，K 取 10 时，即使全部找到，Precision@10 也只有 20%。因此，较低的精确率可能来自排序或召回问题，也可能与 K 的设置及样本本身有关。

不同查询的分数可以汇总，但比较系统时应使用一致的查询集、K 值和相关性标注，并结合场景分组分析。精确率高说明结果更集中，不代表回答需要的信息已经齐全。

召回率（Recall@K）

Recall@K 衡量已知相关内容有多少进入了前 K 个检索结果：

某问题共有 8 个相关片段，其中 5 个出现在前 10 个结果里，则 Recall@10 为 62.5%。这一指标用于发现检索遗漏。

在候选排序不变、结果列表按前缀扩展的条件下，增大 K 不会降低召回率，但会增加上下文长度和噪声。因此，评测应使用与实际系统一致的 K 值，并同时观察延迟、精确率和生成质量。

召回率依赖相关片段标注的完整性。如果参考集合漏标，分数也可能失真。对于没有相关文档的问题，应单独检查系统能否识别资料不足，而不是直接套用分母为零的公式。

F分数（F-score）

F 分数将精确率和召回率合并，用于观察二者之间的平衡。记精确率为 P、召回率为 R，则：

当 β 为 1 时，得到 F1 分数，即精确率与召回率的调和平均值；β 大于 1 时更重视召回，小于 1 时更重视精确率。

例如，P 为 0.6、R 为 0.75 时，F1 约为 0.667。它适合用于汇总比较，但单个综合分数仍然可能掩盖问题。分析时应保留 P、R 各自的结果，以便判断需要减少噪声还是补充遗漏。

3.2.1.2 排序指标

Precision 和 Recall 只统计前 K 个结果里出现了多少相关内容。同样是 10 个结果中包含 5 个相关片段，它们位于前 5 位还是后 5 位，这两个指标都不会变化。

实际系统中，排序会影响截断后保留哪些资料，以及关键依据在上下文中的位置。排序指标用于进一步观察相关内容是否得到了合理的优先级。下面也列出 Hit Rate，作为判断 Top-K 是否至少命中一条相关内容的补充；它本身不区分命中位置。

平均倒数排名（Mean Reciprocal Rank，MRR）

MRR 关注每个问题第一次命中相关结果的位置。若第一个相关结果排在第 r 位，该问题的倒数排名为 1/r；在评测范围内没有命中时记为 0，再对全部问题取平均。

例如，4 个问题的首次命中位置分别为第 2、1、4 位和未命中，则：

MRR 适合判断系统是否能尽早找到一条有效依据，但它忽略第一次命中之后的结果。对于需要综合多份资料才能回答的问题，即使 MRR 很高，信息也可能不完整。

平均精度均值（Mean Average Precision, MAP）

MAP 在多个相关结果的基础上评价排序。先计算每个查询的平均精度 AP，再对所有查询的 AP 取平均。

在二元相关性标注下，AP 的计算方式是：每遇到一个相关结果，就记录截至该位置的 Precision，将这些值相加后除以该查询的全部已标注相关结果数。

其中，相关结果的 rel(i) 为 1，否则为 0；R 为全部已标注相关结果数。未检索到的相关结果不会贡献分子，但仍计入分母。

例如，某问题共有 3 个相关片段，全部出现在第 1、4、5 位，则：

若另一个问题的 AP 为 0.8，这两个问题的 MAP 就是 0.75。如果第一个问题实际上还有第 4 个相关片段未被检索到，则其 AP 应为 2.1/4，而不是 2.1/3。

MAP 能同时反映相关结果的覆盖和排序，但计算依赖较完整的标注。使用截断版本 AP@K 时，还需要明确分母采用哪种约定，避免不同实现之间直接比较分数。相关定义可参见信息检索教材中的排序评测说明。

命中率（Hit Rate）

Hit Rate@K 统计有多少查询在前 K 个结果中至少找到了一个相关片段：

例如，100 个问题中有 82 个至少命中一条相关资料，Hit Rate@K 就是 82%。它直观地反映检索是否具备基本的信息供给能力。

这一指标不检查命中数量和位置，也不保证已有资料足以支撑完整回答。对于单一事实查询，它较有参考价值；对于跨文档综合任务，还需要结合召回率和上下文覆盖情况。

归一化折损累积增益（Normalized Discounted Cumulative Gain，NDCG）

当文档相关性存在程度差异时，可以使用 NDCG。它既考虑相关性得分，也根据排名位置进行折损，让更靠前的高相关结果获得更高权重。

一种常用定义为：

其中，IDCG@K 是将已标注结果按相关性从高到低排列后得到的理想 DCG。实际排序越接近理想排序，NDCG 越接近 1。也有实现直接使用相关性分值作为增益，评测时需要固定公式和标注尺度。

这一指标适合区分“直接包含答案”“提供部分依据”和“仅主题相关”等不同等级。它经过归一化，便于在查询集上汇总，但跨数据集比较仍需考虑题目难度、标注规则和 K 值差异；IDCG 为零的情况也应约定处理方式。

在 RAG 中，可以将 Recall 用来观察依据是否找全，将 NDCG 用来观察这些依据是否排得合理，再通过生成指标确认排序变化是否改善了回答。

3.2.2 生成侧

生成结果通常存在多种合理表达，即使有参考答案，也很难只凭字面匹配判断质量。更实用的方式是将回答拆成若干可检查的维度，再由规则、模型裁判和人工复核共同完成评价。

下面从忠实度、答案相关性、上下文相关性和上下文召回四个角度展开。前两项直接评价回答，后两项从回答需求出发检查资料质量。Ragas 等框架提供了其中若干指标的实现，但具体名称、输入要求和算法需要以采用的版本为准。

Faithfulness(忠实度)

忠实度检查回答中的事实性陈述能否得到检索上下文的支持。基本做法是将回答拆分成独立陈述，再逐条判断是否有依据：

例如，资料说明“设备保修期为 12 个月，保修范围不包含人为损坏”，回答却写成“保修 12 个月、不包含人为损坏、提供终身免费上门服务”。按这三个检查项计算，前两项有依据，最后一项缺少支持，忠实度为 2/3。

此类判定方式可参考 Ragas 的 Faithfulness 定义。

忠实度低时，需要检查是否遗漏约束、混用了其他信息，或被上下文噪声干扰。可以通过加强基于资料作答的要求、优化上下文组织以及改进模型选择进行验证。

忠实度高也不代表答案一定正确。如果检索到的资料本身有误或已经过期，模型仍可能忠实地复述错误内容。因此，该指标还应与知识库质量、答案正确性和问题覆盖程度一起分析。

Answer Relevancy(答案相关性)

答案相关性关注回答是否围绕用户的实际问题展开。内容即使正确，如果没有回应用户关心的事项，仍然可能缺乏使用价值。

一种自动评测方式是根据生成答案反向构造若干问题，再计算这些问题与原始问题的语义相似度：

这是一种基于相似度的近似判定，具体实现还可能对回避性或无实质内容的回答增加处理。Ragas 中的相关实现见 Response Relevancy。

例如，用户问“设备保修多长时间”，回答花了大部分篇幅介绍产品功能，只在末尾提到保修期。回答与产品有关，却没有充分围绕提问组织内容，相关性评价应关注这种偏离。

分数偏低时，可以检查问题理解、回答要求及无关上下文。还需要注意，语义相似不等于事实正确：一个直接回答问题但给出错误期限的答案，仍可能得到较高的相关性分数。

Context Relevancy(上下文相关性)

上下文相关性衡量输入给模型的资料中，有多少内容对当前问题有帮助。它可以用于观察检索和切分策略是否引入了过多噪声。

一种便于理解的自定义口径是先将上下文切成句子，再判断每句话是否与回答问题有关：

例如，将一个片段拆成四句话：“产品面向企业销售。”“支持批量采购。”“设备保修期为 12 个月。”“可通过官网查询服务网点。”对于“保修多长时间”这一问题，直接相关的只有第三句话，按该口径得分为 25%。

这个公式是句子级相关性的一种统计方式，不应视为所有框架的统一定义。句子切分和相关性判定都会影响结果，文档标题、适用范围、时间条件等辅助信息也不能简单当作噪声删除。

低分时，可以检查 Chunk 是否过大、相邻内容是否混杂、重排是否有效，再调整切分与上下文组装方式。减少 Top-K 可能提高信息密度，但也可能删掉必要依据，需要同时检查召回指标。

Context Recall(上下文召回)

上下文召回从参考答案出发，判断生成正确答案所需的信息是否已被检索到。将参考答案拆成若干要点后，可以计算：

例如，问题要求说明保修期限及例外情况，参考答案包含“保修 12 个月”和“人为损坏不在保修范围”两项。若上下文只有期限信息，该指标为 1/2。基于参考陈述的实现可参见 Ragas 的 Context Recall 说明。

它与检索侧 Recall@K 的统计单位不同：前者关注答案要点是否有依据，后者关注已标注文档或片段是否被找回。因此，即使找回的相关片段不多，只要覆盖了全部必要信息，上下文召回也可能较高。

分数偏低时，需要检查索引是否缺失内容、查询是否表达完整、切分是否破坏了条件，以及检索或重排是否遗漏关键片段。如果参考答案本身不完整或过时，也应先修正标注。

.3.3 RAG评估集怎么构建

一条 RAG 评测样本可以围绕问题、参考答案和相关文档片段组织，再补充知识库版本、适用时间及业务标签。执行评测后，还应保存实际检索结果和生成答案，用于关联分析。

不同指标需要不同字段。没有参考答案时，仍可检查忠实度和部分相关性指标；但要计算基于参考要点的上下文召回，就需要对应标注。样本结构应由评测目的决定。

人工构造适合覆盖明确的业务规则和关键场景。可以由熟悉业务的人设计问题、标注答案依据，再由另一位人员复核。初期整理几十到一两百条样本即可启动流程，之后根据场景覆盖和误差分析逐步扩充。

真实日志采样更容易保留用户实际的表达方式，包括口语、省略、拼写错误和上下文依赖。采样时应兼顾高频请求、长尾问题和失败案例，再补齐缺失上下文及参考标注。真实日志的价值在于代表性，质量高低仍取决于清洗与标注。

LLM 生成适合快速覆盖知识库内容，并构造改写问题或多种问法。它可以降低初始整理成本，但生成的问题可能过于贴近文档措辞，也可能存在无依据的答案，需要抽查和去重。

三种方式可以结合使用：先用人工样本明确标准，用合成样本补充覆盖，再以真实请求持续校正分布。除了正常可回答问题，还应加入资料缺失、规则冲突、时间条件变化和跨文档综合等情况，避免评测只反映理想输入下的表现。

.3.4 评估驱动的优化闭环

RAG 优化应从一份可复现的基线开始。固定评测集、知识库快照、模型配置和指标版本，保存每条样本的检索结果与回答，后续调整才能有明确的比较对象。

.第一步，记录基线

同时记录检索、生成和效率指标，并按业务类型拆分结果。整体均分用于观察方向，分组和样本明细用于定位问题。

.第二步，提出瓶颈假设

指标变化可以帮助缩小排查范围，但不能直接代替归因。

.第三步，验证具体调整

在条件允许时一次只修改一个主要变量，例如更换 Embedding 模型或调整重排策略。涉及多个组件的联合修改，应记录变更范围，避免把全部收益归因于其中一项。

.第四步，比较收益与代价

既看整体质量，也看核心场景是否退化、延迟和成本是否增加。验收阈值应结合业务要求设定，不宜把某个固定召回率当作所有场景的统一标准。

.第五步，补充新样本

将线上暴露的问题整理到评测集中，并保留一组稳定样本用于历史比较。通过持续回归和线上验证，逐步确认优化带来的提升是否能够保持。

04Agent评测

模型评测通常从输出能力入手；Agent 评测还要确认一项任务是否在实际环境中完成。同样一句“已办理”，可能对应正确写入的记录，也可能只是一次没有生效的工具调用；相反，Agent 没有按预想顺序使用工具，也未必意味着任务失败。

要作出可靠判断，必须把两项工作连起来：观测记录执行过程中发生了什么，评测依据任务目标判断结果是否可接受。线上的异常由观测发现并保留证据，转化为评测样本后用于修复和回归，新版本再通过线上观测接受检验。

.4.1 从用户请求确定验收对象

Agent 的输入不只是 Prompt。任务还受初始数据、工具权限、业务规则和运行时状态影响。因此，在设计评测前，先要明确“交付”具体是什么：是给出一条信息、生成一个文件，还是改变某个系统中的记录。不同交付物需要不同的验收方法。

以一个售后处理 Agent 为例，用户提出退款请求。Agent 可能需要查询订单、核对适用规则、判断是否具备处理权限，并在满足条件时发起申请。若最终回复“退款已提交”，但订单系统里没有对应申请，这项任务仍然失败；若订单本来不满足条件，准确解释原因并避免误提交，反而应当算作正确处理。

因此，任务的成功条件应同时包含目标状态与边界条件。目标状态用于回答“事情办成了吗”，边界条件用于回答“有没有以不被允许的方式办成”。例如，不能修改其他用户的订单，不能把“已发起申请”说成“退款已到账”，也不能在必要信息缺失时自行补造订单号。

评测对象也不是孤立的模型。模型版本、Prompt、工具接口、Skill 描述和执行策略只要发生变化，整体表现就可能变化。对比版本时，需要知道运行的是哪套配置，才谈得上解释差异。因此，确定验收条件时也应确定需要保留哪些证据：订单系统的最终状态用于核验结果，工具调用和返回值用于解释过程，用户所见回复用于评价沟通是否准确。

.4.2 把真实任务写成评测样本

一条可执行的 Agent 评测样本，至少应写清请求、初始环境和验收规则。对需要操作外部系统的任务，还要预置可恢复的数据状态：同一个退款用例不能在第一次运行后留下申请记录，第二次运行又从已申请的状态开始。

同一业务功能需要覆盖不同情形。正常样本检查核心流程；边界样本可以设置资料缺失、规则冲突、工具超时或订单已处理；禁止操作样本检查 Agent 能否适时停止并解释。只从成功演示中抽题，会让评测集高估实际可靠性。

样本来源可以结合真实请求、历史故障和专门设计的边界场景。线上观测中的工具异常、用户纠正、人工接管以及“回复成功但实际状态未变”等现象，可以作为待检查的线索；经过人工或规则确认后，再把具有代表性的任务转入评测集。

真实记录需要去除敏感信息，补齐或重建初始状态，并保留关联的执行记录，否则样本即使能够运行，也可能因条件变化而无法复现原问题。按功能、风险和任务难度分组后，报告既能反映整体表现，也能显示具体哪类请求发生退化。

评测集还应区分两种用途。一组相对稳定的任务用于比较版本，确保过去能完成的事情仍然能完成；另一组持续吸收新失败和新需求，用于探索系统的能力边界。样本与判分规则发生变更时，应保存版本，避免把“试卷变了”误读为“Agent 变好了”。

.4.3 按结果、约束和体验分别判分

设计评分时，可以先问一项检查是否存在独立的验证办法。文件是否生成、订单状态是否变化、代码测试是否通过，都可以由程序读取实际产物或环境状态。这类检查应优先于“模型看完回复后觉得做成了”的判断，因为 Agent 对自己执行结果的描述也可能出错。观测到“提交申请”工具返回成功，只能证明这一步收到了成功响应；评测仍需核对订单系统最终是否存在正确的申请记录。

其次检查必须满足的约束。例如权限范围、是否重复提交、是否使用了过期规则。对于明确的越权或误操作，应单独记录并作为关键失败处理；如果只把它们折算进平均质量分，优秀的语言表达可能掩盖严重的执行错误。

开放性的部分再使用评分细则。例如，售后说明是否准确引用当前规则，是否说明申请与到账的区别，是否在信息不足时请求补充。将这些要求拆成可判断的要点，模型裁判就能参与批量评估；人工则负责检验标准、复核争议样本和修正误判。对高风险任务，程序检查和人工复核不能仅由模型裁判替代。

完成质量与资源消耗应分开呈现。任务完成率回答“有多少任务办成了”，单位任务耗时和成本回答“以什么代价办成”。先看能否达到最低质量要求，再比较同等质量下哪套方案更高效，比将准确性、耗时和 Token 全部加权成一个不透明总分更便于决策。

同一任务还需要重复执行。单次成功率统计每次运行的通过比例；“运行 k 次至少成功一次”反映多次尝试获得可用结果的机会；“k 次全部成功”更接近稳定性要求。三种口径不能混称。对于用户只会发起一次的业务流程，单次通过率通常比允许后台多次尝试的指标更贴近实际体验。

过程记录主要用于解释分数和识别结果检查无法覆盖的风险。为每次执行关联任务编号、运行编号、模型与配置版本，并记录工具或 Skill 的调用、参数、返回值、错误、耗时和关键状态变化，就能把每一条评测结论追溯到相应证据。

若任务失败，沿记录检查问题出在需求理解、规则获取、工具执行、环境状态还是验收标准；若任务成功，也可检查有无不必要的重试或违规动作。这里评价的是可观察的行为，不要求 Agent 严格沿着唯一的参考路径执行。

.4.4 观测与评测如何形成迭代闭环

观测与评测的衔接，不是把日志送给评分模型就结束了。一条问题线索需要经历发现、判定、归因、修复和再次验证，最终回到真实任务中检查是否改善。可以按下面的顺序运行：

例如，售后 Agent 告诉用户“申请已提交”，但线上出现重复询问。观测记录显示提交工具返回成功，评测再核对订单系统，发现没有对应申请。回放发现 Agent 把接口的受理响应当作最终处理结果，于是修改工具结果的解释和状态确认步骤，并将“接口受理但未落单”加入评测集。

修复后先检查这个样本及既有退款任务，再观察线上“回复已提交但状态未变”的情况是否减少。这时，线上观测负责发现和验证，离线评测负责明确标准并守住修复结果。

为了让版本结论可信，实验中要固定样本、初始数据和评分规则，记录模型、Prompt、Skill、工具接口的版本。可能产生副作用的任务应在隔离环境运行，每次试验前恢复状态；外部接口无法完全固定时，应记录返回数据版本与故障情况，避免把环境波动误判为能力变化。

最终报告不能只有一个平均分，还要列出按场景统计的任务完成率、关键约束违规次数、成本与耗时，以及新增成功和新增失败的具体任务。若退款申请成功率提高，但重复提交从零变为多次，版本仍需修复。持续更新的评测集帮助发现新问题，稳定的回归集则保护已有能力；两者依靠执行记录与线上反馈相连，才构成可重复运行的闭环。

05开源案例

.5.1 One-Eval：自动化模型评测开源项目

代码仓库：One-Eval。

5.1.1 项目定位

一次模型评测通常需要串联多项准备工作：选择基准、下载数据、适配格式、配置推理、解析输出和计算指标。当这些步骤分别由不同脚本处理时，重复配置和流程衔接会占用较多时间。

One-Eval 面向这一问题，将自然语言描述的评测需求转化为可执行流程，即 NL2Eval。用户给出希望评估的能力，系统再组织基准选择、数据准备、推理、评分和报告生成。项目定位与能力说明见 One-Eval 仓库文档。

例如，需求可以是“评估候选模型的数学推理表现”。系统中的 Agent 负责组织这次评测，被测对象则是候选模型。理解该项目时，需要区分执行评测流程的 Agent 与被评测的模型或应用。

从工程角度看，这类工具的价值在于减少流程组装工作，让评测需求更容易转化为可执行任务。但基准是否贴近业务、执行预算是否合理，仍然需要由使用者结合目标判断。

5.1.2 核心架构与工作流

One-Eval 基于 DataFlow 和 LangGraph 组织评测能力，采用 Graph、Node 和 State 表达执行关系、具体步骤与任务状态。其公开说明强调流程自动化、关键节点人工介入和可扩展能力。

按工作职责，可以将流程理解为：解析评测需求 → 选择与确认基准 → 准备和适配数据 → 检查运行配置 → 执行模型推理 → 确认评分方式 → 计算结果并生成报告。

这种组织方式将长流程拆成可以单独检查的步骤。数据准备失败时，可以优先处理数据问题；指标不适用时，可以调整评分配置；关键选择也可以保留人工确认。

从评测平台设计的角度，值得关注四点：

评估是否采用此类方案时，除了看能否自动完成一次演示，还应检查私有数据接入、失败恢复、结果复现和维护成本。这些因素决定了工具能否长期融入研发流程。

5.1.3 未来规划

项目公开路线图列出了三个扩展方向：支持代码和 Text2SQL 等需要额外执行环境的任务，补充依赖沙箱的 Agent 评测能力，以及建设用于组织、交流和复用基准的在线平台。

这几个方向对应着不同的工程要求。代码和数据库任务需要可靠的执行验证，Agent 任务需要环境初始化与隔离，在线平台则需要管理数据、配置和共享边界。调研时应区分已经可以运行的能力与计划中的能力，并通过目标场景验证实际适用性。

5.1.4 项目体验

— One-Eval 项目体验

需要先启动对应的前后端服务，并完成模型接口等配置。

.5.2 OpenJudge：评分与评测开源项目

代码仓库：OpenJudge。项目文档：OpenJudge 使用文档。

5.2.1 项目定位

OpenJudge 以评分器为核心，为 AI 应用提供质量评价能力。它既提供现成评分器，也支持根据业务要求构建评分标准，并将评分能力接入应用评测和优化流程。

从本文讨论的评测链路来看，One-Eval 更侧重组织一次评测如何执行，OpenJudge 则更侧重样本表现如何判断。两者的侧重点不同，选型时应先确定主要问题是流程自动化，还是评分能力的构建与复用。

5.2.2 核心特性

系统化、质量保证的评分器库

OpenJudge 按不同任务领域组织评分器，既覆盖内容和结构检查，也包含面向 Agent 执行过程的评价。

预置评分器可以减少重复实现，但是否适合某项业务，还需要结合具体样本验证。例如，“相关性”评分可能无法识别业务规则错误，工具选择正确也不代表参数和最终执行结果正确。

因此，接入时应明确每个评分器能判断什么、需要哪些输入，以及不能覆盖哪些问题。项目自带的验证数据和测试能够帮助检查实现，业务侧仍需保留自己的校准样本。

灵活的评分器构建方法

不同业务对评分标准的明确程度不同，OpenJudge 提供了多种构建方式，包括自定义规则、根据任务描述生成 Rubric、从标注样本归纳标准，以及训练专用评判模型。

自动生成的评分标准适合作为起点。投入使用前，应检查标准是否真正对应用户目标，并用成功、失败和边界样本验证。评分器与被测系统一样，也需要版本管理和回归检查。

集成

OpenJudge 提供与 LangSmith、Langfuse 等观测平台，以及 VERL 等训练框架的集成方式，使评分结果可以进入评测分析或训练流程。

在工程接入中，需要重点解决样本、轨迹和评分结果之间的关联：某个分数对应哪次执行，使用哪个评分器版本，依据哪些内容得出。只有这些信息能够串联起来，评分结果才能用于归因和回归。

如果将评分转换为训练奖励，还应进一步检查奖励目标是否与业务目标一致，避免模型只优化容易得分的表面特征。

5.2.3 项目体验

— OpenJudge 项目体验

项目内置了一些用例，可以用来体验基本的评测流程。