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 für die Kandidatengenerierung mit zwei Towern mit Vertex AI implementieren. Das Two-Tower-Modellierungsframework ist eine leistungsstarke Abruftechnik für Personalisierungsanwendungsfälle, da es die semantische Ähnlichkeit zwischen zwei verschiedenen Entitäten wie Webanfragen und infrage kommenden Elementen lernt.

Dieses Dokument richtet sich an technische Experten wie Data Scientists und ML-Entwickler, die Empfehlungsanwendungen im großen Maßstab mit Anforderungen an die Bereitstellung mit niedriger Latenz entwickeln. Weitere Informationen zu den Modellierungstechniken, der Problemformulierung und der Datenvorbereitung zum Erstellen eines Two-Tower-Modells finden Sie unter Deep Retrieval mit TensorFlow Recommenders und der Vektorsuche skalieren.

Architektur

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

Die Architektur im Diagramm umfasst die folgenden Komponenten:

• Trainingsdaten: Trainingsdateien werden in Cloud Storage gespeichert.
• Two-Tower-Training: Das kombinierte Two-Tower-Modell wird offline mit dem Vertex AI Training-Dienst trainiert. Jeder Tower wird separat gespeichert und für verschiedene Aufgaben verwendet.
• Registrierte Anfrage- und Kandidatentürme: Nachdem die Türme trainiert wurden, wird jeder Turm separat in die Vertex AI Model Registry hochgeladen.
• Bereitgestellter Query-Tower: Der registrierte Query-Tower wird auf einem Vertex AI-Onlineendpunkt bereitgestellt.
• Batchvorhersage von Einbettungen: Der registrierte Kandidatenturm wird in einem Batchvorhersagejob verwendet, um die Einbettungsdarstellungen aller verfügbaren Kandidatenartikel vorab zu berechnen.
• 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 Serving-Index zu erstellen, der für die Suche nach dem ungefähren nächsten Nachbarn (Approximate Nearest Neighbor, ANN) konfiguriert ist.
• Bereitgestellter Index: Der ANN-Index wird für einen 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 Cloudzugegriffen werden. Sie werden zu Redundanzzwecken über Standorte hinweg repliziert.

Anwendungsfall

Um die Anforderungen an das Serving mit niedriger Latenz zu erfüllen, werden Empfehlungssysteme im großen Maßstab häufig als zweistufige Systeme oder manchmal als mehrstufige Systeme in der Produktion bereitgestellt. Das Ziel der ersten Phase, der Kandidatengenerierung, besteht darin, 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 Abrufanfrage zu optimieren, sollten Sie die folgenden beiden Hauptziele berücksichtigen:

1. Beim Modelltraining wird die beste Darstellung des zu lösenden Problems oder der zu lösenden Aufgabe ermittelt und in <query, candidate>-Einbettungen kompiliert.
2. Rufen Sie während der Modellbereitstellung relevante Elemente schnell genug ab, um die Latenzanforderungen zu erfüllen.

Das folgende Diagramm zeigt die konzeptionellen Komponenten eines zweistufigen Empfehlungssystems:

Im Diagramm werden durch die Filter zur Kandidatengenerierung Millionen von Kandidatenelementen herausgefiltert. Beim Ranking werden dann die Hunderten von infrage kommenden Elementen gefiltert, um Dutzende von empfohlenen Elementen zurückzugeben.

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

• Kandidaten-Tower: Mit dem Kandidaten-Tower werden Einbettungen für alle Kandidaten-Elemente vorab berechnet. Die vorab berechneten Einbettungen werden in einem Vertex AI-Vektorsuche-Index-Endpunkt bereitgestellt, der für den Abruf mit niedriger Latenz optimiert ist.
• Bereitgestellter Tower: Bei der Onlinebereitstellung werden mit dem bereitgestellten Abfragetower Rohnutzeranfragen in Einbettungsdarstellungen umgewandelt. Die Einbettungsdarstellungen werden dann verwendet, um ähnliche Artikeleinbettungen im bereitgestellten Index zu suchen.

