Векторная база для RAG: как выбрать без лишней инфраструктуры

Раздел

RAG и базы знаний

Сложность

средняя

Обновлено

2026-05-20

Короткий ответ

Векторная база для RAG нужна не всегда. Если у вас десятки документов и редкие запросы, начните с простого поиска, SQLite, Postgres с pgvector или даже готового managed-поиска. Отдельная vector database нужна, когда корпус растет, нужны фильтры по правам, гибридный поиск, стабильная latency, переиндексация без простоя и понятная эксплуатация.

Выбор делайте не по рейтингу баз, а по требованиям вашего RAG: объем корпуса, типы документов, метаданные, права доступа, частота обновления, SLA, бюджет, команда эксплуатации и сценарий отказа без источника.

Материал связан с общим хабом RAG система, разбором локального RAG и статьей про оценку качества RAG.

Что хранит vector database

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

Минимальная запись:

• уникальный id фрагмента;
• текст или ссылка на текст;
• embedding;
• document_id;
• заголовок и URL источника;
• дата версии;
• язык;
• тип документа;
• права или tenant_id.

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

Критерии выбора

Первый критерий - фильтры. Для корпоративного RAG почти всегда нужно искать не по всему корпусу, а по разрешенному набору: отдел, клиент, проект, роль, версия, язык, статус документа. Если база плохо работает с metadata filtering, ответы будут либо небезопасными, либо нерелевантными.

Второй критерий - гибридный поиск. Векторный поиск хорошо ловит смысл, но может хуже искать коды, артикулы, номера договоров, имена функций и точные формулировки. Для таких запросов нужен keyword или sparse search вместе с dense vectors.

Третий критерий - обновление. Если база знаний меняется ежедневно, индексация должна быть наблюдаемой: сколько документов обновлено, что упало, какая версия индекса отвечает пользователю.

Четвертый критерий - latency. Важно считать не только поиск, но весь путь: права, query rewrite, embeddings, vector search, reranking, генерация, форматирование источников. Быстрая база не спасет медленный pipeline.

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

Матрица отбора помогает не спорить абстрактно:

Для self-hosted проверки полезно посмотреть, как Qdrant описывает поиск и фильтры. Для managed-пилота отдельно проверьте ограничения индексации по документации Pinecone indexing overview. Если retrieval собирается в LangChain, сверяйте не только vector store, но и всю цепочку из раздела LangChain retrieval.

Managed или self-hosted

Managed vector database удобна, когда команда хочет быстрее проверить продуктовую гипотезу и не держать отдельную инфраструктуру. Это хороший путь для коммерческого RAG без жестких on-premise требований.

Self-hosted нужен, когда документы нельзя отправлять во внешний сервис, есть требования к локальному контуру, нужен контроль над сетью и хранением, или команда уже умеет сопровождать такую инфраструктуру.

Не выбирайте self-hosted только потому, что он кажется дешевле. Полная цена включает серверы, резервные копии, обновления, алерты, разбор деградаций, тесты миграций и поддержку индекса. Для маленького корпуса managed часто дешевле, даже если счет за запросы выглядит выше.

Гибридный вариант тоже возможен: чувствительные документы остаются локально, публичные и маркетинговые материалы индексируются в managed-сервисе. Но тогда нужно явно разделять источники и не смешивать права в одном неочевидном pipeline.

Метаданные и права

Права доступа должны применяться до передачи контекста модели. Нельзя найти закрытый документ, отдать его в prompt и надеяться, что модель не раскроет лишнее. Фильтр должен работать на уровне retrieval.

Для каждого фрагмента храните минимальные метаданные:

• tenant или организация;
• список ролей;
• уровень конфиденциальности;
• дата действия документа;
• статус: draft, active, archived;
• исходный URL или путь;
• владелец знания.

Если права сложные, не храните векторную базу как единственный источник авторизации. Пусть RAG получает разрешенный список document_id из основной системы прав, а vector database использует его как фильтр. Так проще доказать, что пользователь не увидит чужой документ.

Гибридный поиск и reranking

