7 måder at bruge Jev på, som fjerner reelt arbejde fra software

Nogen spurgte vores hjemmeside, hvor mange integrationer vi har. Den svarede med råd om, hvor mange felter der bør være i en tilmeldingsformular.

Svaret kom hurtigt. Det var ubrugeligt.

Begge spørgsmål indeholdt »hvor mange«. Vores søgekode gav et accepteret FAQ-match en minimumsscore på 0,86, så et svagt match kom til at se overbevisende ud. Hastigheden skjulte den forkerte beslutning.

Den slags fejl er værd at tænke på, når du ser på Ship with Jev. Den 26. september 2026 havde kataloget 551 projekter fra fællesskabet. Spil står side om side med søgekomponenter, browseragenter, researchværktøjer og forsøg med routing. Kataloget tilskriver præstationstallene projekternes ophavspersoner. Det er et sted at opdage projekter, ikke en uafhængig benchmark.

Det interessante spørgsmål er, hvilke af mønstrene der fjerner arbejde fra et rigtigt produkt.

For teams, der bygger integrationer og erhvervssoftware, er det disse syv, jeg ville evaluere først. Rækkefølgen er min redaktionelle vurdering af nytte og testbarhed. Arbejdsgangene nedenfor er forslag til design, medmindre jeg nævner en konkret implementering med link.

Hvad Jev bidrager med i en applikation

TypeSafe beskriver Jev som en model for typede vurderinger. Giv den relevant tilstand og et spørgsmål; du får et valg, en sandsynlighed eller en score, som kode kan bruge. Dens oversigt over anvendelser omfatter routing, søgning, verifikation og udtræk.

Den skelnen har en nyttig forløber i det YouTube-materiale, vi har indlæst. I Diogo Almeidas oplæg ved AI Engineer argumenterer TypeSafes medstifter for software, hvis byggesten kan udtrykke mere intelligens. Han stiller den ambition over for blot at føje en assistent til eksisterende software. Det er hans argument om AI’s retning, ikke en benchmark af Jevs nuværende præstation.

Tænk på et jernbanesporskifte. Det nyttige output er, hvilket af de tilgængelige spor toget skal tage. Et afsnit, der beskriver sporene, flytter ikke skiftet.

Indvendingen er rimelig: »En almindelig LLM kan allerede returnere JSON.« Ja. Begrundelsen for en anden komponent afhænger af målt kvalitet, pris og latenstid for netop den beslutning. Et typet svar alene beviser intet af det.

Udfordringen fra CLM fortjener førstepladsen

Den 23. september udgav Jacky Kwok, Hangoo Kang, Tarun Suresh, Jon Saad-Falcon, Marco Pavone, Christopher Ré og Azalia Mirhoseini Contrastive Language Models. Arbejdet udfordrer antagelsen om, at Jev er den eneste praktiske vej til hurtige semantiske beslutninger.

Forfatterne rapporterer zero-shot-resultater på niveau med Jev i opgaver med computerbetjening, spil og værktøjskald, med op til 9 gange lavere latenstid. Separat rapporterer de 81,6 % på 38 tilbageholdte DeepSWE-opgaver og 87,6 % på 30 Terminal-Bench 2.1-opgaver. Programmeringsresultaterne bruger finjusterede CLM-verifikatorer, som vælger mellem løsninger genereret af andre modeller. De rapporterer også, at Jev lå under deres reference med tilfældigt valg i dette verifikationsforsøg. Latenstiden blev målt på en H100. Det er forfatternes resultater, som vi ikke selv har efterprøvet. Original evaluering og metode.

Sammenligningen ændrer, hvad vi bør teste. At vælge en supportkø, udpege en søgeresultatpassage og vurdere et langt programmeringsforløb er forskellige opgaver. Et godt resultat på én afgør ikke de andre.

CLM koder tilstande og mulige handlinger separat, så repræsentationer af handlinger, der kan genbruges, kan lægges i cache. Dets repository dokumenterer en TypeSafe-kompatibel grænseflade og en standardgrænse på 2.048 tokens for tilstanden. Længere tilstande afkortes, medmindre det konfigureres anderledes. Kompatibilitet ved API-grænsen garanterer ikke ens beslutninger.

Modelkortet for udgivelsen angiver Qwen3-8B-repræsentationer og advarer om, at de stærke verifikationsresultater kræver finjusterede hoveder. Det gør også klart, at CLM scorer givne kandidater og ikke selv genererer en løsning. Åbne vægte giver mulighed for evaluering; hardware, drift og vedligeholdelse koster stadig.

