Опубликовано 2 октября 2026 г.

Четыре decision-модели за неделю: Jev-класс вышел из тупика

Обновлено 3 октября 2026 г.

Темы: ai, llm, decision-models, routing, 243-fz

Джилл за рулём на перекрёстке: над тремя полосами зелёный, жёлтый и красный

Сводка

За неделю в открытых весах появились пять моделей одного класса: Cloudflare Clef и Clef-Flash, OmniJev OneJev (линейка 0.8B/4B/9B/27B), Frontier Infra Jebadiah (27B/9B/4B), RinggAI ringg-router-e2b и FRIDA-Decisions от ai-forever. Все они отвечают не текстом, а вероятностями по закрытому списку вариантов. Размеры - от 823 миллионов параметров до 27B, есть Apache-2.0 и MIT, есть запуск на llama.cpp, есть вариант на CPU без PyTorch.

Класс называют System One (по модели Jev от TypeSafe AI, вышедшей 15 сентября 2026). Ключевое отличие от обычной LLM: вместо генерации текста, который потом надо распарсить, модель выдаёт вероятность по каждому варианту каждого вопроса одним проходом. Калибровка при этом настоящая, а не softmax по буквам - в обучение входит Brier loss, штрафующий именно за неверную уверенность.

Что это меняет практически: узкое решение с закрытым списком вариантов перестаёт требовать большой модели. 0.8B справляется за 5 мс на вопрос, 9B - за 32 мс. Все крупные релизы показывают на своих бенчмарках результат на уровне Jev, при весе в 3-6 раз меньше.

Что такое decision-модель

Обычная LLM - собеседник. Ты пишешь, она думает и отвечает текстом. Дальше этот текст распаривается, из него вытаскивается нужное, и если модель забыла запятую или переименовала поле, всё развалилось.

Decision-модель - судья. На вход состояние дел (текст, JSON, картинка или видео) плюс схема типизированных вопросов. На выход - вероятность по каждому допустимому варианту каждого вопроса. Не текст.

Три типа вопросов, общих для всех моделей класса:

noul    - да/нет, возвращается вероятность "да"
choice  - выбор одного именованного варианта из N, плюс вероятности по всем
score   - оценка по упорядоченной шкале, вероятностно-взвешенная

Судье не нужно ничего сочинять. Ей не нужен длинный контекст, не нужна цепочка рассуждений, не нужен внятный стиль. Нужно одно - попасть в вариант. Это принципиально более простая задача, и решается моделью на порядок меньше. Отсюда и размеры от 0.8B: мы годами спорим, как запихнуть 30B в наш GPU, а для судьи 2B - вагон и тележка.

Технически устроено так. Бэкбон делает один проход в режиме prefill-only по состоянию и вопросам. Затем маленький трансформер - совместная схематическая голова - читает финальные скрытые состояния, роутит свидетельства к каждому вопросу, даёт полям перекрёстное внимание и скорит все варианты совместно. Softmax по каждому вопросу даёт вероятности.

У Clef обучение шло так: оба бэкбона заморожены, оптимизировалась только роутинговая голова плюс LoE ранга 256. Потери - перекрёстная энтропия со сглаживанием меток плюс Brier loss на калибровку. Вторичная цель RLCD даёт частичный зачёт соседним ординальным вариантам в score-вопросах.

Кто что выпустил

Cloudflare Clef и Clef-Flash

Первые модели от команды Workers AI. Clef - пост-тренинг Qwen3.8-27B, Clef-Flash - Qwen3.5-9B. У обоих сохранён vision encoder бэкбона, оба под Apache-2.0, оба совместимы с API Jev и SystemOne, оба уже крутятся на Workers AI (до 64 вопросов и до 4 картинок в одном запросе).

Переключение с Jev - смена эндпоинта и имени модели. Клиент Jev работает как есть.

GGUF от bartowski, llama.cpp b11279, imatrix:

