Une base de connaissances, plusieurs agents : comment on la conçoit dans Foundry IQ

Plusieurs agents peuvent interroger la même base de connaissances derrière Microsoft Foundry IQ : la base se construit une fois par domaine et se connecte aux agents qui en ont besoin, au lieu de maintenir un pipeline de recherche par agent. Ce post parcourt comment se compose cette solution, quelles six décisions il faut prendre avant de connecter l'agent, comment se fait la connexion, et comment on prouve que la réponse revient étayée par la source. Ce qui suit vient du module « Get started with Microsoft Foundry IQ » de Microsoft Learn.

Le coût de ne pas avoir la base

Les modèles apprennent de larges motifs de leurs données d'entraînement et n'ont pas d'accès automatique aux informations privées ni à l'état actuel de l'organisation. Un assistant de dépenses, pour bien répondre, a besoin des politiques et procédures approuvées de la société ; une réponse générale d'Internet ne suffit pas. La génération augmentée de récupération (RAG) comble cet écart en récupérant le matériel pertinent et en l'ajoutant au contexte que reçoit le modèle avant qu'il ne réponde.

Le problème apparaît quand chaque agent construit son propre pipeline : traitement des documents, embeddings (la représentation numérique de chaque texte, pour pouvoir la chercher par sens), indexes, logique de récupération, permissions et supervision. Ce travail se répète par agent et les résultats deviennent incohérents entre eux. Microsoft Foundry IQ est la couche de connaissances gérée de Microsoft Foundry : elle connecte des données structurées et non structurées de systèmes d'entreprise et web, les organise en bases de connaissances réutilisables et renvoie des réponses pertinentes, compatibles avec les permissions et avec citations. En dessous, elle s'appuie sur une ressource Azure AI Search, le service d'indexation et de recherche d'Azure, qui apporte l'infrastructure d'indexation et de récupération.

Les trois composants de la solution

La base de connaissances est la ressource qui identifie une collection de sources liées et contrôle le comportement de la récupération. Elle offre à l'agent une seule interface pour récupérer depuis une ou plusieurs sources, au lieu de lui enseigner où chaque document est stocké : sans cette interface, chaque requête devrait pointer vers un emplacement précis, et l'agent devrait connaître le détail de stockage de chaque source. Sa configuration apporte trois pièces : un modèle d'IA générative qui soutient la récupération agent, des invites pour prioriser les sources selon le type d'information, et des instructions pour les réponses générées.

La source de connaissances est la connexion à du contenu indexé ou distant que Foundry IQ peut récupérer : indexes existants d'Azure AI Search, documents dans Azure Blob Storage, contenu Microsoft SharePoint, données Microsoft OneLake, contenu web public et Microsoft 365 Copilot Work IQ, entre autres. Le choix se fait en regardant trois choses : où sont les données autoritatives, avec quelle fraîcheur elles doivent être, et quelles permissions s'y appliquent.

