Каскад маленькой и большой модели: где он оправдан

Почему схема выглядит лучше, чем работает

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

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

Экономия появляется только тогда, когда первая ступень сама закрывает заметную долю потока и делает это достаточно точно. Если она снимает 50-70% типовых вопросов, схема может окупиться. Если сложных обращений много, большая модель все равно отвечает в большинстве случаев, а первая ступень просто добавляет задержку и лишнюю стоимость маршрута.

Это особенно заметно там, где поток уже очищен заранее. Например, обычные FAQ закрывает поиск или жесткие шаблоны, а в LLM попадает только то, что требует рассуждения, сверки контекста или аккуратной формулировки. В таком сценарии маленькая модель редко срезает трафик. Чаще она повторяет очевидный шаг перед передачей задачи дальше.

Есть и более неприятный риск. Ошибка происходит до финального ответа. Если первая ступень неверно определила тип запроса, выбрала плохой маршрут или слишком уверенно решила "справлюсь сама", сильная модель уже не получит шанс исправить ситуацию. Пользователь увидит слабый ответ, хотя вторая ступень могла бы решить задачу нормально.

На бумаге каскад снижает расходы. В проде он часто просто переносит проблему из бюджета в маршрутизацию. Команде приходится поддерживать порог передачи, правила для пограничных случаев и проверку ошибок первой ступени.

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

Где первая ступень действительно режет трафик

Первая ступень полезна там, где запросы часто повторяются и почти всегда ведут к одному решению. Это короткие обращения с ясным смыслом: "где мой заказ", "как вернуть товар", "пришлите чек", "сменить адрес доставки". В таких случаях маленькая модель не рассуждает вместо большой. Она быстро решает, нужен ли вообще дорогой вызов.

Хороший пример - поддержка интернет-магазина. Если история обращений показывает, что большая модель почти всегда выбирает один и тот же шаблон ответа для статуса заказа или возврата, нет смысла прогонять через нее весь поток. Маленькая модель может определить класс запроса, подставить нужный шаблон и закрыть задачу за один проход.

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

Сигнал уверенности обязателен. Без него первая ступень превращается в случайную развилку. На практике смотрят на метку класса, оценку уверенности, длину запроса, наличие стоп-слов и иногда добавляют совсем простые правила. Если модель уверена, запрос остается на дешевой ветке. Если нет, система передает его дальше.

Лучше всего такая схема работает в узких задачах: фильтр спама, простая модерация, выбор шаблона ответа. Там сама задача ограничена, и сильная модель редко приносит дополнительную пользу.

Проверять это лучше не по ощущениям, а по логам. Возьмите прошлые 10 000 запросов и посмотрите, в каких классах большая модель спорит с первой редко, например в 2-5% случаев. Именно там обычно лежит реальное снижение стоимости. Если через дешевую ступень проходит 70% простого потока, а ее вызов стоит в 8-10 раз меньше, экономия уже заметна.

Если вы и так маршрутизируете модели через OpenAI-совместимый шлюз вроде RU LLM, такой тест проще прогнать на одном и том же трафике. Можно быстро менять первую модель и смотреть, сколько запросов она отсекает без просадки по качеству.

Где каскад только тратит время

Каскад не помогает, если почти каждый запрос требует длинный контекст, проверку деталей и аккуратное рассуждение. В такой схеме маленькая модель редко отсекает поток. Она просто читает тот же текст, который потом читает большая.

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

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

Обычно схема тратит время зря в четырех случаях. Первый - запросы почти всегда сложные и длинные. Второй - маленькая модель передает дальше большую часть обращений. Третий - первая ступень читает тот же контекст, что и вторая. Четвертый - цена ошибки выше, чем возможная экономия.

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

Есть простой мысленный тест. Клиент прислал историю переписки, выдержку из договора и просит объяснить, почему ему отказали в выплате. Почти наверняка первая ступень не сможет дать уверенный финальный ответ без передачи дальше. Значит, она не режет трафик, а просто добавляет еще один круг обработки.

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

