DeepEval Framework (2026 Edition)

Salut, c'est Alex de DEV STORIES DOT EU. DeepEval Framework, épisode 1 sur 18. La plupart des équipes évaluent leurs modèles de langage fraîchement déployés en lisant manuellement un tableur de réponses. C'est lent, très biaisé, et impossible à scaler quand l'application grandit. DeepEval est le framework d'évaluation open-source qui remplace ce travail manuel, et qui fonctionne concrètement comme le Pytest des LLMs. Imagine que ton équipe déploie une nouvelle application générative. Tu dois t'assurer qu'elle se comporte correctement avant de la pousser en production. Avec DeepEval, tu écris des tests exactement comme tu écris des tests unitaires Python classiques. Tu crées un fichier nommé test example point py. Dans ce fichier, tu construis un test case. Cet objet test case contient le prompt d'input initial, l'output réel généré par ton application, et toutes les réponses cibles attendues. Tu appliques ensuite une métrique d'évaluation à ce test case. Au lieu d'utiliser un test d'égalité standard pour voir si la variable A correspond parfaitement à la variable B, tu utilises une fonction d'assertion spécialisée fournie par le framework. Tu lances ce fichier depuis ta ligne de commande en utilisant la commande Pytest standard. Le framework exécute les tests en parallèle, attrape les assertions, et signale les succès et les échecs directement dans ton terminal. Voici l'idée clé. Les tests déterministes standards ne peuvent pas évaluer la qualité ou la précision du langage humain. Si un utilisateur demande à ton application le résumé d'un document, il y a des milliers de façons correctes de l'écrire. Les patterns regex et le string matching exact sont inutiles ici, car ils ne peuvent pas interpréter le sens sémantique. DeepEval gère cette variabilité massive en utilisant un concept appelé LLM-as-a-judge. Le framework utilise un modèle de langage généralisé et très performant pour évaluer les outputs spécifiques de ta propre application. Le modèle juge lit l'output de ton application, le compare aux critères stricts de la métrique que tu as sélectionnée, et calcule un score numérique. Plus important encore, il renvoie un résultat booléen indiquant si le score atteint ton seuil prédéfini, accompagné d'une raison en plain text expliquant exactement pourquoi il a donné ce score. Ça veut dire qu'un test échoué te donne un contexte de debugging immédiat. Lors de la conception de ces test cases, tu dois choisir entre deux modes d'évaluation distincts. C'est facile de confondre la portée de ces modes, alors traçons une ligne claire. L'évaluation end-to-end regarde uniquement l'input initial et l'output final. L'application entière est traitée comme une black box. Tu fournis un prompt, le système donne une réponse, et le juge note ce texte final. Ça ignore complètement comment l'application a généré la réponse. L'évaluation au niveau des composants est une approche white-box. Au lieu de juste vérifier la réponse finale, ce mode trace les étapes internes spécifiques que ton application a suivies pour y arriver. Si ton système cherche dans une base de données pour récupérer des documents de contexte avant de générer son texte, un test au niveau des composants évalue cette étape de recherche spécifique. Il vérifie si les documents récupérés étaient vraiment pertinents par rapport au prompt de l'utilisateur, de façon totalement indépendante de la réponse générée finale. Tu testes la mécanique interne, pas juste le produit final. Tu peux avoir un système qui passe un test end-to-end en donnant une bonne réponse, mais qui échoue à un test au niveau des composants parce qu'il a tiré cette réponse du mauvais document interne. Évaluer un modèle de langage n'est plus un exercice de lecture subjectif ; c'est une pièce rigide, automatisée et répétable de ton pipeline d'intégration continue. Merci d'avoir écouté, happy coding tout le monde !

Salut, c'est Alex de DEV STORIES DOT EU. Framework DeepEval, épisode 2 sur 18. Tu ne peux pas mesurer ce que tu n'as pas défini. Si tes évaluations automatisées te semblent incohérentes, le problème commence souvent avant même que la metric ne s'exécute. Tu passes probablement les mauvais composants de ton prompt aux mauvaises limites d'évaluation. La solution, c'est de définir strictement l'interaction LLM en utilisant le blueprint du test case LLM. Un test case LLM dans DeepEval sert d'unité atomique d'évaluation. Il te force à isoler une interaction unique et spécifique avec ton système. Tu ne passes pas des logs de conversation complets ou des bases de données brutes à un évaluateur. À la place, tu extrais exactement l'input, l'output, et les données de background impliquées pour un tour bien précis. Les interactions multi-turn ont leur propre blueprint spécifique, mais le test case standard se concentre strictement sur une requête et une réponse isolées. Chaque test case demande deux arguments obligatoires. Le premier, c'est l'input. C'est la string exacte qu'un utilisateur ou un système a soumise au modèle. Le second, c'est l'actual output. C'est le texte que ton LLM a généré en réponse. Même si tu n'évalues rien d'autre, tu dois fournir ces deux paramètres pour mesurer des metrics de base comme la toxicité ou l'answer relevance. Imagine un chatbot de support client. L'input, c'est un utilisateur qui demande s'il peut retourner une paire de chaussures usées après trente-cinq jours. L'actual output, c'est ton modèle qui génère une réponse pour refuser le retour. Pour évaluer si ce refus est vraiment correct, tu dois fournir une vérité de base. DeepEval te donne deux paramètres optionnels différents pour ça. Ce sont l'expected output et le context. Les développeurs les confondent constamment. Le context est strictement factuel. Il contient la vérité brute, non formatée, comme une string tirée de ta politique d'entreprise qui indique une limite stricte de remboursement de trente jours. L'expected output est beaucoup plus spécifique. Il dicte le ton, la linguistique et le formatage. Tu utilises l'expected output quand tu veux que l'évaluateur vérifie si le modèle a répondu avec des excuses polies et précises, plutôt que de juste sortir un refus brutal. Le context ancre les faits. L'expected output ancre le style et la formulation exacte. Voici le point clé. La façon dont tu construis le reste de ce test case change en fonction de ton architecture sous-jacente. Si tu évalues un pipeline Retrieval-Augmented Generation, tu dois définir le retrieval context. Ce paramètre accepte une liste de strings qui représentent les chunks de documents exacts que ton retriever a tirés de la vector database. Ne confonds pas ça avec le paramètre context standard. Le context, c'est la vérité idéale que tu hardcodes pour le test. Le retrieval context, c'est la vraie donnée que ton pipeline a réellement trouvée en production. Les évaluateurs comparent les deux pour déterminer si ton algorithme de recherche récupère les bons documents. Si tu construis un agent plutôt qu'un pipeline standard, tu utilises le paramètre tools called. Il accepte une liste d'objets ou de strings représentant les fonctions spécifiques que l'agent a décidé d'invoquer pendant cette interaction isolée, comme le déclenchement d'un calculateur de remboursement interne. Fournir ça te permet d'évaluer les décisions de routing de l'agent en même temps que la génération de texte finale. La fiabilité d'une metric automatisée est entièrement liée à l'hygiène de ces paramètres. Un évaluateur ne pourra jamais pénaliser une hallucination si tu ne fournis pas le context factuel strict avec lequel il vérifie l'output. Merci de m'avoir écouté, happy coding tout le monde !

