Jev от TypeSafe: ответ модели — число, а порог — ваша политика безопасности

Коротко для руководителя SOC

• Подходит там, где человек читает текст и отвечает на простой вопрос. Фишинг ли это письмо, пересланное сотрудником? Просит ли звонящий в поддержку сбросить второй фактор? Указал ли аналитик, почему закрыл алерт?
• Не подходит там, где ответ надо посчитать. Сколько было неудачных входов за пять минут, обращается ли хост к одному адресу каждые шестьдесят секунд, совпадает ли хэш файла с известным. Считать и сравнивать числа и время модель не умеет, это признаёт сам разработчик. Такие вопросы решают правила корреляции в SIEM и ваш код.
• Ошибки бывают дешёвые и дорогие, и автоматику надо строить по этому признаку. Дешёвая ошибка — модель зря отправила письмо в карантин или аналитику: человек потратит минуту. Дорогая — модель назвала атаку ложным срабатыванием, алерт закрылся, и никто его не увидел. Действия, где модель может ошибиться только в сторону осторожности, можно автоматизировать с мягким порогом. Автоматическое закрытие алертов — только с порогом, который вы проверили на пропущенных инцидентах.
• Для такой проверки нужно больше данных, чем кажется. Считаются не алерты в выборке, а настоящие инциденты среди них. Чтобы утверждать «пропускаем не больше 5% инцидентов», их нужно около шестидесяти, и ни один не должен быть пропущен.
• Деньги не ограничение. По моей прикидке, 10 тысяч алертов в сутки обойдутся примерно в 40 центов.
• Для России главный вопрос — куда уходят данные. Jev — облачный сервис за рубежом. Объектам КИИ и государственным системам отправлять туда журналы и письма, как правило, нельзя. Им подойдут только локальные модели того же типа.

Что такое Jev

Психолог Даниэль Канеман делил мышление человека на две системы. Первая работает быстро и без рассуждений: вы видите лицо и сразу понимаете, что человек сердится. Вторая медленная: так вы умножаете в уме двузначные числа. TypeSafe называет Jev моделью «первой системы», и это точное описание: он отвечает сразу, ничего не рассуждая, а обычная языковая модель, которая сначала пишет рассуждение и только потом ответ, похожа на вторую. На вход подаётся текст или структура данных (в документации это называется состоянием) и набор вопросов трёх типов:

• Noul — вопрос «да или нет», ответ — вероятность «да» от 0 до 1;
• Choice — выбор одного варианта из вашего списка, до 255 вариантов, с вероятностью каждого;
• Score — оценка по упорядоченной шкале от 2 до 10 уровней.

Запрос идёт на https://api.typesafe.ai/v1/systemone с ключом в заголовке Authorization: Bearer. Формат полей — из документации, тексты вопросов мои:

{
  "model": "jev-1.13.0",
  "state": "Тема: Срочно подтвердите вход. Текст: ваш аккаунт будет заблокирован через 2 часа, перейдите по ссылке и введите пароль.",
  "questions": {
    "urgency": {
      "type": "noul",
      "instructions": "Письмо давит срочностью или угрозой последствий за промедление?"
    },
    "asks_secret": {
      "type": "noul",
      "instructions": "Письмо просит ввести пароль, одноразовый код или данные карты?"
    },
    "category": {
      "type": "choice",
      "instructions": "К какому классу относится письмо?",
      "criteria": {
        "phishing": "Пытается получить учётные данные или деньги обманом",
        "spam": "Массовая реклама без попытки обмана",
        "legitimate": "Обычная деловая или служебная переписка"
      }
    }
  }
}

Ответ приходит в виде чисел, без текста. У Noul это одно число noul. У Choice — choice, probabilities по каждому варианту и confidence от 0 до 1: чем сильнее вероятность сосредоточена на одном варианте, тем выше уверенность. У Noul поля confidence нет, о неуверенности говорит значение около 0,5.

Разбирать ответ не нужно: это готовые числа, и дальше решение принимает обычный код. Например, так (веса и пороги здесь условные, как их подбирать — ниже):

балл = сумма ответов с весами, от 0 до 1
балл выше 0.9       — в карантин (обратимо)
от 0.3 до 0.9       — аналитику или в песочницу
ниже 0.3            — пропустить

