Conclusiones clave
- Alucinación en domótica = dispositivo equivocado activado, estado mal leído, o entidad inexistente referenciada — no un hecho general inventado
- Solución principal: restringir el esquema de function calling del modelo a solo tu lista de entidades real y actual
- Pasar el estado actual del sensor/dispositivo directamente en el prompt, en lugar de dejar que el modelo lo suponga o lo recuerde de un momento anterior de la conversación
- Los modelos pequeños y bien acotados (ver la guía de modelos de lenguaje pequeños) son inherentemente menos propensos a esto que los modelos de propósito general con un conjunto de herramientas amplio y sin restricciones
- Prueba las automatizaciones frente a casos límite (entidades renombradas, dispositivos desconectados) antes de confiar en ellas sin supervisión
Cómo se ve la alucinación en la domótica
Los tres modos de fallo comunes son: activar un dispositivo con nombre similar pero equivocado, actuar sobre un estado de sensor supuesto en lugar de real, y hacer referencia a una entidad que no existe en absoluto en tu configuración.
- Activación del dispositivo equivocado: pedir apagar "la lámpara" cuando tienes varias, y el modelo elige una basándose en una suposición en lugar de pedir aclaración o usar el contexto correctamente.
- Estado supuesto: una automatización actúa como si una ventana estuviera cerrada porque ese es el caso habitual, en lugar de comprobar la lectura real y actual del sensor.
- Entidad inexistente: el modelo hace referencia a un nombre de dispositivo que suena plausible (porque es común en los datos de entrenamiento) pero que nunca se configuró realmente en tu instancia de Home Assistant.
Grounding: restringir a entidades reales
La solución principal es un esquema de function calling que solo expone al modelo tu lista de entidades real y actual — solo puede llamar a funciones de dispositivos que realmente existen, eliminando estructuralmente el modo de fallo de "entidad inventada".
- Genera el esquema de function calling (o la lista de entidades pasada al modelo) dinámicamente a partir del registro de entidades real y actual de Home Assistant, en lugar de una lista escrita a mano o desactualizada que puede desincronizarse a medida que añades/eliminas dispositivos.
- Si tu configuración tiene nombres de entidades ambiguos (varias entidades de "luz"), renómbralas para que sean más distintivas en lugar de confiar en que el modelo las desambigüe correctamente — esto es una solución de configuración, no de prompting, y es más fiable.
- La guía de integración de Home Assistant-Ollama cubre la configuración práctica de conectar Ollama al agente de conversación de Home Assistant, que se encarga automáticamente de gran parte de esta generación de esquemas.
Pasar el estado actual, no un estado supuesto
Las automatizaciones que dependen del estado de un sensor deben consultar la lectura real y actual en el momento de la ejecución, en lugar de confiar en la memoria del modelo de un turno de conversación anterior o en una suposición sobre el estado típico.
- Para cualquier automatización en la que "¿está la ventana abierta?" o "¿está la luz ya encendida?" importe para la decisión, obtén ese estado directamente como parte de la lógica de la automatización, en lugar de confiar en que el modelo lo haya seguido correctamente a lo largo de una conversación.
- Este es un principio general de reducción de la fragilidad de los prompts (ver la guía transversal sobre ese tema), aplicado específicamente al estado del hogar inteligente respaldado por sensores.
- Combinar varias lecturas de sensores (fusión de sensores) antes de actuar también puede reducir que una lectura errónea de un solo sensor influya en una decisión — ver la fusión de sensores en la guía del hogar inteligente.
Probar y detectar errores
Prueba las automatizaciones frente a casos límite — una entidad renombrada, un dispositivo temporalmente desconectado, un comando ambiguo — antes de confiar en que funcionen sin supervisión, de la misma forma en que probarías cualquier lógica de automatización.
- Prueba deliberadamente un comando que haga referencia a una entidad renombrada o eliminada recientemente para confirmar que la automatización falla de forma segura (pide aclaración o no hace nada) en lugar de adivinar un dispositivo con nombre similar.
- Registra las acciones activadas por la automatización durante un período de prueba inicial para poder revisar lo que el modelo realmente hizo frente a lo que pretendías, detectando activaciones erróneas silenciosas antes de que se vuelvan rutinarias.
- Empieza las nuevas automatizaciones impulsadas por LLM con dispositivos de bajo riesgo (iluminación) antes de extender el patrón a dispositivos de mayor riesgo (cerraduras, sistemas de seguridad) donde una acción equivocada tiene más consecuencias.
Preguntas frecuentes
¿En qué se diferencia esto de los consejos generales sobre alucinación de IA?
Los consejos generales de reducción de alucinaciones (ver la guía de alucinaciones de IA) cubren hechos inventados en generación de texto abierta. Este artículo es específico para los modos de fallo de function calling que ocurren cuando un LLM mapea un comando a una acción sobre un dispositivo.
¿Un modelo más pequeño alucina más o menos en este contexto?
Un modelo pequeño bien acotado y restringido a un esquema de function calling específico suele ser menos propenso a esto que un modelo de propósito general con un conjunto de herramientas amplio y sin restricciones — ver la guía de modelos de lenguaje pequeños para entender por qué.
¿Puedo eliminar por completo las activaciones de dispositivos equivocados?
No por completo, pero restringir el esquema de function calling a tu lista de entidades real y actual, usar nombres de entidades distintivos, y probar casos límite reduce significativamente la tasa de fallo — trátalo como una reducción de riesgo, no como una garantía.
¿Debería dejar que un LLM controle cerraduras y sistemas de seguridad?
Empieza con dispositivos de menor riesgo (iluminación) para generar confianza en la fiabilidad de tu configuración específica antes de extender el control por LLM a dispositivos de mayor consecuencia como las cerraduras — esta es una decisión de gestión de riesgo, no un requisito técnico.
¿La integración de Ollama de Home Assistant gestiona el grounding de entidades automáticamente?
Genera dinámicamente la lista de entidades disponibles a partir de tu configuración actual para el agente de conversación, lo que gestiona gran parte del grounding descrito aquí — ver la guía de integración de Home Assistant + Ollama para los detalles de configuración.
¿Qué debería hacer una automatización si no puede identificar con confianza la entidad correcta?
Fallar de forma segura — pedir aclaración o no hacer nada — en lugar de adivinar una entidad con nombre similar. Esta es una decisión de diseño sobre cómo estructuras la lógica de function calling de la automatización.