RLCD: объяснение — почему TypeSafe учит Jev быть честным насчёт уверенности, а не нравиться

Jev 1.13 (typesafe/jev-1.13) обучается с помощью метода, который его создатель называет Reinforcement Learning for Calibrated Decisions — RLCD, — и эта аббревиатура придумана самой TypeSafe, а не является отраслевым термином, который вы должны уже знать. В посте о запуске прямо сказано: компания создала «новую архитектуру модели, параллельный сэмплер для максимальной эффективности и метод обучения, который мы называем Reinforcement Learning for Calibrated Decisions (RLCD)». Это третий ответ на вопрос, у которого раньше было два, и причина его существования — несоответствие, с которым большинство команд сталкивается, впервые пытаясь поместить языковую модель внутрь процесса принятия решений. Прежде чем перейти к нему, важны две даты, потому что эта страница — не материал о запуске. TypeSafe выпустила саму модель 2026-09-15, что выходит за пределы семидневного окна, для которого пишет этот блог, и ничто здесь не следует воспринимать как представление Jev в качестве новинки. Датированное событие — 2026-09-24, когда OrcaRouter добавил typesafe/jev-1.13 в собственный каталог и открыл для него карточку модели — впервые Jev можно вызывать через сторонний шлюз, а не только через собственный эндпоинт TypeSafe. Именно на этом изменении и строится эта страница, а практическое следствие состоит в том, что описанный ниже приём теперь можно попробовать в коде с ключом, который у вас, возможно, уже есть, а не просто прочитать о нём как об исследовательской идее.

То, что следует далее, — это концепция, а не модель. Первая треть этой страницы посвящена двум методам обучения, против которых был задуман RLCD, потому что RLCD становится понятным только как исправление того, что делают эти два, когда задача перестаёт быть разговором и становится суждением. Если вы уже знаете, на что оптимизированы RLHF и RLVR, нужный вам раздел — третий, где работает собственная трёхсторонняя таблица TypeSafe.

RLHF оптимизирует ответ, который предпочитает человек

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

Простой способ увидеть это несоответствие — задаться вопросом, что на самом деле измеряет сигнал вознаграждения. В рамках RLHF он измеряет предпочтение оценщика между двумя вариантами ответа. Это превосходный прокси-показатель, когда продукт — это беседа, потому что критерий успеха беседы действительно состоит в том, считает ли человек ответ хорошим. Это сломанный прокси, когда продукт — это решение, потому что критерий успеха там — соответствует ли заявленная уверенность реальности, а оценщик, сравнивающий два правдоподобных абзаца, никак не может увидеть разницу между хорошо откалиброванной 0,6 и уверенно звучащей 0,95. Два ответа могут быть одинаково предпочтительны и при этом колоссально различаться в том, насколько та или иная программа должна им доверять.

Режимы отказа, которые TypeSafe называет во вводном руководстве, напрямую вытекают из этого:

• Подхалимство — модель учится выдавать то, что хочет услышать оценщик, а это цель, отличная от истины.

• Уверенно звучащая галлюцинация — беглость и уверенность вознаграждаются предпочтением, даже когда они ничем не подкреплены.

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

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

RLVR оптимизирует под выходные данные, которые может проверить программа, — а у решений такие данные есть редко.

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

Ограничение заключается в самой форме слова «верифицируемый». Верифицируемая награда требует верификатора, а верификатор требует, чтобы у задачи был правильный ответ, который кто-то может вычислить. Возьмите вопросы, которые на самом деле задаёт продакшн-система. Этот тикет поддержки должен попасть в биллинг или в технический отдел? Соответствует ли этот запрос на возврат политике? Выглядит ли эта транзакция как мошенничество? У каждого из них в большинстве случаев есть ответ, который можно обосновать, но ни у одного нет ответа, который программа может проверить, а самые важные случаи — это именно те, где опытные люди расходятся во мнениях. Нет функции, которую можно запустить. RLVR нечего вознаграждать, поэтому он ничего не даёт.

