Entitätsauflösung mit Elasticsearch, Teil 4: Die ultimative Herausforderung

Wir haben nun die Implementierung intelligenter Entitätsauflösung auf zwei Arten gesehen. Beide Ansätze beginnen auf dieselbe Weise: Aufbereitung und Extraktion der Entitäten, gefolgt vom Abruf der Kandidaten mit Elasticsearch. Anschließend bewerten wir diese Kandidaten mithilfe eines großen Sprachmodells (LLM), entweder durch promptbasierte JSON-Generierung oder durch Funktionsaufrufe, und fordern vom Modell eine transparente Begründung für seine Entscheidung.

Wie wir im vorherigen Beitrag gesehen haben, ist die Konstanz, die durch Funktionsaufrufe ermöglicht wird, nicht nur eine praktische Optimierung, sondern essenziell. Nachdem wir strukturelle Fehler aus dem Evaluationskreislauf entfernt hatten, verbesserten sich die Ergebnisse in Standardszenarien (wie denen im Tier-4-Datensatz) dramatisch.

Doch eine offensichtliche Frage bleibt noch zu beantworten:

Funktioniert dieser Ansatz noch, wenn es kompliziert wird?

Die Entitätsauflösung in der realen Welt schlägt selten in einfachen Fällen fehl. Sie scheitert, wenn Namen Sprach-, Kultur-, Schrift-, Zeit- und Unternehmensgrenzen überschreiten. Sie scheitert, wenn auf Menschen mit Titeln anstelle von Namen Bezug genommen wird, wenn Unternehmen Namen ändern, wenn Transliterationen nicht konstant sind und wenn Kontext (nicht die Schreibweise) das Einzige ist, was eine Erwähnung mit einer realen Entität verbindet.

Für den letzten Beitrag dieser Serie haben wir das System einer sogenannten ultimativen Herausforderung unterzogen.

Was macht dies zur ultimativen Herausforderung?

In früheren Auswertungen haben wir das System mit zunehmend komplexeren Datensätzen getestet. Als wir die im vorherigen Beitrag besprochene Stufe 4 erreichten, hatten wir es bereits mit einer Mischung aus Spitznamen, Titeln, mehrsprachigen Namen und semantischen Bezügen zu tun. Diese Tests zeigten, dass die Architektur selbst solide war, aber dass Zuverlässigkeitsprobleme, insbesondere fehlerhaftes JSON, den Rückruf unterdrückten.

Mit dem implementierten Funktionsaufruf hatten wir endlich eine stabile Grundlage. So konnten wir eine interessantere Frage stellen:

Kann eine einheitliche Pipeline viele verschiedene Arten von Entitätsauflösungsproblemen gleichzeitig bewältigen?

Der ultimative herausfordernde Datensatz wurde darauf ausgelegt, genau diese Dimension zu erreichen.

Anstatt sich auf eine einzelne Schwierigkeit (wie Spitznamen oder Transliteration) zu konzentrieren, kombiniert dieser Datensatz mehr als 50 verschiedene Herausforderungstypen, darunter:

• Kulturelle Namenskonventionen.
• Titelbasierte Referenzen.
• Geschäftliche Beziehungen und historische Namensänderungen.
• Mehrsprachige und skriptübergreifende Erwähnungen.
• Zusammengesetzte Herausforderungen, die mehrere der oben genannten Punkte kombinieren.

Entscheidend ist, dass es hier nicht um die Optimierung für einen einzigen, eng begrenzten Anwendungsfall geht. Es geht darum zu testen, ob das Entwurfsmuster Bestand hat, wenn sich die Regeln von Entität zu Entität ändern.

Der Datensatz auf einen Blick

Der ultimativ herausfordernde Datensatz besteht aus:

• 50 Entitäten, darunter Personen, Unternehmen und Institutionen.
• ~60 Artikel, mit unterschiedlicher Struktur und sprachlicher Komplexität.
• 51 verschiedene Herausforderungskategorien, grob unterteilt in:
  • Kulturelle Namenskonventionen.
  • Titel und beruflichem Kontext.
  • Geschäfts- und Unternehmensbeziehungen.
  • Mehrsprachigkeit und Transliterationsherausforderungen.
  • Kombinierten und Grenzfall-Szenarien.

