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

Как работает Jev

Итак, вы понимаете, для чего нужен Jev, и чувствуете, что движетесь в верном направлении. Теперь возникает вопрос: как запрос к Jev выглядит изнутри?

Давайте начнем с самого начала. Каждый запрос к Jev состоит из состояния и набора вопросов. Состояние — это входные данные, которые Jev должен оценить. Это может быть строка, JSON-объект или массив строк. Если вы пытаетесь оценить последовательность элементов, например, сообщения в переписке, то лучше всего подойдет массив. Вопросы — это список суждений, которые Jev должен выполнить относительно состояния. Вопрос состоит из двух элементов: инструкций и критериев. Инструкции описывают суждение, которое должно быть выполнено. Критерии описывают возможные ответы. При оценке состояния Jev определит, насколько хорошо каждый из критериев соответствует состоянию, и вернет это в качестве результата. Когда состояние является JSON-объектом, инструкции могут ссылаться на именованное поле в состоянии, заключив его в обратные кавычки. Мы называем это путем к полю. Например, допустимым путем к полю может быть listing.description. Когда предоставлена такая инструкция, Jev прочитает значение в указанном поле и выполнит суждение по нему.

Типы вопросов: choice (выбор), noul (да/нет) и score (оценка). Вопрос типа choice выбирает один вариант из набора, определенного вами. Вопрос типа noul решает, является ли утверждение истинным. Вопрос типа score помещает объект на упорядоченную шкалу уровней, которые вы определяете.

Jev оценивает каждый из ваших вопросов индивидуально и параллельно для одного и того же состояния. Он выдаст вам только один ответ на каждый вопрос. Каждый ответ имеет тип: choice, noul или score. Ответ типа choice состоит из: 1. Выбранного варианта, 2. Вероятности каждого варианта, 3. Уверенности от 0 до 1, которую TypeSafe вычисляет на основе формы распределения вероятностей. Если вероятность сильно сконцентрирована в выбранном варианте, уверенность будет высокой. Если она распределена, она будет ниже, даже если выбранный вариант имеет наибольшую вероятность индивидуально. Уверенность — это не вероятность выбранного варианта. Это сводка всего распределения. Ответ типа noul состоит из: 1. Единой вероятности того, что утверждение истинно, 2. Отсутствия уверенности, так как вероятность noul уже выражает, насколько модель уверена. Ответ типа score состоит из: 1. Средневзвешенного по вероятности номера уровня, 2. Вероятности каждого номера уровня, 3. Уверенности и 4. Легенды, сопоставляющей номера уровней с соответствующими описаниями.

Каждый ответ — это вариант или число, которые ваш код может сравнивать, ограничивать пороговыми значениями и комбинировать. Никакой текст не генерируется для последующего парсинга. Это причина предпочесть Jev чат-модели, которую просят ответить ДА или НЕТ. Вы получаете распределение ответов, которые вы определили, поэтому неопределенность — это число, на основе которого можно выстраивать логику.

Jev работает через OpenRouter Decisions API с использованием идентификатора модели typesafe/jev-1.13. Любое использование API оплачивается через ваш аккаунт OpenRouter. Запрос к Jev состоит исключительно из текста, при этом бюджет токенов расходуется как на состояние, так и на заданные вопросы. На странице модели Jev в настоящее время указаны бюджет и цены. Новые пользователи могут пройти руководство по Jev, чтобы получить свой первый ответ за несколько минут.

Торговая площадка в качестве примера

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

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

Как Jev вписывается в программу

Jev — это модель System One. Этот термин — название TypeSafe для модели, которая создает типизированные решения и откалиброванные вероятности. Руководство по созданию от TypeSafe описывает, как строить решения с такой моделью. Вставляйте Jev там, где требуется суждение в цепочке обычного программного рабочего процесса. Код управляет потоком управления, детерминированными правилами и побочными эффектами. Jev предоставляет типизированные, основанные на состоянии ответы на небольшой набор вопросов, подготовленных кодом. Код преобразует эти ответы в действия. Jev не принимает решение о следующем действии самостоятельно.

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

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

