Как выбрать полезное действие

Полезность действия зависит от последствий ошибки, доступных измерений и допустимости ожидания. Самый вероятный ответ модели ещё требуется проверить по этим условиям.

От фразы к проверяемой цели#

«Сделай комфортно» недостаточно для автоматического управления. Система должна узнать, о какой величине и зоне идёт речь. Для первого света цель можно выразить так: «когда рабочее место занято, поддерживать не ниже выбранного уровня; не переключать лампу слишком часто; уважать ручное отключение».

Не объявляем нормативный уровень освещённости без назначения помещения и нормативного исследования. В примерах книги используются учебные пороги. У пользователя есть возможность изменить профиль, а приложение показывает физическое ограничение: бинарная лампа не удерживает произвольный точный уровень.

Замкнутый набор вариантов#

Планировщик получает не универсальное право «управлять домом», а набор допустимых предложений. Для кабинета это может быть: включить основную лампу, выключить её, сохранить состояние, запросить измерение, уточнить цель или отказаться. Само множество вариантов формируется кодом по текущим возможностям и правам.

Предложение включает объект, действие, параметры, ожидаемый эффект, неопределённость, срок действия, входной снимок и причину. Исполнитель повторно проверяет условия непосредственно перед отправкой. Между расчётом и действием человек мог нажать кнопку.

Рассмотреть схему

Ожидаемые потери#

В простом варианте выбираем действие, минимизирующее ожидаемую потерю:

$$a^*=\arg\min_{a\in A_{\mathrm{allowed}}}\sum_s P(s\mid o)\,L(a,s).$$

$s$ — возможное состояние, $o$ — наблюдения, $L$ — согласованная цена результата. Если выключить свет при человеке гораздо хуже, чем ненадолго оставить его в пустой комнате, порог выключения должен быть строже порога включения. Это не универсальная моральная шкала, а настройка конкретного безопасного сценария.

Для неизвестной нагрузки «оставить включённой» не является универсальным безопасным выбором. Сначала определяем её класс, локальные ограничения и поведение при отказе. Нагреватель, насос и светильник требуют разных политик.

Неполный и невозможный план#

Когда данные недостаточны, система может выбрать измерение или вопрос. Когда цель физически недостижима доступными устройствами, она должна сказать об этом. Например, одна включённая лампа даёт слишком мало света: многократная отправка ON не исправляет её мощность.

Если пользователь просит включить две лампы, операция не обязана быть физически атомарной. План хранит результат каждой команды. При частичном успехе интерфейс сообщает, что сработало и что осталось неизвестным. Компенсация — отдельное действие, не обещание отката физического времени.

Предложение должно быть объяснимым без рассказа модели#

Основание решения строим из структурных полей: цель, проверенные наблюдения, активные ограничения и выбранный вариант. Языковая модель может переформулировать это для пользователя, но не дописывать несуществующее измерение или эксперимент.

Пример объяснения «Включил основную лампу: рабочее место считается занятым, измерено 160 лк, для этого профиля выбран минимум 280 лк. Ручной запрет не активен. Реле подтвердило включение; датчик показал рост света. Точное достижение цели будет проверено следующим измерением».

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

Два вида ограничений на одном примере#

Пусть пользователь хочет светлее, а модель предлагает включить обе лампы. Запрет гостю управлять второй комнатой — жёсткое ограничение: такое действие вообще не участвует в выборе. Экономия нескольких минут работы доступной лампы — предпочтение: его можно сравнивать с удобством, если владелец задал этот компромисс.

Смешивать эти вещи в одном штрафе опасно для смысла системы. Очень большая ожидаемая полезность не должна «перевесить» отсутствие прав, истёкший срок или аппаратный предел. Сначала код строит множество разрешённых действий; затем регулятор или модель выбирает внутри него.

Один порог стоимости не создаёт гистерезис#

Если сравнивать только ожидаемый ущерб от ON и OFF в одном независимом шаге, обычно получится один порог вероятности, а не два. Гистерезис появляется из памяти состояния, стоимости переключения или явно заданных ограничений dwell. В модели указываем цену недостаточного света за единицу времени, цену лишнего включения за единицу времени и отдельную цену перехода. Иначе частота пересчёта незаметно меняет смысл предпочтений.

Жёсткие права и пределы безопасности отсекают недопустимые действия до сравнения полезности. Неизвестное состояние не обязано вести к оптимистичному выбору: доступны «оставить», «спросить» и «измерить». Команда из общего микрофона не получает приоритет владельца из-за высокого confidence.