Datenkonsolidierung mittels Large Language Model

Von regelbasiertem Matching zu semantischer Intelligenz

Die Konsolidierung von Daten aus unterschiedlichen Quellen gehört zu den klassischen Herausforderungen datengetriebener Systeme. Anspruchsvoll wird es, wenn zwei (oder mehr) Datenprovider ähnliche, aber nicht identische Informationen über dieselben Entitäten liefern – etwa zu Produkten, Unternehmen, Events, Locations oder Personen.

In unserem Projekt standen wir genau vor dieser Situation: zwei externe APIs lieferten strukturierte Ereignisdaten aus dem Unterhaltungsbereich mit erheblicher inhaltlicher Überschneidung. Viele Ereignisse waren in beiden Quellen enthalten, unterschieden sich jedoch in der konkreten Benennung, in Schreibweisen sowie bezüglich weiterer Metadaten. Ziel war es, diese Informationen automatisiert zusammenzuführen – präzise, skalierbar und wartbar.

Aus Datenschutzgründen haben wir den konkreten Use Case für diesen Blogartikel verfremdet und illustrieren ihn anhand des folgenden Produktmatchings von zwei Lieferanten: Lieferant A führt das Produkt "Smarte LED Deckenlampe 30x120 cm". Bei Lieferant B gibt es das Produkt "Smart LED Panel rectangular 0,3 x 1,2m warm white". Hat man nun Informationen zu Produktmerkmalen wie das Gewicht des Pakets, den Hersteller sowie weitere Spezifikationen, dann kann das darauf hinweisen, dass es sich mit hoher Wahrscheinlichkeit um die gleiche Lampe handelt.

Was zunächst als Proof of Concept begann, ist inzwischen produktiv im Einsatz. Nach einer erfolgreichen Evaluierungsphase wurde das System in eine bestehende Web-Applikation integriert. Von dort aus wird der Konsolidierungsprozess mehrmals täglich vom Kunden angestoßen: die APIs beider Provider werden abgefragt, die Daten semantisch per Large Language Model (LLM) gematcht und potenzielle Duplikate identifiziert.

Ausgangssituation: Regelbasiertes Matching

Ursprünglich erfolgte das Matching der Daten über linguistisch basierte Regeln auf unterschiedlichen inhaltlichen Ebenen, etwa hinsichtlich der Produktbeschreibungen oder der Hersteller. Zum Einsatz kamen unter anderem die Normalisierung von Strings (z. B. Lowercasing, Stemming, Entfernen von Sonderzeichen), gepflegte Synonymlisten, Fuzzy-Matching mit definierten Schwellwerten sowie gewichtete Ähnlichkeitsmetriken.

Solche Verfahren sind grundsätzlich bewährt, stoßen jedoch schnell an ihre Grenzen – und konnten in unserem konkreten Anwendungsfall keine wirklich zufriedenstellende Matching-Quote erzielen, sodass viel manuelle Nachbearbeitung notwendig war.

Mit zunehmender Datenvielfalt steigt der Pflegeaufwand erheblich, Regelwerke werden komplex und schwer wartbar, und neue Edge Cases erfordern kontinuierliche Nachjustierungen. Zudem bleiben semantische Zusammenhänge, die über rein syntaktische Ähnlichkeiten hinausgehen, weitgehend unberücksichtigt.

Semantisches Matching mit der OpenAI-API

Mit Large Language Models (LLMs) stehen heute Werkzeuge zur Verfügung, die semantische Ähnlichkeit erfassen können – unabhängig von exakten Wortübereinstimmungen.

Für die Umsetzung des Matchings haben wir uns für die Nutzung der OpenAI API entschieden. Sie ermöglicht den Einsatz leistungsfähiger LLMs, ohne Infrastruktur in den Tech-Stack des Kunden integrieren oder Trainings- und Wartungsaufwände für Modelle übernehmen zu müssen. Gleichzeitig erlaubt sie eine schnelle und skalierbare Einbindung in bestehende Systeme. Durch strukturierte Outputs und ein Pay-per-Use-Abrechnungsmodell eignet sich die Lösung für produktive Anwendungen mit hoher Flexibilität und gut planbaren Betriebskosten.

Nach einer vorgelagerten Datenaufbereitung werden die zu matchenden Daten an die OpenAI API übermittelt. Gemeinsam mit den aufbereiteten Daten senden wir einen gezielt formulierten Prompt, der das LLM anweist, die Datensätze semantisch zu analysieren und zu entscheiden, welche Daten zusammengehören und welche nicht. Gleichzeitig definieren wir darin das gewünschte Ausgabeformat, um eine strukturierte Weiterverarbeitung der Ergebnisse zu gewährleisten.

Eines unserer zentralen Learnings ist, dass die Qualität des Matchings maßgeblich von der Präzision des Prompts abhängt. Im Prompt spezifizieren wir primäre, sekundäre und tertiäre Matching-Kriterien sowie verbindliche Constraints und Blocker, um False Positives zu reduzieren und zugleich False Negatives möglichst gering zu halten. Spezifischer: die Matching-Logik priorisiert die Ähnlichkeit von (Produkt-)namen als primäres Kriterium und nutzt Metadaten (das können zum Beispiel Hersteller oder Produktmerkmale sein) als unterstützende Signale (sekundäre und tertiäre Matching-Kriterien). Außerdem ignoriert sie bestimmte Unterschiede oder tolerierbare Abweichungen in Bezeichnungen oder technischen Details, die teilweise aus Fehlspezifikationen resultieren. Zusätzlich ergänzen wir den Prompt um Few-Shot-Beispiele, die das gewünschte Entscheidungsverhalten illustrieren, und definieren klare Instruktionen zum Output via Structured Outputs, um konsistente und maschinenlesbare Ergebnisse über ein JSON-Schema sicherzustellen.