Простое правило такое: когда сложные запросы составляют основную массу, а порог передачи срабатывает слишком часто, каскад превращается в дорогую задержку.

Как разделить роли между ступенями

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

Просите у нее не готовый текст для пользователя, а короткий структурированный результат. Ей проще вернуть метку, уровень уверенности и решение о передаче дальше, чем писать абзац объяснений. Это снижает расход токенов и делает поведение предсказуемее.

Например, выход первой ступени может включать тип запроса, отметку о том, хватает ли входных данных, оценку уверенности и статус: "обработать здесь" или "передать дальше". Такой ответ легко проверить кодом.

Дальше стоит передавать только спорные случаи: неполный контекст, конфликтующие условия, длинную историю диалога или риск ошибиться в сути. Если первая модель сомневается, просит недостающие данные или видит несколько трактовок, ей лучше не гадать.

Большой модели оставляйте то, за что действительно есть смысл платить задержкой и ценой. Она лучше справляется с неоднозначными задачами, длинными инструкциями, сравнением нескольких вариантов и развернутым ответом нормальным человеческим тоном.

Хорошее разделение выглядит так: маленькая модель решает, можно ли ответить по шаблону и хватает ли ясности, а большая разбирает пограничные случаи и пишет финальный текст, когда нужен разбор, а не ярлык. Если первая ступень начинает сочинять ответы, схема почти всегда усложняется без заметной выгоды.

Как собрать схему и протестировать

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

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

Рабочий минимум простой:

1. Возьмите 100-300 реальных запросов одного типа.
2. Разметьте их как простые, сложные и пограничные.
3. Прогоните всю выборку через большую модель и сохраните ответы как эталон.
4. После этого добавьте первую ступень и правила передачи.

Эталон нужен не для отчета. Он показывает, какой результат вы вообще готовы считать достаточным. Если большая модель в этом сценарии уже ошибается или отвечает слишком долго, каскад это не исправит. Он унаследует те же проблемы и добавит новые.

На первой ступени сразу задайте два ограничения: порог передачи и таймаут. Порог отвечает на вопрос, когда модель может закрыть запрос сама. Таймаут - сколько времени вы готовы ей на это дать. Частая ошибка - настроить только порог и забыть про время. Тогда первая ступень думает 800 мс, потом запрос все равно уходит дальше, и весь выигрыш по цене съедает задержка.

Если вы тестируете схему через RU LLM, удобно держать один и тот же OpenAI-совместимый вызов и менять только модель и правила маршрутизации. Так проще сравнить чистую разницу между одним вызовом и каскадом, не трогая остальной код.

Считать нужно три вещи сразу: цену, время и качество. И смотреть не только на средние значения, а на распределение. Если схема дешевле на 20%, но хвост задержки вырос вдвое, это может быть плохой обмен. Если качество на простых запросах осталось тем же, а большая модель получает заметно меньше трафика, идея уже выглядит живой.

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

Как выбрать порог передачи

Ставить порог только "по экономии" обычно слишком рано. Сначала нужно защититься от опасных пропусков - ситуаций, когда маленькая модель уверенно оставляет запрос у себя, хотя должна была передать его дальше. Для поддержки это может быть возврат денег, спор по доставке или обращение с персональными данными. Один такой промах часто стоит дороже, чем десяток лишних передач на вторую ступень.

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

Если у вас есть скоринг уверенности, не верьте ему вслепую. У многих моделей высокий score не гарантирует хороший ответ. Поэтому на порог полезнее смотреть как на бизнес-правило: при каком значении вы готовы принять риск ошибки. На практике часто лучше держать цель вроде "не больше N плохих ответов на 1000 запросов", чем гнаться за минимальным числом эскалаций.

Один общий порог почти всегда грубоват. Короткие запросы вроде "где мой заказ" и длинные обращения с историей переписки ведут себя по-разному. На коротких фразах маленькая модель чаще угадывает интент, но иногда путает контекст. На длинных сообщениях она тратит больше времени и чаще теряет детали. Поэтому разумно считать порог хотя бы отдельно для коротких и длинных запросов.