For Tajo er læringen konkret: Sammenlign beslutningsmodeller på de samme tilfælde, registrer kold og varm latenstid hver for sig, og test plausible, men forkerte kandidater. Fasthold revisionen af modellen og eventuelle encodere eller projektionshoveder. Afvis ikke-understøttede leverandørkonfigurationer i stedet for stille at vælge en anden leverandør. Kontrollér kalibreringen igen, når modellen eller kandidatsættet ændres.

De syv arbejdsgange nedenfor er stadig gode kandidater til evaluering. Deres værdi afhænger ikke af, at Jev vinder hver sammenligning.

1. Søgning, der tjekker, om resultatet besvarer spørgsmålet

Det er mit førstevalg, fordi fejlen er synlig og resultatet let at markere. Besvarede den returnerede passage det, den besøgende spurgte om?

Hent et lille sæt kandidater med søgeord, vektorrepræsentationer eller begge dele. Spørg så Jev, om hver passage indeholder den ønskede oplysning. TypeSafes vejledning om omrangering viser denne todelte struktur. Den viser også grænsen: En omrangering kan ikke vælge et dokument, som den første søgning udelod.

1. Hentning

   søgeord, vektorrepræsentationer

   Lille sæt kandidater

   Kan ikke tilføje det, den missede
2. Jev

   typet vurdering

   Indeholder denne passage

   den ønskede oplysning?
3. Svar

   eller intet svar

   Korrekt eller ubesvaret

   Samlet latenstid målt

For vores eksempel med antallet af integrationer er den korteste vej endnu enklere. Tæl posterne i det autoritative katalog. Forklar, hvad tallet betyder. En dokumenteret connector og en forbindelse, en kunde har sat op, er to forskellige ting.

Gem semantiske vurderinger til spørgsmål, der kræver fortolkning, som »Kan dette kun overføre kunder, der er ændret siden i går?« Hent den relevante dokumentation om synkronisering og kontrollér, at den beskriver inkrementelle opdateringer.

Kyle McLarens jevsearch-implementering gør rækkefølgen håndgribelig: Søgeordsresultaterne kommer først, derefter Jevs rangering. Den offentliggjorte benchmark bruger projektets eget dokumentationsmateriale og mærkede forespørgsler. Det er evidens om den test, ikke et løfte for en anden hjemmeside eller et andet sprog.

Mål korrekte svar, udokumenterede svar, ubesvarede spørgsmål og samlet latenstid. Medtag stavefejl og oversatte søgninger. Hurtigere irrelevante resultater er stadig irrelevante.

2. Send henvendelser til den rigtige side, kø eller agent

En bruger skriver: »Kontakterne holdt op med at komme ind, efter at jeg ændrede kontoen.« Din applikation skal skelne fejlfinding af forbindelsen fra fakturering, feltmapping og et ønske om at oprette en ny synkronisering.

Send den aktuelle skærm, den seneste samtale og de destinationer, brugeren har adgang til. Bed om den bedste destination med en udtrykkelig »intet match«-mulighed. Applikationen beholder selv kontrollen over destinationernes id’er.

Flere vurderinger kan være nyttige på én gang: hensigt, destination, hastende karakter og om beskeden rummer en konkret anmodning. TypeSafes fan-out-mønster lader uafhængige spørgsmål dele én anmodning. Koden bruger derefter de relevante svar.

Et harmløst navigationsforslag og tilladelse til at udføre arbejde er stadig separate beslutninger. At finde den rigtige faktureringsside giver ikke lov til at udstede en refusion. At finde den rigtige agent giver ikke agenten adgangsoplysninger.

Den praktiske gevinst er færre overdragelser og færre runder med opklarende spørgsmål. Mål, hvor ofte brugeren når den rigtige destination i første forsøg. Gem et testsæt med opfølgende beskeder som »ja«, »ny opgave« og »er de færdige?«. De giver kun mening med kontekst.

3. Map rodede data til en pålidelig integration

Her er et foreslået integrationsforløb. En eksport fra kilden indeholder customer_email, billing_email og account_owner_email. Destinationen forventer kontaktens e-mailadresse.

Lighed mellem feltnavne efterlader en reel tvetydighed. Feltbeskrivelser, eksempelværdier og forretningsformål hjælper med at løse den. Jev kan vælge blandt faktiske kildefelter, mens kode kontrollerer typer, påkrævede værdier og destinationens begrænsninger.

