Implementierung einer Deep Learning Suchmaschine

Wie man eine Deep Learning-Suchmaschine mit Lucidworks implementiert und Techniken, um robuste und effiziente Modelle zu trainieren und die Skalierbarkeit in Angriff zu nehmen.

Präsentiert auf der virtuellen Activate 2020. Die jüngsten Fortschritte im Bereich Deep Learning bieten uns die Möglichkeit, in fast jedem Bereich Verbesserungen zu erzielen. Suchmaschinen sind da keine Ausnahme. Semantische Suche, visuelle Suche, „Null-Ergebnisse“-Abfragen, Empfehlungen, Chatbots usw. – das ist nur eine kleine Auswahl von Themen, die von Deep Learning-basierten Algorithmen profitieren können. Aber leistungsfähigere Methoden sind auch teurer, so dass sie eine Vielzahl von Herausforderungen in Bezug auf die Skalierbarkeit bewältigen müssen. In diesem Vortrag gehen wir im Detail darauf ein, wie wir die Deep Learning Search Engine bei Lucidworks implementieren: welche Techniken wir verwenden, um robuste und effiziente Modelle zu trainieren, und wie wir Skalierbarkeitsprobleme angehen, um die beste Abfragezeitleistung zu erzielen. Wir werden auch verschiedene Anwendungsfälle demonstrieren, wie wir semantische Suchfunktionen nutzen, um Herausforderungen wie die visuelle Suche und „Null-Ergebnisse“-Abfragen im eCommerce zu bewältigen.

Referenten:
Sava Kalbachou, AI Research Engineer, Lucidworks
Ian Pointer, Senior Data Engineer, Lucidworks

Zielgruppe:
Ingenieure, Data Scientists, Product Owner und einfach Enthusiasten des maschinellen Lernens, die ihre Produkte mit den DL-gestützten semantischen Suchfunktionen bereichern möchten. Vorkenntnisse sind nicht erforderlich, können aber nützlich sein, um einige Konzepte in der Tiefe zu verstehen.

Teilnehmer nehmen mit:
Sie erfahren, wie DL-basierte semantische Suchlösungen das Sucherlebnis für Sie und Ihre Benutzer drastisch verbessern können und dennoch skalierbar und in der Produktion einsetzbar sind.

---

Abschrift:

Ian: Hallo, ich bin Ian, Senior Data Engineer bei Lucidworks.

Heute werden Sava und ich mit Ihnen darüber sprechen, wie wir eine neue dichte Vektorsuchmaschine in Fusion 5 integrieren.

Ich möchte Ihnen nur einen Überblick über einige unserer Angebote für die semantische Suche geben, die wir bereits in Fusion 5 haben. Wir bieten Ihnen mehrere Möglichkeiten, Ihre Daten mit einigen unserer neuen Funktionen anzureichern und zu präsentieren, einschließlich unserer Empfehlungsfunktionen.

Wir haben unsere auf Benutzer-Element-Interaktion basierenden Empfehlungssysteme. Dazu gehört unser klassisches ALS-System, und wir haben auch einen neuen BPR-Empfehlungsgeber, der gerade erst in Fusion 5.2 eingeführt wurde. Wir haben inhaltsbasierte Empfehlungssysteme, ähnliche abfragebasierte Empfehlungssysteme und wir arbeiten derzeit aktiv an einigen sitzungs- und bildbasierten Empfehlungssystemen, die in zukünftigen Versionen verfügbar sein werden.

Bei Smart Answers handelt es sich um unsere Deep Learning-basierte Lösung für die natürlichsprachliche Suche. Sie bietet überwachtes Training auf Frage-Antwort-Paaren oder Signaldaten. Aber wir bieten auch eine Kaltstartlösung an, wenn Sie diese Informationen nicht sofort zur Hand haben.

Wir bieten maßgeschneiderte kleine und effiziente Deep Learning-Modelle. Wir unterstützen auch umfangreichere Modelle wie BERT und können Smart Answers auch sprachübergreifend verwenden, was Sava später in seinem Vortrag zeigen wird. In Kürze werden wir unsere Smart Answers-Funktion um die Extraktion kurzer Antworten erweitern.

Einige der Technologien, die wir in der heutigen Demo zeigen, werden für die Implementierung der Bildsuche verwendet. Werfen wir einen Blick darauf, wie einige dieser Technologien derzeit implementiert sind. In unserer aktuellen Version von Fusion, 5.2. Wie Sie auf der linken Seite sehen können, haben wir unseren üblichen Standardspeicher von Solr in der Mitte haben wir unsere Empfehlungsfunktion und die intelligenten Antworten. Auf der rechten Seite haben wir unseren Index und die Abfrage-Pipelines.

