[!NOTE] Автоматический перевод Эта статья была автоматически переведена с оригинальной английской версии.

Стек технологий для ранжирования результатов поиска в 2026 году: BM25, Эмбеддинги, кросс-кодеры и LLM Реранкинг

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

В этой статье стек постепенно собирается слой за слоем: BM25 retrieval, плотные эмбеддинги, метод слияния обратных рангов, кросс-энкодер реранкинг, и, наконец, метод ранжирования по спискам LLM. рабочая демонстрация бенчмарки — каждый этап в процессе поиска продуктов в сервисе Amazon ESCI датасет.

Кратко: Разрабатывайте систему поиска поэтапно, с измерением эффективности на каждом шаге. Начните с алгоритма BM25, добавьте метод retrieval тогда, когда это улучшит показатель воспроизведения запросов, объединяйте результаты только в том случае, если у двух методов поиска разные типы ошибок, и переранжируйте кандидатские результаты исключительно в рамках заданного бюджета латентность. В этой демонстрации ESCI размером с ноутбук полный цикл обработки пайплайн позволил повысить показатель NDCG@10 с 0,585 до 0,717. Этот результат является примером реальной работы, а не доказательством того, что каждая производственная система обязана использовать все пять этапов или онлайн-механизм LLM.


Выбор этапов в зависимости от режима сбоя

Сценарий примененияПредварительная стековая конфигурация кандидатаПроверка корректности
Поиск продуктовBM25 + плотное retrieval + RRF + кросс-энкодерпоказатель восстановления атрибутов, замены, латентность, ограничения бизнес-логики
Поиск документацииГибридный retrieval + кросс-энкодерТочные идентификаторы, семантические вопросы, фильтры версий
Поддержка дефлекцииГибридный подход retrieval с интеграцией проверок цитированияRetrieval — это показатель воспроизведения, граундинг, а также уровень отказа.
Рынок или каталог товаровЛексические фильтры + интенсивная обработка retrieval + бизнес-логика реранкерДоступность, свежесть, политика и разнообразие продавцов
Небольшой внутренний корпус данныхБазовая модель BM25, затем реранкерЯвляется ли несоответствие словарного запаса основанием для использования плотного индекса?
Критически важный поиск в юридической или медицинской сферахПодход, ориентированный на воспоминание retrieval, в сочетании с экспертной оценкойПокрытие, происхождение, калиброванное воздержание

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

Как мы дошли до этого состояния

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

BM25 и лексикальный retrieval

На протяжении десятилетий, BM25 Это был стандартный вариант. Речь идет о вероятностном методе модель, который оценивает документы по частоте выражений запроса в них с учетом нормализации на длину документа и обратную частоту документа (IDF).

BM25 демонстрирует высокую эффективность в тех случаях, когда буквальные термины точно отражают поисковый интент: коды ошибок, идентификаторы SKU продуктов, названия и API. Основным ограничением этого алгоритма является несоответствие словарного состава. Запрос на поиск «дешёвого ноутбука» может пропустить документ, описывающий «ноутбук бюджетной категории», если в индексированном тексте отсутствует связующее звено между этими выражениями.

Тем не менее, BM25 представляет собой надёжную базовую модель. Она показывает средний показатель nDCG@10 в размере 0.429 по всему набору данных. BEIR бенчмарк’s 18 датасеты и Это всё равно лучше, чем некоторые нейронные модели. при решении аргументативных задач типа retrieval Tуш-2020.

Плотные retrieval и эмбеддинги

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

Архитектура би-энкодера (или «двух-башенная») обрабатывает запрос и документ независимо с помощью отдельных энкодерных башен, генерируя векторы фиксированной длины эмбеддинги. Векторы документов могут быть предварительно вычислены и индексированы офлайн, после чего их можно быстро извлекать с использованием алгоритмов приближённого поиска ближайшего соседа (ANN). Благодаря этому такие термины, как «дешёвый ноутбук» и «ноутбук бюджетного класса», теперь находятся рядом друг от друга в векторном пространстве.

Некоторые би-энкодеры используют Siamese architecture, как в Sentence-BERT, В таких случаях обе стороны используют веса. Другие подходы предусматривают отдельные модули для обработки запросов и поиска документов. Механизм объединения ресурсов, размер векторов, функция сходства и цель обучения являются модель выбором разработчика, а не неотъемлемыми характеристиками всех методов плотного поиска.

Эти модели обучаются с использованием contrastive learning, как правило, путём InfoNCE loss. При наличии пакета пар (запрос, положительный документ) цель заключается в максимизации sim(query, positive_doc) при минимизации sim(query, negative_docs). Негативные примеры формируются на основе положительных примеров из других запросов той же партии (внутрипартийные негативы). Параметр температуры τ\tau определяет степень остроты распределения: более низкие значения заставляют модель усиливать различия между положительными и негативными примерами.

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

