Data Agents dans Fabric : Quand choisir Lakehouse vs Semantic Model ?

Phare Data

0:03[musique] [musique] Oh ! Bonjour et bienvenue sur Fardata, la chaîne qui éclaire vos données. Dans l'océan des données voir clair change tout. Sur Fre data, on décrypte les services de données d'analytique CDIA. Le tout avec un ton accessible, des choix techniques assumés. et une touche d'hermarin. Que vous soyez architecte d'analyse, data engénieur, product honur ou simplement curieux, Fardata vous accompagne pour comprendre les enjeux réels, éclairer les compromis et prendre de meilleures décisions et parfois avec le cri des mouettes dans bruit de fond. Si ce genre de contenu vous parle, n'hésitez pas à vous abonner. Cap sur l'épisode du jour. Aujourd'hui, on va faire une battle. On va parler des agents, des data agents et surtout répondre à la question que tout le monde se pose. Est-ce qu'il est préférable de brancher un data agent sur un Lhouse ou sur un sémantique modèle ? Et alors pour cette session un peu mouvementée, vous le verrez, je suis accompagné de Akram AK, le capitaine du Houseous prêt à défendre cette table Delta Coréum et Émilie, notre arbitre incorruptible. Bien sûr, de mon côté, vous l'aurez compris, je serai là pour défendre le sémantique modèle parce que dans cette histoire, il faut bien quelqu'un pour ramener un peu de logique métier dans ce chaos, mais je m'avance un peu. On va lever l'encre. Je vous laisse vous présenter d'abord. Oui, merci Romain. Euh, bonjour, je suis Akram, Cloud Solution architect chez Microsoft sur la partie data IA et aujourd'hui, je tiens la barre du Lhouse, la donnée brute, ouverte, sans filtre et croyez-moi, il a de quoi surprendre. Et bonjour à tous, c'est Milibo. Je suis Solution engineer sur la data et l'analytique chez Microsoft et je m'assurerai de d'avoir un combat qui soit équitable et qu'on ait des réponses à la fin. Parfait. Levons les voiles.

Data Agents dans Fabric : Quand choisir Lakehouse vs Semantic Model ?

1:58Et bien aujourd'hui, ce qui va nous intéresser, c'est la grande question. Les agents, est-ce qu'on les plug sur les houseous ou sur les modèles sémantiques comme nous l'a dit Romain ? parce qu'effectivement, on a beaucoup beaucoup de projets de définition d'agent chez nos clients et ils se posent tous cette question : quelles sont les meilleures performances, quel type de questions vont être mieux adapté au lous ou au modèle sémantique ? Et c'est ce qu'on va pouvoir démontrer au travers de cette battle. Donc les règles sont simples. Pour pouvoir justement faire un benchmark intéressant, on va vous fournir les mêmes données. Vous aurez les mêmes questions, la même plateforme qui sera bien sur fabrique, pas les mêmes fonctionnalités comme on l'a compris et on identifiera quelle est la bonne méthodologie à adopter pour créer nos agents. Mais avant ça, revoyons un petit peu de théorie pour comprendre ce que c'est qu'un fabrique data agent. Donc un fabrique data agent, c'est une interface no code qui va vous permettre de définir vos propres agents et les publier pour vos utilisateurs métier. Pour faire ça, on va pouvoir se

Microsoft Fabric Data Agent

3:01brancher sur un certain nombre de sources de données qui sont supportées au sein de fabrique et en externe au travers des shortcut, du mirroring et cetera. et vous allez avoir la possibilité de customiser votre agent en lui donnant un certain nombre d'informations complémentaires de façon à ce qu'il puisse répondre le plus pertinemment possible à vos questions. Et comme vous le voyez, une fois que l'agent est prêt, que vous l'avez bien testé, on va le publier au travers de différents canaux pour pouvoir le consommer. Et donc pour préciser un petit peu les règles du jeu, d'abord on est fairplay. Vous avez tous les deux une F32, donc une capacité de niveau F32. On va travailler sur un modèle de données relatif à des données médicales et vous aurez les mêmes questions à chaque round. On aura cinq rounds et on identifiera à la fin de chaque round quelle est la meilleure qualité de réponse. En terme euh de zone de jeu, vous aurez la création d'un fabrique data agent pour toi au travers d'un house et pour toi Romain sur un modèle sémantique. Vous allez avoir ensuite une décision finale sur qui a remporté la manche en fonction du nombre de CU consommé, en fonction de la rapidité à laquelle on a obtenu une réponse, en fonction des explications qui seront les plus claires possibles et bien sûr en ayant une confiance dans la réponse qui nous a été fournie. On évaluera tous ces critères à la fin de chaque round. Et ben c'est

Round 1 - Installation et configuration

