Активировать мало — недостаточно: почему AI-роутеру могут понадобиться альтернативные стратегии

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

Из этой практики вырос вопрос, который уже не относится к организации моей работы.

Почему от самой AI-системы мы так часто ожидаем одного ответа? Почему она должна как можно раньше выбрать единственный маршрут, если задача допускает несколько стратегий, цена ошибки неизвестна, а лучшим действием иногда оказывается отказ от действия?

Свежий выход Qwen3.8-Flash-Next сделал этот вопрос особенно наглядным. Большая модель может хранить огромный объём параметров, но использовать для конкретного токена только небольшую их часть. Это похоже на экономное распределение внимания — и одновременно показывает границу между выбором вычислений и выбором стратегии.

Об этой границе я и хочу порассуждать.

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

Большая модель, малый активный контур

В техническом отчёте авторов Qwen3.8-Flash-Next описана разреженная MoE-модель с 125 миллиардами параметров и примерно 6 миллиардами активных параметров на токен. Дополнительно используются таблицы n-граммных представлений на 51 миллиард параметров, размещённые вне ускорителя, в памяти хоста.

Если отбросить числа, идея выглядит просто. Системе доступна большая ёмкость, но для каждого небольшого шага она использует не всё сразу.

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

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

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

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

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

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

Но здесь легко сделать лишний шаг.

Эксперт внутри MoE — ещё не независимый собеседник

Когда мы слышим слово «эксперт», воображение быстро дорисовывает команду специалистов. Один предлагает построить мост, второй ищет брод, третий оценивает риск, а четвёртый спрашивает, нужно ли вообще переходить реку.

Стандартный MoE не обязан работать именно так.

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

Это важное различие:

MoE-роутер:
какие параметры использовать сейчас?

Роутер стратегий:
какие варианты действия сохранить,
как их проверить и когда не выбирать ни один?

Первый вопрос относится прежде всего к организации вычислений внутри модели. Второй — к принятию решений под неопределённостью.

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

Можно экономно активировать параметры и при этом очень быстро пойти по неверному пути.

Мысленный эксперимент с рекой

Допустим, перед нами река, а цель находится на другом берегу.

Первый очевидный вариант — переплыть. Если течение слабое, расстояние небольшое и человек умеет плавать, это может быть самым быстрым решением.

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

Третий — пройти вдоль берега и найти брод. Мы увеличим путь, но уменьшим риск.

Четвёртый — выяснить, действительно ли нам нужен противоположный берег. Возможно, цель можно достичь иначе.

Пятый — пока не действовать. Например, если неизвестны глубина, скорость течения и прогноз погоды.

У этих вариантов нет универсального рейтинга. Их полезность зависит от контекста:

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

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

Несколько рассуждений — уже известная идея

Я не первый человек, которому пришло в голову не фиксироваться на одной цепочке.

Self-Consistency предлагает сэмплировать несколько путей рассуждения, а затем выбирать наиболее согласованный ответ. Tree of Thoughts рассматривает промежуточные «мысли» как ветви поиска: система может оценивать варианты, смотреть вперёд и возвращаться назад.

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

Ещё раньше появилась идея адаптивного количества вычислений. В работе Adaptive Computation Time сеть училась выделять разное число вычислительных шагов для разных входов.

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

То есть почти все детали моего мысленного конструктора уже лежат на столе:

• разреженная активация параметров;

• несколько траекторий рассуждения;

• маршрутизация между моделями;

• адаптивный вычислительный бюджет;

• оценка неопределённости;

• отказ от ответа.

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

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

Представим систему, которая начинает не с генерации ответа, а с оценки самой задачи.

Её первый компонент пытается определить:

• к какому классу относится запрос;

• насколько обратимо предполагаемое действие;

• какова возможная цена ошибки;

• достаточно ли входных данных;

• сколько вычислений оправданно потратить.

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

После первичной оценки система выбирает режим.

Быстрый режим

Подходит для понятной, обратимой и дешёвой ошибки. Одна ветвь формирует решение, результат проходит минимально необходимую проверку.