Die Empfehlungsprogramme in Smart Answers lesen heute alle Informationen, die sie verwenden werden, aus Solr. Im Falle der Empfehlungsprogramme generieren die Empfehlungsprogramme ihre Empfehlungen und schreiben diese Informationen dann zurück in Solr, in verschiedene Sammlungen.

Im Falle von Smart Answers lesen sie die Daten aus Solr ein und trainieren ein Deep Learning-Modell auf diesen Daten. Das trainierte Modell wird dann über den Seldon-Kern im Fusion-Cluster bereitgestellt und beim ML-Service registriert. Auf der Pipeline-Seite rufen wir dann bei der Indexierung von Smart Answers das Modell mit dem Dokument auf und erhalten eine Kodierung des Modells mit diesem Dokument. Dann komprimieren wir diese Vektordarstellung und die Cluster und fügen sie zu Feldern im Dokument hinzu, das dann in Solr indiziert wird, und eine Abfragezeit für intelligente Antworten.

Was passiert, ist, dass wir erneut zum Modell gehen müssen, um die Abfrage zu kodieren und zu clustern. Dies geschieht über einen GRPC an den ML-Dienst, der mit dem Seldon-Kerneinsatz kommuniziert.

Sobald wir diese Informationen haben, holen wir uns potenzielle Kandidaten aus Solr, das uns eine Liste von Dokumenten liefert, die alle komprimierte Kandidatenvektoren haben, die in der Indizierungsphase gespeichert wurden.

Wir müssen diese Kandidatenvektoren dekomprimieren. Wir berechnen die Vektorähnlichkeit zwischen diesen Kandidaten und unserer eingehenden Anfrage. Schließlich fassen wir die Werte der Vektorähnlichkeit und die Verkäuferwerte zusammen und führen eine neue Rangfolge durch, die wir dann an den Rest der Pipeline weitergeben.

Für Empfehlungsgeber ist es ein bisschen einfacher. Wir holen einfach andere Artikel-IDs nach Artikel-ID aus Solr. Für jeden dieser Artikel gehen wir dann zu Solr und holen uns die Informationen für diese Artikel aus Solr. Auch diese Informationen geben wir an die Pipeline weiter.

Dieser Ansatz funktioniert zwar, aber er bringt einige erhebliche Herausforderungen mit sich, die wir mit unseren aktuellen Versionen von Fusion zu überwinden versuchen mussten. Die meisten unserer Probleme rühren daher, dass Solr selbst keine native Unterstützung für die Suche mit dichten Faktoren bietet. Das bedeutet, dass wir in den letzten Versionen von Fusion im Wesentlichen unseren eigenen Ansatz entwickelt haben.

Wir haben diese komprimierten Vektoren, dekomprimieren sie und führen dann alle Berechnungen der Ähnlichkeitsdistanz durch, aber wir machen das alles innerhalb des Fusion Query Microservice. Alles geschieht in Java. Alles ist völlig unbeschleunigt. Wie Sie sich vorstellen können, bedeutet das, dass es ein wenig langsam ist.

Für uns besteht das Problem darin, dass wir die Anzahl der Kandidaten, die wir aus Solr abrufen, begrenzen müssen, wenn wir eine vernünftige Abfragezeit erreichen wollen. Die potenzielle Übereinstimmung, die Sie erhalten, wird etwas begrenzt sein. Es ist schwierig für uns, Dinge wie unsere sprachübergreifende Unterstützung zu verbessern oder sogar neue Funktionen wie die Bildersuche mit diesem Ansatz hinzuzufügen, da wir sehr viel von Grund auf neu schreiben müssen. Es ist ziemlich langsam, wenn wir soweit sind.

Wir haben beschlossen, in den kommenden Versionen von Fusion einen anderen Ansatz zu wählen. Das bedeutet, dass wir unserem Fusion-Stack einen neuen Teil hinzufügen werden, nämlich Milvus. Dabei handelt es sich um ein Open-Source-Produkt mit Apache-Lizenz. Es ist Teil des Linux Foundations LF AI-Projekts, das prominente Open-Source-Anwendungen und -Lösungen im Bereich der künstlichen Intelligenz und des Deep Learning fördern und entwickeln soll. Milvus selbst ist ein hoch skalierbares GPU-fähiges, dichtes Vektorsuchsystem. Hinter den Kulissen verwendet es leistungsfähige Vektorsuchbibliotheken wie FAISS und NMSLib von Facebook und Annoy. Es wird standardmäßig mit Java, Python, Go, C++ und REST-APIs ausgeliefert. Die programmatische Integration mit Fusion war ziemlich einfach. Außerdem wurde es mit Blick auf Kubernetes entwickelt.

