LlamaIndex: Context-Augmented LLM Applications

Salut, c'est Alex de DEV STORIES DOT EU. LlamaIndex : Applications LLM Context-Augmented, épisode 1 sur 14. Les modèles pré-entraînés sont géniaux, mais ils ignorent absolument tout des documents privés que tu as créés ce matin. Tu demandes à un LLM de résumer ton tout nouveau slide deck financier du Q3, et soit il devine à l'aveugle, soit il te dit qu'il ne peut pas t'aider. Le Context-Augmentation Imperative, c'est comme ça que tu règles le problème. Les Large Language Models possèdent d'incroyables capacités de raisonnement, mais leurs connaissances sont figées dans le temps et limitées aux données publiques. Ils n'ont pas accès à tes wikis internes, à tes tickets de support client, ou à tes rapports financiers privés. LlamaIndex existe pour combler exactement cette lacune. Il sert de lien entre les foundational models et tes données privées et localisées. Quand tu demandes à un modèle de résumer ce slide deck du Q3, tu ne peux pas juste envoyer la question. Tu as besoin d'un système qui trouve les slides pertinentes, extrait le texte, et fournit cette information spécifique au modèle avec ton prompt. Ce processus, c'est le context augmentation. Tu donnes au modèle le contexte exact dont il a besoin pour appliquer ses capacités de raisonnement à tes données privées. LlamaIndex fournit l'infrastructure pour ingérer, organiser et récupérer tes données afin que le context augmentation se fasse de manière fiable. Récupérer du texte et répondre à une seule question, c'est juste la base. Les applications modernes demandent plus d'autonomie. Ce qui nous amène aux agentic applications. Une agentic application ne suit pas juste une ligne droite d'une question à une base de données jusqu'à une réponse. Elle prend des décisions en cours de route pour gérer des intentions utilisateur complexes. La première brique de tout ça, c'est le routing. Quand un utilisateur pose une question, le système doit décider quelle source de données ou quel tool est approprié. Si l'utilisateur demande un résumé global de l'entreprise, le router dirige la query vers l'index du slide deck du Q3. Si l'utilisateur demande la répartition chiffrée exacte des ventes régionales, le router peut plutôt envoyer la query vers une base de données SQL structurée. Le routing garantit que le modèle utilise le bon tool pour le job en fonction de l'input. La deuxième brique, c'est le prompt chaining. Les tâches complexes échouent souvent quand tu demandes à un modèle de les gérer dans un seul prompt massif. Le prompt chaining décompose un objectif complexe en tâches plus petites et séquentielles. Le système peut lancer un premier prompt pour extraire les chiffres d'affaires du slide deck, passer ces chiffres à un deuxième prompt qui les compare aux données historiques, et envoyer cet output à un troisième prompt qui rédige un executive summary. L'output d'une étape devient le contexte exact de l'étape suivante. C'est là que ça devient intéressant. Même avec les bonnes données et une chain structurée, les modèles font des erreurs. C'est ce qui introduit la reflection. La reflection est une étape de contrôle qualité automatisée. Avant de livrer le résumé final du deck du Q3 à l'utilisateur, l'agentic application utilise un prompt séparé pour évaluer son propre brouillon. Elle vérifie si le texte généré est entièrement supporté par les slides récupérées. Si l'étape de reflection repère une hallucination ou une métrique clé omise, elle rejette le brouillon et déclenche une correction. La véritable puissance des applications context-augmented n'est pas juste de donner un document à lire à un LLM, mais de lui donner un workflow structuré et auto-correctif pour raisonner de manière sécurisée sur tes données privées. Si tu veux aider à faire vivre l'émission, tu peux chercher DevStoriesEU sur Patreon et nous soutenir là-bas. C'est tout pour cet épisode. Merci pour ton écoute, et keep building !

Salut, c'est Alex de DEV STORIES DOT EU. LlamaIndex : Applications LLM enrichies par le contexte, épisode 2 sur 14. Tu ne peux pas juste balancer un PDF de 500 pages dans la context window d'un LLM et t'attendre à une réponse précise. Le modèle va perdre le fil, halluciner, ou tout simplement rejeter le payload parce qu'il dépasse ses limites. Pour rendre ces fichiers massifs utiles, tu dois les découper en tout petits morceaux et les traduire dans un format mathématique que la machine peut chercher. C'est exactement ce processus qu'on aborde aujourd'hui dans Data Ingestion : Documents et Nodes. Imagine que tu dois digérer un énorme manuel RH pour les employés. Le texte se trouve dans un PDF géant, qui s'étale sur des dizaines de chapitres complexes. La première étape d'un pipeline de Retrieval-Augmented Generation, c'est la phase de loading. C'est là qu'entrent en jeu les Data Connectors, qu'on appelle souvent des Readers. Un connecteur prend ta source de données brute — que ce soit un PDF local, une table de base de données distante ou une réponse d'API externe — et l'encapsule dans une structure de données appelée Document. On se plante souvent sur ce terme. Dans ce framework, un Document ne veut pas dire un fichier Word ou un PDF. Un Document est simplement un conteneur générique pour n'importe quelle source de données ingérée. Il contient le texte brut avec quelques propriétés de base. Cependant, un seul Document qui représente un manuel de 500 pages est complètement inutile pour une recherche précise et rapide. Tu dois le découper. Ce qui nous amène aux Nodes. Un Node est la véritable unité de données atomique dans LlamaIndex. C'est un chunk plus petit et gérable d'un Document parent — peut-être un seul paragraphe qui détaille la politique de congé parental. Quand tu traites le manuel RH, le framework prend le Document massif et le découpe en milliers de Nodes. Voici le point clé. Les Nodes ne contiennent pas juste du texte isolé. Ils transportent des métadonnées riches et des relations structurelles. Un Node sait exactement de quel Document parent il vient. Il sait aussi quel Node le précède logiquement et quel Node le suit. C'est cette structure liée qui permet au système de synthétiser un contexte plus large par la suite, si un seul chunk ne contient pas toute la réponse. Une fois que tu as tes données découpées en Nodes précis, tu passes à l'étape d'indexation. Tu as besoin d'un moyen robuste de trouver le bon Node quand un utilisateur posera une question plus tard. Ça nécessite de traduire le langage humain dans un format numérique qu'on appelle un embedding. Un embedding est un array de nombres à virgule flottante qui représente le sens sémantique du texte à l'intérieur du Node. Tu passes chaque Node à travers un modèle d'embedding. Le modèle lit le chunk et renvoie un vecteur à haute dimension. Si deux Nodes parlent de sujets conceptuellement similaires — comme les congés maladie et les congés payés — leurs vecteurs numériques seront mathématiquement proches l'un de l'autre dans l'espace. Avec ces vecteurs générés, tu construis un Index. L'Index est le composant structurel central qui organise tes Nodes pour qu'ils puissent être requêtés. Pour la plupart des applications, cet Index est adossé à un Vector Store. Le Vector Store agit comme une base de données spécialisée, explicitement conçue pour stocker ces représentations mathématiques et effectuer des calculs de similarité très efficaces dessus. Le flux logique est très prévisible. D'abord, tu configures un Data Connector pour cibler ton manuel RH. Le connecteur lit le fichier et sort un seul objet Document. Ensuite, un parser prend ce Document et le divise en un array d'objets Node indépendants. Enfin, tu passes cet array de Nodes dans un Index, qui coordonne la création des embeddings vectoriels et les commit dans le Vector Store. Tout le pipeline d'ingestion existe pour résoudre une limitation fondamentale. Les Large Language Models ne peuvent pas lire des livres entiers d'un seul coup de manière fiable, mais ils peuvent calculer instantanément la distance mathématique entre deux arrays de nombres. Traduire tes fichiers bruts en Documents, les découper en Nodes liés, et les encoder dans des index vectoriels, c'est ce qui comble ce vide. C'est tout pour cet épisode. Merci d'avoir écouté, et continue de développer !

