Un Agent IA qui interroge Snowflake & Fabric

Phare Data

0:03[musique] [musique] Ouais, bonjour et bienvenue sur Farata, la chaîne qui éclaire vos données. Dans l'océan des données, voir clair change tout. Sur Far Data on décrypte les services de données d'analytique et DIIA. Le tout avec un ton accessif des choix techniques assumés et une touche d'marin. Que vous soyez architecte analyste data engéur ou product honur et ou simplement curieux Fardata vous accompagne pour comprendre les enjeux réels, éclairer les compromis et prendre de meilleures décisions parfois avec le cri de mouette en bruit de fond. Si ce genre de contenu vous parle, n'hésitez pas à vous abonner. Cap sur l'épisode du jour. Aujourd'hui, nous allons parler de self service agentique ou comment permettre à des utilisateurs médiés d'interroger leurs données en langage naturel et ce grâce à les tout en s'appuyant sur une plateforme mutualisée, on va voir qu'on va pouvoir requêter des données aussi bien dans fabrique que dans Snowfleak. Peut-on vraiment cacher la complexité derrière une simple conversation ? Comment un assistant peut-il savoir où chercher l'information et interroger le bon système au bon moment ? Pour répondre à ces questions, je suis en compagnie de Lucy et Marc. Je vous laisse vous présenter. Honur aux dames. Bonjour à tous. Je suis Lucine, je suis solution engineer chez Microsoft sur tous les sujets autour du développement applicatif et de l'IA sur Azur. Et de mon côté donc Marc AD, je suis Solution comme les SIL mais sur la partie data et analytics.

Avantages du partenariat Snowflake et Microsoft

1:40Aujourd'hui, beaucoup d'entreprises disposent de plusieurs plateformes de données. Certaines informations sont stockées dansflex, d'autres dans Power BI, dans Fabrique. Le problème, c'est que les utilisateurs doivent savoir où se trouve la bonne information avant de même poser de sa question. à moins de savoir ou de les avoir déjà unifiés au travers du Onelex, c'est ce qu'on prône chez Microsoft. Marc, tu peux nous en dire un mot ? Tout à fait. Euh donc Lucille et moi sommes dans des travaill pour des clients qui sont surtout sur le secteur du retail et beaucoup ont des environnements divers et variés avec notamment en tant que data plateforme, ils vont avoir un Snowflex et puis ils ont bah finalement la couche reporting et côté PowerBet. Et donc il nous sollicite en nous disant ben voilà, nous on veut créer des agents, on sait pas où les créer. On veut faire de la self service agentique, on sait pas si c'est dans fabrique, dans dans Snowflex et euh comment faire quoi finalement. Aujourd'hui, on la réponse, elle est assez simple. Pourquoi choisir ? Dans la mesure où vous avez une plateforme, vous avez une plateforme analytics d'un côté pour la partie Power BI et une plateforme de données côté Snowflex, vous allez pouvoir tirer partie des deux solutions avec des agents que vous avez certainement déjà créé. côté Snowflex puis d'autres côté Power BI pour faire de la service BI. Finalement, vous allez pouvoir croiser les deux. Donc c'est ça le le maître mot. Euh vous allez vous n'avez pas besoin de choisir, vous allez tirer partie des deux solutions. Si je reviens rapidement avant de laisser Lucil développer sur le partenariat qu'on a aujourd'hui entre Snowflake et Microsoft, c'est un partenariat qui est intéressant parce que quand on parle de Oneelake et d'intégration, l'idée c'est de pouvoir tirer partie des données de Snowflake avec ce que nous on appelle Oneelake qui est le notre stockage où on va faire bah pour le coup de la data verticalisation. L'idée c'est d'aller prendre les données de Snowflex sans pour autant les copier. et ensuite en tirer partie avec no workload côté côté Microsoft fabrique dont notamment Power BI. Donc ça vous avez cette intégration qui est facilité via le via ce partenariat. Puis euh de manière assez simple hein, si vous avez une marketplace côté Azure et que vous avez un contrat côté côté Microsoft, vous allez pouvoir rapidement provisionner votre votre compte Snowflex et puis forcément vous allez avoir aussi la sécurité puisque vous serez dans un environnement Azure et donc finalement votre Power BI fabrique se rapproche de votre Snowflex et vous n'aurez pas bah tous les coûts réseaux que ça pourrait induire et toute la sécurité sera mise en place. Et avant de commencer, Lucile, tu peux nous rappeler ce que c'est un agent ?

