Jev AI -malli on rakennettu päätöksiä, ei proosaa varten

TypeSafe AI kuvaa Jeviä uudeksi transformer-pohjaiseksi malliksi, mutta ei suureksi kielimalliksi. Tekstitokenien generoimisen sijaan se palauttaa todennäköisyyksiä vaihtoehdoille, jotka kehittäjät määrittelevät etukäteen. TechCrunchin mukaan TypeSafe kutsuu näitä tuloksia ”kalibroiduiksi päätöksiksi”.

Raportin mukaan tällä suunnittelulla on kolme välitöntä seurausta.

Ensinnäkin malli asemoidaan halvemmaksi ja nopeammaksi kuin yleisen LLM:n käyttö luokittelutyyppiseen työhön. TechCrunch raportoi, että Jevin output-tokenit ovat ilmaisia ja sen input-tokenit mitataan miljardeissa, eivät miljoonissa.

Toiseksi tulosavaruus on rajattu. Jos kehittäjä määrittelee mahdolliset tulokset etukäteen, malli ei voi vastata sujuvalla mutta odottamattomalla kappaleella. TechCrunchin mukaan TypeSafe esittää tämän keinona välttää hallusinaatioita. Käytännön versio on kapeampi: Jev voi silti olla väärässä, mutta sen pitäisi olla väärässä tunnetun valintajoukon sisällä, todennäköisyys mukana.

Kolmanneksi tuo todennäköisyys on osa tuotetta, ei jälkikäteen lisätty ajatus. Earendilin CTO Armin Ronacher kertoi TechCrunchille, että Jev ”delegoi hallusinaatio-ongelman vähän käyttäjälle”. Jos tulos palaa 50 %:n varmuudella, sovellus voi sivuuttaa sen. Jos se palaa 95 %:n varmuudella, sovellus voi toimia.

Tällä erolla on merkitystä. Suuri osa AI-automaatiosta ei hajoa siksi, ettei malli olisi koskaan hyödyllinen, vaan siksi, ettei ohjelmisto tiedä, milloin malli vain arvaa. Kehittäjät yrittävät usein palauttaa varmuutta pyytämällä LLM:ää selittämään itseään, äänestämään itsensä kanssa tai tuottamaan rakenteista JSONia. Jeviä esitellään mallina, jossa varmuuspisteet ovat koko asian ydin.

TechCrunch raportoi, että kehittäjien kiinnostus oli niin suurta, että TypeSafe AI menetti hetkellisesti kykynsä palvella käyttäjiä API:nsa kautta. Artikkeli kehystää Jevin varhaisen vetovoiman ohjelmistoautomaation ympärille: kehittäjät käyttävät älykkyyttä koodin sisällä, eivät chat-käyttöliittymänä.

Raportin kaksi esimerkkiä näyttävät, millaista kysyntää on syntymässä.

Vercelin ohjelmistoinsinööri Pranit Sharma kertoi TechCrunchille, että Vercel oli käyttänyt OpenAI-mallia luokittelijaan, joka arvioi komentojen turvallisuutta. Kun Vercel korvasi OpenAI:n Lunan Jevillä, Sharman mukaan tulokset saatiin 5–18 kertaa nopeammin ja tarkemmin.

Bryo AI:n CTO Nikhil Mudholkar testasi Jeviä Geminiä vastaan yrityssähköpostien luokittelussa, TechCrunchin mukaan. Hänen testissään Gemini oli hieman tarkempi, mutta 10–20 kertaa kalliimpi. Mudholkar korosti Jevin varmuuspisteitä ja sanoi sen olevan ”ainoa, joka palauttaa oikean todennäköisyyden”, mikä teki siitä hyödyllisen työnkulkujen automatisoinnissa.

Nämä eivät ole laajoja benchmarkeja. Ne ovat raportoituja kehittäjätestejä tietyissä ympäristöissä, ja yksityiskohdat ovat testejä ajaneiden ihmisten hallinnassa. Ne kuitenkin osoittavat todelliseen kategoriaan: tapauksiin, joissa tehtävä ei ole ”kirjoita vastaus” vaan ”valitse oikea haara”.

Esimerkkejä ovat:

Monet tiimit ratkaisevat nämä nykyään LLM-prompteilla ja rakenteisilla tuloksilla. Se voi toimia, varsinkin kun mukana on skeemoja, uudelleenyrityksiä ja validointia. Mutta se käyttää silti LLM-budjettia tehtävään, joka ei välttämättä vaadi kielen generointia.

