Векторная база — не ответ на всё: Traditional, Vectorless и Hybrid RAG

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

Дело не в том, что векторный поиск «неправильный». Дело в том, что он не всегда уместный. Прежде чем что-то строить, стоит ответить себе на вопрос: какая архитектура поиска подходит моим данным, моим запросам и моим продакшен-ограничениям? Правильный ответ, найденный на старте, экономит недели отладки, которые иначе уходят на починку системы уже под нагрузкой.

Ниже разберём три подхода на конкретных примерах: классический — с векторной базой, «бесвекторный» (Vectorless) — с точным поиском по уже существующим данным, и гибридный — их сочетание. Материал опирается на статью Santosh Mahale «Traditional, Vectorless, and Hybrid RAG»; это взгляд автора, а не доказанные факты — где проходит эта граница, разбираем в разделе «Оговорки».

Что такое RAG и где здесь вообще выбор

Retrieval-Augmented Generation (RAG) — приём, который «подкладывает» большой языковой модели (large language model, LLM) релевантный контекст перед тем, как она сформулирует ответ. На высоком уровне процесс всегда одинаковый: данные и документы попадают в систему; приходит вопрос пользователя; из хранилища извлекается релевантный контекст; модель генерирует ответ, опираясь на него. Без такого контекста модель отвечает по памяти и устаревшим знаниям или уверенно выдумывает.

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

Traditional RAG: семантический поиск по документам

Классический, он же Traditional RAG, — это семантический поиск по векторной базе данных. Механика примерно такая. Документы режутся на фрагменты — чанки. Каждый чанк прогоняется через модель эмбеддингов: она превращает текст в вектор — длинный список чисел, кодирующий смысл фрагмента. Смысловое пространство устроено так, что близкие по смыслу тексты оказываются рядом. Векторы складываются в векторную базу. Когда приходит запрос, его точно так же превращают в вектор и база возвращает чанки с максимальной семантической близостью — top-k. Дальше эти чанки попадают в промпт вместе с вопросом, и LLM формулирует ответ.

Пример из статьи — страховая компания. Глобальный страховщик строит RAG по десяткам тысяч полисных документов. Клиент спрашивает: «Что моя страховка покрывает при затоплении арендованной недвижимости?» Вопрос сформулирован обычными словами, и дословного совпадения с текстом полиса ждать не приходится; поиск по ключевым словам такой запрос, скорее всего, не решил бы. Векторный поиск справляется, потому что сравнивает не слова, а смысл: близкие по смыслу фрагменты оказываются рядом, даже когда формулировки полностью разные.

Сильные стороны Traditional RAG:

• Отличный семантический поиск: находит релевантный контент, даже когда слова в запросе и в документе не совпадают.
• Хорошо работает с большими коллекциями неструктурированных документов.
• Естественно обрабатывает запросы на естественном языке.

Реальные издержки:

• Каждый документ и каждый запрос прогоняются через модель эмбеддингов — это дополнительные расходы.
• Задержка: поиск по векторной базе добавляет время к ответу, а опциональный этап реранкинга — переоценки найденных фрагментов отдельной моделью — увеличивает задержку ещё сильнее. Для Traditional RAG реранкинг не обязателен; его подключают как улучшение качества.
• Стратегия нарезки на чанки — отдельная инженерная задача: слишком мелкие куски теряют контекст, слишком крупные — «размывают» релевантность.
• Векторная база добавляет инфраструктурную сложность: её нужно поднимать, поддерживать и масштабировать.

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

Vectorless RAG: точный поиск без эмбеддингов

Второй подход — Vectorless RAG — в туториалах почти не встречается, хотя заслуживает гораздо большего внимания. Он извлекает релевантный контекст без векторной базы: за счёт точного поиска, фильтров по базе данных, вызовов API или обхода графа знаний.

Процесс выглядит так: вопрос → лексический или SQL-поиск → релевантные записи → сборка промпта → ответ LLM. В качестве механизмов поиска используются BM25 (распространённый алгоритм поиска по ключевым словам), а также SQL-фильтры, REST API, полнотекстовые индексы и графы знаний. Никаких эмбеддингов и векторного хранилища — только поиск по данным, которые у вас уже есть.

Пример из статьи — Kubernetes и дежурные инженеры. Инженерная команда делает ИИ-ассистента для коллег на дежурстве. Ассистент отвечает на вопросы вроде «Покажи все события CrashLoopBackOff в namespace payment-service за последние два часа» или «Какой код ошибки был у пода xyz-123 в 02:14?». Это не семантический поиск, а точные запросы к структурированным логам. Vectorless-система, которая ходит в систему логирования напрямую через SQL и API, отвечает на них за миллисекунды — так описывает пример автор. Векторная база здесь добавила бы только инфраструктурные расходы, никак не улучшив качество поиска.

Сильные стороны Vectorless RAG:

• Заметно ниже инфраструктурная сложность: не нужно поднимать, поддерживать и масштабировать векторную базу.
• Отлично подходит для точных терминов, идентификаторов, логов, кода, таблиц и структурированных записей.
• Свежие данные доступны сразу — их можно искать напрямую, без повторного эмбеддинга.
• Низкая и предсказуемая задержка: лексический поиск и SQL быстры.
• Нет проблемы нарезки на чанки: вы запрашиваете структурированные записи напрямую.

