В этом материале
Логит релевантности не становится вероятностью автоматически, а полезное ранжирование само по себе не подтверждает порог отклонения.
Оценки Nemotron 3.5 Rerank нужно трактовать по контракту выхода checkpoint до выбора порога отклонения. Ранжирование кандидатов и решение, что подходящего кандидата вообще нет, являются разными задачами: полезная для сортировки оценка не становится автоматически откалиброванной вероятностью релевантности документа конкретному вопросу пользователя.
Отделить поиск кандидатов от reranking
Анонс семейства NVIDIA различает embedding-поиск и повторное ранжирование. Reranker рассматривает переданные пары запроса и документа; он не восстанавливает релевантную страницу, отсутствующую среди кандидатов. При оценке сохраняют видимость исходного покрытия. Иначе пустой ответ ошибочно объяснят порогом, хотя поисковая стадия вообще не передала нужное подтверждение. Это разные дефекты, для которых понадобятся разные изменения конфигурации и разные контрольные примеры при повторной проверке.
Прочитать контракт оценки
Официальная карточка Nemotron 3.5 Rerank описывает logit релевантности для текстового запроса и документа с текстом, изображениями страниц либо обоими типами содержания. Опубликованная конфигурация checkpoint задаёт классификационную архитектуру. Обёртка способна дополнительно преобразовать выход. До сравнения интеграций и переноса порога записывают, хранятся ли сырые значения модели или уже преобразованные оценки. Одинаковое название поля score ещё не подтверждает одинаковое численное значение и смысл.
Создать наборы ранжирования и отказа
Подготовим действующую полезную процедуру, связанную устаревшую процедуру и постороннюю заметку. Сначала проверим порядок для одного вопроса. Затем добавим вопросы, ответов на которые нет ни в одном кандидате. Они проверяют другое решение: способен ли конвейер не принять лучший доступный документ за достаточное подтверждение. Сам факт существования первого места такого решения не обосновывает, поскольку сортировка всегда может выбрать победителя даже среди полностью неподходящих материалов.
| Контрольный набор | Проверяемый вопрос |
|---|---|
| Полезные и посторонние кандидаты | Разделяет ли порядок явную релевантность? |
| Действующая и устаревшая процедуры | Учитывается ли применимость документа? |
| Нет подтверждающего кандидата | Предотвращает ли отказ неподдержанный ответ? |
Подобрать порог под нагрузку
На разработочной разметке выбирают правило решения, затем отдельно рассматривают ложные принятия и отклонения отложенной выборки. Текстовые и визуальные документы оставляют раздельными срезами: их подготовка и подтверждения различаются. Порог по простым отрицательным примерам может не сработать на правдоподобных устаревших фрагментах. Вместе с ним сохраняют распределение кандидатов и типы запросов. Изменение любого из этих условий способно нарушить интерпретацию даже при прежнем checkpoint.
Версионировать переход от оценки к решению
Рабочий артефакт содержит ревизию checkpoint, процессор, преобразование выхода, правило решения и рассмотренные примеры. После обновления обёртки или модели повторяют наборы ранжирования и отказа. Ошибки представляют как отсутствие кандидата, неверную сортировку или ошибочное отклонение, а не один общий балл. Так документированная роль reranker остаётся отделена от неподтверждённых заявлений об уверенности, а политика итогового ответа поддаётся проверке по сохранённым входам и решениям.
Связанные материалы: Qwen reranker: как отделить повторную оценку от генерации текста; Reranker в RAG: сколько документов передавать на повторную оценку.