在人工智能项目开发中，常常会遇到这样的情况：团队在构建生成式AI应用时，往往在项目后期才开始重视自动化评估（evals）的构建，而在此之前，他们更倾向于依赖人工来审查和判断AI系统的输出结果。究其原因，是由于自动化评估的构建被视为一项巨大的投入，比如需要创建数百乃至数千个示例，并设计和验证相应的评估指标。这种巨大的前期投入让团队总是觉得没有合适的时间去做这件事。然而，我建议团队转变思路，将构建评估视为一个迭代的过程。即使从一个快速而粗糙的实现开始（例如，仅有5个示例和未经优化的指标），然后逐步迭代和改进，也是完全可行的。这样做，可以逐渐将评估的负担从人工转移到自动化评估。
正如我之前在一篇文章中提到的，创建高质量的评估至关重要，但同时也充满挑战。假设你正在构建一个客户服务聊天机器人，它可以自由文本的形式回复用户。由于没有唯一正确的答案，许多团队最终不得不花费大量时间，对每次系统更新后的输出结果进行人工审核，以判断系统是否有所改进。虽然像“LLM-as-judge”这样的技术有所帮助，但要使其发挥作用，需要对诸多细节进行微调（例如，使用什么提示语、为评估者提供什么上下文等）。所有这些都加深了人们的印象，即构建评估需要大量的前期投入。因此，在任何特定的一天，团队都可能觉得依赖人工评估比费力构建自动化评估更能取得进展。
我鼓励大家以不同的方式看待评估的构建。即使构建的快速评估只能对系统性能进行部分、不完整和有噪音的测量，也是可以接受的，并且可以通过迭代来改进它们。它们可以作为人工评估的补充，而不是替代品。随着时间的推移，你可以逐渐调整评估方法，以缩小评估输出与人工判断之间的差距。例如：
- 可以从评估集中非常少的示例开始（比如5个），然后随着时间的推移逐渐添加。或者，如果你发现某些示例过于简单或过于困难，对区分不同版本的系统性能没有帮助，可以将其删除。
- 可以从仅测量你关心的部分性能维度开始，或者测量你认为与系统性能相关但不完全捕获系统性能的狭窄线索。例如，如果你的客户支持代理在对话的某个时刻应该 (i) 调用API来发放退款，并且 (ii) 生成适当的消息给用户，你可以首先只测量它是否正确调用了API，而不用担心消息的内容。或者，如果你的聊天机器人应该在某个时刻推荐特定的产品，一个基本的评估可以测量聊天机器人是否提到了该产品，而不用担心它说了什么。
只要评估的输出与整体性能相关，那么在开始时只测量你关心的事物的一个子集是可以的。
因此，开发过程包括两个迭代循环，你可以并行执行它们：
- 迭代系统以使其表现更好，这可以通过自动化评估和人工判断相结合来衡量；
- 迭代评估以使它们更符合人工判断。
与人工智能领域的许多事情一样，我们常常无法第一次就做对。因此，最好快速构建一个初始的端到端系统，然后迭代改进它。我们已经习惯于采用这种方法来构建人工智能系统。我们可以用同样的方式构建评估。
对我来说，一个成功的评估需要满足以下标准。假设我们目前有系统A，我们可以对其进行调整以获得系统B：
- 如果根据熟练的人工判断，A比B明显更好，那么评估应该给A一个明显高于B的分数。
- 如果A和B的性能相似，它们的评估分数应该相似。
每当系统A和B的配对与这些标准相矛盾时，就表明评估存在“错误”，我们应该调整它以使其正确地对A和B进行排名。这与构建机器学习算法中的错误分析类似，只不过我们关注的是评估的“错误”，而不是机器学习算法输出的错误（例如，当它输出不正确的标签时）。例如，当它们错误地对两个系统A和B进行排名时，因此评估在选择它们之间没有帮助。
纯粹依赖人工判断是启动项目的绝佳方式。但是对于许多团队来说，将评估构建为一个快速原型并迭代到更成熟的东西可以让你更早地进行评估并加速你的进度。
精益求精！
Andrew
