Vector DB для enterprise: Qdrant, pgvector или Pinecone

Короткий ответ: для большинства enterprise-RAG наш дефолт — Qdrant: гибридный поиск из коробки, сильная фильтрация метаданных и On-Premise одной командой Docker. Но выбор зависит от объема, бюджета и требований безопасности — разбираем все три варианта.

Проблема выбора

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

Qdrant: баланс и контроль

Открытый движок с отличной фильтрацией метаданных и приемлемым порогом входа. Ставится On-Premise одной командой Docker. Наш дефолт для enterprise-проектов: гибридный поиск (вектора плюс ключевые слова) из коробки, кванты памяти экономят до 40% RAM на больших коллекциях.

pgvector: если уже есть PostgreSQL

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

Pinecone: управляемый сервис

Ноль администрирования и хорошая скорость, но данные уходят наружу. Для компаний с NDA и персональными данными это часто дисквалифицирующий фактор. Плюс стоимость растёт нелинейно с объёмом.

Правило выбора: есть PostgreSQL и меньше десяти миллионов векторов — берите pgvector. Нужен строгий контур и фильтрация — Qdrant. Нет своей инфраструктуры вообще — Pinecone, но считайте цену данных.

Чеклист: семь вопросов до выбора движка

Ответьте письменно на каждый пункт. Если половина ответов «не знаю» — начните с аудита данных, а не с выбора технологии.

1. Объём. Сколько векторов сейчас и прогноз через 12 месяцев. Миллионы и десятки миллионов — разные классы задач: pgvector справляется с первым, для второго нужны специализированные движки.
2. Контур. Есть ли персональные данные, коммерческая тайна, требования регулятора. Любое «да» вычёркивает управляемые облака и оставляет On-Premise.
3. Фильтрация. Нужен ли поиск с ограничением по отделу, роли, версии документа. Для enterprise-RAG с разграничением доступов слабая фильтрация метаданных ломает безопасность сильнее, чем неудачная модель эмбеддингов.
4. Гибридность. Будут ли запросы с артикулами, номерами документов, редкими терминами. Чисто векторный поиск их теряет — нужен гибрид с полнотекстовым ранжированием.
5. Нагрузка. Пиковый QPS и допустимая задержка ответа. Внутренний инструмент для 50 сотрудников и клиентский сервис на тысячи одновременных сессий стоят по-разному.
6. Команда. Кто будет администрировать: DBA с опытом Postgres, DevOps или никто. Это определяет, какую систему вы реально сможете эксплуатировать через год.
7. Миграция. Как будете переезжать, если выбор окажется неверным. Формат хранения эмбеддингов и метаданных проектируется переносимым с первого дня.

Эксплуатация: расходы, которые проявляются после запуска

Выбор движка — треть решения. Остальное — операционная дисциплина, которой не видно на демо:

• Версионирование эмбеддингов. Смена модели эмбеддингов требует полного переиндексирования корпуса. Храните имя и версию модели рядом с каждым вектором — иначе будущая миграция превратится в археологию.
• Контроль качества поиска. Держите эталонный набор вопросов с правильными документами и меряйте recall после каждого изменения индекса. Точность RAG до 99,9% на формализованных вопросах держится именно на этом контроле, а не на удачной модели.
• Резервное копирование. Векторная коллекция без бэкапа восстанавливается только полной переиндексацией всех исходников. На больших корпусах это дни работы GPU и простой поиска.
• Стоимость памяти. Квантизация и снижение размерности режут счёт за RAM в разы, но бьют по качеству выдачи. Баланс подбирается на ваших данных, а не на бенчмарках из интернета.

Гибридный поиск и схема метаданных: где выигрывается качество

Модель эмбеддингов получает незаслуженно много внимания — качество enterprise-RAG чаще всего теряется на соседних слоях:

