Implémenter la récupération à deux tours pour la génération de candidats à grande échelle

Last reviewed 2025-01-16 UTC

Ce document fournit une architecture de référence qui vous montre comment implémenter un workflow de génération de candidats à deux tours de bout en bout avec Gemini Enterprise Agent Platform. Le framework de modélisation à deux tours est une technique de récupération puissante pour les cas d'utilisation de personnalisation, car il apprend la similarité sémantique entre deux entités différentes, telles que les requêtes Web et les éléments candidats.

Ce document s'adresse aux professionnels techniques tels que les data scientists et les ingénieurs en machine learning qui développent des applications de recommandation à grande échelle avec des exigences de diffusion à faible latence. Pour en savoir plus sur les techniques de modélisation , la formulation des problèmes et la préparation des données pour la création d'un modèle à deux tours , consultez la page Soumettre la récupération profonde à un scaling à l'aide des outils de recommandation TensorFlow et de Vector Search.

Architecture

Le diagramme suivant illustre une architecture permettant d'entraîner un modèle à deux tours et de déployer chaque tour séparément pour différentes tâches de déploiement et de mise en service :

L'architecture du schéma comprend les composants suivants :

• Données d'entraînement : les fichiers d'entraînement sont stockés dans Cloud Storage.
• Entraînement à deux tours : le modèle combiné à deux tours est entraîné hors connexion à l'aide du service d'entraînement géré de Gemini Enterprise Agent Platform. Chaque tour est enregistré séparément et utilisé pour différentes tâches.
• Tours de requêtes et de candidats enregistrés : une fois les tours entraînés, chacun d'eux est importé séparément dans Model Registry sur Gemini Enterprise Agent Platform.
• Tour de requêtes déployé : le tour de requêtes enregistré est déployé sur un point de terminaison en ligne Agent Platform.
• Embeddings de prédiction par lot : le tour de candidats enregistré est utilisé dans une tâche de prédiction par lot pour précalculer les représentations d’embedding de tous les éléments candidats disponibles.
• JSON d'embeddings : les embeddings prédits sont enregistrés dans un fichier JSON dans Cloud Storage.
• Index ANN : Agent Platform Vector Search est utilisé pour créer un index de diffusion configuré pour la recherche de voisins approximatifs les plus proches (ANN).
• Index déployé : l'index ANN est déployé sur un point de terminaison d'index de recherche vectorielle Agent Platform.

Produits utilisés

Cette architecture de référence utilise les produits suivants Google Cloud :

• Gemini Enterprise Agent Platform Managed Training : service d'entraînement géré qui vous permet d'opérationnaliser l'entraînement de modèles à grande échelle.
• Vector Search : service de mise en correspondance de similarités vectorielles qui vous permet de stocker, d'indexer et de rechercher des données sémantiquement similaires ou associées.
• Model Registry sur Gemini Enterprise Agent Platform : dépôt central dans lequel vous pouvez gérer le cycle de vie de vos modèles de ML.
• Cloud Storage : store d'objets économique et sans limite pour tout type de données. Les données sont accessibles depuis et en dehors de Google Cloud Google Cloud, et sont répliquées sur plusieurs emplacements à des fins de redondance.

Cas d'utilisation

Pour répondre aux exigences de diffusion à faible latence, les outils de recommandation à grande échelle sont souvent déployés en production en tant que systèmes à deux étapes ou parfois en tant que systèmes à plusieurs étapes. L'objectif de la première étape, la génération de candidats, est de passer au crible une vaste collection d'éléments candidats et de récupérer un sous-ensemble pertinent de centaines d'éléments pour les tâches de filtrage et de classement en aval. Pour optimiser cette tâche de récupération, tenez compte des deux objectifs principaux suivants :

1. Pendant l'entraînement de modèle, apprenez la meilleure représentation du problème ou de la tâche à résoudre, et compilez cette représentation dans des <query, candidate> embeddings.
2. Pendant la mise en service du modèle, récupérez les éléments pertinents assez rapidement pour répondre aux exigences de latence.

Le schéma suivant illustre les composants conceptuels d'un outil de recommandation à deux étapes :

