decision-cascade учит локальную модель считать цену ошибки до вызова внешней LLM

Знакомая история: вы строите систему с маленькой локальной моделью и большой внешней. Простая схема маршрутизации выглядит так: если локальная модель не уверена, отправляем запрос в облако. Порог обычно берут с потолка, скажем 0.6. Автор проекта decision-cascade через месяц после первой публикации задал себе неудобный вопрос: а почему именно 0.6?

Почему порог уверенности — плохой критерий

Уверенность модели и польза от эскалации — разные вещи. Можно сомневаться в ответе, где ошибка ничего не стоит: например, выбрать один из двух равнозначных вариантов. Платить за внешний вызов там бессмысленно. А можно быть уверенным на 0.8 и ошибиться в месте, где цена промаха высока. Порог такие случаи не различает.

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

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

Что показали демо и бенчмарки

Автор проверил подход в двух локальных играх, где у решений есть последствия. В шахматах против Stockfish 19% эскалаций закрывают половину разрыва до режима «всегда думать глубоко», а стоят 38% от полного просчёта. В лабиринте в духе Pac-Man осторожная политика набирает 94% очков при 33% эскалаций, это вдвое больше жадной стратегии. Гроссмейстера из движка никто не делает. Смысл в другом: экономика эскалации работает там, где решение имеет цену.

Отдельно есть сравнение с двумя «живыми» моделями, Clef-Flash (9,4B) и Laya (421M), на публичных наборах. Условия: n=200 и одна GPU на 16 ГБ.

• AG News, точность: 87,3% у decision-cascade (124M), 85,5% у Clef-Flash, 66,2% у Laya.
• AG News, медианная задержка: 10 мс против 130 мс у Clef-Flash и 16 мс у Laya.
• RouterBench, точность: 54,2% против 44,2% у Clef-Flash и 31,2% у Laya.
• RouterBench, медианная задержка: 21 мс против 170 мс у Clef-Flash.

Вывод автора: маленькая модель с обученными головами на задачах принятия решений обходит 9B-конкурента и работает примерно в 10 раз быстрее. На свободной генерации, как он сам признаёт, выиграет большая модель. Скрипт eval/competitors/reproduce_real.sh и сырые JSON лежат в релизах, так что цифры можно перепроверить.

Что с интеграцией и где подвох

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

Теперь об ограничениях, которые автор честно перечисляет сам. По умолчанию головы случайны, осмысленное качество требует SFT/RLCD или готового пака весов. Риск-модель полезна только после накопления примеров. Доменную калибровку под свой сценарий придётся делать самостоятельно. И не забываем про масштаб замеров: n=200, бенчмарки собраны самим автором, это не независимая оценка.

Что с этим делать

Даже если вы не будете ставить decision-cascade, идея переносится на любую связку «дешёвая модель плюс дорогая». Перестаньте маршрутизировать по одной уверенности. Заведите хотя бы грубую оценку цены ошибки по типам запросов и сравнивайте её со стоимостью вызова. Для задач классификации, выбора варианта и оценки это может сильно срезать расходы на внешний API при малой потере качества. В планах у проекта энкодер-трансформер с attention-mask состояний и глубокая интеграция в чат-агентов. Автор просит присылать случаи, где каскад эскалирует не туда, и это самый полезный способ проверить подход на практике.