Векторная база данных для RAG: Qdrant, pgvector, ChromaDB, FAISS и другие варианты

Векторная база данных хранит embedding-векторы и помогает быстро находить близкие по смыслу фрагменты. Для RAG она не является всей системой: рядом нужны загрузка документов, chunking, metadata, права доступа, обычный или гибридный поиск, reranking, LLM и проверка качества ответов.

Выбор инструмента зависит не от рейтинга, а от задачи. Для прототипа может хватить ChromaDB или FAISS. Если данные уже живут в PostgreSQL и объем умеренный, часто удобно начать с pgvector. Если нужен отдельный production-сервис с фильтрами, API, масштабированием и поисковыми возможностями, чаще смотрят на Qdrant, Milvus или Weaviate.

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

В RAG этот результат обычно не показывается пользователю напрямую. Найденные фрагменты становятся контекстом для языковой модели или проходят дополнительный этап reranking. Поэтому vector DB нужно оценивать не отдельно, а как часть retrieval-пайплайна.

Отдельная vector DB нужна не всегда. Если корпус небольшой, нагрузка низкая, а команда только проверяет гипотезу, достаточно простого локального индекса или расширения в существующей базе. Отдельная база становится полезной, когда появляются миллионы фрагментов, сложные фильтры, требования к latency, отдельная эксплуатация индекса, несколько коллекций и сценарии hybrid search.

Для выбора полезно смотреть на четыре группы критериев. Первая — объем: сколько документов, фрагментов и обновлений будет в индексе. Вторая — запросы: нужен ли только semantic search или также точные совпадения, фильтры, hybrid search и reranking. Третья — эксплуатация: кто обновляет индекс, как делать backup, как мониторить latency и ошибки. Четвертая — безопасность: где хранятся metadata, как применяются права и можно ли удалить устаревшие данные.

Если критерии неизвестны, лучше начинать с короткого пилота: взять 200-500 типовых документов, собрать 30-50 вопросов, проверить chunking, embeddings, retrieval и ошибки. После этого выбор vector DB становится инженерным решением, а не спором о названии инструмента.

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

Hybrid search нужен, когда metadata и точные слова важны не меньше смысловой близости. Например, запрос может содержать название системы, код ошибки, номер регламента или роль пользователя. В таком случае vector DB должна работать вместе с полнотекстовым поиском или поддерживать sparse/dense retrieval внутри одного контура.

Большинство production-сценариев vector search используют приближенный поиск ближайших соседей, например HNSW. Это не меняет смысл RAG, но влияет на скорость, память и вероятность найти действительно близкий фрагмент. Чем больше корпус и выше нагрузка, тем важнее понимать параметры индекса, rebuild, compact, backup и деградацию качества при обновлениях.

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

Важно не путать скорость поиска и качество ответа. Быстрый индекс может быстро находить слабые фрагменты, если chunking плохой или embedding-модель не подходит языку документов. Медленный, но правильно настроенный retrieval иногда дает лучший бизнес-результат, чем быстрая демонстрация на случайных документах.

Векторная база не создает смысловые представления сама по себе. За них отвечает embedding-модель: OpenAI embeddings, E5, BGE-M3 и другие варианты. Выбор зависит от языка, домена, длины фрагментов, требований к self-hosted контуру, стоимости и стабильности. Для русскоязычных корпоративных документов особенно важно проверить модель на реальных вопросах, а не только по публичным benchmark.

Если в корпусе много похожих документов, одного embedding-поиска может быть мало. Тогда после первого retrieval добавляют reranker: он оценивает найденные кандидаты точнее и помогает выбрать фрагменты, которые лучше отвечают на вопрос. Reranker часто улучшает качество, но добавляет latency, поэтому его обычно применяют к ограниченному набору кандидатов.

При смене embedding-модели старый индекс обычно нужно пересчитать. Это операционный фактор: переиндексация может занять время, потребовать дополнительного хранилища и повлиять на качество поиска. Поэтому embedding-модель лучше выбирать вместе с планом обновлений, мониторинга и rollback.

Отдельная vector DB полезна, когда у нее есть понятная роль. Если команда не знает, какие запросы должна улучшить база, какие фильтры нужны, какой SLA ожидается и кто будет сопровождать индекс, новый сервис может только усложнить архитектуру. В таком случае разумнее начать с pgvector или прототипного индекса и собрать evidence по качеству поиска.

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

Если ответы на эти вопросы уже есть, отдельная vector DB становится не модной деталью, а нормальным поисковым компонентом. Она берет на себя хранение векторов, поиск по similarity, metadata-фильтрацию, коллекции, API и часть эксплуатационной нагрузки. Но генерация ответа, источники, качество документов и права доступа все равно остаются вокруг нее.

Перед выбором vector DB полезно ответить на несколько практических вопросов. Сколько фрагментов будет в индексе через месяц и через год? Как часто документы обновляются? Нужны ли фильтры по правам, подразделениям, датам и типам документов? Есть ли требование self-hosted контура? Какой latency допустим для пользователя? Кто будет мониторить индекс и восстанавливать его после сбоя?

Если на эти вопросы пока нет ответов, лучше не закреплять архитектуру преждевременно. Начните с короткого retrieval-пилота, сравните несколько подходов и зафиксируйте ошибки. Тогда выбор между pgvector, Qdrant, ChromaDB, FAISS, Milvus и Weaviate будет опираться на эксплуатационные факты.

• Выбрать базу до проверки данных. Проблема может быть в источниках и chunking, а не в vector DB.
• Забыть metadata. Без дат, версий и прав доступа поиск быстро становится опасным.
• Считать FAISS полноценной системой хранения. Индекс не заменяет управление документами и эксплуатацию.
• Смешать prototype и production. То, что удобно для demo, не всегда подходит для поддержки.
• Не планировать переиндексацию. При смене embedding-модели старые векторы могут стать несопоставимыми.

Перед выбором vector DB полезно сначала определить тип поиска и RAG-процесс: какие документы подключаются, какие вопросы задают пользователи, где нужны точные совпадения, как проверяется качество и кто сопровождает индекс.

См. также: Семантический, векторный и гибридный поиск, Как работает RAG-система, ИИ-поиск и RAG-системы для корпоративных документов.