Jos Jevin varhaiset väitteet pitävät paikkansa TechCrunchin raportoimien esimerkkien ulkopuolella, se asettuu samaan käytännölliseen suunnitteluavaruuteen kuin työkalukutsut ja rakenteiset tulokset: mallin käyttäytymisen muuttamiseen sopimuksiksi, joita ohjelmisto voi käyttää.

Yksi TechCrunchin raportin kiinnostavimmista käyttötavoista ei ole LLM:ien korvaaminen vaan sen päättäminen, milloin niitä kannattaa käyttää.

Ronacher kertoi TechCrunchille, että Jev voisi olla hyödyllinen mallireitityksessä: ennustamaan, tarvitseeko tietty työkuorma tietyn mallin. LLM:n käyttäminen tähän päätökseen voi olla kallista. Halvempi ja nopeampi malli, joka palauttaa kalibroidun pistemäärän, voisi olla mallipinon edessä ja päättää, minne kukin pyyntö lähetetään.

Tämä on tuttu ongelma kaikille, jotka rakentavat useilla malleilla. Vahvin malli ei ole aina tarpeen. Halvin malli ei ole aina turvallinen. Jotkin promptit tarvitsevat pitkän kontekstin päättelyä; toiset nopean luokittelijan; toiset kuvan, äänen tai hakutyökalun. Reitittimen on arvioitava työ ennen budjetin käyttämistä.

Tässä myös Jevin muodolla on merkitystä. Reititin ei tarvitse esseetä siitä, miksi prompt on vaikea. Se tarvitsee päätöksen, kuten:

• lähetä pienelle mallille;
• lähetä frontier-mallille;
• hae dokumentit ensin;
• pyydä ihmisen hyväksyntää;
• hylkää turvattomana.

Se on lähempänä todennäköisyyden arviointia kuin keskustelua. Reitityksen ydinongelma on käytännöllinen, ei retorinen: arvokkain osa on usein oikean kyvykkyyden valitseminen oikeaan hintaan, ei vain suurimman saatavilla olevan mallin kutsuminen.

Jev viittaa siihen, että reitityksestä itsestään voi tulla AI-työkuorma, jonka taustalla on erikoistuneita malleja.

TechCrunch raportoi myös, että Almeida näkee Jeviä käytettävän LLM-agenttien jälkien valvontaan ja jailbreakien estämiseen. Kustannusperustelu on suoraviivainen. Jos jokainen agentin toiminto täytyy tarkistaa toisella täydellä LLM:llä, turvallisuuskerroksesta voi tulla kallis. Jos pienempi päätösmalli voi merkitä epäilyttävän käytöksen halvalla, useammalla sovelluksella on varaa jatkuvaan valvontaan.

Tämä ei poista agenttiturvallisuuden vaikeita osia. Luokittelija tarvitsee selkeästi määritellyt tunnisteet. Se tarvitsee esimerkkejä. Se tarvitsee kynnysarvoja. Se tarvitsee käytännön sille, mitä tapahtuu, kun varmuus on matala. Ja jos toiminto on riittävän arkaluonteinen, todennäköisyyspisteytyksen ei pitäisi korvata ihmisen harkintaa.

Arkkitehtuuri on kuitenkin selkeä:

1. agentti ehdottaa tai tekee vaiheen;
2. päätösmalli pisteyttää vaiheen;
3. järjestelmä estää, sallii, kirjaa tai eskaloi;
4. ihminen tarkistaa vain tapaukset, jotka tarvitsevat ihmisen tarkistusta.

Tämä on lähellä sitä, miten tuotantojärjestelmät jo ajattelevat riskiä. Maksujärjestelmät, petosten torjuntajärjestelmät, roskapostijärjestelmät ja väärinkäytösten torjuntajärjestelmät toimivat usein kynnysarvojen ja eskalointipolkujen kautta. AI-agentit alkavat tarvita samaa mallia.

Autonomisia työnkulkuja rakentaville tiimeille opetus ei ole ”korvaa turvallisuustyösi Jevillä”. Se on, että turvallisuus voidaan erottaa generoinnista. Voit suunnitella agentteja, joissa yksi malli toimii, toinen malli tai luokittelija valvoo ja ihmisen hyväksyntäkerros käsittelee peruuttamattomat toiminnot. Sama periaate näkyy human-in-the-loop-hyväksynnöissä ja moniagenttijärjestelmissä, joissa yksi komponentti tarkistaa toisen ennen työn etenemistä.

