LLM som domare har blivit ett dominerande sätt att utvärdera hur bra en modell är på att lösa en uppgift, eftersom den fungerar utan testuppsättning och hanterar fall där svaren inte är unika. Men trots hur brett detta används är nästan alla rapporterade resultat mycket partiska. Ser fram emot att dela med oss av vårt preprint om hur man korrekt använder LLM som domare. 🧵 === Så hur använder man egentligen LLM som domare? De flesta använder bara LLM som utvärderare och rapporterar den empiriska sannolikheten att LLM säger att svaret ser rätt ut. När LLM:n är perfekt fungerar detta bra och ger en opartisk skattare. Om LLM:n inte är perfekt går detta sönder. Tänk på ett fall där LLM:n utvärderar korrekt 80 procent av gångerna. Mer specifikt, om svaret är korrekt, säger LLM "detta ser rätt ut" med 80 procents sannolikhet, och samma 80 procent gäller när svaret faktiskt är felaktigt. I denna situation bör du inte rapportera den empiriska sannolikheten, eftersom den är snedvriden. Varför? Låt den verkliga sannolikheten för att den testade modellen är korrekt vara p. Då är den empiriska sannolikheten att LLM säger "korrekt" (= q) q = 0,8p + 0,2(1 - p) = 0,2 + 0,6p Så den opartiska uppskattningen bör vara (q - 0,2) / 0,6 Det blir ännu mer intressant om felmönstret är asymmetriskt eller om du inte känner till dessa felprocenter a priori. === Så vad betyder detta? Följ först den föreslagna riktlinjen i vårt preprint. Det finns ingen gratis lunch. Du kan inte utvärdera hur bra din modell är om inte din LLM som domare är känd för att vara perfekt på att bedöma den. Beroende på hur nära den är en perfekt utvärderare behöver du en tillräckligt stor testmängd (= kalibreringsmängd) för att uppskatta utvärderarens felprocent, och sedan måste du korrigera för dem. För det andra behöver tyvärr många av de resultat vi sett i artiklar under de senaste åren ses om. Om inte två artiklar använde exakt samma LLM som domare kunde jämförelse av resultat mellan dem ha lett till falska påståenden. Förbättringen kan helt enkelt komma från att ändra utvärderingsprocessen något. En rigorös metastudie är akut nödvändig. === Sammanfattning: (1) Nästan alla utvärderingar av LLM som domare under de senaste åren rapporterades med en snedvriden skattare. (2) Det är lätt att fixa, så vänta på vår fullständiga preprint. (3) Många LLM-som-domare-resultat bör tas med en nypa salt. Fullständig preprint kommer om några dagar, så håll utkik! Fantastiskt arbete av mina studenter och samarbetspartners. @chungpa_lee @tomzeng200 @jongwonjeong123 och @jysohn1108

