7 bruksområder for Jev som fjerner reelt arbeid fra programvare

Noen spurte nettstedet vårt hvor mange integrasjoner vi har. Det svarte med råd om hvor mange felt et registreringsskjema bør inneholde.

Svaret kom raskt. Det var ubrukelig.

Begge spørsmålene inneholdt «hvor mange». Søkekoden vår ga et godkjent treff i vanlige spørsmål en minimumsscore på 0,86. Dermed virket et svakt treff overbevisende. Farten skjulte den gale beslutningen.

Det er en slik feil det er verdt å tenke på når du ser på Ship with Jev. Den 26. september 2026 listet katalogen 551 prosjekter fra fellesskapet. Spill står ved siden av søkekomponenter, nettleseragenter, forskningsverktøy og rutingeksperimenter. Katalogen tilskriver ytelsestallene til prosjektenes skapere. Den er et verktøy for å oppdage prosjekter, ikke en uavhengig sammenligningstest.

Det interessante spørsmålet er hvilke av disse mønstrene som fjerner arbeid fra et faktisk produkt.

For team som bygger integrasjoner og forretningsprogramvare, er dette de sju jeg ville vurdert først. Rekkefølgen er en redaksjonell vurdering av nytte og testbarhet. Arbeidsflytene nedenfor er foreslåtte utforminger, med mindre en konkret implementasjon er navngitt og lenket.

Hva Jev tilfører en applikasjon

TypeSafe beskriver Jev som en modell for vurderinger med definerte datatyper. Gi den relevant tilstand og et spørsmål, og få tilbake et valg, en sannsynlighet eller en score som kode kan bruke. Oversikten over bruksområder omfatter ruting, gjenfinning, verifisering og uthenting av data.

Dette skillet har en nyttig forløper i YouTube-materialet vi har hentet inn. I Diogo Almeidas foredrag på AI Engineer argumenterer TypeSafe-medgründeren for programvare der selve byggeklossene kan uttrykke mer intelligens. Han setter denne ambisjonen opp mot å legge en assistent til eksisterende programvare. Dette er argumentet hans om retningen for AI, ikke en måling av Jevs nåværende ytelse.

Tenk på en sporveksel. Det nyttige resultatet er hvilket av de tilgjengelige sporene toget bør følge. Et avsnitt som beskriver sporene, tilfører ikke vekselen noe.

Innvendingen er rimelig: «En vanlig LLM kan allerede returnere JSON.» Ja. Begrunnelsen for en annen komponent må bygge på målt kvalitet, kostnad og forsinkelse for akkurat den beslutningen. Et svar med en definert datatype fastslår ingen av delene alene.

Utfordringen fra CLM bør komme først

Den 23. september publiserte Jacky Kwok, Hangoo Kang, Tarun Suresh, Jon Saad-Falcon, Marco Pavone, Christopher Ré og Azalia Mirhoseini Contrastive Language Models. Arbeidet utfordrer antakelsen om at Jev er den eneste praktiske veien til raske semantiske beslutninger.

Forfatterne rapporterer sammenlignbare resultater med Jev uten oppgaveeksempler på datamaskinbruk, spill og verktøykall, med opptil 9 ganger lavere forsinkelse. De rapporterer separat 81,6 % på 38 DeepSWE-oppgaver holdt av til testing og 87,6 % på 30 oppgaver fra Terminal-Bench 2.1. Disse programmeringsresultatene bruker finjusterte CLM-verifikatorer som velger mellom løsninger generert av andre modeller. De rapporterer også at Jev ligger under referansen for tilfeldig valg i dette verifikatoroppsettet. Forsinkelsen ble målt på en H100. Dette er forfatternes funn, som vi ikke har gjenskapt uavhengig. Opprinnelig evaluering og metode.

Sammenligningen endrer hva vi bør teste. Å velge en supportkø, velge et søkeutdrag og evaluere et langt programmeringsforløp er forskjellige oppgaver. Et godt resultat på én oppgave avgjør ikke de andre.

CLM koder tilstander og mulige handlinger hver for seg, slik at vektorrepresentasjoner av handlinger kan mellomlagres og gjenbrukes. Kodearkivet dokumenterer et TypeSafe-kompatibelt grensesnitt og en standardgrense på 2 048 tokener for tilstanden. Lengre tilstander kuttes hvis ikke annet er konfigurert. Kompatibilitet på API-grensen betyr ikke at beslutningene er likeverdige.

Modellkortet for utgivelsen spesifiserer Qwen3-8B-vektorrepresentasjoner og advarer om at de sterke verifikatorresultatene krever finjusterte utgangslag. Det presiserer også at CLM vurderer innsendte kandidater og ikke genererer en løsning. Åpne modellvekter gir en mulighet for evaluering. Maskinvare, modellservering og vedlikehold koster fortsatt.

