怎样判断 AI 应用是否可靠：评估、质量、成本与延迟

01 / 定义：评估是固定条件下的比较

一次评估包含任务、样本、预期或评分规则、实际运行结果和比较方式。它回答的是“在这些条件下表现怎样”，不能自动推出所有场景都可靠。样本来源、时间、难度和版本决定结论适用范围。

继续用工单分类助手。分类正确、输出结构正确、没有越权、响应及时是不同维度。即使分类准确率很高，只要把外项目数据泄露出去，仍不符合业务要求。关键边界应设为必须通过项，不能用平均分抵消。

02 / 推导：从失败成本反推指标

先问错误会造成什么后果。把普通问题分错类可能只是增加一次人工转派；把紧急问题漏掉可能带来更大损失。两者不能仅用一个总准确率表达。还需要关注各类别的漏判与误判。

• 质量：结构通过率、分类正确率、关键类召回、人工改写比例。
• 安全边界：越权读取、未经允许的动作、数据泄露等独立检查。
• 成本：整条任务链的模型、检索、工具与重试成本，而不只看一次请求。
• 延迟：用户等待整个任务的时间，同时看分位数和超时比例。

长尾延迟描述慢请求的体验。平均一秒不意味着每个人都一秒；某些复杂任务可能等待很久。指标定义必须写清时间从哪里开始、到哪里结束。

03 / 应用：建立第一份可复跑评估集

1. 收集真实失败类型。从脱敏工单中选明确样本、模糊样本、空输入、恶意指令和少数重要类别。演示时可以用小样本，上线判断需要与真实流量匹配的覆盖。
2. 先人工标注。每条保存 ID、输入、期望类别、理由和是否存在歧义。标注有争议时先统一业务口径，不让模型替你决定真值。
3. 拆分开发与保留集。调提示词时使用开发集，最终比较使用未参与反复调试的样本。反复看同一组答案会使改进过度适应该组样本。
4. 固定运行条件。记录模型版本或标识、提示词版本、工具配置、资料版本和超时策略。否则分数变化可能来自条件变化。
5. 保存逐项结果。不是只存总分。保留解析失败、类别错误、耗时、消耗以及错误理由，才能定位问题。
6. 一次改变一个主要因素。例如先比较两种提示词，再比较模型。若同时换检索和模型，难以知道收益来自哪里。
7. 决定是否采用。先检查硬性边界，再看质量提升是否值得成本与等待；保留旧方案和回退条件。

def accuracy(expected, actual):
    if len(expected) != len(actual) or not expected:
        raise ValueError("样本必须非空且一一对应")
    return sum(a == b for a, b in zip(expected, actual)) / len(expected)

# 仅为指标计算示例，不是模型实测结果
assert accuracy(["login", "billing", "other", "login"],
                ["login", "other", "other", "login"]) == 0.75

四条样例中的 75% 只是计算示意，不能证明应用达到某个质量水平。真实结论必须基于实际运行，而且要报告样本量与覆盖限制。

04 / 验收与扩展：避免评估自己骗自己

上线后建立最小观测面：请求关联号、失败类型、耗时、人工纠正和版本。对高敏感内容保存必要统计或脱敏摘要，而不是默认记录全部正文。监测发现问题后，要能暂停相关能力、退回人工或回滚配置。

评估也需要更新。新的真实失败先进入开发回归集，定期补充新的保留样本。不要让测试集成为只能背答案的固定考试。

05 / 迁移：把“可靠”变成可讨论的条件

用于知识问答时，重点变成证据支持与资料覆盖；用于代码修改时，重点变成行为测试、差异与回归；用于外部操作时，还要检查权限、幂等和回执。框架可以复用，指标不能照抄。

团队如何把指标用于推广，见组织落地。评估最终服务的是一个明确决策：采用、限制、继续改进，或者不使用。