Oikean tekoälymallin valinta: kustannusten ja suorituskyvyn tasapaino

Tehokkaimman mallin valitseminen tuntuu tietyllä tavalla turvalliselta. Kun rakentaa tekoälyä hyödyntävää tuotetta, tehokkaimman saatavilla olevan mallin valinta tuntuu vastuulliselta, lähes loogiselta. GPT-4o. Claude Opus. Gemini Ultra. Ne ovat vaikuttavaa teknologiaa, eikä ketään ole koskaan erotettu siksi, että hän valitsi joukon älykkäimmän työkalun.

Tähän liittyy kuitenkin varaus. Projektit paisuvat. Kustannukset karkaavat. Viivettä alkaa kertyä. Noin kolmannen kuukauden kohdalla tiimi alkaa kysellä kiusallisia kysymyksiä siitä, miksi yksinkertainen automaattinen tekstintäydennys kuluttaa API-krediittejä kuin riskirahalla toimiva startup, jolla ei ole tulosvastuuta.

Asia on näin: ”kyvykkäin” ja ”sopivin” ovat kaksi hyvin erilaista valintaperustetta. Tekoälysovellusten kehityspalvelujen tarjoajat valitsevat mallit arviointien, eivät suorituskykyrankingien perusteella.

Suurempi ei automaattisesti ole parempi

Alan huippumalli toimii poikkeuksellisen hyvin ihanteellisissa oloissa, mutta sen käyttö on kallista, se käsittelee puutteellisia syötteitä huonosti ja sen kyvyt ylittävät yksinkertaisten tehtävien tarpeet.

GPT-4o voi kirjoittaa runoja, analysoida oikeudellisia sopimuksia päättelyn avulla, korjata koodia ja selittää kvanttilomittumista kymmenvuotiaalle, joskus samassa vastauksessa. Se on todella vaikuttavaa. Mutta jos sovelluksesi tiivistää asiakastukipyyntöjä tai poimii laskuista jäsenneltyä tietoa, maksat kyvyistä, jotka jäävät käyttämättä.

Pienemmät erikoistuneet mallit hoitavat rajatut tehtävät vaikuttavalla tarkkuudella:

• GPT-4o mini hoitaa useimmat kielitehtävät noin viidestoistaosalla GPT-4o:n kustannuksista
• Claude Haiku on suunniteltu nopeaksi ja tehokkaaksi suurten volyymien jäsenneltyihin työkuormiin
• Mistral 7B ja Llama 3.1 8B ovat avoimen lähdekoodin vaihtoehtoja, jotka toimivat nopeasti ja soveltuvat hyvin hienosäätöön

Ero näiden ja huippumallien välillä pienenee huomattavasti, kun tehtävä on rajattu ja kehotteet on suunniteltu hyvin.

Kustannuslaskelma, josta suunnittelukokouksissa ei puhuta

Huippumallien API-hinnat voivat olla tokenia kohden 10–30-kertaiset kevyempiin vastineisiin verrattuna. Ero kuulostaa abstraktilta, kunnes sen laskee suuren mittakaavan käytölle.

Oletetaan, että sovelluksesi tekee 500 000 API-kutsua kuukaudessa:

Sama ominaisuus, mutta aivan erilainen kate.

Jotkin tiimit käyttävät hybridiarkkitehtuuria: yksinkertaiset luokittelutehtävät ohjataan kevyille malleille ja raskaammat mallit varataan monimutkaiseen generointiin tai päättelyvaiheisiin. Esimerkiksi Martian ja RouteLLM ovat kehittäneet työkaluja juuri tällaiseen mallien väliseen reititykseen. Se ei ole hohdokasta insinöörityötä, mutta se saa talousjohtajat selvästi rentoutuneemmiksi.

Viive on käyttökokemuksen ongelma

Pikaruoan olemassaololle on syynsä. Ihmiset eivät aina halua viiden ruokalajin ateriaa. Joskus he haluavat vastauksen heti.