For Tajo er lærdommene konkrete: Sammenlign beslutningsmodeller på de samme tilfellene, registrer forsinkelse ved kald og varm kjøring separat, og test troverdige, men feilaktige kandidater. Lås versjonen av modellen og eventuell koder eller projeksjonslag. Avvis leverandørkonfigurasjoner som ikke støttes, i stedet for å velge en annen leverandør i stillhet. Kontroller kalibreringen på nytt når modellen eller kandidatsettet endres.

De sju arbeidsflytene nedenfor er fortsatt nyttige kandidater for evaluering. Verdien deres avhenger ikke av at Jev vinner alle sammenligninger.

1. Søk som sjekker om resultatet besvarer spørsmålet

Dette er førstevalget mitt fordi feilen er synlig og resultatet er lett å merke. Besvarte utdraget det den besøkende spurte om?

Hent et lite kandidatsett med nøkkelordsøk, vektorrepresentasjoner eller begge deler. Be deretter Jev vurdere om hvert utdrag gir den etterspurte opplysningen. TypeSafes veiledning for omrangering viser denne todelte strukturen. Den viser også begrensningen: En omrangeringsmodell kan ikke velge et dokument som gjenfinningen utelot.

1. Gjenfinning

   nøkkelord, vektorrepresentasjoner

   Lite kandidatsett

   Kan ikke legge til det den gikk glipp av
2. Jev

   vurdering med datatype

   Gir dette utdraget

   den etterspurte opplysningen?
3. Svar

   eller ikke noe svar

   Riktig eller ubesvart

   Samlet forsinkelse målt

For eksemplet vårt med antall integrasjoner er den korteste veien enda enklere. Tell oppføringene i den autoritative katalogen. Forklar hva tallet betyr. En dokumentert kobling og en tilkobling konfigurert av en kunde er forskjellige ting.

Bruk semantisk vurdering til spørsmål der meningen må tolkes, for eksempel «Kan dette flytte bare kunder som har blitt endret siden i går?» Hent relevant dokumentasjon om synkronisering, og kontroller at den omtaler inkrementelle oppdateringer.

Kyle McLarens jevsearch-implementasjon gjør rekkefølgen konkret: Nøkkelordtreff kommer først, fulgt av en Jev-rangering. Den publiserte sammenligningstesten bruker prosjektets egen dokumentasjonssamling og merkede søk. Det er nyttig dokumentasjon om den testen, ikke et løfte for et annet nettsted eller språk.

Mål riktige svar, udokumenterte svar, ubesvarte spørsmål og samlet forsinkelse. Ta med feilstavinger og oversatte søk. Raskere irrelevante resultater er fortsatt irrelevante.

2. Ruting av forespørsler til riktig side, kø eller agent

En bruker skriver: «Kontaktene sluttet å komme inn etter at jeg endret kontoen.» Applikasjonen må skille feilsøking av tilkoblingen fra fakturering, feltmapping og en forespørsel om å opprette en ny synkronisering.

Gi modellen den gjeldende skjermen, den siste samtalen og målene som er tilgjengelige for brukeren. Be om det beste målet, med et uttrykkelig alternativ for ingen treff. La applikasjonen beholde kontrollen over målidentifikatorene.

Flere vurderinger kan være nyttige sammen: hensikt, mål, hastegrad og om meldingen inneholder en forespørsel som kan utføres. TypeSafes fan-out-mønster lar uavhengige spørsmål dele én forespørsel. Koden bruker de relevante svarene etterpå.

Et ufarlig navigasjonsforslag og tillatelse til å utføre arbeid er fortsatt separate beslutninger. Å finne riktig faktureringsside gir ikke tillatelse til refusjon. Å finne riktig agent gir ikke agenten innloggingsopplysninger.

Den praktiske gevinsten er færre overleveringer og færre avklaringsrunder. Mål hvor ofte brukeren når riktig mål på første forsøk. Behold et sett som kan spilles av på nytt, med oppfølginger som «ja», «ny oppgave» og «er de ferdige?» De gir bare mening med kontekst.

3. Mapping av rotete data til en pålitelig integrasjon

Her er en foreslått arbeidsflyt for integrasjon. En eksport fra kilden inneholder customer_email, billing_email og account_owner_email. Målsystemet forventer kontaktens e-postadresse.

Tekstlikhet etterlater en reell tvetydighet. Feltbeskrivelser, eksempelverdier og forretningsformålet hjelper med å løse den. Jev kan velge blant faktiske kildefelt, mens koden sjekker datatyper, obligatoriske verdier og begrensninger i målsystemet.