Cloudflare_clef-flash-Q6_K    7.79 GB
Cloudflare_clef-flash-Q6_K_S  7.51 GB
Cloudflare_clef-flash-Q5_K_M  6.88 GB
Cloudflare_clef-flash-Q5_K_S  6.50 GB
Cloudflare_clef-flash-Q4_K_L  ~5.5 GB

Clef в 27B добавляется, но локально он крупный.

OmniJev OneJev

Тот же класс, но с акцентом на агентские сценарии. На вход скриншот, фото, видео или текст; полный файнтюн Qwen на 99 193 вопросах из реальных прогонов агентов, видео и картинок.

OneJev-0.8B    Qwen3.5-0.8B    2.2 GB
OneJev-4B      Qwen3.5-4B      10.4 GB
OneJev-9B      Qwen3.5-9B      18.8 GB
OneJev-27B     Qwen3.8-27B     54.7 GB
OneJev-27B-FP8 27B в 8-бит     30.4 GB

Задержка на одной H200, скриншот 1280x720:

OneJev-0.8B   31 мс на 1 вопрос, 51 мс на 10 вопросов (5.1 мс/вопрос)
OneJev-27B   189 мс на 1 вопрос, 324 мс на 10 вопросов (32.4 мс/вопрос)

Apache 2.0. Сервер qev говорит на System One API плюс поле media. Через llama.cpp из GGUF работает без PyTorch: картинки идут через mmproj, видео требует PyTorch-сервера.

Нюанс по квантам: GGUF от bartowski у 27B в семейной карточке нет, базовая репозитория указывает сборку mradermacher. То есть скачивать 27B надо не оттуда, откуда ожидаешь.

Frontier Infra Jebadiah

Третий экземпляр класса. Тоже вероятности по меткам вместо текста, те же три типа вопросов, сервер /v1/systemone. Обычная transformers-модель, обучена только на публичных данных. В версии 2 поменяли ровно одну вещь: база v1 была Qwen3.5-9B-Base, v2 - Qwen3.5-9B chat-чекпоинт с выключенным thinking. Данные, адаптеры, цель обучения и температурные фиты остались от v1. С 29 сентября для score-вопросов температура подогнана по фиту метки.

27B, 9B v2, 4B v2  (плюс предыдущий 9B v1)

Цифры автора, его собственный харнесс на публичных айтетах, не официальный борд: на JevBench v1.4.2 (231 публичный айтем) 9B v2 даёт 0.818, 27B - 0.866, столько же сколько Jev 1.13.0. На слепом тесте JDE (290 реальных решений из продакшн-движка Titanium Computing): 9B v2 - 277 верных против 282 у Jev, при 0 переключений на 5 800 повторных вызовов. Jev лучше на coverage-проверках. На Decision Index 0.2.1 версия 27B набирает 54.67, пятое место из 67 открытых моделей.

Автор советует для локального запуска начинать с Jebadiah 9B v2 GGUF, для Apple silicon есть MLX-сборки, для vLLM или дообучения - полные веса.

RinggAI ringg-router-e2b

Маленькая специализация: роутинг в голосовых агентах. 2B из gemma-4-E2B, только текст. Читает короткий диалог и список вариантов, отдаёт один JSON, где решение идёт первым:

{"branch": "<option id>", "extracted": {"<field>": "<value or null>"}}

Плюс причина в одно предложение. Поддерживает ветку "инструмент не подходит" и ответы да / нет / неизвестно.

Исходная задача - индийские языки и смешанная речь (хинди, хинглиш, бенгали, тамил, маратхи и другие). Набор бенчмарков и сама схема при этом универсальны. Обучающие данные: MASSIVE, Banking77, CLINC-OOS, Bitext, Open-Jev, jev-bench, jev-distill, tasksource-jev, typed-decisions-synth, IndicXNLI, BoolQ-Indic, MultiNLI, e-SNLI, ECQA, Naamapadam, HiNER, MultiCoNER v2, SGD, MASSIVE-Agents, BFCL-Hi, ToolACE, Hermes JSON mode, xLAM irrelevance, X-RiSAWOZ, IndicQA.

FRIDA-Decisions от ai-forever

