AI 评测与实验方法

一次成功演示只能说明模型在一个输入、一个上下文和一次运行中给出了可接受结果。它不能直接说明模型在真实任务中稳定，也不能说明 Agent 会在不同数据、工具和攻击条件下保持同样行为。

AI 评测要把“看起来不错”变成有边界的证据：明确测什么，和谁比较，在什么环境中测，失败如何定义，结论能覆盖哪些任务。HELM等评测工作也强调，模型比较需要同时记录场景、指标和限制条件。

先定义任务和成功标准

评测从任务开始，而不是从指标开始。先写清输入来自哪里，谁会使用结果，允许模型做什么，禁止做什么，最终交付物是什么，以及哪些错误会造成不可接受的后果。

例如，评测一个安全告警 Agent，不能只问“回答是否正确”。还要区分它是否找到真正相关的日志，是否提出了可复现的假设，是否调用了允许的工具，是否泄露了不应读取的数据，是否在证据不足时停下。

成功标准要能被独立检查。代码可以运行测试，数据可以对账，格式可以用 Schema 校验，业务动作可以由权威状态确认；开放式写作则需要明确评分规则和抽样复核，不能只让同一个模型给自己打分。

建立基线和对照

没有基线，就无法判断改进来自哪里。基线可以是人工流程、规则系统、旧版本模型、没有检索的版本，或一个明确的简单实现。对照组要尽量只改变一个关键变量，例如只改变模型版本、上下文检索、工具集合或解码参数。

同一个任务集还应覆盖正常输入、缺失信息、歧义输入、边界条件和错误工具返回。只测模型最擅长的样本，会把演示效果误认为系统能力；只测极端攻击样本，又无法说明日常任务是否可用。

指标要对应具体失败

生成质量可以观察格式、相关性、完整性和可读性；事实任务要检查来源、数值、时间和实体；执行任务要检查成功率、错误副作用、人工接管、恢复结果和单位成功成本；安全任务要记录越权、敏感数据暴露、危险工具调用和未授权状态变化。

一个指标不能承载所有目标。平均分可能掩盖少量严重失败，成功率可能掩盖成本和延迟，安全通过率也不能证明系统没有未覆盖的攻击路径。高影响任务应同时报告失败类型、样本数量、任务分布、重复运行方式和未覆盖范围。

评测器也需要被验证

模型评审可以处理开放式表达，但它可能偏爱更长、更自信或更像自己风格的答案。评测器应先用人工标注样本校准，明确什么是通过、失败、部分通过和无法判断，再检查不同模型、格式和顺序是否会改变评分。

能用确定性方法验证的地方，应优先使用确定性方法。测试、Schema、规则、数据库状态和人工审批比“请模型判断自己是否完成”更容易复核。模型评审适合补充语义质量，不能替代安全控制或业务事实。

记录一次实验的完整条件

每次实验至少保存模型和运行时版本、系统提示、工具 Schema、上下文来源、检索快照、任务集版本、解码参数、并发和预算、评测器版本、原始输出、失败分类与人工介入点。NIST AI RMF提供了把风险、测量、治理和管理放进同一生命周期的参考框架。Agent 还要记录行动请求、工具观察、权威状态和最终验收结果。

这些记录让团队能够回答：改动到底改变了哪一层，结果是否可以重现，失败是否重复出现，生产环境是否和评测环境一致。缺少条件记录的分数，只能描述某次运行，不能支撑发布或迁移判断。

从失败中更新系统

失败分析要先找出发生在哪一层：模型知识不足，提示或上下文缺失，检索召回错误，工具参数无效，权限检查缺失，状态没有更新，验证器判断错误，还是任务本身无法被可靠定义。

错误归因决定修复位置。知识缺失可能需要补充来源或检索，工具不稳定需要修改契约和错误处理，重复规划失败需要调整状态与停止条件，权限问题必须修复模型外控制面。只反复修改 Prompt，往往会把系统问题隐藏成文字技巧。

评测如何连接 AI 安全

AI 系统安全关注评测对象是否和生产对象一致，AI 赋能安全关注任务结果是否有独立证据，AI 滥用防御关注攻击者是否能利用反馈持续提高成功率。三者都需要任务分布、攻击者能力、工具权限、失败后果和证据边界。

因此，一份评测结论应写成有条件的判断：在指定模型、数据、工具、权限、预算和验收规则下，观察到哪些结果，仍有哪些未覆盖区域，下一次变化会触发什么复测。评测提供证据，不能把一次通过改写成脱离条件的可靠性结论。

继续学习模型如何形成能力，阅读模型训练与推理；需要把评测接入 Agent 的运行闭环时，进入 Agent 与工具工程。