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
- Une liste d'entités restreinte compte plus que la taille du modèle : la documentation Ollama de Home Assistant note que les petits modèles se trompent plus souvent — associez tout modèle à une liste d'entités bien délimitée et choisissez-en un qui prend en charge l'appel d'outils (voir le guide sur les petits modèles de langage)
- 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.
- Dans Home Assistant, le modèle ne peut agir que sur les entités que vous lui exposez (Paramètres > Assistants vocaux > Exposer) ; exposer peu d'entités, choisies délibérément, réduit donc l'ensemble des mauvaises réponses possibles. L'option « Contrôler Home Assistant » de l'intégration Ollama est documentée comme expérimentale, exige un modèle compatible avec les outils et utilise par défaut une fenêtre de contexte de 8k que les grandes maisons devront peut-être augmenter.
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.
Réduire les hallucinations LLM : la liste courte
Les techniques générales contre les hallucinations LLM — ancrer le modèle dans des données réelles, contraindre sa sortie, vérifier avant d'agir et échouer en sécurité — ont chacune une forme directe en domotique avec Home Assistant.
- Ancrer dans des données réelles : la version domotique de la récupération consiste à passer la liste d'entités et les états actuels dans le contexte du modèle, au lieu de se fier à ce qu'il a retenu de l'entraînement.
- Contraindre la sortie : utilisez l'appel d'outils (function calling) pour que le modèle ne puisse renvoyer qu'un appel vers une entité et un service existants, et non du texte libre qu'un script doit ensuite interpréter.
- Réduire la surface : n'exposez que les entités que vous voulez contrôler. Home Assistant exige que les entités soient exposées à Assist avant d'être pilotables, et sa documentation Ollama recommande d'exposer moins de 25 entités lors des essais.
- Choisir un modèle capable d'appeler des outils : la documentation Ollama de Home Assistant indique que seuls les modèles compatibles avec les outils peuvent piloter la maison, et que les petits modèles se trompent plus souvent que les grands.
- Vérifier et échouer en sécurité : contrôlez l'état de l'entité cible avant d'agir, relisez-le ensuite, et demandez une précision ou ne faites rien si la correspondance est incertaine.
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 ?
Cela dépend du périmètre, pas seulement de la taille. Un petit modèle limité à quelques entités exposées peut gérer des commandes simples, mais la documentation Ollama de Home Assistant note que les petits modèles se trompent plus souvent que les grands, et que seuls les modèles compatibles avec les outils peuvent piloter la maison. Restreignez d'abord la liste d'entités, puis testez le modèle sur vos propres commandes — voir le guide sur les petits modèles de langage.
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.
Comment réduire les hallucinations LLM dans Home Assistant ?
N'exposez que les entités à contrôler, contraignez le modèle à des appels d'outils pour ces entités, transmettez l'état actuel plutôt que de vous fier à sa mémoire, utilisez un modèle compatible avec l'appel d'outils, testez les cas limites et faites échouer l'automatisation en sécurité en cas de doute. Aucune étape ne supprime le risque ; ensemble, elles le réduisent.
Combien d'entités exposer à un LLM dans Home Assistant ?
La documentation de l'intégration Ollama de Home Assistant recommande d'exposer moins de 25 entités lors des essais. Commencez par les quelques appareils que vous voulez vraiment contrôler et ajoutez-en à mesure que la fiabilité est vérifiée. Les entités doivent être exposées explicitement, ce qui évite aussi qu'une serrure ou une porte de garage soit commandée par erreur.