55 篇博文 含有标签「testing」

你的团队上线了一个新的 LLM 功能。单元测试全部通过，CI 是绿色的，你部署了。然后用户开始反馈 AI "就是不好用"——回答格式奇怪，智能体选错了工具，在多步骤任务进行到一半时上下文丢失。你查看测试套件，它仍然是绿色的。每个测试都通过了。但这个功能是坏的。

这不是运气不好，而是当你把确定性测试哲学应用于概率性系统时必然发生的结果。经典测试金字塔——宽泛的单元测试底座、较小的集成测试中间层、狭窄的端到端测试顶端——建立在一个如此根本的假设之上，以至于没有人会把它写下来：代码每次都做同样的事情。LLM 在每个层面都违反了这个假设。建立在其上的测试策略需要从头重建。

我去年合作过的一个团队拥有一套包含 847 个测试用例的评估套件，仪表盘一片绿色，发布节奏从外部看非常有纪律。然而，他们的旗舰摘要功能开始为大约二十分之一的客户支持线程生成言之凿凿的错误摘要。该能力的评估得分在连续六个月里一直保持在 94%。当我们对这套套件进行审计时，发现问题并不在于评估在撒谎。问题在于这些评估已经悄然腐化，测量了错误的东西，惩罚了正确的模型行为，并与它们正在评估的模型共享盲点。这套套件并不是像传统测试那样以一种响亮的方式崩溃，而是像温度计一样坏掉了——无论你把它放在哪里，它都显示室温。

测试异味（Test smells）在传统软件领域已经被研究了二十年。Van Deursen 的目录、xUnit 模式分类以及更近期的工作都记录了那些看起来正常的测试如何能积极地损害代码库——通过编码错误的规范、使重构变得昂贵、以及制造让真正的 bug 隐藏得更深的虚假信心。LLM 评估是一个非常新的领域，以至于同类的文献几乎不存在，但同样的动态已经发生在我交流过的每个 AI 团队中。不同之处在于，LLM 评估异味具有传统测试所不具备的机制：训练数据重叠、随机输出、评委模型反馈循环、能力漂移。你不能只是简单地移植旧的分类体系，你需要一个新的。

你的 LLM 供应商 SLA 涵盖了 HTTP 正常运行时间和首个 Token 到达时间。但它对于模型下个月是否仍会遵从你的格式化指令、是否会拒绝上周还能接受的请求、或者在你未测试的边缘条件下能否返回有效 JSON，只字未提。大多数工程团队是通过生产环境事故才发现这一点的——而非通过更新日志。

这就是隐性 API 契约问题。传统 API 承诺稳定、有据可查的行为；LLM 供应商只承诺一条连接。从请求发出到应用处理响应之间发生的一切，都由你自己负责。

一个安全模型在公开基准测试集上取得了 85.3% 的准确率。当研究人员用并非来自公开数据集的新型对抗性提示进行测试时，这个数字跌至 33.8%。该模型并未真正学会如何推理安全性，而是学会了识别评估数据分布。

这就是合成评估数据核心问题所在：当同一个模型家族既生成训练数据又生成测试用例时，通过评估意味着符合某个共同的统计先验，而非真正展示能力。这是一个看起来像质量保证的反馈循环，直到生产流量到来，数字对不上号才会暴露问题。

这种失败是结构性的，而非偶然的。修复它需要的不仅仅是增加更多合成样本。

你的 AI 功能在上线时通过了所有评估。六周后，与其交流最频繁的用户群体的流失率翻了一倍，而你的 CSAT 仪表板却显示出一条无人能解释的平线。提示词（Prompts）没有变，模型没有更换，检索索引增长了，但没人觉得它坏了。上线时的表现第一轮（turn one）很好。真正变质的是在第 400 轮、第 17 次会话、注册三周后发生的事情。

大多数团队的评估套件无法察觉到这种失败。他们测试的是固定数据集上的单轮准确性，如果有追求的话，可能会测试单次会话中的多轮对话，然后就宣布该功能可以上线。真正重要的失败模式——即随着系统积累用户状态而质量下降——存在于评估工具从未设计去覆盖的时间维度中。在记忆研究文献中，研究人员称之为“自我退化”（self-degradation）：在初始阶段之后，受记忆膨胀（memory inflation）和错误记忆累积的驱动，性能出现明显且持续的下降。生产工程师则将其称为留存用户群无声流失的原因。

每一个从"我们有个聊天机器人"升级到"我们有个 Agent"的工程团队，都会撞上同一堵墙：他们的测试套件开始失去意义。

