Velg riktig AI-modell: balansen mellom kostnad og ytelse

Det finnes en viss komfort i å velge den mest kraftige modellen. Når du bygger et AI-drevet produkt, føles det ansvarlig (nesten logisk) å velge den mest kraftige modellen som er tilgjengelig. GPT-4o. Claude Opus. Gemini Ultra. Disse er imponerende teknologier, og ingen har noen gang blitt sparket for å velge det smarteste verktøyet i rommet.

Bortsett fra, vel, det finnes et forbehold. Prosjekter blir for store. Kostnadene løper løpsk. Latensen kryper inn. Og et sted rundt måned tre begynner teamet å stille ubehagelige spørsmål om hvorfor en enkel autocomplete-funksjon brenner gjennom API-kreditter som en startup med venture-finansiering uten å måtte stå til ansvar.

Her er det viktigste: “mest kapabel” og “mest passende” er to helt forskjellige standarder. Leverandører av AI-app-utviklingstjenester velger modeller basert på evalueringer, ikke leaderboard-rangeringer.

Større er ikke automatisk bedre

En frontier-modell presterer eksepsjonelt godt under ideelle forhold, men er dyr i drift, håndterer ufullstendige inndata dårlig og har flere evner enn enkle oppgaver krever.

GPT-4o kan skrive poesi, resonere gjennom juridiske kontrakter, feilsøke kode og forklare kvantesammenfiltring til en tiåring, noen ganger i samme respons. Det er virkelig imponerende. Men hvis din app oppsummerer kundestøttehenvendelser eller trekker ut strukturerte data fra fakturaer, betaler du for evner som ikke blir brukt.

Mindre, spesialiserte modeller håndterer fokuserte oppgaver med imponerende nøyaktighet:

• GPT-4o mini dekker de fleste språkoppgaver til omtrent 15 ganger lavere kostnad enn GPT-4o
• Claude Haiku er bygget for hastighet og effektivitet ved store volumer av strukturerte arbeidsoppgaver
• Mistral 7B og Llama 3.1 8B er alternativer med åpen kildekode som kjører raskt og egner seg godt for finjustering

Gapet mellom disse og frontier-modellene blir betydelig mindre når oppgaven er smal og promptene er godt konstruert.

Kostnadsmatematikken ingen snakker om på planmøter

API-prising for frontier-modeller kan være 10 til 30 ganger høyere per token enn deres lettere motparter. Det gapet høres abstrakt ut til du modellerer det ut i skala.

La oss si at appen din gjør 500 000 API-forespørsler per måned:

Samme funksjon. Svært forskjellige fortjenestemarginer.

Noen team kjører hybrid-arkitekturer, ruter enkle klassifiseringsoppgaver til lette modeller mens de reserverer de tyngre modellene for komplekse genererings- eller resonneringssteg. Selskaper som Martian og RouteLLM har bygget verktøy spesifikt for denne type modell-ruting. Det er ikke glamourøst ingeniørarbeid, men det er den type ting som gjør CFO-er merkbart mer avslappet.

Latens er et problem for brukeropplevelsen

Det finnes en grunn til at hurtigmat eksisterer. Folk ønsker ikke alltid et femretters måltid. Noen ganger ønsker de svaret nå.

Frontier-modeller er langsommere. Ikke alltid mye, men nok til å merke i sanntidsapplikasjoner. Hvis dine brukere venter på AI-responser i et samtalebasert brukergrensesnitt, et chatgrensesnitt eller en live-kodinghjelper, påvirker responstid direkte hvordan produktet føles. En modell som tar 4-6 sekunder å svare begynner å virke upålitelig, selv om utgangen teknisk sett er overlegen.

Regelen er: Hvis en bruker ser en lastingspinner, reduserer hvert ekstra sekund tilliten.

Haiku, Mistral og Llama 3.1 8B kjører betydelig raskere (noen ganger 3 til 5 ganger raskere) under lignende lastforhold. For bruker-orienterte funksjoner hvor oppfattet hastighet betyr noe, er dette ikke en liten overveielse. Det er et produktvalg.

Prompt Engineering-variabelen (som endrer alt)

Her er noe som blir glattet over i modell-sammenligningstråder: en godt konstruert prompt på en mindre modell slår ofte en lat prompt på en frontier-modell.

Utgangskvalitet er et produkt av modell-kapasitet OG prompt-kvalitet. Når team investerer i prompt-engineering (klare instruksjoner, strukturerte utdataformater, noen få demonstrasjonseksempler, godt definerte begrensninger) presterer mindre modeller langt over sitt tilsynelatende kapasitetstak.

Noen verktøy som er verdt å kjenne til her:

• LangChain og DSPy for å komponere og optimere prompt-pipelines
• Guidance for begrenset generering og strukturerte utdata
• PromptFoo for å kjøre systematiske prompt-evalueringer over modeller

