Почему не каждая задача ИИ требует самой большой модели: проектирование с учетом ресурсов

Одна система борьбы с мошенничеством, четыре разных задачи

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

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

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

Тестовые сценарии против реальной работы

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

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

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

Что показывают исследования в области маршрутизации

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

В статье FrugalGPT, написанной Ченом, Захарией и Цзоу (2024), были проанализированы каскадные конфигурации из различных языковых моделей. Тщательное их сочетание значительно снизило затраты на обработку запросов при сохранении целевой производительности; в некоторых тестированных условиях экономия составила 98%. Project RouteLLM (Онг и др., 2025) пошёл ещё дальше, научившись определять, к какой модели — более мощной или менее мощной — следует направить запрос. На своих публичных тестах он зафиксировал более чем двукратную экономию без снижения качества по сравнению с используемой в качестве контроля конфигурацией.

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

Специалисты, правила и точные сравнения

Сочетание моделей — это не просто выбор между двумя универсальными большими языковыми моделями. Когда задача имеет строгие ограничения, специализация иногда может заменить собой просто большие размеры модели. Pecher, Srba и Bielikova (2025) сравнивали небольшие специализированные модели с крупными универсальными моделями в восьми задачах классификации текста, и при довольно небольшом количестве маркированных данных для конкретной области небольшие модели демонстрировали такую же или даже лучшую производительность по некоторым узкоспециализированным задачам.

Однако существует ограничение. Компактный классификатор, обученный для одной цели, не может заменить мощную универсальную модель, когда задача требует широкомасштабного рассуждения, работы в незнакомых ситуациях, интерпретации информации из разных источников или знаний, выходящих за рамки его обучающих данных. Тем не менее узкие, повторяющиеся задачи меняют ситуацию: если система постоянно выполняет одну четко определенную операцию, ей может не понадобиться обладать общими способностями, с которыми она никогда не сталкивается. Исследования в области маршрутизации также движутся в этом направлении. BEST-Route (Ding et al., 2025) определяет не только тот факт, какая модель должна обработать запрос, но и количество вычислительных ресурсов, необходимых для его обработки.

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

Рассмотрим еще более простые операции:

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

Ни один из этих шагов по сути не является семантическим. Осуществление точного сравнения с помощью языковой модели превращает детерминистскую задачу в вероятностную, увеличивает нагрузку на процесс вывода выводов и создаёт дополнительные возможности для сбоев. Именно поэтому подходы, сочетающие детерминистские и обучаемые механизмы, кажутся более убедительными, чем использование ИИ в каждом компоненте. Нейросимволические методы в кибербезопасности указывают в том же направлении: обучаемые компоненты способствуют распознаванию шаблонов, в то время как символические или основанные на правилах компоненты обеспечивают явное обоснование действий и контроль (Bizzarri et al., 2025).

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

Та же дисциплина для многоподразделочных систем

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

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

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

Где происходят вычисления

Выбор механизма — это лишь половина проблемы, поскольку вычисления также должны где-то выполняться. У локальных устройств, инфраструктуры типа edge и облачных платформ есть свои преимущества и ограничения, и исследования в области совместных вычислений рассматривают возможность распределения нагрузки между ними вместо того, чтобы предполагать, что вся работа должна выполняться исключительно в одном месте (Zhou et al., 2019; Ren et al., 2023).

Ничто здесь не работает во всех случаях. Работа в локальной среде автоматически не делает процесс быстрее, поскольку аппаратное обеспечение конечных узлов может быть слабым, тогда как настроенный облачный сервис выполняет задачу быстрее. Работа в облаке также автоматически не является лучшим решением, поскольку задержки сети, пропускная способность, чувствительность данных или требования к времени работы могут изменить баланс. Вопросы конфиденциальности сложнее, чем простое утверждение «локально — значит конфиденциально». Хранение необработанных данных на устройстве сокращает объем передаваемых данных, однако промежуточные представления, создаваемые в процессе разделенного или совместного анализа, могут всё равно раскрывать конфиденциальную информацию. Хиггинс и соавторы (2025) исследуют риски реконструкции и анализа в условиях разделенного обучения.

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

Пример из практики защиты от мошенничества

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

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

Уровень 0: фильтрация и сортировка

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

Уровень 1: координация и объяснение

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

Это важно, поскольку использование языковой модели внутри системы не требует передачи ей контроля над системой. Слой оркестрации может ограничивать область действия моделей, данные, которые они могут видеть, и действия, доступные им далее. Он также может разделять анализ и объяснение: сначала формируются структурированные доказательства, а затем полученные результаты преобразуются в понятный язык.

Слой 2: специализированные аналитические агенты

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

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

Что показало демонстрационное решение

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

Было упущено несколько аспектов: полный рабочий процесс производственной среды уровня 0, прямая интеграция с Microsoft 365 или Google Workspace, OCR в производственных условиях, федеративное обучение, обнаружение локальных аномалий с использованием VAE, выводы в рамках конфиденциальных вычислений для обработки медиаконтента, а также обнаружение глубоких фейков аудио или видео. Объем работ имеет значение. Демонстрация концепции показывает, что такой рабочий процесс осуществим. Однако она ничего не говорит о точности в производственных условиях, масштабируемости или преимуществах полноценной трехуровневой архитектуры.

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

У сложности есть цена

Гетерогенная архитектура — это не бесплатно:

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

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

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

Начните с самой задачи

Прежде чем выбирать модель, лучше сначала ответить на ряд более простых вопросов:

• Не сможет ли точное правило, сравнение или поиск выполнить работу? Если да, возможно, вовсе не потребуется использование методов инференса.
• Является ли задача достаточно узкой и регулярно повторяющейся, чтобы оправдать привлечение специалиста?
• Действительно ли для нее требуется семантическое обоснование или широкая генерализация?
• Где можно обрабатывать данные без нарушения ограничений по задержкам, безопасности или конфиденциальности?
• Что происходит, если выбранный механизм неверен, и можно ли безопасно улучшить рабочий процесс?
• Если рассматривается несколько агентов, имеют ли они разные обязанности, инструменты или данные, или же одна задача разбивается на части лишь потому, что это кажется более сложным?

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

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

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

Упомянутые исследования

• Чен, Захария и Цзоу (2024): FrugalGPT — использование каскадных языковых моделей для снижения затрат
• Онг и др. (2025): RouteLLM — обучение выбору маршрута между моделями на основе данных предпочтений
• Динг и др. (2025): BEST-Route — адаптивное маршрутизирование с использованием вычислительных ресурсов во время тестирования
• Пехер, Срба и Биеликова (2025): небольшие специализированные модели против крупных универсальных моделей для классификации текста
• Биццарри и др. (2025): обзор нейросимволических ИИ для обнаружения вторжений в сети
• Шэнь и др. (2024): многоагентный агент для обучения инструментам
• Ванг и др. (2024): улучшает ли многогранное обсуждение между агентами рассуждения ЯЗЫКОВЫХ МОДЕЛЕЙ
• Ли и др. (2024): редкая топология коммуникации в многогранных дебатах
• Чжоу и др. (2019) и Рэнь и др. (2023): обзоры технологий интеллекта на периферии и совместной интерпретации нейронных сетей

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