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 end-to-end di generazione dei candidati a due torri 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 somiglianza semantica tra due entità diverse, come le query web e gli elementi candidati.

Questo documento è rivolto a professionisti tecnici come data scientist e machine learning engineer che sviluppano applicazioni di suggerimenti su larga scala con requisiti di gestione a bassa latenza. Per saperne di più sulle tecniche di modellazione, sulla definizione del problema e sulla preparazione dei dati per la creazione di un modello a due torri, consulta Scalabilità del deep retrieval 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 distribuzione:

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 a due torri combinato viene addestrato offline utilizzando il servizio di addestramento gestito della piattaforma per agenti Gemini Enterprise; ogni torre viene salvata separatamente e utilizzata per attività diverse.
• Torri di query e candidati registrate: dopo l'addestramento, ogni torre viene caricata separatamente in Model Registry su Gemini Enterprise Agent Platform.
• Query tower di cui è stato eseguito il deployment: il deployment della query tower registrata viene eseguito su un endpoint online di Agent Platform.
• Previsione in batch degli embedding: la torre dei candidati registrata viene utilizzata in un job di previsione in batch per precalcolare le rappresentazioni degli embedding di tutti gli elementi candidati disponibili.
• Embeddings 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 distribuzione configurato per la ricerca del vicino più prossimo approssimato (ANN).
• Indice di cui è stato eseguito il deployment: l'indice ANN viene distribuito in un endpoint dell'indice Vector Search di Agent Platform.

Prodotti utilizzati

Questa architettura di riferimento utilizza i seguenti prodotti Google Cloud :

• Addestramento gestito di Gemini Enterprise Agent Platform: un servizio di addestramento gestito che ti consente di rendere operativo l'addestramento di modelli su larga scala.
• Vector Search: un servizio di corrispondenza di somiglianza vettoriale che ti consente di archiviare, indicizzare e cercare 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 ML.
• Cloud Storage: un archivio di oggetti a basso costo e senza limiti per diversi tipi di dati. I dati sono accessibili dall'interno e dall'esterno di Google Cloude vengono replicati in più località per la ridondanza.

Caso d'uso

Per soddisfare i requisiti di pubblicazione a bassa latenza, i sistemi di suggerimenti su larga scala vengono spesso implementati in produzione come sistemi a due fasi o, a volte, come sistemi multifase. L'obiettivo della prima fase, la generazione dei candidati, è quello di esaminare una vasta raccolta di elementi candidati e recuperare un sottoinsieme pertinente di centinaia di elementi per le attività di filtro e ranking successive. 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 embedding <query, candidate>.
2. Durante l'erogazione del modello, recupera gli elementi pertinenti abbastanza rapidamente da soddisfare i requisiti di latenza.

Il seguente diagramma mostra i componenti concettuali di un sistema di suggerimenti in due fasi:

Nel diagramma, la generazione dei 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 poi produce una rappresentazione di embedding di queste caratteristiche. Il deployment di ogni torre viene eseguito separatamente, perché ogni torre verrà utilizzata per attività diverse in produzione:

• Torre dei candidati: la torre dei candidati viene utilizzata per precalcolare gli embedding di tutti gli elementi candidati. Il deployment degli embedding precalcolati viene eseguito su un endpoint indice di Vector Search ottimizzato per il recupero a bassa latenza.
• Torre di cui è stato eseguito il deployment: durante l'erogazione online, la torre delle query di cui è stato eseguito il deployment converte le query utente non elaborate in rappresentazioni di embedding. Le rappresentazioni degli embedding vengono poi 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 delle entità di query e candidate e le mappa a uno spazio di embedding condiviso. Quando le entità vengono mappate a uno spazio di embedding condiviso, le entità semanticamente simili vengono raggruppate più vicine. Pertanto, se calcoli i vector embedding di una determinata query, puoi cercare nello spazio di incorporamento 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 senza dover riaddestrare un nuovo vocabolario di elementi. Inserendo un insieme di caratteristiche degli elementi nella torre degli elementi candidati, puoi calcolare gli embedding degli elementi 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 dei candidati può supportare un insieme arbitrario di elementi candidati, inclusi quelli che non hanno ancora interagito con il sistema di suggerimenti. Questo supporto è possibile perché le architetture two-tower elaborano contenuti avanzati e caratteristiche dei metadati relative a ogni coppia <query, candidate>. 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 distribuiti in un'infrastruttura di distribuzione ottimizzata per il recupero a bassa latenza.
  • Il co-apprendimento 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 metà dell'equazione in anticipo. Il precalcolo ti consente di prendere il resto della decisione il più rapidamente possibile.

