Points clés
- Hallucination en domotique = mauvais appareil déclenché, état mal lu, ou entité inexistante référencée — pas un fait général inventé
- Solution principale : contraindre le schéma de function calling du modèle à votre seule liste d'entités réelle et actuelle
- Transmettre l'état actuel du capteur/appareil directement dans le prompt, plutôt que de laisser le modèle le supposer ou s'en souvenir depuis plus tôt dans une conversation
- Les modèles petits et bien cadrés (voir le guide des petits modèles de langage) y sont intrinsèquement moins sujets que les modèles généralistes disposant d'une boîte à outils large et non contrainte
- Tester les automatisations sur des cas limites (entités renommées, appareils hors ligne) avant de leur faire confiance sans supervision
À quoi ressemble l'hallucination en domotique
Les trois modes de défaillance courants sont : déclencher un appareil au nom similaire mais erroné, agir sur un état de capteur supposé plutôt que réel, et référencer une entité qui n'existe pas du tout dans votre installation.
- Déclenchement du mauvais appareil : demander d'éteindre "la lampe" quand vous en avez plusieurs, et le modèle en choisit une sur la base d'une supposition plutôt que de demander une clarification ou d'utiliser correctement le contexte.
- État supposé : une automatisation agit comme si une fenêtre était fermée parce que c'est le cas le plus fréquent, plutôt que de vérifier la lecture réelle et actuelle du capteur.
- Entité inexistante : le modèle référence un nom d'appareil qui semble plausible (parce que courant dans les données d'entraînement) mais qui n'a en réalité jamais été configuré dans votre instance Home Assistant.
Grounding : se contraindre aux entités réelles
La solution principale est un schéma de function calling qui n'expose au modèle que votre liste d'entités réelle et actuelle — il ne peut appeler des fonctions que pour des appareils qui existent réellement, éliminant structurellement le mode de défaillance "entité inventée".
- Générez le schéma de function calling (ou la liste d'entités transmise au modèle) dynamiquement à partir du registre d'entités actuel et réel de Home Assistant, plutôt qu'une liste écrite à la main ou obsolète qui peut se désynchroniser au fil de l'ajout/suppression d'appareils.
- Si votre installation a des noms d'entités ambigus (plusieurs entités "lumière"), renommez-les pour qu'elles soient plus distinctes plutôt que de compter sur le modèle pour désambiguïser correctement — c'est une correction de configuration, pas de prompting, et elle est plus fiable.
- Le guide d'intégration Home Assistant-Ollama couvre la mise en place pratique de la connexion d'Ollama à l'agent de conversation de Home Assistant, qui gère automatiquement une grande partie de cette génération de schéma.
Transmettre l'état actuel, pas un état supposé
Les automatisations qui dépendent de l'état d'un capteur devraient interroger la lecture réelle et actuelle au moment de l'exécution, plutôt que de se fier à la mémoire du modèle d'un tour de conversation antérieur ou à une supposition sur l'état typique.
- Pour toute automatisation où "la fenêtre est-elle ouverte" ou "la lumière est-elle déjà allumée" compte pour la décision, récupérez cet état directement dans la logique de l'automatisation, plutôt que de faire confiance au modèle pour l'avoir correctement suivi au fil d'une conversation.
- Il s'agit d'un principe général de réduction de la fragilité des prompts (voir le guide transversal sur ce sujet), appliqué spécifiquement à l'état de la maison connectée reposant sur des capteurs.
- Combiner plusieurs lectures de capteurs (fusion de capteurs) avant d'agir peut aussi réduire le risque qu'une mauvaise lecture d'un seul capteur influence une décision — voir la fusion de capteurs dans le guide de la maison connectée.
Tester et détecter les erreurs
Testez les automatisations sur des cas limites — une entité renommée, un appareil temporairement hors ligne, une commande ambiguë — avant de leur faire confiance pour fonctionner sans supervision, de la même façon que vous testeriez n'importe quelle logique d'automatisation.
- Testez délibérément une commande qui référence une entité récemment renommée ou supprimée pour confirmer que l'automatisation échoue de manière sûre (demande une clarification ou ne fait rien) plutôt que de deviner un appareil au nom similaire.
- Enregistrez les actions déclenchées par l'automatisation pendant une période d'essai initiale afin de pouvoir vérifier ce que le modèle a réellement fait par rapport à votre intention, en détectant les erreurs de déclenchement silencieuses avant qu'elles ne deviennent routinières.
- Commencez les nouvelles automatisations pilotées par LLM sur des appareils à faible enjeu (éclairage) avant d'étendre le modèle à des appareils à enjeu plus élevé (serrures, systèmes de sécurité) où une action erronée a plus de conséquences.
Questions fréquentes
En quoi est-ce différent des conseils généraux sur l'hallucination IA ?
Les conseils généraux de réduction des hallucinations (voir le guide sur les hallucinations IA) couvrent les faits inventés dans une génération de texte ouverte. Cet article est spécifique aux modes de défaillance du function calling qui se produisent quand un LLM associe une commande à une action sur un appareil.
Un modèle plus petit hallucine-t-il plus ou moins dans ce contexte ?
Un petit modèle bien cadré, contraint à un schéma de function calling spécifique, est souvent moins sujet à cela qu'un modèle généraliste doté d'une boîte à outils large et non contrainte — voir le guide des petits modèles de langage pour comprendre pourquoi.
Puis-je éliminer complètement les déclenchements du mauvais appareil ?
Pas complètement, mais contraindre le schéma de function calling à votre liste d'entités réelle et actuelle, utiliser des noms d'entités distincts et tester les cas limites réduit significativement le taux d'erreur — considérez cela comme une réduction du risque, pas une garantie.
Devrais-je laisser un LLM contrôler les serrures et les systèmes de sécurité ?
Commencez par des appareils à faible enjeu (éclairage) pour bâtir la confiance dans la fiabilité de votre installation spécifique avant d'étendre le contrôle par LLM à des appareils à conséquences plus élevées comme les serrures — c'est un choix de gestion du risque, pas une exigence technique.
L'intégration Ollama de Home Assistant gère-t-elle automatiquement le grounding des entités ?
Elle génère dynamiquement la liste des entités disponibles à partir de votre installation actuelle pour l'agent de conversation, ce qui prend en charge une grande partie du grounding décrit ici — voir le guide d'intégration Home Assistant + Ollama pour les détails de configuration.
Que devrait faire une automatisation si elle ne peut pas identifier avec certitude la bonne entité ?
Échouer de manière sûre — demander une clarification ou ne rien faire — plutôt que de deviner une entité au nom similaire. C'est un choix de conception dans la façon dont vous structurez la logique de function calling de l'automatisation.