Хабр Курсы для админов
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Администрирование доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 4
Отличный разбор, узнаю недавно прожитую боль. У меня похожая ситуация воспроизвелась немного с другой стороны: детерминированные проверки честно зелёные, а «врёт» именно зазор между проверкой и реальным положением вещей. Недавно словил каскад — приложение падало в контейнере первым же запуском, а CI при этом был полностью зелёный, потому что ни один шаг CI сам образ не запускал, гонял тесты на хосте. Вывод тот же, что у вас: контроль должен жить в том стеке, где живёт продукт, а не рядом с ним. Как вы гоняете агента против инфры — на живом окружении или на моке ingress? Мок ведь ровно этот зазор и прячет
Перед запуском тест забирает из production MCP актуальный список инструментов, их схемы и контракты. Затем реальной модели задаётся сохранённый вопрос (из истории, отобранный вручную). Когда модель вызывает tool, запрос перехватывается. Вместо обращения в прод источники тест возвращает готовый ответ (в виде raw метрик и логов), ранее полученный в реальной проблеме (для нас это ок, поскольку тулы в mcp узкопрофилированые, при правильных входных данных отдадут правильную выборку). При этом проверяются имя инструмента и его аргументы: кластер, namespace, сервис, время и окно поиска. Если агент выбрал другой ЦОД, потерял время или вызвал неподходящий tool, сохранённый ответ не подставится и тест завершится ошибкой.
После этого проверяется итоговый ответ от самой модели по сырым данным: присутствуют ли подтверждённые факты, не появилась ли выдуманная причина, не назвал ли агент недоступный источник исправным. Один сценарий запускается несколько раз, чтобы увидеть нестабильность выбора инструментов.
Все это работает сейчас долго, и честно хочется универсальности и чуть быстрее получать результат теста, но пока не получилось ничего лучше...
Спасибо, теперь схема ясна — и она изящнее, чем я думал: вы мокаете не результат, а проверяете, что агент попросил правильный ответ (тот кластер, namespace, окно). Мок не прячет зазор, а сторожит выбор агента. У меня было наоборот: фейк в тестах повторял дырявое поведение прода и потому узаконивал дыру — тесты честно проходили на неправильном поведении. Прогон одного сценария несколько раз ради нестабильности выбора заберу себе. Один вопрос: вы тянете актуальные схемы из прод-MCP перед прогоном — а что ловит момент, когда контракт изменился, а сохранённый «правильный ответ» устарел?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
502 на ingress, 302 в приложении: как я учил инфраструктурного LLM-агента не врать