Bygge, kjøpe eller finjustere: velge AI-tilnærming

De dyreste AI-feilene er nesten aldri tekniske. De er arkitektoniske, gjort i den første uken, før en linje kode er skrevet. Et team bygger en egen modell der et enkelt API-kall hadde holdt, og brenner måneder på noe en leverandør allerede tilbyr. Eller omvendt: et team lener seg på et token-API for en volumtung, personvernsensitiv last som ropte på selvhosting, og ser regningen og samsvarsrisikoen stige sammen. Begge feilene kommer av å svare «bygge, kjøpe eller finjustere» på instinkt i stedet for analyse.

Det finnes ikke ett universelt riktig svar, og enhver som gir deg ett uten å spørre om dataene dine selger noe. Svaret avhenger av tre ting: hvor sensitive dataene er, hvor mye volum du kjører, og hvor spesialisert oppgaven er. Bli klar på de, og beslutningen tar vanligvis seg selv.

Når bare kalle et API

For en generell oppgave, ved lavt eller moderat volum, på ikke-sensitive data er en frontier-API nesten alltid det riktige første trekket. Raskeste vei til noe som virker, ingen infrastruktur, evnen til de beste modellene uten driftsbyrden. Å bygge noe eget her er for tidlig optimalisering — du løser et kostnads- eller personvernproblem du ennå ikke har, på bekostning av farten du trenger.

Vi sier gjerne til en kunde at svaret er en enkel API-integrasjon og at det ikke er noe prosjekt for oss her. Det er ofte den riktige, ærlige anbefalingen.

Når finjustere en liten modell

Regnestykket endres når to ting er sanne: oppgaven er smal og gjentatt, og dataene vil du helst ikke sende til en tredjepart. For en veldefinert jobb du kjører millioner av ganger på sensitive input, matcher en finjustert liten modell ofte API-ets kvalitet på den oppgaven, til en brøkdel av driftskostnaden, og holder hver post internt. Volum rettferdiggjør forarbeidet, personvern kontrollen.

Dette tilfellet overser team oftest, fordi API-et føles lettere i starten. Det er lettere i starten — og så kommer volumet, og token-kostnaden som så triviell ut i demoen blir den største linjen i budsjettet.

Når bygge mer rundt modellen

Noen problemer løses ikke av noe enkelt modellkall, uansett hvor godt. Flertrinns arbeidsflyter, innhenting over egen kunnskap og regulerte beslutninger som trenger dokumentasjon og tilsyn krever ekte ingeniørarbeid rundt modellen: orkestrering, innhentingslag, rekkverk, evaluering, overvåking. Modellen er en komponent; systemet er produktet. Å undervurdere dette er hvordan en lovende prototype ikke blir en pålitelig funksjon.

Feilen her er det motsatte av for tidlig optimalisering — å anta at fordi modellen er kapabel, er systemet rundt trivielt. Det er sjelden.

Kostnadskurven ingen tegner

Den mest nyttige øvelsen er å tegne kostnad mot volum for hvert alternativ før du bestemmer. En API har nesten null fast kostnad og lineær kostnad per forespørsel; en selvhostet modell reell fast kostnad og marginalkostnad nær null. Disse linjene krysser et sted, og hvor avhenger helt av tallene dine. Under vinner API-et; over vinner selvhosting, med økende gap.

Team anslår rutinemessig dette punktet feil, nesten alltid høyere enn det er, fordi API-regningen er usynlig til den kommer. Tegnet ærlig mot reelt volum blir gjettingen en beslutning.

Personvern kan overstyre regnestykket helt

Noen ganger er kostnadskurven ikke engang avgjørende. Kan dataene dine virkelig ikke forlate din kontroll — av juridiske, regulatoriske eller kontraktuelle grunner — kan selvhosting være det eneste levedyktige alternativet uansett volum, for alternativet er ikke «litt dyrere», men «ikke tillatt». Da setter personvernkravet arkitekturen, og kostnadsanalysen virker innenfor den grensen.

Å være klar på hvilken faktor som faktisk binder — kostnad, volum eller personvern — er halve beslutningen. De peker ikke alltid samme vei, og å vite hvilken som styrer hindrer at man optimaliserer feil ting.

Hybrider er ofte det ekte svaret

Den ærlige anbefalingen er ofte ikke ett av de tre, men en kombinasjon. En finjustert liten modell tar det volumtunge normaltilfellet billig og privat, mens en frontier-API kalles bare for de sjeldne, vanskelige tilfellene. Innhenting forankrer en kjøpt modell i dataene dine uten å trene noe. De sterkeste arkitekturene blander bevisst.

Bestem på tall, ikke mote

Tilnærmingen vår er å benchmarke de ærlige alternativene mot dine faktiske data og begrensninger før vi anbefaler noe, for arkitekturen som er billigst på papiret er ofte ikke billigst i produksjon, og det som er moteriktig dette kvartalet er ikke nødvendigvis det problemet ditt trenger. Bygge, kjøpe og finjustere er ikke ideologier, men verktøy med ulike profiler. Riktig valg er det dine egne målinger støtter — og det vet man bare ved å måle før man forplikter seg, ikke etter.