jev-latest

A Jev a TypeSafe zászlóshajó-modellje és az új System One osztály első modellje. Nem szöveget ír, hanem gyors döntéseket hoz, amelyeket egy program közvetlenül felhasználhat: meg kell adni az állapotot (state) — szöveget vagy JSON-t — és a kérdések készletét, a válasz pedig típusozott értékeket tartalmaz kalibrált valószínűségekkel.

A nyelvi modellek embereknek írnak szavakat, a Jev viszont a TypeSafe szerint közelebb áll a kódhoz: a válasz rögtön a kódnak megfelelő formában érkezik, nagy sebességgel, és egyetlen érték sem esik a megadott lehetőségeken kívülre. A modellt úgy tervezték, hogy ismételt kéréseknél is stabil válaszokat adjon.

Miben különbözik a System One a nyelvi modelltől?

• Nem generál. A Jev nem ír felhasználói válaszokat, kódot vagy magyarázatot a következtetési folyamatáról. A lehetséges válaszokat a felhasználó adja meg a három kérdéstípus egyikével.
• Kalibrált döntésekre tanították. A TypeSafe RLCD-vel (Reinforcement Learning for Calibrated Decisions) tanítja a modellt: a valószínűségeket a tényleges kimenetelekhez igazítják, így azok a bizonytalanságot tükrözik. Sok 0,8 valószínűségű válasz közül körülbelül 80%-nak kell helyesnek lennie. A kalibráltság nagy mintára vonatkozó tulajdonság, nem az egyes válaszok helyességének garanciája.
• Más a tanítás célja. A chatmodelleket úgy tanítják, hogy az emberek kedveljék őket (RLHF); a TypeSafe megfigyelése szerint ez megfelelési kényszert és magabiztosan előadott hibákat ösztönöz. Az RLHF egyik társszerzője, Diogo Almeida a TypeSafe társalapítója.

A név Daniel Kahneman Gyors és lassú gondolkodás című könyvének „1. rendszerére” utal: a gyors, intuitív ítélet áll szemben a „2. rendszer” lassú, megfontolt gondolkodásával. A Jev gyors, szűk körű ítéletekre készült.

Három kérdéstípus

Egy kérdés egyetlen ítéletet kér az állapotról, a válasz pedig olyan érték, amelyet a kód küszöbbel összevethet, rendezhet vagy továbbadhat.

1. Choice — választás a lehetőségek közül. A megkeresést kezelő részleg, egy termék kategóriája vagy egy kódrészlet nyelve. A lehetőségek „változat → leírás” szótárt alkotnak, legfeljebb 255 elemmel. A válasz tartalmazza a kiválasztott choice értéket, az összes lehetőség probabilities valószínűségét (összegük 1) és a confidence bizonyossági értéket. Ha a lista nem fedhet le minden esetet, érdemes „egyéb” vagy „egyik sem” lehetőséget hozzáadni.
2. Score — skálás értékelés. Hely egy rendezett skálán, amelyet a felhasználó ír le: a hiba súlyossága, az ügyfél elégedetlensége vagy a készségszint. A skála 2 és 10 közötti szintet tartalmazhat, az alacsonytól a magasig; a modell minden szintet külön értékel, anélkül hogy látná annak sorszámát vagy a szomszédait. A válaszban szerepel a score (a szintek sorszámának a valószínűségeikkel súlyozott összege, ezért az érték két szint közé is eshet), a szintek leírását tartalmazó legend, valamint a probabilities és a confidence.
3. Noul — igen vagy nem. Igaz-e az állítás? A noul válasz az „igen” valószínűsége 0 és 1 között: az 1 körüli érték biztos „igen”, a 0 körüli biztos „nem”, a 0,5 körüli pedig bizonytalanságot jelez. Külön confidence nincs: egyetlen szám teljesen leírja a választ. Az opcionális criteria pontosítja, mi számít „igennek” és mi „nemnek”.

Választás: ismert, nem rendezett lehetőségekhez choice; egy tartomány lépcsőihez score; tiszta „igen/nem” kérdéshez, ahol maga a valószínűség fontos, noul. A noul 0,5 egyenlő esélyű „igent” és „nemet” jelent, nem „közepes szintet”: a mértéket a score méri. Két megfelelő típus közül azt érdemes választani, amellyel a kód közvetlenül cselekedhet: choice — elágazások, score — küszöb, noul — if.

