Hvordan finne ut om en ny AI-modell faktisk er bedre for jobben din

Hvorfor lanseringsbenchmarkene ikke svarer på spørsmålet ditt

Hver ny frontmodell lanseres med et diagram som viser den i ledelsen på en rekke standardiserte tester. Disse tallene er ekte, og de er også nesten ubrukelige for å avgjøre hva du bør bruke på mandag, av tre grunner.

Marginene er små, og oppgavene er ikke dine. En forskjell på to poeng på en resonneringsbenchmark sier ingenting om hvorvidt en modell skriver en bedre kunde-e-post eller holder et skjema mer pålitelig gjennom to hundre rader.

Benchmarker måler oppgavene som er enkle å poengsette. Ting med et riktig svar. Det meste av profesjonelt arbeid har ikke det: tone, struktur, vurderinger om hva som bør utelates. Det er nettopp der modellene skiller seg mest, og der ingenting blir målt.

Lanseringssammenligninger utføres av leverandøren. Ikke nødvendigvis uredelig, men ingen publiserer testen der egen modell kom på andreplass.

Det verdt å svare på er smalere: på de spesifikke oppgavene du gjør tjue ganger i uken, hvilken av disse to er best? Det finnes ikke noe publisert svar på det, og det tar omtrent en time å finne ut.

Hva som egentlig endrer seg mellom lanseringer

Gjennom de siste frontlanseringene ligger forbedringene som betyr noe i daglig bruk konsekvent på de samme områdene, og det er sjelden de som fremheves i lanseringen.

Hva som ble bedre	Hvordan du merker det	Om benchmarken viser det
Instruksjonsetterlevelse	Den slutter å ignorere din tredje betingelse	Sjelden
Negative instruksjoner	"Bruk ikke analogier" blir faktisk fulgt	Nei
Gjenkalling i lang kontekst	Den finner tingen på side 140, ikke bare side 3	Delvis
Formateringsdisiplin	Tabellen har kolonnene du ba om, hver gang	Nei
Kalibrert usikkerhet	Den sier den ikke vet i stedet for å finne opp noe	Nei
Tonekontroll	Færre omskrivinger før noe er klart til å sendes	Nei
Resonneringsdybde	Den fanger unntakstilfellet du overså	Ja, dette er den de måler

Fem av disse syv er usynlige i et benchmark-diagram og er grunnen til at en ny modell føles bedre eller verre å jobbe med. Instruksjonsetterlevelse er spesielt forskjellen mellom et førsteutkast du redigerer, og et førsteutkast du kaster.

Timen med testing

Gjør dette i stedet for å lese lanseringsdekning. Kjør begge modellene side ved side på ditt eget materiale.

1. Samle fem reelle oppgaver fra de siste to ukene. Ekte oppgaver, med din faktiske kontekst limt inn, ikke leketøysprompter. Inkluder minst én skriveoppgave, én oppgave med strukturert output, og én der du trengte resonnering om noe ukjent.
2. Skriv ned hva et godt svar inneholder for hver, i én setning, før du kjører noe. Dette er trinnet som forhindrer deg fra å foretrekke det svaret som er lengst og mest selvsikkert, som er en sterk og i stor grad ubevisst skjevhet.
3. Kjør hver oppgave mot begge modellene parallelt, slik at ingen av svarene forankres i det andre.
4. Score på redigeringsinnsats, altså hvor mye arbeid mellom outputen og noe du faktisk ville sendt. Ikke på hvordan det leses.
5. Noter gapets størrelse, ikke bare hvem som vant. Utskiftbare resultater sier deg at du kan slutte å tenke på modellvalg for den oppgaven, som er genuint nyttig.
6. Behold loggen. Om tre måneder, når neste lansering kommer, kjører du de samme fem oppgavene på nytt og får et reelt svar på tjue minutter.

Det siste punktet er det som gir avkastning over tid. Et lagret testsett er det som gjør hver påfølgende lansering billig å vurdere.

Seks spørsmål som skiller frontmodeller

Generelle spørsmål gir like svar fra enhver kompetent modell. Vil du se en forskjell, må du legge press på en spesifikk egenskap.

• Tone under vanskelige forhold. Skriv en melding som forteller en kunde at vi ikke holdt fristen. Ta ansvar uten å overdrive unnskyldningen og uten bortforklaringer. Under 120 ord. Registerforskjeller viser seg umiddelbart.
• Negativ betingelse. Forklar [konsept] uten å bruke noen analogi eller metafor. Etterlevelse av negative instruksjoner varierer langt mer enn du ville forventet.
• Streng ekstraksjon. Trekk ut hver dato, beløp og part i et JSON-array med nøyaktig disse nøklene. Hvis et felt er tomt, bruk null. Gjett ikke. Tester formatdisiplin og tendensen til å fylle hull.
• Gjenkalling i lang kontekst. Last opp et langt dokument og spør om noe i midten. Avslører brukbar kontekst, som ikke er det samme som annonsert kontekst.
• Innrømme det man ikke vet. Spør om noe genuint obskurt eller helt nytt. Det beste svaret er et klart "jeg vet ikke" eller et kildebelagt oppslag. Oppspinn her diskvalifiserer, uansett hva noen benchmark sier.
• Etterlevelse av flere betingelser samtidig. Gi seks betingelser på én gang og tell hvor mange som overlever. Denne ene testen forutsier daglig tilfredshet bedre enn noe annet på listen.

Svaret er vanligvis "begge, til forskjellige ting"

Folk går inn i en lansering og vil ha en dom, og det ærlige funnet etter å ha kjørt testen er nesten alltid delt. Én modell vinner på skriving og tone. Den andre vinner på streng struktur og hastighet. De er tett nok på generell resonnering til at det ikke avgjør noe.

Det er ikke en unnamanøver, det er det faktiske resultatet, og det har en praktisk konsekvens. Kan du bare bruke én modell, velger du hvilken oppgavekategori du skal være svakere på. Kan du bruke begge, stopper lanseringsspørsmålet med å være "bør jeg bytte" og blir i stedet "hvilke oppgaver flytter seg", som er en mye mindre og lavere-risiko avgjørelse.

Det endrer også hva en lansering betyr for deg. Når nye modeller lander i et arbeidsområde som allerede har flere, kjører du de fem oppgavene på nytt, justerer rutingen, og går videre. Det er ingen migrering, ingen kansellert abonnement, og ingen måned med å bruke noe verre fordi du forpliktet deg før testing.

Hva du bør gjøre på lanseringsdagen

Bytt ikke standardvalgene dine umiddelbart. Inntrykkene fra lanseringsuken domineres av nyhetens interesse og av hvilke eksempler som sirkulerte først.

Kjør testsettet ditt på nytt. Tjue minutter hvis du har beholdt ett fra forrige gang.

Sjekk de kjedelige tingene. Kontekstvindu, om dine eksisterende prompter fortsatt oppfører seg likt, og om noe du stolte på har endret seg. En modell som er bedre generelt kan være svakere på din spesifikke mal, og det er verdt å vite før du flytter produksjonsarbeid over på den.

Oppdater ruting per oppgave, ikke i sin helhet. Flytt kategoriene der den nye modellen klart vant, og la resten være.

Vent to uker på begrensningene. Feilmodusene til en ny modell viser seg etter omtrent to uker med bred bruk, og de er sjelden i lanseringen.

For det generelle rammeverket, se hvordan velge en AI-modell, og for mekanikken bak å kjøre to modeller på ett prompt, se sammenligne modeller side ved side.