Как LLM управляют умными устройствами: технический разбор Function Calling, проблемы отказа и инженерные решения

Когда ваш умный дом начинает спорить с вами

Вы говорите "включи свет в гостиной", а ваш ИИ-ассистент отвечает: "Я понимаю, что вы хотите включить свет, но сначала давайте обсудим энергосбережение и влияние искусственного освещения на циркадные ритмы". Знакомо? Это не баг. Это фундаментальная проблема архитектуры LLM, которая в 2026 году все еще не решена полностью.

Function Calling: как LLM на самом деле взаимодействуют с миром

В 2026 году все крупные модели — GPT-4.5, Claude 3.5 Sonnet, Gemini 2.0 Ultra — поддерживают Function Calling (или Tool Calling, как его теперь чаще называют). Но мало кто понимает, что происходит под капотом.

Механика вызова функций

Когда вы говорите "поставь температуру 22 градуса", модель не выполняет команду. Она анализирует контекст и решает: "Ага, пользователь хочет изменить температуру. У меня есть функция set_temperature. Нужно ее вызвать с параметрами".

# Пример Function Calling с GPT-4.5 (2026 год)
import openai
from typing import List, Dict

# Определяем функции, доступные модели
functions = [
    {
        "name": "set_temperature",
        "description": "Установить температуру в указанной комнате",
        "parameters": {
            "type": "object",
            "properties": {
                "room": {
                    "type": "string",
                    "enum": ["living_room", "bedroom", "kitchen", "bathroom"]
                },
                "temperature": {
                    "type": "integer",
                    "minimum": 16,
                    "maximum": 30
                }
            },
            "required": ["room", "temperature"]
        }
    }
]

# Запрос к модели
response = openai.chat.completions.create(
    model="gpt-4.5-turbo",
    messages=[{"role": "user", "content": "Сделай в гостиной 22 градуса"}],
    functions=functions,
    function_call="auto"
)

# Модель возвращает JSON для вызова функции
if response.choices[0].message.function_call:
    function_name = response.choices[0].message.function_call.name
    arguments = json.loads(response.choices[0].message.function_call.arguments)
    # Теперь ВЫ вызываете реальную функцию
    result = call_device_function(function_name, arguments)

Ключевой момент, который все пропускают: LLM никогда не выполняет функции напрямую. Она только генерирует JSON. Выполнение — ваша ответственность. Это архитектурное решение, а не ограничение.

Проблема отказа: почему ваш умный дом вдруг становится философом

Refusal — сознательный отказ модели выполнить запрос — стал главной головной болью для инженеров IoT. Особенно после того, как в 2025 году все крупные провайдеры усилили безопасность моделей.

Типичные сценарии отказа

• "Включи все приборы на максимум" → "Я не могу выполнить эту команду, так как она может привести к перегрузке сети"
• "Выключи отопление на неделю" → "Это может привести к замерзанию труб. Давайте обсудим альтернативные решения"
• "Открой входную дверь" → "По соображениям безопасности я не могу открывать наружные двери без подтверждения"

Проблема в том, что отказ часто избыточен. Модель отказывается выполнять безопасные команды, потому что видит в них потенциальную угрозу. И делает это на основе своего обучения, а не реального контекста вашего дома.

Архитектура агента: как заставить LLM делать, а не рассуждать

В 2026 году никто не подключает LLM напрямую к устройствам. Все используют архитектуру агентов с четким разделением ответственности.

1 Слой оркестрации

Первое, что встречает пользовательский запрос. Его задача — понять намерение и выбрать правильный workflow. Не путать с LLM — это детерминированный код.

class Orchestrator:
    def __init__(self):
        self.intent_classifier = IntentClassifier()
        self.workflows = {
            "climate_control": ClimateWorkflow(),
            "lighting": LightingWorkflow(),
            "security": SecurityWorkflow(),
            "entertainment": EntertainmentWorkflow()
        }
    
    def process_request(self, user_input: str, context: Dict) -> Dict:
        # 1. Классифицируем намерение (можно использовать маленькую модель)
        intent = self.intent_classifier.predict(user_input)
        
        # 2. Выбираем workflow
        if intent in self.workflows:
            return self.workflows[intent].execute(user_input, context)
        
        # 3. Если намерение не распознано — передаем LLM
        return self.fallback_to_llm(user_input, context)

2 Слой LLM с constrained decoding

Здесь LLM работает, но с ограничениями. Мы используем технику constrained decoding — модель может генерировать только определенные структуры.

# Пример с использованием Guidance (актуально на 2026)
import guidance

# Определяем шаблон, который МОЖЕТ генерировать модель
guidance_template = """
{{#system}}Вы — ассистент умного дома. Вы можете выполнять только эти действия:
- Включить/выключить устройство
- Изменить температуру
- Установить таймер
- Получить статус

Вы НЕ МОЖЕТЕ:
- Обсуждать философию
- Давать советы по энергосбережению
- Отказываться без причины
{{/system}}

{{#user}}{{user_input}}{{/user}}

{{#assistant}}
{{#select "action"}}действие=включить устройство{{or}}действие=выключить устройство{{or}}действие=изменить температуру{{or}}действие=установить таймер{{or}}действие=получить статус{{/select}}

{{#if (equal action "изменить температуру")}}
Температура: {{gen "temperature" pattern="[0-9]+"}}
Комната: {{select "room" options=rooms}}
{{/if}}
{{/assistant}}
"""

