Счёт за RAG часто пытаются уменьшить в самом конце конвейера: выбирают модель дешевле, сокращают промпт или торгуются за GPU. Разбор VentureBeat указывает на более сильный рычаг, сократить сам поток запросов и документов, который доходит до LLM.
Шестикратную экономию нельзя принимать за универсальный коэффициент: это результат одной системы, описанной её разработчиком. Однако механику можно проверить на любом работающем RAG. Для этого достаточно выяснить, какие случаи действительно требуют рассуждения модели, а какие проходят через неё лишь потому, что так было проще собрать первую версию.
Что произошло
Автор VentureBeat описывает RAG-системы классификации для регулируемых корпоративных процессов, где решение должно выдержать проверку спустя месяцы. Обычная архитектура отправляет каждый неоднозначный случай в LLM вместе с несколькими найденными документами. На демо это выглядит удобно. На масштабе растут расходы и задержка, а объяснение в духе «модель решила на основе контекста» не помогает восстановить путь решения.
В описанной архитектуре поток проходит через каскад из трёх стадий. Точные совпадения, сравнение структурированных полей и случаи с однозначным правилом обрабатываются детерминированно, без вызова модели. По наблюдению автора, этот слой нередко снимает больше половины потока, хотя доля зависит от качества данных.
Для оставшейся неоднозначности retrieval подбирает только релевантные свидетельства: похожие решения проверяющих, документы, объясняющие конфликт, или исторические прецеденты. LLM получает уже тот остаток, который предыдущие стадии не смогли уверенно разобрать.
В одной такой системе до модели доходили лишь 10–15% случаев. По сравнению с вариантом, где LLM обрабатывала весь поток, расходы на инференс снизились примерно в шесть раз. Решения на детерминированном большинстве при этом стали, по оценке автора, практически полностью последовательными.
Главная метрика находится перед моделью
Здесь важен не сам рекорд, а смена единицы учёта. Команда, которая смотрит только на цену миллиона токенов, принимает объём отправляемого контекста как данность. Полезнее считать долю потока, которая дошла до LLM без необходимости, и отдельно, долю извлечённых материалов, реально повлиявших на решение.
Тогда работа над экономией становится конкретной: выделить классы запросов, которые закрываются точным правилом; проверить, зачем retrieval приносит каждый документ; удалить контекст, который не помогает снять неоднозначность. Цена модельного вызова становится следующим уровнем оптимизации, когда лишние обращения уже убраны.
Критической частью второго этапа автор VentureBeat называет retrieval. Если система достала неверный контекст, более сильная LLM лишь убедительнее сформулирует неверный ответ. Смена модели в таком случае улучшит витрину, но сохранит источник расходов и ошибок.
На этом фоне выбор между флагманской и дешёвой моделью похож на обсуждение тарифа такси до решения, нужно ли вообще ехать. В материалах InfoWorld тема контроля расходов уже соседствовала с вопросом, на какую модель ставить компанию. Каскадная архитектура даёт более устойчивый ответ: бизнесу важнее ограничить участок, где без LLM нельзя обойтись, чем выбирать одну модель для всего потока.
Как проверить эффект у себя
Практическая проверка начинается с базовой линии: стоимости и задержки текущего варианта, где весь спорный поток идёт в LLM. Затем случаи размечаются по точкам выхода из каскада: решено правилом, снято на retrieval-этапе, отправлено модели, передано человеку.
Качество retrieval и итоговую точность классификации нужно измерять отдельно. Высокая оценка ранжирования ещё не означает правильного решения: генерация может неверно взвесить найденные свидетельства. В тестовом наборе VentureBeat советует намеренно увеличить долю случаев третьей стадии, иначе простые детерминированные примеры замаскируют ошибки именно там, где требуется суждение модели.
Для задач с несимметричным риском каскад продолжается и после LLM. Модель получает инструкцию отправлять неопределённость на эскалацию, возвращает оценку уверенности, а ответы ниже заданного порога уходят человеку. Если для оценки используется LLM-судья, её промпт должен учитывать ту же разницу в цене ошибок, что и рабочая система.
Маркер на ближайший цикл оптимизации простой: после введения каскада доля обращений к LLM должна снижаться без ухудшения точности на специально отобранных сложных случаях. Резкий рост очереди ручной проверки или падение качества третьей стадии покажут, что расходы просто перенесли в другое место. Если модель стабильно получает только неоднозначный остаток, искать следующую скидку на токены можно уже без спешки.