La récupération agent est le processus qui planifie les recherches, cherche le contenu pertinent, classe les résultats et renvoie une réponse unifiée avec références de source. Avant de répondre, elle prépare le contenu indexé (découpage, génération d'embeddings et extraction de métadonnées), récupère par recherche hybride, vectorielle ou par mot-clé, coordonne plusieurs sources et exige les permissions utilisateur sur les sources prises en charge.

flowchart TD
    Agente[Agent qui répond] -->|question de l'utilisateur| Recuperacion
    Recuperacion[Récupération agent : planifie, cherche et classe] --> Base
    Base[Base de connaissances : regroupe les sources et régule la récupération] --> Origen1[SharePoint, OneLake et Azure SQL]
    Base --> Origen2[Indexes de recherche et données web publiques]
    Base --> Infra[Azure AI Search : indexe et récupère]

Le parcours est simple : l'agent interroge, la récupération agent construit le plan de recherche et classe ce qu'elle trouve, la base répartit la requête entre ses sources, et Azure AI Search fait le travail lourd d'indexation et de retour des fragments.

Une base, plusieurs agents

Avec un pipeline indépendant par agent, le même matériel se traite plusieurs fois et les réponses se ressemblent moins. L'exemple le plus clair : un agent financier sur les politiques de dépenses, un agent des installations du lieu de travail et un agent des vacances. Au lieu de trois pipelines RAG, on crée des bases de connaissances par domaine, une pour les politiques financières et une autre pour les installations, et on connecte chaque agent à celle dont il a besoin.

C'est là l'avantage central : les plusieurs agents partagent la même base, si bien qu'une amélioration des connaissances faite dans la base profite à tous les agents connectés. Et comme les bases sont offertes comme outils MCP, un agent peut appeler la base par un chemin standard, sans câble sur mesure entre chaque paire de systèmes. La connexion se déclare une fois et reste disponible pour les agents de la ressource, ce qui soutient l'idée d'une seule couche centralisée.

Les six axes de conception, avant de connecter quoi que ce soit

Une base doit contenir des sources qui vont ensemble et qui admettent un ensemble clair de questions. Tout fourrer n'aide pas : le contenu non lié ou contradictoire rend la récupération moins précise. En planifiant, six axes sont pesés :

Portée : quelles questions la base doit répondre.
Autorité : quels systèmes contiennent la source approuvée.
Fraîcheur : avec quelle rapidité les changements doivent être disponibles.
Métadonnées : titres, dates, catégories, emplacements ou identifiants qui aident à récupérer et à citer.
Qualité du contenu : complet, actuel, lisible et sans doublons.
Accès : quels utilisateurs et agents peuvent récupérer chaque élément.

La croisation entre deux de ces axes mérite une ligne à part. L'autorité décide quel système compte comme source approuvée ; l'accès décide quels utilisateurs et agents peuvent récupérer chaque élément. Elles se touchent parce que la récupération exige les permissions utilisateur sur les sources prises en charge : une base construite sans ce critère finit par renvoyer du matériel que l'utilisateur ne devrait pas voir. C'est pourquoi le sixième axe est aussi administratif que les autres : il soutient la promesse de réponses compatibles avec les permissions.

En pratique, une base de connaissances financières combine la documentation de la politique de dépenses hébergée dans SharePoint avec des données financières générales qui vivent dans une base de données. L'agent interroge la base et Foundry IQ coordonne la récupération des sources configurées.

La connexion, en six étapes

Dans un projet Foundry, créer ou connecter un service Azure AI Search qui prenne en charge la récupération agent.
Créer la base de connaissances et ajouter ses sources.
Créer ou choisir un agent avec un modèle déployé.
Ajouter la connexion de la base à l'agent comme outil MCP.
Définir les instructions d'utilisation.
Tester des questions et inspecter réponses, citations et activité des outils dans l'aire de jeux.

flowchart LR
    S1[1. Service Azure AI Search] --> S2[2. Base de connaissances avec ses sources]
    S2 --> S3[3. Agent avec son modèle]
    S3 --> S4[4. Connexion comme outil MCP]
    S4 --> S5[5. Instructions d'utilisation]
    S5 --> S6[6. Questions de test et révision des citations]

Le service de recherche vient en premier parce qu'il soutient tout le reste : sans la base créée et les sources chargées, l'agent n'a rien à interroger.

La dernière étape boucle la boucle : c'est là qu'on inspecte les réponses, les citations que l'agent a jointes et l'activité des outils qu'il a exécutée en répondant. Les trois lectures racontent le cas complet d'une question : ce qu'elle a récupéré, ce qu'elle a utilisé et ce qu'elle a fini par dire.

Les instructions décident du comportement

Connecter la base ne garantit pas que l'agent l'utilise bien. Ce qui est attendu se décrit dans les instructions, et elles doivent couvrir quatre points :

Quand récupérer : quelles questions ou quels domaines exigent la base.
Comment utiliser les preuves : fonder les réponses sur le contenu récupéré.
Comment citer : références de source inspectables.
Que faire quand les preuves manquent : confirmer l'incertitude ou escalader vers une personne ou un processus.

L'exemple qui suit résume le ton : utilise la base de connaissances pour répondre aux questions sur la politique de dépenses, fonde les affirmations factuelles sur le contenu récupéré, cite les sources appuyantes et, si la base ne contient pas assez d'informations, suppose que tu ne le sais pas au lieu de deviner.

Pour tester la récupération, il faut donner à l'identité du projet uniquement les permissions dont elle a besoin : le rôle Search Index Data Reader d'Azure AI Search permet la lecture de l'index qu'utilise la base. L'avertissement qui accompagne cette connexion est court et concret : revois les prérequis, la propreté de ce qui reste déployé et les coûts avant de la mettre à tourner.

Les questions avec des utilisateurs de permissions distinctes ne sont pas non plus une formalité. Comme la récupération exige les permissions utilisateur sur les sources prises en charge, tester avec des comptes qui voient des choses différentes est la manière de voir si ce filtre arrive jusqu'à la réponse finale.

Les tests avant production

Avant de laisser l'agent servir les gens, on teste avec des questions réalistes de plusieurs types : simples avec source claire, qui exigent plusieurs sources, ambiguës et qui doivent provoquer une clarification, sans réponse dans la base, d'utilisateurs aux permissions distinctes, et avec du contenu qui essaie de changer les instructions de l'agent.

La récupération et la réponse s'évaluent séparément. D'abord on regarde si Foundry IQ a renvoyé des preuves pertinentes, actuelles et autorisées ; ensuite si la réponse est fondée, pertinente, complète et bien citée. Séparer permet de localiser l'échec : évaluer les deux ensemble mélange le cas où il n'y avait pas de contenu avec le cas où la réponse a été rédigée mal. Avec le diagnostic séparé, chaque symptôme pointe vers un correctif différent, et la supervision continue qui tourne après la mise en production montre ces mêmes symptômes : trous de contenu, récupération faible, problèmes de permissions et instructions à affiner.

Ce qui reste

L'ordre importe : d'abord les six axes, ensuite la connexion. Une base mal délimitée, connectée à plusieurs agents, répartit le bruit avec la même efficacité avec laquelle elle répartit la bonne réponse. Et le travail de bien la construire se paie une seule fois, puisque l'amélioration faite dans la base partagée atteint tous les agents connectés.

Limite honnête de cette source : elle décrit le flux et sa gestion des permissions, et n'apporte pas de mesures de résultat sur un abonnement propre. Le saut de « ça marche dans le guide » à « ça marche ici » reste sans mesure.

*Source : le module « Get started with Microsoft Foundry IQ » de Microsoft Learn.*