> 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-ai-and-machine-learning-in-buildingpro-suites/machine-learning/introduction-to-anomaly-detection-in-smart-buildings/from-building-data-to-detection-challenges.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 bei der Quartalsrechnung drei Monate nächtlicher Verschwendung entdecken. Das sind keine Versäumnisse der Aufmerksamkeit. Sie entstehen, wenn Anomalieerkennung nicht für die spezifische Realität von Gebäuden ausgelegt ist. Diese Seite beschreibt diese Realität, die spezifischen Arten, wie Gebäudedaten die Erkennung erschweren, die daraus folgenden Fehlermodi und die Anforderungen, die jeder ernsthafte Ansatz erfüllen muss, um betrieblich nützlich statt nur technisch vorhanden zu sein. *** ## Von Dateneigenschaften zu Fehlermodi Das Beschreiben einer Dateneigenschaft und das Beschreiben, wo die Erkennung schiefgeht, sind zwei verschiedene Dinge. Die vorherige Seite, [-> Gebäudedaten verstehen](/collection/german/akademie/building-intelligence-ai-and-machine-learning-in-buildingpro-suites/machine-learning/introduction-to-anomaly-detection-in-smart-buildings/understanding-building-data.md), beschrieb Gebäudedaten als multimodal und nicht-stationär. Diese Seite fragt: Was genau versagt, wenn eine Erkennungsmethode das nicht gut handhabt? ### 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 stuft das als Anomalie ein. An 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 von betrieblich relevanter Abweichung, die Anomalieerkennung eigentlich finden soll. Kontextbewusstsein ist keine Verfeinerung. Es ist die Mindestvoraussetzung dafür, dass Erkennung in Gebäuden betrieblich nützlich ist.

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

Vorhersageverhalten eines Modells mit einem historischen 24-Stunden-Fenster plus Zeitmerkmalen. Das obere Diagramm zeigt Ist- gegenüber Prognosewerten; das untere Diagramm zeigt den differenzbasierten Anomaliescore. Beachten Sie die sprunghaften Vorhersagen selbst nach Ende der Anomalie, da die ungesehenen Daten durch das gleitende Fenster propagiert werden

*** ### Fehlermodus 2: Einzelbereichsdenken in einer Welt mit mehreren Modi Viele Gebäudesignale clustern sich in unterschiedliche Betriebszustände, statt sich sanft um einen einzigen Mittelpunkt zu bewegen. 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 tatsächlich unterschiedlichen typischen Bereichen.

Empirische Verteilung des Hauptzählers des Gebäudes (15-Minuten-kWh-Werte, Histogramm) mit überlagerter einzelner Normalverteilung und einem Gauß-Mischmodell mit fünf Komponenten, die die Diskrepanz zwischen einem unimodalen Gauß-Modell und der multimodalen, schwerschwänzigen Struktur realer Gebäudenergie-Daten veranschaulicht.

Ein gutes Beispiel ist das Hochfahren am Morgen. In manchen Gebäuden hängt die exakte Startzeit von Heizung, Lüftung und Klimaanlage (HVAC) davon ab, wann die ersten Personen eintreffen oder wann das Steuerungssystem beschließt, 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 beiden gültigen Zustände passt. Hier versagen einfache Einzelbereichs- oder Einzelvorhersageansätze. Wenn eine Methode versucht, beide normalen Modi mit einer einzigen Durchschnittsprognose oder einem einzigen breiten Bereich darzustellen, platziert sie den Erwartungswert oft irgendwo in der Mitte. Aber in diesem Fall ist die Mitte genau der Ort, an dem normales Verhalten nicht hingehört. Das erzeugt auf einmal zwei Probleme: * echte normale Beobachtungen, die entweder klar niedrig oder klar hoch sind, können als anomal markiert werden, weil sie weit von der Durchschnittsprognose entfernt sind * wirklich anomale Beobachtungen in der Mitte können als normal behandelt werden, weil sie nahe an diesem Durchschnitt liegen Die Methode dreht also die Logik um. Sie markiert normales Verhalten als verdächtig und verdächtiges Verhalten als gesund.

