Abfrage-Autofilterung IV: Ein neuartiger Ansatz für NLP
Dies ist mein vierter Blogbeitrag über eine Technik, die ich Query Autofiltering nenne. Die Grundidee ist, dass wir Metainformationen, die…
Dies ist mein vierter Blogbeitrag über eine Technik, die ich Query Autofiltering nenne. Die Grundidee ist, dass wir Metainformationen, die im Solr/Lucene-Index selbst gespeichert sind (in Form von String- oder nicht-tokenisierten Textfeldern), verwenden können, um eine Wissensbasis zu generieren, aus der wir Benutzerabfragen analysieren und Phrasen innerhalb der Abfrage Metadatenfeldern im Index zuordnen können. Auf diese Weise können wir die Abfrage des Benutzers umschreiben, um eine bessere Präzision der Antwort zu erreichen.
Neuere Versionen von Query Autofiltering, die den Lucene FieldCache als Wissensspeicher verwenden, können diese Aufgabe recht gut erledigen, lassen aber immer noch einige Mehrdeutigkeiten offen. Dies kann vorkommen, wenn ein bestimmter Metadatenwert in mehr als einem Feld vorkommt (einige Beispiele dafür finden Sie unten). Der Abfrage-Autofilter erstellt dann eine komplexe boolesche Abfrage, um alle möglichen Permutationen zu behandeln. Wenn mehrere Felder betroffen sind, existieren einige der feldübergreifenden Kombinationen nicht im Index (der Autofilter kann das nicht wissen) und ein zusätzlicher Filterungsschritt erfolgt zufällig, wenn die Abfrage ausgeführt wird. Dadurch erhalten wir oft genau das richtige Ergebnis, aber es gehört auch ein gewisses Maß an Glück dazu, was bedeutet, dass es zwangsläufig Situationen gibt, in denen uns das Glück verlässt.
Bei der Entwicklung von Demos für diesen Ansatz mit einer Musikontologie, an der ich arbeite, habe ich einige dieser Anwendungsfälle entdeckt. Wie immer, wenn Sie ein Problem sehen und die Ursache verstehen, können Sie auch andere Beispiele dafür finden. Im Folgenden werde ich einen Anwendungsfall aus dem Bereich Biomedizin / persönliche Gesundheit erörtern, von dem ich lange Zeit dachte, dass er mit herkömmlichen Suchmethoden nur schwer oder gar nicht zu lösen sei (nicht dass die automatische Filterung von Suchanfragen „herkömmlich“ wäre). Aber ich greife mir selbst vor. Das Problem tritt auf, wenn Benutzer Verben, Adjektive oder Präpositionen zu ihrer Abfrage hinzufügen, um die Ergebnisse einzuschränken, und diese Begriffe nicht als Feldwerte im Index vorkommen. Vielmehr werden sie auf Felder im Index. Der Benutzer teilt uns mit, dass er nach einer Schlüsselphrase in einem bestimmten Metadatenkontext suchen möchte, nicht in allen Kontexten, in denen die Phrase vorkommen kann. Das ist ein Problem aus dem Einmaleins der natürlichen Sprache! – Subjekt-Verb-Objekt-Zeug. Wir erhalten die Subjekt- und Objekt-Nomenphrasen aus der automatischen Filterung von Abfragen. Jetzt brauchen wir eine Möglichkeit, die anderen Schlüsselbegriffe (oft Verben) zu erfassen, um diese Abfragen besser analysieren zu können – damit der Benutzer die Genauigkeit erhält, die er wünscht.
Ich denke, wir brauchen hier ein Beispiel aus der realen Welt, um zu veranschaulichen, wovon ich spreche. In der Musik-Ontologie gibt es Entitäten wie Songs, die Komponisten/Songwriter/Texter, die sie geschrieben haben, und die Künstler, die sie aufgeführt oder aufgenommen haben. Es gibt auch das Konzept einer „Gruppe“ oder „Band“, die aus Gruppenmitgliedern besteht, die Songschreiber, Interpreten oder beides sein können.
Einer meiner Lieblingskünstler (und ich bin sicher, dass einige, aber vielleicht nicht alle meiner Leser dieser Meinung sind) ist Bob Dylan. Dylan hat viele Lieder geschrieben und aufgenommen und viele seiner Lieder wurden von anderen Künstlern gecovert. Eines der interessanten Verben in diesem Zusammenhang ist „gecovert“. Nach meiner Definition ist ein Cover eine Aufnahme durch einen Künstler, der nicht zu den Komponisten des Songs gehört. Die Verbform „to cover“ ist der Akt der Aufnahme oder Aufführung der Komposition eines anderen Künstlers. Dylan hat, wie andere Künstler auch, sowohl seine eigenen Songs als auch Songs anderer Musiker aufgenommen, aber ein Cover kann auch eine Signatur sein. So hat zum Beispiel Elvis Presley viel mehr Songs gecovert, als er geschrieben hat, aber wir halten „Jailhouse Rock“ immer noch für einen Elvis Presley-Song, obwohl er ihn nicht geschrieben hat (Jerry Leiber und Mike Stoller haben ihn geschrieben).
Wenn ich also nach „Bob Dylan Songs“ suche, meine ich Songs, die Dylan entweder geschrieben oder aufgenommen hat (d.h. beides). Wenn ich jedoch nach „Songs, die Bob Dylan gecovert hat“ suche, meine ich Songs, die Bob Dylan aufgenommen, aber nicht geschrieben hat, und „Covers von Bob Dylan-Songs“ würde Aufnahmen anderer Künstler von Songs bedeuten, die Dylan geschrieben hat – Jimi Hendrix‘ erstaunliche Coverversion von „All Along The Watchtower“ kommt mir hier sofort in den Sinn. (Neben den Verben gibt es noch ein weiteres sprachliches Phänomen, auf das ich gleich noch eingehen werde).
Wie lösen wir also diese Probleme? Nun, wir wissen, dass der Ausdruck „Bob Dylan“ an vielen Stellen in unserer Ontologie/unserem Datensatz vorkommen kann. Er ist ein Wert im Feld „Komponist“, im Feld „Interpret“ und im Titelfeld unseres Datensatzes für Bob Dylan selbst. Es ist auch der Wert einer Album-Entität, da sein erstes Album den Titel „Bob Dylan“ trug. Bei der Abfrage „Bob Dylan“ sollten wir also all diese Dinge erhalten – und das tun wir auch. Die Mehrdeutigkeit der Abfrage stimmt mit den vom Autofilter entdeckten Mehrdeutigkeiten überein, also ist alles in Ordnung. „Bob Dylan Songs“ liefert uns Lieder, die er geschrieben oder aufgenommen hat – jetzt ist die Abfrage spezifischer, aber immer noch mehrdeutig, aber immer noch gut, weil wir Wertübereinstimmungen für die gesamte Abfrage haben. Wenn wir jedoch „Songs, die Bob Dylan aufgenommen hat“ im Gegensatz zu „Songs, die Bob Dylan geschrieben hat“ sagen, fragen wir nach verschiedenen Untermengen von „Song“-Dingen. Ohne Hilfe übersieht der Autofilter diese Feinheiten, da es keine passenden Felder für die Begriffe „recorded“ oder „wrote“ gibt, so dass er sie als Füllwörter behandelt.
Um den Abfrage-Autofilter etwas „intelligenter“ zu machen, können wir ihm einige Regeln geben. Die Regel besagt, dass, wenn ein Begriff wie „recorded“ oder „performed“ in der Nähe einer Entität (die vom Standard-Parser des Abfrage-Autofilters erkannt wird) wie „Bob Dylan“ liegt, die dem Feld „performer_ss“ zugeordnet ist, nur dieses Feld selbst verwendet wird und nicht auf die anderen Felder aufgefächert wird, denen die Phrase ebenfalls zugeordnet ist. Wir konfigurieren dies folgendermaßen:
gespielt, aufgenommen, gesungen => performer_ss
und für komponierte oder geschriebene Lieder:
komponiert,geschrieben,geschrieben von => composer_ss
Die Liste der synonymen Verb- oder Adjektivausdrücke befindet sich auf der linken Seite und das Feld oder die Felder, denen diese zugeordnet werden sollen, auf der rechten Seite. Jetzt funktionieren diese Abfragen wie erwartet! Schön.
Ein anderes Beispiel ist, wenn wir in der Lage sein wollen, Fragen zu den Bands, in denen ein Künstler mitgewirkt hat, oder zu den Mitgliedern einer Gruppe zu beantworten. Bei Fragen wie „Wer ist in The Who?“ oder „Wer waren die Mitglieder von Procol Harum?“ würden wir die Verb- oder Präpositionalphrasen „who’s in“ und „members of“ den Feldern group_members_ss und member_of_group im Index zuordnen.
Wer ist dabei, war dabei,
Wenn man jetzt nach „Who’s in the Who“ sucht, findet man nur die Herren Daltrey, Entwistle, Moon und Towhshend – cool!!!
Tiefer gehen – Umgang mit Covers mit Substantiv-Nomen-Phrasen-Mehrdeutigkeiten
Das frühere Beispiel, das ich gegeben habe, „Songs, die Bob Dylan gecovert hat“ vs. „Covers von Bob Dylan-Songs“, enthält zusätzliche Komplexitäten, die die einfache Verb-zu-Feld-Zuordnung noch nicht löst. Wenn ich dieses Problem aus einer sprachlichen Perspektive betrachte (und nicht aus der Sicht eines Software-Hackers), konnte ich eine Erklärung und daraus eine Lösung finden. Eine Randbemerkung dazu ist, dass das Ergebnis meiner Vorverarbeitung der Ontologie zur Erkennung, ob eine Aufnahme ein Cover ist, die umgekehrte Beziehung war, wenn der Interpret eines Songs auch einer der Komponisten ist. Indexeinträge dieser Art werden mit einem Feld „original_performer_s“ und einem „version_s:Original“ versehen, um sie bei der Abfrage von Covers zu unterscheiden (die mit „version_s:Cover“ gekennzeichnet sind).
Um auf die Sprache zurückzukommen: Es stellt sich heraus, dass in dem Satz „Bob Dylan songs covered“ das Subjekt „Bob Dylan songs“ ist! Das bedeutet, dass das Substantiv „Bob Dylan“ die Pluralform von „song“ ist und die Substantivphrase „Bob Dylan“ dieses Substantiv qualifiziert, um Lieder von ihm zu spezifizieren. In der Linguistik wird dies als „Substantiv-Nomen-Phrase“ bezeichnet, was bedeutet, dass ein Substantiv „Bob Dylan“ als Adjektiv zu einem anderen Substantiv dient, in diesem Fall „song“. Denken Sie daran – Sprache ist kompliziert! In dem Satz „Songs, die Bob Dylan gecovert hat“ ist jedoch „Songs“ das Objektnomen, „Bob Dylan“ das Subjektnomen und „covered“ das Verb. Um diese Frage zu klären, habe ich mir eine zusätzliche Regel ausgedacht, die ich als Musterregel bezeichne: Wenn eine Entität „original_performer“ einer Entität „composition_type song“ vorausgeht, verwenden Sie dieses Muster für die automatische Filterung der Abfrage. Dies wird in der Konfiguration folgendermaßen ausgedrückt:
covered,covers:performer_ss => version_s:Cover | original_performer_s:_ENTITY_,recording_type_ss:Song=>original_performer_s:_ENTITY_
Um dies aufzuschlüsseln, führt der erste Teil das Mapping von ‚covered‘ und ‚covers‘ auf das Feld performer_ss durch. Der zweite Teil setzt einen statischen Abfrageparameter version_s:Cover und der dritte Teil:
original_performer_s:
Bedeutet: Wenn auf einen Originalinterpreten ein Aufnahmetyp „Song“ folgt, verwenden Sie original_performer_s als Feldname.
Wir möchten auch, dass dieses Muster kontextsensitiv angewendet wird – es wird benötigt, um das bidirektionale Verb „cover“ zu disambiguieren, also verwenden wir es nur in dieser Situation. Das heißt, diese Musterregel wird nur ausgelöst, wenn das Verb „cover“ in der Abfrage vorkommt. Auch diese Regeln sind vom jeweiligen Anwendungsfall abhängig und können nach Bedarf erweitert oder verfeinert werden. Regelbasierte Ansätze wie dieser erfordern eine Kuratierung und Analyse von Abfrageprotokollen, können aber eine sehr effektive Methode sein, um Randfälle wie diesen zu behandeln. Glücklicherweise kann der Teil der automatischen Abfragefilterung, der „einfach einstecken und vergessen“ lautet, eine große Anzahl von Anwendungsfällen ohne Hilfe bewältigen. Das ist ein gutes Gleichgewicht.
Mit dieser Regel konnte ich erreichen, dass Suchanfragen wie „Beatles Songs gecovert von Joe Cocker“ und „Smokey Robinson Songs gecovert von den Beatles“ wie erwartet funktionieren. (Die Antwort auf die zweite Frage ist der großartige R&B-Klassiker „You’ve Really Got A Hold On Me“).
Sorgen um das Gesundheitswesen
Lassen Sie uns einen anderen Bereich untersuchen, um die Allgemeinheit dieser Techniken zu sehen. Im Gesundheitswesen gibt es eine umfangreiche Ontologie, die Krankheiten, Symptome, Behandlungen und biomedizinische Ursachen miteinander verbindet. Es gibt auch Gesundheitsdienstleister verschiedener Fachrichtungen und Pharmahersteller, um nur einige zu nennen. In diesem Fall werden die Ontologien (wie MeSH) von den National Institutes of Medicine und anderen angeschlossenen Behörden zur Verfügung gestellt. Stellen Sie sich also vor, wir hätten eine Website zum Thema Gesundheit für Verbraucher mit Seiten, auf denen diese Entitäten behandelt werden und auf denen man zwischen ihnen navigieren kann. Die Seiten würden auch Metadaten enthalten, die wir sowohl facettieren als auch eine automatische Filterung von Abfragen durchführen können.
Lassen Sie uns ein konkretes Beispiel nehmen. Nehmen wir an, dass Sie unter Bauchschmerzen leiden (das tut mir leid). Dies ist ein Beispiel für einen Zustand oder ein Symptom, das gutartig sein kann (Sie haben gestern Abend zu viel gegessen oder getrunken) oder ein Anzeichen für etwas Ernsteres ist. Die Symptome können durch Krankheiten wie Blinddarmentzündung oder Gastroenteritis verursacht werden, sie können mit Medikamenten behandelt werden oder sie können sogar durch eine Nebenwirkung oder unerwünschte Reaktion eines Medikaments verursacht werden. Wenn Sie also auf dieser Website sind, stellen Sie sich vielleicht Fragen wie „Welche Medikamente können Bauchschmerzen behandeln?“ und vielleicht auch „Welche Medikamente können Bauchschmerzen verursachen?“. Dies ist ein schwieriges Problem für herkömmliche Suchmethoden, und auch der Autofilter für Suchanfragen würde ohne die Art von Unterstützung, die ich hier bespreche, nicht richtig funktionieren. Bei Medikamenten wären die Metadatenfelder für die Seite „Indikation“ für positive Zusammenhänge (eine Indikation ist das, wofür das Medikament von der FDA zugelassen wurde) und „side_effect“ oder „adverse_reaction“ für die Schattenseiten von Arzneimitteln (scheinen diese Disclaimer in der Fernsehwerbung nicht immer weiter zu gehen?).
Mit unserem neuen Abfrage-Autofilter-Trick können wir diese Verb-Präpositions-Phrasen jetzt so konfigurieren, dass sie den richtigen Feldern zugeordnet werden:
behandeln,für,indiziert => indikation_ss
verursachen,produzieren => neben_Wirkung_ss,unerwünschte_Reaktion_ss
Jetzt sollten diese Abfragen korrekt funktionieren: Unsere Suchanwendung ist jetzt viel intelligenter – und unsere Benutzer werden viel zufriedener mit uns sein. Denn wie wir wissen, sind Benutzer, die solche Fragen stellen, hoch motiviert, gute, brauchbare Antworten zu erhalten, und haben nicht die Zeit/Geduld, sich durch die Rauschtreffer zu wühlen (d.h. sie haben vielleicht schon Schmerzen).
Sie werden sich jetzt vielleicht fragen, wie viele dieser Regeln wir brauchen? Eine Sache, die Sie beachten sollten, und der Grund dafür, dass ich Beispiele aus zwei verschiedenen Bereichen verwende, ist die Veranschaulichung der domänenspezifischen Natur dieser Probleme. Für allgemeine Websuchanwendungen wie Google könnte diese Liste von Regeln sehr umfangreich sein (aber das ist Google ja auch). Für domänenspezifische Anwendungen, wie sie in der Unternehmenssuche oder im eCommerce vorkommen, kann die Liste viel überschaubarer und anwendungsbezogener sein. Das heißt, wir werden diese Korrekturen wahrscheinlich entdecken, wenn wir unsere Abfrageprotokolle untersuchen, aber jetzt haben wir ein weiteres Werkzeug in unserem Arsenal, um Sprachprobleme wie dieses anzugehen.
Verwendung von Techniken zur Verarbeitung natürlicher Sprache zur Erkennung von und Reaktion auf Benutzerabsichten
Die allgemeine Technik, die ich hier vorstelle, nenne ich „Query Introspection“. Im Klartext bedeutet dies, dass wir die Absicht des Benutzers ableiten. Das heißt, dass wir mit Hilfe dieser Technik besser herausfinden können, wonach der Benutzer sucht, und dann die Abfrage so ändern können, dass wir es bekommen, wenn wir können. Das ist ein Problem der natürlichen Sprachverarbeitung oder NLP. Es gibt noch andere Ansätze, die hier erfolgreich waren, insbesondere die Analyse von Wortbestandteilen der Abfrage (POS), um die Substantive, Verben und Präpositionen zu ermitteln, über die ich gesprochen habe. Dies kann auf maschinellem Lernen oder algorithmischen Ansätzen (regelbasiert) beruhen und ist eine gute Möglichkeit, die Anfrage in ihre sprachlichen Bestandteile zu zerlegen. Das berühmte Watson-Programm von IBM brauchte einen ziemlich guten Ansatz, um die Jeopardy-Fragen zu analysieren. Ansätze des maschinellen Lernens können auch direkt auf Q&A-Probleme angewendet werden. Eine gute Diskussion darüber finden Sie in Ingersoll et.al.’s großartigem Buch Taming Text.
Der Schritt der Erkennung der Benutzerabsicht, den die oben beschriebenen klassischen NLP-Techniken und nun auch der Abfrage-Autofilter durchführen können, stellt die erste Phase des Prozesses dar. Die zweite Phase besteht darin, dies in eine entsprechend genaue Abfrage zu übersetzen. Bei Ansätzen, die mit POS-Tags arbeiten, beinhaltet dies in der Regel eine Wissensdatenbank, die es ermöglicht, Teile von Sprachphrasen auf Abfragefelder abzubilden. Der Abfrage-Autofilter erledigt dies natürlich von Haus aus, da er die Informationen sozusagen „aus erster Hand“ erhalten kann. Der POS/Wissensbasis-Ansatz ist möglicherweise besser geeignet, wenn der Index selbst weniger Metadatenstruktur aufweist, da die KB das Ergebnis von Data-Mining-Operationen sein kann. Auf der jüngsten Lucene/Solr Revolution in Austin gab es einige hervorragende Vorträge zu diesem Thema (siehe meinen Blogbeitrag dazu). Wenn Sie Ihre Daten jedoch bereits manuell oder automatisch mit Tags versehen haben, sollten Sie die automatische Filterung von Abfragen ausprobieren.
Der Quellcode ist verfügbar
Der Java-Quellcode dafür ist auf github sowohl für die Solr4.x- als auch für die Solr 5-Version verfügbar. Dort finden Sie auch technische Details über den Code und seine Funktionsweise. Laden Sie diesen Code herunter und verwenden Sie ihn, wenn Sie diese Funktion jetzt in Ihre Suchanwendungen einbauen möchten. Es gibt auch einen Solr JIRA-Eintrag(SOLR-7539).