7 sätt att använda Jev som sparar verkligt arbete i programvara

Någon frågade vår webbplats hur många integrationer vi har. Den svarade med råd om hur många fält ett registreringsformulär bör innehålla.

Svaret kom snabbt. Det var värdelöst.

Båda frågorna innehöll ”hur många”. Vår sökkod gav en godkänd FAQ-träff minst 0,86 poäng, vilket fick en svag träff att se övertygande ut. Hastigheten dolde det felaktiga beslutet.

Den sortens fel är värda att tänka på när du tittar på Ship with Jev. Den 26 september 2026 listade katalogen 551 projekt från communityn. Spel finns sida vid sida med sökkomponenter, webbläsaragenter, forskningsverktyg och försök med dirigering. Katalogen tillskriver projektens skapare siffrorna om prestanda. Den hjälper dig att upptäcka projekt, men är ingen oberoende jämförelse.

Den intressanta frågan är vilka av mönstren som tar bort arbete från en verklig produkt.

För team som bygger integrationer och företagsprogram är det dessa sju användningar jag skulle utvärdera först. Ordningen är min bedömning av nytta och möjligheten att testa dem. Arbetsflödena nedan är designförslag om ingen konkret implementation länkas.

Vad Jev tillför en applikation

TypeSafe beskriver Jev som en modell för typade bedömningar. Ge den relevant tillstånd och en fråga; du får ett val, en sannolikhet eller en poäng som kod kan använda. Dess karta över användningsfall omfattar dirigering, informationshämtning, verifiering och extraktion.

Den skillnaden har en användbar föregångare i vårt inlästa YouTube-material. I Diogo Almeidas föredrag på AI Engineer argumenterar TypeSafes medgrundare för programvara vars byggstenar kan uttrycka mer intelligens. Han ställer den ambitionen mot att fästa en assistent vid befintlig programvara. Det är hans argument om vart AI är på väg, ingen mätning av Jevs nuvarande prestanda.

Tänk på en järnvägsväxel. Det användbara resultatet är vilket tillgängligt spår tåget ska ta. Ett stycke som beskriver spåren flyttar inte växeln.

Invändningen är rimlig: ”En vanlig LLM kan redan returnera JSON.” Ja. Skälet att använda en annan komponent beror på uppmätt kvalitet, kostnad och svarstid för just det beslutet. Ett typat svar bevisar i sig inget av detta.

Utmaningen från CLM förtjänar att komma först

Den 23 september publicerade Jacky Kwok, Hangoo Kang, Tarun Suresh, Jon Saad-Falcon, Marco Pavone, Christopher Ré och Azalia Mirhoseini Contrastive Language Models. Deras arbete ifrågasätter antagandet att Jev är den enda praktiska vägen till snabba semantiska beslut.

Författarna rapporterar zero-shotresultat jämförbara med Jevs för datoranvändning, spel och verktygsanrop, med upp till 9 gånger lägre svarstid. Separat rapporterar de 81,6 % på 38 undanhållna DeepSWE-uppgifter och 87,6 % på 30 Terminal-Bench 2.1-uppgifter. Programmeringsresultaten bygger på finjusterade CLM-verifierare som väljer mellan lösningar skapade av andra modeller. De rapporterar också att Jev hamnar under deras baslinje med slumpmässigt urval i det verifieringsupplägget. Svarstiden mättes på en H100. Det här är författarnas resultat, som vi inte har återskapat oberoende. Ursprunglig utvärdering och metod.

Jämförelsen förändrar vad vi bör testa. Att välja en supportkö, hitta ett sökavsnitt och bedöma ett långt programmeringsförlopp är olika uppgifter. Ett bra resultat i en av dem avgör inte de andra.

CLM kodar tillstånd och möjliga handlingar separat, vilket gör att representationer av återanvändbara handlingar kan lagras i cache. Dess kodarkiv dokumenterar ett TypeSafe-kompatibelt gränssnitt och en standardgräns på 2 048 token för tillståndet. Längre tillstånd kapas om inget annat anges i konfigurationen. Kompatibla API:er innebär inte likvärdiga beslut.

Modellkortet för den publicerade modellen anger Qwen3-8B-representationer och varnar för att de starka verifieringsresultaten kräver finjusterade huvuden. Det gör också klart att CLM poängsätter angivna kandidater och inte skapar en lösning. Öppna vikter ger en möjlighet att utvärdera; hårdvara, drift och underhåll kostar fortfarande.

