Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Маленькие локальные модели справились с большей частью задач агентной системы домашней автоматизации без заметного проигрыша облачным моделям. В живом Wactorz облако оставили только для планирования и генерации кода: результат совпал с полностью облачной схемой, а расходы составили 28%, хотя препринт не рецензирован и все числа получили сами авторы. Значит, модель стоит выбирать не для агента целиком, а для каждого типа вызова.
Пять вызовов оказались пятью разными задачами
Точка вызова — это место в программе, где агент обращается к LLM с определённой задачей и форматом ответа. В Wactorz таких точек пять: маршрутизация намерения, классификация действия, сопоставление запроса с реестром устройств, построение плана и генерация Python-кода.
Первые задачи требуют короткой метки или небольшого структурированного ответа. Последняя должна написать рабочий асинхронный код для незнакомого программного интерфейса. Если обслуживать их одной моделью, её приходится выбирать по самой сложной задаче, хотя чаще она решает более простые.
Работа University of West Attica, Waldiez PC и ThinGenious PC сравнила девять моделей на 280 сценариях из двух действующих установок Home Assistant — домашней и офисной. Локальные Qwen3.5 и Gemma4 сопоставили с облачными Claude Haiku 4.5 и Claude Sonnet 5. Все модели получали неизменённые рабочие подсказки Wactorz, а запросы к устройствам содержали реальные реестры обеих площадок.
Для каждой точки использовали собственный критерий. Классификаторы должны были вернуть точную метку, планировщик — допустимую схему с правильными идентификаторами, генератор — компилируемый код с нужными асинхронными функциями. При управлении устройствами лишнее действие считалось ошибкой, а запрос к отсутствующему устройству требовал отказа.
Средняя точность скрыла два опасных провала
Если назначить каждой точке лучшую локальную модель, общая точность достигает 91,8% против 95,4% у полностью облачной схемы с Claude Sonnet 5. На всех участках, кроме генерации кода, разница между лучшей универсальной локальной моделью и облачными вариантами оказалась в пределах статистической погрешности.
Размер модели не определял победителя. Более крупная Qwen3.5 уступила младшей версии при выборе устройств, а старшая Gemma4 проиграла более компактной при генерации кода. Поэтому рейтинг, полученный на одном типе вызова, нельзя переносить на весь агент.
Генерация кода стала единственной устойчиво сложной точкой. Локальные модели справлялись с обычным Python, но чаще нарушали особые правила Wactorz: неверно вызывали подписки, создавали обработчики с неподходящей сигнатурой или неправильно управляли жизненным циклом агента. Код мог компилироваться, но в работающей системе читать пустой буфер и молча возвращать неверный результат.
Ещё опаснее выглядела агрегация результатов управления устройствами. Gemma4 E2B выполняла действие в 87,2% запросов к устройствам, которых не было на площадке, тогда как другая маленькая модель отказывалась выполнять любые команды. Обычная точность смешивает эти противоположные сбои: модель либо включает реальный, но не тот прибор, либо становится бесполезной из-за постоянных отказов.
Ограничение ответа списком допустимых идентификаторов не решает проблему. Во многих ошибочных запросах модель выбирала устройство, которое действительно присутствовало в реестре, но не соответствовало команде. Здесь нужно отдельно измерять способность выполнить допустимый запрос и отказаться от невозможного.
Что менять в архитектуре агентной системы
Работа не требует сразу заменять основной модельный слой. Она предлагает сначала разметить точки вызова в уже работающем агенте и проверить каждую на её собственных запросах. Статическое распределение моделей не требует дополнительного маршрутизатора: программа заранее знает, собирается ли она классифицировать команду, строить план или писать код.
- Зафиксировать рабочие подсказки и форматы. Упрощённый тест не покажет, как модель поведёт себя с длинным реестром устройств или внутренним программным интерфейсом.
- Назначить отдельный критерий каждой точке. Для классификации подходит точное совпадение, для кода нужна проверка выполнения, а для физического действия — раздельные оценки исполнения и отказа.
- Переносить вызовы по одному типу. В Wactorz управление устройствами создавало 81% расходов на облачную модель из-за длинного реестра, хотя именно эту задачу уже могла обслуживать локальная модель.
- Проверить схему целиком. Сквозной запуск обнаружил ошибки программного интерфейса и недоступный клиент LLM, которых не мог показать тест отдельного вызова.
Для похожей архитектуры разумная стартовая схема — оставить в облаке генерацию кода и, при необходимости, планирование, а классификацию и привязку к данным проверить на локальных моделях. Экономика будет зависеть не от средней точности, а от частоты вызовов и длины их подсказок.
Точные назначения моделей относятся к Wactorz и двум установкам Home Assistant. Локальные варианты запускали на NVIDIA DGX Spark, каждый сценарий проходили однократно в детерминированном режиме, а живую проверку проводили на домашней установке с человеческой оценкой результата. После смены модели, подсказки или реестра такую таблицу маршрутизации придётся пересчитать.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