Dans le schéma, la génération de candidats filtre des millions d'éléments candidats. Le classement filtre ensuite les centaines d'éléments candidats résultants pour renvoyer des dizaines d'éléments recommandés.

L'architecture de référence de ce document entraîne un modèle de récupération basé sur deux tours. Dans l'architecture, chaque tour est un réseau de neurones qui traite les caractéristiques de la requête ou de l'élément candidat, puis produit une représentation d'embeddings de ces caractéristiques. Chaque tour est déployé séparément, car il sera utilisé pour différentes tâches en production :

• Tour de candidats : le tour de candidats est utilisé pour précalculer les embeddings de tous les éléments candidats. Les embeddings précalculés sont déployés sur un Vector Search point de terminaison d'index optimisé pour la récupération à faible latence.
• Tour déployé : lors de la diffusion en ligne, le tour de requêtes déployé convertit les requêtes utilisateur brutes en représentations d'embedding. Les représentations d'embedding sont ensuite utilisées pour rechercher des embeddings d'éléments similaires dans l'index déployé.

Les architectures à deux tours sont idéales pour de nombreuses tâches de récupération, car une architecture à deux tours capture la relation sémantique des entités de requête et de candidat, et les mappe à un espace d'embedding partagé. Lorsque les entités sont mappées à un espace d'embedding partagé, les entités sémantiquement similaires sont regroupées plus près les unes des autres. Par conséquent, si vous calculez les embeddings vectoriels d'une requête donnée, vous pouvez rechercher dans l'espace d'embedding les éléments candidats les plus proches (les plus similaires). Le principal avantage d'une telle architecture est la possibilité de dissocier l'inférence des représentations de requêtes et de candidats. Cette dissociation présente principalement deux avantages :

• Vous pouvez diffuser de nouveaux éléments sans réentraîner un nouveau vocabulaire d'éléments. En fournissant n'importe quel ensemble de caractéristiques d'éléments au tour d'éléments candidats, vous pouvez calculer les embeddings d'éléments pour n'importe quel ensemble de candidats, même ceux qui ne sont pas vus pendant l'entraînement. L'exécution de ce calcul permet de résoudre le problème de démarrage à froid.
  • Le tour de candidats peut prendre en charge un ensemble arbitraire d'éléments candidats, y compris ceux qui n'ont pas encore interagi avec le système de recommandation. Cette prise en charge est possible, car les architectures à deux tours traitent des fonctionnalités de contenu enrichi et de métadonnées pour chaque <query, candidate> paire. Ce type de traitement permet au système de décrire un élément inconnu en termes d'éléments qu'il connaît.
• Vous pouvez optimiser l'inférence de récupération en précalculant tous les embeddings d'éléments candidats. Ces embeddings précalculés peuvent être indexés et déployés sur une infrastructure de diffusion optimisée pour la récupération à faible latence.
  • Le co-apprentissage des tours vous permet de décrire des éléments en termes de requêtes et inversement. Si vous disposez de la moitié d'une paire, comme une requête, et que vous devez rechercher l'autre élément correspondant, vous pouvez précalculer la moitié de l'équation à l'avance. Le précalcul vous permet de prendre le reste de la décision le plus rapidement possible.

Considérations de conception

Cette section fournit des conseils pour vous aider à développer une architecture de génération de candidats dans Google Cloud qui répond à vos besoins en termes de sécurité et de performances Les conseils de cette section ne sont pas exhaustifs. En fonction de vos exigences spécifiques, vous pouvez choisir de prendre en compte d'autres facteurs de conception et compromis.

Sécurité

Agent Platform Vector Search prend en charge les déploiements de points de terminaison publics et de cloud privé virtuel (VPC). Si vous souhaitez utiliser un réseau VPC, commencez par suivre la procédure Configurer une connexion d'appairage de réseaux VPC. Si l'index Vector Search est déployé dans un périmètre VPC, les utilisateurs doivent accéder aux ressources associées à partir du même réseau VPC. Par exemple, si vous développez à partir de Gemini Enterprise Agent Platform Workbench, vous devez créer l'instance de l'atelier dans le même réseau VPC que le point de terminaison d'index déployé. De même, tout pipeline censé créer un point de terminaison ou déployer un index sur un point de terminaison doit s'exécuter dans le même réseau VPC.