Этап 3 — это Jev, а остальные четыре — ваши. Это одинаково для всех интеграций Jev. Jev — это функция преобразования состояния в доказательства, а все остальное — обычное программное обеспечение.

Решите, что определяет Jev, а что определяет ваш код

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

TypeSafe jaggedness page for Jev 1.13 относит арифметику, точный подсчет и сравнение дат к элементам, которые должны оставаться в коде, а не входить в вопросы.

Применительно к торговой площадке, этот тест сортирует проверки следующим образом.

Проверки также определяют тип объявления, который разделяют все этапы. Каждое поле — это одно из трех: входные данные для жестких правил, факт, вычисленный для Jev, или текст, который читает Jev. Состояния упорядочены от худшего к лучшему, поэтому индекс заявленного состояния совпадает с уровнями оценки состояния в дальнейшем.

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

Жесткие правила представляют собой стандартный код и выполняются до любого вызова Jev.

Ценовые ограничения показывают разброс в рамках одной проверки. Ограничения реализуются в коде, но сумка, выставленная за 120 долларов в категории, где обычно продаются за 1800 долларов, указывает на проблемы с подделкой, и интерпретация этого сигнала является делом оценки. Код выполняет сравнение и отправляет готовую метку в Jev.

Структурируйте состояние, которое видит Jev

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

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

Передавайте вычисленные факты в виде готовых меток. Jev может напрямую использовать price_signal: 'far_below_typical', в то время как исходные значения price_usd: 120 и typical_price: 1800 заставляют его решать задачу деления.

Ниже приведено состояние для одного листинга на маркетплейсе.

Идентификатор продавца, метки времени и URL-адреса фотографий опущены, так как ни один из пяти вопросов их не использует. category_definition включено, так как вопрос о соответствии категории сравнивает листинг с ним, а price_signal — потому что его читает критерий подделки.

Выберите тип вопроса для каждого решения

Каждый вопрос Jev имеет тип, и тип должен вытекать из того, что означает ответ. Он фиксирует форму ответа, а форма определяет, что вы можете с ним делать дальше.

Используйте choice, когда должен победить один вариант из определенного вами набора, и вашему коду нужно знать, какой именно. Вы получаете победителя и вероятность для каждого варианта, поэтому можете видеть, сколько вероятности досталось претендентам, занявшим последующие места. Используйте noul, когда ответом является утверждение, которое является либо истинным, либо ложным, и вы получаете единственную вероятность для установки порогового значения.

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

Формат критериев варьируется в зависимости от типа вопроса. Вопросы choice получают объект, который сопоставляет имя каждого варианта с его описанием, с максимум 255 вариантами. Вопросы noul получают необязательный объект с описаниями истинности (true) и ложности (false). Идеальный вопрос лаконичен и прям, поэтому многим вопросам даже не нужен объект описания. Вопросы score получают упорядоченный массив описаний уровней (от 2 до 10 уровней), и ответ измеряется по индексу этого массива, начиная с нуля.

Маркетплейс использует все три. Запрещенный товар — это выбор из пяти названных категорий и варианта none, потому что политика должна знать, какое правило было нарушено (оружие отличается от подделки, как и сообщения, которые они вызывают, и проверяющие, к которым они попадают). Соответствие категории, противоречие в названии и описании, а также контакт вне платформы — это вопросы типа noul, так как каждый из них представляет собой утверждение да/нет, и единственное число, которое нужно политике — это вероятность. Описанное состояние — это оценка по пяти уровням, поскольку политика спрашивает, насколько далеко друг от друга находятся заявленное и описанное состояния, а расстояние может быть измерено только по упорядоченной шкале.