Стоимость представления определяется через боттлнек. Биинкодеры сжимают всю семантическую нюансированность в один вектор фиксированного размера, из‑за чего они зачастую упускают тонкие взаимосвязи между конкретными терминами запроса и конкретным содержимым документа.

Кросс-энкодеры и LLMs

Кросс-энкодеры (Nogueira и Cho, 2019) загружаем запрос и документ в Transformer в виде объединённой последовательности[CLS] Query [SEP] Document), поэтому каждый запрос токен может обрабатывать каждый документ токен с использованием полного self-attention. Такое глубокое взаимодействие позволяет улавливать нюансы, которые ускользают при простом кодировании.

LLM реранкинг применяет индуцированный модель для одновременного сравнения нескольких кандидатов. RankGPT На тестовых данных бенчмарки модель GPT-4 показала высокую эффективность в режиме zero-shot при обработке списков, однако стабильность вывода, расходы на вычисления и соответствие конкретной области применения требуют дополнительных проверок.

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


Многоэтапный воронка

Запуск дорогостоящего кросс-энкодера или LLM на масштабе миллионов документов является нерентабельным подходом, поэтому современные системы поиска используют структуру в виде воронки. На каждом этапе происходит сужение списка потенциальных результатов по мере роста модель сложности обработки.

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

Многоэтапный воронка ранжирования

ЭтапМасштаб входных данныхОсновная цельТипичные методыИзмерение выхода
RetrievalКорпус данных или индексКоэффициент воспоминания кандидатовBM25, бай-энкодерыВоспроизведение на этапе отбора кандидатов
ПредранжированиеБольшой набор кандидатовДешёвая фильтрацияЛегковесный модели, правилаКоличество сохранённых элементов в миллисекунду
Полный рейтингСписок кандидатовВысокое качество топового уровняКросс-энкодеры, LLMsNDCG/MRR, латентность, стоимость
СмешиваниеИтоговые списки с рангами или слотыОграничения и смешиваниеПравила, ранжирование многокритериальных задачПолитика, разнообразие и бизнес гардрейлы

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


Демонстрация: пятиэтапный процесс пайплайн

Чтобы проиллюстрировать это на практике, я разработал стек поисковой ранжирования демонстрация, выполняющая пятиэтапную пайплайн на Amazon ESCI Поиск продуктов бенчмарк. Каждый этап измеряется независимо, что позволяет определить, откуда именно происходит улучшение качества результатов.

Демонстрация архитектуры Пайплайн

пайплайн:

  1. BM25 sparse retrieval — лексический эталонный индексатор (rank_bm25)
  2. Плотный би-энкодер retrieval — генерация семантических кандидатов (all-MiniLM-L6-v2)
  3. Гибридное слияние RRF — слияние разреженных и плотных результатов на основе рангов
  4. Кросс-кодер реранкинг — парные оценки релевантности (ms-marco-MiniLM-L-12-v2)
  5. LLM поэлементное реранкинг — запрошенное сравнение итогового списка кандидатов (Ollama, API или локальный модель)

Шаги 1–3 представляют собой этап retrieval воронки (максимизация воспроизводства); шаги 4–5 — этап полной ранжировки (максимизация точности). В демо-версии опускаются этапы предварительного ранжирования и смешивания результатов. При объёме около 8 500 документов можно напрямую отправлять все гибридные результаты в реранкинг.

Быстрое начало

git clone https://github.com/slavadubrov/search-ranking-stack.git
cd search-ranking-stack
uv sync

# Download and sample ESCI dataset (~2.5GB download, ~5MB sample)
uv run download-data

# Run the full pipeline (without LLM reranking)
uv run run-all

# Run with LLM reranking via Ollama
uv run run-all --llm-mode ollama

Датасет и сэмплирование: Amazon ESCI

В демонстрации используются Amazon Shopping Queries Датасет (ESCI) из Kубок KDD 2022 — настоящий механизм поиска продуктов бенчмарк с четырёхуровневыми метками степени релевантности:

МеткаполучениеПример (запрос: «беспроводные наушники»)
Точное (E)3Удовлетворяет всем требованиям запроса.Беспроводные наушники Sony WH-1000XM5
Замена (S)2Функциональная альтернативаНаушники с проводом и адаптером Bluetooth
Комплемент (C)1Связанный полезный элементЧехол для наушников
Нерелевантно (I)0Отсутствует значимая связьUSB-кабель для зарядки

Значимость элементов рейтинга, оценённая по степени градации, критически важна, поскольку она позволяет использовать NDCG (Normalized Discounted Cumulative Gain) — показатель, отделяющий «идеальный» порядок элементов от «просто приемлемого». Бинарные метрики считают все элементы на одном уровне равно значимыми и не способны различать разные степени значимости в одной и той же позиции.

Я использовал демо-версию. small_version Пример: около 500 запросов, 8 500 продуктов и 12 000 оценок. Эта выборка достаточно мала, чтобы её можно было обрабатывать на ноутбуке, однако она слишком небольшая и специфична по домену для формирования рейтинга в производственных условиях. Её следует использовать для воспроизведения отдельных этапов работы системы и анализа моделей сбоев; для принятия деплой решений подходят отобранные, репрезентативные запросы.


