Reranking
reranking — повторная оценка и сортировка найденных кандидатов
Reranking — второй этап поиска, на котором уже найденные документы получают новые оценки и меняются местами. Первичный поиск собирает кандидатов, а более внимательный реранкер сопоставляет их с запросом. Так в контекст RAG чаще попадают материалы, которые точнее отвечают на вопрос.
Коротко
Reranking — это повторная сортировка результатов поиска. Сначала первичный поиск (retriever) находит подходящих кандидатов, затем реранкер внимательнее сопоставляет запрос с каждым из них и выстраивает новый порядок. Он не ищет документы заново и не может вернуть то, что первый этап пропустил.
Представим запрос: «Как снизить шум вентилятора ночью». Обычный поиск приносит материалы о моторах, температуре, питании и тихом режиме. Нужная карточка уже есть, но лежит не первой. Реранкер читает запрос вместе с каждой карточкой и поднимает материал о ночном режиме выше. В этом условном примере состав списка не изменился — изменился порядок. На реальных запросах эффект ещё нужно проверить.
Зачем нужен второй этап
При поиске по большой коллекции приходится выбирать, насколько подробно сравнивать документы с запросом. Тысячи или миллионы записей нужно просмотреть быстро, поэтому первый этап обычно использует сравнительно простой способ оценки:
- совпадение слов;
- близость векторов;
- сочетание лексического и семантического поиска;
- фильтры по метаданным.
Такой поиск помогает собрать кандидатов, но не всегда ставит наиболее полезный документ первым. Похожая формулировка или многозначное слово могут поднять выше текст, который лишь отдалённо относится к вопросу.
Реранкер получает гораздо меньшую пачку и может позволить себе более подробное сравнение. Поэтому типичная цепочка выглядит так:
запрос → первичный поиск → кандидаты → повторная оценка → новый порядок
В RAG после этого выбирают несколько верхних фрагментов и передают их языковой модели. Чем точнее контекст, тем меньше ей приходится угадывать, о каком документе шла речь.
Как реранкер оценивает документы
Один из распространённых вариантов — cross-encoder. Он получает запрос и документ одновременно. Механизм внимания видит слова обеих частей в общем контексте и возвращает оценку релевантности пары.
[запрос + документ] → модель → оценка релевантности
Векторный поиск с bi-encoder устроен иначе: запрос и документ кодируются независимо, а затем сравниваются их числовые представления — эмбеддинги.
запрос → вектор запроса
документ → вектор документа
сходство векторов → первичная оценка
Документы можно закодировать заранее, поэтому по их векторам удобно быстро искать в большой коллекции. Cross-encoder оценивает каждую пару «запрос + кандидат», хотя несколько пар можно обрабатывать одним пакетом. Совместное чтение текстов может улучшить оценку, но обычно требует больше вычислений, чем сравнение заранее рассчитанных векторов. Поэтому сначала быстро отбирают широкий набор кандидатов, затем подробно оценивают небольшую часть.
Cross-encoder — не синоним любого реранкера. Повторный порядок могут строить модели с поздним взаимодействием, обученные алгоритмы ранжирования, языковые модели или комбинации нескольких сигналов. Конкретная оценка тоже не обязана лежать между нулём и единицей: её шкала зависит от модели.
Что именно меняется после reranking
У каждого кандидата появляется новая оценка. Затем список сортируется по ней. Иногда этого достаточно; иногда поверх оценки действуют дополнительные правила:
- убрать почти одинаковые фрагменты;
- сохранить разнообразие источников;
- учесть актуальность версии документа;
- поднять материал нужного языка или типа.
Права доступа — не просто ещё один вес в этой сортировке. Закрытые для пользователя документы отсеивают до передачи текста внешнему реранкеру или генератору; их высокая релевантность не даёт права их раскрыть.
Остальные правила помогают собрать полезный финальный набор. Например, пять почти одинаковых абзацев из одной инструкции могут быть релевантны, но для ответа полезнее взять один из них и добавить независимые подтверждения из других разделов.
Главное ограничение
Реранкер работает только с кандидатами, которые уже лежат перед ним. Если нужного документа нет в первичной выборке, переставлять нечего.
Из этого следует простая диагностика. Сначала проверяют, попадает ли правильный материал хотя бы в достаточно широкий набор первичного поиска. Если нет, проблема находится раньше: в разбиении документов, индексировании, формулировке запроса, фильтрах или retriever. Если правильный материал находится, но остаётся слишком низко, тогда есть смысл разбираться с реранкером.
Сколько кандидатов передавать
Универсального числа нет. Маленькая пачка быстрее, но увеличивает риск, что нужный документ останется за её пределами. Большая даёт реранкеру больше вариантов, зато повышает задержку и стоимость.
Подходящий размер зависит от:
- качества первичного поиска;
- длины фрагментов;
- скорости модели;
- допустимой задержки;
- сложности запросов;
- числа документов, которые понадобятся следующему этапу.
Выбор обычно делают по собственному тестовому набору. Для простых запросов иногда хватает лёгкого маршрута без второго этапа, а неоднозначные можно отправлять на более тщательное ранжирование. Такая каскадная схема экономит вычисления, но требует отдельной проверки качества маршрутизации.
Длинные документы и разбиение на фрагменты
Реранкеру удобнее сравнивать запрос с содержательным фрагментом, а не с целой книгой или длинной инструкцией. Если текст обрезается до того, как модель увидит ответ, высокая точность архитектуры уже не поможет.
Поэтому в RAG сначала продумывают разбиение текста: границы разделов, размер перекрытия, заголовки и метаданные. После ранжирования соседние фрагменты можно объединить или вернуть вместе с родительским документом. Так модель получает не только удачное предложение, но и достаточный контекст вокруг него.
Как понять, что стало лучше
Одна красивая демонстрация мало что доказывает. Нужен набор реальных запросов с отмеченными релевантными документами. На нём полезно смотреть сразу на несколько уровней:
- Recall@K первичного поиска — какая доля всех отмеченных релевантных документов попала в первые K результатов;
- MRR — насколько высоко находится первый полезный результат; nDCG — насколько удачно расположен список с учётом разной степени полезности документов;
- качество финального ответа — использовала ли модель правильный контекст и сохранила ли ссылки на источники;
- задержка и стоимость — укладывается ли цепочка в требования продукта.
Результат стоит проверять отдельно на коротких и длинных запросах, разных языках и редких темах. Реранкер, обученный на одном типе данных, может уверенно ошибаться в другой предметной области.
Где reranking особенно полезен
Он хорошо проявляет себя там, где первичный поиск уже находит нужное, но путает близкие документы:
- ответы по технической документации;
- поиск по каталогу с похожими товарами;
- поддержка по базе знаний;
- подбор фрагментов для RAG;
- поиск по юридическим или научным коллекциям;
- объединение результатов из нескольких поисковых веток.
Reranking и Hybrid Search
Эти методы часто стоят рядом, но решают разные задачи. Hybrid Search собирает кандидатов из нескольких поисковых сигналов, например по словам и по смыслу. Reranking получает уже собранный список и уточняет его порядок.
Их можно соединить:
лексический поиск ─┐
├→ объединённые кандидаты → reranking → финальный список
семантический поиск┘
Но это не обязательная связка. Реранкер может работать после одного retriever, а гибридный поиск — обходиться без отдельного второго этапа. Вся последовательность от документа до ответа разобрана в гайде по RAG и AI-поиску.
В библиотеке референсов можно похожим образом сначала найти кандидатов, а затем подробнее оценить их соответствие сцене. Саму генерацию удобно отделить от отбора: в ComfyUI можно сохранить схему обработки изображений, а поиск и реранкер подключить отдельно. Такое подключение само по себе не учит текстовую модель ранжирования понимать изображения.
Reranking и LLM-as-a-Judge
Большая языковая модель тоже способна расставлять документы по релевантности. Она может объяснить выбор или учитывать сложную инструкцию, но обычно требует больше времени и вычислений. Специализированный реранкер решает более узкую задачу и нередко удобнее для постоянного потока запросов.
Встречаются и смешанные схемы: лёгкая модель сортирует основную пачку, а языковая разбирает несколько спорных кандидатов. Выбор зависит от качества на нужном языке, длины документов и допустимой задержки.
Частые ошибки
Реранкер пытаются поставить вместо поиска
Сравнить запрос с каждым документом большой коллекции можно лишь в небольших базах. На крупном корпусе сначала нужен способ быстро сократить пространство поиска.
Считают новую оценку вероятностью
Число на выходе модели может быть логитом или относительным баллом. Его не стоит автоматически читать как «вероятность правильности» без калибровки.
Не учитывают дубликаты
Если первые позиции занимают копии одного фрагмента, высокая релевантность не превращается в хороший контекст. После сортировки часто нужен контроль разнообразия.
Измеряют только качество ответа
Ошибка может возникнуть на поиске, повторной сортировке или генерации. Раздельные метрики показывают, где именно теряется нужный документ.
Доверяют чужому рейтингу моделей
Публичный бенчмарк полезен как отправная точка, но не заменяет проверку на языке, тематике и длине документов конкретного проекта.
Частые вопросы
Реранкинг всегда улучшает поиск?
Нет. Слабая или неподходящая предметной области модель способна испортить порядок. Бывает и так, что первичный поиск уже решает задачу достаточно хорошо, а второй этап лишь добавляет задержку.
Нужно ли заново строить индекс?
Обычно нет. Реранкер работает поверх результатов существующего поиска. Но изменение разбиения текста или первичного поиска может потребовать переиндексации независимо от него.
Можно ли ранжировать изображения и таблицы?
Да, если выбранная модель умеет работать с нужной модальностью или получает качественное текстовое представление объекта. Обычный текстовый cross-encoder сам по себе изображение не понимает.
Чем реранкинг отличается от повторного поиска?
Повторный поиск формирует новый запрос и может принести другие документы. Реранкинг сохраняет набор кандидатов и меняет их порядок.
Реранкер и реранкинг — одно и то же?
Реранкинг — процесс повторной сортировки. Реранкер — модель или алгоритм, который назначает новые оценки.
Главное
Reranking добавляет поиску внимательный второй взгляд. Быстрый этап приносит кандидатов, реранкер сопоставляет каждый из них с запросом и переставляет список. Такая схема особенно полезна в RAG, где несколько верхних фрагментов становятся контекстом для ответа.
При этом реранкер не чинит всё сразу: он не возвращает пропущенный документ, не заменяет хорошее разбиение текста и не гарантирует правильный ответ языковой модели. Его польза видна только на собственных данных — вместе с качеством первичного поиска, задержкой и результатом всей цепочки.
