Каскадная маршрутизация LLM для RAG: как сократить расходы на инференс без потери качества

Стандартный RAG-пайплайн отправляет каждый пользовательский запрос к флагманской модели - GPT-4o, Claude Opus или Gemini Ultra. Счёт за API растёт линейно с нагрузкой. При этом значительная часть запросов элементарна: «выдели дату договора», «найди сумму счёта», «перечисли стороны сделки». Платить полную стоимость инференса за такие задачи - прямой путь к раздуванию операционных расходов.

Каскадная маршрутизация LLM (LLM Cascade) решает эту проблему архитектурно. Запрос сначала попадает к дешёвой локальной модели. Если ответ проходит проверочный цикл, он сразу возвращается пользователю. Если нет - эскалируется на уровень выше, вплоть до флагманской hosted-модели. Фактические замеры на задаче извлечения полей из документов показали: каскад из 20 локальных моделей в связке с одной флагманской обрабатывает 70-85% запросов на первом уровне, сохраняя итоговую точность на уровне монолитного решения.

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

Зачем нужна каскадная маршрутизация LLM в RAG-системах

Типичный продакшен-пайплайн RAG выглядит так: retriever достаёт релевантные чанки из векторной базы, генератор формирует ответ. Когда генератор - это GPT-4o, стоимость одного запроса составляет $0.005-0.015 за 1K токенов выхода. Тысяча запросов в день - $150-450 в месяц только на инференс. Десять тысяч - $1500-4500.

Проблема в том, что сложность запросов распределена неравномерно. Анализ логов RAG-систем в юридических и финансовых доменах показывает: 60-80% обращений - это извлечение конкретных атрибутов из найденных чанков. Модель не рассуждает, не синтезирует новую информацию, не разрешает противоречия. Она выполняет механическую работу по заранее заданной схеме.

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

Цифры для ориентира: локальный инференс Llama 3 8B на GPU A10G обходится в $0.0001-0.0003 за 1K токенов - в 50-150 раз дешевле флагманских hosted-моделей. Даже с учётом стоимости сервера разница на порядок сохраняется при утилизации выше 30%. Подробный разбор бэкендов для инференса с бенчмарками throughput и latency мы давали в статье про vLLM, LMDeploy и Triton - выбор движка напрямую влияет на экономику каскада.

Архитектура каскада: от локальных моделей к флагманским

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

Типичная конфигурация для задачи структурированного извлечения:

• Уровень 1: локальная модель 7-8B параметров (Llama 3, Mistral, Qwen 2.5) на одном GPU. Стоимость минимальна, задержка 50-200 мс.
• Уровень 2: локальная модель 20-34B параметров (Mixtral 8x7B, Command R) на двух GPU или мощная hosted-модель среднего ценового сегмента (Claude Haiku, GPT-4o-mini).
• Уровень 3: флагманская hosted-модель (Claude Sonnet, GPT-4o). Принимает только сложные случаи.

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

Декомпозиция сложных задач дополняет каскад. Вместо одного запроса «проанализируй договор и выдели все риски» пайплайн разбивает работу: сначала извлечение структурированных полей (стороны, суммы, даты) на уровне 1, затем анализ рисков на уровне 2, финальная проверка полноты на уровне 3. Такой подход увеличивает долю запросов, замыкающихся на дешёвых уровнях, с 60% до 80-85%.

Выбор стартовой модели: критерии и компромиссы

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

Критерии выбора, проверенные на практике:

1. Точность на целевом классе задач. Запустите эвал на 50-100 реальных примерах из вашего домена. Стартовая модель должна давать приемлемый ответ хотя бы на 60-70% из них. Приемлемый - значит проходящий вашу валидацию, не обязательно идеальный.
2. Задержка. Для интерактивных RAG-систем первый ответ должен приходить быстрее 500 мс. Локальные 7-8B модели на vLLM укладываются в 50-200 мс. 70B модели - уже 500-1500 мс, что может быть критично.
3. Требования к оборудованию. Модель должна помещаться в один GPU. Два GPU на первом уровне удваивают стоимость инфраструктуры и усложняют оркестрацию. Практичный выбор - модели 7-8B в 4-битном квантовании, они занимают 5-6 ГБ VRAM.
4. Совместимость со схемой ответа. Модель должна стабильно выдавать structured output (JSON с заданной схемой). Llama 3 8B и Qwen 2.5 7B показывают compliance >95% на схемах до 20 полей. Mistral 7B - около 85%, что приводит к лишним эскалациям.

