谷歌本周发布了一份预印本,介绍 Auto-Diagnose,一个基于 LLM 的系统,它读取集成测试的日志,告诉工程师测试为什么失败。动机来自谷歌内部调查:38.4% 的集成测试失败诊断需要超过一小时,8.9% 需要超过一天。单元测试几乎瞬时就能分诊,因为失败面就是一个函数;而集成测试横跨服务、数据中心和运行时层,所以根因分析变成了一项日志考古工作。Auto-Diagnose 用前沿模型上的提示工程来自动化这项考古,而不是用微调模型。
模型是 Gemini 2.5 Flash,温度 0.1,top-p 0.8,没有在谷歌测试语料上做过微调。流水线收集测试驱动日志和跨数据中心的组件日志,将它们按时间顺序拼成单一流,然后整体提交给模型。每次执行的平均负载:110,617 个输入 token 和 5,962 个输出 token。延迟 p50 为 56 秒,p90 为 346 秒。提示引导模型通过明确的阶段:扫描日志段、阅读上下文、定位失败、总结错误,然后给出结论。关键的工程选择是一个严格的反幻觉约束,强制模型在证据不足时拒绝回答而不是猜测。正是这种拒绝行为,让准确率在一个「自信地答错会浪费工程师数小时」的领域里维持在 90% 以上。
2025 年 5 月以来的生产数据:评估了 224,782 次测试执行,诊断了 52,635 个不同的失败测试。在 39 个团队的 71 个真实世界失败上的人工评估:根因准确率 90.14%。开发者反馈:评审员 84.3% 的「please fix」、开发者响应中的有用度比例 62.96%、在 370 个内部 Critique 工具中按有用度排名第 14(前 3.78%)。值得注意的是缺失的部分:没有微调、没有 RAG 层、没有定制模型。只有 Gemini 2.5 Flash 加上用心的提示设计和一条拒绝-于-歧义规则。系统也受益于谷歌极端集中的日志基础设施,所以你不能简单地把同一个提示发到 AWS CloudWatch 就期待同样的数字,因为提示假设日志已经跨服务按时间顺序拼好了。
如果你在运行任何形式的多服务 CI,这里的方法论可复制,但不便宜。模型成本微不足道(Gemini 2.5 Flash 每次分诊约 116k token,成本几分钱),所以真正的投入在日志管道:在 LLM 看到任何东西之前,先收集、标准化并跨服务拼接。拒绝-于-歧义这个模式是最可迁移的单一想法。大多数 CI 里的 LLM 流水线没有调好拒绝,结果会幻觉出看起来合理的原因,这比沉默更糟,因为它会把工程师引向错误修复。如果你在给测试套件接 LLM 分诊,先复制这个模式,再去操心模型。第二个教训是,现成的前沿模型加上用心的提示,在专门任务上已经能和微调方案竞争,前提是你把输入塑造好。这提高了小团队不搞 ML 基础设施也能做出的东西的上限。