Absolute Log-Likelihood-Kurve des Einzel-Gauß-Vorhersagers. Die bei 5 festhängende Anomalie liegt im Zentrum hoher Likelihood und unterdrückt den Score.

Pro Zeitschritt normalisierte PDF für das Gauß-Modell. Zwischen den tatsächlichen Clustern sammelt sich hohe Wahrscheinlichkeitsmasse, was das Paradoxon der Varianzaufblähung veranschaulicht.

Dies ist kein seltener Grenzfall. Es ist eine häufige Folge davon, Einzelmodus-Denken auf Gebäudesysteme anzuwenden, die tatsächlich in mehreren gültigen Regimen arbeiten. Ein nützlicher Anomalieerkennungsansatz braucht daher eine Möglichkeit, mehrere Formen normalen Verhaltens darzustellen, statt sie auf einen Durchschnitt zu reduzieren.

Optimaler probabilistischer Mischdichteansatz zur genauen Modellierung der Daten. Zwei deutlich ausgeprägte hochwahrscheinliche Dichtekämme stimmen mit den realen Betriebsmodi überein, während das mittlere Band unwahrscheinlich bleibt.

*** ### Fehlermodus 3: Anpassung, die Fehler verschluckt Nicht-Stationarität ist eine reale Eigenschaft von Gebäudedaten. Jahreszeiten ändern sich. Belegungsmuster verschieben sich. Jede nützliche Methode muss legitime Veränderungen des normalen Verhaltens im Laufe der Zeit mitverfolgen. Aber genau diese notwendige Flexibilität erzeugt einen spezifischen und gefährlichen Fehlermodus. Wenn eine Methode zu schnell an aktuelle Beobachtungen angepasst wird, folgt sie einem anhaltenden Fehler nach oben. Nach ein paar Tagen erhöhter nächtlicher Verbräuche hat sich das Normalitätsverständnis der Methode so verschoben, dass es den Fehler einschließt. Der Anomaliescore fällt wieder gegen null. Das Problem besteht weiter. Die Rechnung steigt weiter. Das System ist verstummt. Dieser Fehlermodus ist besonders schädlich, weil er sich selbst verschleiert. Die Methode meldet keinen Fehler. Sie hört lediglich auf, das zu markieren, was sie eigentlich verfolgen sollte. Die Spannung hier ist nicht auflösbar: Die Methode muss flexibel genug sein, um gesunde saisonale Veränderungen zu verfolgen, 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 erkennt den Beginn von Anomalien korrekt, passt sich aber schnell an das neue Niveau an, sodass der Anomaliescore wieder auf nahezu null fällt, während die Anomalie noch andauert.

