Глава 4 — Выбор подходящей векторной базы данных

Четвёртый пост поглавного разбора LLM Primer III: Enhancing Enterprise AI with RAG. Та часть RAG-системы, что растёт быстрее всего, обходится дороже всех на масштабе и сильнее всех привязывает команду — выбирается по техническим достоинствам, а решается по операционным.

Почему существует эта глава

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

4.1 Архитектура: специализированные системы против расширений

Первое решение, часто непроизнесённое, — между внедрением новой системы, специально построенной под векторные нагрузки, и расширением системы, которую команда уже эксплуатирует. Специализированная база — Pinecone, Qdrant, Milvus, Weaviate, Vespa — спроектирована от индекса наружу. Планировщик запросов, расположение данных, модель репликации и API — всё под approximate nearest-neighbor по высокоразмерным векторам. Выше потолок производительности, особенно на гибридных запросах фильтр-плюс-вектор; ещё одна система в эксплуатации.

Подход расширения — pgvector, Elasticsearch dense_vector, MongoDB Atlas Vector Search, Redis с RediSearch — добавляет векторный поиск к базе, которой команда уже владеет. Никакой новой аутентификации, процедуры бэкапа, on-call ротации, кадера патчинга. Потолок производительности задан архитектурой хоста и обычно сильно выше того, что требуется приложениям ниже диапазона десятков миллионов векторов. Решение редко чисто про производительность. Чаще — где команда готова тратить операционный бюджет: команде с одной базой Postgres не хочется эксплуатировать вторую; команда, гоняющая десять сервисов данных, не моргнёт от одиннадцатого.

4.2 Лидеры managed-сегмента: Pinecone и Vertex

Pinecone — каноническая managed-векторная база. Операционная простота, предсказуемая латентность, зрелый SDK и serverless-тариф, разделяющий хранение и вычисления и считающий по реальному использованию, а не по выделенной ёмкости. Правильный дефолт для новых развёртываний, если у нагрузки нет специфической пользы от зарезервированных ресурсов. Цена — архитектурная привязка, которую несёт любая managed-проприетарная система: эмбеддинги в принципе переносимы, но цена «выгрузить-и-переиндексировать» реальна. Vertex AI Vector Search — предложение Google, построенное на библиотеке ScaNN, питающей собственный масштабный поиск Google. Более высокий потолок масштабирования, плотная интеграция с остальным GCP — модели эмбеддингов, IAM, Cloud Monitoring — и соответствующая стратегическая привязка к одному облаку. Azure AI Search занимает то же место для команд, привязанных к Microsoft. Выбор среди трёх облачно-нативных вариантов обычно следует уже существующему облачному выбору, что разумно при условии, что команда проверила масштабы и резидентность.

4.3 Open-source: Qdrant, Milvus, Weaviate

Категория open-source — для команд, желающих контролировать собственную инфраструктуру (по цене, резидентности или стратегическим причинам) и имеющих операционную способность гонять распределённые системы. Qdrant — самый маленький и сфокусированный: написан на Rust, разворачивается одним бинарником, спроектирован под низкую латентность векторного поиска с сильной фильтрацией и поддержкой квантизации. Доступен настолько, чтобы заработать за минуты; правильный выбор для самого маленького возможного операционного следа. Milvus — самый большой и enterprise-ориентированный, с cloud-native архитектурой, разделяющей вычисления, хранение и метаданные, с самым высоким потолком масштабирования в категории (корпуса миллиардного размера, GPU-ускоренные индексы, многоуровневое хранение). Значительная операционная сложность, смягчаемая Zilliz Cloud. Weaviate сидит между ними — богаче по фичам, чем Qdrant, проще, чем Milvus, со встроенными модулями эмбеддинга, реранжирования и мультиарендности. Скорее поисковая платформа, чем просто поисковый индекс. Все три ядра под Apache-лицензией, есть платные managed-предложения, а бенчмарки сравниваются на небольшой константе. Решение — соответствие, а не голая производительность.

4.4 Встраиваемые и Postgres: Chroma и pgvector

Большинство реальных RAG-развёртываний обслуживают десятки запросов в секунду на нескольких сотнях тысяч векторов, а не миллионы запросов в секунду на миллиардах. Для таких нагрузок правильный инструмент работает в процессе приложения или рядом с ним. Chroma — встраиваемая опция: in-process по умолчанию, сохраняется на локальный диск, в простейшем случае не требует конфигурации. Подходит для прототипов, инструментов, поставляющихся со своими данными, и продакшен-развёртываний, помещающихся на одну машину. pgvector добавляет в Postgres тип вектора, операторы расстояния и индексы HNSW/IVFFlat. Для корпусов до примерно десяти миллионов векторов на хорошо подготовленном хосте pgvector — заслуживающий доверия продакшен-выбор и операционно простейший вариант для команд, уже эксплуатирующих Postgres. Векторный поиск становится SQL-запросом к таблице, которую понимает существующий ORM; джойны со структурированными метаданными — первого класса. Скрытая добродетель этих опций — они снижают цену смены мнения: миграция к распределённой системе, если случится, ограничена.

4.5 Резидентность, операции и стоимость — оси, на которых решается

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

Операционная форма — это ёмкость самой команды. Команда из трёх инженеров, обслуживающая один сервис, должна выбрать вариант, добавляющий минимум операционной поверхности — pgvector, managed Pinecone или Qdrant Cloud, встраиваемая Chroma. Команда из тридцати может переварить сложность open-source распределённой системы ради преимуществ по стоимости и возможностям. Ошибка — выбрать систему, не соответствующую реальной способности команды её эксплуатировать. Общая стоимость за срок жизни системы включает обеспечение, мониторинг, бэкап, drill восстановления, планирование ёмкости, апгрейды и пропорциональную долю времени on-call. Честная рамка спрашивает стоимость в трёх сценариях — текущая нагрузка, 10x, 100x — потому что наклон кривой важен не меньше начальной точки.

Что подготавливает глава 4

Векторная база определяет, что слой хранения способен держать, насколько быстро его можно опрашивать, какие паттерны фильтрации и метаданных поддерживаются. Ни одно из этих свойств в одиночку не решает качество поиска — они решают, что вообще возможно построить поверх. А поверх строится поисковый пайплайн, где выигрыши складываются: гибридный поиск, сочетающий плотные векторы с BM25, reciprocal rank fusion по разнородным ретриверам, cross-encoder reranking и слой понимания запроса, соединяющий то, как спрашивают пользователи, и то, как отвечают документы.

Дальше — Глава 5: Архитектура поискового пайплайна. Как плотный векторный поиск и keyword-поиск соединяются через reciprocal rank fusion, шаг cross-encoder reranking, закрывающий большую часть оставшегося разрыва качества, и слой понимания запроса, делающий остальное.