Почему Jefferies решили строить AI-ассистента: боль фронт-офиса
Трейдинговый деск крупного инвестиционного банка генерирует терабайты данных ежедневно. Каждая сделка, каждый поток котировок, каждое FIX-сообщение оседает в хранилищах. Но доступ к этим данным для фронт-офиса оставался узким горлышком.
Трейдеру нужен ответ здесь и сейчас. Рынок не ждёт. А стандартный процесс выглядел так: запрос на новый дашборд или нестандартный отчёт уходил в IT-очередь, где лежал днями. Команда разработки перегружена - помимо стратегических задач, они вручную настраивали визуализации, писали SQL-запросы под ad-hoc вопросы, согласовывали форматы вывода. Трейдер терял время, рынок уходил, возможность закрывалась.
Jefferies работает с многомиллионными наборами данных из memory-гридов и потоков FIX-сообщений. Скорость реакции здесь - конкурентное преимущество первого порядка. Задержка в несколько часов на получение аналитики по нестандартному запросу могла означать упущенную сделку. IT-команда тонула в рутине, а бизнес-пользователи оставались зависимыми от технических специалистов для каждого шага влево от утверждённых дашбордов.
Банк поставил задачу: дать трейдерам инструмент, который понимает вопрос на естественном языке и возвращает готовую визуализацию за секунды. Инструмент, который не требует знания SQL, не ждёт разработчика и не создаёт новых дыр в комплаенсе. Решением стал агентный AI-ассистент на базе Amazon Bedrock, Strands Agents и протокола MCP.
Архитектура решения: как запрос на естественном языке становится визуализацией
Архитектура ассистента выстроена вокруг трёх ключевых слоёв: интерпретация запроса, выполнение к данным и визуализация результата. Каждый слой реализован отдельным компонентом, что позволяет независимо масштабировать и обновлять части системы.
Flow обработки запроса выглядит так. Трейдер вводит вопрос: «Покажи топ-10 акций по объёму торгов за последний час в моём секторе». Ассистент на базе Strands Agents принимает этот текст и запускает цепочку обработки. Foundation-модель через Amazon Bedrock интерпретирует интент пользователя, определяет требуемые таблицы и поля, генерирует SQL-запрос. SQL уходит в вычислительный слой, который работает напрямую с memory-гридами и хранилищами FIX-сообщений. Результат запроса возвращается агенту, который формирует визуализацию - график, таблицу или сводку - и отдаёт пользователю.
Агентный подход позволяет обрабатывать сложные многошаговые запросы. Трейдер может спросить: «Сравни волатильность моего портфеля с рыночной за последние три дня и подсвети инструменты, где отклонение превысило два стандартных отклонения». Ассистент разбивает это на подзадачи: извлечь состав портфеля, вытащить исторические цены, рассчитать волатильность по каждому инструменту, сравнить с бенчмарком, отфильтровать выбросы, построить визуализацию. Strands Agents оркестрирует эту цепочку, управляя состоянием и обрабатывая ошибки на каждом шаге.
Роль Amazon Bedrock и Strands Agents в оркестрации
Amazon Bedrock выступает как управляемый сервис доступа к foundation-моделям. Jefferies не управляет GPU-кластерами, не следит за версиями моделей и не решает проблемы инференса. Bedrock предоставляет API к моделям класса Claude с гарантиями безопасности и комплаенса, критичными для финансовой организации.
Strands Agents - фреймворк для построения агентных рабочих процессов. Он берёт на себя разбиение сложного запроса на атомарные шаги, вызов внешних инструментов (SQL-движок, генератор визуализаций) и сборку финального ответа. Выбор в пользу Strands Agents, а не альтернатив вроде LangChain или кастомной оркестрации, обусловлен tight-интеграцией с AWS-экосистемой и встроенными механиками безопасности. Фреймворк работает внутри контура банка, не отправляя данные вовне, и поддерживает все необходимые политики доступа.
Практическое преимущество связки: Bedrock закрывает вопрос «какую модель использовать и как её обслуживать», Strands Agents закрывает вопрос «как собрать из модели полезное действие с вызовом real-time данных». Команда Jefferies сфокусировалась на бизнес-логике и интеграциях, а не на инфраструктурных задачах. Это сократило time-to-market решения и снизило операционные издержки на поддержку.
Протокол MCP: стандартизация взаимодействия с данными
Model Context Protocol (MCP) - открытый протокол для унифицированного доступа к контекстным данным. В кейсе Jefferies он решает проблему разнородных источников: memory-гриды живут в одном формате, FIX-сообщения - в другом, а данные по позициям - в третьем. Без MCP каждый новый источник требовал бы написания коннектора, тестирования и поддержки.
MCP стандартизирует этот слой. Ассистент через MCP-сервер получает описание доступных данных - таблиц, полей, типов, связей - и использует это описание при генерации SQL. Протокол абстрагирует физическое расположение данных: для агента нет разницы, лежат ли они в memory-гриде, в колоночном хранилище или в логах FIX-шлюза. MCP-сервер транслирует запрос в нужный диалект и к нужному источнику.
Результат: добавление нового источника данных не требует переписывания агента. Достаточно реализовать MCP-эндпоинт, который отдаёт схему и принимает запросы. Команда Jefferies получила расширяемую архитектуру, где данные подключаются по стандартному интерфейсу. Аналогичный подход мы разбирали в материале о корпоративной ИИ-архитектуре, где data agents на LangGraph работают поверх Snowflake Cortex Analyst - принцип унификации доступа к данным работает на любом стеке.
Безопасность данных: как Jefferies защищает конфиденциальную информацию
Финансовый сектор не прощает ошибок с данными. Утечка позиций клиента или инсайдерской информации - это не репутационный риск, а прямой путь к регуляторным штрафам и судебным искам. Архитектура ассистента Jefferies закладывает защиту на двух уровнях.
Первый уровень - Amazon Bedrock Guardrails. Этот механизм фильтрует как входящие запросы, так и генерируемые ответы. Guardrails проверяют контент на токсичность, блокируют запросы, которые пытаются обойти системные ограничения, и отслеживают попытки prompt injection. Модель не получит запрос, содержащий инструкции по извлечению чужих данных, и не сгенерирует ответ с чувствительной информацией, если та попала в контекст по ошибке. Bedrock Guardrails работают как независимый слой, который нельзя отключить через промпт - это архитектурное ограничение, а не текстовая инструкция.
Второй уровень - row-level security. Трейдер видит только те данные, которые ему разрешены ролью. Ограничение реализовано на уровне SQL-запросов: перед выполнением агент добавляет в WHERE-условия фильтры по идентификатору пользователя, его desks, разрешённым рынкам и инструментам. Трейдер из нью-йоркского офиса, работающий с equities, не получит доступ к сделкам лондонского fixed-income деска, даже если явно попросит об этом в запросе. Система просто не вернёт такие строки.
Технически row-level security реализована через прокси-слой между агентом и источниками данных. Прокси получает контекст пользователя из SSO-сессии, применяет политики доступа и модифицирует SQL перед отправкой в движок. Это исключает ситуацию, когда модель «забывает» добавить фильтр - ограничение накладывается не промптом, а кодом. Связка Guardrails + row-level security создаёт эшелонированную защиту: первый слой отсекает некорректные запросы, второй гарантирует, что даже корректный запрос не выйдет за пределы полномочий пользователя.
Бизнес-эффекты: что изменилось после внедрения
Главный результат - время получения ответа на ad-hoc аналитический запрос сократилось с дней до секунд. Трейдер больше не пишет тикет в IT, не ждёт, пока разработчик освободится, не согласовывает формат вывода. Он задаёт вопрос в чат-интерфейсе и получает визуализацию немедленно.
IT-команда перестала быть бутылочным горлышком для бизнес-аналитики. Рутинные задачи по настройке отчётов и дашбордов ушли ассистенту. Разработчики сфокусировались на стратегических проектах: улучшении data-инфраструктуры, построении новых моделей риска, оптимизации latency. Это качественный сдвиг в распределении ресурсов - дорогие инженерные часы перестали тратиться на задачи, которые может закрыть AI.
Трейдеры получили автономность. Возможность задать любой вопрос по данным и сразу получить ответ изменила процесс принятия решений. Вместо «подготовьте мне отчёт к завтрашнему утру» - «покажи корреляцию моего портфеля с индексом за последние 30 минут». Скорость итераций выросла кратно. Решение масштабируется на другие desks и офисы - архитектура с row-level security позволяет подключать новых пользователей без риска пересечения данных.
Этот кейс перекликается с опытом Tradeshift, где агентный ИИ на Amazon Quick ускорил запросы в 30 раз и превратил внутреннюю аналитику из центра затрат в доходный продукт. Паттерн один: AI-агент берёт на себя рутинную работу с данными, а люди занимаются тем, что требует экспертизы и суждения.
Практические выводы: что можно забрать в свой проект
Кейс Jefferies подсвечивает несколько архитектурных решений, которые воспроизводимы за пределами трейдинговых десков.
1. Агентное разделение на интерпретацию, выполнение и визуализацию. Монолитный подход, где одна модель пытается сделать всё сразу, нестабилен. Разделение на слои позволяет отлаживать и улучшать каждый компонент независимо. Strands Agents оркестрирует цепочку, Bedrock отвечает за понимание языка, SQL-движок - за работу с данными. Этот паттерн применим в любом домене со сложными аналитическими запросами.
2. Управляемые сервисы снижают порог входа. Jefferies не строит инфраструктуру для инференса - использует Amazon Bedrock. Это экономит месяцы разработки и снимает проблему найма ML-инженеров под обслуживание моделей. Для команд, которые только начинают путь в агентный AI, управляемые сервисы - способ быстро получить результат и итеративно наращивать сложность. Подробный разбор архитектуры самописного агента с альтернативным подходом есть в нашем материале по построению AI-агента с нуля - там сравниваются latency, cost и reliability своего решения против готовых фреймворков.
3. MCP как стандарт подключения данных. Протокол решает проблему N×M интеграций между агентом и источниками. Каждый новый источник подключается через MCP-сервер, агент получает унифицированное описание схемы. Это архитектурный паттерн, который стоит закладывать на старте, даже если источников пока два - их количество будет расти.
4. Безопасность на уровне архитектуры, а не промптов. Bedrock Guardrails и row-level security реализованы как независимые слои, которые нельзя обойти текстовой инструкцией. Это критично для regulated-индустрий: финансы, медицина, страхование. Текстовые ограничения в промпте - не защита, а рекомендация, которую модель может проигнорировать. Интересный ракурс на эту проблему даёт кейс ИИ-агента, который провалил боевые задачи разработки, но неожиданно закрыл 50% исследовательских запросов аналитиков - там архитектура контекстной инфраструктуры на tree-sitter также решала вопросы безопасности через изоляцию данных.
5. Старт с чётко очерченного use case. Jefferies начали с ad-hoc аналитики для трейдеров - одной конкретной боли с измеримым эффектом. Попытка сразу построить универсального ассистента для всего банка утонула бы в требованиях и интеграциях. Узкий старт дал возможность обкатать архитектуру, доказать ценность и затем расширять на другие desks.
Ограничения, которые важно учитывать. Решение требует зрелой data-инфраструктуры: данные должны быть чистыми, каталогизированными и доступными через API или MCP-эндпоинты. Модели могут галлюцинировать - даже с Guardrails нужно мониторить качество SQL и визуализаций. Row-level security работает только если политики доступа корректно настроены и поддерживаются в актуальном состоянии. Агентный AI не заменяет data governance - он добавляет к нему новый интерфейс, и без надёжного фундамента этот интерфейс будет показывать мусор или дыры в безопасности.
Кейс Jefferies показывает, что агентный AI в финансах перешёл из разряда экспериментов в разряд работающих инструментов. Трейдеры получили автономность, IT-команды - разгрузку, а банк - масштабируемую архитектуру для следующих AI-инициатив. Повторить этот путь можно в любой data-зрелой организации, где есть понятная аналитическая боль и готовность инвестировать в безопасность на уровне архитектуры.