Implementierung der Zwei-Turm-Suche für die groß angelegte Kandidatengenerierung

Last reviewed 2025-01-16 UTC

Dieses Dokument enthält eine Referenzarchitektur, die zeigt, wie Sie einen End-to-End-Workflow zur Kandidatengenerierung mit zwei Towern mit Vertex AI implementieren. Das Modellierungs-Framework mit zwei Towern ist eine leistungsstarke Abrufmethode für Personalisierungsanwendungsfälle, da es die semantische Ähnlichkeit zwischen zwei verschiedenen Entitäten wie Webabfragen und Kandidatenelementen erlernt.

Dieses Dokument richtet sich an technische Experten wie Data Scientists und ML-Entwickler, die Empfehlungsanwendungen im großen Maßstab mit geringen Latenzanforderungen entwickeln. Weitere Informationen zu den Modellierung techniken, zur Problemformulierung und zur Datenvorbereitung für die Erstellung eines Modells mit zwei Towern finden Sie unter Deep Retrieval mit TensorFlow Recommenders und der Vektorsuche skalieren.

Architektur

Das folgende Diagramm zeigt eine Architektur zum Trainieren eines Modells mit zwei Towern und zum separaten Bereitstellen der einzelnen Tower für verschiedene Bereitstellungs- und Bereitstellungsaufgaben:

Die Architektur im Diagramm umfasst folgende Komponenten:

• Trainingsdaten: Trainingsdateien werden in Cloud Storage gespeichert.
• Training mit zwei Towern: Das kombinierte Modell mit zwei Towern wird offline mit dem Vertex AI Training-Dienst trainiert. Jeder Tower wird separat gespeichert und für verschiedene Aufgaben verwendet.
• Registrierte Abfrage- und Kandidaten-Tower: Nachdem die Tower trainiert wurden, wird jeder Tower separat in die Vertex AI Model Registry hochgeladen.
• Bereitgestellter Abfrage-Tower: Der registrierte Abfrage-Tower wird auf einem Vertex AI-Onlineendpunkt bereitgestellt.
• Batch-Vorhersage von Einbettungen: Der registrierte Kandidaten-Tower wird in einem Batch-Vorhersagejob verwendet, um die Einbettungsdarstellungen aller verfügbaren Kandidatenelemente vorzuberechnen.
• JSON-Datei mit Einbettungen: Die vorhergesagten Einbettungen werden in einer JSON Datei in Cloud Storage gespeichert.
• ANN-Index: Die Vektorsuche in Vertex AI wird verwendet, um einen Bereitstellungsindex zu erstellen, der für die Suche nach ungefähren nächsten Nachbarn (Approximate Nearest Neighbor, ANN) konfiguriert ist.
• Bereitgestellter Index: Der ANN-Index wird auf einem Indexendpunkt der Vektorsuche in Vertex AI bereitgestellt.

Verwendete Produkte

In dieser Referenzarchitektur werden die folgenden Google Cloud Produkte verwendet:

• Vertex AI Training: Ein vollständig verwalteter Trainingsdienst, mit dem Sie umfangreiches Modelltraining operationalisieren können.
• Vektorsuche: Ein Dienst für den Abgleich von Vektorähnlichkeiten, mit dem Sie semantisch ähnliche oder verwandte Daten speichern, indexieren und durchsuchen können.
• Vertex AI Model Registry: Ein zentrales Repository, in dem Sie den Lebenszyklus Ihrer ML-Modelle verwalten können.
• Cloud Storage: Ein kostengünstiger, unbegrenzter Objektspeicher für verschiedene Datentypen. Auf Daten kann von innerhalb und außerhalb von Google Cloud zugegriffen werden Google Cloud. Sie werden zu Redundanzzwecken über Standorte hinweg repliziert.

Anwendungsfall