Пятый экземпляр класса, и единственный с русским языком внутри. Это не файнтюн Qwen, а отдельная ветка: T5-энкодер FRIDA на 823 миллиона параметров, файнтюн под задачу. Лицензия MIT, языки ru и en.

Отличия от остальных важны практически.

Варианты не смотрят друг на друга по построению. Опции не внимают друг другу, поэтому добавление, удаление или перестановка варианта не меняет отступы остальных. Это ровно тот пункт, который в проверке decision-моделей стоит первым в списке граблей, и здесь он закрыт конструкцией, а не тюнингом.

Каталог на 243 интента - один запрос. Все вопросы и все их варианты лежат рядом с одной копией текста, и текст кодируется один раз. При точном кэше состояния последующий вопрос про тот же текст стоит только своих токенов. Замер: 0.44 секунды на каталог из 243 интентов против 4.65 секунды, если делать отдельную последовательность на каждый вариант.

Два бэкенда, включая CPU без PyTorch. PyTorch на GPU или CPU плюс int8-сборка ONNX для CPU без torch. Ядру хватает numpy, tokenizers, safetensors и huggingface_hub.

Русский бенчмарк и честное сравнение с коммерческим API. На датасете razvilka (735 айтемов) FRIDA-Decisions даёт 0.893. TypeSafe Jev на тех же айтемах даёт 0.897 - парный тест McNemar даёт p, равный 0.84, то есть разницы нет. Это второй результат из всех открытых моделей, которые авторы гоняли на этом наборе.

Метры.

задержка              28-34 мс на запрос на RTX 5060 Ti
                      (текст ~400 токенов, 1-3 вопроса, внутри процесса)
память               1.8 ГБ, выделено PyTorch на пике всего прогона
int8 ONNX на CPU     0.891 на razvilka - то же решение, что GPU-модель на 726 из 735
                      384 токена и 3 вопроса - около 0.9 с на 6 потоках CPU,
                      примерно в 2.5 раза быстрее fp32

Набор razvilka собран из публичных источников с русской разметкой: MASSIVE intent, и наряду с choice-задачами там есть type, score и noul. Лицензии исходников - CC-BY-4.0 и подобные, то есть набор открытый и его можно прогнать на своей разметке.

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

Бенчмарки, честно с обеих сторон

Cloudflare на своём шортлисте из 10 бенчмарков Decision Index 0.2.1 набрал высший результат по семи:

BANKING77 macro-F1       Clef   94.20   Jev  79.74
CLINC150+OOS macro-F1    Clef   97.43   Jev  89.27
Home appliances          flash  97.73   Jev  52.27

Но Jev держит явный отрыв на общих знаниях, и это важно понимать при проектировании:

GPQA Diamond    Jev  78.3   Clef  48.0
MMLU-Pro        Jev  82.7   Clef  65.9
BBH             Jev  92.9   Clef  73.7

На workflow-эвалах TypeSafe Clef выиграл 3 из 4 областей с небольшим отрывом: обработка счетов 64.7 против 61.8, поддержка клиентов 76.3 против 76.0, инциденты безопасности 62.9 против 61.7. Jev лучше на наблюдаемости трасс агентов: 71.6 против 68.5.

Вывод, который из этого следует: Clef не замена генеративной модели на всё. Это замена классификатора. Если задача укладывается в "выбери вариант, да или нет, поставь оценку", то 9B Flash с настоящей калибровкой вместо промпта с последующим разбором JSON - прямая экономия.

Про FRIDA-Decisions сравнение отдельное, потому что бенчмарк другой: razvilka, 735 русских айтемов, Jev как платный API.

razvilka (735 айтемов)   FRIDA-Decisions  0.893   TypeSafe Jev  0.897
                         разница не значима, парный McNemar p = 0.84

Разница между 0.893 и 0.897 при p, равном 0.84, означает, что на этом наборе модели неразличимы. Формулировка авторов точная: лучший результат среди открытых моделей, которые они гоняли. Не "лучше Jev", а "на уровне Jev при 823 миллионах параметров, MIT-лицензии и запуске на CPU".

