Реранкер (rerank) в RAG — это вторая модель поиска, которая получает уже найденные фрагменты вместе с вопросом и заново расставляет их по релевантности. Он не находит новые документы, а только уточняет порядок кандидатов из первого этапа. Свежий открытый тест на базе из 64 заметок показал, что обычный семантический поиск уже ставил нужную заметку первой в 23 случаях из 24, а реранкер исправил первый результат лишь один раз. Реранкер окупается там, где первый этап находит много похожих кандидатов и их порядок решает, какой контекст попадёт в ответ модели, — и это нужно проверять на своей базе, а не включать по умолчанию.
Материал подготовлен AIrassvet 14 октября 2026 года по статье на Хабре «Я добавил Rerank в Obsidian. Что показали тесты на 64 и 500 заметках» (13 октября 2026 года) и документации Sentence Transformers и Cohere. Он адресован руководителям проектов, ИТ-директорам и командам, которые строят корпоративный поиск, базу знаний или RAG-ассистента и решают, добавлять ли этап переранжирования. Мы не повторяли эксперимент сами: цифры принадлежат автору исходной статьи и относятся к его тестовым хранилищам. Статья не сравнивает поставщиков реранкеров и не охватывает настройку векторных баз. AIrassvet не аффилирован с автором теста и разработчиками упомянутых моделей; раздел в конце статьи описывает услуги издателя.
Содержание
- Кратко
- Что такое реранкер и как работает двухэтапный поиск
- Как измеряют качество поиска: nDCG, Hit@1 и MRR
- Что показал тест на 64 заметках
- Сколько стоит и какую задержку добавляет реранкер
- Тест на 500 заметках: документ или фрагмент
- Когда реранкер нужен, а когда нет
- Как проверить реранкер на своей базе знаний
- Приватность: что уходит внешнему провайдеру
- Автоматически или по кнопке
- Частые вопросы
- Первоисточники и метод проверки
Кратко
- Реранкер уточняет порядок, но не ищет заново. Если первый этап не нашёл нужный документ среди кандидатов, реранкер его не вернёт.
- На небольшой базе выигрыш мал. В тесте на 64 заметках nDCG@10 выросла с 0,94235 до 0,97502, но в шести из одиннадцати «улучшений» сдвинулись только слабые вспомогательные материалы.
- Иногда становится хуже. В двух запросах из 24 полезная заметка опустилась ниже, хотя первый результат остался правильным.
- Деньги — не главное ограничение, задержка — главное. Одно уточнение стоило в среднем около $0,00008, но добавляло около полусекунды по медиане и до 4 секунд в худшем случае.
- Метрика может не увидеть пользу. На 500 заметках документные метрики не изменились, а число фрагментов с полным ответом в первой десятке выросло с 29 до 39–40 из 40 в зависимости от модели.
- Решение автора теста: реранкер выключен по умолчанию и запускается кнопкой «Уточнить результаты».
Что такое реранкер и как работает двухэтапный поиск
Семантический поиск — это поиск по смыслу, а не по совпадению слов. Документы режут на фрагменты (чанки), каждый фрагмент превращают в числовой вектор — эмбеддинг, — а при запросе ищут фрагменты с ближайшими векторами. Так находится заметка «возобновление задачи с контрольной точки» по запросу «как продолжить обработку после сбоя».
Bi-encoder — модель, которая кодирует вопрос и документ по отдельности. Это быстро и подходит для коллекций из миллионов записей, но, как сказано в документации Sentence Transformers, такой поиск может возвращать нерелевантных кандидатов (Sentence Transformers, Retrieve & Re-Rank).
Cross-encoder — модель, которая получает вопрос и документ одновременно и выдаёт одну оценку релевантности. Она точнее, потому что сравнивает тексты в контексте друг друга, но оценивать так тысячи или миллионы пар слишком медленно. Поэтому сначала быстрый поиск отбирает, например, 100 кандидатов, а затем cross-encoder их переранжирует.
Реранкер — это и есть второй этап: модель, которая упорядочивает найденные документы от наиболее к наименее релевантным запросу (Cohere, Rerank Overview). Конкретная архитектура зависит от модели, но задача одна — уточнить порядок уже найденных кандидатов.
| Первый этап: эмбеддинги | Второй этап: реранкер | |
|---|---|---|
| Что делает | Находит кандидатов, близких по смыслу | Переставляет кандидатов по релевантности |
| Как сравнивает | Вектор вопроса и векторы документов вычислены независимо | Вопрос и документ подаются модели вместе |
| Скорость | Подходит для всей базы | Подходит только для десятков-сотен кандидатов |
| Может найти пропущенное? | Да, это его задача | Нет — работает только с тем, что нашёл первый этап |
| Что получает провайдер | Тексты при построении индекса и вопрос при поиске | Читаемые фрагменты при каждом уточнении |
Где реранкер стоит в общей архитектуре корпоративного ИИ-поиска, мы разбирали в статье о RAG-системе для бизнеса.
Как измеряют качество поиска: nDCG, Hit@1 и MRR
Чтобы сравнивать поиск «до» и «после», нужна разметка: для каждого вопроса заранее решают, какие документы полезны. Автор теста использовал шкалу от 0 до 3: 0 — документ не относится к вопросу, 1 — слабая связь, 2 — полезный, но неполный ответ, 3 — прямой и полный ответ.
- Hit@1 показывает, оказался ли на первом месте релевантный документ.
- MRR@10 усредняет обратную позицию первого релевантного документа: первое место даёт 1, второе — 0,5, третье — примерно 0,33, отсутствие в первой десятке — 0.
- nDCG@10 (Normalized Discounted Cumulative Gain) учитывает сразу и релевантность каждого документа, и его позицию в первой десятке: чем ниже полезный документ, тем меньше его вклад. Значение от 0 до 1, где 1 — идеальный порядок по разметке.
Важная оговорка: если всем документам выставить одинаковую оценку, любая перестановка сохранит идеальную метрику. Это ровно то, что случилось во втором эксперименте автора, о нём ниже.
Что показал тест на 64 заметках
Автор разрабатывает открытый плагин Veynrel для Obsidian с семантическим поиском и проверял, стоит ли запускать реранкер автоматически (Хабр, 13.10.2026). Для теста он собрал синтетическое хранилище, в котором первому этапу должно быть трудно: 64 заметки, 80 фрагментов, близкие темы с разной полезностью. Вопросов — 28: для 24 в корпусе был ответ, ещё четыре составлены так, чтобы ответа не было. Положительные вопросы разделены на шесть групп: перефразирование, отрицания, похожие операции, разные языки, несколько источников и длинные заметки.
Первый этап — эмбеддинги text-embedding-3-small, до 30 кандидатов на вопрос; второй — Voyage Rerank 3 Lite через OpenRouter. Модель не получала правильных ответов, а документы не добавлялись вручную.
| Метрика (24 вопроса с ответом) | Только эмбеддинги | После реранкера |
|---|---|---|
| Релевантный документ на первом месте | 23 из 24 | 24 из 24 |
| Релевантный документ в первой тройке | 24 из 24 | 24 из 24 |
| MRR@10 | 0,97917 | 1,00000 |
| nDCG@10 | 0,94235 | 0,97502 |
По nDCG@10 получилось 11 улучшений, 11 случаев без изменений и 2 ухудшения; средняя оценка выросла примерно на 0,0327. Но автор посмотрел, какие документы сдвинулись:
- В шести из одиннадцати улучшений изменились позиции только слабых материалов с оценкой 1, а полезные документы остались на месте.
- В пяти случаях поднялись релевантные заметки, и лишь однажды реранкер исправил первый результат — поднял нужную заметку со второго места на первое.
Где реранкер помог. Вопрос — как продолжить прерванную конвертацию данных, не повторяя завершённые операции. В базе были две близкие заметки: о плановой остановке сервиса и о контрольных точках после аварийного завершения. Первый этап поставил первой плановую остановку, реранкер — заметку о контрольных точках. nDCG@10 для этого вопроса выросла с 0,5788 до 0,9640.
Где стало хуже. В вопросе об упражнениях для активной речи главный ответ остался первым, но полезная заметка о комплексной практике опустилась с четвёртого места на восьмое; nDCG@10 снизилась с 0,9149 до 0,8872. Вторая регрессия — в вопросе о проверке восстановления из бэкапа. Автор проверил, что нужный текст попадал в запросы к модели, так что дело не в потере данных.
Ещё два наблюдения. На четырёх многоязычных запросах метрика не изменилась, а один из них выполнялся больше четырёх секунд. На вопросах без ответа реранкер всё равно возвращал упорядоченный список: высокий балл реранкера сам по себе не доказывает, что ответ в базе есть.
Сколько стоит и какую задержку добавляет реранкер
Сначала автор сравнил три модели на четырёх простых вопросах — все поставили нужный документ первым (Хабр, 13.10.2026):
| Модель | Правильный первый результат | Средняя задержка | Стоимость 4 запросов |
|---|---|---|---|
| Cohere Rerank 3.5 | 4 из 4 | 490 мс | $0,004 |
| Voyage Rerank 3 Lite | 4 из 4 | 521 мс | $0,0000102 |
| Qwen3 Reranker 8B | 4 из 4 | 662 мс | $0,0002844 |
На этой выборке Voyage оказалась примерно в 392 раза дешевле Cohere, но у моделей разные схемы тарификации, и на других объёмах соотношение может отличаться.
В основном тесте на 64 заметках 28 вызовов реранкера стоили $0,00223506, а весь прогон вместе с эмбеддингами — $0,00243830; одно уточнение — в среднем около $0,00008. Это примерно в 31 раз дороже, чем в коротком тесте: на уточнение уходило до 30 кандидатов, и стоимость растёт с их числом и длиной.
| Задержка реранкера (тест на 64 заметках) | Время |
|---|---|
| Средняя | 675 мс |
| Медиана | 516 мс |
| 95-й перцентиль | 1042 мс |
| Самый долгий запрос | 4020 мс |
Вывод автора: деньги оказались наименее заметным ограничением, а задержка — самым заметным. Если человек сам нажал кнопку, полсекунды терпимы; ждать вторую модель при каждом поиске быстро надоедает. Для RAG-ассистента, где после поиска ещё генерируется ответ, эта задержка добавляется к общему времени ответа.
Тест на 500 заметках: документ или фрагмент
Третий прогон автор провёл на демонстрационном хранилище из 500 заметок (1600 фрагментов) — методика и агрегированные результаты опубликованы вместе со статьёй (Хабр, 13.10.2026). Хранилище оказалось шаблонным: названия технологий и общие описания без конкретных ответов. В итоге осталось всего 4 содержательных вопроса и 20 диагностических без ответа. Разметку 12 000 пар «вопрос — документ» сделал ИИ-агент, а проверил второй агент без доступа к результатам моделей; независимой проверки людьми не было.
На уровне документов все 500 заметок получили оценку «полный ответ» на все четыре вопроса, поэтому Hit@1, MRR@10 и nDCG@10 были равны 1 и до реранкера, и после. Но плагин отправляет реранкеру только один фрагмент на заметку, а ответ мог лежать в другом разделе. Когда отдельно оценили сами фрагменты, картина изменилась:
| Фрагментов с полным ответом в первой десятке (4 вопроса, всего 40 позиций) | Результат |
|---|---|
| Исходный поиск | 29 из 40 |
| Voyage Rerank 3 Lite | 40 из 40 |
| Cohere Rerank 3.5 | 39 из 40 |
| Qwen3 Reranker 8B | 40 из 40 |
Изменение затронуло два вопроса из четырёх. Реранкер поднимал выше кандидатов, у которых уже выбранный фрагмент содержал ответ. Для RAG это важное наблюдение: в окно модели попадают фрагменты, а не документы, поэтому качество поиска стоит мерить и на уровне фрагментов. Документная метрика может показать «без изменений» там, где контекст для генерации стал лучше. Сам автор подчёркивает, что выводов о больших технических базах из этого прогона не делает: содержательных вопросов было мало.
Когда реранкер нужен, а когда нет
Ниже — таблица решений редакции AIrassvet по выводам теста и описанию двухэтапного поиска в документации. Это ориентиры для проверки, а не измеренные пороги.
| Ситуация | Реранкер скорее нужен? | Почему |
|---|---|---|
| Сотни разнородных документов, конкретные вопросы | Скорее нет | Первый этап часто уже ставит нужный документ первым |
| Тысячи похожих документов: регламенты, инструкции, решения инцидентов с одинаковой лексикой | Скорее да | Первому этапу нужно найти группу кандидатов, второму — различить их |
| Одна тема раскрыта в нескольких документах разной полноты | Скорее да | Порядок решает, увидит ли пользователь сначала пример или определение |
| RAG с ограниченным окном контекста | Проверить обязательно | Порядок фрагментов определяет, какой контекст попадёт к модели |
| Первый этап часто вообще не находит нужный документ | Нет, сначала чинить первый этап | Реранкер не восстановит пропущенное: улучшайте чанкинг, гибридный поиск, метаданные |
| Строгое требование к задержке ответа | Только с замером | Медиана около 0,5 с, хвост до секунд |
| Данные нельзя отправлять внешнему провайдеру | Только локальная модель | Облачный реранкер получает читаемый текст при каждом уточнении |
Если в вашей базе много точных идентификаторов — артикулов, номеров договоров, кодов ошибок, — сначала проверьте гибридный поиск по словам и смыслу; пример такого подхода разобран в статье об умном поиске для интернет-магазина.
Как проверить реранкер на своей базе знаний
Методика ниже повторяет логику теста из статьи на Хабре и подходит для корпоративной базы. Это план редакции, а не результат нашего внедрения.
- Соберите вопросы из реальной работы. Возьмите настоящие запросы сотрудников или клиентов, включая перефразирования, отрицания («без отправки в облако»), похожие операции, разные языки и вопросы, на которые в базе ответа нет.
- Разметьте релевантность заранее. Шкала 0–3 для документов и отдельно — содержит ли выбранный фрагмент полный ответ. Разметку лучше делать до запуска моделей и проверять выборочно людьми.
- Зафиксируйте пул кандидатов. Сохраните кандидатов первого этапа (например, 30) и передавайте реранкеру ровно их, чтобы сравнение было честным.
- Считайте несколько метрик. Hit@1, MRR@10, nDCG@10 на уровне документов и долю фрагментов с полным ответом в первой десятке.
- Разберите каждое изменение глазами. Сколько улучшений касаются только слабых материалов, сколько раз исправлен первый результат, где стало хуже.
- Замерьте цену и задержку. Медиана, 95-й перцентиль, самый долгий запрос, стоимость по биллингу на одно уточнение.
Шаблон итогового отчёта, который стоит заполнить перед решением:
| Показатель | Без реранкера | С реранкером | Решение |
|---|---|---|---|
| Hit@1 | |||
| nDCG@10 | |||
| Фрагментов с полным ответом в топ-10 | |||
| Исправлено первых результатов / ухудшений | |||
| Медиана и p95 задержки | |||
| Стоимость одного уточнения |
Если вы выбираете между несколькими реранкерами или эмбеддинг-моделями, тот же набор вопросов работает как ваш собственный бенчмарк; почему публичных рейтингов для такого выбора недостаточно, мы разбирали в статье о своём бенчмарке для выбора LLM. Как отдельно оценивать поиск, ответы и галлюцинации RAG, — в статье о точности RAG.
Приватность: что уходит внешнему провайдеру
Реранкеру нужен читаемый текст фрагментов. При облачной модели выбранные фрагменты отправляются провайдеру при каждом уточнении — в дополнение к текстам, которые уходили при построении индекса, если эмбеддинги тоже облачные.
Автор теста нашёл неочевидную утечку (Хабр, 13.10.2026): модуль разбиения заметок подставлял имя файла как запасной заголовок, и это имя попадало прямо в тело запроса к провайдеру, хотя поля с путями из запроса были убраны. Исправление потребовало отдельного представления фрагмента для отправки наружу.
Практические выводы для корпоративной базы:
- проверяйте содержимое исходящих HTTP-запросов, а не только список полей;
- учитывайте, что служебные данные — имена файлов, пути, метаданные — могут попасть в текст фрагмента;
- если в документах есть персональные или коммерческие данные, рассмотрите локальный реранкер или модель в российском контуре.
Автоматически или по кнопке
У автора теста не было данных, которые позволили бы заранее понять, на каком запросе второй этап поможет. Поэтому в версии плагина 2.1.0 он выбрал ручной режим (Хабр, 13.10.2026): пользователь получает обычные результаты и, если они кажутся неточными, нажимает «Уточнить результаты». Плагин хранит до 30 кандидатов первого этапа, показывает 10 и при уточнении не повторяет поиск. Автоматический режим сохранён в настройках.
Для корпоративной системы есть три варианта:
| Режим | Когда подходит | Риск |
|---|---|---|
| Всегда включён | Тест на ваших данных показал устойчивый выигрыш, а задержка приемлема | Платите задержкой за каждый запрос, даже когда пользы нет |
| По кнопке | Сценарий поиска, где человек сам просматривает результаты | Пользователь может не заметить кнопку |
| По правилу | Включается для определённых типов запросов или разделов базы | Правило нужно обосновать замером, иначе это догадка |
Частые вопросы
Что такое реранкер в RAG?
Это вторая модель поиска, которая получает найденные фрагменты вместе с вопросом и заново расставляет их по релевантности. Она не ищет новые документы, а уточняет порядок кандидатов, которые нашёл первый этап.
Чем cross-encoder отличается от обычных эмбеддингов?
Эмбеддинги кодируют вопрос и документ по отдельности и сравнивают векторы — это быстро. Cross-encoder получает вопрос и документ вместе и оценивает их в контексте друг друга — это точнее, но слишком медленно для всей базы, поэтому его применяют к десяткам-сотням кандидатов.
Всегда ли реранкер улучшает поиск?
Нет. В открытом тесте на 64 заметках он исправил первый результат один раз из 24, а в двух запросах ухудшил порядок следующих документов. Польза зависит от того, сколько в базе похожих документов и как хорошо работает первый этап.
Сколько стоит реранкер?
В тесте на Хабре одно уточнение через Voyage Rerank 3 Lite стоило в среднем около $0,00008 при 30 кандидатах. Стоимость растёт с числом и длиной кандидатов и зависит от тарифа модели, поэтому её стоит измерить на своих данных.
Может ли реранкер найти документ, которого нет в выдаче?
Нет. Он работает только с кандидатами первого этапа. Если нужный документ не попал в пул кандидатов, нужно улучшать первый этап: чанкинг, эмбеддинги, гибридный поиск или метаданные.
Как понять, нужен ли реранкер нашей базе знаний?
Проверить на своих вопросах: сравнить поиск с реранкером и без него по Hit@1, nDCG@10 и доле фрагментов с полным ответом, разобрать каждое изменение и замерить задержку и цену. Включать его стоит, если выигрыш устойчив, а задержка приемлема для сценария.
Первоисточники и метод проверки
Метод: мы прочитали исходную статью целиком 14 октября 2026 года, выписали все метрики, цены и задержки вместе с оговорками автора и сверили описание двухэтапного поиска с документацией. Собственного теста реранкеров AIrassvet не проводил; таблица решений и план проверки — методика редакции.
- Хабр, 13.10.2026: «Я добавил Rerank в Obsidian. Что показали тесты на 64 и 500 заметках» — постановка тестов, метрики, цены, задержки, приватность, решение о ручном режиме.
- Sentence Transformers: Retrieve & Re-Rank — bi-encoder и cross-encoder в двухэтапном поиске.
- Cohere: Rerank Overview — назначение реранкера.
Ограничения: все тесты автора проведены на синтетических или шаблонных хранилищах заметок, а не на корпоративной базе; разметка 500 заметок сделана ИИ-агентами без проверки людьми; цены и тарифы провайдеров меняются.
Как AIrassvet помогает настроить поиск в RAG-системе
Если ваш ИИ-ассистент отвечает по внутренним документам, качество ответа начинается с того, какие фрагменты он находит. Решение о реранкере стоит принимать по замеру, а не по умолчанию. На сайте AIrassvet описаны направления, которые относятся к этой задаче напрямую:
- RAG-системы и корпоративные базы знаний: разбиение документов, первый этап поиска и проверка переранжирования на ваших вопросах.
- Развёртывание и дообучение языковых моделей на серверах заказчика — если фрагменты документов нельзя отправлять внешнему провайдеру.
- Аудит процессов, подготовка данных и разметка вопросов для оценки поиска.
- Разработка MVP, интеграция и тестирование до запуска на всю базу.
Первый шаг — выбрать один раздел базы знаний и одну группу пользователей, собрать их реальные вопросы, описать источники документов и ограничения по их передаче и договориться о критерии: какая доля правильных первых результатов и какая задержка будут для вас достаточными.
Итог: сначала замер, потом второй этап
Реранкер — полезный инструмент, но не обязательный слой каждой RAG-системы. Открытый тест показал: на небольшой базе с хорошим первым этапом он почти не меняет первый результат, иногда ухудшает следующие позиции и добавляет около полусекунды задержки. Зато там, где много похожих документов и важен порядок фрагментов для генерации, второй этап может поднять наверх фрагменты с полным ответом.
Поэтому решение принимают по данным: свои вопросы, разметка, метрики на уровне документов и фрагментов, замер цены и задержки. Если выигрыш устойчив — включайте реранкер для нужных сценариев; если нет — улучшайте первый этап поиска.