*** ### Fehlermodus 4: Spike-Erkennung, die anhaltende Verschwendung übersieht Viele Erkennungsansätze sind auf scharfe, kurze Abweichungen optimiert. Ein Wert, der in einem Intervall stark außerhalb des Bereichs liegt, ist leicht zu markieren. Ein Wert, der drei Wochen lang nur mäßig außerhalb des Bereichs liegt, ist sowohl technisch als auch hinsichtlich der Aggregation und Persistenz von Anomaliescores wesentlich schwieriger zu behandeln. Die finanzielle Realität ist genau 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 Ausschläge sichtbar macht, während dauerhafte Abweichungen unbemerkt auflaufen, schützt sich gegen spektakulär aussehende Fehler und ignoriert dabei die eigentlichen Quellen der Energieverschwendung. Deshalb ist [-> Anomaliezentrum](/collection/german/pakete/energy-and-sustainability-intelligence/energy-anomaly-detection/anomaly-center.md) und [-> Dashboard für Anomalieerkennungsstatistiken](/collection/german/pakete/energy-and-sustainability-intelligence/energy-anomaly-detection/anomaly-detection-statistics-dashboard.md) anhaltende Anomalien über Zeit und Auswirkungen hinweg sichtbar zu halten. *** ### Fehlermodus 5: Datenartefakte mit Gebäudeproblemen verwechseln Übertragungslücken, gepufferte erneute Ü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 geliefert hat, erscheint als Spitze. Ein Kommunikationsausfall mit anschließender Wiederverbindung erscheint als Lücke und dann als Sprung. Ein System, das diese als Anomalien anzeigt, gewöhnt Nutzer an Fehlalarme. Ein paar Untersuchungen, die im Netzwerk und nicht im Gebäude enden, reichen aus, um das Vertrauen zu untergraben, das den gesamten Workflow überhaupt erst lohnend macht. *** ### Fehlermodus 6: Eine Grundlinie auf Basis ungesunder Historie Anomalieerkennung in Gebäuden ist fast immer halbüberwacht. Die praktische Annahme ist, dass historische Daten größtenteils gesund sind und die gelernte Grundlinie den Normalbetrieb widerspiegelt. Diese Annahme ist oft nur näherungsweise richtig. Ein Gebäude, das mehrere Monate lang ein klemmendes Ventil, einen falsch konfigurierten Zeitplan oder eine dauerhaft laufende Pumpe hatte, trägt all das in seiner Historie mit sich. Die Grundlinie enthält den Fehler. Wenn die Methode das aktuelle Verhalten mit dieser Grundlinie vergleicht, findet sie den Fehler unauffällig, weil er im Verhältnis zu dem, womit sie trainiert wurde, unauffällig ist. Das ist kein Fehler des Algorithmus. Es ist eine strukturelle Einschränkung des realen operativen Einsatzes. Das klar anzuerkennen ist hilfreicher, 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 Grundlinie, die zu kurz oder saisonal unvollständig ist Eine kontaminierte Grundlinie ist ein Problem. Eine unzureichende ist ein anderes — und es tritt häufiger auf, als man denken könnte. Ein im August angebundenes Gebäude hat sechs Wochen Daten aus warmem Wetter. Wenn im Oktober der Heizbedarf beginnt, hat das System dieses Gebäude noch nie im Winter 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, stößt auf einen echten blinden Fleck — und die Optionen sind alle schlecht: den legitimen Kaltwetterbetrieb als anomal markieren, die Sensitivität so lange unterdrücken, bis genügend Winterdaten zusammenkommen, oder einfach warten und mehrere Monate möglicher Probleme verpassen. Dasselbe Problem tritt nach wesentlichen betrieblichen Änderungen auf. Ein Gebäude, das saniert, neu vermietet oder dessen HVAC-System ersetzt wurde, hat eine Historie, die nicht mehr repräsentiert, wie es sich jetzt verhält. Die aktuelle Grundlinie auf Daten von vor der Änderung aufzubauen bedeutet, das Gebäude mit einer Version seiner selbst zu vergleichen, die nicht mehr existiert. Das unterscheidet sich grundlegend vom Problem der kontaminierten Grundlinie. Dort existiert die Historie, ist aber nicht vertrauenswürdig. Hier ist die Historie sauber, deckt aber einfach die aktuelle Situation nicht ab. Kein Reinigen oder Filtern löst 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 kann problemlos Dutzende aktiver Anomalien zu einem gegebenen Zeitpunkt erzeugen. Nicht alle sind gleich wichtig. Manche sind klein und kurzlebig. Andere sind groß, anhaltend und teuer. Wenn jede Anomalie mit gleichem visuellen Gewicht dargestellt wird — als Liste von Markierungen ohne weitere Unterscheidung — stehen Betreiber vor einem Triage-Problem, das das System selbst erzeugt, aber ihnen zur Lösung überlässt. Das Ergebnis ist ein vertrautes Muster: Die jüngste Anomalie erhält Aufmerksamkeit, nicht die teuerste. Anhaltende Abweichungen mit hoher Wirkung bleiben in der Liste stehen, während Betreiber untersuchen, was auch immer gerade am neuesten ist. Ohne eine Schätzung des finanziellen Einflusses für jede Anomalie liefert das Erkennungssystem zwar Belege, hilft den Betreibern aber nicht dabei 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 geschätzte 840 CHF gekostet hat, während das Gebäude nebenan eine ähnliche Anomalie mit Kosten von 12 CHF aufweist, ist handlungsrelevant. Die Schätzung des finanziellen Einflusses ist daher kein Add-on für Berichte. Sie ist ein Kernbestandteil davon, Erkennung im großen Maßstab betrieblich nützlich zu machen. Dies ist die Rolle von [-> Dashboard für Anomalieerkennungsstatistiken](/collection/german/pakete/energy-and-sustainability-intelligence/energy-anomaly-detection/anomaly-detection-statistics-dashboard.md) und [-> Anomaliezentrum](/collection/german/pakete/energy-and-sustainability-intelligence/energy-anomaly-detection/anomaly-center.md), wo Anomalien nach Konsequenzen statt als flache Liste dargestellt werden. ### Fehlermodus 9: Erkennung ohne Erklärung oder Richtung Selbst wenn eine Anomalie korrekt erkannt, korrekt bewertet und korrekt priorisiert wurde, bleibt für den Betreiber eine kritische 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, Stockwerken, Systemen und Geräten ist eine Anomalie auf Standortebene ein Anfang, 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 Facility Manager, der für mehrere Gebäude verantwortlich ist, ist dieser Prozess selbst bei Anomalien mit einfachen Erklärungen ein erheblicher Zeitaufwand. Zwei Fähigkeiten adressieren diese Lücke direkt. **Hierarchische Ursachenzuordnung** nutzt die Anlagenstruktur des Gebäudes, um eine übergeordnete Anomalie in die dazu beitragenden Teilanlagen zu zerlegen. Wenn eine Anomalie auf Gebäudeebene erkannt wird, bewertet das System, welche Stockwerke, Systeme oder Geräte am stärksten zur Abweichung beigetragen haben, und zeigt diese als vorrangige Ansatzpunkte für die Untersuchung an. Der Betreiber bewegt sich in der Benutzeroberfläche vom Gebäude zur Etage zum System statt vor Ort.

