Векторная база данных

Векторная база данных — это система хранения и поиска, оптимизированная для работы с векторными представлениями объектов: текстов, изображений, аудио, товаров, событий. Ее основная задача — находить не точные совпадения, а похожие объекты по расстоянию между векторами. Это полезно для семантического поиска, рекомендаций и RAG, но не заменяет обычную реляционную БД там, где важны транзакции, строгие связи, точные фильтры и полностью объяснимый результат.

Простыми словами

Обычная база данных хорошо отвечает на вопросы вида найди запись с id=42 или покажи все заказы за март. Векторная база нужна для другого типа задач: найди то, что похоже по смыслу. Например, пользователь ищет не точную фразу из документации, а задает вопрос своими словами. Ключевые слова могут не совпасть, но смысл должен совпасть.

Для этого текст, изображение или другой объект сначала преобразуют в набор чисел фиксированной длины — вектор или эмбеддинг. Если два объекта близки по смыслу, их векторы обычно оказываются близко и в математическом пространстве. Векторная база хранит такие векторы, строит специальный индекс и быстро возвращает ближайшие объекты.

На практике под векторной базой понимают как отдельные системы, так и расширения к существующим хранилищам и поисковым движкам. Важно не название продукта, а набор возможностей: хранение векторов, поиск ближайших соседей, фильтрация по метаданным, обновление индексов и приемлемая задержка на рабочей нагрузке.

Как это работает

1. Подготовка данных. Исходный объект преобразуют в эмбеддинг с помощью модели. Для текста это может быть предложение, абзац или фрагмент документа; для изображения — его визуальное представление.
2. Сохранение. В базу записывают сам вектор, идентификатор объекта и метаданные: источник, дата, права доступа, категория, язык, версия документа.
3. Индексация. Для быстрого поиска ближайших векторов строят индекс. Полный перебор возможен, но на больших объемах слишком дорог. Поэтому используют алгоритмы приближенного поиска ближайших соседей, или ANN.
4. Запрос. Пользовательский запрос тоже преобразуют в вектор той же моделью или совместимой моделью.
5. Поиск и ранжирование. Система ищет ближайшие векторы по выбранной мере расстояния: косинусное сходство, скалярное произведение или евклидово расстояние. Затем результат можно отфильтровать по метаданным и при необходимости доранжировать отдельной моделью.

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

Важно и то, что качество векторного поиска зависит не только от базы. На результат сильно влияют:

• выбор модели эмбеддингов;
• разбиение документов на фрагменты;
• чистота и актуальность корпуса;
• метрика расстояния;
• параметры индекса;
• наличие гибридного поиска и доранжирования.

Если эмбеддинги плохие, база не исправит проблему. Она лишь быстро найдет ближайшие элементы в том пространстве, которое задала модель.

Зачем нужно

• Семантический поиск. Поиск по смыслу в документации, базе знаний, тикетах, договорах, письмах, медицинских заметках.
• RAG. Извлечение релевантных фрагментов для языковой модели перед генерацией ответа.
• Рекомендации. Поиск похожих товаров, статей, видео, резюме, вакансий.
• Мультимодальный поиск. Поиск по изображениям, аудио и другим данным, где обычный SQL сам по себе бесполезен.
• Дедупликация и поиск похожих инцидентов. Нахождение близких документов, повторяющихся обращений или похожих лог-событий.

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

Пример

Практический сценарий: внутренняя база знаний команды эксплуатации. Есть инструкции, runbook-файлы, постмортемы и ответы из тикет-системы. Задача — помочь инженеру быстро найти релевантные фрагменты по вопросу в свободной форме.

Компонент	Что делает
Эмбеддинг-модель	Преобразует фрагменты документов и пользовательский запрос в векторы
Векторная база	Хранит векторы, текст фрагмента и метаданные
Фильтры	Ограничивают поиск по продукту, версии и правам доступа
Реранкер	Уточняет порядок найденных фрагментов перед показом или передачей в LLM

Процесс выглядит так:

1. Документы разбивают на фрагменты разумного размера, чтобы один кусок содержал законченную мысль.
2. Для каждого фрагмента считают эмбеддинг и сохраняют запись вида id + vector + text + metadata.
3. Когда инженер спрашивает: как откатить неудачную миграцию после сбоя, запрос тоже превращают в вектор.
4. Система ищет ближайшие фрагменты, дополнительно фильтруя по нужному продукту и версии.
5. Лучшие результаты показывают пользователю или передают в RAG-цепочку для генерации ответа.