Соблазнительный обходной путь — создать верификатор, разметив набор данных и обучив модель на этих метках. Это даёт методу материал для работы, но меняет целевую функцию так, что это важно. Метки кодируют решение, а не неопределённость вокруг него. Модель, обученная воспроизводить суждения одной команды на сложных случаях, учится быть настолько уверенной, насколько уверенными были эти метки, — то есть ровно настолько самоуверенной, насколько самоуверенны были люди, которые их писали. И даже там, где настоящий верификатор действительно существует, есть второй разрыв. Верификатор оценивает ответ. Он не оценивает заявленную уверенность. Модель, которая права в 95% случаев и сообщает об уверенности во всех них, получает идеальную награду и, как компонент автоматизированного пайплайна, бесполезна — потому что 5% — это единственная часть, о которой пайплайну нужно было сообщить. Материалы запуска TypeSafe проводят ту же мысль с другой стороны: «Если модель справляется с задачей в 95% случаев, но не говорит, когда она попадает в эти 5%, она не может автоматизировать эту задачу».

Что делает RLCD, в формулировке самой TypeSafe

RLCD меняет контракт вывода, а не качество ответа. В карточке праймера сказано: «Обучение с подкреплением для калиброванных решений учит TypeSafe возвращать решения и калиброванные вероятности вместо сгенерированного текста». Краткая версия из поста о запуске: «калиброванные решения: ответы с эпистемически честными вероятностями в задачах System One». Оба описывают один и тот же ход: обучать модель, ориентируясь на то, совпадала ли заявленная ею вероятность с частотой, с которой этот ответ оказывался правильным, а не на то, понравился ли ответ человеку или проверяющему.

В посте о запуске три метода сопоставлены рядом, и это противопоставление — самая ясная из существующих формулировок этой идеи. Читайте это как набор контрастов, а не как таблицу:

• Что оптимизируется — RLHF оптимизирует человеческие предпочтения, «тексты и ответы в чате, которые предпочитают оценщики-люди»; RLVR оптимизирует «выходы, которые можно проверить программно»; RLCD оптимизирует калибровку, «ответы с эпистемически честными вероятностями в задачах Системы 1».

• Что поступает на вход — две более старые модели принимают неструктурированные данные «с акцентом на сообщения»; калиброванная модель принятия решений принимает неструктурированные данные «с акцентом на структурированное состояние программы».

• Что получается на выходе — сгенерированные строки, которые «нужно парсить + валидировать», при том что «всегда есть некоторый риск, что ИИ сойдёт с рельсов», в отличие от типобезопасных структурированных значений, где «возможные выходные данные и структура определены заранее», модель «никогда не допускает ошибок типов», а «все ответы сопровождаются калиброванными вероятностями и оценками уверенности».

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

• Сколько это стоит — входные токены от $0,20 до $10 за миллион у сравниваемых моделей, при этом вывод стоит примерно в пять раз дороже ввода, против $0,042 за миллион входных токенов с нулевой оплатой вывода у Jev.

• Насколько быстро он отвечает — от 3 до 329 секунд от начала до конца у передовых моделей против 70 мс–500 мс, что поставщик характеризует как в 40–200 раз быстрее на запросах, построенных по образцу System One.

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

Последняя строка — это и есть фактическое утверждение о продукте, и оно опровержимо так, как остальные — нет. «Более высокая уверенность означает более высокую точность» — это утверждение о кривой: разбейте ответы модели на корзины по вероятности, которую она им присвоила, и эти корзины должны оказываться верными примерно с той частотой, которую заявляют вероятности. В документации TypeSafe по уверенности этот контракт изложен с необычно конкретными числами:

• Исходы, которым присвоена вероятность 0,2, должны происходить примерно в 20 % случаев.

• Исходы, которым присвоена вероятность 0,8, должны происходить примерно в 80% случаев.

• Исходы, которым присвоена вероятность 1.0, должны происходить в 100% случаев.

