инженерные заметки
GREEN bias: как среды разработки фальсифицируют качество ИИ-агентов
Почему тестирование ИИ-агентов даёт зелёные отчёты, а агент проваливается в проде: встроенный перекос сред разработки на GREEN и как его обойти честной оценкой.
Коротко для руководителя. Зелёные тесты ИИ-агента часто значат не «агент работает», а «его проверяли в условиях, где он не мог не пройти». У сред разработки и у людей, пишущих тесты, есть встроенный перекос на зелёный результат — они бессознательно помогают системе. Из-за этого вы можете получить отличный отчёт о качестве и плохой продукт одновременно. Решается это не новыми тестами, а независимой проверкой, заинтересованной в провале.
Когда агент проходит тесты, кажется, что вопрос качества закрыт. На деле зелёный отчёт чаще говорит о свойствах теста, чем о свойствах агента. В тестировании ИИ-агентов есть систематическое искажение в сторону успеха — назовём его GREEN bias, — и пока его не видишь, ты принимаешь удобную картинку за измерение.
Тест, который подыгрывает агенту, проверяет ожидания автора, а не прочность системы.
Гипотеза: среды и тестировщики бессознательно тянут результат к зелёному
Тест пишет человек, который знает, как устроена система, — и неосознанно формулирует вход так, чтобы агент справился: чётко, без противоречий, по одной ветке. Современные агентные среды усиливают это: они упрощают сценарий, исправляют опечатки, дополняют неполный ввод, выбирают наиболее вероятную интерпретацию намерения. Каждое такое «удобство» приближает прогон к зелёному. В сумме система подсознательно помогает себе пройти проверку, и зелёный отчёт перестаёт что-либо доказывать.
Проблема: зелёный отчёт и рабочий агент — это разные вещи
Из-за GREEN bias легко получить высокий процент пройденных тестов и низкое качество в проде. Тест проверял знание фактов в тепличных условиях; реальность проверяет поведение в хаосе. Опасность не в самой ошибке, а в ложном сигнале: менеджмент видит зелёный отчёт, читает его как «готово» и выпускает агента в клиентский контур. Дальше край находит не команда, а клиент — и это уже не строчка в CI, а испорченный диалог и репутационный риск.
Внедрение растёт на порядок, но почти половина проектов не доходит до результата. Разрыв между демонстрацией и работающей системой закрывается архитектурой, а не моделью.
Разрыв виден на цифрах внедрения: агентный ИИ внедряют всё активнее, но до работающего результата доходит примерно половина. Это и есть зазор между «прошло демо» и «работает с людьми» — и закрывается он не сменой модели, а честной проверкой.
Почему обычные подходы не работают
Первый рефлекс — «добавим ещё тестов» — не помогает, потому что новые тесты пишут те же люди в той же среде, и они несут тот же перекос. Больше зелёного в удобных условиях не даёт ни одного красного в неудобных. Второй подход — «прогоним один раз и зафиксируем» — игнорирует недетерминизм: один и тот же вход у LLM даёт разные ответы, поэтому единичный зелёный прогон не гарантирует ничего; нужна статистика, а не галочка. Третий — «пусть тестирует разработчик» — упирается в конфликт интересов: автор проверяет свои ожидания, а не прочность. Корень один: проверку ведёт сторона, заинтересованная в зелёном.
Инженерная модель: как обойти перекос
Чтобы оценка была честной, нужен контур, заинтересованный в красном, и условия, в которых перекос не работает. Практически это три вещи. Первое — независимый атакующий агент, чья задача не помочь, а сломать: запутать, увести с темы, поймать на противоречии, заставить выдумать ответ. Второе — недетерминизм учитывается явно: каждый сценарий прогоняется много раз, а метрика — доля успешных исходов и частота уверенных ошибок, а не единичное «прошло». Третье — вход берётся из реальных диалогов, а не из синтетики: люди сбиваются не так, как воображает разработчик, и именно эти сбои ломают агента. Это и есть переход от демонстрации к работающей системе.
Большинство пилотов «отвечают», но не дают эффекта — потому что строится интерфейс, а не процесс с состоянием, контрактами и контролем.
То же искажение видно по пилотам генеративного ИИ: большинство «отвечают», но быстрый рост выручки дают единицы. Между «красиво отвечает в демо» и «двигает бизнес-метрику» лежит ровно та проверка, которую GREEN bias и прячет.
Практический вывод для бизнеса
Не принимайте зелёный отчёт как доказательство. Спросите, кто писал тесты и был ли заинтересован в провале хоть кто-нибудь. Если проверяла та же команда, что разрабатывала, — у вас нет независимой оценки, есть самопроверка.
Что поручить. Независимое тестирование агента — отдельная функция, как security review. Минимум на старте: атакующий агент плюс прогон на корпусе ваших реальных диалогов, с метрикой по множеству попыток. Это дёшево относительно цены агента, который уверенно ошибся перед клиентом.
Чего не делать. Не запускайте агента по зелёному отчёту его же авторов. Не путайте зелёный CI с готовностью: первый — гигиена, вторая — про то, доходит ли живой человек до результата. И не наращивайте число тестов вместо того, чтобы добавить в контур заинтересованность в красном.
Проверить вашего агента на перекос — .
Открытые вопросы
Можно ли полностью убрать GREEN bias — нет, но его можно сделать видимым и компенсировать независимым контуром. Где грань между «удобство среды» и «фальсификация» — там, где среда начинает чинить ввод, который в проде никто не починит. Кто отвечает за решение «отчёт честный» — это управленческий вопрос, и он решается до запуска, а не после первого инцидента с клиентом.
Если у вас зелёные тесты, но нет уверенности в агенте на реальных людях, — это и есть симптом GREEN bias. — посмотрим, что ваши тесты пока не проверяют.