A típusok egy kérésben keverhetők. A válasz mindig a megadott lehetőségekre korlátozódik, és nem függ a többi kérdéstől: kérdések hozzáadhatók és eltávolíthatók a többi válasz megváltoztatása nélkül.

Állapot

Az állapot az, amit a modell értékel: ügyfélüzenet, dokumentumrészlet, adatbázisrekord vagy az alkalmazás állapota.

• Karakterlánc — ha egyetlen szöveg van: üzenet, cikk vagy részlet.
• Objektum — elnevezett mezők, kapcsolódó rekordok vagy az alkalmazás állapota. A TypeSafe a legtöbb kéréshez objektumot ajánl, mert minden résznek egyértelmű neve van.
• Tömb — üzenetek vagy rekordok sorozata.

Szakértőknek összeállított anyagként érdemes előkészíteni: a levelezés, a rendelés és a visszatérítési szabályok kerüljenek egy helyre, ha a döntéshez össze kell vetni őket. A tartalom az állapotba, az ítéletek a kérdésekbe kerüljenek. Ha a kérdés az állapot egy részére vonatkozik, abban backtickek között kell megadni az elérési utat, például ticket.messages[0].text.

Kérdések megfogalmazása

• Egy gyors ítélet kérdésenként. Jó kérdés az, amelyre a szükséges kontextust ismerő ember egy másodperc alatt válaszolhat: „Van sürgősség az üzenetben?”. A „Vizsgáld meg az üzenetet, és döntsd el, mit tegyünk” már lassú következtetés, ezért egyszerű kérdésekre kell bontani.
• A teljes kérdés az instructions mezőbe kerüljön. A kérdés kulcsa, például refund_requested, csak a saját kódhoz szükséges, a modell nem kapja meg.
• Az egy állapothoz tartozó összes kérdés egy kérésbe kerüljön. A modell párhuzamosan értékeli őket: a TypeSafe szerint a további kérdések alig növelik a válaszidőt, és csak a saját tokenjeikbe kerülnek. Egy „biztos, ami biztos” kérdés szinte ingyen van — a kód maga dönti el, mely válaszokra van szükség.
• Összetett ítéletet részekre bontva. Az „értékeld a startup kérelmét” helyett külön érdemes rákérdezni a piac méretére, a műszaki megvalósíthatóságra és a versenytársaktól való eltérésekre, a végeredményt pedig súlyokkal kiszámítani a kódban. Ha változnak a prioritások, a súlyokat kell módosítani, nem a kérdést átírni.
• Függő kérdések második kérésben. Egy kérés válaszai nem szolgálnak egymás kontextusául. Második kérésre csak akkor van szükség, ha az első válasz nélkül nem állítható össze: például adatot kell betölteni, vagy ki kell választani a következő kérdés lehetőségeit.
• Hosszú kérdés objektumként. Az instructions és a criteria általában karakterlánc, de objektum vagy tömb is lehet: a kérdés az egyik mezőben, az adatok a többiben szerepelnek. Így egyetlen kérdéssel kényelmesen összevethető egy önéletrajz az adatbázisrekordokkal.

Bizonyosság

Choice és score esetében a 0 és 1 közötti confidence azt mutatja, mennyire összpontosul a valószínűség egy válaszra: 1 esetén teljesen egy lehetőségre, 0 esetén egyenlően az összesre. Score esetében a szomszédos szint kevésbé csökkenti a bizonyosságot, mint egy távoli. Noul esetében maga az érték a bizonyosság: minél távolabb van 0,5-től, annál határozottabb a válasz.

A TypeSafe három tartományt ajánl:

1. Magas bizonyosság — automatikus végrehajtás.
2. Közepes — óvatos végrehajtás, például megerősítés kérése a felhasználótól.
3. Alacsony — az eset átadása embernek, a kérés pontosítása vagy tartalék út bekapcsolása, például egy erősebb, következtető modell használata.