Retrieval: гибридный поиск

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

BM25: лексический базовый вариант

Алгоритм BM25 оценивает документы на основе степени перекрытия термов с запросом, учитывая насыщение частоты термов и нормализацию длины документа:

BM25(q,d)=tqIDF(t)tf(t,d)(k1+1)tf(t,d)+k1(1b+bd\/textavgdl)\text{BM25}(q, d) = \sum_{t \in q} \text{IDF}(t) \cdot \frac{tf(t,d) \cdot (k_1 + 1)}{tf(t,d) + k_1 \cdot (1 - b + b \cdot |d|\/text{avgdl})}

Где IDF(t)\text{IDF}(t) является обратной частотой документа для термина tt; tf(t,d)tf(t,d) — это частота термина в документе dd.|d|—этодлинадокумента,а— это длина документа, а\text{avgdl}—средняядлинадокументоввкорпусе.Важныдвапараметра:— средняя длина документов в корпусе. Важны два параметра:k_1(обычно1,22,0)регулируетнасыщениекоэффициентаTF—тоестьскорость,скоторойповторяющиесятерминыперестаютвноситьвкладвоценку,—а(обычно 1,2–2,0) регулирует насыщение коэффициента TF — то есть скорость, с которой повторяющиеся термины перестают вносить вклад в оценку, — аb$ (обычно 0,75) отвечает за нормализацию длины документа.

Реализация краткая. Простой пробел токенизация используется для rank_bm25:

# src/search_ranking_stack/stages/s01_bm25.py

from rank_bm25 import BM25Okapi

def run_bm25(data: ESCIData, top_k: int = 100):
    doc_ids = list(data.corpus.keys())
    tokenized_corpus = [text.lower().split() for text in data.corpus.values()]

    bm25 = BM25Okapi(tokenized_corpus)

    results = {}
    for query_id, query_text in data.queries.items():
        scores = bm25.get_scores(query_text.lower().split())
        top_indices = np.argsort(scores)[::-1][:top_k]
        results[query_id] = {doc_ids[idx]: float(scores[idx]) for idx in top_indices}

    return results

BM25 достигает показателя Recall@100 в 0.741 — 74% релевантных продуктов попадают хотя бы в одну из позиций топ-100. Для чисто лексикального метода это неплохо, однако 26% релевантных элементов остаются незамеченными на всех последующих этапах обработки.

Плотный би-энкодер retrieval

Би-энкодер независимо преобразует запросы и документы в общий пространство эмбеддинг:

# src/search_ranking_stack/stages/s02_dense.py

from sentence_transformers import SentenceTransformer

model = SentenceTransformer("sentence-transformers/all-MiniLM-L6-v2")

# Encode corpus once, cache to disk
corpus_embeddings = model.encode(
    doc_texts,
    batch_size=128,
    normalize_embeddings=True,  # Cosine sim = dot product
    convert_to_numpy=True,
)

# At query time: encode query, compute dot product
query_embeddings = model.encode(query_texts, normalize_embeddings=True)
similarity_matrix = np.dot(query_embeddings, corpus_embeddings.T)

При нормализации эмбеддинги косинусное сходство сводится к скалярному произведению. В демонстрации вычисляется полная матрица запросов по корпусу, поскольку 8 500 документов удобно помещаются в памяти; в реальных проектах для работы с крупными корпусами обычно используется индекс ближайших соседей. В данном примере all-MiniLM-L6-v2 Повышает показатель Recall@100 с 0.741 до 0.825.

Как би-энкодеры обучаются формировать качественные представления

Обучение би-энкодера обычно проходит в две фазы. Сначала модель проходит предварительное обучение на задачах понимания естественного языка Инференс (NLI) и оценки семантической схожести текстов датасеты, что помогает развить универсальное семантическое восприятие — модель учится распознавать, что выражения вроде «кошка сидит на коврике» и «кошачья особь отдыхает на ковре» должны иметь схожие эмбеддинги. Затем модель подвергается дополнительной настройке на данных, специфичных для retrieval, таких как MS MARCO, где она учится понимать, что запрос и соответствующий ему фрагмент текста должны находиться ближе друг к другу, чем запрос и несвязанные с ним фрагменты.

Ключевым элементом второй фазы является процесс hard negative mining. Случайные отрицательные примеры (например, документ о приготовлении пищи, связанный с запросом об наушниках) легко различимы, и модель не может извлечь из них никакой полезной информации. Вместо этого используется сам текущий модель для поиска документов, которые он высоко ранжирует, но на самом деле не имеют к запросу никакого отношения.

