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

Эмбеддинги, векторные базы данных и реранкеры — это три разные части поиска. Модель эмбеддингов преобразует текст или другие данные в числовые представления; векторная база данных или векторный индекс хранит и ищет эти представления, чтобы получить элементы-кандидаты; реранкер берёт меньший набор кандидатов и переупорядочивает его с помощью более дорогой модели релевантности или метода оценки. Они часто встречаются вместе в RAG, но ни один из них не является тем же самым, что и RAG, и ни один не обязателен в каждой поисковой системе.

Что это на самом деле означает

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

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

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

Простейший пример

Предположим, база знаний содержит 100 000 фрагментов документов. Пользователь спрашивает: «Как отозвать API-токен?»

Сначала модель эмбеддингов может закодировать запрос в вектор. Фрагменты документов, возможно, уже имеют собственные сохранённые эмбеддинги. Затем векторный поиск сравнивает вектор запроса с индексированными векторами документов и возвращает, например, 30 вероятных кандидатов.

Эти 30 кандидатов затем можно передать реранкеру. Реранкер сравнивает запрос более напрямую с каждым кандидатом и создаёт новый порядок релевантности. Приложение может оставить лучшие пять для контекста модели.

Где простой пример останавливается

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

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

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

Эмбеддинги: представление, а не поиск

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

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

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

Модель эмбеддингов определяет пространство представлений

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

Именно поэтому миграция модели эмбеддингов — это не просто смена имени API. Существующие документы могут потребовать повторного вычисления эмбеддингов, а индекс — перестроения или версионирования.

Плотные и разреженные представления различаются

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

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

Функции сходства — часть контракта представления

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

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

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

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

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

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

Приближённый поиск ближайших соседей обменивает точность на эффективность

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

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

Qdrant предоставляет как параметры, связанные с HNSW, так и опцию точного поиска, что иллюстрирует, что хранение векторов и политика приближённого поиска — это отдельные решения.

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

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

Тот же принцип применяется к локали, статусу документа, классу источника, дате, версии продукта и другим детерминированным ограничениям. Сходство должно ранжировать допустимых кандидатов; оно не должно отменять допустимость.

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

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

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

Переранжирование: уточнение релевантности на втором этапе

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

Текущие рекомендации Elastic описывают семантическое переранжирование как технику финального этапа над небольшим набором top-k и отмечают, что оно может уточнять лексический, семантический или гибридный поиск. Cohere документирует ту же архитектуру: лексический или семантический поиск на первом этапе, за которым следует этап переранжирования.

Распространённая реализация использует модель, подобную кросс-энкодеру, которая рассматривает запрос и каждого кандидата вместе. Такое более богатое взаимодействие может различать релевантность точнее, чем независимое сходство эмбеддингов, но оно гораздо дороже в масштабе корпуса.

Поиск с би-энкодером и переранжирование с кросс-энкодером решают разные задачи по стоимости

Переранжировщик не может восстановить то, что пропустил поиск

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

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

Гибридный поиск — это отдельный проектный выбор

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

Гибридный поиск объединяет несколько сигналов кандидатов, часто лексический BM25 и векторное сходство, а затем объединяет ранжирования с помощью такого метода, как Reciprocal Rank Fusion или взвешенная комбинация оценок.

Затем переранжирование может работать с объединённым набором кандидатов. Таким образом, гибридный поиск и переранжирование — это взаимодополняющие, но различные этапы.

BM25 не устарел из-за появления эмбеддингов

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

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

Разбиение на фрагменты меняет то, что могут видеть эмбеддинги и переранжировщики

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

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

Не сравнивайте оценки поиска так, как будто это универсальные вероятности

Косинусное сходство, оценки BM25, оценки разреженных векторов, ранги RRF и оценки переранжировщика имеют разные значения. Оценка 0,82 от одной модели эмбеддингов не обязательно сопоставима с 0,82 от другой модели или с оценкой переранжировщика.

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

Оценивайте этапы поиска отдельно

Это разделение операционно важно. Если Recall@50 низкий, реранкер — не первый компонент, который нужно исправлять. Если Recall@50 высокий, но лучший пассаж остаётся на 38-м месте, реранжирование или объединение ранжирований становится вероятной целью.

Какой слой на самом деле отказал?

Релевантность и источник истины — это разные вещи

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

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

Свидетельства из оригинальной реализации

Source of Truth Research Engine: лексический и семантический поиск разделены

Source of Truth Research Engine содержит локальный путь лексического поиска с использованием SQLite FTS5/BM25 и отдельный опциональный путь семантического поиска с использованием локально сгенерированных эмбеддингов.

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

Это полезное свидетельство реализации для R01, поскольку один и тот же корпус может поддерживать лексическое ранжирование и векторное сходство, не смешивая ни один из этих механизмов с доказательной авторитетностью.

Aaasaasa AI Client: Qdrant — это компонент векторной инфраструктуры

Aaasaasa AI Client включает Qdrant/векторную инфраструктуру как отдельный локальный ресурс. Архитектура Electron предоставляет сервисы Qdrant со стороны доверенного главного процесса, а не рассматривает векторный поиск как часть самой модели.

Репозиторий содержит адаптер клиента Qdrant, конфигурацию сервиса Qdrant и инфраструктуру Qdrant на основе Docker. Это демонстрирует архитектурное разделение между выполнением AI-провайдера/модели и векторным хранением/поиском.

Наличие поддержки Qdrant не следует преувеличивать как полноценный production RAG-конвейер. Свидетельство здесь более узкое: векторная инфраструктура реализована как собственная граница компонента.

Когда нужен каждый компонент?

Практическая последовательность проектирования поиска

Распространённые заблуждения

Краевые случаи и ограничения

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

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

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

Многоязычный и доменно-специфичный поиск может вести себя очень по-разному в разных моделях эмбеддингов. Заявления о бенчмарках из публичных наборов данных не следует считать доказательством для частного корпуса.

Задержка реранжирования растёт с количеством и длиной кандидатов. Поэтому размер набора кандидатов следует настраивать как переменную точности/стоимости/задержки, а не копировать из руководства.

Что могло бы изменить этот ответ?

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

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

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

Связанные канонические знания

R01 предполагает, что базовое понятие RAG уже понято. RAG — это более широкий паттерн, в котором найденная внешняя информация подаётся модели; эмбеддинги, векторный поиск и реранжирование — это опциональные компоненты поиска внутри этого паттерна.

Когда поиск даёт сбой, диагностируйте покрытие источников, поиск, ранжирование, сборку контекста и генерацию по отдельности, а не рассматривайте всю систему как одну «ошибку RAG».

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

Часто задаваемые вопросы

Глоссарий

Заключение

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

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

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

Первоисточники и доказательства реализации

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