Minél költségesebb a hiba, annál szigorúbb a küszöb: visszafordíthatatlan műveleteknél magasabb, mint olvasásnál. A válasz azt mondja meg, mit válasszunk, a bizonyosság pedig azt, érdemes-e cselekedni. A küszöböket saját adatokon kell meghatározni, a bizonyosságot a pontossággal összevetve.

Hogyan épüljön rendszer a Jev köré?

A Jev nem olyan ügynökökhöz készült, amelyek maguk választják ki a következő lépést, és minden körben eltévedhetnek, hanem olyan programokhoz, amelyekben a folyamatot a kód vezérli, a modell pedig szűk szemantikai kérdésekre válaszol. A TypeSafe nyolc tervezési lépése:

1. Amit kóddal el lehet végezni, azt kóddal kell megoldani — megbízhatóan és olcsón.
2. Az állapotba csak az kerüljön, amire az aktuális kérdésekhez szükség van; a friss tények saját tudásbázisból, ne a modell emlékezetéből származzanak.
3. Szerkezet az állapotban: beágyazott JSON, a kérdésben pedig a szükséges mező elérési útja backtickek között, ha ez csökkenti a kétértelműséget.
4. A lehető legszűkebb és legkonkrétabb kérdések — a TypeSafe szerint talán ez a legfontosabb szabály: egy tág kérdés több ítéletet rejt egy válasz mögé.
5. Szerkezet a kérdésekben: maga a kérdés rövid; a magyarázatok, példák és saját adatbázisból származó értékek az instructions vagy a criteria objektum szomszédos mezőiben, ne egy hosszú karakterláncban legyenek.
6. Sok független kérdés ugyanahhoz az állapothoz, egyetlen kérésben — több haszon minden dollárért.
7. A válaszokat a kód egyesíti: szabályokkal, súlyozott összeggel vagy egy hagyományos gépi tanulási modell jellemzőiként.
8. Elágazás a bizonyosság szerint: a bizonytalan esetek emberhez vagy következtető modellhez kerüljenek.

A Jev nem chatmodell és nem kódkiegészítő modell, ezért programozó ügynökben nem helyettesíthet nyelvi modellt. Egy ügynök viszont megírhatja azt a kódot, amely ott hívja meg a Jevet, ahol gyors, kalibrált válasz szükséges.

Felhasználási területek

• Háttérautomatizálás — emberi jelenlét nélkül milliószor lefuttatott döntések.
• Valós idő — a TypeSafe szerint a kérések többsége körülbelül 100 ms alatt teljesül: ez elegendő menet közbeni feldolgozáshoz és felületekhez.
• Nagy adathalmazok — keresés hatalmas korpuszokban, ügynökök munkanaplóinak címkézése, előrejelzési jellemzők.
• Más modellek ellenőrzése — kérések, kinyert adatok, következtetések és eszközhívások: korlátozások megkerülése, idézési hibák, kitalált állítások.
• Keresés és rangsorolás — „kérés — jelölt” párok relevanciája, újrarangsorolás, kontextusválogatás.
• Elágazás a szándék szerint — mit szeretne a felhasználó, és melyik kezelő szükséges: egyszerű logika, szakmodell vagy ember; a téma, az összetettség és a kockázat határozza meg, melyik nyelvi modell kapja a kérést.
• Védelmi ellenőrzések — a nyelvi modell bemenete, kimenete és eszközhívásai: beágyazott utasítások, szabálysértések, személyes adatok kiszivárgása.
• Ügyféltámogatás — a megkeresés témája és szándéka, sürgősség, elégedetlenség, lemorzsolódási kockázat, visszatérítési kérés és sorba állítás.
• Moderálás — a saját platform szabályai alapján: mérgező tartalom, zaklatás, spam, csalás, veszélyes tanácsok és személyes adatok; súlyosság és bizonyosság alapján engedélyezés, figyelmeztetés, ellenőrzés vagy blokkolás.
• Ágazatok — biztosítási esetek, pénzügyi vizsgálatok és KYC, szerződések és reklám, termékkártyák, toborzás, érdeklődők, játékok, kockázatok, kereslet-előrejelzés, tudásgráfok, tudományos áttekintések és a kód szemantikai ellenőrzése CI-ban.

Jellemzők

