Активировать мало - недостаточно: зачем AI-роутеру альтернативные стратегии
В предыдущем материале я рассматривал генеративные модели как интеллектуальных оппонентов. Вместо просьбы подтвердить первое решение им можно поручить поиск условий, при которых это решение окажется неверным. Такой подход постепенно привёл меня к более широкому вопросу: почему AI-система обычно стремится как можно раньше выбрать один-единственный путь, если задача допускает несколько вариантов, цена ошибки неизвестна, а лучшим решением иногда становится отказ от действия?
Особенно наглядно проблему показывает развитие разреженных моделей. В техническом отчёте о Qwen3.8-Flash-Next описана MoE-система со 125 млрд параметров, из которых примерно 6 млрд активируются для обработки одного токена. Дополнительно модель использует крупные таблицы n-граммных представлений - около 51 млрд параметров, размещённых вне ускорителя, в оперативной памяти хоста.
Смысл такой архитектуры прост: модель располагает большой общей ёмкостью, но на каждом шаге задействует только часть ресурсов. Это напоминает крупную инженерную организацию, где для решения конкретной задачи не требуется собирать всех сотрудников одновременно. Если обсуждается качество видеопотока, достаточно привлечь специалистов по инфраструктуре, сетям и обработке изображений.
В MoE эту функцию выполняет роутер. Он определяет, какие эксперты будут обрабатывать текущее представление токена, после чего их результаты возвращаются в общий вычислительный поток. Подобный принцип не нов: например, Switch Transformer использовал маршрутизацию к одному эксперту, стремясь увеличить ёмкость модели без пропорционального роста вычислений для каждого входа.
Однако условная активация не означает, что вся модель помещается в небольшом объёме видеопамяти. Все веса нужно где-то хранить и своевременно доставлять, а итоговые затраты зависят от длины контекста, кешей, пропускной способности памяти и обмена данными между компонентами. Поэтому эффективность AI-архитектуры следует оценивать не по одному показателю активных параметров, а по работе системы целиком.
Здесь возникает важное смысловое различие. Слово "эксперт" легко создаёт образ независимого специалиста: один предлагает построить мост, другой ищет брод, третий оценивает риски, а четвёртый задаёт вопрос, нужно ли вообще переходить реку. Но эксперты стандартной MoE-модели не обязаны быть самостоятельными собеседниками. Обычно это похожие вычислительные блоки, которые обучались внутри единой системы. Роутер выбирает фрагменты параметров, но не обязательно организует соревнование полноценных планов действий.
Иными словами, выбор вычислений - ещё не выбор стратегии. Первый процесс отвечает на вопрос "какие параметры сейчас использовать?". Второй - на вопрос "что делать дальше, если возможны разные сценарии, последствия плохо известны, а уверенность в исходных данных невысока?".
Именно поэтому AI-роутер для бизнеса может оказаться не просто механизмом распределения запросов между моделями. В прикладной системе ему потребуется учитывать стоимость вызова, требования к задержке, конфиденциальность данных, критичность результата и необходимость дополнительной проверки. В таком случае интеллектуальный роутинг LLM должен выбирать не только подходящую модель, но и режим работы.
Один из возможных режимов - быстрый. Он подходит для типовых задач с низкой ценой ошибки: классификации, извлечения структурированных данных, подготовки короткого ответа или первичной обработки пользовательского запроса. Другой режим можно назвать альтернативным: система формирует несколько независимых вариантов решения, сопоставляет их и оценивает расхождения.
Третий режим - проверочный. В нём одна модель предлагает ответ, а другая ищет слабые места, пропущенные ограничения и контрпримеры. Четвёртый - режим воздержания. Если входных данных недостаточно или уверенность слишком мала, система не должна искусственно производить убедительный текст. Она может запросить уточнение, отложить действие или передать задачу человеку.
Так появляются альтернативные стратегии AI-роутера. Они не обязательно требуют нескольких совершенно разных моделей. Иногда достаточно изменить инструкцию, включить повторную проверку, увеличить число независимых рассуждений или выбрать другой порядок обработки. Но для критичных сценариев могут понадобиться разные архитектуры: быстрая компактная модель для фильтрации, специализированная модель для анализа документов и более мощная система для сложных случаев.
Есть и практическая сторона вопроса. Маршрутизация запросов между нейросетями должна учитывать не только качество ответа, но и цену ошибки. Дешёвая модель может быть оптимальной для большинства обращений, однако один неверный результат в финансовом, медицинском или юридическом процессе способен перечеркнуть всю экономию. Поэтому оптимизация затрат на использование нейросетей не сводится к выбору самого недорогого вызова. Нужно учитывать стоимость повторных проверок, ручной обработки и исправления последствий.
Дополнительная сложность связана с тем, что разные стратегии могут конфликтовать. Быстрый ответ уменьшает задержку, но снижает глубину анализа. Независимые варианты повышают шанс обнаружить ошибку, однако увеличивают расходы. Передача человеку обеспечивает контроль, но плохо масштабируется. Следовательно, роутер должен оптимизировать не одну метрику, а баланс между скоростью, стоимостью, надёжностью и уровнем риска.
На практике полезно хранить не только итоговый ответ, но и сведения о маршруте: какие модели участвовали, почему был выбран определённый режим, насколько расходились варианты и в какой момент потребовалось вмешательство человека. Такая трассировка помогает оценивать систему после запуска и обнаруживать классы задач, на которых первоначальная схема маршрутизации работает плохо.
При этом доверять подобным механизмам безоговорочно пока рано. Модель может формально создать несколько вариантов, но фактически повторить одну и ту же ошибку разными словами. Несогласие между ответами не всегда означает наличие полезной альтернативы, а уверенный тон не является доказательством корректности. Поэтому систему необходимо тестировать на специально подготовленных наборах с неоднозначными условиями, неполными данными и заранее известными ловушками.
Моя гипотеза состоит в том, что следующий этап развития AI-систем связан с маршрутизацией не только вычислений, но и способов действия. MoE уже показывает, как экономно выбирать активную часть большой модели. Следующий шаг - научить систему выбирать между быстрым ответом, поиском альтернатив, проверкой, воздержанием и передачей задачи человеку. Это не отменяет классическую архитектуру, но расширяет её назначение: роутер становится не просто диспетчером параметров, а координатором разных режимов принятия решений.
Такой подход особенно важен для реальных проектов, где правильный ответ - лишь одна из возможных целей. Иногда нужно минимизировать задержку, иногда - исключить риск, а иногда - честно признать, что автоматике не хватает информации. Активировать подходящего эксперта мало. Важно ещё понять, какую стратегию следует применить, когда её остановить и кто должен принять решение в случае неопределённости.
