Modellvalg: Riktig modell for riktig jobb

Gevinster:

• Kan sammenligne modellfamilie (rask/balansert/kraftig) på kapasitet, hastighet og kostnad
• Designer modellvalg og rutingstrategier i henhold til oppgavens kompleksitet
• Baserer modellvalg på bevis med et lite sett med evalueringer

Den enkeltavgjørelsen som avgjør mest mulig valuta for pengene og kvaliteten i LLM-integrasjon, er hvilken modell du bruker. Den vanlige refleksen er "velg den sterkeste modellen"; Dette betyr imidlertid ofte unødvendige kostnader og forsinkelser. Den riktige tilnærmingen er å velge den letteste modellen som utfører hver oppgave og basere det valget på måling, ikke gjetting. I denne enheten vil du sammenligne modellfamilien på kapasitet/hastighet/kostnad-aksen, etablere en modellrutingsstrategi i henhold til oppgavekompleksitet, og bevise valget med et lite sett med evalueringer.

Forstå modellfamilien

Leverandører tilbyr generelt tre klasser: rask/billig, stabil og kraftig. Forholdet mellom dem er oppsummert på tre akser: evne (kraft til å løse vanskelige oppgaver), hastighet (latens), kostnad (tokenpris).

klasse

eksempel

talent

hastighet

Kostnad

Tilgjengelige oppgaver

raskt

Haiku 4.5

medium

veldig høy

lav

Klassifisering, merking, kort oppsummering, orientering

balansert

sonett 5

høy

høy

medium

Generelle formål, koding, flertrinnsflyt, mest agentarbeid

sterk

Opus 4.8

høyest

medium

høy

Kompleks resonnement, autonome oppgaver på lang rekkevidde, vanskelig analyse

Kritisk innsikt: Den kraftigere modellen gir ikke bedre resultater på alle jobber. I en enkel «haster eller ikke»-merking gir den sterke modellen og den raske modellen samme riktige svar; den eneste forskjellen er at den kraftige er 5 ganger dyrere og tregere. Ekstra talent produserer verdi bare når oppdraget krever det.

Trinn for trinn: Hvordan velge en modell?

1. Klassifiser oppgaven. Er det rutinemessig/mønstret (merking, slutning), eller åpent/multi-trinn (analyse, planlegging, kode)?
2. Start med den letteste kandidaten. Prøv det med den raske modellen. Hvis det er nok, stopp.
3. Hvis det ikke er nok, gå opp til en høyere klasse. Hvis nøyaktigheten er lav, gå til den balanserte, hvis det ikke er nok, gå til den sterke.
4. Mål, ikke gjett. Sammenlign nøyaktigheten og kostnadene for hver kandidat med et lite sett med eval (nedenfor).
5. Sett opp omdirigering. I stedet for å koble til en enkelt modell, fordel oppgaven til riktig modell med en "ruter".

Modellruting

Virkelige arbeidsmengder er blandede: de fleste innkommende forespørsler er enkle, noen er vanskelige. Det er bortkastet å sende dem alle til den kraftige modellen; Å sende dem alle til den raske modellen reduserer kvaliteten. Ruting løser dette: en billig modell (eller en enkel regel) klassifiserer oppgaven først, deretter går jobben til riktig modell.

# Ruterprompt (fungerer med billig modell) Klassifiser den innkommende forespørselen i henhold til vanskelighetsgraden. Returner bare følgende JSON:{"difficulty": "simple|complex"}Enkel: enkelttrinn, formel, kortsvar.Kompleks: krever flertrinns resonnement, analyse eller lang generering.Forespørsel: """{{request}}"""

• gå til enkel → rask modell (billig, rask).
• gå til kompleks → kraftig modell (dyr, men nødvendig).

Dette mønsteret reduserer gjennomsnittskostnaden betydelig fordi mesteparten av trafikken generelt er enkel.

Tips: En henvisningsbeslutning krever ikke alltid en LLM. Enkle regler som "Gå til rask modell hvis tekst er mindre enn 20 ord" er også en veiledning og gir null ekstra symbolkostnad. Prøv regelen først.

Koble valg til bevis: The Small Eval Cluster

Ikke velg en modell basert på "det ser bedre ut for meg". Eval (evalueringssett) er et lite sett med prøver der det riktige svaret er kjent; du kjører hver modell på dette settet og måler nøyaktighet, kostnader og ventetid.

# Eval oppsett mal1) Samle 20-50 virkelige eksempler, håndskriv "riktig svar" på hver.2) Kjør hver modell (rask/balansert/sterk) på dette settet.3) For hver modell: antall korrekte, gjennomsnittlig gjennomstrømning tokens, kostnad per forespørsel, gjennomsnittlig tid.4) Velg modellen som "gir tilstrekkelig nøyaktighet billigste".

# Eval sammenligningstabell (fyll) Modell | Nøyaktighet | Kostnad per forespørsel | Gjennomsnittlig varighetHaiku | ...% | ... $ | ... snSonnet | ...% | ... $ | ... snOpus | ...% | ... $ | ...sek

Svak forespørsel / sterk forespørsel (beslutning om modellvalg)

# SVAK (ikke grunnlag for beslutning)La oss bruke den beste modellen, budsjett er ikke viktig.

# STERK (avgjørelse basert på måling) I eval av 50 prøver ga Haiku 96 % nøyaktighet, Sonnet ga 97 % nøyaktighet; Forskjellen er statistisk ubetydelig. Haiku ble valgt fordi det er 5 ganger billigere og 2 ganger raskere. Hvis nøyaktigheten faller under 95 %, vil beslutningen om å oppgradere til Sonnet bli tatt automatisk.

