> For the complete documentation index, see [llms.txt](https://docs.buildings.ability.abb/collection/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.buildings.ability.abb/collection/german/akademie/building-intelligence-ki-und-maschinelles-lernen-in-buildingpro-suites/maschinelles-lernen/einfuhrung-in-die-anomalieerkennung-in-intelligenten-gebauden/von-gebaudedaten-zu-erkennungsherausforderungen.md). # Von Gebäudedaten zu Erkennungsherausforderungen Ein Facility Manager, der für zehn Gebäude verantwortlich ist, sollte nicht jeden Morgen entscheiden müssen, welche Anomaliealarme echt sind und welche nur Rauschen. Ein Energiemanager sollte nicht erst beim Eintreffen der Quartalsrechnung drei Monate nächtlicher Verschwendung entdecken. Das sind keine Aufmerksamkeitsfehler. Sie entstehen, wenn die Anomalieerkennung nicht für die spezifische Realität von Gebäuden ausgelegt ist. Diese Seite beschreibt diese Realität, die konkreten Arten und Weisen, in denen Gebäudedaten die Erkennung erschweren, die daraus resultierenden Fehlermodi und die Anforderungen, die jeder ernsthafte Ansatz erfüllen muss, um operativ nützlich zu sein und nicht nur technisch vorhanden zu sein. *** ## Von Datenmerkmalen zu Fehlermodi Die Beschreibung eines Datenmerkmals und die Beschreibung, wo die Erkennung schiefgeht, sind zwei verschiedene Dinge. Die vorige Seite, [-> Gebäudedaten verstehen](/collection/german/akademie/building-intelligence-ki-und-maschinelles-lernen-in-buildingpro-suites/maschinelles-lernen/einfuhrung-in-die-anomalieerkennung-in-intelligenten-gebauden/gebaudedaten-verstehen.md), beschrieb Gebäudedaten als multimodal und nicht stationär. Diese Seite fragt: Was genau bricht zusammen, wenn eine Erkennungsmethode damit nicht gut umgeht? ### Fehlermodus 1: Kontextblindheit Eine Methode, die keinen Kontext nutzt, beurteilt jede Beobachtung anhand eines einzigen globalen Verständnisses von Normalität. Das Ergebnis ist in beide Richtungen vorhersehbar. An kalten Wintermorgen steigt der Heizenergieverbrauch stark an. Eine kontextblinde Methode markiert das als Anomalie. In milden Feiertagsnächten läuft das Gebäude mit voller Last, weil niemand den Zeitplan angepasst hat. Eine kontextblinde Methode sieht einen normalen Wert und sagt nichts. Beide Fehler haben reale Kosten. Der erste untergräbt durch Fehlalarme das Vertrauen. Der zweite verpasst genau die Art operativ bedeutsamer Abweichung, die Anomalieerkennung finden soll. Kontextbewusstsein ist keine Verfeinerung. Es ist die Mindestanforderung dafür, dass Erkennung in Gebäuden operativ nützlich ist.

Verhalten eines Merkmals-Only-Modells (ohne historischen Verbrauch als Eingabe). Die Vorhersage stützt sich ausschließlich
auf den Kontext (Zeit/Wochenende), was zu einer stabilen Basislinie und einer genauen Erkennung anhaltender Anomalien
ohne Anpassung führt.

Vorhersageverhalten eines Modells, das ein historisches 24-h-Fenster plus Zeitmerkmale verwendet. Das obere Panel
zeigt Ist- gegenüber Vorhersagewerten; das untere Panel zeigt den differenzbasierten Anomaliescore. Beachten Sie die
sprunghaften Vorhersagen auch nach dem Ende der Anomalie, da die ungesehenen Daten durch das gleitende Fenster wandern

*** ### Fehlermodus 2: Denken in einem einzigen Bereich in einer Welt mit mehreren Modi Viele Gebäudesignale sammeln sich in klaren Betriebszuständen an, statt sich glatt um einen Mittelpunkt zu verändern. Ein Gebäude kann einen unbesetzten Niedriglastmodus und einen besetzten Hochlastmodus haben. Das sind keine kleinen Schwankungen um einen Durchschnitt. Das sind zwei getrennte Regime mit wirklich unterschiedlichen typischen Bereichen.

Empirische Verteilung des Hauptzählers des Gebäudes (15-Minuten-kWh-Werte, Histogramm) mit einer
overlagerten einfachen Normalverteilung und einem Gaußschen Mischmodell mit fünf Komponenten, was die
Diskrepanz zwischen einem unimodalen Gauß-Modell und der multimodalen, schwanzlastigen Struktur realer Gebäude-Energiedaten veranschaulicht.

Ein gutes Beispiel ist der morgendliche Hochlauf. In einigen Gebäuden hängt die genaue Startzeit von Heizung, Lüftung und Klimatisierung (HVAC) davon ab, wann die ersten Personen eintreffen oder wann das Steuerungssystem entscheidet, mit der Vorkonditionierung zu beginnen. Zu einem bestimmten Morgenzeitpunkt kann sich das Gebäude daher in einem von zwei gültigen Zuständen befinden: Entweder hat das System noch nicht gestartet und der Verbrauch ist noch niedrig, oder das System läuft bereits und der Verbrauch ist deutlich höher. Beides kann normal sein. Ungewöhnlich ist ein Wert dazwischen, weil er zu keinem der gültigen Zustände passt. Hier versagen einfache Einbereichs- oder Einzelvorhersageansätze. Versucht eine Methode, beide Normalmodi mit einer durchschnittlichen Vorhersage oder einem breiten Band abzubilden, landet der erwartete Wert oft irgendwo in der Mitte. Aber in diesem Fall ist die Mitte genau der Ort, an dem normales Verhalten nicht hingehört. Das erzeugt zwei Probleme zugleich: * reale normale Beobachtungen, die entweder klar niedrig oder klar hoch sind, können als anomal markiert werden, weil sie weit von der durchschnittlichen Vorhersage entfernt sind * tatsächlich anomale Beobachtungen in der Mitte können als normal behandelt werden, weil sie nahe an diesem Durchschnitt liegen Die Methode kehrt damit die Logik um. Sie markiert gültiges Verhalten als verdächtig und verdächtiges Verhalten als gesund.

Absoluter Log-Likelihood-Verlauf für den Einzel-Gauß-Prediktor. Die Stuck-at-5-Anomalie fällt mit dem Zentrum hoher Wahrscheinlichkeit zusammen und unterdrückt den Score.

Per Zeitschritt normalisierte PDF für das Gauß-Modell. Hohe Wahrscheinlichkeitsmasse sammelt sich
zwischen den tatsächlichen Clustern und veranschaulicht das Varianzaufblähungs-Paradoxon.

Das ist kein seltener Sonderfall. Es ist eine häufige Folge davon, Ein-Modus-Denken auf Gebäudesysteme anzuwenden, die tatsächlich in mehreren gültigen Regimen arbeiten. Ein nützlicher Ansatz zur Anomalieerkennung benötigt daher eine Möglichkeit, mehrere Formen normalen Verhaltens abzubilden, statt sie zu einem einzigen Durchschnitt zusammenzuziehen.

Optimaler probabilistischer Mischdichteansatz zur genauen Modellierung der Daten. Zwei deutliche Hochwahrscheinlichkeitsrippen liegen auf den realen Betriebsmodi, während das mittlere Band unwahrscheinlich bleibt.

*** ### Fehlermodus 3: Anpassung, die Fehler verschluckt Nichtstationarität ist eine reale Eigenschaft von Gebäudedaten. Jahreszeiten wechseln. Belegungsmuster verschieben sich. Jede nützliche Methode muss legitime Änderungen des normalen Verhaltens im Laufe der Zeit mitverfolgen. Aber diese notwendige Flexibilität erzeugt einen spezifischen und gefährlichen Fehlermodus. Wenn sich eine Methode zu schnell an die jüngsten Beobachtungen anpasst, folgt sie einem anhaltenden Fehler nach oben. Nach einigen Tagen erhöhter nächtlicher Verbräuche hat sich das Normalitätsverständnis der Methode so verschoben, dass der Fehler darin enthalten ist. Der Anomaliescore fällt wieder in Richtung null. Das Problem ist immer noch aktiv. Die Rechnung steigt weiter. Das System ist verstummt. Dieser Fehlermodus ist besonders schädlich, weil er sich selbst verbirgt. Die Methode meldet keinen Fehler. Sie hört einfach auf, genau das zu markieren, was sie verfolgen sollte. Die Spannung hier ist nicht auflösbar: Die Methode muss flexibel genug sein, um gesunde saisonale Veränderungen mitzugehen, aber robust genug, um weiterhin etwas zu markieren, das nicht normal werden darf. Diese beiden Anforderungen ziehen in entgegengesetzte Richtungen, und der Umgang mit dieser Spannung ist eine der technisch wichtigsten Designentscheidungen in der Gebäude-Anomalieerkennung.

Vorhersageverhalten eines Modells, das nur ein kurzes historisches Fenster (5 Schritte) verwendet. Das Modell
identifiziert den Beginn von Anomalien korrekt, passt sich jedoch schnell an das neue Niveau an, wodurch der Anomaliescore
wieder auf nahezu null sinkt, während die Anomalie noch andauert.

*** ### Fehlermodus 4: Spitzenerkennung, die anhaltende Verschwendung übersieht Viele Erkennungsansätze sind auf scharfe, kurze Abweichungen optimiert. Ein Wert, der für ein Intervall dramatisch außerhalb des Bereichs liegt, ist leicht zu markieren. Ein Wert, der drei Wochen lang nur mäßig außerhalb des Bereichs liegt, ist technisch und auch bei der Aggregation und Persistenz von Anomaliescores viel schwieriger zu handhaben. Die finanzielle Realität ist umgekehrt. Eine anhaltende nächtliche Anomalie von moderater Größe, die einen Monat lang läuft, kostet um Größenordnungen mehr als ein einzelner großer Ausschlag an einem Nachmittag. Ein System, das nur Spitzen anzeigt, während sich anhaltende Abweichungen unbemerkt anhäufen, schützt sich vor dramatisch aussehenden Fehlern und ignoriert dabei die eigentlichen Quellen von Energieverschwendung. Deshalb sind [-> Anomalie-Zentrum](/collection/german/suiten/energy-and-sustainability-intelligence/energy-anomaly-detection/anomaliezentrum.md) und [-> Statistik-Dashboard zur Anomalieerkennung](/collection/german/suiten/energy-and-sustainability-intelligence/energy-anomaly-detection/statistik-dashboard-zur-anomalieerkennung.md) halten anhaltende Anomalien über Zeit und Wirkung hinweg sichtbar. *** ### Fehlermodus 5: Datenartefakte mit Gebäudproblemen verwechseln Übertragungslücken, gepufferte Wiederübertragung und Effekte der Zähleraggregation erzeugen Muster in der Zeitreihe, die wie Anomalien aussehen, aber nichts mit dem physischen Gebäude zu tun haben. Ein Zähler, der mehrere Intervalle verpasst und sie alle auf einmal liefert, erscheint als Spitzenwert. Ein Kommunikationsausfall, gefolgt von der Wiederverbindung, erscheint als Lücke und dann als Sprung. Ein System, das diese als Anomalien anzeigt, trainiert Nutzer auf Fehlalarme. Ein paar Untersuchungen, die auf der Netzwerkebene und nicht beim Gebäude enden, reichen aus, um das Vertrauen zu untergraben, das den gesamten Workflow überhaupt lohnend macht. *** ### Fehlermodus 6: Eine Basislinie, die auf ungesundem Verlauf aufbaut Gebäudeanomalieerkennung ist fast immer halbüberwacht. Die praktische Annahme lautet, dass historische Daten größtenteils gesund sind und die gelernte Basislinie den Normalbetrieb widerspiegelt. Diese Annahme ist oft nur näherungsweise wahr. Ein Gebäude, das mehrere Monate lang ein festsitzendes Ventil, einen falsch konfigurierten Zeitplan oder eine dauerhaft laufende Pumpe hatte, trägt all das in seiner Historie. Die Basislinie enthält den Fehler. Vergleicht die Methode das aktuelle Verhalten mit dieser Basislinie, wird sie den Fehler als unauffällig ansehen, weil er relativ zu dem, worauf sie trainiert wurde, unauffällig ist. Das ist kein Fehler des Algorithmus. Es ist eine strukturelle Grenze des realen operativen Einsatzes. Das klar anzuerkennen ist nützlicher, als so zu tun, als gäbe es das Problem nicht. Im Laufe der Zeit helfen Nutzerfeedback und Validierung, es zu korrigieren, aber der Ausgangszustand ist wichtig. *** ### Fehlermodus 7: Eine Basislinie, die zu kurz oder saisonal unvollständig ist Eine kontaminierte Basislinie ist ein Problem. Eine unzureichende ist ein anderes — und sie tritt häufiger auf, als man denkt. Ein Gebäude, das im August angebunden wurde, hat sechs Wochen an Daten für warmes Wetter. Wenn im Oktober der Heizbedarf einsetzt, hat das System dieses Gebäude im Winter nie gesehen. Es weiß nicht, ob der Heizverbrauch, den es jetzt beobachtet, normales saisonales Verhalten oder eine Anomalie ist. Ein Modell, das nur aus dem lernen kann, was es an diesem konkreten Gebäude gesehen hat, steht vor einem echten Blindfleck — und alle Optionen sind schlecht: den legitimen Kaltwetterbetrieb als anomal markieren, die Sensitivität dämpfen, bis genügend Winterdaten vorliegen, oder einfach abwarten und mehrere Monate möglicher Probleme verpassen. Dasselbe Problem taucht nach erheblichen betrieblichen Änderungen auf. Ein Gebäude, das saniert, neu vermietet oder dessen HVAC-System ersetzt wurde, hat eine Historie, die sein jetziges Verhalten nicht mehr repräsentiert. Die aktuelle Basislinie auf Daten vor der Änderung aufzubauen bedeutet, das Gebäude mit einer Version seiner selbst zu vergleichen, die nicht mehr existiert. Das ist grundsätzlich anders als das Problem der kontaminierten Basislinie. Dort existiert die Historie, ist aber unzuverlässig. Hier ist die Historie sauber, deckt die aktuelle Situation aber einfach nicht ab. Keine Menge an Bereinigung oder Filterung behebt das. Die Lücke in der Abdeckung ist real, und eine Methode, die sich ausschließlich auf lokale Historie stützt, hat keine Möglichkeit, sie zu überbrücken. *** ### Fehlermodus 8: Eine Liste von Anomalien ohne Möglichkeit zur Priorisierung Selbst eine technisch hervorragende Erkennungsmethode erzeugt in dem Moment ein neues Problem, in dem sie gut funktioniert: Volumen. Ein Portfolio von Gebäuden über mehrere Standorte hinweg kann jederzeit leicht Dutzende aktiver Anomalien erzeugen. Nicht alle sind gleich wichtig. Einige sind klein und kurzlebig. Andere sind groß, anhaltend und teuer. Wenn jede Anomalie mit gleichem visuellem Gewicht präsentiert wird — als Liste von Markierungen ohne weitere Differenzierung — stehen Betreiber vor einem Triage-Problem, das das System zwar erzeugt, aber ganz ihnen überlässt, es zu lösen. Das Ergebnis ist ein vertrautes Muster: Der jüngste Anomaliefall erhält Aufmerksamkeit, nicht der kostspieligste. Persistente Abweichungen mit hohem Einfluss bleiben in der Liste stehen, während Betreiber das jeweils Neueste untersuchen. Ohne eine Schätzung der finanziellen Auswirkungen, die jeder Anomalie beigefügt ist, zeigt das Erkennungssystem zwar Belege an, hilft den Betreibern aber nicht zu entscheiden, was sie damit tun sollen. Zu wissen, dass etwas anomal ist, ist nützlich. Zu wissen, dass es in den letzten zehn Tagen schätzungsweise 840 CHF gekostet hat, während das Gebäude nebenan eine ähnliche Anomalie mit Kosten von 12 CHF hat, ist handlungsrelevant. Die Schätzung der finanziellen Auswirkungen ist daher kein Reporting-Add-on. Sie ist ein Kernbestandteil davon, Erkennung in großem Maßstab operativ nützlich zu machen. Dies ist die Rolle von [-> Statistik-Dashboard zur Anomalieerkennung](/collection/german/suiten/energy-and-sustainability-intelligence/energy-anomaly-detection/statistik-dashboard-zur-anomalieerkennung.md) und [-> Anomalie-Zentrum](/collection/german/suiten/energy-and-sustainability-intelligence/energy-anomaly-detection/anomaliezentrum.md), wo Anomalien nach ihren Folgen statt als flache Liste eingestuft werden. ### Fehlermodus 9: Erkennung ohne Erklärung oder Richtung Selbst wenn eine Anomalie korrekt erkannt, korrekt bewertet und korrekt priorisiert wird, steht der Betreiber weiterhin vor einer kritischen Lücke: Er weiß, dass etwas nicht stimmt, aber nicht, wo er suchen oder was er tun soll. In einem Gebäude mit Dutzenden von Zählern, Unterzählern, Etagen, Systemen und Geräten ist eine Anomalie auf Standortebene ein Ausgangspunkt, keine Antwort. Ohne weitere Unterstützung ist der Untersuchungsprozess vollständig manuell: Etage prüfen, System prüfen, Gerät prüfen, Zeitplan prüfen, Techniker anrufen, von vorn beginnen. Für einen für mehrere Gebäude verantwortlichen Facility Manager ist dieser Prozess selbst bei Anomalien mit einfacher Erklärung ein erheblicher Zeitaufwand. Zwei Fähigkeiten schließen diese Lücke direkt. **Hierarchische Ursachenzuordnung** nutzt die Anlagenstruktur des Gebäudes, um eine Anomalie auf hoher Ebene in die beitragenden Teilanlagen zu zerlegen. Wird eine Anomalie auf Gebäudeebene erkannt, bewertet das System, welche Etagen, Systeme oder Geräte am stärksten zur Abweichung beigetragen haben, und zeigt diese als primäre Ermittlungsansätze an. Der Betreiber bewegt sich in der Oberfläche vom Gebäude zur Etage zum System, statt vor Ort.
**KI-generierte Erklärung und empfohlene Maßnahmen** nehmen die strukturierten Belege aus Erkennung und Ursachenattribution — Ort der Anomalie, finanzielle Auswirkungen, Zeitmuster, Kontextbedingungen und beitragende Teilanlagen — und übertragen sie in für Menschen lesbare Sprache. Der Betreiber sieht nicht nur, wo die Anomalie liegt, sondern eine begründete Erklärung dafür, was sie wahrscheinlich verursacht hat und welche Maßnahmen sich lohnen. Das ist nicht das System, das autonome Entscheidungen trifft. Die Erklärung wird aus strukturierten Belegen abgeleitet, die bereits deterministisch berechnet wurden. Die KI-Schicht übersetzt diese Belege in Sprache und Vorschläge. Der Betreiber behält die Kontrolle und validiert das Ergebnis.
Ohne diese Fähigkeiten bleibt die Anomalieerkennung an der Schwelle zur Nützlichkeit stehen. Sie sagt dem Betreiber, dass etwas passiert ist. Sie hilft ihm nicht zu verstehen, was, wo oder was als Nächstes zu tun ist. Für Gebäude in großem Maßstab ist diese Lücke der Unterschied zwischen einem System, das konsultiert wird, und einem, das ignoriert wird. Im Arbeitsablauf des Betreibers läuft dieser Untersuchungsweg über [-> Anomalie-Zentrum](/collection/german/suiten/energy-and-sustainability-intelligence/energy-anomaly-detection/anomaliezentrum.md), [-> die Anomalie-Detailseite](/collection/german/suiten/energy-and-sustainability-intelligence/energy-anomaly-detection/detailseite-der-anomalie.md), und [-> Anomalieerkennungs-Analysetyp](/collection/german/suiten/energy-and-sustainability-intelligence/energy-anomaly-detection/analytischer-typ-der-anomalieerkennung.md). *** ## Die Kernspannung: Präzision versus Recall unter betrieblichen Einschränkungen Hinter den neun Fehlermodi oben verbirgt sich eine einzige zugrunde liegende Spannung, die jedes praktische Anomalieerkennungssystem meistern muss. Ein empfindlicheres System erkennt mehr echte Anomalien, erzeugt aber auch mehr Fehlalarme. Ein weniger empfindliches System produziert weniger Fehlalarme, übersieht aber mehr echte Probleme. Keines der beiden Extreme ist im operativen Gebäudemanagement akzeptabel. Zu viele Fehlalarme und Betreiber hören auf nachzusehen. Das System wird zum Hintergrundrauschen, das niemand untersucht. Echte Anomalien werden nicht übersehen, weil das System sie nicht erkannt hätte, sondern weil niemand hingeschaut hat. Zu wenige Alarme, und das System bietet keinen operativen Mehrwert. Energieverschwendung sammelt sich unentdeckt an. Das Werkzeug ist vorhanden, aber nicht nützlich. Der richtige Betriebspunkt hängt vom Gebäude, vom Betreiber und von der Schwelle für finanzielle Auswirkungen ab, die die Organisation für untersuchungswürdig hält. Deshalb ist die Sensitivität konfigurierbar und nicht fest vorgegeben. Aber das bedeutet auch, dass die zugrunde liegende Qualität der Erkennungsmethode — wie gut sie Signal von Rauschen trennt — direkt bestimmt, wie nützlich die Sensitivitätssteuerung tatsächlich ist. *** ## Anforderungen: das Bewertungsframework Die neun Fehlermodi und die obige Kernspannung übersetzen sich direkt in eine Reihe von Anforderungen. Das sind keine Wunschmerkmale. Sie sind die Mindestbedingungen dafür, dass Anomalieerkennung in Gebäuden operativ nützlich ist. Die nächste Seite, [-> Wie BuildingPro Suites die Herausforderungen der Anomalieerkennung adressiert](/collection/german/akademie/building-intelligence-ki-und-maschinelles-lernen-in-buildingpro-suites/maschinelles-lernen/einfuhrung-in-die-anomalieerkennung-in-intelligenten-gebauden/wie-buildingpro-suites-die-herausforderungen-der-anomalieerkennung-angeht.md), beschreibt, wie ABB Ability™ BuildingPro Suites jede einzelne davon adressiert — was heute implementiert ist, wo die aktuellen Grenzen liegen und was als Nächstes kommt.
#AnforderungWas ohne sie versagt
R1Kontextbewusste BasislinieRegimewechsel lösen Fehlalarme aus. Zeitplanverstöße bleiben unentdeckt.
R2Wahrscheinlicher Erwartungsbereich statt eines einzelnen WertsGebäude mit mehreren Modi erzeugen systematische Fehlalarme und Blindstellen zwischen den Modi.
R3Persistenzverfolgung für anhaltende AbweichungenDie Anomalien mit dem größten Einfluss werden übersehen. Nur Spitzenwerte werden angezeigt.
R4Kontrollierte Anpassung: folgt gesunder Veränderung, widersteht der Aufnahme von FehlernAnhaltende Fehler werden in die Basislinie aufgenommen und verschwinden aus dem Score.
R5Trennung von Datenartefakten und physischen AnomalienNutzer untersuchen Netzwerkprobleme statt Gebäudproblemen. Das Vertrauen erodiert.
R6Funktioniert ohne gelabelte Daten, verbessert sich mit FeedbackDas System kann in realen Gebäuden nicht eingesetzt oder über die Zeit verfeinert werden.
R7Robust gegenüber unvollständigen historischen BasislinienBereits bestehende Fehler werden als normal gelernt und nie markiert.
R8Wirksam bei begrenzter oder saisonal unvollständiger lokaler HistorieNeue Gebäude, kürzlich veränderte Gebäude und ein Onboarding mitten in der Saison werden systematisch zu wenig abgedeckt.
R9Schätzung der finanziellen Auswirkungen zur PriorisierungAlle Anomalien werden unabhängig von den Kosten gleich behandelt. Ereignisse mit hohem Einfluss warten.
R10Hierarchische UrsachenzuordnungJede Anomalie erfordert eine vollständige manuelle Untersuchung von der Spitze der Hierarchie nach unten.
R11KI-gestützte Erklärung und empfohlene MaßnahmenBetreiber wissen, dass etwas nicht stimmt, haben aber keine Orientierung, wo sie suchen oder was sie tun sollen.
--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.buildings.ability.abb/collection/german/akademie/building-intelligence-ki-und-maschinelles-lernen-in-buildingpro-suites/maschinelles-lernen/einfuhrung-in-die-anomalieerkennung-in-intelligenten-gebauden/von-gebaudedaten-zu-erkennungsherausforderungen.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.