Главная / Статьи / Jev от TypeSafe: модель, которая возвращает типизированные решения вместо текста

Jev от TypeSafe: модель, которая возвращает типизированные решения вместо текста

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

1485 слов

Новая модель от TypeSafe вообще не генерирует текст. Она возвращает типизированное решение с приложенной вероятностью, и это меняет то, в каких местах вашего кода вообще может жить ИИ-модель.

Модель называется Jev, и это первая из линейки, которую компания называет System One Models. Название отсылает к разделению по Канеману на быстрое, автоматическое мышление и медленное, обдуманное. Jev берёт на себя быструю половину, а обдуманная остаётся за большими языковыми моделями.

Анонс на typesafe.ai поднялся на Hacker News почти до тысячи очков и собрал больше 300 комментариев, примерно половина из которых спорила о заголовке. Выглядит это как очередной запуск маленькой, быстрой и дешёвой модели, но это не так. Jev вообще не пишет: текстового вывода у него нет. Поэтому он почти не конкурирует с чат-моделями, которыми вы уже пользуетесь. Он конкурирует с оператором if.

Оператор if, за который все вечно извиняются

Почти в каждом пайплайне есть одно гнилое место. Где-то посередине нужно принять решение на глаз. Стоит ли этому тикету пройти без очереди? Не звучит ли этот ответ грубо? Стоит ли оставлять эту строку?

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

Поэтому команды стали ставить туда LLM. Это работает, но заодно ломает пайплайн. Одно решение может занимать около восьми секунд, а парсинг JSON падает на четырёхсотой строке. Гонять такое на каждый элемент большого датасета или внутри цикла не получится, и уж точно не в том месте, где пользователь ждёт ответа.

Проблема никогда не была в интеллекте

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

Что выпустила TypeSafe

Основатель формулирует это одной фразой: вызов функции с интеллектом уровня фронтир-моделей, который принимает неструктурированное состояние и возвращает типизированные вероятностные решения.

Вы передаёте state, будь то тикет поддержки, документ или кадр игры, сериализованный в текст, плюс словарь вопросов. В ответ приходят типизированные ответы. Типов вопросов всего три, и это вся поверхность API:

  • Choice выбирает один вариант из набора. Возвращает выбор, вероятность для каждого варианта и значение уверенности.
  • Score оценивает что-то по упорядоченным уровням с описаниями и возвращает тот же набор значений.
  • Noul — вопрос «да/нет», ответом на который служит вероятность того, что ответ «да».

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

Заявленная задержка — от 70 до 500 мс от начала до конца, а цена — $42 за миллиард входных токенов, вывод бесплатный. Значит ли эта цифра то, что кажется, разберём ниже.

Весь API

Быстрый старт начинается с одного импорта:

from typesafe_sdk import Choice, Noul, Score, TypeSafeClient

Дальше на вход идёт тикет поддержки, а обратно приходят три решения:

client = TypeSafeClient()ticket = "Hi, I've been trying to connect my Stripe account for 3 days and it keeps failing. I'm losing sales. Please help ASAP."response = client.system_one(
    state=ticket,
    questions={
        "department": Choice(
            instructions="Which team should handle this",
            criteria={
                "billing": "Payment or subscription issues",
                "technical": "Bugs or integration problems",
                "sales": "Pricing or account questions",
            },
        ),
        "frustration": Score(
            instructions="How frustrated the customer appears",
            criteria=[
                "Calm, just stating facts",
                "Frustrated but civil",
                "Very angry, strong language",
            ],
        ),
        "is_urgent": Noul(
            instructions="The message conveys urgency or time-sensitivity",
        ),
    },
)

Никакого промпт-инжиниринга, никаких инструкций «отвечай только валидным JSON» и никаких обёрток с повторными попытками. Три решения приходят за один запрос. SDK для Python и JavaScript работают поверх одного POST-эндпоинта.

То, что меняет подход к написанию кода

Ответ LLM звучит одинаково уверенно, знает модель ответ или гадает. Jev вместо этого возвращает распределение.

Метод обучения называется RLCD, Reinforcement Learning for Calibrated Decisions, и его цель — чтобы эти вероятности соответствовали тому, как часто модель действительно права. А значит, можно ветвиться по степени сомнения:

  • Выше 0.9 — маршрутизировать элемент автоматически.
  • От 0.6 до 0.9 — передать модели покрупнее.
  • Ниже — показать человеку.

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

Что тестировщики сделали в первый же день

Первые пользователи провели серию экспериментов, и один из них показывает суть продукта лучше любой таблицы бенчмарков. Автор из медиакомпании скормил Jev все 27 своих опубликованных статей и ещё 10 подделок, намеренно написанных в стиле ИИ. Он задал 21 параллельный вопрос о типичных признаках машинного текста. Всего вышло 777 решений по 37 документам. Все они пришли меньше чем за 0.7 секунды и обошлись примерно в четверть цента.

CEO компании продолжил четырьмя проверками на 12 фрагментах, запустив их наперегонки с фронтир-LLM. Jev потребовалось в среднем 0.35 секунды на фрагмент, а LLM — 8.83. Это примерно в 25 раз быстрее и, по их подсчётам, примерно в 580 раз дешевле.

Демо с Doom

Именно одно демо заставило публику Hacker News всё понять. TypeSafe подключила Jev к игре в Doom. Модель не читала пиксели: она получала состояние игры, сериализованное в структурированный текст, примерно десять запросов в секунду. Инженер, который это собрал, говорят, переживал из-за такой частоты запросов, а она обходится примерно в $7 в час.

ИИ внутри игрового цикла — это весь питч, воплощённый буквально.

Где модель проседает

На главной странице обещают «Zero Hallucinations», и именно с этим утверждением стоит поспорить в первую очередь. Гарантируется лишь то, что вывод соответствует вашей схеме, то есть Choice всегда попадёт в один из ваших вариантов. Но это не то же самое, что быть правым. Jev может вернуть валидный и уверенно неверный ответ, и в треде на Hacker News об этом говорили подробно.

Эксперимент автора это подтверждает. В тестовый набор заложили семь дефектов. Jev нашёл шесть и пропустил один — абзац про общий календарь, по которому родители и сотрудники «учат вместе». Сравнительная LLM его заметила. Его собственный вердикт был честным: если дело идёт к продакшену, сначала нужно тщательнее проверить точность.

Жёсткие ограничения тоже вполне реальны:

  • Контекстное окно — 32k токенов, так что о работе с целым репозиторием можно забыть.
  • У Choice максимум 255 вариантов.
  • Изображения на вход пока не принимаются.
  • Архитектуру держат в секрете. Ни статьи, ни независимой оценки RLCD нет, только ранние отзывы.

Цена — это не та замена, о которой вы думаете

$42 за миллиард входных токенов выглядит смехотворно дёшево на фоне фронтир-модели, но единица измерения другая. Вы покупаете решения, а их вы будете принимать гораздо чаще, чем когда-либо делали вызовы LLM. Низкая цена за токен как раз и позволяет делать десять вызовов в секунду. Это не простое вычитание из вашего текущего счёта.

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

Стоит ли она вашего внимания?

Да, но не из-за множителей скорости. Jev выделяется тем, что честно очерчивает свои рамки. Он не болтает, не рассуждает вслух, не объясняет себя и не делает вид, что умеет.

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

Прогоните его на своих данных, прежде чем подпускать к чему-то важному, — этот совет ранние тестировщики повторяют постоянно. Многие и так сомневаются, что одна текстовая модель на все случаи — правильный инструмент для узких задач, и это первая серьёзная попытка сделать что-то иначе.