RAG-система (Retrieval-Augmented Generation) нуждается в двух вещах: хранилище эмбеддингов документов и механизм поиска ближайших по смыслу фрагментов, которые передаются в LLM как контекст. Первый инстинкт — завести под это отдельную специализированную векторную БД. Но у корпоративных документов помимо эмбеддинга есть метаданные: источник, версия, права доступа. Здесь и возникает вопрос архитектуры.
Расширение pgvector добавляет тип данных vector и операторы близости прямо в PostgreSQL. Реляционные данные (метаданные, права доступа, версии документов) и векторный поиск живут в одной СУБД, а не в двух синхронизируемых системах. Это снимает целый класс проблем консистентности: не нужно поддерживать двухфазный коммит между реляционной БД и векторным хранилищем, а обновление прав доступа к документу сразу отражается в том же SQL-запросе, который выполняет поиск.
Тип vector(n) хранит эмбеддинг фиксированной размерности — колонка объявляется с числом измерений, соответствующим модели, которая генерирует эмбеддинги.
pgvector поддерживает три оператора расстояния:
Выбор метрики — следствие того, как обучена модель эмбеддингов. Большинство современных text-embedding моделей нормализуют векторы под косинусное расстояние: евклидова метрика на ненормализованных векторах даст иное ранжирование, чем заложено в модель. Перед выбором оператора стоит сверяться с документацией конкретной модели.
Полный перебор всех векторов быстро перестаёт масштабироваться — на таблице из миллионов эмбеддингов каждый запрос сканирует всю таблицу. pgvector реализует два типа индексов для приближённого поиска ближайших соседей (approximate nearest neighbor, ANN): IVFFlat и HNSW.
Разбивает векторное пространство на кластеры (lists) и при поиске проверяет только ближайшие к запросу кластеры. Это ускоряет запрос, но снижает recall: чем меньше кластеров проверяется, тем выше шанс упустить релевантный, но «пограничный» вектор. Слишком мало кластеров — грубое разбиение, слишком много — замедление построения индекса.
Строит многослойный граф ближайших соседей и в общем случае даёт лучшее соотношение скорости запроса и recall, чем IVFFlat, но требует больше времени и памяти на построение. Когда корпус документов относительно стабилен и переиндексируется не каждый день, дополнительная стоимость построения окупается качеством поиска на каждом запросе.
Оба индекса приближённые: они не гарантируют строго ближайшие векторы, а находят близкие с настраиваемой вероятностью. Выбор между IVFFlat и HNSW — баланс между скоростью построения и качеством выдачи на конкретном наборе данных.
Документ целиком редко попадает в эмбеддинг — регламенты, базы знаний, confluence-страницы разбиваются на фрагменты (чанки) перед векторизацией. Размер чанка и перекрытие между соседними чанками напрямую влияют на качество поиска: слишком крупный чанк размывает эмбеддинг (в одном векторе смешаны несколько тем), слишком мелкий теряет контекст.
Каждый чанк снабжается метаданными: источник документа, раздел, дата обновления, права доступа. Эти метаданные хранятся в реляционных колонках той же таблицы — фильтрация по ним выполняется обычным WHERE в SQL-запросе, без отдельного слоя логики.
Эмбеддинги генерируются внешней моделью (open-source или через API) и сохраняются в PostgreSQL вместе с текстом чанка. Хранить исходный текст рядом с вектором важно: без него после поиска пришлось бы делать отдельный запрос за содержимым фрагмента.
Пайплайн складывается из трёх этапов.
Документ проходит чанкинг, каждый чанк векторизуется, строка (текст чанка + вектор + метаданные) записывается в таблицу с колонкой типа vector.
Запрос пользователя векторизуется той же моделью, что и документы. SQL-запрос с оператором близости и LIMIT возвращает топ-N релевантных чанков.
Найденные чанки передаются как контекст в LLM, которая формирует ответ со ссылкой на исходный документ.
В корпоративных сценариях чисто векторного поиска часто недостаточно: запрос может содержать точный термин или код документа, который эмбеддинг «размывает». Гибридный поиск — комбинация векторного сходства с полнотекстовым (tsvector) или с фильтрацией по метаданным — повышает точность за счёт объединения семантического и лексического сигналов в одном запросе.
Managed PostgreSQL снимает с команды задачи, не относящиеся к продуктовой логике: бэкапы, обновления минорных версий, мониторинг инстанса. Настройка расширения pgvector, выбор типа индекса и его параметров остаются на стороне пользователя — это вопрос конкретной нагрузки, а не инфраструктуры.
Рост таблицы с эмбеддингами стоит планировать отдельно: пересборка индекса HNSW или IVFFlat при массовой догрузке данных — ресурсоёмкая операция, которую лучше закладывать в окно обслуживания, а не выполнять на живой нагрузке.
Права доступа к документам в RAG-системе — не декоративная деталь. Если фильтрация по правам делается постфактум (на стороне приложения, после того как SQL вернул чанки), документ с ограниченным доступом может «протечь» в контекст LLM до применения фильтра. Правильная точка проверки — сам SQL-запрос: row-level security или явная фильтрация по метаданным прав в том же запросе, который выполняет поиск по вектору.
При очень большом объёме векторов (сотни миллионов и выше) специализированные векторные БД могут показать лучшую производительность за счёт архитектуры, изначально заточенной под ANN-поиск в таком масштабе.
Приближённый поиск не гарантирует стопроцентный recall ни при IVFFlat, ни при HNSW. Для сценариев, где пропущенный релевантный документ критичен (юридические, медицинские регламенты), качество поиска нужно тестировать на реальных запросах, а не полагаться на настройки индекса по умолчанию.
Выбор между IVFFlat и HNSW, как и подбор параметров индекса, требует эмпирической настройки: универсального ответа нет — есть баланс под конкретный набор данных и профиль нагрузки.
Наши специалисты свяжутся с вами в ближайшее время и ответят на все вопросы.
Будем держать в курсе новостей и облачных трендов