Zweiturmarchitekturen eignen sich ideal für viele Abrufvorgänge, da sie die semantische Beziehung von Anfrage- und Kandidatenentitäten erfassen und sie einem gemeinsamen Einbettungsraum zuordnen. Wenn die Entitäten einem gemeinsamen Einbettungsbereich zugeordnet werden, werden semantisch ähnliche Entitäten näher zusammen gruppiert. Wenn Sie also die Vektoreinbettungen einer bestimmten Anfrage berechnen, können Sie den Einbettungsraum nach den ähnlichsten Kandidatenelementen durchsuchen. Der Hauptvorteil einer solchen Architektur besteht darin, dass die Inferenz von Abfrage- und Kandidatenrepräsentationen entkoppelt werden kann. Die Vorteile dieser Entkopplung sind hauptsächlich zweifacher Natur:

• Sie können neue (aktuelle) Artikel bereitstellen, ohne ein neues Artikelvokabular zu trainieren. Wenn Sie dem Kandidaten-Item-Tower eine beliebige Gruppe von Item-Features zuführen, können Sie die Item-Einbettungen für eine beliebige Gruppe von Kandidaten berechnen, auch für solche, die während des Trainings nicht berücksichtigt wurden. Diese Berechnung hilft, das Kaltstartproblem zu beheben.
  • Der Kandidaten-Tower kann eine beliebige Anzahl von Kandidaten-Elementen unterstützen, einschließlich Elementen, mit denen das Empfehlungssystem noch nicht interagiert hat. Diese Unterstützung ist möglich, da Two-Tower-Architekturen umfangreiche Inhalts- und Metadatenfunktionen für jedes <query, candidate>-Paar verarbeiten. Bei dieser Art der Verarbeitung kann das System ein unbekanntes Element anhand von Elementen beschreiben, die es kennt.
• Sie können die Retrieval-Inferenz optimieren, indem Sie alle Kandidaten-Item-Einbettungen vorab berechnen. Diese vorab berechneten Einbettungen können indexiert und in einer Bereitstellungsinfrastruktur bereitgestellt werden, die für das Abrufen mit niedriger Latenz optimiert ist.
  • Durch das gemeinsame Lernen der beiden Bereiche können Sie Elemente anhand von Suchanfragen und umgekehrt beschreiben. Wenn Sie eine Hälfte eines Paares haben, z. B. eine Anfrage, und nach dem anderen entsprechenden Element suchen müssen, können Sie die Hälfte der Gleichung vorab berechnen. Durch die Vorberechnung 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 Ihren Sicherheits- und Leistungsanforderungen entspricht. Die Anleitung in diesem Abschnitt ist nicht vollständig. Je nach Ihren spezifischen Anforderungen müssen Sie möglicherweise zusätzliche Designfaktoren und Kompromisse berücksichtigen.

Sicherheit

Vertex AI Vector Search unterstützt sowohl öffentliche als auch Virtual Private Cloud-Endpunktbereitstellungen (VPC). Wenn Sie ein VPC-Netzwerk verwenden möchten, folgen Sie der Anleitung unter VPC-Netzwerk-Peering-Verbindung einrichten. Wenn der Vector Search-Index in einem VPC-Perimeter 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 Index-Endpunkt erstellen. Entsprechend sollten alle Pipelines, mit denen ein Endpunkt erstellt oder ein Index für einen Endpunkt bereitgestellt werden soll, im selben VPC-Netzwerk ausgeführt werden.

Leistungsoptimierung

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

Trainingsjobs profilieren

Zur Optimierung von Daten-Input-Pipelines und des gesamten Trainingsdiagramms empfehlen wir, die Trainingsleistung mit Cloud Profiler zu profilieren. Profiler ist eine verwaltete Implementierung des Open-Source-Tools 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 enthält Traces von der Host-CPU und von der Geräte-GPU oder TPU-Hardware. Die Traces enthalten Informationen zum Ressourcenverbrauch des Trainingsjobs. Um Fehler aufgrund von Speicherplatzmangel zu vermeiden, empfehlen wir, mit einer Profildauer zwischen 2 und 10 Trainingsschritten zu beginnen und diese bei 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 die Fehlerbehebung finden Sie unter GPU-Leistung optimieren. Informationen zur Leistungsoptimierung finden Sie unter TensorFlow-Leistung mit dem Profiler optimieren.

Beschleuniger optimal nutzen

Wenn Sie Trainingsbeschleuniger wie NVIDIA-GPUs oder Cloud-TPUs anhängen, ist es wichtig, dass diese vollständig ausgelastet sind. 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 Gesamtressourcenverbrauch führen.

