decision-cascade месяц спустя: от порога уверенности к экономике решения

В прошлый раз я писал о том, что decision-cascade - это локальный движок решений с типизированными ответами (Noul/Choice/Score) и каскадом, который эскалирует сложные случаи к внешней модели. Тогда главным критерием эскалации был порог уверенности: если confidence ниже 0.6 - идём во внешнюю модель.

Честно говоря, после публикации я сам себе задал неудобный вопрос: а почему, собственно, 0.6? Почему не 0.5 или 0.7? И главное - уверенность модели и польза от эскалации - это не одно и то же. Можно быть очень неуверенным в вопросе, где ошибка ничего не стоит. А можно быть уверенным на 0.8 - и ошибиться там, где ошибка обойдётся дорого.

Именно это понимание привело к главному изменению за месяц: benefit-aware эскалация.

Что такое benefit-aware и зачем это нужно

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

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

В коде это выглядит как отдельный режим, но по сути это смена парадигмы: от «модель решает, когда она права» к «система решает, когда стоит платить за уточнение».

Демо-игры: проверка в среде с последствиями

Синтетические бенчмарки - это хорошо, но они не отвечают на вопрос «а работает ли это там, где ошибка имеет цену». Поэтому я добавил две игры - шахматы против Stockfish и лабиринт в духе Pac-Man. Обе полностью локальные, без сторонних ассетов.

В шахматах 19% эскалаций закрывают половину разрыва до «всегда думать глубоко», при 38% стоимости полного просчёта. В лабиринте осторожная политика набирает 94% очков при 33% эскалаций - вдвое больше, чем жадная стратегия. Это не значит, что движок стал шахматным гроссмейстером. Это значит, что benefit-aware каскад работает в условиях, где решение имеет реальную цену, а не только метрику accuracy.

Реальные конкуренты, реальные цифры

В прошлой статье я приводил цифры на AG News. Сейчас добавились бенчмарки против живых релизов Clef-Flash (9.4B) и Laya (421M) на публичных наборах, n=200, одна GPU 16 ГБ.

Маленькая локальная модель с обученными головами обходит 9B-конкурента по качеству на decision-задачах и в 10 раз быстрее. Это не значит, что Clef плохая - на свободной генерации она выиграет легко. Но на задачах принятия решений каскад даёт другую экономику.

Все цифры воспроизводимы: eval/competitors/reproduce_real.sh и сырые JSON в релизах.

Стабильный контракт и PyPI

Ещё одно изменение, которое не так заметно, но важно для тех, кто рассматривает проект для интеграции: версия 1.x теперь имеет стабильный контракт. Формат паков и переменные DECISION_* не ломаются без major-версии и окна депрекации. Плюс проект опубликован на PyPI - pip install decision-cascade - и имеет быстрый старт на hash-энкодере без скачивания моделей и без GPU за пару минут.

Что осталось честно сказать

Проект стабильный, но по умолчанию головы случайны - осмысленное качество требует SFT/RLCD или скачивания готового пака весов. Риск-модель полезна только после накопления примеров. Доменная калибровка под ваш сценарий - отдельная задача. Это не «магия из коробки», а инфраструктура, которая окупается, когда вы на неё накатите свои данные.

Планы

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

Репозиторий: https://github.com/slavabars/decision-cascade