Salut, c'est Alex de DEV STORIES DOT EU. LlamaIndex : Context-Augmented LLM Applications, épisode 3 sur 14. Tu récupères le bon chunk de document, tu l'envoies au modèle de langage, et pourtant tu obtiens une mauvaise réponse parce qu'il était enfoui sous dix chunks non pertinents. Trouver le texte n'est que la moitié du travail. Le filtrage, le ranking, et décider comment le récupérer à la base, c'est là que le système réussit ou échoue vraiment. Aujourd'hui, on s'intéresse à la phase d'exécution du RAG, et plus précisément au Query Pipeline : les retrievers et les routers. À ce stade, tes données sont déjà chargées et indexées. Un utilisateur soumet une query. Le premier composant à intercepter cette query est souvent un router. Un router est un moteur de décision. Il analyse la question entrante et détermine quel tool ou index sous-jacent est le plus adapté pour y répondre. Disons qu'un utilisateur pose une question complexe sur un événement historique précis qui inclut aussi des acronymes très spécifiques. Une recherche vectorielle standard pourrait capter le sens sémantique de l'événement, mais rater les acronymes. Une recherche par mots-clés va trouver les acronymes, mais passera à côté du contexte plus large. Le router évalue la query et décide de l'envoyer sur deux chemins en même temps. Il route la requête vers une recherche vectorielle et une recherche par mots-clés à la fois. Ce qui nous amène aux retrievers. Un retriever est chargé de définir exactement comment récupérer le contexte pertinent depuis un index. Il ne génère pas de réponses. Il récupère uniquement des données. Pour reprendre notre scénario, le vector retriever convertit la query de l'utilisateur en un embedding et extrait les nodes les plus similaires mathématiquement, qui sont juste des chunks de tes documents sources. En même temps, le keyword retriever extrait les nodes qui contiennent des correspondances de texte exactes pour ces acronymes. Maintenant, tu as deux piles distinctes de nodes. Tu ne peux pas juste tous les ajouter aveuglément au prompt de ton modèle de langage. Les context windows sont limitées, et les modèles sont facilement distraits par des données non pertinentes. C'est là qu'interviennent les node postprocessors. Voici l'idée clé. Les node postprocessors agissent comme un filtre entre les retrievers et le modèle de langage. Ils appliquent des transformations, du filtrage ou une logique de re-ranking aux nodes récupérés. Par exemple, un postprocessor peut imposer un similarity cutoff, en supprimant tous les nodes qui ont un score inférieur à un seuil spécifique. Il peut dédupliquer les nodes si la recherche vectorielle et la recherche par mots-clés ont récupéré exactement le même paragraphe. Il peut aussi re-ranker les nodes restants pour que le chunk le plus pertinent se trouve tout en haut de la context window. Une fois que le postprocessor a nettoyé et ordonné les données, le système les transmet au response synthesizer. Le synthesizer a un seul job. Il prend la liste de nodes finalisée et la query utilisateur initiale, les combine dans un prompt structuré, et les envoie au modèle de langage. Le modèle de langage génère ensuite la réponse finale lisible par un humain, en se basant uniquement sur ce contexte fourni. La phase d'exécution de la query est strictement un pipeline. Tu routes la query, tu récupères les raw nodes, tu filtres et tu rankes ces nodes avec un postprocessor, et enfin tu synthétises le texte. Si tu contrôles ce que le modèle de langage voit, tu contrôles la qualité de l'output. Merci d'avoir passé quelques minutes avec moi. À la prochaine, porte-toi bien.

