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