Tischeinsätze ML für intelligente Suche

Präsentiert auf der virtuellen Activate 2020. Maximierung des Geschäftswerts in einer digitalen Umgebung, in der Suchanfragen den primären Blick auf die Bedürfnisse Ihrer Nutzer darstellen.

Präsentiert auf der virtuellen Activate 2020. Die Maximierung des Geschäftswerts in einer digitalen Umgebung, in der Suchanfragen die primäre Sicht auf die Bedürfnisse Ihrer Benutzer sind, macht die Suche zu einem Problem des maschinellen Lernens. Aber wie viel „ML“ wird heutzutage wirklich benötigt und welche Art von Infrastruktur ist erforderlich, um all dieses ML zu unterstützen?

In diesem Vortrag erörtert Jake eine kurze Liste dessen, was erforderlich ist (in Bezug auf Produktmerkmale, architektonische Komponenten und technische Verfahren), damit unsere Suchmaschinen einen „Platz am Tisch“ der hochgradig geteilten Aufmerksamkeit unserer Benutzer erhalten.

Sprecher:
Jake Mannix, Search Relevance Architect, Salesforce.com, Inc.

Teilnehmer:
Einige werden sich daran erinnern, dass Sie einen Feature Store, Personalisierung, einen Sitzungsverlauf und ähnliches brauchen. Für diejenigen, die neu im Bereich ML-in-Search sind, ist es eine kurze Liste von Orten, an denen man anfangen sollte (aber es könnte 3-5 Jahre dauern, bis Sie alles hinzugefügt haben!)

Zielgruppe:
Ingenieure, Datenwissenschaftler und Produktmanager für Suchteams, Führungskräfte und Manager, die Kaufentscheidungen für Suchmaschinentechnologie treffen

---

Abschrift

Jake Mannix: Als Architekt für Suchrelevanz werde ich oft gefragt, wie ich die Suchfunktion meiner Website oder App oder meines Startups intelligenter gestalten kann. Was ist erforderlich und was kann später kommen?

Im Laufe der Jahre, in denen ich auf diese Fragen geantwortet habe, habe ich eine Liste von wichtigen Suchfunktionen und Architekturkomponenten erstellt, die diese unterstützen, und die ich heute mit Ihnen teilen möchte.

Doch bevor wir eintauchen, müssen wir uns fragen, was die Suche intelligent macht? Nun, gute Suchrelevanz, richtig? Nun, aber was ist das? Um den geschäftlichen Wert von Besuchen in einem suchgesteuerten Fluss zu maximieren, müssen Sie in der Lage sein, so genau wie möglich vorherzusagen, was Ihre Benutzer tun werden, nachdem sie eine Anfrage an Sie gestellt haben. Wird er auf einen Datensatz klicken, um auf eine andere Seite zu gelangen? Werden sie tatsächlich etwas in den Warenkorb legen oder einen Artikel auf Ihrer eCommerce-Website kaufen? Werden sie Ihren Artikel in den sozialen Medien teilen? Was ist das Bedürfnis Ihres Unternehmens, das Sie zu fördern versuchen? Der beste Weg, sie dazu zu bringen, mehr von dem zu tun, was Sie wollen, ist, eine gute Vorstellung davon zu haben, was sie tun werden, wenn Sie ihnen zeigen, was sie tun.

Die Suchrelevanz ist also ein komplexes Data-Science-Problem, das auf detaillierten Instrumenten zum Erlernen von Vorhersagemodellen auf der Grundlage Ihrer Benutzer, ihrer Fragen und der möglichen Antworten beruht.

Das ist ein Zitat von mir, das ich vor ein paar Jahren auf einer anderen Konferenz gegeben habe, aber das ist in Ordnung.

Damit die Suche intelligent ist, muss sie konversationell sein. Damit meine ich etwas ganz Bestimmtes. Eine Suchanfrage besteht in der Regel nicht aus einer einzigen Anfrage und einem einzigen Satz von Antworten. Wenn ich nach einem weißen Mantel mit schwarzer Krawatte suche, d.h. nach einem weißen Smoking für eine formelle Veranstaltung mit schwarzer Krawatte, und Sie diese Frage an ein ungetuntes Lucene Solr-basiertes System stellen, werden Sie von den ersten Ergebnissen wahrscheinlich enttäuscht sein.

Wenn Sie geduldig sind, werden Sie vielleicht versuchen, Ihre Suchanfrage ein paar Mal umzuformulieren, schwarzer Krawattenmantel, der weiß ist, oder sogar wie ich es vorhin beschrieben habe. Weiße Krawatte, weißer Smoking für eine formelle Veranstaltung. Hoffentlich geraten Sie dann nicht in ein Stühlerücken mit Ihrer Suchmaschine.

