Vector Database

Vector Database хранит embedding-вектора вместе со ссылками на исходные объекты и метаданными. Для нового запроса она находит ближайшие записи по выбранной метрике, применяет фильтры и возвращает кандидатов. Векторный поиск используют в RAG, рекомендациях и поиске похожих текстов, изображений и аудио.

Коротко

Vector Database хранит векторы и быстро находит записи, которые находятся ближе всего к вектору запроса. Рядом с вектором обычно лежат идентификатор, исходный объект или ссылка на него и метаданные. Embedding создаёт отдельная модель; база отвечает за хранение, индекс, фильтрацию и поиск соседей.

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

В реальности координат не две и не три, а гораздо больше. Визуальная карта — только метафора многомерного пространства embeddings.

Из чего состоит запись

Векторная запись обычно объединяет несколько частей:

id + vector + payload/metadata + ссылка на исходный объект

• ID связывает результат с документом, кадром, товаром или пользователем.
• Vector — числовое представление объекта, созданное embedding-моделью.
• Metadata хранит язык, автора, раздел, права доступа, дату, тип файла и другие поля для фильтров.
• Исходный объект может находиться в самой базе или во внешнем хранилище. Часто сохраняют текстовый фрагмент и ссылку на полный документ.

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

Как проходит запрос

Типичная цепочка выглядит так:

1. Пользователь вводит текст или передаёт изображение.
2. Та же embedding-модель, которой индексировали коллекцию, создаёт вектор запроса.
3. База применяет обязательные фильтры: например, раздел, язык или права доступа.
4. Индекс ищет ближайшие векторы по выбранной метрике.
5. База возвращает записи, их расстояния и метаданные.
6. Следующий этап показывает результаты, объединяет их с лексическим поиском или отправляет на reranking.

объект → embedding model → query vector → vector index → ближайшие записи

Сама Vector DB обычно не понимает текст и не создаёт embedding. Она получает уже готовый массив чисел. Некоторые продукты прячут вызов модели за удобным API, но архитектурно это остаются разные задачи.

Почему похожие смыслы оказываются рядом

Embedding-модель обучена размещать связанные объекты ближе друг к другу. Фразы «уютное место для чтения» и «кресло у тёплой лампы» могут иметь мало общих слов, но получить близкие направления в векторном пространстве.

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

Метрики близости

Ближайший сосед определяется не интуицией, а математической функцией.

Косинусная близость

Сравнивает угол между векторами. Направление важно сильнее длины. Часто используется для нормализованных текстовых embeddings.

Скалярное произведение

Учитывает направление и величину. Для векторов единичной длины порядок результатов совпадает с косинусной близостью, хотя числовые значения записаны иначе.

Евклидово расстояние

Измеряет прямое расстояние между точками. Подходит, если именно такая геометрия использовалась при обучении embedding-модели.

Метрику выбирают не по популярности, а по документации модели. Смена cosine на dot product без проверки нормализации способна изменить порядок результатов.

Совместимое пространство

Документы и запрос должны быть закодированы совместимым способом:

• одной моделью или гарантированно совместимыми версиями;
• с одинаковой размерностью;
• с тем же препроцессингом текста или изображения;
• с одинаковой нормализацией;
• в одной модальности или в общем мультимодальном пространстве.

Нельзя проиндексировать коллекцию одной случайной моделью, а искать векторами другой. Координаты могут иметь одинаковую длину, но описывать разные системы отсчёта.

При смене embedding-модели коллекцию обычно переиндексируют. Безопасная миграция хранит версии в отдельных полях или индексах, пока новый поиск не проверен и не переключён.

Точный и приближённый поиск

Самый прямой способ — посчитать расстояние от запроса до каждого вектора и отсортировать результаты. Это exact nearest-neighbor search: он находит настоящих ближайших соседей, но его стоимость растёт вместе с коллекцией.

На больших наборах используют ANN — Approximate Nearest Neighbor. Индекс просматривает только часть пространства и возвращает очень близких кандидатов, иногда пропуская точного соседа. Выигрыш в скорости оплачивается неполным recall.

Настройка ANN всегда балансирует три величины:

• задержку запроса;
• долю найденных правильных соседей;
• память и размер индекса.

Слова «приближённый поиск» не означают случайный результат. Качество можно измерить: берут выборку запросов, находят точных соседей полным перебором и сравнивают их с ответом индекса.

Как устроены индексы

HNSW

HNSW строит многослойный граф близких векторов. Поиск начинается на разреженном верхнем уровне, быстро приближается к нужной области и уточняется на нижних слоях. Индекс даёт сильный компромисс между скоростью и recall, но требует дополнительной памяти и времени на построение.

IVF

IVF делит пространство на области вокруг центров. Запрос сначала выбирает ближайшие области, затем сравнивается только с векторами внутри них. Чем больше областей просматривается, тем выше recall и больше работа.

Quantization

Квантизация хранит более компактное представление векторов. Сжатый индекс можно использовать для широкого отбора кандидатов, а затем пересчитать расстояние по исходным векторам. Такая двухступенчатая схема экономит память без обязательного отказа от точного финального порядка.

Методы можно комбинировать. Название индекса само по себе не определяет производительность: важны распределение данных, фильтры, оборудование, обновления и параметры запроса.

