jev-latest

Jev er TypeSafes flagskibsmodel og den første model i den nye klasse System One. Den skriver ikke tekst, men træffer hurtigt beslutninger, som programmet kan bruge direkte: du sender en tilstand (state) — tekst eller JSON — og et sæt spørgsmål og får typede værdier med kalibrerede sandsynligheder tilbage.

Sprogmodeller skriver ord til mennesker, mens Jev ifølge TypeSafe ligger tættere på kode: svaret er straks i den form, koden kræver, med høj hastighed og ingen værdier uden for de fastlagte muligheder. Modellen er udformet til stabile svar ved gentagne forespørgsler.

Hvordan System One adskiller sig fra en sprogmodel

• Genererer ikke. Jev skriver ikke brugersvar eller kode og forklarer ikke ræsonnementet. Du fastlægger svarmulighederne gennem én af tre spørgsmålstyper.
• Trænet til kalibrerede beslutninger. TypeSafe træner modellen med RLCD (Reinforcement Learning for Calibrated Decisions): sandsynligheder tilpasses faktiske udfald og afspejler usikkerhed. Blandt mange svar med sandsynlighed 0,8 bør cirka 80% være korrekte. Kalibrering er en egenskab ved en stor stikprøve, ikke en garanti for et enkelt svar.
• Et andet træningsmål. Chatmodeller trænes til at behage mennesker (RLHF), hvilket ifølge TypeSafe fremmer føjelighed og selvsikkert formulerede fejl. En af medskaberne af RLHF, Diogo Almeida, er medstifter af TypeSafe.

Navnet henviser til «System 1» fra Daniel Kahnemans bog «At tænke – hurtigt og langsomt»: hurtig intuitiv vurdering over for den langsomme, overvejede tænkning i «System 2». Jev er skabt til hurtige, snævre vurderinger.

Tre spørgsmålstyper

Et spørgsmål er én vurdering af tilstanden, og svaret en værdi, som koden sammenligner med en tærskel, sorterer eller sender videre.

1. Choice — valg af mulighed. Afdeling for en henvendelse, produktkategori eller et kodeuddrags sprog. Mulighederne er en ordbog «mulighed → beskrivelse» med op til 255 poster. Svaret indeholder valgt choice, probabilities for alle muligheder (sum 1) og confidence. Hvis listen ikke nødvendigvis dækker alle tilfælde, tilføj «andet» eller «ingen af ovenstående».
2. Score — vurdering på en skala. Placering på en ordnet skala, du beskriver: fejlens alvor, kundens irritation eller færdighedsniveau. Fra 2 til 10 niveauer, lavest til højest; modellen vurderer hvert niveau separat uden at se nummeret eller naboniveauerne. Svaret indeholder score (summen af niveaunumre ganget med deres sandsynligheder, så værdien kan ligge mellem niveauer), legend med niveauernes beskrivelser, probabilities og confidence.
3. Noul — ja eller nej. Om en påstand er sand. noul er sandsynligheden for «ja» fra 0 til 1: tæt på 1 er sikkert «ja», tæt på 0 sikkert «nej», og tæt på 0,5 er modellen i tvivl. Der er ingen særskilt confidence: ét tal beskriver hele svaret. Valgfrit criteria præciserer, hvad der tæller som «ja» og «nej».

Sådan vælges typen: kendte uordnede muligheder — choice; trin i et spektrum — score; rent «ja/nej», hvor sandsynligheden selv er vigtig — noul. Noul 0,5 er lige sandsynlighed for «ja» og «nej», ikke «mellemste niveau»: score måler graden. Hvis to typer passer, vælg den, koden kan handle direkte på: choice til forgrening, score til tærskler og noul til if.

Typer kan blandes i samme forespørgsel. Svaret er altid begrænset til dine muligheder og afhænger ikke af andre spørgsmål: spørgsmål kan tilføjes eller fjernes uden at ændre de øvrige svar.

Tilstand

Tilstanden er det, modellen vurderer: en kundebesked, et dokumentuddrag, en databasepost eller din applikations tilstand.

• Streng — ét tekststykke: besked, artikel eller uddrag.
• Objekt — navngivne felter, forbundne poster eller applikationstilstand. TypeSafe anbefaler objekter til de fleste forespørgsler: hver del har et forståeligt navn.
• Array — en sekvens af beskeder eller poster.

Forbered den som materiale til eksperter: læg korrespondance, ordre og returregler sammen, hvis beslutningen kræver sammenligning. Hold indhold i tilstanden og vurderinger i spørgsmålene. Ved et spørgsmål om én tilstandsdel angives stien i backticks, eksempelvis ticket.messages[0].text.

