Внедрение ИИ-агентов: guardrails и верификация
Почему агент сообщает об успехе там, где его нет, как устроен слой верификации, чем ограничение в коде отличается от ограничения в промпте и что мониторить после запуска.
Все статьи гида ИИ-агенты · 11
Между работающим прототипом и системой в проде стоит один вопрос: что происходит, когда агент ошибается. Если ответа нет, прототип так и останется прототипом.
Почему агент врёт про результат
Это не дефект конкретной модели и не следствие плохого промпта. Модель генерирует продолжение текста; «задача выполнена» - такое же продолжение, как любое другое, и оно особенно вероятно, потому что диалоги обычно так и заканчиваются.
Отсюда следствие, которое стоит принять как данность: отчёт агента о результате не является доказательством результата. Он полезен как объяснение, но не как подтверждение.
Типичные проявления:
- Инструмент вернул ошибку, агент сообщил об успехе.
- Агент выполнил три шага из пяти и написал, что сделал всё.
- Данные не найдены, а в отчёте фигурируют правдоподобные, но выдуманные.
- Ограничение из промпта нарушено, но в отчёте написано, что оно соблюдено.
Слой верификации
Решение простое по идее и требует дисциплины: после завершения работы агента система сама проверяет факт.
Как это выглядит:
- Агент сказал, что создал тикет - проверяем, что тикет существует и обязательные поля заполнены.
- Агент сказал, что отправил сообщение - проверяем по идентификатору отправки, а не по его словам.
- Агент сказал, что данные обновлены - читаем их и сравниваем с ожидаемым.
Ключевое требование к проверке: она должна быть независимой от агента. Проверка, которую выполняет тот же агент, ничего не подтверждает - он подтвердит собственный вывод.
Второй уровень - проверка не факта, а качества: отдельный прогон, который смотрит на результат свежим взглядом и ищет несоответствия. На агентных задачах в разработке этот приём разобран в блоге: слой верификации.
Guardrails в коде, а не в промпте
Разница принципиальная.
Ограничение в промпте - это просьба. Соблюдается обычно. Не соблюдается в редких случаях, и именно они попадают в инцидент.
Ограничение в коде - это невозможность. Агент не удалит данные, если у него нет инструмента удаления и нет прав на удаление в базе.
Что переносится из промпта в код в первую очередь:
- Права. Отдельный пользователь базы с доступом только к нужным таблицам и только на нужные операции.
- Отсутствие опасных инструментов. Не «инструмент удаления с предупреждением в описании», а отсутствие инструмента.
- Подтверждение человеком для необратимых действий: платежи, рассылки, удаление, публикация.
- Лимит шагов и лимит стоимости на запуск.
- Ограничение объёма. Инструмент, который может обновить одну запись, безопаснее инструмента, который может обновить все.
- Идемпотентность. Повтор действия не создаёт второй эффект - см. идемпотентные пайплайны.
Развёрнутый чек-лист - в блоге: guardrails для агентов в проде.
Порядок вывода в прод
Пять шагов, каждый из которых снимает свой класс рисков:
- Режим наблюдения. Агент предлагает, человек выполняет. Даёт настоящий процент ошибок вместо предполагаемого.
- Узкий срез. Один тип задач, малый объём, обратимые последствия.
- Верификация до расширения. Пока проверка результата не автоматизирована, расширять нельзя: вы просто не узнаете об ошибках.
- Метрики и алерты. Сначала измерение, потом рост объёма.
- Постепенное расширение с сохранением возможности выключить.
Отдельным пунктом: должен существовать способ выключить агента за одну минуту и понятный откат. Если выключение требует деплоя, оно не сработает тогда, когда понадобится.
Что мониторить
- Доля успешных завершений по проверке фактов, а не по отчётам.
- Доля передач человеку. Её рост означает, что что-то изменилось во входных данных.
- Число шагов, среднее и максимальное. Рост максимума - ранний признак зацикливаний.
- Стоимость запуска. Растёт раньше, чем ухудшается качество.
- Доля повторных запусков - признак проблем с ошибками и идемпотентностью.
Главное свойство агентных систем в эксплуатации: они деградируют тихо. Не падают, а начинают ошибаться чаще. Без этих цифр разница между «работает» и «работает наполовину» не видна до жалоб.
Как это учитывается на этапе разработки - в статье про разработку агентов. Общая картина - гид по ИИ-агентам.
Вопросы и ответы
Почему ИИ-агент сообщает, что задача выполнена, хотя это не так?
Потому что модель достраивает правдоподобное завершение, а не проверяет факт. Для неё «отчитаться об успехе» - это такой же текст, как любой другой. Лечится это не формулировкой промпта, а проверкой результата программой: существует ли созданная запись, ушло ли сообщение, изменилось ли состояние.
Можно ли ограничить агента промптом?
Промпт задаёт поведение по умолчанию, но не гарантирует его. Настоящее ограничение - это отсутствие инструмента, отсутствие прав или обязательное подтверждение человеком. Если единственная защита от удаления данных написана в системном промпте, защиты нет.
Что мониторить у агента в продакшене?
Долю успешных завершений, долю передач человеку, среднее и максимальное число шагов, стоимость запуска и долю повторных запусков. Агенты не падают заметно - они начинают чаще ошибаться, и увидеть это можно только по динамике этих цифр.
Ещё по теме
- Что такое ИИ-агент и чем он отличается от чат-ботаГид
- Создание ИИ-агента: от промпта до продакшенаКак устроен путь от идеи до работающего агента: постановка задачи, выбор инструментов, цикл выполнения, тестирование до запуска и то, что нужно сделать перед выводом в прод.
- Как создать ИИ-агента: пошаговый разбор на реальном кейсеРазбор одного агента от требований до работающей системы: схема, инструменты и их описания, первый прогон и правки по его итогам, и что в результате осталось не агентом.
- ИИ-агенты для бизнеса: где они окупаются, а где нетВ каких процессах ИИ-агент даёт реальную экономию, где дешевле обычная автоматизация или найм, как считать окупаемость честно и какие риски обычно не закладывают в расчёт.
Сделаю под ключ
Соберу ИИ-агента под реальную задачу
С инструментами, памятью и логами, чтобы он работал в проде, а не только в демо.
от 1 500 $ · 1-2 недели