Независимые вопросы относятся к одному запросу. Jev оценивает их параллельно по отношению к одному и тому же состоянию, поэтому пять вопросов обходятся в один цикл связи туда и обратно, а листинг, который задействует два из них (сумка-тоут далее в этой статье задействует), возвращается с двумя разными причинами. Широкий вопрос скрывает несколько решений в одном ответе. Разбиение широких вопросов на узкие, атомарные делает их намного проще для проверки, настройки и объединения в коде.

Напишите критерии Jev, которые выдерживают буквальное прочтение

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

При написании критериев для любой предметной области действует несколько правил. Описывайте варианты, используя лексику, присутствующую во входном тексте, потому что критерий, называющий ситуацию («общая учетная запись с данными для входа, отправленными после оплаты»), соответствует тексту, в котором никогда не используется слово вашей политики для этого. Для каждого noul описывайте обе стороны так, чтобы близкие промахи попадали на правильную сторону. Давайте каждому выбору явный вариант none на случай, если ничто не подходит, чтобы модель не была вынуждена выбирать что-то произвольное.

Для score описывайте каждый уровень как конкретную ситуацию, потому что уровни составляют шкалу. А ID вопроса, такой как prohibited, — это ключ, по которому ваш код считывает ответ обратно, поэтому не ожидайте, что модель истолкует его как инструкцию.

Клиент, шкала состояния и критерии запрещенных товаров приведены ниже. Критерии noul занимают сам запрос. Ищите их в следующем разделе.

Вызов API Jev из TypeScript

Вы обращаетесь к Jev через OpenRouter Decisions API. Запрос состоит из трех компонентов: model, state и questions. Ответ содержит ответы, соотнесенные с вашими ID вопросов, каждый с указанием его типа, а также данные об использовании и стоимость.

Нужен ли специальный API-ключ? Нужно ли связывать его с аккаунтом TypeSafe? Нет! Подойдет любой действующий API-ключ OpenRouter. Для использования Decisions API аккаунт TypeSafe не требуется. Есть всего два шага настройки: установите SDK с помощью bun add --exact @openrouter/sdk@1.3.17, а затем установите переменную окружения OPENROUTER_API_KEY в качестве вашего ключа. Полная схема для Decisions API находится на справочной странице.

Эта функция отправляет состояние маркетплейса и все пять вопросов, а затем разбирает ответ в понятную для политики структуру Judgment.

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

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

Блок операторов throw — это этап валидации. Определения типов в SDK оставляют уверенность и вероятности необязательными, что означает, что ответ может прийти без них. Предоставление значения по умолчанию замаскировало бы сломанный ответ за правдоподобным решением. Поэтому функция отказывается от выполнения, а оркестратор превращает этот отказ в задержку (hold) — туда же, куда попадает сбой сети или ошибка API.

Тот же запрос по обычному HTTP

