От жёстких токенов к читаемым схемам: как малые языковые модели управляют функциями автомобиля

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

Выбор способа представления функций автомобиля для языковой модели оказывается критичнее, чем количество параметров: компактная модель в 270M может не уступать 1,7B-модели на знакомых командах, но способность понимать новые функции определяется вовсе не размером.

Проблема: как маленькой модели управлять автомобилем

Голосовой ассистент в современном автомобиле — это не ChatGPT с неограниченными ресурсами. Он работает на встроенном процессоре, где память считается в мегабайтах, а задержка ответа измеряется миллисекундами. Пользователь говорит «включи кондиционер на 22 градуса» — и система должна за доли секунды превратить эту фразу в точный вызов функции setClimateControl(targetTemp: 22).

Именно здесь в игру вступают малые языковые модели (SLM, Small Language Models) — компактные нейросети, которые можно запустить прямо на устройстве, без обращения к облаку. Вопрос, который исследователи из числа авторов статьи на arXiv попытались прояснить: как лучше «показать» модели список доступных функций?

Два подхода: жёсткие токенчики vs. читаемые схемы

В работе рассматриваются две принципиально разные архитектурные стратегии.

Functional Tokens (FT) — подход, при котором каждая функция автомобиля (открыть окно, настроить обогрев сиденья, переключить радиостанцию) кодируется отдельным специальным токеном. Модель учит на этапе обучения, что токен #47 означает «открыть водительское окно», токен #48 — «открыть пассажирское» и так далее. Плюс очевиден: короткий контекст, быстрый вывод. Минус — столь же очевиден: функция, которой модель не видела при обучении, для неё просто не существует.

Schema-in-Prompt (SIP) — альтернативный подход, где список доступных функций описывается прямо в промпте в виде читаемых схем (по сути, JSON-подобных описаний с названиями параметров и их типами). Модель видит не мёртвый токен, а человекочитаемое описание: «setWindow(window: driver|passenger, position: open|close)». Это длиннее и дороже при инференсе, зато модель потенциально способна работать с функциями, которых не было в обучающей выборке.

Компромисс между этими подходами — классическая инженерная дилемма между специализацией и обобщаемостью. Новая работа пытается дать на неё количественный ответ.

Бенчмарк: 79 функций Android Automotive, почти 10 000 примеров

Авторы собрали бенчмарк из 9 822 примеров, покрывающих 79 функций автомобиля на базе Android Automotive. В набор данных включены как функции, которые модель видит при обучении, так и «held-out» — зарезервированные, невидимые функции для проверки обобщающей способности. Отдельная категория — запросы, на которые модель должна отказаться (out-of-scope requests), потому что запрашиваемая функция недоступна в данной конфигурации автомобиля.

Это важный момент: реальный пользователь может попросить машину сделать что-то, что она физически не умеет. Адекватный отказ — не менее ценный навык, чем правильное выполнение команды.

Главный результат: масштаб — не главное

Исследователи протестировали четыре модели размером от 270 миллионов до 1,7 миллиарда параметров, обученные одинаковым образом (fine-tuning) на обоих подходах.

Результаты на знакомых функциях парадоксальны: увеличение модели от 270M до 1,7B практически не даёт прироста точности. Более того, пик эффективности наблюдается на модели с ~600M параметров. Это указывает на то, что задача преобразования фиксированного набора команд в вызовы функций не требует колоссальных вычислительных ресурсов — она достаточно структурирована, чтобы с ней справлялась компактная модель.

На held-out функциях картина резко меняется. Functional Tokens по определению дают нулевую точность — модель буквально не имеет токена для функции, которую не видела. Schema-in-Prompt, напротив, показывает способность к обобщению, и эта способность растёт с увеличением модели. Для заказчиков автопрома, которые выпускают новые модели автомобилей с обновлённым набором функций, это критически важное различие.

Ещё один нюанс: на запросах вне области (out-of-scope) Functional Tokens могут «галлюцинировать» — вызвать функцию, которую модель когда-то знала, но которой нет в данной конкретной комплектации автомобиля. Schema-in-Prompt ведёт себя надёжнее: если функция не указана в схеме промпта, модель скорее откажется от вызова.

Цена гибкости: память и задержка

Авторы не скрывают, что SIP-подход дороже. Более длинный промпт с описаниями всех 79 функций занимает значительную часть контекстного окна, увеличивает потребление памяти и время инференса. В автомобильном контексте, где процессор не может потреблять десятки ватт, а ответ нужен «ещё вчера», это реальное ограничение.

Теоретический анализ в работе объясняет, почему именно так: длина контекста линейно влияет на вычислительные затраты внимания (attention), и для моделей с ограниченным контекстным окном длинные схемы могут просто «не поместиться».

Для производителей автомобилей это означает, что выбор архитектуры — не чисто академическое упражнение. Если функциональность автомобиля статична и не меняется после продажи, FT может быть оправдан. Если же OTA-обновления добавляют новые функции (а в современных электромобилях это происходит постоянно), гибкость SIP оказывается важнее экономии на памяти.

Что это значит на практике

Исследование имеет несколько практических следствий, которые стоит учитывать инженерам и продакт-менеджерам.

Во-первых, гонка за параметрами в сегменте on-device ИИ не всегда оправдана. Модель в 270M параметров, обученная на конкретном домене, может справляться не хуже модели в шесть раз крупнее — при условии, что набор задач фиксирован.

Во-вторых, представление данных (data representation) часто важнее архитектуры модели. Это старый урок из классического машинного обучения, который нейросетевой бум на время отодвинул на второй план, но который продолжает работать.

В-третьих, безопасность автомобильного ИИ — это не только про «не врежься в стену», но и про корректный отказ от невозможных действий. Система, которая пытается открыть люк на автомобиле без люка, — это не просто ошибка, это потенциальная уязвимость.

Ограничения исследования

Бенчмарк построен на Android Automotive — платформе, которая хоть и распространена, но не единственная на рынке. Как поведут себя выводы на QNX, Linux Automotive или проприетарных решениях отдельных автопроизводителей — вопрос открытый.

Кроме того, в реальном автомобиле голосовой запрос — лишь верхушка айсберга. Перед вызовом функции система должна разрешить эллипсис («включи» — что именно?), мультитёрн-диалог («теперь потеплее» после предыдущего запроса на кондиционирование) и множество других лингвистических нюансов. Однораундовый бенчмарк — полезная, но всё же упрощённая модель реальности.

Наконец, конкретные цифры латентности и потребления памяти для SIP на разных размерах моделей в аннотации не приводятся — эти данные нужно смотреть в полном тексте статьи. Без них сложно оценить, насколько «дорого» обходится гибкость в абсолютных величинах.

Работа заслуживает внимания как методичный эксперимент в области, которая станет критически важной по мере распространения встроенных ИИ-ассистентов в автомобилях. Главный вывод — неожиданно простой и в то же время часто игнорируемый: способ, которым модель «видит» свои возможности, определяет её поведение сильнее, чем то, сколько миллиардов параметров она в себя вмещает.