Как заставить LLM сортировать данные: от наивного подхода до TrueSkill
- Эксперимент проведён на 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. В практическом выборе значимы эталон качества и то, насколько допустимо смещение внимания к началу при подаче элементов модели.
Коротко
- Сортировка «всё в один запрос» может давать систематическое смещение к началу списка из-за внимания модели; на больших наборах это искажает ранжирование.
- Для списков фичей, резюме или материалов заранее проясняется, нужны ли объяснения по каждому пункту: от этого зависит выбор между Score и сравнительными схемами.
- Когда элементов много, относительные сравнения батчами снижают число вызовов и при этом сохраняют близкую связь результата с «земной» метрикой из домена.
- Оценки по шкале 1–100 удобны для сортировки, но в статье отмечена нестабильность абсолютных баллов: один и тот же запрос может менять значение.
- Автор показал, что критерии «интересно разработчикам», «домохозяйкам» и «бизнесу» дают разные топы; формулировка запроса меняет результат.
FAQ
Зачем этот разбор может быть важен тем, кто просит LLM ранжировать контент, приоритизировать фичи или сортировать большой список по субъективному критерию?
Статья показывает на реальных данных, что качество сортировки сильно зависит от выбранной процедуры, а не только от модели, и что наивный подход может систематически искажать порядок.
Почему метод Bulk (весь список в один запрос) в эксперименте оказался ненадёжным и даже дал обратную связь с фактическими репостами?
Автор связывает это с ограничениями контекста и positional bias: модель внимательнее читает начало списка и поэтому даёт позиционное преимущество первым элементам.
Чем отличаются подходы Score и TrueSkill Batch с точки зрения того, какие сигналы они используют для ранжирования: абсолютные оценки или относительные сравнения?
Score присваивает каждому элементу балл по шкале 1–100 и затем сортирует по баллам, а TrueSkill Batch обновляет рейтинги по результатам сортировки случайных батчей и ранжирует по μ − 3σ.
Как в статье измеряли качество ранжирования и какие выводы автор сделал о компромиссе между точностью и стоимостью разных методов?
Качество оценивали по корреляции Спирмена между предсказанным рангом и фактическими репостами; Score показал лучшую корреляцию, а TrueSkill Batch — близкий результат при меньших затратах по вызовам.
Читайте также
Когда, зачем и как правильно начинать новую сессию в Claude Code- Обучение ИИ в «диких» условиях: как рутинные действия превращаются в датасеты
- LLM-агент для поиска свободных доменов: автоматизация подбора
- Бесплатный API для нейросетей от NVIDIA: более 100 моделей, OpenAI-совместимый эндпоинт и 40 запросов в минуту
- Как Meta* убила Llama, чтобы спасти свой ИИ-бизнес
- Positional bias при сортировке списков через LLM: Наивная сортировка «всё в один запрос» склонна завышать элементы в начале списка: модель распределяет внимание неравномерно, и порядок начинает зависеть от позиции, а не от смысла. В эксперименте это проявилось как инверсия результата относительно реального поведения аудитории, поэтому для больших списков такой подход нельзя считать надёжным.
[LLM-практики: ранжирование и оценка]
Зарегистрированные пользователи видят только два тезиса.
Зарегистрироваться
Автор протестировал пять методов сортировки списка через LLM на 164 постах и измерил, какой подход лучше предсказывает реальные репосты. В выводах показано, что наивный Bulk может систематически искажать порядок, а Score и TrueSkill Batch дают более устойчивое ранжирование.