В этом примере мы рассмотрим вызов SDK (который, по сути, является оберткой для POST https://openrouter.ai/api/alpha/decisions). Пример также включает два кратких вопроса и ответы на них. Первый вопрос, noul, задан без критериев, и в этом вся суть — показать, что они необязательны. ID ответа не будет совпадать с вашим.

В этом ответе продавец указал состояние товара как like_new (как новый) с оценкой Jev 1 по шкале от 0 до 4. Ответы привязаны к ID вопросов и помечены по типу, наряду с соответствующими вероятностями и уровнем уверенности. Модель в ответе указывает версию сборки typesafe/jev-1.13, которая его сгенерировала.

Превращение вероятностей в публикацию, удержание или отклонение

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

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

Функция decide() является чистой. Она принимает объявление и сохраненное решение, возвращает действие с причинами и не делает никаких сетевых вызовов. Эта чистота делает последующую настройку дешевой, поскольку вы можете повторно прогнать ее через ответы, за которые уже заплатили. Каждая причина указывает на вопрос и число, которое ее вызвало, поэтому проверяющий видит то же, что видела система.

Проверки на отклонение выполняются первыми и завершаются досрочно. Проверки на удержание являются кумулятивными, поэтому сомнительное объявление попадает в очередь со всеми прикрепленными к нему причинами.

Проверки на запрещенные товары основаны исключительно на уверенности, а не на вероятности выигрышного ответа. Это связано с тем, что выигрышный ответ не обязательно является уверенным. Конкретные проверки таковы: если ни один вариант не побеждает, а оставшаяся вероятность распределена между несколькими запрещенными опциями, то это большинство для ответа «fine» (нормально). Это не должно приводить к публикации. Причина, по которой нижний порог состояния ниже, чем порог для запрещенных товаров, заключается в том, что оценка, попадающая между двумя уровнями, может распределять вероятность на соседние уровни, даже если описание четкое. Разрыв состояния рассчитывается путем вычитания оценки Jev из индекса заявленного уровня. Именно поэтому этот механизм реализован в коде и срабатывает только в одном направлении. Например, если продавец заявляет like_new, но описывает товар как fair (удовлетворительно), фиксируется удержание. Однако, если продавец занизил оценку хорошего товара, удержание не фиксируется, так как защищается покупатель.

Функция moderate() управляет потоком, выполняя жесткие правила, затем суждение, а затем политику. Объявление без фотографий никогда не доходит до Jev, а обработчик превращает любое неудачное суждение в удержание с указанием ошибки в качестве причины.

У этой структуры есть два свойства. Во-первых, любой сбой на пути модели достаточен для того, чтобы поместить объявление в очередь на удержание и предотвратить его публикацию. Во-вторых, политика является чистой функцией сохраненных ответов, поэтому изменение порога просто переигрывает суждения, за которые вы уже заплатили, без новых вызовов Jev.

Каждое число в THRESHOLDS — это отправная точка. Если очередь на удержание заполняется безвредными объявлениями, повысьте порог, который их туда отправил. Если нарушения проскакивают, понизьте его.

Установка порогов уверенности на основе размеченной выборки

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

Процесс настройки одинаков для любой интеграции Jev. Возьмите примеры, которые человек уже оценил, оцените каждый из них один раз, сохраните ответы и прогоните через них кандидатов в пороги. Для торговой площадки я разметил 24 объявления как «публикация», «удержание» или «отклонение», смешав чистые объявления, явные нарушения и пограничные случаи, которые возникают в реальной очереди (поварской нож, классифицированный как мебель, мелатониновые жевательные конфеты, игрушка для страйкбола).

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

Вот результат работы Jev 1.13 от 22 сентября 2026 года.

Три вещи, которые можно извлечь из такого прогона в любой области.

Во-первых, где находятся явные нарушения относительно пограничных случаев. Здесь каждое реальное нарушение имело оценку около 1.0, а два пограничных объявления (мелатониновые конфеты и игрушка для страйкбола) находились значительно ниже, поэтому любой порог в промежутке между ними работает на этой выборке. Выберите тот, у которого есть запас с обеих сторон, потому что индивидуальные вероятности меняются между прогонами, и порог, находящийся прямо на пограничном случае, будет колебаться. На этой выборке 0.8 — это самый низкий порог с нулевым количеством ошибочных отклонений, и именно он идет в продакшн.

Во-вторых, перекрывают ли пороги уверенности ваши чистые примеры. Последний блок выводит наименее уверенный ответ «none» и наименее уверенную оценку состояния среди объявлений, помеченных как «публикация». Установите каждый порог ниже этих значений, ожидая, что порог состояния будет ниже из двух.

В-третьих, что разногласия говорят о вопросах. Единственное отклонение, которое Jev не пометил как запрещенное, было объявлением о MacBook с просьбой оплаты через Zelle, и отдельный вопрос offsite_transaction поймал его — это принцип атомарных вопросов в действии. Единственное удержание, с которым метки не согласны, — это игрушка для страйкбола, и я оставлю это удержание. Взгляд человека на реплику винтовки перед ее публикацией — это затраты, которые стоит понести.

Весь прогон, 24 объявления по пять вопросов в каждом, стоил около одной десятой цента. Текущие цены указаны на странице модели Jev.

Сборка всего воедино

Точка входа короткая. Для каждого объявления она вызывает moderate() и выводит действие, причины и «сырые» числа. Сохраняйте это логирование в продакшене, иначе проверяющий увидит простое HOLD и не будет иметь представления, какой вопрос сработал.

Каждый результат — это принцип Jev в действии. Наушники публикуются с описанным состоянием, которое находится прямо на уровне «хорошо» продавца, что является типом оценки, предоставляющим политике число для сравнения. Сумка отклоняется по двум независимым причинам из двух разных вопросов.

Автокресло никогда не помечается как «отозванное» или «небезопасное», но все равно отклоняется, поскольку критерий называет реальные ситуации: аварию и отсутствие ремней. Peloton задерживается, потому что продавец заявил «как новый», описывая скрипучую педаль и битые пиксели, и этот разрыв между заявленным фактом и решением Jev — это то, что делает видимым код.

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

Следующие шаги

Чтобы выйти за рамки маркетплейса, сохраните эту форму. Код выполняет детерминированную работу. Состояние минимально, содержит только то, что нужно для вопросов, а вычисленные факты передаются в виде меток. Вопросы узкие и типизированные, задаются вместе в одном запросе, причем каждый тип выбирается в зависимости от того, что означает ответ: буквальные критерии или явное отсутствие. Ответы — это доказательства. Проверяйте их форму, сопоставляйте их с действиями с помощью чистой политики, пороговые значения которой берутся из размеченных примеров, и направляйте неопределенность и сбои человеку.

Этот подход работает для маршрутизации тикетов, управления инструментами агентов и классификации контента. Jev не генерирует текст, поэтому задача вроде «перепиши этот заголовок объявления» передается генеративной модели. О том, как сочетать Jev с LLM, рассказывается в статье Jev vs LLM.

Чтобы создать это, сначала создайте ключ API OpenRouter. Затем добавьте код в свой проект (первая строка в каждом блоке кода называет файл) и протестируйте его на объявлениях из вашей собственной очереди с помощью bun run run.ts.

Центр документации Jev предоставляет доступ, информацию о ценах, SDK и демо-версии.
Справочник API решений содержит схему запросов и ответов.
Руководство по управлению вызовами инструментов применяет ту же форму одобрения, блокировки и проверки к действиям агентов.
Руководство по классификации применяет Jev к большому бэклогу в рамках ограничений по скорости.
«Что такое Jev?» объясняет модель, три типа вопросов и то, как читать вероятности.
«Настолько ли Jev точен в классификации, как передовые модели?» сравнивает Jev с Claude Opus 5 на бенчмарке из 77 намерений, включая каскад уверенности.

Часто задаваемые вопросы

Как использовать Jev с OpenRouter?

Создайте ключ API OpenRouter, установите @openrouter/sdk и вызовите openrouter.alpha.decisions.create() с моделью typesafe/jev-1.13, объектом состояния и одним или несколькими типизированными вопросами (choice, noul или score). Jev возвращает типизированный ответ с вероятностями для каждого вопроса, а ваш код превращает эти числа в действия. Тот же запрос работает через обычный HTTP по адресу POST https://openrouter.ai/api/alpha/decisions.

Какой эндпоинт API и ID модели у Jev?

Jev обслуживается через API решений OpenRouter по адресу POST https://openrouter.ai/api/alpha/decisions. ID модели — typesafe/jev-1.13, а псевдоним ~typesafe/jev-latest отслеживает самый новый релиз. Тело запроса содержит модель, состояние и вопросы.

Нужна ли мне учетная запись TypeSafe для доступа к Jev?

Нет. Любой, у кого есть ключ API OpenRouter, может использовать Jev, оплата производится через ваш аккаунт OpenRouter. Очереди ожидания нет, и вам не нужна отдельная регистрация в TypeSafe.

Какой порог уверенности мне следует использовать с Jev?

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