直接回答
AI 工具评估不是列一张热门产品榜单,而是完成一次受控决策:定义工作负载和不可接受的失败,先淘汰违反硬约束的候选,再让剩余方案在同一组版本化任务上比较合格任务质量、安全、时延、总成本、运维和退出成本。只有满足完整生产契约的候选,才算适合。
这套方法适用于模型 API、编程助手、多模态服务、Agent 平台和自托管模型。产品名称与价格会持续变化,评估方法应能跨版本复用。
先确认你在选择哪一层
“AI 工具”可能指不同层次。把它们当成同类候选,会产生错误结论。
| 层次 | 要解决的决策 | 所需证据 |
|---|---|---|
| 模型 | 哪个模型版本适合某项任务 | 固定输入、输出、评分规则与采样配置 |
| 供应商端点 | 模型应该在哪里运行 | 区域、保留策略、限流、SLA、价格版本 |
| 产品 | 哪个助手能完成用户工作流 | 端到端成功率、权限、人工审查成本 |
| 框架 | 如何编排调用、工具和状态 | 恢复、可移植性、可观测性与维护成本 |
| 部署 | 托管 API、专属实例还是自托管 | 容量测试、人员投入、许可证和事故责任 |
强模型放进弱产品,仍可能因为上下文选择、权限或恢复机制而失败。框架 Benchmark 也不能证明某个托管产品实现了同样行为。评测时应记录完整组合:
产品 + 模型版本 + 系统指令 + 工具
+ 检索/索引版本 + 采样参数 + 区域 + 策略 + 日期
先写工作负载契约
工作负载契约把“找最好的模型”改成可验证的要求。
workload: support-ticket-resolution
population:
languages: [zh, en]
length_buckets: [short, medium, long]
risk_slices: [refund, account-access, self-harm]
required_outputs:
schema: ticket-decision-v3
evidence: cited-policy-sections
hard_constraints:
regions: [approved-region]
retention: no-training
p95_latency_ms: 2500
critical_safety_failures: 0
quality_gates:
policy_accuracy_min: 0.94
schema_validity_min: 0.995
abstention_recall_min: 0.90
operations:
cancellation: required
usage_export: required
rollback: required
硬约束是过滤条件,不是可以加权抵消的偏好。不能满足数据驻留要求的模型,不应靠更高质量分弥补;出现一次已确认的严重越权,也不能靠平均语言流畅度赢得选型。
NIST ARIA 评测规划手册将 Model Testing、Red Teaming 与 User Testing 组合起来。这种拆分很实用:离线输出质量、对抗行为与真实工作流可用性回答的是不同问题。
构建有代表性的评测集
评测集应该复现系统成功与失败的真实方式。
至少覆盖:
- 真实语言、格式和频率下的普通任务;
- 长度、歧义和 Schema 边界案例;
- 历史生产故障;
- 对抗输入和策略敏感请求;
- 工具错误、超时、过期证据与部分结果;
- 没有安全答案时应该拒答或转人工的案例。
在调 Prompt 前先切分数据。开发集用于迭代,密封留出集用于决定是否通过。如果同一批案例既塑造 Prompt,又评判结果,分数测量的是对测试集的适应,而不是泛化能力。
不同任务需要不同 Oracle:
| 任务 | 合适的判定依据 |
|---|---|
| 分类 | Gold Label,以及每类 Precision / Recall |
| 信息提取 | Schema 校验与字段级正确率 |
| 代码生成 | 编译、测试、安全检查与人工 Review |
| 有来源回答 | Claim 与证据一致,以及正确拒答 |
| 创意草稿 | 人工 Rubric、Pairwise Preference、修改成本 |
| Agent 工作流 | 最终状态、副作用、恢复与审计事件 |
HELM 评测框架强调场景覆盖、多指标与统一 Adaptation。它最值得复用的不是某个排行榜数字,而是明确写出评测没有覆盖什么。
在昂贵测试前先过滤候选
使用当前一手文档核对:
- 所需模态与语言是否支持;
- 精确模型和端点是否可用;
- 该端点的上下文与输出限制;
- 数据保留、训练用途、驻留和删除条款;
- 许可证与再分发条件;
- 限流、配额、流式、取消和 Batch 行为;
- Tool Calling 或约束输出能力;
- 运维责任与回滚路径。
不能根据模型家族名推断这些属性。名称接近的两个端点,快照、限制、策略和 Serving Stack 都可能不同。把来源 URL 与核验日期写入评测记录,不要把它们固化成产品代码里的永久事实。
带不确定性地比较质量
让所有候选使用同一批案例和配置规则。对结果具有随机性的关键案例进行多次运行。保留原始输出和评测决定,以便审查争议。
报告至少包括:
- 各任务和风险切片的通过率;
- False Acceptance 与 False Rejection;
- 样本数、置信区间或其他不确定性说明;
- 使用 LLM Judge 时的人机一致性;
- 无效、空白、截断与拒答输出;
- 相对当前生产基线的回归。
聚合分数可能隐藏灾难性切片。整体准确率 96%,但账号接管请求召回率只有 60% 的模型,不是一个“96 分方案”。
用配对结果评估变更
替换生产模型时,对完全相同的输入比较候选。配对结果可以直接回答新方案修复、保持或破坏了什么:
基线通过 -> 候选通过:保持
基线失败 -> 候选通过:修复
基线通过 -> 候选失败:回归
基线失败 -> 候选失败:未解决
应公布回归格子,而不是只展示净平均分。它能说明由哪些用户承担取舍。
计算每个成功结果的总成本
Token 单价只是总成本的一项:
总成本 =
模型输入 + 模型输出 + Cache/Reasoning 用量
+ 检索 + 工具/API 调用 + 审核
+ 存储 + 出网 + 重试 + 人工复核
+ 预留基础设施和运维
每个成功结果成本 = 总成本 / 合格业务结果数
小模型可能需要更多重试,大模型可能生成更长结果,自托管还包含容量、能耗、人员和闲置成本。比较时必须使用相同工作量和服务目标。
时延也应按分布报告。流式应用中的首 Token 时间与 Token 间延迟不同;Agent 系统中,端到端完成时间与工具等待往往比单纯生成速度更重要。
可运行的 Go 门禁
下面的无依赖程序评估已经测得的结果。它不会调用模型,也不虚构通用权重;请用自己的工作负载数据和门槛替换示例 Fixture。
package main
import (
"fmt"
"sort"
)
type Result struct {
Passed bool
CriticalFailure bool
LatencyMS int
CostUSD float64
}
type Candidate struct {
Name string
Results []Result
}
type Summary struct {
Name string
Eligible bool
Passed int
Total int
P95LatencyMS int
TotalCostUSD float64
CostPerSuccess float64
}
func summarize(candidate Candidate, minPassRate float64, maxP95MS int) (Summary, error) {
if candidate.Name == "" || len(candidate.Results) == 0 {
return Summary{}, fmt.Errorf("candidate needs a name and results")
}
latencies := make([]int, 0, len(candidate.Results))
passed := 0
criticalFailures := 0
totalCost := 0.0
for i, result := range candidate.Results {
if result.LatencyMS < 0 || result.CostUSD < 0 {
return Summary{}, fmt.Errorf("result %d has a negative measurement", i)
}
if result.Passed {
passed++
}
if result.CriticalFailure {
criticalFailures++
}
latencies = append(latencies, result.LatencyMS)
totalCost += result.CostUSD
}
sort.Ints(latencies)
p95Index := (95*len(latencies) + 99) / 100
p95 := latencies[p95Index-1]
passRate := float64(passed) / float64(len(candidate.Results))
costPerSuccess := 0.0
if passed > 0 {
costPerSuccess = totalCost / float64(passed)
}
return Summary{
Name: candidate.Name,
Eligible: criticalFailures == 0 && passRate >= minPassRate && p95 <= maxP95MS,
Passed: passed,
Total: len(candidate.Results),
P95LatencyMS: p95,
TotalCostUSD: totalCost,
CostPerSuccess: costPerSuccess,
}, nil
}
func main() {
candidates := []Candidate{
{Name: "baseline", Results: []Result{
{Passed: true, LatencyMS: 900, CostUSD: 0.018},
{Passed: true, LatencyMS: 1100, CostUSD: 0.020},
{Passed: false, LatencyMS: 800, CostUSD: 0.017},
}},
{Name: "candidate", Results: []Result{
{Passed: true, LatencyMS: 700, CostUSD: 0.010},
{Passed: true, LatencyMS: 760, CostUSD: 0.011},
{Passed: true, LatencyMS: 820, CostUSD: 0.012},
}},
}
for _, candidate := range candidates {
summary, err := summarize(candidate, 0.80, 1200)
if err != nil {
panic(err)
}
fmt.Printf(
"%s eligible=%t passed=%d/%d p95_ms=%d cost_per_success=$%.4f\n",
summary.Name,
summary.Eligible,
summary.Passed,
summary.Total,
summary.P95LatencyMS,
summary.CostPerSuccess,
)
}
}
预期输出:
baseline eligible=false passed=2/3 p95_ms=1100 cost_per_success=$0.0275
candidate eligible=true passed=3/3 p95_ms=820 cost_per_success=$0.0110
三个 Fixture 足以解释计算,却不足以批准生产模型。样本量和不确定性方法应与决策风险匹配。
同时评测安全、隐私与运维
质量测试之外,还要加入:
- 直接与间接 Prompt Injection;
- Secret、个人数据与跨租户访问;
- 不支持的工具调用,以及审批后参数发生变化;
- 超时、取消、重试、重复投递与部分结果;
- 配额耗尽与供应商故障;
- 日志、删除与审计导出;
- 面向用户产品的无障碍和人工接管。
NIST AI RMF把可信性视为有效可靠、安全、韧性、隐私、透明、可解释与公平等属性的情境化组合。通过其中一项,不能推导其他项也已通过。
用门禁决策,再渐进发布
保存一份决策记录:
{
"workload": "support-ticket-resolution",
"candidate": "provider/model@revision",
"fixture_set": "support-eval-v12",
"prompt_revision": "sha256:...",
"evaluator_revision": "rubric-v5",
"hard_gates": {
"critical_safety_failures": 0,
"policy_accuracy_min": 0.94,
"p95_latency_ms_max": 2500
},
"result": "shadow_only",
"missing_coverage": ["voice", "new-market-locale"]
}
发布顺序应为离线回放、影子流量、低风险灰度、受限生产,再逐步扩大。新组合在真实负载下满足质量和运维门禁前,保留旧路线。模型、Prompt、工具或检索发生变化,都会产生新的 Bundle,需要定向复测。
常见失败模式
- 未定义工作负载就开始排名产品;
- 把通用 Benchmark 平均值直接写进业务决策;
- 同时改变 Prompt、工具和样本,却把结果归因于模型;
- 把模型 Confidence 当成校准概率;
- 只优化 Token 单价,忽略失败任务与人工复核;
- 未核对数据条款和地区可用性就选产品;
- 把“OpenAI-compatible”误认为行为完全兼容;
- 只测试正常英文输入;
- 没有影子证据和回滚就全量切换;
- 只记录赢家,不保存版本、失败案例和覆盖缺口。
实施检查清单
- [ ] 定义用户结果、不可接受的失败和硬约束。
- [ ] 记录完整的产品—模型—Prompt—工具—检索组合。
- [ ] 构建真实、留出、双语、对抗和故障 Fixture。
- [ ] 能确定性判断时不用主观 Judge,并校准人工与模型评分。
- [ ] 报告分切片结果、样本数、回归和覆盖缺口。
- [ ] 测量时延分布与每个成功结果的成本。
- [ ] 核验隐私、许可证、区域、保留、删除和可替换性。
- [ ] 测试超时、取消、重试、配额和供应商故障。
- [ ] 通过回放、影子、灰度和可回滚生产逐步发布。
- [ ] 任一关键组件变化后触发重新评估。
常见问题
团队应该怎样选择 AI 工具?
先定义任务人群、不可接受的失败、法律和运维硬约束,以及通过所需证据。昂贵评测前先淘汰不合格候选,再让剩余方案处理完全相同的案例;关键门禁有一项未通过,就不能用平均分补偿。
公开 AI Benchmark 足以支持模型选型吗?
不够。它们适合发现候选和理解外部位置,但任务、Prompt、语言、模型快照与指标可能都不同于实际产品。应把公开结果作为一层证据,并增加独立留出的生产形态评测。
哪个成本指标最有用?
每个合格业务结果的成本比每 Token 单价更有意义。它会把重试、下游调用、失败任务、人工复核和基础设施一起纳入,而不是只看一次请求。
一次应该评测多少个候选?
保留能代表不同假设的最小集合即可,通常包括当前基线、低成本候选,以及更高能力或不同部署方式的候选。只有新候选可能改变决策时,增加实验才值得。
什么时候需要重新评估?
模型、端点、Prompt、工具、检索源、政策、价格或用户分布变化后,都应触发定向复测。即使配置中的模型名没变,事故或生产指标持续漂移也构成重评条件。
相关资源
一手资料
- NIST ARIA 评测规划手册
- NIST AI 风险管理框架
- Stanford CRFM:HELM 整体语言模型评测
- Microsoft:为工作负载选择合适的 AI 模型
- AWS:Beyond Vibes 模型选型方法
总结
最合适的 AI 工具,是满足特定工作负载契约时,规模最小、安全可控且可运维的完整组合。公开 Benchmark 用于发现候选;真实任务集、硬门禁、总成本、对抗测试和渐进发布才产生选型结论。保留证据和失败样本,让下一次复评从事实出发,而不是重新制作一张产品排行榜。