智能家居的自动化水平长期依赖固定规则，例如“日落开灯”或“门磁触发报警”。这类规则在单一条件下表现稳定，但当多个事件叠加时，系统往往会做出违背用户预期的动作。场景理解要解决的核心问题，是把来自温度、光照、人体红外、门窗磁、摄像头等设备的数据，转化为具有语义的事件，再基于当前家庭状态推理出下一步动作。这个过程中，AI推理不是简单地替代规则，而是补充规则无法覆盖的模糊场景。
一、场景理解：从原始数据到语义事件
传感器上报的原始数据通常是数值或布尔状态，例如光照强度为35 lux，人体红外为true，门磁状态为closed。这些数值本身不携带“有人回家”“夜晚降临”等语义。场景理解的第一层是事件抽象，也就是把连续或离散的原始信号映射为可解释的事件。通常可以定义事件结构，包含事件类型、发生时间、置信度和来源设备。
在代码实现上，可以维护一个事件队列，由规则或轻量分类模型产生事件。例如，光照强度低于阈值并持续一段时间，就生成“光线变暗”事件；人体红外与门磁open在短时间内先后出现，可以生成“有人进入”事件。这里的关键不是单一阈值，而是时间窗口和联合条件，因为传感器噪声很容易造成误判。
class Event:
def __init__(self, event_type, confidence, source):
self.event_type = event_type
self.confidence = confidence
self.source = source
def detect_dark(light_value, duration_seconds, threshold=40):
if light_value < threshold and duration_seconds > 3:
return Event("dark", min(0.95, 0.5 + duration_seconds * 0.05), "light_sensor")
return None
上述代码只展示了最基础的事件生成逻辑。实际系统中，事件抽象还需要考虑传感器校准差异。同一个家庭里，阳台和客厅的光照传感器即使在相同照度下读数也可能不同。可以在部署时对每个传感器做基线校准，或者使用相对变化率替代绝对阈值。这样场景理解模块在不同户型中的迁移成本会更低。
上下文融合是场景理解的第二层。它负责把多个事件放入同一个时间窗口内，判断它们是否构成一个更高级的场景。比如“有人进入”加“光线变暗”可能意味着用户下班回家，需要打开玄关灯；但如果电视正在播放且窗帘已关闭，系统则应保持当前状态。上下文信息包括当前时间、家庭成员位置、设备状态、历史行为等。
二、决策引擎：规则与概率推理的组合
规则推理适合处理明确的因果关系，优点是透明、可解释、响应快。但在智能家居中，很多场景并没有非黑即白的触发条件。例如用户躺在床上玩手机时，人体红外可能长时间不动，系统若只靠规则判断“无移动即离开”就会错误关闭空调。此时需要概率推理来综合多个弱信号，给出带置信度的决策。
一个轻量的做法是使用朴素贝叶斯或加权评分。系统为每个候选动作计算得分，动作包括开灯、关灯、调节空调、打开窗帘等。每个事件或上下文对动作产生正向或负向影响，最后选择得分最高且超过阈值的动作执行。这样即使某个传感器误报，也不会直接触发错误动作。
import math
def score_action(action, events, context):
weights = {
"open_light": {"dark": 1.5, "person_enter": 2.0, "sleeping": -3.0},
"close_curtain": {"dark": 1.2, "watch_tv": 1.8, "morning": -2.0},
}
score = 0.0
for evt in events:
score += weights.get(action, {}).get(evt.event_type, 0) * evt.confidence
if context.get("is_sleeping"):
score -= 1.0
return 1 / (1 + math.exp(-score))
上面的加权评分可以理解为一种简化版的推理。当事件置信度高且多个事件指向同一动作时，sigmoid输出接近1；出现矛盾事件时，分数被抵消。相比直接写固定if-else，这种方式更容易维护，也方便后续加入学习到的参数。对于规模更大的系统，可以引入决策树或梯度提升模型，但部署复杂度会明显增加。
概率推理的另一个优势是可以输出不确定度，用于后续的确认机制。例如当“打开空调”的置信度在0.6到0.8之间时，系统可以先执行温和动作，比如调整为低风速，而不是直接全功率制冷。这种渐进式响应能显著减少用户的被打扰感。
三、边缘推理落地：性能与隐私的平衡
智能家居场景对延迟和隐私要求较高。把音视频数据上传到云端推理，虽然可以利用更强的算力，但会带来网络延迟和隐私泄露风险。边缘推理将模型部署在家庭网关或带NPU的智能音箱上，数据不出局域网即可完成场景理解。常见的硬件包括树莓派、带神经网络加速的SoC，以及支持TFLite Micro的MCU。
边缘设备的资源有限，部署模型前通常需要进行量化或剪枝。对于基于规则和轻量模型的混合方案，大部分事件抽象和评分可以在CPU上完成，只有图像识别等重负载任务需要NPU。举例来说，人体检测可以使用HOG特征加SVM，在树莓派上达到实时；而人脸识别则建议使用量化后的MobileNet。这样整个推理链路在家庭网关上即可闭环。
隐私保护方面，边缘推理本身已经减少了原始数据外传。但还需要注意，本地日志中不要记录敏感视频帧，事件队列中只保留语义事件和必要的传感器读数。对于语音助手，唤醒词检测在本地完成，语音命令识别可以本地或按用户授权上传。设计时可以把“数据最小化”作为默认原则。
四、调试与优化：处理误报和场景冲突
AI推理上线后，误报是首要问题。常见的误报来源包括传感器延迟不一致、时间窗口设置不当以及事件定义过宽。调试时建议先记录所有原始事件和最终决策，回放分析是哪一步导致错误。例如发现“有人进入”事件频繁在宠物经过时触发，可以加入移动目标尺寸或红外触发时长的限制。
场景冲突是另一个难点。比如用户手动打开了窗帘，系统却因为“光线变暗”事件自动关闭了窗帘，形成对抗。解决办法是在决策引擎中引入手动操作的优先级，或在一段时间内抑制相关自动动作。可以在上下文中加入“用户最近手动操作”字段，当该字段为true时，自动决策需要更高阈值才可执行。
最后，任何推理系统都需要监控和迭代。可以为每个动作记录执行后的用户反馈，比如用户是否立即撤销。这些隐式反馈可以作为后续调整权重的依据。初期保持规则为主、概率为辅，逐步过渡到更多学习能力，是风险较低的实施路径。