> 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/agents/result-analysis.md). # Ergebnisanalyse Allein die Datenabfrage reicht oft nicht aus. Benutzer müssen Muster, Vergleiche und Trends sehen, um Schlussfolgerungen zu ziehen. Sprachmodelle können bei der Interpretation von Ergebnissen hilfreich sein, wenn sie richtig eingesetzt werden. Das Abrufen von Daten aus einer Datenbank ist nur der erste Schritt. Eine Datenbankabfrage liefert\ Zeilen und Spalten, aber der Benutzer hat eine Frage gestellt. Die Lücke zwischen rohen tabellarischen\ Daten und einer umsetzbaren Antwort ist der Punkt, an dem Analyse und Visualisierung ins Spiel kommen. Betrachten Sie eine Abfrage, die 250 Zeilen des wöchentlichen Energieverbrauchs über 10 Gebäude hinweg zurückgibt. Das Rohresultat beantwortet „Was sind die Daten?“, aber nicht die Fragen, die den Benutzer wahrscheinlich interessieren: Welches Gebäude verbraucht am meisten? Steigt oder sinkt der Verbrauch? Wie schneidet diese Woche im Vergleich zur vorherigen ab? Gibt es Ausreißer? ### Das Problem mit LLMs und Zahlen Der naheliegende Impuls ist, Abfrageergebnisse direkt an ein Sprachmodell zu übergeben und es zu bitten, sie zu analysieren. Dieser Ansatz scheitert aus mehreren Gründen. #### Tokenisierung und numerisches Schlussfolgern Sprachmodelle verarbeiten Text als Token, nicht als Zahlen. Die Zahl „1,247.83“ wird intern nicht als Gleitkommawert dargestellt, sondern als Folge von Token (z. B. „1“, „,“, „24“, „7.8“, „3“).\ Diese Darstellung ist grundsätzlich ungeeignet für exakte Arithmetik. LLMs können Berechnungen durchführen, sollten aber im Allgemeinen bei Aufgaben wie den folgenden als unzuverlässig betrachtet werden: * Summieren von Zahlenkolonnen * Berechnen von Durchschnittswerten, Medianen oder Prozenten * Präzises Vergleichen von Werten über Zeilen hinweg * Erkennen kleiner, aber bedeutender Unterschiede Die Fehlerrate steigt mit der Anzahl der beteiligten Werte und der erforderlichen Genauigkeit. Für analytische Aufgaben, bei denen numerische Genauigkeit wichtig ist, sind von LLMs generierte Berechnungen nicht vertrauenswürdig. #### Sättigung des Kontextfensters Das Einspeisen großer Ergebnismengen in das Kontextfenster eines LLMs schafft zusätzliche Probleme: * **Aufmerksamkeitsverdünnung**: Wenn sich der Kontext mit Hunderten von Datenzeilen füllt, nimmt die Fähigkeit des Modells ab, über einzelne Zeilen oder Muster zu schlussfolgern. * **Kontextgrenzen**: Große Ergebnismengen können das verfügbare Kontextfenster vollständig überschreiten oder so viel davon verbrauchen, dass das Modell neben den Daten keine nützliche Antwort mehr erzeugen kann. * **Kosten und Latenz**: Die Verarbeitung von Tausenden Token tabellarischer Daten ist langsam und teuer, insbesondere wenn das Modell anschließend eine unzuverlässige Analyse dieser Daten liefert. Das Fazit ist klar: **LLMs sollten keine numerischen Berechnungen auf Rohdaten durchführen.** Sie sollten entscheiden *was* berechnet werden soll, und die eigentliche Berechnung an deterministische Werkzeuge delegieren. Ein in der Praxis umgesetztes Beispiel für dieses Prinzip finden Sie unter [Ergebnisanalyse des Copilot-Assistenten](/collection/german/copilot-assistent/agent-modes/data-agent.md#result-analysis). ### Deterministische Ergebnisinspektion Das Prinzip der deterministischen Ergebnisinspektion ist eine saubere Trennung der Zuständigkeiten: * **Das LLM entscheidet** welche analytische Operation angewendet werden soll und auf welchen Teil der Daten (z. B. „ermittle die Top 3 Gebäude nach Gesamtenergieverbrauch und vergleiche jedes mit dem Gruppendurchschnitt“). * **Ein deterministisches Werkzeug führt** die Operation mit exakter Arithmetik auf dem vollständigen Ergebnissatz aus und gibt die berechneten Werte zurück. * **Das LLM interpretiert** die Ausgabe des Werkzeugs und integriert sie in die Antwort. Das LLM sieht niemals alle Rohzeilen. Es sieht eine kleine Vorschau (ausreichend, um die Datenstruktur zu verstehen) und arbeitet dann mit den deterministisch berechneten Ergebnissen des Inspektionstools. Ergebnismengeninspektion / -analyse: * Ein LLM Rohdaten analysieren zu lassen, ist selten eine gute Idee (Konzept von Token und Zahlen!!) * Das Abladen von Hunderten Zeilen Rohdaten füllt den verfügbaren Kontext sehr schnell und führt zu Genauigkeitsverlusten * Es sollte nach Möglichkeit vermieden werden, es numerische Berechnungen durchführen zu lassen * Stattdessen sollte man ihm einen praktischen Satz von Tools und Funktionen geben, die es deterministisch auf Ergebnismengen anwenden kann (diese führen die eigentlichen Berechnungen durch); das LLM entscheidet nur, welche Funktion es verwendet und auf welchen Teil der Daten, und sieht nur das von der Funktion berechnete Ergebnis **Beispieloperationen:** | Kategorie | Operationen | Beispielanwendungsfall | | -------------- | ----------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------ | | Aggregation | Summe, Mittelwert, Median, Min, Max, Anzahl | Wie hoch ist die durchschnittliche Temperatur in allen Räumen? | | Rangfolge | Top N, Bottom N, Zeile mit Max/Min | Welches Gebäude verbraucht am meisten Energie? | | Vergleich | Vergleich mit Gruppenmittel/-median, spaltenübergreifendes Delta, Veränderung von Periode zu Periode, Abweichung von der Basislinie | Wie schneidet Gebäude A im Vergleich zum Portfoliodurchschnitt ab? | | Anteil | Prozentualer Anteil am Gesamtwert, Beitrag nach Gruppe | Welchen Anteil der Gesamtenergie macht jedes Gebäude aus? | | Datenprofiling | Nullbericht, Schemainspektion, Wertverteilung | Gibt es Sensoren mit fehlenden Daten? | | Zeitlich | Differenz von Periode zu Periode, prozentuale Veränderung, rollierende Statistiken | Wie hat sich der Energieverbrauch von Monat zu Monat verändert? | #### Abgeleitete Ergebnismengen Einige Inspektionsoperationen erzeugen nicht nur skalare Werte, sondern neue tabellarische Ergebnismengen. Wenn man beispielsweise die prozentuale Veränderung des Monats gegenüber dem Vormonat pro Gebäude berechnet, entsteht eine neue Tabelle mit den ursprünglichen Gruppierungsspalten sowie berechneten Delta-Spalten. Diese **abgeleiteten Ergebnismengen** können: * Als Eingabe für weitere Inspektionsoperationen verwendet werden (Verkettung) * An einen Visualisierungs-Subagenten zur Diagrammerstellung übergeben werden Diese Verkettungsfähigkeit bedeutet, dass komplexe mehrstufige Analysen aus einfachen, zuverlässigen Grundbausteinen aufgebaut werden können – ohne das LLM jemals um Arithmetik zu bitten. ### Visualisierung #### Das Zuordnungsproblem Das Erzeugen eines nützlichen Diagramms aus einem SQL-Ergebnis erfordert die Lösung eines mehrdimensionalen Zuordnungsproblems: * **Was möchte der Benutzer verstehen?** (Vergleich, Trend, Verteilung, Zusammensetzung) * **Wie ist die Struktur der Daten?** (Zeitreihe, kategorisch, Matrix, einzelne Kennzahl) * **Welcher Diagrammtyp stellt diese Kombination am besten dar?** (Linie, Balken, Kreis, Heatmap, Streudiagramm) * **Wie sollten Datenspalten den visuellen Elementen zugeordnet werden?** (x-Achse, y-Achse, Seriengruppierung) * **Wie viele Daten werden benötigt?** (Reichen 10 Vorschauzeilen aus, oder erfordert die Diagrammqualität den vollständigen Ergebnissatz?) Ein regelbasierter Diagrammgenerator kann einfache Fälle handhaben (eine Zeitspalte + eine Kennzahlenspalte -> Liniendiagramm). Aber die Datenanalyse in der Praxis erzeugt vielfältige Ergebnisformen: * Mehrere Kennzahlen mit unterschiedlichen Einheiten auf derselben Zeitachse * Gruppierte Kategorien, bei denen Serien nach einem Spaltenwert aufgeteilt werden sollten * Matrixförmige Daten, die ein Heatmap oder eine Reihe gruppierter Balken sein könnten * Ergebnisse, bei denen nur eine Teilmenge der Spalten für die Diagrammerstellung relevant ist Ein **Visualisierungs-Subagent** bewältigt diese Vielfalt, indem er erhält: 1. Die Struktur des Ergebnissatzes (Spalten, Typen, Zeilenanzahl) 2. Eine übergeordnete **Visualisierungsabsicht** vom Orchestrator (z. B. „Gebäude im Zeitverlauf vergleichen“, „Verteilung der Temperaturen anzeigen“) 3. Optionale Baselines oder Anzeigeeinstellungen Dann entscheidet er unabhängig: * Wie viele Diagramme erzeugt werden sollen * Welche Diagrammtypen verwendet werden sollen * Wie Spalten Diagrammen zugeordnet werden (Achsen, Serien, Kategorien) * Anzeigeoptionen (Stapeln, Ausrichtung, Sortierung, Behandlung von Nullwerten) Die Ausgabe ist ein strukturiertes **Visualisierungsplan,** eine deklarative Spezifikation, die in eine größere Diagrammkonfiguration kompiliert werden kann. Anstatt den vollständigen Diagrammkonfigurationscode zu schreiben oder ein Bild zu erzeugen, erstellt sie eine Zuordnungskonfiguration, die die Struktur der Daten in eine visuelle Struktur übersetzt. Benutzer können diese Entscheidungen überschreiben, aber das Standardverhalten ist darauf ausgelegt, nützliche Visualisierungen zu erzeugen, ohne dass eine manuelle Diagrammkonfiguration erforderlich ist.\ Ein Visualisierungs-Subagent arbeitet nach demselben Prinzip wie andere agentische Integrationen: Der Benutzer gibt an, was er verstehen möchte, und das System übernimmt die technische Übersetzung. --- # 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/agents/result-analysis.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.