Es stellt sich übrigens heraus, dass Google diese schwierige Anfrage nicht nur versteht, sondern auch korrekt unterschiedliche Ergebnisse für weißen, schwarzen Krawattenmantel und schwarzen, weißen Krawattenmantel liefert.

Auf der anderen Seite behandelt Amazon diese Anfrage nicht korrekt. Die Suche nach weißen Smokings funktioniert, aber die Suche nach einer schwarzen Krawatte ist völlig unzureichend. Nun, mein Hauptargument, die Suche konversationstauglich zu machen, ist vielleicht besser formuliert als „session aware“ oder „no short term memory loss“.

Denken Sie daran, was Ihre Benutzer abfragen. Sie versuchen, sie zu lehren, Ihnen beizubringen, was sie meinen. Einige von Ihnen werden vielleicht sagen, nein, nein, nein, nein. Ich würde diese spezielle Art von Abfrage mit X oder Y oder Z Techniken der natürlichen Sprachverarbeitung lösen. Das wäre großartig. Dem stimme ich zu. Die Suche sollte natürlich sein. Die Zeiten, in denen man sich einfach auf Stoppwörter, ausgeklügelte Tokenizer, Stemmers und Lemmatizer verlassen hat, sind längst vorbei.

Die Tabelleneinsätze einer natürlichen Suche gehen sogar über die statistische Identifizierung von Phrasen hinaus. Wenn Sie eine vollständige NLTK-Stoppwortliste verwenden, erhalten Sie wahrscheinlich eine gefilterte Abfrage in der Form „Konto bereits eröffnet“, was zwar technisch gesehen die Frage des Benutzers ist.

Offen gesagt ist es unwahrscheinlich, dass ein einfaches stichwortbasiertes System damit Erfolg hat. Heutzutage erwarten die Benutzer, dass sie Abfragen wie diese verwenden können, oder sogar meine schamlose Werbung, Marias Top-Offene-Opportunities in Seattle mit Stage Prospecting, die diesen Monat geändert wurden, weil Einstein Search bei Salesforce diese spezielle komplexe natürliche Abfrage tatsächlich verarbeiten kann.

Sie werden feststellen, dass in diesem Beispiel im zweiten Fall eine ziemlich eklatante Zweideutigkeit vorliegt. Wer, zum Teufel, ist Maria? In meiner Firma gibt es wahrscheinlich viele Marias. Es ist ein ziemlich geläufiger Name. Nun, ja, aber vielleicht gibt es in meinem Team nur eine Maria, mit der ich häufig zu tun habe oder nach der ich mich erkundige.

Wenn Ihre Suchmaschine personalisiert ist, werden Sie damit zurechtkommen. Sogar in Unternehmen gibt es häufig den Begriff des sozialen Graphen. Über einen einfachen sozialen Graphen von Benutzer zu Benutzer hinaus bedeutet Personalisierung, dass Sie aktuelle und weniger aktuelle Suchanfragen und andere Interaktionen Ihrer Benutzer speichern und möglicherweise wissen, wie Sie sie in ähnliche demografische Gruppen segmentieren oder gruppieren können.

Es bedeutet auch, dass Sie ausgeklügelte oder auch nur einfache, auf der Zählung basierende Nutzerinteressenprofile erstellen und die Suchanfragen und sonstigen Interaktionen Ihrer Nutzer verfolgen müssen. Was mich daran erinnert, dass die Suche reaktionsfähig sein muss, um ein natürliches und personalisiertes intelligentes Suchsystem zu betreiben. Wir müssen hören, was unsere Nutzer fragen und verstehen, was sie tun, wenn sie etwas tun, was sie wirklich tun wollten.

Ist ein Klick immer ein positives Signal? Nicht immer. Was ist, wenn sie zurückgehen und sich die Suchergebnisse ein zweites Mal ansehen? Sie stellen fest, dass die Seite falsch ist, und verlassen sie deshalb. Was ist, wenn sie etwas in den Warenkorb legen? Dann entfernen sie es wieder aus ihrem Warenkorb? Ist das ein positives Signal? Das kann von den Analysen Ihres Unternehmens abhängen. Das ist eigentlich ein weiteres heikles Problem der Datenwissenschaft, aber Sie wollen ja nicht Ihren köstlichen Zyklus vorantreiben, dafür sind Ingenieure viel zu teuer.

Sie werden Ihren Maschinen beibringen müssen, das zu lernen. Das meiste von dem, was ich hier beschrieben habe, erfordert maschinelles Lernen, gerade weil Sie wahrscheinlich nicht so viele Daten haben wie Google. Wie bereits angedeutet, können sie oft mit dem Zählen als Algorithmus für maschinelles Lernen auskommen. Das können Sie manchmal auch, aber wenn Sie das nicht können, müssen Ihre anspruchsvolleren ML-Modelle modular sein. Genau wie bei der übrigen Softwareentwicklung brauchen Sie auch für ML lose gekoppelte Subsysteme. Allerdings muss hier ein Gleichgewicht gefunden werden. Eine völlige Entkopplung führt zu unzureichend leistungsfähigen Modellen und doppeltem Aufwand.