Salut, c'est Alex de DEV STORIES DOT EU. LlamaIndex : Applications LLM enrichies de contexte, épisode 4 sur 14. Tu développes un agent qui gère les tickets de support IT, mais la moitié des soumissions sont juste des photos de smartphone avec des voyants d'erreur qui clignotent. Le traitement uniquement textuel t'oblige à construire des pipelines de vision séparés ou à laisser tomber complètement le contexte visuel. Aujourd'hui, on parle de l'interfaçage avec les LLMs et des inputs multi-modaux, ce qui règle ça directement au niveau du modèle. Dans LlamaIndex, l'interaction avec un modèle de langage passe par la classe LLM de base. Ça agit comme une interface unifiée. Que tu appelles un modèle OpenAI, un modèle Anthropic ou un autre provider, les méthodes de base que tu utilises sont identiques. Cette abstraction protège la logique de ton application des changements d'API spécifiques au provider. Quand tu veux une réponse du modèle, tu choisis entre deux méthodes principales. La première, c'est la méthode complete. Tu lui passes une seule string de texte qui contient ton prompt, et elle te retourne une seule réponse textuelle. C'est fait pour des tâches simples en single-shot, comme résumer un document ou extraire un fait précis. La deuxième méthode, c'est la méthode chat. Elle est conçue pour les conversations ou les interactions structurées. Au lieu d'une seule string, tu passes une liste d'objets chat message. Chaque message a un rôle spécifique qui lui est attaché, typiquement system, user ou assistant. En passant une liste, la méthode chat donne au modèle tout le contexte d'un échange avant de générer sa réponse suivante. Les méthodes complete et chat attendent toutes les deux que le modèle ait terminé toute sa génération avant de retourner l'output. Si le modèle écrit une longue réponse, ton application reste inactive. Pour régler ça, tu utilises le streaming. Tu appelles stream complete ou stream chat à la place. Ces méthodes retournent un generator. Au fur et à mesure que le modèle produit des tokens, ton code les reçoit en petits chunks. Tu boucles sur ce generator pour afficher la réponse sur une interface utilisateur en temps réel, ce qui supprime la perception de latence. Maintenant, la deuxième partie, c'est la gestion des données non textuelles. C'est là que ça devient intéressant. Les LLMs modernes analysent les informations visuelles, et LlamaIndex supporte ça via des content blocks. Au lieu de passer une simple string de texte dans un user chat message, tu peux passer une liste de blocks. Repense au ticket de support IT avec la baie de serveurs en panne. Tu as besoin que le modèle regarde la photo et lise tes instructions de diagnostic. D'abord, tu crées un ImageBlock. Tu fournis les données de l'image à ce block. LlamaIndex te permet de passer un chemin de fichier local, une URL directe, ou des bytes bruts encodés en base soixante-quatre. Ensuite, tu crées un TextBlock. Tu lui donnes ton prompt textuel, en demandant au modèle d'identifier la panne matérielle montrée sur la photo. Tu mets l'ImageBlock et le TextBlock dans une seule liste, et tu attaches cette liste à un nouveau user chat message. Quand tu passes ce message dans la méthode chat d'un modèle capable de faire de la vision, le LLM traite la disposition visuelle de la baie de serveurs en même temps que tes instructions textuelles. Il retourne un diagnostic basé sur les deux inputs combinés. Voici le point clé. La vraie puissance de cette architecture, c'est sa cohérence. Que tu envoies une string d'une seule ligne, que tu streames une réponse en temps réel, ou que tu passes un array complexe de text blocks et d'image blocks, le pattern d'interaction avec la classe LLM reste complètement standardisé sur toute ta codebase. C'est tout pour cet épisode. À la prochaine !

Salut, c'est Alex de DEV STORIES DOT EU. LlamaIndex : Context-Augmented LLM Applications, épisode 5 sur 14. Rien ne casse un pipeline en production plus vite qu'un LLM qui décide d'ajouter « Bien sûr, voici ton JSON » juste avant le payload de données. Tu demandes un output lisible par une machine, tu obtiens du texte de remplissage, et ton parser crashe instantanément. Faire le pont entre du langage naturel non structuré et des types programmatiques fiables, c'est exactement ce que résout l'extraction de données structurées avec Pydantic. Prends le scénario où tu dois parser une boîte mail chaotique remplie de messages de fournisseurs, de rappels de paiement et de reçus non structurés. Ton système doit extraire des données de facturation structurées à partir de ce texte. Si tu te reposes sur de la génération de texte standard, tu obtiens des résultats imprévisibles. Une réponse pourrait utiliser du camel case pour les clés, une autre pourrait formater les dates différemment, et les prix reviennent souvent sous forme de strings avec des symboles monétaires attachés. Tu finis par écrire une logique de manipulation de strings interminable juste pour extraire un nombre exploitable de la réponse. Au lieu de demander du JSON au modèle et d'espérer qu'il obéisse, tu définis tes exigences exactes en utilisant un base model Pydantic. Tu crées une classe Python appelée Invoice. À l'intérieur de cette classe, tu déclares les types de données précis que ton application attend. Tu définis la date comme une string, les articles achetés comme une liste de strings, et le prix total strictement comme un float. Voici le point clé. LlamaIndex prend ta classe Pydantic et la sérialise automatiquement en un JSON schema strict. Quand tu envoies le texte de l'email au modèle, LlamaIndex attache ce schema et déclenche le structured output ou l'API de function calling du modèle sous-jacent. Le schema agit comme une limite stricte. Le LLM ne génère plus de texte libre. Il est contraint de peupler les champs du JSON schema spécifiquement avec les types que tu as demandés. Tu peux aussi guider le raisonnement du modèle directement à l'intérieur de tes structures de données. En attachant une field description à un attribut, tu donnes au LLM des instructions ciblées. Pour l'attribut price, tu pourrais ajouter une field description indiquant d'extraire le coût total final, en ignorant les frais de port. Le LLM lit cette description comme faisant partie de la définition du schema et applique cette logique pendant la phase d'extraction. Quand la réponse revient, LlamaIndex ne te donne pas une string brute ou un dictionnaire générique. Il traite la réponse via Pydantic et retourne un objet Invoice complètement instancié. Les données sont déjà validées. Parce que le framework exploite les fonctionnalités natives de structured output, le modèle sait à l'avance qu'il doit fournir un vrai float pour le prix, et non sa représentation sous forme de string. Tu peux immédiatement accéder à l'attribut invoice dot price dans ton code et faire des maths avec. Plus besoin de nettoyer le texte de remplissage, de retirer les signes dollar, ou de caster des strings en nombres. La transition du langage naturel à la logique applicative se fait de manière transparente au niveau de la couche d'extraction. En poussant ton data schema directement dans le processus d'extraction, tu forces le LLM à s'adapter à ton code applicatif, plutôt que d'écrire du code applicatif fragile pour tolérer le comportement imprévisible du LLM. C'est tout pour cet épisode. Merci d'avoir écouté, et continue de builder !