Um die Anforderungen an die Bereitstellung mit geringer Latenz zu erfüllen, werden Empfehlungssysteme im großen Maßstab häufig als zweistufige oder manchmal auch als mehrstufige Systeme in der Produktion bereitgestellt. Ziel der ersten Stufe, der Kandidatengenerierung, ist es, eine große Sammlung von Kandidatenelementen zu durchsuchen und eine relevante Teilmenge von Hunderten von Elementen für nachgelagerte Filter- und Rankingaufgaben abzurufen. Um diese Abrufaufgabe zu optimieren, sollten Sie die folgenden beiden Hauptziele berücksichtigen:

1. Beim Modelltraining die beste Darstellung des zu lösenden Problems oder der zu lösenden Aufgabe erlernen und diese Darstellung in <query, candidate> Einbettungen zusammenfassen.
2. Beim Bereitstellen des Modells relevante Elemente schnell genug abrufen, um die Latenzanforderungen zu erfüllen.

Das folgende Diagramm zeigt die konzeptionellen Komponenten eines zweistufigen Empfehlungssystems:

Im Diagramm werden bei der Kandidatengenerierung Millionen von Kandidatenelementen gefiltert. Beim Ranking werden dann die resultierenden Hunderte von Kandidatenelementen gefiltert, um Dutzende von empfohlenen Elementen zurückzugeben.

In der Referenzarchitektur in diesem Dokument wird ein auf zwei Towern basierendes Abrufmodell trainiert. In der Architektur ist jeder Tower ein neuronales Netzwerk, das entweder Abfrage- oder Kandidatenelement-Features verarbeitet und dann eine Einbettungsdarstellung dieser Features erzeugt. Jeder Tower wird separat bereitgestellt, da jeder Tower in der Produktion für verschiedene Aufgaben verwendet wird:

• Kandidaten-Tower: Der Kandidaten-Tower wird verwendet, um Einbettungen für alle Kandidatenelemente vorzuberechnen. Die vorab berechneten Einbettungen werden auf einem Indexendpunkt der Vektorsuche in Vertex AI bereitgestellt, der für den Abruf mit geringer Latenz optimiert ist.
• Bereitgestellter Tower: Bei der Onlinebereitstellung konvertiert der bereitgestellte Abfrage-Tower Rohabfragen von Nutzern in Einbettungsdarstellungen. Die Einbettungsdarstellungen werden dann verwendet, um ähnliche Elementeinbettungen im bereitgestellten Index zu suchen.

Architekturen mit zwei Towern eignen sich ideal für viele Abrufaufgaben, da sie die semantische Beziehung zwischen Abfrage- und Kandidatenentitäten erfassen und sie einem gemeinsamen Einbettungsraum zuordnen. Wenn die Entitäten einem gemeinsamen Einbettungsraum zugeordnet werden, werden semantisch ähnliche Entitäten näher zusammen gruppiert. Wenn Sie also die Vektoreinbettungen einer bestimmten Abfrage berechnen, können Sie im Einbettungsraum nach den nächsten (ähnlichsten) Kandidatenelementen suchen. Der Hauptvorteil einer solchen Architektur ist die Möglichkeit, die Inferenz von Abfrage- und Kandidatendarstellungen zu entkoppeln. Diese Entkopplung bietet hauptsächlich zwei Vorteile:

• Sie können neue Elemente bereitstellen, ohne ein neues Elementvokabular trainieren zu müssen. Wenn Sie dem Kandidatenelement-Tower eine beliebige Menge von Element-Features zuführen, können Sie die Einbettungen für eine beliebige Menge von Kandidaten berechnen, auch für solche, die während des Trainings nicht gesehen wurden. Diese Berechnung hilft, das Kaltstartproblem zu lösen.
  • Der Kandidaten-Tower kann eine beliebige Menge von Kandidatenelementen unterstützen, einschließlich Elementen, mit denen das Empfehlungssystem noch nicht interagiert hat. Diese Unterstützung ist möglich, da Architekturen mit zwei Towern umfangreiche Inhalts- und Metadaten-Features für jedes <query, candidate> Paar verarbeiten. Durch diese Art der Verarbeitung kann das System ein unbekanntes Element anhand von Elementen beschreiben, die es kennt.
