为什么“通常可用”对AI而言远远不够
许多企业仍然像验收传统软件一样评估AI：原型展示令人满意，少量内部测试通过，随后直接上线。对于确定性软件，这种方式可能可行；对于生成式AI和AI代理，它远远不够。
传统系统在相同输入下通常返回相同结果。大语言模型具有概率性，措辞、上下文、模型版本、检索文档和配置都会影响输出。AI代理更复杂：它规划多步任务、调用工具、收集信息、改变中间状态，并可能通过不同路径完成目标。早期的一个小错误可能在整个工作流中放大。
因此，管理层真正应该提出的问题不是：“模型是否足够聪明？” 而是：“我们能否证明整个系统在真实条件下可靠、经济，并始终遵守既定规则？”
系统化AI评估能够回答这个问题。它让质量可见、建立发布门槛，并将技术性能与业务成果连接起来。对于预算有限的中小企业尤其重要：企业没有空间承受长期试错，而一个失控的AI流程就可能损害客户关系、合规或核心运营。
AI评估的真正含义
AI评估，通常简称为 Evals，是用于测量、比较和持续改进AI系统的可重复过程。评估对象并不只是基础模型，而是由提示词、上下文、检索、数据、工具、业务规则、用户界面和人工监督共同构成的完整系统。
NIST AI Risk Management Framework明确要求将可信性纳入AI系统的设计、开发、使用和评估。该框架将治理、场景映射、测量和管理结合起来，并把监控视为持续责任，而不是一次性验收。1 因此，AI应用永远不会“永久测试完成”。模型、数据和使用方式持续变化，风险也会变化。
对于AI代理，评估范围进一步扩大。Databricks将代理评估描述为贯穿实验、离线测试和生产监控的全生命周期能力。企业不仅要评估最终结果，还要评估规划、信息检索、工具调用、中间决策，以及多次运行时的稳定性。2
AI系统的四层质量结构
| 质量层级 | 核心问题 | 典型指标 |
|---|---|---|
| 输出质量 | 回答是否正确并对用户有帮助？ | 正确性、相关性、完整性、事实依据、语气 |
| 过程与轨迹质量 | 系统是否采用了正确路径？ | 检索质量、工具选择、参数正确性、步骤数量、规则遵守 |
| 运营质量 | 系统是否稳定、快速且经济？ | 延迟、错误率、重复稳定性、Token消耗、每次成功处理成本 |
| 业务影响 | AI是否改善相关业务KPI？ | 周期时间、转化率、首次解决率、错误成本、升级率、采用率 |
这些层级彼此依赖。内容正确但耗时过长、成本超标的答案，在运营上仍不合格。能够完成正确交易但访问了未授权数据的AI代理不能上线。回答质量很高但无人使用的聊天机器人也无法创造商业价值。
为什么公共基准不足以支持业务决策
模型供应商通常发布数学、编程、知识和推理基准。这些数据适合做初步比较，却无法证明系统能否可靠完成企业自己的流程。
一个在公共基准上领先的模型，仍可能混淆内部产品代码、建议不合适的合同条款，或对本地语言的客户请求使用错误升级规则。企业质量高度依赖具体情境，必须使用来自自身流程的真实案例进行测量。
因此，每个生产AI系统都需要一份质量契约：明确什么是好结果、哪些错误可以容忍、哪些错误绝不能发生，以及在哪个阈值下必须转交人工处理。
面向中小企业的Eval Operating System
务实的AI质量管理由七个模块构成，它们共同形成可嵌入现有AI治理和运营评审的 Eval Operating System。
1. 定义质量契约与风险边界
起点不是工具，而是管理决策。业务负责人、领域专家、IT以及必要时的数据保护和合规团队共同定义质量目标。内部营销助手的一句不当表达容易修正；处理支付数据或生成具有法律意义内容的系统则需要严格得多的边界。
质量契约至少应明确目的、允许与禁止的任务、关键错误类型、目标指标、最低阈值、升级规则和责任人。
2. 建立Golden Dataset
Golden Dataset 是一组经过筛选的代表性测试案例，包括常见请求、困难边缘场景、已知故障模式，以及在可能情况下提供的预期答案或评分标准。开始阶段，50到100个高质量案例通常足够。覆盖风险比数量更重要。
| 测试类别 | 目的 | 示例 |
|---|---|---|
| 正常案例 | 测量日常表现 | 现有客户的标准请求 |
| 边缘案例 | 检查少见但合理的情况 | 信息不完整或相互矛盾 |
| 风险案例 | 测试规则与安全边界 | 索取机密客户数据 |
| 回归案例 | 防止已知错误再次出现 | 旧版本曾错误处理的案例 |
Golden Dataset应从生产中持续成长。重要投诉、人工纠正和升级案例都可以转化为新的回归测试，从而将运营经验沉淀为长期质量知识。
3. 每次变更前执行离线Evals
在真实用户受到影响之前，离线Evals使用同一个Golden Dataset测试新的提示词、模型、知识库或代理逻辑，并与当前生产版本比较。只有达到最低阈值且关键类别没有退化，变更才能发布。
这种发布门槛可以避免常见问题：某次优化提高平均表现，却悄悄损害一个重要边缘场景。没有标准化比较，质量就会退化为个人主观判断。
4. 组合确定性测试、LLM-as-a-Judge与人工审核
没有单一方法可以覆盖所有质量问题。
确定性测试适合客观标准：是否调用正确工具？必填字段是否存在？输出是否符合Schema？是否使用了禁止的数据源？这类测试速度快、成本低且可重复。
LLM-as-a-Judge 使用一个语言模型，根据评分规则评价开放式输出，例如相关性、语气或完整性。它比纯人工审核更易扩展，但自身也可能带来偏差和不一致，因此必须使用人工判断进行校准。
人工审核对于专业细节、新型错误、伦理权衡和高风险案例仍不可替代。合理策略应基于风险：高容量场景使用自动评分，普通案例进行人工抽样，关键决策必须人工批准。
5. 建立生产Tracing与Observability
离线测试无法覆盖所有真实情况。生产系统必须能够追踪用户请求、提示词、模型及版本、检索来源、工具调用、参数、中间错误、最终回答、延迟和成本。
这条执行轨迹对AI代理尤其重要。反复出现的错误包括虚构工具调用、无限重试、参数错误、缺失上下文、过时记忆以及不必要的操作。2 没有Tracing，企业只能看到结果，却看不到原因。
Observability也必须符合隐私要求。日志可能包含个人或机密信息，因此保存期限、脱敏、访问权限和删除规则都应纳入数据保护设计。
6. 联合管理质量、成本与业务影响
AI团队经常优化技术指标，而管理层关注生产力和业务结果。统一Scorecard可以消除这种脱节。
| 视角 | 核心指标 | 管理问题 |
|---|---|---|
| 质量 | 正确性、事实依据、任务完成率 | 系统是否稳定地产生可用结果？ |
| 风险 | 规则违规、关键错误、未授权访问 | 系统是否始终在边界内运行？ |
| 运营 | 延迟、可用性、重复稳定性 | 系统能否应对日常业务量？ |
| 经济性 | 每次成功处理成本、返工时间 | 它是否比替代方式更经济？ |
| 业务 | 周期时间、收入贡献、服务质量 | 它是否改善优先业务KPI？ |
每次成功处理成本尤其重要。每个Prompt或Token的成本可能产生误导。如果员工必须修改每个结果，一个便宜模型反而很昂贵。能够首次正确完成任务的高性能模型，在整体上可能更经济。
7. 建立持续改进周期
即使代码没有变化，AI质量也可能变化。新文档会影响检索，用户会提出不同问题，数据结构会改变，供应商也会更新模型。NIST强调了已部署AI系统监控的特殊挑战，因此持续观察至关重要。3
适合中小企业的节奏包括：每周检查异常案例；每月由业务负责人审查Scorecard；每季度重新评估风险、阈值和模型策略。关键事件应立即触发根因分析和新的回归测试。