在人工智能应用项目中，自动化评估（evals）的重要性日益凸显。许多团队在项目后期才开始关注自动化评估，而在此之前，他们往往依赖人工评估来判断系统的输出质量。这种做法的根本原因在于，构建自动化评估系统被视为一项耗时且高成本的巨大投资。例如，团队可能需要创建数百甚至数千个示例，并设计和验证相应的评估指标。由于前期投入巨大，团队往往难以找到合适的时机来进行这项工作。因此，我建议将构建评估系统视为一个迭代的过程。从一个快速且简单的实现开始，例如，使用5个示例和未经优化的指标，然后随着时间的推移逐步迭代和改进。通过这种方式，可以将评估的负担从人工逐渐转移到自动化评估系统上。
正如我之前所写的那样，创建评估系统至关重要，但也充满挑战。假设你正在构建一个客户服务聊天机器人，它可以自由文本回复用户。由于没有标准的正确答案，许多团队最终不得不花费大量时间，人工审查每次更新后的数十个示例输出，以判断系统是否得到了改进。尽管诸如“LLM-as-judge”之类的技术很有帮助，但要使其正常工作，需要对细节进行微调，例如，使用什么提示、为判断者提供什么上下文等等。所有这些都使得构建评估系统需要大量前期投入，因此，在任何一天，团队都可以通过依赖人工判断来取得更大的进展，而不是弄清楚如何构建自动评估系统。
因此，我鼓励大家以不同的方式构建评估系统。即使快速构建的评估系统只能部分、不完整且有噪声地衡量系统的性能，也可以接受，并可以迭代地改进它们。它们可以作为人工评估的补充，而不是替代品。随着时间的推移，你可以逐渐调整评估方法，以缩小评估输出与人工判断之间的差距。例如：
- 从评估集中非常少的示例开始是可以的，例如5个，并随着时间的推移逐渐添加它们——或者如果你发现某些示例太容易或太难，并且对于区分系统不同版本的性能没有用处，则可以删除它们。
- 从仅衡量你关心的性能维度的一个子集的评估开始是可以的，或者衡量你认为与系统性能相关但不能完全捕获系统性能的狭窄线索。例如，如果在对话的某个时刻，你的客户支持代理应该（i）调用API来发出退款，以及（ii）生成一条适当的消息给用户，你可以首先只衡量它是否正确调用了API，而不必担心消息。或者，如果在某个时刻，你的聊天机器人应该推荐一个特定的产品，一个基本的评估可以衡量聊天机器人是否提到了该产品，而不必担心它说了什么。
只要评估的输出与整体性能相关，那么在开始时只衡量你关心的事物的一个子集是可以的。
因此，开发过程包括两个迭代循环，你可以并行执行它们：
- 迭代系统以使其表现更好，通过自动评估和人工判断的组合来衡量；
- 迭代评估以使它们更符合人工判断。
与人工智能中的许多事物一样，我们通常不会第一次就做对。因此，最好快速构建一个初始的端到端系统，然后迭代以改进它。我们习惯于采用这种方法来构建人工智能系统。我们可以用同样的方式构建评估。
对我来说，一个成功的评估满足以下标准。假设我们目前有系统A，我们可以调整它以获得系统B：
- 如果根据熟练的人工判断，A比B好得多，那么评估应该给A一个比B高得多的分数。
- 如果A和B具有相似的性能，那么它们的评估分数应该相似。
每当一对系统A和B与这些标准相矛盾时，这是一个评估存在“错误”的信号，我们应该调整它以使其正确地对A和B进行排名。这与构建机器学习算法中的错误分析类似，只是我们专注于评估的“错误”，例如当它们错误地对两个系统A和B进行排名时，因此评估在选择它们之间没有帮助，而不是关注机器学习算法输出的错误——例如当它输出不正确的标签时。
仅仅依靠人工判断是开始一个项目的好方法。但对于许多团队来说，将评估构建为一个快速原型并迭代到更成熟的东西，可以让你更早地进行评估并加速你的进展。
继续建设！
安德鲁
