AI 评估的艺术

原文来自 Jeff Nyman 的博客，探讨了针对 AI 测试应该进行的思路转变和评估原则。翻译出来分享一下

超越模型本身：AI 评估的艺术

当我们谈论“ AI测试”时，大多数人首先想到的是大语言模型本身。他们往往聚焦于“引擎”，却忽略了“载具”。然而，在定制化企业应用的背景下，我们测试的不仅仅是一个模型，而是一个完整的系统。

这一点至关重要！越来越多的企业正依赖将 AI 融入其应用程序中。但通常情况下，他们并非在构建一个仅仅让用户与机器人“聊天”的简单架构。相反，他们正在构建复杂的架构，其中 AI 只是庞大机器中的一个组件。具体而言，企业正通过一些已非常明确的模式来利用 AI：

检索增强生成（RAG）： 您可以将其视为 AI 的“图书馆”。模型不再仅仅根据训练数据进行猜测，而是在“发言”前被强制查找特定的公司文档（即“事实来源”）。
代理工作流： 这里，AI 扮演了“项目经理”的角色。它被赋予一个目标，并被允许使用工具（如查询 SQL 数据库、搜索网页或调用 API）来完成多步骤任务。
结构化输出管道： 在此场景下，AI 充当“数据翻译官”。它接收杂乱、非结构化的人类文本，并将其转化为干净、可执行的代码或 JSON，供业务软件的其他部分理解。

在传统软件测试中，我们倾向于寻找“决定性”：即“如果我点击 X，Y 必须发生”。而在 AI 测试中，我们处理的是“随机性”（即基于概率的结果）。由于 AI 可能会用三种不同的方式来描述同一个事实，我们的测试不能仅仅依赖寻找精确的文本字符串。我们必须测试其意图、准确性和逻辑。

这就是“评估者”概念登场的地方。如果 LLM 是提供证词的证人，那么评估者就是核对证词与物证的法医鉴定专家。我们测试的不是 AI 是否“聪明”，而是测试系统是否忠实于数据，以及是否与用户的需求相关。

区分模型的通用能力与其具体应用是非常有帮助的。

如果非要打个比方，我会说测试原始 LLM 就像测试厨师刀的质量；而测试一个 AI 应用则像品尝最终的“红酒炖牛肉”。一把锋利的刀是必要的（或者至少非常有帮助！），但这并不能保证炖出的菜不会太咸。

评估这些融合了 AI 的应用程序，需要我们关注该背景下输出质量的“三大支柱”：

为了规模化处理这些问题，我们可以使用专门的工具，如 DeepEval 或 RAGAS。这些工具采用了一种通常被称为“LLM-as-a-Judge”（以 LLM 为评判者）的元认知方法。坦白说，我不确定这是否是一个好名字。我更愿意将其视为对对话的“司法鉴定”。

我的意思是，我们使用一个次要的、通常更强大的模型来充当客观的评估者。它会查看“证据”（检索到的上下文）和“判决”（生成的答案），以确定逻辑是否站得住脚。这使我们能够将定性的人类直觉转化为定量的、可复现的指标，例如上下文召回率和答案正确性。

关于这个话题，我还有很多话要说，但在这里，我想做的是“展示”而不仅仅是“讲述”。我能说的是，我们正在从一个“凭感觉测试”的世界（即我们只是问 AI 几个问题，看看是否喜欢答案）迈向一个拥有严谨评估者的世界。虽然您可能不直接测试 LLM，但您正在测试特定领域内对给定模型力量的管控能力。

我认为，对于那些正在与选择将 AI 作为运营一部分（无论是否面向客户）的公司合作的测试专家来说，这很大程度上构成了他们的伦理使命。

就个人倾向而言，我是一个托马斯主义者。用托马斯主义的术语来说，LLM 是“质料因”（即原始的潜力），而您的应用则是赋予其特定形状和目的的“形式因”。仅仅测试 LLM，就像在研究大理石的属性，而您本该评估的是用这大理石建造的大教堂的结构完整性。

因此，为即将到来的内容做铺垫，本系列文章将介绍那些帮助我们“审视大教堂”的概念和工具。这需要读者稍微深入钻研一下。我将主要（甚至完全）使用 Python，并向测试人员展示如何结合这些更广泛的概念实际使用这些工具。

我需要指出，我认为这是现代测试领域完全空白的一块。我看到很多人对 AI 大声疾呼表示担忧（或许是合理的），但很少有人真正去学习如何使用这些工具，从而在这个已经到来的未来中提升自己的市场竞争力。

之前我曾谈到过关于“错误专家”的伦理使命。众所周知，AI 会犯错。事实上，Claude 就会在您提交的任何提示词底部直接告诉您这一点。

ChatGPT 也是如此。

这很棒！自我意识是一件好事。但这留下了一个问题：我们如何规模化地“复核回复”并“核实重要信息”？对于那些希望保持领先优势的测试人员来说，这是一片绝佳的阵地。

因此，我们的伦理使命不仅没有被移除或取代，反而实际上扩大了。作为“错误专家”，我们的关注领域也随之增长。