LLM come giudice è diventato un modo dominante per valutare quanto sia buono un modello nel risolvere un compito, poiché funziona senza un set di test e gestisce casi in cui le risposte non sono uniche. Ma nonostante quanto sia ampiamente utilizzato, quasi tutti i risultati riportati sono altamente distorti. Siamo entusiasti di condividere il nostro preprint su come utilizzare correttamente LLM come giudice. 🧵 === Quindi, come usano realmente LLM come giudice? La maggior parte delle persone utilizza semplicemente LLM come valutatore e riporta la probabilità empirica che LLM dica che la risposta sembra corretta. Quando LLM è perfetto, questo funziona bene e fornisce un estimatore non distorto. Se LLM non è perfetto, questo si rompe. Considera un caso in cui LLM valuta correttamente l'80 percento delle volte. Più specificamente, se la risposta è corretta, LLM dice "questo sembra corretto" con una probabilità dell'80 percento, e lo stesso 80 percento si applica quando la risposta è effettivamente scorretta. In questa situazione, non dovresti riportare la probabilità empirica, perché è distorta. Perché? Lascia che la vera probabilità che il modello testato sia corretto sia p. Quindi la probabilità empirica che LLM dica "corretto" (= q) è q = 0.8p + 0.2(1 - p) = 0.2 + 0.6p Quindi l'estimatore non distorto dovrebbe essere (q - 0.2) / 0.6 Le cose diventano ancora più interessanti se il modello di errore è asimmetrico o se non conosci queste percentuali di errore a priori. === Quindi, cosa significa questo? Innanzitutto, segui le linee guida suggerite nel nostro preprint. Non c'è pranzo gratis. Non puoi valutare quanto sia buono il tuo modello a meno che il tuo LLM come giudice non sia noto per essere perfetto nel giudicarlo. A seconda di quanto sia vicino a un valutatore perfetto, hai bisogno di una dimensione sufficiente del set di test (= set di calibrazione) per stimare le percentuali di errore del valutatore, e poi devi correggerle. In secondo luogo, molto sfortunatamente, molte scoperte che abbiamo visto in articoli negli ultimi anni devono essere riviste. A meno che due articoli non abbiano utilizzato esattamente lo stesso LLM come giudice, confrontare i risultati tra di loro potrebbe aver prodotto affermazioni false. Il miglioramento potrebbe semplicemente derivare da un leggero cambiamento nel pipeline di valutazione. È urgentemente necessaria una rigorosa meta-analisi. === tldr: (1) Quasi tutte le valutazioni LLM-come-giudice negli ultimi anni sono state riportate con un estimatore distorto. (2) È facile da correggere, quindi aspetta il nostro preprint completo. (3) Molti risultati LLM-come-giudice dovrebbero essere presi con le pinze. Il preprint completo arriverà tra pochi giorni, quindi resta sintonizzato! Lavoro straordinario dei miei studenti e collaboratori. @chungpa_lee @tomzeng200 @jongwonjeong123 e @jysohn1108

Un thread più serio sull'hype di DeepSeek-OCR / seria interpretazione errata in corso. 1. Sulla riduzione dei token tramite la rappresentazione del testo nelle immagini, i ricercatori di Cambridge hanno precedentemente dimostrato che è possibile una compressione dei token di prompt di 500x (ACL'25, Li, Su e Collier). Senza utilizzare l'idea di convertire il testo in immagini. 2. Non dovremmo attribuire il successo di DeepSeek OCR al potere della rappresentazione delle immagini. Allo stesso tempo, non c'è nulla di fondamentalmente sbagliato nella rappresentazione del testo con qualsiasi tokenizer. Infatti, puoi fare l'opposto di ciò che ha fatto DeepSeek-OCR, cioè puoi rappresentare le immagini come una sequenza di token di testo (ognuno rappresentante i loro valori RGB), e le cose funzioneranno semplicemente bene. (Vedi il documento LIFT.) 3. L'unico takeaway corretto è che gli attuali spazi di embedding utilizzati dagli LLM sono semplicemente enormi e forse anche molto spreconi. E, cosa importante, non li stiamo ancora utilizzando appieno. 4. Ci sono molte prove recenti che supportano lo stesso messaggio. Ad esempio, è stato dimostrato che se fornisci dimostrazioni contestuali da più compiti ma mescolati in un unico contesto, allora il tuo modello può risolvere simultaneamente più compiti di previsione ICL. (Vedi il documento EVERYTHING EVERYWHERE ALL AT ONCE.) 5. tldr; - DeepSeek-OCR è interessante - ma puoi ottenere un tasso di riduzione dei token più elevato semplicemente affinando gli LLM su token di testo compressi - ci sono ulteriori prove che gli LLM non stanno sfruttando appieno il grande spazio di embedding e l'enorme quantità di calcolo che viene utilizzata durante il tempo di inferenza - e questo è l'unico vero takeaway che dovresti portare via.