Этот SimANS Подход (Simple Ambiguous Negatives Sampling) формализует этот процесс следующим образом: сначала с помощью текущего бай-энкодера определяется ранг всех документов, после чего исключаются простые отрицательные примеры (имеющие слишком низкий ранг — с ними уже справляется модель) и потенциальные ложноотрицательные примеры (имеющие слишком высокий ранг — они могут на самом деле быть релевантными, но не иметь меток). Именно «сложная зона посередине» генерирует максимально эффективный сигнал для обучения.

# What a training triplet looks like after hard negative mining
training_triplet = {
    "query": "wireless noise canceling headphones",
    "positive": "Sony WH-1000XM5 Wireless Noise Cancelling Headphones",
    "negative": "Sony headphone replacement ear pads",  # Hard negative: same brand, related product, but wrong intent
}
# The bi-encoder must learn that "ear pads" is NOT what the user wants,
# even though it shares many tokens with the positive document.

Функция потерь на основе контраста (InfoNCE) связывает все эти элементы воедино. Для каждого запроса qq с положительным документом d+d^+ и набора отрицательных документов {d1,,dn}\{d^-_1, \ldots, d^-_n\}:

L=logesim(q,d+)/τesim(q,d+)/τ+i=1nesim(q,di)/τ\mathcal{L} = -\log \frac{e^{\text{sim}(q, d^+) / \tau}}{e^{\text{sim}(q, d^+) / \tau} + \sum_{i=1}^{n} e^{\text{sim}(q, d^-_i) / \tau}}

Где sim(q,d)\text{sim}(q, d) представляет собой косинусное сходство между запросом и документом эмбеддинги, а τ\tau — параметр температуры (обычно в диапазоне 0.05–0.1), который определяет степень остроты распределения: чем меньше его значение, тем сильнее функция потерь реагирует на явные отрицательные примеры. По сути это кросс-энтропия с функцией softmax: Необходимо повысить схожесть позитивной пары по отношению ко всем негативным примерам. При малом значении τ\tau даже незначительные различия в схожести приводят к крупным градиентам, что заставляет модель делать более тонкое различие между элементами.

Обучение двойного энкодера Пайплайн

Сервинг двойной кодировщик эмбеддинги в крупном масштабе

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

В демо-версии объём данных невелик: 8 500 документов × 384 измерения × 4 байта на каждый числовой тип float = примерно 13 МБ эмбеддинги. Однако в реальных производственных условиях показатели резко возрастают: 1 миллиард документов с эмбеддинги размером 768 измерений требуют около 3 ТиБ памяти. Именно здесь на помощь приходит квантизация (сжатие 32‑битных чисел типа float до 8‑битных целых чисел). продукт квантизация (разложение векторов на подпространства) и индексы, основанные на SSD DiskANN Войдите. Этот Раздел индексации плотных векторов рассматривает алгоритмы построения индексов.

Двухканальный кодировщик Сервинг Пайплайн

Почему тестируют гибридные retrieval решения

Эти два метода часто демонстрируют различные признаки сбоев. Алгоритм BM25 особенно эффективен для обработки собственных имён, уникальных идентификаторов продуктов и кодов ошибок. Метод плотного retrieval позволяет устранять несоответствия в словарном составе, такие как использование терминов «дешёвый ноутбук» и «ноутбук бюджетной категории». Эффективность объединения этих подходов зависит от того, насколько часто встречаются подобные взаимодополняющие сценарии в исходном наборе запросов.

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

Фьюжн взаимных рангов (RRF)

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

Гибридный поиск с RRF

Слияние рекурсивных рангов (Cormack et al., 2009) полностью исключают первоначальные оценки и используют исключительно порядковое положение:

RRF(d)=rRankings1k+rank(d,r)\text{RRF}(d) = \sum_{r \in \text{Rankings}} \frac{1}{k + \text{rank}(d, r)}

Здесь kk представляет собой константу сглаживания; значение 60 часто используется в качестве начального параметра. Алгоритм RRF стимулирует элементы, занимающие высокие позиции в списках входных данных, без необходимости сравнения их первоначальных оценок. Он позволяет избежать проблемы масштабирования оценок калибровка, однако все равно требуется оценка retrieval пороговых значений, веса, а также значения kk.

Реализация:

# src/search_ranking_stack/stages/s03_hybrid_rrf.py

def reciprocal_rank_fusion(ranked_lists, k=60, top_k=100):
    fused_results = {}

    for query_id in all_query_ids:
        rrf_scores = defaultdict(float)

        for results in ranked_lists:
            sorted_docs = sorted(results[query_id].items(),
                                 key=lambda x: x[1], reverse=True)

            for rank, (doc_id, _score) in enumerate(sorted_docs, start=1):
                rrf_scores[doc_id] += 1.0 / (k + rank)

        sorted_rrf = sorted(rrf_scores.items(),
                            key=lambda x: x[1], reverse=True)[:top_k]
        fused_results[query_id] = dict(sorted_rrf)

    return fused_results