• jev-latest — a legújabb stabil verzió álneve, jelenleg Jev 1.13; a válaszoló verzió a model mezőben látható, például jev-1.13.0. Új verzió megjelenésekor az álnév arra vált, és a válaszok saját módosítás nélkül is megváltozhatnak — figyelni kell ezt a mezőt, ha a küszöbök egy adott verzióhoz igazodnak.
• Kontextus — kérésenként 64K token: az állapot és az összes kérdés együtt; az állapot a leghosszabb kérdéssel együtt legfeljebb 32K. A modell egyszer olvassa az állapotot, és az összes kérdést párhuzamosan ellenőrzi vele szemben.
• Bemenet — kizárólag szöveg: karakterlánc, JSON-objektum vagy szövegtömb. Képek, hang és videó egyelőre nem támogatottak — előbb szöveggé kell alakítani őket.
• Nyelv — a tanítás fő nyelve az angol, jelenleg ezen a legnagyobb a pontosság. A modell más nyelveket, köztük kínait, japánt és koreait is fogad, de kisebb pontossággal — saját adatokon kell ellenőrizni.
• Árak és számlázás az Ailoot API-ban — a feltételek a választott metódustól függnek, és annak kártyáján szerepelnek.
• Beállítás — a Jevet nem finomhangolják az ügyfél adataival: a saját anyagok a state, a szakterületi szabályok az instructions és a criteria mezőbe kerüljenek.
• Adatok — a TypeSafe közlése szerint a Jevet nem tanítják az ügyfelek kérésein és válaszain.

A Jev 1.13 ismert gyengeségei

A TypeSafe nyíltan felsorolja az aktuális verzió gyengeségeit, és sok javítást ígér a következőkre. A modell gyors, kalibrált és józan ítéletekre képes, de:

1. Szó szerint olvas. A leírt kérdésre válaszol, nem a szándékoltra: a fenntartásokat, tagadásokat és kimondatlan feltételeket szó szerint érti. A pontos feltételt és a határeseteket a criteria mezőben kell megadni; az elkerülhetetlen értelmezést két szó szerinti kérdésre kell bontani.
2. Nem számológép. A karakterek, ismétlődések és listaelemek számlálása megbízhatatlan, a hiba a mérettel nő — ezt kódban kell elvégezni, jelöltenként egy kérdéssel. A hex vagy RGB formájú színeket a modell kevésbé érti, mint a színneveket. A score küszöbhöz megfelelő, de a szintek közötti pontos számhoz nem.
3. Dátumok és idő. Melyik dátum korábbi, mennyi idő van köztük, beleesik-e egy időszakba — ezek megbízhatatlanok, különösen vegyes formátumoknál és relatív dátumoknál. A dátum részeit choice kérdéssel érdemes kinyerni („nincs megadva” lehetőséggel), az összehasonlítást pedig kódban elvégezni.
4. Közvetettség. A kettős tagadás és egy tulajdonság tulajdonságára vonatkozó kérdés csökkenti a pontosságot. Közvetlenül kell fogalmazni, és név szerint megadni az állapot részeit.
5. Felesleges tartalom az állapotban. Az oda nem tartozó szöveg rontja a pontosságot. Kódban kell szűrni, ha ez nem lehetséges, noul kérdésekkel kiszűrni a nem releváns részeket.
6. Ellenséges szöveg. A modell alapértelmezésben nem számít csapdákra az állapotban: egy beágyazott utasítás vagy a saját besorolásával vitatkozó szöveg eltolhatja a választ. Pontos kritériumokat kell írni, és indulás előtt ellenőrizni a határeseteket.
7. Ellentmondások. Ha az instructions és a criteria mást kér — például a noul „igenje” „nemként” van leírva —, csökken a pontosság. A kritériumok a kérdés folytatását jelentik.
8. A lehetőségek sorrendje. A modell néha a choice első lehetőségéhez húz. Érdemes átrendezni őket, és ellenőrizni, hogy a válasz nem változik-e.
9. Generálás. A Jevet nem tanították szövegírásra. Adatkinyeréshez a jelölteket reguláris kifejezéssel vagy generatív modellel kell megkeresni, a Jev pedig choice segítségével válassza ki a megfelelőt.