А затем — фраза, которая сохраняет это утверждение честным, словами самого вендора: «Эти показатели описывают группы прогнозов, а не являются гарантией в отношении какого-либо отдельного ответа». Это не оговорка, прикрученная из юридических соображений. В этом весь смысл калибровки. Хорошо откалиброванная модель, которая говорит 0,8, не обещает быть правой на этот раз; она обещает, что среди всех ответов, которые она пометила как 0,8, около четырёх из пяти были правильными. Один ответ вам ничего не говорит. Тысяча ответов за неделю говорит вам, реальна ли эта кривая.

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

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

Почему именно калибровка делает дешёвую модель принятия решений пригодной к использованию

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

• Высокая уверенность — действуйте автоматически. У модели есть чёткое понимание, и вы можете продолжать без участия человека.

• Средняя уверенность — действуйте с осторожностью. У модели есть разумный ответ, но она не уверена, поэтому уточните у пользователя, пометьте для проверки или соберите больше информации, прежде чем действовать.

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

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

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

Есть вторая причина, по которой это важнее для дешёвой модели, чем для дорогой, и именно поэтому история маршрутизации и история RLCD — это одна и та же история. Модель по цене $0,042 за миллион входных токенов без платы за выходные токены достаточно дешева, чтобы обращаться к ней постоянно — на каждом шаге цикла агента, на каждой записи в пакете, по каждому тикету по мере его поступления. Постоянное обращение к модели — это именно та ситуация, в которой ошибки модели накапливаются, потому что никто не читает её вывод, прежде чем на его основании начинают действовать. Именно уверенность делает это безопасным. Именно дешевизна делает ветку эскалации доступной по цене, поскольку дорогой путь запускается лишь для той доли случаев, от которых отказалась дешёвая модель. Ни одна из половин не работает без другой, а решение о маршрутизации, которое их соединяет, — это порог по числу, причиной верить в которое служит RLCD.

Честный предел: откалиброванный — не значит правильный

Самое важное, что нужно правильно понять про RLCD, — это то, чего он не обещает. Калибровка — свойство уверенностей, а не гарантия правильности ответов, и поставщик говорит об этом в собственной документации, а не оставляет это на усмотрение критиков. На странице System One: «Модели System One обучены принимать калиброванные решения: их вероятности оптимизируются по результатам, чтобы отражать неопределённость. Калибровка измеряется по группам прогнозов; она не гарантирует, что отдельный ответ верен». Модель может быть идеально калиброванной и всё равно ошибиться по вашей заявке, потому что 0,9 означает девять из десяти, а это может быть десятый случай.

Наши собственные эксплуатационные показатели служат здесь полезным противовесом — именно потому, что это измерения модели в проде, а не утверждения о том, чего достигает метод. За семь дней, заканчивающихся 2026-09-30, по трафику через плейграунд OrcaRouter с момента добавления модели в каталог карточка Jev 1.13 сообщает об уровне ошибок 0,49% на 76,2 млн токенов, а также p50 времени до первого токена 151 мс, p95 — 247 мс и около 349 выходных токенов в секунду. Два момента в этом числе стоит сказать прямо. Оно наше, а не вендора, и это скользящее окно, а не фиксированный тестовый набор — то же поле показывало 0,57% ранее в этом окне, потому что оно пересчитывается по последним семи дням живого трафика, а вчерашние вызовы выпадают. Это также не измерение калибровки. Уровень ошибок говорит, как часто на нашем трафике что-то шло не так; он не говорит, были ли значения уверенности честными, — это другой вопрос, и для ответа на него нужны размеченные данные.

