文章系统讲解了如何从主观 vibe-check 过渡到可量化的 LLM 评估流程,包括构建 eval set、定义具体指标、AB 测试等实操步骤。
每一个 LLM 项目都会撞上同一堵墙:你改了一个 prompt,输出"看起来更好"了,你上线了——但你根本不知道自己是真正改进了什么,还是只是把问题挪到了你没看到的地方。"看起来不错"不是一种指标。
评估是 LLM 开发中最无趣、却最具决定性的环节。能交付可靠产品的团队,是那些学会了如何测量质量、而不是凭感觉判断质量的团队。以下是具体做法。
传统软件有确定性测试:给定输入 X,断言输出 Y。LLM 打破了这个模式。输出是开放的、不确定的,而且往往有多种有效形式——没有唯一正确的字符串可以断言。"总结这篇文章"有一千个好的答案,没有一把确切的钥匙。这就是为什么本能反应是随便读几个输出然后凭感觉检查——也是为什么这种本能无法在 demo 之后扩展。
你通过几个步骤从轶事走向测量:
构建评估集。收集一组固定的代表性输入——包括奇怪的边缘案例和过去的失败。这就是你的测试套件。一旦你有了它,"这次改动有用吗"就变成了一个可以回答的问题,而不是一种感觉。
具体地决定"好"意味着什么。不同任务需要不同的衡量方式。对于有正确答案的任务(分类、提取),你可以对精确匹配或近似匹配打分。对于开放式任务,你需要定义标准:它是否基于来源?是否相关?是否在正确的格式中?模糊的质量变成了具体的、可检查的属性。
使用正确的评分器。有些东西可以用代码检查——它是否是有效的 JSON,是否包含必需的字段,数字是否正确。对于更微妙的品质,一个越来越流行的做法是 LLM-as-judge:用一个强大的模型,结合仔细的评分标准,来大规模地对输出打分。它不完美,需要根据人类判断来验证,但这是在不手动阅读所有内容的情况下评估数千个开放式回答的方式。
警惕回归。每次有意义的改动都运行评估集。那个修复了一个问题的"小 prompt 调整"可能破坏了其他三个——如果没有评估,你就会盲目上线。
最重要的纪律是对自己的数字保持诚实。设计一个让你看起来不错的评估非常容易——用简单的案例测试,选用宽松的标准,悄悄忽略那些失败。一个被你操纵来通过的指标什么也告诉不了你。一个你信任的、不好看的数据比一个你无法信任的、漂亮的数据更有价值。这个原则贯穿我构建的一切,从 LLM 系统到机器学习模型,我在评估上坚持同样的底线。
不要再问"这个输出看起来好吗?",开始问"我的评估集得分是多少,有提高吗?"第一个是感觉;第二个是工程。每一个严肃的 LLM 产品都是建立在第二个问题之上的。
测量是把"我觉得它更好了"变成"它确实更好了,以下是具体提高了多少"。更多关于我的方法论见 www.divyakush.com。