Arkkitehtuuri on osin läpinäkymätön. TechCrunchin mukaan Almeida on ”vaitonainen” Jevin sisäisestä toiminnasta, kun taas ulkopuoliset tarkkailijat epäilevät sen rakentuvan avoimen painotuksen LLM:n päälle. TypeSafe AI kutsuu Jeviä ”System One -malliksi”: malliksi, joka on optimoitu nopeisiin, intuition kaltaisiin päätöksiin eksplisiittisen päättelyn sijaan, ja jonka kapeampi rakenne sopii tehtävään.

Almeida kertoi TechCrunchille, että Jev koulutetaan yksinomaan synteettisellä datalla tekniikalla, jota hän kutsuu ”kalibroiduista päätöksistä oppivaksi vahvistusoppimiseksi”. Hän sanoi myös, että TypeSafe AI panosti varhain kaiken oman datansa tekemiseen. Hän kuvasi osaa yhtiöstä laboratorioksi, joka keskittyy ”tilastollisesti hyvin ymmärrettyyn synteettiseen dataan”.

Tässä on riittävästi tuoteteesin ymmärtämiseen, mutta ei riittävästi koulutusmenetelmän itsenäiseen arviointiin. TechCrunchin raportista emme tiedä, miten kalibrointia mitataan, kuinka kestävä se on jakautuman ulkopuolella, miten malli käsittelee adversariaalisia syötteitä tai miten suorituskyky muuttuu eri toimialueilla.

Näillä kysymyksillä on merkitystä, koska todennäköisyydestä on hyötyä vain, kun se on kalibroitu. Jos malli sanoo 95 % ja on samankaltaisissa olosuhteissa oikeassa suunnilleen 95 % ajasta, kehittäjät voivat rakentaa sen ympärille käytäntöjä. Jos luku on vain varmuuden näköinen tulos, siitä tulee yksi validoitava asia lisää.

Järkevä arviointi testaisi tarkkuuden lisäksi kalibrointikäyriä, pidättäytymiskäyttäytymistä, kynnysarvojen suorituskykyä ja kustannuksia todellisessa liikenteessä. Tiimeille, jotka jo ajavat malliarviointeja, Jev kuuluisi samaan testikehikkoon kuin LLM, jonka se saattaa korvata tai jota se saattaa valvoa.

Jev on nimetty William Stanley Jevonsin mukaan, 1800-luvun taloustieteilijän, joka yhdistetään Jevonsin paradoksiin: kun resurssin käyttö tehostuu, kokonaiskulutus voi nousta laskemisen sijaan. Almeida kertoi TechCrunchille, että TypeSafe AI odottaa halvemman älykkyyden johtavan ”älykkääseen ohjelmistoon kaikkialla”, enemmän varhaisen internetin tapaan kuin maailmaan, jota hallitsevat vain ”megasovellukset”.

Tämä on strateginen väite. Jos älykkyydestä tulee riittävän halpaa sijoitettavaksi tavalliseen ohjauslogiikkaan, kehittäjät voivat lakata varaamasta AI:ta chatboteille ja suurille agenttisille kokemuksille. Sen sijaan pieniä päätöksiä ilmestyy kaikkialle: jonoihin, ylläpitopaneeleihin, asiakastuen työnkulkuihin, käyttöönoton tarkistuksiin, viestintäjärjestelmiin ja dataputkiin.

Tämä olisi merkittävä muutos. ChatGPT-aikakauden käyttöliittymä on ollut chat. Jev osoittaa kohti upotettua päättelyä: näkymättömiä, kapeita ja toistuvia päätöksiä, jotka saavat ohjelmiston mukautumaan reaaliajassa.

Rakentajille käytännön askel on kartoittaa paikat, joissa pyydät tällä hetkellä yleistä LLM:ää tekemään rajatun työn. Luokittelu, reititys, poiminta, järjestäminen, moderointi ja eskalointi ovat ilmeisiä ehdokkaita. Jotkin niistä voivat yhä tarvita LLM:ää. Jotkin voivat hoitua paremmin säännöillä. Jotkin voivat perustella erikoistuneen päätösmallin, jos talous toimii.

Jos työnkulkusi käsittelee paljon rivejä, viestejä, tikettejä tai tapahtumia, kysymys terävöityy: tarvitsetko tuotettua tekstiä vai luotettavan päätöksen mittakaavassa? Tämä on sama taloudellinen rajalinja, joka on AI-eräkäsittelyn ja monien tuotantoautomaation järjestelmien taustalla.

Tärkeä fakta ei ole se, että Jev olisi ”parempi kuin LLM:t”. TechCrunchin raportti ei osoita sitä, ja esimerkit ovat liian kapeita siihen johtopäätökseen. Tärkeä fakta on, että kehittäjät osoittavat kiinnostusta malliin, joka on muotoiltu ohjelmistopäätöksiä eikä ihmiskeskustelua varten.

