7 приложения на Jev, които спестяват реална работа в софтуера

Някой попита нашия уебсайт колко интеграции имаме. Той отговори със съвет колко полета трябва да има във формуляр за регистрация.

Отговорът дойде бързо. Беше безполезен.

И в двата въпроса присъстваше „колко“. Нашият код за търсене задаваше минимална оценка 0,86 на прието съвпадение с често задаван въпрос и така слаб резултат изглеждаше убедителен. Скоростта скри грешното решение.

За такъв провал си струва да помислите, когато разглеждате Ship with Jev. На 26 септември 2026 г. каталогът съдържаше 551 проекта на общността. До игрите стоят компоненти за търсене, браузърни агенти, инструменти за изследване и експерименти с насочване. Каталогът приписва данните за производителността на авторите им; той е инструмент за откриване, а не независим сравнителен тест.

Интересният въпрос е кои от тези подходи премахват работа от реален продукт.

За екипите, които изграждат интеграции и бизнес софтуер, първо бих оценил следните седем. Редът е редакторска преценка за полезността и възможността за тестване. Примерите за работни процеси по-долу са предложени проекти, освен когато е посочена конкретна реализация.

Какво добавя Jev към едно приложение

TypeSafe описва Jev като модел за типизирани преценки. Подавате му релевантно състояние и въпрос; получавате избор, вероятност или оценка, които кодът може да използва. Неговата карта на приложенията включва насочване, извличане, проверка и извличане на стойности.

Това разграничение има полезен предшественик в обработените от нас материали от YouTube. В лекцията на Диого Алмейда на AI Engineer съоснователят на TypeSafe защитава идеята за софтуер, чиито градивни елементи могат да изразяват повече интелигентност. Той противопоставя тази амбиция на добавянето на асистент към съществуващ софтуер. Това е неговият аргумент за посоката на AI, а не сравнителен тест на настоящата производителност на Jev.

Представете си железопътна стрелка. Полезният резултат е изборът на наличния коловоз, по който влакът трябва да поеме. Абзац с описание на коловозите не добавя нищо към превключването.

Възражението е основателно: „Един обикновен LLM вече може да връща JSON.“ Да. Аргументът за друг компонент зависи от измереното качество, разходи и забавяне при това решение. Сам по себе си типизираният отговор не доказва нито едно от тях.

Предизвикателството на CLM заслужава да бъде разгледано първо

На 23 септември Джак Куок, Хангу Канг, Тарун Суреш, Джон Саад-Фалкън, Марко Павоне, Кристофър Ре и Азалия Мирхосейни публикуваха Contrastive Language Models. Работата им оспорва предположението, че Jev е единственият практичен път към бързи семантични решения.

Авторите съобщават за сравними с Jev резултати без предварително обучение за конкретната задача при управление на компютър, игри и извикване на инструменти, с до 9 пъти по-ниско забавяне. Отделно съобщават 81,6% върху 38 отделени задачи от DeepSWE и 87,6% върху 30 задачи от Terminal-Bench 2.1. Тези резултати за програмиране използват допълнително обучени проверяващи модели CLM, които избират измежду решения, генерирани от други модели. Те съобщават също, че в тази конфигурация за проверка Jev остава под тяхната базова линия на случаен избор. Забавянето е измерено на H100. Това са резултати на авторите, които не сме възпроизвели независимо. Оригинална оценка и методология.

Това сравнение променя какво трябва да тестваме. Изборът на опашка за поддръжка, изборът на откъс от търсене и оценката на дълга последователност от стъпки при програмиране са различни задачи. Добър резултат в една от тях не решава останалите.

CLM кодира състоянията и възможните действия отделно, което позволява векторните представяния на действията да се кешират и използват повторно. Неговото хранилище документира съвместим с TypeSafe интерфейс и стандартно ограничение от 2048 токена за състоянието, като по-дългите състояния се съкращават, ако няма друга настройка. Съвместимостта на границата на API не доказва равностойни решения.

Публикуваната карта на модела посочва векторни представяния Qwen3-8B и предупреждава, че силните резултати на проверяващия модел изискват допълнително обучени изходни слоеве. Тя уточнява и че CLM оценява подадени кандидати и не генерира решение. Отворените тегла дават възможност за оценка; хардуерът, обслужването и поддръжката все пак имат цена.

