Google apresentou Auto-Diagnose — sistema de IA para encontrar causas de falhas em testes de integração

Google представила Auto-Diagnose — внутреннюю систему на базе LLM, которая разбирает логи упавших интеграционных тестов, сама вытаскивает ключевые строки и публикует диагноз прямо в code review. Для больших инженерных команд это попытка убрать один из самых дорогих скрытых издержек разработки: часы, а иногда и дни, которые уходят на ручной поиск причины сбоя в десятках файлов с логами. Проблема у Google вполне измерима.

Во внутреннем опросе 6059 разработчиков диагностика падений интеграционных тестов вошла в топ-5 самых частых жалоб на инженерные инструменты. Дополнительный опрос 116 инженеров показал, что 38,4% таких сбоев разбираются дольше часа, а 8,9% — дольше суток. Для unit-тестов эти показатели составили 2,7% и 0% соответственно.

Причина понятна: интеграционный тест почти никогда не падает в одном очевидном месте. В типичном кейсе есть отдельный test driver, набор сервисов внутри system under test, разнесённые по разным компонентам логи, масса предупреждений и ошибок, которые вообще не связаны с корневой причиной. В исследовании Google медианный сбойный тест содержал 16 лог-файлов и 2801 строку логов.

Auto-Diagnose встроен в существующий поток разработки. Когда интеграционный тест падает, система автоматически получает событие, собирает логи test driver и SUT-компонентов уровня INFO и выше, сводит их в единый поток и сортирует по времени. Затем вместе с метаданными компонентов всё это отправляется в Gemini 2.

5 Flash. Модель работает без дообучения на специальных логах Google: ставка сделана не на fine-tuning, а на жёсткий промпт и интеграцию в процесс. В промпте модель заставляют идти по шагам: найти секции логов, выделить компонент, где произошёл сбой, проверить контекст и только потом формулировать вывод.

Ключевой момент — запрет на догадки. Если в логах нет строк именно из того компонента, который не поднялся или не стал healthy, модель должна не фантазировать, а прямо ответить, что данных недостаточно. После этого ответ приводится к стандартному формату и публикуется в Critique, внутренней системе code review Google, где разработчик сразу видит вывод, шаги расследования и самые релевантные строки логов.

По цифрам система выглядит не как лабораторный прототип, а как реально обкатанный внутренний инструмент. В ручной проверке на 71 реальном падении из 39 команд Auto-Diagnose верно определил корневую причину в 64 случаях, то есть с точностью 90,14%. После этого Google запустила его на все интеграционные сбои при code changes по всей компании, начиная с мая 2025 года.

За это время система отработала на 52635 уникальных тестах, 224782 запусках, 91130 изменениях кода и 22962 авторах. Медианное время публикации диагноза в code review составило 56 секунд, а 90-й перцентиль — 346 секунд, то есть результат обычно появляется до того, как инженер окончательно переключится на другую задачу. В среднем один запуск потребляет 110617 входных токенов и генерирует 5962 выходных.

По обратной связи тоже всё неплохо: из 517 отзывов от 437 разработчиков доля отметок Not helpful составила 5,8%, что ниже внутреннего порога Google в 10% для таких инструментов, а по helpfulness Auto-Diagnose занял 14-е место из 370 систем, публикующих findings в Critique. Есть и важная побочная польза. Семь ошибок из ручной оценки оказались не провалом модели как таковой, а проблемами инфраструктуры логирования: в одних случаях не сохранялись логи test driver после крэша, в других — логи самого упавшего компонента.

Похожие ответы в духе «нужно больше данных» позже помогли выявить ещё около 20 инфраструктурных проблем. Поэтому главное значение Auto-Diagnose не только в том, что Google ускоряет разбор тестовых падений. Компания показывает более практичный паттерн использования LLM в разработке: не просить модель чинить код вслепую, а встроить её в узкое место процесса, дать жёсткие правила отказа от догадок и вернуть результат прямо туда, где инженер уже работает.

Для крупных команд это, возможно, более ценный сценарий, чем очередной «AI coding assistant», потому что он сокращает время до понимания причины сбоя, а именно это чаще всего и тормозит релиз.