Implementare il recupero a due torri per la generazione di candidati su larga scala

Last reviewed 2025-01-16 UTC

Questo documento fornisce un'architettura di riferimento che mostra come implementare un workflow di generazione di candidati a due torri end-to-end con Gemini Enterprise Agent Platform. Il framework di modellazione a due torri è una potente tecnica di recupero per i casi d'uso di personalizzazione perché apprende la similarità semantica tra due entità diverse, come query web ed elementi candidati.

Questo documento è destinato a professionisti tecnici come data scientist e machine learning engineer che sviluppano applicazioni di raccomandazione su larga scala con requisiti di pubblicazione a bassa latenza. Per ulteriori informazioni sulle tecniche di modellazione , sulla definizione dei problemi e sulla preparazione dei dati per la creazione di un modello a due torri , consulta Scalare il recupero approfondito con TensorFlow Recommenders e Vector Search.

Architettura

Il seguente diagramma mostra un'architettura per addestrare un modello a due torri ed eseguire il deployment di ogni torre separatamente per diverse attività di deployment e pubblicazione:

L'architettura nel diagramma include i seguenti componenti:

• Dati di addestramento: i file di addestramento sono archiviati in Cloud Storage.
• Addestramento a due torri: il modello combinato a due torri viene addestrato offline utilizzando il servizio di addestramento gestito di Gemini Enterprise Agent Platform; ogni torre viene salvata separatamente e utilizzata per attività diverse.
• Torri di query e candidati registrate: dopo l'addestramento delle torri, ogni torre viene caricata separatamente in Model Registry su Gemini Enterprise Agent Platform.
• Torre di query di cui è stato eseguito il deployment: la torre di query registrata viene sottoposta a deployment in un endpoint online di Agent Platform.
• Embedding di previsione batch: la torre di candidati registrata viene utilizzata in un job di previsione batch per precalcolare le rappresentazioni di embedding di tutti gli elementi candidati disponibili.
• Embedding JSON: gli embedding previsti vengono salvati in un file JSON in Cloud Storage.
• Indice ANN: Agent Platform Vector Search viene utilizzato per creare un indice di pubblicazione configurato per la ricerca del vicino più prossimo approssimativo (ANN).
• Indice di cui è stato eseguito il deployment: l'indice ANN viene sottoposto a deployment in un endpoint di indice di Agent Platform Vector Search.

Prodotti utilizzati

Questa architettura di riferimento utilizza i seguenti Google Cloud prodotti:

• Addestramento gestito di Gemini Enterprise Agent Platform: un servizio di addestramento gestito che ti consente di operazionalizzare l'addestramento di modelli su larga scala.
• Vector Search: un servizio di corrispondenza della similarità vettoriale che ti consente di archiviare, indicizzare ed eseguire ricerche su dati semanticamente simili o correlati.
• Model Registry su Gemini Enterprise Agent Platform: un repository centrale in cui puoi gestire il ciclo di vita dei tuoi modelli di machine learning.
• Cloud Storage: uno spazio di archiviazione di oggetti a basso costo e senza limiti per diversi tipi di dati. È possibile accedere ai dati dall'interno e dall'esterno Google Cloud, e vengono replicati tra le località per la ridondanza.

Caso d'uso

Per soddisfare i requisiti di pubblicazione a bassa latenza, i sistemi di raccomandazione su larga scala vengono spesso sottoposti a deployment in produzione come sistemi a due fasi o, a volte, come sistemi multifase. L'obiettivo della prima fase, la generazione di candidati, è quello di setacciare una vasta raccolta di elementi candidati e recuperare un sottoinsieme pertinente di centinaia di elementi per le attività di filtro e ranking a valle. Per ottimizzare questa attività di recupero, considera questi due obiettivi principali:

1. Durante l'addestramento del modello, apprendi la migliore rappresentazione del problema o dell'attività da risolvere e compila questa rappresentazione in <query, candidate> embedding.
2. Durante l'erogazione del modello, recupera gli elementi pertinenti abbastanza velocemente da soddisfare i requisiti di latenza.

Il seguente diagramma mostra i componenti concettuali di un motore per suggerimenti a due fasi:

Nel diagramma, la generazione di candidati filtra milioni di elementi candidati. Il ranking filtra quindi le centinaia di elementi candidati risultanti per restituire decine di elementi consigliati.

L'architettura di riferimento in questo documento addestra un modello di recupero basato su due torri. Nell'architettura, ogni torre è una rete neurale che elabora le caratteristiche della query o dell'elemento candidato e produce una rappresentazione di embedding di queste caratteristiche. Ogni torre viene sottoposta a deployment separatamente, perché ogni torre verrà utilizzata per attività diverse in produzione:

• Torre di candidati: la torre di candidati viene utilizzata per precalcolare gli embedding per tutti gli elementi candidati. Gli embedding precalcolati vengono sottoposti a deployment in un endpoint di indice di Vector Search ottimizzato per il recupero a bassa latenza.
• Torre di cui è stato eseguito il deployment: durante l'erogazione online, la torre di query di cui è stato eseguito il deployment converte le query utente non elaborate in rappresentazioni di embedding. Le rappresentazioni di embedding vengono quindi utilizzate per cercare embedding di elementi simili nell'indice di cui è stato eseguito il deployment.

Le architetture a due torri sono ideali per molte attività di recupero perché un'architettura a due torri acquisisce la relazione semantica tra le entità di query e candidati, e le mappa in uno spazio di embedding condiviso. Quando le entità vengono mappate in uno spazio di embedding condiviso, le entità semanticamente simili vengono raggruppate più vicine. Pertanto, se calcoli gli embedding vettoriali di una determinata query, puoi cercare nello spazio di embedding gli elementi candidati più vicini (più simili). Il vantaggio principale di un'architettura di questo tipo è la possibilità di disaccoppiare l'inferenza delle rappresentazioni di query e candidati. I vantaggi di questo disaccoppiamento sono principalmente due:

• Puoi pubblicare nuovi elementi (aggiornati) senza riaddestrare un nuovo vocabolario di elementi. Fornendo qualsiasi insieme di caratteristiche dell'elemento alla torre dell'elemento candidato, puoi calcolare gli embedding dell'elemento per qualsiasi insieme di candidati, anche quelli non visualizzati durante l'addestramento. L'esecuzione di questo calcolo aiuta a risolvere il problema dell'avvio a freddo.
  • La torre di candidati può supportare un insieme arbitrario di elementi candidati, inclusi gli elementi che non hanno ancora interagito con il sistema di raccomandazione. Questo supporto è possibile perché le architetture a due torri elaborano contenuti avanzati e caratteristiche dei metadati su ogni <query, candidate> coppia. Questo tipo di elaborazione consente al sistema di descrivere un elemento sconosciuto in termini di elementi che conosce.
• Puoi ottimizzare l'inferenza di recupero precalcolando tutti gli embedding degli elementi candidati. Questi embedding precalcolati possono essere indicizzati e sottoposti a deployment in un'infrastruttura di pubblicazione ottimizzata per il recupero a bassa latenza.
  • L'apprendimento congiunto delle torri ti consente di descrivere gli elementi in termini di query e viceversa. Se hai una metà di una coppia, ad esempio una query, e devi cercare l'altro elemento corrispondente, puoi precalcolare in anticipo metà dell'equazione. Il precalcolo ti consente di prendere il resto della decisione il più rapidamente possibile.

Note sul layout

Questa sezione fornisce indicazioni per aiutarti a sviluppare un'architettura di generazione di candidati che soddisfi le tue esigenze di sicurezza e prestazioni needs. Google Cloud Le indicazioni in questa sezione non sono esaustive. A seconda dei tuoi requisiti specifici, potresti scegliere di considerare fattori di progettazione e compromessi aggiuntivi.

Sicurezza

Agent Platform Vector Search supporta i deployment di endpoint pubblici e Virtual Private Cloud (VPC). Se vuoi utilizzare una rete VPC inizia seguendo Configurare una connessione di peering di rete VPC. Se l'indice Vector Search viene sottoposto a deployment all'interno di un perimetro VPC, gli utenti devono accedere alle risorse associate dalla stessa rete VPC. Ad esempio, se stai sviluppando da Gemini Enterprise Agent Platform Workbench, devi creare l'istanza di Workbench nella stessa rete VPC dell'endpoint di indice di cui è stato eseguito il deployment. Allo stesso modo, qualsiasi pipeline che dovrebbe creare un endpoint o eseguire il deployment di un indice in un endpoint deve essere eseguita nella stessa rete VPC.

