Почему ваш умный дом все еще тупой?
Представьте: вы заходите в промозглый подъезд, руки заняты пакетами, а ключи где-то на дне рюкзака. Было бы круто просто сказать колонке: «Открой дверь, включи свет в прихожей и поставь чайник, но только если я один и температура на балконе ниже +5». В 2026 году такое должно работать. Но на практике большинство голосовых ассистентов живет в мире жестких сценариев: «Включи свет» — да, «Если я пришел домой и темно, включи свет» — уже нет. Проблема не в железе, а в архитектуре понимания естественного языка. SberDevices с ГигаЧатом пошли по другому пути — не через дообучение (SFT) под каждый сценарий, а через контекстное обучение (in-context learning) прямо в момент запроса. Как это работает и как собрать такой пайплайн самому — разбираемся.
Ключевая идея: вместо сотен тысяч размеченных примеров для каждой команды — один умный промпт, который видит текущее состояние дома и историю диалога. Это ускоряет разработку в 10 раз и позволяет обрабатывать сценарии, которые не закладывали дизайнеры.
Анатомия запроса: от голоса к сценарию
Когда пользователь говорит: «Включи свет в зале, если меня нет дома больше часа», пайплайн ассистента должен пройти несколько этапов:
- ASR (Automatic Speech Recognition) — превращаем аудио в текст.
- NLU — извлекаем намерение (intent) и сущности (entities). В нашем случае: устройство = свет, комната = зал, условие = отсутствие > 1 часа, действие = включить.
- Контекстный слой — собираем текущее состояние: а где я сейчас? (далеко ли от дома?) есть ли в зале кто-то? температура?
- LLM с in-context learning — формируем сценарий в формате сценарной машины.
- Исполнение — отправляем команды на устройства.
Кажется, что шаги 2 и 4 можно объединить. Но в SberDevices сделали хитрее: NLU выдает гипотезу, а финальную упаковку в сценарий берет на себя LLM. Почему? Потому что NLU не умеет обрабатывать сложные условия и временные зависимости. Например, «если меня нет больше часа» NLU выбьет в слот condition=absence, duration=60, но как это скомбинировать с «включить свет» — только LLM.
Контекстное обучение вместо SFT: почему это выстрелило
До 2025 года стандартный подход к обучению ассистента создавать сценарии был таким: собираем датасет из 100 тысяч примеров «запрос-сценарий», дообучаем модель (SFT), релизим. Проблема: каждый новый тип условия (например, «если влажность > 70%» или «если в доме тишина») требует новой разметки. SberDevices перешли на in-context learning. В промпт зашиваются 3-5 примеров сценариев в JSON-формате, а также текущий контекст умного дома (список устройств, их статусы, датчики). Модель на лету учится генерировать правильную структуру.
# Пример промпта (упрощенно)
prompt = f"""Ты — сценарный ассистент умного дома.
Устройства пользователя: {devices_json}
Текущие значения датчиков: {sensors_json}
Примеры сценариев:
Запрос: "Включи кондиционер, если температура выше 25"
Ответ: {{"trigger": {{"type": "temperature", "device": "thermometer_1", "condition": ">25"}}, "action": {{"type": "turn_on", "device": "ac_1"}}}}
Запрос: "Выключи свет в спальне через 10 минут"
Ответ: {{"trigger": {{"type": "timer", "value": 600}}, "action": {{"type": "turn_off", "device": "light_bedroom"}}}}
Теперь обработай запрос пользователя:
"{user_query}"
Ответ (только JSON):"""
Обратите внимание: нет жестких правил «если» — модель сама решает, какой тип триггера использовать. Это позволяет обрабатывать запросы вроде «сделай так, чтобы, когда я вхожу, свет загорался, но не слепил» (тут уже нужна мягкая настройка яркости — тоже через JSON).
Сценарная машина: не просто команды, а композиция
Сценарий умного дома — это не одна команда, а связка триггер -> условие -> действие (+ возможно пост-действие). SberDevices используют собственную сценарную машину, которая умеет выполнять JSON-сценарии, полученные от LLM. Она проверяет:
- Существуют ли устройства из сценария в аккаунте пользователя?
- Корректны ли типы триггеров (таймер, датчик, геозона)?
- Нет ли циклических условий (включи свет, когда я зашел -> включился свет -> засветило в глаза -> пользователь ругается)?
Если LLM сгенерировала что-то невалидное (а она может), сценарная машина не падает — она возвращает ошибку с указанием проблемы, и ассистент просит переформулировать запрос. Этот feedback loop — важная часть пайплайна. Без него пользователь просто услышит «Извините, что-то пошло не так» и разочаруется.
Warning: Никогда не доверяйте LLM исполнение команд напрямую. Всегда проверяйте, что сгенерированный сценарий не содержит опасных действий: «включи чайник на 24 часа» или «открой дверь незнакомцу». Сценарная машина должна иметь белый список действий и лимиты.
Ошибка, которая сломает ваш пайплайн: перегрузка контекста
Самая частая проблема при контекстном обучении — потеря контекста из-за переполнения окна токенов. Если в промпт пихать всю историю диалогов и состояние всех 50 устройств дома, LLM начнет галлюцинировать или просто игнорировать условия. Решение от SberDevices: динамическая фильтрация контекста. В текущий момент отправляются только устройства, релевантные запросу (по результатам NLU), и последние 3-5 реплик диалога. Остальное — в долговременной памяти (база знаний ассистента).
Пример запроса, который сожрет контекст: «А помнишь, вчера я просил настроить сценарий для гостиной и еще для кухни? Сделай так же, но для спальни». Без работы с долговременной памятью LLM не вспомнит вчерашние сценарии. В SberDevices это решается через Agent Skills — специальный слой, который умеет вызывать функции для извлечения истории. Подробнее об этом подходе мы писали в статье Agent Skills: как заставить ИИ-агента не тупить и помнить все инструкции.
Как НЕ надо делать: монолитная тонкая настройка
Допустим, вы решили не заморачиваться с промптами и контекстом, а просто натренировать модель на тысячи примеров «запрос-сценарий». Выглядит надежно, но на практике:
- Проблема распределения: 80% запросов — банальное «включи/выключи». Модель переобучится на простые сценарии и начнет отказываться от сложных условий.
- Сложность обновления: Добавили новый тип датчика (например, CO2) — собирайте заново 10 000 примеров с CO2, дообучайте, тестируйте, выкатывайте. Это недели.
- Отсутствие контекста: Модель не знает, какие устройства реально есть у пользователя. Она может сгенерировать сценарий для «кондиционера в ванной», хотя там нет кондиционера.
In-context learning решает все три проблемы за счет того, что контекст (список устройств) подставляется динамически, а примеры в промпте задают лишь структуру, а не конкретные названия.
Пошаговый план: как собрать свой пайплайн
1 Определите формат сценария
Выберите JSON-схему для триггеров, условий и действий. Пример:
{
"trigger": {"type": "sensor", "sensor_id": "temp_1", "condition": "<15"},
"action": {"type": "turn_on", "device_id": "heater_2"},
"post_action": {"type": "notification", "text": "Включен обогреватель"}
}
Сделайте валидатор — он же сценарная машина.
2 Соберите NLU и контекстный слой
NLU вытаскивает устройства и намерения. Контекстный слой подтягивает состояние этих устройств и датчиков. В SberDevices за это отвечает отдельный микросервис, который кеширует последние показания. Если данных нет (например, новый датчик), запрос уходит в фоновое обновление с задержкой ответа.
3 Разработайте промпт с примерами
Берите 3-5 примеров, покрывающих основные кейсы: таймер, датчик, геозона, комбинация условий. Используйте Chain-of-Thought — попросите модель сначала объяснить, что она поняла, а потом выдать JSON. Это повышает точность на 10-15%.
4 Организуйте цикл проверки и обратной связи
Сценарная машина после парсинга JSON запускает проверки. Если ошибка — сообщите LLM, что именно не так, и попросите перегенерировать (с новым контекстом). Этот механизм похож на подход GUI-агентов, которые учатся на ошибках (см. GUI-агенты: как они видят, думают и учатся на наших ошибках).
5 Добавьте логирование и A/B тесты
Не все сценарии будут идеальными с первого раза. Логируйте запросы пользователей, сгенерированные JSON и результаты выполнения. Используйте для улучшения промпта. Со временем накопите пулл примеров, который можно превратить в SFT, но на старте это лишнее.
Подводные камни: что взрывается в продакшене
- Галлюцинации идентификаторов устройств. LLM может выдумать device_id, которого нет. Решение: после генерации заменять названия на реальные ID через маппинг.
- Конкурентные сценарии. Пользователь просит «включай свет, когда я вхожу» и «выключай свет, когда я вхожу» — сценарная машина должна уметь разрешать конфликты (обычно по приоритету последнего).
- Задержка выполнения. Запрос через LLM занимает 1-2 секунды, плюс парсинг JSON и исполнение. При голосовом интерфейсе каждая секунда на счету. SberDevices решили это асинхронностью: пользователю сразу говорят «Сценарий создается» и выполняют в фоне.
- Неоднозначные условия. «Если холодно» — что значит холодно? Нужно подтягивать настройки пользователя или спрашивать уточнение. В пайплайне можно добавить тургенсивное уточнение: «Уточните, какая температура считается холодной?».
Почему контекстное обучение — это не серебряная пуля
In-context learning уменьшает количество размеченных данных, но требует качественных примеров в промпте и продуманного контекстного слоя. Если модель плохо держит контекст (например, старая версия GPT-3.5), она будет путать примеры и пользовательские запросы. SberDevices используют собственные модели семейства GigaChat, которые уже имеют достаточное окно токенов (128K) и хорошо обучены на русском языке. Для тех, кто строит ассистента с нуля, подойдет вариант с кастомной платформой на базе open-source LLM с дообучением на контекстных примерах. О выборе между готовыми ассистентами и собственной разработкой мы писали в кейсе OpenAI Assistants против кастомной платформы: кейс построения сложных AI-агентов для EdTech.
Будущее: от сценариев к автономным агентам
Когда LLM научилась создавать сценарии по голосовым запросам, следующий шаг — позволить ей самой предлагать сценарии на основе поведения пользователя. «Я заметил, что вы каждый день в 8 утра включаете кофеварку. Хотите автоматизировать?» — это уже не сценарий, а проактивность. Здесь нужен отдельный слой анализа, напоминающий метод «Принудительных связей» для креативных решений, но адаптированный под умный дом (см. Метод «Принудительных связей»).
Технически это означает переход от реактивного пайплайна к проактивному: ассистент регулярно собирает данные, анализирует их с помощью LLM и предлагает новые сценарии через push-уведомления. Нагрузка на инфраструктуру растет, но пользовательский опыт выходит на другой уровень. SberDevices уже тестируют такую фичу в закрытой бете.
Если вы хотите глубже разобраться в механизмах function calling, которые лежат в основе исполнения сценариев, рекомендую прочитать отдельный материал: Как LLM управляют умными устройствами: технический разбор Function Calling, проблемы отказа и инженерные решения.
