Explorez vos documents en profondeur avec Search Tuning sur Google Cloud Vertex AI Agent Builder

Commençons par le commencement : en tant que développeurs, nous attachons de l'importance aux noms, et il n'a pas toujours été simple de suivre l'évolution des appellations de ces fonctionnalités. Petit récapitulatif : initialement présenté sous le nom de Gen App Builder début 2023, le produit a été rebaptisé peu après Vertex AI Search and Conversation, et s'appelle aujourd'hui Vertex AI Agent Builder.

Maintenant que la bête a un nom, voyons ce qu'elle peut faire pour nous !

Vertex AI Agent Builder est l'approche de Google Cloud pour permettre à votre entreprise de tirer parti de la Gen AI sans complexité inutile. Le service masque une grande partie du travail nécessaire pour bâtir une IA conversationnelle, une expérience de recherche sémantique ou même un système de Retrieval Augmented Generation (RAG), et vous donne accès à ses modèles de fondation à l'état de l'art ainsi qu'à sa technologie de recherche mondialement reconnue, fruit de 25 ans de R&D.

Comparé à d'autres briques de la suite Vertex AI (par exemple l'API Gemini 1.5 Pro ou Vector Search), il se positionne plutôt côté managé du spectre : moins de personnalisation et de flexibilité, mais en contrepartie un time-to-market raccourci et un moindre besoin de profils internes rares.

Au sein de Vertex AI Agent Builder, nous avons accès à Vertex AI Agents et à Vertex AI Search :

• Vertex AI Agents propose un moyen simple de bâtir des interfaces conversationnelles à l'aide d'une plateforme de compréhension du langage naturel reposant sur de grands modèles de langage (LLM).
• Vertex AI Search, de son côté, vous aide à créer des expériences de recherche et de recommandation propulsées par l'IA.

Aujourd'hui, nous allons nous concentrer sur Vertex AI Search, puisque c'est ce produit qui propose Search Tuning et pour lequel nous présenterons un script de vérification de données.

Pour une introduction complète, consultez la documentation ici.

Au sein de Vertex AI Search, on peut créer des search apps et des recommendation apps. Aujourd'hui, cap sur les search apps.

Voici quelques-unes des fonctionnalités clés :

• Compréhension du langage naturel et recherche sémantique disponibles d'emblée. La recherche sémantique saisit le contexte et l'intention derrière une requête. À l'inverse, des approches plus classiques comme la recherche par mots-clés s'appuient sur la correspondance exacte de termes précis, sans en comprendre le raisonnement ni le contexte. Par exemple, pour la requête " Quand Apple a-t-il annoncé le dernier iPhone ? ", la recherche sémantique comprendra que l'on parle d'Apple Inc. et non de votre fruit préféré.
• Capacités natives pour comprendre les synonymes, corriger l'orthographe et suggérer automatiquement des recherches.
• Résumés et recherche conversationnelle propulsés par la Gen AI sur des documents non structurés. On peut par exemple choisir le type de réponse servie :

- Recherche (single-turn)

- Recherche avec une réponse (single-turn avec résumé)

- Recherche avec relances (multi-turn)

La mise en place de Vertex AI Search se déroule, à grands traits, en deux étapes :

1. Préparation : on configure un data store en y ingérant des données structurées ou non. Elles sont traitées, découpées en chunks et embeddées avec leurs métadonnées, puis stockées pour la récupération dans la base vectorielle ultra-performante de Google Cloud, Vector Search. Quelques options de personnalisation restent disponibles : vous pouvez fournir votre propre schéma, vos propres embeddings (en Preview au moment de la rédaction), et même personnaliser le parsing et le chunking.
2. Runtime : c'est le moment où l'on interroge réellement le système avec l'entrée utilisateur. Il récupère les documents pertinents et génère une réponse à partir de ceux-ci (si c'est ce que vous voulez). Là encore, la personnalisation a sa place : vous fournissez bien sûr vos propres prompts, vous pouvez définir certains controls pour, par exemple, filtrer les résultats retournés, et vous choisissez entre des réponses courtes (snippets) ou des paragraphes plus longs (extractive answers ou segments). En revanche, impossible d'apporter votre propre ranker — mais on y revient plus bas !

