Jev и рост моделей принятия решений: что «System One» ИИ значит для инструментов безопасности

25 сентября 2026 года компания TypeSafe AI анонсировала Jev — первую модель в категории, которую она называет «System One»: не чат-бот и не просто более крупная языковая модель, а то, что компания описывает как модель принятия решений — систему, созданную, чтобы отвечать на ограниченный вопрос типизированным, откалиброванным ответом, а не абзацем прозы. Анонс насыщен конкретными цифрами, поэтому в этом материале мы разбираем его ровно так, как он заявлен, прямо отмечаем, что удалось проверить, а что нет, и смотрим, почему сама лежащая в основе идея — принимать решение вместо того, чтобы генерировать текст, — заслуживает серьёзного внимания именно для программного обеспечения безопасности.

Что именно анонсировала TypeSafe

TypeSafe AI основал Диогу Алмейда, который пишет в анонсе: «В OpenAI я помогал создавать методы, которые сделали языковые модели полезными для следования инструкциям и общения с людьми». Jev, названную «первой публичной моделью» компании, преподносят как совершенно другую задачу: производство того, что TypeSafe называет типобезопасными структурированными значениями с откалиброванными вероятностями и оценками уверенности, генерируемыми с помощью того, что компания называет параллельным сэмплером, вместо обычного посимвольного (токен за токеном) декодирования, и обученными методом, который компания называет Reinforcement Learning for Calibrated Decisions, или RLCD.

• TypeSafe сообщает о полном времени отклика «70–500 мс» против измеренных ею «от 3 до 329 секунд» для передовых языковых моделей, с которыми она сравнивала Jev.
• TypeSafe оценивает входные токены в «0,042 доллара за миллион токенов», выходные токены при этом указаны как бесплатные.
• На собственных оценках рабочих процессов TypeSafe сообщает, что Jev работает «в 193,6 раза быстрее и в 444,6 раза дешевле», чем политики, с которыми её сравнивали.
• TypeSafe описывает ошибку типа в выводе Jev, по её собственным словам, как «математически невозможную».
• Jev находится в раннем доступе; TypeSafe заявляет, что снимает разработчиков «с листа ожидания настолько быстро, насколько можем».

Генерация против решения

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

Здесь стоит разделить два утверждения, потому что это не одно и то же: типизированность и калиброванность. Типизированный вывод ограничивает форму ответа — вопрос типа «выбор» возвращает один из вариантов из списка, вопрос типа «оценка» возвращает число в заданном диапазоне, никогда не случайное предложение или выдуманное поле. Калибровка — гораздо более старая и совершенно отдельная идея. Это статистическое свойство, а не стилистическое: оно означает, что когда система заявляет вероятность 0,62, она оказывается права именно с такой частотой среди множества похожих предсказаний, так что программа ниже по цепочке может действительно использовать это число как порог, а не относиться к нему как к украшению.

Собственная терминология TypeSafe заимствует словарь из психологии, а не из статистики. Дэниел Канеман, получивший в 2002 году Нобелевскую премию по экономике «за применение психологических методов в экономической науке, особенно в отношении суждений и принятия решений человеком в условиях неопределённости», популяризировал эти термины в книге «Думай медленно… решай быстро»: «Система 1» — «быстрая, автоматическая, частая, эмоциональная, стереотипная, неосознаваемая», тогда как «Система 2» — «медленная, требующая усилий, редкая, логическая, вычислительная, осознаваемая». Метафора выразительна, но она описывает человеческое познание, а не гарантию в отношении программного обеспечения. Модель может быть быстрой так же, как быстра Система 1, при этом заявленная уверенность вообще ничего не будет значить — калибровку нужно заслужить и измерить, а не подразумевать по названию.

Что может и чего не может значить «не может галлюцинировать»

Заявление TypeSafe о том, что ошибка типа «математически невозможна», описывает ограниченное декодирование — технику, которая уже существует и в других местах. Собственное руководство OpenAI по структурированным выводам даёт похожую гарантию: функция, как там сказано, «гарантирует, что модель всегда будет генерировать ответы, соответствующие заданной JSON-схеме, так что вам не нужно беспокоиться о том, что модель пропустит обязательный ключ или придумает недопустимое значение перечисления». Эта гарантия реальна и полезна. Но она и уже, чем звучит: она ограничивает форму ответа, а не то, правилен ли он. Вопрос типа «выбор» с тремя вариантами всегда вернёт один из трёх — в том числе, если модель неверно оценила входные данные, уверенный, корректно типизированный, но неправильный ответ.

Калибровку нужно проверять, а не декларировать. Стандартный инструмент — диаграмма надёжности: сгруппировать предсказания по заявленной уверенности и для каждой группы построить, как часто эти предсказания на самом деле оказывались верными; разрыв между диагональю и наблюдаемой линией обычно обобщают как ожидаемую ошибку калибровки. Это не новый вопрос для машинного обучения — работа Guo и др. 2017 года «On Calibration of Modern Neural Networks» обнаружила, что «современные нейронные сети… по умолчанию плохо откалиброваны», а простое, однопараметрическое исправление под названием temperature scaling оказалось «на удивление эффективным» для устранения этого. Урок обобщается за пределы одной этой работы: калибровка — не то свойство, которое модель может объявить о себе сама. Это то, что нужно проверять на собственных размеченных данных, потому что она склонна деградировать именно там, где нужна больше всего, — на входных данных, совершенно не похожих на те, на которых модель настраивалась.

Минимальный каркас для оценки (шаблон)

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

