7 сценариев Jev, которые сокращают реальную работу в ПО

Кто-то спросил наш сайт, сколько у нас интеграций. В ответ он дал совет о том, сколько полей должно быть в форме регистрации.

Ответ пришёл быстро. Пользы от него не было.

В обоих вопросах было слово «сколько». Наш поисковый код назначал принятому совпадению с FAQ минимальную оценку 0,86, отчего слабое совпадение выглядело убедительным. Скорость скрыла ошибочное решение.

Именно о таких сбоях стоит думать, изучая Ship with Jev. На 26 сентября 2026 года каталог содержал 551 проект сообщества. Игры соседствуют с поисковыми компонентами, браузерными агентами, исследовательскими инструментами и экспериментами с маршрутизацией. Каталог приводит показатели производительности со слов авторов. Это инструмент для поиска проектов, а не независимый сравнительный тест.

Интереснее другой вопрос: какие из этих подходов сокращают работу в реальном продукте?

Командам, создающим интеграции и бизнес-приложения, я бы предложил сначала оценить эти семь сценариев. Порядок отражает редакционное суждение о пользе и проверяемости. Примеры рабочих процессов ниже являются предложениями по проектированию, если прямо не указана реализация со ссылкой.

Что Jev добавляет приложению

TypeSafe описывает Jev как модель для типизированных суждений. Передайте ей нужное состояние и вопрос, а в ответ получите выбор, вероятность или оценку, которую обработает код. В карте сценариев применения перечислены маршрутизация, поиск информации, проверка и извлечение данных.

У этого различия есть полезная предыстория в собранных нами материалах YouTube. В выступлении Diogo Almeida на AI Engineer сооснователь TypeSafe выступает за программное обеспечение, чьи составные элементы способны выражать больше интеллекта. Он противопоставляет эту цель добавлению ассистента к уже существующему ПО. Это его взгляд на развитие AI, а не оценка нынешней производительности Jev.

Представьте железнодорожную развилку. Полезный результат: по какому из доступных путей должен поехать поезд. Абзац с описанием путей ничего не добавляет к работе стрелки.

Возражение понятно: «Обычная LLM уже умеет возвращать JSON». Да. Основанием для выбора другого компонента должны быть измеренные качество, стоимость и задержка именно для этого решения. Один лишь типизированный ответ ничего из этого не доказывает.

Сначала стоит рассмотреть вызов со стороны CLM

23 сентября Jacky Kwok, Hangoo Kang, Tarun Suresh, Jon Saad-Falcon, Marco Pavone, Christopher Ré и Azalia Mirhoseini опубликовали работу Contrastive Language Models. Она ставит под сомнение предположение, что Jev является единственным практичным способом быстро принимать семантические решения.

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

Такое сравнение меняет набор необходимых проверок. Выбрать очередь поддержки, выбрать фрагмент поисковой выдачи и оценить длинную последовательность действий при программировании значит решить разные задачи. Хороший результат в одной не определяет результат в остальных.

CLM кодирует состояния и возможные действия отдельно, что позволяет кэшировать повторно используемые эмбеддинги действий. В репозитории описаны совместимый с TypeSafe интерфейс и стандартный предел состояния в 2 048 токенов. Более длинные состояния обрезаются, если не изменить настройки. Совместимость API не означает эквивалентности решений.

В опубликованной карточке модели указаны эмбеддинги Qwen3-8B и отмечено, что высокие результаты верификатора требуют дообученных выходных слоёв. Там также ясно сказано: CLM оценивает переданные кандидаты и не генерирует решение. Открытые веса дают ещё один вариант для оценки; оборудование, обслуживание модели и сопровождение всё равно стоят денег.

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

Семь рабочих процессов ниже по-прежнему заслуживают оценки. Их ценность не зависит от того, выигрывает ли Jev каждое сравнение.

1. Поиск, который проверяет, отвечает ли результат на вопрос

Это мой первый выбор: ошибку видно, а результат легко разметить. Ответил ли найденный фрагмент на вопрос посетителя?

Получите небольшой набор кандидатов с помощью ключевых слов, эмбеддингов или обоих подходов. Затем спросите Jev, содержит ли каждый фрагмент нужный факт. В руководстве TypeSafe по повторному ранжированию показана такая двухэтапная схема. Видно и ограничение: повторное ранжирование не может выбрать документ, пропущенный на этапе поиска.

1. Извлечение

   ключевые слова, эмбеддинги

   Небольшой набор кандидатов

   Не добавит то, что упустил
2. Jev

   типизированная оценка

   Содержит ли фрагмент

   нужный факт?
3. Ответ

   или отсутствие ответа

   Верный или без ответа

   Измеряется общая задержка

Для нашего примера с числом интеграций кратчайший путь ещё проще. Посчитайте записи в авторитетном каталоге. Объясните, что означает это число. Документированный коннектор и подключение, настроенное клиентом, представляют собой разные вещи.

Оставьте семантические суждения для вопросов, смысл которых требует интерпретации, например: «Можно ли переносить только клиентов, чьи данные изменились со вчерашнего дня?» Найдите соответствующую документацию по синхронизации и проверьте, описывает ли она инкрементальные обновления.

Реализация jevsearch от Kyle McLaren наглядно показывает последовательность: сначала появляются результаты по ключевым словам, затем ранжирование 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 и email-маркетинга сохраняйте исходное поле вместе с решением о сопоставлении. Показывайте предварительный просмотр затронутых записей. Не утверждайте сомнительные сопоставления до проверки.

Здесь есть экономическое преимущество: утверждённое сопоставление схем можно использовать повторно. Если смысл поля не изменился, вызов модели для каждой строки не нужен.