Salut, c'est Alex de DEV STORIES DOT EU. Framework DeepEval, épisode 3 sur 18. Les métriques NLP traditionnelles comme BLEU et ROUGE sont nulles pour évaluer les grands modèles de langage modernes, mais mobiliser un humain pour chaque test run est impossible. La solution pour scaler ton évaluation sans sacrifier la compréhension sémantique, c'est la puissance du LLM-as-a-Judge. Les métriques traditionnelles cherchent des correspondances exactes entre les mots. Si ton modèle sort un résumé parfaitement précis en utilisant des synonymes différents, une métrique basée sur un string matching exact lui donnera un mauvais score, parce qu'elle ne peut pas comprendre le sens. Utiliser un LLM comme juge résout ce problème. Il lit l'output, process le contexte et évalue la sémantique un peu comme le ferait un relecteur humain, mais à la vitesse d'une machine. Dans DeepEval, une métrique évaluée par un LLM effectue trois actions spécifiques. Premièrement, elle calcule un score entre zéro et un. Zéro est un échec total, un est parfait. Deuxièmement, elle compare ce score à un threshold strict que tu définis. Si ton threshold est de 0,7 et que le modèle obtient un score de 0,6, le test fail. Troisièmement, elle renvoie une raison. Le LLM qui évalue génère une explication textuelle qui détaille exactement pourquoi il a attribué ce score spécifique. Ça te dit ce qui s'est mal passé sans t'obliger à lire manuellement les raw logs. DeepEval divise ces métriques en trois catégories. Les métriques RAG évaluent les pipelines de Retrieval-Augmented Generation. Les métriques Agentic évaluent les agents autonomes. Les custom metrics te permettent de définir tes propres critères d'évaluation from scratch. Bien que les prompts sous-jacents soient différents, elles utilisent toutes le même mécanisme de juge. Quand ils choisissent une métrique, les développeurs confondent souvent les métriques reference-based et referenceless. Voici le point clé. Les métriques reference-based nécessitent une ground truth. Elles ont besoin d'une réponse connue et correcte pour faire la comparaison, ce qui les rend super efficaces pendant les premières phases de développement et de testing. Les métriques referenceless n'ont pas besoin de ground truth. Elles évaluent l'output en se basant entièrement sur le contexte fourni ou sur le prompt d'entrée lui-même. Comme elles ne reposent pas sur une réponse pré-écrite, les métriques referenceless sont exactement ce que tu utilises pour le monitoring en live production. Il est tentant d'attacher une douzaine de métriques à chaque prompt pour garantir la qualité. Ne fais pas ça. La règle générale, c'est d'utiliser moins de cinq métriques par application. Choisis les métriques qui s'alignent vraiment avec ta business logic spécifique. Faire tourner des métriques inutiles ne fait que ralentir les tests et augmenter les coûts de compute. En parlant de coûts, utiliser un modèle commercial flagship pour juger des milliers de test runs quotidiens devient vite cher. DeepEval te permet de remplacer l'évaluateur par défaut par des custom models. Tu peux configurer le framework pour utiliser Azure OpenAI si ton infrastructure d'entreprise l'exige. Alternativement, tu peux setup un modèle local en utilisant Ollama. En faisant tourner un modèle open-source performant en local sur ton propre hardware, tu crées un juge gratuit et impartial. Tu initialises simplement ton client Ollama local et tu passes cet objet model directement dans la configuration de la métrique. DeepEval gère ensuite le reste, en exécutant tout le pipeline d'évaluation sans taper sur des API de facturation externes. La vraie valeur d'un juge LLM n'est pas juste le score numérique, mais le raisonnement automatisé qu'il fournit pour t'aider à débugger chaque échec. Merci d'avoir écouté, happy coding tout le monde !

Salut, c'est Alex de DEV STORIES DOT EU. Framework DeepEval, épisode 4 sur 18. C'est une chose si ton pipeline RAG répond à une question. C'en est une tout autre s'il invente avec aplomb des détails qui n'existent pas dans tes documents sources. Aujourd'hui, on va regarder comment évaluer les generators RAG, et plus précisément comment détecter exactement ce genre d'erreurs. Un pipeline de Retrieval-Augmented Generation a deux composants distincts. Le retriever récupère les documents pertinents. Le generator prend ces documents et écrit la réponse finale. On ignore le retriever aujourd'hui. On part du principe que ton système a déjà récupéré les bons documents. On se concentre strictement sur le generator qui synthétise le texte. Pour t'assurer que ce texte est à la fois sûr et utile, tu te bases sur deux métriques : Faithfulness et Answer Relevancy. La première métrique, c'est Faithfulness. C'est ton principal garde-fou contre les hallucinations. Faithfulness mesure si la réponse du generator, que DeepEval appelle l'actual output, peut être entièrement justifiée par le retrieval context. Prends un scénario standard. Un utilisateur pose une question à ton chatbot sur la mutuelle de l'entreprise. Le retriever récupère le bon manuel RH. Le generator répond que le contrat couvre les frais médicaux, l'optique et une couverture dentaire complète. Sauf que le manuel RH ne mentionne jamais la couverture dentaire. Le generator a synthétisé un mensonge très plausible et bien formaté. La métrique Faithfulness détecte exactement ce comportement. Elle isole les affirmations faites dans l'actual output et les vérifie une par une par rapport au retrieval context. Si le generator inclut des faits absents du contexte, le score de Faithfulness baisse. Peu importe si le fait s'avère être vrai dans le monde réel. S'il n'est pas explicitement soutenu par le contexte fourni, la métrique le signale comme un échec. Maintenant, le deuxième élément, c'est Answer Relevancy. Une réponse fidèle n'est pas forcément une réponse utile. Le generator pourrait te sortir un résumé parfaitement exact du manuel RH qui ignore complètement ce que l'utilisateur a vraiment demandé. Answer Relevancy mesure à quel point l'actual output répond directement à l'input d'origine. Elle évalue si la réponse est complète, concise et sans blabla inutile. Si l'utilisateur demande le montant de la franchise, et que le generator liste la franchise mais ajoute ensuite trois paragraphes sur l'histoire de la mutuelle de l'entreprise, le score de Answer Relevancy diminue. Le système pénalise les informations évasives ou verbeuses aussi strictement que les informations manquantes. Pour évaluer ces métriques, tu construis un test case dans DeepEval. Tu dois fournir trois variables. Premièrement, l'input, qui représente le prompt de l'utilisateur. Deuxièmement, l'actual output, qui est le texte que ton generator a produit. Troisièmement, le retrieval context, qui contient le texte brut des documents que ton retriever a fournis au generator. Tu passes ce test case aux deux métriques. DeepEval évalue le texte et calcule un score entre zéro et un pour chacune. Tu définis un seuil de réussite. Si une réponse obtient zéro virgule neuf en Faithfulness mais zéro virgule quatre en Answer Relevancy, tu sais que le generator est sûr mais inutile. Si les scores sont inversés, ton generator est utile mais il hallucine complètement. Voici l'idée clé. Quand tu évalues des generators, tu dois systématiquement dissocier la vérité du contexte. Un bon generator ne dit pas la vérité absolue ; il dit exactement ce que les documents fournis lui permettent de dire, en répondant uniquement à ce qui a été demandé, et rien de plus. Merci d'avoir écouté, et bon code à tous !

