Джев і розвиток моделей прийняття рішень: що означає штучний інтелект 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 / MTok», а вихідні токени вказані як безкоштовні.
• Згідно з власними оцінками робочого процесу, TypeSafe повідомляє, що Jev працює «в 193,6 раза швидше, у 444,6 раза дешевше», ніж політики, за якими він оцінювався.
• TypeSafe описує помилку типу у виводі Jev як, за його словами, «математично неможливу».
• Jev знаходиться в ранньому доступі; TypeSafe каже, що виводить розробників зі списку очікування «якнайшвидше».

Покоління проти рішення

Велика частка того, що називають «ШІ у виробництві», — це взагалі не письмове завдання. Дозволити або заблокувати підключення. Ескалація або закриття заявки. Позначити або видалити транзакцію. Направте повідомлення в ту чи іншу чергу. Бажаний результат не є прозою, це мітка, витягнута з короткого фіксованого списку, іноді з доданою оцінкою. Проведення такого роду запитань через модель, створену для створення плавних абзаців, є невідповідністю: повертається крапля JSON, яку потрібно проаналізувати та перевірити на дійсність, і будь-яка заявлена ​​впевненість, як правило, мало що означає, оскільки ніщо не змусило його відстежувати реальний рівень помилок моделі.

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

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

Що «не можна галюцинувати» може і не може означати

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

Калібрування – це те, що потрібно перевіряти, а не стверджувати. Стандартним інструментом є діаграма надійності: передбачення групи за їхньою заявленою достовірністю, і для кожного сегмента побудуйте графік, як часто ці передбачення насправді виявлялися правильними; розрив між діагоналлю та спостережуваною лінією зазвичай підсумовується як очікувана помилка калібрування. Це не нове питання для машинного навчання — Стаття Гуо та інших 2017 року «Про калібрування сучасних нейронних мереж» виявив, що «сучасні нейронні мережі... погано відкалібровані» за замовчуванням, і що просте виправлення з одним параметром під назвою температурне масштабування було «напрочуд ефективним» у виправленні цього. Цей урок узагальнює минулий цей документ: калібрування не є властивістю, про яку модель може повідомляти про себе. Це те, що ви перевіряєте на своїх власних позначених даних, оскільки воно має тенденцію погіршуватися саме там, де вам це найбільше потрібно — на вхідних даних, які зовсім не схожі на те, на що була налаштована модель.

Мінімальна система оцінки (шаблон)

Перш ніж спрямувати реальне рішення через будь-яку модель прийняття рішень, Jev чи іншу, три питання важливіші за будь-яку цифру постачальника: чи введена відповідь аналізує вашу схему щоразу, чи відстежує заявлена ​​достовірність свій реальний показник попадання на помічену вибірку ваших власних даних і чи витримує це калібрування вхідні дані, які відрізняються від того, що вже бачила модель. Наведений нижче ескіз — це шаблон, побудований на основі форми запиту, показаної у власній документації про швидкий старт TypeSafe. У ньому немає жодних заяв про те, що покаже його запуск проти Джева — ми його не запускали, і це ілюстративний псевдокод, а не звіт.

# Illustrative pseudo-code. Mirrors the request shape shown in TypeSafe's own
# 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 є правильним у дев’ять разів із десяти для вашого власного позначеного трафіку, а не для чиєїсь eval-множини.
• Чи тримається це калібрування на вхідних даних, які не бачилися раніше: нова програма, новий протокол, відправник, який прочитав те саме оголошення, яке ви щойно прочитали.
• Що робить абонент, коли минув час очікування або збій, оскільки система прийняття рішень потребує безпечного замовчування, коли модель рішення недоступна.

Чому це важливо для засобів безпеки

Брандмауер, спам-фільтр, перевірка на шахрайство, черга сортування: кожне з них є системою прийняття рішень, яка знову і знову відповідає на одне й те саме запитання — дозволити чи заблокувати введені дані, з якою мірою впевненість і де знаходиться поріг. Власна сторінка оцінки TypeSafe черпає свої приклади саме з цієї території: рішення про те, чи закривати сповіщення системи безпеки, передавати його особі чи негайно стримувати, є рішенням сортування, а не письмовим завданням, і це тип виклику, який інструмент безпеки робить постійно, з гучністю, яку жоден аналітик не зможе переглянути вручну.

Компроміс конфіденційності, чесно кажучи

Jev, як це описує TypeSafe, — це розміщений API: запит передає «стан», тобто будь-які дані, про які йде мова, на сервери TypeSafe через Інтернет. Для прикладів інцидентів із безпекою та сортування, як підкреслює сам TypeSafe, цей стан є саме тією інформацією, яку багато людей не хотіли б передавати третій стороні за замовчуванням — яка програма спілкується з якою адресою, як часто, з якого пристрою. Надсилання даних у будь-яку хмарну модель, якою б швидкою чи дешевою вона не була, означає, що дані залишають машину, з якої вони надійшли.

FireAI, власний брандмауер macOS HisnLabs, зробив протилежний вибір саме для тієї категорії рішень, про яку йдеться в цій статті. FireAI працює на macOS 14 або пізнішої версії на Apple Silicon за одноразову ціну 49 євро і явно не є антивірусом і не VPN. Коли програма, яку ви раніше не бачили, намагається підключитися до мережі, FireAI може запустити невелику модель на самому пристрої — необов’язкове завантаження на 1,5 ГБ — щоб перевірити це з’єднання та підказати вам причину простою мовою; трафік, який переглядається, ніколи нікуди не надсилається. Кожне з цих рішень за допомогою штучного інтелекту стає видимим правилом, пов’язаним із сигнатурою коду програми, яке ви можете переглядати та скасовувати, поряд із повідомленнями про загрози, які застосовуються локально, а не запитуються на віддаленому сервері.

Ми не стверджуємо, що модель FireAI на пристрої відповідає Jev або будь-якій іншій системній моделі щодо коректності, швидкості чи ціни — ми не проводили це порівняння та не маємо власних оцінок для публікації тут. Те, що це оголошення підтримує, так це напрямок розробки: те, що рішення щодо безпеки добре обслуговується невеликою, швидкою, обмеженою моделлю, яка працює поруч із даними, а не шляхом маршрутизації через універсальний чат-бот деінде. TypeSafe робить це з боку API; FireAI вже будує його з боку пристрою, і з іншої причини — тому що, зокрема, для брандмауера дані, про які йдеться, взагалі не повинні залишати машину для оцінки.

Відкриті питання

• Незалежні оцінки: жодна стороння сторона ще не опублікувала відтворення множників швидкості або вартості в оголошенні TypeSafe, на основі даних, які TypeSafe не вибирав.
• Калібрування під зміною розподілу — точний сценарій, про який йдеться в статті Гуо та інших, і той, який має найбільше значення проти супротивника, який адаптується, коли метод захисту стає публічним.
• Чи зберігається ціна при реальному обсязі виробництва та чи зберігається заявлена ​​затримка при тривалому навантаженні, а не при одному продемонстрованому запиті.
• Як модель поводиться за суперечливих або справді неоднозначних вхідних даних, де впевнено введена відповідь може бути менш чесною, ніж відповідь, яка говорить «незрозуміло».
• Коли ранній доступ відкривається поза списком очікування, кому та на яких умовах для даних, надісланих як "стан".

Наразі 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.