Где это применяется

Разложить входящие по кучкам

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

Голосовое меню вместо IVR

"Вас беспокоит бухгалтерия" - дальше набрать 2, 3 или соединить с оператором. Классический сценарий Ringg. Такого бота обычно строят на большой модели, а тут 2B.

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

Проверка "задача закрыта или нужен ещё шаг"

Вот это самое интересное. Агент кликнул, получил результат, надо решить: работа закончена или нужен ещё шаг. Если это гонять на основной модели, мы платим за рассуждение на каждом шаге цикла. Отдельный слой с двумя вариантами done / next решает задачу за десятки миллисекунд.

Один практический пример для QA: агент работает с тестовым стендом. После каждого действия слой решает - это цель достигнута, продолжать или стоп. Экономим и токены, и главное - время цикла, потому что короткие решения отсекаются до обращения к большой модели.

Фильтр перед дорогим разбором

Скриншот ошибки: это известный баг, это наша зона или пользовательская, это вообще не про нас. Практический фильтр: дешёвая проверка решает, стоит ли вообще тратить разбор.

Для DevOps/SRE: классификация алярмов. Из потока алертов в тикет идут не все, а только те, что попали в класс "нужен человек". Ошибка роутера стоит дешево: лишняя карточка в очереди, а не непрочитанный инцидент.

Оценка срочности и приоритета

"Насколько этот тикет срочный, 1-5" - тип score, шкала упорядочена, поэтому соседние баллы получают частичный зачёт. Для менеджера продукта это готовая сортировка бэклога: модель не выдумывает обоснование, а раскладывает входящие по шкале, и дальше человек решает верхний срез.

Понять, что инструмент не подходит

Отдельная ветка "ничего не подходит". Нужна, чтобы агент не хватался за инструмент не по делу. Ringg выделяет это отдельным классом в обучающих данных, и это правильно: без такой ветки агент склонен придумывать применение.

Модели до фильтра: почему размер перестал быть техническим вопросом

Вчера я разбирал запись к врачу и писал, что в этой задаче важен не размер модели, а то, ниже или выше она упадётся под порог 243-ФЗ. Статья 3 пункт 2 определяет большую фундаментальную модель как программу, содержащую не менее миллиарда параметров и применяемую для выполнения большого количества различных задач. Миллиард. Много разных задач.

Там был вывод, что стек на сто миллионов параметров живёт вне 243-ФЗ: Whisper base на уши, rubert-tiny2 на мозг, стейт-машина на логику. Ноль параметров на принятие решения о том, нужен ли пациенту очный приём.

Теперь посмотрите на этот порог с другой стороны. Он перестал быть границей, за которой начинается ферма, и стал границей между двумя правовыми контурами. Модели до миллиарда параметров снаружи. Модели от миллиарда внутри, со статьями 9 и 10 и обязательствами с 1 марта 2027 года.

FRIDA-Decisions          ~0.82 млрд русский, MIT, ONNX int8 на CPU
OneJev-0.8B              ~0.8 млрд  снаружи 243-ФЗ
ringg-router-e2b         ~2 млрд    внутри
clef-flash               ~9 млрд    внутри
Clef                     ~27 млрд   внутри
Jebadiah 27B             ~27 млрд   внутри

Про первый параметр оговорка. Название модели и её база указывают на 0.8 миллиарда, карточка на HuggingFace округляет размер до 1B. Формально под порогом она или ровно на пороге - зависит от того, как считать, и определять это должен юрист, а не инженер. Но разница между 2 и 9 миллиардами в этом смысле уже ничего не даёт: обе строки внутри, и обе несут статьи 9 и 10.

С FRIDA-Decisions в таблице появляется строка, которая меняет разговор. 823 миллиона параметров - это не файнтюн большой модели, а отдельный энкодер, и по массе он ближе к rubert-tiny2 из вчерашней статьи, чем к чему-либо из остального списка. Плюс MIT вместо Apache-2.0, плюс запуск на CPU без PyTorch. То есть модель, которая внешне и по режиму работы ближе всего к тому, что в медицинском сценарии и так считается беспороговым.

