Maschinelles Lernen in Lucidworks Fusion

Klassifizierung, Clustering und kollaboratives Filtern sind jetzt in der Lucidworks Fusion Anwendungssuite verfügbar.

Zusammenfassung

Klassifizierung, Clustering und kollaboratives Filtern („die 3 K’s des maschinellen Lernens“) sind jetzt in der Lucidworks Fusion-Anwendungssuite verfügbar – vom Offline-Training Ihrer Modelle im horizontal skalierbaren Apache Spark-Cluster von Fusion bis hin zur Bereitstellung dieser Modelle als Teil von Abfrage- und Indizierungspipelines zur Laufzeit.

Überwachtes maschinelles Lernen: Klassifizierung

Motivation

Stellen Sie sich vor, Sie haben eine große E-Commerce-Website mit einem breit gefächerten Produktkatalog, der gut in eine Hierarchie von Produktkategorien unterteilt ist (Kategorien wie Elektronik > Computer & Tablets > Zubehör, Haushaltsgeräte > Herde & Backöfen > Reichweiten > Elektroherde, und so weiter). Ihr Produktkatalog wird in einem Solr-Index gespeichert, um Ihren Kunden eine hochrelevante Volltextsuche zu ermöglichen. Wenn Suchanfragen eingehen, können Ergebnisse aus verschiedenen Produktkategorien übereinstimmen, und die besten werden oben auf der Seite mit den Suchergebnissen angezeigt. Eine Suchanfrage nach „iPad“ könnte ein weißes 32-GB-iPad ganz oben ergeben, ein 16-GB-iPad darunter und ein schwarzes 32-GB-iPad darunter. Das ist normalerweise genau das, was Sie wollen.

Aber was passiert, wenn die Abfrage „Tablet-Hülle“ lautet? Sie würde am ehesten mit iPad-Hüllen und anderen Tablet-Hüllen im Produktkatalog übereinstimmen, aber je nach den Ranking-Faktoren, die Sie verwenden, tauchen vielleicht auch die Tablets selbst (nicht die Hüllen) auf (weil in ihren Beschreibungen vielleicht erwähnt wird, dass sie mit schönen Hüllen geliefert werden), ebenso wie Hüllen für Smartphones. Das ist nicht schlecht, und mit einer geeigneten Facettierungsoberfläche kann der Benutzer Elektronik > Computer & Tablets > Tablets > Zubehör (eine Kategorie, die sehr wahrscheinlich eine große Anzahl von Treffern für diese Abfrage hat) aus den Kategoriefacetten auswählen und die Ergebnisse eingrenzen, um Tablets und Smartphone-Hüllen aus der Ansicht zu entfernen.

Eine gute Regel des UX-Designs besagt jedoch, dass jede Aktion, zu der Sie den Benutzer zwingen, die Wahrscheinlichkeit erhöht, dass er Ihren Trichter verlässt, weil er mit etwas anderem abgelenkt wird, mit dem, was er bisher gesehen hat, unzufrieden ist oder frustriert ist, weil er nicht weiß, was er als nächstes tun soll.

Was wäre, wenn wir die Abfrage „tablet case“ analysieren könnten, sobald sie eingeht, und mit hoher Sicherheit wüssten, dass der Nutzer Ergebnisse aus der Kategorie Elektronik > Computer & Tablets > Tablets > Zubehör wünscht, und diesen Facettenfilter präventiv anwenden könnten? Wenn die meisten Benutzer diese Abfrage eingeben, ist es das, was sie tun möchten, und nur eine Minderheit der Benutzer möchte etwas anderes tun, dann haben wir die Benutzer, die eine zusätzliche Aktion durchführen müssen, von der Mehrheit auf eine viel kleinere Minderheit von Benutzern verschoben. Diejenigen, die nicht zu dieser Kategorie gehören möchten, müssten dann diesen Facettenfilter deaktivieren – eine Aktion, die wir nachverfolgen möchten, um Rückmeldungen darüber zu erhalten, wie oft die Benutzer unsere Vermutungen darüber, was sie tun möchten, gut finden und/oder damit einverstanden sind.