Что обычно работает

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

Смотрите сразу на два числа: долю передач и медианную задержку. Если порог снизил расходы на 8%, но добавил 600-800 мс почти всем пользователям, схема может уже не окупаться.

Порог нельзя считать постоянным. Сменили модель, провайдера или параметры генерации - пересчитайте его заново. Калибровка уверенности меняется быстро. Если вы гоняете разные модели через RU LLM и один API, это удобно делать сериями. Но удобная замена сама по себе ничего не решает: после каждой смены нужен новый прогон на свежем наборе запросов.

Пример с поддержкой интернет-магазина

У поддержки интернет-магазина обычно есть две разные группы обращений. Первая - простые и частые вопросы. Вторая - случаи, где цена ошибки выше, а ответ зависит от деталей заказа, правил возврата и тона клиента. На таком потоке каскад имеет смысл только тогда, когда первая ступень отсекает заметную долю трафика.

Хороший кандидат для первой ступени - запросы, где ответ почти шаблонный и его легко проверить по данным из CRM или OMS. Обычно это статус заказа, срок доставки, смена адреса до отгрузки и подтверждение, что заказ уже передан в службу доставки.

Если клиент пишет: "Где мой заказ 54821?" или "Можно поменять адрес на другой офис?", маленькая модель часто справляется сама. Она определяет тип обращения, вытаскивает нужные поля и отдает короткий ответ по правилам. Тут не нужна длинная генерация. Нужны точность и понятная логика.

С возвратами денег, спорными платежами и жалобами все иначе. Человек может описывать ситуацию расплывчато, путать даты, злиться, ссылаться на прошлые обещания поддержки. В таких случаях маленькой модели лучше не отвечать по существу. Пусть она быстро ставит метку маршрута и короткую причину, например: refund_request или complaint, а затем передает запрос дальше.

Так команда получает простую схему: первая ступень либо закрывает легкий тикет, либо передает его дальше с понятной причиной. Это полезнее, чем заставлять маленькую модель писать длинные объяснения там, где она часто ошибается.

Считать стоит не только цену токенов. Смотрите, какой процент обращений первая ступень закрыла без просадки по качеству: без роста повторных контактов, без лишних переводов на оператора, без падения CSAT. Если она закрывает 35-50% простых запросов, экономия обычно видна быстро.

Но жалобы часто ломают такую схему. Если почти все они все равно уходят дальше, первая ступень только добавляет задержку, еще один вызов и лишнюю точку сбоя. В этом случае лучше сразу отправлять такие темы на большую модель или на человека, а маленькую оставить только для узких и предсказуемых сценариев.

Что считать до запуска

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

Сначала посчитайте стоимость на 1000 запросов по каждому маршруту отдельно. Один маршрут заканчивается на маленькой модели. Другой идет дальше, и вы платите уже за две ступени. Третий встречается реже, но часто ломает экономику: первая модель пропустила сложный запрос, пользователь переспросил, а сотрудник потом исправил ответ вручную.

Удобная формула простая: цена первой ступени + цена второй при передаче + цена повторов + цена ручной доработки. Если после такого расчета экономия остается только на бумаге, схема не готова.

С задержкой ошибаются еще чаще. Средняя цифра мало что говорит. Смотрите p50 и p95 отдельно для первой ступени, отдельно для второй и для полного маршрута. Если маленькая модель добавляет 200-300 мс ко всем обращениям, а отсекает только небольшую долю трафика, вы платите временем каждого пользователя за слабую экономию.

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

Отдельный тест нужен для сложной выборки. Возьмите неоднозначные формулировки, длинный контекст, редкие темы, смешанный русский и английский, запросы с суммами, датами и условиями. На таком наборе смотрите не только долю ошибок первой ступени, но и их тип. Самая неприятная ошибка - когда маленькая модель уверенно оставляет у себя запрос, который нужно было передать дальше.

