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

Last reviewed 2025-01-16 UTC

In diesem Dokument wird eine Referenzarchitektur beschrieben, mit der Sie einen End-to-End-Workflow für die Kandidatengenerierung mit zwei Türmen mit Vertex AI implementieren können. Das Two-Tower-Modell ist ein leistungsstarkes Abrufverfahren für Anwendungsfälle der Personalisierung, da es die semantische Ähnlichkeit zwischen zwei verschiedenen Entitäten lernt, z. B. zwischen Webanfragen und Kandidatenelementen.

Dieses Dokument richtet sich an technische Fachkräfte wie Data Scientists und Entwickler für maschinelles Lernen, die groß angelegte Empfehlungsanwendungen mit Anforderungen an die Bereitstellung mit niedriger Latenz entwickeln. Weitere Informationen zu den Modellierungstechniken, zur Problembeschreibung und zur Datenvorbereitung für die Erstellung eines Zwei-Turm-Modells finden Sie unter Deep Retrieval mit TensorFlow Recommenders und der Vektorsuche skalieren.

Architektur

Das folgende Diagramm zeigt eine Architektur zum Trainieren eines Zwei-Turm-Modells und zum separaten Bereitstellen der einzelnen Türme für verschiedene Bereitstellungs- und Bereitstellungsaufgaben:

Die Architektur im Diagramm umfasst die folgenden Komponenten:

• Trainingsdaten: Trainingsdateien werden in Cloud Storage gespeichert.
• Training mit zwei Modellen: Das kombinierte Modell mit zwei Modellen wird offline mit dem Vertex AI Training-Dienst trainiert. Die einzelnen Modelle werden separat gespeichert und für verschiedene Aufgaben verwendet.
• Registrierte Such- und Kandidatentürme: Nachdem die Türme trainiert wurden, werden sie einzeln in die Vertex AI Model Registry hochgeladen.
• Bereitgestellter Abfrageturm: Der registrierte Abfrageturm wird auf einem Vertex AI-Onlineendpunkt bereitgestellt.
• Embeddings per Batchvorhersage berechnen: Der registrierte Kandidatenturm wird in einem Batchvorhersagejob verwendet, um die Embedding-Darstellungen aller verfügbaren Kandidatenelemente vorab zu berechnen.
• Embeddings JSON: Die vorhergesagten Einbettungen werden in einer JSON-Datei in Cloud Storage gespeichert.
• ANN-Index: Mit der Vertex AI-Vektorsuche wird ein Bereitstellungsindex erstellt, der für die Suche nach dem nächsten Nachbarn (Approximate Nearest Neighbor, ANN) konfiguriert ist.
• Bereitgestellter Index: Der ANN-Index wird auf einem Vertex AI-Vektorsuchindex-Endpunkt 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 die Vektorähnlichkeit, mit dem Sie semantisch ähnliche oder verwandte Daten speichern, indexieren und suchen 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 die geringe Latenz beim Ausliefern zu erfüllen, werden Large-Scale-Recommender häufig als zweistufige Systeme oder manchmal als mehrstufige Systeme in der Produktion bereitgestellt. Ziel der ersten Phase, der Kandidatengenerierung, ist es, eine große Sammlung von Kandidatenelementen zu durchsuchen und eine relevante Teilmenge von Hunderten von Elementen für nachfolgende Filter- und Rankingaufgaben abzurufen. Um diese Abrufaufgabe zu optimieren, sollten Sie die folgenden zwei Hauptziele berücksichtigen:

1. Ermitteln Sie während des Modelltrainings die beste Darstellung des zu lösenden Problems oder der zu lösenden Aufgabe und kompilieren Sie diese Darstellung in <query, candidate>-Embeddings.
2. Relevante Elemente müssen während der Modellbereitstellung schnell genug abgerufen werden, um die Latenzzeitanforderungen 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 Hunderte von Kandidatenelementen gefiltert, um Dutzende von empfohlenen Elementen zurückzugeben.

In der Referenzarchitektur in diesem Dokument wird ein zweitürmiges Abrufmodell trainiert. In der Architektur ist jeder Turm ein neuronales Netzwerk, das entweder Suchanfragen oder Artikeleigenschaften verarbeitet und dann eine Einbettungsdarstellung dieser Features erstellt. Jeder Turm wird separat bereitgestellt, da er für unterschiedliche Aufgaben in der Produktion verwendet wird:

• Kandidatenturm: Mit dem Kandidatenturm werden vorab embeddings für alle Kandidatenelemente berechnet. Die vorab berechneten Einbettungen werden in einem Indexendpunkt der Vertex AI-Vektorsuche bereitgestellt, der für einen Abruf mit niedriger Latenz optimiert ist.
• Bereitgestellter Tower: Während der Onlinebereitstellung wandelt der bereitgestellte Query Tower Rohnutzeranfragen in Darstellungen für das Einbetten um. Anhand der Einbettungsdarstellungen werden dann ähnliche Artikel-Ebenen im bereitgestellten Index abgerufen.