4:32parti messieurs, on commence sur ce premier round où vous allez construire vos agents et on va tester quelques premières questions simples. C'est parti. Merci Émilie pour l'introduction. Alors le setup met d'abord un petit rappel sur un Lake en fait c'est tout simplement un grand entrepôt de données ouvert. Techniquement il s'appuie sur le format Delta parquet. Un format ouvert et universel. Ça veut dire que touses vos données restent lisibles par n'importe quel outil. Du SQL pour les analystes, du Spark pour les datas ingénieurs, Power BI pour les dashboard et cetera. Pas de format propriétaire, pas de copie cachée et surtout pas de données enfermé dans une boîte noire. Maintenant, regardez cette ce ligage de mon côté, le chemin, il est ultra court. On voit que mon data agent se branche directement sur le pas de couche intermédiaire. Lehouse et l'agent qui lit dessus, c'est tout. Résultat, moins d'objets à sécuriser, moins de pièces mobiles et une donnée toujours live. Voilà quelle vitesse enlève l'encre. Maintenant, passons à la démo pour voir le setup. Avec le Lake, je vais droit au but. Vous voyez ici que j'ai créé un workspace data agent battle 2. Je crée mon data agent et je lui donne le nom avec à la fin les chaos pour distinguer de celui de Romain. Et tout de suite dès que mon data agent il est créé, je vais pouvoir rajouter ma source de données qui est bien évidemment le Lhous. Donc c'est le CMS data like que je crée et là je le lis directement à mon data agent et puis j'aurai à faire trois actions. Les actions c'est que je prends les tables, je définis mon scope. Là j'ai cinq tables, ça sera les mêmes tables que Romain va utiliser après. Et c'est déjà prêt. On peut déjà commencer à poser nos questions, mettre nos printes et attendre les réponses de notre date agent. comme vous pouvez le voir ici avec une question simple. Super, merci Akram. Alors donc je prends la main pour la évoquer la création d'adapt agent sur un sémantique modèle. Donc vous voyez le lineage edge, il est un peu plus long certes, mais on va travailler sur le même jeu de données et puis on va travailler aussi bien sur des données qui sont en direct le l donc stocké sur le houseous que sur des données importées et ce pour des questions de performance. On verra s'il y a un gain ou pas. Donc commençons la première démonstration où je suis dans mon workspace, je vais créer un nouveau data agent encore une fois sur le même lout sur le même jeu de données, sur les mêmes tables queam. Donc ici de la même façon, je vais chercher ma source de données et là je choisis le sémantique modèle. Ça tombe bien, il y a plus de 20 millions, je crois, de sémantique modèles dans le monde avec déjà des relations, déjà des mesures, déjà une logique métier. Donc on imagine he les bénéfices que ça a que de pluguer directement un data agent sur ce jeu de données déjà enrichi de connaissance business. Et donc comme ceci, je vais pouvoir de la même façon poser une question pour savoir euh qu'est-ce que mon data agent a comme information à l'intérieur de celui-ci. Voilà. Et donc comme je le disais hein, plus de 20 millions de sémantique modèles dans le monde. Donc en fait pas besoin de les créer, elles sont déjà là, il y a plus qu'à les réutiliser. Donc sur ce premier round avec Akram, on a vu que on avait globalement une rapidité au départ pour pouvoir pluger notre agent parce queon a pas de modelling à faire, pas de modèle sémantique à mettre en place, pas de refr et cetera. Donc on arrive rapidement au besoin qui est de créer notre agent. Par contre, avec Romain, sur le modèle sémantique, on va pouvoir réutiliser des modèles déjà existants avec des métriques, des KPI, des relations entre les tables qui sont non seulement enrichis au travers de nos données et qui vont nous apporter des réponses intéressantes à la fin. Pour l'instant, sur ce premier round, on se donne une égalité sur la qualité de ces premières questions très simples. Euh, on va dire que on est égalité. Petite question par contre messieurs, vous avez commencé à poser vos questions en anglais. Est-ce qu'on aurait pu les poser en français aussi ? En effet, c'est vrai qu'on s'est attardé à poser nos questions en anglais, mais les LLM comprennent aussi le français, donc savent traduire les questions dans le langage qui est le plus propice pour comprendre le jeu de données.

Round 2 - Premiers Tests