Еще один расход часто забывают: что происходит после ответа. Если пользователь вынужден отправлять второй запрос, а оператор правит каждый двадцатый ответ, формальное снижение стоимости быстро исчезает. В поддержке это видно сразу: расходы на модели падают, а очередь у людей растет.

Если у вас уже есть маршрутизация через единый шлюз, такие метрики собирать проще. Но сама телеметрия не спасает. Каскад стоит запускать только тогда, когда стоимость, p95, доля передач и цена ошибок сходятся в одной таблице, а не в четырех разных отчетах.

Частые ошибки

Самая дорогая ошибка выглядит безобидно: первая модель начинает "думать вслух" и пишет полстраницы рассуждений там, где от нее нужна короткая метка. Для каскада это почти всегда плохой знак. Первая ступень должна делать одно простое действие: отсечь очевидные запросы, отдать короткий шаблонный ответ или передать запрос дальше. Если она тратит десятки или сотни токенов на объяснения, экономия быстро исчезает.

Вторая типичная ошибка - смотреть только на среднюю стоимость и среднюю задержку. Красивый график легко создает ложное чувство контроля. Пользователю безразлично, что среднее время ответа снизилось на 15%, если спорный запрос теперь висит в два раза дольше. Поэтому смотрите отдельно на трудные обращения, p95 и p99, долю ложных "не эскалировать" и долю запросов, которые первая ступень поняла неверно.

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

Порог передачи команды тоже часто портят сами. Его подгоняют под демо, тестовые промпты или аккуратно отобранные примеры. В реальных логах все хуже: опечатки, обрывки переписки, вставки из CRM, раздраженные пользователи, смешанные интенты. Поэтому порог нужно крутить на живых данных. Если у вас есть требования по 152-ФЗ, берите обезличенные логи и маскируйте PII, а не работайте на ручной выборке из презентации.

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

Еще одна частая ошибка - включать каскад сразу везде. Так команда получает шум вместо выводов. Лучше начать с одного сценария, где много повторяющихся запросов и низкая цена ошибки. Не стоит первым запуском отправлять в каскад претензии, финансовые споры или обращения VIP-клиентов.

И еще один практический момент: у схемы должен быть простой откат. Один флаг, одно правило маршрутизации, и весь трафик снова идет в большую модель. В OpenAI-совместимых схемах, в том числе через RU LLM, это обычно можно сделать на уровне маршрута без переписывания SDK и клиентского кода.

Быстрая проверка перед запуском

Перед выкладкой хватит небольшого теста на одном потоке. Возьмите 100-200 реальных запросов, которые уже проходили через обычный маршрут, и прогоните их через каскад параллельно, без влияния на пользователей. Так вы увидите не идею на схеме, а реальную цену, задержку и долю запросов, дошедших до второй ступени.

Чтобы тест не расползся, первая модель должна отвечать в фиксированном формате. Не "похоже, стоит эскалировать", а, например, route=small или route=large, плюс короткая причина и оценка уверенности. Если формат плавает, вы быстро начнете чинить парсер вместо самой схемы.

У каскада должны быть случаи, где решение принимается сразу. Если запрос длиннее заданного лимита, если в нем есть платежные данные, если пользователь просит сгенерировать сложный текст или сравнить несколько условий, лучше отправлять его прямо во вторую модель. Часто это быстрее, чем сперва прогонять его через дешевую ступень и все равно эскалировать.

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

Хороший тест выглядит скучно, и это нормально. Один и тот же набор запросов, один поток, одинаковые промпты, обычный маршрут рядом для сравнения. Уже через день обычно понятно: первая ступень отрезает хотя бы 30-40% трафика без заметной потери качества или нет. Если нет, ее лучше отключить и не усложнять систему.

Если вы сравниваете пары моделей у разных провайдеров и при этом храните данные в РФ, такой прогон удобно делать через RU LLM. Вы меняете только base_url на api.rullm.com, оставляете привычный SDK и быстро проверяете разные комбинации через один OpenAI-совместимый эндпоинт. Дальше все просто: соберите короткий датасет из реальных запросов, включите подробные логи и дайте схеме один день на честную проверку.