Tämän pitäisi muuttaa tapaa, jolla tiimit kehystävät AI-arkkitehtuuria.

Käytä LLM:iä siellä, missä kielellä, päättelyllä, synteesillä ja työkalujen käytöllä on merkitystä. Käytä rakenteisia tuloksia, kun tarvitset sopimuksen. Käytä hakua, kun vastaus riippuu yksityisestä tai muuttuvasta tiedosta. Käytä ihmisen hyväksyntää, kun toiminnot ovat arkaluonteisia. Ja seuraa nousevaa päätösmallien luokkaa paikoissa, joissa todennäköisyydet ovat proosaa hyödyllisempiä.

Jev voi jäädä erikoistuneeksi tuotteeksi, tai kilpailijat voivat liikkua samaan yleiseen suuntaan. Ronacher kertoi TechCrunchille odottavansa muiden seuraavan perässä, mutta se ei välttämättä tarkoita suoria Jev-klooneja; se voi tarkoittaa enemmän järjestelmiä, jotka rakentuvat kapeiden, todennäköisyyspohjaisten päätösten ympärille avoimen tekstingeneroinnin sijaan. Joka tapauksessa se on hyödyllinen signaali: AI-infrastruktuurin seuraava aalto voi liittyä vähemmän siihen, että yksi malli saadaan puhumaan paremmin, ja enemmän siihen, että ohjelmistolle annetaan halvempia, pienempiä ja mitattavampia älykkyyden palasia.

Käytännön johtopäätös liittyy vähemmän LLM:ien korvaamiseen ja enemmän oikean mallimuodon valitsemiseen jokaiseen päätökseen.

• Jeviä kuvataan transformer-pohjaiseksi malliksi, joka palauttaa todennäköisyyksiä ennalta määritellyille tuloksille proosan generoimisen sijaan.
• Mallia esitellään rajattuihin ohjelmistopäätöksiin, kuten luokitteluun, reititykseen, moderointiin, eskalointiin ja turvallisuustarkistuksiin.
• Raportoidut kehittäjätestit viittaavat siihen, että Jev voi olla nopeampi tai halvempi kuin yleiset LLM:t joissakin kapeissa luokittelutyönkuluissa, mutta ne eivät ole laajoja benchmarkeja.
• Kalibroidut todennäköisyydet voivat auttaa sovelluksia päättämään, milloin toimia, pidättäytyä, eskaloida tai kutsua vahvempaa mallia.
• Rakentajien kannattaa arvioida Jevin kaltaisia järjestelmiä tarkkuuden, kalibroinnin, kynnysarvokäyttäytymisen, pidättäytymisen, kestävyyden ja todellisen liikenteen kustannusten perusteella.

Nämä kysymykset käsittelevät sitä, miten Jev AI -malli toimii, miten se eroaa yleisestä LLM:stä ja mihin todennäköisyyspohjaiset päätökset voivat sopia ohjelmistojärjestelmissä. Ne myös kuvaavat, mitä tiimien kannattaa arvioida ennen Jevin kaltaisten mallien käyttöä tuotannossa.

Jev on TypeSafe AI:n malli, jota kuvataan transformer-pohjaiseksi mutta ei suureksi kielimalliksi. Tekstin kirjoittamisen sijaan se palauttaa todennäköisyyksiä tuloksille, jotka kehittäjät määrittelevät etukäteen.

Yleinen LLM generoi kielitokeneita, kun taas Jev on suunniteltu valitsemaan ennalta määriteltyjen tulosten joukosta ja liittämään mukaan todennäköisyys. Se tekee siitä paremmin ohjelmistopäätöksiin kuin avoimeen keskusteluun sopivan.

Kehittäjät ovat kiinnostuneita, koska monet AI-työkuormat tarvitsevat luotettavan haaran, tunnisteen tai turvallisuuspäätöksen kappaleen sijaan. TechCrunch raportoi varhaisista testeistä, joissa Jev oli halvempi tai nopeampi tietyissä luokittelun käyttötapauksissa.

Artikkelissa käsitellään käyttötapauksia, kuten komentojen turvallisuusarviota, yrityssähköpostien luokittelua, agenttien valvontaa, mallireititystä, työnkulun triagea ja LLM-agenttien turvakaiteita.

Tiimien kannattaa testata muutakin kuin tarkkuutta. Niiden tulisi mitata kalibrointia, kynnysarvojen suorituskykyä, pidättäytymiskäyttäytymistä, kestävyyttä koulutusalueen ulkopuolella, adversariaalisia syötteitä ja kustannuksia todellisessa liikenteessä.