Гибридный RRF достигает показателей Recall@100 равных 0.842 и NDCG@10 равных 0.628 — что превосходит результаты как BM25 (0.585), так и Dense (0.611) при использовании каждого из них по отдельности. Чтобы документ смог выжить в процессе слияния, ему достаточно иметь хороший ранг только в одном из методов.


Кросс-энкодер реранкинг

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

Би-энкодер против кросс-энкодера

Взаимодействие на уровне Токен

Реальная разница заключается в аттеншн матрице. В би-энкодере аттеншн имеет блок-диагональную структуру: запросы токены взаимодействуют только с другими запросами токены, а документы токены — только с другими документами токены. Эти два вида представлений никогда не встречаются на уровне токен; они пересекаются лишь в конце процесса через скалярное произведение. Кросс-энкодер же вычисляет полную аттеншн матрицу, при которой каждый запрос токен взаимодействует со всеми документами токен, и наоборот. Именно это cross-attention позволяет реализовать глубокое взаимодействие на уровне токен.

Архитектура кросс-энкодера Аттеншн

В би-энкодере запрос «apple» кодируется ещё до того, как появляются документы. Кросс-энкодер рассматривает запрос и кандидаты одновременно, что позволяет ему использовать их отношения на уровне токен. Это может быть полезно в таких случаях, как:

Входной сигнал к кросс-энкодеру форматируется как [CLS] query tokens [SEP] document tokens [SEP]. [CLS] это метод классификации токен, при котором окончательное скрытое состояние пропускается через линейный блок для вычисления единственного значения оценки релевантности. Сегменты эмбеддинги отвечают за различение запроса токены и документа токены, [SEP] обозначает границу между сегментами.

Как обучаются кросс-энкодеры

Кросс-энкодеры могут обучаться на (query, document, relevance_label) Примеры с целями типа «по точкам», «по парам» или «по списку». В приведённом ниже примере с целью «по точкам» используется единая метка релевантности; это не единственный вариант проектирования обучения.

# Cross-encoder training data format
training_example = {
    "query": "wireless headphones",
    "document": "Sony WH-1000XM5 Wireless Headphones",
    "label": 1.0,  # Relevant
}
# Forward pass: [CLS] hidden state → Linear layer → sigmoid → score
# Loss: binary cross-entropy between predicted score and label

Обычный классификатор отображает итоговый [CLS] Преобразование данных в оценку качества. Для бинарных меток часто применяется функция бинарной кросс-энтропии; при работе с плавающей шкалой значимости подходят методы регрессии, ординальные функции потерь, а также способы расчёта потерь на уровне пар или всего списка. Выбор подходящего метода следует осуществлять на основе метрик ранжирования, полученных с использованием отдельной выборки, а не на предположении, что одна цель объективно лучше других.

Добыча жёстких отрицательных примеров имеет ещё более важное значение для кросс-энкодеров по сравнению с би-кодерами. Кросс-кодеры требуют значительных ресурсов для обучения — для каждого примера требуется полный проход по объединённой последовательности, — поэтому нельзя тратить вычислительные мощности впустую на крайне простые отрицательные примеры. Практический подход заключается в использовании би-кодера для получения топ-K кандидатов для каждого запроса в процессе обучения, а затем извлечении «твёрдых» отрицательных примеров из определённых диапазонов рангов (например, с 10 по 100). Это позволяет кросс-кодеру получать примеры, в которых различение релевантных и нерелевантных данных действительно требует глубокой токен взаимодействия.

# src/search_ranking_stack/stages/s04_cross_encoder.py

from sentence_transformers import CrossEncoder

model = CrossEncoder("cross-encoder/ms-marco-MiniLM-L-12-v2")

def run_cross_encoder(data, hybrid_results, top_k_rerank=50):
    for query_id, query_text in data.queries.items():
        candidates = list(hybrid_results[query_id].items())[:top_k_rerank]

        # Form (query, document) pairs for joint encoding
        pairs = []
        doc_ids = []
        for doc_id, _ in candidates:
            doc_text = data.corpus.get(doc_id, "")[:2048]
            pairs.append([query_text, doc_text])
            doc_ids.append(doc_id)

        # Score all pairs with full cross-attention
        scores = model.predict(pairs, batch_size=64)

        # Rerank by cross-encoder score
        scored_docs = sorted(zip(doc_ids, scores),
                             key=lambda x: x[1], reverse=True)
        reranked_results[query_id] = {
            doc_id: float(score) for doc_id, score in scored_docs
        }

В записанном демонстрационном запуске, ms-marco-MiniLM-L-12-v2 Для каждого запроса модель переупорядочивает 50 кандидатов, в результате чего показатель NDCG@10 повышается с 0.628 до 0.645. Необходимо измерить эффективность латентность на аппаратной платформе деплой; значения модель, длины последовательностей, размера пакетов данных и рантайм оказывают влияние на получаемый результат.

Компромисс между скоростью и качеством