Da die Anzahl der zu überprüfenden Daten sehr groß ist, partitionieren wir die Daten anhand von klar definierten Codes in Batches. Die Codes (zum Beispiel ISO-Ländercodes) sind nicht fehleranfällig, sodass Abweichungen zwischen den Providern an dieser Stelle ausgeschlossen sind. Dadurch reduzieren wir den Vergleichsraum und stellen sicher, dass nur plausible Daten miteinander abgeglichen werden. In der Evaluation der Matching-Ergebnisse haben wir festgestellt, dass trotz eines eng definierten Prompts vereinzelt Zuordnungen entstehen, die offensichtlich fehlerhaft sind. Diese Fälle lassen sich vermutlich darauf zurückführen, dass LLMs in seltenen Situationen zu inkorrekten Schlussfolgerungen neigen – ein Phänomen, das häufig unter dem Begriff "Halluzination" beschrieben wird.

Durch einen zweiten API-Call, bei dem wir die zuvor konsolidierten Ergebnisse im Sinne eines "LLM as a Judge"-Ansatzes erneut überprüfen lassen und zusätzlich einen Confidence-Score erzeugen, konnten wir dieses Verhalten reduzieren bzw. sichtbar machen.

Insgesamt hat sich das Matching von einem regelbasierten Prozess zu einer semantisch fundierten Entscheidungslogik gewandelt, die verlässlich korrekte, hohe Matching-Quoten zeigt.

Architektur des Konsolidierungssystems

Das System ist als FastAPI-Anwendung implementiert und wird containerisiert in Kubernetes auf AWS betrieben.

Vereinfacht dargestellt umfasst der Prozess folgende Schritte:

1. Die APIs von Provider 1 und Provider 2 werden periodisch abgefragt.
2. Die eingehenden Daten werden normalisiert und harmonisiert.
3. Über einen Button in der Web-App wird der Matching-Prozess angestoßen.
4. Die FastAPI-Anwendung partitioniert die normalisierten Daten in Batches auf Basis von nicht fehleranfälligen Spezifikationscodes und übermittelt diese an die OpenAI-API.
5. Das LLM identifiziert innerhalb jedes Batches potenzielle Matches.
6. In einem zweiten API-Call werden die ermittelten Matches im Sinne eines "LLM-as-a-Judge"-Ansatzes überprüft und mit einem Confidence-Score versehen.
7. Die Ergebnisse werden in der Web-App angezeigt und um zusätzliche Informationen angereichert.
8. Manuelle Korrekturen können direkt in der Web-App vorgenommen werden.
9. Die vollständig konsolidierten und validierten Daten stehen anschließend für weitere Prozessierung bereit.

Abschließende Anmerkungen

Trotz des hohen Automatisierungsgrads ist das System bewusst nicht als Black Box konzipiert. In der Webapplikation bleiben die Rohdaten beider Provider jederzeit transparent einsehbar. Diese Transparenz ist essentiell, denn auch bei sehr geringer Fehlerrate ist das Matching-System nicht unfehlbar.

Falsch-positive Matches sind in der Praxis vergleichsweise leicht zu erkennen und zu korrigieren. Der Confidence-Score unterstützt dabei, potenziell fehlerhafte Zuordnungen in der Web-App gezielt zu identifizieren und bei Bedarf manuell zu trennen. Deutlich aufwändiger ist hingegen die Identifikation nicht gematchter Daten. Solche "False Negatives" erfordern eine aktive Suche nach potenziellen Dubletten und verursachen entsprechend einen höheren manuellen Prüfaufwand. Durch den Einsatz des LLM-basierten Ansatzes konnte die Anzahl dieser nicht erkannten Duplikate im Vergleich zum früheren regelbasierten Verfahren signifikant reduziert werden.

Die implementierte Lösung weist derzeit eine Matching-Dauer von mehreren Minuten auf. Für den konkreten Anwendungsfall ist diese Laufzeit ausreichend performant, bietet jedoch weiteres Optimierungspotenzial. Eine deutliche Performancesteigerung ließe sich insbesondere durch den Einsatz intelligenter Caching-Strategien erzielen. Durch das Zwischenspeichern bereits bewerteter Matches oder von gematchten Herstellern oder technischen Details könnten sowohl die Anzahl der LLM-Calls an die OpenAI-API als auch das übertragene Datenvolumen reduziert werden. Dies würde Latenz und Kosten gleichermaßen senken. Demgegenüber steht jedoch ein erhöhter Pflege- und Wartungsaufwand für die Caching-Infrastruktur. Insbesondere bei sich ändernden Produktdaten müssten Cache-Invalidierungsstrategien sorgfältig implementiert werden, um Konsistenz und Aktualität der Ergebnisse sicherzustellen. Hier zeigt sich der klassische Trade-off zwischen Performance-Optimierung und Systemkomplexität.