En mer seriös tråd om DeepSeek-OCR hype / allvarliga feltolkningar som pågår. 1. När det gäller tokenreduktion genom att representera text i bilder har forskare från Cambridge tidigare visat att 500x snabb tokenkomprimering är möjlig (ACL'25, Li, Su och Collier). Utan att använda tanken på att konvertera text till bilder. 2. Vi bör inte tillskriva framgången för DeepSeek OCR till kraften i bildrepresentation. Samtidigt är det inget fundamentalt fel med textrepresentation med vilken tokenizer som helst. Faktum är att du kan göra motsatsen till vad DeepSeek-OCR gjorde, dvs du kan representera bilder som en sekvens av texttokens (var och en representerar sina RGB-värden), och saker och ting kommer bara att fungera bra. (Se dokumentet LIFT.) 3. Det enda korrekta att ta med sig är att de nuvarande inbäddningsutrymmena som används av LLM:er är enorma och kanske till och med mycket slösaktiga. Och viktigast av allt, vi utnyttjar dem inte fullt ut ännu. 4. Det finns många nya bevis som stöder samma budskap. Till exempel visas det att om du tillhandahåller kontextdemonstrationer från flera uppgifter men blandade i en enda kontext, kan din modell lösa flera ICL-förutsägelseuppgifter samtidigt. (Se dokumentet ALLT ÖVERALLT, ALLT PÅ EN GÅNG.) 5. TLDR; - DeepSeek-OCR är coolt - men du kan uppnå en högre tokenreduktionshastighet genom att bara finjustera LLM:er på pressade texttokens - det finns fler bevis för att LLM:er inte fullt ut utnyttjar det stora inbäddningsutrymmet och den enorma mängden beräkning som går in vid inferenstiden - Och det är den enda riktiga take-away du bör ta med dig

DLLM:er verkar lovande ... Men parallellgenerering är inte alltid möjlig Diffusionsbaserade LLM:er kan generera många tokens på olika positioner samtidigt, medan de flesta autoregressiva LLM:er genererar tokens en efter en. Detta gör diffusionsbaserade LLM:er mycket attraktiva när vi behöver snabb generering med mindre beräkning. En stor fråga är ... Är parallell generering möjlig utan att förlora modelleringsnoggrannhet? Svaret är nej. Det finns fundamentala gränser för hur mycket parallellitet vi kan uppnå. Tänk på det här exemplet: "Välj en stad enhetligt och slumpmässigt från följande fyra städer: New York, New Orleans, Mexico City eller Panama City." Då P(Y₁ = Ny, Y₂ = York) = 1/4, P(Y₁ = Ny, Y₂ = Orleans) = 1/4, och så vidare. Således är P(Y₁ = Ny) = 1/2, P(Y₂ = Stad) = 1/2. Om du väljer att generera Y₁ och Y₂ parallellt, oavsett vilken avkodningsalgoritm du använder ... Du är dömd att prova "New City". Ingen av dagens DLLM:er kan generera dessa två ord korrekt utan att ge upp parallellitet. ----- Varför är det så? Faktum är att vi aldrig tränar LLM:er för att lära oss den gemensamma distributionen över flera tokens i en framåtriktad iteration. Vi lär alltid ut en marginell fördelning med en token som är villkorad av sammanhanget. (Samma sak gäller för autoregressiva modeller också.) Därför är det bara möjligt att sampla flera token samtidigt när dessa token är ömsesidigt oberoende av varandra med tanke på den aktuella kontexten. Och denna begränsning av parallell provtagning kan formaliseras exakt. Man kan härleda en informationsteoretisk gräns som är avkodningsstrategiagnostisk, och även härleda strategispecifika gränser. ----- Så är DLLM:er dömda? Nej! De har en enorm potential att spara beräkning och tid. Men: (1) vi måste vara medvetna om deras grundläggande begränsningar, och (2) Vi måste utforma bättre tränings- och avkodningsstrategier. I synnerhet finns det stort utrymme för förbättringar när det gäller avkodning. Varför? Vi vill helst att modellen ska styra graden av parallellitet under genereringen. Samtidigt bör den välja en delmängd av framtida tokens som är nästan ömsesidigt oberoende med tanke på den aktuella kontexten. Är nuvarande avkodningsstrategier bra på detta? Svårt att säga. De flesta DLLM:er stresstestades aldrig för det. ----- Därför introducerade vi ett syntetiskt riktmärke för att stresstesta DLLM:er. Vi kallar det ParallelBench. Idén är enkel: det här är uppgifter som rör naturligt språk, men som är noggrant utformade så att parallellgenerering i sig är svårt. (Tänk "ny stad", fast mer naturliga, verkliga arbetsuppgifter.) Vad kom vi fram till? Vi testade populära DLLM:er med olika avkodningsalgoritmer, och ingen kom i närheten av "orakelprestanda", den idealiska prestanda du skulle få om modellen optimalt kunde justera sin parallellitet under avkodning. ----- Takeaway: (1) Parallellgenerering är inte alltid möjlig och kolla in vårt dokument för mer information :) (2) Om du kan designa en DLLM som matchar orakelprestanda på vårt riktmärke, ja, vem vet, du kanske bara får ett samtal från någon i Menlo Park. 😉