Главное ограничение:

• Система может пропустить смысловые совпадения, если слова пользователя отличаются от терминов в индексе.
• Требуется аккуратная переформулировка запросов и ранжирование, чтобы обрабатывать неоднозначные вопросы на естественном языке.
• Не подходит для неструктурированных текстов, где смысл важнее точных терминов.

Когда подходит: точные запросы к структурированным данным. Анализ логов, запросы к базам данных, поиск по API, поиск по записям о соответствии требованиям (compliance), поиск по коду. Если данные структурированы, а запросы тяготеют к точным терминам, ID или фильтрам — Vectorless RAG это не компромисс, а правильный выбор.

Hybrid RAG: два пути поиска и общий реранкер

Гибридный подход объединяет оба механизма. Вопрос параллельно уходит в векторный и лексический поиск, результаты объединяются и дедуплицируются, а затем реранкер — модель, которая оценивает релевантность кандидатов относительно запроса — отбирает лучший контекст из обоих источников. Уже эти отобранные фрагменты попадают в LLM.

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

Пример из статьи — финансовый ассистент. Финансовая компания строит ИИ-ассистента для менеджеров по работе с клиентами (relationship managers). Менеджеры задают вопросы двух разных типов: семантические — «Какие продукты подходят клиенту, не склонному к риску и планирующему выход на пенсию?» — и точные — «Какая текущая процентная ставка по продукту с кодом FX-2024-GBP?». Чисто векторная система «спотыкается» о точный код продукта, чисто лексическая — о семантический вопрос о подходящих продуктах. Гибрид справляется с обоими типами, а реранкер гарантирует, что до модели дойдут наиболее релевантные свидетельства, каким бы путём они ни были найдены.

Сильные стороны Hybrid RAG:

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

Реальные издержки:

• Сложнее весь процесс: два пути поиска, шаг слияния и реранкер — всё это нужно строить и поддерживать.
• Инфраструктурные расходы выше, чем у Vectorless RAG.
• Реранкер добавляет задержку, которой нужно управлять в приложениях с жёсткими требованиями к латентности.

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

Сравнительная таблица

Дерево решений: с чего начать

Универсальной рекомендации нет, но отправные точки автор формулирует так.

• Данные структурированы, а запросы точные — логи, SQL-таблицы, API, события, записи по compliance, поиск по коду; пользователи ищут по ID, кодам и фильтрам. → Начинайте с Vectorless RAG. Это быстро, без инфраструктуры векторной базы, и для многих задач точный поиск действительно закрывает всё.
• Данные — большие массивы неструктурированных, семантически насыщенных документов — полисы, базы знаний, исследовательские корпуса; пользователи формулируют вопросы своими словами, и точное совпадение слов не находит нужное. → Начинайте с Traditional RAG: инвестиции в эмбеддинги оправданы именно тогда, когда точный поиск физически не может найти то, что ищет человек.
• Типы запросов смешанные и непредсказуемые, качество ответов критично. → Двигайтесь к Hybrid RAG, но не прыгайте туда сразу.

Ключевой принцип автора: стройте сначала самое простое решение, которое закрывает задачу; измеряйте, где оно ошибается; и добавляйте сложность — второй путь поиска и реранкер — только там, где это подтверждается данными, а не интуицией. Мысленная модель из статьи: правильные данные → правильный поиск → правильный контекст → лучший ИИ.

Оговорки: чему из этого можно верить

Исходный материал — публицистическая статья на HackerNoon с пометкой «opinion piece / thought leadership»: это мнение и рекомендации автора, а не исследование с бенчмарками. В тексте нет публичных замеров, сравнительных цифр или эталонных тестов, а примеры — страховая компания, Kubernetes, финансовый ассистент — это иллюстративные сценарии, а не документальные кейсы. Поэтому к утверждениям вроде «ответы за миллисекунды» или «большинство корпоративных RAG-внедрений приходят к гибриду» стоит относиться как к авторской оценке, а не как к доказанной закономерности.

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

Чек-лист перед запуском в продакшен

• [ ] Собрали выборку реальных запросов пользователей, а не придуманных примеров из туториалов.
• [ ] Прогнали их через самое простое решение (BM25 или SQL) и оценили, какая доля ответов приемлема.
• [ ] Зафиксировали, где система ошибается именно из-за поиска, а не из-за модели.
• [ ] Добавили эмбеддинги или реранкер только там, где измеренный провал поиска это оправдывает.
• [ ] Проверили, как система ведёт себя со свежими данными: не требует ли она постоянного пере-эмбеддинга там, где данные меняются часто.
• [ ] Измерили задержку и стоимость на реальном масштабе, а не на демо-наборе.

Вывод

Главный практический вывод материала: большинство сбоев RAG — это, по мнению автора, сбои поиска, а не модели. В контекст попадает не тот материал, и модель уверенно выдаёт неверный ответ. Поэтому архитектура поиска — основной рычаг, и решение о ней, принятое в начале, обходится дешевле, чем отладка системы в продакшене.

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

Источник: Santosh Mahale, «Traditional, Vectorless, and Hybrid RAG: How to Choose the Right Architecture», HackerNoon, 6 сентября 2026.