Разница между крайними строками таблицы - в бенчмарках меньше, чем в юридических обязанностях. И это меняет то, как принимается решение о выборе. Инженер выбирает по железу и по скорости. Юрист читает тот же выбор как выбор правового контура. И раньше эти два человека выбирали разное, а теперь они смотрят на один и тот же экран выбора модели.

Полная аргументация по медицинской части - в статье про запись к врачу.

И тут видно, почему размер перестал быть техническим вопросом. Для экрана смартфона 0.8B и 9B различаются втрое по весу и в десяток по задержке. Для статьи 3 пункта 2 это переход через границу, за которой начинаются маркировка материала и уведомление о правах на результат интеллектуальной деятельности. Один и тот же выбор, прочитанный двумя разными профессиями.

Почему это окупается в быту

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

Решение принимается тысячи раз в день. Одна настройка вместо промпта - и вся линия обслуживания работает на 2B. Экономия тут меняет порядок величины, а не процент.

Порог становится осмысленным. Вот здесь главное. Когда вы применяете правило "если уверенность выше 0.8 - действовать, ниже - спросить человека", вам нужна калиброванная вероятность. Не "какая буква вылезла", а честная вероятность. Обычная LLM, разбитая softmax по буквам, эту честность не даёт: она покажет 0.95 и ошибётся. Decision-модели тренируют именно на это, ошибка Brier штрафует за неверную уверенность отдельно от неверного выбора. Отсюда у Ringg ноль переключений на 5 800 повторов.

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

Что выбрать под наш железо

Всё, что помещается в карту и приносит пользу:

FRIDA-Decisions               823 M   русский текст, MIT, ONNX int8 на CPU
OneJev-0.8B                   2.2 GB  обучен на реальных агентских прогонах
Cloudflare_clef-flash-Q5_K_M 6.88 GB  лучший на узких бенчмарках
Cloudflare_clef-flash-Q4_K_L  ~5.5 GB то же, меньше памяти
Cloudflare_clef Q4_K_M        ~15 GB  27B, если позволяет карта
Holo4-35B-A3B Q4_K_M          22.32 GB другой класс, про computer use ниже
Jebadiah 9B v2 GGUF                     автор прямо советует как старт
RinggAI ringg-router-e2b        2B      роутинг голосовых агентов

Мой порядок проверки изменился с появлением FRIDA-Decisions. Первым теперь он, потому что у него есть то, чего нет больше ни у кого: русскоязычный открытый набор razvilka из 735 айтемов и честно опубликованное сравнение с платным Jev. Значит, его можно проверить на наших задачах, не выдумывая разметку, и сразу понять, чего не хватает в наших данных. Плюс 823 миллиона параметров - это проверка на любой машине, включая CPU без видеокарты.

Вторым clef-flash, потому что он выигрывает на англоязычных бенчмарках. Разница между этими двумя покажет, русский это перевод или полноценная работа с языком.

OneJev-0.8B переезжает на третье место: он обучен на реальных агентских прогонах с картинками, и это закрывает то, что FRIDA-Decisions не закрывает, - мультимодальность.

Чего эти модели не умеют

Свободного текста эти модели не дают в принципе. Если задача требует объяснить клиенту, почему его обращение отклонили, - это уже не сюда.

Общие знания - слабое место Clef против Jev. GPQA Diamond 48.0 против 78.3. Не стоит навешивать на decision-модель задачи, где нужен эрудированный ответ, даже если вариантов ответа несколько.

Видео в llama.cpp не работает. OneJev прямо это указывает: через GGUF идут картинки, видео требует PyTorch-сервера. Проверять надо путь mmproj в конкретном раннере, а не наличие мультимодальности в базовой архитектуре.

Карточки GGUF для decision-моделей врут шаблоном. У bartowski для clef-flash приклеен обычный чат-шаблон с инструкцией по вызову инструментов - Clef её вообще не использует. Не пугайся, увидев такое: это артефакт автоматической генерации карточек.