Kraftig versjon; binder utvalget til et tall, en terskel og en eskaleringsregel. Dette både forsvarer dagens beslutning og styrer fremtidige endringer.

Tre minivesker

Tilfelle 1 - Røm fra den overveldende modellen. Et kundesenter produserte alle samtalesammendrag med Opus; månedsregningen var høy. Ved 40-prøver var Sonnet 1 % bak Opus i nøyaktighet, men kostet en tredjedel. De flyttet oppsummeringsverket til sonetten; månedlige kostnader falt fra $9000 til $3100, uten kvalitetsklager.

Tilfelle 2 — Blandet trafikk med omdirigering. 80 % av et juridisk teknologiteams forespørsler var enkel dokumentmerking, 20 % var kompleks kontraktsanalyse. De sendte dem alle til den mektige modellen. De la til en billig ruter og distribuerte enkle jobber til Haiku og komplekse jobber til Opus; gjennomsnittlig forespørselskostnad falt med 64 %, mens analysekvaliteten ble opprettholdt.

Case 3 — Kostnaden ved nedbemanning uten å måle. For å redusere kostnadene reduserte ett team kompleks medisinsk kodeutvinning direkte til den raske modellen; De evalerte ikke. I live falt nøyaktigheten fra 92 % til 78 %, noe som resulterte i en retur av ukorrekte slutninger. De måtte evaluere først: den oppgaven krevde den kraftige modellen. Leksjon: både reduksjon og høyde gjøres ved måling.

Vanlige feil

• Den "sterkeste modellen"-refleksen: Sløsing og unødvendig forsinkelse i enkle oppgaver.
• Endre modellen uten å måle: Både reduksjon og forstørrelse er risikabelt uten eval.
• Låsing til en enkelt modell: Ruting i blandet trafikk er ofte mer effektivt.
• Tar alltid feil av ruteren for LLM: Enkle regler kan fungere uten kostnad.
• Ikke sette en boost-terskel: Hva skjer hvis nøyaktigheten faller bør defineres på forhånd.
• Ikke fikse modellversjonen: Registrer hvilken modell/versjon du jobber med i produksjonen; Versjonsendring kan endre atferd.

Deeper: Perpetuating Eval and Incremental Trial

Modellvalg er ikke en engangsbeslutning. Leverandører introduserer nye modeller, prisene endres, jobbbeskrivelsen din utvikler seg. Så sett opp eval-klyngen én gang og ikke glem; hold det som et levende vesen. Når en ny modell kommer ut, kjører du de samme 20-50 prøvene gjennom den, oppdaterer tabellen og tar avgjørelsen på nytt. Dette beskytter deg mot "mønsterbytteintuisjon"-fellen.

Den andre avanserte teknikken er fallback/kaskademønsteret. Du gir oppgaven til den billige modellen først; Hvis utdataene har lav konfidens eller bekreftelseslaget (enhet 11) avviser det, eskalerer du den samme forespørselen. Så det meste av trafikken løses på den billige modellen, med bare den resterende minoriteten som går til den dyre modellen. Dette er både billigere og mer holdbart enn den faste enkeltmodelltilnærmingen.

Det tredje punktet er at eval inkluderer ikke bare nøyaktighet, men også kostnad og latens. Hvis en modell er 1 % mer nøyaktig, men 3 ganger dyrere og 2 ganger tregere, er avveiningen ikke verdt det for de fleste jobber. Ta avgjørelsen langs tre akser (nøyaktighet, kostnad, latens) og definer en "tilstrekkelighetsterskel": "hvis nøyaktigheten er over 95 %, velg den billigste."

Registrer til slutt hvilken modell/versjon du brukte i produksjonen. Hvis utskriftskvaliteten endres en dag, er det første du vil se på om modellversjonen har endret seg. Versjonssporbarhet gjør det raskere å finne årsaken til kvalitetsproblemer.

En annen advarsel: eval-klyngen bør representere den faktiske arbeidsmengden din. En eval som kun består av enkle eksempler skjuler seg der modellen snubler i vanskelige saker og lurer deg inn i falsk tillit. En god eval; Den inkluderer vanlige enkle eksempler så vel som hjørnesaker du møter i virkeligheten (tvetydige, ufullstendige, motstridende input). Denne vanskelige minoriteten avgjør modellvalget ditt, fordi hver modell lykkes i den enkle majoriteten uansett. Hold Eval frisk og representativ ved å gi den med jevne mellomrom nye ekte eksempler.

Oppsummert

Den rette modellen er den letteste modellen som får jobben gjort; Kraftigere er ikke bedre i alle jobber, det er bare dyrere og tregere. Å klassifisere oppgaven og ta utgangspunkt i den letteste kandidaten, fordele den blandede trafikken med ruting og underbygge utvalget med et lite sett med evals reduserer kostnadene mange ganger samtidig som kvaliteten opprettholdes.

Søknadsoppgave

Velg en arbeidsmengde. (1) Klassifiser oppgaven som enkel/kompleks. (2) Design et lite eval sett med 20 virkelige eksempler (med deres riktige svar). (3) Lag en plan for å fylle ut sammenligningstabellen for nøyaktighet/kostnad/tid for de tre modellklassene. (4) Hvis du har blandet trafikk, skriv en rutingregel og sett en eskaleringsterskel.

sjekkliste

• [ ] Jeg kan sammenligne modellfamilien på kapasitet/hastighet/kostnad-aksen.
• [ ] Jeg kan bruke prinsippet om den "letteste vellykkede modellen".
• [ ] Jeg kan sette opp modellruting i henhold til oppgavens kompleksitet.
• [ ] Med et lite sett med eval kan jeg binde utvalget til bevisene.
• [ ] Jeg kan definere en oppgraderings-/degraderingsterskel.