十一、Eval(评估)⭐ 决定能否上生产

AI 输出不确定、无标准答案 → 不能像普通代码测对错,只能"评好坏"。 没 Eval,优化全靠感觉,改好一个可能弄坏三个都不知道。

为什么不能用普通测试

不确定(采样随机)+ 开放式(无唯一解)+ 难量化。

四种评估方法

1. 人工评估:按评分标准(Rubric)打分。最准但慢,适合早期/定标准。
2. 自动指标:精确匹配(分类/抽取)、embedding相似度。适合有明确对错的。
3. LLM 当裁判(LLM-as-Judge)⭐ 主流:用另一个AI给答案打分,能规模化评开放式回答。关键场景仍要人抽检。
4. 生产信号:A/B测试、用户点赞点踩、是否追问/放弃。

核心:评估集(Golden Set)

攒一批"代表性测试用例"(问题 + 期望要点,30-100条)。每次改动跑一遍,看整体质量变化 = AI版回归测试。

评估维度

维度	看什么
准确性	答得对不对
相关性	有没有答到点上
忠实度 Faithfulness ⭐	基于资料、没瞎编(RAG 最关键)
格式合规	是否按要求结构输出
安全性	有无有害/越界
成本&延迟	token/速度

RAG 专项:两段分开评

① 检索对不对(Retrieval):有没有找到对的资料?找错了后面白搭
② 生成好不好(Generation):拿到对资料后,答得准不准、忠不忠于资料?

RAG答错,先查是"没找到"还是"找到了但答歪"——病因不同,药不同。

评估驱动开发闭环 ⭐

建评估集 → 跑基线分数 → 改进(prompt/检索/切块) → 再跑对比
→ 变好保留 / 变差回退 → 循环

别过度工程

起步:人工 + 10-30条,眼睛看(能发现80%问题)→ 成长:加LLM裁判、扩到50-100条 → 成熟:接生产反馈/A-B/监控。

---

---