Zwei-Turm-Architekturen eignen sich ideal für viele Abrufaufgaben, da sie die semantische Beziehung zwischen Suchanfrage und Kandidatenentitäten erfassen und ihnen einen gemeinsamen Embedding-Raum zuordnen. Wenn die Entitäten einem gemeinsamen Einbettungsraum zugeordnet werden, werden semantisch ähnliche Entitäten näher beieinander 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 besteht darin, dass die Inferenz von Abfrage- und Kandidatenrepräsentationen entkoppelt werden kann. Die Vorteile dieser Entkopplung sind hauptsächlich zweierlei:

• Sie können neue (frische) Artikel präsentieren, ohne ein neues Artikelvokabular neu trainieren zu müssen. Wenn Sie dem Kandidatenitem-Turm beliebige Artikelfeatures zuführen, können Sie die Artikel-Embeddings für beliebige Kandidaten berechnen, auch für solche, die während des Trainings nicht verwendet wurden. Durch diese Berechnung lässt sich das Kaltstartproblem beheben.
  • Der Kandidatenturm kann eine beliebige Anzahl von Kandidatenelementen unterstützen, einschließlich Elementen, die noch nicht mit dem Empfehlungssystem interagiert haben. Diese Unterstützung ist möglich, da bei Two-Tower-Architekturen umfangreiche Inhalte und Metadatenfunktionen für jedes <query, candidate>-Paar verarbeitet werden. Bei dieser Art der Verarbeitung kann das System ein unbekanntes Element anhand von bekannten Elementen beschreiben.
• Sie können die Abrufinferenz optimieren, indem Sie alle Kandidatenelement-Embeddings vorab berechnen. Diese vorab berechneten Einbettungen können indexiert und in einer Bereitstellungsinfrastruktur bereitgestellt werden, die für die Abrufung mit niedriger Latenz optimiert ist.
  • Durch das gemeinsame Lernen der Türme können Sie Elemente in Bezug auf Abfragen und umgekehrt beschreiben. Wenn Sie eine Hälfte eines Paars haben, z. B. eine Suchanfrage, und nach dem anderen entsprechenden Element suchen müssen, können Sie die Hälfte der Gleichung vorab berechnen. Durch die Vorverarbeitung können Sie den Rest der Entscheidung so schnell wie möglich treffen.

Designaspekte

Dieser Abschnitt enthält eine Anleitung zum Entwickeln einer Architektur für die Kandidatengenerierung in Google Cloud , die Ihren Sicherheits- und Leistungsanforderungen entspricht. Die Anleitung in diesem Abschnitt ist nicht vollständig. Je nach Ihren spezifischen Anforderungen können Sie zusätzliche Designfaktoren und Kompromisse berücksichtigen.

Sicherheit

Vertex AI Vector Search unterstützt sowohl öffentliche als auch Virtual Private Cloud (VPC)-Endpunktbereitstellungen. Wenn Sie ein VPC-Netzwerk verwenden möchten, lesen Sie den Hilfeartikel VPC-Netzwerk-Peering-Verbindung einrichten. Wenn der Index für die Vektorsuche innerhalb eines VPC-Perimeters bereitgestellt wird, müssen Nutzer von innerhalb desselben 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 den bereitgestellten Indexendpunkt erstellen. Ebenso sollte jede Pipeline, die einen Endpunkt erstellen oder einen Index an 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 Referenzarchitektur zum Entwerfen einer Topologie in Google Cloud verwenden, die die Leistungsanforderungen Ihrer Arbeitslasten erfüllt.

Profilerstellungsjobs

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

Wenn Sie das Argument –profiler in den Trainingsjob übergeben, können Sie mit dem TensorFlow-Callback eine festgelegte Anzahl von Batches für jede Epoche erfassen. Das Profil erfasst Traces von der Host-CPU und von der GPU oder TPU-Hardware des Geräts. Die Protokolle enthalten Informationen zur Ressourcennutzung des Trainingsjobs. Um Fehler aufgrund von Speicherplatzmangel zu vermeiden, empfehlen wir, mit einer Profildauer zwischen 2 und 10 Trainingsschritten zu beginnen und sie bei Bedarf zu erhöhen.

Weitere Informationen zur Verwendung des Profilers mit Vertex AI Training und Vertex AI TensorBoard finden Sie unter Leistung des Modelltrainings mit Profiler bestimmen. Best Practices für die Fehlerbehebung finden Sie unter GPU-Leistung optimieren. Informationen zur Leistungsoptimierung finden Sie unter Leistung von TensorFlow mit dem Profiler optimieren.

Beschleuniger optimal nutzen

Wenn Sie Beschleuniger für das Training wie NVIDIA-GPUs oder Cloud TPUs anschließen, ist es wichtig, dass sie voll ausgelastet sind. Die vollständige Ausschöpfung von Beschleunigern für die Ausbildung ist eine Best Practice für die Kostenverwaltung, da Beschleuniger die teuerste Komponente in der Architektur sind. Die vollständige Auslastung von Training Accelerators ist auch eine Best Practice für die Jobeffizienz, da keine Inaktivitätszeiten zu einem geringeren Ressourcenverbrauch insgesamt führen.