Salut, c'est Alex de DEV STORIES DOT EU. Framework DeepEval, épisode 5 sur 18. Si ton LLM donne de mauvaises réponses, ce n'est peut-être pas la faute du modèle. Ton retriever lui donne peut-être juste n'importe quoi. Aujourd'hui, on parle de l'évaluation des retrievers RAG, et plus précisément de Contextual Precision, Contextual Recall et Contextual Relevancy. Imagine que tu interroges une grande base de connaissances pour un détail très précis sur une règle. Au lieu d'extraire le paragraphe exact dont tu as vraiment besoin, ton retriever récupère dix pages de texte vaguement lié. Le LLM se perd dans le bruit, le coût en tokens augmente, et la réponse finale en souffre. Pour corriger ça, tu dois mesurer l'étape de retrieval de manière totalement séparée de l'étape de génération. La première mesure, c'est la Contextual Relevancy. Cette métrique analyse les chunks de texte bruts que ton retriever tire de la base de données, et calcule le ratio de phrases pertinentes par rapport au total des phrases. Si tu récupères mille mots juste pour capter une seule phrase utile, ton score de relevancy s'effondre. Une relevancy élevée signifie que tu passes un contexte propre et dense au prompt du LLM, sans gaspiller de tokens avec des informations de fond inutiles. Ensuite, il y a le Contextual Recall. Ça évalue si ton retriever a trouvé toutes les informations nécessaires pour répondre à la query de l'utilisateur. DeepEval calcule ça en prenant l'output attendu pour une query et en extrayant toutes les affirmations factuelles qui s'y trouvent. Il scanne ensuite ton contexte récupéré pour voir si ces affirmations spécifiques sont bien présentes. S'il manque un fait crucial dans le contexte pour la réponse, le score de recall chute. Un recall élevé garantit que le LLM a vraiment la matière première dont il a besoin pour réussir. Ensuite, on a la Contextual Precision. On confond souvent la precision et le recall. Le recall signifie que tu n'as rien raté. La precision signifie que tu n'as inclus aucun superflu. Dans les évaluations RAG, la precision prend fortement en compte le ranking. Elle vérifie si les chunks de contexte très pertinents apparaissent tout en haut de la liste récupérée. Si le paragraphe vital est enterré à la dixième position sous neuf chunks inutiles, ton score de precision est bas. Les LLMs font généralement plus attention au début du prompt, donc l'ordre du retrieval change complètement le résultat. Voici l'idée clé. Il y a une tension constante entre la precision et le recall. Si tu configures ton retriever pour renvoyer cinquante chunks à chaque fois, ton recall sera probablement parfait parce que tu jettes un filet énorme. Mais ta precision et ta relevancy vont s'effondrer parce que la plupart de ces cinquante chunks sont du bruit. À l'inverse, si tu limites le retriever à exactement un chunk, ta relevancy est impeccable, mais ton recall échoue au moment où une query utilisateur nécessite de synthétiser deux faits différents provenant de deux documents différents. Pour lancer ces tests dans le framework, tu définis un objet test case. Cet objet contient l'input utilisateur, l'output attendu, et une liste des strings de contexte réelles que ton retriever a récupérées dans la base de données. Tu instancies la métrique spécifique que tu veux, comme une métrique de Contextual Recall, et tu lui passes le test case. Le framework utilise ensuite un modèle d'évaluation sous le capot pour lire les strings, mapper les affirmations, calculer une pénalité pour les informations manquantes ou mal rankées, et renvoyer un score numérique final entre zéro et un. Évaluer ton retriever te force à confronter exactement ce que tu donnes à ton modèle de génération. Un pipeline RAG performant ne se contente pas de balancer des données à un LLM ; il filtre et ranke ces données impitoyablement. Merci d'avoir écouté, et happy coding tout le monde !

Salut, c'est Alex de DEV STORIES DOT EU. Framework DeepEval, épisode 6 sur 18. Évaluer une simple réponse textuelle, c'est facile : tu compares l'output final avec l'input. Mais comment tu évalues un agent autonome qui décide de ses propres étapes, qui boucle sur plusieurs processus de réflexion et qui déclenche des tools externes ? Si la réponse finale est correcte, mais que l'agent a fait vingt étapes inutiles et appelé la mauvaise base de données pour y arriver, ton système est cassé. Pour corriger ça, tu as besoin de l'Agentic Evaluation. Il faut séparer un simple call API d'un flow d'agent autonome en plusieurs étapes. L'intégration standard d'un modèle de langage suit un chemin prédéfini. Tu envoies un prompt, et le modèle te renvoie une string. Un flow agentique transfère le contrôle au modèle. Le modèle reçoit un objectif global et décide de manière autonome quels tools internes utiliser, dans quel ordre, et quels arguments leur passer. Si tu évalues un agent en regardant uniquement son output texte final, tu passes à côté de la vraie mécanique de son raisonnement. DeepEval gère ça avec la métrique Task Completion. Au lieu de parser la string de la réponse finale, la métrique Task Completion analyse la trace d'exécution de l'agent. Une trace, c'est l'enregistrement complet et séquentiel de chaque pensée, action et tool call que l'agent a fait pendant un run spécifique. La métrique Task Completion lit cette trace pour déterminer si l'agent a vraiment répondu à la requête de l'utilisateur via des actions valides. Prends l'exemple d'un agent planificateur de voyage. Un utilisateur lui demande de réserver un week-end à Rome avec des réservations pour le dîner. Pour réussir, l'agent doit invoquer correctement un tool de recherche de restaurants, puis passer ces données à un tool générateur d'itinéraire. Si l'agent sort un output avec un itinéraire parfaitement formaté mais qu'il n'a jamais vraiment exécuté le tool de recherche de restaurants, une métrique d'évaluation de texte standard va sûrement le valider. L'output a l'air hyper convaincant. Mais la métrique Task Completion va le recaler. En analysant la trace, la métrique voit qu'il manque l'exécution du tool nécessaire. L'agent a halluciné les données du restaurant au lieu de les récupérer, et la trace le prouve. Ça déplace l'évaluation de l'output final vers les étapes opérationnelles. Tu dois aussi évaluer si les tools ont été utilisés correctement. Les test cases de DeepEval gèrent ça avec un paramètre qui s'appelle tools called. Quand tu construis un test case d'évaluation, tu passes la liste des tools que l'agent a invoqués pendant son exécution dans ce paramètre tools called. Fournir ces données permet au framework d'évaluer la Tool Correctness. L'évaluation vérifie si l'agent a sélectionné les bons tools pour l'objectif spécifique, s'il a fourni les bons arguments en input à ces tools, et s'il a bien traité les données que les tools ont renvoyées. Si ton agent planificateur de voyage a bien décidé d'utiliser le tool de recherche de restaurants, mais qu'il a passé la ville de Paris au lieu de Rome comme argument, l'évaluation de la Tool Correctness capte l'erreur au point de plantage exact. Tu sais exactement quelle étape a cassé la chain. Voici l'idée clé. Évaluer des agents, ça veut dire entrer dans la boîte noire. Tu vérifies l'intégrité du processus de raisonnement de l'agent et de ses actions mécaniques, étape par étape. Une réponse finale structurellement parfaite est complètement inutile si l'agent y est arrivé en contournant des tools, avec des données hallucinées et une logique cassée. Merci de m'avoir écouté, et happy coding à tous !

Bonjour, c'est Alex de DEV STORIES DOT EU. DeepEval Framework, épisode 7 sur 18. Un chatbot peut donner une super première réponse, mais complètement oublier l'intention du user ou son propre persona dès le troisième turn. C'est pour ça qu'on utilise l'évaluation de conversation multi-turn. Évaluer des réponses isolées, c'est facile, mais les vrais utilisateurs n'envoient pas des prompts isolés. Ils posent des questions de suivi, changent d'avis et font référence à des trucs qu'ils ont dits cinq minutes avant. Les méthodes d'évaluation standard s'effondrent ici parce qu'elles regardent un seul input et un seul output. Elles n'ont aucune notion de temps ou de mémoire. Pour tester comment un modèle gère un dialogue en cours, tu as besoin d'une structure qui capture tout le thread. Dans le framework, tu gères ça avec un objet spécifique appelé ConversationalTestCase. Au lieu de prendre une string en input et une string en output, il prend un paramètre appelé turns. Le paramètre turns est une liste séquentielle. Chaque item de cette liste représente un seul aller-retour entre l'utilisateur et le système. Tu ordonnes ces échanges du premier message jusqu'au tout dernier. Wrapper la séquence dans un ConversationalTestCase dit au moteur d'évaluation de traiter toute la liste comme une seule interaction continue et stateful. Il y a un piège classique ici. Ne passe pas un ConversationalTestCase dans des métriques standard non conversationnelles. Les métriques standard sont construites pour des outputs uniques. Si tu les utilises sur un objet multi-turn, elles vont complètement ignorer le contexte historique. Tu dois utiliser des métriques conversationnelles dédiées pour évaluer la liste de turns. Les métriques conversationnelles évaluent la conversation dans son ensemble. Elles prennent en compte le contexte précédent pour juger le comportement continu du modèle. Deux exemples principaux sont le Role Adherence et la Knowledge Retention. Prends l'exemple d'un chatbot de support client qui a pour instruction explicite d'agir comme un pirate. Au premier turn, l'utilisateur dit bonjour, et le bot répond avec de l'argot de pirate. Au deuxième turn, l'utilisateur pose une question, et le bot reste dans son personnage. Mais au troisième turn, quand l'utilisateur demande un remboursement, le bot répond avec des excuses corporate standard. Il a complètement abandonné son personnage. Tu peux attraper cette erreur automatiquement en utilisant la métrique Role Adherence. Tu définis le persona cible dans le setup de la métrique, et elle évalue toute la conversation pour vérifier que le modèle n'est jamais sorti de son personnage, même quand le contexte s'est allongé. La Knowledge Retention résout un problème différent. Si un utilisateur donne un numéro de compte au premier turn, et demande une mise à jour de statut au quatrième turn, le bot ne devrait pas redemander le numéro de compte. La métrique Knowledge Retention scanne la liste de turns pour s'assurer que le modèle récupère et applique avec succès les faits introduits plus tôt dans l'historique du chat. Mettre ça en place dans le code prend juste quelques étapes. D'abord, tu crées tes turns individuels, en mappant l'input utilisateur sur l'output du modèle pour chaque étape du dialogue. Ensuite, tu passes toute cette séquence dans un nouveau ConversationalTestCase. Puis, tu configures ta métrique conversationnelle, en assignant des critères comme le persona attendu. Enfin, tu exécutes la métrique sur ton test case. Le framework traite tout l'historique et renvoie un score basé sur l'interaction cumulée. Voici l'idée clé. L'évaluation multi-turn fait passer ton testing de la mesure d'une précision technique isolée à la mesure d'une cohérence comportementale continue dans le temps. Merci d'avoir écouté, happy coding à tous !

