Главная / Статьи / Как на самом деле работают векторные базы данных: от эмбеддингов до гибридного поиска

Vector Databases Embeddings RAG Semantic Search Azure AI Search HNSW

Как на самом деле работают векторные базы данных: от эмбеддингов до гибридного поиска

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

1832 слов

Есть фраза, которая постоянно возникает, когда разработчики впервые начинают работать с системами GenAI:

«Я понимаю, как работают SQL-базы данных. Но векторные базы данных по-прежнему кажутся мне чёрным ящиком».

Это вполне разумная позиция.

Традиционная база данных обрабатывает запросы с помощью структурированных связей:

SELECT * FROM customers WHERE country = 'India';

Векторная база данных создана для ответов на совершенно иной тип вопросов:

«Какие сохранённые элементы имеют значение, наиболее близкое к этому запросу?»

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

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

Самое важное — это не технология базы данных как таковая.

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

Что же такое эмбеддинг?

Преобразование смысла в числа

Рассмотрим следующее предложение:

"Employees can work remotely for up to 30 days."

Модель эмбеддингов преобразует его в вектор:

[0.021, -0.184, 0.731, 0.092, ...]

На практике эмбеддинги имеют сотни или даже тысячи измерений.

Не стоит считать отдельные числа такими:

«Это конкретное значение означает слово “сотрудник”.»

Это неточная картина в уме.

На самом деле вектор представляет собой изученную числовую кодировку семантических характеристик текста.

Учитывая это, предложения вроде:

"I love my dog."
"My puppy is my favorite companion."

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

"I love my dog."
"The database connection timed out."

Вот основной механизм, который используется.

Значение преобразуется во что-то, что можно математически искать.

Генерация эмбеддинга

Создание эмбеддинга с помощью модели следует простой схеме:

from openai import OpenAI

client = OpenAI()

response = client.embeddings.create(
    model="text-embedding-3-small",
    input="Employees can work remotely for up to 30 days."
)

vector = response.data[0].embedding
print(len(vector))
print(vector[:5])

Результатом являющийся вектор не предназначен для чтения человеком.

Это нормально.

Люди не являются целевой аудиторией для сырых чисел.

Цель — сравнить этот вектор с другими векторами.

Похожесть — вот что действительно важно

По сути, база данных векторов ищет в математическом пространстве

Предположим, у вас есть три исходных документа:

A -> Remote work policy
B -> Travel reimbursement policy
C -> Employee leave policy

А ваш запрос звучит так:

"Can I work from home while travelling abroad?"

Сначала запрос преобразуется в эмбеддинг.

Затем этот вектор запроса сравнивается с вектором каждого документа.

Широко используемой метрикой похожести здесь является косинусная похожесть:

import numpy as np

def cosine_similarity(a, b):
   return np.dot(a, b) / (
      np.linalg.norm(a) *
      np.linalg.norm(b)
   )

Визуально это выглядит так:

Большее значение косинусного сходства указывает на то, что два вектора направлены примерно в одном направлении.

После нормализации векторов косинусное сходство математически становится близким к сходству, основанному на скалярном произведении.

Именно это совпадение объясняет, почему оба понятия часто упоминаются при обсуждении систем поиска векторов.

Почему мы не можем просто сравнить каждый вектор?

Масштаб — причина неудачи наивного подхода

Представьте набор данных, состоящий из:

1,000 documents

При таком размере сравнение запроса со всеми векторами — дело тривиальное.

Теперь представьте:

100 million vectors

Проведение полного сравнения со всеми векторами при таком масштабе становится дорогостоящим.

Именно эту проблему решает индексация векторов.

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

Хорошо известной группой таких методов являются HNSW — иерархические навигируемые графы малого мира.

Чтобы воспользоваться поиском векторов, вам не обязательно создавать HNSW самостоятельно.

Однако вам необходимо понимать основной компромисс:

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

Этот компромисс лежит в основе функционирования баз данных векторов.

Что на самом деле хранится в индексе векторов?

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

document = {
    "id": "policy-1042",
    "title": "Remote Work Policy",
    "content": "Employees can work remotely...",
    "department": "HR",
    "country": "India",
    "embedding": vector
}

Этот деталь имеет большое значение.

Эмбеддинг не является заменой полному документу.

Он служит удобным для поиска представлением документа.

Помимо него вам всё равно необходимо сохранять:

оригинальный текст, метаданные, уникальные идентификаторы, детали контроля доступа и ссылки на исходный источник

Это становится критически важным при создании систем RAG для корпоративного использования.

Azure AI Search

Точка пересечения векторного поиска и корпоративного поиска

Azure AI Search предлагает векторный поиск наряду с традиционным поиском по ключевым словам и гибридными комбинациями обоих подходов.

Упрощённый пример векторного запроса выглядит следующим образом:

from azure.search.documents.models import VectorizedQuery

vector_query = VectorizedQuery(
    vector=query_vector,
    k_nearest_neighbors=5,
    fields="content_vector"
)
results = search_client.search(
    search_text=None,
    vector_queries=[vector_query],
    select=["title", "content"]
)

Результат поиска не представляется в виде:

«Вот наиболее близкое по математическим показателям предложение».

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

Именно здесь архитектурные решения начинают иметь реальное значение.

Почему гибридный поиск часто бывает лучше

Поиск на основе смысла и поиск по ключевым словам проявляют себя лучше в разных ситуациях

Возьмем такой вопрос:

"Что гласит политика HR-2026-17?"

Для такого вида поиска по ключевым словам работает отлично.

Теперь сравним это с:

"Может ли сотрудник временно работать из другой страны?"

Здесь явно преимущество у семантического поиска.

