Перейти к содержимому
PD
ИИ-агенты

Внедрение ИИ-агентов: guardrails и верификация

Почему агент сообщает об успехе там, где его нет, как устроен слой верификации, чем ограничение в коде отличается от ограничения в промпте и что мониторить после запуска.

Все статьи гида ИИ-агенты · 11

Между работающим прототипом и системой в проде стоит один вопрос: что происходит, когда агент ошибается. Если ответа нет, прототип так и останется прототипом.

Почему агент врёт про результат

Это не дефект конкретной модели и не следствие плохого промпта. Модель генерирует продолжение текста; «задача выполнена» - такое же продолжение, как любое другое, и оно особенно вероятно, потому что диалоги обычно так и заканчиваются.

Отсюда следствие, которое стоит принять как данность: отчёт агента о результате не является доказательством результата. Он полезен как объяснение, но не как подтверждение.

Типичные проявления:

  • Инструмент вернул ошибку, агент сообщил об успехе.
  • Агент выполнил три шага из пяти и написал, что сделал всё.
  • Данные не найдены, а в отчёте фигурируют правдоподобные, но выдуманные.
  • Ограничение из промпта нарушено, но в отчёте написано, что оно соблюдено.

Слой верификации

Решение простое по идее и требует дисциплины: после завершения работы агента система сама проверяет факт.

Как это выглядит:

  • Агент сказал, что создал тикет - проверяем, что тикет существует и обязательные поля заполнены.
  • Агент сказал, что отправил сообщение - проверяем по идентификатору отправки, а не по его словам.
  • Агент сказал, что данные обновлены - читаем их и сравниваем с ожидаемым.

Ключевое требование к проверке: она должна быть независимой от агента. Проверка, которую выполняет тот же агент, ничего не подтверждает - он подтвердит собственный вывод.

Второй уровень - проверка не факта, а качества: отдельный прогон, который смотрит на результат свежим взглядом и ищет несоответствия. На агентных задачах в разработке этот приём разобран в блоге: слой верификации.

Guardrails в коде, а не в промпте

Разница принципиальная.

Ограничение в промпте - это просьба. Соблюдается обычно. Не соблюдается в редких случаях, и именно они попадают в инцидент.

Ограничение в коде - это невозможность. Агент не удалит данные, если у него нет инструмента удаления и нет прав на удаление в базе.

Что переносится из промпта в код в первую очередь:

  • Права. Отдельный пользователь базы с доступом только к нужным таблицам и только на нужные операции.
  • Отсутствие опасных инструментов. Не «инструмент удаления с предупреждением в описании», а отсутствие инструмента.
  • Подтверждение человеком для необратимых действий: платежи, рассылки, удаление, публикация.
  • Лимит шагов и лимит стоимости на запуск.
  • Ограничение объёма. Инструмент, который может обновить одну запись, безопаснее инструмента, который может обновить все.
  • Идемпотентность. Повтор действия не создаёт второй эффект - см. идемпотентные пайплайны.

Развёрнутый чек-лист - в блоге: guardrails для агентов в проде.

Порядок вывода в прод

Пять шагов, каждый из которых снимает свой класс рисков:

  1. Режим наблюдения. Агент предлагает, человек выполняет. Даёт настоящий процент ошибок вместо предполагаемого.
  2. Узкий срез. Один тип задач, малый объём, обратимые последствия.
  3. Верификация до расширения. Пока проверка результата не автоматизирована, расширять нельзя: вы просто не узнаете об ошибках.
  4. Метрики и алерты. Сначала измерение, потом рост объёма.
  5. Постепенное расширение с сохранением возможности выключить.

Отдельным пунктом: должен существовать способ выключить агента за одну минуту и понятный откат. Если выключение требует деплоя, оно не сработает тогда, когда понадобится.

Что мониторить

  • Доля успешных завершений по проверке фактов, а не по отчётам.
  • Доля передач человеку. Её рост означает, что что-то изменилось во входных данных.
  • Число шагов, среднее и максимальное. Рост максимума - ранний признак зацикливаний.
  • Стоимость запуска. Растёт раньше, чем ухудшается качество.
  • Доля повторных запусков - признак проблем с ошибками и идемпотентностью.

Главное свойство агентных систем в эксплуатации: они деградируют тихо. Не падают, а начинают ошибаться чаще. Без этих цифр разница между «работает» и «работает наполовину» не видна до жалоб.

Как это учитывается на этапе разработки - в статье про разработку агентов. Общая картина - гид по ИИ-агентам.

Вопросы и ответы

Почему ИИ-агент сообщает, что задача выполнена, хотя это не так?

Потому что модель достраивает правдоподобное завершение, а не проверяет факт. Для неё «отчитаться об успехе» - это такой же текст, как любой другой. Лечится это не формулировкой промпта, а проверкой результата программой: существует ли созданная запись, ушло ли сообщение, изменилось ли состояние.

Можно ли ограничить агента промптом?

Промпт задаёт поведение по умолчанию, но не гарантирует его. Настоящее ограничение - это отсутствие инструмента, отсутствие прав или обязательное подтверждение человеком. Если единственная защита от удаления данных написана в системном промпте, защиты нет.

Что мониторить у агента в продакшене?

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

Ещё по теме