Ergebnisanalyse
Allein der Datenabruf ist oft unzureichend. Nutzer müssen Muster, Vergleiche und Trends sehen, um Schlussfolgerungen zu ziehen. Sprachmodelle können bei der Interpretation von Ergebnissen hilfreich sein, wenn sie korrekt eingesetzt werden.
Das Abrufen von Daten aus einer Datenbank ist nur der erste Schritt. Eine Datenbankabfrage gibt Zeilen und Spalten zurück, aber der Nutzer 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 „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 naheliegender Reflex 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 Fließkommawert dargestellt, sondern als Sequenz von Tokens (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 für Aufgaben wie die folgenden als unzuverlässig betrachtet werden:
Spalten von Zahlen summieren
Durchschnittswerte, Mediane oder Prozentsätze berechnen
Werte über Zeilen hinweg präzise vergleichen
Kleine, aber bedeutungsvolle Unterschiede erkennen
Die Fehlerrate steigt mit der Anzahl der beteiligten Werte und der erforderlichen Präzision. Für analytische Aufgaben, bei denen numerische Genauigkeit wichtig ist, sind von LLMs erzeugte Berechnungen nicht vertrauenswürdig.
Sättigung des Kontextfensters
Das Übergeben großer Ergebnismengen in das Kontextfenster eines LLMs bringt zusätzliche Probleme mit sich:
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 Ergebnismengen können das verfügbare Kontextfenster vollständig überschreiten oder so viel davon belegen, dass das Modell neben den Daten keine nützliche Antwort mehr erzeugen kann.
Kosten und Latenz: Tausende von Tokens tabellarischer Daten zu verarbeiten ist langsam und teuer, besonders 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 der deterministischen Ergebnisinspektion ist eine klare Trennung der Verantwortlichkeiten:
Das LLM entscheidet welche analytische Operation angewendet werden soll und auf welchen Teil der Daten (z. B. "berechne die Top-3-Gebäude nach gesamtem Energieverbrauch und vergleiche jedes mit dem Gruppendurchschnitt").
Ein deterministisches Werkzeug führt aus die Operation mit exakter Arithmetik auf dem gesamten Ergebnissatz und gibt die berechneten Werte zurück.
Das LLM interpretiert die Ausgabe des Werkzeugs und bezieht sie in die Antwort ein.
Das LLM sieht nie alle Rohzeilen. Es sieht eine kleine Vorschau (ausreichend, um die Datenstruktur zu verstehen) und arbeitet dann mit den deterministisch berechneten Ergebnissen aus dem Inspektionstool.
Ergebnismenge-Inspektion / Analyse:
Ein LLM rohe Daten analysieren zu lassen, ist selten eine gute Idee (Konzept von Tokens und Zahlen!!)
Das Abladen von Hunderten von Zeilen roher Daten füllt den verfügbaren Kontext sehr schnell und führt zu Genauigkeitsverlusten
Es sollte vermieden werden, es nach Möglichkeit numerische Berechnungen durchführen zu lassen
Geben Sie ihm stattdessen einen praktischen Satz an Werkzeugen und Funktionen, die es deterministisch auf Ergebnismengen anwenden kann (diese führen die eigentlichen Berechnungen aus); das LLM entscheidet nur, welche Funktion es auf welchen Teil der Daten anwenden soll, und sieht nur das von der Funktion berechnete Ergebnis
Beispieloperationen:
Aggregation
Summe, Mittelwert, Median, Minimum, Maximum, Anzahl
„Wie hoch ist die durchschnittliche Temperatur in allen Räumen?“
Ranking
Top N, Bottom N, Zeile mit Max/Min
„Welches Gebäude verbraucht am meisten Energie?“
Vergleich
Vergleich mit Gruppenmittelwert/-median, Delta zwischen Spalten, 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 Gesamtenergieverbrauch hat jedes Gebäude?“
Profiling
Nullwertbericht, Schema-Inspektion, Werteverteilung
„Gibt es Sensoren mit fehlenden Daten?“
Zeitlich
Differenz von Periode zu Periode, prozentuale Veränderung, gleitende 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. So erzeugt beispielsweise die Berechnung 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 Ergebnismengen können:
als Eingabe für weitere Inspektionsoperationen verwendet werden (Verkettung)
an einen Visualisierungs-Subagenten für die Diagrammerstellung übergeben werden
Diese Fähigkeit zur Verkettung bedeutet, dass komplexe mehrstufige Analysen aus einfachen, zuverlässigen Grundbausteinen aufgebaut werden können – ohne jemals das LLM um Arithmetik zu bitten.
Visualisierung
Das Zuordnungsproblem
Aus einem SQL-Ergebnis ein nützliches Diagramm zu erzeugen, erfordert die Lösung eines mehrdimensionalen Zuordnungsproblems:
Was möchte der Nutzer verstehen? (Vergleich, Trend, Verteilung, Zusammensetzung)
Wie ist die Struktur der Daten? (Zeitreihe, kategorial, Matrix, Einzelmetrik)
Welcher Diagrammtyp stellt diese Kombination am besten dar? (Linie, Balken, Kreis, Heatmap, Streuung)
Wie sollten Datenspalten den visuellen Elementen zugeordnet werden? (x-Achse, y-Achse, Gruppierung der Reihen)
Wie viele Daten werden benötigt? (reichen 10 Vorschauzeilen aus, oder erfordert die Diagrammqualität die gesamte Ergebnismenge?)
Ein regelbasiertes Diagrammgenerator kann einfache Fälle behandeln (eine Zeitspalte + eine Metrikspalte -> Liniendiagramm). In der realen Datenanalyse entstehen jedoch vielfältige Ergebnisformen:
Mehrere Metriken mit unterschiedlichen Einheiten auf derselben Zeitachse
Gruppierte Kategorien, bei denen Reihen nach einem Spaltenwert getrennt 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 Visualisierung relevant ist
Ein Visualisierungs-Subagent bewältigt diese Vielfalt, indem er Folgendes erhält:
Die Struktur der Ergebnismenge (Spalten, Typen, Zeilenanzahl)
Eine hochlevelige Visualisierungsabsicht vom Orchestrator (z. B. "Gebäude im Zeitverlauf vergleichen", "Verteilung der Temperaturen anzeigen")
Optionale Basiswerte oder Anzeigepräferenzen
Anschließend entscheidet er eigenständig:
Wie viele Diagramme erzeugt werden sollen
Welche Diagrammtypen verwendet werden sollen
Wie Spalten Diagrammen zugeordnet werden (Achsen, Reihen, Kategorien)
Anzeigeoptionen (Stapeln, Ausrichtung, Sortierung, Umgang mit Nullwerten)
Die Ausgabe ist ein strukturiert es Visualisierungsplan, eine deklarative Spezifikation, die in eine größere Diagrammkonfiguration übersetzt 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.
Nutzer 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 Nutzer sagt, was er verstehen möchte, und das System übernimmt die technische Übersetzung.
Zuletzt aktualisiert
War das hilfreich?