Векторная база данных

Векторная база данных — это хранилище данных, специально созданное для хранения многомерных числовых векторов (embedding'ов) и ответа на запросы вида «найди мне векторы, наиболее похожие на этот» в масштабе — обычно через алгоритмы приближённого поиска ближайших соседей (approximate nearest neighbor, ANN), такие как HNSW или IVF, которые жертвуют небольшой точностью ради огромного прироста скорости по сравнению с перебором методом грубой силы. Это важно для SaaS/AI-разработчиков, потому что именно это инфраструктура, которая делает возможными RAG, семантический поиск, дедупликацию и рекомендательные функции: вместо сопоставления по точным ключевым словам вы сопоставляете по смыслу. Популярные варианты охватывают широкий спектр: специализированные векторные базы данных вроде Pinecone, Weaviate, Qdrant и Milvus изначально построены вокруг векторов с богатой фильтрацией и горизонтальным масштабированием; pgvector добавляет векторные столбцы и операторы сходства прямо в PostgreSQL, позволяя командам не запускать отдельную базу данных, если масштаб этого не требует; а Redis, Elasticsearch и MongoDB прикрутили векторный поиск к своим существующим движкам. Механика такова: каждый документ (или фрагмент документа) превращается в вектор через модель embedding, сохраняется вместе с метаданными (URL источника, временная метка, теги) и индексируется. Запрос кодируется тем же способом, а база данных возвращает ближайшие векторы по метрике расстояния — обычно косинусному сходству или скалярному произведению. Конкретный пример с pgvector в Postgres: `CREATE TABLE docs (id serial, content text, embedding vector(1536)); CREATE INDEX ON docs USING hnsw (embedding vector_cosine_ops); SELECT content FROM docs ORDER BY embedding <=> '[0.012, -0.045, ...]' LIMIT 5;` — этот единственный запрос возвращает 5 наиболее семантически похожих на входной вектор документов за миллисекунды, даже среди миллионов строк. Выбор между управляемой векторной базой данных и pgvector внутри Postgres — это реальное архитектурное решение: управляемые сервисы масштабируются дальше при меньшей операционной нагрузке, но добавляют новую систему и статью расходов; pgvector сохраняет ваш стек простым, если вы уже на Postgres, а корпус — в пределах низких миллионов векторов. Помимо чистого поиска по сходству, большинство продакшн-векторных баз данных поддерживают фильтрацию по метаданным (например, «искать только среди документов с тегами `region: EU` и `status: published`»), что необходимо для мультитенантных SaaS-продуктов, где RAG-запросы одного клиента никогда не должны показывать приватные документы другого клиента — фильтрация происходит на уровне запроса к базе данных, а не как проверка постфактум, чтобы никогда не передавать LLM данные не того тенанта. Стратегия перестроения индекса тоже важна на практике: по мере добавления, обновления или удаления документов векторный индекс должен оставаться синхронизированным, и одни базы данных справляются с этим через почти мгновенные upsert'ы, а другие требуют периодической полной переиндексации — существенная разница для продукта, где контент меняется часто (например, живая база знаний тикетов поддержки), по сравнению с редко меняющимся (например, статичное руководство пользователя).