jev-latest

Jev er TypeSafes flaggskipmodell og den første modellen i den nye klassen System One. Den skriver ikke tekst, men tar raske beslutninger som et program kan bruke direkte: du sender inn en tilstand (state) som tekst eller JSON og et sett med spørsmål, og får typede verdier med kalibrerte sannsynligheter tilbake.

Språkmodeller skriver ord for mennesker, mens Jev ifølge TypeSafe ligger nærmere kode: svaret kommer direkte i formen koden trenger, med høy hastighet og ingen verdier utenfor de angitte alternativene. Modellen er laget for å gi stabile svar ved gjentatte forespørsler.

Hvordan System One skiller seg fra en språkmodell

• Genererer ikke. Jev skriver ikke svar til brukeren, skriver ikke kode og forklarer ikke resonneringsforløpet. Du angir mulige svar gjennom én av tre spørsmålstyper.
• Trent på kalibrerte beslutninger. TypeSafe trener modellen med RLCD (Reinforcement Learning for Calibrated Decisions): sannsynlighetene tilpasses faktiske utfall og gjenspeiler usikkerhet. Blant mange svar med en sannsynlighet på 0,8 bør omtrent 80% være riktige. Kalibrering er en egenskap ved et stort utvalg, ikke en garanti for at et enkelt svar er riktig.
• Et annet treningsmål. Chatmodeller trenes på å tilfredsstille mennesker (RLHF), noe TypeSafe mener fremmer overdrevent medhold og feil som uttrykkes med sikkerhet. Diogo Almeida, en av medforfatterne bak RLHF, er medgründer av TypeSafe.

Navnet viser til «System 1» i Daniel Kahnemans bok «Tenke, fort og langsomt»: raske, intuitive vurderinger i motsetning til langsom, gjennomtenkt tenkning i «System 2». Jev er laget for raske, avgrensede vurderinger.

Tre spørsmålstyper

Et spørsmål er én vurdering av tilstanden, og svaret er en verdi som koden sammenligner med en terskel, sorterer eller sender videre.

1. Choice — valg av alternativ. Avdeling for en henvendelse, produktkategori eller språket i et kodeutsnitt. Alternativene er en ordbok med «alternativ → beskrivelse», opptil 255 oppføringer. Svaret inneholder valgt choice, probabilities for alle alternativene (med sum 1) og sikkerhetsverdien confidence. Hvis listen ikke nødvendigvis dekker alle tilfeller, legg til «annet» eller «ingen av alternativene».
2. Score — vurdering på en skala. Plassering på en ordnet skala som du beskriver: feilens alvorlighetsgrad, kundens irritasjon eller ferdighetsnivå. Fra 2 til 10 nivåer, fra lavest til høyest; modellen vurderer hvert nivå separat uten å se nummeret eller nabonivåene. Svaret inneholder score (summen av nivånumrene multiplisert med sannsynlighetene deres, så verdien kan ligge mellom nivåene), legend med nivåbeskrivelser, probabilities og confidence.
3. Noul — ja eller nei. Om en påstand er riktig. Svaret noul er sannsynligheten for «ja» fra 0 til 1: nær 1 er et sikkert «ja», nær 0 et sikkert «nei», og nær 0,5 er modellen usikker. Det finnes ingen separat confidence: ett tall beskriver svaret fullt ut. Det valgfrie criteria presiserer hva som skal regnes som «ja» og «nei».

Slik velger du: kjente alternativer uten rekkefølge — choice; trinn på et spekter — score; et rent «ja/nei» der selve sannsynligheten er viktig — noul. Noul 0,5 betyr like sjanser for «ja» og «nei», ikke et «middels nivå»: graden måles med score. Av to egnede typer velger du den koden handler direkte på: choice for forgreninger, score for en terskel og noul for if.

Typene kan blandes i én forespørsel. Svaret er alltid begrenset til alternativene dine og er uavhengig av andre spørsmål: spørsmål kan legges til eller fjernes uten at de øvrige svarene endres.

Tilstand

Tilstanden er det modellen vurderer: en kundemelding, et dokumentutsnitt, en databaseoppføring eller tilstanden til programmet ditt.

• Streng — når det er én tekst: en melding, artikkel eller et utdrag.
• Objekt — navngitte felt, relaterte oppføringer eller programtilstand. TypeSafe anbefaler objekter for de fleste forespørsler: hver del har et tydelig navn.
• Array — en sekvens av meldinger eller oppføringer.

Klargjør tilstanden som materiale for eksperter: legg korrespondanse, bestilling og returregler sammen hvis beslutningen krever at de sammenlignes. Hold innholdet i tilstanden og vurderingene i spørsmålene. Hvis et spørsmål gjelder én del av tilstanden, oppgi stien i spørsmålet med backticks, for eksempel ticket.messages[0].text.

Hvordan spørsmål formuleres

