Команда МТС Web Services опубликовала детальный разбор того, как простой поисковый ассистент для техподдержки эволюционировал в полноценную ИИ-платформу. Развитие шло не от большой архитектурной задумки, а от конкретной боли: инженеры всё равно бегали между Kibana, базами данных и Jira - RAG закрывал лишь часть рабочего процесса.
Почему поиска по документам оказалось мало
После первых недель работы RAG-помощника стало очевидно: найти инструкцию - это не то же самое, что расследовать инцидент. Почему не дошло SMS, откуда ошибка интеграции, какой статус у объекта в базе - всё это требовало живых данных, а не документации. Инженер искал ответ в одном интерфейсе, потом шёл в другой, потом вручную собирал всё в комментарий к тикету. Классическая потеря времени на склейку инструментов.
Вместо того чтобы строить новую систему с нуля, команда сохранила поиск по базе знаний как ядро и начала наращивать вокруг него слои. Логи, доступ к PostgreSQL, автоматический анализ Jira-тикетов и единый чат-интерфейс через Open WebUI - всё это появилось не одновременно, а по мере роста реальных задач.
Архитектура: от Streamlit-прототипа к сервисной модели
Первая версия существовала как Streamlit-приложение со встроенной логикой. Удобно для прототипа, но плохо масштабируется. Когда появились новые интерфейсы и сценарии, поиск, работу с контекстом и генерацию ответов вынесли в отдельный RAG API. Теперь Streamlit, Open WebUI и обработчики Jira - просто его клиенты. Разные фронты, одно ядро.
Доступ к API реализован через OpenAI-совместимый протокол. Параллельно подняли собственный MCP-сервер - он нужен для интерактивного чата в Open WebUI и интеграции со средой разработки. Для фоновых сценариев, где важны таймауты и предсказуемость, Jira-обработчик и RAG-оркестратор ходят к сервисам напрямую по HTTP, без лишнего посреднического слоя.
Зачем делить на сервисы: дело не только в гибкости
Ключевая причина декомпозиции - разброс в длительности операций. Поиск по базе знаний занимает секунды. Анализ логов или обработка тикета - это уже несколько запросов к внешним системам плюс дополнительные вызовы языковой модели. Если не изолировать эти процессы, тяжёлый анализ будет тормозить быстрый поиск.
- Сервис анализа логов работает независимо от пользовательских запросов
- Обработка Jira-тикетов идёт в фоне, не конкурируя с интерактивным чатом
- Postgres Retrieval Service изолирован и не влияет на время ответа RAG
- MCP остаётся слоем только для интерактивных сценариев и IDE
Результат - путь тикета от создания до автоматического комментария теперь полностью автоматизирован. Инженер больше не собирает картину вручную из пяти вкладок. Система делает это сама, а человек получает готовый срез с контекстом, данными и первичной гипотезой о причине инцидента.