# Illustrative pseudo-code. Mirrors the request shape shown in TypeSafe's
# quickstart docs (POST /v1/systemone with state, model, and typed questions).
# Not run against Jev or any live API; no results are claimed here.
import requests

def ask(state: str, question_id: str, question: dict) -> dict:
    resp = requests.post(
        "https://api.typesafe.ai/v1/systemone",
        headers={"Authorization": f"Bearer {API_KEY}"},
        json={"state": state, "model": "jev-latest", "questions": {question_id: question}},
    )
    return resp.json()["answers"][question_id]

# 1. Shape check: does every response parse against the declared type, on your
#    own edge cases, not just a vendor demo set?
# 2. Calibration check: bucket the stated confidence and compare it to the
#    true label rate, on data the model has never seen.
buckets = {i: {"n": 0, "correct": 0} for i in range(10)}
for state, true_label in labeled_sample:          # your own traffic, labeled by hand
    answer = ask(state, "decision", {"type": "noul", "instructions": "Should this be allowed?"})
    bucket = min(int(answer["noul"] * 10), 9)
    buckets[bucket]["n"] += 1
    buckets[bucket]["correct"] += int(round(answer["noul"]) == true_label)

for b, s in buckets.items():
    if s["n"]:
        stated = (b + 0.5) / 10
        observed = s["correct"] / s["n"]
        print(f"stated~{stated:.2f}  observed={observed:.2f}  n={s['n']}")  # the gap here is your calibration error

• Разбирается ли типизированный ответ всегда, на входных данных, которые производит ваша собственная система, а не только на демонстрационном наборе поставщика.
• Оказывается ли заявленное значение 0,9 верным примерно девять раз из десяти на вашем собственном размеченном трафике, а не на чужом наборе для оценки.
• Держится ли эта калибровка на входных данных, непохожих на всё, что модель видела раньше: новое приложение, новый протокол, отправитель, прочитавший тот же анонс, что и вы.
• Что делает вызывающая сторона при тайм-ауте или сбое, поскольку системе принятия решений нужен безопасный вариант по умолчанию на случай, когда модель принятия решений недоступна.

Почему это важно для инструментов безопасности

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

Компромисс с приватностью, честно

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

FireAI, собственный файрвол HisnLabs для macOS, сделал противоположный выбор именно для той категории решений, о которой идёт эта статья. FireAI работает на macOS 14 или новее на Apple silicon, за разовую плату 49 евро, и прямо не является ни антивирусом, ни VPN. Когда приложение, которое вы раньше не видели, пытается выйти в сеть, FireAI может запустить небольшую модель прямо на устройстве — опциональную загрузку объёмом около 1,5 ГБ, — чтобы проверить это соединение и показать вам запрос с прикреплённой причиной на понятном языке; проверяемый трафик никуда не отправляется. Каждое такое решение, принятое с помощью ИИ, становится видимым правилом, привязанным к цифровой подписи приложения, которое можно увидеть и отменить, наряду с фидами угроз, применяемыми локально, а не запрашиваемыми у удалённого сервера.

Мы не утверждаем, что модель FireAI, работающая на устройстве, сопоставима с Jev или любой другой моделью класса «System One» по чистой правильности, скорости или цене, — мы не проводили такого сравнения и не публикуем здесь собственных оценок. Что этот анонс действительно подтверждает, так это направление проектирования: решение по безопасности хорошо обслуживается небольшой, быстрой, ограниченной моделью, работающей рядом с данными, а не маршрутизацией через универсальный чат-бот где-то в другом месте. TypeSafe отстаивает эту позицию со стороны API; FireAI уже строит на ней свою архитектуру со стороны устройства, и по другой причине — потому что именно для файрвола данные, о которых идёт речь, вообще не должны покидать машину, чтобы быть оценёнными.

Открытые вопросы

• Независимые оценки: ни одна сторонняя организация ещё не опубликовала воспроизведение показателей скорости или стоимости из анонса TypeSafe на данных, которые выбирала не сама TypeSafe.
• Калибровка при сдвиге распределения данных — именно тот сценарий, о котором работа Guo и др., и тот, что важнее всего против противника, адаптирующегося сразу после публикации метода защиты.
• Сохранится ли цена при реальном объёме в продакшене и сохранится ли заявленная задержка при устойчивой нагрузке, а не при единственном показанном запросе.
• Как модель ведёт себя на состязательных или по-настоящему неоднозначных входных данных, где уверенный типизированный ответ может быть менее честным, чем ответ «неясно».
• Когда ранний доступ откроется за пределами листа ожидания, кому именно и на каких условиях в отношении данных, отправляемых как «state».

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

Какое место здесь занимают FireAI и HisnLabs

We have not tested Jev and make no claim it works as described or that FireAI matches it in any way — but the idea that a security decision deserves a small, bounded, fast model instead of a paragraph from a chatbot is one we built FireAI around a year before TypeSafe wrote a blog post about it.

FireAI — это собственный продукт HisnLabs: ИИ-файрвол, работающий прямо на вашем Mac. Он показывает простым языком каждое соединение, которое устанавливают ваши приложения, и позволяет вам решать, что покидает ваш Mac, — его ИИ работает локально, поэтому ваш трафик никогда не отправляется ни нам, ни кому-либо ещё. Команда исследователей безопасности HisnLabs — это те, кто поддерживает точность этих решений: они каталогизируют, какие домены являются обычной телеметрией, а какие — реальным сервисом, отслеживают страну и сеть, стоящие за соединением, и обучают локальную модель (функцию Autopilot) на реальных шаблонах трафика — и ничего из этого не покидает ваш Mac.

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