**KI-generierte Erklärung und empfohlene Maßnahmen** nehmen die strukturierte Evidenz aus Erkennung und Ursachenzuordnung — den Ort der Anomalie, den finanziellen Einfluss, das Zeitmuster, die Kontextbedingungen und die beitragenden Teilanlagen — und übersetzen sie in menschenlesbare Sprache. Der Betreiber sieht nicht nur, wo die Anomalie liegt, sondern auch eine begründete Erklärung dafür, was sie wahrscheinlich verursacht hat und welche Maßnahmen sinnvoll sind. Das bedeutet nicht, dass das System autonome Entscheidungen trifft. Die Erklärung wird aus strukturierter Evidenz abgeleitet, die bereits deterministisch berechnet wurde. Die KI-Schicht übersetzt diese Evidenz in Sprache und Vorschläge. Der Betreiber behält die Kontrolle und validiert das Ergebnis.

Ohne diese Fähigkeiten endet die Anomalieerkennung an der Schwelle zur Nützlichkeit. Sie sagt dem Betreiber, dass etwas passiert ist. Sie hilft ihm nicht zu verstehen, was es war, wo es war oder was als Nächstes zu tun ist. Für Gebäude im großen Maßstab ist diese Lücke der Unterschied zwischen einem System, das konsultiert wird, und einem, das ignoriert wird. Im Betreiber-Workflow verläuft dieser Untersuchungsweg über [-> Anomaliezentrum](/collection/german/pakete/energy-and-sustainability-intelligence/energy-anomaly-detection/anomaly-center.md), [-> die Anomalie-Detailseite](/collection/german/pakete/energy-and-sustainability-intelligence/energy-anomaly-detection/anomaly-detail-page.md), und [-> Anomalieerkennungs-Analysetyp](/collection/german/pakete/energy-and-sustainability-intelligence/energy-anomaly-detection/anomaly-detection-analytic-type.md). *** ## Die zentrale Spannung: Präzision versus Recall unter betrieblichen Randbedingungen Hinter den neun Fehlermodi oben liegt eine einzige zugrunde liegende Spannung, die jedes praktische Anomalieerkennungssystem bewältigen muss. Ein empfindlicheres System erkennt mehr echte Anomalien, erzeugt aber auch mehr Fehlalarme. Ein weniger empfindliches System erzeugt weniger Fehlalarme, übersieht aber mehr echte Probleme. Keine der beiden Extremlagen ist im operativen Kontext des Gebäudemanagements akzeptabel. Zu viele Fehlalarme, und die Betreiber hören auf zu prüfen. Das System wird zu Hintergrundrauschen, das niemand untersucht. Echte Anomalien werden übersehen, nicht weil das System sie nicht erkannt hätte, sondern weil niemand hingeschaut hat. Zu wenige Warnungen, und das System liefert keinen betrieblichen Nutzen. Energieverschwendung sammelt sich unentdeckt an. Das Werkzeug ist vorhanden, aber nicht nützlich. Der richtige Betriebspunkt hängt vom Gebäude, vom Betreiber und vom Schwellenwert für den finanziellen Einfluss ab, den die Organisation für untersuchenswert hält. Deshalb ist die Sensitivität konfigurierbar statt fest vorgegeben. Aber das bedeutet auch, dass die zugrunde liegende Qualität der Erkennungsmethode — also wie gut sie Signal von Rauschen trennt — direkt bestimmt, wie nützlich die Sensitivitätssteuerung tatsächlich ist. *** ## Anforderungen: der Bewertungsrahmen Die neun Fehlermodi und die zentrale Spannung oben lassen sich direkt in eine Reihe von Anforderungen übersetzen. Das sind keine Wunschfunktionen. Sie sind die Mindestbedingungen dafür, dass Anomalieerkennung in Gebäuden betrieblich nützlich ist. Die nächste Seite, [-> Wie BuildingPro Suites die Herausforderungen der Anomalieerkennung angeht](/collection/german/akademie/building-intelligence-ai-and-machine-learning-in-buildingpro-suites/machine-learning/introduction-to-anomaly-detection-in-smart-buildings/how-buildingpro-suites-addresses-the-challenges-of-anomaly-detection.md), beschreibt, wie ABB Ability™ BuildingPro Suites jede einzelne davon angeht — was heute implementiert ist, wo die aktuellen Grenzen liegen und was als Nächstes kommt.