Все вопросы уходят одним запросом и считаются параллельно. В примере разработчика тринадцать вопросов к документу в 54 тысячи символов одним запросом обошлись в 12,2 раза дешевле и в 10 раз быстрее, чем тринадцать отдельных: документ отправляется один раз. Поэтому разложить решение на пять-десять простых вопросов почти не дороже, чем задать один сложный.

Чем отличается от LLM

Jev не может вернуть вариант, которого нет в вашем списке. Но он может выбрать неверный вариант из допустимых: ответ «legitimate» с вероятностью 0,95 по фишинговому письму безупречен по форме и неверен по сути. Та же мысль вынесена в название научной работы «Type-Safe Is Not Error-Free».

Что известно о цифрах и кто это говорит:

• Разработчик: задержка 70–500 миллисекунд, вход $0,042 за миллион токенов, выход бесплатно.
• Исследователи Carnegie Mellon University при слепой оценке людьми: там, где ответ есть в самом тексте, Jev отстаёт от GPT-6 не больше чем на три процентных пункта точности, при этом он в 277 раз дешевле и отвечает за 0,15 секунды. Там, где ответ надо вывести — экспертные знания, код, математика, логика, — он отстаёт на 7–28 пунктов.
• Автор теста на Хабре распределял закупочные позиции по справочнику ОКТРУ из 78 тысяч кодов. При повторных запусках Jev в 97,8% случаев давал тот же ответ, а GPT-OSS менял ответ примерно на каждой шестой позиции. Для аудита это важно: решение, которое при повторе получается другим, невозможно разобрать задним числом.
• Оговорка к повторяемости. В примере разработчика со страховыми заявками вероятности между пятнадцатью запусками в среднем менялись всего на 0,01. Но по одному вопросу вероятность колебалась от 0,43 до 0,53, то есть то была ниже 0,5, то выше. Если порог стоит ровно на 0,5, такой случай будет получать то «да», то «нет». Поэтому порогов нужно два, а случаи между ними решает человек.

Чего Jev не умеет: список от самого разработчика

TypeSafe публикует страницу «Jev 1.13 Jaggedness» с известными шероховатостями. Для безопасника она полезнее рекламы:

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

Отсюда правило проектирования: код считает и сравнивает, Jev понимает смысл. Возраст домена, результаты SPF и DKIM, число неудачных входов, расхождение видимой ссылки и реального адреса вы вычисляете заранее и передаёте готовыми фактами. Jev отвечает на то, что в тексте: давит ли письмо срочностью, выдаёт ли отправитель себя за банк, просит ли секрет.

Где ставить в SOC

Не на журналы событий. Запись в SIEM выглядит так: время, адрес источника, адрес назначения, порт, имя процесса, хэш файла, код события. Вывод из таких записей почти всегда требует счёта и сравнения. Заражённый хост выдаёт себя тем, что обращается к одному адресу через равные промежутки времени. Перебор паролей — тем, что за пять минут было двести неудачных входов. И то и другое — арифметика по сотням записей, то есть ровно то, что Jev по списку выше делает плохо. Если отдать ему выгрузку соединений и спросить «хост заражён?», он ответит числом, и число будет выглядеть убедительно. В этом опасность. Такие вопросы решают правила корреляции в SIEM.

На текст, который пишут люди:

