Jev — это модель принятия решений от TypeSafe. Она принимает неструктурированные входные данные и возвращает типизированные оценки с вероятностями, а ваш код решает, что делать дальше. Это руководство демонстрирует, как использовать Jev для решения вашей собственной задачи, на сквозном примере модерации объявлений на торговой площадке на TypeScript.
Как работает Jev
Итак, вы понимаете, для чего предназначен Jev, и чувствуете, что находитесь на правильном пути. Теперь возникает вопрос: как выглядит запрос к Jev «под капотом»?
Давайте начнем сначала. Каждый запрос Jev состоит из состояния и набора вопросов. Состояние — это входные данные, которые Jev должен оценить. Это может быть строка, JSON-объект или массив строк. Если вы пытаетесь оценить последовательность элементов, например сообщения в беседе, массиву стоит отдать предпочтение. Вопросы — это список оценок, которые Jev должен выполнить над состоянием. Вопрос состоит из двух элементов, а именно: инструкций и критериев. Инструкции описывают оценку, которую необходимо выполнить. Критерии описывают возможные ответы. При оценке состояния Jev определит, насколько каждый из критериев соответствует состоянию, и вернет это в качестве результата. Когда состояние представляет собой JSON-объект, инструкции могут ссылаться на поименованное поле в состоянии, заключив его в обратные кавычки. Мы называем это путем к полю. Например, действительным путем к полю может быть listing.description. Когда эта инструкция предоставлена, Jev считает значение в поименованном поле и выполнит по нему оценку.
Типы вопросов — это выбор (choice), проверка на истинность/ложь (noul) и оценка (score). Вопрос с выбором выбирает один вариант из набора, заданного вами. Вопрос noul определяет, истинно ли утверждение. Вопрос со счетом помещает объект на упорядоченную шкалу уровней, определяемую вами.
Jev оценивает каждый из ваших вопросов индивидуально и параллельно для одного и того же состояния. Он выдает только один ответ на вопрос. Каждый ответ имеет тип: выбор, noul или оценка. Ответ с выбором состоит из: 1. Выигравшего варианта, 2. Вероятности каждого варианта, 3. Уверенности от 0 до 1, которую TypeSafe вычисляет на основе формы распределения вероятностей. Если вероятность сильно сконцентрирована на выигравшем варианте, уверенность будет высокой. Если она рассредоточена, она будет ниже, даже если у выигравшего варианта самая высокая вероятность индивидуально. Уверенность не является вероятностью выигравшего варианта. Это сводка по всему распределению. Ответ noul состоит из: 1. Единой вероятности того, что утверждение истинно, 2. Отсутствия уверенности, поскольку вероятность noul уже выражает уверенность модели. Ответ с оценкой состоит из: 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 перечисляет арифметику, точный подсчет и сравнение дат как элементы, которые должны оставаться в коде, а не превращаться в вопросы.
Применительно к торговой площадке этот критерий сортирует проверки следующим образом.
Проверки также определяют тип объявления, общий для всех этапов. Каждое поле представляет собой одно из трех: ввод для жестких правил, факт, вычисленный для 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) для представления степени. Она располагается вдоль упорядоченной шкалы. Результат представляет собой число, которое можно вычитать, сравнивать с другими числами и которое дает вам меру различий между ними.
Формат критериев различается в зависимости от типа вопроса. Вопросы с выбором получают объект, который сопоставляет имя каждого варианта с его описанием (максимум 255 вариантов). Булевы вопросы получают необязательный объект с описаниями истинного и ложного значений. Идеальный вопрос краток и прям, поэтому многим вопросам даже не нужен объект описания. Вопросы с оценкой получают упорядоченный массив описаний уровней (от 2 до 10 уровней), а ответ измеряется по индексу этого массива, начиная с нуля.
Торговая площадка использует все три. Запрещенный товар — это выбор из пяти названных категорий и варианта «нет», поскольку политика должна знать, какое правило было нарушено (оружие отличается от подделки, как и сообщения, которые они вызывают, и проверяющие, к которым они попадают). Соответствие категории, противоречие между заголовком и описанием, а также контакт вне платформы — это булевы вопросы, поскольку каждый из них представляет собой утверждение типа «да/нет», и единственное число, необходимое для политики — это вероятность. Описанное состояние — это оценка по пяти уровням, поскольку политика спрашивает, насколько сильно отличаются заявленное и описанное состояния, а расстояние можно измерить только по упорядоченной шкале.
Независимые вопросы относятся к одному запросу. Jev оценивает их параллельно на основе одного и того же состояния, поэтому пять вопросов требуют одного круга обращения, а объявление, которое задевает два из них (сумка-тоут позже в этой статье задевает), возвращается с двумя разными причинами. Широкий вопрос скрывает несколько оценок в одном ответе. Разбиение широких вопросов на узкие, атомарные делает их гораздо более удобными для проверки, настройки и объединения в коде.
Пишите критерии Jev, которые выдерживают буквальное прочтение
Инструкции говорят, что нужно решить, а критерии определяют ответы. Jev применяет и то, и другое буквально. Эта буквальность является частью того, что делает Jev предсказуемым, и означает, что критерии выполняют большую часть работы.
Несколько правил действуют при написании критериев для любой предметной области. Описывайте варианты, используя лексику, присутствующую в исходном тексте, поскольку критерий, называющий ситуацию («общий учетная запись с данными для входа, отправленными после оплаты»), соответствует тексту, в котором никогда не используется слово из вашей политики для этого. Для каждого булева вопроса описывайте обе стороны, чтобы пограничные случаи попадали на правильную сторону. Давайте каждому выбору явный вариант «нет» на случай, когда ничего не подходит, чтобы модель не была вынуждена выбирать что-то случайное.
Для оценки описывайте каждый уровень как конкретную ситуацию, поскольку уровни составляют шкалу. А идентификатор вопроса, такой как prohibited, — это ключ, по которому ваш код считывает ответ, поэтому не ждите, что модель интерпретирует его как инструкцию.
Клиент, шкала состояния и критерии запрещенных товаров приведены ниже. Булевы критерии занимают сам запрос. Ищите их в следующем разделе.
Вызов API Jev из TypeScript
Вы обращаетесь к Jev через Decisions API OpenRouter. Запрос состоит из трех компонентов: модели, состояния и вопросов. Ответ содержит ответы, сопоставленные с вашими идентификаторами вопросов, каждый из которых помечен своим типом, а также данные об использовании и стоимости.
Нужен ли специальный ключ 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, задается без критериев, и в этом суть — показать, что они опциональны. Идентификатор ответа не будет совпадать с вашим.
В этом ответе продавец указал товар как like_new (как новый) с оценкой Jev, равной 1 по шкале от 0 до 4. Ответы привязаны к идентификаторам вопросов и помечены по типу вместе с соответствующими вероятностями и уровнем уверенности. Модель в ответе указывает датированную сборку 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 — это минимальный порог с нулевым количеством ложных отклонений, и именно он идет в продакшен.
Во-вторых, преодолевают ли нижние пороги уверенности ваши чистые примеры. В последнем блоке выводятся наименее уверенный вариант «нет» и наименее уверенная оценка состояния среди листингов, помеченных для публикации. Установите каждый порог ниже этих значений, причем порог состояния, как ожидается, должен оказаться меньшим из двух.
В-третьих, о чем говорят расхождения в отношении вопросов. Единственным отклонением, которое Jev не пометил как запрещенное, был листинг MacBook с просьбой расплатиться через Zelle, и отдельный вопрос offsite_transaction поймал его — это пример того, как окупается принцип атомарных вопросов. Единственное удержание, с которым разметка не согласна, — это игрушка для страйкбола, и я оставляю это удержание. Реплика винтовки, получившая взгляд человека перед публикацией, стоит потраченных усилий.
Весь прогон — 24 листинга по пять вопросов в каждом — стоил около десятой части цента. Актуальные цены указаны на странице модели Jev.
Связываем все воедино
Точка входа короткая. Для каждого листинга она вызывает функцию moderate() и выводит действие, причины и сырые числа. Сохраняйте это логирование в продакшене, иначе проверяющий увидит голую метку HOLD и не будет иметь ни малейшего понятия, какой именно вопрос сработал.
Каждый результат — это принцип Jev в действии. Наушники публикуются с описанным состоянием, находящимся прямо на отметке «хорошо» от продавца, что демонстрирует передачу системой оценки числа, которое бизнес-логика может сравнить. Сумка отклоняется по двум независимым причинам из двух разных вопросов.
Автокресло никогда не говорит «отзыв» или «небезопасно» и все равно отклоняется, потому что в критерии указаны реальные ситуации: авария и отсутствие ремней. Peloton задерживается, потому что продавец заявил «как новое», описывая скрипящую педаль и битые пиксели, и этот разрыв между заявленным фактом и решением Jev делает видимым код.
Запустите его снова, и вероятности изменятся на сотую долю или две, в то время как действия останутся прежними. Это та форма, которая вам нужна: политика, устойчивая к шуму в данных.
Следующие шаги
Чтобы выйти за рамки маркетплейса, сохраняйте эту форму. Код выполняет детерминированную работу. Состояние минималистично и содержит только то, что требуется для вопросов, а вычисленные факты передаются в виде меток. Вопросы узкие и типизированные, задаются одновременно в одном запросе, причем каждый тип выбирается в зависимости от значения ответа, буквальных критериев и явного варианта отсутствия. Ответы являются свидетельствами. Проверяйте их форму, сопоставляйте с действиями с помощью чистой политики, пороговые значения которой получены из размеченных примеров, а неопределенность и сбои направляйте человеку.
Этот подход работает для маршрутизации тикетов, управления инструментами агентов и классификации контента. Jev не генерирует текст, поэтому такая задача, как «переписать название этого объявления», передается генеративной модели. О том, как связать Jev с LLM, рассказывается в статье Jev против 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 Jev и идентификатор модели?
Jev обслуживается через API решений OpenRouter по адресу POST https://openrouter.ai/api/alpha/decisions. Идентификатор модели — typesafe/jev-1.13, а псевдоним ~typesafe/jev-latest отслеживает самый свежий релиз. Тело запроса содержит модель, состояние и вопросы.
Нужна ли мне учетная запись TypeSafe для получения доступа к Jev?
Нет. Любой человек с ключом API OpenRouter может использовать Jev, с оплатой через учетную запись OpenRouter. Никаких листов ожидания и отдельной регистрации в TypeSafe не требуется.
Какой порог уверенности следует использовать с Jev?
Выберите его на основе ваших собственных размеченных данных и стоимости ошибочного действия, так как уверенность Jev измеряет степень концентрации распределения вероятностей и ничего не говорит о точности в вашем домене. Оцените размеченную выборку один раз, сохраните ответы и прогоните по ним кандидатные пороговые значения. В нашей выборке из 24 объявлений каждое реальное нарушение набрало 0.99 или выше, а значение 0.8 направило два пограничных случая на рассмотрение рецензенту.