Для бизнес-документов dense search редко достаточно. Запросы пользователей часто содержат точные идентификаторы: номер договора, пункт регламента, название тарифа, артикул, ошибку API. Векторный поиск может понять тему, но пропустить точное совпадение.

Гибридная схема соединяет:

• dense vectors для смысла;
• lexical или sparse поиск для точных слов;
• metadata filters для прав;
• reranker для финального порядка;
• правила отказа, если источники слабые.

Не включайте reranker без тестов. Он может улучшить top-3, но добавить latency и стоимость. Проверяйте на реальных вопросах: нашелся ли правильный документ, правильный фрагмент, свежая версия и разрешенный источник.

Индексация

Индексация должна быть отдельным процессом, а не скрытым side effect. Записывайте, какие документы вошли в индекс, когда, какой моделью embeddings, с каким chunking и какой версией кода. Иначе при ошибке вы не поймете, источник устарел или retrieval сломался.

Минимальные проверки индексации:

• нет пустых chunks;
• заголовки не потеряны;
• дубли склеены или помечены;
• архивные документы исключены;
• права перенесены;
• ссылки на источники открываются;
• документы без владельца не попали в production.

Если документы часто обновляются, используйте инкрементальную индексацию, но периодически прогоняйте полный rebuild. Инкрементальный pipeline удобен, но может копить мусор: старые chunks, удаленные страницы и конфликтующие версии.

Как тестировать выбор

Соберите тестовый набор до выбора базы. Возьмите 100-200 реальных вопросов, укажите правильный источник и допустимые фрагменты. Добавьте вопросы без ответа, вопросы на права и запросы с точными идентификаторами.

Для каждой базы или конфигурации измеряйте:

• top-1, top-3, top-5 попадание правильного фрагмента;
• ошибки прав;
• долю устаревших источников;
• latency p50 и p95;
• стоимость индексации и запроса;
• сложность обновления корпуса;
• качество отказа без источника.

Пример одной строки eval-набора:

{
  "question": "Какие SLA действуют для тарифа Enterprise-2026?",
  "allowed_roles": ["support_lead", "account_manager"],
  "expected_document_id": "contract_sla_enterprise_2026",
  "must_not_return": ["archived_sla_2024", "draft_pricing_notes"],
  "accepted_chunk_ids": ["sla_ent_2026_03", "sla_ent_2026_04"],
  "expected_behavior_without_access": "refuse_with_handoff"
}

Такой пример проверяет сразу три вещи: нашелся ли правильный источник, сработали ли права и умеет ли RAG отказаться без доступа. Без подобных кейсов выбор vector database превращается в сравнение демо-скорости.

Не сравнивайте базы на демо-наборе из трех вопросов. На маленькой выборке почти любой вариант выглядит хорошо.

Чеклист выбора

• Понятен объем корпуса сейчас и через год.
• Есть список обязательных metadata filters.
• Права применяются до prompt.
• Нужен или не нужен гибридный поиск.
• Есть тестовый набор реальных вопросов.
• Измерены retrieval metrics, а не только финальные ответы.
• Ясен режим обновления и удаления документов.
• Есть план backup и rebuild индекса.
• Посчитана стоимость managed и self-hosted вариантов.
• Определен владелец качества RAG после запуска.

FAQ

Можно ли начать без отдельной векторной базы?

Да. Для маленького корпуса начните проще и докажите пользу RAG. Отдельная база нужна, когда появляются объем, права, latency и регулярная эксплуатация.

Что важнее: embeddings или vector database?

Важен весь pipeline. Плохие chunks и устаревшие документы сломают даже хорошую базу. Но база должна поддерживать нужные фильтры и обновления.

Нужен ли гибридный поиск?

Часто да, если в документах есть коды, номера, названия продуктов, API-методы и юридические формулировки. Проверяйте на тестовом наборе.

Как понять, что база не подходит?

Правильный источник не попадает в top-5, фильтры по правам замедляют поиск, индекс трудно обновлять, а команда не может объяснить, почему RAG ответил старым документом.

Что читать дальше?

После выбора базы проверьте оценку качества RAG и поиск по документам с ИИ.