Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Haoyaun Zhu и Jie Zhang проверили, можно ли использовать LLM-оценщики через общие конечные точки API как стабильный измерительный инструмент; их работа — препринт, не проходивший рецензирования. В тесте согласованность повторных ранжирований по коэффициенту Спирмена — мере сохранения порядка — составила 0,400 при заранее установленном пороге 0,90. Это важно командам, которые поручают модели отбор обучающих данных, оценку ответов или контроль качества генерации.
Что сделали
Авторы заранее зафиксировали протоколы и пороги, после чего несколько раз отправляли моделям-оценщикам одинаковые запросы. Проверки останавливались на этапе валидации самого измерителя: даже совпадающие до байта запросы на следующий день сохраняли ранжирование с согласованностью 0,78 при требовании 0,99. При этом запросы доставлялись корректно, формат ответов соблюдался, а доступные через API метаданные не менялись.
По анализу авторов, нестабильность складывалась из нескольких эффектов. Назначение условных меток влияло на ответ сопоставимо с измеряемым сигналом, различия между кандидатами оказывались ниже собственного шумового порога оценщика, а небольшое изменение ответа нарушало весь точный порядок ранжирования. Замена метрики, увеличение числа вызовов и переход между проверенными провайдерами не устранили проблему в исследованных конфигурациях. Самостоятельное размещение модели помогало только при низкой нагрузке.
Что это значит
Имя модели на общем API нельзя автоматически считать указанием на неизменный измерительный инструмент. До фиксации порога авторы предлагают провести пилот: измерить повторяемость, шумовой порог и распределение различий между кандидатами, проверить смысл доступных метаданных и смоделировать, как критерий работает при наблюдаемом шуме. Для итоговой оценки предпочтительнее заранее запланированные повторы и непрерывные оценки, а не точное ранжирование, где единичная перестановка меняет весь результат.
Ограничения работы: выводы относятся к внешнему поведению моделей на общей инфраструктуре, арифметическим задачам и структурированному ранжированию; основной анализ опирался на 31 допустимую группу задач. Авторы не исследовали внутренние состояния моделей и не оценивали качество сервисов провайдеров. Сравнение конечных точек также не изолирует причину нестабильности: по этим замерам нельзя разделить влияние пакетной обработки запросов, планирования вычислений и смены развёртывания за неизменным именем модели.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
