SH

Soloharness

概念 · 辨析 · Agent

← 返回概念辨析

Concept Contrast Fable

真人坐下来判断质量和用另一个大模型来打分

人工评估是让真实用户或领域专家对模型输出做逐条判断——准确性、流畅度、安全性、偏好排序。LLM 评测平台是用另一个大模型作为评判器,给定评分标准和参考答案,对目标模型输出自动打分。两者都是质量度量,但数据来源和置信度不同:人工评估反映真实用户感受但慢且贵,自动评测快且一致性强但可能带评判器自带的偏好偏差。把自动评测当人工评估的平替做客户汇报,等于用一个模型证明另一个模型,逻辑上没有独立的锚点。

寓言

食肆里的两种试菜:一种是真人食客坐下来尝,一种是让另一个厨子先品

老食肆出菜前有两套品菜流程。第一套是食客桌——每天中午在门口支一张长桌,请六位回头客坐下来吃三道新菜,吃完每道菜打分、写评语。食客有吃辣不吃辣的、有北方人和南方人、有喜欢口感脆的和喜欢入口软的。六个人六种舌头,但评语真实——“这道东坡肉太甜了,不够咸香”,“鱼片切厚了,一筷子夹起来往下坠”。

第二套是厨子会——每周一次,请对面馆子的老厨子过来,给他一本评分手册,让他坐在厨房里试菜。手册上列了刀工、火候、调味、卖相四个维度各十分。老厨子三分钟试一道,十分制出分,末尾给一行评语。效率高,厨房不耽误,但评语总是那几种口味:“咸甜比例尚可”“火候略过”“摆盘有待改进”。

食肆掌柜开始用厨子会的分数来调整菜单。老厨子打了高分的菜推上了招牌榜,结果客人点单率反而低了。回访发现老厨子对辣度的容忍很低,所有带青椒的菜他下意识压分,“火候略过”的评语重复出现。但本地客人恰恰喜欢带锅气的辣炒菜。厨子的口味把菜单调偏了。

掌柜又做了一次对照实验。同一周上新的五道菜,食客和厨子各打一组分。有两道菜厨子给的分比食客低了一截——还是辣度的问题。有一道甜汤厨子给了满分,食客那边因为太甜反而分数中等。掌柜意识到厨子的舌头受过专业训练,对标准做法很敏感,但对本地口味的感知和普通食客是两套系统。

调整后的品菜制度变成了两线并行。食客桌每周照开,负责判断菜受不受欢迎、会不会有人点。厨子会保留,但不再给菜单排名投票——改成只查硬伤:生熟问题、食材不新鲜、基本调味失衡。食客管好恶,厨子管底线。两者都叫品菜,但判的是不同层面的质量。

掌柜把新制度写在厨房墙上:食客坐的是客席,脚踩着泥来的,手里拿的是筷子。厨子坐的是品菜位,带着评分手册和清口用的温水,味蕾在找标准和偏差。两套工具没有谁替代谁,拆开用才各有用处。

后来有个投资人问掌柜:你们怎么判断一道菜到底好不好。掌柜把食客打分表和老厨子检查表并排放在桌上,指着同一个菜的两组数据说:食客说这道菜香、下饭,说明它能卖;厨子说这盘菜刀工不均但调味无过,说明它不砸招牌。合在一起才是好不好。

人工评估

由真实用户或领域专家对模型输出做逐条判断和打分,评估维度包括准确性、流畅度、安全性、偏好排序等。优点是反映真实使用感受和长尾场景判断,缺点是慢、贵且评分者之间存在个体差异。

LLM 评测平台

用另一个大模型作为评判器,给定评分标准和参考答案,对目标模型输出进行自动打分和评语生成。优点是快速、一致性好、可大规模并行,缺点是评判器自身的偏好和偏见会嵌入评分结果中。

故事对应

  • 食客桌:人工评估,真实用户多元判断,反映实际偏好和长尾场景
  • 厨子会:LLM 评测平台,用评判器按固定维度标准自动打分
  • 厨子压低了辣菜的分数:评判器的偏好偏见扭曲了评分分布
  • 配对比实验暴露口味差异:自动评测和人工评测之间的系统性偏差
  • 食客管好恶、厨子管底线:两人分工——自动评测看硬伤,人工评测看受欢迎度
  • 掌柜把两张表并排放:完整质量判断需要两种评测互为补充

落到 AI 模型质量评估体系

日常迭代中用 LLM 评测平台做快速质量回归——跑完一次微调马上出分,比人工快几个数量级。但关键版本发布和客户验收前必须上人工评估——找目标用户或领域专家逐条判断。自动评测的分数和人工评估的分数之间有系统性偏差,不要做简单的数值对齐。用自动评测做安全网——查硬伤、查明显退化、查评分波动异常;用人工评估做方向标——查真实偏好、查场景适配、查长期满意度。两份报告分开呈现,各自注明评测方法和误差范围。