Salut, c'est Alex de DEV STORIES DOT EU. LlamaIndex : Applications LLM contextuelles, épisode 6 sur 14. Et si ton application pouvait décider quelles fonctions exécuter en fonction de l'intention de l'utilisateur, plutôt qu'avec un ensemble rigide de conditions ? C'est l'idée centrale derrière la création d'agents fonctionnels autonomes. Quand tu construis un pipeline de requêtes standard, c'est toi qui dictes le chemin d'exécution. Un agent inverse ce paradigme. Tu fournis un ensemble de tools, et un moteur de raisonnement automatisé utilise un large language model pour décider quels tools appeler, et dans quel ordre, pour résoudre un problème. Avant d'aller plus loin, on doit dissiper un malentendu très courant. Le LLM lui-même n'exécute pas ton code Python. Il génère simplement une requête textuelle structurée pour dire qu'il veut appeler une fonction spécifique avec des arguments spécifiques. Le framework d'agents LlamaIndex intercepte cette requête, exécute ton code Python en local, puis renvoie le résultat au LLM. Pour que ce routage autonome fonctionne, tu as besoin de tools. Un tool, c'est essentiellement une fonction Python standard encapsulée dans une classe LlamaIndex qui s'appelle FunctionTool. Mais comme le LLM a besoin de savoir quand et comment utiliser ta fonction, les métadonnées de ton code deviennent une partie critique du système. Le framework extrait le nom de la fonction, les type hints et la docstring, puis les passe au LLM comme instructions. Prenons un scénario concret. Tu veux que ton agent résolve des problèmes de maths. Tu écris deux fonctions Python, une qui s'appelle add et une qui s'appelle multiply. Pour la fonction multiply, tes type hints précisent qu'elle prend deux entiers et renvoie un entier. Point crucial, tu rédiges une docstring qui dit clairement que cette fonction multiplie deux nombres entre eux. Tu encapsules les deux fonctions dans des tools et tu les passes dans une liste, avec le LLM de ton choix, pour initialiser l'agent. C'est là que ça devient intéressant. Tu demandes à l'agent : combien font deux plus deux, multiplié par trois. L'agent entre dans une boucle de raisonnement. D'abord, le LLM analyse le prompt et regarde les tools disponibles. Il lit tes docstrings et décide qu'il doit d'abord faire une addition. Il génère une requête pour appeler le tool add avec les arguments deux et deux. Le framework exécute ta fonction Python en local et renvoie le résultat, quatre, à l'agent. L'agent n'a pas terminé. Il regarde le résultat intermédiaire et son but initial. Il décide qu'il doit maintenant multiplier. Il demande le tool multiply, en lui passant le quatre qu'il vient de recevoir et le trois de ton prompt initial. Le framework exécute la multiplication et renvoie douze. Enfin, le LLM reconnaît que le problème est résolu et génère une réponse conversationnelle pour l'utilisateur. Il n'y a aucune règle codée en dur ni de logique de routage explicite ici. L'agent a compris les dépendances et l'ordre des opérations tout seul, en se basant sur les tools disponibles. Ça veut dire que la façon dont tu écris tes définitions Python dicte directement à quel point ton agent est intelligent. Tes type hints et tes docstrings ne sont plus là juste pour les autres développeurs, ce sont littéralement le prompt qui pilote la logique autonome de l'agent. Si tu tires de la valeur de ces épisodes et que tu veux soutenir l'émission, tu peux chercher DevStoriesEU sur Patreon. C'est tout pour cet épisode. Merci d'avoir écouté, et continue de développer !

Salut, c'est Alex de DEV STORIES DOT EU. LlamaIndex : Applications LLM enrichies par le contexte, épisode 7 sur 14. Tu développes un agent qui doit vérifier les cours de la bourse, récupérer des messages sur Slack, ou requêter une base de données. Tu pourrais passer des jours à lire la documentation de l'API, à gérer les schémas d'authentification et à écrire du code d'intégration boilerplate. Ou alors, tu pourrais juste récupérer le travail qu'un développeur de la communauté a déjà écrit et vérifié. Cet épisode parle de l'extension des agents avec les tools LlamaHub. Les agents s'appuient sur des tools pour interagir avec le monde extérieur. Même si tu peux écrire chaque intégration à la main, LlamaHub existe précisément pour éliminer ce travail redondant. Il fonctionne comme un vaste registre open-source de tool specifications pré-construites. Une tool specification, ou tool spec, est essentiellement une classe Python qui regroupe plusieurs appels d'API liés dans un seul package. En les important directement dans ton projet, tu contournes tout le processus d'écriture de la logique sous-jacente pour les services tiers. Pour utiliser une de ces intégrations, tu installes son package spécifique. Si tu veux que ton agent réponde à des questions sur le cours de l'action d'une entreprise, tu n'écris pas de requête HTTP custom vers l'API Yahoo. À la place, tu utilises ton package manager standard pour installer le package Llama Index Yahoo Finance tools. Une fois installé, tu importes la classe Yahoo Finance Tool Spec dans ton script. Voici le point clé. Tu ne passes pas la classe tool spec directement à l'agent. Parce qu'un tool spec est un bundle de plusieurs fonctionnalités, tu dois d'abord l'unpack. Tu fais ça en créant une instance du Yahoo Finance Tool Spec, puis en appelant une méthode spécifique dessus nommée to tool list. Cette méthode sépare le bundle et retourne un array plat standard de tools individuels que l'agent peut lire et exécuter. Ce design modulaire signifie que tu n'es pas restreint à utiliser uniquement des tools externes ou uniquement des tools internes. Tu peux les combiner de façon transparente. Supposons que tu aies déjà un function tool local et custom qui formate les montants en devises spécifiquement pour le dashboard interne de ton entreprise. Tu crées simplement une liste Python standard. Dans cette liste, tu places ton tool custom de formatage de devises, et tu fais aussi un append des tools unpackés de la tool list Yahoo Finance. Tu prends ensuite cet array combiné et tu le passes directement à ton agent pendant l'initialisation en l'assignant au paramètre tools. Quand tu fais un prompt à l'agent avec une question sur le cours actuel d'une action, l'agent évalue la requête de l'utilisateur par rapport aux descriptions de tous les tools dans cette liste combinée. Il reconnaît que le tool Yahoo Finance est le bon choix pour récupérer les données du marché. Il extrait le ticker de l'entreprise à partir du prompt utilisateur, exécute le tool Yahoo Finance, récupère le prix en temps réel, et peut ensuite, en option, chainer ce résultat brut dans ton tool de formatage local avant de retourner la réponse finale à l'utilisateur. Tu viens de donner à ton application des capacités complexes de recherche financière en installant un package, en instanciant une classe, et en appelant une méthode d'unpacking. Ce pattern architectural s'applique à des centaines d'intégrations sur LlamaHub, de la lecture de documents Google Drive aux requêtes sur Wikipedia. Le vrai levier d'un agent autonome ne se trouve pas seulement dans la capacité de raisonnement du modèle de langage sous-jacent, mais dans l'immense variété de systèmes externes auxquels il peut accéder instantanément grâce aux tool specifications pré-construites. C'est tout pour cet épisode. Merci d'avoir écouté, et continue de développer !