• Én rask vurdering per spørsmål. Et godt spørsmål kan en kyndig person med riktig kontekst svare på på ett sekund: «Uttrykker meldingen at det haster?». «Analyser meldingen og bestem hva som skal gjøres» krever allerede langsom resonnering og må deles i enkle spørsmål.
• Hele spørsmålet i instructions. Spørsmålsnøkkelen, for eksempel refund_requested, brukes bare av koden din og sendes ikke til modellen.
• Alle spørsmål om samme tilstand i én forespørsel. Modellen vurderer dem parallelt: ifølge TypeSafe øker ekstra spørsmål svartiden svært lite og koster bare sine egne tokener. Et spørsmål «for sikkerhets skyld» koster nesten ingenting; koden bestemmer selv hvilke svar som trengs.
• Krevende vurderinger deles opp. Fremfor «vurder søknaden fra oppstartsbedriften», spør separat om markedsstørrelse, teknisk gjennomførbarhet og forskjeller fra konkurrentene, og beregn sluttresultatet i kode med vekter. Når prioriteringene endres, endrer du vektene, ikke spørsmålet.
• Avhengige spørsmål i en ny forespørsel. Svarene i én forespørsel gir ikke hverandre kontekst. En ny forespørsel trengs bare dersom den ikke kan bygges uten det første svaret: data må lastes inn, eller alternativer til neste spørsmål velges.
• Lange spørsmål som objekter. instructions og criteria er vanligvis strenger, men kan være objekter eller arrays: spørsmålet i ett felt og data i de andre. Dette er praktisk for å sammenligne en CV med databaseoppføringer i ett spørsmål.

Sikkerhet

For choice og score viser confidence fra 0 til 1 hvor konsentrert sannsynligheten er om ett svar: 1 betyr at alt ligger på ett alternativ, og 0 at den er likt fordelt mellom alle. For score reduserer et nabonivå sikkerheten mindre enn et fjernt nivå. For noul ligger sikkerheten i selve verdien: jo lenger fra 0,5, desto sikrere er svaret.

TypeSafe anbefaler tre områder:

1. Høy sikkerhet — handle automatisk.
2. Middels — handle forsiktig, for eksempel ved å be brukeren bekrefte.
3. Lav — send saken til et menneske, presiser forespørselen eller bruk en reservevei, for eksempel en kraftigere modell med resonnering.

Jo dyrere en feil er, desto strengere terskel: for irreversible handlinger bør den være høyere enn for lesing. Svaret sier hva som skal velges, og sikkerheten om det bør handles. Tilpass tersklene til egne data ved å sammenligne sikkerhet med nøyaktighet.

Hvordan et system rundt Jev bygges

Jev er laget for programmer der koden styrer prosessen og modellen besvarer avgrensede spørsmål om mening, fremfor agenter som velger neste trinn selv og kan komme på avveie i hver runde. TypeSafes åtte designtrinn:

1. Gjør alt som kan gjøres i kode, med kode — pålitelig og rimelig.
2. Ta bare med det de aktuelle spørsmålene trenger, i tilstanden; hent nye fakta fra din egen kunnskapsbase, ikke fra modellens minne.
3. Struktur i tilstanden: nestet JSON og en sti til riktig felt med backticks i spørsmålet hvis det gir mindre tvetydighet.
4. De mest avgrensede og konkrete spørsmålene er ifølge TypeSafe kanskje hovedregelen: et bredt spørsmål skjuler flere vurderinger bak ett svar.
5. Struktur i spørsmålene: selve spørsmålet er kort; forklaringer, eksempler og verdier fra databasen legges i nabofelt i instructions- eller criteria-objektet, ikke i én lang streng.
6. Mange uavhengige spørsmål om samme tilstand i én forespørsel — mer nytte per dollar.
7. Koden kombinerer svarene: med regler, en vektet sum eller som egenskaper for en klassisk maskinlæringsmodell.
8. Forgrening etter sikkerhet: usikre tilfeller sendes til et menneske eller en modell med resonnering.

Jev er ikke en chatmodell eller en modell for kodefullføring og kan ikke erstatte en språkmodell i en programmeringsagent. Agenten kan derimot skrive kode for deg som kaller Jev der det trengs et raskt, kalibrert svar.

Bruksområder

