Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Исследователи Meta предложили hLLM — систему для переранжирования кандидатов с помощью LLM; работа опубликована как препринт, не проходивший рецензирования. По замерам авторов, система обрабатывает запрос за 28 мс и ускоряет вывод в 64 раза относительно учителя с генерацией рассуждений. Результат важен командам, которые используют LLM для поиска, рекомендаций или рекламы и упираются в задержку последовательной генерации.
Что сделали
Обычный генеративный ранжировщик получает контекст пользователя и список кандидатов, а затем выводит их номера в нужном порядке. Хотя ответ представляет собой перестановку заранее известных значений, LLM генерирует его как обычный текст: каждый следующий токен требует отдельного последовательного прохода декодера.
hLLM не генерирует номера слева направо. Сначала базовая LLM за один параллельный проход обрабатывает весь запрос — этот этап называют заполнением контекста. Из скрытого состояния в позиции каждого кандидата система извлекает его представление. Небольшая головка с механизмом внимания преобразует представления в матрицу: строки соответствуют товарам или документам, столбцы — местам в выдаче, а каждая ячейка показывает пригодность кандидата для позиции.
Затем алгоритм Hungarian решает задачу максимального паросочетания: каждому кандидату назначается ровно одна позиция, а каждой позиции — ровно один кандидат. Поэтому результат всегда является корректной перестановкой без повторов и пропусков. Важно, что постоянным становится число проходов LLM, а не вычислительная сложность всей системы: обработка контекста и задача назначения всё равно зависят от длины списка.
Для обучения авторы заменяют дискретное назначение его дифференцируемым приближением Sinkhorn, через которое можно передавать градиенты. Целевые перестановки заранее генерирует авторегрессионная модель-учитель. Их сохраняют и используют для дистилляции — переноса поведения учителя в ученика без повторных обращений к учителю во время обучения. Саму базовую модель адаптируют через LoRA, то есть обучают небольшие низкоранговые добавки к её весам.
Что показали
На закрытом наборе Meta hLLM сохранила близкие к учителю результаты по площади под ROC-кривой, полноте верхних позиций и NDCG — метрике, которая сильнее учитывает релевантные элементы в начале списка. По отдельным показателям ученик оказался немного выше или ниже учителей, поэтому работа не демонстрирует одинакового преимущества по качеству: её основной результат относится к задержке.
Сравнение с учителем без цепочки рассуждений отделяет эффект нового декодера от простого сокращения ответа. Даже когда учитель выводил только номера кандидатов, hLLM оказалась в 3,1 раза быстрее. Значит, выигрыш авторы связывают не только с удалением служебного текста, но и с отказом от последовательной генерации самой перестановки.
На открытом наборе Amazon Beauty система показала задержку 113 мс и ускорение в 44,9 раза относительно модели-учителя Qwen3-32B. Качество осталось близким по выбранным авторами метрикам, хотя ученик уступил учителю по части из них. Отдельные эксперименты также показали, что адаптация базовой LLM через LoRA и дополнительное сравнение кандидатов в головке полезнее, чем обучение головки поверх полностью замороженных представлений.
Ограничения
Закрытая часть проверки охватывает 236 тысяч тестовых запросов со списками до 150 кандидатов, но сами данные и их распределение недоступны для независимого воспроизведения. Открытая проверка ограничена 1 118 списками Amazon Beauty по 50 товаров: она подтверждает перенос на другой источник, но не показывает работу на веб-поиске, рекламе или других категориях рекомендаций.
Задержку измеряли на NVIDIA A100 и для конкретной реализации. В работе не показаны производительность при пакетной обработке, потребление памяти, стоимость эксплуатации и поведение при более длинных списках. Авторы обсуждают FIRST, DiffuRank и другие подходы, однако в основных экспериментах не сравнивают hLLM с ними или с негenerativeными переранжировщиками. Поэтому результаты отвечают на вопрос о замене декодера выбранного LLM-учителя, но не определяют лучший вариант ранжирования среди всех доступных архитектур.
Что это значит
Для команд, которые уже строят генеративное переранжирование, работа меняет направление оптимизации. Перестановку фиксированного набора кандидатов необязательно считать текстом: её можно представить как матрицу назначений, а структурные ограничения передать точному комбинаторному алгоритму. После этого задержка определяется главным образом обработкой входного контекста, а не длиной сгенерированного списка.
Однако менять производственный стек только на основании этих замеров рано. hLLM требует доступа к скрытым состояниям модели, собственного обучения и заранее подготовленных перестановок учителя. Подход поэтому нельзя напрямую применить к закрытому API, который возвращает только текст, или к сценарию со свободной формой ответа.
Практический вывод — проверить такую архитектуру как отдельный прототип, если последовательное декодирование уже занимает значимую часть бюджета задержки. Для новых систем работа также предлагает разделить задачи: LLM формирует сравнительные представления кандидатов, а корректность выходной структуры обеспечивает специализированный алгоритм. Если текущий ранжировщик и без генерации укладывается в требования по качеству и времени ответа, препринт сам по себе не создаёт причины заменять его на LLM.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