Agent AI ?

4:13Ouais, tout à fait. Alors, ce qu'on entend par ce mot, en fait, c'est un programme ou une application qui va être basée sur un modèle de langage, ce qui va lui permettre de comprendre quand un humain va lui parler va lui parler en langage naturel. Mais contrairement au chatbot plus classique, plus traditionnel, euh en fait l'agent IA, c'est un expert sur un domaine d'expertise. Euh et donc pour ça, on va lui passer des instructions pour qu'il comprenne euh ce qu'il doit faire et on va l'outiller. Et la grande différence, c'est qu'en fait il peut prendre des actions basées sur ces outils. Un outil peut être enrichir ses connaissances avec des méthodes de rag. Donc par exemple, aller récupérer des informations dans un datalec. Et euh si on veut lui faire faire des actions, on peut lui donner par exemple euh via des protocoles comme de la HTTP assez classique de appel d'API ou du MCP euh la possibilité de inscrire une donnée dans une base par exemple. Donc un agent ça peut à la fois raisonner mais aussi faire des actions. Et ben c'est justement ce qu'on a ce qu'on a fait avec cet agent, cet agent qu'on a

Plateforme de référence pour l'Agentic Self BI

5:13développé d'enfanterie. Mais d'abord ce qui est intéressant donc comme comme l'expliquait Marc, c'est que on a un patrimoine existant avec deux sources de données qui viennent de plateformes data plateformes différentes avec des agents en fait qui existent déjà sur ces sur ces plateformes. Ce qui fait que bah ces agents ils sont spécialisés et ils ont accès à une donnée euh euh à une donnée connue qui existe sur cette plateforme. Euh sur Fenderie en fait, on a orchestré du coup différents appels euh qui passent euh enfin qui les agents vont être appelés via des protocoles. Alors ça peut être du MCP dans dans ce cas-là, ça pourrait être de l'oué. Ce qui est intéressant ici, c'est qu'en fait aussi bien sur Snowflex ou sur Fabrique, une fois que les agents ont été développés, ils sont compatibles avec ces protocoles standardisés, open source. Et donc bah en fait très rapidement d'enfanterie, on a pu configurer un agent qui était capable d'appeler l'un ou l'autre et de comprendre quand est-ce que l'un ou l'autre devait être appelé. Euh ensuite, une fois qu'on a terminé de développer notre agent, ce qui est important, bah c'est de pas donner accès à une plateforme technique à quelqu'un qui va être métier, mais c'est que l'agent, il soit disponible quel que soit l'environnement de travail de l'utilisateur final. Et donc en fait, on aime on a tendance à dire chez Microsoft que les agents doivent vous rejoindre dans votre écosystème. Et donc par exemple si votre entreprise est dans l'environnement M365 et ben votre agent il devrait être publié euh dans M365, disponible dans Teams, disponible dans Copilot ou très très simplement être embarqué dans votre portable web métier et donc disponible là où vous travaillez. En plus des éventuels avantages he qu'on connaît de Microsoft Fund mais peut-être qu'on les rappellera tout à l'heure. Quel était le bénéfice d'utiliser un agent côté Snowflake versus l'unification via la virtualisation de l'accès aux données côté fabrique à Snowflake et pour avoir finalement qu'un seul agent data agent dans fabrique et après peut-être cette couche au-dessus de dans Microsoft fonderie. C'est une très bonne question et justement il faut se mettre à la place du client. le client aujourd'hui a forcément développé déjà des agents dans Snowflake parce qu'il a testé forcément ses ses features qui sont mis en avant par Snowflex et donc ils ont déjà des agents qui sont testés, évalués et qui sont déjà, on va dire production ready. Et l'idée c'est de pas tout refaire en disant bah je vais prendre toutes les données qu'il y a déjà dans mon Snowflex, les mettre dans mon fabrique pour refaire le même type d'agent. Là, c'est vraiment tirer partie de ce qui a déjà été fait et ne pas avoir une double maintenance aussi parce que ces agents déjà qui existants dans Snowflex, peut-être que si je les reproduit dans fabrique, il va falloir que je euh remette à chaque fois à jour et cetera et cetera. De de l'autre côté, on pourrait se dire bah ce qui a été déjà fait dans dans dans Fabrique au travers les reportings et cetera, les dates à agents, je pourrais le remettre aussi dans Snowflake parce que la donnée la donnée basse, la couche basse là que vous voyez tout en bas, je l'ai déjà. Donc ce qu'il y a dans finalement dans dans Fabrique, je pourrais le recréer dans Snowflex au travers les mesures et cetera, mais j'ai justement créé des sémantique modèle dans Power BI et je vais capitaliser dessus pour ne pas recréer cette couche là dans Snowflex. Voilà. Donc en résumé si cette là synthétique montre bien quel agent est aujourd'hui dans la picture et surtout à quoi il servent. Donc on a le fabrique data agent qui est l'agent on va dire officiel des reporting de l'entreprise au travers le data agent sur Microsoft Fabrique. Il connaît donc il a le sémantique modèle qui est existant et il va pouvoir se baser dessus pour répondre aux questions. On a ensuite l'agent plus détaillé donc l'agent Snowflex qui va pouvoir faire du drill done dans les données et aller assez finement dans les transactions si je me mets dans dans un dans un dans une dans un monde retail où je peux aller par exemple jusqu'au ticket de caisse. Et puis j'ai cet agent intelligent, l'agent orchestrateur qui va faire le routage et qui va savoir en fonction de la question du client router justement sur ces agents-là. Et il peut très bien aussi combiner, ça c'est un point important, l'agréger et le détailler parce que rien neche un client de demand enfin un business user de poser une question qui mêle euh des agrégations et du détailler. Et c'est ça aussi toute l'intelligence qu'elle va avoir la l'agent fonderie, c'est de dire je vais prendre le mix des deux sources de données qui me sont données au travers les deux agents qu'on vient de décrire pour pouvoir répondre de manière complémentaire. C'est finalement la même logique quand on s'adresse à une seule personne qui va consulter après les spécialistes appropriés avant de revenir avec la réponse. Mais qu'est-ce que Fondri apporte en plus de ce simple routage intelligent ? Ouais. Alors effectivement là on a simplifié un petit peu le rôle de Fenderry comme l'agent orchestrateur mais en fait il faut comprendre que Microsoft Fund c'est une plateforme

