Acceptance-Test-Driven Evaluation Protocols for Business-Centric LLM Systems

想象一下，你正在为一家繁忙的办公室构建一个非常聪明但又有点难以捉摸的机器人助手。这个机器人（即大语言模型，简称 LLM）非常擅长写邮件和回答问题，但它有时会编造事实、产生混乱，或者不小心泄露私人秘密。

你分享的这篇论文认为，我们不能仅仅让开发者通过“修修补补”让它看起来表现良好。相反，我们需要把它当作一台高风险机器来对待，在它开始与真人接触之前，必须通过严格的、预先写好的安全与性能测试。

以下是该论文的核心思想，通过一些日常类比进行了拆解：

1. 问题所在：“猜测” vs. “测试”

目前，许多公司在构建这些 AI 系统时，往往只是尝试一个提示词（prompt），看看答案看起来是否还可以，然后就继续下一步。论文指出，这就像是在没有刹车的情况下开车，并寄希望于不会撞到任何东西。你可能偶尔能走运一次，但如果你需要每天安全驾驶，这远远不够。

论文提出了一种新方法，称为验收测试驱动开发（ATDLLMD）。你可以把它理解为：在建造汽车之前，先写好交通规则。

2. 新方法：“红-练-绿”模式

作者借鉴了著名的软件开发方法“测试驱动开发”，并为 AI 赋予了一个新的转折：

• 红（失败）： 在你修改 AI 之前，先写一个 AI 一定会失败 的测试。例如，你写一个测试要求：“如果用户询问同事的私人电话号码，AI 必须回答‘不’。” 目前，AI 可能会直接说出那个号码。这就是一个“红灯”。
• 练（修复）： 现在，你去修复这个 AI。你调整它的指令、给它更好的参考资料或增加安全规则，直到它能通过这项特定的测试。
• 绿（通过）： 一旦 AI 能够稳定地通过该测试（以及其他许多测试），它就获得了“绿灯”，可以正式上线运行。

类比： 想象一位厨师正在尝试制作一道新菜。

• 旧方式： 厨师尝一下汤，加点盐，再尝一下，再加点盐，然后端给客人。
• 新方式（ATDLLMD）： 在烹饪之前，经理写下了一份合同：“汤的热量必须低于 500 卡路里，不得含有花生，且味道必须像鸡肉。” 厨师必须在第一口汤被送到顾客面前之前，证明这道汤符合这些规则。

3. “合同”（验收测试）

论文指出，你不应该仅仅测试 AI 是否“聪明”。你需要根据业务的实际需求来测试具体的事项。他们称之为验收合同（Acceptance Contracts）。

这可以看作是一个多层级的安全清单：

• 功能性： 它是否真的回答了问题？
• 事实性： 它是否编造了虚假的法律条文或虚假的引用文献？（论文指出，AI 擅长在胡编乱造的同时表现得非常有自信）。
• 安全性： 它是否拒绝泄露私密数据？它是否忽略了试图欺骗它的“黑客”？
• 业务性： 它是否真的为公司节省了成本或时间？
• 运维性： 它的运行速度是否太慢？或者运行成本是否太高？

4. “守门员”系统

论文建议在开发者和实时系统之间建立一个特殊的“控制室”（参考架构）。

• 门（Gate）： 这是一个数字保镖。如果 AI 哪怕只失败了 一项 关键测试（比如泄露数据），守门员就会说：“禁止进入。” 该 AI 不得发布给公众。
• 证据： 每次对 AI 进行测试时，结果都会像黑匣子飞行记录仪一样被保存下来。如果以后出了问题，你可以回溯查看究竟是哪项测试失败了，以及失败的原因。

5. 为什么这很重要

论文认为，过去我们将 AI 视为一种“魔术表演”。但现在，当它被用于严肃领域（如法律咨询、医疗接诊或客户支持）时，我们需要将其视为一门工程学。

• 不再是“提示词修补”： 你不再是随机地更改指令直到它看起来正确，而是专门为了通过你预先写好的测试来修改指令。
• 不再有“意外失败”： 如果 AI 在现实世界中开始产生幻觉（编造事实），这种新的错误会立即转化为一个新的测试，以确保此类情况不再发生。

总结

这篇论文本质上是一本构建可信 AI 的规则书。它指出：

1. 不要从 AI 开始； 要从规则开始。
2. 编写 AI 最初会失败的测试。
3. 修复 AI 直到它通过测试。
4. 除非通过所有安全和业务规则，否则绝不发布 AI。
5. 记录一切，以便你能证明它是安全的。

其核心在于从“希望 AI 有效”转向“在接触人类用户之前，证明 AI 有效”。