Режим альтернатив

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

Режим проверки

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

Режим воздержания

Система сообщает, каких данных ей не хватает, и не маскирует неопределённость правдоподобным текстом.

Передача человеку

Если действие дорого, необратимо или относится к зоне ответственности человека, система готовит варианты и доказательства, но не принимает финальное решение.

В виде упрощённой схемы это выглядит так:

Запрос
  ↓
Оценка типа задачи, цены ошибки и полноты данных
  ├─ низкий риск ─────────────→ быстрый ответ → проверка
  ├─ есть неопределённость ───→ несколько стратегий → сравнение
  ├─ не хватает данных ───────→ уточняющий вопрос
  ├─ высокий риск ────────────→ расширенная проверка → человек
  └─ действие недопустимо ────→ отказ

Мне здесь важно слово «стратегия». Если три агента независимо предлагают один и тот же мост, написанный разными словами, мы не получили три варианта.

Стратегия должна иметь хотя бы пять полей:

action: что предлагается сделать
assumptions: при каких условиях это имеет смысл
required_evidence: какие данные нужны для проверки
cost: время, вычисления или другие ресурсы
risk: что произойдёт при ошибке

Тогда сравнивать приходится уже не тексты, а решения.

Зачем мне разные архитектуры — и почему я им пока не доверяю

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

Но слово «может» здесь принципиально.

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

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

Это подтверждается и исследованиями многомодельных ансамблей. Авторы работы Rethinking Mixture-of-Agents показали, что смешивание разных LLM не всегда полезно: в ряде экспериментов несколько выборок от одной сильной модели превосходили комбинацию разных моделей. Причина выглядит здраво — разнообразие не компенсирует низкое среднее качество автоматически.

С другой стороны, deep ensembles давно используются для оценки неопределённости и устойчивости. Но их ценность тоже проверяется экспериментом, а не выводится из количества участников.

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

Поэтому я бы измерял не факт различия моделей, а структуру их ошибок:

• как часто компоненты ошибаются одновременно;

• возникают ли действительно разные стратегии;

• кто ошибается с высокой уверенностью;

• распознаёт ли проверяющий компонент конфликт;

• улучшается ли итог при учёте стоимости вызовов и задержки.

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

Как это связано с реальными проектами

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

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

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

Эти примеры объединяет не технология. Их объединяет цена преждевременного выбора.

Что именно предстоит проверить

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

1. одна модель и один ответ;

2. роутер, выбирающий одну специализированную ветвь;

3. несколько кандидатов с последующей проверкой;

4. несколько разнородных моделей и отдельный оценщик;

5. адаптивная система с быстрым режимом, уточнением и отказом.

Одной точности будет недостаточно. Я хочу измерять:

• долю правильных решений;

• долю критических ошибок;

• качество оценки уверенности;

• долю корректных отказов;

• корреляцию ошибок между ветвями;

• число действительно разных стратегий;

• задержку, токены и стоимость;

• долю случаев, переданных человеку.

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

Вместо заключения

Архитектуры вроде sparse MoE показывают важное направление: размер доступной модели и объём активных вычислений больше не обязаны расти вместе.

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

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

ответить быстро
рассмотреть альтернативы
проверить глубже
запросить данные
передать человеку
не действовать

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

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

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

Источники

1. On the Design of Qwen3.8-Next Architecture: Evaluation, Efficiency, and Training Stability

2. Switch Transformers: Scaling to Trillion Parameter Models with Simple and Efficient Sparsity

3. Self-Consistency Improves Chain of Thought Reasoning in Language Models

4. Tree of Thoughts: Deliberate Problem Solving with Large Language Models

5. RouteLLM: Learning to Route LLMs with Preference Data

6. FrugalGPT: How to Use Large Language Models While Reducing Cost and Improving Performance

7. Adaptive Computation Time for Recurrent Neural Networks

8. Selective Classification for Deep Neural Networks

9. Rethinking Mixture-of-Agents: Is Mixing Different Large Language Models Beneficial?

10. Simple and Scalable Predictive Uncertainty Estimation using Deep Ensembles