Exemple d'extractive segment sur un data store non structuré (PDF). Notez que le numéro de page du fichier d'origine est repris dans la référence. (capture d'écran ajustée pour des raisons de place)

Et si la qualité des résultats de recherche obtenus ne vous satisfait pas pleinement ? Vous pouvez vous tourner vers la fonctionnalité Search Tuning (en Preview au moment de la rédaction) pour vos data stores non structurés. Lorsque les données à interroger sont très spécifiques à votre entreprise, un modèle générique peut peiner à effectuer une récupération précise. C'est là que nous intervenons ; et pour cela, il suffit de lui fournir quelques données !

Comment utiliser Search Tuning ?

Concrètement, vous devrez fournir 3, voire 4 jeux de données d'entraînement :

1. Training queries : les requêtes de recherche que vous attendez de la part de vos utilisateurs. Par exemple :

Quel est le ratio maximal élève/instructeur pour les plongées en eau confinée ?

2. Extractive segments : des extraits issus des documents du data store (votre corpus). Certains segments devront répondre à certaines des requêtes définies ci-dessus, d'autres non (les deux ont leur utilité : renforcer positivement et renforcer négativement le modèle). Ces segments doivent en outre être suffisamment longs. Par exemple :

## Ratios

### Eau confinée 10:1 — Possibilité d'ajouter quatre élèves plongeurs par assistant certifié.

### Eau libre 8:1 — Possibilité d'ajouter deux élèves plongeurs par assistant certifié

3. Relevance scores : ces labels d'entraînement relient les requêtes aux extractive segments via un score (entier non négatif), où 0 signifie que le segment n'est pas pertinent pour la requête, et plus le score est élevé, plus le segment est pertinent pour une requête donnée. Par exemple :

Le score de pertinence serait ici de 1, puisque le segment répond bien à la question posée.

4. (Optionnel) Test labels : ces données s'apparentent aux relevance scores, mais servent à évaluer les performances du modèle ajusté. Si vous ne les fournissez pas vous-même, Search Tuning utilisera 20 % des requêtes des labels d'entraînement définis au point 3.

Qu'est-ce qui pourrait mal tourner ?

Ces données sont fournies sous forme de fichiers et exigent un formatage précis ainsi que le respect de certaines contraintes. Plusieurs de nos clients rencontraient toutefois des difficultés à l'usage : ils obtenaient un Error Code 13, accompagné du message " Internal error encountered. Please try again. If the issue persists, please contact our support team. "

La cause racine ? Tous les fichiers ne respectaient pas les exigences décrites dans la documentation, mais le message d'erreur ne le signalait malheureusement pas. Pas de panique : DoiT à la rescousse ! Nous avons codé quelques vérifications simples qui vous aideront à détecter rapidement les fichiers mal formatés et à éviter l'erreur. Le tout est disponible sur GitHub et s'exécute aussi simplement que :

python search_tuning_checks.py.py <corpus_path> <query_path> <scoring_path>`.

Voici un exemple de sortie :

General dataset checks
 - - - - - - - - - - -
Number of segments in Corpus file that don't have a match in Scoring file: 6030
Number of segments in Scoring file that don't have a match in Corpus file: 1551
Number of queries in Query file that don't have a match in Scoring file: 0
Number of queries in Scoring file that don't have a match in Query file: 0
Documentation dataset checks
 - - - - - - - - - - - - - -
Training query requirements met: ✅ met
|___ Subcheck: At least one extractive segment per query: ✅ met
|___ Subcheck: At least 10 000 additional extractive segments: ✅ met
Extractive segment requirements met: ✅ met
Relevance score requirements met: ✅ met
|___ Subcheck: At least 100 segments that contain query answers: ✅ met
|___ Subcheck: At least 10 000 random segments: ❌ not met
|___ Subcheck: At least 10 000 segments with 0 as score: ✅ met
Corpus file requirements met: ❌ not met
Query file requirements met: ✅ met
|___ Subcheck: Same ids in query and scoring data: ✅ met
|___ Subcheck: Column 'score' contains non-negative integer values: ✅ met
Training labels requirements met: ✅ met

Les `general data checks` se contentent d'un contrôle d'intégrité des données fournies : tous les ID des segments correspondent-ils bien à un score, d'une part, et tous les ID des requêtes correspondent-ils bien à un score, d'autre part.

Les `documentation dataset checks` lancent les vérifications suivantes, telles que documentées par Google Cloud :

• Pour les données d'entraînement en général (les 3 premières vérifications)
• Pour le fichier Corpus
• Pour le fichier Query
• Pour le fichier Training labels

Mieux vaut viser le ✅ partout avant de soumettre vos fichiers, car la boucle de feedback peut s'étirer sur plusieurs heures !