• Ящик для подозрительных писем. Сотрудники пересылают туда всё подряд, и большая часть оказывается рассылками и обычными письмами. Это лучший первый пилот: писем много, текст живой, а если модель зря отправит письмо аналитику, это будет стоить ему минуты. Вместо одного вопроса «это фишинг?» задайте пять простых: давит ли письмо срочностью, просит ли пароль или код, выдаёт ли себя за банк, госорган или ИТ-службу, зовёт ли открыть вложение или перейти по ссылке, и к какому из трёх классов относится. К ответам модели ваш код добавляет то, что считает сам — возраст домена, результаты SPF и DKIM, — и складывает всё в один балл. Веса для сложения подбираются на ваших письмах и могут различаться по отделам: для бухгалтерии просьба о платеже весит больше, чем для ИТ.
• Описание алерта или тикета. Не сырые поля события, а текст, который собрал ваш код или написал человек. Choice выбирает очередь или плейбук, Noul отвечает на узкие вопросы: упомянута ли привилегированная учётная запись, пишет ли пользователь, что уже ввёл пароль.
• Обращения в поддержку. Просьба сбросить пароль или второй фактор «потому что потерял телефон» — обычный приём социальной инженерии. Если модель видит, что обращение просит сбросить MFA, ссылается на срочность или руководителя, просит сделать исключение из процедуры, его можно автоматически отправить на дополнительную проверку личности. Ошибка здесь стоит лишней проверки, поэтому автоматика допустима.
• Заметки аналитиков при закрытии. Указана ли причина, обосновано ли ложное срабатывание, не закрыт ли инцидент с упоминанием выноса данных. Контроль качества, на который у старшего смены обычно нет времени.
• Запросы к ИИ-ассистентам. У TypeSafe есть готовый рецепт: четыре вопроса на каждое сообщение, первый — «пытается ли сообщение заставить ассистента игнорировать, переопределить или раскрыть свои инструкции?». Где ставить такие проверки в цикле агента, я разбирал в статье «Как работает ИИ-агент и где его атакуют».

Объяснимость. Jev не говорит, почему он так решил. Частично помогает то же разложение на простые вопросы: в карточке видно, что «просит пароль» получило 0,96, «выдаёт себя за ИТ-службу» — 0,91, а «давит срочностью» — почти ноль. Это не объяснение модели, но аналитик за десять секунд проверит по письму, так ли это. Храните ответы на все вопросы вместе с версией модели, чтобы решение можно было разобрать и через месяц.

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

Стоимость. Моя прикидка по заявленной цене: 10 тысяч алертов в сутки по тысяче токенов — 10 миллионов токенов, около 40 центов в день. Ограничивают не деньги, а лимиты на число запросов (при превышении API отвечает ошибками 429 и 529) и то, куда уходят данные.

Первые внедрения построены так же осторожно. Ken Huang собрал на Jev семь модулей для SOC с агентами — от первичного разбора алерта до закрытия, — но изоляцию хоста система только предлагает, а выполняет её человек. По-моему, это правильное разделение: Jev решает, что человеку посмотреть первым, а не что отключить.

Порог: принимай уверенное, передавай сомнительное

Самая полезная для SOC научная работа о Jev — «JEV-as-a-Judge: Accept When Confident, Escalate When Unsure» (Yubo Li и соавторы, Carnegie Mellon University, arXiv, 29 сентября 2026). Название — готовая политика: принимай решение модели, когда она уверена, отправляй дальше, когда сомневается.

Сразу оговорка. В работе Jev оценивает не алерты, а ответы языковых моделей: какой из двух ответов лучше, верен ли факт. Перенос на SOC — моя аналогия, но устройство то же: дешёвая модель решает сама, когда уверена, а сомнительные случаи передаёт дорогой модели или человеку. Все результаты получены на размеченных наборах данных, а не в боевой эксплуатации. Уверенностью авторы называют наибольшую из вероятностей вариантов. Это не то же самое, что поле confidence в ответе API, поэтому их порог 0,9 нельзя просто взять и перенести к себе.

Что показала работа.

• Когда уверенность Jev не ниже 0,9, он почти так же точен, как GPT-6: 94,7% против 94,4% на 3 744 случаях. Когда Jev ошибается, он обычно и сам не уверен: на уверенность 0,9 и выше приходится только 12–21% его ошибок, у GPT-6 — 25–41%.
• Авторы проверили схему «Jev решает сам при уверенности от 0,9, остальное отдаёт GPT-6» на 1 610 парах, которые не использовались при настройке. Jev решил сам 68,5% случаев, остальные ушли к GPT-6, и среди них оказалось 85% всех ошибок Jev. В итоге схема дала 93,4% точности против 92,5% у одной GPT-6 и обошлась в 41,4% её стоимости.

Где порог не помогает. Уверенность полезна, пока она отличает ошибки от верных ответов. Авторы измеряют это показателем AUROC: 1 — отличает идеально, 0,5 — не лучше монетки. На обычных парах он 0,84, на парах, где неверный ответ написан убедительнее верного, — 0,76, а на свободных текстах, где нет правильного ответа для сравнения, — 0,498, то есть монетка. Для безопасности главная здесь вторая цифра: фишинговое письмо и есть текст, который атакующий написал убедительнее правды.

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

