构建由LLM驱动的应用程序是容易的部分。知道它是否运作良好——并检测何时发生回退——是困难的部分。LLM评估（evals）在大多数使用AI构建的团队中是一个欠发达的实践。以下是需要理解的内容。
为什么Eval很难
由于根本原因，评估LLM输出比评估传统软件更难：LLM输出是非确定性的和高维的。传统代码中的Bug要么存在要么不存在；你运行测试并得到通过或失败。LLM响应是正确的、错误的、部分正确的、在风格上是否合适、在一个上下文中合适而在另一个上下文中不合适——并且在运行之间变化。传统测试范式不适用：你无法写`assert output == “expected answer”`，因为正确答案可以用无限多种方式表达。你无法运行10,000个确定性集成测试，因为每次运行都要花费金钱和时间。常见错误：对你用于提示工程的示例进行评估（过度拟合到你的测试集）；只使用人工评估（无法扩展）；在错误的指标上评估（长度、置信度、流畅度——而不是准确性和任务完成）；以及不测试边缘情况和对抗性输入。
Eval的类型
精确匹配：对于有基准真实值的任务——具有已知正确答案的问答、分类、提取。模型输出是否与预期答案匹配？适用于有限类别的任务。基于标准的评分标准：定义响应必须满足的标准——事实准确性、完整性、适当的语气、没有幻觉——并根据这些标准对响应打分。可以由人工评估员或LLM评审员完成。LLM作为评审员：使用有能力的LLM（通常是GPT-4或Claude）根据定义的标准评估另一个LLM的输出。优点：可扩展，比人工评估更快，对定义明确的标准相当可靠。缺点：LLM评审员有已知偏见（偏好更长的答案，偏好自己的输出风格，可以被提示操纵）。人工评估：主观质量的基准真实——相关性、帮助性、语气。对于校准自动化指标至关重要，但无法扩展。A/B比较：将两个输出呈现给人工评估员或LLM评审员，询问哪个更好，不显示哪个系统产生了哪个（盲比较）。基于参考的：使用语义相似性指标（BLEU、ROUGE、BERTScore）将模型输出与参考答案进行比较——限于存在参考答案的任务。红队/对抗性测试：系统地尝试使模型失败——产生幻觉、产生有害内容、拒绝回答合法请求。应该是任何生产eval套件的标准部分。
构建实用的Eval系统
从黄金数据集开始：50到200个代表你实际用例的示例，标注了预期输出（或标准）。这是任何eval系统的核心。当模型失败时添加案例：每次生产失败都应该成为eval案例。在每次模型更改时自动化你的eval：如果你改变系统提示、模型版本或检索系统，自动运行你的eval并比较分数。跟踪回归而不仅仅是绝对质量：重要的是更改是否使事情变得更好或更差，而不仅仅是绝对分数是什么。衡量你的用户关心的：法律合同起草助手应该在准确性、完整性和没有幻觉方面进行评估——而不是流畅度。客服机器人应该在解决率、升级率和客户满意度方面进行评估。将评估与训练数据分开：如果你的eval使用与你用来调整提示的相同示例，你的eval是无意义的——你在测试模型是否记住了你的示例，而不是它是否泛化。