Eine enge Kopplung führt zu instabilen Systemen, die spröde und zerbrechlich sind. Nachdem ich ein wenig multivariate Tests mit dieser Folie durchgeführt hatte, stellte sich heraus, dass es für dieses Ass im Gesamtkonzept der ML-Modularität notwendig war, mein Muster „eine Folie pro Konzept“ zu durchbrechen.

Lassen Sie uns ein wenig nachhaken.

Wenn Sie den Weg einschlagen, den ich bisher beschrieben habe, haben Sie möglicherweise viele Personalisierungsmodule mit kollaborativen Filterschichten, Einbettung von Benutzer-IDs, Deep-Learning-Modellen, Textklassifizierern verschiedener Typen, Einbettung verschiedener Dokumentkodierungen und Abfragekodierungen, mehreren Ranking-Schichten über das gesamte Spektrum der Latenz- und Qualitätskompromisse hinweg, von einem linearen Modell tief in Ihrer Lucene-Schicht bis hin zu einem L2 und L3 Re-Ranker gegenüber einer ganzen Seitenrelevanz auf der obersten Ebene, und jedes Maß an ML-Kopplung zwischen diesen führt dazu, dass diese Modelle sich gegenseitig beeinflussen.

Sie haben Abfrageklassifizierungswahrscheinlichkeiten als Merkmale in Ihrem Ranking-Modell. Sie werden Ranking-Speicher und Ranking-Scores als Merkmale in Ihrer Text-to-SQL-Engine haben. Sie werden Personalisierungsebenen und Empfehlungsgeber als gemeinsame Komponenten in vielen verschiedenen Modellen haben.

Um Ihnen ein paar Beispiele dafür zu geben, wovon ich spreche, sehen wir uns einige Fallstricke in der Modularitätslandschaft an, die guten, die schlechten und die hässlichen.

Der gute Fall. Das Team für das Verstehen von Suchanfragen erstellt ein großartiges Modell für die Einbettung der Personalisierung. Sie speichern diese eingefrorene Einbettungsschicht und geben sie an das Ranking-Team weiter, das damit ein Ranking-Modell feinabstimmen kann, ohne die Gewichte des zugrunde liegenden Personalisierungseinbettungsmodells zu ändern. Eine Win-Win-Situation für beide Teams und beide Produkte.

Schlechter Fall. Das Team für das Verstehen von Dokumenten hat einen ausgeklügelten Text-zu-Vektor-Codierer entwickelt, der jedoch sehr auf lange Dokumente spezialisiert ist. Und er funktioniert nicht mit Abfragen. Er kann nicht mit ihnen geteilt werden.

Das hässliche Beispiel. Das ist ein Beispiel aus der Praxis, das wir in Salesforce erlebt haben. Das Modell für die Relevanz der gesamten Seite wird mit den Ergebnissen der dritten Stufe des neuen Rankings als Input-Merkmalen trainiert, aber dann startet das Ranking-Team ein neues Ranking mit Ergebnissen, die nun zwischen null und eins statt zwischen 1 und 100 skaliert sind. Das gesamte Modell für die Seitenrelevanz bricht komplett zusammen, es sei denn, Sie kalibrieren Ihre Modelle sorgfältig neu.

Es wird knifflig. Es gibt eine Menge Probleme, wenn es darum geht, die Modelle miteinander zu verbinden. Aber wenn Sie das nicht tun, sind die einzelnen Modelle zu schwach, um eine angemessene Suchrelevanz zu erzielen.

Nehmen wir an, wir fangen an, diese Funktionen für Ihre Suchmaschine zu entwickeln und all diese kniffligen datenwissenschaftlichen Probleme anzugehen. Welche Art von Architektur brauchen Sie zur Unterstützung? Es sollte sich von selbst verstehen, dass Sie solide Datenpipelines benötigen, aber es lohnt sich, dies zu wiederholen. Behandeln Sie Relevanz-Feedback von Ihrer UI-Ebene als einen erstklassigen Bürger in Ihrer Datenlandschaft, gleichrangig mit den APIs zum Suchen und Hinzufügen zum Index.

Es sollte auch selbstverständlich sein, dass Sie für das Training Ihrer Modelle Computer benötigen, die skalierbar und sicher sind. Sie lassen Ihre Datenwissenschaftler doch nicht auf ihren Desktops trainieren, oder?