Salut, c'est Alex de DEV STORIES DOT EU. Framework DeepEval, épisode 8 sur 18. Parfois, les métriques standard ne sont pas adaptées à ton use case, par exemple pour vérifier si un chatbot financier très réglementé a l'air assez professionnel. Tu as besoin d'un moyen de mesurer des traits subjectifs de manière fiable, et c'est exactement là qu'intervient la création de métriques custom avec G-Eval. Avant de définir des métriques custom, détermine le type de logique que tu mesures. G-Eval est conçu exclusivement pour les critères subjectifs, comme le ton, la cohérence ou le flow de la conversation. Si tu dois imposer une logique objective stricte, tu devrais utiliser des DAGs. G-Eval gère les nuances du langage humain. Pour créer une métrique de professionnalisme pour un chatbot financier, tu n'écris pas de règles de parsing complexes. Tu utilises G-Eval pour définir une métrique custom en utilisant le langage courant. Tu instancies la métrique en lui donnant un nom et une string de critères en langage naturel. Pour ce chatbot, tes critères pourraient dire : détermine si l'actual output maintient un ton formel et respectueux, et évite strictement l'argot ou les tournures familières. Voici le point clé. La métrique ne se contente pas d'envoyer tes critères à un Large Language Model pour demander un score rapide. G-Eval exécute un algorithme Chain of Thought en deux étapes. L'étape un, c'est la génération. L'algorithme lit tes critères en langage clair et génère automatiquement une liste structurée d'étapes d'évaluation. Il écrit sa propre grille d'évaluation. Pour la métrique de professionnalisme, il pourrait générer une étape pour scanner les salutations informelles, et une autre étape pour vérifier l'utilisation d'une terminologie financière appropriée. L'étape deux, c'est l'évaluation en elle-même. L'algorithme prend ces étapes générées et les applique aux paramètres spécifiques de ton test case. Un test case G-Eval standard inclut généralement l'input utilisateur et l'actual output de ton modèle, mais tu peux aussi inclure l'expected output ou le retrieval context. L'évaluateur exécute sa grille custom sur le texte, calcule un score final entre zéro et un, et fournit une raison détaillée expliquant pourquoi il a retiré des points. L'écriture de critères efficaces dicte la qualité de ta métrique. Traite la string de critères comme un prompt très contraint. N'écris pas d'instructions vagues comme : vérifie si la réponse est bonne. Définis exactement ce que bon veut dire. Si l'utilisation d'argot doit entraîner un score automatique de zéro, précise-le explicitement dans les critères. Les étapes d'évaluation générées à l'étape un sont seulement aussi précises que les instructions que tu fournis. Ça couvre les interactions simples. Les conversations présentent un défi différent. Un chatbot peut commencer de façon professionnelle mais adopter un ton familier au quatrième message. Pour gérer ça, tu utilises Conversational G-Eval. Conversational G-Eval applique exactement le même algorithme en deux étapes à un chat multi-turn. La différence, c'est le format d'input. Au lieu d'évaluer un seul input et actual output, tu passes un historique de conversation entier. Cet historique est constitué de turns séquentiels qui alternent entre l'utilisateur et l'assistant. La métrique lit la transcription entière, génère ses étapes d'évaluation basées sur tes critères custom, et donne un score à l'interaction dans son ensemble. Ça garantit que l'output du modèle reste cohérent de la première salutation jusqu'à la conclusion finale. L'efficacité de n'importe quelle métrique custom dépend entièrement du fait de traiter tes critères comme une spécification rigoureuse, où la clarté bat toujours la brièveté. Merci d'avoir écouté, happy coding tout le monde !

Salut, c'est Alex de DEV STORIES DOT EU. Framework DeepEval, épisode 9 sur 18. Quand tu évalues des règles de formatage complexes, un seul prompt dense peut facilement faire halluciner le score de ton LLM évaluateur. Il pourrait voir les bons mots dans le texte, ignorer complètement l'ordre structurel, et donner une note de passage à un test qui échoue. La solution pour ça, c'est l'évaluation déterministe avec un DAG. DAG, ça veut dire Directed Acyclic Graph. Dans ce framework, une métrique DAG te permet de construire un arbre de décision strict qui contrôle comment le LLM évalue une réponse. Au lieu de demander à un modèle d'ingérer un texte et de le noter en fonction d'un bloc massif d'instructions, tu décomposes la logique en opérations granulaires, étape par étape. La data circule strictement dans une seule direction, des root nodes au début de ton arbre jusqu'aux leaf nodes à la fin. Pour construire cet arbre, tu te bases sur trois composants distincts. Le premier, c'est le Task Node. Une erreur courante, c'est de le traiter comme un évaluateur. Ce n'est pas le cas. Un Task Node extrait ou traite simplement la data de l'input ou de la réponse générée. Ensuite, il y a le Binary Judgement Node. Ce node prend la data traitée par le Task Node et l'évalue selon des critères spécifiques, en renvoyant un oui ou un non strict. Enfin, il y a le Verdict Node. Il agit comme un leaf node. Il termine une branche de ton arbre de décision et renvoie en output un score numérique final avec une justification écrite. Appliquons ça à un scénario concret. Tu testes un LLM qui génère des résumés de transcriptions de réunions. Ton exigence stricte, c'est que chaque résumé doit avoir exactement trois headings : Intro, Body, et Conclusion, dans cet ordre précis. Tu commences ta métrique en créant un root Task Node. Tu demandes à ce node de lire le résumé généré et d'extraire une liste de tous les headings qu'il trouve. C'est tout son job. Il isole la data de formatage et passe une simple liste de texte au niveau suivant de l'arbre. Maintenant, tu passes cette liste à un Binary Judgement Node. Tu définis les critères pour que ce node vérifie si la liste contient exactement trois items. Si le node évalue ça comme false, il redirige l'exécution vers un Verdict Node. Ce Verdict Node fait immédiatement échouer le test, assigne un score de zéro, et renvoie en output une raison indiquant que le nombre de headings était incorrect. Si le Binary Judgement Node évalue à true, l'exécution passe à un deuxième Binary Judgement Node. Ce node prend la même liste extraite et vérifie la séquence. Il vérifie si le premier item est Intro, le deuxième Body, et le troisième Conclusion. Si c'est true, il redirige vers un Verdict Node final qui donne un score parfait. Si c'est false, il redirige vers un Verdict Node différent qui assigne un zéro à cause d'une erreur d'ordre. C'est la partie qui compte. En séparant l'extraction d'informations dans un Task Node de la logique d'évaluation dans les Judgement Nodes, tu forces le LLM à suivre un chemin inflexible. Le modèle gère l'extraction sémantique, pendant que ton graphe garantit l'exécution déterministe des règles. Merci d'avoir écouté, happy coding tout le monde !