Salut, c'est Alex de DEV STORIES DOT EU. LlamaIndex : Context-Augmented LLM Applications, épisode 8 sur 14. Tu donnes à un modèle de langage un prompt massif pour lui demander de faire des recherches sur un sujet, de rédiger un rapport et d'évaluer son propre travail de manière critique. Il échoue. La context window est brouillée, les tools sont mal utilisés, et l'output est un compromis superficiel. La solution, c'est de décomposer ce prompt massif en un essaim de spécialistes grâce aux Multi-Agent Swarms avec AgentWorkflow. Un seul agent surchargé galère car il a trop de tools et des instructions contradictoires. Il doit décider quand chercher, quand rédiger et quand éditer, tout en gérant un context interne massif. AgentWorkflow résout ça en te permettant de définir un réseau d'agents ultra-ciblés. Chaque agent fonctionne avec un system prompt très précis, un ensemble restreint de tools, et un objectif unique. Prends l'exemple d'un pipeline de génération de contenu. Au lieu d'un seul méga-agent, on crée trois FunctionAgents distincts. D'abord, le Researcher. On équipe cet agent d'un tool de recherche web et on lui donne l'instruction stricte de collecter des faits. Il ne rédige pas de texte. Ensuite, on définit le Writer. On lui retire complètement les tools de recherche pour éviter qu'il ne se disperse. Son seul boulot, c'est de prendre les faits bruts et de rédiger des paragraphes propres. Enfin, on définit le Reviewer. On lui donne des guidelines sur le ton et l'exactitude des faits, en lui demandant de critiquer le texte. Voici le point clé. Avoir plusieurs agents ne sert à rien s'ils ne peuvent pas se coordonner, mais leur laisser carte blanche pour parler à n'importe qui crée le chaos. Tu dois les connecter explicitement entre eux. Dans AgentWorkflow, tu fais ça en définissant des permissions de handoff. Quand tu configures tes agents, tu spécifies une propriété appelée can handoff to. Elle accepte une liste d'autres agents. Pour notre pipeline, on donne au Researcher la permission de faire un handoff vers le Writer. On donne au Writer la permission de faire un handoff vers le Reviewer. On donne aussi au Reviewer la permission de faire un handoff en retour vers le Writer si le texte a besoin d'être révisé. Ça crée un graphe d'agents strict et orienté. Le framework fait respecter ces limites. Le Researcher ne peut pas contourner le Writer et envoyer ses notes brutes directement au Reviewer. Il n'en a tout simplement pas l'autorisation. Pour exécuter ça, tu passes ta liste d'agents à une instance AgentWorkflow. Tu lances le processus en exécutant le workflow avec une user query initiale, en la pointant vers le Researcher pour démarrer. Le framework de workflow gère automatiquement le state partagé et le routing. Le Researcher exécute ses search tools, compile les données, et décide en interne que son boulot est terminé. Il utilise ensuite son handoff tool pour passer le contrôle, avec les données collectées, au Writer. Le Writer prend ce context, rédige le rapport, et fait un handoff vers le Reviewer. Si le Reviewer repère un défaut, il déclenche un handoff en retour vers le Writer avec du feedback. Cette boucle continue jusqu'à ce qu'un agent décide que le travail est terminé et renvoie une réponse finale au user au lieu de déclencher un autre handoff. Contraindre un agent à un seul rôle et définir explicitement ses chemins de communication est le moyen le plus fiable de forcer des modèles de langage à produire un raisonnement complexe en plusieurs étapes. C'est tout pour cet épisode. Merci de ton écoute, et continue à développer !

Bonjour, c'est Alex de DEV STORIES DOT EU. LlamaIndex: Context-Augmented LLM Applications, épisode 9 sur 14. Si tu laisses des agents autonomes se passer le contrôle en peer-to-peer, tu te retrouves facilement avec des boucles infinies ou des pertes de context. Parfois, tu ne peux pas compter sur les agents pour se passer le relais. Tu as besoin d'un manager central en charge de toute l'opération. C'est le pattern Orchestrator Agent. Dans un système multi-agents, laisser les agents se parler directement semble puissant, mais ça devient vite un cauchemar à débugger. Tu perds le fil de qui est aux commandes, et gérer le state global de l'application devient incroyablement complexe. Le pattern Orchestrator résout ça en imposant strictement un modèle hub-and-spoke. Il y a un agent orchestrateur de plus haut niveau, et tous les autres agents sont traités strictement comme des tools que cet orchestrateur peut utiliser. Imaginons un scénario où ton système doit générer un briefing technique très documenté. Tu configures un agent orchestrateur pour agir comme un manager strict. Ce manager possède le state global. Il garde en mémoire le prompt utilisateur initial, détient le master context, et garde une trace de ce qui a été accompli jusque-là. Il ne fait pas le gros du travail lui-même. À la place, tu lui fournis des tools. Ces tools ne sont pas de simples wrappers d'API ou des calculatrices basiques. Ce sont des sous-agents entièrement séparés et pleinement fonctionnels. Tu pourrais créer un premier sous-agent dédié à la recherche, équipé de capacités de vector search et de web scraping. Tu pourrais créer un deuxième sous-agent dédié à la rédaction, équipé de guidelines stylistiques et d'une logique de formatage. Dans LlamaIndex, tu prends ces sous-agents et tu exposes leurs méthodes run comme des tools. En faisant ça, tu encapsules l'intégralité de leurs boucles de raisonnement internes derrière une interface de tool standard avec un nom et une description. Pour l'orchestrateur, ces sous-agents ressemblent exactement à des fonctions Python standards. Quand l'utilisateur demande le briefing, l'orchestrateur évalue l'objectif global en se basant sur les descriptions de tools que tu as fournies. Il décide d'appeler le tool de recherche en premier et lui passe les paramètres nécessaires. Le contrôle passe temporairement au sous-agent de recherche. Ce sous-agent exécute sa propre boucle autonome. Il peut faire trois ou quatre tool calls internes pour rassembler des données, synthétiser les faits et formuler une réponse. Une fois que l'agent de recherche a terminé, il condense tout ce travail dans une string de texte finale et la retourne. Voici le point clé. L'orchestrateur ne cède jamais vraiment le contrôle du process principal. Il attend juste que le tool retourne une valeur. L'orchestrateur reçoit le résumé de la recherche, l'ajoute à son propre context, et évalue l'étape suivante. Il se rend compte que les informations doivent être rédigées dans un document, alors il appelle le tool de rédaction, en passant la recherche toute fraîche comme paramètre d'input. Le sous-agent de rédaction prend le relais, fait son propre traitement interne, et renvoie le texte fini. L'orchestrateur voit que l'objectif final est atteint et délivre la réponse à l'utilisateur. Cette séparation stricte des responsabilités rend ton système hautement prévisible. L'agent de recherche n'a pas besoin de savoir que l'agent de rédaction existe. Aucun des deux sous-agents n'a à se soucier de passer le context, de formater la réponse finale de l'utilisateur, ou de décider quand le job global est terminé. L'orchestrateur centralise toute la logique de prise de décision de haut niveau. En forçant les sous-agents à fonctionner purement comme des tools isolés dans la boucle d'un manager central, tu peux construire des systèmes multi-agents extrêmement performants qui restent entièrement prévisibles et faciles à débugger. C'est tout pour cet épisode. À la prochaine !

