Как заставить ИИ-агентов работать без сбоев: опыт создания морского аналитика Shippy

Создание автономных ИИ-агентов часто описывают как простую связку мощной языковой модели и набора API. Однако на практике разработчики неизбежно сталкиваются с недетерминированной природой нейросетей, их склонностью к выдумкам и потерей контекста при выполнении сложных цепочек задач. Показательным примером стал проект Shippy — интеллектуальный агент от Института искусственного интеллекта Пола Аллена (Ai2).

Зачем создавался Shippy

Shippy интегрирован в аналитическую систему Skylight, которая помогает морским службам более чем 70 стран выявлять браконьерство, сопоставляя спутниковые снимки и данные транспондеров судов. С помощью агента на базе Claude Opus специалисты могут на естественном языке запрашивать сложную аналитику по подозрительной активности в океане.

В таких задачах цена ошибки крайне высока: ложный вывод может направить патрульный катер по неверному курсу. Чтобы свести риски к минимуму, авторам пришлось пересмотреть классические подходы к архитектуре ИИ-агентов.

Главные проблемы ИИ-агентов и их решения

1. Выход за рамки компетенций

Языковые модели стремятся дать ответ даже тогда, когда вводных данных недостаточно, что приводит к ложным обвинениям судов в нарушениях. Чтобы предотвратить галлюцинации, в Shippy внедрили системный уровень правил (Soul):

• Агенту строго запрещено выносить юридические вердикты и давать прямые указания операторам (например, отправлять патруль).
• Ответы должны строиться исключительно на информации из внешних инструментов Skylight, а не на внутренних знаниях нейросети.

2. Неспособность соблюдать сложные правила API

Когда модели предоставили прямой доступ к REST API с десятками параметров, она начала регулярно ошибаться при сборке запросов. Решением стал отказ от прямого обращения к API в пользу промежуточного консольного интерфейса (CLI). Традиционный код взял на себя строгую валидацию параметров и обработку краевых случаев (таких как пагинация), оставив модели лишь выбор высокоуровневого действия.

3. Ошибки в длинных последовательностях и потеря данных

При передаче объемных ответов между инструментами через стандартный вывод контекст быстро переполнялся, а часть данных терялась из-за ограничений системных буферов. Разработчики изолировали тяжелые массивы: CLI сохраняет промежуточные результаты в локальные JSON-файлы, а LLM лишь передает ссылки на них между этапами обработки.

4. Выдумывание несуществующих инструментов

В ходе тестов агент начал генерировать вымышленные CLI-команды для решения задач. Для устранения этой проблемы разработчики формализовали рабочие процессы в виде версионируемых инструкций-навыков (Skills). Вместо неограниченной свободы действий модель получила четкие сценарии под конкретные сценарии вроде поиска морских заповедников или анализа треков.

5. Сложности с оценкой качества

Поскольку агент может решать одну и ту же задачу разными путями, стандартные тесты кода для него не подходят. В Ai2 создали автоматизированный стенд тестирования: сценарии прогоняются на реальных данных, а отдельная модель-судья выставляет баллы по взвешенным критериям (точность геопозиции, временные рамки, ссылки на источники), что позволяет вовремя замечать регрессии после правок инструкций.

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