Как реализовать семантический поиск для RAG-архитектуры в PostgreSQL без усложнения инфраструктуры?
Ситуация: вы разрабатываете чат-бота для техподдержки на базе RAG-архитектуры. Используете PostgreSQL как хранилище знаний и делаете поиск по текстовым полям, но качество ответов нестабильное: система плохо справляется с синонимами, профессиональным сленгом и переформулировками запросов. Обязательно ли внедрять отдельную векторную базу данных, или можно реализовать семантический поиск прямо в PostgreSQL? Возможна ли простая проверка продуктовой гипотезы без усложнения архитектуры?
Да, семантический поиск в RAG-сценариях можно реализовать прямо в PostgreSQL без выделенной векторной базы данных (ClickHouse, Opensearch, Qdrant, Milvus и т. д).
Для этого используется PostgreSQL + расширение pgvector, которое добавляет поддержку хранения эмбеддингов (векторов) и поиск по расстоянию до ближайших соседей (KNN) прямо внутри SQL-движка. Разберем, как это работает на практике.
В RAG-пайплайне текст документов и запрос пользователя преобразуются в векторные представления. PostgreSQL хранит эти векторы в таблице и позволяет выполнять поиск по смысловой близости, а не по точному совпадению слов.
Для этой задачи будем использовать pgvector — это расширение к PostgreSQL, которое добавляет тип данных vector и операторы поиска по расстоянию до ближайших соседей (KNN).
Поддерживаются три основные метрики сравнения векторов:
L2 (евклидово расстояние) — классическое расстояние между двумя точками в многомерном пространстве. Хорошо работает, если векторы не нормализованы и распределение значений относительно равномерное.
Cosine similarity (косинусное сходство). В отличие от предыдущей метрики измеряет не абсолютное расстояние, а угол между двумя векторами. Подходит для текстовых эмбеддингов, где важна направленность, а не масштаб. Требует нормализации векторов.
Inner product (внутреннее произведение) — скалярное произведение двух векторов. Может использоваться как прокси для оценки «сходства» при обучении моделей и в задачах ранжирования.
Допустим, мы получаем на наш запрос именно такой вектор от модели OpenAI. Для хранения создаем таблицу с типом VECTOR:
CREATE TABLE items ( id SERIAL PRIMARY KEY, title TEXT, embedding VECTOR(1536) );
Добавим данные для нескольких векторов разных объектов:
INSERT INTO items (title, embedding) VALUES ('PostgreSQL embeddings', '[0.10, -0.80, 0.45]'), ('Neural image processing', '[0.42, 0.18, -0.35]'), ('Sound pattern matching', '[-0.20, 0.70, 0.60]'), ('Document clustering', '[0.09, -0.79, 0.48]');
Теперь сравним их попарно и отсортируем по расстоянию:
SELECT a.title AS title_a, b.title AS title_b, a.embedding <-> b.embedding AS distance FROM items a JOIN items b ON a.id < b.id ORDER BY distance;
Оператор <-> здесь вычисляет расстояние между двумя векторами. Таким образом, мы можем оценивать степень семантической близости любых объектов, представленных векторами. Какая именно метрика используется, зависит от операторного класса, заданного при создании индекса.
В подобных RAG-сценариях нет необходимости сразу вводить отдельный класс инфраструктуры типа векторная БД. Семантический поиск можно реализовать эволюционно поверх существующего PostgreSQL.
А если вы не хотите самостоятельно заниматься настройкой индексов, тюнингом памяти и производительности, а также обновлением версии PostgreSQL, то воспользуйтесь DBaaS от Selectel. Мы предоставим вам кластер PostgreSQL с преднастроенными расширениями, готовый к эксплуатации под нагрузкой. Это позволит сосредоточиться на RAG-логике и качестве поиска, а не на инфраструктурной оптимизации.
