Архитектура надежности: как извлечь ИИ-агента из хама галлюцинаций
Разработка автономных агентов на базе больших языковых моделей (LLM) часто обещает мгновенный успех: «выбрали модель, подключили инструменты — и всё работает». Однако реальная практика, как показал кейс аналитического агента Shippy для платформы Skylight, демонстрирует обратное. Успешная интеграция ИИ требует жесткого разделения зон ответственности: модель должна отвечать только за выбор действий, в то время как детерминированный код контролирует выполнение операций, управление памятью и соблюдение строгих правил. Только такой гибридный подход позволяет создать систему, пригодную для реального мира, где цена ошибки высока.
# Типичные ошибки работы с ИИ-агентами: опыт создания Shippy
В сфере разработки интеллектуальных систем доминирует нарратив триумфа. Публикации чаще всего посвящены удачной комбинации лучшего языка и удобного API, скрывая за фасадом «магии» сложные инженерные компромиссы. История создания ИИ-агента Shippy, предназначенного для анализа данных спутникового мониторинга океана, стала редким исключением. Команда разработчиков честно задокументировала путь от иллюзий всемогущества нейросетей до создания надежного инструмента.
Shippy — это компонент платформы Skylight от Института искусственного интеллекта Пола Аллена (Ai2), используемой более чем в 70 странах для борьбы с незаконным рыболовством. Задача агента — отвечать на запросы пользователей на естественном языке, анализируя данные о судах и морской обстановке в реальном времени. Под капотом работает модель Claude Opus, но сама по себе она не гарантирует точность в критически важных сценариях.
Главный урок проекта можно сформулировать так: вероятностная природа LLM делает их непригодными для выполнения детерминированных, строго регламентированных задач без внешнего контроля. Решением стала архитектурная перестройка, где нейросеть отделена от логики исполнения.
Границы компетенции: создание слоя «Soul»
Первая и самая серьезная проблема возникала из-за склонности моделей генерировать правдоподобные, но ложные гипотезы. В контексте Shippy это означает риск того, что агент сфантазирует наличие незаконной деятельности там, где её нет. Для системы, влияющей на патрулирование судов, такое «галлюцинирование» недопустимо.
Чтобы решить эту дилемму, разработчики внедрили отдельный программный слой, названный «Soul» (Душа). Этот модуль не является частью самой языковой модели и содержит жесткие правила поведения.
Ключевые ограничения в «Soul»: * Запрет на юридические выводы: Агент не имеет права самостоятельно определять, нарушает ли судно закон. Его задача — предоставить сырые данные или факты, но не формулировать юридическую оценку. * Оперативная нейтральность: Модель не может рекомендовать конкретные действия (например, «отправить патруль в координаты X»). Она лишь может сообщить о факте обнаружения активности. * Источник правды: Все утверждения должны базироваться исключительно на данных, полученных через инструменты платформы, а не на внутреннем знании самой модели.
Такая сегментация позволяет обновлять правила безопасности, не меняя веса обученной нейросети. Однако одного запрета недостаточно для создания надежной системы.
Проблемы интеграции API и управление состоянием
На следующем этапе команда столкнулась с задачей взаимодействия с REST API платформы Skylight. Изначально агент получал прямой доступ к интерфейсу и самостоятельно формировал запросы. Быстро стало очевидно, что модель не способна эффективно управлять сложной структурой API, содержащей множество обязательных параметров, ограничений и зависимостей между полями.
Для решения этой задачи был введён промежуточный слой — CLI (Command Line Interface). Этот модуль не использует ИИ для генерации кода, а выполняет стандартные алгоритмы обработки запросов. Таким образом, LLM отвечает только за семантическое понимание запроса пользователя и перевод его на команды CLI, а сам CLI гарантирует корректность формирования запроса к API.
Другая техническая сложность заключалась в передаче промежуточных данных. При обработке длинных цепочек действий (например, определение границ территории, запрос событий, фильтрация по времени) стандартный вывод команд (stdout) часто оказывался недостаточным. Объем данных превышал лимиты буфера, что приводило к потере информации и нарушению контекста.
Разработчики перенесли хранение промежуточных результатов в локальные JSON-файлы. Теперь модель обращается к этим файлам для продолжения анализа, оставляя огромный массив данных за пределами своего контекстного окна. Это позволило работать с большими объёмами информации, не перегружая модель.
Борьба с галлюцинациями инструментов и тестирование
Одной из наиболее интересных находок стало обнаружение того, что агент мог попытаться вызвать несуществующую CLI-команду. Модель «придумала» новый инструмент как часть рабочего процесса, не осознавая, что его физически не существует. Ошибка не касалась содержания ответа, а破坏了 саму логику выполнения задачи.
Для предотвращения подобных ситуаций были введены «навыки» (skills). Вместо общего пространства возможностей агент получает строго описанные в Markdown-файлах инструкции для конкретных типов запросов (поиск судов, определение границ ММП и т.д.). Это сузило поиск действий до заранее утвержденных сценариев.
Также была пересмотрена стратегия тестирования. Традиционные методы, проверяющие только конечный текст, оказались неэффективны, так как одна и та же задача может реализовываться разными путями. В Shippy была внедрена система оценки сессий, где результаты работы агента проверяются автоматически по набору критериев (точность географических данных, корректность временного диапазона, наличие источников). Каждый сценарий проходит оценку через отдельный LLM-судью, который выставляет баллы по шкале от 0 до 1. Этот подход позволил выявить регрессии и скрытые ошибки, которые не проявлялись бы в единичных тестах.
Что такое галлюцинации в контексте агентов?
В отличие от простого фактологического искажения, галлюцинация инструмента в агентах представляет собой попытку взаимодействия с несуществующим элементом системы. Модель уверенно формирует вызов, который не может быть выполнен, поскольку такой API или команда в текущей конфигурации отсутствуют. Это требует жесткой валидации на уровне кода, а не полагаться на самокоррекцию модели.
Заключение: синергия вероятностного и детерминированного
Опыт создания Shippy четко показывает, что стремление дать языковой модели полный контроль над процессом часто приводит к нестабильности. Надежная архитектура строится на разделении труда:
1. LLM (Языковая модель): Отвечает за понимание запроса, выбор стратегии и генерацию обоснования. Здесь важны её творческие способности и гибкость. 2. Детерминированный код: Отвечает за выполнение операций, соблюдение правил, управление памятью и проверку корректности данных. Здесь важна точность и предсказуемость.
Полностью исключить непредсказуемость ИИ невозможно, но её влияние на результат системы можно нивелировать. Выделив строгие правила и технические детали во внешний слой, разработчики создали агент, способный работать в реальном мире, где цена ошибки измеряется не точками в чате, а безопасностью морских территорий.
Таким образом, будущее ИИ-агентов лежит не в создании всёмогущих черных ящиков, а в построении гибридных систем, где человеческая логика и программная дисциплина направляют энергию больших данных.