Почему не использовать кросс-энкодеры для всех задач? Потому что предварительный расчёт невозможен. Би-энкодеры документов эмбеддинги не зависят от запроса, поэтому их можно вычислить один раз и сохранить. Выход кросс-энкодера определяется одновременно как запросом, так и самим документом. Оценка релевантности для «беспроводных наушников», связанных с продуктом Sony, формируется на основе полного cross-attention между этими конкретными токены. Его нельзя кэш заново или использовать для другого запроса.

Для работы би-кодера требуется кодирование запроса в сочетании с vector search предварительно обработанных документов эмбеддинги. Кросс-кодер оценивает каждую пару запроса и документа из отобранного списка, причем стоимость этой оценки растёт как с количеством кандидатов, так и с длиной последовательности. Группировка запросов помогает снизить нагрузку, однако оценка 100 000 кандидатов по‑прежнему является неоптимальным подходом; сначала необходимо выполнить поиск, а затем бенчмарк сформировать наибольший список, соответствующий критериям качества и латентность.

Показания демо-версии подтверждают следующее правило: показатель Recall@100 остаётся неизменным на уровне 0,842 на протяжении обеих стадий реранкинг. Механизм Реранкинг может переставлять порядок результатов, но никогда не добавляет новые документы. Предел значений задаётся параметром Retrieval.


LLM по элементам реранкинг

На заключительном этапе демонстрации для выполнения операции по списку реранкинг используется LLM. Вместо того чтобы оценивать каждый документ отдельно, модель берёт во внимание 10 лучших результатов и возвращает соответствующую их последовательность. Этот подход был разработан под влиянием RankGPT, промпт делает относительное сравнение явным, однако при этом приводит к появлению ограничений, связанных с контекстом, смещениям из-за позиции элементов, ошибкам парсинга, а также к вариабельности результатов при последовательных запусках.

LLM Реранкинг Подходы

Списковый промпт

Шаблон промпт просит LLM учесть иерархию релевантности ESCI:

# src/search_ranking_stack/stages/s05_llm_rerank.py

def _create_listwise_prompt(query, documents, max_words=200):
    n = len(documents)

    doc_texts = []
    for i, (doc_id, doc_text) in enumerate(documents, start=1):
        words = doc_text.split()[:max_words]
        doc_texts.append(f"[{i}] {' '.join(words)}")

    return (
        f"I will provide you with {n} product listings, each indicated by "
        f"a numerical identifier [1] to [{n}]. Rank the products based on "
        f'their relevance to the search query: "{query}"\n\n'
        "Consider:\n"
        "- Exact matches should rank highest\n"
        "- Substitutes should rank above complements\n"
        "- Irrelevant products should rank lowest\n\n"
        f"{chr(10).join(doc_texts)}\n\n"
        "Output ONLY a comma-separated list of identifiers: [3], [1], [2], ...\n"
        "Do not explain your reasoning."
    )

Три режима выполнения

Демо-версия поддерживает три бэкенды для LLM реранкинг:

РежимМодельКак это работает
ollamallama3.2:3b (настраиваемый)Локальная работа с помощью Ollama API
apiclaude-haiku-4-5-20251001Anthropic API
localQwen/Qwen2.5-1.5B-InstructHuggingFace Transformers

Анализ и резервный вариант

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

def _parse_ranking(output: str, n: int) -> list[int] | None:
    """Parse LLM output to extract ranking order."""
    matches = re.findall(r"\[(\d+)\]", output)

    if not matches:
        return None

    positions = [int(m) - 1 for m in matches]

    # Pad with remaining positions if LLM returned partial output
    if len(positions) < n:
        seen = set(positions)
        for i in range(n):
            if i not in seen:
                positions.append(i)

    return positions[:n]

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


Результаты анализа данного примера из ESCI

Вот результаты выполнения полной обработки пайплайн примерно над 500 запросами ESCI:

Результаты Пайплайн

ЭтапNDCG@10MRR@10Воспоминание@100NDCG-дельта
BM250.5850.8120.741
Плотный двухканальный энкодер0.6110.8080.825+0.026
Гибридный (RRF)0.6280.8340.842+0.017
+ Кросс-энкодер0.6450.8600.842+0.017
+ LLM Реранкер0.7170.9010.842+0.072

Основные замечания

Гибридный способ поиска превосходит любой из методов в работе сам по себе. Показатель RRF NDCG (0.628) оказывается лучше как у алгоритма BM25 (0.585), так и у метода Dense (0.611). Режимы работы с разреженными и плотными retrieval обладают взаимодополняющими слабыми сторонами, и их сочетание позволяет восстановить документы, которые бы были упущены при использовании только одного из них.

Уровень воспроизведения установлен на retrieval. Значение Recall@100 остаётся неизменным и равным 0.842 на протяжении обеих стадий реранкинг. При перестановке Реранкеры документы не добавляются. Если требуется более высокий уровень воспроизведения, необходимо скорректировать слой retrieval.