Zu Beginn der Serie haben wir gesehen, dass die Verwendung von generativer KI (GenKI) zur Erstellung von Datensätzen ein zweischneidiges Schwert sein kann. Ohne sie wäre es äußerst schwierig, ausreichend große und vielfältige Testdaten zusammenzustellen. Aber wenn das Modell nicht kontrolliert wird, neigt es dazu, die Dinge zu einfach zu machen.

Bei einer frühen Generationsüberprüfung stellten wir beispielsweise fest, dass das Modell Formulierungen wie „der russische Präsident“ als expliziten Aliasnamen für Wladimir Putin enthielt. Das mag heute vernünftig erscheinen, aber es widerspricht dem Zweck der Prüfung der Kontextauflösung. Was passiert, wenn der Artikel Russland in den 1990er Jahren behandelt? Das System sollte die richtige Entität aus dem Kontext ableiten und sich nicht auf einen fest codierten Alias verlassen.

Aus diesem Grund wurde dieser Datensatz bewusst so konzipiert, dass Abkürzungen nicht funktionieren. Pseudonyme werden nicht explizit aufgeführt, wenn das System die Bedeutung erschließen soll. Beschreibende Phrasen sind nicht vorab mit Entitäten verknüpft. Korrekte Treffer hängen oft vom Kontext auf Artikelebene ab, nicht nur vom lokalen Text.

Wichtiger Hinweis: Obwohl wir die Fähigkeiten des Systems in verschiedenen Szenarien demonstrieren, ist dies dennoch ein Bildungsprototyp. Produktionssysteme, die die Überwachung von sanktionierten Entitäten in der realen Welt handhaben, würden zusätzliche Validierung, Compliance-Prüfungen, Audit-Trails und eine spezialisierte Handhabung für sensible Anwendungsfälle erfordern.

Warum diese Szenarien schwierig sind

Im ersten Beitrag dieser Reihe haben wir ein einfaches, aber mehrdeutiges Beispiel vorgestellt: „Das neue Swift-Update ist da!“ Die Herausforderung besteht darin, dass „Swift“ je nach Kontext auf mehrere reale Entitäten aufgelöst werden kann. Dieses Beispiel verdeutlicht eine grundlegendere Wahrheit: Natürliche Sprache ist von Natur aus mehrdeutig.

Die Entitätsauflösung ist daher nicht nur ein Problem des Zeichenfolgenabgleichs. Menschen verlassen sich routinemäßig auf gemeinsames Wissen, kulturelle Normen und situativen Kontext, um Referenzen zu lösen, und oft merken wir gar nicht, dass wir das tun.

Betrachten wir ein paar gängige Fälle:

• Ein Titel wie „der Präsident“ ist ohne geopolitischen und zeitlichen Kontext bedeutungslos.
• Ein Firmenname kann sich je nach Zeitpunkt der Artikelveröffentlichung auf ein Mutterunternehmen, eine Tochtergesellschaft oder eine ehemalige Marke beziehen.
• Der Name einer Person kann in verschiedenen Reihenfolgen, Schriften oder Transliterationen erscheinen, abhängig von Sprache und Kultur.
• Die gleiche Phrase kann in verschiedenen Kontexten legitimerweise auf unterschiedliche Entitäten verweisen, und das System muss in der Lage sein, Matches genauso zuversichtlich abzulehnen, wie sie zu akzeptieren.

Es gibt kein einzelnes Regelwerk, das all dies sauber abdeckt. Deshalb trennt dieser Prototyp die verschiedenen Bereiche so konsequent:

• Elasticsearch schränkt den Kandidatenraum effizient und transparent ein.
• Das LLM wird nur dort verwendet, wo ein Urteil erforderlich ist, und ist gezwungen, sich selbst zu erklären.
• Abruf und Schlussfolgerung bleiben getrennte Schritte.

Diese Trennung wird umso wichtiger, je größer die Vielfalt der Herausforderungen ist.