9:05Et c'est parti pour ce deuxième round. Alors là, on a mis en place nos data agents, ils fonctionnent. Maintenant, on va essayer de les tester un petit peu avec des questions simples. Trois questions. La première sur le coût total des médicaments par an. On va aussi essayer d'avoir un top 10 des marques en fonction de leur vente totale en 2022 et ensuite on va essayer d'avoir le coût en fonction des réclamations. Montrez-moi ce que vous savez faire avec ça. Super. Ben commençons. Alors, je suis sur le datagent que j'ai créé précédemment et donc je lui pose une question. Quels sont le total des coûts par an de mes médicaments ? Et donc il réfléchit et puis va me donner la réponse. Et alors si on regarde un petit peu le détail de cette réponse, on va s'apercevoir que derrière il a exécuté une requête en DAX. Et oui, c'est le langage pour requêter nos cubes tabulaires, nos sémantiques modèles. Et donc c'est comme ça qui va pouvoir après retourner l'information. Donc de la même façon ici, je lui demande quels sont les top 10 des marques par rapport à leur vente en 2022. Et de la même façon, je vais pouvoir analyser le résultat mais aussi la requête qu'il a exécuté. C'est toujours intéressant pour benchmarker. Est-ce qu'il a utilisé les bonnes mesures que j'avais créé ou pas ? Et dernièrement le coût des réclamations. On va voir si la réponse est aussi pertinente. Donc on va poser les mêmes questions. Après Akram va poser les mêmes questions et on va voir si les réponses sont identiques entre ces deux agents. Sachant qu'on a pas fait grand-chose hein, on a juste rajouté ses sources de données pour le moment. Donc de la même façon ici, on voit qu'il utilise une mesure. Tiens, je suis intéressé de savoir quel sera le comportement dans le cas de de Akram sur le chaos directement puisque en effet la le C percem est une fonction est une mesure avec peut-être comme on le voit ici un certain nombre de règles business qui ont déjà des descriptions et ces fameuses descriptions on le verra sont peut-être très utilisées dans mon data agent pour être plus pertinent en terme de réponse. Les questions simples de mon côté, je commence par demander à mon agent quel est le coût total des médicaments par an, même question que Roma m'a posé déjà remarquer le temps de traitement rapide de mes questions s'il vous plaît. Et là regardez bien, il me sort aussi les chiffres par année de 2013 à 2023 mais surtout il me montre le SQL qu'il a généré, un simple select group buy, tout est là. 2è question le top 10 démarque par dépense totale. Et voilà et voilà le résultat mais regardez surtout le SQL en fait qui va se générer juste après. Un select top 10 un inner join entre ma table de fait et ma dimension que vous voyez juste ici avec un W sur 2022. L'agent il a compris tout seul qu'il fallait joindre deux tables et moi je vois exactement comment il a fait. 3è question, un piège, le coût par réclamation, une division qui dit division dit risque de division par zéro. Et là, l'agent protège son calcul directement sur la requête et vous voyez qu'il a mis un ulif seul, robuste et sans que je lui demande. En fait, Romain lui, son agent génère du DAX. En général, il connaît déjà les KPI, les réponses sont business friendly, je le reconnais. Mais moi, du langage naturel, je passe au SQL, transparent et auditable. Je vois exactement ce que fait l'agent et ça pour la confiance, ça n'a pas de prix. Émilie. Alors conclusion sur ce deuxème round. Donc on l'a vu avec Romain d'abord effectivement on va utiliser du langage naturel qui sera transformé en DAX et donc on bénéficie d'un modèle sémantique qui a déjà des KPI préchargés qui peuvent correspondre aux questions des utilisateurs et donc là on gagne beaucoup de temps et on est sur la fiabilité de la réponse. Du côté d'Akram, on a vu que on requête en langage naturel et ça se transforme en requête SQL. et il va de manière intelligente construire cette requête en faisant des relations et en évitant certains pièges. Par contre, on peut se dire que pour des requêtes sur lesquelles on aurait déjà des képiles instantianciés dans le modèle sémantique, on aurait une petite avance côté modèle sémantique. Et je rajouterai que dans mon modèle, j'ai catégorisé mes valeurs, ce qui permet pour une valeur peut-être financière d'avoir directement catégorisé le la valeur. Et donc dans les résultats du data agent, on verra toujours peut-être un dollar ou 1 € puisque déjà configuré dans le modèle. Alors que finalement côté la je ne suis pas sûr que tu puisses avoir ce genre de détail. Donc un peu plus de personnalisation sur la réponse apportée basée sur le modèle sémantique. On répondra à côté les ca sur la les prochaines round avec les complexes question et là il y aura aussi de la matière à faire côté les causes. Regardons.

Round 3 - Questions complexes

