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
- Eine enge Entitätsliste zählt mehr als die Modellgröße: Die Ollama-Dokumentation von Home Assistant weist darauf hin, dass kleinere Modelle eher Fehler machen — kombiniere jedes Modell mit einer eng gefassten Entitätsliste und wähle eines, das Tool Calling unterstützt (siehe den Leitfaden zu kleinen Sprachmodellen)
- 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.
- In Home Assistant kann das Modell nur auf Entitäten zugreifen, die du ihm freigibst (Einstellungen > Sprachassistenten > Freigeben). Wenige, bewusst gewählte Entitäten verkleinern daher die Menge möglicher falscher Antworten. Die Option "Home Assistant steuern" der Ollama-Integration ist als experimentell dokumentiert, erfordert ein Modell mit Tool-Unterstützung und nutzt standardmäßig ein 8k-Kontextfenster, das größere Haushalte eventuell erhöhen müssen.
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.
LLM-Halluzinationen reduzieren: die Kurzliste
Die allgemeinen Techniken gegen LLM-Halluzinationen — das Modell an echten Daten verankern, seine Ausgabe einschränken, vor dem Handeln prüfen und sicher fehlschlagen — haben in Home Assistant jeweils eine direkte Smart-Home-Entsprechung.
- An echten Daten verankern: Die Smart-Home-Variante von Retrieval ist, die aktuelle Entitätsliste und die aktuellen Zustände in den Kontext des Modells zu übergeben, statt sich auf sein Trainingswissen zu verlassen.
- Ausgabe einschränken: Nutze Tool-Calling (Function Calling), damit das Modell nur einen Aufruf für eine existierende Entität und einen existierenden Dienst zurückgeben kann — keinen Freitext, den ein Skript erst interpretieren muss.
- Angriffsfläche verkleinern: Stelle nur die Entitäten bereit, die gesteuert werden sollen. Home Assistant verlangt, dass Entitäten für Assist freigegeben werden, bevor sie steuerbar sind, und die Ollama-Dokumentation empfiehlt beim Experimentieren weniger als 25 freigegebene Entitäten.
- Ein Modell mit Tool-Unterstützung wählen: Laut der Ollama-Dokumentation von Home Assistant können nur Modelle mit Tool-Unterstützung das Zuhause steuern, und kleinere Modelle machen eher Fehler als größere.
- Prüfen und sicher fehlschlagen: Prüfe den Zustand der Zielentität vor der Aktion, lies ihn danach zurück und frage nach oder tu nichts, wenn die Zuordnung unsicher ist.
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?
Das hängt vom Umfang ab, nicht allein von der Größe. Ein kleines Modell, das auf wenige freigegebene Entitäten beschränkt ist, kann einfache Befehle bewältigen, doch die Ollama-Dokumentation von Home Assistant weist darauf hin, dass kleinere Modelle eher Fehler machen als größere, und nur Modelle mit Tool-Unterstützung können das Zuhause überhaupt steuern. Grenze zuerst die Entitätsliste ein und teste das Modell dann mit deinen eigenen Befehlen — siehe den Leitfaden zu kleinen Sprachmodellen.
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.
Wie reduziere ich LLM-Halluzinationen in Home Assistant?
Gib nur die Entitäten frei, die gesteuert werden sollen, beschränke das Modell auf Tool-Aufrufe für diese Entitäten, übergib den aktuellen Zustand statt dich auf das Gedächtnis zu verlassen, nutze ein Modell mit Tool-Calling-Unterstützung, teste Grenzfälle und lass die Automatisierung bei Unsicherheit sicher fehlschlagen. Kein einzelner Schritt beseitigt das Risiko; zusammen verringern sie es.
Wie viele Entitäten sollte ich einem LLM in Home Assistant freigeben?
Die Dokumentation der Ollama-Integration von Home Assistant empfiehlt, beim Experimentieren weniger als 25 Entitäten freizugeben. Beginne mit den wenigen Geräten, die du wirklich steuern willst, und ergänze weitere, sobald die Zuverlässigkeit bestätigt ist. Entitäten müssen ausdrücklich freigegeben werden — das verhindert auch, dass Schlösser und Garagentore versehentlich gesteuert werden.