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

Что она делает

Обычная база ищет по точному совпадению или диапазону: «где id = 42», «цена меньше 1000». Векторная база отвечает на другой вопрос: «какие записи ближе всего к этому вектору по смыслу». Она хранит эмбеддинги и умеет по запросу-вектору быстро вернуть k ближайших. Всё остальное (метаданные, тексты кусков) обычно лежит рядом, чтобы вместе с найденным вектором вернуть и сам текст, и ссылку на источник.

Приближённый поиск ближайших соседей

Точно найти ближайшие векторы среди миллионов — дорого: пришлось бы сравнить запрос с каждым. Поэтому векторные базы используют приближённый поиск ближайших соседей (ANN, approximate nearest neighbors): специальные индексы (самый популярный — HNSW, граф связей между похожими векторами) находят почти самых близких, но в тысячи раз быстрее полного перебора. «Приближённый» означает, что изредка идеально ближайший вектор может не попасть в выдачу, — на практике это почти не сказывается на качестве ответов, зато поиск остаётся мгновенным на любом масштабе.

Ещё одна важная возможность — фильтрация по метаданным: «найди похожее по смыслу, но только среди документов этого пользователя и только за последний год». Смысловой поиск в связке с обычными фильтрами закрывает большинство реальных задач.

pgvector или выделенная база

Главная развилка при выборе.

pgvector — расширение PostgreSQL. Оно добавляет обычному Postgres тип «вектор» и поиск ближайших. Огромный плюс: вектора лежат рядом с вашими обычными данными, в той же базе, под теми же транзакциями и бэкапами. Не нужно поднимать и синхронизировать отдельную систему. Для большинства проектов, где эмбеддингов от тысяч до нескольких миллионов, этого достаточно — и это разумный выбор по умолчанию. О самом PostgreSQL — в разделе про него.

Выделенные векторные базы (Qdrant, Weaviate, Milvus, Pinecone и другие) — специализированные системы, заточенные только под векторный поиск. Их берут, когда векторов десятки-сотни миллионов и больше, нужен экстремальный масштаб, тонкая настройка индексов или векторный поиск — центральная нагрузка сервиса. За это платят отдельной системой в эксплуатации.

Правило то же, что и с любым специализированным хранилищем: начинают с pgvector (данные и так в Postgres), а на выделенную базу переходят, когда масштаб или требования это оправдывают — а не «на будущее».

Грабли

  • выбор метрики и модели эмбеддингов. Вектора от одной модели нельзя искать среди векторов от другой — они несопоставимы. Сменили модель эмбеддингов — надо переиндексировать всё.
  • стоимость индексации. Перевести миллионы кусков в эмбеддинги — это миллионы вызовов модели; это заметная разовая (и при обновлениях — регулярная) статья расходов.
  • не только вектор. Часто лучший результат даёт гибрид: семантический поиск плюс обычный по ключевым словам — они дополняют друг друга.

Где это применяется

Векторная база — обязательный компонент любого RAG-приложения: база знаний, поиск по документам, рекомендации похожего, дедупликация и кластеризация по смыслу. Везде, где вопрос звучит как «найди похожее по смыслу, а не по точному совпадению».

Коротко

  • Векторная база хранит эмбеддинги и быстро находит ближайшие по смыслу — фундамент RAG.
  • Масштаб держит приближённый поиск ближайших соседей (ANN, индекс HNSW): почти точно, но в тысячи раз быстрее перебора; плюс фильтрация по метаданным.
  • pgvector (расширение Postgres) — выбор по умолчанию: вектора рядом с данными, без отдельной системы. Выделенные базы — под очень большой масштаб.
  • Грабли: несовместимость векторов от разных моделей (при смене — переиндексация), стоимость индексации, польза гибрида с поиском по словам.

Дальше — агентные приложения: когда модель не просто отвечает, а сама решает, какие инструменты вызвать, чтобы выполнить задачу.