14:18Alors c'est parti pour le round 3. Dans ce round, on va avoir des questions un petit peu plus complexes. Donc on va voir comment ça se passe au niveau de vos réponses. Sachant que pour l'instant vous n'avez fait que euh vous connecter sur vos sources de données. Est-ce qu'il va y avoir quelques customisations à faire et comment est-ce que vos différents agents vont répondre ? On voit ça tout de suite pour les questions complexes et je commence volontairement avec un agent totalement nu. Aucune instruction, aucun exemple query. Je veux d'abord vous montrer ce qu'il fait par pure interprétation. Première question, une croissance année par année avec un top 5 des génériques. Tout seul, l'agent comprend la logique, pivote les de années, classe le résultat. C'est déjà un point de départ. 2è question intéressante, une dépense sur une classe thérapeutique entière. Et là, c'est intéressant, sans aucun glosseur, l'agent tente quand même de traduire la classe en médicament par lui-même. Il s'en sort, mais son interprétation, je ne contrôle pas ce qu'il met dedans. Et la troisème question et toujours sans instruction qui va venir juste après, on a pu euh on a vu qu'il sont est sorti sur la deuxème question. c'est que elle est beaucoup plus dure. Une analyse a plusieurs niveaux. Qu'est-ce qu'il a tiré de la croissance ? Qui l'a amplifié ? Par où agir ? Et là l'agent, vous allez voir, il cale. Il ne sait pas décomposer un problème aussi riche tout seul. Sans cadre, il atteint sa limite. Et c'est exactement ici que tout bascule. Parce que mon Lake House est ouvert et transparent, je peux le guider en langage naturel. Je lui donne trois choses. D'abord un rôle clair, un glossur métier comme les classes thérapeutiques et enfin le plus puissant des exemples query. Je pense pas que tu as ça. Romain. Je lui montre des modèles de raisonnement comme décomposer une analyse de driver. Ces exemples ne sont pas exécutés tels quel. Ils servent à éduquer l'agent, à lui apprendre ma façon de penser. Le problème, je sauvegarde et c'est tout. pas de refresh. Et donc là après instruction, je repose la première question mais cette fois avec les instructions actives, vous comme vous pouvez le voir euh même première question, le raisonnement est le même qu'avant, sauf qu'il s'appuie maintenant sur mon exemple query comme vous pouvez le voir ici, il applique automatiquement mon seuil de matérialité, formate proprement les montants, structure son SQL exactement comme je lui ai montré. Ce n'est plus l'agent qui a pru sa méthode, c'est ma méthode. La deuxième question que je viens de reposer sur la classe thérapeutique, c'est là que la différence est la plus parlante. Avant, l'agent devinait lui-même quel médicament composait la classe. Maintenant, il s'appuie sur le glossaire. Et l'exemple querri que je lui ai donné, la définition de la classe vient de moi. Elle est explicite, auditable et identique à chaque fois. On s'entraî c'est exactement ce qu'on veut. La 3e question maintenant il y joué il y a 30 secondes et maintenant l'agent la décompose parfaitement sur plusieurs requêtes comme vous pouvez le voir. Euh ce qui a tiré la croissance, qui l'a amplifié et où concentrer l'action en priorité, il ne se contente plus de répondre, il raisonne, il structure, il priorise, il priorise. C'est un peu le jour et la nuit. On va plus loin avec une 4e question. Et pour confirmer que ce n'est pas un coup de chance, euh une dernière question encore plus exigeante. Une métrique dérivée calculé à la volée comparée à un niveau rationnel puis décliné par territoire. L'agent l'enchaîne comme vous pouvez le voir ici sans brancher parce que maintenant il a le cadre, le vocabulaire et surtout les exemples pour le faire. Donc en conclusion en fait sur les quatre questions, les instructions et les exemples query transforment vraiment un agent générique comme on a pu le voir avant en un expert de mon domaine. Je vois, je corrige, j'améliore. Aucune boîte noire ne vous offre ce niveau de de détail et de contrôle. Très impressionnant. Maintenant regardons côté sémantique modèle. Et alors que tu devrais répéter ces instructions dans le X data agent qui consomme ton houseous, on va voir que via les sémantiques models, cette information est définie dans son modèle. Donc n'importe quel dat agent de main bénéficiera de ces informations. On va voir ça en détail. Donc ici, première question, donc je retrouve le résultat, le même. Tous nos résultats sont identiques. Et ici, je lui demande donc quelque chose d'assez plus compliqué. Et il y a notamment des termes que s'il a pas connaissance de ces termes, il va pas pouvoir répondre. Donc ici, par exemple, euh I was unable to retrave the information. Donc qu'est-ce qu'on va faire ? On va aller sur sémantique model définir une seule et une seule fois ses informations au niveau du prep data fori et donc ici comme son nom l'indique le prep data fori va nous préparer notre sémentque modèle pour qu'il soit consommé par ces fameux LLM. Donc de la même façon, moi je renseigne un certain nombre d'instructions. On voit que c'est pas au même endroit hein qu'on renseigne les instructions, mais finalement c'est assez avantageux je trouve que de le définir au niveau du sémantique model pour que chacun des agents qui réutiliserait ce sémantique modèle puisse bénéficier des mêmes informations. Donc ici, une fois que j'ai défini mon modèle et ses instructions, ben je retente la même question. Voyons voir si c'est mieux se débrouiller maintenant. Donc il fait son analyse et maintenant la réponse est différente. Il a réussi à me retrouver le même résultat puisque il a utilisé les instructions qu'il avait qu'on a défini au niveau du sémantique modèle. Autre question, qu'est-ce qui a euh gérer les tendances ? OK, de d'augmentation. OK, regardons ce qui sait faire. Donc le résultat est disponible. Encore une fois, je peux voir le DAX utilisé, les différentes mesures qu'il a soit créé, soit réutilisé du sémantique model. Et enfin, dernière question la plus complexe. On voit qu'il s'est aussi exécuté en plusieurs étapes cette analyse et donc j'obtiens le résultat attendu. Et donc pour conclure ce R 3, au travers d'Akram, on a vu que on avait des instructions qui allaient nous permettre d'ajouter du contexte métier comme des glossaires, des schémas, des règles business qui vont permettre de driver finalement l'agent sur la requête qu'il va devoir effectuer. On a aussi une chose très importante, ce sont les exemples qui vont pouvoir lui donner un cadre dans lequel il va pouvoir utiliser des représentations de requêtes qui ont déjà été faites avec leur leurs résultats pour pouvoir reproduire de nouvelles requêtes en fonction de la demande de l'utilisateur. Donc très intéressant de pouvoir personnaliser justement l'agent de façon à ce qu'il réponde à ses requêtes complexes. Et du côté de Romain, on a vu qu'on avait une fonctionnalité près de data for AI directement au niveau du modèle sémantique qui va nous permettre de la même façon d'ajouter des éléments du contexte métier avec des description des descriptions, des synonymes. On peut même y rajouter éventuellement des exemples de questions. Et donc on va à nouveau s'appuyer sur l'ensemble des des képiaill des règles qui ont déjà été mises en place dans le modèle sémantique pour répondre à ces questions complexes. Donc là, les deux finalement environnements nous permettent d'aller contextualiser, rajouter des informations métier pour répondre à ces questions complexes.

Round 4 - Performances

