LLM som dommer har blitt en dominerende måte å evaluere hvor god en modell er til å løse en oppgave, siden den fungerer uten testsett og håndterer tilfeller der svarene ikke er unike. Men til tross for hvor mye dette brukes, er nesten alle rapporterte resultater svært partiske. Gleder meg til å dele vår preprint om hvordan man riktig bruker LLM som dommer. 🧵 === Så hvordan bruker folk egentlig LLM som dommer? De fleste bruker bare LLM-en som en evaluator og rapporterer den empiriske sannsynligheten for at LLM-en sier svaret ser riktig ut. Når LLM-en er perfekt, fungerer dette fint og gir en upartisk estimator. Hvis LLM-en ikke er perfekt, brytes dette. Tenk på et tilfelle der LLM-en evaluerer korrekt 80 prosent av gangene. Mer spesifikt, hvis svaret er riktig, sier LLM-en «dette ser riktig ut» med 80 prosent sannsynlighet, og de samme 80 prosentene gjelder når svaret faktisk er feil. I denne situasjonen bør du ikke rapportere den empiriske sannsynligheten, fordi den er skjev. Hvorfor? La den sanne sannsynligheten for at den testede modellen er korrekt være p. Da er den empiriske sannsynligheten for at LLM-en sier «korrekt» (= q) q = 0,8p + 0,2(1 - p) = 0,2 + 0,6p Så det upartiske estimatet bør være (q - 0,2) / 0,6 Det blir enda mer interessant hvis feilmønsteret er asymmetrisk eller hvis du ikke kjenner disse feilratene a priori. === Så hva betyr dette? Først, følg den foreslåtte retningslinjen i preprinten vår. Det er ingen gratis lunsj. Du kan ikke vurdere hvor god modellen din er med mindre LLM-en din som dommer er kjent for å være perfekt til å vurdere den. Avhengig av hvor nær den er en perfekt evaluator, trenger du et tilstrekkelig testsett (= kalibreringssett) for å estimere evaluatorens feilrater, og deretter må du korrigere for dem. For det andre, dessverre, må mange funn vi har sett i artikler de siste årene revurderes. Med mindre to artikler brukte nøyaktig samme LLM som dommer, kunne sammenligning av resultater på tvers av dem ha gitt falske påstander. Forbedringen kan ganske enkelt komme av å endre evalueringsprosessen litt. En grundig metastudie er sårt nødvendig. === TLDR: (1) Nesten alle evalueringer av LLM som dommer de siste årene ble rapportert med en skjev estimator. (2) Det er lett å fikse, så vent på hele preprinten vår. (3) Mange resultater fra LLM som dommer bør tas med en klype salt. Full preprint kommer om noen dager, så følg med! Fantastisk arbeid av mine studenter og samarbeidspartnere. @chungpa_lee @tomzeng200 @jongwonjeong123 og @jysohn1108

