Помощники по расследованиям в корпорациях нуждаются в EA, LangGraph, MCP и RAG.
Корпоративные расследования объединяют тикеты, журналы и учетные книги в рамках системы управления. Почему для получения доказательств требуются EA, LangGraph и MCP, а для объяснений — RAG, поэтапно.
Архитектура предприятия для помощника в расследованиях с использованием нескольких источников данных — бэк-офис, логи Grafana и сводки транзакций
Следователи редко работают в одной системе хранения данных. Полезный помощник должен синхронизировать заявки из бэк-офиса, логи Grafana и сводки транзакций в одной временной шкале. Это проблема архитектуры предприятия: определение границ, правил управления и поэтапная реализация — а не просто викенд-чатбот.
Почему это проблема архитектуры предприятия, а не проект по созданию «чатбота»
Интерфейсы чатов скрывают сложные аспекты: какой источник считается авторитетным для определения суммы, кто имеет доступ к персональным данным, как инструменты взаимодействуют между сетевыми зонами и как ответы основаны на доказательствах. Документы с записями архитектурных решений и этапы в стиле TOGAF помогают четко определить эти вопросы до того, как их количество возрастет.
ADM в одном предложении
Метод разработки архитектуры последовательно учитывает видение, бизнес-аспекты, данные, технологии, возможности, миграцию, управление и изменения — таким образом гарантируется соблюдение принципов согласия и контроля при реализации проекта.
Предварительный этап — принципы до действий
Заранее согласуйте принципы: минимальные полномочия, требование указания источника или отказ, инструменты должны быть проверены, а RAG предоставляет пояснения, а также необходимо человеческое одобрение для непоправимых действий. Без принципов каждый новый инструмент создает собственную модель доверия.
Этап А — Видение архитектуры: описание проблем на языке бизнеса
Специалисты тратят часы на переход между порталами, пытаясь ответить на вопрос «что произошло с этой оплатой?». Успех в реализации видения архитектуры проявляется в виде целостного повествования с ссылками на идентификаторы заявок, строки журнала и записи в учетных книгах — а не в виде обычного эссе, написанного с помощью ИИ.
Этап Б — Бизнес-архитектура: что означает расследование
Карта ролей (аналитик, специалист по борьбе с мошенничеством, аудитор), триггеров (возврат средств, оповещение об аномалии) и результатов (завершить, перевести на более высокий уровень, запросить дополнительные данные). Каждый результат подразумевает разные права доступа к инструментам.
Этап C — Архитектура данных: три истины, одна временная шкала
Системы бэк-офиса, мониторинга и транзакций передают лишь частичную информацию. Нормализуйте идентификаторы, часовые пояса и ключи сущностей, чтобы объединение данных было корректным. Храните информацию о происхождении каждого полученного фрагмента данных.
Этап D — Технологическая архитектура: LangGraph, MCP, роли RAG
LangGraph координирует рабочие процессы расследований с учетом текущего состояния. MCP обеспечивает доступ к контролируемым инструментам в изолированных системах. RAG обобщает и объясняет информацию; он не создает балансы самостоятельно.
User question →
classify intent + extract entities (player_id, time window, txn id)
→ plan tools (which sources, in what order)
→ execute tools (parallel where independent)
→ reconcile (timeline merge, conflict detection)
→ answer (cited) OR escalate
Почему LangGraph? (Решение ARB)
Отдел расследований: иногда сначала извлекают логи, иногда — учетные записи, а иногда ждут вмешательства человека. Графики с точками контроля эффективнее линейных цепочек, когда паузы и повторные запуски являются обычным явлением.
MCP — один протокол, множество корпоративных границ
Каждый сервер MCP расположен на границе доверия с собственной системой аутентификации. Агент находит необходимые инструменты, не встраивая каждый SDK. Политики сети привязаны к серверам, а не к тексту запросов.
RAG — объяснение; инструменты подтверждают
Встроенные модели восстанавливают контекст повествования; проверки баланса и запросы к логам обрабатываются через инструменты, взаимодействующие с системами хранения данных. Смешивание этих подходов без меток создает ложное чувство уверенности.
Этап E — возможности и решения
Разрабатывайте собственные механизмы оркестрации; покупайте или переиспользуйте соединители там, где поставщики уже обернули основные системы; избегайте переписывания Grafana или учетных записей.
Этап F — миграция: пилот без риска для банка
Начните с одного типа расследования и одного бизнес-подразделения, при этом ответы должны проверяться людьми. Расширяйте источники только после того, как показатели «цитировать или отклонить» стабилизируются.
Этап G — Управление реализацией
ARB фиксирует решения: какие инструменты разрешены, где хранятся секретные данные и как сохраняются следы.
ADR-008:
Player investigation assistant
LangGraph orchestration, MCP tools, RAG for context onlyStatus:
Accepted Date: 03/01/2026
Deciders: Architecture Board, Support Ops, Fraud, Payments, SRE, Data Platform, Risk
Context: Support, fraud ops, and back office investigate player issues by manually querying transaction summaries, Grafana/Loki logs, and back-office APIs. Answers are slow, inconsistent, and hard to audit. A generic "chat with your data" approach risks hallucinated financial facts and unbounded database access.
Decision Build an internal player investigation assistant: LangGraph- stateful orchestration (classify → plan → execute tools → reconcile → answer or escalate). Chosen over linear chains and one-shot prompts because investigations branch (payment vs gameplay vs bonus), require explicit state for audit, and need deterministic edges (e.g. FAILED txn → always pull payment-service logs) that ARB can diagram and version in Phase H MCP servers - one bounded tool surface per system of
record: `transaction_summary` - read-only parameterized queries on summary views `grafana_loki` - time-bounded LogQL with service allowlist `back_office` - scoped REST for account flags and context RAG - embed docs only (schema, enums, runbooks, ADR snippets); never live txn rows or log streams Citations required - factual claims must reference tool output ids Fail closed on ambiguous `player_id` or conflicting tool resultsConsequences Positive: Faster investigations; consistent citations; reusable MCP servers for future automations; clear security boundary (tools vs retrieval). Negative: LangGraph flow maintenance; MCP server ownership per domain team; golden-question regression suite required on model changes. Obligations: No free-form SQL from the model; quarterly access review; version MCP schemas when summary views change; shadow mode before full rollout.Alternatives considered | Alternative | Why rejected | |-------------|--------------| | Single prompt with DB + Grafana credentials | Ungovernable; audit nightmare | | RAG over exported txn/log snapshots | Stale truth; PII surface area | | Buy vendor "AI ops" suite only | Poor fit to gaming txn + custom back office; lock-in | | Dashboards only | Solves visibility, not synthesis and audit trail | | Autonomous agent with write tools | Unacceptable risk on wallet/account paths for v1 |
Этап H — Управление изменениями
Модели могут меняться, но политика расследований должна оставаться неизменной. Используйте уведомления о версиях и инструменты вроде API; переподготавливайте сотрудников, когда меняется поведение отклонения запросов.
Чему мы научились («и», а не «против»)
LangGraph и MCP и RAG взаимодействуют между собой: они обеспечивают оркестрацию, доступ к данным и объяснение результатов. Рассматривать их как конкурентов — значит тратить ресурсы впустую.
Когда не стоит это создавать
Если один поиск в CRM уже позволяет ответить на 95% запросов, использование агента с несколькими источниками будет излишним. Создавайте такой агент тогда, когда основной проблемой является сбор информации из разных систем.
Заключение
Помощники в корпоративных расследованиях демонстрируют эффективность, когда архитектура определяет факты, инструменты и участников процесса — после чего LangGraph просто реализует этот план.
Более подробные замечания по добавлению этапа C
Исследователи теряют доверие, когда временные метки отличаются на несколько часов из-за того, что одна система использует координаты UTC, а другая — локальное время. Необходимо стандартизировать использование UTC в интерфейсе отображения временных рядов помощника и показывать исходные часовые пояса в качестве метаданных. Разрешение идентичности сущностей (идентификаторы аккаунтов, электронные адреса и идентификаторы устройств) должно регулироваться в рамках архитектуры данных, а не определяться с помощью простых запросов. Лучше использовать детерминистичные методы поиска основных данных через инструменты MCP, чем полагаться на нечеткие алгоритмы RAG.
Более подробные замечания по управляющей плоскости этапа D
В состоянии LangGraph должны храниться идентификатор расследования, идентификатор участника, список разрешенных инструментов и временная память с гипотезами. Описания инструментов MCP должны указывать класс побочных эффектов (чтение или запись). Коллекции RAG делятся в зависимости от уровня конфиденциальности. ARB должен отклонять такие решения, которые позволяют модели генерировать SQL-запросы к производственным хранилищам; только специально отобранные инструменты могут взаимодействовать с этими системами.
Важные показатели для тестирования
- Медианное время до нахождения первого упомянутого доказательства
- Процент ответов, содержащих по меньшей мере два независимых источника
- Частота вмешательства человека при использовании инструментов
- Частота отказов при недостаточности доказательств
- Количество заблокированных попыток доступа от других пользователей
Показатели вроде «количество отправленных сообщений» не свидетельствуют о практической ценности системы для расследований.
Антипаттерны
Создание мега-индекса всего без полей ACL; предоставление ИИ возможности выбирать нативные драйверы баз данных; пропуск этапа H, в результате чего запросы меняются еженедельно без проверки; рассмотрение Grafana лишь как дополнительного инструмента для отображения цветов, а не как основного канала сбора информации о сбоях во время работы.
Пример из практики
Аналитик спрашивает, почему произошла отмена выплаты. Система открывает инструмент для анализа случаев (бэк-офис), извлекает соответствующие идентификаторы транзакций, проверяет логи за период проведения операции и только затем составляет краткое резюме с ссылками на источники. Если логи отсутствуют, ассистент отказывается давать однозначный ответ и просит уточнить временной диапазон — вместо того чтобы выдумать объяснение.
Краткие описания архитектуры безопасности
Размещайте серверы MCP в тех же зонах безопасности, что и системы, которые они обрабатывают. Оркестратор в зоне DMZ должен видеть только конечные точки инструментов, а не строки подключения к базам данных. Краткосрочные токены для каждого расследования лучше, чем долгосрочные ключи сервиса, используемые между агентами. Записывайте вызовы инструментов в неизменяемый журнал аудита, отдельный от трассировок моделей, чтобы службы контроля могли определить, кто извлек какую информацию, не загружая полные запросы.
Связь с существующими решениями ITSM
Не заменяйте инструменты управления случаями сразу же. Записывайте выводы ассистента в виде комментариев к случаю с указанием источников. Аналитики остаются ответственными; графовая структура ускоряет сбор информации. Пилотные проекты фазы F, направленные на автоматическое закрытие случаев, обычно сталкиваются с проблемами доверия — режим теневых комментариев помогает создать это доверие с использованием доказательств.
Навыки против базовых инструментов (дополнительный уровень)
По мере роста каталогов инструментов навыки анализа могут обрабатывать последовательности действий (получение случая → извлечение транзакций → поиск в логах → подведение итогов), при этом MCP остается слоем функциональных возможностей. Это соответствует общему направлению развития отрасли и не требует создания нового стандарта до тех пор, пока пилотный проект не докажет свою ценность.
Краткое резюме для ARB
Просите финансирование на основе сокращения времени обработки и улучшения возможностей аудита, а не на основе «наличия агента». Покажите демонстрацию изменений во времени с использованием трех источников. Обещайте отклонять тарифы и тесты ACL в качестве критериев выпуска. В таком контексте LangGraph и MCP являются деталями реализации утвержденной архитектуры, а не отдельным научным проектом.
Контракты на данные для трех истин
Опубликуйте небольшую схему для CaseEvent, LogAnchor и LedgerPosting, которая используется инструментами MCP и индексаторами. Хронологии расследований десериализуют эти объекты, а не текстовые данные. Если источник не может предоставить поле, явно отметьте его как null, чтобы синтезатор не выдумал значения. Контракты развиваются по тому же пути ARB, что и сервисы — а не только путем редактирования промптов.
Документируйте предположения, связанные с потоком управления, рядом с кодом, чтобы будущие изменения не могли незаметно удалить какой-либо элемент или фильтр. Предпочитайте утверждения, проверяемые машиной, вместо знаний, передаваемых только в чатах. Проводите тренировки на случай сбоев каждый раз, когда меняются правила топологии или идентичности.