22:20Égalité messieurs, c'est parti pour ce 4e round messieurs. Dans celui-ci. Là, vous nous aviez bien prouvé que vous arriviez à adresser des questions complexes. Maintenant, ce que j'aimerais voir, c'est les performances pour répondre à ces questions. Donc, montrez-moi comment vos deux environnements vont pouvoir répondre à la question de l'utilisateur final le plus rapidement possible. Très bien, commençons. Donc en fait pour faire ces ces calculs de performance, ce qu'on a fait c'est qu'on a créé trois agents, donc sur le houseous, sur le sémantique model en mode direct le et un autre sur le mode import parce qu'on a voulu tester les performances. Et donc ce qu'on a fait c'est qu'on a créé un notebook qui va exécuter en parallèle les queries aux différents data agent, donc les mêmes. Et puis après, on va pouvoir comme ça comparer leur résultat pour après euh avec l'aide de copilote comparer les performances et avoir un verdict. Donc si on commence euh on pourra vous partager d'ailleurs ces notebooks qu'on a utilisé. Euh la première étape donc c'est que on a un certain nombre euh d'instructions sur euh ici euh mon sémantique modèle sur mon modèle en mode import. Donc en fait on a mis les mêmes instructions sur les différents sémantiques modèles. Ensuite euh j'ai été donc dans mon notebook qu'on vous partagera si vous voulez. Et ce qui est intéressant, puisqu'on a un SDK au-dessus des datas agents, on va pouvoir aussi en mode batch demander d'exécuter euh des queries et puis sauvegarder leurs résultats comme ça on va pouvoir voir euh lequel des dates d'agent fonctionne le mieux, les performances des réponses par rapport aux différentes questions. aussi on voit ici l'évaluation donc sur ces trois data agents en parallèle et on va sauvegarder le résultat de ces exécutions dans un house pour qu'après on puisse comparer lesquels ont bien répondu, lesquelles ont mal répondu, hein, puisque j'ai les réponses attendues et les réponses euh qu'on a aussi eu des des datas agents. Donc ici, je vois l'évaluation. Je peux même aller dans le détail et regarder la réponse comme si je l'avais fait manuellement. Maintenant ce que je fais, c'est que j'analyse dans une seule table ses réponses et donc ça nous permet voilà de comparer les performances d'exécution sur les mêmes jeux de question des différents data agents. Et donc on voit très clairement que le modèle en mode important. On voit aussi que le modèle sur le data agence sur la CAOS, ben n'est pas non plus à la traî en terme de performance, mais on en reparlera tout à l'heure. Maintenant, regardons l'export de diagnostic, hein, qui au passage vous permet de savoir sur quel LLM on utilise par les dates agents. Donc à l'heure, je crois d'enregistrement, on est sur le chat GPT. Tu te souviens AKRAM 4.5 ? C'est 4.5. Oui. Ouais. Euh donc ici maintenant que j'ai téléchargé les deux diagnostics plutôt que le délire parce que c'est quand même pas mal de lignes, ben je demande à à copilote de comparer les résultats. Ce qui est assez intéressant parce que il va y rajouter aussi des informations euh d'analyse. Donc ici, il me dit déjà que j'exécute les mêmes queries sur deux data agents qui sont sur des sources de données différentes. le mode direct le lake sémantique model et le mode le house. On voit qu'il m'analyse les queries donc c'est pas le même langage et puis après il va analyser le résultat les interpréter mais aussi comparer puisque j'ai les informations d'exécution les performances. Et donc on voit qu'à la comparaison, ben les deux requêtes ont pris tous les deux 20 secondes euh que certaines euh conclusions sont intéressantes comme le fait euh de pouvoir réutiliser les mesures côté sémantique modèle. Et donc résumons ce que Romain il a fait donc il a lancé un notebook sur Fabrique qui pose nos c questions aux trois agents. Donc l'agent qui est connecté au Lake House le bien et l'agent qui est connecté au sémantique model en direct lic et aussi l'agent qui est connecté au mode import. Et vous avez vu comment copilote il comp partout et on a remarqué que c'est le même protocole pour les trois. C'est assez équitable pour les trois sur la manière d'interroger. Maintenant euh pour côté performance, il y a deux façons de mesurer la performance que ça soit sur le temps de réponse pure. Et là on a vu sur le notebook à la fin que Roma il a montré que le modèle sémantique peut être plus rapide. Ces données sont en mémoire. Je prends peut-être quelques secondes de plus pour générer le SQL avec le data agent qui est sur le Lhouse, mais sur le coup, le Lake House peut consommer jusqu'à 40 % de moins. Et donc là, vous pouvez voir que sur ces exemplesl mon house, il m'a consommé 6300 euh versus le semique model avec 10000. Pourquoi ? Parce que vous pouvez voir le détail à droite, le côté Lhouse, la donnée ne pèse que 5 % du coût. Tout le reste c'est li la même pour tous. Le modèle sémantique, lui il ajoute une couche en plus euh que vous pouvez voir sur le niveau de du dataset. Et le house aussi peut-être euh des informations plus sur son côté performance, qu'il continue de s'améliorer avec deux fonctionnalités euh qui sont euh que j'adore, c'est que la première et c'est elle est toute nouvelle, c'est l'incrémental liquid clustering. En fait, pour faire simple, c'est que vos données delta avec le temps, il finissent éparpiller dans des centaines de petits fichiers, les fameux parquets dont on parlait tout à l'heure. Et c'est ce qui ralentit les requêtes. Avant pour ranger tout ça, on faisait du optimiz, on réécrivait toute la table, mais maintenant avec la partie incrémentale, on ne retouche que ce qui a changé. Et ça peut être plus rapide jusqu'à neu fois plus rapide. Et là, non seulement ça peut impacter les dates à agents qui sont connectés au niveau Lake House, mais même également Romain, il peut se connecter en direct lake également. Donc il y a aussi un impact indirect sur les dates agents qui euh qui sont connectés en direct l surtout. Euh et aussi la deuxième fonctionnalité c'est le time travel et ça c'est vraiment spécifique au sens où on imagine un bouton retour dans le temps sur vos données. Chaque modification des tables delta est versionnée comme un historique git. Mais pour la data, je peux interroger ma table telle qu'elle était hier. avant un changement par exemple raté et même restaurer une ancienne version pour l'audit, pour le débug ou pour un autre besoin et ça c'est inestimable et peut-être le modèle sémantique ne peut pas offrir ce genre de fonctionnalité. Donc soyons fairplay, le modèle de Romain était parfaitement préparé pour ces questions, d'où la performance qui était plus performant en en temps de réponse. Mais dans la vraie vie, peut-être on a jamais tout préparé d'avance. Et là, c'est le Lake House qui répond ouvert, économe et prêt à exploiter. Super point d'attention sur ces résultats. Euh c'est pas parce qu'on a trouvé sur notre jeu de données ces résultats que sur votre jeu d'oré, vous aurez les mêmes. Donc n'hésitez pas à faire des tests et c'est pour ça qu'on vous passera notre notre notebook afin que vous puissiez dans votre cas regarder les performances aussi bien en terme de coût CU que de temps d'exécution. Donc pour faire un résumé clair de cette 4e manche, de ton côté Acram, tu nous as montré des fonctionnalités intéressantes comme le time travel qui va permettre de récupérer les anciennes versions de nos données. Tu nous as montré qu'effectivement il y avait peut-être des requêtes un peu plus lentes du à la conversion en SQL, mais par contre que niveau consommation de CU, on est bien plus intéressant que ce qu'on peut faire sur un modèle sémantique. Par contre, côté modèle sémantique, même si on consomme un peu plus de CU, on capitalise toujours sur le fait que on est en inmémory et donc on aura des performances vraiment plus intéressantes. On sait que côté la house, on a des améliorations en cours et des customisations qui vont nous permettre aussi de gagner en plus en performance. Donc là, on est vraiment sur une égalité. Si vous avez des modèles sémantiques déjà en place avec beaucoup de mesures de KPI qui ont déjà été définies, ça peut être intéressant les utiliser avec forcément un coût peut-être un tout petit peu plus élevé, mais par contre si vous avez des données brutes sur lesquelles il est nécessaire de reconstruire un modèle sémantique, là l'approche du sera intéressante et à moindre coût.