Optimisation des performances

Cette section décrit les facteurs à prendre en compte lorsque vous utilisez cette architecture de référence pour concevoir une topologie dans Google Cloud qui répond aux exigences de performances de vos charges de travail.

Profiler les tâches d'entraînement

Pour optimiser les pipelines d'entrée de données et le graphique d'entraînement global, nous vous recommandons de profiler les performances d'entraînement avec Cloud Profiler. Profiler est une implémentation gérée de TensorBoard Profiler Open Source .

En transmettant l'argument –profiler dans la tâche d'entraînement, vous activez le rappel TensorFlow pour profiler un nombre défini de lots pour chaque époque. Le profil capture les traces du processeur hôte et du matériel GPU ou TPU de l'appareil. Les traces fournissent des informations sur la consommation de ressources de la tâche d'entraînement. Pour éviter les erreurs de mémoire insuffisante, nous vous recommandons de commencer par une durée de profil comprise entre 2 et 10 étapes d'entraînement, puis d'augmenter si nécessaire.

Pour savoir comment utiliser Profiler avec Agent Platform Managed Training et Vertex AI TensorBoard, consultez la page Profiler les performances d'entraînement des modèles. Pour connaître les bonnes pratiques de débogage, consultez la page Optimiser les performances des GPU. Pour savoir comment optimiser les performances, consultez la page Optimiser les performances de TensorFlow à l'aide de Profiler.

Utiliser pleinement les accélérateurs

Lorsque vous associez des accélérateurs d'entraînement tels que des GPU NVIDIA ou des TPU Cloud, il est important de les utiliser pleinement. L'utilisation complète des accélérateurs d'entraînement est une bonne pratique pour la gestion des coûts, car les accélérateurs sont le composant le plus coûteux de l'architecture. L'utilisation complète des accélérateurs d'entraînement est également une bonne pratique pour l'efficacité des tâches, car l'absence de temps d'inactivité entraîne une consommation globale de ressources moins importante.

Pour utiliser pleinement un accélérateur, vous effectuez généralement quelques itérations de recherche du goulot d'étranglement, d'optimisation du goulot d'étranglement, puis vous répétez ces étapes jusqu'à ce que l'utilisation de l'appareil accélérateur soit acceptable. Étant donné que de nombreux ensembles de données pour ce cas d'utilisation sont trop volumineux pour tenir en mémoire, les goulots d'étranglement se trouvent généralement entre le stockage, les VM hôtes et l'accélérateur.

Le schéma suivant illustre les étapes conceptuelles d'un pipeline d'entrée d'entraînement ML :

Dans le schéma, les données sont lues à partir du stockage et prétraitées. Une fois les données prétraitées, elles sont envoyées à l'appareil. Pour optimiser les performances, commencez par déterminer si les performances globales sont limitées par le processeur hôte ou par l'appareil accélérateur (GPU ou TPU). L'appareil est responsable de l'accélération de la boucle d'entraînement, tandis que l'hôte est responsable de l'alimentation des données d'entraînement à l'appareil et de la réception des résultats de l'appareil. Les sections suivantes décrivent comment résoudre les goulots d'étranglement en améliorant les performances du pipeline d'entrée et les performances de l'appareil.

Améliorer les performances du pipeline d'entrée

• Lecture des données à partir du stockage : pour améliorer les lectures de données, essayez la mise en cache, prefetching, les modèles d’accès séquentiels, et les E/S parallèles.
• Prétraitement des données : pour améliorer le prétraitement des données, configurez le traitement parallèle pour l'extraction et la transformation des données, et ajustez la interleave transformation dans le pipeline d'entrée de données.
• Envoi de données à l'appareil : pour réduire le temps global de la tâche, transférez les données de l'hôte vers plusieurs appareils en parallèle.

Améliorer les performances de l'appareil

