LLM в качестве судьи стал доминирующим способом оценки того, насколько хорошо модель решает задачу, поскольку он работает без тестового набора и обрабатывает случаи, когда ответы не уникальны. Но, несмотря на то, как широко это используется, почти все сообщенные результаты сильно предвзяты. С нетерпением ждем возможности поделиться нашим препринтом о том, как правильно использовать LLM в качестве судьи. 🧵 === Так как же люди на самом деле используют LLM в качестве судьи? Большинство людей просто используют LLM в качестве оценщика и сообщают эмпирическую вероятность того, что LLM говорит, что ответ выглядит правильным. Когда LLM идеален, это работает нормально и дает непредвзятый оценщик. Если LLM не идеален, это ломается. Рассмотрим случай, когда LLM оценивает правильно 80 процентов времени. Более конкретно, если ответ правильный, LLM говорит "это выглядит правильно" с вероятностью 80 процентов, и та же вероятность 80 процентов применяется, когда ответ на самом деле неправильный. В этой ситуации вы не должны сообщать эмпирическую вероятность, потому что она предвзята. Почему? Пусть истинная вероятность того, что протестированная модель правильна, равна p. Тогда эмпирическая вероятность того, что LLM говорит "правильно" (= q) равна q = 0.8p + 0.2(1 - p) = 0.2 + 0.6p Таким образом, непредвзятая оценка должна быть (q - 0.2) / 0.6 Ситуация становится еще более интересной, если паттерн ошибок асимметричен или если вы не знаете эти уровни ошибок заранее. === Так что это значит? Во-первых, следуйте предложенной инструкции в нашем препринте. Нет бесплатного обеда. Вы не можете оценить, насколько хороша ваша модель, если ваш LLM в качестве судьи не известен как идеальный в оценке. В зависимости от того, насколько близок он к идеальному оценщику, вам нужен достаточный размер тестового набора (= калибровочный набор), чтобы оценить уровни ошибок оценщика, а затем вы должны скорректировать их. Во-вторых, очень к сожалению, многие выводы, которые мы видели в статьях за последние несколько лет, необходимо пересмотреть. Если две статьи не использовали один и тот же LLM в качестве судьи, сравнение результатов между ними могло привести к ложным утверждениям. Улучшение могло просто произойти из-за небольшого изменения в процессе оценки. Необходима строгая мета-исследование. === tldr: (1) Почти все оценки LLM в качестве судьи за последние несколько лет были сообщены с предвзятым оценщиком. (2) Это легко исправить, так что ждите нашего полного препринта. (3) Многие результаты LLM в качестве судьи следует воспринимать с недоверием. Полный препринт выйдет через несколько дней, так что следите за новостями! Удивительная работа моих студентов и коллег. @chungpa_lee @tomzeng200 @jongwonjeong123 и @jysohn1108