Round 5 - Sécurité

31:34C'est parti pour cette 5e et dernière manche. Alors messieurs, vous le savez, quand on utilise des agents, la sécurité est un point fondamental. Je veux être sûr que mes utilisateurs n'aient pas accès à n'importe quelle donnée. Est-ce que vous pouvez me démontrer sur vos différentes environnements, sur vos différents environnements, quels sont les moyens que vous avez pu mettre en œuvre pour assurer cette sécurité ? Super ! Ben commençons avec le sémantique modèle parce que c'est pas nouveau. Dans un sémantique modèle, nous avons le RLS, euh l'OLS même qui vont nous permettre de limiter ce que les utilisateurs peuvent voir sur un même sémantique modèle. Donc ici, très simplement, je crée un nouveau rôle Miami et donc je filtre sur les données de Miami. Comme ceci, l'utilisateur qui sera dans ce groupe ne verra uniquement que les données de Miami. Donc ici, je rajoute les O6 dans ce groupe Miami. Et donc on imagine bien maintenant à droite euh j'ai les haut les O6 hein, en vérifant les O6 alors qu'à gauche j'ai l'administrateur. Je pose une question côté administrateur, je vais voir le résultat. Je pose la même question côté Léo et regardons si il a le droit de voir les informations. Donc comme c'est Miami, on suppose que oui. Maintenant à gauche, je demande la même question mais sur Houston. Et donc de la même façon, Léo, quel est le total des ventes à Houston ? Et là, on imagine ben qu'il ne va pas pouvoir répondre. Regardons ce qu'il nous dit. No data was fund. Donc le RLS sur le sémantique modèle configuré une seule fois n'importe quel data agent verra la sécurité forcée. Maintenant on sait aussi côté modèle en mode direct lake, je peux réutiliser la sécurité fine au plus bas niveau, à savoir sur le one leg. Et donc de la même façon, je crée ici un euh R level sécurité toujours sur Miami. Je rajoute les au-dessus. Maintenant, sur mon modèle qui est en mode direct, pas besoin de dupliquer cette couche de sécurité. Voyons voir comment ça se comporte. Et de la même façon, l'utilisateur ne voit pas les données. De mon côté, je vais poser la même question aux deux utilisateurs comme Romain il a fait. Donc, j'ai mon administrateur qui est à gauche de l'écran euh et lui, il peut obtenir la réponse en entier. et à droite mon utilisateur euh que j'ai appelé Akram 1, un simple viewer qui va se voir refuser euh l'accès à la colonne du coût. Donc même agent, même question de réponses selon l'identité. Donc comment euh cela est possible ? Donc en fait avec une seule ligne du SQL au niveau du endp, j'ai juste fait un deny sur la colonne totale des du coût de du médicament en fait Romain. Et là vous pouvez voir les utilisateurs en viewers et admin et donc là quand je rentre sur mon layout et sur mon SQL point, c'est la fonction d'in que j'ai mis en place pour enlever l'accès à cette colonne là. Et donc Romain, il a fait du one leg sécurité sur son modèle. Très bien. Moi aussi je peux le faire. le scurité, il impacte aussi le layout et les sémantique modèl mais en plus je peux le faire également au niveau du SQL point comme vous pouvez le voir sur l'écran avec le den règle de requête SQL elle est posée sur la elle-même donc elle prétend elle protège tout ce qui la touche le data agent mais aussi le Power BI Excel park tout ce qui touche à ce Lake et la sécurité elle ne vit plus sur l'outil mais elle vit dans la donnée et en plus imaginez je peux utiliser ce qu'on appelle le dynamic data masasking. En fait, sur la même chose avec des scripts, on euh euh on peut interdire une colonne et je peux laisser l'utilisateur l'avoir, l'utiliser dans ses calculs, ses agrégats tout en masquant les valeurs sensibles. En fait, c'est du PUR SQL queries avec des fonctions comme du random ou email. Et là, l'utilisateur, il peut manipuler la donnée sans jamais voir le détail confidentiel et ça c'est fabrique. Ce n'est possible qu'au niveau du SQL Point, pas ailleurs. Donc masqués sont supprimés, protégés sont bloqués. Voilà la vraie puissance d'une sécurité qui vit dans la donnée. Donc sur ce round concernant la sécurité, on a vu globalement une égalité. Vous êtes en capacité d'appliquer du Relevel Security au travers de Oneel Security, que ce soit directement sur le endpoint SQL ou au travers du DAX et de la capacité de de mettre en place du RLS sur nos modèles sémantiques. On a le dynamic data masking aussi côté Lake House mais qui peut être mise en place également côté modèle sémantique quand on est en dir query va pouvoir en bénéficier. Donc OK, je suis convaincu. Vous êtes capable de me sécuriser mes accès au travers de mes agents. Égalité. Alors, dernier round, round bonus. Moi, j'aimerais savoir si on pourrait pas

