Векторные базы данных: что они хранят и когда они нужны
Понятное объяснение того, что такое векторные эмбеддинги, чем векторные БД отличаются от реляционных или документоориентированных, и когда технология стоит добавления в стек.
«Нам нужна векторная база данных» стало распространённой фразой в предложениях по ИИ-проектам. Иногда это оправдано. Часто - это инфраструктура по принципу карго-культа: добавили, потому что в статье про RAG упоминался Pinecone, и теперь Pinecone есть в архитектурной диаграмме, и никто не объяснил, что она хранит и зачем.
Этот пост - попытка дать менеджеру или техническому собственнику достаточно ясную модель, чтобы задавать правильные вопросы.
Что такое эмбеддинг
Когда языковая модель или модель эмбеддингов обрабатывает текст, она преобразует его в список чисел - обычно несколько сотен или тысяч. Этот список называется вектором, и он кодирует нечто вроде «смысла» текста в геометрическом пространстве.
Ключевое свойство: тексты, которые означают похожие вещи, получают векторы, которые близки друг к другу в этом пространстве. «Условие расторжения договора» и «пункт об аннулировании соглашения» будут иметь близкие векторы. «Условия оплаты счёта» - чуть дальше. «Отзыв корма для собак» - далеко.
Эта близость измерима. Именно это измерение векторные базы данных умеют выполнять эффективно на больших объёмах.
Что делает векторная база данных
Векторная БД хранит векторы (и обычно рядом - исходный текст или документ) и оптимизирована для одного конкретного типа запроса: «дан этот вектор - найди N векторов в базе, которые наиболее похожи на него».
Традиционная реляционная база тоже может хранить векторы, но её индексы построены для точных совпадений и запросов по диапазонам. Поиск по близости среди миллионов многомерных векторов требует других структур данных - индексов приближённых ближайших соседей - на этом и специализируются векторные базы.
Когда она вам действительно нужна
Векторный поиск по близости нужен, когда:
- Вы строите семантический поиск, где пользователи ожидают найти документы по смыслу, а не по ключевым словам.
- Вы строите RAG-систему, и ваш корпус достаточно большой, чтобы не влезть в контекстное окно модели.
- Вы делаете рекомендации в больших масштабах на основе сходства контента.
- Вы ищете почти дублирующиеся документы или кластеризуете их по теме.
Отдельная векторная база вам скорее всего не нужна, если:
- Ваш корпус достаточно мал, чтобы поместиться в контекстное окно используемой модели.
- Вам нужен только ключевой поиск с некоторым ранжированием.
- Вы создаёте прототип - pgvector в Postgres отлично справляется с умеренными нагрузками и убирает одну операционную зависимость.
Практическая архитектура
В типичной RAG-системе:
- Вы прогоняете документы через модель эмбеддингов и сохраняете полученные векторы в векторной базе рядом с исходными фрагментами текста.
- На этапе запроса вы эмбеддируете вопрос пользователя и извлекаете N наиболее похожих фрагментов из векторной базы.
- Вы помещаете эти фрагменты в контекстное окно генеративной модели вместе с вопросом.
- Модель отвечает на основе этого контекста.
Качество этого пайплайна очень сильно зависит от того, как вы нарезаете документы на фрагменты и какую модель эмбеддингов используете - а не только от выбора векторной базы. Многие проблемы с качеством RAG, которые я вижу на практике, уходят корнями в примитивную нарезку (разбивка по количеству символов без учёта смысловых границ), а не в выбор базы.
Операционная реальность
Векторные базы данных - относительно молодая категория. Ведущие варианты - Pinecone, Weaviate, Qdrant, Chroma, Milvus - все разумны, но различаются моделью хостинга (управляемый vs self-hosted), возможностями фильтрации и производительностью обновлений.
pgvector остаётся моей рекомендацией по умолчанию для проектов, где корпус умещается в несколько миллионов векторов и команда уже работает с Postgres. Это на один сервис меньше для эксплуатации. Когда масштаб превышает этот порог или нужны функции вроде мультиарендности с жёсткой изоляцией - специализированные решения становятся оправданными.
Вопрос не «какую векторную базу выбрать», а «нужна ли нам отдельная, исходя из реального объёма данных?»