Miksi kaikkein kyvykkäin tekoälymalli ei välttämättä ole oikea valinta sovelluksellesi

On tietynlainen turvallisuuden tunne valitaessa voimakkain malli. Kun rakennat tekoälykäyttöistä tuotetta, tuntuu vastuulliselta (melkein loogiselta) valita voimakkain saatavilla oleva malli. GPT-4o. Claude Opus. Gemini Ultra. Nämä ovat vaikuttavia teknologioita, ja kukaan ei koskaan menettänyt työtään valitsemalla viisaan työkalun huoneessa.

Poikkeuksena on kuitenkin se, että… Projektit laajenevat. Kustannukset kasvavat. Viiveet alkavat vaivata. Ja noin kuukauden kolmen paikkeilla tiimi alkaa esittää epämukavia kysymyksiä siitä, miksi yksinkertainen automaattisen täydennysominaisuus polttaa API-luottokortteja kuin startup-yritys, jolla on venture-rahastot ja ei vastuuta.

Asia on se, että “kyvykkäin” ja “soveltuvin” ovat kaksi eri standardia. Tekoälysovelluskehityspalvelujen tarjoajat valitsevat malleja arvioinnin perusteella, ei johtajan sijoitusten perusteella.

Suurempi ei välttämättä ole parempi

Rajamalli toimii poikkeuksellisen hyvin ihanteellisissa olosuhteissa, mutta se on kallista käyttää, käsittelee virheellisiä syötteitä huonosti ja ylittää vaatimukset yksinkertaisissa tehtävissä.

GPT-4o voi kirjoittaa runoja, perustella oikeudellisia sopimuksia, korjata koodia ja selittää kvantti-sideyhteyden kymmenenvuotiaalle, joskus samassa vastauksessa. Se on aidosti merkittävä. Mutta jos sovelluksesi tiivistää asiakastukipyyntöjä tai poistaa rakenteellista tietoa laskuista, maksat kyvyistä, joita ei käytetä.

Pienemmät, erikoistuneet mallit käsittelevät kohdennettuja tehtäviä vaikuttavalla tarkkuudella:

• GPT-4o mini kattaa useimmat kielitehtävät noin 15-kertaisella alhaisemmalla kustannuksella kuin GPT-4o
• Claude Haiku on rakennettu nopeuteen ja tehokkuuteen suurivolyymisissä, rakenteellisissa työkuormissa
• Mistral 7B ja Llama 3.1 8B ovat avoimen lähdekoodin vaihtoehtoja, jotka suorittavat nopeasti ja hienosäätöä hyvin

Ero näiden ja rajamallien välillä pienenee huomattavasti, kun tehtävä on kapea ja ohjaukset on suunniteltu hyvin.

Kustannuslaskelma, josta kukaan ei puhu suunnittelukokouksissa

Rajamallien API-hinnat voivat olla 10-30-kertaisia korkeammat kuin kevyempien vastineiden per tokeni. Se ero kuulostaa abstraktilla, kunnes mallinnat sen mittakaavassa.

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

Sama ominaisuus. Hyvin erilainen voittojen tarina.

Jotkut tiimit suorittavat hybridi-arkkitehtuureja, jossa yksinkertaiset luokittelutehtävät ohjataan kevyempiin malleihin, kun taas raskaammat mallit pidetään kompleksisemmille generointi- tai päättelyvaiheille. Yritykset kuten Martian ja RouteLLM ovat kehittäneet työkaluja tällaisen mallin reititykseen. Se ei ole glamouria, mutta se on sellaista, joka tekee CFO:iden merkittävästi rentoutuneemmaksi.

Viive on käyttökokemusongelma

On syy, miksi nopea ruoka on olemassa. Ihmiset eivät aina halua viiden ruokalajin ateriaa. Joskus he haluavat vastauksensa nyt.

Rajamallit ovat hitaampia. Ei aina paljon, mutta riittävästi, jotta se merkitsee reaaliaikaisissa sovelluksissa. Jos käyttäjät odottavat tekoälyvastauksia keskusteluliittymässä, chat-rajapinnassa tai live-koodin apulaisessa, vastausviive muotoilee suoraan, miten tuote tuntuu. Malli, joka vie 4-6 sekuntia vastata, alkaa tuntua epäluotettavalta, vaikka tuloste on teknisesti ylempää tasoa.

Sääntö: Jos käyttäjä näkee latauspyörää, jokainen ylimääräinen sekunti vähentää luottamusta.

Haiku, Mistral ja Llama 3.1 8B suorittavat huomattavasti nopeammin (joskus 3-5 kertaa nopeammin) samanlainen kuormitusolosuhteissa. Käyttäjän näkökulmasta tärkeissä ominaisuuksissa, joissa havaittu nopeus on merkittävä, se ei ole vähäpätöinen asia. Se on tuotepäätös.

Ohjausmuuttuja, joka muuttaa kaiken

Tässä on jotain, jota yleensä ohitetaan mallin vertailuketjuissa: hyvin suunniteltu ohjaus kevyemmässä mallissa usein voittaa laiskan ohjauksen rajamallissa.

Tulosteen laatu on tuote mallin kyvystä JA ohjauslaadusta. Kun tiimit panostavat ohjaussuunnitteluun (selkeät ohjeet, rakenteelliset tulostemuodot, vähäisiä esimerkkejä, hyvin määritellyt rajoitukset), kevyemmät mallit suorittavat paljon yläpuolellaan olevaa ilmoitettua katossa.

Muutamia työkaluja, joita kannattaa tietää tässä:

• LangChain ja DSPy ohjausputkien koostamiseen ja optimointiin
• Guidance rajoitettuun generointiin ja rakenteellisiin tulosteisiin
• PromptFoo järjestelmällisiin ohjaustestauksiin malleissa

