Что такое Ninth Wave Compass и какую задачу он решает
Compass - мультиагентный AI-ассистент онбординга, который компания Ninth Wave построила на Amazon Bedrock AgentCore и фреймворке Strands Agents. Система проверяет банковские API на соответствие стандарту Financial Data Exchange (FDX), сопоставляет поля и оценивает готовность к production. По заявлению Ninth Wave, сроки интеграции сжимаются с недель до минут, а рутинный аудит спецификаций берут на себя семь специализированных агентов под управлением оркестратора.
Контекст, в котором это работает, стоит держать в голове. Open finance - модель, при которой клиент разрешает стороннему сервису читать свои финансовые данные через API банка. Банк публикует эндпоинты, финтех получает доступ к балансам, транзакциям, реквизитам счетов. FDX задаёт единый язык этого обмена: структуру ресурсов, обязательные поля, форматы значений, правила доступа. Чем ближе API банка к FDX, тем быстрее и дешевле подключение.
Основное время съедает разрыв между «эндпоинт отвечает» и «API соответствует FDX». Compass закрывает именно эту щель: он читает документацию банка, сверяет её со стандартом, показывает расхождения и считает числовую оценку готовности. Человек подключается там, где нужен выбор, а не там, где нужно механическое сравнение двух спецификаций.
Детали работы системы известны по описанию самой Ninth Wave. Независимых замеров, публичных бенчмарков и сторонних аудитов по Compass в открытом доступе нет, и в тексте это отмечено отдельно. Поэтому цифры и формулировки ниже даны с привязкой к источнику заявления, а не как проверенные факты.
Почему онбординг в open finance - это боль
Типичный сценарий подключения банка выглядит так. Банк отдаёт спецификацию и тестовый стенд. Инженер открывает документ, рядом кладёт спецификацию FDX и начинает сверять по пунктам: есть ли обязательные поля, совпадают ли типы данных, как называются идентификаторы, что с пагинацией, какие коды ошибок возвращает сервис. Потом пишется тестовый клиент, прогоняются сценарии, расхождения описываются в отчёте, отчёт уходит в банк, банк правит, цикл повторяется.
В процессе участвует несколько ролей: интеграционный инженер, аналитик, специалист по безопасности. Время теряется на синхронизацию и на повторную проверку того, что уже проверяли в прошлой итерации. Добавьте сюда, что каждый банк называет поля по-своему: где-то account_id, где-то accountId, где-то вложенный объект с тем же смыслом. Отсюда и берутся недели на подключение, хотя сам код интеграции может занимать дни.
Отдельная проблема, что результат такой проверки плохо воспроизводится. Один специалист считает покрытие полей так, другой иначе, а на вопрос «почему вы решили, что банк готов» отвечает уже переписка в мессенджере. Для регулируемой сферы это слабое место: нужна проверяемая оценка, а не устная договорённость.
Ключевые возможности Compass
Архитектурно Compass собран из оркестратора и семи агентов: поиск, Q&A по документации, классификация документов, маппинг полей, анализ, интерактивные сценарии и анализ готовности. Оркестратор определяет интент запроса и решает, кто будет его обрабатывать. Такой набор закрывает полный цикл: от нахождения нужной спецификации до итоговой оценки готовности банка к production.
Практический эффект в том, что один и тот же интерфейс отвечает и на вопрос «где в документации описан эндпоинт /accounts», и на вопрос «какие обязательные поля FDX не покрыты в этом API». Раньше это были задачи разных людей и разных инструментов.
Архитектура мультиагентной системы на Amazon Bedrock
Фундамент Compass - Amazon Bedrock AgentCore, среда для запуска агентов с управляемой памятью, идентичностями и трассировкой, плюс фреймворк Strands Agents, на котором описаны сами агенты и их инструменты. Агенты не вызывают друг друга напрямую: каждый запрос проходит через оркестратор. Такой контур проще отлаживать, потому что точка входа одна и вся цепочка видна в трассировке. Обзор возможностей платформы, включая AgentCore и Strands, собран в разборе обновлений Amazon Bedrock за август 2026.
Оркестратор и маршрутизация по интенту
Оркестратор разбирает входящий запрос, определяет интент и передаёт управление нужному агенту. Запрос «проверь, соответствует ли поле account_id стандарту FDX» уходит к агенту маппинга полей. Запрос «покажи документацию по эндпоинту /accounts» уходит к агенту Q&A. Запрос «насколько банк готов к продакшену» запускает агента анализа готовности.
Смысл маршрутизации в том, что каждый агент получает узкий контекст и узкую инструкцию. Классификатор документов не тащит в промпт правила сверки полей, а аналитик расхождений не отвлекается на поиск файлов. Это снижает расход токенов и уменьшает шанс, что модель начнёт отвечать не на тот вопрос, который ей задали.
Семь специализированных агентов
Зоны ответственности разведены достаточно чётко, чтобы отказ одного агента не ломал остальные.
| Агент | Задача | Пример запроса |
|---|---|---|
| Поиск | Находит нужные документы и данные в подключённых источниках | «Найди спецификацию API этого банка» |
| Q&A по документации | Отвечает на вопросы по спецификациям и стандарту | «Как FDX описывает пагинацию списка транзакций» |
| Классификация документов | Определяет тип входящего документа и его назначение | «Это спецификация API или регламент безопасности» |
| Маппинг полей | Сопоставляет поля API банка с полями FDX | «С каким полем FDX соответствует acct_num» |
| Анализ | Ищет расхождения и потенциальные проблемы | «Где расходятся типы данных в этом ответе» |
| Интерактивные сценарии | Моделирует сценарии использования API | «Что вернёт сервис, если токен истёк» |
| Анализ готовности | Оценивает готовность банка к production | «Посчитай readiness-скор для этого банка» |
Разделение на семь ролей выглядит избыточным, пока не начнёшь считать стоимость ошибок. Если один агент и ищет документ, и сопоставляет поля, и оценивает готовность, то промах на этапе поиска молча уезжает в финальный отчёт. Отдельные агенты позволяют увидеть, где именно сломалось, и перезапустить только нужный шаг.
Выбор модели под задачу
Одно из ключевых решений Compass - не привязывать всю систему к одной модели. Классификация документа и разбор короткого вопроса по спецификации требуют компактной и быстрой модели. Сопоставление полей и поиск расхождений в объёмном ответе API требуют более сильной модели с большим контекстом. Amazon Bedrock даёт доступ к разным моделям через единый интерфейс, поэтому переключение между ними не требует переписывать агента.
Экономика здесь простая: каждый запрос, который ушёл к тяжёлой модели без необходимости, стоит дороже и отвечает медленнее. Разделение задач по агентам позволяет отправлять к сильной модели только те шаги, где качество рассуждения реально влияет на результат.
RAG-агент и tenant-scoped grounding: как изолируются данные банков
Ответы на вопросы по документации строятся на RAG, то есть на поиске по базе знаний с последующей генерацией ответа на найденном фрагменте. Основой служит Amazon Bedrock Knowledge Bases: управляемая векторная база, которая избавляет от необходимости собирать и обслуживать поисковый слой самостоятельно. Как устроен агентный поиск с маршрутизацией между несколькими базами знаний и где проходят границы классического RAG, разобрано в отдельном практическом материале.
Зачем отдельный RAG-агент, а не общий поиск
В Compass поиск и RAG разделены. Агент поиска работает с подключёнными источниками и находит сами документы. RAG-агент отвечает на содержательные вопросы по этим документам, обращаясь к векторной базе. Причина простая: у этих задач разные настройки. Поиску важен охват и свежесть индекса, RAG важны размер чанка, топ-k и качество формулировки запроса к векторной базе. Если смешать их в одном агенте, придётся искать компромисс между двумя разными режимами работы.
Отдельный RAG-агент заодно решает проблему цитирования. Когда ответ строится на найденных фрагментах, можно показать, из какого места спецификации взята формулировка. Для проверки соответствия стандарту это критично: инженеру нужно не доверять ответу, а открыть документ и убедиться.
Как работает tenant-scoped grounding
Tenant-scoped grounding означает, что поиск ограничен данными конкретного банка на уровне запроса к базе, а не на уровне инструкции в промпте. У каждого тенанта свой набор документов в векторной базе, и при обработке запроса результаты фильтруются по идентификатору тенанта. Банк A загрузил свою спецификацию API: банк B не получит к ней доступ через Q&A-агента, даже если задаст вопрос с похожей формулировкой.
Разница между «попросили модель не показывать чужие данные» и «модель физически не может получить чужие данные» принципиальна. Первое ломается на хитром промпте или на ошибке в шаблоне, второе держится на архитектуре. Похожий подход к изоляции данных и ролевому доступу применяется и в других проектах на AgentCore, например в мультиагентной системе AvioBook с изоляцией через JWT и Cognito.
У подхода есть цена. Мультитенантная векторная база требует аккуратной работы с индексами и метаданными: при ошибке в тегировании документов фильтр вернёт пустой результат, и агент честно ответит «не нашёл», хотя данные есть. Отладка таких случаев заметно неприятнее, чем отладка обычного поиска.
Безопасность и соответствие SOC 2 и PCI DSS
Compass работает с банковскими данными, поэтому система спроектирована с учётом требований SOC 2 и PCI DSS. Это не отдельный модуль безопасности, а набор решений по всей цепочке: изоляция данных тенантов, контроль доступа, логирование действий агентов и предсказуемость расчётов. Аудит в регулируемой сфере смотрит не на обещания, а на то, можно ли восстановить картину произошедшего и повторить результат.
Детерминированный расчёт readiness-скора
Readiness-скор в Compass считается в коде, а не моделью. Это осознанный выбор. Если итоговую оценку готовности банка формирует LLM, то один и тот же набор входных данных может дать разные числа при повторном прогоне. Для внутренней аналитики это терпимо, для отчёта, который уходит банку или аудитору, нет: нужна воспроизводимость.
Схема выглядит так: агенты собирают факты, а расчёт сводит их в число по фиксированным правилам. В качестве иллюстрации: доля покрытых обязательных полей FDX, наличие обязательных эндпоинтов, результаты прогона интерактивных сценариев. Веса задаются в конфигурации, итог вычисляется детерминированно, и любую цифру можно разложить на составляющие. Модель отвечает за извлечение и сопоставление, а не за арифметику.
Побочная выгода: при изменении бизнес-правил правится конфигурация, а не промпт. Промпт-инжиниринг в регулируемом домене плохо подходит на роль носителя требований, потому что его сложно версионировать и объяснять проверяющему.
Аудит и логирование
Система логирует действия каждого агента: какой запрос пришёл, какой агент его обработал, какие данные использовались, что вернулось на выходе. Из этих записей собирается цепочка обработки, которую можно восстановить при разборе инцидента или при проверке. Для SOC 2 важна не только полнота логов, но и их защищённость от изменения: если запись можно переписать задним числом, она ничего не доказывает.
Практический момент, который часто упускают: логи агентов содержат фрагменты банковских данных, поэтому к ним применяются те же требования, что и к самим данным. Хранение, доступ и срок жизни логов приходится проектировать вместе с системой, а не прикручивать после первого аудита.
Наблюдаемость и CI/CD с circuit-breaker
Мультиагентная система ломается иначе, чем монолит. Ошибка может не проявиться как исключение: агент вернёт правдоподобный, но неверный ответ, и внешне всё будет в порядке. Поэтому наблюдаемость в Compass строится по каждому агенту отдельно, а не по системе в целом.
Метрики по каждому агенту
Собираются типовые показатели: время ответа, доля успешных запросов, количество обращений к внешним сервисам, расход токенов и стоимость обработки. Привязка к агенту даёт быструю диагностику: если выросла задержка, сразу видно, что тормозит агент маппинга полей, а не вся платформа. Если вырос расход токенов, понятно, какой шаг начал тянуть в контекст лишние документы.
Отдельно отслеживается качество: доля ответов, где агент не нашёл подтверждения в документах. Рост этого показателя обычно означает проблему с индексацией или с фильтрами тенанта, а не с моделью. Трассировка запросов через AgentCore и внешние системы наблюдаемости разобрана на примере воркбенча Heurist Finance на Amazon Bedrock AgentCore.
Circuit-breaker в CI/CD
Circuit-breaker в конвейере деплоя работает как автоматический предохранитель. Если после выката метрики ухудшаются, выкат отменяется и система возвращается к предыдущей версии. Порог задаётся заранее: например, доля ошибок конкретного агента превысила допустимый уровень, значит новая сборка уходит назад без ручного вмешательства дежурного.
В мультиагентной системе такой предохранитель нужнее, чем в обычном сервисе. Сбой одного агента часто не роняет процесс: оркестратор получает пустой или частичный ответ и продолжает работу, а на выходе получается неверная оценка готовности. Пользователь видит правдоподобный отчёт и не понимает, что часть проверок не выполнилась. Автоматический откат ловит именно такие тихие деградации.
Сравнение с другими AI-ассистентами в регулируемых доменах
Полезно посмотреть, как выглядят соседние примеры. Они не конкуренты Compass, но показывают, какие паттерны уже проверены в продакшене, а какие остаются специфичными для финансового онбординга.
TSA и Salesforce Ace: что общего
TSA развернула ИИ-агента Ace на Salesforce Public Sector Solutions для ответов на вопросы путешественников. Заявленные показатели: около 100 000 разговоров в месяц, 96% типовых запросов решаются без участия человека, экономия более 11 660 часов персонала в год и снижение стоимости взаимодействия более чем на 90%. Цифры взяты из сообщения Salesforce и независимо не проверялись.
Общее с Compass: обе системы работают в регулируемом домене и закрывают поток типовых обращений. Различие в устройстве. Ace ближе к монолитному ассистенту с единой логикой ответа, Compass разложен на семь агентов с разными зонами ответственности и оркестратором сверху. Монолит проще в поддержке на старте, мультиагентная схема лучше держит разнородные задачи: сверку полей, ответы по документации и расчёт готовности трудно уложить в один промпт без потери качества.
Чем Compass отличается от Buildots и Nuance Labs
Buildots применяет компьютерное зрение в строительстве: 360-градусные камеры, дроны и лазерные сканеры сопоставляются с BIM-моделью и графиком работ, обработка занимает от 24 до 36 часов. Nuance Labs привлекла 50 млн долларов Series A при участии NVIDIA и Define Ventures под полно-дуплексную модель человеческого общения. Это разные области применения AI, и сравнивать их с Compass по метрикам бессмысленно.
Ценность сравнения в другом: оно показывает, что мультиагентный подход с изоляцией данных и детерминированными расчётами возникает там, где на кону проверяемый результат. В строительстве это расхождение факта с проектом, в финансах - соответствие стандарту и вывод, который уйдёт в аудит. Compass решает узкую задачу онбординга в open finance и не претендует на роль универсального ассистента.
Практические выводы для команд, внедряющих AI в регулируемых доменах
Из архитектуры Compass переносятся несколько решений, которые не требуют бюджета уровня крупного банка.
Что можно применить сразу
- Разделите задачи между агентами. Классификация, поиск и аналитика требуют разных инструкций и разного контекста. Один универсальный агент на всё даёт непредсказуемое качество на длинных цепочках.
- Изолируйте данные тенантов на уровне запроса к базе знаний, а не через формулировку в промпте. Фильтр по идентификатору тенанта проверяется технически, инструкция в промпте - нет.
- Считайте критичные оценки в коде. Скор, который уходит клиенту или аудитору, должен воспроизводиться при повторном прогоне на тех же данных.
- Подбирайте модель под задачу. Компактная модель на классификации и сильная модель на анализе расхождений дают тот же результат дешевле и быстрее.
- Стройте метрики по каждому агенту. Общие показатели системы не покажут, какой шаг начал деградировать.
- Ставьте circuit-breaker в конвейер деплоя. Автоматический откат по метрикам ловит тихие ошибки, которые не проявляются как падение сервиса.
- Закладывайте требования SOC 2 и PCI DSS в архитектуру. Логи, доступ и срок хранения данных проектируются вместе с системой, а не добавляются перед аудитом.
Ограничения и риски подхода
Мультиагентная схема дороже в поддержке. Семь агентов означают семь наборов промптов, инструментов и тестов, которые нужно синхронно обновлять. Отладка распределённого контура сложнее, чем разбор одного агента, и требует зрелой трассировки с первого дня.
Привязка к Amazon Bedrock даёт удобство и создаёт зависимость от одного вендора. Перенос системы на другую платформу потребует переписать слой работы с моделями, базами знаний и идентичностями. Для части команд это приемлемая цена, для других - повод заранее изолировать вызовы моделей за собственным интерфейсом.
Расходы на токены растут вместе с объёмом проверок. Мультиагентность снижает цену отдельного запроса за счёт выбора модели, но общее число вызовов на один банк велико: поиск, классификация, маппинг, анализ и расчёт. При десятках одновременных онбордингов стоимость становится отдельной статьёй бюджета, которую нужно считать заранее.
И главное ограничение относится к проверке результата. Все заявления о сокращении сроков с недель до минут принадлежат Ninth Wave. Независимых тестов и публичных замеров точности сопоставления полей пока нет, поэтому при выборе подобной системы стоит запрашивать пилот на своих спецификациях: взять два-три API банков с известными расхождениями и посмотреть, найдёт ли система то, что уже найдено вручную.