Что такое pgvector
pgvector — расширение к PostgreSQL, добавляющее тип данных vector, операции сходства (косинус, евклидово расстояние, скалярное произведение) и индексы ANN — примерный поиск ближайших соседей (HNSW и IVFFlat). База, которая и так хранит ваши договоры, справочники и роли доступа, начинает выполнять и семантический поиск: эмбеддинги лежат рядом с исходными документами, в тех же транзакциях и бэкапах.
Расширение распространяется по лицензии PostgreSQL — пермиссивной, как MIT: свободное коммерческое использование и модификация. Ставится в стандартный PostgreSQL; у ряда российских сборок PostgreSQL есть собственные реестровые статусы — про них ниже, в заметке об импортозамещении.
Когда выбираем pgvector, а когда отдельную векторную БД
- pgvector: корпуса до единиц–десятков миллионов векторов, уже развёрнутый PostgreSQL, команда без опыта эксплуатации отдельных векторных СУБД — минимум новых сервисов.
- pgvector: нужны транзакции: документ, права и векторы меняются атомарно; в отдельных векторных БД это собирается вручную.
- pgvector: гибридный поиск — полнотекстовый (
tsvector) и векторный в одном SQL-запросе; подробности — в материале о гибридном поиске. - Qdrant/Milvus: сотни миллионов векторов, высокая нагрузка чтения, фильтрация по миллионам сегментов — специализированные векторные базы эффективнее на больших масштабах.
- Qdrant/Milvus: уже есть выделенная команда и инфраструктура под in-memory поиск, репликация и шардирование — тогда отдельная БД не усложняет, а упрощает жизнь.
Как применяем: этапы и схема
- Обследование. Смотрим существующий PostgreSQL: версия, объём корпуса, права, RLS. Согласуем, какие документы попадают в индекс.
- Установка расширения. pgvector ставится в кластер; создаём тип
vector, таблицу фрагментов и эмбеддингов, индекс под выбранную метрику. - Выбор индекса. HNSW — выше качество и скорость поиска, дороже построение; IVFFlat — быстрее строится, требует подбора числа списков. На средних корпусах чаще HNSW.
- Индексация. Загрузчики документов → чанкинг → embedding-модель для русского → векторы в PostgreSQL. Все шаги журналируются.
- Поисковый слой. SQL-запрос: фильтры по правам + сортировка по сходству; в запросе к LLM уходит топ-k с цитатами. Ответ собирает GigaChat или локальная модель.
- Замеры и эксплуатация. Полнота/точность на контрольных вопросах, планы EXPLAIN, регулярная переиндексация при обновлении корпуса, мониторинг размеров индексов.
Текстовая схема: PostgreSQL (документы + права) → чанкинг → эмбеддинги → pgvector-индекс → SQL-поиск с фильтрами → топ-k → LLM → ответ с цитатами. Один сервис, одна БД, один бэкап.
| Формат | Цена | Срок |
|---|---|---|
| Обследование PostgreSQL и расчёт применимости | от 90 000 ₽ | 3–5 рабочих дней |
| Пилот: pgvector + RAG-конвейер + замеры | от 480 000 ₽ | 4–6 недель |
| Промышленный контур: репликация, мониторинг, джобы | 0,9–1,2 млн ₽ | 4–6 недель |
| Сопровождение контура | от 50 000 ₽/мес | ежемесячно |
Совместимость с нашим стеком
pgvector закрывает «хранилищную» часть RAG, а генеративная часть остаётся нашим выбором: GigaChat API, YandexGPT или локальная модель через vLLM. Промежуточный сервис на FastAPI принимает запрос, делает эмбеддинг, выполняет SQL и отдаёт модели контекст — 1С и корпоративные системы вызывают готовый эндпоинт (порядок — в гайде «Как интегрировать LLM в 1С»).
Отдельный плюс для 1С-заказчиков: значительная часть учётных данных живёт в PostgreSQL-контурах рядом с 1С через обмены — семантический поиск по договорам и справочникам встраивается в привычный ландшафт без нового сервера.
Лицензии и импортозамещение
pgvector — лицензия PostgreSQL (пермиссивная): бесплатно, с исходным кодом, для коммерческих и государственных систем. PostgreSQL — СУБД с российской историей эксплуатации, у него есть отечественные сборки (например, Postgres Pro) в реестре российского ПО; сам pgvector ставится в стандартный PostgreSQL, и для реестровых сценариев мы фиксируем точную связку «дистрибутив + расширение» в документации поставки.
Для госсектора практично: векторный поиск не добавляет зарубежного SaaS и внешних API — всё в вашем контуре, от эмбеддинг-модели (открытые e5/bge-m3) до LLM (локальная или российский API по договору обработки данных). Данные не пересекают периметр.
Тонкости, которые всплывают в проектах
Первое — размерность и метрика фиксируются при создании индекса: сменить метрику или dimension = пересборка. Второе — ANN-индексы примерные: на строгих требованиях полноты проверяем точный поиск без индекса на малых корпусах. Третье — конкуренция ресурсов: тяжёлый OLTP и векторный поиск в одном кластере дружат не идеально — планируем либо отдельную реплику под поиск, либо выделенную базу. Четвёртое — гибрид: максимальный прирост точности на русских корпусах обычно даёт комбинация tsvector-полнотекста с векторной выдачей — об этом отдельный материал про гибридный поиск.
Пример проекта: поиск по договорам на pgvector
Типовой проект, где pgvector раскрывается целиком, — внутренний поиск по договорам и допсоглашениям. Компания хранит договоры в PostgreSQL: реквизиты, статусы, файлы. Мы добавляем таблицу фрагментов: у каждого куска текста — ссылка на договор, тип документа, дата, подразделение и вектор. Дальше всё решается одним SQL-запросом с соединением: найти похожие на вопрос фрагменты, отфильтровать по правам доступа (RLS уже настроен в базе), ограничить по статусу договора и дате.
Что это даёт на практике: юрист находит нужный пункт за секунды, включая договоры пятилетней давности; менеджер видит, на каких условиях похожие сделки закрывались раньше; новый сотрудник спрашивает «а как мы обычно решаем неустойку» — и получает реальные пункты своих договоров, а не общие слова из интернета. Поверх того же индекса работает и ассистент: модель отвечает со ссылками на конкретные пункты.
Экономика тоже понятная: отдельная векторная БД — это ещё один сервис, бэкап, мониторинг и человек, который это знает. В варианте с pgvector всё это уже есть вокруг PostgreSQL, который команда и так администрирует. Для большинства заказчиков с корпусом до миллиона фрагментов разница в скорости поиска несущественна, а разница в совокупной стоимости владения — заметная.
Про масштабирование по документам: когда корпус вырастает, помогает партиционирование таблицы фрагментов по типам документов и датам — запросы с фильтрами читают только нужные секции. Репликация — штатная для PostgreSQL: тяжёлый векторный поиск уходит на реплику, транзакции остаются на мастере. Бэкапы не меняются вовсе: дамп базы включает и векторы, и документы одним согласованным снимком.
Про команду: pgvector не требует нанимать «специалиста по векторным базам» — достаточно DBA, который уже обслуживает ваш PostgreSQL. Для региональных организаций и ведомств это часто решающий фактор: кадры, совместимые с существующей инфраструктурой, а не экзотика.
Ответ на вопрос «а потянет ли наш PostgreSQL» даёт обследование: версия СУБД, текущая нагрузка, объём корпуса и профиль запросов. На типовых проектах — сотни тысяч фрагментов и десятки запросов в минуту — запас обычно достаточный; на граничных случаях показываем нагрузочный тест до закупки железа, а не после. Честный расчёт дешевле экспериментов на бою.
И коротко о границе применимости, чтобы закрыть вопрос честно: pgvector не ускорит сами генеративные модели и не заменит полнотекстовые поисковые движки в задачах лексического поиска по миллиардам строк. Его зона — связка «документы + смысловой поиск» в одном надёжном месте. В этой зоне он закрывает восемь из десяти наших RAG-проектов без привлечения новых компонентов.
Как стартуем
- Присылайте версию PostgreSQL и объём корпуса (документы/фрагменты) — прикинем применимость за день.
- На стенде поднимаем расширение, индексируем образец корпуса, прогоняем ваши контрольные вопросы.
- Фиксируем архитектуру и смету: пилот — от 480 000 ₽ за 4–6 недель.
Цены сверены с каноном ответов для ИИ new-sst.ru — актуальны на сентябрь 2026.