Вместо того чтобы выбирать один подход в ущерб другому:

Keyword OR Vector

вы можете их объединить:

Keyword + Vector => Hybrid Ranking

Azure AI Search позволяет выполнять гибридные запросы, сочетающие полнотекстовый поиск с векторным поиском.

Это позволяет использовать полезную схему:

results = search_client.search(
    search_text="remote work from another country",
    vector_queries=[vector_query],
    top=10
)

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

Не стоит решать все проблемы поиска исключительно с помощью эмбеддингов.

Фильтрация метаданных не является опциональной в корпоративных масштабах

Представьте, что ваш векторный индекс содержит документы вроде этих:

India HR policies
US HR policies
UK HR policies
Finance policies
Engineering documentation

Затем пользователь задает вопрос:

"Каков лимит возмещения расходов на поездку в Индию?"

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

Использование фильтров метаданных позволяет сузить диапазон поиска:

results = search_client.search(
    search_text=query,
    vector_queries=[vector_query],
    filter="country eq 'India'",
    top=5
)

Теперь процесс поиска сочетает в себе два фактора:

Semantic relevance + Structured filtering

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

Они не заменяют то, что базы данных уже делают хорошо.

Вместо этого она сочетает неструктурированное семантическое поиск с привычным подходом к структурированным данным.

Pinecone, Weaviate и Databricks Vector Search

Разные поставщики, одна и та же основная концепция

Несколько платформ, с которыми вы, скорее всего, столкнетесь:

Pinecone

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

Weaviate

База данных векторов с открытым исходным кодом, предоставляющая возможности векторного поиска, фильтрации и ряд дополнительных функций, ориентированных на ИИ.

Databricks Vector Search

Функция векторного поиска, встроенная в платформу Databricks; она особенно полезна, когда корпоративные данные уже хранятся в lakehouse.

Интерфейсы и операционные детали различаются у этих инструментов.

Основная концепция остается прежней:

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

Начните с понимания самой модели поиска.

Как только вы это сделаете, каждый продукт станет просто одним из вариантов реализации.

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

Векторная база данных — не лучший инструмент для всех сценариев ИИ

К числу наиболее подходящих ситуаций относятся:

Корпоративные системы RAG

Поиск соответствующих политик, документации и технических знаний.

Семантический поиск

Поиск на основе скрытых концепций, а не точного совпадения ключевых слов.

Системы поддержки

Поиск прошлых инцидентов или заявок, похожих на текущий.

Поиск кода

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

Помощники по инженерии данных

Сбор соответствующих документов к пайплайнам, схем, руководств по работе и истории инцидентов.

Тем не менее для структурированных аналитических запросов не следует автоматически использовать векторную базу данных.

Если вопрос звучит так:

"Каковы были доходы во 2 квартале?"

и ответ хранится в управляемом хранилище данных, то SQL обычно является более подходящим инструментом.

Structured question => SQL
Semantic question => Vector Search
Mixed question => SQL + Vector Search

Уже это различие может помочь избежать множества архитектурных ошибок.

Архитектура предприятия, которую я предпочитаю

Хорошо спроектированная система поиска чаще напоминает пайплайн, чем отдельный инструмент.

Векторная база данных — это лишь одна из составляющих этого пайплайна.

Вероятно, это самое распространенное заблуждение, которое стоит исправить.

Сама по себе векторная база данных не делает приложение ИИ умнее.

Это предоставляет эффективный способ поиска информации на основе семантической близости.

Настоящий интеллект формируется из всего, что его окружает:

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

Модель мышления, которую нужно запомнить

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

Вместо этого запомните следующее:

Embedding = numerical representation of meaning

Vector Search = find semantically similar representations

Vector Index = make nearest-neighbor search fast

Hybrid Search = semantic + lexical retrieval

Metadata Filter = apply structured constraints

Reranking = improve ordering of retrieved candidates

Как только эти шесть концепций станут вам понятны, инструменты вроде Azure AI Search, Pinecone, Weaviate и Databricks Vector Search перестанут казаться отдельными загадками.

Это просто разные способы решения одного и того же основного вопроса:

Как при наличии запроса выделять наиболее полезную информацию из огромного набора данных?

Именно по этой причине векторные базы данных имеют такое значение.

Они — не просто ещё один тип баз данных.

Они превращаются в один из ключевых элементов систем поиска, обеспечивающих работу современных ИИ-систем.

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

Связанные материалы

Сравнительный тестирование векторных баз данных для высокопроизводительного семантического поиска — Ознакомьтесь с практической методологией на Node.js и Python для тестирования векторных баз данных при реалистичной нагрузке, которая поможет принимать обоснованные архитектурные и масштабирующие решения.
Векторные базы данных: принципы работы движка, лежащего в основе RAG и поиска с использованием ИИ — Узнайте, как векторные базы данных преобразуют текст в эмбеддинги, обеспечивают семантический поиск и работу пайплайнов RAG, а также способствуют развитию реальных ИИ-приложений, таких как системы рекомендаций.

Управление пайплайнами Docling через HTTP: от настройки проекта до индексированных фрагментов — Пошаговое руководство по использованию REST API пайплайнов Docling: запуск сервера, обнаружение операторов, проверка и выполнение DAG для вставки данных, а также чтение информации об их выполнении.

Настройка индексов HNSW и масштабирование векторного поиска для производственных систем RAG — Узнайте, как параметры M и ef в алгоритме HNSW влияют на точность воспроизведения, задержку и использование памяти, как настроить их в Chroma, а также когда следует масштабировать векторную базу данных вертикально или с помощью шардинга.

Все статьи Прислать бриф