Considerazioni sulla progettazione

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

Sicurezza

Agent Platform Vector Search supporta i deployment di endpoint sia pubblici che Virtual Private Cloud (VPC). Se vuoi utilizzare una rete VPC, inizia seguendo la procedura descritta in Configura una connessione di peering di rete VPC. Se l'indice di Vector Search viene distribuito 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 del workbench all'interno della stessa rete VPC dell'endpoint indice di cui è stato eseguito il deployment. Analogamente, qualsiasi pipeline che deve creare un endpoint o eseguire il deployment di un indice in un endpoint deve essere eseguita all'interno della stessa rete VPC.

Ottimizzazione delle prestazioni

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

Profila i job di addestramento

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, attivi 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 esaurita, 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 della piattaforma agente e Vertex AI TensorBoard, consulta Profila le prestazioni di addestramento del modello. Per le best practice di debug, consulta Ottimizza le prestazioni della GPU. Per informazioni su come ottimizzare le prestazioni, consulta Ottimizza le prestazioni di TensorFlow utilizzando Profiler.

Utilizza appieno gli acceleratori

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

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 nella memoria, i colli di bottiglia si trovano in genere tra lo spazio di archiviazione, le VM host e l'acceleratore.

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

Nel diagramma, i dati vengono letti dallo spazio di 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 loop 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.

Migliora le prestazioni della pipeline di input

• Lettura dei dati dallo spazio di archiviazione: per migliorare le letture dei dati, prova la memorizzazione nella cache, il 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 trasformazione interleave nella pipeline di input dei dati.
• Invio di dati al dispositivo: per ridurre il tempo complessivo del job, trasferisci i dati dall'host a più dispositivi in parallelo.

Migliora 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 poter essere inserito nella memoria insieme al resto del programma di addestramento. Se aumenti troppo le dimensioni del mini-batch, potresti riscontrare errori di memoria esaurita e divergenza del modello.
• Vettorizza le funzioni definite dall'utente. In genere, le trasformazioni dei dati possono essere espresse come una funzione definita dall'utente;utente che descrive come trasformare ogni elemento di un set di dati di input. Per vettorizzare questa funzione, applichi l'operazione di trasformazione a un batch di input contemporaneamente, anziché trasformare un elemento alla volta. Qualsiasi funzione definita dall'utente dall'utente comporta un overhead relativo 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.

Fai lo scale up prima di fare lo scale out

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

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

Valuta il recall rispetto alla latenza per la ricerca vettoriale ANN

Per valutare i vantaggi della ricerca ANN, puoi misurare la latenza e il recall 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 più elevata, per trovare i vicini più prossimi reali per un determinato vettore di query. L'utilizzo di indici brute-force 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 brute force. L'indice brute-force 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 recall del recupero per ottenere un miglioramento della 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 sia dai modelli di deep retrieval che da quelli di shallow retrieval.
• Dimensioni: le dimensioni sono un altro aspetto che viene determinato dal modello. Le dimensioni dell'indice ANN devono corrispondere alle dimensioni dei vettori della torre di query e della torre candidata.
• Tag di raggruppamento e filtro: i tag possono fornire funzionalità efficaci per personalizzare i risultati per diversi casi d'uso di produzione. È una best practice capire in che modo i tag influenzano i candidati recuperati e influiscono sul rendimento.
• Conteggio ANN: l'aumento di questo valore aumenta il richiamo e può aumentare proporzionalmente la latenza.
• Percentuale di nodi foglia in cui cercare: la percentuale di nodi foglia in cui cercare è l'opzione più critica 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 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