Round Bonus

36:59capitaliser sur les forces de ces deux environnements. Est-ce que vous pourriez pas me faire un agent qui soit capable d'aller interroger à la fois le house et le sémantique modèle pour avoir les réponses les plus pertinentes, les plus rapides et les plus sécurisées ? Nous l'avons fait. Nous l'avons fait. Donc ici nous avons nos différents dat agents et nous avons ici créé un data agent qui comme vous le voyez prend ces deux sources de données, le houseous et le sémantique model un peu le meilleur des deux. Et on a rajouté des agents instruction qui vont aiguiller quant à l'usage plutôt des données provenant duous ou plutôt provenant du sémantique model. Exactement. C'est c'est le but des des instructions romains dans le sens où on peut lui dire quand est-ce qu'il va interagir avec le sémantique model et quand est-ce qu'il doit interagir avec le Lake House. Et donc on va d'une certaine manière bénéficier des points positifs des de deux façons. Donc si il y a des euh réponses qu'on peut trouver sur des données brutes sur le Lake House, ben on l'aiguise et on faire le Lhous. Et sinon s'il y a des KPI déjà prêtes sur les sémantiques modèles, pourquoi pas ? Et sur un data agent, on peut rajouter plusieurs sources. Là, nous avons rajouté deux mais on peut en faire plusieurs, donner les instructions justement pour synchroniser tout ça. Et donc ici, on exécute une requête. Ouais. Tu voulais rajouter quelque chose ? Oui, je voulais rajouter par rapport au scoping que que je peux que je vois ici, même si la donnée peut-être elle peut être dupliquée sur les deux sources, on peut très bien en fait montrer que euh pour ces tablesl ben le scoping, on le prend côté house et on prend les tables qui manquent sur le côté sémantique model comme ça ça soit vraiment complémentaire entre les deux sources. Ouais. Donc ici, on voit que la première réponse é effectuée par les données en Daxe, donc au niveau du sémantique model. Alors qu'ici, il analyse les données du houseous pour répondre à cette deuxième question. Donc le même data agent, des questions différentes et une exécution en DAX, en SQL par rapport au plus pertinent par rapport à la question que lui a posé pour qu'il puisse y répondre. Effectivement, c'est vraiment puissant de voir qu'il utilise les exemples queries d'un côté et il utilise aussi les instructions de DAX dan. Donc c'est vraiment better together. On pouvait même rajouter une autre source du KQL pour avoir des réponses en temps réel avec une base de données KQL qu'on a fait avec le real time intelligence de fabrique. Et imaginez donc nous avons sémantique model avec des KPI qui sont déjà prêtes, les Lhous avec des données brutes et prêt à être utilisé et de une troisème source du KQL pour avoir les données en temps réel. Tout ça, on peut le synchroniser grâce aux instructions au niveau agent et c'est ce qui fait un peu le la force de toute cette synergie. Oui. Et là, on voit que pour répondre à une même question, il l'a découposé en allant chercher une partie des données sur la houseous puis après les corréler euh à des données issues du sémantique model. Donc conclusion de toute cette de tout ce benchmark, moi j'ai un peu l'impression que le gagnant s fabrique finalement parce que vous nous avez montré que on a une seule copie des

