← 返回概念解读

Concept Fable精修版

评测

Evaluation, Evals · LLMOps / quality

先读故事。这里不急着给定义,先让问题自己长出来。

寓言故事

三位师傅都说这把尺最公平

铜桥镇有三家修伞铺。雨季前,镇长想选一家给全镇修伞。三位师傅都拿出样伞,说自己的伞更牢、更轻、更好看。

镇长起初让大家现场展示。第一把伞在小雨里很好,第二把伞在大风里更稳,第三把伞开合最快。围观的人越看越热闹,却没人知道到底该选谁。

助手的天真修补是让每位师傅互相打分。结果他们都挑对方最弱的天气测试,还给自己的伞解释例外。评分表很满,结论却更混乱。

第一批伞发下去后,问题暴露了。老人嫌开伞费力,船夫说海风里会翻,学童发现伞布会把书包染色。铺子在台上赢了,在真实街道上输了。

镇长于是把争论停掉,先写清楚伞要服务哪些人、哪些天气、哪些失败不能接受、哪些指标只是参考。他收集了过去三年最常见的雨天场景,又请不同人群试用。

新的评测不再只看一场表演。它有固定样例、人工判定、耐久测试、成本记录和失败分类。每次改伞,都要跑同一套场景,看看是进步、退步还是只在某个角落变好。

后来,三家铺子都能参加,但不能只带故事来。它们要带数据、错误案例、边界说明和改版对比。镇长也不再问‘哪把伞最聪明’,而问‘哪把伞在我们要的场景里最可靠’。

镇民发现,尺子本身也需要维护。新街道、新人群、新雨季都会让旧测试变得不够用,所以评测集要持续更新。镇长最后明白,评测不是为了证明某把伞完美,而是为了让每一次选择和改动都有可复查的依据。后来镇长每次换伞前先问:这把尺还代表今天的街道吗?若街上多了夜市、桥上风更大,旧测试就要补新场景。他们也开始保留失败样本。某把伞为什么翻、在哪条街翻、谁拿着翻,比胜出的样伞更能告诉工匠下一版该改哪里。

揭示

这个故事讲的是:评测

评测是用人工、规则或模型裁判衡量 AI 系统在任务质量、安全性、稳定性和成本上的表现。企业 Agent 的 evals 应覆盖真实任务、边界场景、回归样例、安全红线、延迟和费用,并与发布流程绑定。没有评测,模型升级、提示词修改、RAG 调整和工具改造都只能靠感觉判断。

它重要的地方在于:它不只是一个术语,而是在真实 AI / Agent 系统里会反复出现的结构性问题。理解它,才能判断什么时候该加模型,什么时候该改流程,什么时候该补治理。

隐喻映射

  • 三家修伞铺:不同模型、prompt、RAG 配置或 Agent 方案
  • 现场展示:demo 和临时人工体验
  • 互相打分:不受控、不一致的主观评价
  • 真实街道失败:生产场景暴露边界问题
  • 固定雨天场景:golden set、benchmark 和 regression cases
  • 人工判定与失败分类:human evaluation、rubric 和 error taxonomy
  • 每次改伞都重跑:CI/CD 中的 eval gate
  • 最后洞察:evals 给 AI 变更提供可复查的质量依据

Soloharness 判断

这个概念的实战价值,是帮你把“看起来聪明的 AI 功能”拆成可交付、可验收、可治理的工作单元。

Benchmarkgolden setregression testLLM-as-judgehuman evaluationred teaming