Модель, которая не пишет текст: зачем в стеке слой решений

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

Что такое System One и почему отказ от текста — это приобретение

Название отсылает к Канеману: быстрое интуитивное мышление против медленного рассуждающего. TypeSafe называет свой класс моделей System One и противопоставляет его обычным языковым моделям не по уму, а по назначению.

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

Отсюда три следствия, которые важны в разговоре с клиентом.

Ответ не может не подойти по формату. Схема задана до запроса, и модель физически не способна вернуть поле не того типа. Это не «стало реже ошибаться», это другое свойство.

К каждому ответу приложена уверенность. Не «модель сказала да», а «модель сказала да с такой-то уверенностью». Именно это, а не скорость, меняет разговор об автоматизации: систему, которая не сообщает, когда она сомневается, нельзя пускать в автоматический режим, даже если она права в девяноста пяти случаях из ста.

Вопросы задаются все сразу. Языковая модель порождает ответ по одному кусочку, каждый следующий зависит от предыдущего. Jev отвечает на все вопросы одним заходом параллельно — отсюда и скорость.

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

Где это встраивается: слой решений перед дорогой моделью

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

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

Арифметика, которую стоит показать клиенту на его собственных цифрах. Если в месяц приходит сто тысяч обращений и восемьдесят тысяч из них типовые, вопрос не в том, насколько умна большая модель. Вопрос в том, зачем отправлять в неё восемьдесят тысяч запросов, на которые достаточно ответить маршрутизацией.

Та же схема повторяется в других местах: в продажах — определить намерение письма и запустить сценарий; в закупках — проверить комплектность предложения и отправить на разбор только спорное; в безопасности — решить, какое событие вообще заслуживает глубокого анализа. Везде одно и то же: сначала понять, что это, потом тратить дорогое.

Самое интересное: слой контроля перед действием агента

Есть применение, которое для корпоративного заказчика важнее скорости и дешевизны.

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

Перед каждым действием можно поставить отдельный быстрый вопрос: можно ли сейчас это выполнять. Уверенность высокая и ответ «да» — выполняем. Уверенность низкая — отправляем человеку. Ответ «нет» — останавливаем и записываем почему.

В документации Pydantic AI этот приём показан буквально на команде удаления каталога: модель отвечает не только «разрешить или нет», но и отдельным полем — «приведёт ли это к потере данных или утечке секретов». Два простых вопроса вместо одного сложного.

Для продавца это разворачивает разговор о безопасности агентов. Раньше ответ был «мы добавим подтверждение человеком» — то есть автоматизации нет. Теперь можно предложить среднее: человек подтверждает только то, где система сомневается, и доля таких случаев измерима.

Как это устроено в коде, на уровне, достаточном для продавца

Jev подключён к Pydantic AI — одному из распространённых каркасов для построения агентов. Разбираться в коде продавцу не нужно, но три вещи стоит знать, потому что они определяют сроки проекта.

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

Один вопрос — одно поле. Сама TypeSafe называет это самым важным правилом. Вместо «хорошее ли это предложение» нужно спрашивать отдельно: большой ли рынок, реализуемо ли технически, есть ли отличие от конкурентов — и складывать ответы обычным кодом. Составной вопрос не выдаёт ошибку: он возвращает правдоподобное число с низкой уверенностью, и вы узнаёте об этом сильно позже.

Порог «да» настраивается под цену ошибки. По умолчанию ответ округляется от половины — куда модель склонилась, то и вышло. Это разумно только там, где ошибиться в одну сторону стоит столько же, сколько в другую. Если ложное срабатывание дорогое, порог поднимают, и «да» приходится заслужить; если дорог пропуск — опускают. Это, пожалуй, единственный технический параметр, который продавцу стоит уметь объяснить: он напрямую про деньги клиента.

Отдельный приём, который хорошо ложится в коммерческое предложение: цепочка из двух моделей. Быстрая отвечает на всё, в чём уверена, а на запросах с низкой уверенностью автоматически подключается большая. Дешёвая делает объём, дорогая — остаток.

Где вендор преувеличивает — и что из заявленного проверяемо

TypeSafe в своём анонсе сама приводит оговорки к каждому графику, и это признак честности. Но в пересказах оговорки теряются первыми, поэтому разберём, что из громких цифр можно проверить, а что нет.