Huippumallit ovat hitaampia. Eivät aina paljon, mutta riittävästi, jotta sillä on merkitystä reaaliaikaisissa sovelluksissa. Jos käyttäjät odottavat tekoälyn vastausta keskustelukäyttöliittymässä, chatissa tai reaaliaikaisessa ohjelmointiavustajassa, vastausviive vaikuttaa suoraan tuotteen käyttötuntumaan. Malli, jolta vastaaminen vie 4–6 sekuntia, alkaa tuntua epäluotettavalta, vaikka tulos olisi teknisesti parempi.

Nyrkkisääntö: jos käyttäjä näkee latausilmaisimen, jokainen ylimääräinen sekunti vähentää luottamusta.

Haiku, Mistral ja Llama 3.1 8B toimivat huomattavasti nopeammin, joskus 3–5 kertaa nopeammin, vastaavassa kuormituksessa. Käyttäjille näkyvissä ominaisuuksissa, joissa koettu nopeus merkitsee, tämä ei ole vähäinen seikka. Se on tuotepäätös.

Kehotesuunnittelu muuttaa kaiken

Mallivertailuissa sivuutetaan usein tämä: hyvin laadittu kehote pienemmällä mallilla päihittää usein huolimattoman kehotteen huippumallilla.

Tuloksen laatu syntyy mallin kyvykkyydestä JA kehotteen laadusta. Kun tiimit panostavat kehotesuunnitteluun — selkeisiin ohjeisiin, jäsenneltyihin tulosmuotoihin, muutamaan esimerkkiin ja tarkasti määriteltyihin rajoitteisiin — pienemmät mallit suoriutuvat paljon näennäistä suorituskykykattoaan paremmin.

Muutamia hyödyllisiä työkaluja:

• LangChain ja DSPy kehoteputkien koostamiseen ja optimointiin
• Guidance rajoitettuun generointiin ja jäsenneltyihin tuloksiin
• PromptFoo kehotteiden järjestelmälliseen arviointiin eri malleilla

Jotkin tämän hetken vaikuttavimmista tuotannossa olevista tekoälyominaisuuksista toimivat malleilla, jotka eivät pääsisi yhdenkään kyvykkyysrankingin viiden kärkeen. Niissä vain käytetään todella hyviä kehotteita.

Hienosäätö muuttaa laskelmaa

Yleiskäyttöisen huippumallin ja pienemmän avoimen lähdekoodin mallin vertailu näyttää aivan erilaiselta, kun mukaan tulee hienosäätö. Llama 3.1 8B, joka on hienosäädetty oman alasi tiedoilla — terminologiallasi, poikkeustapauksillasi ja toivomallasi tulosmuodolla — voi päihittää GPT-4o:n juuri sinun tehtävässäsi.

Tämä ei ole hypoteesi. Terveydenhuollon, oikeusteknologian ja verkkokaupan yritykset ovat osoittaneet sen toistuvasti.

Mistä hienosäätö kannattaa aloittaa:

• Hugging Face avoimen lähdekoodin mallien isännöintiin, tietoaineistoihin ja koulutusinfrastruktuuriin
• Together AI suosittujen avointen mallien nopeisiin ja edullisiin hienosäätöajoihin
• Replicate mukautettujen mallien käyttöönottoon ilman oman GPU-infrastruktuurin hallintaa

Hienosäätö vaatii alkuinvestoinnin: datan kuratointia, laskenta-aikaa ja arviointityötä. Mutta suuren volyymin toimialakohtaisissa tehtävissä taloudellinen hyöty on usein huomattava.

Tietoturvaa ja tietojen sijaintia ei voi jättää jälkikäteen mietittäviksi

Jotkin sovellukset eivät voi lähettää tietoja kolmansien osapuolten API-rajapintoihin lainkaan. Ajatellaan esimerkiksi:

