Каскады и параллельные вопросы

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

Каскады: решайте только там, где уверены

Прямое сравнение в задаче обнаружения медицинских галлюцинаций даёт чистое число:

Позвольте модели принятия решений уладить 37% случаев, где она уверена как минимум на 90%, и она сохраняет собственную точность каждой большой модели, убирая 37% вызовов большой модели.

Это стоит процитировать, потому что здесь сказано, чем на самом деле является экономия каскада: доля трафика, попадающая в вашу зону высокой уверенности, а не какая-то фиксированная величина. Чем плотнее уверенность, тем больше экономия — при условии, что эта уверенность настоящая, а это снова возвращает нас к калибровке.

Две детали легко упустить:

① После эскалации большая модель не должна получить неограниченную свободу. Одна реализация, передающая неуверенные строки LLM, принуждает эту LLM выбирать из того же набора меток. Без этого «не уверена» маленькой модели превращается в вывод, который ваш пайплайн не может потребить.

② Раз выбор сделан — держите его. Один роутер моделей сохраняет свой выбор на всю сессию, чтобы сохранить непрерывность prompt-кэша. Повторный выбор на каждом ходу меняет префикс и выбрасывает кэш — деньги, сэкономленные на более дешёвом вызове, уходят обратно через кэш.

Параллельные вопросы: экономия — это вход

Модели принятия решений позволяют положить много вопросов в один запрос; официальные примеры задают десятки сразу.

Бенчмарк на 2,976 вызовах измерил, что это даёт:

Так что экономия не в том, что «модель считает быстрее», а в том, что одно и то же состояние отправляется один раз. Чем больше вопросов, тем тоньше размазывается эта фиксированная накладная стоимость. С одним-двумя вопросами разница между параллельным и последовательным одного порядка с шумом между запусками, и не стоит смены архитектуры.

Контрпример: пакетирование может сломать ранжирование

Это самая контринтуитивная находка на странице:

Расширение для DuckDB пакетирует 40 строк по умолчанию. Бенчмарк обнаружил, что пакетный путь проваливает свой шлюз качества ранжирования, тогда как одна строка на запрос его проходит.

Причину можно реконструировать: упаковка 40 строк в один запрос просит модель выдать 40 относительных упорядочиваний сразу, что труднее, чем сравнивать несколько кандидатов за раз. Стоимость и верность здесь в конфликте — и сторона стоимости видна (счёт), а сторона верности невидима, если вы не построили шлюз, чтобы её измерить.

Общее правило: параллельные вопросы подходят для независимых вопросов (классификация, оценивание, суждение) и не подходят для вопросов, где элементы нужно сравнивать друг с другом.

Ещё одно предварительное условие: ошибки должны быть случайными

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

Независимое тестирование калибровки вне распределения это опровергает. Choice и Score систематически переуверены; Boolean систематически неуверен. Систематическое смещение — не шум: оно заставляет маленькую модель сообщать высокую уверенность на целом классе входов, поэтому этот класс никогда не эскалируется и отвечается неверно каждый раз.

Риск, таким образом, не «чуть более низкая точность», а целый вид входа, который последовательно отбрасывается, невидимо на уровне агрегата. Чтобы его найти, нужно смотреть на точность по подклассам, а не в целом.

В одном предложении

Каскад экономит пропорционально тому, сколько трафика лежит в его зоне высокой уверенности; параллельные вопросы экономят за счёт амортизации фиксированной накладной стоимости. У обоих есть цена — первый делает ставку на то, что ошибки меньшей модели случайны, второй вредит задачам, требующим перекрёстного сравнения.