«В сто раз быстрее». Заявленное время ответа — от 70 до 500 миллисекунд против секунд и десятков секунд у больших моделей. Это проверяется собственным замером за один день, и это самая достоверная часть заявлений. Оговорка самой компании: их замеры сделаны с ноутбуков на западном побережье США, рядом с их же сервисом. Для Казахстана к этому добавится задержка сети, о которой стоит помнить.

«В четыреста раз дешевле». Цена входа заявлена как 0,042 доллара за миллион токенов против диапазона от 0,20 до 10 долларов у больших моделей, выход бесплатен. Цена прозрачна и проверяется. Но сама компания пишет, что не может доказать отсутствие субсидирования, и что устойчивость такой цены покажет только время. Закладывать её в трёхлетний расчёт для клиента я бы не стал.

Числа «в 193 раза быстрее, в 444 раза дешевле». Это результат их собственного испытания на рабочих сценариях. Оговорки, которые компания приводит сама: сценарии составлены её же командой, эталоном считается среднее из ответов двух больших моделей, и смещение возможно. Проверить это независимо нельзя. В предложении клиенту такие числа использовать не стоит — их проверят и спросят про методику.

«Ноль ошибок типа». Здесь честно: это не измерение, а математическая гарантия, и компания прямо пишет, что её ноль на графике не эмпирический. Утверждение сильное и корректное — но, повторим, оно про формат ответа, а не про его правильность.

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

Чего Jev не умеет, и это надо знать до предложения

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

Где взять и как это ложится в облачную архитектуру

Прямой доступ у TypeSafe пока по списку ожидания. Без ожидания модель доступна через несколько шлюзов-посредников, в том числе OpenRouter, где она появилась через три дня после анонса, — но вызывается там отдельной точкой входа, а не обычным интерфейсом чата.

И важная поправка, которую стоит держать в голове, если вы рисуете клиенту схему на AWS: этой модели нет в Amazon Bedrock. Она не является моделью Bedrock и не управляется через него. Работающая схема выглядит иначе: обращение приходит в шлюз, функция вызывает внешний интерфейс модели по сети, получает решение и дальше либо запускает готовый сценарий, либо идёт в Bedrock за большой моделью для формулировки ответа.

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

Что спросить у своего инженера перед встречей

1. Какие решения в сценарии клиента действительно типовые, и какую их долю можно снять маршрутизацией без большой модели?
2. Через какой канал мы получаем доступ, что записано про обработку данных и где они физически проходят?
3. Какие пороги мы предлагаем и на каких размеченных примерах клиента их калибруем?
4. Как выглядит запасной путь, если быстрый слой недоступен, — останавливаемся или уходим на большую модель?
5. Как мы измеряем, что связка работает: не только точность, но и доля запросов, ушедших на дорогую модель?

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

Красные флаги на стороне клиента

• Нет размеченных примеров. Пороги настраиваются на данных клиента. Без пары сотен разобранных случаев настройка превращается в угадывание, а результат — в спор об ощущениях.
• Ожидание, что это заменит большую модель. Не заменит: она не пишет текст. Это слой перед ней, и продавать надо именно так, иначе разочарование наступит на демонстрации.
• Никто не отвечает за разбор сомнительных случаев. Вся ценность схемы в том, что неуверенные ответы уходят человеку. Если такого человека нет, порог просто опустят, и мы вернёмся к автоматизации без контроля.
• Решение принимается по цене за запрос. Экономия на вызовах реальна, но основные затраты проекта — разбор сценариев, разметка и калибровка. Сравнение по прайсу уведёт разговор не туда.

Вопросы, которые задаст технический директор

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

«Что происходит, когда этот слой недоступен?» — про запасной путь. Хороший ответ: переключение на большую модель с деградацией по скорости и цене, а не остановка.

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

«Это компания какого возраста и что будет, если она закроется?» — лаборатория вышла из закрытой разработки в сентябре 2026 года. Вопрос справедливый; отвечать стоит через переносимость: тот же сценарий описан так, что может работать и на обычной модели — медленнее и дороже, но может.

Материал обновлён 30 сентября 2026

Отпечаток текста 29fea7ede645… · проверить подлинность