• Эксперимент проведён на 164 постах телеграм-канала; сравнивались 5 методов сортировки, использовалась модель gpt-4.1-mini; критерий — «вероятность репоста» (shareability) и фактические forwards.
• Bulk: 1 API-вызов, 14.5K токенов, $0.006, 6 сек; корреляция Спирмена ρ = +0.27 при p-value < 0.001 (в тексте это описано как инверсия порядка).
• Score: 164 API-вызова, 81K токенов, $0.056, 1.2 мин; корреляция Спирмена ρ = -0.50 при p-value < 0.001.
• Score + Reasoning: 164 API-вызова, 103K токенов, $0.080, 1.3 мин; корреляция Спирмена ρ = -0.43 при p-value < 0.001.
• TrueSkill Batch: 17 API-вызовов, 106K токенов, $0.045, 1.8 мин; батчи по 10 элементов, начальные параметры μ=25 и σ=8.33, финальная сортировка по μ − 3σ; корреляция Спирмена ρ = -0.46 при p-value < 0.001.
• TrueSkill Pairwise: 1230 API-вызовов, 659K токенов, $0.271, 1.8 мин; корреляция Спирмена ρ = -0.42 при p-value < 0.001.

Почему это важно: Задачи субъективного ранжирования встречаются в приоритизации фичей, подборках контента и оценке списков, где классический поиск или эмбеддинги не дают прямого порядка. В эксперименте показано, что алгоритм важнее модели: разные процедуры сравнения дают разную связь с реальной реакцией аудитории при заметно разных затратах. Это превращает сортировку через LLM в инженерный компромисс между качеством, стоимостью и объяснимостью результата.

На что обратить внимание: В тексте перечислены типовые ограничения наивной сортировки: контекстное окно, деградация внимания к концу списка, нестабильность повторных запросов и лимиты вывода большого числа ID. Там же противопоставлены схемы с абсолютными баллами (Score) и схемы с относительными сравнениями (TrueSkill), где батчи дают больше информации за один вызов, а pairwise упоминается как вариант, если критично избежать positional bias. В практическом выборе значимы эталон качества и то, насколько допустимо смещение внимания к началу при подаче элементов модели.