Damit ein Beschleuniger vollständig genutzt wird, führen Sie in der Regel einige Iterationen durch, in denen Sie den Engpass ermitteln, den Engpass optimieren und diese Schritte dann wiederholen, bis die Auslastung des Beschleunigergeräts akzeptabel ist. Da viele der Datasets für diesen Anwendungsfall zu groß sind, um in den Arbeitsspeicher zu passen, treten Engpässe in der Regel zwischen Speicher, Host-VMs und dem Beschleuniger auf.

Das folgende Diagramm zeigt die konzeptionellen Phasen einer Pipeline für ML-Trainingsdaten:

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, müssen Sie zuerst feststellen, 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 des Trainingszyklus 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 Eingabepipeline und die Geräteleistung verbessern.

Leistung der Eingabepipeline verbessern

• Daten aus dem Speicher lesen: Um das Lesen von Daten zu verbessern, können Sie Caching, prefetching, sequenzielle Zugriffsmuster und parallele E/A verwenden.
• Datenvorverarbeitung: 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 Gesamtdauer des Jobs zu verkürzen, übertragen Sie Daten parallel vom Host auf mehrere Geräte.

Geräteleistung verbessern

• Minibatch-Größe erhöhen: Mini-Batches sind die Anzahl der Trainingsbeispiele, die von jedem Gerät in einer Iteration einer Trainingsschleife verwendet werden. Wenn Sie die Minibatch-Größe erhöhen, steigern Sie die Parallelität zwischen Vorgängen und verbessern die Datenwiederverwendung. Der Mini-Batch muss jedoch zusammen mit dem Rest des Trainingsprogramms in den Arbeitsspeicher passen. Wenn Sie die Minibatch-Größe zu stark erhöhen, kann es zu Fehlern aufgrund von zu wenig Arbeitsspeicher und zu einer Divergenz des Modells kommen.
• 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 auf einen Batch von Eingaben gleichzeitig an, anstatt jeweils ein Element zu transformieren. Jede benutzerdefinierte Funktion hat einen Overhead, der mit der Planung und Ausführung zusammenhängt. Wenn Sie einen Batch von Eingaben transformieren, fällt der Overhead nur einmal pro Batch an, nicht einmal pro Dataset-Element.

Hochskalierung vor der horizontalen Skalierung

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

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

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

Um die Vorteile der ANN-Suche zu bewerten, können Sie die Latenz und den Recall einer bestimmten Anfrage messen. Zur Unterstützung der Indexoptimierung bietet die Vektorsuche in Vertex AI die Möglichkeit, einen Brute-Force-Index zu erstellen. Bei Brute-Force-Indexen wird eine umfassende Suche durchgeführt, um die tatsächlichen nächsten Nachbarn für einen bestimmten Abfragevektor zu finden. Dies führt jedoch zu einer höheren Latenz. 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 Kandidaten-Embeddings 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 Abrufspeichers für eine geringere Abruflatenz zu opfern. Dieser Kompromiss sollte jedoch bewertet werden. Weitere Merkmale, die sich auf Recall und Latenz auswirken:

• Modellierungsparameter: Viele Modellierungsentscheidungen wirken sich auf den Einbettungsraum aus, der letztendlich zum Serving-Index wird. Vergleichen Sie die Kandidaten, die für Indexe abgerufen werden, die sowohl mit flachen als auch mit tiefen Abrufmodellen erstellt wurden.
• Dimensionen: Dimensionen sind ein weiterer Aspekt, der letztendlich vom Modell bestimmt wird. Die Dimensionen des ANN-Index müssen mit den Dimensionen der Vektoren des Anfrage- und Kandidatenturms übereinstimmen.
• Tags für die Überfüllung und Filterung: Tags können leistungsstarke Funktionen bieten, um die Ergebnisse für verschiedene Produktionsanwendungsfälle anzupassen. Es hat sich bewährt, nachzuvollziehen, wie sich Tags auf die abgerufenen Kandidaten und die Leistung auswirken.
• Anzahl der ANN: Durch Erhöhen dieses Werts wird der Recall erhöht, was zu einer proportionalen Erhöhung der Latenz führen kann.
• Prozentsatz der zu durchsuchenden Blattknoten: Der Prozentsatz der zu durchsuchenden Blattknoten ist die wichtigste Option für die Bewertung des Kompromisses zwischen Recall und Latenz. Durch Erhöhen dieses Werts wird der Recall erhöht, was zu einer proportionalen Erhöhung der Latenz führen kann.

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