Варианты архитектуры

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

Ниже шесть уровней, от самого дешёвого к самому дорогому.

Уровень 0. Без индекса: агент с поиском

Никакого хранилища. Агент получает инструменты поиска по файлам и содержимому и ориентируется на месте: ищет по имени, грепает по коду, открывает найденное (см. Инструменты и их вызов).

Для кода это часто и есть лучший RAG. Индекс не устаревает, потому что его нет: агент читает то, что лежит в репозитории прямо сейчас, а настройка не требуется вовсе. Потолок наступает за границей файловой системы: вики, трекер и база инцидентов остаются недоступны. На больших объёмах поиск к тому же начинает возвращать сотни совпадений, и агент тратит контекст на перебор.

Уровень 1. Классический RAG

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

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

Потолок. Точные идентификаторы. Номер задачи PROJ-123, имя таблицы, код ошибки, артикул, аббревиатура домена: на них векторный поиск промахивается. А они и составляют половину вопросов в IT-команде.

Уровень 2. Гибридный поиск

Два поиска вместо одного: векторный по смыслу и обычный по ключевым словам. Результаты объединяются, документ, который нашли оба, поднимается наверх.

Что даёт. Закрывает главную дыру предыдущего уровня. Вопрос «почему seller_payouts пустеет после отмены» находит и раздел про отмены (по смыслу), и все упоминания таблицы (по словам). Для IT-контента гибрид нужен почти всегда, так что считайте второй уровень базовой комплектацией и отправной точкой, а не тонкой оптимизацией.

Потолок. Кандидатов стало больше, а мест в контексте столько же. Нужно уметь выбирать лучшие.

Уровень 3. Реранкинг

Двухступенчатый отбор: дешёвым поиском достаём широкий список кандидатов (скажем, полсотни), затем более умная и медленная модель переоценивает каждого на релевантность вопросу, и наверх идут пять лучших.

Что даёт. Лучшее соотношение прироста качества к сложности после гибрида. Кандидатов можно брать щедро: реранкер отсеет лишнее, а в контекст модели попадёт только отобранное.

Потолок. Реранкер оценивает фрагмент таким, каким его нарезали. Если фрагмент сам по себе непонятен, никакая переоценка не поможет.

Уровень 4. Обогащение и маршрутизация

Два приёма, которые обычно внедряют вместе.

Обогащение фрагмента. К тексту фрагмента добавляется его контекст: заголовок и краткое содержание документа, домен-владелец, дата. Фрагмент «в этом случае комиссия не удерживается» превращается в «Регламент выплат Платежей, раздел «Возвраты после отгрузки»: в этом случае комиссия не удерживается». Теперь его и находят точнее, и понимают правильно.

Маршрутизация. Перед поиском система определяет, к какому домену относится вопрос, и ищет прицельно. Вопрос про ставки рекламных кампаний не должен перебирать документацию WMS.

flowchart TB
    Q["Вопрос: «почему с января возвраты считаются иначе»"]
    ROUTE{"Определение домена"}
    subgraph S ["Поиск только в нужных доменах"]
      direction LR
      P["Индекс: Платежи"]
      R["Индекс: Реклама"]
    end
    RANK["Реранкинг: отобрать лучшие фрагменты"]
    ANS["Ответ со ссылками на ADR"]
    Q --> ROUTE
    ROUTE --> P
    ROUTE --> R
    P --> RANK
    R --> RANK
    RANK --> ANS

Маршрутизация убирает шум чужих доменов, но требует поддерживать карту доменов в актуальном состоянии.

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

Уровень 5. Агентный RAG

Поиск становится инструментом агента, а не шагом конвейера. Агент сам решает, что искать, читает найденное, понимает, чего не хватает, переформулирует запрос и ищет снова, и сам решает, когда остановился.

Так вытягиваются многошаговые вопросы. «Сравни, как возврат обрабатывается у Платежей и у Селлеров, и найди, где расходятся» требует минимум двух поисков и сопоставления результатов, для одного прохода задача неподъёмная. Заодно снимается проблема словаря: не нашлось по одной формулировке, агент попробует другую.

Платить за это придётся временем и деньгами. Ответ занимает не секунду, а десятки секунд, и стоит в несколько раз дороже: агент делает несколько обращений к модели, и каждое несёт накопленный контекст. Плюс агент может зациклиться, и это надо ограничивать.

Практичнее всего построить такой уровень, отдав поиск по базе знаний существующему харнесу как инструмент через MCP-сервер, не изобретая своего агента. Тогда та же база знаний работает и в редакторе разработчика, и в чате аналитика. Подробнее об этом на странице Инструменты вокруг RAG.

Граф знаний (GraphRAG)

Отдельная ветка, не продолжение лестницы. Вместо фрагментов текста или вместе с ними строится граф сущностей и связей: сервисы, команды, события, контракты и то, как они друг на друга ссылаются.

Так отвечают на вопросы про связи: «какие сервисы сломаются, если изменить контракт события о выплате», «через какие команды проходит отмена заказа». Но обходится это дорого. Граф трудно построить и ещё труднее поддерживать: он устаревает быстрее текстов, а его извлечение из документов само по себе задача с ошибками. Оправдан он редко и обычно на узком куске, например только на карте сервисов и контрактов, которую и так поддерживают.

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

Сводная таблица

Уровень	Что чинит	Поддержка	Когда брать
0. Агент с поиском	навигацию по репозиторию	нулевая	всегда, когда речь про код
1. Классический RAG	доступ к текстам вне репозитория	средняя	первый шаг за пределы кода
2. Гибридный поиск	идентификаторы, коды, имена таблиц	средняя	практически сразу, базовый уровень
3. Реранкинг	шум в выдаче, лишний контекст	средняя	когда нужное находится, но не попадает в топ
4. Обогащение и маршрутизация	вырванные из контекста фрагменты, чужие домены	высокая	от нескольких доменов и сотен документов
5. Агентный RAG	многошаговые и сравнительные вопросы	высокая	когда есть вопросы, где одного поиска мало
Граф знаний	вопросы о связях между сущностями	очень высокая	узкие задачи вроде карты сервисов

Что дальше

Что индексировать: решение, которое влияет на качество сильнее выбора уровня.
Поиск без векторов: ветка в стороне от лестницы, для длинных структурированных документов.
Качество и оценка: как понять, что уровень исчерпан и пора выше.

Автор учебника: Шахматов Алексей