По результатам тестов 20 локальных моделей на задаче извлечения полей из документов, оптимальными стартовыми точками оказались Qwen 2.5 7B (лучшее соотношение точность/скорость) и Llama 3 8B (лучшая совместимость с JSON-схемами). Обе модели на задаче извлечения 10-15 полей из договоров показали точность 78-82% относительно флагманского бейзлайна, обрабатывая запрос за 80-120 мс на одном A10G.

Проверочный цикл: валидация и эскалация

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

Три уровня валидации, которые мы применяем в пайплайне:

1. Структурная валидация. Самый быстрый и дешёвый фильтр. Проверяет, что ответ соответствует ожидаемой JSON-схеме, все обязательные поля присутствуют, типы данных корректны. Отсекает 15-20% ответов локальных моделей - пустые строки вместо чисел, отсутствие обязательных полей, невалидный JSON. Затраты - доли миллисекунды.

2. Бизнес-валидация. Проверяет доменные инварианты: дата не может быть в будущем для исторических документов, сумма не может быть отрицательной, ИНН должен соответствовать регулярному выражению. Правила пишутся под конкретный домен. Отсекает ещё 5-10% ответов. Затраты - микросекунды на регулярные выражения и сравнения.

3. Семантическая валидация моделью-критиком. Используется для ответов, прошедших первые два фильтра, но требующих проверки по смыслу. Модель-критик - это та же локальная модель, но с другим промптом: она сравнивает извлечённые поля с исходным чанком и выставляет бинарную оценку «корректно/некорректно». Добавляет 50-100 мс к задержке, но отсеивает оставшиеся 5-8% ошибок. Важно: критик не должен быть той же модели, что и генератор - иначе систематические ошибки дублируются. Практика показывает, что связка «Qwen генерирует, Llama проверяет» даёт лучшие результаты, чем любая модель в обеих ролях.

Порог эскалации настраивается по единственному параметру: доля запросов, уходящих на следующий уровень. Оптимальное значение для задачи извлечения полей - 15-25%. При таком пороге итоговая точность каскада не отличается от флагманского бейзлайна статистически значимо (p > 0.05 на выборке из 500 документов).

Экономия на инференсе: цифры и реальные кейсы

Перейдём к конкретным замерам. Конфигурация тестового стенда: 20 локальных моделей размерами от 7B до 34B параметров, развёрнутых на кластере из четырёх GPU A10G через vLLM. Флагманская модель - GPT-4o через Azure API. Задача - извлечение 12 полей из договоров аренды (стороны, дата, срок, сумма, предмет аренды, адрес, условия расторжения).

Результаты обработки 1000 документов:

Экономия составила 76-82% при сохранении точности в пределах погрешности. 78% запросов замкнулись на первом уровне, 15% - на втором, 7% дошли до GPT-4o. Средняя задержка для 80% пользователей сократилась в 3-4 раза за счёт локального инференса.

Распределение запросов по уровням каскада стабильно во времени: за две недели наблюдений доля эскалаций колебалась в пределах ±3 процентных пункта. Это означает, что сложность входящего потока предсказуема, и каскад не деградирует при изменении характера запросов.

Кейс: извлечение полей из документов

Детализация конфигурации, показавшей наилучшее соотношение цена/качество (Qwen 7B → Llama 3 8B → GPT-4o):

Уровень 1 - Qwen 2.5 7B Instruct, 4-bit GPTQ. Промпт содержит JSON-схему из 12 полей с описаниями и 3 примера (few-shot). Модель получает чанк документа (до 4000 токенов) и возвращает структурированный объект. Среднее время ответа - 85 мс. Стоимость - $0.00012 за запрос.

Валидация уровня 1: структурная проверка JSON-схемы, бизнес-правила (дата < текущей, сумма > 0, ИНН соответствует regexp), семантическая проверка моделью Llama 3 8B в роли критика. Порог - если критик оценивает confidence ниже 0.8, запрос эскалируется.

Уровень 2 - Llama 3 8B Instruct, 4-bit GPTQ. Более консервативный промпт с требованием указывать null для полей, не найденных в чанке. Модель обрабатывает те же чанки, что не прошли валидацию уровня 1. Среднее время - 110 мс. Стоимость - $0.00015 за запрос.

Уровень 3 - GPT-4o. Получает исходный чанк и все предыдущие ответы. Промпт инструктирует модель выбрать лучший из ответов или сгенерировать новый, если оба неудовлетворительны. Стоимость - $0.012 за запрос.

Итоговая точность F1=0.93 против 0.94 у чистого GPT-4o. Разница в 1 процентный пункт распределена по полям неравномерно: поля «дата» и «сумма» извлекаются одинаково хорошо (F1 0.97-0.98), поле «условия расторжения» на каскаде показало F1=0.84 против 0.89 у флагмана. Это ожидаемо: семантически насыщенные поля требуют глубокого понимания контекста, и здесь эскалация срабатывает чаще.

