В прошлый раз я писал о том, что 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 ГБ.
Набор
decision-cascade 124M
Clef-Flash 9.4B
Laya 421M
AG News — accuracy
0.873
0.855
0.662
AG News — p50
10 мс
130 мс
16 мс
RouterBench — accuracy
0.542
0.442
0.312
RouterBench — p50
21 мс
170 мс
—
Маленькая локальная модель с обученными головами обходит 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
Источник: habr.com