Bygge, købe eller finjustere: vælge AI-tilgang

De dyreste AI-fejl er næsten aldrig tekniske. De er arkitektoniske, begået i den første uge, før en linje kode er skrevet. Et team bygger en egen model, hvor et enkelt API-kald havde rakt, og brænder måneder på noget, en leverandør allerede tilbyder. Eller omvendt: et team læner sig op ad et token-API til en volumentung, privatlivsfølsom last, der råbte på selvhosting, og ser regningen og overholdelsesrisikoen stige sammen. Begge fejl kommer af at svare "bygge, købe eller finjustere" på instinkt i stedet for analyse.

Der findes ikke ét universelt rigtigt svar, og enhver, der giver dig ét uden at spørge om dine data, sælger noget. Svaret afhænger af tre ting: hvor følsomme dine data er, hvor meget volumen du kører, og hvor specialiseret din opgave er. Bliv klar på de, og beslutningen tager som regel sig selv.

Hvornår bare kalde et API

Til en generel opgave, ved lav eller moderat volumen, på ikke-følsomme data er en frontier-API næsten altid det rigtige første træk. Hurtigste vej til noget, der virker, ingen infrastruktur, evnen hos de bedste modeller uden driftsbyrden. At bygge noget eget her er for tidlig optimering — du løser et omkostnings- eller privatlivsproblem, du endnu ikke har, på bekostning af den fart, du behøver.

Vi siger gerne til en kunde, at svaret er en simpel API-integration, og at der ikke er noget projekt for os her. Det er ofte den rigtige, ærlige anbefaling.

Hvornår finjustere en lille model

Regnestykket ændres, når to ting er sande: opgaven er smal og gentaget, og dataene vil du helst ikke sende til en tredjepart. Til et veldefineret job, du kører millioner af gange på følsomme input, matcher en finjusteret lille model ofte API'ets kvalitet på den opgave, til en brøkdel af driftsomkostningen, og holder hver post internt. Volumen retfærdiggør forarbejdet, privatliv kontrollen.

Dette tilfælde overser teams oftest, fordi API'et føles lettere i starten. Det er lettere i starten — og så kommer volumen, og token-omkostningen, der så triviel ud i demoen, bliver den største linje i budgettet.

Hvornår bygge mere om modellen

Nogle problemer løses ikke af noget enkelt modelkald, uanset hvor godt. Flertrins arbejdsgange, hentning over egen viden og regulerede beslutninger, der behøver dokumentation og tilsyn, kræver reelt ingeniørarbejde om modellen: orkestrering, hentelag, værn, evaluering, overvågning. Modellen er en komponent; systemet er produktet. At undervurdere dette er, hvordan en lovende prototype ikke bliver en pålidelig funktion.

Fejlen her er det modsatte af for tidlig optimering — at antage, at fordi modellen er kapabel, er systemet om den trivielt. Det er sjældent.

Omkostningskurven ingen tegner

Den mest nyttige øvelse er at tegne omkostning mod volumen for hvert alternativ, før du beslutter. En API har næsten nul fast omkostning og lineær omkostning per forespørgsel; en selvhostet model reel fast omkostning og marginalomkostning nær nul. Disse linjer krydser et sted, og hvor afhænger helt af dine tal. Under vinder API'et; over vinder selvhosting, med voksende gab.

Teams anslår rutinemæssigt dette punkt forkert, næsten altid højere end det er, fordi API-regningen er usynlig, til den kommer. Tegnet ærligt mod reel volumen bliver gætteriet en beslutning.

Privatliv kan tilsidesætte regnestykket helt

Nogle gange er omkostningskurven ikke engang afgørende. Kan dine data virkelig ikke forlade din kontrol — af juridiske, regulatoriske eller kontraktuelle grunde — kan selvhosting være det eneste levedygtige alternativ uanset volumen, for alternativet er ikke "lidt dyrere", men "ikke tilladt". Så sætter privatlivskravet arkitekturen, og omkostningsanalysen virker inden for den grænse.

At være klar på, hvilken faktor der faktisk binder — omkostning, volumen eller privatliv — er halvdelen af beslutningen. De peger ikke altid samme vej, og at vide, hvilken der styrer, forhindrer, at man optimerer det forkerte.

Hybrider er ofte det ægte svar

Den ærlige anbefaling er ofte ikke ét af de tre, men en kombination. En finjusteret lille model tager det volumentunge normaltilfælde billigt og privat, mens en frontier-API kaldes kun til de sjældne, svære tilfælde. Hentning forankrer en købt model i dine data uden at træne noget. De stærkeste arkitekturer blander bevidst.

Beslut på tal, ikke mode

Vores tilgang er at benchmarke de ærlige muligheder mod dine faktiske data og begrænsninger, før vi anbefaler noget, for arkitekturen, der er billigst på papir, er ofte ikke billigst i produktion, og det, der er moderne dette kvartal, er ikke nødvendigvis det, dit problem behøver. Bygge, købe og finjustere er ikke ideologier, men værktøjer med forskellige profiler. Det rigtige valg er det, dine egne målinger understøtter — og det ved man kun ved at måle, før man forpligter sig, ikke efter.