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