Salut, c'est Alex de DEV STORIES DOT EU. Framework DeepEval, épisode 10 sur 18. Tester un modèle de langage sur cinq prompts manuels, c'est mignon. Mais quand tu passes à une nouvelle version du modèle, ces cinq prompts ne te diront pas si tu as cassé des edge cases sur des centaines d'interactions historiques. Pour être production-ready, tu as besoin d'un repository de vérité robuste et versionné. C'est exactement ce qu'apporte un Evaluation Dataset. Dans DeepEval, un Evaluation Dataset est tout simplement une collection structurée d'éléments appelés Goldens. Avant d'aller plus loin, on doit dissiper une confusion fréquente. Les développeurs confondent souvent un Golden avec un Test Case. Ce n'est pas la même chose. Un Golden, c'est la ligne brute du dataset. Il contient tes paramètres de test statiques, comme l'input utilisateur, l'output attendu et le contexte de retrieval. Il représente le scénario idéal. Un Golden ne devient un Test Case que plus tard, au runtime, une fois que ton application live a traité l'input et injecté son output réel. Le Golden est le blueprint, tandis que le Test Case est le résultat exécuté. Prenons un scénario concret. Tu as un log historique de 500 requêtes de support client sauvegardé dans un fichier CSV. Tu veux tester rigoureusement une nouvelle version du modèle sur ce set exact de requêtes. Tu n'as pas besoin d'écrire une logique de parsing custom. Tu initialises simplement un Evaluation Dataset et tu utilises la méthode built-in pour ajouter des données depuis un fichier CSV. Tu passes le chemin du fichier et tu définis un mapping. Tu indiques au dataset quelle colonne CSV correspond à l'input utilisateur, laquelle map vers l'output attendu, et laquelle contient le contexte. Le framework gère le parsing et construit 500 Goldens en mémoire. Tu peux faire exactement la même chose avec un fichier JSON, en mappant les clés JSON vers les champs du Golden. Voici l'idée clé. L'Evaluation Dataset contrôle un lifecycle spécifique qui fait le pont entre tes données statiques et ton pipeline d'évaluation dynamique. D'abord, tu charges et tu stockes tes Goldens dans le dataset. Ensuite, pendant ton test run, tu itères sur le dataset. Tu extrais l'input de chaque Golden, tu le passes à ton modèle de langage live, et tu captures la réponse générée. Tu attaches ensuite cette réponse live au Golden et tu le convertis en un Test Case officiel. Enfin, tu passes ce Test Case complet à tes métriques pour le scoring. Ça permet de garder tes données brutes complètement séparées de ta logique d'exécution. Jusqu'ici, on a décrit des datasets single-turn. Un input utilisateur, un output attendu. Mais beaucoup d'applications impliquent des interfaces de chat. Pour ça, DeepEval supporte les datasets multi-turn. Au lieu d'une string d'input plate, un dataset multi-turn contient une séquence d'interactions. Un seul Golden multi-turn conserve tout l'historique de la conversation, en trackant comment l'utilisateur et le système interagissent sur plusieurs étapes. Ça permet à tes métriques d'évaluer le flow et la rétention de contexte d'une conversation, plutôt que d'isoler une seule réponse. Structurer tes données dans des Evaluation Datasets formels garantit que chaque tweak de prompt et chaque swap de modèle est mesuré par rapport à un standard historique strict et invariable. Merci d'avoir écouté, et happy coding à tous !

Salut, c'est Alex de DEV STORIES DOT EU. DeepEval Framework, épisode 11 sur 18. Le plus gros goulot d'étranglement pour évaluer les large language models n'est pas le framework de test que tu utilises. C'est avant tout le manque de données de test de haute qualité. Générer des données synthétiques avec le DeepEval Synthesizer est le moyen de contourner ce blocage. Imagine une startup qui développe un bot RH interne. Tu as besoin de lancer des tests immédiatement pour vérifier qu'il récupère les bonnes politiques. Mais le bot est tout nouveau. Tu n'as absolument aucun log de requêtes de vrais utilisateurs. C'est le problème classique du cold-start pour les données d'évaluation. Tu ne peux pas évaluer un système de retrieval sans une liste solide de questions réalistes à lui poser. Le DeepEval Synthesizer bootstrap un dataset d'évaluation directement à partir de ta base de connaissances brute. Au lieu d'écrire des centaines de test cases à la main, tu pointes l'outil vers tes documents sources. La méthode principale pour ça s'appelle generate goldens from docs. Dans DeepEval, un Golden est le terme utilisé pour un test case unique contenant un input, un expected output, et un context. Pour l'utiliser, tu initialises d'abord un objet Synthesizer. Ensuite, tu appelles la méthode generate goldens from docs et tu lui passes un array de chemins de documents. Pour le bot RH, ce serait les chemins de fichiers vers tes manuels d'employés, tes politiques de congés et tes PDF d'avantages sociaux. Quand tu lances cette méthode, le Synthesizer traite les fichiers et découpe le texte en chunks gérables. Il utilise ensuite un language model évaluateur pour agir comme un utilisateur curieux. Le modèle analyse un chunk spécifique du manuel RH et génère une question pertinente et réaliste basée uniquement sur ce texte. Cette question est sauvegardée comme input synthétique. Le Synthesizer sauvegarde aussi le chunk de texte exact utilisé pour inspirer la question. Ça devient l'expected context. Enfin, le modèle formule la réponse idéale et factuelle à la question et la sauvegarde comme expected output. C'est la partie qui compte. Les gens comprennent souvent mal les limites de la génération synthétique. Le Synthesizer crée uniquement les inputs, l'expected context, et l'expected output. Il ne génère pas l'actual output. Trouver l'actual output, c'est le boulot de ta propre application RH pendant la phase de test. Vois le Synthesizer comme un prof qui prépare un examen et crée un corrigé. Ton bot doit quand même passer l'examen. Tu peux contrôler la portée de cette génération. En appelant la méthode, tu peux spécifier combien de test cases générer par document. Ça garde le processus rapide et peu coûteux pour des itérations rapides, ou tu peux le scale up pour une couverture exhaustive. Une fois la méthode terminée, tu extrais les goldens générés et tu les sauvegardes. Tu peux exporter le dataset localement sous forme de fichier JSON, ou le push directement sur Confident AI pour tracker les versions de ton dataset au fil du temps. Bootstrapper des datasets synthétiques te permet d'arrêter d'attendre que de vrais utilisateurs exposent les failles de ton système, pour tester systématiquement les limites absolues de la logique de tes documents dès le premier jour. Merci d'avoir écouté, happy coding tout le monde !

