Программы для переранжирования тоже не волшебные: когда кросс-кодировочный слой оправдывает затраты

Enterprise Document Intelligence [Том 1 #2bis] Почему добавление переранжировщика к слабому поиску не спасает ситуацию, что действительно исправляют кросс-кодировщики, а что нет, и какова позиция редакции этой серии.

Делиться

Та же самая схема, что и в статье об эмбеддингах. Две ситуации.

Сцена 1. Команда, разрабатывающая систему RAG для нескольких сотен контрактов, ознакомилась со статьей 2. Встраивания данных дают сбой при отрицании, при точных идентификаторах, при разрыве между вопросом и ответом. Первым рефлексом команды стало то, что предлагает литература: добавить переранжировщик . Кросс-кодировщик, меньший по размеру, чем LLM, но умнее, чем косинус, вставляют его между встраиваниями и LLM. Они подключают bge-reranker-base , отправляют ему топ-100 с этапа встраивания, а топ-10 сохраняют. Несколько запросов, которые вчера не работали, сегодня, похоже, заработали. Команда воодушевлена.

Сцена 2. Спустя две недели повторяется та же схема работы, что и в статье 2. Пользователь спрашивает: «Перечислите все пункты, в которых упоминается расторжение договора», и система возвращает три «наиболее релевантных», ровно три, в порядке убывания значимости. В договоре их одиннадцать. Пользователь спрашивает: «Каково правило расторжения договора для лиц, не являющихся сотрудниками?» Система переранжирования никогда не встречала в договоре термин non-employee labor , и ставит на первое место несвязанный с ним абзац. Пользователь спрашивает: «Есть ли пункт, в котором НЕ упоминается возмещение убытков?» Та же ошибка отрицания, что и раньше; кросс-кодировщик не видит логического дополнения так же, как и встраивание. Задержка, тем временем, теперь составляет сотни миллисекунд. Кросс-кодировщик запускается во время выполнения запроса для каждого кандидата, и нет способа предварительно его рассчитать. Хуже того: при сравнении результатов с text-embedding-3-large без использования reranker, само по себе встраивание часто совпадает или превосходит результаты ada-002 + bge-reranker-base .

Классическая воронка поиска выглядит так же, как и в статье 2. Дешевая оценка сходства эмбеддингов внизу сужает список из миллионов кандидатов до тысяч. Дополнительный кросс-кодировщикный переранжировщик между ними сужает список из тысяч до десятков. LLM-модель завершения чата наверху считывает десятки. Переранжировщик — это слой, расположенный между двумя большими константами на лестнице стоимости и качества. Знание того, что на самом деле делает каждый этап, — вот что заставляет воронку работать; ожидание чуда от какого-либо отдельного этапа приводит к тому, что команды теряют шесть месяцев. В этой статье эмпирически проверяется градиент стоимости-производительности: четыре модели эмбеддингов с 2014 по 2024 год, а также три готовых кросс-кодировщикных переранжировщика, оценивались параллельно на примерах, описанных в статье 2. Результат оказывается более неожиданным, чем предполагает воронка.

В этой статье эмпирически проверяется градиент «стоимость-эффективность»: четыре модели встраивания с 2014 по 2024 год, а также три готовых алгоритма переранжирования с использованием кросс-кодировщиков, оценивались параллельно на примерах, описанных в статье 2. Результат оказался более неожиданным, чем предполагает диаграмма распределения.

Семь протестированных моделей, с указанием URL-адресов лицензионных соглашений (URL-адрес страницы, на которой сам автор модели заявляет о наличии лицензии):

• GloVe-avg (2014, 300-мерные векторные представления слов): Apache 2.0, объявлено на карточке модели HuggingFace.
• all-MiniLM-L6-v2 (2021, 22M параметров, 384-размерный): Apache 2.0, объявлен на карточке модели HuggingFace.
• text-embedding-ada-002 (OpenAI 2022, 1536-dim): собственность; Условия использования OpenAI.
• text-embedding-3-large (OpenAI 2024, 3072-dim): собственность; Условия использования OpenAI.
• bge-reranker-base (BAAI 2023, 278M параметров): лицензия MIT, указана в карточке модели HuggingFace.
• bge-reranker-large (BAAI 2023, 560M параметров): лицензия MIT, указана в карточке модели HuggingFace.
• cross-encoder/ms-marco-MiniLM-L-12-v2 (историческая базовая версия): Apache 2.0, объявлен на карточке модели HuggingFace.

 from sentence_transformers import CrossEncoder from openai import OpenAI # Bi-encoder (the embedding stage from Article 2). # Each text becomes a vector INDEPENDENTLY. Cosine in vector space. client = OpenAI() def cosine_score(query, passage): v_q = client.embeddings.create(input=query, model="text-embedding-ada-002").data[0].embedding v_p = client.embeddings.create(input=passage, model="text-embedding-ada-002").data[0].embedding return dot(v_q, v_p) / (norm(v_q) * norm(v_p)) # Cross-encoder reranker. # Query and passage are TOKENIZED TOGETHER and attended over jointly. # One forward pass per (query, passage) pair. Returns a single relevance score. reranker = CrossEncoder("BAAI/bge-reranker-base") def rerank_score(query, passage): return reranker.predict([(query, passage)])[0]

Эта статья является частью более обширной серии «Entreprise Document Intelligence Vol. 1», в которой пошагово выстраивается корпоративная система RAG, начиная с базового конвейера и заканчивая архитектурой масштаба корпуса документов.

1. Что на самом деле представляет собой переранжировщик

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

1.1 Градиент стоимости/точности

Три этапа, упорядоченные по стоимости одного запроса:

• Бикодирующий вектор сходства. Предварительно вычисленный вектор для каждого документа. Во время выполнения запроса модель кодирует запрос один раз и выполняет косинусное сходство по индексу. Миллисекунды для миллионов кандидатов. Дешево и приблизительно.
• Переранжировщик на основе кросс-кодировщика. Запрос и фрагмент текста токенизируются вместе и пропускаются через преобразователь, который обрабатывает оба фрагмента. На выходе получается единый показатель релевантности для каждой пары. Предварительно вычислить его невозможно, поскольку запрос является частью входных данных. Время обработки пары — десятки миллисекунд. Средняя стоимость, средняя точность.
• LLM-функция автозавершения чата. Считывает небольшой набор вариантов и выдает структурированный ответ. Сотни миллисекунд, доллары за миллион токенов. Самая дорогая, самая точная.

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

1.2 Воронка

Архитектурная картина представляет собой воронку. Корпус содержит, скажем, 200 000 страниц. На этапе встраивания оцениваются все страницы, и возвращаются 100 лучших. Переранжировщик оценивает эти 100 страниц и возвращает 10 лучших. LLM анализирует эти 10 страниц и выдает ответ. Каждая стрелка сужает круг кандидатов на порядок или более, и каждый этап оправдан с точки зрения соотношения затрат и качества с соседними страницами.

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

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

1.3 Механическое сравнение двухкодового и кросс-кодового устройств

Механические различия имеют значение для того, что может моделировать каждый из них. Бикодировщик (модель встраивания из статьи 2) кодирует запрос и отрывок независимо друг от друга, а затем сравнивает векторы. Внутри модели они никогда не видят друг друга. Любое взаимодействие между ними (отвечает ли этот отрывок на данный вопрос) должно сохраниться после проекции в вектор фиксированной размерности для каждой стороны.

Кросс-кодировщик токенизирует запрос и фрагмент текста, разделяя их специальным токеном, и пропускает их через трансформер, который обрабатывает обе стороны. Каждый токен в фрагменте текста может обрабатывать каждый токен в запросе. Модель может напрямую оценивать, что «второй токен запроса является отрицанием; третий токен фрагмента текста означает противоположное». В принципе, это дает кросс-кодировщику доступ к детальным взаимодействиям, которые двунаправленный кодировщик не может представить.

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

2. Градиент «стоимость-производительность», протестированный на тех же примерах.

В учебнике используется упрощенная модель градиента «стоимость-производительность»: слабые эмбеддинги внизу, сильные эмбеддинги посередине, кросс-энкодеры-реранжировщики вверху. Каждый шаг обходится дороже, и каждый шаг должен обеспечивать более точную оценку. Честный тест заключается в том, чтобы взять случаи, описанные в статье 2, и применить их ко всему градиенту: четыре модели эмбеддингов от GloVe-avg (2014) до text-embedding-3-large (2024), плюс три готовых кросс-энкодера-реранжировщика ( bge-base , bge-large , ms-marco-MiniLM-L-12-v2 ). Семь столбцов на рисунке. Читайте каждую строку горизонтально, и градиент либо сохраняется, либо нарушается, либо иногда инвертируется.

При просмотре каждого рисунка следует обратить внимание на три момента: – Перемещается ли первое место в строке TARGET слева направо (градиент сохраняется, чем больше модель, тем лучше)? Застревает ли TARGET на 2-3 местах во всех семи столбцах (ни один обученный оценщик не улавливает эту форму)? Или же меньшая, более дешевая модель оценивает TARGET выше, чем большие модели, переоценивающие его (градиент инвертируется)?

Все три варианта представлены ниже.

2.1 Ловушка буквального значения жетона (Статья 2, раздел 1.6)

Запрос hot dog , кандидаты: перефразированное описание еды (TARGET, ноль общих токенов), лексическая ловушка the dog basked in the hot sun » и несвязанная с этим подстава. В статье 2 ada-002 попал в ловушку; восстановлено было только text-embedding-3-large .

Результат на семиколоночной сетке поразителен: 3-large прежнему остается единственной моделью, которая переворачивает ловушку на #2 и поднимает перефразирование на #1. Ни один из трех реранжировщиков этого не делает. Добавление bge-large поверх ada-002 не дает того, что 3-large уже дает бесплатно на этапе встраивания. Если бюджет таков: «либо улучшить встраивание, либо добавить реранжировщик», то в данном случае доказывается, что следует улучшить встраивание.

2.2 Восстановление синонимов с помощью сложного лексического дистрактора (Статья 2, раздел 1.2)

Запрос is green card needed . Правильный ответ (« Permanent resident card is required for this process. ») не имеет общих токенов с запросом, но является строгим синонимом. Ловушка ( Green colored cards are popular in stationery stores. ») имеет ТРИ общих токена ( green , card , cards ) и семантически не связана. Это канонический тест «синоним против лексического пересечения».

В таблице наблюдается инверсия утверждения о соотношении затрат и производительности. MiniLM , ada-002 , 3-large и bge-base присваивают синониму TARGET первое место. Затем bge-large и ms-marco-MiniLM-L-12-v2 снова попадают в лексическую ловушку на первом месте, как будто более крупные модели, обученные на MS-MARCO, имеют более сильную лексическую предвзятость. Два из трех переранжировщиков активно ухудшают ситуацию по сравнению с bge-base . Команда, которая автоматически использует самый большой доступный переранжировщик для каждого запроса, теряет здесь позиции, которые она могла бы сохранить, используя более мелкий или вообще отказавшись от переранжировщика.

2.3 Тематическая близость против релевантности ответа (Статья 2, раздел 2.3)

Вопрос пользователя: «Кто подписал контракт?» Корпус содержит один фрагмент, описывающий порядок подписания контрактов (процедурный, насыщенный словами signed / signature / representative ), и один фрагмент, представляющий собой саму подпись ( Signed: John Smith, Marketing Director, dated 2025-03-15 ). В каждой модели встраивания в статье 2 процедурный фрагмент превосходил по значимости саму подпись. Это тот тип несоответствия вопросов и ответов, на котором обучаются кросс-кодировщики (MS-MARCO имеет примерно такую форму, повторяющуюся миллионы раз).

Сетка показывает то, чего не предсказывает учебник. MiniLM — единственная модель, будь то эмбеддинг или реранжёр, которая выводит фактическую строку подписи на первое место. Все остальные столбцы, включая три кросс-кодировщика реранжёров, специально обученных на парах такого типа, оставляют процедурный фрагмент на первом месте, а подпись — на втором. Эмбеддинг с 22 миллионами параметров превосходит шесть других слоёв в каноническом тесте реранжёров. Градиент «стоимость-производительность» здесь не просто выравнивается; он инвертируется.

2.4. Снижение интенсивности сигнала в длинном контексте (Статья 2, раздел 2.4)

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

Это единственная форма, где затраты на переранжирование оправдываются. bge-large , bge-base -saturated и ms-marco-MiniLM ставят короткий ответ на первое место, а абзац с скрытым ответом — на второе. Они возвращают скрытый ответ на второе место, тогда как ada-002 и MiniLM поставили его на третье или даже ниже. 3-large уже достигает этого на этапе встраивания. Таким образом, картина такова: при ослаблении сигнала либо платить за 3-large на этапе встраивания, либо использовать бесплатный переранжировщик поверх более дешевого встраивания. Оба пути работают. Это самый чистый случай в статье для кросс-кодировщикового слоя.

2.5 Вопрос «да/нет» (Статья 2, раздел 2.6)

В статье 2 рассматривается наиболее сложный случай: фактический ответ ( Yes, it is needed. ) на вопрос типа «да/нет» в сравнении с дословным копированием ключевых слов запроса ( Permanent resident card ) и более длинным набором ключевых слов. В каждой модели эмбеддинга дословное копирование ключевых слов превосходило ответ. Вся причина существования кросс-кодировщиков как слоя заключается в том, что они обучаются на парах «запрос-ответ», где ответ редко повторяет запрос.

В целом, таблица подтверждает: буквальное копирование Permanent resident card занимает первое место в каждом столбце. «ЦЕЛЬ» ( Yes, it is needed. ) занимает третье или четвертое место среди всех эмбеддингов и алгоритмов переранжирования BGE. Единственный столбец, который продвигает фактический ответ, — это ms-marco-MiniLM-L-12-v2 . Он ставит Yes, it is needed. на второе место, опережая A green card may be required. и ответ « No . Небольшая победа в случае «да/нет», который больше нигде не обрабатывается. Стоит отметить, что алгоритм переранжирования, обученный на MS-MARCO, обладает этим специфическим поведением; однако этого недостаточно, чтобы проектировать конвейер обработки данных.

При горизонтальном расположении столбцов градиент «стоимость-производительность» в основном плоский. В столбце 2.1 единственным победителем является 3-large (встраивание 2024 года, не требующее переранжирования). В столбце 2.3 единственным победителем является MiniLM (бесплатное встраивание с 22 миллионами параметров 2021 года). В столбце 2.2 два из трех переранжировщиков хуже, чем меньшие модели. Только в столбце 2.4 (разбавление сигнала) наблюдается явное преимущество переранжировщика. Использование бесплатного готового переранжировщика поверх более дешевого встраивания не дает надежного прироста по сравнению с заменой встраивания на более сильное; для некоторых форм это активно вредит.

Это соответствует закономерности, которую инженерные команды обнаружили на собственном горьком опыте: дополнительные средства лучше потратить на этап встраивания (или, как утверждается в остальной части серии, на архитектуру вышестоящего уровня: экспертные ключевые слова, классификация перед извлечением), чем на переранжировщик. Классическая воронка продаж продает «встраивания дешево, переранжировщики точнее» как четкую лестницу. На этих формах запросов такой лестницы нет. Раздел 3 — более сложная сторона: случаи, которые не меняются независимо от используемого оценщика.

3. Где кросс-кодировщик по-прежнему дает сбой

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

3.1 Отрицание, всё ещё невидимое

В статье 2 был проведен тест на отрицание для четырех моделей встраивания: запрос «Что НЕ является городом?», варианты Paris , New York , City , Table . Каждая модель поставила Table (единственный правильный ответ) на последнее место. Токен отрицания не нес никакого сигнала. Обнаруживает ли какой-либо кросс-кодировщик инверсию?

Кросс-кодировщики обучаются на парах (query, relevant_passage) из веб-поиска и MS-MARCO. Практически ни одна обучающая пара не имеет формы «релевантный фрагмент является дополнением к теме запроса». Модель научилась оценивать соответствие теме, и оператор NOT в запросе практически не меняет этого. Исправление происходит на этапе разбора вопроса: обнаружение отрицания, инвертирование поиска (статья 6).

3.2 Точные идентификаторы и внутренние аббревиатуры

Номера контрактных ссылок, внутренние коды продукции, аббревиатуры, существующие только внутри компании. Интуитивно понятно, что изученное сходство приведет к путанице между ZRX-2025-A и расположенным рядом ZRX-2024-B . Давайте посмотрим.

Рисунок служит полезным уроком как в разработке тестов, так и в поиске информации. При наличии всего трех кандидатов и дословного упоминания нужного контракта в тексте кандидата, все современные системы оценки правильно определяют неоднозначность. MiniLM , оба эмбеддинга OpenAI и все три системы переранжирования ставят ZRX-2025-A на первое место. Только GloVe допускает ошибки. Реальная проблема с идентификаторами возникает в больших масштабах : корпус с сотнями контрактов, окружающий текст которых следует шаблонному образцу ( Contract covers up to ), где идентификатор является единственным отличительным признаком. В этом случае сигнал буквального токена эмбеддинга становится крошечной долей косинуса, и близкие идентификаторы размываются. Определение неоднозначности идентификаторов в производственных масштабах должно осуществляться с помощью BM25 или индекса точного совпадения (статья 6, раздел 2.2 через concept_keywords_df ), а не на основе сходства. Приведенный здесь тест с тремя кандидатами лишь показывает, что векторные представления не игнорируют идентификаторы, когда поле небольшое.

3.3 Листинг, канонический режим отказа

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

Решение заключается в агрегации списков (статья 12), а не в переранжировании. Вопрос со списком обрабатывается как намерение list_all на этапе анализа вопроса и направляется в конвейер, который возвращает все соответствующие элементы, а не k лучших по оценке.

3.4 Словарь, выходящий за рамки предметной области

Каждая модель в сетке несет в себе индуктивную предвзятость своего обучающего корпуса. Эмбеддинги OpenAI и реранжеры BGE обучены на широких веб-данных/поисковых запросах; ms-marco-MiniLM-L-12-v2 на MS-MARCO. Специализированные словари (медицинские, юридические, финансовые, нормативные) находятся за пределами этих распределений. Тонкая настройка реранжереера на предметных данных исправляет большую часть этих проблем. Но тонкая настройка — это проект, а не бесплатное обновление. В стандартной комплектации ни один из оценщиков в сетке не соответствует термину «компания».

Универсальный провал по всем семи столбцам. TARGET занимает 3-е место в каждой модели; Contractors are paid on a per-project basis (поверхностное лексическое соответствие) занимает 1-е место. Ни самый большой вектор встраивания, ни самый большой переранжировщик не обеспечивают связь между contractor и non-employee labor . Именно эту проблему призван решить concept_keywords_df из данной серии. Эксперт подбирает сопоставление contractor → non-employee labor , overtime → beyond 40h/week , и на этапе поиска используются эти ключевые слова напрямую. Переранжировщику потребуется тонкая настройка на основе контрактов компании, чтобы изучить то же сопоставление, которое только что набрал эксперт.

4. Где затраты на переранжирование действительно оправданы.

Позиция сериала, изложенная прямо:

Кросс-кодировщиковые реранжировщики — это запасной вариант для узких случаев, а не основной этап корпоративного конвейера обработки данных. Они оправдывают свою стоимость, когда пул кандидатов велик (100 000 лучших из векторного хранилища), исходный поток представляет собой универсальный косинусный алгоритм, и нет времени на создание тщательно разработанного конвейера. Они мало что добавляют, когда исходный поток уже невелик, имеет уже определенную область применения и структурирован.

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

Анализ вопросов направляет запрос в определенный конвейер. Вопрос, содержащий список, проходит через агрегацию list_all (статья 12), а не через ранжированный поиск. Вопрос, содержащий фильтрацию, проходит через фильтры метаданных (статья 18), а не через оценку сходства. Вопрос с отрицанием обнаруживается и инвертируется во время анализа вопросов (статья 6). Таким образом, входными данными для переранжировщика является небольшой, уже определенный набор кандидатов, созданный структурно подходящим конвейером, а не набор из 100 лучших результатов из универсального векторного хранилища.

Метод «классификация перед извлечением» сужает круг кандидатов. В статье 15 описан этап классификации, который помечает каждый документ метаданными по теме, типу и дате. Во время запроса фильтры метаданных сокращают корпус кандидатов с 200 000 документов до, возможно, 800. Переранжировщик (если он вообще работает) работает с таким небольшим пулом, что эксперт в данной области может просмотреть его за пятнадцать минут. Больше нет необходимости управлять воронкой из 100 000 лучших документов.

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

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

Главный вывод для читателя: алгоритмы переранжирования полезны. Они действительно занимают своё место в литературе. Градиент стоимости/точности реален, а воронка — это инженерная реальность любой архитектуры поиска в производственной среде. В этой серии статей объясняется их назначение и используется там, где они оправдывают свою стоимость. Но архитектурные решения, которые защищает серия (экспертный словарь, поиск с учётом структуры, классификация перед поиском, специальные конвейеры для конкретных типов вопросов), загоняют алгоритм переранжирования в узкий угол, а не используют его по умолчанию. Статья 9 возвращается к комбинированию методов на уровне поиска; статьи 15-20 рассматривают случай масштаба корпуса.

5. Заключение

Вопрос о переранжировании — это лишь один из аспектов более широкой концепции: Enterprise Document Intelligence Volume 1 шаг за шагом выстраивает корпоративную систему переранжирования документов, при этом исходные элементы (анализ вопросов, классификация перед извлечением, ключевые слова экспертов) выполняют работу, которую обычно требуется от специалиста по переранжированию.

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

Семиколоночная сетка говорит об обратном. В четырех из пяти «ожидаемых выигрышей переранжировщика» из статьи 2 столбцы кросс-кодировщика либо соответствуют векторному представлению, либо показывают худшие результаты. Только signal dilution (скрытый ответ в длинном абзаце) является явным выигрышем переранжировщика. В ловушке буквального токена, в тесте канонического ответа против процедурного и в случае синонима против отвлекающего фактора сильное векторное представление ( text-embedding-3-large ) или даже небольшое бесплатное ( MiniLM ) часто превосходит стандартные переранжировщики. Отрицание, точные идентификаторы (при небольшом количестве кандидатов), внедоменная лексика, перечисление: ни один из этих факторов не меняется независимо от используемого оценщика.

Редакционная позиция серии сохраняется и подкрепляется данными: реранжировщики являются запасным вариантом для одной конкретной формы запроса (размывание сигнала в длинном контексте), а не основным этапом. На этапе встраивания данных дополнительные затраты обеспечивают больший прирост на этапе реранжирования, чем на этапе реранжирования для этих форм запросов. Архитектурные решения, делающие реранжировщики в основном избыточными (анализ вопросов, классификация перед поиском, экспертные ключевые слова, специальные конвейеры для конкретных намерений), — это то, что выстраивается в остальной части серии. Статья 3 рассматривает более широкий вопрос (RAG — это не машинное обучение). Статьи 6 и 7 закладывают основы. Статья 9 возвращается к комбинированию методов на уровне поиска. Статьи 15-20 рассматривают пример масштаба корпуса, где реранжировщики действительно могут оправдать свое место.

6. Дополнительная литература

• Ногейра и Чо, Переранжирование отрывков с помощью BERT, 2019 (arXiv:1901.04085). Эта основополагающая статья о кросс-кодировщиках для переранжирования описывает архитектуру, унаследованную семейством bge-reranker.
• Хаттаб и Захария, ColBERT: Эффективный и действенный поиск фрагментов текста с помощью контекстуализированного позднего взаимодействия на основе BERT, SIGIR 2020 (arXiv:2004.12832). Альтернатива позднего взаимодействия — сохраняет перекрестное внимание на уровне токенов, но с затратами, характерными для двухкодировщиков.
• Сяо и др., семейство C-Pack / BGE Reranker, 2023 (arXiv:2309.07597). Примечания к выпуску BAAI для алгоритмов переранжирования, использованных в этой статье ( bge-reranker-base , bge-reranker-large ).
• Прадип и др., RankZephyr: Эффективное и надежное ранжирование списков без предварительного обучения — это проще простого!, 2023 (arXiv:2312.02724). Альтернатива LLM в качестве алгоритма ранжирования; актуальна, когда стоимость моделей с граничными условиями еще больше снизится.

Анджела Ши. Все материалы от Анджелы Ши.

Источник: towardsdatascience.com