Den tilknyttede veiledningen for uthenting av forhåndstolkede verdier bruker en særlig nyttig utforming: Koden finner kandidatverdier, modellen velger en kandidat, og koden kopierer originalverdien. Dermed unngår du å generere en erstatningsadresse eller et nytt beløp.

1. Kode

   finn kandidater

   customer_email

   billing_email

   account_owner_email
2. Jev

   velg ett

   Feltbeskrivelser

   Eksempelverdier, formål
3. Kode

   kopier originalverdien

   Datatyper, obligatoriske verdier

   Begrensninger i målsystemet

For en integrasjon mellom CRM og e-post bør du lagre kildefeltet og mappingbeslutningen sammen. Vis en forhåndsvisning av berørte poster. La usikre mappinger stå uavklart til de er gjennomgått.

Dette har en økonomisk fordel: En godkjent skjemamapping kan gjenbrukes. Du trenger ikke et modellkall for hver rad når feltets betydning er uendret.

Mål avviste poster og feilaktige mappinger mot et gjennomgått utvalg. En vellykket API-forespørsel viser at dataene ble akseptert. Den viser ikke at riktig e-post havnet hos riktig kontakt.

4. Valg av den minste modellen som fullfører oppgaven

Modellruting er interessant når en applikasjon sender alt til den dyreste modellen sin. En etikettendring, en søkevurdering og en vanskelig arkitekturutredning har forskjellige krav.

Definer først hvilke modeller som er konfigurert og har lov til å motta oppgavens data. Registrer verktøyene de støtter, og ytelsen du har observert. Deretter kan en avgrenset vurdering anbefale et passende alternativ fra dette settet. TypeSafe tar med mønsteret i sine eksempler på modellruting.

OpenRouters Jev Router tilbyr dette mønsteret med modell-ID-en typesafe/jev-router gjennom sitt chat-API. Oppføringen beskriver valg av både modell og resonneringsnivå etter hvert som samtalen endrer seg. Før du tar den i bruk, bør du evaluere tillatte videre modeller, faktiske kostnader, datahåndtering og oppførsel under verktøykall. Vi har kontrollert oppføringen. Vi har ikke målt ytelsen til denne ruteren.

Retningslinjen vi foreslår, begynner med vanlig kode for eksakte regler og fakta. Bruk en beslutningsmodell for avgrensede semantiske spørsmål, en egnet generativ modell for skriving eller implementering, og opptrapping når resultatene tilsier det.

Hva trenger oppgaven?

1. Eksakte regler og fakta

   Vanlig kode

2. Et avgrenset semantisk spørsmål

   Beslutningsmodell

3. Skriving eller implementering

   En egnet generativ modell

4. Dokumentasjonen tilsier mer

   Trapp opp

Ruteren selv koster tid og penger. For åpenbare oppgaver som gjentar seg, kan en fast regel være bedre. For tvetydige oppgaver bør du sammenligne ruting med en fast modell basert på fullført arbeid.

Følg kostnad per akseptert resultat, nye forsøk, opptrappingsrate og feil som oppdages senere. Et billigere første kall kan bli en dyr arbeidsflyt hvis noen må reparere resultatet.

5. Kontroll av påstander før de blir svar til kunder

En kildehenvisning kan finnes uten å støtte setningen ved siden av. Kilden kan beskrive en planlagt funksjon mens svaret sier at den er tilgjengelig i dag.

TypeSafes veiledning for kontroll av kildehenvisninger skiller mellom to sjekker. Vanlig tekstsammenligning oppdager et sitat som ikke finnes. En semantisk vurdering undersøker om teksten rundt sitatet støtter påstanden.

Bruk samme utforming på et supportsvar, en generert integrasjonsveiledning eller en agents foreslåtte rapport om fullført arbeid. Behold påstanden, kildeutdraget og vurderingen slik at de kan gjennomgås.

Fullføring krever fortsatt direkte bevis. Tester dokumenterer testet oppførsel. En utrullingslogg dokumenterer en utrulling. En semantisk vurdering kan påpeke avvik mellom en rapport og dokumentasjonen. Den kan ikke skape dokumentasjonen som mangler.

Dette bruksområdet er interessant fordi det kan plasseres før et eksisterende publiseringstrinn. Mål udokumenterte påstander som slipper gjennom, dokumenterte påstander som blokkeres unødvendig, og kontrollarbeidet som oppstår. Begynn med konkrete feil du allerede vet at systemet gjør.

6. Å gjøre transkripsjoner og kundetilbakemeldinger til nyttige utvalg

Et transkripsjonsarkiv blir nyttig når noen kan finne utdraget som betyr noe. «Inneholder ordet integrasjon» er et svakt filter for «forklarer hvorfor en kunde avbrøt oppsettet».