Sådan stilles spørgsmål

• Én hurtig vurdering pr. spørgsmål. Et godt spørgsmål kan en vidende person med den rette kontekst besvare på et sekund: «Udtrykker beskeden hast?». «Analysér beskeden og beslut, hvad der skal gøres» er langsomt ræsonnement og skal opdeles i enkle spørgsmål.
• Hele spørgsmålet i instructions. Spørgsmålsnøglen, eksempelvis refund_requested, bruges kun af din kode og sendes ikke til modellen.
• Alle spørgsmål om én tilstand i én forespørgsel. Modellen vurderer dem parallelt: ifølge TypeSafe øger ekstra spørgsmål næsten ikke svartiden og koster kun deres egne tokens. Et spørgsmål «for en sikkerheds skyld» koster næsten intet — koden afgør selv, hvilke svar der er nødvendige.
• Komplekse vurderinger i dele. I stedet for «vurdér startupansøgningen» spørges separat om markedsstørrelse, teknisk gennemførlighed og forskelle fra konkurrenterne, og resultatet beregnes i kode med vægte. Ved ændrede prioriteter ændres vægtene, ikke spørgsmålet.
• Afhængige spørgsmål i anden forespørgsel. Svar i samme forespørgsel er ikke kontekst for hinanden. En anden forespørgsel kræves kun, hvis den ikke kan samles uden første svar: data skal hentes, eller næste spørgsmåls muligheder vælges.
• Lange spørgsmål som objekter. instructions og criteria er normalt strenge, men kan være objekter eller arrays: spørgsmålet i ét felt og data i andre. Det gør det muligt at sammenholde et CV med databaseposter i ét spørgsmål.

Sikkerhed i svaret

For choice og score viser confidence fra 0 til 1, hvor koncentreret sandsynligheden er på ét svar: 1 er alt på én mulighed, 0 ligeligt på alle. Ved score sænker et naboniveau sikkerheden mindre end et fjernt. For noul er sikkerheden selve værdien: jo længere fra 0,5, desto mere sikkert er svaret.

TypeSafe anbefaler tre intervaller:

1. Høj sikkerhed — handl automatisk.
2. Mellem — handl forsigtigt, eksempelvis ved at bede brugeren bekræfte.
3. Lav — send sagen til et menneske, præcisér forespørgslen eller tilslut en reservevej, eksempelvis en stærkere model med ræsonnement.

Jo dyrere fejlen er, desto strengere tærskel: højere for uigenkaldelige handlinger end læsning. Svaret siger, hvad der skal vælges, og sikkerheden, om der bør handles. Vælg tærskler på egne data ved at sammenligne sikkerhed med præcision.

Sådan bygges et system omkring Jev

Jev er ikke beregnet til agenter, der selv vælger næste trin og kan komme på afveje i hver runde, men til programmer, hvor kode styrer processen, og modellen besvarer snævre betydningsspørgsmål. TypeSafes otte designtrin:

1. Alt, der kan gøres med kode, gøres med kode — pålideligt og billigt.
2. Kun det, de aktuelle spørgsmål kræver, i tilstanden; nye fakta fra egen vidensbase, ikke modelhukommelse.
3. Struktur i tilstanden: indlejret JSON, og en sti til det relevante felt i backticks i spørgsmålet, hvis det mindsker tvetydighed.
4. Snævrest mulige, konkrete spørgsmål er ifølge TypeSafe måske hovedreglen: et bredt spørgsmål skjuler flere vurderinger i ét svar.
5. Struktur i spørgsmålene: selve spørgsmålet kort; forklaringer, eksempler og vidensbaseværdier i nabofelter i et instructions- eller criteria-objekt, ikke én lang streng.
6. Mange uafhængige spørgsmål om én tilstand i samme forespørgsel — mere nytte pr. dollar.
7. Koden kombinerer svar med regler, vægtede summer eller som features i en klassisk maskinlæringsmodel.
8. Forgrening efter sikkerhed: usikre tilfælde til et menneske eller en model med ræsonnement.

Jev er ikke chat eller kodefuldførelse og kan ikke erstatte en sprogmodel i en programmeringsagent. En agent kan derimod skrive kode, der kalder Jev, hvor et hurtigt kalibreret svar er nødvendigt.

Anvendelser