За Tajo полезните изводи са конкретни: сравнявайте моделите за решения върху едни и същи случаи, записвайте отделно забавянето при първо и последващо извикване и тествайте правдоподобни, но грешни кандидати. Закрепете версиите на модела и на всеки енкодер или проекционен слой. Отхвърляйте неподдържани конфигурации на доставчик, вместо мълчаливо да избирате друг. Проверявайте отново калибрирането при промяна на модела или набора от кандидати.

Седемте работни процеса по-долу остават полезни кандидати за оценка. Стойността им не зависи от това Jev да печели всяко сравнение.

1. Търсене, което проверява дали резултатът отговаря на въпроса

Това е първият ми избор, защото провалът е видим, а резултатът лесно се обозначава. Отговори ли върнатият откъс на въпроса на посетителя?

Извлечете малък набор от кандидати чрез търсене по ключови думи, векторни представяния или и двете. После попитайте Jev дали всеки откъс съдържа искания факт. Ръководството на TypeSafe за преподреждане показва тази двуетапна структура. То показва и ограничението: моделът за преподреждане не може да избере документ, който извличането е пропуснало.

1. Извличане

   ключови думи, вектори

   Малък набор от кандидати

   Не може да добави пропуснатото
2. Jev

   типизирана преценка

   Съдържа ли този откъс

   търсения факт?
3. Отговор

   или без отговор

   Верен или без отговор

   Измерва се общото забавяне

За нашия пример с броя интеграции най-краткият път е още по-прост. Пребройте записите в достоверния каталог. Уточнете какво означава броят. Документиран конектор и връзка, настроена от клиент, са различни неща.

Запазете семантичната преценка за въпроси, чието значение трябва да се тълкува, например „Може ли това да прехвърля само клиенти, променени от вчера насам?“ Извлечете съответната документация за синхронизация, след което проверете дали тя разглежда постепенните актуализации.

Реализацията jevsearch на Кайл Макларън прави последователността конкретна: първо пристигат резултатите по ключови думи, последвани от класиране с Jev. Публикуваният ѝ тест използва собствен корпус от документация и въпроси с означени правилни отговори. Това е полезно доказателство за този тест, а не обещание за друг уебсайт или език.

Измервайте правилните отговори, неподкрепените отговори, въпросите без отговор и общото забавяне. Включете правописни грешки и преведени заявки. По-бързите неуместни резултати остават неуместни.

2. Насочване на заявки към правилната страница, опашка или агент

Потребител пише: „Контактите спряха да пристигат, след като смених акаунта.“ Приложението Ви трябва да различи проблем с връзката от въпрос за фактуриране, съпоставяне на полета и искане за създаване на нова синхронизация.

Подайте текущия екран, скорошния разговор и направленията, достъпни за този потребител. Поискайте най-подходящото направление, с изрична възможност „няма съвпадение“. Оставете идентификаторите на направленията под контрола на приложението.

Няколко преценки могат да бъдат полезни заедно: намерение, направление, спешност и дали съобщението съдържа изпълнимо искане. Подходът fan-out на TypeSafe позволява независими въпроси да споделят една заявка. След това кодът използва нужните отговори.

Безобидното предложение за навигация и разрешението за изпълнение на работа остават отделни решения. Намирането на правилната страница за фактуриране не разрешава възстановяване на сума. Намирането на правилния агент не му предоставя идентификационни данни.

Практическата полза е по-малко прехвърляния между екипи и по-малко цикли на уточняване. Измервайте колко често потребителят стига до правилното направление от първия опит. Поддържайте набор за повторно изпълнение с последващи съобщения като „да“, „нова задача“ и „готови ли са?“. Те имат смисъл само в контекст.

3. Съпоставяне на нееднородни данни в надеждна интеграция

Ето предложен работен процес за интеграция. Експорт от източник съдържа customer_email, billing_email и account_owner_email. Системата получател очаква имейл адреса на контакта.

Сходството между низовете оставя истинска двусмисленост. Описанията на полетата, примерните стойности и бизнес целта помагат за разрешаването ѝ. Jev може да избере измежду действителните полета на източника, докато кодът проверява типовете, задължителните стойности и ограниченията на получателя.

Свързаното ръководство за извличане на предварително разпознати стойности използва особено полезен подход: кодът намира възможните стойности, моделът избира кандидат, а кодът копира оригиналната стойност. Така не се генерира заместващ адрес или сума.

