Как выбрать архитектуру RAG: вектор, гибрид, агент

Почему это сложное решение

Каждая статья про RAG начинается с одной диаграммы: запрос - векторный индекс - top-k - LLM - ответ. На практике большинство проектов, стартующих с этой схемы, через три месяца упираются. Причина: чистый вектор отлично работает на демо с 200 документами и ломается как только вы загружаете 50К документов с разным уровнем авторитетности, разными языками и сроками действия.

Этот гайд описывает три базовых семейства RAG-архитектуры - чистый вектор, гибрид и Agentic - и объясняет когда переходить из одного в другое. Опыт основан на пилотах SLAtech в медицине, гостеприимстве, образовании и финансах.

Семейство 1: чистый вектор

Запрос embedding'ится в вектор, ищутся ближайшие в pgvector / Pinecone / Qdrant, top-k возвращается, LLM получает контекст и отвечает.

Когда работает:

• Единая база знаний, однородная по типу и авторитетности.
• Меньше 10 000 документов, меньше 1 GB текста.
• Один язык.
• Контент, не зависящий от даты - продуктовая документация, FAQ, словарь терминов.

Где ломается:

• Устаревшие документы остаются семантически близкими - вектор не знает что протокол сменили два года назад. Опасная галлюцинация.
• Запрос с точным числом (артикул, пункт договора) - семантическая близость возвращает «похоже», не «точно».
• Мульти-язычный контент - современный embedding работает между языками, но качество распределения менее стабильное.

Семейство 2: гибрид (вектор + keyword)

Два этапа поиска параллельно: семантический вектор (embedding) + keyword-поиск на BM25 / Postgres FTS. Два набора результатов мерджатся в reranker (часто маленький cross-encoder), и только тогда LLM видит финальный top-k.

Почему переходить:

• Запросы с цифрами, артикулами, названиями брендов - keyword ловит то, что вектор пропускает.
• Русские запросы с морфологическими формами - комбинация лемматизации keyword + embedding даёт лучший recall.
• База знаний где «точно» так же важно как «близко» (договоры, протоколы, compliance-документы).

Цена:

• Два индекса в поддержке. Два типа мониторинга.
• Latency растёт - reranker добавляет 30-150ms. В интерактивном чате это заметно.
• Команда должна понимать оба мира поиска. На демо это не проблема; в продакшене - главный источник тихих багов.

Семейство 3: Agentic RAG

LLM сама становится агентом, решающим какие поисковые операции выполнить и в каком порядке. Вместо одного «слепого» retrieval'а перед генерацией, агент может выполнить несколько поисков, обратиться к внешним инструментам, и собрать сложный ответ.

Почему переходить:

• Сложные запросы, требующие нескольких источников - «в чём разница между протоколом 2023 и 2026, и какая текущая рекомендация для беременной пациентки?»
• Необходимость реального взаимодействия с внешними системами - слот расписания, динамический прайс, CRM.
• Сценарии, требующие «планирования» - агент решает что сначала надо аутентифицировать пользователя, потом проверить историю, и только потом предложить действие.

Цена:

• Latency существенно выше - каждый вызов инструмента = round-trip к LLM. Ответ 2 секунды в чистом векторе становится 7-15 секунд в Agentic.
• Стоимость API растёт в 3-7 раз.
• Нужна серьёзная observability framework - без встроенного трекинга «какие инструменты были вызваны и почему» дебажить невозможно.
• Уязвимость к prompt injection через инструменты возрастает - нужен sanitization слой на каждом входе с внешнего API.

Триггеры миграции между семействами

Частые ошибки

1. Прыжок в Agentic до того как выжали гибрид. В 80% случаев гибрид + хороший reranker решает проблему за половину стоимости.
2. Один индекс на всё. Авторитетные документы, рекомендательные и архивные должны быть в разных индексах. Смешение = галлюцинация.
3. Поиск без дата-фильтра. Регуляторный контент меняется. Без приоритизации «свежее 2024», вы строите систему советов с устаревшим контентом.
4. Нет reranker'а. Сырой top-k в LLM = заметный процент шума. Маленький cross-encoder улучшает recall@5 на десятки процентов.
5. Нет аудит-трейла. Если нельзя вернуть «какие куски источника LLM видела» - в regulated production это всё отменяет.

Что брать с собой

1. Начинайте с вектора. Большинство команд не в Enterprise-data режиме не нуждаются в большем. Сэкономьте 2 недели вместо 6 месяцев.
2. Планируйте переход на гибрид с первого дня. Триггеры выше - запишите их в документации.
3. Agentic это не «апгрейд», это другая архитектура. Переходите только когда есть use case, который гибрид не решает.
4. Смотрите на observability до выбора LLM. Без встроенного tracing - потеряете дни на дебаг.