Evaluation

很多 AI 项目一开始做优化时，最容易出现的一种状态是：

1. 调了 Prompt
2. 换了模型
3. 改了检索参数
4. 甚至把流程都改了

最后大家只能说一句：

感觉比之前好一些。

这句话在工程里通常是不够的。
因为只要没有评估，你就很难知道系统是真的变好了，还是只是某几个样例碰巧看起来更顺。

1. Evaluation 到底是什么

Evaluation 直接看成：

用一套可重复的方法，判断 AI 系统现在的效果到底怎么样。

它解决的不是系统能不能跑，而是：

1. 答得对不对
2. 召回准不准
3. 结构稳不稳
4. 任务有没有真正完成

所以评估的核心价值，是让优化从“感觉”变成“有依据”。

2. 为什么 AI 系统特别离不开评估

因为 AI 系统的变化源太多了。

你随便动一个地方，都可能影响最终结果：

1. 模型版本
2. Prompt 写法
3. 上下文组织
4. 检索召回数量
5. 重排策略
6. 工具调用规则

如果没有评估，后面很容易变成：

1. 改了很多
2. 看了几个案例
3. 觉得还行
4. 然后上线

这种方式在 Demo 阶段还能勉强用，到了真实项目里就很危险。

3. 一套最小评估链路怎么理解

flowchart LR
    A[准备样本集] --> B[跑系统]
    B --> C[收集输出]
    C --> D[按指标打分]
    D --> E[对比改动前后]
    E --> F[决定是否继续上线]

这条线看起来简单，但它已经把最关键的事情说清楚了：

1. 先准备样本
2. 再统一跑
3. 再用同一套标准比较

没有这三步，很多优化都很难沉淀下来。

4. 常见评估维度有哪些

不同场景关注点不同，但常见维度通常包括：

1. 答案正确性
2. 检索命中质量
3. 工具调用成功率
4. 结构化输出稳定性
5. 任务完成率
6. 用户满意度或人工标注结果

比如：

1. 做知识库问答，更关心召回和答案引用是否靠谱
2. 做结构化抽取，更关心字段准确率和格式稳定性
3. 做 Agent 任务执行，更关心任务完成率、重试次数和失败位置

5. 评估不只是一种

工程里更常见的是把评估分成两类看：

5.1 离线评估

也就是先准备一批样本，在固定环境里统一跑。

它的好处是：

1. 便于对比版本
2. 适合做回归测试
3. 能更稳定地观察改动影响

5.2 在线评估

也就是系统上线后，继续观察真实请求表现。

它更适合看这些变化：

1. 用户真实感受有没有变好
2. 新场景里有没有出现意外退化
3. 成本和延迟是否还能接受

🌟 更稳的做法通常不是二选一，而是离线先收住，再用在线数据继续校验。

6. Evaluation 和 Observability、Tracing 有什么关系

这三个词经常一起出现，但职责不一样。

1. Observability 负责看系统状态
2. Tracing 负责看请求链路
3. Evaluation 负责看效果好坏

可以把它们理解成：

1. 可观测性告诉你系统有没有异常
2. 链路追踪告诉你问题大概出在哪
3. 评估告诉你这次改动到底有没有带来提升

7. 最容易踩的几个坑

7.1 只看几个顺眼样例

这会让系统很容易被“演示效果”欺骗。

7.2 只有离线评估，没有线上观察

这样一旦真实用户输入和样本集差异太大，退化可能要很久才会暴露。

7.3 指标很多，但没有核心判断标准

工程上不是指标越多越好，而是要先知道当前阶段最关心什么。

8. 一段更稳的总结

Evaluation 解决的是“系统到底有没有变好”这个问题。它让模型、检索、Prompt、工具调用这些改动有了统一比较标准，也让优化不再停留在主观感觉上。很多 AI 项目后面做不稳，不是因为没人调，而是因为一直在调，却没有一套像样的评估方式。