1. Код

   намира кандидати

   customer_email

   billing_email

   account_owner_email
2. Jev

   избира едно

   Описания на полетата

   Примерни стойности, цел
3. Код

   копира оригиналната стойност

   Типове, задължителни стойности

   Ограничения на получателя

При интеграция на CRM и имейл маркетинг запазвайте заедно изходното поле и решението за съпоставяне. Показвайте предварителен преглед на засегнатите записи. Оставяйте несигурните съпоставяния неразрешени до преглед.

Тук има икономическо предимство: одобрено съпоставяне на схеми може да се използва повторно. Не е нужно извикване на модел за всеки ред, когато значението на полето не се е променило.

Измервайте отхвърлените записи и грешните съпоставяния спрямо прегледана извадка. Успешната API заявка доказва, че данните са приети; тя не доказва, че правилният имейл е стигнал до правилния контакт.

4. Избор на най-малкия модел, който изпълнява задачата

Насочването към модел е привлекателно, когато приложението изпраща всичко към най-скъпия си модел. Промяната на етикет, преценката за резултат от търсене и сложно архитектурно проучване имат различни изисквания.

Първо определете моделите, които са конфигурирани и на които е разрешено да получат данните на задачата. Запишете поддържаните им инструменти и наблюдаваната им производителност. После тясно формулирана преценка може да препоръча подходящ вариант от този набор. TypeSafe включва този подход в своите примери за насочване към модел.

Jev Router на OpenRouter предоставя този подход през своя chat API с идентификатор на модел typesafe/jev-router. Описанието посочва избор както на модел, така и на усилие за разсъждение при промяна на разговора. Преди да го приемете, оценете разрешените модели надолу по веригата, действителните такси, обработването на данни и поведението при извикване на инструменти. Проверихме описанието; не сме тествали този маршрутизатор сравнително.

Предложената от нас политика започва с обикновен код за точни правила и факти. Използвайте модел за решения при ограничени семантични въпроси, подходящ генеративен модел за писане или реализация и ескалация, когато доказателствата я оправдават.

От какво има нужда задачата?

1. Точни правила и факти

   Обикновен код

2. Ограничен семантичен въпрос

   Модел за решения

3. Писане или реализация

   Подходящ генеративен модел

4. Доказателствата налагат повече

   Ескалиране

Самият маршрутизатор струва време и пари. За очевидни повтарящи се задачи фиксирано правило може да е по-добро. За двусмислени задачи сравнявайте насочването с базова линия с фиксиран модел върху завършена работа.

Следете разхода за приет резултат, повторните опити, дела на ескалациите и грешките, открити по-късно. По-евтино първо извикване може да се превърне в скъп процес, ако някой трябва да поправя резултата му.

5. Проверка на твърденията, преди да станат отговори за клиенти

Цитат може да съществува и въпреки това да не подкрепя изречението до него. Източник може да описва планирана функция, докато отговорът твърди, че тя е налична днес.

Ръководството на TypeSafe за проверка на цитати разделя две проверки. Обикновено сравнение на низове открива липсващ цитат. Семантична преценка оценява дали околният текст от източника подкрепя твърдението.

Приложете същия подход към отговор от поддръжката, генерирано ръководство за интеграция или предложен от агент отчет за изпълнение. Запазете твърдението, откъса от източника и заключението за преглед.

За завършването все пак са нужни преки доказателства. Тестовете установяват тествано поведение. Запис за внедряване установява внедряване. Семантичната преценка може да отбележи несъответствие между отчета и доказателствата му; тя не може да създаде липсващите доказателства.

Този случай на употреба е привлекателен, защото може да се включи преди съществуваща стъпка за публикуване. Измервайте неподкрепените твърдения, които преминават, подкрепените твърдения, които се блокират ненужно, и създадената работа по преглед. Започнете с изричните грешки, за които вече знаете, че системата Ви допуска.

6. Превръщане на транскрипции и клиентска обратна връзка в полезни кратки списъци

Архив от транскрипции става полезен, когато някой може да намери важния откъс. „Съдържа думата интеграция“ е слаб филтър за „обяснява защо клиент се е отказал по време на настройката“.

