Pipelines für maschinelles Lernen für die Suche: Lernen zu ranken

Werfen wir einen Blick darauf, wie unsere Services die notwendigen Schritte für unsere Beurteilungspipeline handhaben. Wir orchestrieren die Schritte über Dark Knight, einen AWS Step Functions-Workflow:

1. Der erste Schritt besteht darin, die relevanten Informationen aus dem Clickstream zu extrahieren, der in diese Pipeline gelangt. Mit emo können wir einen Zeitrahmen angeben, und der Service gibt dann alle Abfrage-/Produkt-/Positions-Tupel mit den entsprechenden Ansichts-, Klick- und A4L-Informationen (In den Warenkorb oder auf die Wunschliste) aus.
2. Basierend auf diesen Informationen und unserer aktuellen Bewertungsformel berechnet judge-dredd einen Bewertungswert pro Abfrage/Produkt/Positionstupel.
3. Solrizer erstellt dann eine XML-Datei mit Produktrankings, die auf unseren Bewertungsergebnissen pro Abfrage basieren. Wir können die Abfragen über Stichproben auswählen, um zu kontrollieren, wie viel Verkehr die Bewertungen während eines Experiments erhalten.
4. Schließlich veröffentlicht solrizer-upload diese Rankings in Solr, so dass wir unsere Rankings mit echtem Kundenfeedback validieren können.

Im Folgenden erhalten Sie einen tieferen Einblick in die Technologie, die unsere Dienste und die Pipeline nutzen.

Die meisten Entwickler in unserem Team kommen mit Python gut zurecht, daher haben wir Python als Hauptsprache gewählt. Wenn wir eine große Datenmenge umwandeln müssen, verwenden wir Pyspark. Wir glauben fest an den Infrastructure-as-Code-Ansatz zum Aufbau einer nachhaltigen und wartbaren Cloud-Infrastruktur. Der größte Teil unserer Infrastruktur wird über Terraform bereitgestellt, für kompliziertere Orchestrationen verwenden wir AWS Step Functions.

Im Allgemeinen handelt es sich bei unseren Services um AWS Sagemaker Processing Jobs, die auf einem Elastic Map Reduce (EMR)-Cluster laufen. Dadurch können wir die Verarbeitungszeiten und -kosten kontrollieren, indem wir die Größe des Clusters je nach Bedarf einfach nach oben oder unten skalieren.

Zur Orchestrierung unserer Services haben wir mit dem AWS Step Functions Data Science SDK einen Workflow-Graphen in Python erstellt. Dadurch können wir jeden Parameter eines beliebigen Dienstes ändern, indem wir einfach eine json-Datei bearbeiten und diese Änderungen hochladen, ohne die gesamte Pipeline neu bereitstellen zu müssen.

Let’s take a look at a JSON snippet which configures the solrizer step in our pipeline:

Das Codeschnipsel beschreibt alle notwendigen Parameter für den Solrizer-Schritt in unserem Workflow. Das JSON besteht aus 4 Feldern: job_name, input, runtime und output. Der job_name wird programmatisch auf die ID des gesamten Workflows gesetzt, damit wir die einzelnen Schritte in der AWS-Konsole leichter überprüfen können.

Im Eingabefeld legen wir alle erforderlichen Datenquellen fest, die dieser Schritt benötigt. Beachten Sie, dass der Beurteilungspfad kontextsensitiv ist, so dass dieser Schritt automatisch die richtigen Daten für diese Workflow-ID und Version abruft.

Über die zur Laufzeit eingestellten Parameter können wir einzelne Schritte einfach ein- oder ausschalten, Feature-Toggles setzen oder die Instanzgröße für den entsprechenden Schritt ändern. Der image_uri-Wert beschreibt, welche Version des Docker-Images verwendet werden soll, so dass wir schnell verschiedene Versionen unseres Codes für diesen Schritt auswählen können.

Das Feld output teilt dem "Schritt" mit, wo die Informationen über den Lauf protokolliert werden sollen und wo die resultierenden Daten zu speichern sind. Wir machen regelmäßig Gebrauch davon, indem wir Ad-hoc-Analysen der Ausgabe von Schritten in unseren Pipelines durchführen. Es ermöglicht uns auch, nur Teile der Pipeline erneut auszuführen und dabei Daten zu verwenden, die von verschiedenen Läufen stammen.

Normalerweise ist dieser Ausgabepfad dann der Eingabepfad für den nächsten Schritt im Arbeitsablauf.

Die vollständige Konfiguration für einen Dark Knight-Lauf besteht dann aus einer Kette von Konfigurationen wie der obigen. Sobald eine beendet ist, wird die nächste ausgelöst und so weiter.
Das ist im Grunde alles 😉

Mit diesen Konzepten haben wir eine Datenpipeline aufgebaut, die skalierbar, flexibel und robust ist. Wir sind sehr zufrieden mit dem Ergebnis 😊.

Wir haben viel über die Funktionen gelernt, die bestimmte AWS-Dienste bieten können, und darüber, welche anderen Dienste es gibt. Seit dem Aufbau dieser Pipeline haben wir viel Erfahrung mit dieser Art von Infrastruktur gesammelt und hatten bisher keine größeren Probleme.

Dennoch war es nicht immer so einfach, wie es hätte sein können. Auch AWS-Dienste haben ihre Grenzen. Einige sind relativ neu oder befinden sich noch in der Entwicklung. Alle Probleme, mit denen wir konfrontiert wurden, konnten jedoch recht schnell gelöst werden; entweder dank unseres sehr guten Supports, dank der gründlichen Dokumentation oder durch Durchsicht des Codes selbst.

Wie geht es weiter?

Ein großer nächster Schritt wird sein, unsere gesamte LTR-Pipeline live zu schalten. Wir freuen uns darauf, alles, was wir bei der Entwicklung der Judgement-Pipeline gelernt haben, in unsere erste Pipeline für maschinelles Lernen einfließen zu lassen. Sie sollte genauso skalierbar und flexibel sein wie unsere Datenverarbeitungspipeline.

Wenn diese Themen für dich interessant klingen und/oder du Erfahrung im Aufbau von ML-Pipelines hast, würden wir uns gerne mit dir austauschen oder dich in unserem Team willkommen heißen -> kontaktiere uns einfach unter JARVISttd