Обычного RAG было недостаточно и мы построили AI-консультанта по архитектуре
Архитектурные знания редко живут в одном месте. Часть хранится в Confluence, часть — в реестре систем, часть — в ADR, а самая ценная информация часто остаётся в головах экспертов и архитекторов. В масштабе технологического ландшафта банка — со множеством систем, модулей, компонентов, интеграций и команд — традиционные способы обмена знаниями уже не обеспечивают необходимой скорости и полноты доступа к информации. Поскольку архитектурные знания в банке распределены между различными источниками, то на поиск информации уходит много времени, новым сотрудникам сложно разобраться в архитектурном ландшафте банка, а архитекторы и эксперты регулярно отвечают на одни и те же вопросы сотрудников.
На первый взгляд задача похожа на классический RAG: собрать документы, разбить их на чанки, построить эмбеддинги и передавать найденный контекст большой языковой модели для получения нужного ответа. Однако довольно быстро выяснилось, что архитектурные вопросы устроены сложнее обычного поиска по тексту.
В статье расскажем, почему классического RAG оказалось недостаточно, зачем нам понадобился граф знаний, как мы организовали маршрутизацию запросов между источниками банка и к какой архитектуре в итоге пришли.
Почему семантического поиска оказалось недостаточно
В первой версии консультанта мы загрузили в векторную базу архитектурную документацию из Confluence и данные из реестра систем. Этого оказалось достаточно для вопросов, ответы на которые содержались в одном или нескольких текстовых фрагментах:
Какой стандарт регулирует логирование?
Кто владелец системы X?
Где находится описание процесса архитектурного согласования?
Классический RAG, работающий по принципу «разбить документы на чанки, построить эмбеддинги и найти семантически близкие фрагменты», хорошо справляется с простыми вопросами, предполагающими конкретный факт.
Сложности начинаются тогда, когда пользователи задают вопросы о структуре и связях архитектурных объектов:
Покажи модули системы, компоненты которых размещены в облаке.
Какие интеграции затронет изменение компонента?
Построй возможный маршрут взаимодействия между двумя системами.
Обычный RAG ищет фрагменты, семантически близкие к тексту вопроса. Такой подход хорошо работает, когда ответ содержится в конкретном документе, но архитектурные запросы часто требуют целого контекста. Нужно учитывать иерархию «система - модуль - компонент», входящие и исходящие интеграции, владельцев, статусы жизненного цикла, среду размещения и действующие архитектурные ограничения.
Например, чтобы оценить влияние изменения компонента, недостаточно найти его описание. Необходимо определить, к какому модулю и системе он относится, с какими компонентами взаимодействует, какие зависимые системы будут затронуты и какие стандарты применимы к этим связям. Ответ в таком случае не извлекается из одного фрагмента текста, а формируется на основе цепочки отношений между архитектурными объектами.
Поэтому семантически близкий контекст ещё не гарантирует полноты и корректности результата: найденные фрагменты могут описывать отдельные элементы, но не отражать их фактические связи и место в архитектурном ландшафте.
Как решить эту проблему?
Для архитектурных знаний нужны два подхода
Архитектурные знания имеют разную структуру, поэтому мы разделили их на два типа и для каждого выбрали свой механизм поиска.
Первый тип — неструктурированные знания, описанные в материалах Confluence:
архитектурные стандарты и принципы;
паттерны и рекомендации по проектированию;
ADR и описания принятых архитектурных решений;
процессы, регламенты и инструкции;
шаблоны, чек-листы и материалы для онбординга.
Для работы с такими знаниями хорошо подходит векторный поиск. Такой подход позволяет учитывать смысл запроса и находить релевантные фрагменты даже при отсутствии точных совпадений по ключевым словам.
Второй тип — структурированные знания:
системы, модули и компоненты;
владельцы, статусы и жизненный цикл;
иерархия объектов;
интеграционные связи;
сетевое размещение компонентов.
Эти данные можно представить в виде графа. Например:
Система
└── модуль
└── компонент
├── размещён в среде
└── интегрируется с компонентом другой системы
Если представить такую модель только в виде текстовых чанков, информация о структуре и взаимосвязях между объектами частично теряется. Графовая база позволяет сохранить архитектурный контекст в явном виде: представить системы, модули и компоненты как вершины, зафиксировать типы и направления связей, а затем выполнять многошаговые запросы по графу.
Как мы подготовили данные для GraphRAG
В реестре архитектуры Альфа-Банка содержатся данные примерно о 2000 системах и 300 000 иерархических и интеграционных связей. Для переноса этих данных в граф недостаточно механически создать вершину для каждой строки. Сначала нужно договориться о структуре модели GraphRAG:
какие сущности являются вершинами;
какие отношения считаются отдельными рёбрами;
какие атрибуты нужны для фильтрации;
как хранить направление интеграции;
как обрабатывать дубли, удалённые объекты и разные версии данных;
как связывать объект графа с его карточкой в реестре и документами в Confluence.
Каждая связь хранит сведения о потребителе и поставщике: идентификаторы системных модулей, компонентов, портов и сервисов, направление потока данных, ID документа, интерфейса и диаграммы, дату документа и признак наличия сетевого компонента.
Базовая модель включала вершины System, Module и Component, отношения иерархии (иерархия между компонентами систем) и интеграционные связи (интеграция между компонентами систем по архитектурной документации Vision). Даже такая схема уже позволяет отвечать на вопросы, недоступные обычному векторному поиску.
Например, запрос «найти все модули системы, у которых есть компоненты в облаке» превращается в обход графа:
Для анализа влияния изменения нужно пройти по исходящим и входящим интеграциям, определить затронутые компоненты и подняться по иерархии до модулей и систем.
При этом GraphRAG не заменяет векторный поиск, а дополняет его: мы используем граф для запросов, где ответ зависит прежде всего от связей между архитектурными объектами, а не от семантической близости текстов.
Что оказалось сложнее всего
Качество исходных данных
Качество ответа консультанта напрямую зависит от актуальности исходных данных. Если в реестре не указан владелец, интеграция задублирована или статус объекта устарел, консультант не исправит эти недостатки, а лишь отразит их в ответе. Показательный кейс: пользователь задал вопрос, используя сокращённое название системы: «Кто архитектор системы АО?», а векторный поиск не смог идентифицировать нужную систему. Проблему решили путём внедрения единого справочника сокращений для всех систем.
Поэтому подготовка базы знаний не ограничивается загрузкой данных. Она также включает нормализацию, проверку обязательных полей, выявление и устранение дубликатов.
Маршрутизация между источниками данных
Для каждого вопроса важно выбрать подходящий источник данных. Если обращаться ко всем хранилищам сразу, увеличиваются время ответа, стоимость обработки и объём лишнего контекста. С другой стороны, слишком строгая классификация может привести к потере полезной информации.
Поэтому мы добавили слой маршрутизации: он выбирает нужный механизм поиска, а для смешанных вопросов объединяет данные из нескольких источников.
В зависимости от содержания вопроса требуются разные источники знаний и механизмы извлечения контекста. Поэтому мы добавили классификатор, который определяет тип запроса и направляет его по одному из четырёх маршрутов.
№ 1. Реестр систем. Этот маршрут подходит для вопросов о системах, модулях, компонентах, владельцах, статусах, жизненном цикле и интеграционных связях. Пример: «Какие компоненты входят в модуль X и кто их владелец?»
№ 2. Документация в Confluence. Здесь ищутся паттерны, стандарты, принципы, описанные процессы, регламенты и шаблоны. Пример — «Какие архитектурные требования предъявляются к синхронным интеграциям?»
№ 3. Оба источника. Самые полезные вопросы часто требуют объединить фактическое состояние системы с нормативным контекстом. Пример: «Соответствует ли текущая интеграция системы X принятому архитектурному стандарту?» Чтобы ответить, консультант должен получить структуру и связи из реестра, найти релевантные требования в документации и только после этого выполнить сопоставление.
№ 4. Общие знания LLM. Этот маршрут предназначен для базовых архитектурных вопросов, которые не требуют привязки к внутренней базе знаний банка. Пример: «Чем event-driven взаимодействие отличается от request-response?»
Правильно классифицировать вопросы – только часть задачи. Затем консультанту нужно определить в запросе системы, модули и компоненты, учесть ограничения и сузить область поиска. Если вопрос сформулирован слишком широко, необходимо запросить уточнение. Например, фраза «покажи связи истории операций» не указывает ни конкретный сервис, ни интересующий тип связей.
Галлюцинации на стыке источников
Даже если сведения из разных источников корректны, LLM может неверно сопоставить их или сделать ошибочный вывод. Поэтому мы разделили обработку запроса на два этапа: сначала консультант извлекает необходимые данные и связи, а затем формирует ответ с указанием источников.
Права доступа
Ролевая модель ограничивает доступ к чувствительным данным. Консультант учитывает права пользователя до формирования контекста для LLM и получает только те данные и документы, к которым у пользователя есть доступ.
Как устроен архитектурный консультант
Так мы пришли к гибридной архитектуре. Векторная база используется для поиска по смыслу в документации, а графовая — для анализа структуры архитектурного ландшафта банка, зависимостей и интеграционных связей между объектами.
На верхнем уровне консультант состоит из следующих компонентов:
Пользовательский интерфейс — единая точка входа для взаимодействия с консультантом.
Low-code-движок на базе Langflow — управляет сценарием обработки запроса и последовательностью вызова компонентов.
Классификатор запросов — анализирует вопрос и определяет необходимые источники знаний и механизмы поиска.
Векторная база знаний — содержит архитектурную документацию из Confluence: стандарты, принципы, паттерны, ADR, регламенты и другие материалы.
Графовая база знаний — хранит сведения о системах, модулях и компонентах, их атрибутах, иерархических зависимостях и интеграционных связях.
LLM — объединяет полученный контекст и формирует итоговый ответ для пользователя.
В зависимости от типа вопроса консультант использует векторный поиск, обращается к графу или объединяет оба механизма. Такой подход позволяет работать как с текстовыми знаниями, так и со структурой архитектурного ландшафта банка.
Что под капотом архитектурного консультанта
В основе консультанта лежит Langflow — open‑source‑платформа с low‑code‑интерфейсом для создания ИИ‑агентов и построения сценариев обработки запросов.
Сценарий работы консультанта собран в виде flow — визуальной схемы из готовых и собственных компонентов. Каждый компонент выполняет свою функцию: принимает запрос, вызывает модель, проверяет структурированный ответ, выбирает нужный маршрут и подключает источники знаний. Такой подход позволяет поэтапно развивать сценарий: добавлять новые компоненты и источники знаний, не перестраивая весь flow.
В первой версии логика работы консультанта выглядела так:
Chat Input принимает запрос.
LLM-классификатор анализирует вопрос и возвращает результат в виде JSON-объекта заданной структуры.
Компонент проверки JSON читает поле datasource и выбирает одну из веток обработки.
Выбранный агент получает только нужные ему RAG-инструменты: поиск по реестру систем, поиск по Confluence или оба инструмента.
Компонент Chat Output возвращает готовый ответ пользователю и завершает обработку запроса.
От детерминированного workflow к мультиагентной архитектуре
Первую версию консультанта мы реализовали как детерминированный workflow: система классифицировала запрос, выбирала подходящий инструмент, получала контекст и передавала его LLM для формирования ответа. Для типовых запросов этого было достаточно. Но по мере развития сценариев появились запросы, которые требовали сразу нескольких действий: распознать архитектурные сущности, проверить их в реестре, пройти по иерархии или интеграционным связям и сопоставить результат с документацией. Поэтому мы начали распределять задачи между специализированными агентами с подключением инструментов через MCP (Model Context Protocol):
агент по реестру систем ищет системы, модули, компоненты и их атрибуты;
агент по архитектурной документации находит информацию в Confluence;
графовый агент анализирует иерархию объектов и связи между ними;
агент по интеграционным решениям находит похожие реализации;
агент проверки решений сопоставляет их с архитектурными стандартами и паттернами;
агент-оркестратор разбирает запрос на отдельные задачи, выбирает нужных агентов и собирает итоговый ответ.
Логику работы консультанта в low-code-интерфейсе с учётом мультиагентного подхода можно представить так:
Request Classification — определяет тип вопроса и нужные источники, а также возвращает результат в виде структурированного JSON;
Реестр систем Entity Extraction Agent — извлекает из запроса системы, модули и компоненты, проверяет их в реестре и возвращает идентификаторы, названия, типы и найденные связи;
Confluence Agent — ищет стандарты, ADR, процессы и другие материалы через отдельный Confluence RAG;
Реестр систем Entity RAG и Реестр систем Entity Relations — получают атрибуты архитектурных объектов, их иерархию и пути интеграций; работа со связями вынесена в MCP-инструмент;
Term — общий справочник терминов и сокращений, который помогает нормализовать названия перед обращением к источникам.
Мультиагентный подход полезен для сложных запросов, которые действительно требуют нескольких независимых операций. При этом он не должен становиться самоцелью: чем больше автономности получают агенты, тем сложнее воспроизводить результаты, контролировать права доступа, ограничивать количество вызовов и находить причины ошибок.
Поэтому простые сценарии мы оставляем детерминированными, а агентов подключаем только там, где декомпозиция запроса действительно улучшает результат.
Что консультант умеет сейчас
отвечать на вопросы о системах, модулях и компонентах из архитектурного реестра;
находить нужную архитектурную информацию в документации Confluence;
отвечать на вопросы о структуре ИТ-систем, модулей и компонентов, а также о связях между ними;
отвечать на вопросы об интеграциях и находить информацию о взаимодействии систем и компонентов, помогая архитекторам и другим участникам процесса быстрее разбираться в текущей архитектуре и готовить архитектурные артефакты, включая Vision;
помогать оценивать решения на соответствие архитектурным требованиям;
отвечать на базовые архитектурные вопросы с помощью LLM.
Выводы
Консультант не заменяет архитектора и не принимает решения за него. Его задача — быстро собрать необходимую информацию: найти подходящие архитектурные стандарты и паттерны, показать структуру систем и связи между ними, подготовить качественный контекст для анализа. Таким образом, архитектурный консультант становится помощником для архитекторов и участников процесса: он помогает быстрее находить знания, эффективнее создавать артефакты и повышать качество принимаемых архитектурных решений.
Архитектурные знания — это не только документы в Confluence. Это также сведения о системах и компонентах, их владельцах, статусах, иерархии объектов и интеграционных связях. Поэтому одного механизма поиска для работы с такими данными недостаточно.
Векторный поиск помогает найти нужную информацию в документации, граф — построить связи между объектами, а маршрутизация — выбрать подходящий источник для конкретного вопроса. При этом результат по-прежнему зависит от полноты и актуальности исходных данных, корректности связей между объектами.
Если вы создаёте похожее решение, начните не с выбора модели или технологии, а с анализа источников данных и реальных вопросов пользователей. Именно они помогут понять, где достаточно обычного RAG, где нужен GraphRAG, а где запрос стоит разделить между несколькими агентами. В нашем случае архитектура консультанта развивалась вместе с задачами: каждый новый механизм появился как ответ на конкретное ограничение.
Читайте также:
KioskNews shows a cleaned-up reading view extracted from the publisher’s page — the original always lives on their site, not ours.