Den beslægtede vejledning i udtræk af allerede analyserede værdier bruger et særligt nyttigt design: Kode finder mulige værdier, modellen vælger én, og kode kopierer den oprindelige værdi. Dermed genereres der ikke en ny adresse eller et nyt beløb.

1. Kode

   find kandidater

   customer_email

   billing_email

   account_owner_email
2. Jev

   vælg ét

   Feltbeskrivelser

   Eksempelværdier, formål
3. Kode

   kopiér oprindelig værdi

   Typer, påkrævede værdier

   Destinationens begrænsninger

For en integration mellem CRM og e-mailmarketing skal du bevare kildefeltet og beslutningen om mapping sammen. Vis et eksempel på de berørte poster. Lad usikre mappings være uafklarede, indtil nogen har gennemgået dem.

Der er en økonomisk fordel: En godkendt skemamapping kan genbruges. Du behøver ikke et modelkald for hver række, når feltets betydning er uændret.

Mål afviste poster og forkerte mappings i forhold til en gennemgået stikprøve. Et vellykket API-kald beviser, at dataene blev accepteret; det beviser ikke, at den rigtige e-mailadresse endte hos den rigtige kontakt.

4. Vælg den mindste model, der kan løse opgaven

Modelrouting er interessant, når en applikation sender alt til sin dyreste model. En ændring af en etiket, en søgevurdering og en vanskelig arkitekturundersøgelse stiller forskellige krav.

Fastlæg først de modeller, der er konfigureret og må modtage opgavens data. Registrer deres understøttede værktøjer og observerede præstation. Derefter kan en afgrænset vurdering anbefale en passende mulighed fra dette sæt. TypeSafe beskriver mønsteret i sine eksempler på modelrouting.

OpenRouters Jev Router tilbyder mønsteret som model-id’et typesafe/jev-router gennem sin chat-API. Beskrivelsen nævner valg af både model og ræsonnementindsats, efterhånden som en samtale ændrer sig. Undersøg tilladte efterfølgende modeller, faktiske udgifter, databehandling og adfærd ved værktøjskald før brug. Vi har verificeret beskrivelsen, men ikke benchmark-testet routeren.

Vores foreslåede politik begynder med almindelig kode til præcise regler og fakta. Brug en beslutningsmodel til afgrænsede semantiske spørgsmål, en passende generativ model til tekst eller implementering og eskalering, når evidensen begrunder det.

Hvad kræver opgaven?

1. Præcise regler og fakta

   Almindelig kode

2. Et afgrænset semantisk spørgsmål

   Beslutningsmodel

3. Tekst eller implementering

   En passende generativ model

4. Evidensen begrunder mere

   Eskalér

Routeren koster selv tid og penge. Til åbenlyse, gentagelige opgaver kan en fast regel være bedre. Til tvetydige opgaver bør du sammenligne routing med en fast model på færdigt arbejde.

Følg omkostning per accepteret resultat, gentagne forsøg, eskaleringsrate og fejl, der opdages senere. Et billigt første kald kan blive en dyr arbejdsgang, hvis nogen skal rette outputtet.

5. Kontrollér påstande, før de når kunderne

En kildehenvisning kan eksistere uden at understøtte sætningen ved siden af. En kilde kan beskrive en planlagt funktion, mens svaret siger, at den findes i dag.

TypeSafes vejledning i citationskontrol adskiller to kontroller. Almindelig sammenligning af tekst finder et manglende citat. En semantisk vurdering afgør, om kildeteksten omkring det understøtter påstanden.

Brug samme design til et supportsvar, en genereret integrationsvejledning eller en agents foreslåede afslutningsrapport. Opbevar påstand, kildepassage og afgørelse, så de kan gennemgås.

Afslutning kræver stadig direkte beviser. Test viser testet adfærd. En udrulningslog viser en udrulning. En semantisk vurdering kan pege på uoverensstemmelser mellem en rapport og dens beviser; den kan ikke skabe manglende beviser.

Anvendelsen er tiltalende, fordi kontrollen kan ligge før et eksisterende publiceringstrin. Mål udokumenterede påstande, der slipper igennem, dokumenterede påstande, der blokeres unødigt, og det ekstra arbejde ved gennemgangen. Begynd med konkrete fejl, dit system allerede begår.

6. Gør transskriptioner og kundefeedback til nyttige udvalg

Et arkiv med transskriptioner bliver nyttigt, når nogen kan finde den passage, der betyder noget. »Indeholder ordet integration« er et svagt filter for »forklarer, hvorfor en kunde opgav opsætningen«.