• HIPAA:n alaisia terveydenhuoltoalustoja
• taloussovelluksia, jotka käsittelevät henkilötietoja tai säänneltyä tapahtumadataa
• yritysohjelmistoja, joihin kohdistuu tiukkoja tietojen sijaintivaatimuksia

Näissä ympäristöissä on rajoitteita, joita mikään huippumallin API ei voi kiertää kyvykkyydestään riippumatta. Itse ylläpidetyt mallit, joko omissa tiloissa tai yksityisessä pilvessä, ovat ainoa etenemistapa. Se tarkoittaa Llama 3:n, Mistralin tai Phi-3:n kaltaisia avoimen lähdekoodin malleja omassa infrastruktuurissa. Huippumalli, jota et voi laillisesti käyttää tuotannossa, ei ole oikea valinta. Piste.

Arviointivaihe, jonka tiimit toistuvasti ohittavat

Useimmat tiimit valitsevat mallin testaamatta ja olettavat kalliin olevan paras. Sen sijaan niiden pitäisi tehdä jäsenneltyjä arviointeja todellista käyttötapaustaan edustavilla näytteillä.

Toimiva prosessi on seuraava:

1. Kokoa arviointiaineisto, jossa on 100–200 edustavaa syötettä ja niiden odotetut tulokset
2. Aja ne kahdella tai kolmella ehdokasmallilla realistisissa olosuhteissa
3. Pisteytä todellisten kriteeriesi mukaan: tarkkuus, muodon noudattaminen, sävy, viive ja kustannus kutsua kohden
4. Tee päätös datan, älä mututuntuman tai ranking-sijoitusten perusteella

Braintrustin, PromptFoon ja Weights & Biases Promptsin kaltaiset työkalut tekevät järjestelmällisestä arvioinnista mahdollista ilman tutkijataustaa. Käyttöönotto vie muutaman tunnin. Hyöty on siinä, ettei väärää mallia tule käytettyä kuutta kuukautta.

Milloin huippumalli todella on oikea valinta

Reiluuden nimissä on tehtäviä, joissa huippumallit todella ovat hintansa arvoisia.

Käytä huippumallia, kun:

• tehtävä edellyttää monimutkaista monivaiheista päättelyä ilman selkeää ratkaisupohjaa
• tulosten laadun vaihtelu on kallista ja volyymi suhteellisen pieni
• tarvitset laajaa yleistietoa tai vivahteikasta harkintaa, jota pelkillä kehotteilla ei voi korvata
• rakennat prototyyppiä etkä ole vielä määritellyt tehtävän rajoja

Pysy kevyemmässä mallissa, kun:

• tehtävä on hyvin määritelty ja toistuva
• nopeudella ja kustannuksilla on merkitystä käyttämässäsi volyymissa
• voit panostaa kehotesuunnitteluun tai hienosäätöön
• tietojen sijainti tai sääntöjen noudattaminen estää kolmansien osapuolten API-rajapintojen käytön

Tarkoitus ei ole välttää tehokkaita malleja. Tarkoitus on valita harkitusti ja näytön perusteella sen sijaan, että valitsisi oletuksena rankingin suurimman nimen vain siksi, että se tuntui turvalliselta.

Yhteenveto

Tekoälymallin valinnan ei pitäisi tuntua arvovaltakilpailulta. Paperilla kyvykkäin malli ei aina ole oikea malli ongelmaasi — eikä edes yleensä.

Sovita malli tehtävään. Tee arvioinnit todellisella datalla. Huomioi viive, kustannukset, tietoturvavaatimukset ja tiimin valmiudet kehotesuunnitteluun tai hienosäätöön. Parhaat tekoälytuotteita koskevat päätökset perustuvat näihin yksityiskohtiin, eivät siihen, mikä yritys julkaisi näyttävimmät luvut viime vuosineljänneksellä.

Erinomaisia tekoälytuotteita toimittavat tiimit eivät välttämättä käytä tehokkaimpia malleja. Ne käyttävät sopivimpia.