För Tajo är lärdomarna konkreta: jämför beslutsmodeller på samma fall, registrera kall och varm svarstid var för sig och testa rimliga men felaktiga kandidater. Lås versionen av modellen och varje kodare eller projektionshuvud. Avvisa konfigurationer för leverantörer som inte stöds i stället för att tyst välja en annan. Kontrollera kalibreringen igen när modellen eller kandidaterna ändras.

De sju arbetsflödena nedan är fortfarande bra kandidater att utvärdera. Deras värde kräver inte att Jev vinner varje jämförelse.

1. Sökning som kontrollerar om resultatet besvarar frågan

Det här är mitt förstahandsval eftersom felet syns och resultatet är lätt att märka upp. Besvarade det hittade avsnittet besökarens fråga?

Hämta en liten uppsättning kandidater med nyckelordssökning, vektorrepresentationer eller båda. Fråga sedan Jev om varje avsnitt ger den efterfrågade uppgiften. TypeSafes guide för omrankning visar den här tvåstegsmodellen. Den visar också begränsningen: en omrankare kan inte välja ett dokument som den första sökningen inte hittade.

1. Hämtning

   nyckelord, vektorrepresentationer

   Liten uppsättning kandidater

   Kan inte lägga till det som missades
2. Jev

   typad bedömning

   Ger det här avsnittet

   den efterfrågade uppgiften?
3. Svar

   eller inget svar

   Rätt eller obesvarat

   Total svarstid mäts

För vårt exempel med antalet integrationer är den kortaste vägen ännu enklare. Räkna posterna i den officiella katalogen. Berätta vad antalet betyder. En dokumenterad connector och en anslutning som en kund har konfigurerat är olika saker.

Spara semantiska bedömningar till frågor vars innebörd måste tolkas, som ”Kan den här bara överföra kunder som ändrats sedan i går?” Hämta relevant synkroniseringsdokumentation och kontrollera om den behandlar inkrementella uppdateringar.

Kyle McLarens jevsearch-implementation gör ordningen konkret: nyckelordsresultat kommer först, följda av Jevs rankning. Den publicerade jämförelsen använder projektets egen dokumentation och märkta sökfrågor. Det är belägg för just det testet, inte ett löfte för en annan webbplats eller ett annat språk.

Mät korrekta svar, svar utan stöd, obesvarade frågor och total svarstid. Ta med stavfel och översatta sökfrågor. Snabbare irrelevanta resultat är fortfarande irrelevanta.

2. Skicka förfrågningar till rätt sida, kö eller agent

En användare skriver: ”Kontakterna slutade komma in efter att jag ändrade kontot.” Din applikation måste skilja ett anslutningsproblem från fakturering, fältmappning och en begäran om att skapa en ny synkronisering.

Skicka med den aktuella skärmen, den senaste konversationen och de destinationer som användaren har tillgång till. Be om den bästa destinationen, med ett tydligt alternativ för ”ingen träff”. Applikationen behåller kontrollen över destinationernas ID:n.

Flera bedömningar kan vara användbara tillsammans: avsikt, destination, hur brådskande det är och om meddelandet innehåller en begäran som går att utföra. TypeSafes fan-out-mönster låter oberoende frågor dela en enda förfrågan. Koden använder sedan de relevanta svaren.

Ett ofarligt navigationsförslag och tillstånd att utföra arbete är fortfarande två skilda beslut. Att hitta rätt faktureringssida ger inte tillstånd till återbetalning. Att hitta rätt agent ger inte agenten inloggningsuppgifter.

Den praktiska nyttan är färre överlämningar och färre rundor med följdfrågor. Mät hur ofta användaren når rätt destination på första försöket. Behåll en testuppsättning med följdsvar som ”ja”, ”ny uppgift” och ”är de klara?”. De blir begripliga först med sammanhang.

3. Mappa stökiga data till en tillförlitlig integration

Här är ett föreslaget integrationsflöde. En export från källan innehåller customer_email, billing_email och account_owner_email. Mottagaren förväntar sig kontaktens e-postadress.

Likhet mellan fältnamn lämnar en verklig tvetydighet. Fältbeskrivningar, exempelvärden och affärssyftet hjälper till att lösa den. Jev kan välja bland de faktiska källfälten medan kod kontrollerar typer, obligatoriska värden och mottagarens begränsningar.