Aber auch der gesamte Lebenszyklus von Datentransformationen auf der Grundlage Ihrer Datenpipelines muss Daten mit geringer Latenz berechnen und schließlich mit Daten auffüllen, die nicht unbedingt in den Suchindex gehören, aber zur Abfragezeit verwendet werden.

Das bringt mich zu den datengesteuerten Produkten. Diese erfordern mehrere verschiedene Arten der Datenspeicherung, nicht nur Ihren invertierten Index, der sozusagen das Brot und Butter der Suche ist, sondern auch einen Dokumentenspeicher, der die nicht invertierte Form der Originaldokumente speichert.

Dies wird zum Erlernen eines Modells zum Verstehen von Dokumenten sowie zur Bereitstellung von Rohdaten verwendet, die bei der Neueinstufung verwendet werden können und die Sie vielleicht aus Platzgründen nicht in Ihrem Index speichern möchten, aber vielleicht für die 50 besten Ergebnisse. Sie holen sie aus einer ersten Ebene und geben sie in einen Re-Ranker ein. Alle Rohdaten durchlaufen dann einen Ranker, der vielleicht zu langsam ist, um jedes Dokument zu überprüfen, aber vielleicht für die Top 50 geeignet ist.

Außerdem benötigen Sie einen Feature-Speicher, in dem alle Features gespeichert werden, die auf eine bestimmte Abfrage bezogen sind, die eingeht. Sie holen die Merkmale der Abfrage ab, vielleicht alle Merkmale der natürlichen Sprache oder die Personalisierungsmerkmale. Die Benutzer-ID hat eine Einbettung, die Sie herausziehen wollen, oder die letzten Abfragen des Benutzers oder Informationen aus der Sitzung oder die Merkmale der Dokumente, die Sie neu bewerten wollen.

Ein Feature Store ist eine Art architektonische Komponente, an die man vor fünf, sechs Jahren noch nicht gedacht hat.

Und schließlich ein Modellspeicher. Denn niemand möchte, dass seine Modelle in Lucene oder noch schlimmer in Zookeeper gespeichert werden. Sie wollen definitiv keine heimatlosen Modelle.

Für ein effizientes Model Serving sollte die Inferenz außerhalb von Lucene und Solr stattfinden. So erhalten Sie unabhängig skalierbare Vorhersagen mit geringer Latenz.

Was ich damit meine? Es bedeutet, dass Sie, wenn Ihre Indexgröße stark ansteigt und Sie das Modell nicht neu trainieren, Ihr Modell nicht in allen verschiedenen Indexdiagrammen replizieren möchten.

Wenn Sie andererseits von einem kleinen linearen Modell zu einem Deep Learning-Modell übergehen, wollen Sie auch nicht alle Ihre Index-Splitter mit dieser Skalierung überlasten.

Sie möchten, dass sie unabhängig voneinander skalieren und den Kompromiss zwischen Relevanz und Latenzzeit nach Belieben anpassen können.

Schließlich möchten Sie sicherstellen, dass Sie eine geringe Verzerrung beim Training und bei der Ausgabe haben. Dies ist ein kniffliges Problem in der Datenwissenschaft, das vor allem bedeutet, dass Sie bei der Laufzeitinferenz dieselben Merkmale mit derselben Vor- und Nachverarbeitung bereitstellen, die Sie zur Laufzeit und zur Trainingszeit hatten.

Das kann ein großer Alptraum sein, wenn es falsch gemacht wird, und sehr schwierig zu debuggen. Wenn Sie jedoch über einen geeigneten Online-Offline-Funktionsspeicher verfügen, der sicherstellt, dass die Daten zur Trainingszeit und zur Laufzeit in der exakt gleichen Form und mit den gleichen Vorverarbeitungsschritten zur Verfügung stehen, können Sie dies vermeiden. Außerdem müssen Sie eine Möglichkeit haben, das entkoppelte Laden von Modellen aus dem Modellspeicher in eine Serving-Schicht zu validieren, die genauso funktioniert wie beim Training.

Dann werden Sie hier gut aufgehoben sein.

Abschließend wäre ich nachlässig, wenn ich nicht noch ein paar schamlose Werbespots machen würde. Sie sollten Einstein Search in Salesforce’s CRM-Flaggschiff ausprobieren und Sie werden das Ergebnis vieler dieser Praktiken der natürlichen Sprache, der natürlichsprachlichen Suche, der Personalisierung und so weiter in Aktion sehen.

Sie werden die architektonischen Komponenten nicht wirklich sehen können, aber sie sind unter der Haube versteckt. Wenn Sie mehr darüber erfahren möchten, wie Sie selbst etwas davon bauen können, sollten Sie sich unseren Vortrag über ML4LR ansehen, unsere neue Open-Source-Bibliothek für tiefes Lernen, mit der Sie eine Vielzahl von Suchproblemen lösen können, der später auf dieser Konferenz stattfindet.