Ottimizzazione delle prestazioni

Questa sezione descrive i fattori da considerare quando utilizzi questa architettura di riferimento per progettare una topologia che soddisfi i Google Cloud requisiti di prestazioni dei tuoi workload.

Job di addestramento del profilo

Per ottimizzare le pipeline di input dei dati e il grafico di addestramento complessivo, ti consigliamo di profilare le prestazioni di addestramento con Cloud Profiler. Profiler è un'implementazione gestita di TensorBoard Profiler open source .

Passando l'argomento –profiler nel job di addestramento, abiliti il callback TensorFlow per profilare un numero impostato di batch per ogni epoca. Il profilo acquisisce le tracce dalla CPU host e dall'hardware GPU o TPU del dispositivo. Le tracce forniscono informazioni sul consumo di risorse del job di addestramento. Per evitare errori di memoria insufficiente, ti consigliamo di iniziare con una durata del profilo compresa tra 2 e 10 passaggi di addestramento e di aumentarla in base alle esigenze.

Per scoprire come utilizzare Profiler con l'addestramento gestito di Agent Platform e Vertex AI TensorBoard, consulta Profilare le prestazioni di addestramento dei modelli. Per le best practice di debug, consulta Ottimizzare le prestazioni della GPU. Per informazioni su come ottimizzare le prestazioni, consulta Ottimizzare le prestazioni di TensorFlow utilizzando Profiler.

Utilizzare completamente gli acceleratori

Quando colleghi acceleratori di addestramento come GPU NVIDIA o Cloud TPU, è importante mantenerli completamente utilizzati. L'utilizzo completo degli acceleratori di addestramento è una best practice per la gestione dei costi perché gli acceleratori sono il componente più costoso dell'architettura. L'utilizzo completo degli acceleratori di addestramento è anche una best practice per l'efficienza dei job perché l'assenza di tempi di inattività comporta un consumo complessivo inferiore di risorse.

Per mantenere un acceleratore completamente utilizzato, in genere esegui alcune iterazioni per trovare il collo di bottiglia, ottimizzarlo e ripetere questi passaggi finché l'utilizzo del dispositivo acceleratore non è accettabile. Poiché molti dei set di dati per questo caso d'uso sono troppo grandi per essere contenuti in memoria, i colli di bottiglia si trovano in genere tra l'archiviazione, le VM host e l'acceleratore.

Il seguente diagramma mostra le fasi concettuali di una pipeline di input di addestramento di machine learning:

Nel diagramma, i dati vengono letti dall'archiviazione e pre-elaborati. Dopo la pre-elaborazione, i dati vengono inviati al dispositivo. Per ottimizzare le prestazioni, inizia determinando se le prestazioni complessive sono limitate dalla CPU host o dal dispositivo acceleratore (GPU o TPU). Il dispositivo è responsabile dell'accelerazione del ciclo di addestramento, mentre l'host è responsabile dell'invio dei dati di addestramento al dispositivo e della ricezione dei risultati dal dispositivo. Le sezioni seguenti descrivono come risolvere i colli di bottiglia migliorando le prestazioni della pipeline di input e del dispositivo.

Migliorare le prestazioni della pipeline di input

• Lettura dei dati dall'archiviazione: per migliorare le letture dei dati, prova a utilizzare la memorizzazione nella cache, prefetching, i pattern di accesso sequenziale, e l'I/O parallelo.
• Pre-elaborazione dei dati: per migliorare la pre-elaborazione dei dati, configura l'elaborazione parallela per l'estrazione e la trasformazione dei dati e ottimizza la interleave trasformazione nella pipeline di input dei dati.
• Invio dei dati al dispositivo: per ridurre il tempo complessivo del job, trasferisci i dati dall'host a più dispositivi in parallelo.

Migliorare le prestazioni del dispositivo