Den relaterade guiden för extraktion av redan analyserade värden använder en särskilt bra lösning: kod hittar möjliga värden, modellen väljer ett och kod kopierar originalvärdet. Då skapas ingen ny adress och inget nytt belopp.

1. Kod

   hitta kandidater

   customer_email

   billing_email

   account_owner_email
2. Jev

   välj ett

   Fältbeskrivningar

   Exempelvärden, syfte
3. Kod

   kopiera originalvärdet

   Typer, obligatoriska värden

   Mottagarens begränsningar

För en integration mellan CRM och e-postmarknadsföring bör du spara källfältet och mappningsbeslutet tillsammans. Visa en förhandsgranskning av berörda poster. Låt osäkra mappningar vara olösta tills de granskats.

Här finns en ekonomisk fördel: en godkänd schemamappning kan återanvändas. Du behöver inte anropa modellen för varje rad när fältets betydelse inte har ändrats.

Mät avvisade poster och felaktiga mappningar mot ett granskat urval. Ett lyckat API-anrop visar att data accepterades; det visar inte att rätt e-postadress hamnade hos rätt kontakt.

4. Välj den minsta modellen som klarar uppgiften

Modelldirigering är lockande när en applikation skickar allt till sin dyraste modell. Att ändra en etikett, bedöma ett sökresultat och undersöka en svår arkitektur ställer olika krav.

Definiera först vilka modeller som är konfigurerade och får ta emot uppgiftens data. Registrera vilka verktyg de stöder och deras observerade resultat. Sedan kan en avgränsad bedömning rekommendera ett lämpligt alternativ ur gruppen. TypeSafe visar mönstret i sina exempel på modelldirigering.

OpenRouters Jev Router erbjuder mönstret som modell-ID typesafe/jev-router genom sitt chatt-API. Listningen beskriver hur både modell och resonemangsnivå väljs när samtalet förändras. Undersök vilka bakomliggande modeller som tillåts, faktiska kostnader, datahantering och beteendet vid verktygsanrop innan du använder den. Vi har kontrollerat listningen men inte jämfört routern i ett test.

Vår föreslagna policy börjar med vanlig kod för exakta regler och fakta. Använd en beslutsmodell för avgränsade semantiska frågor, en lämplig generativ modell för skrivande eller implementation och eskalering när beläggen motiverar det.

Vad kräver uppgiften?

1. Exakta regler och fakta

   Vanlig kod

2. En avgränsad semantisk fråga

   Beslutsmodell

3. Skrivande eller implementation

   En lämplig generativ modell

4. Beläggen motiverar mer

   Eskalera

Routern själv kostar tid och pengar. För uppenbara, upprepade uppgifter kan en fast regel vara bättre. Jämför dirigering med en fast modell på färdigt arbete för tvetydiga uppgifter.

Följ kostnad per godkänt resultat, nya försök, eskaleringsgrad och fel som upptäcks senare. Ett billigt första anrop kan bli ett dyrt arbetsflöde om någon måste rätta dess resultat.

5. Kontrollera påståenden innan kunder får läsa dem

En källhänvisning kan finnas utan att stödja meningen bredvid. En källa kan beskriva en planerad funktion medan svaret påstår att den finns i dag.

TypeSafes guide för kontroll av citat skiljer mellan två kontroller. Vanlig textjämförelse upptäcker ett saknat citat. En semantisk bedömning avgör om det omgivande källavsnittet stöder påståendet.

Använd samma upplägg för ett supportsvar, en genererad integrationsguide eller en agents föreslagna slutrapport. Spara påstående, källavsnitt och slutsats så att de kan granskas.

Slutförande kräver fortfarande direkta belägg. Tester styrker det beteende som testades. En distributionslogg styrker en distribution. En semantisk bedömning kan flagga skillnaden mellan en rapport och dess belägg; den kan inte skapa belägg som saknas.

Det här användningsfallet är attraktivt eftersom kontrollen kan ske före ett befintligt publiceringssteg. Mät påståenden utan stöd som slinker igenom, påståenden med stöd som stoppas i onödan och granskningsarbetet som skapas. Börja med tydliga fel som systemet redan gör.

6. Gör transkriptioner och kundrespons till användbara urval

Ett transkriptionsarkiv blir användbart när någon kan hitta avsnittet som spelar roll. ”Innehåller ordet integration” är ett svagt filter för ”förklarar varför en kund avbröt installationen”.