Damit ein Beschleuniger optimal genutzt wird, müssen Sie in der Regel einige Iterationen ausführen, um das Nadelöhr zu finden, es zu optimieren und diese Schritte dann so lange zu wiederholen, bis die Gerätenutzung des Beschleunigers 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 Speicher, Host-VMs und dem Beschleuniger auf.

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

Im Diagramm werden Daten aus dem Speicher gelesen und vorab verarbeitet. 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 Beschleunigungsgerät (GPU oder TPU) begrenzt ist. Das Gerät ist für die Beschleunigung des Trainingsloops verantwortlich, während der Host für die Bereitstellung von Trainingsdaten auf dem Gerät und den Empfang von Ergebnissen vom Gerät zuständig ist. 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 die Datenleseleistung zu verbessern, können Sie Caching, prefetching, sequentielle Zugriffsmuster und parallele E/A verwenden.
• Daten vorverarbeiten: Konfigurieren Sie die parallele Verarbeitung für die Datenextraktion und ‑transformation, um die Datenvorverarbeitung zu verbessern, und optimieren Sie die interleave-Transformation in der Dateneingabepipeline.
• Daten an das Gerät senden: Um die Gesamtzeit des Jobs zu verkürzen, können Sie Daten parallel vom Host auf mehrere Geräte übertragen.

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. Durch eine größere Minibatch-Größe wird die Parallelität zwischen den Vorgängen erhöht und die Datenwiederverwendung verbessert. Der Mini-Batch muss jedoch zusammen mit dem restlichen Trainingsprogramm in den Arbeitsspeicher passen. Wenn Sie die Minibatch-Größe zu stark erhöhen, kann es zu Fehlern aufgrund fehlenden Arbeitsspeichers und zu Abweichungen beim Modell kommen.
• Benutzerdefinierte Funktionen vektorisieren Normalerweise können Datentransformationen als benutzerdefinierte Funktion ausgedrückt werden, die beschreibt, wie jedes Element eines Eingabedatensatzes transformiert werden soll. Wenn Sie diese Funktion vektorisieren möchten, wenden Sie den Transformationsvorgang auf einen Batch von Eingaben gleichzeitig an, anstatt jedes Element einzeln zu transformieren. Jede benutzerdefinierte Funktion hat einen Overhead, der sich auf die Planung und Ausführung bezieht. Wenn Sie einen Batch von Eingaben transformieren, entsteht der Overhead einmal pro Batch, nicht einmal pro Dataset-Element.

Hochskalierung vor der horizontalen Skalierung

Wenn Sie die Rechenressourcen für Ihre Trainingsjobs konfigurieren, empfehlen wir, zuerst nach oben und dann nach außen zu skalieren. Sie sollten also ein größeres, leistungsstärkeres Gerät wählen, bevor Sie mehrere weniger leistungsstarke Geräte verwenden. Wir empfehlen folgende Skalierung:

1. Ein einzelner Nutzer + ein einzelnes Gerät
2. Einzelner Worker und leistungsstärkeres Gerät
3. Einzelner Worker und 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 Abruf einer bestimmten Suchanfrage messen. Zur Indexoptimierung können Sie mit der Vertex AI-Vektorsuche einen Brute-Force-Index erstellen. Bei Brute-Force-Indexen wird eine vollständige Suche durchgeführt, was zu einer höheren Latenz führt, um die tatsächlichen nächsten Nachbarn für einen bestimmten Abfragevektor zu finden. Brute-Force-Indexe sind nicht für die Produktionsnutzung vorgesehen, bieten aber eine gute Referenz, wenn Sie den Recall bei der Indexoptimierung berechnen.

Um den Rückruf mit der Latenz zu vergleichen, können Sie die vorab berechneten Kandidaten-Embeddings in einem Index bereitstellen, 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 absoluten nächsten Nachbarn zurück, dauert aber in der Regel länger als eine ANN-Suche. Sie sind vielleicht bereit, einen gewissen Abrufabruf für eine geringere Abruflatenz zu opfern, aber dieser Kompromiss sollte bewertet werden. Weitere Merkmale, die sich auf Recall und Latenz auswirken:

• 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 vom Modell bestimmt wird. Die Dimensionen des ANN-Index müssen mit den Dimensionen der Such- und Kandidatenmastenvektoren übereinstimmen.
• Tags für Überlastung und Filterung: Mit Tags können Sie die Ergebnisse für verschiedene Produktionsanwendungsfälle anpassen. Es hat sich bewährt, 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. Die Latenz kann sich dadurch proportional erhöhen.
• Prozentsatz der zu durchsuchenden Blattknoten: Der Prozentsatz der zu durchsuchenden Blattknoten ist die wichtigste Option für die Abwägung zwischen Trefferquote 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