Bonjour, ici Alex de DEV STORIES DOT EU. DeepEval Framework, épisode 12 sur 18. Les queries synthétiques de base générées à partir de tes documents sont trop faciles. Les modèles de langage modernes traitent les questions simples avec une facilité déconcertante, laissant des failles logiques dangereuses totalement inexplorées. Pour trouver les véritables points de rupture de ton application, tu dois augmenter artificiellement la difficulté de tes données de test. C'est ce qu'on fait avec l'Evolving Synthetic Complexity. La génération standard produit des questions simples et directes. L'évolution complexifie mathématiquement ces questions pour faire un stress-test de ton système. On confond parfois ça avec une modification des faits sous-jacents. Faire évoluer une query synthétique ne veut pas dire changer la ground truth. Les données sources restent exactement les mêmes. Ce qui change, c'est la difficulté structurelle de la query qui interroge ces données. Dans DeepEval, tu contrôles ce processus de mutation avec l'Evolution Config. Cette configuration applique des stratégies d'évolution spécifiques pour transformer un prompt de base en un edge case à contraintes multiples. Prends une question synthétique simple comme : quelle est la politique de remboursement ? C'est direct, mais c'est trop générique pour être un test rigoureux. La première stratégie que tu peux appliquer, c'est la Concretizing evolution. Ça prend une query abstraite et ça la force dans un scénario tangible et très spécifique. Au lieu de demander la politique générale, la concrétisation mute la query en quelque chose comme : si j'ai acheté une chemise rouge mardi, est-ce que je peux me faire rembourser la semaine prochaine ? Le modèle doit maintenant mapper les contraintes spécifiques de l'utilisateur à la règle générale. La deuxième stratégie, c'est la Reasoning evolution. Ça introduit une couche de déduction obligatoire. La question évoluée force le modèle à effectuer des étapes logiques avant de pouvoir fournir la réponse finale. Au lieu de juste récupérer un fait, la query peut exiger que le système calcule des dates, compare des valeurs, ou suive une chain logique conditionnelle basée sur le texte source avant de former sa réponse. La troisième stratégie, c'est la Multicontext evolution. Ça teste le retrieval et la synthèse en forçant le modèle à tirer des réponses à partir d'informations disparates. Ça modifie la query pour que la réponse ne puisse pas être extraite d'un seul paragraphe. Pour réussir, le modèle de langage doit combiner le délai de remboursement général d'un document avec les exclusions spécifiques des articles en liquidation d'une section complètement différente. Quand tu mutes artificiellement des milliers de queries avec ces stratégies, certaines vont inévitablement se dégrader. Une question évoluée peut devenir tellement alambiquée qu'il est vraiment impossible d'y répondre, ou elle peut s'éloigner des faits d'origine. C'est exactement le problème que résout la Filtration Config. Tu ne peux pas laisser du bruit insoluble polluer ton dataset d'évaluation. La filtration utilise un modèle critique séparé pour agir comme un gatekeeper de contrôle qualité. Il examine chaque nouvelle query évoluée selon des critères stricts avant qu'elle soit sauvegardée. Si une question mutée est logiquement cassée, ne s'aligne plus avec le contexte source, ou se dégrade en n'importe quoi, le modèle critique la rejette catégoriquement. Ce processus en deux étapes t'assure de générer des questions incroyablement difficiles, mais toujours entièrement valides. Un score élevé sur des données synthétiques de base ne prouve rien sur la résilience de ton système ; la vraie fiabilité d'un modèle se mesure uniquement à la façon dont il gère les edge cases complexes et intentionnellement évolués que la génération standard laisse de côté. Merci d'avoir écouté, happy coding tout le monde !

Salut, c'est Alex de DEV STORIES DOT EU. Framework DeepEval, épisode 13 sur 18. Les évaluations end-to-end te disent si un système a échoué, mais elles te laissent deviner pourquoi. Le tracing au niveau des composants te dit exactement quelle fonction spécifique a planté. Aujourd'hui, on s'intéresse au LLM Tracing et à l'Observability. Prends l'exemple d'un pipeline Retrieval-Augmented Generation standard. Un utilisateur pose une question complexe, et ton système renvoie une réponse hallucinée dix secondes plus tard. Tu dois savoir exactement ce qui s'est mal passé. Est-ce que la fonction d'embedding retrieval a récupéré des documents non pertinents dans ta database, ou est-ce que l'étape finale de génération du language model a juste échoué à synthétiser le bon contexte ? Tu ne peux pas débugger ça efficacement juste en regardant l'output final. Tu dois inspecter les étapes internes. Pour faire ça, tu dois comprendre deux termes fondamentaux qui sont souvent confondus : les Traces et les Spans. Une Trace, c'est l'arbre d'exécution complet d'une seule opération. Elle représente la timeline complète, du moment où l'utilisateur envoie un prompt jusqu'au moment où le système délivre la réponse finale. Un Span, en revanche, c'est un composant ou une fonction spécifique qui s'exécute à l'intérieur de cette Trace. L'exécution complète de ton pipeline est une Trace. La fonction qui requête la vector database est un Span. La fonction qui formate le prompt est un autre Span. L'appel réel au large language model est un troisième Span. Chaque Trace est construite à partir de ces Spans imbriqués. Chaque Span enregistre son propre start time, son end time, ses paramètres d'input et ses résultats d'output. Dans DeepEval, tu captures cette hiérarchie en utilisant le decorator observe. Tu places simplement le mot observe avec un arobase directement au-dessus des fonctions Python que tu veux monitorer. Tu l'attaches à ta fonction d'entry-point principale, et tu l'attaches aux helper functions internes comme ton retriever et ton generator. Quand ton application tourne, le decorator observe intercepte automatiquement l'exécution. Il logge les arguments exacts passés à la fonction et les données exactes retournées. Il tracke aussi la latency et toutes les erreurs qui se produisent. Plus important encore, il comprend le contexte d'exécution. Si ta fonction principale de pipeline appelle ta fonction retriever, le decorator enregistre automatiquement le retriever comme un child Span de la Trace principale. Il cartographie les relations parent-enfant de tes fonctions sans que tu aies à les lier manuellement. Voici l'idée clé. Faire du tracing de cette façon est complètement non intrusif. Tu n'as pas besoin de réécrire la codebase de ton application pour générer de la telemetry. Tu n'as pas besoin de modifier tes function signatures pour faire passer des trace IDs ou des objets de contexte le long de la call stack. Tu gardes ta business logic propre et tu wrappes juste les composants qui t'intéressent. En faisant ça, tu isoles les données pour chaque étape individuelle. Si tu veux évaluer juste la logique de retrieval plus tard, les inputs et outputs exacts de ce Span spécifique sont déjà loggés. Tu évalues en end-to-end pour mesurer l'expérience utilisateur finale, mais tu fais du tracing au niveau des composants pour vraiment localiser et corriger le code sous-jacent. Merci de m'avoir écouté, et happy coding à tous !

Salut, c'est Alex de DEV STORIES DOT EU. Framework DeepEval, épisode 14 sur 18. Dans les workflows complexes d'agents autonomes, tu ne sais pas toujours à quoi devrait ressembler le test case avant que l'agent ne commence vraiment son exécution. Tu ne peux pas écrire une test suite statique exhaustive pour des décisions intermédiaires qui n'ont pas encore été prises. Les Dynamic Evals au runtime résolvent cette limitation en te permettant de construire et d'évaluer des test cases à la volée. En général, les développeurs définissent les test cases statiques en externe. Tu crées un fichier avec des inputs rigides et des expected outputs, puis tu fais tourner ton application avec. Cette approche ne marche plus quand on a affaire à des systèmes autonomes. Quand un agent reçoit un prompt, il peut router la requête, sélectionner un tool spécialisé, et générer sa propre search string interne. Ces inputs et outputs intermédiaires n'existent pas tant que le code ne tourne pas vraiment. Les évaluations dynamiques abandonnent le fichier externe. À la place, elles construisent le test case étape par étape, au fur et à mesure que les variables se remplissent dans l'application active. Prends un scénario bien précis. Tu dois évaluer la context precision à l'intérieur d'une fonction retriever profondément imbriquée. Tu veux tester juste cette étape spécifique à la volée, isolée de l'output final que l'utilisateur voit. Pour faire ça, DeepEval fournit deux fonctions spécifiques pour intercepter les données d'exécution : update current span et update current trace. Une trace enregistre tout le cycle de vie d'une requête, de l'input utilisateur initial jusqu'à la réponse finale. Un span représente une opération spécifique à l'intérieur de cette trace, comme ta fonction retriever. Quand cette fonction retriever s'exécute, les variables dynamiques se matérialisent enfin. Tu as maintenant la search string exacte que l'agent a générée et les chunks de texte spécifiques que ta base de données a renvoyés. Pile à ce moment-là, dans la logique du retriever, tu appelles update current span. Tu utilises cette fonction pour intercepter ces variables en direct et les mapper directement dans un nouveau test case. Tu prends la search string interceptée et tu l'assignes comme input de test. Tu prends les chunks bruts de la base de données et tu les assignes comme retrieval context. Tu viens juste de construire un golden test case pendant l'exécution. Comme tu as construit ce golden dynamiquement à l'intérieur du span, tu peux l'évaluer immédiatement. Tu appliques ta métrique de context precision juste là. La métrique tourne sur les données en direct, donne un score à l'étape du retriever, et attache ce score directement au span local. Quand tu passeras en revue tes traces plus tard, tu ne verras pas juste qu'un retrieval a eu lieu. Tu verras une évaluation très ciblée de ce retrieval spécifique, basée sur les conditions exactes de ce run. Ça, ça couvre les étapes granulaires. Parfois, cependant, une opération imbriquée découvre quelque chose qui change le contexte de la requête entière. C'est là que update current trace devient nécessaire. Alors que update current span modifie l'étape locale, update current trace permet à une fonction profondément imbriquée de remonter et de modifier l'enregistrement d'exécution global. Si ton agent découvre des informations à la volée qui changent complètement à quoi devrait ressembler la réponse finale, tu appelles update current trace pour mettre à jour l'expected output pour tout le run. Ça permet de garder l'évaluation globale alignée avec la réalité en direct et changeante de la logique d'exécution. Voici l'idée clé. Déplacer les évaluations depuis des fichiers externes vers l'arbre d'exécution au runtime transforme le testing d'un exercice post-mortem en un mécanisme de diagnostic en direct. En liant les métriques directement aux spans pendant qu'ils s'exécutent, tu arrêtes de deviner pourquoi un agent multi-étapes a échoué et tu commences à mesurer exactement quel transfert interne a causé l'échec. Merci d'avoir écouté, et happy coding tout le monde !