Ett sätt är att hämta sannolika avsnitt och sedan bedöma några särskilda egenskaper: beskriver avsnittet ett hinder vid installationen, innehåller det ett konkret exempel eller går det att förstå utan saknat sammanhang?

Behåll källans URL och tidsstämpel vid varje utvalt avsnitt. Tidsstämpeln kommer från transkriptionen. Modellen bedömer relevansen.

För en videoredigerare kan signalerna ge ett kort urval klipp att granska. För ett produktteam kan de ordna återkommande invändningar. För marknadsföring kan de skilja kundbelägg från kampanjpåståenden utan stöd.

TypeSafes mönster för sammansatt poängsättning håller dimensionerna åtskilda så att koden kan ändra deras vikt. Ett klipp som passar en handledning kan skilja sig från ett som passar en kort produktdemonstration. Återanvänd bedömningarna så länge belägg och kriterier inte ändras.

JevQL är en närliggande communityimplementation: semantiska villkor för PostgreSQL-rader, utvärderade utanför databasen. Dokumentationen visar varför vanliga filter påverkar kostnaden. Minska antalet möjliga rader innan du begär semantiska bedömningar.

Mät hur ofta granskare accepterar urvalet och hur mycket tid de sparar när de hittar användbart material. Ett betyg på hur stark en inledning är förutsäger inte antalet visningar.

7. Gränssnitt som väljer nästa användbara åtgärd

En inställningssida kan få meddelandet ”Pausa denna synkronisering till i morgon”. En webbläsaragent kan behöva välja bland reglagen som syns på den aktuella sidan.

I vårt föreslagna gränssnitt ger applikationen tillåtna åtgärder och aktuellt tillstånd. Jev väljer bland dem. Gränssnittet visar det relevanta reglaget eller ett förslag som går att granska.

Ship with Jev visar Gregor Zunics demo för flygsökning i webbläsaren. Den rapporterade tiden och kostnaden gäller den demonstrationen. Det som går att ta med sig är att välja mellan tillgängliga åtgärder i varje steg; ett annat webbläsarflöde behöver en egen kontroll.

Tillståndets aktualitet spelar roll. Om det valda kontot eller sidan ändras medan en bedömning görs ska du kasta det inaktuella resultatet. Knyt åtgärderna till kontot och tillståndet som granskades.

Det kan också göra en katalog med typade gränssnitt användbar. En modell väljer en känd vy och dess avgränsade data; vanlig renderingskod skapar gränssnittet. Mät slutförda uppgifter och felaktiga åtgärder, särskilt om reglagen förblir begripliga.

Där skulle jag börja

Välj det upprepade beslut som redan skapar synligt merarbete. Bygg utvärderingsuppsättningen av dess verkliga fel.

Befintligt problem	Första försöket	Belägg att samla
Sökningen svarar på fel fråga	Bedöm ett kort urval sökträffar	Korrekta svar, avståenden, svarstid
Förfrågningar skickas mellan team	Välj bland tillåtna köer	Rätt dirigering på första försöket, överlämningar
Import kräver manuell mappning	Välj verkliga källfält	Mappningsfel, granskningstid
Varje uppgift använder största modellen	Dirigera lämpliga uppgifter	Kostnad per godkänt resultat
Genererade svar påstår för mycket	Kontrollera påståenden mot källor	Påståenden utan stöd som slinker igenom
Ingen använder transkriptionsarkivet	Returnera avsnitt med tidsstämplar	Granskarnas acceptans, tid till belägg
Användare hittar inte reglagen	Föreslå en tillgänglig åtgärd	Slutförandegrad, felaktiga val

Kopiera inte en demos gräns för konfidens. TypeSafes dokumentation om konfidens förklarar att konfidens för Choice och Score sammanfattar en fördelning. Den bevisar varken att indata var fullständiga eller att den valda åtgärden är tillåten.

Ta med fall där ingen kandidat passar. Ta med en otillgänglig tjänst. Ta med varje språk du vill stödja. Spara modellversion och frågedefinitioner med resultaten så att en senare förändring kan jämföras rättvist.

För en integrationsprodukt skulle jag börja med sökrelevans och fältmappning. Båda förkortar vägen till en fungerande synkronisering. Båda låter dig upptäcka felet innan det blir ett kundproblem.

Välj ett felaktigt svar som din programvara ger i dag. Se till att den tillförlitligt tar rätt nästa steg.