Oder vielleicht ist eine Abfrage wie „Tablet-Hülle“ eine sehr weit gefasste Abfrage nach allem, was in einer ganzen Kategorie vorkommt (sie spezifiziert weder Marke, Größe, Farbe noch irgendetwas anderes, außer dass sie in diesem tief verschachtelten Teil der Kategorienhierarchie sein möchte). Anstatt also nur einen Facettenfilter für diese Kategorie anzuwenden, wäre das Benutzererlebnis noch besser, wenn wir den Facettenfilter anwenden und eine Abfrage formulieren würden, die sicherstellt, dass wir von den Top-Ergebnissen in dieser Kategorie mindestens eines von jeder der drei Top-Marken und mindestens zwei verschiedene Farben anzeigen? Oder noch einfacher, wir könnten die Ergebnisse in dieser Kategorie nach Beliebtheit (oder erwartetem Umsatz/Gewinn) sortiert anzeigen.

Wenn wir nur wüssten, wann sich eine Abfrage (a) eindeutig auf nur eine Kategorie im Produktkatalog bezieht und/oder (b) wann die Abfrage sehr breit gefächert ist (aber wahrscheinlich trotzdem auf einen Kategorieknoten beschränkt ist).

Das müssen Sie sich nicht mehr vorstellen! Mit Fusion 3.1 können Sie Ihren eigenen Klassifikator für Suchanfragen trainieren, der es Ihnen ermöglicht, je nach Art der Trainingsdaten, die Sie ihm zur Verfügung stellen, die in Fusion eingehenden Suchanfragen zu kategorisieren. Sie können bestimmen, zu welcher Produktkategorie die Abfrage am besten passt oder ob die Absicht der Abfrage in eine von mehreren gängigen Abfrageklassen fällt, wie z.B. die Suche nach bekannten Artikeln (z.B. „32GB schwarzes iPad 3“ oder „Black & Decker Akku-Bohrmaschine 150W“), breit angelegte Themenabfragen (z.B. „Tablet-Hüllen“ oder „klassische Musik-CDs“) oder Hilfeabfragen (z.B. „wie tausche ich Batterien aus“ oder „wie lauten die Rückgabebedingungen für Videospiele“).

In jedem Fall ist der Abfrageklassifikator eine Stufe der Fusion-Abfrage-Pipeline. Was Sie mit den Ergebnissen eines Klassifizierers machen, bleibt Ihnen überlassen. Die obigen Szenarien sollen Ihnen nur einen Eindruck davon vermitteln, was problemlos möglich ist.

Natürlich muss ein Textklassifikator nicht auf Abfragen beschränkt sein. Die Kennzeichnung von Dokumenten, die eine Indexpipeline durchlaufen, ist ein weiterer häufiger Anwendungsfall. Es gibt viele Gründe, warum Sie dies tun möchten. Stellen Sie sich vor, Sie haben das oben erwähnte E-Commerce-Geschäft mit einem gut beschrifteten Produktkatalog. Sie beschließen, einen Marktplatz einzurichten, der Inventar von Drittanbietern aufnimmt. Wenn diese neuen Produkte nicht so gut kategorisiert sind (oder vielleicht haben die neuen Produkte einfach eine andere Kategorisierung als Ihre interne Kategorienhierarchie), dann könnten Sie einen Textklassifikator, der auf Ihrem primären Katalog trainiert wurde, auch auf diese neuen Produkte anwenden, um diese Bezeichnungen auf die zuvor nicht beschrifteten Artikel auszuweiten. Ähnlich wie eine Abfrageklassifizierungsstufe als Teil einer vollständigen Abfrage-Pipeline mit einer von Ihnen kontrollierbaren Logik existiert, können Sie eine Indizierungsstufe mit einem Textklassifizierer mit zusätzlicher Logik folgen lassen, oder Sie können einfach die Ausgabe der Indizierungsstufe nehmen und sie in einem Dokumentenfeld zur Aufnahme in den Index speichern.

