Большинство операций в типовом проекте не требует тяжёлой модели. Классификация обращения по пятнадцати темам, извлечение шести полей из накладной, маршрутизация заявки на нужную группу — всё это упирается в качество инструкции и стабильность формата ответа, а не в мощность модели. Ставить на такие операции старшую модель — значит платить втрое за результат, который не станет лучше.
Отсюда каскад: лёгкая модель отвечает на весь поток, тяжёлая подключается только там, где лёгкой действительно не хватает. В модельном расчёте ниже это снимает около 45 % счёта за модель. Но у приёма есть цена — 50 часов на сборку и второй контур, который надо сопровождать, — и есть порог объёма, ниже которого он не окупается никогда.
Все цены за токены в статье взяты порядком величины по состоянию на сентябрь 2026 года: 0,20 ₽ за тысячу входящих и 0,60 ₽ за тысячу исходящих у лёгкой модели, втрое дороже у тяжёлой. Подставьте актуальный прайс своего поставщика на дату расчёта — арифметика от этого не изменится, изменятся только итоги.
Три класса моделей и что каждый делает надёжно
Выбирать удобнее не между конкретными названиями, которые устаревают за месяцы, а между классами. Классов три, и различаются они не «умом», а тем, какую работу каждый выполняет предсказуемо.
| Класс | Что это на практике | Делает надёжно | Порядок цены обращения |
|---|---|---|---|
| Маленькая быстрая | Младшая модель в линейке поставщика или локальная модель на 8–14 млрд параметров | Классификация, извлечение полей из типовой формы, маршрутизация, короткий ответ по шаблону | около 1 ₽ |
| Большая рассуждающая | Старшая модель линейки того же поставщика | Сводка длинного документа, ответ по нескольким противоречивым источникам, спорный клиентский случай | около 3 ₽ |
| Своя на своём железе | Открытая модель, развёрнутая в контуре компании на собственном сервере | То же, что позволяет выбранный размер, но данные не покидают вашу сеть | Зависит от загрузки: постоянная стоимость контура делится на объём |
Третий класс стоит особняком: его выбирают не за качество и не за цену обращения, а за то, что запрос не уходит наружу. Удельная стоимость там ведёт себя иначе — сервер стоит одинаково при любом потоке, поэтому цена обращения падает с объёмом и становится сопоставимой с облаком только на больших числах. Как считать эту точку, разобрано в сравнении облака и своего сервера для ИИ; сама смета железа — в материале про сервер под свою модель.
Здесь же проходит граница, за которой выбор перестаёт быть экономическим. Облако заканчивается там, где начинается одно из трёх: в запросе появляются персональные данные, для которых требуется локализация обработки и оформленное поручение; заказчик прямо записал в договоре, что обработка ведётся на территории России и состав сервисов согласовывается; либо у нужного поставщика вообще нет легального доступа из России. В этих случаях третий класс выбирают не потому, что он дешевле или лучше, а потому, что первые два недоступны — и тогда каскад считают не в рублях за токен, а в очереди и времени ответа.
Сравнение в три колонки. Колонка «Маленькая быстрая»: «классификация, извлечение полей, маршрутизация», «около 1 ₽ за обращение». Колонка «Большая рассуждающая»: «сводка длинного документа, несколько источников, спорный случай», «около 3 ₽ за обращение». Колонка «Своя на своём железе»: «данные не покидают сеть», «цена обращения зависит от загрузки сервера». Под колонками подпись: «Названия моделей устаревают за месяцы, границы классов — нет». Чертёжный стиль, подписи по-русски.
Что кому отдавать
Граница проходит по одному признаку: нужно ли для ответа связывать между собой несколько источников или несколько шагов рассуждения. Если нет — задача лёгкая, какой бы важной она ни казалась.
- Лёгкой модели достаточно: классификация обращений по 10–20 темам, извлечение полей из типовой формы, маршрутизация заявки на группу, короткий ответ по шаблону, определение языка и тональности, проверка полноты заявки.
- Нужна тяжёлая: сводка договора или тендерной документации, ответ, который собирается из пяти и более фрагментов с противоречиями, спорный клиентский случай с историей обращений, юридически значимая формулировка, любой ответ, уходящий клиенту без человека и касающийся денег.
- Спорная зона: ответ по базе знаний. На простой базе с однозначными формулировками лёгкая модель справляется; на базе, где ответ приходится собирать из нескольких документов, — нет. Именно этот сценарий чаще всего и уходит в эскалацию.
Как устроен каскад с эскалацией
Схема, в которой обращение сначала обрабатывает лёгкая модель, а тяжёлая подключается только по явному правилу — когда лёгкая не справилась или тема заранее отнесена к сложным. Это не «две модели голосуют» и не выбор модели по типу обращения на входе: решение принимается после первой попытки, по её результату, и потому не требует отдельного классификатора.
Конструкция намеренно простая: чем больше в ней ветвлений, тем труднее потом объяснить, почему конкретное обращение обработалось именно так. Рабочая схема состоит из четырёх элементов.
- 1Лёгкая модель отвечает первой и всегда
Через неё проходит 100 % потока. Она же выдаёт признак уверенности и заполненность обязательных полей — на этом строится решение об эскалации, отдельный классификатор для этого не нужен.
- 2Правило эскалации из трёх условий
Обращение уходит в тяжёлую модель, если: результат не прошёл валидацию формата, обязательные поля пусты или помечены как неуверенные, тема попала в список «всегда тяжёлая» — деньги, претензии, расторжение, всё, что касается здоровья.
- 3Тяжёлая модель получает обращение и черновик
Передавать ей результат лёгкой полезно: он экономит токены на объяснении задачи и служит подсказкой. Именно поэтому эскалированные обращения оплачиваются дважды — этот двойной счёт обязан быть в расчёте.
- 4Доля эскалаций — отдельная метрика
За ней следят еженедельно. Рост доли означает либо изменение потока, либо деградацию лёгкой ветки; и то и другое — повод разбираться, а не молча платить больше.
Схема слева направо. Блок «Поток 60 000 обращений» → блок «Лёгкая модель, 1,04 ₽, 100 % потока» → ромб «Правило эскалации» с тремя подписанными условиями: «ответ не прошёл валидацию», «обязательные поля пусты», «тема из списка: деньги, претензии, здоровье». От ромба вниз ветка «22 %, 13 200 обращений» в блок «Тяжёлая модель, 3,12 ₽», от ромба вправо ветка «78 %» в блок «Ответ». Под схемой подпись: «Эскалированное обращение оплачивается дважды: 1,04 ₽ + 3,12 ₽». Чертёжный стиль, подписи по-русски.
Счёт за месяц: 60 000 обращений с каскадом и без
Вводные модельного примера: 60 000 обращений в месяц, средний запрос 4 000 входящих токенов и 400 исходящих, доля эскалаций 22 %. Цена обращения у лёгкой модели — 4 000 × 0,20 ₽/1000 плюс 400 × 0,60 ₽/1000, то есть 1,04 ₽. У тяжёлой при втрое более дорогом тарифе — 2,40 ₽ плюс 0,72 ₽, то есть 3,12 ₽.
Проверить легко: 129 000 ₽ разделить на 77 376 ₽ — получается 1,67 месяца. Сборка складывается из маршрутизатора и правила эскалации (10 часов), отдельного промпта и схемы ответа для лёгкой ветки (12 часов), метрики доли эскалаций (6 часов), второго регресс-набора на 60 примеров силами методиста (10 часов) и сравнительного прогона обеих веток (12 часов).
45 % — это доля от счёта за модель, а не от стоимости процесса. В разборе стоимости одного обращения переменная часть составляет 3,2 ₽ из 17,0 ₽ удельной цены, то есть 19 %: остальное держат сопровождение, инфраструктура, контроль качества и амортизация внедрения. Каскад работает с этой пятой частью. Ждать от него сокращения общей стоимости процесса вдвое не стоит — так не бывает.
Как убедиться, что качество не просело
Перевод части задач на лёгкую модель — это изменение, которое обязано доказываться цифрами. Проверка занимает один рабочий день и делается на том же наборе примеров, что и любая другая проверка системы.
- 1Один набор, два прогона: те же 180 примеров прогоняются через старую конфигурацию и через каскад. Никаких новых примеров специально под каскад — иначе сравнение теряет смысл.
- 2Сравнивается не средняя оценка, а поимённо упавшие примеры. Одинаковая средняя при разном составе ошибок — это не «то же качество», а другое качество.
- 3Корзина денежных и правовых тем смотрится отдельно, допуск по ней нулевой. Если такой пример упал на лёгкой ветке, тема переносится в список «всегда тяжёлая», и вопрос закрыт.
- 4Фиксируется доля эскалаций на выборке и сравнивается с ожидаемой. Расхождение вдвое означает, что расчёт экономии придётся пересчитать до запуска, а не после первого счёта.
- 5Порог приёмки записывается до прогона. Формулировка вида «принимаем, если критических падений ноль, а обычных не больше трёх» решает будущий спор заранее.
Появляются два промпта, которые со временем расходятся, второй регресс-набор, отдельная метрика доли эскалаций и двойная оплата на эскалированных обращениях. Труднее становится разбор инцидента: сначала надо понять, какая ветка отвечала. Это плата за 45 % счёта, и на малом потоке она превышает выигрыш. Как устроен сам набор примеров и почему он должен лежать у заказчика, разобрано в материале про регресс-набор при обновлениях.
Порог: когда каскад не окупается
Порог считается в одно действие. Экономия на одном обращении — это разница между ценой тяжёлой модели и средней ценой в каскаде: 3,12 ₽ минус сумма 1,04 ₽ и 22 % от 3,12 ₽, то есть 1,39 ₽. Дальше вопрос только в том, покрывает ли эта разница постоянные расходы каскада.
Проверка нижней границы: при 5 000 обращений в месяц без каскада счёт составит 15 600 ₽, с каскадом — 5 200 ₽ плюс 3 432 ₽ за 1 100 эскалаций, то есть 8 632 ₽. Экономия 6 968 ₽ минус 6 240 ₽ сопровождения даёт 728 ₽ в месяц — при разработке за 129 000 ₽ это окупаемость в 177 месяцев. Такой проект не надо ни защищать, ни обсуждать: его надо не делать.
Двухосевой график. Горизонтальная ось — поток обращений в месяц от 0 до 60 000. Вертикальная — рубли в месяц. Прямая линия «экономия на обращениях, 1,39 ₽ за штуку» пересекает горизонтальную линию «постоянные расходы каскада, 16 990 ₽/мес» в точке, подписанной «около 12 200 обращений — порог окупаемости». Отмечены две точки: «5 000 обращений — 728 ₽ чистой экономии» и «60 000 обращений — 77 376 ₽ чистой экономии». Чертёжный стиль, подписи по-русски.
Кроме объёма, есть ещё три случая, когда каскад не нужен независимо от арифметики.
- Однородный поток. Если все обращения одного типа и одинаковой сложности, делить нечего: правило эскалации либо отправит наверх всё, либо ничего. Проверяется за час на выгрузке за месяц.
- Высокая цена ошибки на любом обращении. В проверке договоров или расчёте условий сделки экономия в 1,39 ₽ несопоставима с ценой одной пропущенной формулировки. Здесь тяжёлая модель работает на всём потоке, и это правильно.
- Сценарии собраны в конструкторе платформы. Разветвление в визуальном конструкторе стоит дороже, чем в коде, а второй набор сценариев придётся вести руками. Каскад в такой системе съедает выигрыш ещё до запуска.
Тяжёлая модель на простой операции не делает её лучше — она делает её дороже. Разница между этими двумя утверждениями и есть весь смысл каскада.