Microsoft Foundry

9:54dédiée pour le développement agentique. On a expliqué il y a il y a quelques temps ce que c'était un agent. On a dit qu'on avait besoin d'une chose, bah en fait c'était un modèle. Euh sur Fenderie, tu as la possibilité de déployer des modèles dans ton environnement Azure euh grâce à un catalogue de modèles. À date, aujourd'hui, on a plus de 12000 modèles disponibles. Alors, on a des euh des modèles providers euh type enropique. On a aussi du mistral, euh du dipsic disponible sur la plateforme. En fait, l'idée c'est de permettre au client de choisir le meilleur modèle du moment par rapport à son business case, par rapport à ses données. pour choisir, bah en fait, tu as 12000 modèles, tu vas te dire comment je fais ? Bah, tu as accès à pas mal de fonctionnalités. Par exemple, tu as accès à des leaderboard pour comprendre quel est le modèle le plus efficace versus quel est le modèle le moins cher par rapport soit donc à des leaderboard, mais tu as aussi la possibilité d'évaluer, de comparer des modèles entre eux. Une fois que tu as choisi tes modèles, tu vas même pouvoir faire des opérations de fine tuning. Euh, tu vas pouvoir prendre un modèle et lui apprendre de nouvelles compétences basées sur ton jeu de données. Bref, tu as tout ce qu'il faut pour euh euh manager le life cycle d'un modèle euh parce qu'en plus, on le sait, les modèles, ils sortent très vite et donc en fait les nouvelles versions de modèles, bah elles déprécie les autres. Donc en fait bah sur la plateforme tu vas vraiment pouvoir un gouverner tes modèles. Après on a vu qu'un agent c'était pas seulement un modèle en fait c'était un modèle plus des instructions plus du tool calling. Bah en fait pour ça tu as besoin d'un framework euh et la plateforme vient avec son propre framework pour développer un agent qu'on va appeler agent services. Ce framework qui est à la fois le code parce qu' tu peux développer des agents via une interface. C'est assez simple à prendre en main via un playground mais aussi Procode parce que tout ça vient avec un SDK et en fait bah tu peux en Python, en DNET, en Java, tu vas pouvoir développer tes agents. Tu vas pouvoir développer un agent et le publier sur Fandry et le voir sur l'interface et inversement, tu vas pouvoir créer un agent sur Fundry et le récupérer dans le code et itérer dessus. Donc cet agent que tu vas développer via Agent Services, en plus on va préconfigurer pour toi en tant que développeur dans ton entreprise bah l'ensemble des outils auquels tu as le droit. d'avoir accès. Bah par exemple ici, on parle de Snowflake, de fabrique data agent, tu vois, on va potentiellement préconfigurer l'accès à ces agents pour toi. Euh typiquement pour se connecter à Snowflake, bah on avait besoin d'utiliser le MCP, on avait besoin d'avoir une API et cetera et cetera. Donc en vraiment là, tu as un environnement qui est préconfiguré pour toi, prêt à l'emploi et typiquement on veut pas non plus que tu ailles utiliser des outils qui sont non homologué dans ton entreprise. Euh donc là on a développé notre agent mais on a aussi besoin de s'assurer que notre agent il fait pas n'importe quoi parce que là derrière bah en fait tu as des cas d'usage de métier. Donc en fait si on renvoie pas la bonne donnée, si notre modèle il hallucine et cetera, bah tu as besoin de mettre en place de l'évaluation et tu as besoin de mettre en place de l'observabilité. Comment les deux choses fonctionnent ensemble ? L'observabilité, c'est ce qu'on va appeler du tracing. C'est à chaque fois que mon utilisateur va poser une question, donc un input, et ben je contrôle ce qui est envoyé en output par mon agent. Et à chacune des étapes, je peux mettre de l'évaluation pour automatiser en fait cette observation. Par exemple, si mon agent commence à répondre euh à côté de la plaque quand on va lui poser une question sur nos données retail, par exemple, il me répond une recette de cuisine, j'en sais rien, bah en fait, je veux pouvoir me créer des alertes et ça c'est parce que j'ai mis en place des évaluateurs qui vont vérifier la fluency, la cohérence dans la réponse de mon agent. Euh voilà, donc ça c'est, tu vois, c'est c'est l'ensemble des outils qui sont là pour gouverner euh ton agent une fois qu'il est parti en production. Mais aussi à chaque fois qu'on va itérer sur notre agent, bah finalement, on va créer des nouvelles versions. Comment on s'assure qu'on n pas en rajoutant une source de données, en rajoutant une action créer une régression en fait euh dans notre use case agentique ? Bah encore une fois, on a besoin de mettre en place une stack d'évaluation, une stack d'observabilité. Donc en fait, tu vois, on retrouve un peu toutes ces tous ces principes du développement d'une application non générative. euh bah on on retrouve toutes ces bonnes pratiques en fait quand on va développer un agence sur la plateforme Fendré. Euh donc je vais parler euh justement d'outiller en fait ces agents. Donc c'est préconfiguré. Donc c'est ce qu'on voit dans la partie tool. En fait tu as accès à des connecteurs euh préconfigurés typiquement les fabriques data agents, appeler des agents via du MCP ou même faire de l'way. Et tu as plein de tools qui sont qui sont voilà qui sont prêts à l'emploi disponible. euh facilement récupérable et et facilement découvrable aussi pour un développeur. Donc ça peut être tes tools, ça peut être tes modèle disponibles au sein de ton entreprise, ça peut être l'ensemble tes MCP, ça peut être aussi des des API plus classiques, ça peut être aussi des agents via et Fundry IQ. Fundry IQ, ça te permet de te faire du rag multisource. Donc en fait, ça va pouvoir te permettre d'indexer plein de sources de données différentes. Typiquement des données non structurées qui viennent de base de données vectorielles, euh mais aussi euh des données qui peuvent venir euh par exemple bah une donnée que je vais récupérer via du MCP et c'est ce qu'on a fait euh via le Snowflake Data Agents et par exemple une donnée métier qui va aller se trouver dans un SharePoint. En fait, avec Fundry IQ, je vais pouvoir définir plein de sources de données différentes et c'est pas mon agent qui va faire du retrieval, c'est Fundry IQ qui va le faire. Ça veut dire ici par exemple, je pourrais avoir un modèle qui est enfin je peux setup fundri IQ avec un modèle euh spécialisé euh plus compétent pour aller faire du retrieval et avoir un modèle beaucoup plus léger dans mon orchestrateur euh dans mon orchestrateur. Donc là aussi, on a des pratiques de Finups. Comment je vais optimiser le temps de réponse, comment je vais optimiser ma gestion de coût des tokens parce qu'on sait que c'est aussi une grosse grosse problématique et d'ailleurs comment je m'assure que mon agent déjà il déraille pas dans la qualité de ses réponses mais en plus il me coûte pas trop cher. Comment je m'assure qu'il est pas en rein de consommer mon ensemble de de quota que j'ai pour pour un modèle donné et cetera. Bah pareil, en fait, j'ai euh toute une partie qu'on appelle le contrôle plane euh qui va me permettre de gouverner tous mes agents au sein d'une d'une souscription Azure et de voir bah combien euh de tokens il consomment, quel modèle ils consomment, euh combien de fois ils ont combien de fois ils ont été appelés, est-ce que j'ai eu des fail request et cetera et cetera. Et enfin, dernière chose, tu as aussi l'ensemble des outils DI qui sont pas des outils type LLM ou ou SLM, mais ça va être des outils di plus classiques, par exemple, des outils d'ossérisation, donc document intelligent conn que vous avez peut-être précédemment utilisé sur d'autres portails. Aujourd'hui, tout est unifié dans Microsoft Fundering qui vient vraiment la plateforme ou le portail Azure pour LIA euh disponible donc sur Azure, disponible via SDK. Donc vous êtes pas obligé de prendre toutes les fonctionnalités, mais vous allez pouvoir par exemple utiliser une fonctionnalité en particulier via le SBK et euh disponible aussi à edge avec ce qu'on appelle fonderie locale donc qui va donner euh possibilité d'utiliser euh d'utiliser l'ensemble de ces fonctionnalités mais at Edge. Voilà. Super, très clair. Merci. Alors vous nous montrez ça en début.