Salut, c'est Alex de DEV STORIES DOT EU. LlamaIndex : Context-Augmented LLM Applications, épisode 10 sur 14. L'orchestration d'agents intégrée, c'est super jusqu'à ce que ta logique métier commence à ressembler à un plat de spaghettis. Quand les hand-offs standards n'arrivent plus à gérer tes règles de scheduling ultra spécifiques, les abstractions deviennent un blocker. C'est exactement là que tu as besoin des Custom Multi-Agent Planners. Un planner custom, c'est ta porte de sortie en tant que power-user. Il te permet de builder ta propre boucle d'orchestration from scratch en utilisant un Workflow LlamaIndex standard. Au lieu de te reposer sur un supervisor préconçu pour dicter quel agent doit agir ensuite, tu contrôles tout le processus de scheduling de manière impérative en Python. C'est toi qui dictes l'ordre d'exécution, le routing des données et le state management. Le processus commence généralement dans une classe custom, souvent appelée PlannerWorkflow. La première phase, c'est le planning. Quand un utilisateur soumet une requête, ton workflow envoie un prompt à un modèle de langage. Ce prompt inclut la query de l'utilisateur et une description stricte des tools ou des agents que tu as à disposition. Tu donnes l'instruction explicite au modèle de langage de générer un plan étape par étape dans un format ultra structuré. Par exemple, tu peux dire au modèle de wrapper chaque action dans un bloc XML en utilisant des tags step, ou de la formater comme un array JSON. Quand le modèle répond, tu parses cet output structuré. Tu utilises une librairie comme Pydantic pour valider le XML ou le JSON et le convertir en une liste concrète de tasks sur laquelle ton code peut itérer. Maintenant, tu entres dans la phase d'exécution. Cette partie dépend entièrement de ta logique custom. Ton workflow itère sur la liste de steps parsée, un par un. Pour chaque step, il vérifie l'action demandée. Tu utilises une logique conditionnelle standard pour décider de ce qu'il faut faire ensuite. Si le step parsé spécifie une task de recherche, ton code appelle explicitement ton agent de recherche. Si le step suivant nécessite un calcul, tu déclenches ton agent de maths. Voici le point clé. Vu que tu écris la loop toi-même, tu gardes le contrôle total sur le state. En général, tu crées un dictionnaire de contexte partagé qui vit pendant toute la durée du run de ton workflow. Quand ton agent de recherche termine sa task, ton workflow prend le résultat et l'écrit directement dans ce dictionnaire. Quand le step suivant déclenche l'agent de maths, ta logique custom peut lui passer les données exactes requises depuis ce dictionnaire partagé. Tu n'es pas en train d'espérer qu'un orchestrateur black-box passe les bonnes variables. Tu mappes explicitement les outputs d'un agent vers les inputs du suivant. Une fois que la loop a terminé tous les steps de ton plan validé, ton workflow effectue le formatage final et retourne la réponse. Builder un planner custom signifie que tu échanges la praticité de l'out-of-the-box contre un contrôle total. Si un agent échoue, tu peux écrire une logique de retry custom pour ce step spécifique. Si un step a besoin d'une validation d'API externe, tu peux mettre la loop en pause. Tu écris du code impératif standard qui se trouve juste utiliser des modèles de langage comme des fonctions. La valeur ultime d'un planner custom, c'est la prévisibilité. En forçant le modèle de langage à générer un plan XML rigide et en l'exécutant avec des loops et des dictionnaires Python standards, tu élimines complètement les incertitudes de l'orchestration black-box. C'est tout pour cet épisode. Merci de ton écoute, et keep building !

Salut, c'est Alex de DEV STORIES DOT EU. LlamaIndex : Context-Augmented LLM Applications, épisode 11 sur 14. Tu crées un agent pour gérer ton infrastructure, et il décide que la meilleure façon de résoudre une erreur est de supprimer une base de données de production. Ne laisse jamais un agent autonome effectuer une action destructrice sans avoir d'abord demandé explicitement la permission à un humain. Pour éviter ça, tu as besoin de workflows Human-in-the-Loop. Le Human-in-the-Loop est un mécanisme event-driven qui met un agent en pause, demande un input externe, et reprend l'exécution en fonction de la réponse. Au lieu de laisser l'agent tourner sans interruption dans son cycle de réflexion et d'action, tu interceptes les opérations à haut risque. Tu fais ça dans les workflows LlamaIndex en utilisant trois composants spécifiques : l'InputRequiredEvent, la méthode wait_for_event, et le HumanResponseEvent. Prends l'exemple d'un tool dangereux conçu pour supprimer une ressource cloud. L'agent décide qu'il a besoin d'utiliser ce tool et déclenche la step de workflow correspondante. Si le tool s'exécute immédiatement, la ressource disparaît. Au lieu de ça, la step du workflow intercepte l'exécution. Avant de supprimer quoi que ce soit, la step crée un InputRequiredEvent. Cet event transporte un payload contenant les détails de l'action, comme le nom de la ressource cible et un prompt demandant à l'utilisateur de confirmer la suppression. La step émet cet event vers l'application principale. Voici le point clé. La step du workflow ne peut pas juste rester dans une boucle active en attendant une réponse. Tu dois suspendre son state. Tu fais ça en appelant wait_for_event sur le contexte du workflow, en spécifiant que la step écoute maintenant un HumanResponseEvent. Cette action rend le contrôle à l'environnement. Le moteur de workflow met la step complètement en pause, figeant l'agent dans son state actuel sans consommer de ressources de compute pendant qu'il attend. En dehors du workflow, ta couche applicative attrape l'InputRequiredEvent. Tu lis le payload et tu affiches le prompt de confirmation à l'utilisateur sur son interface en ligne de commande. L'humain lit le warning et tape oui ou non. Maintenant, tu dois sortir l'agent de sa pause. Ton application prend l'input de l'utilisateur et l'encapsule dans un HumanResponseEvent. Tu renvoies ce nouvel event directement dans le moteur de workflow en cours d'exécution. Le moteur reconnaît le type d'event et le route vers la step exacte qui a été suspendue. La méthode wait_for_event se résout, et renvoie la string de réponse humaine à la logique du tool. Le tool évalue la réponse. Si l'humain a tapé oui, le tool procède à l'appel API pour supprimer la ressource cloud. Si l'humain a tapé non, le tool annule la suppression. Dans les deux cas, le tool renvoie un message de statut final à l'agent. L'agent traite ce résultat, comprend si l'action a réussi ou a été bloquée par l'utilisateur, et décide de son prochain mouvement. En utilisant des events pour mettre en pause et reprendre l'exécution, ton agent conserve l'intégralité de son contexte de raisonnement et de sa mémoire pendant qu'il attend des heures, voire des jours, qu'un humain prenne une décision. C'est tout pour cet épisode. Merci de ton écoute, et continue à développer !