Как проверять

Общий лидерборд у класса один: Decision Index. Jebadiah автор честно пишет про свои цифры как про собственный прогон на публичных айтетах, а не официальные строки борда.

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

Что мерить обязательно:

доля валидного вывода          отдельно от смысловой точности
смысловая точность            top-1 метка против человеческой
калибровка                    reliability-диаграмма или ECE на удержанной разметке
задержка                      на своём железе, не на H200 из карточки
перестановка вариантов         меняется ли выбор при смене порядка опций

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

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

Рядом, но из другой оперы

Holo4 от H Company - это не про решения, а про управление компьютером. Визуально-языковая модель для computer use, MoE на Qwen3.6-35B-A3B с контекстом 262 144 токена, работает с харнессом hai-agents: скриншоты и результаты инструментов на вход, клики и вызовы на выход. Отдельно задокументированы вызов функций, локализация элементов и распознавание документов. Линейка: Holo4-27B (плотная), Holo4-35B-A3B (MoE), Holotron4-30B-A3B (NemotronH Nano Omni).

Бенчмарки у них своя метрика - стоимость задачи:

OSWorld        Holo4-27B  85.2%  при $0.08
OSWorld 2.0    Holo4-27B  61.7%  при $1.22
OSWorld 2.0    Holo4-35B-A3B 30.9% при $0.61
AutomationBench Holo4-27B 45.4%  при $0.05
AutomationBench Holo4-35B-A3B 34.5% при $0.02

Выбор между ними не вопрос размера. На OSWorld выигрывает плотная 27B, на AutomationBench MoE в 2.5 раза дешевле при 76 процентах качества. Все агентные траектории выложены в открытый датасет, можно заранее посмотреть, где именно модель падает.

bytkim Qwen3.8-27B-pi - файнтюн Qwen3.8-27B под агентный цикл в харнессе Pi: чтение репозитория, правка файлов, запуск инструментов, разбор обратной связи. Плюс GRPO-стадия с наградой за экономию рассуждения. Заявленная метрика: на среднем уровне даёт тот же процент завершения, что база на максимальном, но примерно на 41 процент меньше токенов ответа. Для нас это прямо экономия в агентной работе с кодом.

TheDrummer Artemis-31B-v1.2 - тюн Gemma 4 31B, формально творческий, но карточка отдельно хвалит рабочие качества: think-блок вытаскивает верные детали, следование сценарию держится на 20k, нет протекания персон между картами примерно на 32k, вызовы инструментов и общее применение работают. Автор пишет, что запускает на q3ks с нейтральными сэмплерами.

FAQ

Если хочется понять, брать ли это вообще: сначала найдите в своих задачах узкое решение со списком вариантов. Если таких нет - не берите, генеративная модель справится.

Если планируешь быстрый роутер для агента: берите 2B. Ringg или аналог, скорость в единицы миллисекунд, ошибка дешёвая.

Если планируешь экранный агент: берите OneJev. Обучен на реальных прогонах агентов с изображениями, 2.2 GB у версии 0.8B.

Если планируешь классификацию с большим списком классов: смотрите BANKING77 в бенчмарках выше, там 77 вариантов и по этой задаче виден разрыв.

Если хочется голосового агента: 2B достаточно, но проверьте на своих языках - индийские языки в обучающих данных Ringg это достоинство модели, а не универсальность.

Если задача на русском тексте и нет видеокарты: FRIDA-Decisions в int8 ONNX на шести потоках CPU, около 0.9 секунды на 384 токена с тремя вопросами, и качество падает с 0.893 до 0.891.

Если задача на русском и нужен быстрый сменный набор меток: у FRIDA-Decisions новый набор вариантов - это новый JSON в запросе, без переобучения.

Если планируешь оценку по шкале: помните, что score и choice - это разные типы вопросов, и для упорядоченной шкалы модель может давать частичный зачёт соседним баллам при обучении с RLCD.

Если планируешь объяснения клиенту: это не сюда, здесь нужен генеративный слой поверх.