Jotkut vaikuttavimmat tekoälyominaisuudet tuotannossa tänään suorittavat malleilla, jotka eivät rikkoneet kärkipaikkaa minkään kyvyn johtajan listalla. Ne suorittavat vain todella hyvillä ohjauksilla.

Hienosäätö muuttaa yhtälön

Vertailu rajamallin ja pienemmän avoimen lähdekoodin mallin välillä näyttää erilaiselta, kun hienosäätö tulee kuvaan. Llama 3.1 8B-malli, joka on hienosäätelty tietyllä alueella (terminologiasi, reunatapauksesi, tulostemuodosi), voi suorittaa GPT-4o:ta paremmin tietyssä tehtävässä.

Se ei ole hypoteettinen. Yritykset terveydenhuollossa, lakitekniikassa ja e-commerce-toimialalla ovat osoittaneet sen useasti.

Missä aloittaa hienosäätö:

• Hugging Face avoimen lähdekoodin mallin isäntä, tietokantoja ja koulutusinfrastruktuuria varten
• Together AI nopeisiin, edullisiin hienosäätöön suosituilla avoimilla malleilla
• Replicate mukautettujen mallien käyttöönotto ilman oman GPU-infrastruktuurin hallintaa

Hienosäätö vaatii etukäteen investoinnin: datan kuratointi, laskentaaika, arviointityö. Mutta suurivolyymisissä, aluekohtaisissa tehtävissä taloudelliset seikat usein ovat huomattavasti sen edullisia.

Turva ja tietoresidenssi eivät ole jälkijunia

Jotkut sovellukset eivät voi lähettää tietoja kolmannen osapuolen API:lle lainkaan. Tarkastele:

• Terveydenhuollon alustoja, jotka toimivat HIPAA:n alaisuudessa
• Rahoitusvälineitä, jotka käsittelevät henkilötietoja tai säänneltyjä transaktiotietoja
• Yrityssovelluksia, joilla on tiukat tietoresidenssivaatimukset

Nämä ympäristöt ovat rajoituksia, joita mikään rajamalli-API ei voi kiertää, riippumatta kyvystä. Itseisännitettyjä malleja, olipa se sitten paikallinen tai yksityinen pilvi, on ainoa eteenpäin vievä polku. Se tarkoittaa avoimen lähdekoodin malleja, kuten Llama 3, Mistral tai Phi-3, joita suoritetaan oman infrastruktuurin ympärillä. Rajamalli, jota et voi laillisesti käyttää tuotannossa, ei ole oikea valinta, piste.

Arviointivaihe, jonka tiimit jatkuvasti ohittavat

Useimmat tiimit valitsevat mallin olettamalla, että kallis on paras ilman testausta. Mitä heidän pitäisi tehdä, on suorittaa järjestelmällisiä arviointeja edustavista näytteistä heidän todellisesta käyttötarkoituksestaan.

Tässä on prosessi, joka toimii:

1. Rakenna arviointijoukko 100-200 edustavaa syötettä odotettavilla tulosteilla
2. Suorita ne kaksi tai kolme ehdokasmallia realistisissa olosuhteissa
3. Pisteytä todellisia kriteerejäsi: tarkkuus, muodon mukaisuus, sävy, viive, kustannus per kutsu
4. Päätä perustuvasti, ei väkisin tai johtajan sijoituksiin

Työkalut kuten Braintrust, PromptFoo ja Weights & Biases Prompts tekevät tämänkaltaisen järjestelmällisen arvioinnin helpoksi ilman tutkimustausta. Se vie muutaman tunnin asettaa. Hyöty on, ettei valitse väärää mallia kuuden kuukauden ajaksi.

Kun rajamalli on todella oikea valinta

Reilusti: on tehtäviä, joissa rajamallit ansaitsevat hinnastonsa.

Käytä rajamallia, kun:

• Tehtävä vaatii monimutkaisia, usean askeleen päättelyä ilman selkeää mallia
• Tulosteen laadun vaihtelu on kallista ja tilavuus on suhteellisen alhainen
• Tarvitset laajaa maailmantietoa tai hienostunutta arviointia, jota ei voi ohjata
• Olet prototyyppi ja et ole määritellyt tehtävän rajoja

Pysy kevyemmässä mallissa, kun:

• Tehtävä on määritelty ja toistuva
• Nopeus ja kustannus merkitsevät tilavuudessa, jota suoritat
• Voit panostaa ohjaussuunnitteluun tai hienosäätöön
• Tietoresidenssi- tai vaatimussäännöt estävät kolmannen osapuolen API:t

Asia ei ole välttää voimakkaita malleja. Asia on valita tietoisesti, näyttöön perustuen, ei olettaa suurimman nimen johtajan listalla, koska se tuntui turvalliselta valintlta.

Yhteenveto

Tekoälymallin valinta sovelluksellesi ei pitäisi tuntua prestiisikilpailulta. Kyvykkäin malli paperilla ei välttämättä ole oikea malli ongelmaasi, tai yleensä.

Sovella mallia tehtävään. Suorita arviointeja todellisilla tiedoilla. Ottaa huomioon viiveen, kustannukset, turvavaatimukset ja tiimisi kyky ohjaussuunnitteluun tai hienosäätöön. Parhaat tekoälytuote päätökset perustuvat niihin yksityiskohtiin, ei siihen, mikä yritys julkaisi loistavimmat numerot viime kuussa.

Tiimit, jotka toimittavat suuria tekoälytuotteita, eivät välttämättä suorita voimakkaimpia malleja. He suorittavat soveltuvin malleja.