Salut, c'est Alex de DEV STORIES DOT EU. LlamaIndex : Applications LLM enrichies par le contexte, épisode 12 sur 14. Quand un agent autonome fait une erreur, fouiller dans les print statements Python standards pour trouver le problème, c'est un vrai cauchemar. Tu poses une question simple, tu obtiens une réponse hallucinée, et la stack trace standard ne te dit absolument rien sur pourquoi le modèle a menti. Pour corriger ça, tu as besoin d'un moyen de voir à l'intérieur de la boîte noire. Cet épisode parle d'observabilité et de tracing. Les outils de debugging traditionnels ne suffisent pas avec les grands modèles de langage. Une stack trace te dit où le code a planté, mais les bugs de LLM sont généralement logiques. Le code tourne parfaitement, mais le système récupère le mauvais document ou interprète mal un prompt. Le logging Python standard est ta première ligne de défense. En passant le niveau de logging sur debug, LlamaIndex sort un flux brut de tout ce qu'il fait. Tu verras les prompts exacts envoyés au modèle de langage et les réponses HTTP brutes. C'est utile pour vérifier si un appel réseau a échoué, mais pour un workflow d'agent en plusieurs étapes, lire un mur de texte non structuré est incroyablement fastidieux. Voici l'idée clé. Tu n'as pas juste besoin d'un log d'événements ; tu as besoin de voir le call graph. Tu as besoin d'une vue structurée de la façon dont les données circulent, de la query initiale jusqu'aux retrievers, dans le modèle de langage, puis en retour. LlamaIndex gère ça avec un système de callbacks. Les callbacks sont des hooks qui se déclenchent à des moments précis du cycle d'exécution. Le framework fournit un outil intégré appelé le Llama debug handler. Tu initialises ce handler et tu l'attaches à tes paramètres globaux. À partir de là, il enregistre silencieusement chaque opération. Disons que tu lances un query engine, et qu'il te renvoie un fait complètement inventé. Sans tracing, tu n'as aucune idée si le modèle a halluciné ou si ta base de données lui a fourni de mauvaises informations. Avec le debug handler attaché, tu peux lui demander de print la trace une fois la query terminée. La trace révèle la séquence exacte des événements. Tu vois la query initiale. Tu vois l'étape de retrieval. Surtout, tu vois les text nodes exacts que le retriever a tirés de ton index. Tu inspectes ces nodes dans la trace et tu découvres qu'un document obsolète a été récupéré. Le modèle de langage n'a pas halluciné ; il a juste lu de mauvaises données. Tu corriges l'index, et le bug est résolu. Les traces dans le terminal sont super pour le développement local, mais elles ne scalent pas bien quand tu as des agents complexes qui font des dizaines d'étapes de raisonnement. Pour la production, LlamaIndex propose ce qu'ils appellent la one-click observability. En définissant une variable d'environnement spécifique ou en ajoutant une seule ligne de configuration, tu peux router toutes ces données de callback vers une plateforme d'observabilité dédiée. Ces plateformes ingèrent les données de trace et génèrent des dashboards visuels. Tu peux cliquer à travers un arbre visuel du workflow de ton agent, en inspectant la latence exacte, l'utilisation des tokens et le payload pour chaque étape. Tu n'as pas besoin d'instrumenter chaque fonction manuellement ; les callbacks natifs du framework s'occupent du gros du travail. La différence entre un prototype fragile et une application de production fiable, c'est de savoir si tu peux expliquer exactement pourquoi le système a généré une réponse spécifique. Si tu as trouvé ça utile et que tu veux soutenir l'émission, tu peux chercher DevStoriesEU sur Patreon. C'est tout pour aujourd'hui. Merci d'avoir écouté, et continue de coder !