• Sie können die Abrufinferenz optimieren, indem Sie alle Einbettungen von Kandidatenelementen vorab berechnen. Diese vorab berechneten Einbettungen können indexiert und in einer Bereitstellungsinfrastruktur bereitgestellt werden, die für den Abruf mit geringer Latenz optimiert ist.
  • Durch das gemeinsame Lernen der Tower können Sie Elemente anhand von Abfragen und umgekehrt beschreiben. Wenn Sie eine Hälfte eines Paares haben, z. B. eine Abfrage, und nach dem anderen entsprechenden Element suchen müssen, können Sie die Hälfte der Gleichung vorab berechnen. Durch die Vorabberechnung können Sie den Rest der Entscheidung so schnell wie möglich treffen.

Designaspekte

Dieser Abschnitt enthält eine Anleitung zum Entwickeln einer Architektur zur Kandidatengenerierung in Google Cloud , die Ihre Sicherheits- und Leistungs anforderungen erfüllt. Die Anleitung in diesem Abschnitt ist nicht vollständig. Je nach Ihren spezifischen Anforderungen müssen Sie möglicherweise zusätzliche Designfaktoren und Vor- und Nachteile berücksichtigen.

Sicherheit

Die Vektorsuche in Vertex AI unterstützt sowohl öffentliche als auch VPC-Endpunktbereitstellungen (Virtual Private Cloud). Wenn Sie ein VPC Netzwerk verwenden möchten, folgen Sie der Anleitung unter VPC-Netzwerk-Peering einrichten. Wenn der Vektorsuche-Index innerhalb eines VPC-Perimeters bereitgestellt wird, müssen Nutzer über dasselbe VPC-Netzwerk auf die zugehörigen Ressourcen zugreifen. Wenn Sie beispielsweise in Vertex AI Workbench entwickeln, müssen Sie die Workbench-Instanz im selben VPC-Netzwerk wie der bereitgestellte Indexendpunkt erstellen. Ebenso sollte jede Pipeline, die einen Endpunkt erstellen oder einen Index auf einem Endpunkt bereitstellen soll, im selben VPC-Netzwerk ausgeführt werden.

Leistungsoptimierung

In diesem Abschnitt werden die Faktoren beschrieben, die Sie berücksichtigen sollten, wenn Sie diese Referenz architektur zum Entwerfen einer Topologie in Google Cloud verwenden, die die Leistungsanforderungen Ihrer Arbeitslasten erfüllt.

Trainingjobs profilieren

Um Daten-Input-Pipelines und den gesamten Trainingsgraphen zu optimieren, empfehlen wir , die Trainingsleistung mit Cloud Profiler zu profilieren. Profiler ist eine verwaltete Implementierung des Open-Source TensorBoard Profiler.

Wenn Sie das Argument –profiler im Trainingsjob übergeben, wird der TensorFlow-Callback aktiviert, um eine bestimmte Anzahl von Batches für jede Epoche zu profilieren. Das Profil erfasst Traces von der Host-CPU und von der GPU- oder TPU-Hardware des Geräts. Die Traces enthalten Informationen zum Ressourcenverbrauch des Trainingsjobs. Um Fehler aufgrund von zu wenig Arbeitsspeicher zu vermeiden, empfehlen wir, mit einer Profildauer zwischen 2 und 10 Trainingsschritten zu beginnen und sie nach Bedarf zu erhöhen.

Informationen zur Verwendung von Profiler mit Vertex AI Training und Vertex AI TensorBoard finden Sie unter Leistung des Modelltrainings profilieren. Best Practices für das Debugging finden Sie unter GPU-Leistung optimieren. Informationen zum Optimieren der Leistung finden Sie unter TensorFlow-Leistung mit dem Profiler optimieren.

