Die Duplikaterkennung ist der Vorgang der eindeutigen Zuordnung eines Objekts. Dabei wird eine textbasierte Nennung dem geeignetsten realen Namen in einer durchsuchbaren Knowledge Base (KB) zugeordnet. Beispielsweise wird „madrid fc“ mit „Real Madrid Club de Fútbol“ verknüpft, wobei Ersteres eine der alternativen Kurzbezeichnungen für Letzteres ist. Duplikaterkennung wird alternativ auch als Objektidentifizierung, Record Linkage oder Datendeduplikation bezeichnet.
Die Duplikaterkennung ist als Teil von MindMelds NLP-Pipeline verfügbar und wird für die eindeutige Zuordnung aller Objekte in der Benutzereingabe durch Abgleich mit einer vorbefüllten KB verwendet. In der offiziellen Dokumentation erfahren Sie, wie Sie eine KB für die Duplikaterkennung erstellen und bei der Erstellung einer MindMeld-Anwendung damit arbeiten.
Bislang bot MindMeld zwei Optionen für die Duplikaterkennung: eine auf Basis der Elasticsearch Volltextsuche- und Analyse-Engine sowie eine Ersatzfunktion basierend auf einem einfachen Exact-Matching-Algorithmus. Mit zunehmend vielfältigen Anwendungen von MindMeld sind diese Optionen möglicherweise nicht immer geeignet. Für die erweiterte Unterstützung bietet MindMeld nun zwei weitere Optionen für die Duplikaterkennung: eine auf Basis von TF-IDF und eine weitere auf Basis von Repräsentationen von vorab trainierten neuronalen Modellen (BERT, GloVe,fastText usw.). Diese neuen Optionen haben keine Abhängigkeiten von Elasticsearch (und seinen Diensten).
Bevor wir uns diesen neuen Optionen im Detail zuwenden, fassen wir nochmals kurz zusammen, wie eine Objekt-Knowledge-Base in MindMeld strukturiert ist. Folgendes Beispiel stammt aus der Vorlage Essensbestellung und der für die eindeutige Erkennung der Bezeichnungen von Speisen erstellten Knowledge Base:
Schnappschuss einer Knowledge Base für die Duplikaterkennung
Wie zu sehen ist, finden sich im Feld „whitelist“ einige häufige Bezeichnungen der jeweiligen Speisen unter „cname“ (canonical name, Standardbezeichnung), und das Feld „id“ verweist auf einen eindeutigen, offiziell erkannten Eintrag in der Knowledge Base. Diese drei Felder sind die Hauptbestandteile eines Objekts in der KB. Der Text im Feld „cname“ wird im Allgemeinen für Antworten in Gesprächen verwendet, und die Bezeichnungen im Feld „whitelist“ werden gemeinsam mit der Standardbezeichnung als Aliase für die Duplikaterkennung verwendet. Die Duplikaterkennung liefert häufig die besten Ergebnisse, wenn das Feld „whitelist“ umfassende Einträge enthält (z. B. alternative Verwendungen, Tippfehler, Kurzformen usw.). Diese Art von Kuratierung kann bei manchen Anwendungen mühselig sein, ist aber für Objekte in hochspezialisierten Domänen unvermeidbar.
Erfahren Sie mehr über die neuen Optionen
Mit Ausnahme von Exact Match besteht der erste Schritt in der Erstellung einer Vektorrepräsentation des Eingabetextes sowie für alle Einträge in der KB (cname und whitelist), die als Aliase für die Duplikaterkennung dienen. Anhand eines Ähnlichkeitsmaßes (z. B. Kosinus-Ähnlichkeit) werden die Aliase daraufhin bewertet und nach Rang geordnet.
Bei den neu hinzugefügten Optionen für die Duplikaterkennung kuratiert der TF-IDF-basierte Resolver verschiedene N-Gramm-Eigenschaften (d. h. oberflächliche Texteigenschaften), bevor er die Kosinus-Ähnlichkeiten anhand der dünnbesetzten Vektoren berechnet. Ein Resolver auf Basis vorab trainierter Worteinbettung hingegen gleicht unter Verwendung der Kosinus-Ähnlichkeit von vollbesetzten Vektorrepräsentationen des Textes ab.
Die Nutzung vorab trainierter Worteinbettung für die Duplikaterkennung hat gegenüber anderen Ansätzen einige Vorteile. Sie ermöglicht beispielsweise semantisches Verständnis von Text ohne die Notwendigkeit umfassend befüllter Whitelists (z. B. ist „hinter den Erwartungen zurückgeblieben“ gleichwertig mit „schlechte Leistung“) und bietet einen einfachen Übergang zur mehrsprachigen Duplikaterkennung (z. B. die Inferenz, dass „Dritte“ auf Deutsch dasselbe ist, wie „third“ auf Englisch“). Jedoch ist die vorab trainierte Worteinbettung bei Diskrepanzen zwischen Vorabtraining und Inferenz, wie beispielsweise unterschiedlich langen Texteingaben, im Nachteil. Zudem kann die Inferenz bei Worteinbettungs-Modellen wegen den zugrundeliegenden Berechnungen mit vollbesetzten Vektoren länger dauern als bei anderen Optionen. Dennoch können bei entsprechender Feineinstellung Worteinbettungs-Modelle anderen hauptsächlich auf oberflächlichen Texteigenschaften basierenden Resolver-Optionen überlegen sein.
Nachstehende Analyse vergleicht Resolver auf Basis vorab trainierter Worteinbettung mit Elasticsearch und TF-IDF-Resolvern. Die für diesen Vergleich kuratierten Datensätze umfassen sowohl oberflächlichen Textabgleich als auch semantischen Abgleich.
Leistung unterschiedlicher Resolver
Versuche mit unterschiedlichen intern kuratierten Datensätzen ergaben für die verschiedenen Resolver folgende durchschnittliche Leistungen bei der Duplikaterkennung kurzer Texte. Die beste Retrieval-Bewertung ist hier als Genauigkeitswert angegeben:
Leistungen unterschiedlicher Resolver
Die vorab trainierten BERT-Varianten sind als Teil von Huggingface sentence-transformers verfügbar; die Grafik bildet nur die Bewertungen der fünf leistungsstärksten Varianten ab. Vorab trainierte Worteinbettungs-Modelle wie fastText weisen im Allgemeinen eine schlechtere Leistung auf als BERT-Einbettungsmodelle oder TF-IDF-basierte Resolver. Diese schlechten Leistungen können auf die Domänenverlagerung und mangelnde Feineinstellung zurückzuführen sein.
Eine weiterführende Analyse mit verschiedenen Konfigurationen der leistungsstärksten BERT-Variante („distilbert-base-nli-stsb-mean-tokens“) liefert folgende Ergebnisse:
Leistungen verschiedener Konfigurationen der leistungsstärksten BERT-Variante
Die Ergebnisse zeigen, dass alternative Ähnlichkeitsbewertungen wie BERTScore nicht wettbewerbsfähig sind. Zudem führt die Verwendung der Kosinus-Ähnlichkeit bei Verknüpfung unterschiedlicher Ebenen des BERT-Modells zu einem Leistungszuwachs, der der Leistung von Elasticsearch entspricht. Das ist naheliegend, da unterschiedliche Ebenen von BERT ergänzende Informationen erfassen können. Selbst nach Quantisierung der BERT-Variante auf geringere Speicherauslastung und geringere Zeitkomplexität verringert sich die Leistung nur um 2–3 %.
Zudem liegt die Leistung des TF-IDF-basierten Resolvers bei Beurteilung anhand von zufallsverrauschten Daten mit Tippfehlern in der Eingabe über der der anderen Optionen. Dies kann durch die vielfältigen N-Gramme begründet sein, die von diesem Resolver erfasst werden. (Für diesen Versuch wurden Whitelist-Texte als Testinstanzen wiederverwendet und Tippfehler eingeführt. Daher ist bei 0 % Rauschen eine Genauigkeit von 100 % zu sehen, da alle Testobjekte auch in den Whitelists vorliegen!)
Leistung bei Abgleich von Text mit eingeführten Tippfehlern
Abschließend zeigt folgende Grafik die unterschiedlichen Zeitkomplexitäten für die Inferenz bei den verschiedenen Resolver-Optionen:
(Von links nach rechts: genaueste BERT, TF-IDF, Elasticsearch) Inferenzzeit pro Objekt bei Messung in unterschiedlich großen Knowledge Bases. Die X-Achse gibt die Größe der Knowledge Base an, die Y-Achse die Zeit pro Objekt in Millisekunden. Gelb dargestellt ist die Inferenzzeit für die Kodierung des Eingabetexts und grün die Inferenzzeit für die Ähnlichkeitsberechnung.
Die Zeitkomplexitäten von TF-IDF und Elasticsearch sind durchaus vergleichbar, wohingegen die beste BERT-Variante trotz Quantisierung 20 Mal langsamer ist. Dieser Wert verbessert sich zu einer 10-fachen Verlangsamung, wenn die oberen 4 Ebenen nicht verknüpft werden, führt jedoch auch zu einer geringeren Genauigkeit.
Auswahl und Konfiguration eines Resolvers
Die Resolver-Konfigurationen von MindMeld bieten verschiedene konfigurierbare Parameter, je nach verwendetem Resolver. Folgender Ausschnitt führt bei Eingabe in die „config.py“-Datei einer Anwendung zur Verwendung eines vorab trainierten BERT-Modells Ihrer Wahl von Huggingface:
Durch Modifikation des Parameters „embedder_type“ können Sie andere Worteinbettungs-Modelle verwenden:
ENTITY_RESOLVER_CONFIG = {
‘model_type’: ‘resolver’,
‘model_settings’: {
‘resolver_type’: ’embedder_cosine_similarity’,
’embedder_type’: ‘glove’,
…
}
}
Sie können bei Verwendung eines Worteinbettungs-Modells auch Laufzeitkonfigurationen wie „batch_size“ und modellspezifische Konfigurationen angeben. Um einen TF-IDF-basierten Resolver zu laden, gehen Sie wie folgt vor:
ENTITY_RESOLVER_CONFIG = {
‘model_type’: ‘resolver’,
‘model_settings’: {
‘resolver_type’: ‘tfidf_cosine_similarity’,
…
}
}
Für jedes Objekt in der KB werden spezielle Worteinbettungen, die die mittlere/maximale Menge der Worteinbettungen aller Aliase darstellen, ebenfalls berechnet und bei entsprechender Konfiguration für die Duplikaterkennung verwendet. Solche speziellen Worteinbettungen verbessern häufig die Genauigkeit von Resolvern bei nur marginalen Auswirkungen auf die Rechnerauslastung. Vollständige Details und alle konfigurierbaren Optionen finden Sie im Abschnitt „Configurations“ (Konfigurationen) in der offiziellen Dokumentation.
Abschließende Gedanken und Ausblick
Insgesamt wird der Elasticsearch-basierte Resolver empfohlen, falls kein spezielles Szenario seiner Anwendung entgegensteht. Verwenden Sie als Ersatzlösung Resolver auf Basis von Worteinbettungs-Modellen, wenn ein eher semantischer Abgleich nötig ist, oder einen TF-IDF-basierten Resolver, wenn das nicht der Fall ist. Das Duplikaterkennungsmodul in MindMeld bietet bislang keine APIs für das Benchmarking des optimalen Resolvers für Ihre Anwendung. Die Unterstützung dafür ist aber bereits geplant, ebenso wie Möglichkeiten zur Feineinstellung von auf Worteinbettungs-Modellen basierenden Resolvern. Bleiben Sie auf dem Laufenden.