Результат, полученный при использовании LLM, демонстрирует наибольший зафиксированный скачок показателей в ходе данного теста. Значение NDCG@10 увеличивается на 0,072 после прохождения этапа LLM. Поскольку промпт включает в себя иерархию релевантности ESCI, полученные результаты позволяют оценить эффективность комбинации модель-промпт-датасет. Для того чтобы приписать этот прирост общему преимуществу реранкер, необходимо провести дополнительные тесты, рассчитать интервалы уверенности, учесть параметры латентность и стоимость обработки, а также использовать независимый набор данных.

При использовании метода Dense retrieval результаты превосходят показатели BM25 в данном примере. Прежде чем определять причину, необходимо тщательно проанализировать фрагменты запросов. Одним из возможных факторов может быть несоответствие словаря, однако структура самого примера, токенизатор, область обучения модель, а также характеристики корпуса также оказывают влияние на итоги сравнения.


Оценка: измерение того, что имеет значение

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

NDCG@10 (основной показатель)

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

DCG@k=i=1k2reli1log2(i+1)NDCG@k=DCG@kIDCG@k\text{DCG@k} = \sum_{i=1}^{k} \frac{2^{rel_i} - 1}{\log_2(i + 1)} \qquad \text{NDCG@k} = \frac{\text{DCG@k}}{\text{IDCG@k}}

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

MRR@10 (первый релевантный результат)

Средний обратный ранг определяется на основе позиции первого найденного релевантного результата. Если он занимает 1-е место, значение обратного ранга составляет 1,0; если — 3-е место, оно равно 0,333. При использовании ступенчатых классификаторов, таких как ESCI, необходимо указать порог релевантности, по которому принимается это бинарное решение.

Уровень воспроизведения@100 (retrieval покрытие)

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


Индексация плотных векторов за пределами демо-версии

Плотные эмбеддинги становятся полезными в масштабных системах лишь тогда, когда имеется индекс приблизительного ближайшего соседа (ANN). В демонстрации используется метод прямого вычисления косинусного сходства (который подходит для объёмов около 8 500 документов), однако в производственных системах требуются специализированные индексы.

HNSW (иерархический навигируемый малый мир)

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

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

IVF (обратный файл)

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

Для работы в условиях крайне высокой масштабируемости. IVF_RaBitQ (Gao & Long, SIGMOD 2024) позволяет сжимать векторы с плавающей точкой до однобитных представлений. В высокомерномензиональном пространстве знак координаты (+/–) содержит достаточно информации о направлении для вычисления степени схожести.

РазмерностьHNSW графIVF-кластеры
Контроль запросовefSearchnprobe
Контроль сборкиСвязность и конструктивная балкаКоличество кластеров и обучающие примеры
Профиль памятиРебра графа и векторыЦентроиды, списки и сохранённые векторы
Поведение обновленияСпецифичная для базы данных процедура восстановления/очисткиТехническое обслуживание списков, специфичных для базы данных
Оценить с помощьюКривая изменения объёма памяти при рекалке латентностьКривая изменения объёма памяти при вызове на память — латентность

В одном Кейс-стади «Поиск доставщиков в Uber», Сокращение значения параметра поиска на уровне шарда с 1 200 до 200 привело к снижению показателя латентность на 34% и показателя CPU на 17%, причём при этом практически не наблюдалось ухудшения показателя воспроизводимости результатов. Ключевой урок заключается в необходимости настраивать кривую баланса между воспроизводимостью и затратами на обработку запросов в условиях реального трафика, а не просто копировать значение 200.


Дополнительные расширения после основной части пайплайн

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

Понимание запроса

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

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

LLM-маркировка релевантности с использованием помощи ИИ

LLMs способен генерировать метки релевантности в ситуациях, когда отсутствует достаточное количество человеческих оценок. TALEC и Работа Pinterest над маркировкой релевантности Предоставьте два прошедших оценку варианта проектирования. Метка LLM по‑прежнему является результатом модель: необходимо откалибровать её с использованием суждений людей, не знакомых с деталями задачи, проанализировать участки разногласий и сохранить набор «золотых» стандартов, созданных людьми, для последующих тестов регрессии.

Полезные элементы управления включают:

Дистилляция знаний

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

  1. Используйте мощный LLM (учитель) для переранжирования тысяч запросов, предназначенных для обучения.
  2. Обучите небольшой, быстрый кросс-энкодер (ученик, с примерно 100–200 млн параметров), способный имитировать распределение рангов, характерное для LLM.
  3. Сравните производительность ученика с учителем и базовым вариантом с точки зрения качества, калибровка и стоимости сервинг.

InRanker сокращает модель MonoT5-3B до версий с 60 млн и 220 млн параметров модели — что обеспечивает уменьшение размера в 50 раз при сохранении конкурентоспособной производительности. The Метод ранжирования без использования GPT Данный подход позволяет сгенерировать список из 7 миллиардов элементов в формате открытого кода с использованием реранкеры, который обеспечивает 97% эффективности по сравнению с GPT-4 благодаря QLoRA файн-тюнинг.

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