En metode er at hente sandsynlige passager og derefter bedømme få konkrete egenskaber: Beskriver passagen en hindring under opsætning, rummer den et konkret eksempel, eller kan den forstås uden manglende kontekst?

Knyt kilde-URL og tidsstempel til hver udvalgt passage. Tidsstemplet kommer fra transskriptionen. Modellen vurderer relevansen.

For en videoredaktør kan signalerne give en kort liste over klip til gennemsyn. Et produktteam kan bruge dem til at organisere tilbagevendende indvendinger. Et marketingteam kan adskille kundernes beviser fra udokumenterede kampagnepåstande.

TypeSafes mønster for sammensat scoring holder dimensionerne adskilt, så kode kan ændre deres vægte. Et klip til en vejledning kan være anderledes end et klip til en kort produktdemo. Genbrug vurderingerne, så længe evidens og kriterier er uændrede.

JevQL er en beslægtet implementering fra fællesskabet: semantiske betingelser for PostgreSQL-rækker, vurderet uden for databasen. Dokumentationen viser, at almindelige filtre påvirker regningen. Begræns de relevante rækker, før du beder om semantiske vurderinger.

Mål, hvor mange forslag gennemseerne accepterer, og hvor meget tid de sparer på at finde brugbart materiale. En score for en stærk åbning er ikke en forudsigelse af visninger.

7. Grænseflader, der vælger den næste nyttige handling

En indstillingsside kan få beskeden »Stop denne synkronisering indtil i morgen«. En browseragent kan skulle vælge mellem kontrollerne på den aktuelle side.

I vores foreslåede grænseflade leverer applikationen tilladte handlinger og aktuel tilstand. Jev vælger mellem dem. Grænsefladen viser den relevante kontrol eller et forslag, som kan gennemgås.

Ship with Jev indeholder Gregor Zunics demo med flysøgning i browseren. Den angivne køretid og pris gælder den demonstration. Idéen, man kan overføre, er at vælge blandt tilgængelige handlinger ved hvert trin; et andet browserforløb kræver sin egen kontrol.

Tilstandens aktualitet betyder noget. Hvis den valgte konto eller side ændrer sig, mens vurderingen kører, skal du kassere det forældede resultat. Bind handlingerne til den konto og den tilstand, som blev gennemgået.

Det kan også gøre et katalog over typede grænseflader nyttigt. En model vælger en kendt visning og dens afgrænsede data; almindelig renderingskode bygger grænsefladen. Mål gennemførte opgaver og forkerte handlinger, især om kontrollerne fortsat er forståelige.

Hvor jeg ville begynde

Vælg den gentagne beslutning, der allerede skaber synligt spild. Brug dens faktiske fejl til at bygge evalueringssættet.

Nuværende problem	Første forsøg	Data, der er værd at indsamle
Søgning besvarer det forkerte spørgsmål	Bedøm en kort liste over fundne resultater	Korrekte svar, afståelser, latenstid
Henvendelser sendes mellem teams	Vælg mellem tilladte køer	Præcision ved første routing, overdragelser
Import kræver manuel feltmapping	Vælg reelle kildefelter	Mappingfejl, tid til gennemgang
Alle opgaver bruger den største model	Send egnede opgaver videre	Pris per accepteret resultat
Genererede svar lover for meget	Kontrollér påstande mod kilder	Udokumenterede påstande, der slipper igennem
Ingen bruger transskriptionsarkivet	Returnér passager med tidsstempler	Accept hos gennemseere, tid til at finde beviser
Brugerne kan ikke finde kontroller	Foreslå en tilgængelig handling	Gennemførelsesgrad, forkerte valg

Kopiér ikke en demos tærskel for konfidens. TypeSafes dokumentation om konfidens forklarer, at Choice- og Score-konfidens opsummerer en fordeling. Den beviser hverken, at input var fuldstændige, eller at den valgte handling er tilladt.

Medtag tilfælde, hvor ingen af kandidaterne passer. Medtag en utilgængelig tjeneste. Medtag hvert sprog, du vil understøtte. Gem modelrevision og spørgsmålsdefinitioner sammen med resultaterne, så en senere ændring kan sammenlignes retfærdigt.

For et integrationsprodukt ville jeg begynde med søgerelevans og feltmapping. Begge forkorter vejen til en fungerende synkronisering. Begge lader dig opdage fejlen, før den bliver et problem for kunden.

Vælg ét forkert svar, din software giver i dag. Få den til pålideligt at tage det rigtige næste skridt.