Когда инвестиционный помощник должен видеть не только prompt

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

Model Context Protocol решает эту проблему как инженерный слой между LLM и внешними источниками. Вместо того чтобы вставлять всё в prompt вручную, можно дать ассистенту контролируемый доступ к данным и инструментам: получить список активов, рассчитать доходность, сравнить бенчмарк, построить сводку по риску.

Для homelab и backend-разработчика MCP интересен не только финансовой темой. Это хороший пример того, как превращать LLM из текстового генератора в управляемый интерфейс к предметной системе.

Что меняется при использовании MCP

Без протокола интеграция часто выглядит как набор самописных вызовов: приложение формирует prompt, добавляет куски JSON, ждёт ответ и пытается разобрать текст. Такой подход быстро становится хрупким. Чем больше функций, тем сложнее поддерживать формат, права доступа и обработку ошибок.

MCP предлагает более понятную архитектуру:

есть клиент, через который работает модель;
есть сервер, предоставляющий инструменты и ресурсы;
инструменты имеют явные параметры;
модель видит доступные действия и вызывает их по необходимости;
приложение может логировать и ограничивать каждый вызов.

В портфельной аналитике это особенно важно. Ошибка в формулировке может привести к неверной интерпретации риска или доходности. Поэтому расчёты лучше выполнять не в модели, а в проверенном коде, а LLM использовать для объяснения результата.

Какие данные стоит отдавать ассистенту

Финансовый ассистент не обязан видеть всё подряд. Ему нужны только те данные, которые помогают ответить на вопрос пользователя. Например, для запроса «почему портфель просел за месяц» достаточно агрегированных позиций, динамики цен, валютного влияния и сравнения с бенчмарком.

Полезные MCP-ресурсы и tools могут выглядеть так:

get_portfolio_snapshot — текущий состав портфеля;
calculate_return — доходность за период;
compare_with_benchmark — сравнение с индексом;
get_asset_allocation — распределение по классам активов;
estimate_risk_metrics — волатильность, просадка, концентрация;
explain_position_change — вклад конкретной позиции в результат.

Такая схема снижает риск галлюцинаций. Модель не придумывает цифры, а получает их из инструментов. Её задача — собрать понятное объяснение и показать, какие факторы повлияли на результат.

Почему расчёты должны оставаться в backend

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

Правильный паттерн — разделить ответственность. Backend хранит данные, выполняет расчёты, проверяет корректность параметров и возвращает структурированный результат. Модель получает уже готовые значения и объясняет их человеку.

Например, tool может вернуть:

{
  "period": "30d",
  "portfolio_return": -2.4,
  "benchmark_return": -1.1,
  "main_factors": ["technology stocks", "currency effect", "single issuer concentration"]
}

После этого ассистент может написать человеческий вывод: портфель просел сильнее бенчмарка из-за концентрации в технологическом секторе и валютного движения. Но сами числа не должны быть результатом свободной генерации.

Безопасность и приватность

Портфельные данные чувствительны. Даже если это учебный проект, стоит сразу проектировать ограниченный доступ. MCP-сервер не должен отдавать секреты, токены брокера, персональные данные и лишнюю историю операций.

Практические правила:

хранить ключи доступа вне prompt;
отдавать модели агрегированные данные там, где это возможно;
ограничивать tools только чтением, если ассистент не должен совершать сделки;
логировать вызовы инструментов;
явно показывать пользователю, какие данные используются;
не смешивать данные разных аккаунтов или окружений.

Особенно важно отделить аналитику от торговых действий. Ассистент может объяснять риск, но не должен автоматически покупать или продавать активы без отдельной политики подтверждений.

Наблюдаемость AI-интеграции

MCP-интеграция — это часть приложения, а не магический слой. Её нужно мониторить так же, как API или очередь задач. Полезно сохранять, какие tools вызывались, какие параметры передавались, сколько времени заняли расчёты и какой ответ получил пользователь.

Это помогает находить ошибки: неверный период, пустой портфель, сбой источника котировок, превышение лимитов, некорректный формат ответа. Без логов разбор жалобы «ассистент написал странный вывод» будет почти невозможен.

Также стоит добавить тестовые сценарии: портфель с одной позицией, мультивалютный портфель, падение рынка, отсутствие данных за период, высокая концентрация в одном активе. Так можно проверять не только код tools, но и качество объяснений.

Где MCP особенно полезен

MCP хорошо подходит для сценариев, где есть предметные данные и набор безопасных операций. Портфельная аналитика — один пример. Тот же подход применим к мониторингу инфраструктуры, CRM, документации, биллингу, домашней автоматизации и DevOps-дашбордам.

Главная идея: модель не должна знать всё из prompt. Она должна уметь запрашивать нужный контекст через ограниченный интерфейс.

Итог

MCP делает AI-ассистента для портфельной аналитики более управляемым. Расчёты остаются в backend, данные выдаются дозированно, tools имеют явные параметры, а модель отвечает за объяснение и навигацию по результатам.

Такой подход полезен и за пределами финансов. Он показывает, как строить LLM-приложения, где важны точность, безопасность и воспроизводимость. Чем меньше магии в prompt и чем больше явных контрактов в инструментах, тем надёжнее становится AI-система.