Beschleuniger vollständig nutzen

Wenn Sie Trainingsbeschleuniger wie NVIDIA-GPUs oder Cloud TPUs anhängen, ist es wichtig, dass sie vollständig genutzt werden. Die vollständige Nutzung von Trainingsbeschleunigern ist eine Best Practice für die Kostenverwaltung, da Beschleuniger die teuerste Komponente in der Architektur sind. Die vollständige Nutzung von Trainingsbeschleunigern ist auch eine Best Practice für die Jobeffizienz, da keine Leerlaufzeiten zu einem geringeren Gesamtresourcenverbrauch führen.

Um einen Beschleuniger vollständig zu nutzen, führen Sie in der Regel einige Iterationen durch, um den Engpass zu finden, den Engpass zu optimieren und diese Schritte dann zu wiederholen, bis die Nutzung des Beschleunigergeräts akzeptabel ist. Da viele der Datensätze für diesen Anwendungsfall zu groß sind, um in den Arbeitsspeicher zu passen, treten Engpässe in der Regel zwischen dem Speicher, den Host-VMs und dem Beschleuniger auf.

Das folgende Diagramm zeigt die konzeptionellen Phasen einer ML-Trainings-Input-Pipeline:

Im Diagramm werden Daten aus dem Speicher gelesen und vorverarbeitet. Nach der Vorverarbeitung werden die Daten an das Gerät gesendet. Um die Leistung zu optimieren, ermitteln Sie zuerst, ob die Gesamtleistung durch die Host-CPU oder durch das Beschleunigergerät (GPU oder TPU) begrenzt wird. Das Gerät ist für die Beschleunigung der Trainingsschleife verantwortlich, während der Host Trainingsdaten an das Gerät sendet und Ergebnisse vom Gerät empfängt. In den folgenden Abschnitten wird beschrieben, wie Sie Engpässe beheben, indem Sie die Leistung der Input-Pipeline und die Geräteleistung verbessern.

Leistung der Input-Pipeline verbessern

• Daten aus dem Speicher lesen: Um das Lesen von Daten zu verbessern, versuchen Sie es mit Caching, prefetching, sequenziellen Zugriffsmustern, und paralleler E/A.
• Daten vorverarbeiten: Um die Datenvorverarbeitung zu verbessern, konfigurieren Sie die parallele Verarbeitung für die Datenextraktion und -transformation und optimieren Sie die interleave Transformation in der Daten-Input-Pipeline.
• Daten an das Gerät senden: Um die Gesamtzeit des Jobs zu verkürzen, übertragen Sie Daten parallel vom Host an mehrere Geräte.

Geräteleistung verbessern

• Minibatchgröße erhöhen. Minibatches sind die Anzahl der Trainingsbeispiele, die von jedem Gerät in einer Iteration einer Trainingsschleife verwendet werden. Durch Erhöhen der Minibatchgröße erhöhen Sie die Parallelität zwischen Vorgängen und verbessern die Wiederverwendung von Daten. Der Minibatch muss jedoch mit dem Rest des Trainingsprogramms in den Arbeitsspeicher passen. Wenn Sie die Minibatchgröße zu stark erhöhen, können Fehler aufgrund von zu wenig Arbeitsspeicher und eine Modeldivergenz auftreten.
• Benutzerdefinierte Funktionen vektorisieren. In der Regel können Datentransformationen als benutzerdefinierte Funktion ausgedrückt werden, die beschreibt, wie jedes Element eines Eingabedatasets transformiert werden soll. Um diese Funktion zu vektorisieren, wenden Sie die Transformationsoperation gleichzeitig auf einen Batch von Eingaben an, anstatt jeweils ein Element zu transformieren. Jede benutzerdefinierte Funktion verursacht Overhead im Zusammenhang mit der Planung und Ausführung. Wenn Sie einen Batch von Eingaben transformieren, fällt der Overhead nur einmal pro Batch an, anstatt einmal pro Dataset-Element.