Что меняется для SOC: ошибки стоят по-разному. Правило авторов считает все ошибки одинаковыми. В SOC пропущенный инцидент и лишний алерт для аналитика — несравнимые по цене события. Пересчитаю по цифрам работы. Jev в одиночку ошибся примерно в 147 случаях из 1 610. 85% этих ошибок ушли к GPT-6, значит, около 22 ошибок остались среди 1 103 случаев, которые Jev решил сам, — это около 2%. Если бы «решил сам» означало «алерт закрыт автоматически», до двух из каждых ста закрытых алертов могли бы оказаться настоящими инцидентами. Это мой пересчёт, в работе такого числа нет.

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

import math

def upper_bound(k, m, alpha=0.05):
    # верхняя 95%-граница доли k из m (точная, Клоппер — Пирсон)
    lo, hi = k / m, 1.0
    for _ in range(50):
        p = (lo + hi) / 2
        cdf = sum(math.comb(m, i) * p**i * (1 - p)**(m - i) for i in range(k + 1))
        lo, hi = (p, hi) if cdf > alpha else (lo, p)
    return hi

def pick_close_threshold(cases, grid, max_missed=0.05):
    # cases: пары (вероятность «ложное срабатывание» от Jev, был ли это настоящий инцидент)
    incidents = sum(1 for _, incident in cases if incident)
    for tau in sorted(grid):                  # от мягкого порога к строгому
        missed = sum(1 for p, incident in cases if p >= tau and incident)
        if upper_bound(missed, incidents) <= max_missed:
            return tau
    return None                               # ни один не подошёл: закрывает только человек

Это не код авторов, а моя переделка. Функция ищет самый мягкий порог, при котором можно с 95-процентной уверенностью сказать: автоматически закрытыми окажутся не больше max_missed настоящих инцидентов.

Отсюда главный практический вывод, и он неприятный. Даже если в вашей выборке не пропущен ни один инцидент, доказать можно лишь, что пропускается не больше примерно 3/N инцидентов, где N — число инцидентов в выборке. При 20 инцидентах это до 14%, при 60 — до 5%. Сто алертов, среди которых пять настоящих, не доказывают ничего. Я проверил функцию на искусственных данных: на выборке с 80 инцидентами она находит порог, а на той же выборке, где инцидентов оставлено 20, не находит ни одного. Так и должно быть. Поэтому выборку собирайте так, чтобы настоящих инцидентов в ней было несколько десятков. В ящике для подозрительных писем это проще всего: настоящий фишинг туда приходит регулярно.

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

Почему не обычный классификатор

Этот вопрос задают на форумах, и он справедлив. На r/LocalLLaMA пост с критикой Jev собрал 635 голосов: участники считают его хорошо обученной узкой моделью, а не новым классом ИИ. Дальше мои рассуждения, а не измерения. Если у вас десятки тысяч размеченных примеров и задача не меняется, свой обученный классификатор будет дешевле, будет работать внутри контура и вести себя предсказуемо. Jev выигрывает, когда разметки мало, категории меняются каждый месяц и определение хочется поправить словами, а не переобучением. Для безопасника это обычная картина: новая тактика, новое правило, а размеченных примеров под них ещё нет.

Российский контекст

Куда уходят данные. Jev — облачный API зарубежной компании. Для SOC на объекте КИИ, в государственной системе или в банке со строгими внутренними правилами отправка журналов, писем и описаний инцидентов во внешний зарубежный сервис, как правило, упирается в требования к защите значимых объектов (187-ФЗ, приказы ФСТЭК) и внутренние запреты — ещё до разговора о пользе. К этому добавляется риск, что сервис станет недоступен из России в любой день. Решение принимайте вместе с юристом и владельцем систем, до пилота.

Локальная альтернатива. Модели того же класса бывают с открытыми весами. На Хабре описана CMF Decision под лицензией Apache-2.0: 304,5 МБ, работает на обычном процессоре. Автор заявляет 93,34% против 85,58% у Jev на наборе BANKING77 — это его цифры на одном наборе. Для закрытого контура это самый короткий путь попробовать сам подход: вопросы, вероятности, пороги. Рецепт выбора порога выше к ней применим так же.

