关键要点
- 家庭自动化幻觉＝触发了错误的设备、误读了状态，或引用了不存在的实体——而不是编造了一个通用事实
- 主要解决方法：将模型的函数调用架构限制为仅你真实、当前的实体列表
- 将当前传感器/设备状态直接传入提示词，而不是让模型假设或凭对话早期内容的记忆判断
- 规模小、范围明确的模型（参见小型语言模型指南）相比拥有广泛、不受约束工具集的通用模型，本质上更不容易出现这个问题
- 在信任自动化无人监督运行之前，先针对边缘情况（重命名的实体、离线设备）进行测试
家庭自动化中的幻觉长什么样
三种常见的失败模式是：触发一个名称相似但错误的设备、依据假设而非实际的传感器状态行动，以及引用一个在你的设置中根本不存在的实体。
- 触发错误设备：要求关闭"台灯"，而你实际上有好几盏台灯，模型基于猜测而不是澄清或正确使用上下文来选择其中一盏。
- 假设状态：自动化认为窗户是关闭的，因为这是常见情况，而不是检查传感器的实际当前读数。
- 不存在的实体：模型引用了一个听起来合理（因为在训练数据中常见）但实际上从未在你的Home Assistant实例中设置过的设备名称。
锚定：限制为真实实体
主要的解决方法是使用一个函数调用架构，始终只向模型暴露你真实、当前的实体列表——它只能为真正存在的设备调用函数，从结构上消除了"凭空捏造实体"这种失败模式。
- 从Home Assistant的实际当前实体注册表动态生成函数调用架构（或传给模型的实体列表），而不是使用手写或过时的列表，后者会随着设备的增删而逐渐失步。
- 如果你的设置中有含糊的实体名称（多个"灯"实体），应将它们重命名得更具区分度，而不是依赖模型正确地消除歧义——这是配置层面的修复，而非提示词层面的修复，也更可靠。
- Home-Assistant-Ollama集成指南介绍了将Ollama连接到Home Assistant对话代理的实际设置方法，该代理会自动处理大部分这类架构生成工作。
传入当前状态，而非假设状态
依赖传感器状态的自动化应在执行时查询实际的当前读数，而不是依赖模型对更早对话轮次的记忆或对典型状态的假设。
- 对于任何"窗户是否打开"或"灯是否已经开着"会影响决策的自动化，应将该状态作为自动化逻辑的一部分直接获取，而不是相信模型在整个对话过程中正确追踪了它。
- 这是减少提示词脆弱性的通用原则（参见关于该主题的跨系列指南）在传感器支持的智能家居状态上的具体应用。
- 在采取行动前结合多个传感器读数（传感器融合）也可以减少单一传感器误读影响决策的情况——参见智能家居指南中的传感器融合部分。
测试与捕捉错误
在信任自动化无人监督运行之前，应像测试任何自动化逻辑一样，针对边缘情况——重命名的实体、暂时离线的设备、含糊的命令——进行测试。
- 有意测试一个引用了近期被重命名或删除的实体的命令，以确认自动化能安全失败（要求澄清或不采取任何行动），而不是猜测一个名称相似的设备。
- 在初始试用期内记录自动化触发的操作，以便你能比较模型实际做了什么与你的预期，在静默的误触发变成常态之前发现它们。
- 新的LLM驱动自动化应先从低风险设备（照明）开始，再扩展到高风险设备（门锁、安防系统），因为在后者上错误操作的后果更严重。
常见问题
这与通用的AI幻觉建议有什么不同？
通用的幻觉减少建议（参见AI幻觉指南）涵盖了开放式文本生成中编造的事实。本文专门针对LLM将命令映射到设备操作时出现的函数调用失败模式。
在这种场景下，较小的模型幻觉更多还是更少？
一个范围明确、被限制在特定函数调用架构内的小型模型，通常比拥有广泛、不受约束工具集的通用模型更不容易出现这个问题——具体原因请参见小型语言模型指南。
我能完全消除错误设备触发吗？
不能完全消除，但将函数调用架构限制为你真实的当前实体列表、使用有区分度的实体名称并测试边缘情况，能显著降低失败率——把它当作风险降低，而不是保证。
我应该让LLM控制门锁和安防系统吗？
在将LLM控制扩展到门锁等后果更严重的设备之前，先从风险较低的设备（照明）开始，以建立对你具体设置可靠性的信心——这是一个风险管理上的选择，而非技术要求。
Home Assistant的Ollama集成会自动处理实体锚定吗？
它会为对话代理从你当前的设置中动态生成可用实体列表，这处理了这里描述的大部分锚定工作——具体设置细节请参见Home Assistant + Ollama集成指南。
如果自动化无法确信地识别出正确的实体，它应该怎么做？
应安全失败——要求澄清或不采取任何行动——而不是猜测一个名称相似的实体。这是你如何构建自动化函数调用逻辑的设计选择。