#	Anforderung	Was ohne sie scheitert
R1	Kontextbewusste Grundlinie	Regimewechsel lösen Fehlalarme aus. Zeitplanverstöße bleiben unentdeckt.
R2	Probabilistischer Erwartungsbereich, kein Einzelwert	Gebäude mit mehreren Modi erzeugen systematische Fehlalarme und blinde Flecken in der Lücke zwischen den Modi.
R3	Persistenzverfolgung für anhaltende Abweichungen	Die Anomalien mit der größten Wirkung werden übersehen. Nur Spitzen werden angezeigt.
R4	Kontrollierte Anpassung: folgt gesunder Veränderung, widersteht dem Verschlucken von Fehlern	Anhaltende Fehler werden in die Grundlinie aufgenommen und verschwinden aus dem Score.
R5	Trennung von Datenartefakten und physischen Anomalien	Nutzer untersuchen Netzwerkprobleme statt Gebäudeprobleme. Das Vertrauen erodiert.
R6	Funktioniert ohne beschriftete Daten, verbessert sich durch Feedback	Das System kann nicht in realen Gebäuden eingesetzt oder im Laufe der Zeit verfeinert werden.
R7	Robust gegenüber unvollständigen historischen Grundlinien	Bereits vorhandene Fehler werden als normal gelernt und nie markiert.
R8	Wirksam bei begrenzter oder saisonal unvollständiger lokaler Historie	Neue Gebäude, kürzlich geänderte Gebäude und Onboarding mitten in der Saison werden systematisch unzureichend versorgt.
R9	Schätzung des finanziellen Einflusses zur Priorisierung	Alle Anomalien werden unabhängig von den Kosten gleich behandelt. Ereignisse mit hoher Wirkung warten.
R10	Hierarchische Ursachenzuordnung	Jede Anomalie erfordert eine vollständige manuelle Untersuchung von oben in der Hierarchie nach unten.
R11	KI-gestützte Erklärung und empfohlene Maßnahmen	Betreiber wissen, dass etwas nicht stimmt, haben aber keine Richtung, 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-ai-and-machine-learning-in-buildingpro-suites/machine-learning/introduction-to-anomaly-detection-in-smart-buildings/from-building-data-to-detection-challenges.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.