Когда приложение RAG (Retrieval-Augmented Generation) выдает неверные ответы, несмотря на то что нужная информация содержится в ваших документах, причиной часто является этап извлечения (ретривала). Векторный поиск отлично справляется с нахождением фрагментов на нужную тему, но часто ошибается на близких по смыслу вариантах — например, извлекает лимит бакетов для тарифного плана Enterprise, когда пользователь спрашивает про план Growth. Переранжирование в RAG решает эту проблему, беря топ-30 кандидатов из вашего векторного поиска и передавая их в специальную кросс-энкодерную модель, которая заново оценивает каждый фрагмент напрямую относительно вопроса.
На бенчмарке из 274 вопросов стандартный векторный поиск с моделью google/gemini-embedding-2 помещал точный нужный фрагмент на первое место в 81% случаев. Добавление voyageai/rerank-3-lite для переранжирования топ-30 увеличило этот показатель до 97% примерно за $0.10 на 1000 запросов. Имейте в виду, что это тестировалось на небольшом синтетическом датасете, поэтому ваши реальные результаты будут зависеть от ваших документов, но приведенный ниже рабочий процесс поможет вам измерить собственный базовый уровень.
Почему RAG извлекает не те фрагменты?
Стандартный векторный поиск сталкивается с трудностями, потому что модели эмбеддингов сжимают целый фрагмент в один вектор до того, как увидят вопрос пользователя. Если фрагмент объемом 130 слов объясняет лимиты бакетов, конкретное название тарифного плана составляет лишь одно или два слова из всего этого блока. В результате векторы для планов Starter, Growth, Scale и Enterprise группируются очень близко друг к другу в векторном пространстве, и ретривер может легко поставить неправильный тариф на первое место.
Чтобы проверить точность поиска без опоры на субъективные оценки, мы создали контролируемый датасет для вымышленного хранилища под названием Fernbank. Корпус содержит 274 фрагмента, охватывающих документацию, коды ошибок, руководства по SDK, записи журнала изменений и «шум», включая нерешенные темы на форуме и тикеты техподдержки, созданные специально для того, чтобы запутать наивные ключевые слова и векторные совпадения. Мы сгенерировали каждый фрагмент из фиксированного набора фактов с помощью anthropic/claude-sonnet-5.5 и проверили его скриптом. Отдельная модель, openai/gpt-6.1-sol, написала вопросы. Поскольку каждый вопрос соответствует ровно одному правильному фрагменту, мы можем оценивать точность поиска без лишних сомнений.
В полном тестовом наборе вопрос звучал так: «Сколько бакетов я могу создать в одной учетной записи Fernbank на тарифе Growth?». Модель google/gemini-embedding-2 поставила фрагменты планов Starter, Enterprise и Scale на 1, 2 и 3 места. Нерешенная тема на форуме заняла четвертое место, а реальный ответ для плана Growth оказался на пятом. Если ваш RAG-пайплайн отправляет LLM только трех лучших кандидатов, модель даже не увидит нужный документ.
Реранкер решает эту проблему за счет использования архитектуры кросс-энкодера. Вместо того чтобы оценивать документы изолированно, он обрабатывает вопрос пользователя вместе с каждым фрагментом-кандидатом. Запуск кросс-энкодера для тысяч документов работает слишком медленно для запросов в реальном времени, поэтому векторный поиск служит быстрым ретривером, сужая круг поиска до короткого списка перед тем, как реранкер отсортирует его.
Как добавить реранкер в ваш RAG-пайплайн
Вам не нужно заменять существующий поиск по эмбеддингам. Оставьте его в качестве первого этапа извлечения, увеличьте количество возвращаемых кандидатов и добавьте вызов переранжирования перед передачей финальных результатов в LLM.
Извлеките 30 фрагментов с помощью эмбеддингов, переранжируйте их и отправьте топ-3 в LLM.
Следующий пример на Python использует наши API эмбеддингов и реранкинга. Он извлекает фрагменты-кандидаты с использованием косинусного сходства, переранжирует их с помощью voyageai/rerank-3-lite и возвращает три результата с наивысшим рангом.
Вам понадобится переменная окружения OPENROUTER_API_KEY, а также установленные библиотеки numpy и requests.
Python
Вывод
С этими короткими односложными фрагментами векторный поиск уже ставит правильный лимит плана Growth на первое место. Оценки косинусного сходства варьируются от 0.695 до 0.832, поэтому несколько кандидатов находятся относительно близко друг к другу. После переранжирования правильный фрагмент получает оценку релевантности 0.922. Нерешенная тема на форуме перемещается на второе место с оценкой 0.793, опережая запись тарифного плана Starter.
Второй результат иллюстрирует важное ограничение: релевантность не равна правильности. В теме на форуме задается тот же вопрос, поэтому реранкер считает ее релевантной, хотя ответа на вопрос она не дает. В этом упрощенном примере реранкер не исправляет первый результат, потому что он и так был правильным. В полном бенчмарке с фрагментами по 130 слов векторный поиск ставил неверный фрагмент на первое место для 19% вопросов, включая вопрос о плане Growth, и переранжирование с помощью voyageai/rerank-3-lite исправило большинство из них.
Практический урок заключается в том, чтобы отправлять в LLM несколько сильных кандидатов, а не полагаться на единственный результат. Вам также следует подумать об отсеве нерешенных обсуждений и другого контента, в котором упоминается вопрос, но нет его решения.
В коде есть еще два важных нюанса, которые стоит учесть:
- Во-первых, параметр input_type сообщает модели эмбеддингов, кодирует ли она поисковый запрос или документ. Некоторые модели обрабатывают эти входы по-разному, поэтому пропуск параметра может ухудшить поиск. В наших тестах его отсутствие снизило precision@1 для Gemini с 81.0% до 74.1%, а для voyageai/voyage-4-lite с 64.6% до 52.9%. См. справочник по API эмбеддингов, который принимает его как строку и определяет search_query и search_document в качестве возможных значений.
Во-первых, параметр input_type сообщает модели эмбеддингов, кодирует ли она поисковый запрос или документ. Некоторые модели обрабатывают эти входы по-разному, поэтому пропуск параметра может ухудшить поиск. В наших тестах его отсутствие снизило precision@1 для Gemini с 81.0% до 74.1%, а для voyageai/voyage-4-lite с 64.6% до 52.9%. См. справочник по API эмбеддингов, который принимает его как строку и определяет search_query и search_document в качестве возможных значений.
- Во-вторых, top_n управляет тем, сколько результатов возвращает реранкер, а не тем, сколько он оценивает. Модель по-прежнему оценивает каждого отправленного ей кандидата, поэтому количество кандидатов влияет как на стоимость, так и на задержку.
Во-вторых, top_n управляет тем, сколько результатов возвращает реранкер, а не тем, сколько он оценивает. Модель по-прежнему оценивает каждого отправленного ей кандидата, поэтому количество кандидатов влияет как на стоимость, так и на задержку.
Как узнать, что переранжирование помогло?
Реранкер может улучшить порядок результатов, необязательно улучшая ответы, которые получают ваши пользователи. Чтобы определить, стоит ли его добавлять, измерьте точность поиска до и после изменений, а затем оцените финальные ответы.
1. Начните с precision@1: процента вопросов, для которых первый извлеченный фрагмент содержит правильный ответ. Вам не нужен огромный набор для оценки, чтобы начать. Пятьдесят реальных вопросов из логов вашего приложения, каждый из которых размечен правильным фрагментом с ответом, могут дать вам первоначальный базовый уровень. Руководство по созданию золотого датасета оценки на основе продакшн-трафика объясняет, как его собрать. 2. Не полагайтесь только на recall@5: он измеряет, появляется ли правильный фрагмент где-либо в первой пятерке, независимо от его позиции. В нашем тесте Gemini показал recall@5 на уровне 98.2%, но precision@1 составила всего 81.0%. Нужная информация обычно присутствовала в результатах, но не всегда оказывалась наверху.
1. Начните с показателя precision@1: это процент вопросов, для которых первый извлеченный фрагмент содержит правильный ответ. Вам не нужен огромный набор данных для оценки, чтобы начать. Пятьдесят реальных вопросов из логов вашего приложения, каждый из которых помечен правильным фрагментом с ответом, могут дать вам начальную базу. Руководство по созданию золотого набора данных для оценки на основе производственного трафика объясняет, как его составить.
2. Не полагайтесь только на recall@5: он измеряет, появляется ли правильный фрагмент где-либо в первой пятерке, независимо от его позиции. В нашем тесте Gemini достиг 98.2% recall@5, но только 81.0% precision@1. Нужная информация обычно была где-то в результатах, но не всегда на первом месте.
Мы также протестировали влияние на итоговые ответы. Мы использовали anthropic/claude-haiku-5.5, чтобы ответить на все 274 вопроса, используя фрагменты, возвращенные каждой конфигурацией поиска, а затем сравнили ответы с известными фактами.
Наш запуск от 8 октября 2026 года включал 274 вопроса. Для переранжирования использовалась модель voyageai/rerank-3-lite.
Результаты показывают, что переранжирование помогло LLM отвечать на большее количество вопросов правильно, используя при этом меньше фрагментов. Большинство неверных ответов были связаны с отсутствием информации. В девяти из десяти случаев, когда правильный фрагмент не попадал в тройку лучших, модель отвечала, что предоставленные отрывки не содержат ответа. Другими словами, приложение сообщало пользователям, что не знает чего-то, на что могла бы ответить его собственная документация.
Переранжирование решило эту проблему, улучшив качество фрагментов, поступающих в модель. Это также позволило нам отправлять три фрагмента вместо пяти, сократив стоимость ответов LLM с $0.22 до $0.16 на 1000 вопросов. Вызов переранжирования добавил $0.10, поэтому в нашей настройке переранжирование стоило в чистом виде на $0.04 больше на 1000 вопросов.
Экономит ли вам деньги переранжирование, зависит от ваших моделей, размеров документов и объема запросов, поэтому измеряйте стоимость и точность по всему конвейеру, от поиска до итогового ответа.
Какая модель переранжирования лучше всего подходит для RAG?
Мы сравнили 11 моделей переранжирования, используя те же 30 кандидатов, извлеченных с помощью google/gemini-embedding-2 для каждого из 274 вопросов. Это дало нам последовательную основу для сравнения их точности, задержки и стоимости.
Модели переранжирования Voyage предложили наилучшее сочетание точности и цены среди протестированных нами специализированных моделей переранжирования.
Наш запуск 8 октября 2026 года. Расходы — это стоимость использования на один ответ, что соответствует GET /api/v1/generation. Около 0.9 секунды от каждой медианы — это сетевые накладные расходы с нашей тестовой машины.
На этом наборе данных voyageai/rerank-3 ставил правильный фрагмент на первое место в 97.8% случаев, в то время как версия Lite достигала 97.1%. Эта разница составляет всего два вопроса в нашем тесте из 274 вопросов, поэтому она слишком мала, чтобы утверждать, что более дорогая модель стабильно лучше. Начните с voyageai/rerank-3-lite и сравните ее с voyageai/rerank-3 на своем собственном наборе для оценки. Обе используют один и тот же эндпоинт /rerank, поэтому для переключения моделей нужно только изменить идентификатор модели.
Различия в цене в значительной степени отражают то, как поставщики выставляют счета, как указано на наших страницах моделей переранжирования. Voyage и Qwen взимают плату за токен (от $0.02 до $0.20 за миллион), в то время как Cohere взимает от $0.001 до $0.0025 за поиск до 100 документов, независимо от длины документа. Поскольку наши 30 кандидатов содержали около 5000 токенов Voyage, модели Voyage были особенно недорогими. На этих коротких фрагментах модели переранжирования Cohere стоили примерно в 4–25 раз дороже, чем варианты Voyage, в зависимости от сравниваемых моделей. Отправка 101 документа в Cohere также вызвала вторую плату за поиск в нашем тесте.
Переранжирование оказало особенно заметное влияние на вопросы о конкретных кодах ошибок, таких как FB-2411. Только поиск по эмбеддингам ставил правильную запись на первое место лишь в 25% случаев с voyageai/voyage-4-lite и в 53.6% с google/gemini-embedding-2. Все 11 моделей переранжирования достигли 100% на этом подмножестве. Поскольку записи с кодами ошибок, как правило, обсуждают похожие ошибки, их эмбеддинги могут выглядеть одинаково. Кросс-энкодер может сравнить точный код в вопросе с кодом в каждом кандидате и различить правильную запись.
Если вам интересно, какие модели разработчики используют чаще всего, наши рейтинги моделей переранжирования предоставляют еще одну полезную справку. По состоянию на 20 октября 2026 года voyageai/rerank-2.5 лидировала с 4.68 миллионами запросов за неделю до 18 октября, и она набрала 96.4% в нашем тесте. Популярность использования стоит учитывать, но она не должна заменять тестирование модели на ваших собственных документах. Производительность модели, цены и задержка поставщика могут меняться. Коллекция моделей переранжирования содержит доступные варианты и их текущие детали.
Сколько документов следует переранжировать?
Начните с переранжирования около 30 кандидатов, затем скорректируйте число на основе результатов вашей оценки.
Чтобы увидеть, как количество кандидатов влияет на производительность, мы протестировали voyageai/rerank-3-lite с разным количеством кандидатов, извлеченных с помощью voyageai/voyage-4-lite:
Наш запуск 8 октября 2026 года использовал 274 вопроса, voyageai/voyage-4-lite в качестве первого этапа.
Увеличение количества кандидатов с 10 до 30 улучшило precision@1 с 94.5% до 96.7%. Увеличение его еще до 50 довело точность до 97.1%, исправив еще только один вопрос, при этом увеличив стоимость переранжирования примерно на две трети. Переход от 50 к 100 кандидатам не улучшил точность.
У переранжирования есть ограничения, так как оно может продвинуть релевантный фрагмент только в том случае, если первый этап поиска включает его в набор кандидатов. Если векторный поиск полностью пропускает ответ, ни один переранжировщик не сможет его вернуть.
Для большей базы знаний используйте свой набор для оценки, чтобы найти точку, в которой извлечение большего количества кандидатов перестает существенно улучшать процент вопросов, для которых доступен правильный фрагмент. Это лучший способ выбрать количество кандидатов, чем предполагать, что 30 является оптимальным для каждого приложения.
Можно ли использовать LLM в качестве переранжировщиков?
В нашем бенчмарке переранжировщики на основе LLM были наиболее точными, хотя им требовалось больше времени для возврата результатов. Вместо того чтобы отправлять каждого кандидата через специализированную модель переранжирования, мы дали чат-модели вопрос и все 30 пронумерованных фрагментов, а затем попросили ее вернуть ID наиболее релевантных фрагментов по порядку. Мы использовали строгую схему структурированного вывода, чтобы гарантировать, что ответ соответствует ожидаемому формату.
Два подхода различаются ключевым образом. Специализированный переранжировщик оценивает каждого кандидата индивидуально по отношению к вопросу. LLM может прочитать всех кандидатов вместе и сравнить их, что помогает, когда несколько документов содержат похожую информацию.
В нашем тесте openai/gpt-6-luna достигла 99.6% precision@1 при цене $0.70 за 1000 запросов, что является нижней границей диапазона стоимости LLM, который достигал $4.14 для google/gemini-3.8-flash. Это более высокая точность, чем у специализированных переранжировщиков, но каждый вызов занимал около четырех секунд в нашей настройке, по сравнению с примерно 1.3 секунды для специализированной модели.
Это дополнительное время имеет значение в интерактивном приложении, где пользователь ждет ответа. Переранжирование с помощью LLM может лучше подойти для пакетной обработки или приложений, где получение правильной информации особенно важно, а дополнительная задержка приемлема.
Имейте в виду, что в нашем бенчмарке использовался чистый текст, сгенерированный моделью. Реальные базы знаний имеют несогласованное форматирование, неполные документы и другие сложности, поэтому мы не можем утверждать, что LLM-реранкеры сохранят те же преимущества на более «грязных» данных из реального мира.
Нужен ли вам по-прежнему реранкер при использовании гибридного поиска или более качественной модели эмбеддингов?
И гибридный поиск, и более качественные модели эмбеддингов могут улучшить поиск, но наш бенчмарк показывает, что ни то, ни другое не было столь эффективно, как добавление реранкера. Гибридный поиск объединяет векторное сходство с поиском по ключевым словам, часто с использованием BM25. Мы объединили результаты с помощью ранжирования на основе взаимного ранга (RRF), которое объединяет два списка ранжирования.
В нашем тестовом наборе гибридный поиск увеличил метрику precision@1 для voyageai/voyage-4-lite с 64,6% до 69,3%. Однако для google/gemini-embedding-2 значение precision@1 упало с 81,0% до 78,8%, несмотря на улучшение recall@5. Более мощная модель эмбеддингов превзошла более дешевую альтернативу. Gemini достигла 81,0% precision@1 по сравнению с 64,6% у Voyage 4 Lite. Но стоимость эмбеддингов Gemini составляла $0,20 за миллион токенов против $0,02 у Voyage 4 Lite. Комбинация более дешевой модели эмбеддингов с voyageai/rerank-3-lite позволила достичь 96,7% precision@1.
Гибридный поиск и лучшие эмбеддинги по-прежнему полезны, поскольку они выполняют разные задачи. Гибридный поиск помогает находить кандидатов, которых пропускает векторный поиск, а более сильная модель эмбеддингов улучшает первичное ранжирование. Реранкер добавляет еще один уровень, сравнивая каждого кандидата непосредственно с вопросом.
Для достижения наилучших результатов оценивайте эти варианты как по отдельности, так и вместе. Вы можете использовать наше сравнение моделей эмбеддингов, чтобы выбрать модель для первого этапа поиска.
Что нарушает работу реранкинга?
Реранкинг может давать сбои без выдачи ошибок, когда документ превышает лимит контекста модели. Например, cohere/rerank-v3.5 имеет ограничение контекста в 4096 токенов, поэтому модель может вообще не увидеть ту часть документа, которая содержит ответ.
Мы протестировали это с двумя документами объемом 11 000 токенов, которые отличались только последним предложением. Один из них содержал ответ, но оба получили одинаковую оценку релевантности: 0,2703. Модель фактически пропустила деталь, которая их различала. Для сравнения, voyageai/rerank-3-lite оценила документы в 0,7812 и 0,3242, правильно расположив документ с ответом выше. Модели Cohere 4, voyageai/rerank-3 и qwen/qwen3-reranker-8b также поставили правильный документ выше. Проверьте лимит контекста вашего реранкера и следите за тем, чтобы чанки комфортно в него укладывались.
Другая проблема — совместимость моделей, поскольку эндпоинт /rerank принимает только модели реранкинга. Отправка туда чат-модели openai/gpt-6-luna возвращает ошибку 400 Model openai/gpt-6-luna does not exist, ту же самую ошибку, которая возникает при опечатке в идентификаторе модели. Перед выполнением запроса убедитесь, что модель присутствует в коллекции моделей реранкинга.
Следующие шаги
- Выполните реранкинг топ-30 с помощью voyageai/rerank-3-lite, затем проведите измерения.
Выполните реранкинг топ-30 с помощью voyageai/rerank-3-lite, затем проведите измерения.
- Справочник по API реранкинга: каждое поле запроса, включая маршрутизацию провайдеров.
Справочник по API реранкинга: каждое поле запроса, включая маршрутизацию провайдеров.
- RAG с эмбеддингами и реранкингом: полный пайплайн вплоть до генерации ответа.
RAG с эмбеддингами и реранкингом: полный пайплайн вплоть до генерации ответа.
- Как проводить бенчмаркинг LLM: сравнение моделей на собственных данных.
Как проводить бенчмаркинг LLM: сравнение моделей на собственных данных.
Часто задаваемые вопросы
Что такое реранкинг в RAG?
Реранкинг в RAG — это второй этап поиска, на котором модель реранкинга оценивает каждый чанк, возвращенный векторным поиском, относительно вопроса и переупорядочивает их так, чтобы несколько наиболее релевантных попали к LLM. Модель реранкинга читает вопрос и чанк вместе, что позволяет ей улавливать близкие к правильным варианты (например, правильный лимит для неправильного плана). В нашем тесте с 274 вопросами это увеличило показатель попадания правильного чанка на первое место с 81% до 97%.
Какие модели реранкинга лучше всего подходят для RAG?
В нашем тесте за октябрь 2026 года voyageai/rerank-3 и voyageai/rerank-3-lite оказались самыми точными специализированными моделями реранкинга и самыми дешевыми реранкерами: правильный чанк оказался на первом месте для 97,8% и 97,1% из 274 вопросов соответственно. LLM-реранкеры набрали больше баллов, но тратили около 4 секунд на один вызов.
Сколько документов следует подвергать реранкингу?
Выполняйте реранкинг примерно для 30 кандидатов, а для большей базы знаний увеличивайте это число до тех пор, пока правильный чанк не начнет стабильно появляться. В нашем тесте переход от 30 до 50 увеличил precision@1 с 96,7% до 97,1% (прирост на один вопрос, находящийся в пределах погрешности) и увеличил стоимость реранкинга на две трети.
Ссылки
- Справочник по API реранкинга и справочник по API эмбеддингов
Справочник по API реранкинга и справочник по API эмбеддингов
- Модели реранкинга и рейтинги реранкинга
Модели реранкинга и рейтинги реранкинга
- Структурированные выводы
Структурированные выводы