Преимущество такого подхода в том, что система может найти документ с формулировкой rollback schema change after failed deployment, даже если в запросе пользователя нет этих точных слов. Ограничение тоже видно сразу: если в базе лежат устаревшие инструкции или модель плохо понимает доменную лексику, результат будет неубедительным независимо от скорости индекса.

Заблуждения и ограничения

• Заблуждение: векторная база заменяет любую БД. Нет. Для транзакций, нормализованных схем, сложных join-операций и строгой целостности по-прежнему нужны реляционные системы.
• Заблуждение: она всегда лучше полнотекстового поиска. Нет. Для артикулов, кодов ошибок, названий полей, точных цитат и юридически значимых формулировок обычный поиск часто надежнее. На практике часто выигрывает гибридный поиск.
• Заблуждение: достаточно просто сохранить векторы. Нет. Нужны качественные метаданные, контроль версий документов, фильтрация по доступам, оценка качества выдачи и мониторинг деградации.
• Ограничение: приближенный поиск не гарантирует идеальный топ. ANN дает выигрыш по скорости, но результат зависит от настройки индекса и допустимой потери полноты.
• Ограничение: высокая зависимость от эмбеддингов. Плохая модель, плохое разбиение на фрагменты или смешение языков и доменов ухудшают качество сильнее, чем выбор конкретной базы.
• Ограничение: стоимость ресурсов. Большие коллекции векторов требуют памяти, диска и времени на переиндексацию. При частых обновлениях и высоком QPS это становится архитектурным фактором.
• Ограничение: объяснимость. Ответ потому что эти векторы близки не всегда достаточен для аудита, комплаенса или разборов инцидентов. Там, где нужна строгая трассируемость причин ранжирования, векторный поиск стоит дополнять прозрачными правилами.

Метод плохо подходит для маленьких наборов данных, где можно обойтись обычным индексом и простым ранжированием, а также для систем, где каждая выборка должна быть полностью детерминированной и легко объяснимой. Если у вас каталог на несколько тысяч записей и пользователи ищут по точным атрибутам, отдельная векторная инфраструктура может быть избыточной.

Частые вопросы

Чем векторная база отличается от полнотекстового поиска?

Полнотекстовый поиск опирается на слова, токены и статистику их встречаемости. Векторная база ищет по близости эмбеддингов, то есть по смысловому сходству. Для точных терминов лучше работает полнотекстовый поиск, для перефразирований и семантики — векторный. Во многих системах лучший результат дает их комбинация.

Нужна ли отдельная векторная база, если уже есть PostgreSQL или Elasticsearch?

Не всегда. Если объем умеренный, требования к задержке разумные, а команда хочет упростить стек, может хватить расширения вроде pgvector или встроенного vector search в поисковом движке. Отдельная система оправдана, когда важны масштаб, специализированные индексы, изоляция нагрузки и отдельное управление жизненным циклом поиска.

Как выбрать меру расстояния?

Сначала смотрят на рекомендации модели эмбеддингов. Для нормализованных текстовых эмбеддингов часто используют косинусное сходство или скалярное произведение. Но выбирать метрику стоит не по привычке, а по оценке на своей выборке: одна и та же модель и задача могут вести себя по-разному.

Что важнее: база, индекс или модель эмбеддингов?

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

Связанные понятия

• Эмбеддинги. Числовые представления объектов, в которых близость отражает семантическое сходство.
• ANN. Approximate Nearest Neighbor, приближенный поиск ближайших соседей для быстрого поиска в больших коллекциях.
• HNSW. Популярная структура индекса для ANN-поиска с хорошим балансом задержки и качества.
• Гибридный поиск. Комбинация полнотекстового и векторного поиска в одной выдаче.
• RAG. Retrieval-Augmented Generation, схема, где LLM сначала получает релевантные фрагменты из поиска, а потом формирует ответ.
• Реранжирование. Дополнительная стадия, где небольшое число найденных кандидатов пересортировывают более точной моделью.
• Метаданные. Атрибуты объекта, по которым применяют фильтры: язык, дата, продукт, права доступа, тип документа.