Jev от TypeSafe: ИИ-модель, которая не умеет отказывать

На прошлой неделе стартап TypeSafe выпустил модель Jev — и она не похожа на очередной чат-бот. В подкасте Latent Space сооснователь и CEO компании Диого Алмейда, бывший инженер OpenAI, объяснил, почему три года подряд говорил о необходимости нового класса моделей — и почему только сейчас смог его построить. Речь о программируемых ИИ-моделях, которые с самого начала проектируются не для диалога с человеком, а для вызова из кода — как обычная функция или database-запрос, только с интеллектом внутри.

Программируемые ИИ-модели: код как единственный потребитель

Ключевая мысль Алмейды простая: индустрия обучала модели либо предсказывать следующий токен в интернет-тексте, либо — через RLHF — вежливо отвечать человеку в чате. Ни та, ни другая цель не годится, если модель должна быть встроена в программный конвейер как зависимость, о которой пользователь может даже не знать. TypeSafe называет свой подход RLCD — новый north star, аналогичный по значимости появлению RLHF или RLVR, только заточенный под «программы в цикле», а не под инструкции от человека. Практическое следствие — три новых примитива API (bool с говорящим названием bernoulli, score и ещё один), которые сознательно не мапятся один в один на привычные типы данных, чтобы разработчик не путал вероятностный вывод модели с детерминированным значением переменной.

Почему отказ модели — это баг, а не фича

Самый спорный тезис интервью: в API у Jev нет отказов вообще. Алмейда называет safety-refusal «типовой ошибкой» (type error) — если библиотека где-то в фоне вдруг решает не выполнить запрос из соображений безопасности, а вызывающий код об этом не знает, всё приложение стохастически ломается. Его аргумент разделяет продукт и инфраструктуру: ограничения уместны в ChatGPT или Claude, где на том конце реальный пользователь и есть кому нести ответственность за диалог. Но API — это слой, на котором разработчик строит собственную систему, и решения о том, что допустимо, должны приниматься на уровне приложения, а не молча внутри модели. Для тех, кто собирает production-агентов на Claude Code, MCP-серверах или любых других orchestration-слоях, это прямое напоминание: надёжность агентной системы определяется тем, насколько предсказуемо ведёт себя её ядро под нагрузкой реальных, а не тепличных промптов.

Надёжность вместо бенчмарков

Второй сквозной сюжет — принципиальный отказ TypeSafe от публичных бенчмарков. Алмейда объясняет это через калибровку: RLHF-модели склонны к mode dropping — они жертвуют редкими, но правильными ответами ради уверенно-гладких средних, и именно поэтому вероятность ошибки растёт с длиной генерации быстрее, чем кажется математически интуитивным (привет знаменитому графику Яна Лекуна про «LLM обречены»). Публичные лидерборды в этой картине мира — источник вредного стимула: их можно газовать данными, похожими на тестовые. Вместо цифр TypeSafe предлагает разработчикам полагаться на собственные внутренние evals под конкретный workflow — и на robustness-тесты, где в промпт подмешивают случайные nonce-идентификаторы и проверяют, что семантически одинаковые запросы дают семантически одинаковые ответы. Показательно, что детерминизм (одинаковый вход → побитово одинаковый выход) в Jev сознательно не гарантируется: команда считает робастность более ценным свойством, чем строгую воспроизводимость, и открыто говорит, что это compromise ради интеллекта на доллар.

Что это значит для рынка

За неделю Jev, по словам Алмейды, преодолел отметку в триллион токенов в день — причём не от людей, тестирующих чат, а от машин, которые уже встроили модель в фоновые процессы. Это косвенное подтверждение главного тезиса интервью: узкое место не в интеллекте моделей, а в отсутствии «правильных разъёмов» между этим интеллектом и экономически ценной рутинной работой. Для читателей, следящих за Claude Code и агентными инструментами, это сигнал не о конкретном продукте, а о направлении: рядом с моделями-собеседниками формируется отдельная категория — модели-инфраструктура, которые не пытаются быть удобными для человека, а пытаются быть предсказуемыми для кода. Куда более узкая ниша, чем универсальный ассистент, но именно поэтому — потенциально куда более прибыльная для тех, кто строит production-системы, а не демо.