ИИ-ревьюеры ловят баги, но только если видеть контекст: реальный тест четырех моделей
В эпоху, когда публикации об успехе ИИ часто лишены цифр, независимый эксперимент демонстрирует жесткую зависимость эффективности агентов от наличия контекста. При тестировании четырех популярных моделей на заранее размеченных дефектах выяснилось, что подсказка измененной строки кода повышает точность находок на 20 процентных пунктов. Без этого ключа информации эффективность резко падает, а количество ложных срабатываний на чистых файлах возрастает.
# Когда ИИ-ревьюер видит только кончик айсберга
В обилии материалов об искусственном интеллекте и разработке часто отсутствует главное: данные. Большинство текстов строятся на субъективном опыте «человек попробовал — ему понравилось или нет». Однако реальный тестирование возможностей агентов требует жестких метрик, а не эмоций. Недавний эксперимент, проведенный разработчиком для журнала Хабр, заполняет эту лакуну, используя набор из 60 дефектов, сгенерированных в рамках мутационного тестирования.
Экспериментатор подготовил эталонную выборку за две недели до появления моделей для оценки: 51 случай, где тесты пропустили реальную поломку (дыра в тестах), 8 эквивалентных изменений, не влияющих на поведение, и один спорный кейс. Это позволило измерить не только способность ИИ находить ошибки, но и уровень шума в ответах.
Критическая важность контекста
В исследовании использовались четыре движка: Codex, Claude Sonnet, Claude Haiku и локальная модель Qwen 27B. Их проверили в двух режимах: «легком» (diff), где агент видит измененную строку кода, и «боевом» (blind), где файл подается целиком без подсказок.
Результаты показали драматическую разницу. В легком режиме модель Codex находила баги с точностью 98%. В боевом режиме эта цифра упала до 78%. Аналогичная тенденция наблюдалась у всех моделей: наличие подсказки о конкретном изменении добавляло около 20 процентных пунктов к эффективности.
*Авторский взгляд:* Практически все маркетинговые заявления о том, что «ИИ отлично ревьюит код», основаны на данных легкого режима. В реальности же системы контроля качества (CI) часто сталкиваются с задачей анализа целого файла или сложного пулл-реквеста без детализации изменений. Именно в этом сценарии ИИ проигрывает, и разница между лучшими моделями становится не столь очевидной.
Цена за молчание: шум и время
Эффективность — не единственный показатель. Важнее соотношение пользы к вреду. В эксперименте агенту предлагались не только файлы с ошибками, но и 12 файлов с безвредными форматировочными правками (подсадные мулянты), а также 20 нетронутых файлов.
В режиме «blind» все четыре модели стали генерировать значительный объем ложных срабатываний. Например, модель Haiku, которая в легком режиме находила почти 94% дефектов, в боевом режиме дала 12 ложных находок из 20 чистых файлов. Локальная модель Qwen 27B показала еще более высокую активность: 5 ложных срабатываний и 638 секунд времени на обработку одного файла против 39 секунд у облачного Codex.
Здесь кроется экономический парадокс. Модель, которая молчит в 50% случаев (выдав меньше фактических багов), обходится компании дешевле, чем модель, уверенно выдающая поток правдоподобных, но выдуманных проблем. Обработка таких ложных тревог требует времени инженера, а за время ожидания ИИ в локальном режиме приходится платить огромные ресурсы.
Надежность судейства и ловушки стенда
Интересный аспект исследования касается оценки качества ответа. Для проверки объяснения ИИ использовалась модель-судья. Однако анализ показал нестабильность даже этого инструмента. При повторном прогоне тех же данных судья-судья совпадала в решениях лишь на 96%, а сравнение разных моделей-судей показало расхождение в 85%.
Кроме того, эксперимент выявил технические нюансы, влияющие на результаты: * Дрейф исходников: Номера строк в разметке устарели, так как за две недели разработки некоторые файлы изменились. Это могло бы исказить данные, если бы исследователь не закрепил рабочую ветку. * Таймауты клиента: Локальная модель Qwen 27B казалась медленной, но проблема была не в вычислениях, а в дефолтных таймаутах HTTP-клиента в Node.js, обрезающих обработку на 301 секунде.
Эти факты подчеркивают главную мысль автора: в замере ИИ подавляющее большинство странных результатов часто кроется в неидеальности самого стенда, а не в неспособности модели.
Выводы для практики
1. Режим имеет значение: Если инструмент ревьюирует пулл-реквест, он получает подсказки о изменениях. Если же он анализирует весь файл «вслепую», его эффективность будет на порядок ниже. 2. Шум стоит денег: Оптимизация под максимальное количество найденных багов без учета ложных срабатываний может привести к тому, что ревьюер (ИИ или человек) будет тратиться впустую. 3. Нестабильность: Одиночный прогон агента не гарантирует воспроизводимый результат. Цифра «агент нашел X% багов» без указания интервала доверия или количества прогонов вводит в заблуждение.
Для внедрения ИИ-ревьюеров важно понимать разницу между идеализированным бенчмарком и реальной задачей. Лучшая модель для ночного сканирования репозитория может оказаться менее полезной для мгновенной проверки пулл-реквеста в рабочем режиме из-за времени ответа и уровня шума.