Reranking

Reranking — второй этап поиска, на котором уже найденные документы получают новые оценки и меняются местами. Быстрый retriever собирает кандидатов, а более внимательный реранкер сопоставляет их с запросом. Так в контекст RAG чаще попадают материалы, которые точнее отвечают на вопрос.

Коротко

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

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

Зачем нужен второй этап

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

• совпадение слов;
• близость векторов;
• сочетание лексического и семантического поиска;
• фильтры по метаданным.

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

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

запрос → первичный поиск → кандидаты → повторная оценка → новый порядок

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

Как реранкер оценивает документы

Один из распространённых вариантов — cross-encoder. Он получает запрос и документ одновременно. Механизм внимания видит слова обеих частей в общем контексте и возвращает оценку релевантности пары.

[запрос + документ] → модель → оценка релевантности

Embedding-модель, которую часто называют bi-encoder, работает иначе:

запрос → вектор запроса
документ → вектор документа
сходство векторов → первичная оценка

Документы можно закодировать заранее, поэтому по их векторам удобно быстро искать в большой коллекции. Cross-encoder приходится запускать отдельно для каждой пары «запрос + кандидат». Он внимательнее сравнивает текст, но обходится дороже. Отсюда и разделение труда: широкий быстрый поиск сначала, подробная оценка небольшой пачки потом.

Cross-encoder — не синоним любого реранкера. Повторный порядок могут строить модели с поздним взаимодействием, обученные алгоритмы ранжирования, языковые модели или комбинации нескольких сигналов. Конкретная оценка тоже не обязана лежать между нулём и единицей: её шкала зависит от модели.

Что именно меняется после reranking

У каждого кандидата появляется новая оценка. Затем список сортируется по ней. Иногда этого достаточно; иногда поверх оценки действуют дополнительные правила:

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

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

Главное ограничение

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

Из этого следует простая диагностика. Сначала проверяют, попадает ли правильный материал хотя бы в достаточно широкий набор первичного поиска. Если нет, проблема находится раньше: в разбиении документов, индексировании, формулировке запроса, фильтрах или retriever. Если правильный материал находится, но остаётся слишком низко, тогда есть смысл разбираться с реранкером.

Сколько кандидатов передавать

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

Подходящий размер зависит от:

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

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

Длинные документы и разбиение на фрагменты

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

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

Как понять, что стало лучше

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

• recall первичного поиска — оказался ли нужный материал среди кандидатов;
• MRR или nDCG — насколько высоко реранкер поднял полезные результаты;
• качество финального ответа — использовала ли модель правильный контекст и сохранила ли ссылки на источники;
• задержку и стоимость — укладывается ли цепочка в требования продукта.

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

Где reranking особенно полезен

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

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

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

Reranking и Hybrid Search

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

Их можно соединить:

лексический поиск ─┐
                   ├→ объединённые кандидаты → reranking → финальный список
семантический поиск┘

Но это не обязательная связка. Реранкер может работать после одного retriever, а гибридный поиск — обходиться без отдельного второго этапа.

Reranking и LLM-as-a-Judge

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

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

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

Реранкер пытаются поставить вместо поиска

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

Считают новую оценку вероятностью

Число на выходе модели может быть логитом или относительным баллом. Его не стоит автоматически читать как «вероятность правильности» без калибровки.

Не учитывают дубликаты

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

Измеряют только качество ответа

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

Доверяют чужому рейтингу моделей

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

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

Реранкинг всегда улучшает поиск?

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

Нужно ли заново строить индекс?

Обычно нет. Реранкер работает поверх результатов существующего поиска. Но изменение chunking или retriever может потребовать переиндексации независимо от него.

Можно ли ранжировать изображения и таблицы?

Да, если выбранная модель умеет работать с нужной модальностью или получает качественное текстовое представление объекта. Обычный текстовый cross-encoder сам по себе изображение не понимает.

Чем реранкинг отличается от повторного поиска?

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

Реранкер и реранкинг — одно и то же?

Реранкинг — процесс повторной сортировки. Реранкер — модель или алгоритм, который назначает новые оценки.

Главное

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

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