Salut, c'est Alex de DEV STORIES DOT EU. LlamaIndex : Context-Augmented LLM Applications, épisode 13 sur 14. Tu changes ton embedding model et soudain, tes réponses te semblent un peu bizarres, mais tu n'arrives pas vraiment à mettre le doigt sur pourquoi. Si tu te contentes de vérifier les outputs à l'œil nu pour évaluer la qualité, ton pipeline avance à l'aveugle. Pour arrêter de te fier au feeling et éviter les régressions en production, tu as besoin de RAG Evaluation Metrics. Créer une application RAG, c'est facile, mais la rendre robuste, c'est difficile. Tu vas constamment ajuster la taille de tes chunks, tes prompts et tes stratégies de retrieval. Si tu comptes sur une vérification humaine pour tester chaque modification, tu vas soit ralentir le développement, soit deploy des régressions. Tu as besoin de mesures automatisées et objectives. Parce que le RAG consiste en deux étapes distinctes, trouver la bonne information et générer une réponse à partir de celle-ci, tu dois évaluer les deux phases séparément. Regardons d'abord la génération. C'est ce qu'on appelle la Response Evaluation. La métrique principale ici, c'est la faithfulness. Le but est de repérer les hallucinations. Une réponse fidèle, c'est quand le modèle de langage se base entièrement sur le contexte récupéré, plutôt que d'inventer des faits à partir de ses propres données de pre-training. Dans LlamaIndex, tu gères ça avec le FaithfulnessEvaluator. Cet outil utilise un modèle de langage sous le capot pour agir comme un juge. Tu initialises l'évaluateur, puis tu lui passes la query originale, l'array des nodes de contexte récupérés, et le texte final généré. L'évaluateur te retourne un objet d'évaluation contenant un boolean binaire pass ou fail, qui te dit si la réponse est strictement supportée par le contexte fourni. Il fournit aussi une string de raisonnement qui explique pourquoi le juge a pris cette décision. Si ton score de faithfulness chute après une mise à jour, c'est que ton prompt ou ton modèle de langage devient peut-être un peu trop créatif. Maintenant, passons à la deuxième partie. Même le meilleur modèle de langage ne peut pas générer une réponse fidèle si tu lui donnes les mauvais documents. C'est là qu'intervient la Retrieval Evaluation. Voici l'idée clé. Tu évalues le retrieval en vérifiant si le système a récupéré les source nodes exacts que tu attendais pour une query donnée, en ignorant complètement le texte final généré. Tu gères ça avec le RetrieverEvaluator. Imagine un scénario où tu veux tester un nouvel embedding model. Au lieu de le deploy et de deviner s'il est meilleur, tu construis un dataset d'évaluation. Ce dataset contient une liste de queries associées aux identifiants de documents spécifiques qui contiennent les bonnes réponses. Tu passes tout ton batch de queries dans le RetrieverEvaluator. L'évaluateur calcule deux métriques cruciales, le Hit Rate et le MRR. Le Hit Rate, c'est très simple. Il vérifie si le document attendu est apparu n'importe où dans le top de tes résultats récupérés. Si tu récupères cinq documents, et que le bon est dedans, c'est un hit. Ça mesure le recall pur. Mais la position compte. Si le bon document est toujours cinquième, ton modèle de langage risque de l'ignorer à cause des limites de contexte ou de l'attention decay. C'est là qu'intervient le Mean Reciprocal Rank, ou MRR. Le MRR regarde la position du premier document pertinent. Si le bon document est tout en haut, le score est de un. S'il est deuxième, le score est de un demi. S'il est troisième, un tiers. L'évaluateur fait la moyenne de ces fractions sur tout ton dataset. Un MRR plus élevé signifie que ton retriever pousse systématiquement l'information la plus pertinente tout en haut de la context window. En comparant le Hit Rate et le MRR de ton ancien embedding model avec le nouveau, tu obtiens une preuve mathématique pour savoir quel modèle est le plus performant. Tu peux suivre ces chiffres dans le temps et faire tourner ce pipeline automatiquement à chaque pull request. La chose la plus précieuse que tu puisses faire pour ton pipeline RAG, c'est de séparer l'évaluation de ce que tu récupères de la façon dont tu génères la réponse finale. Merci d'avoir passé quelques minutes avec moi. À la prochaine, prends soin de toi.

Salut, c'est Alex de DEV STORIES DOT EU. LlamaIndex : Applications LLM enrichies par le contexte, épisode 14 sur 14. Arrête de copier-coller la même API et le même boilerplate React à chaque fois que tu veux tester une nouvelle idée de Retrieval-Augmented Generation. Tu comprends déjà les mécaniques du framework, mais mettre en place une interface propre pour vraiment utiliser tes modèles te prend encore des heures de travail répétitif. Aujourd'hui, on couvre les outils de démarrage qui te permettent de scaffolder vers la production en quelques secondes. Construire une application fonctionnelle demande bien plus qu'un simple index et un query engine. Tu as besoin d'un serveur backend pour gérer les requêtes entrantes de manière sécurisée. Tu as besoin de routes API pour faire passer les messages dans les deux sens. Tu as besoin d'un client frontend pour afficher l'historique du chat, faire le rendu des loading states, et parser les réponses. Écrire cette infrastructure from scratch pour chaque nouveau dataset ou prototype te fait perdre un temps fou. Pour résoudre ça, LlamaIndex propose un utilitaire en ligne de commande appelé create-llama. Cet outil génère une application web full-stack complète, préconfigurée avec les best practices de LlamaIndex. Tu ouvres ton terminal et tu lances la commande create-llama. L'outil te guide ensuite à travers une série de choix. Il te demande si tu veux un backend Python avec FastAPI, ou un backend Node avec Express. Il te demande si tu veux un frontend Next JS pour offrir à tes utilisateurs une interface web soignée. Ensuite, il te demande ta source de données. Tu peux pointer l'outil directement vers un dossier local contenant tes fichiers PDF. Une fois que tu as fini de répondre aux prompts, create-llama prend le relais. Il installe toutes les dépendances requises. Il scaffold la structure des dossiers. Il écrit le script d'ingestion pour parser tes PDF. Il connecte les endpoints de l'API pour que ton frontend puisse parler à ton retrieval engine. Enfin, il configure les variables d'environnement. Tu lances une seule commande start, et tu as immédiatement une interface de chat stylisée qui tourne dans ton navigateur. Tu peux taper une question, et l'interface va taper sur le backend généré, récupérer le contexte de tes PDF, et streamer la réponse sur ton écran. Tu passes d'un dossier vide à un prototype full-stack fonctionnel en environ trente secondes. Ça, c'est pour les applications web. Mais parfois, un serveur web et une interface graphique, c'est overkill. Si tu viens juste de télécharger une longue spécification technique et que tu as besoin de la requêter immédiatement sans quitter ta ligne de commande, tu utilises la RAG CLI. La RAG CLI est un outil construit purement pour l'interaction avec des documents depuis le terminal. Tu l'installes, puis tu lances une commande pour la pointer vers ton dossier local de documents. La CLI lance automatiquement le processus d'ingestion. Elle chunk le texte, génère les embeddings, et les stocke dans une base de données vectorielle locale, directement sur ta machine. Quand l'ingestion est terminée, tu lances la commande chat. Ton prompt de terminal standard se transforme en session de chat. Tu poses une question, la CLI récupère les données pertinentes, requête le modèle de langage, et affiche la réponse générée directement dans ta console. Il n'y a aucun composant visuel ni aucune route web à configurer. C'est le moyen le plus rapide dans l'absolu pour parler à tes données en local. Voici le point clé. Tu comprends maintenant les mécaniques profondes des applications augmentées par le contexte, du chunking de documents jusqu'à la création de routeurs d'agents complexes. Ces outils de scaffolding existent pour que tu puisses arrêter de te battre avec l'infrastructure de base et passer ton temps à tuner ces stratégies de retrieval centrales. Comme c'est le dernier épisode de notre série LlamaIndex, la meilleure prochaine étape est de te rendre sur la documentation officielle et d'essayer de construire ces pipelines hands-on. Si tu as une idée pour une stack technologique complètement différente que tu veux qu'on couvre, visite devstories dot eu pour suggérer un sujet. C'est tout pour cet épisode. Merci d'avoir écouté, et continue de développer !