Hochskalierung vor der horizontalen Skalierung

Wenn Sie die Rechenressourcen für Ihre Trainingsjobs konfigurieren, empfehlen wir, zuerst hochzuskalieren und dann horizontal zu skalieren. Das bedeutet, dass Sie ein größeres, leistungsstärkeres Gerät auswählen sollten, bevor Sie mehrere weniger leistungsstarke Geräte verwenden. Wir empfehlen, so zu skalieren:

1. Ein Worker + ein Gerät
2. Ein Worker + leistungsstärkeres Gerät
3. Ein Worker + mehrere Geräte
4. Verteiltes Training

Recall im Vergleich zur Latenz für die ANN-Vektorsuche auswerten

Um die Vorteile der ANN-Suche zu bewerten, können Sie die Latenz und den Recall einer bestimmten Abfrage messen. Zur Optimierung des Index können Sie mit der Vektorsuche in Vertex AI einen Brute-Force-Index erstellen. Brute-Force-Indexe führen eine umfassende Suche durch, was zu einer höheren Latenz führt, um die tatsächlichen nächsten Nachbarn für einen bestimmten Abfragevektor zu finden. Die Verwendung von Brute-Force-Indexen ist nicht für die Produktion vorgesehen, bietet aber eine gute Baseline, wenn Sie den Recall während der Indexoptimierung berechnen.

Um den Recall im Vergleich zur Latenz zu bewerten, stellen Sie die vorab berechneten Kandidateneinbettungen in einem Index bereit, der für die ANN-Suche konfiguriert ist, und in einem anderen Index, der für die Brute-Force-Suche konfiguriert ist. Der Brute-Force-Index gibt die absolut nächsten Nachbarn zurück, dauert aber in der Regel länger als eine ANN-Suche. Möglicherweise sind Sie bereit, einen Teil des Abruf-Recalls für eine geringere Abruflatenz zu opfern, aber dieser Kompromiss sollte bewertet werden. Weitere Merkmale, die sich auf Recall und Latenz auswirken, sind:

• Modellierungsparameter: Viele Modellierungsentscheidungen wirken sich auf den Einbettungsraum aus, der letztendlich zum Bereitstellungsindex wird. Vergleichen Sie die Kandidaten, die für Indexe abgerufen werden, die sowohl aus flachen als auch aus tiefen Abrufmodellen erstellt wurden.
• Dimensionen: Dimensionen sind ein weiterer Aspekt, der letztendlich durch das Modell bestimmt wird. Die Dimensionen des ANN-Index müssen mit den Dimensionen der Vektoren des Abfrage- und Kandidaten-Towers übereinstimmen.
• Tags für Crowding und Filterung: Mit Tags lassen sich Ergebnisse für verschiedene Produktionsanwendungsfälle anpassen. Es ist eine Best Practice, zu verstehen, wie sich Tags auf die abgerufenen Kandidaten und die Leistung auswirken.
• ANN-Anzahl: Durch Erhöhen dieses Werts wird der Recall erhöht und die Latenz kann proportional steigen.
• Prozentsatz der zu durchsuchenden Blattknoten: Der Prozentsatz der zu durchsuchenden Blattknoten ist die wichtigste Option, um den Kompromiss zwischen Recall und Latenz zu bewerten. Durch Erhöhen dieses Werts wird der Recall erhöht und die Latenz kann proportional steigen.

Nächste Schritte

Weitere Referenzarchitekturen, Diagramme und Best Practices finden Sie im Cloud-Architekturcenter.

Beitragende

Autoren:

• Jordan Totten | Customer Engineer
• Jeremy Wortz | Customer Engineer
• Lakshmanan Sethu | Technical Account Manager

Weiterer Mitwirkender: Kaz Sato | Staff Developer Advocate