Инженеры МТС Web Services опубликовали описание архитектуры ИИ-агента, созданного после внедрения RAG-помощника для технической поддержки. Первоначальная версия на Streamlit обеспечивала гибридный поиск по Confluence и Jira, однако для расследования инцидентов требовался доступ к логам, базам данных и состоянию сервисов. Команда решила не переписывать RAG, а развивать его как платформу, добавив единый интерфейс, доступ к эксплуатационным данным и автоматизацию обработки тикетов.
Ключевым изменением стало выделение поиска, контекста и генерации ответов в отдельный сервис — RAG API, который стал ядром системы. Его клиентами выступают Streamlit, Open WebUI и обработчики Jira. Для интеграции с чатами и средой разработки используется MCP-сервер, предоставляющий инструменты через OpenAI-совместимый API. В то же время фоновые сервисы (анализ логов, Postgres Retrieval) взаимодействуют с RAG-оркестратором напрямую по HTTP, чтобы контролировать таймауты и избежать лишнего уровня при длительных операциях.
| Сервис | Роль |
|---|---|
| RAG API | Гибридный поиск, переранжирование, генерация ответов с цитатами, оркестрация вызовов логов и Postgres Retrieval |
| Сервис анализа логов | Отдельное FastAPI-приложение для интерпретации запроса, каталог микросервисов с привязкой к источникам логов, каскадный поиск, структурированная таблица ошибок |
| Postgres Retrieval Service | План сценариев → SQL только на чтение через MCP → сборка ответа или Excel |
| Автоматический анализ Jira | Celery Beat + worker: периодический опрос Jira по JQL, проверка готовности тикета, маршрутизация, вызов нужных сервисов, публикация результата комментарием |
| MCP-сервер | Тонкий адаптер для чата: инструменты → HTTP-запрос к сервисам выше |
Архитектура включает несколько специализированных сервисов. Сервис анализа логов — отдельное FastAPI-приложение, которое использует каталог микросервисов с привязкой к источникам логов и каскадный поиск: из найденных логов извлекаются идентификаторы, по которым ищутся события в связанных сервисах. Результат возвращается в виде структурированной таблицы ошибок. Postgres Retrieval Service выполняет только чтение через MCP, формируя ответ или Excel-файл. Автоматический анализ тикетов реализован на Celery Beat: воркер периодически опрашивает Jira по JQL, проверяет готовность тикета, маршрутизирует запрос к нужному сервису (логи, RAG или Postgres) и публикует результат комментарием.
Выделение сервисов позволило изолировать операции с разным временем выполнения. Если поиск по базе знаний занимает секунды, то анализ логов или обработка тикета требует нескольких запросов к внешним системам и дополнительных вызовов LLM. Разделение гарантирует, что длительные задачи не блокируют пользовательские запросы. При этом MCP остаётся тонким адаптером для интерактивного чата, а HTTP-вызовы используются в фоновых сценариях.
Инженеры отметили, что отказались от полностью автономного агента: в критических случаях требуется человеческий контроль. Вместо этого система предлагает готовый анализ, но окончательное решение остаётся за инженером. Среди удачных решений — использование MCP для унификации доступа к инструментам, а среди сложностей — необходимость синхронизации разных схем данных. В планах — расширение поддержки новых источников и улучшение точности каскадного поиска.