So geht das System mit Vielfalt ohne Spezialfälle um

Eines der interessantesten Ergebnisse dieser Bewertung ist, was sich nicht geändert hat:

• Wir haben keine spezielle Logik für japanische Namen hinzugefügt.
• Wir haben keine benutzerdefinierten Regeln für arabische Patronyme hinzugefügt.
• Wir haben keine fest codierten Mappings für historische Firmennamen hinzugefügt.

Stattdessen basierte das System auf denselben Kernzutaten, die früher in der Serie eingeführt wurden:

• Mit Kontext angereicherte Entitäten, die für semantische Suchen indexiert sind.
• Hybrider Abruf (exakt, per Alias und semantisch) in Elasticsearch.
• Eine kleine, gut definierte Gruppe von Kandidatenmatches.
• LLM-Bewertung eingeschränkt durch Funktionsaufruf und Minimalschemata.

Das deutet darauf hin, dass die Flexibilität des Systems von Repräsentation und Architektur herrührt, nicht von einer ständig wachsenden Sammlung von Regeln.

Wenn das System erfolgreich ist, liegt das daran, dass die richtigen Kandidaten ermittelt werden und das LLM ausreichend Kontext hat, um zu erklären, warum eine Referenz einer bestimmten Entität zugeordnet wird oder nicht.

Ergebnisse: Wie hat es abgeschnitten?

Im ultimativ herausfordernden Datensatz erzielte das System folgende Gesamtergebnisse:

• Präzision: ~91 %
• Rückruf: ~86 %
• F1-Score: ~89 %
• LLM-Annahmequote: ~72 %

Leistung nach Herausforderungstyp

Die Aufschlüsselung der Ergebnisse nach Herausforderungstyp zeigt Stärken und Schwächen:

Die stärkste Leistung (100 % F1-Score) wurde in folgenden Bereichen beobachtet:

• Schriftübergreifender Abgleich (kyrillische, koreanische, chinesische Unternehmen).
• Hebräische Szenarien (Patronyme, Berufstitel, religiöse Titel, Transliteration).
• Unternehmenshierarchien (Luft- und Raumfahrt, diversifizierte Fertigungsunternehmen, Konzerne mit mehreren Geschäftsbereichen).
• Berufsbezeichnungen (akademisch, militärisch, politisch, religiös).
• Kombinierte japanische Szenarien mit mehreren Schriftsystemen.

Starke Leistung (80–99 % F1-Score) umfassten:

• Internationale politische Persönlichkeiten (98 %).
• Historische Namensänderungen (90 %).
• Komplexe Unternehmenshierarchien (89 %).
• Japanische Firmennamen (93 %).
• Cross-Script-Transliteration (86 %).
• Arabische Patronyme (86 %).

Problematischere Bereiche waren:

• Erweiterte Transliteration (Chinesisch, Koreanisch): 0 % F1.
• Bestimmte japanische Szenarien (Höflichkeitsformen, Namensreihenfolge, Variationen des Schriftsystems): ~67 % F1.
• Einige arabische Szenarien (Unternehmensnamen, institutionelle Referenzen): ~40 % F1.

Wichtig ist hier, warum das System in diesen Fällen Schwierigkeiten hatte. Die Fehler waren nicht auf das Scheitern des Gesamtansatzes zurückzuführen, sondern auf Einschränkungen in bestimmten Komponenten, insbesondere dem dichten Vektormodell, das für die semantische Suche in bestimmten mehrsprachigen Szenarien verwendet wird.

Da Abruf und Beurteilung klar getrennt sind, erfordert die Leistungssteigerung keine Neuprogrammierung des Systems. Der Austausch eines leistungsfähigeren mehrsprachigen Einbettungsmodells, die Anreicherung des Entitätskontextes oder die Verfeinerung der Suchstrategien würde die Ergebnisse in diesen Kategorien verbessern, ohne die Kernarchitektur zu verändern.

Aus architektonischer Sicht ist das der eigentliche Erfolgsmaßstab.

Was uns das über das Design verrät

Beim Rückblick auf die Serie lassen sich einige Muster erkennen:

