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

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

Честно говоря, после публикации я сам себе задал неудобный вопрос: а почему, собственно, 0.6? Почему не 0.5 или 0.7? И главное – уверенность модели и польза от эскалации – это не одно и то же. Можно быть очень неуверенным в вопросе, где ошибка ^[1] ничего не стоит. А можно быть уверенным на 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 ^[2] и сырые JSON в релизах.

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

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

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

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

Планы

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

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