# Модель физически не может сгенерировать отказ
program = guidance(guidance_template)
result = program(user_input=user_input, rooms=["гостиная", "спальня", "кухня"])

3 Слой валидации и безопасности

Перед выполнением любой команды — проверка. Этот слой не доверяет LLM вообще.

class SafetyValidator:
    def __init__(self, home_config):
        self.config = home_config
        self.max_power = home_config["max_power"]
        self.security_zones = home_config["security_zones"]
    
    def validate_command(self, command: Dict, context: Dict) -> bool:
        # 1. Проверка на перегрузку
        if command["type"] == "power_on":
            current_power = self.get_current_power_usage()
            device_power = self.get_device_power(command["device"])
            if current_power + device_power > self.max_power:
                return False
        
        # 2. Проверка безопасности
        if command["type"] == "unlock" and command["zone"] in self.security_zones:
            # Требуем дополнительное подтверждение
            if not context.get("security_override", False):
                return False
        
        # 3. Проверка на абсурдность
        if command["type"] == "set_temperature":
            if command["value"] < 10 or command["value"] > 35:
                return False
        
        return True

Практические решения проблем 2026 года

За последний год сообщество выработало несколько работающих подходов к интеграции LLM с IoT.

Решение 1: Двухэтапная обработка запросов

Сначала маленькая быстрая модель классифицирует запрос. Только сложные запросы идут в большую LLM.

# Используем DistilBERT для классификации (быстро и дешево)
from transformers import pipeline

classifier = pipeline("text-classification", 
                     model="distilbert-base-uncased-finetuned-smart-home",
                     device="cuda")

# Классифицируем запрос
classification = classifier(user_input)[0]

if classification["label"] == "SIMPLE_COMMAND":
    # Исполняем напрямую через правила
    execute_simple_command(user_input)
elif classification["label"] == "COMPLEX_COMMAND":
    # Отправляем в GPT-4.5
    result = call_llm_with_functions(user_input)
else:
    # Запрос не распознан
    ask_for_clarification()

Решение 2: Контекстное обогащение

LLM отказывается, потому что не знает контекста. Даем ей данные.

# Перед отправкой запроса в LLM собираем контекст
context = {
    "current_time": datetime.now().strftime("%H:%M"),
    "outside_temperature": get_outside_temperature(),
    "room_occupancy": get_room_occupancy(),
    "energy_price": get_current_energy_price(),  # В 2026 году это важно
    "user_preferences": get_user_preferences(),
    "device_status": get_all_devices_status()
}

# Формируем промпт с контекстом
prompt = f"""Текущий контекст:
- Время: {context['current_time']}
- Температура на улице: {context['outside_temperature']}°C
- В гостиной кто-то есть: {context['room_occupancy']['living_room']}
- Стоимость электроэнергии: {context['energy_price']} руб/кВт·ч

Запрос пользователя: {user_input}

Учитывая контекст, что нужно сделать?"""

Решение 3: Фолбэк на детерминированные правила

Когда LLM отказывается или дает странный ответ — переключаемся на правила.

class FallbackSystem:
    def __init__(self):
        self.rules = self.load_rules()
    
    def execute_with_fallback(self, user_input: str):
        try:
            # Пробуем LLM
            llm_result = self.call_llm(user_input)
            
            # Если LLM отказалась или ответ странный
            if self.is_refusal(llm_result) or self.is_nonsense(llm_result):
                # Переключаемся на правила
                return self.execute_rules(user_input)
            
            return llm_result
            
        except Exception as e:
            # LLM упала — правила спасают
            return self.execute_rules(user_input)
    
    def execute_rules(self, user_input: str):
        # Простые регулярки и ключевые слова
        # "включи свет в гостиной" -> light.living_room.on()
        for pattern, action in self.rules.items():
            if re.search(pattern, user_input, re.IGNORECASE):
                return action()
        return "Не понял команду"

Ошибки, которые все еще совершают в 2026

Даже сейчас, с опытом трех лет интеграции LLM в IoT, разработчики наступают на те же грабли.

Что будет дальше? Прогноз на 2027

Сейчас все говорят о мультимодальных моделях. Но для IoT это не главное. Важнее другое:

• Специализированные доменные модели: Не "умная модель всего", а "модель для управления климатом", "модель для безопасности", "модель для энергосбережения". Обученные на реальных данных домов.
• Локальное выполнение: Модели размером 3-7B параметров, которые работают на Raspberry Pi 6. Без облака, без задержек, без проблем с приватностью.
• Предсказуемое поведение: Техники вроде Refusal Steering станут стандартом. Модель будет отказываться только когда действительно нужно.
• Интеграция с планировщиками: LLM будет не просто выполнять команды, а строить планы. "Экономить энергию" → анализирует график тарифов, прогноз погоды, расписание жильцов → составляет оптимальный план на день.

Самая большая иллюзия 2026 года — что одна большая модель решит все проблемы умного дома. Не решит. Потому что ваш дом — не текстовый документ. Это физическая система с сотнями датчиков, исполнительных механизмов и, что самое важное, реальными последствиями ошибок.

Лучшая архитектура сегодня — та, где LLM занимается только тем, что у нее получается хорошо: понимать естественный язык и планировать. А выполнение, безопасность, надежность — это ваша ответственность как инженера. Как в той старой поговорке: "Доверяй, но проверяй". Только в случае с LLM проверяй всегда.