经典测试金字塔——70% 单元测试、20% 集成测试、10% 端到端测试——建立在三个基本假设之上：单元测试运行成本低、与外部系统隔离、结果确定可重复。Agentic AI 系统同时打破了这三个假设。所谓的"单元"是一次消耗 token 且每次返回不同结果的模型调用。一次端到端运行可能耗时数分钟，消耗的 API 预算足以让一位初级工程师整个迭代周期的测试都无法证明其合理性。而隔离性几乎无从实现，因为 Agent 的智能恰恰来自于与外部工具和状态的交互。

演示非常精彩。模型流利地回答了每一个问题，总结文档时没有出现幻觉，并处理了你提出的每一个边缘情况。利益相关者印象深刻。上线日期也就此定下。

发布三周后，准确率徘徊在 60% 左右。用户感到困惑。工单堆积如山。在演示中表现出色的模型，在处理生产环境流量时却步履维艰。

这不是一个关于模型好坏的故事，而是一个几乎每个构建 LLM 功能的团队都会遇到的错配故事：你测试的输入并不是用户发送的输入。

大多数在 QA 阶段夭折的 AI 项目，死因并非模型不好，而是没有人在构建之前就"好"的定义达成共识。工单里的验收标准往往写着"摘要功能应生成准确、相关的摘要"——当工程师问"准确"是什么意思时，得到的答案是"看到就知道"。这不是行为需求，这是一种期许。

问题在于团队把原本用于确定性软件的需求流程照搬到了本质上具有随机性的系统上。当你为数据库查询写 assertTrue(output.equals("Paris")) 时，测试的通过与否是完全确定的。但把同样形式的断言用在 LLM 上，得到的是一个对所有有效的同义表达都失败、对所有自信的幻觉都通过的测试。单元测试在骗你，而它所依据的规格从来就不是为"生成输出分布而非单一值"的系统设计的。

你的智能体通过了每一项测试。CI 流水线显示绿色。你发布了它。

一周后，一位用户报告说他们的批量导出任务悄无声息地只返回了 200 条记录，而不是 14,000 条。智能体访问了分页 API 的第一页，得到了一个干净的响应，以为没有更多内容了，然后就继续下一步了。你的模拟（Mock）一次性返回了全部 200 个条目。而真实的 API 从未告诉智能体还有另外 70 页。

这不是模型的失败。模型的推理是正确的。这是测试基础设施的失败 —— 这种现象在团队构建和测试智能体系统（agentic systems）时非常普遍。

Andrej Karpathy 直言不讳：AI 实验室正在"过拟合"Arena 排行榜。某头部实验室在公开发布前私下评估了 27 个模型变体，只发布了表现最佳的那个。研究人员估计，仅凭选择性提交就可以将排行榜分数人为提高多达 112%。所有人都视为基准真相的众包评估系统已经成为博弈目标——一旦成为目标，它就不再是有效的衡量标准了。

这就是古德哈特定律在发挥作用：当一个指标成为目标时，它就不再是好的指标。这一规律在经济学和政策领域已被充分理解了数十年。在 LLM 工程中，它正在实时摧毁评估套件，而构建这些套件的团队往往浑然不知。

你的 Agent 在预发布环境中运行完美。它调用正确的工具，推理多步骤计划，并返回精心打磨的结果。然后生产环境来了：地理编码 API 在 7 步计划的第 3 步超时，LLM 在句子中间返回不完整的响应，而你的 Agent 自信地编造数据来填补空白。直到客户发现，没有人注意到。

LLM API 调用在生产环境中有 1-5% 的失败率——速率限制、超时、服务器错误。对于每个任务进行 10-20 次工具调用的多步骤 Agent，这意味着相当比例的任务至少会遇到一次故障。问题不在于你的 Agent 是否会遇到故障，而在于你是否曾经测试过它遇到故障时会发生什么。

一家金融科技公司的产品团队发布了一款基于大语言模型 (LLM) 的文档摘要生成器。他们的评估数据集包含 200 个经过人工筛选并附带人工评分的示例，质量得分达到 87%。在生产环境中，当用户上传短备忘录时，系统偶尔会返回比原始文档更长的摘要。评估数据集中没有任何篇幅少于 300 字的备忘录。而“对于摘要任务，输出长度 ≤ 输入长度”这一属性从未被测试过。直到一位客户截下了这个荒唐的界面并将其发布到网上，才有人察觉到这个问题。

这就是属性测试 (Property-Based Testing, PBT) 所填补的核心空白。评估数据集衡量的是你“想到的”测试场景中的准确性。而属性测试衡量的则是，在所有可能发生的情况中，你的系统是否始终遵守了预定义的契约。