Аргументы за локальный арбитр
От функций потребительских агентов всё чаще ожидают отклика в темпе человеческого взаимодействия: обработка слова-активатора, оценка направления взгляда, сенсорное слияние, классификация коротких текстов. Эти шаги чувствительны к задержке и работают с данными, которые либо непрерывны (аудио, движение, кадры камеры), либо достаточно персональны, чтобы их отправка на удалённый узел создавала поверхность утечки данных без ощутимой функциональной выгоды. Круговые рейсы в облако накладывают затраты, хвостовую задержку и границу приватности, которую большинству этих шагов пересекать не нужно.
Агент, работающий только удалённо, также отказывает в офлайне. Для ассистента уровня устройства офлайн-поведение — не деградированный режим, а базовое требование. Если арбитр не может обработать слово-активатор или локальную классификацию без сетевого перехода, функция недоступна в самолёте, в лифте или в перегруженной соте. Арбитр существует, чтобы удерживать короткие шаги локально и делать эскалацию явным, проверяемым решением.
Что решает арбитр
Арбитр маршрутизирует по классу задачи, а не по отдельному запросу. Работоспособное разделение:
- Остаётся локально. Обработка слова-активатора, детекция голосовой активности, слияние данных о взгляде и сенсоров, короткая классификация, поиск эмбеддингов по небольшому локальному индексу, а также форматирование или переходы состояний, зависящие только от недавнего локального контекста.
- Эскалируется. Шаги, которым нужен длинный контекст, более крупная модель или инструмент, недоступный устройству (удалённый индекс поиска, API платежей или бронирования, общее хранилище состояния для нескольких пользователей).
Правило маршрутизации должно быть закодировано как политика, а не как эвристика, погребённая в коде приложения. Объект политики объявляет для каждого класса задачи разрешённые цели выполнения, максимальный локальный контекст, класс приватности и поведение при отказе, когда локальная цель недоступна. Приложение запрашивает у арбитра решение и получает цель плюс код причины. Это делает разделение инспектируемым и тестируемым и не позволяет благонамеренной ветке функции тихо отправить буфер микрофона на удалённый узел.
Конкретный механизм: представить каждый шаг как небольшой дескриптор с полями для класса задачи, оценённого бюджета токенов или кадров, требуемых инструментов, класса приватности и дедлайна. Арбитр оценивает дескриптор относительно возможностей устройства (доступная локальная модель, свободная память, тепловое состояние, достижимость сети) и возвращает одно из local, remote или defer. Решение и его входные данные логируются для каждого запуска. Без этого журнала разделение невоспроизводимо; с ним эскалацию можно воспроизвести и объяснить.
Ограничения, формирующие разделение
Потолок памяти и тепловой бюджет. Смартфон может выполнить лишь столько локальных шагов, прежде чем начнёт троттлить. Арбитру нужно рассматривать тепловой запас как вход первого класса, а не как запоздалую мысль. Когда устройство нагрето, правильное поведение обычно — удержать самые дешёвые локальные шаги локально, а остальные отложить или эскалировать, вместо того чтобы выполнять всё и позволить планировщику деградировать весь конвейер. Это реальный компромисс: эскалация под тепловым давлением увеличивает облачные затраты и задержку именно тогда, когда пользователь наиболее склонен это заметить, но выполнение локальных шагов в состоянии троттлинга даёт худшую и менее предсказуемую задержку.
Расхождение версий моделей. Модель на устройстве и модель на сервере расходятся. Если разделение не записывается для каждого запуска — какая модель обслуживала какой шаг и в какой версии — изменение поведения нельзя атрибутировать. Запись воспроизводимости должна фиксировать решение арбитра, идентификатор и версию модели для каждого выполненного шага и действующую ревизию политики. Это разница между отлаживаемой системой и системой, которая ведёт себя правильно только на машине, где была собрана.
Классификация приватности до сериализации. Классификация приватности должна происходить до сериализации полезной нагрузки, а не после. Как только буфер закодирован в тело запроса, классификация становится свойством транспорта, а не данных, и принимать на её основе решение о маршрутизации уже поздно. Сначала классифицируйте дескриптор шага; затем решайте; затем сериализуйте только то, что выбранной 
оработке.
Тестирование разделения
Разделение — это системная граница, поэтому ему нужна собственная оценка. Важны три практики.
Измеряйте локальный путь отдельно от эскалированного. Единая агрегированная доля успеха скрывает тот факт, что локальная модель может отказывать именно на тех случаях, которые эскалируются. Сообщайте об успехе задачи по каждому пути и по каждому классу задач внутри каждого пути. Если доля успеха локального пути стабильна, но частота эскалации растёт, локальная модель деградирует или распределение входных данных сместилось.
Инструментируйте частоту эскалации как метрику первого класса. Частота эскалации — самый ясный сигнал о здоровье локальной модели. Растущая частота означает, что устройство всё больше опирается на облако, что меняет затраты, задержку и экспозицию приватности. Отслеживайте её по классу задач и по уровню устройства и устанавливайте порог для проверки, а не порог для оповещения: смысл в том, чтобы заметить дрейф прежде, чем он станет проблемой затрат или соответствия требованиям.
Симулируйте офлайн и условия деградированной сети как стандартные сценарии оценки. Офлайн — не крайний случай для ассистента уровня устройства. Прогоны оценки должны включать: полностью офлайн, сеть с высокой задержкой, доступная, но обрывающаяся посреди шага. Путь defer арбитра и его поведение при отказе нужно упражнять, а не предполагать. Шаг, который эскалируется, а затем теряет сеть, должен отказать определённым образом, и это определение принадлежит набору оценок.
Честный компромисс
Разделение с приоритетом локальности не бесплатно. Поддержание локальной модели в актуальном состоянии означает поставку обновлений модели, управление различиями в возможностях уровней устройств и принятие того, что некоторые шаги будут обслуживаться меньшей моделью, чем могло бы предложить облако. Арбитр добавляет слой решений, который сам должен быть протестирован, а его политика должна версионироваться вместе с моделями. Альтернатива — агент, работающий только удалённо — проще в создании и легче поддерживается в согласованном состоянии, но он отказывает в офлайне, добавляет круговой рейс к каждому короткому шагу и расширяет поверхность утечки данных. Для потребительских ассистентов на устройствах локальный арбитр — более защитимое значение по умолчанию, при условии что разделение записывается, измеряется и рассматривается как инженерная граница, а не как деталь реализации.