Независимое руководствоНезависимое руководство по Jev — модели TypeSafe AI
Практический путеводитель по Jev

Решения в реальных рабочих процессах

Для чего можно использовать Jev?

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

Независимое руководствоПоследняя проверка Обновлено

Главное

Начните с реального решения, проверьте источник и держите ограничения рядом с примером.

Сначала задача, затем технология

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

Vercel

Проверить команду перед выполнением

Vercel оценивала Jev как возможный инструмент проверки команд в автоматическом режиме fx. Суждение модели само по себе не даёт разрешения выполнить команду.

Эксперимент по сообщению автора · Здесь не воспроизводился

Изучить пример
Every

Проверить текст

Every проверяла статьи с помощью конкретных вопросов о тексте. Результаты помогают выбрать статьи и пункты для повторной проверки; пропущенные проблемы всё равно требуют внимания человека.

Эксперимент по сообщению автора · Здесь не воспроизводился

Изучить пример
Good Start Labs

Проверить ответ по заданным критериям

Good Start Labs рассказала об экспериментах с оценкой игровых задач и исследовательских ответов. Расхождение оценок — повод разобраться, а не доказательство правильности вердикта.

Эксперимент по сообщению автора · Здесь не воспроизводился

Изучить пример

Vercel · Guillermo Rauch

Посмотреть исходную публикацию автора

Vercel оценивала Jev как возможный инструмент проверки команд в автоматическом режиме fx. Суждение модели само по себе не даёт разрешения выполнить команду.

Загружает материалы X. Сервис может обрабатывать сведения о вашем устройстве. До вашего выбора медиа не загружаются.

Если публикация не загружается, откройте оригинал. Объяснение на этой странице остаётся доступным.

Открыть исходную публикацию

Попробуйте задачу

Начните с одного вопроса и редактируемого примера.

Предложить очередь и проверить решение

Классификация отзывов клиентов с Jev

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

Читать руководство
Одна конкретная проверка черновика

Проверка абсолютных обещаний в тексте продукта

Отмечайте абсолютные обещания вопросом да/нет, затем самостоятельно проверяйте формулировку и контекст.

Читать руководство
Найдите пропуски до отправки

Проверка полноты ответа с Jev

Попробуйте шаблон, который проверяет, отвечает ли черновик на все явно сформулированные части запроса.

Читать руководство
Соотнесите вопрос с нужным решением

Jev Choice или Noul: выбор типа вопроса

Когда выбирать одну категорию с Choice, а когда проверять условие да/нет с Noul.

Читать руководство
Явно опишите границы категорий

Пересекающиеся метки при классификации с Jev

Различайте конкурирующие маршруты и совместимые свойства, уточняйте границы категорий и сохраняйте ручную проверку.

Читать руководство
Сопоставьте число с его вопросом

Вероятность и confidence в Jev: в чём разница

Разберитесь в вероятности варианта и confidence для Choice, не смешивая их с измеренной точностью.

Читать руководство

Сначала определите решение, затем выбирайте модель

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

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

Примеры сообщества: как разработчики используют Jev

Эти публичные отчёты описывают конкретные задачи принятия решений, которые разработчики проверили на практике. Каждый обзор содержит ссылку на автора. Включение в подборку не означает, что TypeSafe или упомянутые команды одобряют этот сайт.

Vercel: проверка команд перед автоматическим выполнением

Эксперимент, опубликованный автором · Сайт не воспроизводил его

Guillermo Rauch рассказал об оценке Jev компанией Vercel для проверки безопасности в автоматическом режиме fx. На вход поступают команды; суждение помогает определить, подходит ли команда для автоматического выполнения. Публикация описывает возможную замену проверяющей модели, а не подтверждённое внедрение Jev. Полная политика проверки не раскрывается. Само по себе суждение модели не даёт разрешения на выполнение.

Прочитать исходный материал

Every: проверка текста с помощью конкретных вопросов

Эксперимент, опубликованный автором · Сайт не воспроизводил его

Mike Taylor из Every проверял тексты статей с помощью вопросов о характерных приёмах письма. Jev возвращал суждения по отдельным проверкам, помогая автору решить, какие статьи и пункты проверки нужно пересмотреть. Это эксперимент по рецензированию текста, а не признанный способ установить его авторство. Автор сообщил и о пропущенных проблемах; решение об исправлениях по-прежнему требует проверки текста человеком.

Прочитать исходный материал

Good Start Labs: проверка ответов по критериям оценки

Эксперимент, опубликованный автором · Сайт не воспроизводил его

Alex Duffy описал эксперименты в период раннего доступа: игровые задания и ответы на вопросы финансового исследования оценивались по заданным критериям. Входные данные включают ответ и критерии; суждения показывают, пройдены ли отдельные проверки. Команда использует расхождения для дальнейшего анализа. Этот отчёт не доказывает правильность суждения модели или внедрение продукта автономной оценки.

Прочитать исходный материал

Попробуйте проверку текста в официальном Playground

Наш оригинальный учебный пример с вымышленными данными; результатов запусков модели нет. Это отдельное упражнение по мотивам проверки текстов, а не промпт Every и не воспроизведение её эксперимента. Orbit Notes — вымышленный продукт. Для удобства копирования входной текст и вопросы оставлены одинаковыми на английском во всех языковых версиях.

Открыть официальный Playground

Это внешняя страница TypeSafe. Войдите в собственную учётную запись с необходимыми правами доступа. Запись в список ожидания сама по себе не даёт доступа.

  1. Вставьте пример ниже в поле state.

  2. Добавьте три вопроса Noul с приведёнными ниже именами и инструкциями. В официальном кратком руководстве объясняется, как задать state и вопросы.

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