Die Integration einer sehr einfachen Milvus-Installation in Fusion erfordert im Grunde nur eine Zeile von Helm. Eine stabilere Einrichtung erfordert etwas mehr, aber die Integration in unsere aktuellen Helm-Charts ist ziemlich einfach. Außerdem wird es mit einer Box mit Integrationen und Dingen wie Prometheus und Grafana geliefert.

Wir werden uns in die bestehende Kubernetes-Infrastruktur der meisten Leute einfügen. Hier sehen Sie eine Folie mit den Interna von Milvus.

Sehr, sehr gute Übersicht. Wie Sie auf der linken Seite sehen können, können wir entweder Objekte einfügen oder eine Abfrage durchführen und erhalten dann ein Top-K-Ergebnis von der API zurück. Wenn Sie sich die Verarbeitungs-Engine ansehen, sehen Sie, dass Sie, wie ich bereits auf der vorherigen Folie sagte, FAISS oder Annoy oder andere Bibliotheken für die Verarbeitung verwenden können. Das hängt davon ab, welchen Index-Typ Sie in Milvus einrichten. Die Metadaten für die Vektoren werden in einer MySQL-Datenbank gespeichert, obwohl die Vektoren selbst aus Leistungsgründen in massiven Indexdateien in diesem Speicher gespeichert werden.

Es heißt, es läuft auf verschiedenen Prozessen. Ich bin da etwas skeptisch, denn auf der Hauptwebseite von Milvus steht, dass es nur auf x86 läuft, aber das Wichtigste für unsere Zwecke ist, dass es auf Intel-Hardware und mit GPU-Beschleunigung läuft, das ist großartig für uns. Von Haus aus unterstützt es Dinge wie Euklidische Distanz, Jaccard-Distanz, Hamming-Distanz und das innere Produkt für Ähnlichkeitsberechnungen. Es kann mit einer Skala von etwa einer Milliarde Vektoren arbeiten, was viel besser ist als die 500 Kandidaten, die wir in unserer aktuellen Implementierung von Solr zurückbekommen.

Eine weitere sehr nützliche Funktion, die wir in weiteren Versionen von Fusion nutzen werden, ist die Möglichkeit, das Programm nahezu in Echtzeit zu nutzen. Es gibt keine festen Garantien, aber es soll sicherstellen, dass Sie innerhalb einer Sekunde nach dem Einfügen eines neuen Vektors in Milvus dessen Oberfläche in Abfragen sehen können.

Das ist sehr nützlich.

Wie wirkt sich das alles auf Fusion in der Zukunft aus? Auf der nächsten Folie sehen wir den zukünftigen Fusion 5 Stack. Auf der linken Seite haben wir wieder Solr, denn Milvus hat sich etwa in der Mitte zu unserem Stack gesellt. Unsere Empfehlungsprogramme haben sich leicht verändert, so dass sie jetzt online laufen können. Wie bisher können sie aus Solr lesen und Operationen mit Southern Collections durchführen.

Allerdings werden wir in Fusion 5.3 auch Unterstützung für Cloud-Speicher, Lesen und Schreiben hinzufügen. Sie werden in der Lage sein, Solr aus dem größten Teil der Schleife herauszunehmen. Aber wie auch immer, für die Empfehlungsgeber können Sie sehen, dass sie die GRPC-Kommunikation verwenden, um die Ausgabe diesmal in Milvus zu schreiben, anstatt in eine bestimmte Solr-Sammlung oder in den Cloud-Speicher zurückzuschreiben.

Bei den intelligenten Antworten hat sich die Geschichte nicht sehr verändert. Die Daten stammen entweder aus den Solr-Sammlungen oder aus dem Cloud-Speicher. Das Modell wird auf diesen Daten trainiert und dann über Southern, das den ML-Dienst aufruft, bereitgestellt. Über die Indexabfrage-Pipeline.

Aber die Dinge haben sich ein wenig geändert. Für die Indizierung intelligenter Antworten. Alles, was wir jetzt tun, ist, dass wir bei der Indizierung eines neuen Dokuments die Modellkodierung dieses Dokuments erhalten. Dann schreiben wir das in Milvus. Zur Abfragezeit kodieren wir die eingehende Abfrage und fragen dann Milvus selbst nach relevanten Dokument-IDs ab. Wir verwenden diese Dokument-IDs, um in Solr nachzuschauen und sie an den Rest der Pipeline weiterzugeben.