Demo

17:09Tout à fait Romain. Alors là, on va parler un petit peu du jeu de données he qui est un sample que généré avec sans données de pubit copilot qui est un un jeu de données plutôt retail. Donc puisque on s'adresse là sur un use case retail, on a plus c'est pas c'est pas la volumétrie qui compte mais vraiment le le principe. On est sur sur une petite volumétrie mais qui est qui est vraiment représentatif de de jeux de données retail qui qui existe sur le marché. euh des clients, des produits, des catégories, des magasins, des commandes et des lignes de vente. Voilà, aussi simple que ça. Donc dans le runbook de notre démo, euh la première chose qu'on va faire, c'est de finalement d'interroger les agents unitairement. Donc si je prends l'agent Snowflex, on va poser des questions du style euh bah donne-moi la leaffiche du client le plus dépensié. Et donc on est vraiment sur de la donnée détaillée. Si tu avances sur la slide d'après, on fera la même chose sur l'agent finalement le data agent côté fabrique où là on va lui demander bah une logique plus capille et ensemble sur bah donne-moi le chiffre d'acur par région et par et par saisonalité et cetera. Donc là on montrera de manière comment on va interroger ces agents-là dans les environnements respectifs puis on le fera de manière globale avec l'agent fondré. Donc voici un exemple de de questions qu'on pourrait poser et comme vous le voyez à chaque fois on va appeler tel ou tel agent en passant par l'IM de l'agent Fondré et lui seul va savoir reuter la bonne question et là où je voulais en venir tout à l'heure c'est que vous voyez on va pouvoir mixer des questions agréger et détaillé dans le même dans la même question de l'utilisateur qui est notre meilleur client à Grenoble et comment le compare et comment se compartil au niveau CA bah là finalement il va aller prendre les données de chaque agent donc tirer partie des données agrégées et déta détailler pour ensuite faire un mixte dans la réponse. Donc là, on passe tout de suite à un environnement pour ceux qui connaissent bien Snowflex. Donc toutes mes données je le rappelle sont dans Snowflex he il y a pas de débat, c'est la data plateforme. Donc là, on voit les données clients, un modèle décisionnel, donc là c'est en étoile avec des catégories, des customers et cetera. Et on passe tout de suite à l'interface de l'agent Snowfleck. Euh donc dans l'agenceflec on va avoir bah un peu on va un peu comme dans tous les outils, on va mettre des instructions, des descriptions et on va aller bah détailler comment il doit répondre, comment euh comment les connecteurs pour lui donner en endpoint MCP. Et une fois qu'on a fait ça, on est parti, on va l'interroger. La première question, c'est assez simple, c'est à quoi il sert finalement cet agent ? Alors, la chose que je trouve intéressante dans Snowflex, c'est qu'il y a un reutage automatique de du LLM en fonction de la la complexité de de la question. Donc ça peut être du Jupt4 pour des questions plus simples et puis plus complexes avec de l'entropique. Donc ça c'est une chose intéressante. Donc voilà dans la complexité des questions que je vais poser. Donc là je lui demande quelle est la fiche client le client le plus dépensé. Là il va aller donc me retrouver la question. Donc c'est une question assez simple. Et là, il il saura lui reuter euh ses ses cré sauce Snowflake, hein, de de deutiliser le LM qui va bien pour être pour euh vraiment travailler sur le les l'aspect Phinops. Donc voilà, on voit ça euh on voit ça de manière assez simple. Donc c'est plutôt pas mal et ça répond assez vite. Euh et puis justement, j'ai voulu poser une question beaucoup plus complexe sur le chin de de nos clients où là il va falloir avoir du reasoning et bah de de manière assez assez bluffante, il a réussi il va réussir à me répondre en me faisant des graphiques, en me faisant des choses très intéressantes sur le CHN. Euh donc voilà, on voit la la puissance de de l'agent qui a été créé côté Snowflex et qui permet de faire du détaillé et surtout d'avoir de la valeur ajoutée dans les dans dans dans la question et dans les réponses qui que qu'on va les poser. Donc vous voyez, c'est il va me faire une élaboration assez complexe et euh et et avec des graphiques. Donc c'est c'est plutôt plutôt cohérent et plutôt intéressant. Euh maintenant, je vais passer euh dans un produit qu'on connaît bien sur sur F data, c'est euh l'interface fabrique. Donc là euh j'ai mon sémantique model et je vais aller créer mon data agent un top. Euh donc ça c'est voilà le rapport hein assez simple avec des capill euh sur le chiffre d'affaires. Donc on voit bien que c'est de l'agrégé, des commandes, la saisonnalité et euh les produits. Donc un rapport assez classique hein mais mais qui euh qui est utilisé toute le bah pour le par les business euh pour faire de l'analytics aujourd'hui. [grognement] Euh donc j'ai mis on top de ça mon data agent où je vais pluguer une seule source de données, c'est mon sémantic model. Là, de la même façon de qu'on l'a fait avec Snowflex, je vais lui donner des instructions pour lui dire "Bah, tu es un analyste euh tu vas me répondre sur des données agrégé et cetera et cetera." Euh et donc quand il va me répondre, on connaît le principe du data agent, il va faire de la translation entre le langage naturel et le code d'axe euh qui est le la le langage euh technique pour interpréter un sémantique modèle, pour interroger un sémantique modèle. Et donc là, il va me répondre "Là, je suis sur le playground, hein. Euh, de la même façon, j'étais sur le playground côté Snowflex. Euh et donc il me répond avec des régions euh et donc de manière agrégée. Voilà, maintenant je passe à la partie fendrier. Voilà, donc bienvenue sur Fender. Donc comme je vous le disais juste avant, il faut vraiment imaginer Fendri comme le portail AI d'Azure et en fait on y accète via cette URLi.azazur.com. Euh donc moi, je suis dans mon dans mon projet surfenderie et si je pars dans la partie build, juste là, ben là vous voyez la liste d'agents euh actif sur ce projet et euh notre fameux retail router euh euh fabrique Snowflex. Euh rappelez-vous ce qu'on se disait pour faire un agent, bah il me faut un modèle. Voilà, je peux choisir parmi tous les modèles que j'ai déjà déployés dans ma dans ma ressource fandie, mais je pourrais aller prendre plus de modèles. Et comme on comme on le disait, on a passé des instructions à cet agent et enfin on l'a équipé cet agent. Donc en fait via du MCP, on récupère les données qui proviennent donc de l'agent que nous a montré Marc juste avant de Snowflake et via duoué et une connexion native avec le fabrique data agents d'enfanterie et ben en fait on se connecte à aux fabricents que nous avons Marc juste avant. euh on pourrait rajouter euh plein d'autres choses à cet agent, mais du coup, si on pose la question euh justement euh agrégée euh à notre agent, etth ben en fait, on va voir euh comment il nous répond et euh sur quoi il s'appuie pour nous répondre. Donc voilà, là on voit que bah finalement notre agent, il nous a répondu, il a agrégé euh différentes sources de données. Et en fait, ce qui va être intéressant ici sur Fender, bah c'est de s'assurer en fait de la cohérence de ce qu'il me dit. Déjà, j'ai quelques métriques opérationnelles. Là, je peux voir le nombre de tokens qui ont été consommés euh suite à cette interaction. Et si je vais sur la partie tracis ici, en fait, je vais pouvoir un petit peu voir ce qui s'est passé. Euh donc là, je vais pouvoir en fait récupérer euh bah en fait toutes les métadata liées à ma conversation avec mon utilisateur. Euh donc là, on voit que l'agent a été appelé, on voit comment il a été appelé euh et on voit l'output qu'il a donné. on va se rendre compte de deux choses. Un, il est parti un petit peu regarder euh dans sa mémoire, par exemple, il sait que moi je préfère communiquer avec lui en français. Euh et ça, en fait, il il est capable de de savoir qui je suis. Et vous allez voir juste après, en fait mon identité, elle est connue parce que je suis connectée euh je suis connectée sur sur Fendri avec mon identité Microsoft et en fait là, il allait taper dans les deux dans les deux agents parce que je suis autorisée à le faire. Euh et donc là en fait euh ce qui est intéressant euh bah c'est qu'on on se rend compte euh quel est euh quel est l'outil qu'il a appelé. Donc euh on se rend compte comment il a appelé euh l'agent côté Snowflake et on va voir aussi comment il a appelé l'agent côté fendrier. Donc là en fait on voit toutes les réponses qui lui ont été envoyées parce que là finalement tu as mixéas dans ta question tu as mixé une demande avec de l'agrégé du détail. C'est ça. Exactement. Exactement. Est-ce que tu peux voir combien ça t'a coûté ce en token ? Ouais, en fait je peux voir combien ça m'a coûté en token et je peux voir combien ça m'a coûté à chacune des étapes. Alors ici, tu nous montres le nombre de tokens qu'on a utilisé pour finalement agréger ces deux sources d'information. Est-ce que on a aussi l'information des deux data agents en terme de consommation qui te sont remontés aussi ici ? Ouais. Alors justement ici là on voit le nombre de tokens qui a été consommé à l'ensemble de ces étapes là. On peut ensuite aller regarder chacune à chacun des tool exécution par exemple le nombre de input output token vraiment lié à cette step et après justement et je vais laisser marque compléter euh mais par exemple sur fabrique on n pas accès puisque le service en fait le LLM il est managé pour nous. C'est c'est exactement ça en fait. Là, on va avoir vraiment le coût côté côté agent orchestrateur. Et comme vous le savez, donc il y a deux agents fils, on pour ainsi dire, on ils ont leur propre LLM. Donc, pour pouvoir vraiment avoir une big picture. Du coup, il faut aller voir combien ça coû consomme en terme de CU dans la capacité du data agent lorsqu'il a été interrogé. Et de la même manière, côté Snowflex, vous avez une partie feedups et vous pourrez voir combien ça a coûté côté Snowflex. Alors là, ce que tu nous montres, c'est encore un playground. Est-ce que tu peux nous montrer une interface qu'on utiliserait ou que les utilisateurs métiers utiliseraient ? Ouais, tout à fait. Alors, comme je te je te le disais juste avant, bah Fandri c'est euh c'est une interface, c'est un playground et tout est disponible via le code. Euh tu as aussi via l'interface la possibilité de publier ton agent dans Teams et Microsoft 365 copilot. En fait, qu'est-ce que ça va faire pour toi ? Ça va te créer un bot framework qui va te permettre du coup de distribuer après ton agent dans ton ton écosystème ou ton environnement M365. Et donc une fois qu'on a publié notre agent dans l'écosystème N365 et ben en fait il est complètement découvrable en fait bah comme n'importe quel agent dans dans Copilot dans Teams. Et là typiquement vous avez accès du coup à ma conversation avec le Routel Agent Azure Xfleake. Et typiquement là bah en fait bah je vois sa réponse et je vois même la source de données en fait qui a été utilisée. Donc voilà, l'agent en fait il vient me il vient me il vient à moi dans mon espace de travail.