Вымышленный входной текст

Открыть технические подробности
Orbit Notes saves your drafts locally.
Your drafts are stored on your device.
Click Export to download a copy.

Вопросы для ввода

Открыть технические подробности
repetition (Noul)
Does the text repeat a claim without adding new information?

clear_action (Noul)
Does the text explain what happens when the reader clicks Export?

guaranteed_safety (Noul)
Does the text claim that a draft can never be lost?

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

Четыре роли и четыре отправные точки

Разработчикам: проверьте смысловое правило

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

Сохраните компилятор, набор тестов и точные правила линтера. Пусть рецензент изучит отмеченные строки и решит, обосновано ли замечание. Начните с рекомендательных комментариев, чтобы оценить цену ложных тревог, прежде чем делать проверку обязательным условием слияния. Это предложение по интеграции, а не готовый PR-бот, предоставляемый этим сайтом.

Командам поддержки: разделите выбор ответственного и срочность

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

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

Командам поиска и RAG: выберите свидетельства до написания ответа

Генерация с дополнением результатами поиска (RAG) передаёт найденные материалы генератору текста. Jev можно оценить как промежуточный этап между поиском и генерацией. В примере TypeSafe для фрагментов RAG отдельно проверяются релевантность, пригодность свидетельств, противоречия и попытки передать инструкции, после чего код включает, помечает или исключает фрагмент.

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

Командам безопасности: расставьте приоритеты для аналитиков

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

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

Полный пример: поиск ответа в документе

1. Задача и входные данные

Поиск по тексту условий использования GitHub из примера: 218 строк с идентификаторами, модель jev-1.12. Разбор и полный скрипт содержат ссылку на полный входной текст и объясняют воспроизведение примера.

2. Вопросы

Один запрос задаёт where (Choice по идентификаторам строк) и exists (Noul: содержит ли документ ответ?).

3. Фрагмент опубликованного вывода

Здесь приведены отдельные значения, а не полный ответ API:

Открыть технические подробности
query: who owns the code I upload?
exists: 0.98
L052: 0.95

Найденная строка источника начинается так: L052 | You own Your Content.

4. Постобработка

В примере вероятности строк сортируются, а идентификаторы снова связываются с исходным текстом. По его правилам наличия ответа значения не ниже 0.7 означают, что ответ есть, ниже 0.35 — что его нет, а промежуток между ними — что ответ частичный. Поэтому этот пример указывает на L052 и проходит проверку наличия ответа.

5. Ограничения и источник

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

Зачем нужны два сигнала?

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

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

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

Полный пример: первичная обработка обращения в поддержку

Входные данные, вопросы и документированный вывод

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

Вопрос Определение в сокращении Опубликованный результат
department — Choice Выбрать отдел расчётов (billing), технический отдел (technical) или продажи (sales) technical; вероятности соответственно: 0.159, 0.84, 0.001; уверенность 0.596
frustration — Score Разместить тон на трёх уровнях от спокойного до очень сердитого Оценка 1.035 по шкале 0–2; уверенность 0.842
is_urgent — Noul Оценить срочность 0.999

Источник: запрос и ответ из краткого руководства.

Превратите результат в предложение

Ниже приведён наш поясняющий код. Его пороги — иллюстративные правила, а не проверенные настройки:

Открыть технические подробности
function proposeRoute(response) {
  const department = response.answers.department;
  const urgency = response.answers.is_urgent.noul;

  return {
    queue: department.confidence >= 0.7
      ? department.choice
      : "manual-triage",
    priority: urgency >= 0.9 ? "urgent" : "normal",
    suggestedTeam: department.choice,
  };
}

Для опубликованных значений эта функция предлагает срочную ручную обработку и рекомендует техническую поддержку. Лидирующий отдел не проходит выбранный нами порог уверенности. Этот пример фактически не назначает ни одного обращения.

Вероятность и уверенность — разные поля. TypeSafe выводит уверенность Choice и Score из распределения; у Noul нет отдельного поля уверенности. Документация об уверенности

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

Сообщение сообщества: исследование первичной обработки фишинговых писем

Участник Discord описал ранний эксперимент с Python SDK 17 сентября 2026 года в 14:24–14:27 UTC. Он рассчитывал помочь работе службы безопасности, а позднее подключить эксперимент к процессу SOAR. Участник сообщил об обнадёживающих начальных результатах и чувствительности к формулировкам и подробности критериев. Начало эксперимента, последующие наблюдения

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

Выберите один следующий шаг

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

Источники и дополнительные материалы

Руководство опирается на официальную документацию и сообщения сообщества по ссылкам. Авторы наблюдений сообщества указаны.

  1. Официальный пример построчного семантического поиска
  2. Официальный пример обращения в поддержку
  3. Карта сценариев TypeSafe
  4. Пример классификации фрагментов для RAG
  5. Пример проверок для LLM
  6. Результаты Choice и варианты ответа
  7. Уверенность и вероятность
  8. Эксперимент сообщества с фишингом: начало
  9. Эксперимент сообщества с фишингом: продолжение
  10. Эксперимент Vercel с безопасностью команд: Guillermo Rauch
  11. Эксперимент Every с проверкой текста: Mike Taylor
  12. Эксперимент Good Start Labs с критериями оценки: Alex Duffy
  13. Официальный Playground TypeSafe
Как мы проверяем источники