Salut, c'est Alex de DEV STORIES DOT EU. Framework DeepEval, épisode 15 sur 18. Ton LLM répond peut-être parfaitement à toutes les questions normales. Mais que se passe-t-il quand un utilisateur malveillant essaie activement de faire un jailbreak de ton application pour faire fuiter des données sensibles ? Ça demande une approche complètement différente, ce qui nous amène à une introduction au Red Teaming. Pour comprendre le Red Teaming, tu dois changer ta façon de voir ton système. L'évaluation standard teste les fonctionnalités. Elle mesure si ton modèle est utile, précis et pertinent quand il est utilisé correctement. Le Red Teaming teste la sécurité, la sûreté et les guardrails. Ça demande un changement de mentalité : on passe de la simple vérification de l'exactitude à la simulation d'acteurs malveillants. Tu essaies activement de faire échouer le modèle. Prends un scénario courant. Si tu demandes directement à ton application d'IA de sortir un profil utilisateur, les guardrails standards vont sûrement le bloquer. L'IA refuse catégoriquement de faire fuiter les Personal Identifiable Information, ou PII. Une évaluation standard marque ça comme un succès. Mais un acteur malveillant ne va pas demander directement. Il pourrait faire un prompt au modèle en utilisant un persona malveillant spécifique, en donnant l'instruction à l'IA d'agir comme un administrateur de base de données senior qui fait un override d'urgence du système. Soudain, l'IA obéit et fait volontairement fuiter les PII. Le Red Teaming, c'est le processus systématique pour découvrir exactement ces angles morts avant qu'ils n'arrivent en production. DeepEval structure ce processus autour de quatre composants principaux. Le premier composant, ce sont les vulnérabilités. Une vulnérabilité, c'est la faiblesse, le risque ou le dommage spécifique que tu testes. C'est le problème sous-jacent que tu veux éviter. Dans notre scénario d'override d'urgence, la vulnérabilité, c'est la fuite de PII. D'autres vulnérabilités pourraient inclure la génération d'outputs toxiques, l'affichage de biais non autorisés, ou le fait de donner des conseils dangereux. Le deuxième composant, ce sont les attaques adversariales. Si la vulnérabilité est la cible, l'attaque est l'arme. Les attaques sont les techniques ou les moyens spécifiques utilisés pour exploiter une vulnérabilité. Adopter un persona de confiance pour tromper l'IA est un type d'attaque. D'autres incluent la prompt injection, où des instructions malveillantes sont cachées dans un input normal, ou des jailbreaks complexes conçus pour contourner complètement l'entraînement de sécurité du modèle. DeepEval sépare la faiblesse de la tactique, parce qu'une seule vulnérabilité peut être exposée par plein de types d'attaques différents. Le troisième composant, c'est le système LLM cible. C'est l'application réelle que tu évalues. Ce n'est pas juste le foundation model brut, mais ton architecture spécifique. Ça inclut tes system prompts personnalisés, tes mécanismes de retrieval, et tous les filtres de sécurité existants. Les attaques adversariales sont exécutées directement contre cette configuration pour voir comment ton produit réel se comporte sous pression. Le quatrième composant, ce sont les métriques. Une fois qu'une attaque est exécutée contre ton système cible pour tester une vulnérabilité, tu as besoin d'un résultat quantifiable. Les métriques évaluent la réponse du système. Elles déterminent si l'attaque a réussi à contourner les guardrails, ou si le système a refusé la requête malveillante en toute sécurité. Une métrique note l'interaction, en te donnant un pass ou un fail concret basé sur le niveau de sécurité réel de l'output. Voici l'idée clé. Tu ne peux pas sécuriser une application d'IA juste en prouvant qu'elle fait ce qu'il faut quand on lui demande poliment ; tu dois prouver systématiquement qu'elle refuse de faire de mauvaises choses quand elle est attaquée. Merci d'avoir écouté, bon code à tous !

Salut, c'est Alex de DEV STORIES DOT EU. DeepEval Framework, épisode 16 sur 18. Tu ne devrais pas avoir à taper manuellement des milliers d'inputs trompeurs pour trouver des failles de sécurité dans ton application. Au lieu de payer une équipe de sécurité pour essayer de casser ton système à la main pendant des semaines, tu peux laisser une IA attaquer ton IA de manière autonome. Aujourd'hui, on va regarder l'exécution d'attaques adverses. Pour orchestrer une attaque LLM-on-LLM automatisée, le moteur de scan a besoin d'une ligne de communication directe avec ton application. Tu établis cette connexion en définissant un callback pour le modèle cible. C'est une fonction Python asynchrone que tu écris. Elle prend un seul argument de type string, qui est le prompt adverse généré par le moteur de test, et elle doit retourner la réponse en string de ton système. Dans un scénario typique avec un modèle OpenAI, tu définirais cette fonction callback async, tu prendrais le paramètre prompt entrant, tu le passerais à ton client OpenAI, tu ferais un await sur la génération, et tu retournerais le contenu texte final. Ce callback sert de pont. Le moteur de red teaming n'a pas besoin de connaître ton architecture interne, tes clés API ou l'état de ta base de données. Il a juste besoin d'une fonction qu'il peut appeler en continu avec des inputs malveillants. Une fois que ton callback est prêt, tu le passes à la fonction red team. C'est l'orchestrateur principal qui lance le scan. Pour le configurer, tu fournis deux listes distinctes : les vulnérabilités et les attaques. Il est crucial de bien comprendre la différence entre les deux. Les vulnérabilités sont les failles structurelles spécifiques ou les comportements nuisibles que tu veux tester. Par exemple, si tu veux t'assurer que ton application ne sort pas de préjugés raciaux ou sexistes, tu importes et tu passes la vulnérabilité Bias à la fonction red team. Les attaques, d'un autre côté, représentent la méthodologie que le moteur va utiliser pour essayer d'exposer cette vulnérabilité. Pour forcer le modèle à faire une déclaration biaisée, tu pourrais vouloir que le moteur utilise des formulations trompeuses ou des techniques de jailbreak. Tu fais ça en passant l'attaque Prompt Injection. Le moteur va maintenant générer de façon autonome des prompts malveillants et ciblés en utilisant le prompt injection, spécialement conçus pour contourner tes system prompts et déclencher la vulnérabilité Bias. Un point de confusion fréquent pendant ce setup, c'est la façon dont les résultats sont réellement notés. Dans une évaluation standard, tu passes beaucoup de temps à définir et à tuner des métriques spécifiques. Quand tu exécutes des attaques adverses, ne définis pas manuellement les métriques. Le framework gère ça entièrement en arrière-plan. Il mappe automatiquement la vulnérabilité que tu as sélectionnée directement à une métrique d'évaluation interne correspondante. Parce que tu lui as dit de tester le Bias, le moteur lance automatiquement un évaluateur de biais sur chaque réponse que le callback de ton modèle cible retourne. Une fois que la fonction red team a fini de lancer ces prompts générés et d'évaluer les réponses, elle sort un Risk Assessment complet. Cette évaluation fournit un compte-rendu clair du scan. Elle montre exactement combien d'attaques ont été tentées, quelles techniques d'attaque spécifiques ont réussi à percer ton système, et les strings d'input exactes qui ont causé l'échec. Tu repars avec une liste concrète d'inputs que ton système ne peut actuellement pas gérer. Voici le point clé. La vraie puissance de ce setup, c'est de découpler la méthode d'attaque de la vulnérabilité cible, ce qui te permet de multiplier ta couverture de sécurité en associant une seule faille comme le biais avec des dizaines de vecteurs d'attaque différents en même temps. Merci d'avoir écouté, happy coding tout le monde !