Более серьезная тема о хайпе DeepSeek-OCR / серьезном неправильном толковании происходящего. 1. Что касается сокращения токенов путем представления текста в изображениях, исследователи из Кембриджа ранее показали, что возможно сжатие токенов в 500 раз (ACL'25, Ли, Су и Коллиер). Без использования идеи преобразования текста в изображения. 2. Мы не должны приписывать успех DeepSeek OCR силе представления изображений. В то же время, нет ничего принципиально неправильного в представлении текста с помощью любого токенизатора. На самом деле, вы можете сделать противоположное тому, что сделала DeepSeek-OCR, т.е. вы можете представлять изображения как последовательность текстовых токенов (каждый из которых представляет свои значения RGB), и все будет работать нормально. (Смотрите статью LIFT.) 3. Единственный правильный вывод заключается в том, что текущие пространства встраивания, используемые LLM, просто огромны и, возможно, даже очень расточительны. И, что важно, мы еще не используем их в полной мере. 4. Существует много недавних доказательств, поддерживающих то же самое сообщение. Например, показано, что если вы предоставите демонстрации в контексте из нескольких задач, но смешанных в одном контексте, то ваша модель может одновременно решать несколько задач предсказания ICL. (Смотрите статью EVERYTHING EVERYWHERE ALL AT ONCE.) 5. Кратко; - DeepSeek-OCR крут - но вы можете достичь более высокого уровня сокращения токенов, просто дообучив LLM на сжатых текстовых токенах - есть больше доказательств того, что LLM не полностью используют большое пространство встраивания и огромное количество вычислений, которые происходят во время вывода - и это единственный реальный вывод, который вы должны сделать.

DLLM выглядят многообещающе... но параллельная генерация не всегда возможна Модели на основе диффузии могут генерировать много токенов на разных позициях одновременно, в то время как большинство авторегрессионных моделей генерируют токены по одному. Это делает модели на основе диффузии очень привлекательными, когда нам нужна быстрая генерация с меньшими вычислительными затратами. Большой вопрос заключается в том, возможно ли параллельное генерирование без потери точности моделирования? Ответ - нет. Существуют фундаментальные ограничения на то, сколько параллелизма мы можем достичь. Рассмотрим этот пример: "Выберите один город равномерно случайным образом из следующих четырех городов: Нью-Йорк, Новый Орлеан, Мехико или Панама-Сити." Тогда, P(Y₁ = New, Y₂ = York) = 1/4, P(Y₁ = New, Y₂ = Orleans) = 1/4 и так далее. Таким образом, P(Y₁ = New) = 1/2, P(Y₂ = City) = 1/2. Если вы решите генерировать Y₁ и Y₂ параллельно, независимо от того, какой алгоритм декодирования вы используете … Вы обречены на выбор "Новый Город." Ни одна из современных DLLM не может правильно сгенерировать эти два слова без отказа от параллелизма. ----- Почему это так? На самом деле, мы никогда не обучаем LLM учиться совместному распределению нескольких токенов за одну итерацию. Мы всегда обучаем распределению одного токена, зависящему от контекста. (То же самое касается и авторегрессионных моделей.) Поэтому выбор нескольких токенов одновременно возможен только тогда, когда эти токены взаимно независимы с учетом текущего контекста. И это ограничение параллельного выборки можно точно формализовать. Можно вывести информационно-теоретическое ограничение, которое не зависит от стратегии декодирования, а также вывести ограничения, специфичные для стратегии. ----- Так что DLLM обречены? Нет! У них есть огромный потенциал для экономии вычислительных ресурсов и времени. Но: (1) мы должны быть осведомлены об их фундаментальных ограничениях, и (2) нам нужно разрабатывать лучшие стратегии обучения и декодирования. В частности, есть огромный потенциал для улучшения в декодировании. Почему? В идеале мы хотим, чтобы модель контролировала степень параллелизма во время генерации. В то же время она должна выбирать подмножество будущих токенов, которые почти взаимно независимы с учетом текущего контекста. Хороши ли текущие стратегии декодирования в этом? Сложно сказать. Большинство DLLM никогда не подвергались стресс-тестированию для этого. ----- Вот почему мы представили синтетический бенчмарк для стресс-тестирования DLLM. Мы называем его ParallelBench. Идея проста: это задачи естественного языка, но тщательно разработанные так, чтобы параллельная генерация была по своей сути сложной. (Думайте о "Новом Городе", но более естественные, реальные задачи.) Что мы нашли? Мы протестировали популярные DLLM с различными алгоритмами декодирования, и ни одна из них не приблизилась к "оракульной" производительности, идеальной производительности, которую вы бы получили, если бы модель могла оптимально регулировать свой параллелизм во время декодирования. ----- Вывод: (1) Параллельная генерация не всегда возможна, и ознакомьтесь с нашей статьей для получения дополнительных деталей :) (2) Если вы сможете разработать DLLM, которая соответствует оракульной производительности на нашем бенчмарке, кто знает, возможно, вы получите звонок от кого-то из Менло-Парка. 😉