Измеряйте количество отклонённых записей и неверных сопоставлений на проверенной выборке. Успешный запрос API доказывает, что данные приняты, но не доказывает, что правильный email попал к правильному контакту.

4. Выбор наименьшей модели, способной выполнить задачу

Маршрутизация между моделями особенно полезна, когда приложение отправляет всё самой дорогой модели. Изменение подписи, оценка результата поиска и сложное исследование архитектуры предъявляют разные требования.

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

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

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

Что нужно задаче?

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

   Обычный код

2. Ограниченный смысловой вопрос

   Модель решений

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

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

4. Свидетельства требуют большего

   Эскалация

Сам маршрутизатор тоже требует времени и денег. Для очевидных повторяемых задач фиксированное правило может быть лучше. Для неоднозначных задач сравнивайте маршрутизацию с использованием одной модели по результатам завершённой работы.

Отслеживайте стоимость принятого результата, повторные попытки, частоту перехода к более мощной модели и ошибки, найденные позднее. Дешёвый первый вызов может превратиться в дорогой процесс, если кому-то придётся исправлять его результат.

5. Проверка утверждений до отправки ответов клиентам

Ссылка может существовать и при этом не подтверждать соседнее предложение. Источник может описывать планируемую функцию, а ответ утверждать, что она уже доступна.

В руководстве TypeSafe по проверке цитат разделены две проверки. Обычное сопоставление строк обнаруживает отсутствующую цитату. Семантическое суждение оценивает, подтверждает ли контекст источника утверждение.

Применяйте эту схему к ответу поддержки, сгенерированному руководству по интеграции или предлагаемому агентом отчёту о завершении. Сохраняйте утверждение, фрагмент источника и вердикт для проверки.

Завершение работы всё равно требует прямых доказательств. Тесты подтверждают проверенное поведение. Запись о развёртывании подтверждает развёртывание. Семантическое суждение может отметить несоответствие отчёта доказательствам, но не может создать недостающие доказательства.

Этот сценарий привлекателен тем, что его можно поставить перед существующим этапом публикации. Измеряйте пропущенные неподтверждённые утверждения, излишне заблокированные подтверждённые утверждения и объём работы по проверке. Начните с явных ошибок, которые ваша система уже совершает.

6. Отбор полезных фрагментов из расшифровок и отзывов клиентов

Архив расшифровок становится полезным, когда в нём можно найти нужный фрагмент. «Содержит слово интеграция» служит слабым фильтром для запроса «объясняет, почему клиент прекратил настройку».

Один из подходов: найти вероятные фрагменты, затем оценить несколько конкретных свойств. Описывает ли фрагмент препятствие при настройке, содержит ли конкретный пример, понятен ли без недостающего контекста?

Сохраняйте URL источника и временную отметку у каждого выбранного фрагмента. Временная отметка берётся из расшифровки. Модель оценивает релевантность.

Для видеоредактора эти признаки могут дать список клипов для просмотра. Для продуктовой команды они помогут сгруппировать повторяющиеся возражения. Для маркетолога они отделят свидетельства клиентов от неподтверждённых заявлений кампании.

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

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

Измеряйте долю материалов, одобренных проверяющим, и время, сэкономленное на поиске полезного материала. Оценка силы вступления не является прогнозом просмотров.

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

Экран настроек может получить запрос «Остановите эту синхронизацию до завтра». Браузерному агенту может понадобиться выбрать один из элементов управления на текущей странице.

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

В Ship with Jev есть демонстрация поиска авиабилетов в браузере от Gregor Zunic. Указанные время выполнения и стоимость относятся к этой демонстрации. Переносимая идея заключается в выборе из доступных действий на каждом шаге; другой браузерный процесс требует собственной проверки.

Актуальность состояния имеет значение. Если во время оценки изменились выбранный аккаунт или страница, отбросьте устаревший результат. Привязывайте действия к проверенным аккаунту и состоянию.

Это также может сделать полезным типизированный каталог интерфейсов. Модель выбирает известное представление и ограниченный набор данных, а обычный код отрисовывает интерфейс. Измеряйте успешное завершение задач и ошибочные действия, особенно следя за понятностью элементов управления.

С чего я бы начал

Выберите повторяющееся решение, которое уже приводит к заметным потерям. Составьте набор для оценки из его реальных ошибок.

Существующая проблема	Первый эксперимент	Какие данные собирать
Поиск отвечает не на тот вопрос	Оценить короткий список найденных фрагментов	Правильные ответы, отказы от ответа, задержка
Запросы переходят между командами	Выбрать из разрешённых очередей	Точность первого направления, передачи
Импорт требует ручного сопоставления	Выбрать реальные исходные поля	Ошибки сопоставления, время проверки
Каждая задача использует крупнейшую модель	Маршрутизировать подходящие задачи	Стоимость принятого результата
Сгенерированные ответы преувеличивают	Проверить утверждения по источникам	Пропущенные неподтверждённые утверждения
Архив расшифровок никто не использует	Возвращать фрагменты с временными отметками	Одобрение проверяющим, время поиска доказательств
Пользователи не находят элементы управления	Предложить доступное действие	Доля завершённых задач, неверный выбор

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

Добавьте примеры, где ни один кандидат не подходит. Добавьте недоступный сервис. Включите каждый язык, который собираетесь поддерживать. Храните версию модели и определения вопросов вместе с результатами, чтобы последующее изменение можно было честно сравнить.

Для продукта интеграции я бы начал с релевантности поиска и сопоставления полей. Оба сценария сокращают путь к работающей синхронизации. В обоих можно увидеть ошибку до того, как она станет проблемой клиента.

Выберите один неверный ответ, который ваше ПО даёт сегодня. Добейтесь, чтобы оно надёжно делало правильный следующий шаг.