Conclusion

27:15Super, merci pour cette démonstration. Ce qu'il faut retenir dans cet épisode, c'est qu'on s'oriente plutôt vers des systèmes multiagents où chaque composant apporte une expertise spécifique mais finalement rendu disponible au travers d'un seul point de contact. C'est plutôt impressionnant. Oui, puis on voit aussi l'ouverture de Microsoft où on peut vraiment naviguer avec et déser avec toutes les tous les partenaires qu'on a là en l'occurrence c'est Snowflex mais on est vraiment sur des protocoles open source où on va pouvoir bah utiliser et tirer partie de ce que les les clients ont mis en place. Tout à fait. Il y a pas besoin de choisir. En fait, vous avez des environnements hybrides. Du coup, on va créer des agents qui sont capables bah de de s'interconnecter à votre environnement. Et derrière, on va rajouter une couche de gouvernance, d'observabilité, donc tout ce qu'on va appeler le contrôle plane, bah pour s'assurer que nos agents, ils se comporte bien, euh contrôler qui a accès à quoi et cetera et cetera. Ouais, les utilisateurs finalement passent moins de temps à chercher où est l'information et la donnée, mais plus de temps à prendre des décisions et c'est ce qu'on souhaite. Donc, merci beaucoup pour cet échange, pour cette démonstration. Merci à vous d'avoir suivi cet épisode sur Fard Data. Si vous avez des questions, des retours d'expérience ou si vous souhaitez creuser un point en particulier, n'hésitez pas, les commentaires sont ouverts. On vous dit à très vite pour un nouvel épisode. D'ici là, passez un bon été, gardez le cap et abonnez-vous à la chaîne. À bientôt.