Как выбрать архитектуру 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'а перед генерацией, агент может выполнить несколько поисков, обратиться к внешним инструментам (API расписания врачей, расчёт страховой цены, поиск в юридическом архиве), и собрать сложный ответ.

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

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

Цена:

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

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

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

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

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

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