• Aumento delle dimensioni del mini-batch. I mini-batch sono il numero di campioni di addestramento utilizzati da ogni dispositivo in un'iterazione di un ciclo di addestramento. Aumentando le dimensioni del mini-batch, aumenti il parallelismo tra le operazioni e migliori il riutilizzo dei dati. Tuttavia, il mini-batch deve essere in grado di essere contenuto in memoria con il resto del programma di addestramento. Se aumenti troppo le dimensioni del mini-batch, puoi riscontrare errori di memoria insufficiente e divergenza del modello.
• Vettorializzare le funzioni definite dall'utente. In genere, le trasformazioni dei dati possono essere espresse come una funzione definita dall'utente che descrive come trasformare ogni elemento di un set di dati di input. Per vettorializzare questa funzione, applichi l'operazione di trasformazione a un batch di input contemporaneamente anziché trasformare un elemento alla volta. Qualsiasi funzione definita dall'utente ha un overhead correlato alla pianificazione e all'esecuzione. Quando trasformi un batch di input, l'overhead viene applicato una volta per batch, anziché una volta per elemento del set di dati.

Eseguire lo scale up prima dello scale out

Quando configuri le risorse di calcolo per i job di addestramento, ti consigliamo di eseguire lo scale up prima dello scale out. Ciò significa che devi scegliere un dispositivo più grande e potente prima di utilizzare più dispositivi meno potenti. Ti consigliamo di fare lo scale in nel seguente modo:

1. Singolo worker + singolo dispositivo
2. Singolo worker + dispositivo più potente
3. Singolo worker + più dispositivi
4. Addestramento distribuito

Valutare il richiamo rispetto alla latenza per la ricerca vettoriale ANN

Per valutare i vantaggi della ricerca ANN, puoi misurare la latenza e il richiamo di una determinata query. Per facilitare l'ottimizzazione dell'indice, Agent Platform Vector Search offre la possibilità di creare un indice di forza bruta. Gli indici di forza bruta eseguiranno una ricerca esaustiva, a scapito di una latenza maggiore, per trovare i veri vicini più prossimi per un determinato vettore di query. L'utilizzo degli indici di forza bruta non è destinato all'uso in produzione, ma fornisce una buona base di riferimento quando calcoli il richiamo durante l'ottimizzazione dell'indice.

Per valutare il richiamo rispetto alla latenza, esegui il deployment degli embedding dei candidati precalcolati in un indice configurato per la ricerca ANN e in un altro indice configurato per la ricerca di forza bruta. L'indice di forza bruta restituirà i vicini più prossimi assoluti, ma in genere richiederà più tempo rispetto a una ricerca ANN. Potresti essere disposto a sacrificare un po' di richiamo di recupero per ottenere una latenza di recupero, ma questo compromesso deve essere valutato. Altre caratteristiche che influiscono sul richiamo e sulla latenza includono:

• Parametri di modellazione: molte decisioni di modellazione influiscono sullo spazio di embedding, che alla fine diventa l'indice di pubblicazione. Confronta i candidati recuperati per gli indici creati da modelli di recupero sia superficiali che approfonditi.
• Dimensioni: le dimensioni sono un altro aspetto che alla fine è determinato dal modello. Le dimensioni dell'indice ANN devono corrispondere alle dimensioni dei vettori della torre di query e candidati.
• Tag di affollamento e filtro: i tag possono fornire funzionalità avanzate per personalizzare i risultati per diversi casi d'uso di produzione. È una best practice comprendere in che modo i tag influenzano i candidati recuperati e le prestazioni.
• Conteggio ANN: l'aumento di questo valore aumenta il richiamo e può aumentare proporzionalmente la latenza.
• Percentuale di nodi foglia da cercare: la percentuale di nodi foglia da cercare è l'opzione più importante per valutare il compromesso tra richiamo e latenza L'aumento di questo valore aumenta il richiamo e può aumentare proporzionalmente la latenza.

Passaggi successivi

Per ulteriori architetture di riferimento, diagrammi e best practice, esplora il Cloud Architecture Center.

Collaboratori

Autori:

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

Altro collaboratore: Kaz Sato | Staff Developer Advocate