2 篇博文 含有标签「llm-testing」

我调查过的最残酷的 Bug 报告来自一个团队，他们的 CI 在六周内一直显示为绿色（通过）。每一次提示词更改都通过了完整的测试套件。每一次工具调用都有一个模拟（mock）。每一次集成测试都断言了大模型在预发布环境中返回的精确字符串。然而，每一个测试都在撒谎。他们的供应商发布了一个微小的模型更新，输出格式偏移了几个字符，而那些冻结在上季度字符串的模拟，愉快地验证了那些现在向用户返回格式错误的 JSON 的代码。

这就是我想谈论的失效模式。在代码结构层面，AI 应用的依赖注入很容易做对（你的提示词运行器接受一个客户端接口，你在测试中传入一个伪造对象，搞定）。但在“保真度”层面，也就是真正重要的属性上，很难做对：通过的测试能否预测生产环境不会崩溃？我看到的大多数测试套件都在不知不觉中牺牲了保真度，因为你替换真实模型的那个“接缝”，也正是你失去对你真正关心的事物信号的那个“接缝”。

修复方法不是“更仔细地模拟”。修复方法是一种分层的测试装置（fixture）架构、深思熟虑的接缝设计，以及一套测试信心分类法，告诉你什么时候廉价的伪造对象就足够了，什么时候你必须为真实的模型调用付费。这三者共同构成了一个测试套件，它在每次提交时仍然只需几秒钟即可运行，但不再对生产行为撒谎。

大多数团队发现模型局限性的方式和用户一样 —— 在生产环境中，通过工单。客户反映提取流水线悄悄丢失了嵌套地址。内部用户注意到摘要器在超过 8,000 个 token 后开始虚构日期。合规审查发现分类器自信地为模糊案例打上标签，而不是选择放弃判断。

这些都不是意外。它们是一直存在的能力边界，只是在等待合适的输入来暴露它们。你要么在部署前绘制这些边界，要么让用户替你绘制 —— 一次一个事故。

系统性地发现这些边界的方法就是能力探测 —— 语言模型的故障注入。你不会在没有对接缝进行负载测试的情况下交付一座桥梁。同样的逻辑适用于任何面向用户的模型。