In Fusion 3.1 ist der Prozess zum Trainieren eines Klassifizierers derselbe, unabhängig davon, wo Sie ihn anwenden möchten – zur Abfragezeit oder zur Indexzeit. Sie können sogar dasselbe individuelle Klassifizierungsmodell in beiden Arten von Pipelines verwenden, wenn die Daten, auf die es angewendet wird, dies sinnvoll machen.

Nachdem wir nun die Motivation und die Anwendungsfälle geklärt haben, stellt sich die Frage, wie Sie diese Modelle tatsächlich trainieren und dann in Fusion verwenden können. Schauen wir uns das mal an.

Schritt für Schritt einen Dokumentenklassifikator erstellen

Kehren wir zu unserem E-Commerce-Beispiel zurück und betrachten wir das etwas einfachere Problem der Erweiterung eines Klassifizierungssystems auf mehr Dokumente: den Fall des Index-Pipeline-Klassifizierers. In diesem Fall haben wir Dokumente in unserem Solr-Index, die Kategoriebezeichnungen in einem gespeicherten Feld haben, und wir möchten einen Klassifikator auf diesen Bezeichnungssatz trainieren. Im Großen und Ganzen läuft der Prozess ungefähr so ab:

1. Identifizieren Sie Ihr Trainingsset – eine Solr-Sammlung, die wir als training_collection bezeichnen, mit einem gespeicherten Feld category_s, das die Kategoriebezeichnungen enthält, und einem Textfeld content_txt, das die Daten enthält, aus denen das System Merkmale extrahiert, um die Vorhersagen durchzuführen.
2. Führen Sie eine Datenbereinigung an diesem Trainingssatz durch – Facette auf das Feld category_s. Sind alle Kategorien, die Sie erwarten, vorhanden, und zwar mit den richtigen Kardinalitäten? Wenn Sie eine hierarchische Kategorisierung haben, haben Sie dann ein Feld, das nur die Blattknoten enthält oder die Ebene, auf die Sie klassifizieren möchten? Sind die Kategorien relativ ausgewogen? Wenn eine Kategorie 90% Ihres Inhalts ausmacht, wird es schwierig sein, eine hohe Genauigkeit bei den kleineren Kategorien zu erzielen. Was Sie in diesem Schritt tun, hängt von Ihren Daten ab, und es ist schwer, feste Regeln aufzustellen. Dies ist die „Kunst“ der Datenwissenschaft.
3. Entscheiden Sie, welches Klassifizierungsmodell Sie trainieren möchten – Fusion 3.1 bietet Ihnen zwei Möglichkeiten: Logistische Regression und Random Forests. Im Folgenden gehen wir auf die Vor- und Nachteile der beiden Modelle ein. Zusammenfassend lässt sich jedoch sagen, dass Sie mit Random Forests beginnen sollten, wenn Sie sich nicht sicher sind.

1. Legen Sie fest, welche Art von Merkmalsextraktion/Engineering Sie durchführen möchten – Ihre Daten bestehen zunächst aus Rohtext, aber sowohl die logistische Regression als auch die Random Forests benötigen numerische Vektoren als Eingabe, also müssen Sie Ihre Dokumente „vektorisieren“. Die Vektorisierung in Fusion besteht aus einer Reihe der folgenden Schritte:
   1. Tokenisierung: Jeder Lucene/Solr Tokenizer funktioniert hier; lesen Sie den Blogbeitrag von Steve Rowe, um mehr darüber zu erfahren, wie Sie einen Tokenizer auswählen.
   2. Zuordnen von Token zu Vektoren durch:

