> 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/agenten/ergebnisanalyse.md). # Ergebnisanalyse 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 handlungsrelevanten 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 zwar „Was sind die Daten?“, aber nicht die Fragen, die den Nutzer 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 Ein natürlicher Impuls ist es, 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 Tokens, nicht als Zahlen. Die Zahl „1,247.83“ wird intern nicht als Gleitkommawert dargestellt, sondern als eine Folge von Tokens (z. B. „1“, „,“, „24“, „7.8“, „3“).\ Diese Darstellung ist grundsätzlich ungeeignet für präzise Arithmetik. LLMs können zwar Berechnungen durchführen, sollten aber im Allgemeinen als unzuverlässig für Aufgaben wie die folgenden behandelt werden: * Summieren von Zahlenspalten * Berechnen von Durchschnitt, Median oder Prozentsätzen * Vergleich von Werten über Zeilen hinweg mit Präzision * Erkennen kleiner, aber bedeutsamer 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 erzeugte Berechnungen nicht vertrauenswürdig. #### Sättigung des Kontextfensters Das Einspeisen großer Ergebnis-Sets in das Kontextfenster eines LLMs erzeugt zusätzliche Probleme: * **Aufmerksamkeitsverwässerung**: 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 Ergebnis-Sets 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 von Tokens tabellarischer Daten ist langsam und teuer, insbesondere wenn das Modell anschließend eine unzuverlässige Analyse dieser Daten erzeugt. Die Schlussfolgerung ist klar: **LLMs sollten keine numerischen Berechnungen auf Rohdaten durchführen.** Sie sollten entscheiden *was* berechnet werden soll, und die eigentliche Berechnung deterministischen Werkzeugen überlassen. ### Deterministische Ergebnisinspektion Das Prinzip hinter 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. „die Top 3 Gebäude nach gesamtem Energieverbrauch berechnen und jedes mit dem Gruppendurchschnitt vergleichen“). * **Ein deterministisches Tool führt aus** die Operation mit exakter Arithmetik auf dem vollständigen Ergebnis-Set aus und gibt die berechneten Werte zurück. * **Das LLM interpretiert** die Ausgabe des Tools und bezieht sie in die Antwort ein. 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. Ergebnis-Set-Inspektion / -Analyse: * Ein LLM rohe Daten analysieren zu lassen, ist selten eine gute Idee (Konzept von Tokens und Zahlen!!) * Das Abladen von Hunderten Zeilen Rohdaten füllt den verfügbaren Kontext sehr schnell und führt zu Genauigkeitsverlusten * Es sollte möglichst vermieden werden, dass es numerische Berechnungen durchführt * Stattdessen sollte man ihm einen praktischen Satz von Werkzeugen und Funktionen geben, die es deterministisch auf Ergebnis-Sets anwenden kann (diese führen die eigentlichen Berechnungen durch); das LLM entscheidet nur, welche Funktion auf welchen Teil der Daten angewendet werden soll, und sieht nur das von der Funktion berechnete Ergebnis **Beispieloperationen:** | Kategorie | Operationen | Beispielanwendungsfall | | ----------- | ------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------- | | Aggregation | Summe, Mittelwert, Median, Minimum, Maximum, Anzahl | „Was ist die durchschnittliche Temperatur über alle Räume hinweg?“ | | Rangfolge | Top N, Bottom N, Zeile mit Max/Min | „Welches Gebäude verbraucht am meisten Energie?“ | | Vergleich | Vergleich mit Gruppenmittelwert/-median, Differenz über Spalten hinweg, Veränderung von Periode zu Periode, Abweichung vom Basiswert | „Wie schneidet Gebäude A im Vergleich zum Portfoliodurchschnitt ab?“ | | Beitrag | Prozentualer Anteil am Gesamtwert, Beitrag nach Gruppe | „Welchen Anteil am gesamten Energieverbrauch hat jedes Gebäude?“ | | Profiling | Null-Bericht, 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 Ergebnis-Sets Einige Inspektionsoperationen erzeugen nicht nur skalare Werte, sondern neue tabellarische Ergebnis-Sets. Beispielsweise erzeugt das Berechnen der prozentualen Veränderung von Monat zu Monat pro Gebäude eine neue Tabelle mit den ursprünglichen Gruppierungsspalten plus berechneten Delta-Spalten. Diese **abgeleiteten Ergebnis-Sets** können: * Als Eingabe für weitere Inspektionsoperationen verwendet werden (Verkettung) * An einen Visualisierungs-Subagenten zur Diagrammerstellung übergeben werden Diese Fähigkeit zur Verkettung 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 Aus einem SQL-Ergebnis ein nützliches Diagramm zu erzeugen, erfordert das Lösen eines mehrdimensionalen Zuordnungsproblems: * **Was möchte der Nutzer verstehen?** (Vergleich, Trend, Verteilung, Zusammensetzung) * **Wie ist die Struktur der Daten?** (Zeitreihe, kategorisch, Matrix, Einzelmetrik) * **Welcher Diagrammtyp stellt diese Kombination am besten dar?** (Linie, Balken, Kreis, Heatmap, Streudiagramm) * **Wie sollen Daten-Spalten auf die Visualisierung abgebildet werden?** (x-Achse, y-Achse, Seriengruppierung) * **Wie viele Daten werden benötigt?** (reichen 10 Vorschaureihen aus, oder erfordert die Diagrammqualität das vollständige Ergebnis-Set?) Ein regelbasierter Diagrammgenerator kann einfache Fälle handhaben (eine Zeitspalte + eine Metrikspalte -> Liniendiagramm). Aber die Datenanalyse in der realen Welt erzeugt vielfältige Ergebnisformen: * Mehrere Metriken mit unterschiedlichen Einheiten auf derselben Zeitachse * Gruppierte Kategorien, bei denen Serien nach einem Spaltenwert aufgeteilt werden sollten * Matrixförmige Daten, die eine 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 Ergebnis-Sets (Spalten, Typen, Zeilenanzahl) 2. Eine hochlevelige **Visualisierungsabsicht** vom Orchestrator (z. B. „Gebäude im Zeitverlauf vergleichen“, „Verteilung der Temperaturen anzeigen“) 3. Optionale Basiswerte oder Anzeigepräferenzen Danach entscheidet er eigenständig: * Wie viele Diagramme erzeugt werden sollen * Welche Diagrammart(en) verwendet werden sollen * Wie Spalten Diagrammen zugeordnet werden (Achsen, Serien, Kategorien) * Anzeigeoptionen (Stapelung, Ausrichtung, Sortierung, Umgang mit Nullwerten) Die Ausgabe ist ein strukturiertes **Visualisierungsplan,** eine deklarative Spezifikation, die in eine größere Diagrammkonfiguration übersetzt werden kann. Anstatt den vollständigen Code für die Diagrammkonfiguration 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 sagt, 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-ki-und-maschinelles-lernen-in-buildingpro-suites/agenten/ergebnisanalyse.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.