Метаданные и фильтры

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

похожесть по вектору
+ язык = русский
+ доступ = разрешён
+ тип = инструкция

Фильтр может применяться до, во время или после обхода ANN-индекса. От этого зависит и скорость, и полнота результатов. Если сначала найти небольшую пачку соседей, а потом отбросить почти всё по редкому условию, итоговый список окажется пустым. Системе приходится расширять поиск, использовать отдельные индексы, партиции или filter-aware traversal.

Права доступа особенно важно проверять внутри retrieval-слоя, а не после передачи текста языковой модели. Иначе закрытый фрагмент уже окажется в контексте, даже если интерфейс не покажет его пользователю.

Vector Database и RAG

В RAG база служит одним из способов найти контекст. Полный путь показан в разборе «RAG и AI-поиск»: документы разбиваются на фрагменты, получают embeddings, попадают в индекс, а найденные кандидаты проходят дополнительные этапы перед ответом.

документы → chunking → embeddings → Vector DB
                                      ↓
запрос → embedding → поиск → reranking → контекст → ответ

Vector DB не пишет ответ и не гарантирует, что найденный текст верен. Она решает более узкую задачу: вернуть кандидатов, геометрически близких к запросу.

Векторный, лексический и гибридный поиск

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

Hybrid Search объединяет оба списка, а reranker уточняет порядок небольшой пачки кандидатов. Такая цепочка полезна, когда запросы смешивают естественный язык с точными обозначениями.

Не обязательно отдельная база

Vector Database — это класс возможностей, а не обязательный тип отдельного сервера. Векторный столбец, метрика и ANN-индекс могут быть частью:

• реляционной СУБД;
• поискового движка;
• распределённой базы;
• встроенной библиотеки внутри приложения;
• специализированного векторного сервиса.

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

Обновления и удаление

Документы меняются, а вместе с ними должны меняться embeddings. У записи полезно хранить хеш исходного фрагмента и версию модели. Тогда конвейер понимает, что переиндексировать, и не пересчитывает неизменившийся текст.

Удаление тоже требует внимания. Нужно убрать:

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

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

Как оценивать качество

У Vector DB есть два разных слоя качества.

Качество retrieval

Проверяется на запросах с известными релевантными объектами. Смотрят recall@k, precision, MRR или nDCG — в зависимости от задачи.

Качество инфраструктуры

Измеряют задержку, пропускную способность, расход памяти, время обновления индекса, устойчивость фильтров и поведение при отказах.

Высокий ANN recall ещё не доказывает, что semantic search полезен: exact-поиск может идеально воспроизводить геометрию плохой embedding-модели. Поэтому отдельно сравнивают индекс с brute force, а весь retrieval — с человеческой разметкой.

Мультимодальный поиск

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

В ComfyUI можно собрать workflow для подготовки embeddings изображений, поиска похожих референсов и загрузки найденных файлов. База при этом остаётся внешним компонентом или пользовательской нодой, а не встроенной памятью графа. Важно сохранять путь, права и версию encoder рядом с каждым вектором.

Частые ошибки

Индексировать документы целиком

Длинный embedding усредняет несколько тем. Для RAG чаще полезнее осмысленные фрагменты с заголовком и ссылкой на родительский документ.

Не версионировать embedding-модель

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

Хранить только текст

Без метаданных трудно применить доступ, язык, источник и дедупликацию. Векторная близость не заменяет структуру данных.

Настраивать ANN по одному запросу

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

Считать distance абсолютной уверенностью

Расстояние имеет смысл внутри конкретной модели и коллекции. Один порог нельзя без проверки переносить между энкодерами и темами.

Забывать про дубликаты

Похожие или одинаковые chunks занимают весь верх списка. Дедупликация и разнообразие результатов часто не менее важны, чем ещё один процент ANN recall.

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

Чем Vector DB отличается от embedding-модели?

Модель создаёт вектор. База сохраняет его, строит индекс и ищет соседей. Один компонент не заменяет другой.

Всегда ли нужен ANN-индекс?

Нет. На небольшой коллекции exact search проще, даёт эталонный recall и иногда полностью устраивает по скорости. Индекс добавляют после измерений.

Можно ли хранить вектора в обычной базе?

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

Что такое top-k?

Это число ближайших кандидатов, которое возвращает поиск. Большее k даёт следующему этапу больше вариантов, но увеличивает работу, объём контекста и риск шума.

Как выбрать метрику?

По требованиям embedding-модели и проверке на своём тестовом наборе. Для нормализованных векторов cosine и dot product часто дают одинаковый порядок, но их числовые шкалы различаются.

Можно ли смешать embeddings текста и изображений?

Только если модель обучена помещать их в совместимое пространство. Два отдельных энкодера без общей геометрии создадут несопоставимые координаты.

Главное

Vector Database — это слой хранения и поиска по близости. Она получает готовый вектор запроса, использует exact или approximate index, применяет фильтры и возвращает связанные объекты с метаданными.

Хороший результат зависит не от модного названия базы, а от всей цепочки: embedding-модели, chunking, совместимой метрики, фильтров, индекса, обновлений и оценки на реальных запросах. Одному проекту подходит отдельный векторный сервис, другому — столбец и индекс в уже существующей СУБД.