• • • Vektorisierung der Anzahl: Jedes Token erhält einen eindeutigen Vektorindex, und der Bag-of-Words für das Dokument wird in eine Reihe von Zählungen der Häufigkeit des Vorkommens jedes Tokens in jedem Dokument übersetzt. Da die Häufigkeit des Vorkommens eines Begriffs in einem Dokument in eine Zahl umgewandelt wird, nennt man dies Term-Frequency (TF) Vektorisierung. Einige der Faktoren, die bei dieser häufig verwendeten Form der Vektorisierung zu berücksichtigen sind, sind die Frage, ob Sie das Vokabular „kopf- oder schwanzlastig“ machen wollen: Entfernen Sie die viel zu häufigen Wörter (den Kopf der Begriffshäufigkeitsverteilung), weil sie nicht viel Signal liefern, und entfernen Sie in ähnlicher Weise die sehr seltenen Wörter (den „langen Schwanz“), die den größten Teil des Vokabulars ausmachen, aber jedes Wort kommt nur in sehr wenigen Dokumenten vor. In Fusion wird dies durch die Einstellung der erweiterten Parameter maxDF und minDF in einer Klassifikator-Trainingskonfiguration erreicht. Werte zwischen 0 und 1 (einschließlich) werden als Brüche interpretiert, Werte über 1 als absolute Anzahl: maxDF = 0.9 bedeutet „alle Token behalten, die in weniger als 90% der Dokumente im Trainingssatz vorkommen, während minDF = 10 bedeutet „alle Token behalten, die in mindestens 10 Dokumenten vorkommen“. In der Praxis funktioniert die Wahl eines großen Bruchteils für maxDF und einer kleinen Anzahl für minDF bei vielen Problemen. Standardmäßig sind sie jedoch auf 1,0 bzw. 0 gesetzt, da die Werte von Ihrem Vokabular und der Größe des Trainingskorpus abhängen.

1. Word2vec-Vektorisierung: Während bei der Zählvektorisierung jedes eindeutige Token mit einem anderen ganzzahligen Index assoziiert wird (so dass jedes Token völlig orthogonal zu den anderen ist, unabhängig davon, ob sie semantisch unabhängig sind oder nicht), kann der beliebte word2vec-Algorithmus eine dichte vektorielle Darstellung des Vokabulars eines Korpus erlernen, die einen Teil der Semantik der Sprache Ihres Trainingssatzes kodiert. Ähnliche Wörter weisen in diesem Raum in ähnliche Richtungen, und nur relativ unverbundene Begriffe sind wirklich (fast) orthogonal.

Wenn Sie in den erweiterten Einstellungen für beide ML-Trainingsaufträge (sichtbar durch Umschalten des grünen Schiebereglers Erweitert oben im Dialogfeld für die Auftragskonfiguration) den Parameter word2vec Dimension auf eine Zahl größer als Null setzen (word2vec verfügt über eine eigene Reihe von Konfigurationsparametern, die weiter unten kurz erläutert werden), geben Sie damit an, dass Sie Ihre Dokumente auf folgende Weise vektorisieren möchten:

• • • Zunächst trainiert Fusion ein word2vec-Modell auf der Grundlage der tokenisierten Form Ihres gesamten Korpus.
    • Zweitens wendet Fusion die Token-zu-Dense-Embedding-Space-Vektor-Zuordnung aus diesem Modell auf die Token des Dokuments an und erstellt einen dichten Vektor pro Token.
    • Drittens weist Fusion dem Dokument die Vektorsumme all dieser Vektoren zu.