Персонализация и смещение из-за позиции

Общая степень релевантности помогает лишь в ограниченной степени. Поиск по запросу «apple» должен возвращать информацию об iPhone для технологически заинтересованного пользователя, а рецепты с использованием яблок — для того, кто изучал контент о кулинарии.

Распространённый retrieval Архитектура персонализации опирается на схему двух башен. эмбеддинг-модель**: башня запросов кодирует сам запрос и контекст пользователя, в то время как башня элементов кодирует элементы и метаданные. Разделение на офлайн- и онлайн-части позволяет использовать алгоритм приближённого поиска по ближайшему соседу. retrieval; его латентность всё ещё зависит от кодировщика, индекса, фильтров и сервинг система.

Анкета объекта на Airbnb эмбеддинги, Pinterest’s OmniSearchSage, и системы двух башен Uber Представлены различные варианты производственных архитектур. Масштабы этих решений и указанные показатели улучшения соответствуют характеристикам конкретных систем; переносимой структурой является комбинация оффлайн-структуры для обработки элементов и онлайн-модуля для обслуживания запросов/пользователей.

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


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

Распространённой ошибкой при выборе стратегии поиска является предположение, что модель модель, обученная на общих веб-данных (таких как MS MARCO), будет эффективно справляться с задачами в специализированных доменах. Это и есть так называемая проблема выхода за пределы домена (OOD).

LLMs позволяет сократить объём меченных данных боттлнек с помощью техники Generative Pseudo-Labeling, но не устраняет его полностью.GPL, ИнПарс):

  1. Возьмите свой корпус документов, специфичный для вашей области.
  2. Промпт LLM с целью сгенерировать запрос к поиску, на который будет отвечать данный документ.
  3. Используйте синтетические пары (запрос, документ), чтобы отточить работу вашего механизма извлечения информации и реранкер.

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

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

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

Практический путь достижения зрелости

Шаг 1 (базовая версия): реализовать алгоритм BM25 или существующую лексическую систему и создать набор тестовых запросов с известными ответами. Зазначить показатели воспроизведения, NDCG, латентность, а также диапазоны случаев сбоев.

Шаг 2 (восстановление кандидатов): проводить тестирование методов плотного retrieval и фьюжн только в том случае, если базовый подход упускает релевантные документы. Настройка порога отбора кандидатов осуществляется с учётом показателей восстановления и стоимости обработки.

Шаг 3 (точность ранжирования): при наличии подходящих кандидатов, которые расположены в неверном порядке, необходимо добавить кросс-энкодер. Размер список кандидатов для этого устройства определяется на основе кривой качества-латентность.

Шаг 4 (соответствие домену): процесс тонкой настройки или дистилляции следует начинать только после того, как универсальные модели выявят стабильные ошибки, характерные именно для данного домена. Необходимо сохранять реальные данные с оценками, не включённые в обучение, отдельно от синтетических данных тренировочной выборки.

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


Направления исследований, подлежащие отдельной оценке

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

Реализация на основе Ризонинг-связанных реранкеры

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

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

Агентный поиск

Search-o1 В работе рассматривается модель, обеспечивающий выполнение дополнительных поисков при решении вопросов с несколькими этапами обработки. Речь идет о проблеме оркестрация — генерации запросов, остановки процесса, использования доказательств и оценки ответа, а не о каком-либо другом этапе реранкинг. Оценка эффективности такого подхода должна осуществляться на основе критериев корректности выполнения конечной задачи и наличия подтверждающих данных, а не только с использованием retrieval метрик.


Основные выводы

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

  2. Измеряйте воспроизводимость кандидатов отдельно от точности ранжирования. В данном примере из ESCI показатель Recall@100 после слияния данных достигает значения 0.842 и остаётся неизменным на протяжении обоих этапов реранкинг.

  3. Используйте гибридный retrieval в тех случаях, когда ошибки носят взаимодополняющий характер. В демонстрационных данных метод RRF позволил улучшить как показатель Recall@100, так и NDCG@10, однако для других корпусов использование двух индексов может оказаться неоправданным.

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

  5. Рассматривайте LLM реранкинг как факультативный заключительный эксперимент. Полученный при этом прирост показателя NDCG@10 в размере 0,072 относится к данному промпт, модель, набору примеров и критериям оценки релевантности. В процесс оценки должны входить многократные запуски, строгая обработка данных, механизмы резервного варианта и учёт затрат.

  6. Сохраняйте разделение типов доказательств. Результаты исследования, кейс-стади от поставщика, демонстрация на ноутбуке и тестирование типа A/B в производственных условиях отвечают на разные вопросы.

Полный код пайплайн находится по адресу github.com/slavadubrov/search-ranking-stack. Скопируйте его, запустите, замените на разные модели и параметры, а затем сами посмотрите полученные значения.

Список литературы

Статьи

Датасеты и бенчмарки

Модели, используемый в демонстрации

Инструменты и платформы

Примеры из отрасли

Проект-демо