Wichtigste Erkenntnisse
- Halluzination in der Hausautomation = falsches Gerät ausgelöst, falsch gelesener Zustand oder referenzierte nicht existierende Entität — keine erfundene allgemeine Tatsache
- Wichtigste Lösung: Function-Calling-Schema des Modells auf nur deine echte, aktuelle Entitätsliste beschränken
- Aktuellen Sensor-/Gerätezustand direkt in den Prompt übergeben, statt das Modell ihn früher im Gespräch annehmen oder sich daran erinnern zu lassen
- Kleine, gut eingegrenzte Modelle (siehe den Leitfaden zu kleinen Sprachmodellen) neigen von Natur aus weniger dazu als Allzweckmodelle mit einem breiten, unbeschränkten Toolset
- Automatisierungen gegen Grenzfälle testen (umbenannte Entitäten, offline Geräte), bevor du ihnen unbeaufsichtigt vertraust
Wie sich Halluzination in der Hausautomation zeigt
Die drei häufigsten Fehlermodi sind: Auslösen eines ähnlich benannten, aber falschen Geräts, Handeln nach einem angenommenen statt tatsächlichen Sensorzustand und Referenzieren einer Entität, die in deiner Konfiguration überhaupt nicht existiert.
- Falsches Gerät ausgelöst: Du bittest, "die Lampe" auszuschalten, obwohl du mehrere Lampen hast, und das Modell wählt eine basierend auf einer Vermutung, statt nachzufragen oder den Kontext korrekt zu nutzen.
- Angenommener Zustand: Eine Automatisierung handelt, als sei ein Fenster geschlossen, weil das der übliche Fall ist, statt die tatsächliche aktuelle Sensormessung zu prüfen.
- Nicht existierende Entität: Das Modell referenziert einen Gerätenamen, der plausibel klingt (weil er in den Trainingsdaten häufig vorkommt), aber in deiner Home-Assistant-Instanz nie tatsächlich eingerichtet wurde.
Grounding: Auf echte Entitäten beschränken
Die wichtigste Lösung ist ein Function-Calling-Schema, das dem Modell immer nur deine echte, aktuelle Entitätsliste offenlegt — es kann nur Funktionen für Geräte aufrufen, die tatsächlich existieren, wodurch der Fehlermodus "erfundene Entität" strukturell ausgeschlossen wird.
- Erzeuge das Function-Calling-Schema (bzw. die dem Modell übergebene Entitätsliste) dynamisch aus Home Assistants tatsächlichem aktuellem Entitätsregister, statt aus einer handgeschriebenen oder veralteten Liste, die beim Hinzufügen/Entfernen von Geräten aus dem Takt geraten kann.
- Wenn deine Konfiguration mehrdeutige Entitätsnamen hat (mehrere "Licht"-Entitäten), benenne sie eindeutiger um, statt dich darauf zu verlassen, dass das Modell korrekt disambiguiert — das ist eine Konfigurationslösung, keine Prompting-Lösung, und zuverlässiger.
- Der Leitfaden zur Home-Assistant-Ollama-Integration behandelt die praktische Einrichtung der Verbindung von Ollama mit Home Assistants Konversations-Agent, der einen Großteil dieser Schema-Generierung automatisch übernimmt.
Aktuellen Zustand übergeben, nicht angenommenen Zustand
Automatisierungen, die vom Sensorzustand abhängen, sollten die tatsächliche aktuelle Messung zum Ausführungszeitpunkt abfragen, statt sich auf die Erinnerung des Modells an einen früheren Gesprächsschritt oder eine Annahme über den typischen Zustand zu verlassen.
- Bei jeder Automatisierung, bei der "ist das Fenster offen" oder "ist das Licht schon an" für die Entscheidung wichtig ist, hole diesen Zustand direkt als Teil der Automatisierungslogik ab, statt darauf zu vertrauen, dass das Modell ihn über ein Gespräch hinweg korrekt verfolgt hat.
- Dies ist ein allgemeines Prinzip zur Reduktion von Prompt-Brüchigkeit (siehe den clusterübergreifenden Leitfaden zu diesem Thema), speziell angewendet auf sensorgestützten Smart-Home-Zustand.
- Das Kombinieren mehrerer Sensormessungen (Sensorfusion) vor dem Handeln kann ebenfalls verringern, dass ein einzelner Fehlmessung in eine Entscheidung einfließt — siehe die Sensorfusion im Smart-Home-Leitfaden.
Testen und Fehler erkennen
Teste Automatisierungen gegen Grenzfälle — eine umbenannte Entität, ein vorübergehend offline Gerät, einen mehrdeutigen Befehl —, bevor du ihnen zutraust, unbeaufsichtigt zu laufen, genauso wie du jede andere Automatisierungslogik testen würdest.
- Teste bewusst einen Befehl, der eine kürzlich umbenannte oder entfernte Entität referenziert, um zu bestätigen, dass die Automatisierung sicher fehlschlägt (nach Klärung fragt oder nichts tut), statt bei einem ähnlich benannten Gerät zu raten.
- Protokolliere automatisierungsausgelöste Aktionen während einer anfänglichen Testphase, damit du überprüfen kannst, was das Modell tatsächlich getan hat im Vergleich zu deiner Absicht, und stille Fehlauslösungen erkennst, bevor sie zur Routine werden.
- Starte neue LLM-gesteuerte Automatisierungen bei risikoarmen Geräten (Beleuchtung), bevor du das Muster auf risikoreichere ausweitest (Schlösser, Sicherheitssysteme), wo eine falsche Aktion mehr Konsequenzen hat.
Häufig gestellte Fragen
Wie unterscheidet sich das von allgemeinen Hinweisen zur KI-Halluzination?
Allgemeine Hinweise zur Halluzinationsreduktion (siehe den Leitfaden zu KI-Halluzinationen) behandeln erfundene Fakten in offener Textgenerierung. Dieser Artikel ist spezifisch für die Function-Calling-Fehlermodi, die auftreten, wenn ein LLM einen Befehl auf eine Geräteaktion abbildet.
Halluziniert ein kleineres Modell in diesem Kontext mehr oder weniger?
Ein gut eingegrenztes kleines Modell, das auf ein spezifisches Function-Calling-Schema beschränkt ist, neigt oft weniger dazu als ein Allzweckmodell mit einem breiten, unbeschränkten Toolset — siehe den Leitfaden zu kleinen Sprachmodellen für die Gründe.
Kann ich falsche Geräteauslösungen vollständig eliminieren?
Nicht vollständig, aber die Beschränkung des Function-Calling-Schemas auf deine echte aktuelle Entitätsliste, die Verwendung eindeutiger Entitätsnamen und das Testen von Grenzfällen reduzieren die Fehlerrate erheblich — betrachte es als Risikoreduktion, nicht als Garantie.
Sollte ich ein LLM Schlösser und Sicherheitssysteme steuern lassen?
Beginne mit risikoärmeren Geräten (Beleuchtung), um Vertrauen in die Zuverlässigkeit deiner spezifischen Konfiguration aufzubauen, bevor du die LLM-Steuerung auf folgenreichere Geräte wie Schlösser ausweitest — das ist eine Risikomanagement-Entscheidung, keine technische Anforderung.
Übernimmt Home Assistants Ollama-Integration das Entitäts-Grounding automatisch?
Sie erzeugt die Liste verfügbarer Entitäten dynamisch aus deiner aktuellen Konfiguration für den Konversations-Agenten, was einen Großteil des hier beschriebenen Groundings übernimmt — siehe den Leitfaden zur Home-Assistant-Ollama-Integration für die Einrichtungsdetails.
Was sollte eine Automatisierung tun, wenn sie die richtige Entität nicht sicher identifizieren kann?
Sicher fehlschlagen — nach Klärung fragen oder nichts tun —, statt bei einer ähnlich benannten Entität zu raten. Das ist eine Designentscheidung dafür, wie du die Function-Calling-Logik der Automatisierung strukturierst.