Един подход е да извлечете вероятните откъси, след което да оцените няколко конкретни свойства: описва ли това пречка при настройката, съдържа ли конкретен пример и разбираемо ли е без липсващ контекст?

Прикачете URL адреса на източника и времевата отметка към всеки избран откъс. Времевата отметка идва от транскрипцията. Моделът оценява релевантността.

За видео редактор тези сигнали могат да създадат кратък списък с клипове за преглед. За продуктов екип могат да подредят повтарящи се възражения. За маркетолог могат да отделят клиентските доказателства от неподкрепените твърдения в кампании.

Подходът на TypeSafe за съставна оценка държи измеренията отделно, за да може кодът да променя тежестите им. Клип, подходящ за урок, може да се различава от клип, подходящ за кратка продуктова демонстрация. Използвайте преценките повторно, когато основните доказателства и критерии остават непроменени.

JevQL предлага свързана реализация от общността: семантични условия върху редове в PostgreSQL, оценявани извън базата данни. Документацията му показва защо обичайните филтри имат значение за сметката. Намалете броя на допустимите редове, преди да поискате семантични преценки.

Измервайте одобрението от преглеждащите и спестеното време за намиране на използваем материал. Оценка за силата на началния момент не е прогноза за броя гледания.

7. Интерфейси, които избират следващото полезно действие

На екран с настройки може да пристигне „Спрете тази синхронизация до утре“. Браузърен агент може да трябва да избере измежду елементите за управление, видими на текущата страница.

В предложения от нас дизайн на интерфейса приложението подава разрешените действия и текущото състояние. Jev избира между тях. Интерфейсът показва съответния елемент за управление или предложение, което може да се прегледа.

Ship with Jev включва демонстрация на Грегор Зунич за търсене на полети с браузър. Посочените време на изпълнение и разходи се отнасят за тази демонстрация. Преносимата идея е изборът измежду действията, налични на всяка стъпка; друг браузърен процес изисква собствена проверка.

Актуалността на състоянието е важна. Ако избраният акаунт или страница се промени, докато преценката се изпълнява, отхвърлете остарелия резултат. Обвържете действията с акаунта и състоянието, които са били прегледани.

Това може да направи полезен и типизиран каталог от интерфейси. Модел избира познат изглед и ограничените му данни; обичайният код за визуализация изгражда интерфейса. Измервайте успешното завършване на задачите и грешните действия, като обръщате особено внимание дали елементите за управление остават разбираеми.

Откъде бих започнал

Изберете повтарящото се решение, което вече създава видима загуба. Използвайте действителните му провали, за да изградите набор за оценка.

Съществуващ проблем	Първи експеримент	Доказателства, които си струва да съберете
Търсенето отговаря на грешен въпрос	Оценете извлечен кратък списък	Правилни отговори, въздържане от отговор, забавяне
Заявките се прехвърлят между екипи	Изберете от разрешени опашки	Точност на първото насочване, прехвърляния
Импортите изискват ръчно съпоставяне	Изберете действителни полета на източника	Грешки при съпоставяне, време за преглед
Всяка задача използва най-големия модел	Насочете допустимите задачи	Разход за приет резултат
Генерираните отговори преувеличават	Проверете твърденията спрямо източници	Неподкрепени твърдения, които преминават
Никой не използва архива с транскрипции	Върнете откъси с времеви отметки	Одобрение от преглеждащите, време за намиране на доказателства
Потребителите не намират елементите за управление	Предложете налично действие	Дял на завършени задачи, грешни избори

Не копирайте прага на увереност от демонстрация. Документацията на TypeSafe за увереността обяснява, че увереността при Choice и Score обобщава разпределение. Тя не доказва, че входните данни са пълни или че избраното действие е разрешено.

Включете случаи, в които никой кандидат не е подходящ. Включете недостъпна услуга. Включете всеки език, който възнамерявате да поддържате. Запазвайте версията на модела и определенията на въпросите заедно с резултатите, за да може по-късна промяна да се сравни справедливо.

За продукт за интеграции бих започнал с релевантността на търсенето и съпоставянето на полета. И двете съкращават пътя до работеща синхронизация. И двете Ви позволяват да видите грешката, преди да се превърне в проблем за клиента.

Изберете един грешен отговор, който софтуерът Ви дава днес. Накарайте го надеждно да предприема правилната следваща стъпка.