Conclusion

40:18données au niveau de Oneel qu'on va pouvoir exposer différentes façons. On a différentes expériences qui vont nous apporter des avantages pour pouvoir les requetter au travers de nos différents agents et une seule gouvernance pour pouvoir gérer toute la partie authentification, identité, droit d'accès et gouvernance de manière générale. On a des performances qui tiennent la route et donc j'ai envie de dire que bah finalement c'est fabrique le vrai vainqueur ici. Et alors pour continuer, sachez que à la build annoncé plein de nouveautés sur les agents. Par exemple un MCP serveur pour pouvoir interroger les agents. On a annoncé plein plein de choses. Donc n'hésitez pas à aller faire un tour et à suivre l'évolution de cette fonctionnalité que l'on enrichit au fur et à mesure. Et en parlant d'enrichissement, on a aussi annoncé il y a quelques mois ce que l'on appelle fabrique IQ au travers de l'ontologie. L'objectif, ça va être de rajouter une couche métier par-dessus les modèles sémantiques, les houseous de façon à amener du contexte qui soit global à l'ensemble de l'entreprise en créant des graphes avec des entités qui représentent les différents instances de l'entreprise. Et cette ontologie justement, on a annoncé à Build qu'elle était passée en G. Donc vous pouvez la tester et même la passer en production. Et ce fabric IQ va venir nourrir finalement un contexte de données pour avoir des réponses plus fiables au travers de nos agents en s'appuyant également sur deux autres briques Work IQ pour pouvoir capitaliser sur les documentations sur les euh les informations des utilisateurs en tant que tel sur quel projet il travaille sur quel document il travaillent avec quel collaborateur il travaille et sur Fund IQ qui va venir nous apporter euh une couche sur laquelle on va avoir une base de connaissance qui va permettre à nos agents de venir aller chercher de la documentation non structurée par exemple dans du SharePoint. Et quand on associe ces trois couches d'IQ, on a de la donnée structurée avec Fabrique IQ, de la documentation au travers de Fund IQ, un environnement de travail au travers de Work IQ, ce qui va permettre à nos agents d'être les plus pertinents possibles dans les réponses qu'ils vont apporter aux utilisateurs. Super, merci Émilie. Et on peut citer aussi le fait que ces datas agents créés dans fabrique peuvent être enrichis même à l'externe. On a cité notamment euh Microsoft Fundri et de plus en plus aussi on voit des framework couverts open agnostic qui euh pourraient on top des dates agagents fabrique aussi euh corréler d'autres sources de données. Super point d'attention. Si vous avez configuré les fabriques copilote capacity, hein, le fait de pouvoir consommer sur une autre capacité où sont hébergés vos items, euh faut savoir que les activités sur les datas agents sont aussi consommées sur cette capacité délié. He on a vu des clients avoir des des surprises là-dessus. Donc nous l'avons vu. Le vrai sujet n'est pas de choisir entre le house ou sémantique modèle mais de savoir quand il sait la bonne voile selon le besoin ou même de faire du better together. Akram Émilie un dernier mot. Oui ben bien dire Romain c'est c'est aucun navire seul en fait. de Lakeout, c'est vraiment pour creuser la donnée brute. C'est mon modèle, c'est plus les p des décisions qui serrent le métier. Donc de navire un seul équipage. Et là d'après ce qu'on voit sur Fabrique, les nouveautés qu' Milie a montré par rapport au build Fabrique on la voit plus comme une data plateforme mais vraiment le soleil a d'une entreprise qui sert les business via pas mal de data agents via une intelligence de IQ et et vraiment ça ça donne envie non seulement de tester tout ça mais aussi de voir la suite et qu'est-ce qui va en devenir de fabrique dans les prochaines années. Mais je voulais aussi vous remercier Capitaine Romain Amiral Milé aussi de de cet échange très intéressant en attendant la suite. Et je conclurai également par une très bonne bataille. Merci messieurs, c'était vraiment très enrichissant et finalement vous nous avez montré que l'enjeu c'est pas simplement de mieux exposer la donnée, mais c'est vraiment de permettre à ces nouveaux agents intelligents de bien comprendre l'entreprise. Donc c'est ce qui va nous permettre au travers d'IQ d'aller un cran plus loin, ce que l'on pourra voir par la suite. Ouais. Nous aborderons donc les ontologies dans un prochain épisode et on les passera à l'épreuve pour savoir aussi quels sont les avantages d'utiliser un data agent sur des ontologies. Ben merci à vous deux, merci à vous d'avoir suivi cet épisode sur Fard Data. Si vous avez des questions, n'hésitez pas à nous le mettre en commentaire. On vous dit à très vite pour de prochains épisodes et d'ici là, abonnez-vous à la chaîne. À bientôt. À bientôt. Merci. Merci. M.