Что также является практической инструкцией, которую даёт поставщик в примечании к своим рекомендациям по пороговым значениям: «Правильные пороговые значения зависят от вашего домена и производительности модели для вашего сценария использования. Начните с консервативных порогов, протестируйте на своих данных и корректируйте их по мере наблюдения за результатами». RLCD — это утверждение о том, как обучали модель. Выполняется ли это утверждение на ваших входных данных — эмпирический вопрос, и это одно из немногих свойств модели, которое можно проверить без какой-либо инфраструктуры машинного обучения — возьмите несколько сотен случаев, для которых у вас уже есть метки, разложите ответы по корзинам в зависимости от уверенности, которую сообщила модель, и проверьте, верны ли корзины с той частотой, которую они заявляют. Если корзина 0,9 верна примерно в 90% случаев на вашем трафике, порог реален, и вы можете автоматизировать всё выше него. Если всё скапливается выше 0,9, а точность не соответствует, вы узнали нечто более полезное, чем любое громкое число.

Ещё два ограничения уместно назвать сразу же. Первое: для этой модели нет публичной карточки бенчмарка, по которой можно было бы всё это проверить, — вендор её не опубликовал, и ни одна сторонняя таблица лидеров не включает эту модель; страница модели на Artificial Analysis по состоянию на 2026-09-30 возвращает 404. Так что аргумент о калибровке опирается на описание обучения, задокументированный контракт и на то, что вы измерите сами, а не на опубликованную кривую. Второе: заявления вендора о производительности — это его собственные заявления: в посте о запуске открыто отмечается, что оценки рабочих процессов, лежащие в основе главных цифр о скорости и стоимости, были построены его командой по возможностям модели, что эталонные ответы, с которыми их сравнивают, представляют собой среднее двух внешних моделей, и что эти числа «на верхней границе реальных улучшений». Там также говорится, что невозможно доказать, что цены не субсидируются. Ничто из этого не подрывает метод обучения, который является отдельным утверждением от утверждения о скорости, но это означает, что довод в пользу RLCD — это аргумент о проектировании целевой функции, а не устоявшийся эмпирический результат. Относитесь к этому как к гипотезе, которую можно дёшево проверить, — это более выгодная позиция, чем та, в которой вас оставляют большинство заявлений о методах обучения.

Что вы можете сделать с этим сегодня

Обе части аргумента сходятся в одной точке. RLCD — это причина, по которой уверенность модели принятия решений стоит того, чтобы от неё ветвить; порог в вашем коде — это место, где живёт эта ветвь; а эскалация обходится дёшево только тогда, когда общий путь достаточно дешёв, чтобы выполняться везде. Jev 1.13 вызывается как typesafe/jev-1.13 на OrcaRouter — один API для 200+ моделей, 0% наценки, прайс-лист провайдера передаётся как есть, поэтому снижение цены поставщиком действует здесь в тот же день — а значит, путь уверенного большинства и путь генеративной эскалации тарифицируются по одному ключу, а не по двум контрактам с вендорами. Вы по-прежнему вызываете его в его собственной форме, POST /v1/systemone, без стриминга, в контексте на 65 536 токенов, потому что это не маршрут chat-completions от OpenAI и он не встроен в chat-эндпоинт. Две датированные заметки из релизов SDK вендора стоит знать, если вы это подключаете: версия 0.7.1, выпущенная 2026-09-21, добавила примеры использования с AI-шлюзами, а версия 0.7.2, выпущенная 2026-09-26, добавила extra http2 в пакет для Python. Вторая — это та деталь, которая всплывает только в примечаниях к релизу: HTTP/2-клиент стоит иметь для модели, чьё основное ценностное предложение — круговые задержки менее 200 миллисекунд.

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

Ещё один последний фрагмент картины стоит держать рядом со всем этим, потому что это то число, на которое направлен весь аргумент, и оно измерено, а не заявлено. Карточка ниже — это наш собственный семидневный журнал обслуживания для typesafe/jev-1.13 — модели в реальной работе, а не метода обучения и не бенчмарка. Читайте это как вторую половину вопроса о калибровке: значения уверенности говорят, на какие вызовы реагировать, а это говорит, насколько остальная часть решения о маршрутизации близка к системе, которую вы оставили бы без присмотра.