I DLLM sembrano promettenti... ma la generazione parallela non è sempre possibile I LLM basati su diffusione possono generare molti token in diverse posizioni contemporaneamente, mentre la maggior parte degli LLM autoregressivi genera i token uno alla volta. Questo rende gli LLM basati su diffusione altamente attraenti quando abbiamo bisogno di una generazione veloce con meno risorse computazionali. Una grande domanda è... è possibile la generazione parallela senza perdere precisione nel modello? La risposta è no. Ci sono limiti fondamentali su quanto parallelismo possiamo raggiungere. Considera questo esempio: "Scegli una città uniformemente a caso tra le seguenti quattro città: New York, New Orleans, Città del Messico o Panama City." Quindi, P(Y₁ = New, Y₂ = York) = 1/4, P(Y₁ = New, Y₂ = Orleans) = 1/4, e così via. Quindi, P(Y₁ = New) = 1/2, P(Y₂ = City) = 1/2. Se scegli di generare Y₁ e Y₂ in parallelo, non importa quale algoritmo di decodifica usi... Sei destinato a campionare "New City." Nessuno degli attuali DLLM può generare correttamente queste due parole senza rinunciare al parallelismo. ----- Perché è questo il caso? In effetti, non alleniamo mai gli LLM per apprendere la distribuzione congiunta su più token in un'unica iterazione in avanti. Insegniamo sempre una distribuzione marginale a un singolo token condizionata al contesto. (Lo stesso vale anche per i modelli autoregressivi.) Pertanto, campionare più token contemporaneamente è possibile solo quando quei token sono mutuamente indipendenti dato il contesto attuale. E questa limitazione del campionamento parallelo può essere formalizzata con precisione. Si può derivare un limite informatico che è indipendente dalla strategia di decodifica e derivare anche limiti specifici per la strategia. ----- Quindi i DLLM sono destinati a fallire? No! Hanno un enorme potenziale per risparmiare risorse e tempo. Ma: (1) dobbiamo essere consapevoli delle loro limitazioni fondamentali, e (2) dobbiamo progettare migliori strategie di addestramento e decodifica. In particolare, c'è un enorme margine di miglioramento nella decodifica. Perché? Idealmente, vogliamo che il modello controlli il grado di parallelismo durante la generazione. Allo stesso tempo, dovrebbe scegliere un sottoinsieme di token futuri che siano quasi mutuamente indipendenti dato il contesto attuale. Le attuali strategie di decodifica sono buone in questo? Difficile dirlo. La maggior parte dei DLLM non è mai stata sottoposta a stress test per questo. ----- Ecco perché abbiamo introdotto un benchmark sintetico per stressare i DLLM. Lo chiamiamo ParallelBench. L'idea è semplice: questi sono compiti di linguaggio naturale, ma progettati con attenzione in modo che la generazione parallela sia intrinsecamente difficile. (Pensa a "New City", ma compiti più naturali e reali.) Cosa abbiamo trovato? Abbiamo testato DLLM popolari con vari algoritmi di decodifica, e nessuno si è avvicinato alle prestazioni "oracle", le prestazioni ideali che otterresti se il modello potesse regolare in modo ottimale il suo parallelismo durante la decodifica. ----- Conclusione: (1) La generazione parallela non è sempre possibile e dai un'occhiata al nostro articolo per ulteriori dettagli :) (2) Se riesci a progettare un DLLM che raggiunga le prestazioni oracle sul nostro benchmark, beh, chissà, potresti ricevere una chiamata da qualcuno a Menlo Park. 😉