• Vorbereitung ist wichtiger als kluges Matching. Die Anreicherung von Entitäten mit Kontextinformationen im Vorfeld reduziert spätere Mehrdeutigkeiten erheblich.
• LLMs sind als Bewertungs- und nicht als Abrufsysteme am wertvollsten. Sie um eine Erklärung zu bitten, warum eine Übereinstimmung sinnvoll ist, ist weitaus wirkungsvoller als sie um eine Suche zu bitten.
• Zuverlässigkeit ermöglicht Genauigkeit. Der Funktionsaufruf hat nicht nur JSON bereinigt, sondern auch den Abruf von Informationen freigegeben, die bereits in der Abrufphase latent waren.
• Verallgemeinerung schlägt Spezialisierung. Eine kleine Anzahl gut gewählter Abstraktionen bewältigte Dutzende von Aufgabentypen ohne benutzerdefinierte Logik.

Aus diesem Grund ist der Prototyp bewusst Elasticsearch-nativ und konservativ in der Verwendung von LLMs. Das Ziel besteht nicht darin, das Suchen zu ersetzen. Es geht darum, das Suchen in Situationen erklärbar zu machen, in denen die Bedeutung wichtig ist.

Fazit

Die ultimative Herausforderung bestand nicht darin, perfekte Metriken zu verfolgen; es ging darum, eine grundlegendere Frage zu beantworten:

Kann eine transparente, suchbasierte, LLM-gestützte Architektur mit der Mehrdeutigkeit realer Entitäten umgehen, ohne in Regeln oder Blackboxes zu zerfallen?

Für diesen Bildungsprototyp lautet die Antwort ja, mit klaren Vorbehalten in Bezug auf Produktionshärtung, Compliance, Überwachung und Datenqualität. Wenn Sie Systeme erstellen, die begründen müssen, warum ein Entitätsabgleich vorgenommen wurde, ist dieses Muster eine ernsthafte Überlegung wert. Ich hoffe, diese Serie hat gezeigt, dass die Entitätsauflösung kein Mysterium sein muss. Mit der richtigen Aufteilung der Anliegen wird sie zu etwas, worüber man nachdenken, was man messen und verbessern kann.

Diese Arbeit deutet auch auf ein breiteres architektonisches Muster hin. Daraus entsteht eine leichte, aber wichtige Weiterentwicklung der klassischen Retrieval-Augmented-Generation (RAG). Anstatt die Abfrage direkt in die Generierung einfließen zu lassen, führen wir einen expliziten Bewertungsschritt ein. Das LLM wird zunächst zur Beurteilung und Plausibilitätsprüfung der abgerufenen Kandidaten verwendet, und nur die als geeignet befundenen Ergebnisse dürfen die Generierung erweitern. Sie können sich das als Generation-Augmented Retrieval-Augmented Generation with Evaluation oder GARAGE vorstellen, denn wer weiß nicht ein gutes Akronym zu schätzen?

Welche anderen Anwendungsfälle könnten von diesem Muster profitieren? Systeme, die Vertrauen, Transparenz und nachvollziehbare Argumentation erfordern, sind natürliche Kandidaten. Die künftige Arbeit in diesem Bereich sollte sich als ebenso überzeugend erweisen wie die Ergebnisse, die wir hier gesehen haben, und ich bin gespannt, wie sich die Gemeinschaft weiter entwickelt.

Nächste Schritte: Versuchen Sie es selbst

Möchten Sie die ultimative Herausforderung in Aktion sehen? Schauen Sie sich das Ultimate Challenge-Notebook für eine vollständige Anleitung mit realen Implementierungen, detaillierten Erklärungen und praktischen Beispielen an.

Die vollständige Pipeline zur Entitätsauflösung demonstriert die Kernkonzepte und die Architektur, die für den produktiven Einsatz erforderlich sind. Sie können es als Grundlage nutzen, um Systeme zu entwickeln, die Nachrichtenartikel überwachen, Erwähnungen von Entitäten verfolgen und Fragen beantworten, welche Entitäten in welchen Artikeln erscheinen – und das alles, während Transparenz und Erklärbarkeit erhalten bleiben.