Guardrail для LLM-агента: как проверить, что он чинит больше, чем ломает

Агентная платформа

Программный комитет ещё не принял решения по этому докладу

Целевая аудитория

Инженеры и архитекторы агентных платформ, ML/LLM-инженеры, backend и platform-инженеры, MLOps и QA, технические руководители, которые отвечают за включение агентов в контур с реальными записями в БД Доклад для тех, кто уже выбирает между retry, verifier, детерминированным валидатором, structured feedback и передачей действия более сильной модели - и кому нужно обосновать этот выбор числами, а не интуицией и AUROC детектора

Тезисы

Мы построили ограничитель для агента, который меняет данные в базе: возвраты и обмены заказов. Он сработал 12 раз - 7 раз исправил ошибку агента и 5 раз испортил изначально правильное действие. Итоговая польза относительно базового поведения: ноль при доверительном интервале ±16,7 п.п.

Самое интересное выяснилось раньше. Чтобы получить эти 12 случаев, понадобилось 42 полных прогона агента по 12 задачам - и лежали они всего на 9 независимых задачах. Номинальный размер бенчмарка почти ничего не говорит о том, сколько раз ограничитель вообще получит шанс сработать. Когда мы просимулировали девять вариантов большого платного эксперимента, ни один не набирал мощности, чтобы отличить полезный ограничитель от вредного. Эксперимент мы не запустили. Гейт, который принял это решение, стоил меньше одного цента

Ограничитель живет на критическом пути каждого шага агента: он умножает вызовы и задержку на весь трафик, а на операциях, меняющих состояние, умеет дублировать и портить уже выполненное. Проверять его надо как инфраструктуру, а не как ML-метрику, и это отдельная инженерная задача

Расскажу, как устроен стенд такой проверки: парный replay веток из одного типизированного лога сообщений и одного хеша базы на момент до действия; запрет на подглядывание в будущее; учёт вреда от коррекции наравне с исправлениями; выбор независимой единицы данных; fail-closed гейты, останавливающие дорогой прогон до оплаты. И разберу три бага, которые нашёл в собственном стенде: replay, молча терявший часть записей в базу; показатель мощности, посчитанный не для того события; и адаптивный набор данных, сместивший оценку.

Унесете процедуру «идентифицируемость → измеримость → replay → сравнение → разрешить/остановить», способ пересчитать размер своего бенчмарка в число независимых единиц вывода и чек-лист условий, при которых включать ограничитель на потоке ещё нельзя

Максим Минкин

IBS

Data Scientist в IBS, специализируется на разработке production LLM-систем. Занимается каскадами LLM-классификаторов, RAG-пайплайнами, retrieval evaluation и агентными системами. Работает с LangGraph, MCP, Qdrant, MLflow, FastAPI и локальным inference. Исследует безопасность LLM-агентов, оценку неопределенности и верификацию многошаговых решенийИЯУ МИФИ