• Bakgrunnsautomatisering — beslutninger som kjøres en million ganger uten et menneske til stede.
• Sanntid — ifølge TypeSafe behandles de fleste forespørsler på omtrent 100 ms: raskt nok for løpende behandling og grensesnitt.
• Store datamengder — søk i svært store korpus, annotering av agentlogger og egenskaper til prognoser.
• Kontroll av andre modeller — forespørsler, datauttrekk, resonnering og verktøykall: omgåelse av begrensninger, siteringsfeil og oppdiktet innhold.
• Søk og rangering — relevans for et par av søkespørsmål og kandidat, rerangering og utvalg av kontekst.
• Forgrening etter hensikt — hva brukeren ønsker, og hvilken behandling som trengs: enkel logikk, en spesialisert modell eller et menneske; tema, vanskelighetsgrad og risiko avgjør hvilken språkmodell forespørselen sendes til.
• Beskyttelseskontroller — språkmodellens inndata, utdata og verktøykall: innskutte instruksjoner, regelbrudd og lekkasje av personopplysninger.
• Kundestøtte — henvendelsens tema og hensikt, hast, irritasjon, frafallsrisiko, refusjonsønske og kø.
• Moderering — etter plattformens regler: toksisitet, trakassering, spam, svindel, farlige råd og personopplysninger; ut fra alvorlighetsgrad og sikkerhet velges gjennomslipp, advarsel, kontroll eller blokkering.
• Bransjer — forsikringssaker, økonomiske undersøkelser og KYC, avtaler og reklame, produktkort, rekruttering, potensielle kunder, spill, risiko, etterspørselsprognoser, kunnskapsgrafer, vitenskapelige oversikter og semantiske kodekontroller i CI.

Egenskaper

• jev-latest — alias for den siste stabile versjonen, nå Jev 1.13; versjonen som svarte, vises i model, for eksempel jev-1.13.0. Når en ny versjon kommer, peker aliaset på den, og svarene kan endres uten endringer fra din side; følg med på dette feltet hvis tersklene er tilpasset en versjon.
• Kontekst — 64K tokener per forespørsel: tilstanden og alle spørsmål samlet; tilstanden sammen med det lengste spørsmålet kan ha opptil 32K. Modellen leser tilstanden én gang og vurderer alle spørsmål mot den parallelt.
• Inndata — bare tekst: en streng, et JSON-objekt eller en array av tekster. Bilder, lyd og video støttes foreløpig ikke; gjør dem om til tekst først.
• Språk — hovedspråket i treningen er engelsk, og nøyaktigheten er nå høyest på dette språket. Modellen tar imot andre språk, inkludert kinesisk, japansk og koreansk, men nøyaktigheten er lavere; kontroller dette med egne data.
• Priser og fakturering i Ailoot API — vilkårene avhenger av den valgte metoden og er oppgitt på kortet for denne metoden.
• Tilpasning — Jev finjusteres ikke på kundedata: eget materiale legges i state, og fagområdets regler i instructions og criteria.
• Data — TypeSafe opplyser at Jev ikke trenes på kunders forespørsler og svar.

Kjente svakheter i Jev 1.13

TypeSafe oppgir svakhetene i den gjeldende versjonen åpent og lover å rette mye i senere versjoner. Modellen er rask, kalibrert og god til vurderinger basert på sunn fornuft, men:

1. Leser bokstavelig. Svarer på spørsmålet som er skrevet, ikke det som er underforstått: forbehold, negasjoner og implisitte vilkår tolkes bokstavelig. Skriv det nøyaktige vilkåret og grensetilfellene i criteria; del nødvendig tolkning i to bokstavelige spørsmål.
2. Ingen kalkulator. Telling av tegn, gjentakelser og listeelementer er upålitelig, og feilen øker med omfanget; tell i kode og bruk ett spørsmål per kandidat. Modellen forstår farger i hex eller RGB dårligere enn fargenavn. score egner seg for en terskel, men ikke et nøyaktig tall mellom nivåene.
3. Datoer og tid. Hvilken dato som er først, avstanden mellom datoer og om en dato faller innenfor en periode, er upålitelig, særlig med blandede formater og relative datoer. Hent datodeler med choice (med alternativet «ikke angitt»), og sammenlign i kode.
4. Indirekte spørsmål. Dobbel negasjon og spørsmål om en egenskap ved en egenskap reduserer nøyaktigheten. Skriv direkte og navngi delene av tilstanden.
5. Overflødig innhold i tilstanden. Uvedkommende tekst reduserer nøyaktigheten. Filtrer i kode, eller sil ut det irrelevante med noul-spørsmål hvis filtrering ikke er mulig.
6. Fiendtlig tekst. Modellen forventer som standard ikke feller i tilstanden: en innskutt instruksjon eller tekst som argumenterer om sin egen klassifisering, kan påvirke svaret. Skriv presise kriterier og kontroller grensetilfeller før oppstart.
7. Motsetninger. Hvis instructions og criteria ber om forskjellige ting, for eksempel hvis «ja» i noul beskrives som «nei», faller nøyaktigheten. Kriteriene er en fortsettelse av spørsmålet.
8. Alternativrekkefølge. Modellen tenderer noen ganger mot det første choice-alternativet. Endre rekkefølgen og kontroller at svaret ikke endres.
9. Generering. Jev er ikke trent til å skrive tekst. For datauttrekk finner du kandidater med et regulært uttrykk eller en generativ modell og lar Jev velge den riktige med choice.