Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Агенты смогли интерпретировать личные данные на устройстве, не отправляя в облако каждое наблюдение. В препринте KAUST и University of Ljubljana, который не прошёл рецензирование и где числа получили сами авторы, гибридная схема повысила долю выполненных задач до 14,9 процентного пункта. Она даёт промежуточный вариант между облачным агентом и полностью локальной системой.
Программа задаёт ход задачи, модель отвечает на узкие вопросы
Облачные агенты часто работают в цикле ReAct: модель вызывает API, читает результат и решает, что делать дальше. Такая схема помогает справляться с многошаговыми задачами, но письма, заметки и другие результаты каждого вызова попадают в контекст облачной модели.
Агент, который сначала пишет код, устроен иначе. Облачная LLM получает запрос и документацию API, создаёт программу на Python и отправляет её на устройство. Программа выполняется рядом с данными, поэтому облаку не нужно читать результаты каждого шага.
Проблема возникает, когда дальнейшее действие зависит от смысла полученных данных. Заранее написанный код может найти фиксированную строку или проверить дату, но не всегда определит, какое письмо относится к поездке или соответствует ли заметка условию пользователя.
Предложенная архитектура добавляет в программу функцию slm, которая вызывает малую языковую модель (SLM) на устройстве. Облако решает, где поставить такой вызов, но не видит данные, переданные функции во время работы. Локальная модель получает один вопрос и ограниченный фрагмент контекста, а не планирует задачу целиком.
Вызов возвращает значение заданного типа: логический ответ, число, строку или один вариант из списка. Программа также может передать только нужные поля записи. Если ответа в контексте нет, функция сообщает об этом вместо того, чтобы придумывать значение, а облачная модель может переписать программу после ошибки.
Узкая роль оказалась посильнее полного локального управления
Архитектуру проверяли на AppWorld — наборе задач, где агент работает с приложениями через API. Тест охватил обычную и усложнённую части набора, несколько облачных моделей Qwen и локальные Qwen размером до 9 млрд параметров. Гибрид сравнивали с облачным ReAct, локальным ReAct и агентом, который исполняет только заранее написанный код.
Максимальный прирост получился в обычной части AppWorld с облачным планировщиком Qwen: доля успешно выполненных задач выросла с 45,8% до 60,7%. Улучшение относительно чистого кода появилось во всех проверенных сочетаниях планировщика и части теста, но на усложнённых задачах разрыв был меньше.
При одинаковой локальной модели гибрид выполнил 52,4% задач, а полностью локальный ReAct — 45,2%. Причина не только в качестве модели: ReAct должен читать результаты всех вызовов и удерживать историю задачи, тогда как slm видит лишь данные, которые передала программа для конкретного вопроса.
Полностью облачный ReAct в части конфигураций оставался точнее. Гибрид также добавлял инструкции для функции slm в запрос к облачной модели, поэтому он расходовал больше облачных токенов, чем агент с чистым кодом. Выигрыш относится прежде всего к локальной обработке и приватности штатного хода задачи, а не к минимальному общему числу токенов.
Для прототипа схема подходит, но границу приватности нужно укрепить
Работа меняет планы команд, которым нельзя передавать пользовательские записи облачной модели, но которым недостаточно правил и поиска по шаблонам. Вместо попытки запустить весь агентный цикл на телефоне можно оставить облаку структуру задачи, а локальной модели поручить классификацию, выбор и извлечение значений.
Для такой роли не обязательно брать крупнейшую модель из теста. В сквозной проверке вариант на 2 млрд параметров давал результат в пределах погрешности относительно старшей локальной модели при каждом облачном планировщике. Это не означает, что модель такого размера справится с самостоятельным агентом: преимущество появляется именно потому, что программа ограничивает вопрос и контекст.
Граница приватности пока не абсолютна. Схема предполагает, что исходный запрос можно отправить в облако, а при сбое туда уходит трассировка ошибки. На сложной части AppWorld личное содержимое оказалось в 0,4% таких исключений, поэтому в продуктовой реализации трассировку придётся очищать на устройстве или заменять формализованным описанием сбоя.
Работа измеряет число токенов и размер контекста, а не задержку, расход батареи и нагрев устройства. Поэтому архитектуру можно брать как основу для прототипа, но выбор локальной модели и экономию ресурсов придётся проверять на целевом оборудовании.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