Wie Sie an dieser Stelle sehen können, beziehen wir die Kandidaten nicht mehr aus Solr. Wir fragen jetzt den gesamten Einbettungsraum ab, was hoffentlich unsere Qualität verbessert. Bei den Empfehlungsgebern verhält es sich ähnlich wie zuvor, nur dass wir die IDs ähnlicher Artikel nicht mehr von Solr, sondern von Milvus erhalten. Von jeder Artikel-ID suchen wir dann in Solr nach anderen Metadaten, die wiederum in der Pipeline weitergegeben werden.

Dann haben wir schließlich unsere Ensemble-Abfrage, bei der wir die Ergebnisse von Solr und Milvus zusammenführen können. Auch diese Abfrage kann auf der Bühne konfiguriert werden. Wir ordnen die Ergebnisse dann einfach nach dem Endergebnis.

So wird es auch in Zukunft aussehen. Ich übergebe jetzt an Sava. Er wird Ihnen kurz demonstrieren, wie das in Fusion 5.3 und darüber hinaus aussehen könnte.

Sava: Vielen Dank, Ian. Hallo zusammen, mein Name ist Sava.

Lassen Sie mich Ihnen ein paar neue coole Beispiele zeigen, die wir jetzt mit Smart Answers und der Milvus-Integration unterstützen können.
Beginnen wir mit eCommerce. E-Commerce unterscheidet sich stark von der Beantwortung von Fragen oder der Dokumentensuche: E-Commerce-Anfragen sind normalerweise sehr kurz. Es gibt unzählige Möglichkeiten, die gleichen Dinge zu beschreiben. Außerdem sind sie sehr verrauscht. Es kann tonnenweise Rechtschreibfehler und ähnliche Probleme geben. Ein weiteres großes Problem, mit dem der E-Commerce zu kämpfen hat, sind Suchanfragen mit null Ergebnissen. In der Regel sind etwa 5-10% aller Suchanfragen Null-Suchergebnisse. In einigen Fällen kann diese Zahl sogar auf bis zu 40% ansteigen.

Traditionell müssen Merchandiser tonnenweise Regeln für falsch geschriebene Wörter, Synonyme, unterschiedliche Formulierungen und so weiter manuell erstellen.

Hier durchsuchen wir zum Beispiel die Produktsammlung von Best Buy. Auf der rechten Seite des Bildschirms sehen Sie die Ergebnisse der Sematic-Suchpipeline, auf der linken Seite die Ergebnisse der Standard-Solr-Pipelines. Es handelt sich im Grunde nur um zwei klassische Token-Matching-Speicher. Wir suchen nach der Abfrage „60TV“. Wie Sie sehen können, kann Solr hier nichts zurückgeben, weil es keine Token-Überschneidung gibt.

Wenn die Sematic-Suchpipeline die Bedeutung der Abfrage verstehen kann und verschiedene Produkte zurückgibt, dann geht es bei dieser Website um Fernsehen, aber Sie werden vielleicht denken, na ja, 60TV, das ist sehr einfach, die Abfrage zu korrigieren.

Sie müssen es nur tokenisieren und Leerzeichen hinzufügen, richtig?
Und das ist auch gut so.

Versuchen wir eine weitere Abfrage und ja, dieses Mal ist Solr tatsächlich in der Lage, etwas zurückzugeben, aber es ist nicht genau das, wonach wir gesucht haben. Im Grunde gibt es einige TV-Ständer zurück. Aber nun ja, wir haben noch keinen Fernseher. Wir suchen eigentlich danach.

Lassen Sie uns ein anderes Beispiel versuchen. Wenn ich z.B. nach einem MacBook suche und es einfach mit diesem Leerzeichen eingebe, würde Solr eine Menge verschiedener Ergebnisse liefern. Das hat nichts mit MacBook Pro Laptops zu tun, während die Sematic Suchpipeline dies als Suchabsicht, Klassifizierung oder ähnliches verstehen würde und sehr relevante Ergebnisse liefern würde.

Aber lassen Sie mich versuchen, die Anfrage zu verfeinern und nur nach Apple Laptops zu fragen.

In diesem Fall gibt Solr etwas Relevanteres zurück, aber es ist immer noch nicht das, wonach wir gesucht haben. Es handelt sich im Grunde um Zubehör wie Laptop-Hüllen, denn Sie können sehen, dass es eine starke Überschneidung von Token gibt, z.B. Apple und Laptop, aber die Symantec-Suchpipeline versteht immer noch die Bedeutung dessen, was der Benutzer sucht, und schlägt relevante Ergebnisse vor.