En mer seriøs tråd om DeepSeek-OCR-hypen / alvorlig feiltolkning som pågår. 1. Når det gjelder tokenreduksjon ved å representere tekst i bilder, har forskere fra Cambridge tidligere vist at 500x prompt token-komprimering er mulig (ACL'25, Li, Su og Collier). Uten å bruke ideen om å konvertere tekst til bilder. 2. Vi bør ikke tilskrive suksessen til DeepSeek OCR til kraften i bilderepresentasjon. Samtidig er det ikke noe grunnleggende galt med tekstrepresentasjon med hvilken som helst tokenizer. Faktisk kan du gjøre det motsatte av hva DeepSeek-OCR gjorde, det vil si at du kan representere bilder som en sekvens av teksttokens (som hver representerer RGB-verdiene deres), og ting vil bare fungere bra. (Se LIFT-papiret.) 3. Den eneste riktige takeawayen er at de nåværende innebyggingsplassene som brukes av LLM-er bare er enorme og kanskje til og med veldig bortkastede. Og viktigere, vi utnytter dem ikke fullt ut ennå. 4. Det er mye nyere bevis som støtter det samme budskapet. For eksempel vises det at hvis du gir demonstrasjoner i kontekst fra flere oppgaver, men blandet i en enkelt kontekst, kan modellen din løse flere ICL-prediksjonsoppgaver samtidig. (Se ALT OVERALT PÅ EN GANG-papiret.) 5. tldr; - DeepSeek-OCR er kult - men du kan oppnå en høyere tokenreduksjonsrate ved å bare finjustere LLM-er på squeezed text-tokens - det er mer bevis på at LLM-er ikke fullt ut utnytter den store innebyggingsplassen og den enorme mengden databehandling som går inn på slutningstidspunktet - og det er den eneste virkelige take away du bør ta med deg

DLLM-er virker lovende ... Men parallell generering er ikke alltid mulig Diffusjonsbaserte LLM-er kan generere mange tokens på forskjellige posisjoner samtidig, mens de fleste autoregressive LLM-er genererer tokens én etter én. Dette gjør diffusjonsbaserte LLM-er svært attraktive når vi trenger rask generering med mindre databehandling. Et stort spørsmål er ... Er parallell generering mulig uten å miste modelleringsnøyaktighet? Svaret er nei. Det er grunnleggende grenser for hvor mye parallellitet vi kan oppnå. Tenk på dette eksemplet: «Velg én by tilfeldig fra følgende fire byer: New York, New Orleans, Mexico City eller Panama City.» Da P(Y₁ = Ny, Y₂ = York) = 1/4, P(Y₁ = Ny, Y₂ = Orleans) = 1/4, og så videre. Dermed er P(Y₁ = Ny) = 1/2, P(Y₂ = By) = 1/2. Hvis du velger å generere Y₁ og Y₂ parallelt, uansett hvilken dekodingsalgoritme du bruker ... Du er dømt til å prøve «New City». Ingen av dagens DLLM-er kan generere disse to ordene riktig uten å gi opp parallellitet. ----- Hvorfor er det slik? Faktisk trener vi aldri LLM-er til å lære den felles distribusjonen over flere tokens i en fremoveriterasjon. Vi lærer alltid en marginal fordeling med ett token betinget av kontekst. (Det samme gjelder for autoregressive modeller også.) Derfor er sampling av flere tokens samtidig bare mulig når disse tokenene er gjensidig uavhengige gitt den nåværende konteksten. Og denne begrensningen av parallell prøvetaking kan formaliseres nøyaktig. Man kan utlede en informasjonsteoretisk grense som er dekodingsstrategiagnostisk, og også utlede strategispesifikke grenser. ----- Så er DLLM-er dømt? Nei! De har et stort potensial for å spare databehandling og tid. Men: (1) vi må være klar over deres grunnleggende begrensninger, og (2) Vi må utforme bedre opplærings- og dekodingsstrategier. Spesielt er det stort rom for forbedring innen dekoding. Hvorfor? Ideelt sett vil vi at modellen skal kontrollere graden av parallellitet under generering. Samtidig bør den velge et undersett av fremtidige tokens som er nesten gjensidig uavhengige gitt den nåværende konteksten. Er dagens dekodingsstrategier gode på dette? Vanskelig å si. De fleste DLLM-er ble aldri stresstestet for det. ----- Derfor introduserte vi en syntetisk benchmark for å stressteste DLLM-er. Vi kaller det ParallelBench. Ideen er enkel: dette er naturlige språkoppgaver, men nøye utformet slik at parallell generering er vanskelig i seg selv. (Tenk "New City", men mer naturlige, virkelige oppgaver.) Hva fant vi? Vi testet populære DLLM-er med ulike dekodingsalgoritmer, og ingen kom i nærheten av "orakel"-ytelse, den ideelle ytelsen du ville fått hvis modellen kunne justere parallelliteten optimalt under dekoding. ----- Takeaway: (1) Parallell generering er ikke alltid mulig, og sjekk ut papiret vårt for mer informasjon :) (2) Hvis du kan designe en DLLM som matcher orakelytelse på vår benchmark, vel, hvem vet, kanskje du bare får en telefon fra noen i Menlo Park. 😉