1. Gewichtung: Bei der TF-Vektorisierung wandelt Fusion die Token in Vektoren um und addiert diese Vektoren auf. Da relativ seltene Wörter oft informativer sind als sehr häufige, ist es für die Relevanz oft hilfreich, den seltenen Wörtern mehr Bedeutung zuzuweisen. Daher haben Sie die Möglichkeit, Begriffe nach ihrer inversen Dokumenthäufigkeit (IDF) zu gewichten, bevor Sie die Vektorsumme bilden (bei der word2vec-Featurierung kodieren die Wortvektoren bereits eine Vorstellung von ihrer Popularität.
2. Normalisierung: Ein Dokument, das den Text „Black 16GB iPad“ enthält, und das Dokument, das „Black 16GB iPad“ enthält. Schwarzes 16GB iPad. Schwarzes 16GB iPad. Schwarz 16GB iPad. Schwarz 16GB iPad“ sind konzeptionell ungefähr dasselbe. Um sicherzustellen, dass es nicht zu Verzerrungen kommt, die lange Dokumente begünstigen, kann Fusion die Länge der Vektoren, die in den vorherigen Schritten ausgegeben wurden, entweder anhand der euklidischen Länge (bekannt als L2-Normalisierung) oder der absoluten Wertlänge (L1-Normalisierung) normalisieren. Oder Fusion kann die Vektoren unnormalisiert lassen.

Eine Beispielkonfiguration für das Training eines Random Forest Klassifikators könnte so aussehen:

{
type: "random_forests_classifier",
id: "random_forest_department_classifier_trainer",
modelId: "random_forest_department_classifier_model_w2v",
analyzerConfig: "{ "analyzers": [{ "name": "StdTokLowerStop","charFilters": [ { "type": "htmlstrip" } ],"tokenizer": { "type": "standard" },"filters": [{ "type": "lowercase" },{ "type": "stop" }] }],"fields": [{ "regex": ".+", "analyzer": "StdTokLowerStop" } ]}",
withIdf: true,
norm: 2,
w2vDimension: 200,
w2vWindowSize: 5,
w2vMaxSentenceLength: 1000,
w2vStepSize: 0.025,
w2vMaxIter: 1,
minDF: 10,
maxDF: 0.8,
dataFormat: "solr",
trainingCollection: "ecommerce",
trainingDataFilterQuery: "+longDescription:* +department:*",
trainingDataSamplingFraction: 1,
trainingDataFrameConfigOptions: { },
overwriteOutput: true,
trainingLabelField: "department",
sourceFields: "id,longDescription,department",
fieldToVectorize: "longDescription",
predictedLabelField: "labelPredictedByFusionModel",
gridSearch: false,
evaluationMetricType: "none",
randomSeed: 1234,
maxDepth: 5,
maxBins: 32,
numTrees: 20
}

Hilfe zur Fehlersuche

Wenn Fusion ein maschinelles Lernmodell auf Spark trainiert, erzeugt der Fusion-API-Dienst einen „Treiber“-JVM-Prozess, der seine Ausgabe in der Datei $FUSION_HOME/var/log/api/spark-driver-default.log. Dies ist der richtige Ort, um Probleme mit diesen Trainingsaufträgen zu beheben (sowie $FUSION_HOME/var/log/api/api.log, wenn der Auftrag beispielsweise aus irgendeinem Grund nicht startet.

Ein erfolgreicher Lauf der Modellschulung ist auf verschiedene Weise sichtbar:

• Direkt auf der Seite zur Konfiguration von Aufträgen, auf der Sie auf Ausführen> Start geklickt haben, sehen Sie schließlich den Status Erfolg links neben der Schaltfläche Start.

• Durch Abfrage der REST-API des Spark-Jobs nach dem Status aller laufenden, abgeschlossenen und fehlgeschlagenen Jobs: http://$FUSION_HOST:8764/api/apollo/spark/jobs/random_forest_department_classifier

• In der Spark-Web-Oberfläche http://$FUSION_HOST:8767 können Sie sehen, dass der von Ihnen gestartete Auftrag als „abgeschlossen“ und nicht als „fehlgeschlagen“ angezeigt wird.
• Die vorgenannten Methoden funktionieren für alle Spark-Aufträge, die von Fusion aus gestartet werden. Bei Trainingsaufträgen für Klassifizierer möchten Sie jedoch wissen, ob der Auftrag ein trainiertes Modell erzeugt und im Blob-Speicher von Fusion gespeichert hat. Das können Sie überprüfen:
  • In der Fusion-Benutzeroberfläche unter Devops > Blobs > Andere. Suchen Sie nach random_forest_department_classifier.

• • Über den HTTP/REST-Endpunkt http://$FUSION_HOST:8764/api/apollo/blobs (um alle zu sehen) oder http://$FUSION_HOST:8764/api/apollo/blobs/sample_rf_classifier/manifest, um den Status dieses bestimmten Blobs zu erhalten.

Nachdem Sie wissen, dass der Auftrag erfolgreich abgeschlossen und das Modell im Blob-Speicher gespeichert wurde, ist es an der Zeit, den Klassifikator in Aktion zu sehen!

Einbindung des Klassifikators in eine Indizierungsphase

Da Sie nun ein Modell im Blob-Speicher gespeichert haben, können Sie es bei der Indizierung verwenden. Wenn Dokumente eintreffen, lässt Fusion sie durch den Klassifikator laufen, der vorhersagt, zu welchen Klassen die Dokumente gehören sollten, und speichert die Bezeichnungen für die vorhergesagten Klassen in einem neuen (oder bestehenden) Feld in den Dokumenten.

Um dies in Fusion zu tun, müssen Sie lediglich eine Indizierungsstufe vom Typ Maschinelles Lernen zu einer Index-Pipeline hinzufügen. Um einfach und schnell zu sehen, wie die Ergebnisse aussehen, ist es am einfachsten, dies in der Index Workbench zu tun. Legen Sie also eine neue Sammlung an. Sie werden dieselben Daten, mit denen Sie das Modell trainiert haben, erneut indizieren, aber diesmal mit dem Klassifikator. In der Praxis kann es vorkommen, dass Sie Ihren Klassifikator auf einigen kategorisierten/markierten Daten trainiert haben und dann die unmarkierte Teilmenge wieder in dieselbe Sammlung reindizieren möchten, um die Lücken zu füllen. Dies erfordert eine Änderung der Index-Pipeline, die Sie bereits für diese Sammlung haben.

Die wichtigsten Konfigurationsparameter für die Index-Pipeline-Stufe des maschinellen Lernens sind:

• Machine Learning Model ID: Dies ist die ID des Modells, das Sie trainiert und im Blob Store gespeichert haben.
• Dokument-Funktionsfeld: Dies ist ein Solr-Feld in Ihren Eingabedokumenten, das Sie in das Modell einspeisen werden, um Vorhersagen zu erstellen. Wenn Sie nicht sicher sind, um welches Feld es sich handeln könnte, haben Sie vielleicht ein body_s Feld, das das gesamte Dokument enthält und das Sie verwenden können.

Hinweis: Dies muss nicht dasselbe Feld sein wie das, auf dem Sie Ihr Modell oben trainiert haben. Das kann der Fall sein, wenn Sie das Szenario „Erweitern Sie die Kategoriebeschriftungen von einer Teilmenge Ihrer Sammlung auf den Rest“ durchführen, das wir gerade durchgespielt haben. Aber manchmal trainieren Sie vielleicht auf einer Sammlung mit einem Satz von Feldern für die Merkmalsextraktion und die Beschriftung und indizieren dann eine Sammlung mit anderen Feldern, die aber hoffentlich einen ähnlichen Inhalt haben, damit der Klassifikator genaue Vorhersagen macht.

• Name des Vorhersagefeldes: Dies ist der Name des Feldes, in dem Sie die vorhergesagten Bezeichnungen für das Dokument speichern möchten. Es kann ein bestehendes Feld sein (in diesem Fall werden die vorausgesagten Bezeichnungen an die bestehenden Daten in diesem Feld angehängt) oder ein neues Feld.
• Standardwert (optional): Sie können einen Standardwert für dieses Vorhersagefeld verwenden, wenn der Klassifikator für ein Dokument kein Ergebnis liefert.
• Bei Fehler fehlschlagen (optional): Veranlassen Sie, dass die Pipeline bei Klassifizierungsfehlern schnell fehlschlägt. So können Sie Probleme bei der Fehlersuche leichter finden oder in Fällen, in denen das Vorhersage-Label einen wichtigen Teil der Daten Ihres Indexes bildet und Dokumente ohne dieses Feld einfach nicht richtig strukturiert sind.

Nachdem Sie diese Stufe konfiguriert haben, setzen Sie sie direkt vor die Solr Indexer-Stufe in der Index-Pipeline und beobachten Sie die simulierten Ergebnisse der neuen Pipeline. Ihr neues Feld sollte vorhanden sein und sinnvolle Werte haben. Wenn es nicht vorhanden ist, überprüfen Sie das Protokoll $FUSION_HOME/var/log/connectors/connectors.log und sehen Sie nach, ob es Fehler im Zusammenhang mit dem Modell oder dem Datensatz gibt.

Beachten Sie auch, dass Sie die Ausgaben dieser Klassifikatoren nicht nur einfach im Index speichern können. Indizierungs-Pipelines sind Pipelines. Es gibt also keinen Grund, warum Sie nicht eine Pipeline-Phase erstellen können, die der Machine Learning-Phase nachgeschaltet ist und die auf irgendeine Weise auf deren Ergebnisse reagiert. Wenn ein Dokument beispielsweise als Spam eingestuft wird, könnte es aus dem Index ausgeschlossen werden (über eine Stufe „Dokumente ausschließen“). Wenn es als PII (persönlich identifizierbare Informationen) eingestuft wird, könnte eine REST-Pipeline-Stufe einen Aufruf an einen Drittanbieterdienst initiieren, oder eine JavaScript-Stufe kann die von Ihnen benötigte Geschäftslogik implementieren.

Einbindung des Klassifikators in eine Abfragephase

Es gibt zwar viele „fortgeschrittene“ Arten von Pipelines, die Sie für die Index-Pipeline-Phase des maschinellen Lernens in Betracht ziehen können, aber der Hauptzweck der Index-Pipeline ist ziemlich einfach: Klassifizieren Sie den zu indizierenden Inhalt, wenden Sie eine Klassenbezeichnung auf ein Feld im Dokument an und indizieren Sie das Dokument. Wenn Sie Benutzerabfragen klassifizieren möchten, wird das Szenario sehr produktabhängig. Erkennt Ihr Abfrageklassifikator, nach welcher Dokumentenkategorie der Benutzer am ehesten sucht? Oder erkennt er, dass verschiedene Arten von Abfrageabsichten im Spiel sind („Suche nach bekannten Artikeln“ vs. „breit angelegte Themenabfrage“ vs. „natürlichsprachliche Frage“)? Jede dieser Möglichkeiten ist denkbar, aber welche Art von Abfrageklassifikator Sie trainieren können, hängt davon ab, welche Trainingsdaten Sie haben. Wenn Ihre Dokumentensammlung mit Kategorien verknüpft ist, können Sie die Klickdaten verwenden, um Abfragekategorie-Etiketten zu generieren: Jede Abfrage, bei der in mehr als, sagen wir, 90 % der Fälle auf Dokumente einer einzigen Kategorie geklickt wird, könnte zuverlässig als diese Kategorie eingestuft werden. Für eine breit angelegte Klassifizierung von Suchanfragen könnte die manuelle Kennzeichnung von ein paar Tausend Suchanfragen jedes Typs ein guter Anfang sein. In diesem Fall kann ein Ansatz, der als aktives Lernen bekannt ist, nützlich sein: Trainieren Sie Ihren ersten Klassifikator auf den ersten paar Tausend gekennzeichneten Suchanfragen, wenden Sie diesen Klassifikator dann auf den gesamten Satz an und überprüfen Sie schnell die Ergebnisse, bei denen der Klassifikator ein hohes Vertrauen hatte, um weitere Kennzeichnungen zu erzeugen. Wiederholen Sie diesen Vorgang dann mit der neu hinzugekommenen Menge an beschrifteten Suchanfragen).

Doch bevor wir uns genau ansehen, was Sie mit diesen Abfrageklassifikatoren tun können, lassen Sie uns eine Abfrage-Pipeline mit unserem neuen Modell einrichten und sehen, wie sie in der Query Workbench aussieht.

Das Hinzufügen einer neuen Abfragestufe für maschinelles Lernen zur Standard-Abfrage-Pipeline in der Query Workbench ist an sich sehr einfach:

• Machine Learning Model ID: Dies ist die ID des Modells, das Sie trainiert und im Blob Store gespeichert haben.
• Feature-Feld abfragen: Dies ist der Abfrageparameter, aus dem Sie die Merkmale entnehmen, die Sie klassifizieren möchten. Standardmäßig ist es das Feld q, in das der Haupttext der Abfrage eines Benutzers eingefügt wird.
• Name des Vorhersagefeldes: Dies ist der Abfrageparameter, in dem Fusion die Ausgabe des Klassifizierers speichert, was an sich nicht viel an Ihren Abfrageergebnissen ändern dürfte, es sei denn, dieser Parameter ist für Solr direkt verständlich.
• Standardwert (optional): Sie können einen Standardwert für dieses Vorhersagefeld verwenden, wenn der Klassifikator für ein Dokument kein Ergebnis liefert.
• Bei Fehler fehlschlagen (optional): Veranlassen Sie, dass die Pipeline bei Klassifizierungsfehlern schnell fehlschlägt. So können Sie Probleme bei der Fehlersuche leichter finden oder in Fällen, in denen das Vorhersage-Label ein erforderlicher Teil der Daten Ihrer Abfrage ist und die Dokumente ohne dieses Feld einfach nicht richtig strukturiert sind.

Lassen Sie uns eine Abfrage nach „50mm“ durchführen (als ob wir nach Kameraobjektiven suchen würden):

Wie bereits erwähnt, müssen Sie an dieser Stelle entscheiden, was mit der Suchanfrage geschehen soll, nachdem Sie einen neuen Abfrageparameter, wie predictedDepartment, darauf angewendet haben. In dem zu Beginn dieses Artikels beschriebenen Motivations-Szenario haben wir uns vorgestellt, diese Vorhersage automatisch als Facettenfilter anzuwenden, um unseren Benutzern einen Navigationsschritt zu ersparen. Jetzt haben Sie die Werkzeuge, um dies zu tun. Sie fügen eine weitere einfache Abfrage-Pipeline-Stufe hinzu, in diesem Fall eine Stufe mit zusätzlichen Abfrageparametern, in der Sie eine Filterabfrage mit dem fq-Parameter von Solr mit dem Wert: department:”${predictedDepartment}” anwenden. Mit dieser Syntax teilen Sie Fusion mit, dass Sie eine variable Ersetzung eines Abfrageparameters durch eine andere Zeichenkette vornehmen möchten. Wenn also die Abfrage-Pipeline-Stufe des maschinellen Lernens feststellt, dass sich der q-Parameter auf die Abteilung Foto/Waren bezieht, dann fügt diese zusätzliche Abfrageparameter-Stufe einen Abfrageparameter &fq=Abteilung: „Foto/Waren“ an die Anfrage an. Beachten Sie, dass der Parameter predictedDepartment sowohl in geschweifte Klammern (für die Variablensubstitution) als auch in doppelte Anführungszeichen eingeschlossen ist (um sicherzustellen, dass die gesamte vorhergesagte Abteilungszeichenkette als exakte Übereinstimmung behandelt wird, falls sie Leerzeichen oder Sonderzeichen enthält).

Sie sehen nun, dass die kombinierte Wirkung der Stufen Abteilungsvorhersage und Abteilungsfilter anwenden die Ergebnismenge auf Katalogartikel in der Abteilung Foto/Waren beschränkt (dies gilt sowohl für die Suchergebnisse selbst als auch für die Anzahl der Facetten).

Es gibt noch andere Möglichkeiten, die Klassifizierungsstufe in Ihrer Abfrage-Pipeline zu nutzen. Anstatt das Ergebnis als Kategoriefilter anzuwenden, könnten Sie zum Beispiel einfach die Ergebnisse, die sich in einer Kategorie befinden, verstärken, was sich zwar auf die Suchrelevanz, nicht aber auf die UX auswirkt. Oder wenn die Anfrage als natürlichsprachliche Abfrage erkannt wurde, wie z.B. „Wie bringe ich meinen Kühlschrank zurück?“, könnte die Abfrage-Pipeline die Anfrage durch eine NLP-Phase leiten, um sie weiter mit Part-of-Speech-Tags zu versehen (und z.B. nur die Begriffe der Substantivphrasen weiterzuleiten), oder sie könnte eine ganz andere Sammlung ansteuern (z.B. die FAQ-Sammlung).