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 як суддя, порівняння результатів між ними могло призвести до хибних тверджень. Покращення може бути просто через незначну зміну процесу оцінювання. Терміново потрібне ретельне мета-дослідження. === Коротко: (1) Майже всі оцінки LLM-as-a-judge за останні кілька років були зареєстровані з упередженим оцінювачем. (2) Це легко виправити, тож зачекайте на повний препринт. (3) Багато результатів LLM-as-a-judge слід сприймати з часткою скептицизму. Повний препринт буде за кілька днів, тож слідкуйте за оновленнями! Дивовижна робота моїх студентів і співробітників. @chungpa_lee @tomzeng200 @jongwonjeong123 і @jysohn1108

Більш серйозна тема про хайп DeepSeek-OCR / серйозне неправильне тлумачення. 1. Що стосується зменшення токенів за допомогою представлення тексту на зображеннях, дослідники з Кембриджа раніше показали, що можливе 500-кратне стиснення токенів (ACL'25, Li, Su та Collier). Без використання ідеї перетворення тексту в зображення. 2. Ми не повинні пов'язувати успіх DeepSeek OCR з потужністю представлення зображень. У той же час, немає нічого принципово поганого в представленні тексту за допомогою будь-якого токенізатора. Насправді, ви можете зробити протилежне тому, що зробив DeepSeek-OCR, тобто ви можете представити зображення у вигляді послідовності текстових токенів (кожен з яких представляє свої значення RGB), і все просто працюватиме нормально. (Див. документ LIFT). 3. Єдиний правильний висновок полягає в тому, що нинішні простори для вбудовування, які використовуються LLM, просто величезні і, можливо, навіть дуже марнотратні. І, що важливо, ми ще не використовуємо їх повною мірою. 4. Є багато свіжих доказів, що підтверджують ту саму думку. Наприклад, показано, що якщо ви надаєте в контексті демонстрації з декількох завдань, але змішані в одному контексті, то ваша модель може вирішувати кілька завдань прогнозування ICL одночасно. (Див. документ «ВСЕ СКРІЗЬ І ОДРАЗУ».) 5. грн.; - DeepSeek-OCR – це круто - але ви можете досягти вищої швидкості зниження токенів, просто налаштувавши LLM на стислих текстових токенах - існує більше доказів того, що LLM не повністю використовують великий простір для вкладення та величезну кількість обчислень, які надходять під час висновків. - і це єдиний реальний висновок, який ви повинні забрати

DLLM здаються перспективними... Але паралельна генерація не завжди можлива LLM на основі дифузії можуть генерувати багато токенів на різних позиціях одночасно, тоді як більшість авторегресійних LLM генерують токени один за одним. Це робить LLM на основі дифузії дуже привабливими, коли нам потрібна швидка генерація з меншим обсягом обчислень. Велике питання полягає в тому, що ... Чи можлива паралельна генерація без втрати точності моделювання? Відповідь – ні. Існують фундаментальні обмеження щодо того, наскільки паралелізму ми можемо досягти. Розглянемо такий приклад: "Виберіть одне місто рівномірно навмання з наступних чотирьох міст: Нью-Йорк, Новий Орлеан, Мехіко або Панама-Сіті». То P(Y₁ = Новий, Y₂ = Йорк) = 1/4, P(Y₁ = Новий, Y₂ = Орлеанський) = 1/4 і так далі. Таким чином, p(Y₁ = Новий) = 1/2, P(Y₂ = Місто) = 1/2. Якщо ви вирішите генерувати Y₁ та Y₂ паралельно, незалежно від того, який алгоритм декодування ви використовуєте ... Ви приречені на пробу «Нового міста». Жоден із сучасних DLLM не може правильно згенерувати ці два слова, не відмовляючись від паралелізму. ----- Чому так? Насправді, ми ніколи не навчаємо LLM вивчати спільний розподіл між кількома токенами за одну пряму ітерацію. Ми завжди навчаємо граничному розподілу одного токена, який залежить від контексту. (Те ж саме стосується і авторегресійних моделей.) Таким чином, вибірка кількох токенів одночасно можлива лише тоді, коли ці токени є взаємно незалежними з урахуванням поточного контексту. І це обмеження паралельної вибірки можна точно формалізувати. Можна вивести інформаційно-теоретичну межу, яка є незалежною від декодування-стратегії, а також вивести межі, специфічні для стратегії. ----- То чи приречені DLLM? Ні! Вони мають величезний потенціал для економії обчислень і часу. Але: (1) ми повинні усвідомлювати їх фундаментальні обмеження, і (2) Нам потрібно розробити кращі стратегії навчання та декодування. Зокрема, є величезні можливості для вдосконалення в декодуванні. Чому? В ідеалі ми хочемо, щоб модель контролювала ступінь паралельності під час генерації. У той же час він повинен вибрати підмножину майбутніх токенів, які є майже взаємно незалежними з урахуванням поточного контексту. Чи хороші в цьому поточні стратегії декодування? Важко сказати. Більшість DLLM ніколи не проходили стрес-тестування. ----- Ось чому ми представили синтетичний бенчмарк для стрес-тестування DLLM. Ми називаємо його ParallelBench. Ідея проста: це завдання на природній мові, але ретельно розроблені так, щоб паралельна генерація була за своєю суттю складною. (Згадайте «Нове місто», але більш природні, реальні завдання.) Що ми з'ясували? Ми протестували популярні DLLM з різними алгоритмами декодування, і жоден з них не наблизився до продуктивності «оракула», ідеальної продуктивності, яку ви б отримали, якби модель могла оптимально налаштувати свою паралельність під час декодування. ----- Винос: (1) Паралельна генерація не завжди можлива, і перегляньте нашу статтю для отримання більш детальної інформації :) (2) Якщо ви можете розробити DLLM, який відповідає продуктивності оракула за нашим тестом, ну, хто знає, можливо, вам просто зателефонує хтось із Менло-Парку. 😉