En tilnærming er å hente sannsynlige utdrag og deretter vurdere noen få egenskaper: Beskriver dette et oppsetthinder, inneholder det et konkret eksempel, eller gir det mening alene uten manglende kontekst?

Behold kildens URL og tidsstempelet sammen med hvert valgt utdrag. Tidsstempelet kommer fra transkripsjonen. Modellen vurderer relevansen.

For en videoredigerer kan disse signalene gi et kort utvalg klipp til gjennomgang. For et produktteam kan de organisere gjentatte innvendinger. For en markedsfører kan de skille kundebevis fra udokumenterte kampanjepåstander.

TypeSafes mønster for sammensatt poengsetting holder dimensjonene atskilt, slik at koden kan endre vektingen. Et klipp som passer til en veiledning, kan være annerledes enn et klipp til en kort produktdemonstrasjon. Gjenbruk vurderingene når den underliggende dokumentasjonen og kriteriene er uendret.

JevQL tilbyr en beslektet implementasjon fra fellesskapet: semantiske betingelser over PostgreSQL-rader, evaluert utenfor databasen. Dokumentasjonen viser at vanlige filtre påvirker regningen. Reduser antallet aktuelle rader før du ber om semantiske vurderinger.

Mål hvor ofte utvalget blir godkjent, og tiden som spares på å finne brukbart materiale. En score for hvor fengende åpningen er, er ikke en prognose for visninger.

7. Grensesnitt som velger neste nyttige handling

En innstillingsside kan få beskjeden «Stopp denne synkroniseringen til i morgen». En nettleseragent kan måtte velge blant kontrollene som er synlige på den gjeldende siden.

I grensesnittet vi foreslår, oppgir applikasjonen tillatte handlinger og nåværende tilstand. Jev velger mellom dem. Grensesnittet viser den relevante kontrollen eller et forslag som kan gjennomgås.

Ship with Jev inkluderer Gregor Zunics demonstrasjon av flysøk i nettleseren. Rapportert kjøretid og kostnad gjelder den demonstrasjonen. Ideen som kan overføres, er å velge blant handlingene som er tilgjengelige på hvert trinn. En annen nettleserflyt trenger sin egen verifisering.

Tilstanden må være oppdatert. Hvis valgt konto eller side endres mens en vurdering pågår, forkast det utdaterte resultatet. Knytt handlingene til kontoen og tilstanden som ble gjennomgått.

Dette kan også gjøre en katalog med typede grensesnitt nyttig. En modell velger en kjent visning og dens avgrensede data. Vanlig visningskode lager grensesnittet. Mål vellykket fullføring og feilaktige handlinger, med særlig vekt på om kontrollene fortsatt er forståelige.

Hvor jeg ville begynt

Velg den gjentatte beslutningen som allerede skaper synlig sløsing. Bygg evalueringssettet fra de faktiske feilene.

Eksisterende problem	Første eksperiment	Dokumentasjon det er verdt å samle
Søket besvarer feil spørsmål	Vurder et kort utvalg hentede treff	Riktige svar, avståelser, forsinkelse
Forespørsler sendes frem og tilbake mellom team	Velg blant tillatte køer	Treffsikkerhet ved første ruting, overleveringer
Import krever manuell mapping	Velg faktiske kildefelt	Mappingfeil, gjennomgangstid
Alle oppgaver bruker den største modellen	Rut oppgaver som oppfyller kravene	Kostnad per akseptert resultat
Genererte svar påstår for mye	Kontroller påstander mot kildene	Udokumenterte påstander som slipper gjennom
Ingen bruker transkripsjonsarkivet	Returner utdrag med tidsstempler	Godkjenning ved gjennomgang, tid til å finne bevis
Brukerne finner ikke kontrollene	Foreslå en tilgjengelig handling	Fullføringsrate, feilvalg

Ikke kopier konfidensgrensen fra en demonstrasjon. TypeSafes dokumentasjon om konfidens forklarer at konfidens for Choice og Score oppsummerer en fordeling. Den beviser ikke at inndataene var komplette, eller at den valgte handlingen er tillatt.

Ta med tilfeller der ingen av kandidatene passer. Ta med en utilgjengelig tjeneste. Ta med hvert språk du vil støtte. Behold modellversjonen og spørsmålsdefinisjonene sammen med resultatene, slik at en senere endring kan sammenlignes rettferdig.

For et integrasjonsprodukt ville jeg begynt med søkerelevans og feltmapping. Begge forkorter veien til en fungerende synkronisering. Begge lar deg undersøke feilen før den vokser til et kundeproblem.

Velg ett galt svar programvaren din gir i dag. Få den til å ta riktig neste steg pålitelig.