Сегодня в отрасли ИИ популярен подход: дать языковой модели доступ к инструментам и позволить ей самой решить, что вызывать. В демонстрациях он работает прекрасно. В промышленной эксплуатации разваливается.
В Atlas Verified наш ИИ-агент имеет доступ к более чем 100 специализированным инструментам: государственным базам соответствия, API отслеживания судов, санкционным сервисам, поставщикам торговых данных, системам отслеживания контейнеров и другим. Каждый инструмент существует потому, что специалисту нужен конкретный показатель для решения по проверке. Инженерная задача не в создании инструментов, а в том, чтобы каждый раз вызывались нужные инструменты в нужном порядке с нужными входными данными.
Эта публикация разбирает реальные проблемы оркестрации инструментов в большом масштабе и инженерные подходы, разработанные нами для их решения.
Проблема стремительного роста числа инструментов
Когда у агента 5 инструментов, выбор тривиален. Модель читает описания каждого, выбирает нужный и вызывает его. Но при росте до более чем 20, 50, 100 инструментов что-то перестаёт работать.
Во-первых, возникает проблема контекстного окна. Каждому инструменту нужны описание, схема параметров и инструкции по использованию в системном запросе. При 100+ инструментах десятки тысяч токенов расходуются ещё до попадания вопроса пользователя в контекст. Модель тратит больше времени на чтение документации инструментов, чем на осмысление задачи.
Во-вторых, есть проблема точности выбора. Языковые модели хорошо выбирают из нескольких чётко различающихся вариантов. Они плохо выбирают из десятков сходно звучащих инструментов. Когда несколько инструментов имеют пересекающиеся названия для санкционных проверок, модель часто выбирает неверный или вызывает несколько инструментов с перекрывающимися данными.
В-третьих, есть проблема стоимости и задержки. Каждое описание инструмента в запросе расходует токены. Каждый ненужный вызов требует обращений к внешним API, многие из которых оплачиваются за запрос. Агент, вызывающий 8 инструментов, когда достаточно 3, дорог и медлителен.
Почему статическая маршрутизация не работает
Наивное решение — статическая маршрутизация: сопоставлять вопрос пользователя с шаблоном и направлять его к заранее определённым наборам инструментов. «Проверьте эту компанию» запускает санкционную проверку. «Отследите этот контейнер» — отслеживание судна. «Проверьте этот сертификат» — поиск USDA.
На практике это сразу перестаёт работать. Рассмотрим вопрос: «Можете проверить этот органический сертификат из Индии?» Статический маршрутизатор может запустить поиск в органической базе USDA, что разумно. Но специалист также хочет знать: находится ли орган сертификации под санкциями? Есть ли действующие предупреждения FDA об импорте этого продукта из этой страны? Фигурирует ли экспортёр в списках запрещённых сторон? Есть ли торговые аномалии в заявленном маршруте?
Один вопрос пользователя обоснованно может требовать пяти или более инструментов из совершенно разных областей. Статическая маршрутизация либо упускает критические проверки, либо чрезмерно запускает всё подряд, возвращая нас к проблемам стоимости и точности.
Контекст чрезвычайно важен. «Расскажите об этой компании» означает совершенно разное в зависимости от того, смотрит ли пользователь на коносамент, органический сертификат или ведёт общий исследовательский разговор. Одни и те же четыре слова исходного вопроса требуют разных инструментов в каждом контексте.
Двухуровневая архитектура: выбор и выполнение
Наше решение отделяет выбор инструментов от их выполнения с помощью двух отдельных модельных слоёв.
Слой выбора использует быструю недорогую модель. Её единственная задача — изучить вопрос пользователя, контекст разговора и компактный перечень доступных инструментов, а затем выбрать инструменты, которые должны быть доступны для данного взаимодействия. Она не вызывает их, а лишь решает, к каким инструментам модель выполнения должна получить доступ.
Модель выбора видит сокращённое представление каждого инструмента: однострочное описание, возвращаемые данные и ограничения. Это намного компактнее полных схем параметров, поэтому она может оценить все 100+ инструментов, не сталкиваясь с пределами контекста. Обычно она выбирает 8-12 инструментов, соответствующих текущему вопросу.
Слой выполнения использует более мощную модель рассуждений. Он получает только инструменты, выбранные слоем выбора, с полными схемами параметров и инструкциями. Работая с целевым набором вместо полного каталога, модель лучше решает, какие инструменты вызывать, в каком порядке и с какими параметрами.
Это разделение даёт измеримые преимущества. Выбор занимает долю секунды и стоит очень мало. Модель выполнения видит ясный целевой контекст и допускает меньше ошибок. После внедрения архитектуры общее количество вызовов инструментов на взаимодействие значительно снизилось.
Фильтрация по возможностям
Помимо двухуровневого выбора, каждый инструмент нашей системы объявляет свои возможности — типы задач, которые он может выполнять. Инструмент может заявлять применимость к проверкам соответствия, торговой аналитике, анализу документов или отслеживанию поставок.
Когда система определяет намерение пользователя, она фильтрует каталог, оставляя только инструменты с соответствующими возможностями. Модель выбора даже не видит инструменты, не относящиеся к текущему типу задачи.
Это важно по неочевидной причине: языковые модели подвержены внушению. Если инструмент санкционной проверки находится в контексте, модель может решить выполнить её, даже когда пользователь задаёт простой вопрос о маршрутах перевозки. Удаляя неподходящие инструменты до выбора, мы устраняем целый класс ненужных вызовов.
Контуры обратной связи по качеству
Выбор инструментов — лишь половина дела. Вторая половина — обеспечить полезность их результатов и знать, что делать, когда результаты бесполезны.
После каждого выполнения инструмента наша система оценивает качество результата. Типичные виды отказов включают:
Пустые результаты. Инструмент успешно выполнился, но не вернул данных. Это может означать, что организации нет в данной базе, что является корректным информативным выводом, либо что запрос плохо сформирован, что нужно исправить и повторить.
Совпадения с низкой уверенностью. Нечёткий поиск названия возвращает результаты, но балл совпадения ниже порога. Системе нужно решить, представить ли их как потенциальные совпадения или отбросить и попробовать другую стратегию поиска.
Недостаточный размер выборки. Запрос торговых данных возвращает результаты только из одного источника, хотя для надёжности нужно сопоставлять несколько. Система распознаёт этот пробел и может инициировать дополнительные вызовы для его заполнения.
Когда проверки качества не пройдены, система возвращает инструкции в цикл рассуждений агента. Это не простая повторная попытка, а направленная попытка с объяснением проблемы и предложением переформулировать запрос.
Постепенная доставка результатов
Проверка соответствия торговым требованиям по своей природе многоэтапна. Пользователь загружает коносамент и просит агента проверить его. Агенту нужно сверить отправителя с санкционными списками, проверить органическую сертификацию, найти текущее положение судна, проверить предупреждения FDA об импорте товарного сырья и подтвердить тарифную классификацию. Эти проверки требуют разного времени.
Вместо ожидания завершения всех проверок перед показом чего-либо мы постепенно передаём результаты потоком. Как только инструмент отвечает, результат сразу форматируется и поступает в интерфейс пользователя. Пользователь видит санкционные результаты, затем данные судна, затем статус органической сертификации — каждый в виде структурированной карточки в момент готовности.
Итоговый этап синтеза, создающий повествовательное резюме, объединяющее все результаты, запускается лишь после завершения всех инструментов.
Автоматическая проверка: замыкание цикла
При обработке документов в нашем OCR-процессе система извлечения выявляет ключевые показатели: идентификаторы NOP, названия компаний, идентификаторы судов, номера контейнеров, коды портов и коды HS. Каждый показатель сопоставляется с конкретными инструментами проверки.
Вместо ожидания просьбы пользователя «проверьте этот документ» система заранее вычисляет подсказки для проверки. Когда пользователь открывает разговор о документе, агент уже знает, какие инструменты вызвать и с какими параметрами. Это резко сокращает время до получения результатов проверки: агенту не нужно читать документ, выявлять сущности, а затем решать, что проверять. У него уже есть готовый к выполнению план.
Принципы
Разработка этой системы сформировала несколько принципов, которые, по нашему мнению, широко применимы к проектированию ИИ-агентов:
Отделяйте выбор от выполнения. Не заставляйте модель рассуждений также выполнять маршрутизацию. Используйте дешёвые быстрые модели для классификации и дорогие мощные — для рассуждений.
Сокращайте выбор, повышайте точность. Модель, выбирающая из 10 подходящих инструментов, всегда превосходит модель, выбирающую из 100. Инвестируйте в фильтрацию до выбора.
Проверяйте после выполнения, а не только до него. Вызовы инструментов могут отказывать непредсказуемым образом. Создавайте контуры обратной связи по качеству, выявляющие плохие результаты и направляющие повторные попытки.
Передавайте потоком, а не пакетами. Пользователи должны видеть результаты по мере поступления. Постепенная доставка — не просто улучшение интерфейса; она принципиально меняет взаимодействие пользователей с данными проверки.
Формулируйте намерение явно. Не позволяйте модели угадывать, что считается «хорошим». Сообщайте ей это. Планирование целей превращает свободное исследование в направленную проверку.
ИИ-агент Atlas Verified координирует 100+ специализированных инструментов проверки для автоматизации проверок соблюдения торговых требований по всей мировой цепочке поставок.