Wie Sie sehen können, sind die Ergebnisse dieselben wie bei der MacBook-Abfrage, die grundsätzlich andere Token enthält.

Lassen Sie uns nun eine etwas kompliziertere Abfrage versuchen. In diesem Fall suche ich nach einem Battlefield-Spiel und wie viele Gamer wissen, wäre die Abkürzung dafür BF, BF2 zum Beispiel. Solr würde nichts zurückgeben, da es offensichtlich keine Abkürzung im Titel gibt.

Die einzige Möglichkeit, dies zu beheben, wäre die Bereitstellung einer benutzerdefinierten Synonymliste oder etwas Ähnliches. Aber die Sematic-Suchpipeline kann die Bedeutung dieser Abfrage verstehen und liefert Battlefield-Spiele an erster Stelle. Darüber hinaus kann sie sogar sehr ähnliche Produkte wie Call of Duty-Spiele empfehlen, die ein sehr ähnliches Franchise sind.

Wenn wir uns mit der Visualisierung unserer Produktvektoren befassen, können wir feststellen, dass sich viele kleine Cluster bilden. Wenn Sie anfangen, diese Cluster zu untersuchen, wie dieses hier in der Mitte. Wir können sehen, dass es sich um Produkte handelt, die sich alle um ähnliche Dinge drehen, im Grunde um externe Festplatten, sogar von verschiedenen Marken wie Western Digital, CG8 und Toshiba.

Versuchen wir es mit einem anderen Cluster. Dieser ist interessanter, weil er Produkte aus verschiedenen Abteilungen enthält. Trotzdem kann die Vektorisierung erkennen, dass es bei diesen Produkten um ähnliche Dinge geht, z.B. wie man Spanisch lernt.

Dies ist eine Visualisierung von Abfragevektoren. Wie Sie sehen können, enthält dieser Cluster zum Beispiel alle möglichen Abfragen, die ein PlayStation-Umzugsgerät beschreiben, sogar mit verschiedenen Schreibweisen, mit verschiedenen Abkürzungen, mit einigen Schreibfehlern, wie mover statt move.

Schauen wir uns eine andere an, zum Beispiel diese hier. Wie Sie sehen können, beschreibt diese kleine Gruppe alle Laptops, die das Dr. Dre Beats Audio System unterstützen. Wie Sie sehen können, sind auch solche Suchanfragen wie Dre labtop, das falsch geschrieben ist, und best audio labtops, ebenfalls falsch geschrieben. Dennoch gibt es außer dem falsch geschriebenen Wort keine Überschneidungen.

Dennoch ist es verständlich, dass es bei Dr. Dre Beats um die gleiche Sache geht, aber eCommerce ist nicht der einzige Anwendungsfall, der von dieser Milvus-Integration profitieren kann. Auch klassische Fragen/Antworten oder FAQ können viel davon profitieren.

Hier haben wir zum Beispiel die United Airlines FAQ und suchen nach einer sehr einfachen Abfrage, wie Handgepäckbeschränkungen. Solr gibt jedoch nur drei Dokumente zurück, die mit dieser Abfrage nichts zu tun haben, nur weil es keine Token-Überschneidungen gibt. Aber weil wir nicht mehr brauchen, verlassen wir uns nicht mehr auf Solr, um Kandidaten für die Auswahl zu erhalten, wir können direkt in diesem Vektorraum suchen und sehr relevante Ergebnisse finden, sogar mit anderem Wortlaut.

Wie Sie sehen, wird in den FAQ „carry on“ statt „hand“, „baggage“ statt „luggage“ und „limits“ statt „restrictions“ verwendet. Noch interessanter wird es, wenn wir in einer anderen Sprache suchen, zum Beispiel auf Japanisch. Wir haben hier gerade nach einer sehr ähnlichen Sache gesucht. Natürlich würde Solr nichts zurückgeben, weil es in unserer Sammlung keine japanischen Inhalte gibt. Das ist richtig, aber die Modelle, die wir hier verwenden, wurden gemeinsam für verschiedene Sprachen trainiert.

Es kann mit Interaktionen zwischen Sprachen umgehen, so dass eine Übersetzung erforderlich ist, und liefert dennoch sehr nützliche und relevante Ergebnisse.

Ich denke, das war’s von uns. Vielen Dank, dass Sie heute an unserem Vortrag teilgenommen haben.