Salut, c'est Alex de DEV STORIES DOT EU. DeepEval Framework, épisode 17 sur 18. Tu ne mergerais jamais une pull request pour du code traditionnel sans lancer tes unit tests d'abord. Pourtant, les équipes déploient régulièrement des modèles de langage non déterministes et espèrent juste que les nouveaux prompts marchent toujours. Si tu veux éviter que des mauvaises mises à jour du modèle ne cassent la production, tu as besoin de la CI/CD et de la Continuous Evaluation. DeepEval traite les évaluations de modèles de langage exactement comme des tests logiciels standards en s'intégrant directement avec Pytest. Tu définis une fonction de test, tu initialises tes métriques d'évaluation, et tu fais un assert pour vérifier que la métrique passe. Évaluer un modèle sur un seul input ne sert à rien, tu dois donc valider les changements sur un grand batch d'inputs de référence approuvés et d'outputs attendus. C'est ton golden dataset. Pour itérer efficacement sur ce dataset, tu utilises le decorator standard Pytest mark parametrize. Tu charges ton dataset, tu extrais les test cases individuels, et tu les passes au decorator. Quand la test suite tourne, Pytest génère dynamiquement une exécution de test séparée pour chaque élément de ton golden dataset. Voici le point clé. Comme le framework s'intègre étroitement avec Pytest, les développeurs pensent souvent qu'ils peuvent juste lancer des commandes Pytest standards dans leur terminal. Ne fais surtout pas ça. Si tu exécutes Pytest directement sur tes fichiers d'évaluation, tu vas tomber sur des erreurs inattendues liées aux event loops asynchrones et à la telemetry des métriques manquante. Tu dois toujours utiliser la command line interface dédiée. La bonne commande est deepeval test run suivie de ton nom de fichier Python. Ce wrapper gère le setup asynchrone complexe requis par les modèles de langage et garantit que tous les résultats de test sont correctement capturés et loggés. Intégrer cette commande dans ton pipeline de deploy te donne une Continuous Evaluation. Prends l'exemple d'un setup GitHub Action classique. Tu configures le workflow pour qu'il se déclenche à chaque fois qu'un ingénieur ouvre une pull request ciblant la branche main. Le runner de l'action fait un checkout du repository, configure l'environnement Python, et exécute deepeval test run sur ton script de golden dataset. Le framework évalue le code ou le prompt nouvellement modifié par rapport à chaque test case historique. Si un développeur modifie un system prompt pour rendre les réponses plus concises, il pourrait accidentellement dire au modèle de supprimer les avertissements de conformité obligatoires. Quand le pipeline de CI tourne, l'évaluation automatisée détecte immédiatement ce contexte manquant. Si la nouvelle logique fait chuter ton score d'évaluation en dessous de ton seuil défini sur n'importe quel test case, l'assert échoue. Le script renvoie un exit code non nul, la GitHub Action passe immédiatement au rouge, et la pull request est bloquée pour le merge. Ce check automatisé avant le deploy agit comme un gatekeeper strict. Il détecte les régressions automatiquement. Tu n'as plus besoin de vérifier manuellement les outputs ou d'attendre que les utilisateurs se plaignent qu'un changement de modèle a cassé un edge case spécifique. Le pipeline prouve mathématiquement si la mise à jour est prête pour le deploy, supprimant entièrement la subjectivité humaine du processus de release. La Continuous Evaluation signifie que tu arrêtes de traiter le prompt engineering comme un pari opérationnel et que tu commences à le traiter comme une release logicielle prévisible, basée sur des données concrètes. Merci d'avoir écouté, happy coding tout le monde !

Bonjour, ici Alex de DEV STORIES DOT EU. DeepEval Framework, épisode 18 sur 18. Tu passes des heures à optimiser un prompt en local, tu obtiens un super score d'évaluation, et tu ship le code. Deux semaines plus tard, un autre ingénieur met à jour le modèle sous-jacent, et soudain, l'application plante sur des edge cases que personne n'a trackés. Faire tourner les évaluations en local n'est que la moitié du travail. Cet épisode explique comment scaler tes tests et tracker les régressions dans le temps avec Confident AI. D'abord, une distinction nécessaire. DeepEval est le framework open source que tu fais tourner dans ton terminal ou ton environnement Python pour exécuter tes tests. Confident AI est la plateforme cloud hébergée qui est construite par-dessus. Tu utilises DeepEval pour définir tes métriques et lancer les évaluations elles-mêmes. Tu utilises Confident AI pour centraliser, tracker et analyser ces rapports d'évaluation à l'échelle de toute une organisation d'ingénierie. Ça transforme des scripts locaux isolés en un vrai système d'enregistrement collaboratif. Passer de l'exécution en local au logging dans le cloud demande une seule étape simple. Dans ton terminal, tu exécutes la commande deepeval login. La CLI va te demander de fournir une clé API générée depuis ton workspace Confident AI. Une fois que tu es authentifié, ton workflow quotidien reste exactement le même. Tu lances tes fichiers de test avec la commande de test standard. Le framework détecte automatiquement la session active et stream les résultats directement vers le dashboard cloud, tout en les affichant en local. Centraliser les rapports permet de tracker les régressions de façon méthodique. Une régression se produit quand un changement dans ton code ou ta configuration dégrade involontairement les performances du système. Pour diagnostiquer pourquoi une régression a eu lieu, tu dois tracker exactement ce qui a changé entre les runs de test. Ça se fait en loggant les hyperparamètres. Dans le contexte des évaluations de modèles de langage, un hyperparamètre est n'importe quelle variable qui modifie le comportement de ton pipeline. Ça inclut l'architecture du modèle, le réglage de la température, la taille de chunk utilisée pour le retrieval, ou même la version spécifique du template de prompt. Quand tu configures DeepEval pour logger ces hyperparamètres, ils sont attachés à chaque run de test envoyé à Confident AI. Prends l'exemple d'une équipe qui essaie de mettre à jour son application. Ils veulent savoir si le passage de GPT-4o à Claude 3.5 Sonnet améliore vraiment le score global de leur pipeline. Ils configurent le nom du modèle comme un hyperparamètre tracké. Quand l'ingénieur lance la suite d'évaluation avec le nouveau modèle, Confident AI logge le nom du nouveau modèle à côté des scores obtenus pour des métriques comme la précision contextuelle ou la cohérence factuelle. Voici le point clé. Comme tous les historiques de runs de test sont sauvegardés dans le cloud, l'équipe peut voir une timeline qui compare les changements exacts d'hyperparamètres avec les scores d'évaluation agrégés. Si le passage au nouveau modèle augmente la pertinence des réponses mais fait chuter drastiquement la cohérence factuelle, le dashboard met en évidence cette régression instantanément. Tout le monde dans l'équipe voit les mêmes données. Tu n'as plus jamais besoin de parser les anciens outputs de console ou de te fier à ta mémoire pour décider si un changement de configuration a été un succès. L'évaluation continue nécessite une baseline historique. Sans un système centralisé qui relie directement tes configurations à tes scores d'évaluation, tu fais juste tourner des expérimentations isolées, tu ne conçois pas un système fiable. Ça conclut notre série sur le framework DeepEval. Je t'encourage vivement à explorer la documentation officielle et à essayer de construire ces évaluations toi-même. Si tu as des sujets techniques que tu aimerais voir abordés dans une future série, visite devstories dot eu pour laisser une suggestion. Merci d'avoir écouté, et happy coding à tous !