• Baggrundsautomatisering — beslutninger, der køres en million gange uden et menneske ved siden af.
• Realtid — ifølge TypeSafe tager de fleste forespørgsler cirka 100 ms, nok til behandling undervejs og interfaces.
• Store data — søgning i enorme korpora, mærkning af agentlogs og features til prognoser.
• Kontrol af andre modeller — forespørgsler, udtræk, ræsonnement og værktøjskald: omgåelse af begrænsninger, citationsfejl og opdigtede oplysninger.
• Søgning og rangering — relevans mellem «forespørgsel — kandidat», genrangering og kontekstvalg.
• Forgrening efter hensigt — hvad brugeren ønsker, og hvilken behandler der kræves: enkel logik, specialmodel eller menneske; emne, kompleksitet og risiko afgør sprogmodelvalget.
• Beskyttelseskontroller — sprogmodellens input, output og værktøjskald: indskudte instruktioner, regelbrud og læk af personoplysninger.
• Support — henvendelsens emne og hensigt, hast, irritation, frafaldsrisiko, returønske og kø.
• Moderering — platformens regler om toksicitet, chikane, spam, svig, farlige råd og personoplysninger; alvor og sikkerhed styrer godkendelse, advarsel, kontrol eller blokering.
• Brancher — forsikring, finansielle undersøgelser og KYC, kontrakter og reklamer, produktkort, rekruttering, leads, spil, risici, efterspørgselsprognoser, vidensgrafer, videnskabelige oversigter og semantisk kodekontrol i CI.

Egenskaber

• jev-latest — alias for seneste stabile version, aktuelt Jev 1.13; den svarende version står i model, eksempelvis jev-1.13.0. Ved nye versioner flyttes aliaset, og svar kan ændres uden egne rettelser — følg feltet, hvis tærskler er tilpasset versionen.
• Kontekst — 64K tokens pr. forespørgsel: tilstand og alle spørgsmål sammen; tilstanden med det længste spørgsmål op til 32K. Modellen læser tilstanden én gang og kontrollerer alle spørgsmål parallelt mod den.
• Input — kun tekst: streng, JSON-objekt eller tekstarray. Billeder, lyd og video understøttes endnu ikke — omsæt dem til tekst først.
• Sprog — træningen er primært engelsk, som aktuelt har højest præcision. Andre sprog, herunder kinesisk, japansk og koreansk, accepteres, men med lavere præcision — kontrollér på egne data.
• Priser og fakturering i Ailoot API — vilkårene afhænger af den valgte metode og fremgår af metodens kort.
• Tilpasning — Jev finjusteres ikke på kundedata: eget materiale i state, fagområdets regler i instructions og criteria.
• Data — TypeSafe oplyser, at Jev ikke trænes på kundernes forespørgsler og svar.

Kendte svagheder i Jev 1.13

TypeSafe angiver åbent versionens svagheder og lover mange rettelser i senere versioner. Modellen er hurtig, kalibreret og vurderer med sund fornuft, men:

1. Læser bogstaveligt. Besvarer det skrevne, ikke underforståede spørgsmål: forbehold, negationer og implicitte vilkår læses ordret. Skriv præcise vilkår og grænsetilfælde i criteria; nødvendig fortolkning opdeles i to bogstavelige spørgsmål.
2. Ikke en lommeregner. Tegn-, gentagelses- og listetælling er upålidelig, og fejlen vokser med størrelsen — tæl i kode med ét spørgsmål pr. kandidat. Farver i hex eller RGB forstås dårligere end farvenavne. score passer til tærskler, ikke et præcist tal mellem niveauer.
3. Datoer og tid. Datorækkefølge, tidsafstand og placering i en periode er upålidelige, især ved blandede formater og relative datoer. Udtræk datodele med choice (og «ikke angivet»), og sammenlign i kode.
4. Indirekte formulering. Dobbelte negationer og spørgsmål om en egenskabs egenskab sænker præcisionen. Skriv direkte og navngiv tilstandsdelene.
5. Overflødigt indhold i tilstanden. Uvedkommende tekst sænker præcisionen. Filtrér i kode eller, hvis det ikke er muligt, frasortér irrelevant materiale med noul-spørgsmål.
6. Fjendtlig tekst. Modellen forventer ikke fælder i tilstanden som standard: en indskudt instruktion eller tekst, der diskuterer egen klassifikation, kan påvirke svaret. Skriv præcise kriterier, og test grænsetilfælde før drift.
7. Modstrid. Hvis instructions og criteria kræver forskelligt, eksempelvis noul-«ja» beskrevet som «nej», falder præcisionen. Kriterierne er en fortsættelse af spørgsmålet.
8. Mulighedernes rækkefølge. Modellen foretrækker undertiden første choice-mulighed. Byt rundt, og kontrollér at svaret er uændret.
9. Generering. Jev er ikke trænet til at skrive tekst. Find dataudtrækskandidater med et regulært udtryk eller en generativ model, og lad Jev vælge den korrekte med choice.