Векторная база данных: что это и как выбрать

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

Почему обычного перебора недостаточно

Точный поиск сравнивает запрос с каждым вектором. На небольшом наборе это работает, но стоимость растёт вместе с числом объектов. Для больших коллекций применяют approximate nearest neighbors — приближённый поиск соседей.

Распространённые индексы:

• HNSW строит граф связей между близкими векторами и даёт хорошую скорость и recall ценой памяти;
• IVF делит пространство на кластеры и во время запроса просматривает только часть из них;
• PQ сжимает векторы и уменьшает память, допуская потерю точности.

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

FAISS, Qdrant и Weaviate

FAISS — библиотека индексов, а не полноценная многопользовательская база. Она удобна для локальных экспериментов, batch-обработки и систем, где хранением, резервным копированием и API управляет само приложение.

Qdrant — специализированная vector database с сервером, коллекциями, payload-фильтрами и HTTP/gRPC API. Она подходит, когда нужны персистентность, фильтрация, несколько клиентов и самостоятельное развёртывание.

Weaviate сочетает векторное хранилище со схемой объектов, модулями и готовыми интеграциями. Выбор зависит не от таблицы «кто быстрее вообще», а от конкретной нагрузки и инфраструктуры.

При выборе проверьте:

• размер коллекции и частоту обновлений;
• фильтрацию до или во время vector search;
• требования к latency и recall;
• backup, репликацию и multi-tenancy;
• место развёртывания и стоимость эксплуатации;
• поддержку нужной метрики и размерности вектора.

Метаданные и безопасность

В реальном RAG одной похожести недостаточно. Пользователь из отдела продаж не должен получить документ юридического отдела только потому, что он семантически близок. Идентификатор tenant и ACL должны участвовать в фильтре до выдачи результатов.

Храните связь с исходником: document_id, chunk_id, version, page и checksum. Тогда документ можно обновить без накопления старых копий, а ответ — снабдить проверяемой ссылкой.

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

Векторная база ускоряет поиск, но не исправляет плохие эмбеддинги и чанкинг. Сначала измерьте retrieval quality, затем оптимизируйте инфраструктуру.

Какие данные хранить рядом с вектором

Один embedding не позволяет вывести цитату или понять, кому доступен документ. Рядом полезно хранить стабильный document_id, идентификатор фрагмента, текст, источник, версию содержимого и metadata для фильтров. Например, два одинаковых текста в договорах разных клиентов могут иметь почти одинаковые векторы, но разные права доступа.

Для самопроверки опишите запись чанка договора: tenant_id=42, document_id=contract-17, chunk_id=3, version=2. Затем разберите три операции. При изменении договора новые векторы должны соответствовать новой версии текста. При удалении документа старые чанки должны исчезнуть из поиска. При запросе клиента 43 фрагмент клиента 42 не должен попасть в контекст LLM.

Сначала проведите эти проверки на небольшом корпусе точным поиском. После перехода к ANN сравните выдачу с точным baseline: ускорение может менять полноту. Метрики обновления, удаления и фильтрации не заменяются одним benchmark времени ответа. Так таблица выбора хранилища превращается в проверяемый контракт проекта.

Продолжите разбор: FAISS, Qdrant или Weaviate: что выбрать для RAG.