Vom Datenschatz zum Erkenntnissystem: Ein Multi‑Agenten‑Ansatz mit LLMs

Dieser Artikel ist der zweite Teil meiner Erfahrungen mit Projekten bei denen wir LLMs in Umgebungen mit großen, chaotischen Daten eingesetzt haben. Den ersten Teil findet ihr hier.

Viele Unternehmen sitzen auf einem enormen Datenschatz – und können ihn dennoch schwer heben. Über Jahre ist eine Plattform mit Tausenden Tabellen gewachsen, die nur für langjährige Experten wirklich sichtbar ist. Wir sollten ein Experiment durchführen: Kann ein LLM-Agent belastbare Analysen zu Produkten, ihren Eigenschaften und den dazugehörigen Marketingaktivitäten auf diesen Daten durchführen? Zum Beispiel Fragen wie: Welche Merkmale prägen erfolgreiche Produkte? Welche Maßnahmen greifen wo? Ein Teilexperiment, das wir durchgeführt haben, war ein selbstgebautes Multi-Agenten System.

Der Agenten-Aufbau

Der Einstieg begann mit Ordnung. Statt die komplette Landschaft zu erfassen, haben wir mit Domain-Experten gezielt einen Kern an Tabellen identifiziert, die für Produkt- und Marketingfragen relevant sind. Zu diesen Tabellen und ihren wichtigsten Spalten entstanden kurze, präzise, durch den Menschen formulierte Beschreibungen: wofür sie stehen, wie sie zusammenhängen, welche typischen Stolperfallen es gibt. Ein LLM half uns, durch Daten-Sampling zusätzliche Strukturtexte zu erzeugen – Verteilungen, Wertebereiche, Join-Hinweise – sodass aus dünner Dokumentation ein kompakter Katalog wurde, der Menschen und Modellen gleichermaßen Orientierung bietet.

Darauf aufbauend entstand die Architektur des Multi-Agenten. Wir trennen Rollen und Verantwortlichkeiten: Ein Retrieval-Agent hat den Datenzugriff – ausschließlich auf Basis der Metadaten und Beschreibungen. Er entscheidet, welche Tabellen und Felder für eine konkrete Frage zu Produkten und Marketing herangezogen werden und formuliert die nötigen SQL-Queries. Die Ergebnisse werden zwischengespeichert, das LLM erhält nur Metadaten, die wichtig sind, um die Daten wiederzufinden. So vermeiden wir, dass das LLM bei großen Ergebnissen durch Halluzination diese verfälscht.

Ein Analyse-Agent erhält dann Zugriff auf die Datenbeschreibungen und den Speicherort, um so Analyseschritte durchzuführen und eine Interpretation der Zahlen zu ermöglichen.

Am Ende werden die Analysen durch einen Reporting-Agenten gesammelt und aufbereitet.

Stolpersteine und Erkenntnisse

Selbst die Menge der vorausgewählten Tabellen stellte sich als zu groß für zuverlässige LLM-Ergebnisse heraus. Zwar haben diese alle in das Kontextfenster gepasst (1 Million Token sind groß genug für mehrere Bücher), aber die Präzision lässt dort dennoch zu wünschen übrig. In der aktuellen Forschung wird hier von „Context Rot“ gesprochen. Die Faustregel ist, nur den wirklich relevanten Kontext zur Verfügung zu stellen. Wir nennen das Context Engineering. In einem mehrstufigen Prozess wurde die Anfrage des LLMs erst klassifiziert, damit danach die Gruppe der Tabellen eingeordnet werden konnte, die benötigt wird. Danach wurde ein weiteres LLM befragt, das die Gruppe genauer kannte und so die richtigen Tabellen vorausgewählt hat. Am Ende erhält der Retrieval-Agent nur die Metainformationen dieser ausgewählten Tabellen, um den Query zu formulieren.

Eine weitere Lehre war, dass Retrieval viel schwieriger ist, als es klingt. Selbst in einem Produkt- und Marketingkontext sind Synonyme, historische Bezeichnungen oder unterschiedliche Logiken für Produktzuordnungen tückisch. Die Suche nach Namen allein greift zu kurz; die relevanten Informationen liegen oft an mehreren Stellen, in verschiedenen Granularitäten.

Darauf haben wir mit zwei Methoden reagiert. Handelt es sich um einen simplen Prozess, hat es gereicht Details hinzuzufügen, wie diese Informationen in der richtigen Reihenfolge durch Joins gefunden werden können. Komplexere aber wieder vorkommende Requests, wie die eindeutige Bestimmung aller Produkte einer Gattung, haben wir durch Code vorbereitet, sodass das LLM nur notwendige Stichwörter füllen oder aus Ergebnislisten auswählen musste. Damit haben wir es geschafft, starre aber wichtige Prozesse mit der Flexibilität und dem gewünschten alternativen Blickwinkel eines Agenten zu vereinbaren.

Das größte Hindernis für uns war am Ende aber die Flexibilität der Agenten. Die gleiche Frage wurde durch das LLM immer anders versucht zu lösen. Das war der stärkste Vorteil, den wir uns erhofft haben: einen neuen, dynamischen Blickwinkel. Aber bei der Implementierung wurde so das richtige Debugging nahezu unmöglich. Des Weiteren mussten nun alle Analysemethoden derart flexibel formuliert werden, dass sie auf jegliche zur Verfügung gestellten Daten passen können und auch mit ständig wechselnder Reihenfolge der Spalten umgehen konnten.

Aufgrund der kurzen Zeit bleibt somit offen, wie wir die Komplexität weiter senken können, ohne an Präzision zu verlieren.

Zusammengefasst haben wir aus diesem und dem vorherigen Projekt wertvolle Erkenntnisse gewinnen können.

Was sich bewährt hat:

• Reduktion vor Detailtiefe: Datenraum möglichst früh verkleinern um den Kontext gezielt zu füllen
• Annotationen der Daten, zusätzlich zu den maschinennotwendigen Namen und Typen sind unerlässlich. Mein Tipp ist hier: Wenn jemand neu eingestellt wird, und die Grundlage ist gut genug, damit diese Person alleine die Daten verstehen kann, dann befinden wir uns in einer guten Ausgangssituation. Ein LLM nutzt auch natürliche Sprache zum „Verständnis“ und kann diese nutzen.
• Struktur statt Freitext: Typisierte, validierte Ausgaben sind die Grundlage für belastbare Automatisierung.
• Transparenz als Standard: Quellen, Regeln und Zwischenergebnisse dokumentieren – und zwar so, dass sie maschinell und menschlich prüfbar sind.

Was wir meiden:

• „Alles-in-einem“-Prompts. Selbst wenn die Kontextlänge ausreicht, leidet die Präzision.

Fazit

LLMs sind im Data Engineering/Science kein Zauberstab, aber ein echter Hebel. Richtig eingesetzt helfen sie, komplexe Datenlandschaften in verlässliche, nachvollziehbare Ergebnisse zu überführen. Der Schlüssel liegt in der Kombination aus Reduktion der Komplexität, erzwungener Struktur und iterativen Workflows. So wird aus dem Datenchaos kein perfekter Garten – aber ein robustes System, das wächst, skaliert und Ergebnisse liefert, denen man vertrauen kann.