• Полнотекстовая ветка гибрида. Артикулы, номера договоров, фамилии для чисто векторного поиска — шум. Гибрид объединяет векторную выдачу с полнотекстовым ранжированием и поднимает точность на таких запросах до рабочего уровня. Qdrant даёт это из коробки; в pgvector гибрид собирается через полнотекстовые индексы Postgres вручную — ещё один час работы, который стоит учесть при выборе.
• Схема метаданных. Отделы строками в свободной форме, версии документов без дат, права доступа на уровне папок — всё это ломает фильтрацию после индексации. Схема проектируется до первой загрузки: типы полей, справочники значений, наследование доступов. Переделка после миллионов векторов означает полную переиндексацию.
• Чанки и переранжирование. Размер чанка и переранжирование топ-K влияют на итоговую точность сильнее смены модели эмбеддингов. Настраиваются только на ваших реальных вопросах: эталонный набор из аудита прогоняется при каждом изменении параметров, как регрессия на код.

Миграция между движками: страховка от неверного выбора

Переезд реален, если исходные документы и структура метаданных хранятся отдельно от векторов. Вектора — производная величина: пересчитываются всегда. Потерянная структура прав и версий не восстанавливается никакими GPU. Три правила:

1. Источник истины — документное хранилище. Векторная база — только индекс; удаление коллекции никогда не означает потерю данных.
2. Экспорт метаданных в открытом формате. Полная выгрузка полей в JSONL по расписанию превращает будущую миграцию из проекта на месяцы в операцию на часы.
3. Двойная запись на период переезда. Новый движок наполняется параллельно со старым, эталоны прогоняются на обоих, трафик переключается процентами — тот же механизм канарейки, что и в раскатке промптов.

Движок задаёт потолок возможностей, но до потолка нужно ещё дотянуться инженерией. Две команды на одинаковом Qdrant получают разные результаты именно на описанных слоях, а не в выборе лицензии.

Практический вывод для CTO: относитесь к векторной инфраструктуре с той же инженерной строгостью, что и к транзакционной базе данных — со схемой, миграциями, бэкапами и мониторингом качества выдачи. Отношение к индексу как к «кэшу, который можно пересоздать» допустимо, пока объём измеряется тысячами документов; на enterprise-корпусах пересоздание превращается в многодневный простой поиска, а потерянная схема метаданных — в остановку всего RAG-контура.

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

Последний штрих к смете: заложите нагрузочное тестирование перед приёмкой. Бенчмарки производителя сняты на чужих данных и чужом железе; ваши пиковые сценарии с вашей фильтрацией — единственный результат, которому можно верить при планировании мощностей.

Сколько стоит содержание векторной базы?

On-Premise Qdrant на корпусе до десяти миллионов векторов укладывается в один сервер за десятки тысяч рублей в месяц плюс несколько часов DevOps. pgvector при уже работающем Postgres почти бесплатен: пара гигабайт памяти и существующая экспертиза команды. Управляемые сервисы стартуют дёшево, но на enterprise-объёмах подписка обгоняет собственный сервер в разы. Считайте горизонт три года, а не первый месяц.

Как быстро разворачивается решение?

Qdrant поднимается одной Docker-командой, pgvector — расширением к существующей базе: день на установку в обоих случаях. Недели уходят не на установку, а на проектирование схемы метаданных, пайплайн индексации и настройку гибридного поиска. В нашем стандартном цикле векторное хранилище — часть MVP, который запускается за 4–6 недель вместе с RAG-слоем и интеграцией в ваши системы.

Что делать, когда объём вырастет в десять раз?

Правильно спроектированная система переживает рост шардированием и репликацией без смены движка: Qdrant масштабируется нативно, pgvector — через партиционирование и read-реплики. Проблемой рост становится тогда, когда на старте выбрали движок без фильтрации метаданных и гибридности: переезд с потерей качества поиска дороже любой экономии на лицензиях. Поэтому мы проектируем схему под объём через два года, а разворачиваем под сегодняшний.