Noen av de mest imponerende AI-funksjonene i produksjon i dag kjører på modeller som ikke ville knekke topp fem på noen kapabilitetsliste. De kjører bare på virkelig gode prompter.

Finjustering endrer ligningen

Sammenligningen mellom en generell frontier-modell og en mindre modell med åpen kildekode ser veldig forskjellig ut når finjustering kommer inn i bildet. En Llama 3.1 8B-modell finjustert på dine domenespesifikke data (din terminologi, dine kanttilfeller, ditt foretrukne utdataformat) kan overgå GPT-4o på ditt spesifikke oppdrag.

Dette er ikke et hypotetisk scenario. Selskaper i helsevesen, juridisk teknologi og e-handel har demonstrert det gjentatte ganger.

Hvor å starte med finjustering:

• Hugging Face for hosting av modeller med åpen kildekode, datasett og treningsinfrastruktur
• Together AI for rask, rimelig finjustering på populære åpne modeller
• Replicate for å deployere tilpassede modeller uten å håndtere din egen GPU-infrastruktur

Finjustering krever forhåndsinvestering: utvelgelse og klargjøring av data, beregningstid og evalueringsarbeid. Men for høy-volum, domene-spesifikke oppgaver, blir det økonomiske regnestykket ofte betydelig gunstigere.

Sikkerhet og krav til datalagringssted kan ikke være en ettertanke

Noen applikasjoner kan ikke sende data til tredjeparts-API-er i det hele tatt. Vurdér:

• Helseplattformer som opererer under HIPAA
• Finansielle verktøy som håndterer PII eller regulerte transaksjonsdata
• Bedriftsprogramvare med strenge krav til datalagringssted

Disse miljøene har begrensninger som ingen frontier-modell-API kan omgå, uansett kapabilitet. Modeller driftet på egen infrastruktur, enten på stedet eller i en privat sky, er den eneste veien videre. Det betyr modeller med åpen kildekode som Llama 3, Mistral eller Phi-3 som kjører på din egen infrastruktur. En frontier-modell du ikke kan lovlig bruke i produksjon, er ikke det riktige valget, full stopp.

Evalueringssteget team stadig hopper over

De fleste team velger en modell ved å anta at den dyreste er best uten å teste den. Hva de burde gjøre, er å kjøre strukturerte evalueringer på et representativt utvalg av deres faktiske brukstilfelle.

Her er en prosess som fungerer:

1. Bygg en evalueringssamling av 100 til 200 representative inndata med forventede utdata
2. Kjør dem gjennom to eller tre kandidat-modeller under realistiske forhold
3. Gi poeng etter dine faktiske kriterier: nøyaktighet, format-overensstemmelse, tone, latens, kostnad per oppkall
4. Avgjør basert på data, ikke magefølelse eller leaderboard-rangeringer

Verktøy som Braintrust, PromptFoo og Weights & Biases Prompts gjør denne type systematisk evaluering tilgjengelig uten en forskningsbakgrunn. Det tar noen timer å sette opp. Utbyttet er ikke å velge feil modell i seks måneder.

Når frontier-modellen faktisk er det riktige valget

For å være rettferdig: det finnes oppgaver hvor frontier-modeller virkelig tjener sin pris.

Bruk en frontier-modell når:

• Oppgaven krever kompleks resonnering i flere steg uten noen klar mal
• Variasjon i utdatakvaliteten er kostbar, og volumet er relativt lavt
• Du trenger bred verdenskunnskap eller nyansert dømmekraft som ikke kan erstattes med bedre formulerte prompter
• Du er i prototyping-fasen og har ikke definert oppgave-grensene ennå

Hold fast ved en lettere modell når:

• Oppgaven er godt definert og repetitiv
• Hastighet og kostnad betyr noe på volumet du kjører
• Du kan investere i prompt-engineering eller finjustering
• Krav til datalagringssted eller regelverksetterlevelse utelukker tredjeparts-API-er

Poenget er ikke å unngå kraftige modeller. Poenget er å velge bevisst, med bevis, i stedet for å standardisere til det største navnet på leaderboarden fordi det føles som det trygge valget.

Sammenfatting

Valg av en AI-modell for din applikasjon bør ikke føles som en prestisjekonkurranse. Den mest kapable modellen på papir er ikke alltid, og faktisk som regel ikke, det riktige valget for problemet ditt.

Match modellen til oppgaven. Kjør evalueringer på faktiske data. Faktorer inn latens, kostnad, sikkerhetskrav og ditt teams evne til prompt-engineering eller finjustering. De beste AI-produktvalgene er grunnlagt i disse spesifikke detaljene, ikke i hvilket selskap som publiserte de flotteste tallene forrige kvartal.

Teamene som leverer flotte AI-produkter kjører ikke nødvendigvis de mest kraftige modellene. De kjører de mest passende.