Доступ и персональные данные. Если внешний сервис вам разрешён, в России Jev можно подключить через агрегаторы с оплатой в рублях, например Polza AI. Но агрегатор — ещё один посредник, через которого пройдут ваши письма и журналы, поэтому его условия хранения данных читайте отдельно. Сама TypeSafe заявляет, что не обучает модели на данных клиентов, и предлагает корпоративным клиентам режим без хранения; где именно обрабатываются данные, написано в её соглашении об обработке данных. Если в письмах есть персональные данные, их отправка за рубеж — трансграничная передача по 152-ФЗ со своими требованиями. Для первого эксперимента берите обезличенные письма.

Поддельные магазины. По сообщению CISOCLUB со ссылкой на исследование CTT Report Hub, через три дня после запуска появились сайты, перепродающие доступ к API в 3–11,5 раза дороже официального. За неделю с 15 по 22 сентября в журналах Certificate Transparency появилось около 670 сертификатов на «jev»-домены. Главный риск не в переплате: ваши письма и журналы идут через чужую инфраструктуру без договора и политики хранения. Это атака на цепочку поставок, только на волне хайпа. Ключ выпускайте только в кабинете TypeSafe или у агрегатора, чьи условия прочитали, адрес API сверяйте с документацией (api.typesafe.ai), а похожие домены из crt.sh внесите в блок-лист прокси.

Ещё два риска

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

Версия и калибровка. Разработчик говорит, что вероятности откалиброваны, то есть «0,9» сбывается в девяти случаях из десяти, и сам же признаёт слабую калибровку уровней Score в версии 1.13. Проверьте на своих данных: разбейте ответы на группы по вероятности (0,8–0,9, 0,9–1 и так далее) и посчитайте, какая доля в каждой группе верна. Псевдоним jev-latest переезжает на новую модель с каждым выпуском, и настроенные пороги могут сломаться без единой правки в вашем коде. Документация советует указывать номер версии, например jev-1.13.0, и переходить на новую по своему графику, после повторной проверки.

Что сделать завтра

1. Решите, можно ли вам отправлять эти данные во внешний сервис. Если нельзя, пробуйте локальную модель.
2. Возьмите ящик для подозрительных писем и замените вопрос «фишинг ли это» пятью простыми. Всё, что надо посчитать или сравнить по времени, считает ваш код.
3. Запустите модель подсказчиком: она расставляет письма по срочности, решает аналитик. Так вы заодно накапливаете разметку.
4. Когда в разметке наберётся несколько десятков настоящих инцидентов, подберите порог автоматического закрытия по доле пропущенных инцидентов, зафиксируйте его и укажите в запросах номер версии модели.
5. Сотруднику на автоматически закрытое письмо отвечайте «принято», а не «безопасно».
6. Отдельно проверьте модель на письмах, специально написанных так, чтобы её обмануть, и внесите поддельные домены TypeSafe в блок-лист.

Итог у меня такой. Jev не заменяет LLM там, где нужно разобраться и объяснить, и не заменяет правила SIEM там, где ответ надо посчитать. Но большая часть рутины с текстом в защите — это сортировка: в какую очередь, по какому плейбуку, пропустить или задержать. Для сортировки быстрая модель, которая отвечает числом, подходит лучше разговорчивой, если вы проверили её на своих данных. И запишите в политику безопасности, кто отвечает за порог. Раньше за каждое закрытое письмо отвечал аналитик, теперь за тысячи таких решений отвечает одно число в настройках.

Источники: документация TypeSafe AI, быстрый старт и формат API, известные ограничения Jev 1.13, версии моделей, рецепт защиты LLM, маршрутизация по уверенности, пакетные вопросы, повторяемость ответов Noul, JEV-as-a-Judge, Carnegie Mellon, arXiv, Type-Safe Is Not Error-Free, arXiv, реализация агентного SOC, Ken Huang, тест Jev на Хабре, CMF Decision на Хабре, критика сообщества, AI-Stat, поддельные магазины, CISOCLUB, доступ из России, Polza AI. Сведения сверены 30 сентября 2026 года, сервис в раннем доступе и меняется.