Методология A.L.F.R.E.D., которую мы разбирали в отдельной статье, доводит этот принцип до предела: шаблонизация ответов и адаптивная маршрутизация позволяют моделям размером 2B параметра обходить 35B-гигантов на специфичных задачах, сокращая расход токенов с 7000 до 1000.

Практические рекомендации по внедрению LLM Cascade

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

Шаг 1. Выберите задачу для пилота. Идеальный кандидат - структурированное извлечение с чёткой схемой ответа. Задача должна составлять значимую долю трафика (хотя бы 30% запросов), чтобы экономия была заметна. Избегайте начинать с открытой генерации или сложного reasoning - там каскад требует более тонкой настройки.

Шаг 2. Соберите эвал-датасет. 100-200 реальных запросов с эталонными ответами. Без этого вы не сможете измерить, сохраняется ли качество. Эталонные ответы можно получить, прогнав датасет через флагманскую модель и выборочно проверив руками 20-30 примеров.

Шаг 3. Разверните локальный инференс. Ollama для прототипирования, vLLM для продакшена. Настройте кэширование префиллов - системный промпт и JSON-схема не меняются между запросами, их кэширование сокращает задержку на 30-40%. Проблемы инвалидации кэша и инструменты для их отладки мы детально разбирали в статье про Cache-Hunter.

Шаг 4. Настройте проверочный цикл. Начните со структурной и бизнес-валидации. Добавляйте семантическую проверку моделью-критиком только если первые два фильтра пропускают слишком много ошибок. Измеряйте precision и recall каждого фильтра отдельно.

Шаг 5. Подберите порог эскалации. Запустите каскад на эвал-датасете, варьируя порог confidence критика от 0.6 до 0.95. Постройте кривую «доля эскалаций - точность». Выберите точку, где точность сравнивается с флагманским бейзлайном. Это и есть рабочий порог.

Шаг 6. Мониторьте в проде. Отслеживайте долю эскалаций, задержку по перцентилям (p50, p95, p99), стоимость на 1000 запросов. При отклонении любого параметра более чем на 20% от baseline - пересматривайте конфигурацию.

Декомпозиция сложных запросов для каскада

Сложный запрос к RAG-системе редко бывает атомарным. «Проанализируй договор аренды и выдели риски для арендатора» - это цепочка: найти договор, извлечь ключевые условия, сопоставить с типовыми рисками, сформулировать вывод. Каждый шаг имеет разную сложность и может быть направлен на свой уровень каскада.

Практический паттерн декомпозиции для юридического RAG:

1. Извлечение структурированных данных (стороны, даты, суммы) - уровень 1, локальная 7-8B модель. Задача механическая, схема фиксирована.
2. Классификация условий (тип договора, наличие пунктов о неустойке, подсудность) - уровень 1 или 2, в зависимости от сложности домена.
3. Поиск отклонений от стандартных условий - уровень 2, модель 20-34B. Требует сравнения с эталоном, что сложнее извлечения.
4. Формулирование рисков и рекомендаций - уровень 3, флагманская модель. Требует синтеза и аргументации.

Такая цепочка обрабатывает 80% шагов на дешёвых уровнях. Флагманская модель получает уже структурированный контекст - извлечённые поля и найденные отклонения - и генерирует финальный текст. Это сокращает входной контекст для флагмана в 3-5 раз, дополнительно снижая стоимость.

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

Ограничения и когда каскад не работает

Каскадная маршрутизация не универсальна. Есть сценарии, где она не даёт выигрыша или даже ухудшает характеристики системы.

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

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

Жёсткие требования к задержке. Каскад с несколькими уровнями добавляет 50-200 мс на каждый переход между уровнями. Для real-time приложений с бюджетом задержки до 300 мс это может быть неприемлемо. Решение - ограничить каскад двумя уровнями и использовать самую быструю локальную модель на первом.

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

Оценка применимости до внедрения: соберите 200-300 реальных запросов, прогоните через флагманскую модель для получения эталонов, затем через локальную модель. Если локальная даёт приемлемый результат на 60%+ запросов - каскад имеет смысл. Если меньше 40% - выгода будет съедена накладными расходами на валидацию и эскалацию.

Каскадная маршрутизация - инженерное решение, а не магический оптимизатор. Оно требует настройки под конкретный домен, мониторинга и периодической корректировки. Затраты на внедрение окупаются при объёмах от 1000 запросов в день. При меньших объёмах выгоднее использовать hosted-модели среднего ценового сегмента (GPT-4o-mini, Claude Haiku) и не усложнять архитектуру.

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

Подписаться на канал