• Augmenter la taille du mini-lot. Les mini-lots correspondent au nombre d'échantillons d'entraînement utilisés par chaque appareil dans une itération d'une boucle d'entraînement. En augmentant la taille du mini-lot, vous augmentez le parallélisme entre les opérations et améliorez la réutilisation des données. Toutefois, le mini-lot doit pouvoir tenir en mémoire avec le reste du programme d'entraînement. Si vous augmentez trop la taille du mini-lot, vous pouvez rencontrer des erreurs de mémoire insuffisante et une divergence du modèle.
• Vectoriser les fonctions définies par l'utilisateur. En règle générale, les transformations de données peuvent être exprimées sous la forme d'une fonction définie par l'utilisateur qui décrit comment transformer chaque élément d'un ensemble de données d'entrée. Pour vectoriser cette fonction, vous appliquez l'opération de transformation à un lot d'entrées à la fois au lieu de transformer un élément à la fois. Toute fonction définie par l'utilisateur présente une surcharge liée à la planification et à l'exécution. Lorsque vous transformez un lot d'entrées, vous n'encourez la surcharge qu'une seule fois par lot, au lieu d'une fois par élément d'ensemble de données.

Effectuer un scaling à la hausse avant d'effectuer un scaling horizontal

Lorsque vous configurez les ressources de calcul pour vos tâches d'entraînement, nous vous recommandons d'effectuer un scaling à la hausse avant d'effectuer un scaling horizontal. Cela signifie que vous devez choisir un appareil plus grand et plus puissant avant d'utiliser plusieurs appareils moins puissants. Nous vous recommandons d'effectuer un scaling de la manière suivante :

1. Un seul nœud de calcul + un seul appareil
2. Un seul nœud de calcul + un appareil plus puissant
3. Un seul nœud de calcul + plusieurs appareils
4. Entraînement distribué

Évaluer le rappel par rapport à la latence pour la recherche vectorielle ANN

Pour évaluer les avantages de la recherche ANN, vous pouvez mesurer la latence et le rappel d'une requête donnée. Pour faciliter le réglage de l'index, Agent Platform Vector Search permet de créer un index de force brute. Les index de force brute effectuent une recherche exhaustive, au détriment d'une latence plus élevée, pour trouver les vrais voisins les plus proches d'un vecteur de requête donné. L'utilisation d'index de force brute n'est pas destinée à la production, mais elle fournit une bonne base de référence lorsque vous calculez le rappel lors du réglage de l'index.

Pour évaluer le rappel par rapport à la latence, vous déployez les embeddings de candidats précalculés sur un index configuré pour la recherche ANN et sur un autre index configuré pour la recherche de force brute. L'index de force brute renvoie les voisins les plus proches absolus, mais il prend généralement plus de temps qu'une recherche ANN. Vous pouvez être prêt à sacrifier une partie du rappel de récupération pour gagner en latence de récupération, mais ce compromis doit être évalué. Les caractéristiques supplémentaires qui ont un impact sur le rappel et la latence incluent les suivantes :

• Paramètres de modélisation : de nombreuses décisions de modélisation ont un impact sur l' espace d'embedding, qui devient finalement l'index de diffusion. Comparez les candidats récupérés pour les index créés à partir de modèles de récupération superficiels et profonds.
• Dimensions : les dimensions sont un autre aspect qui est finalement déterminé par le modèle. Les dimensions de l'index ANN doivent correspondre à celles des vecteurs de requête et de tour de candidats.
• Tags de regroupement et de filtrage : les tags peuvent fournir des fonctionnalités puissantes pour personnaliser les résultats pour différents cas d'utilisation en production. Il est recommandé de comprendre comment les tags influencent les candidats récupérés et ont un impact sur les performances.
• Nombre ANN : l'augmentation de cette valeur augmente le rappel et peut augmenter proportionnellement la latence.
• Pourcentage de nœuds feuilles à rechercher : le pourcentage de nœuds feuilles à rechercher est l'option la plus importante pour évaluer le compromis entre rappel et latence L'augmentation de cette valeur augmente le rappel et peut augmenter proportionnellement la latence.

Étape suivante

Pour découvrir d'autres architectures de référence, schémas et bonnes pratiques, explorez le Cloud Architecture Center.

Contributeurs

Auteurs :

• Jordan Totten | Ingénieur client
• Jeremy Wortz | Ingénieur client
• Lakshmanan Sethu | Responsable de compte technique

Autre contributeur : Kaz Sato | Évangéliste développeur principal