Les 31 techniques RAG avancées de Stanford pour vos agents IA en production

Q: Quelle est la taille de chunk idéale pour le RAG ?

Stanford recommande ~500 tokens comme point de départ, avec un overlap de 50 à 100 tokens entre chunks adjacents. Cette taille équilibre la préservation du contexte sémantique et la qualité des embeddings.

Q: Comment évaluer la performance d'un pipeline RAG ?

Stanford recommande quatre métriques : Precision@K, Recall@K, MRR et NDCG. Le framework RAGAS permet d'automatiser cette évaluation en mesurant fidélité, pertinence et complétude des réponses générées.

Q: Qu'est-ce que le prompt caching et comment réduit-il les coûts ?

Le prompt caching met en cache les préfixes de prompt répétitifs entre plusieurs appels API. Les tokens mis en cache sont facturés 10x moins cher. Pour un agent traitant des centaines de requêtes quotidiennes, l'économie peut atteindre 60 à 80% de la facture API.

Temps de lecture : ~18 min | Niveau : Avancé (CTO, Tech Lead, Développeur IA)

En bref :
Une conférence de 2h à Stanford distille 31 techniques avancées sur les agents IA, les LLM et le RAG. Points clés : la knowledge cutoff est la plus grande limitation des LLM (RAG la résout sans réentraînement), les stratégies de chunking et d’embedding déterminent 80% de la qualité de retrieval, et la boucle ReAct (Observe → Plan → Act) est le cœur de tout agent IA autonome en production.

Sommaire

Pourquoi Stanford s’intéresse aux agents IA et au RAG en production
Bloc 1 — Fondations RAG : chunking, embedding et retrieval (techniques 1 à 9)
Bloc 2 — Optimisation des coûts et de la précision (techniques 10 à 12)
Bloc 3 — Tool Calling : transformer le LLM en agent actif (techniques 13 à 21)
Bloc 4 — Architecture des agents IA : la boucle ReAct (techniques 22 à 27)
Bloc 5 — Systèmes multi-agents et sécurité (techniques 28 à 30)
Technique 31 — La règle d’or : commencer petit
Comment Agentsia applique ces 31 techniques en production
FAQ

Pourquoi Stanford s’intéresse aux agents IA et au RAG en production

Il existe des centaines de tutoriels RAG sur Internet. La plupart s’arrêtent à la même architecture basique : un PDF découpé en morceaux, un modèle d’embedding, une recherche vectorielle, une réponse générée. C’est suffisant pour un prototype. C’est insuffisant pour la production.

Ce qui distingue cette conférence de 2h dispensée à Stanford, c’est la densité opérationnelle de son contenu : 31 techniques directement applicables, organisées autour des trois piliers d’un système IA robuste — la récupération d’information, l’appel d’outils, et l’architecture des agents. Pas de théorie creuse. Pas de démo Jupyter qui ne tourne que sur le laptop de la conférencière.

La knowledge cutoff : la plus grande limitation des LLM

Voici le problème que tout CTO rencontre dans les six premières semaines d’un projet LLM en entreprise.

Un modèle de langage, aussi puissant soit-il, ne sait rien de ce qui s’est passé après sa date d’entraînement. GPT-4o a une knowledge cutoff. Claude aussi. Gemini aussi. Votre documentation interne, vos procédures mises à jour la semaine dernière, vos prix révisés ce matin — le modèle n’en a aucune connaissance.

La solution naïve ? Réentraîner le modèle. Coût : plusieurs millions de dollars et plusieurs semaines de calcul pour les grands modèles. Inenvisageable pour 99% des entreprises.

La solution correcte : le RAG (Retrieval-Augmented Generation). Plutôt que de graver les connaissances dans les poids du modèle, on les injecte dynamiquement dans le contexte, au moment de l’inférence. Le modèle reste généraliste ; la base de connaissances reste à jour.

Stanford le formule ainsi : « RAG fixes the knowledge cutoff without retraining. » C’est la technique 1 — et c’est le fondement de tout le reste.

Ce que distille cette conférence de 2h

La conférencière ne présente pas RAG comme une fonctionnalité. Elle le présente comme une discipline d’ingénierie avec ses propres métriques, ses propres patterns architecturaux, ses propres pièges en production.

Les 31 techniques se répartissent en cinq blocs logiques :

Bloc	Techniques	Thème
Fondations RAG	1 → 9	Chunking, embedding, retrieval
Optimisation	10 → 12	Coûts, re-ranking, évaluation
Tool Calling	13 → 21	Outils, routing, MCP
Architecture agents	22 → 27	ReAct, Observe/Plan/Act
Sécurité & Scale	28 → 31	Multi-agents, gardes-fous, méthode

Décortiquons chaque bloc.

Bloc 1 — Fondations RAG : chunking, embedding et retrieval (techniques 1 à 9)

Technique 1 — Knowledge cutoff et RAG

Le problème : votre LLM ne connaît pas votre catalogue produit mis à jour, votre nouvelle politique RH, ni la réglementation publiée le mois dernier.

La solution RAG : au moment où l’utilisateur pose une question, le système récupère les passages pertinents depuis votre base documentaire et les injecte dans le prompt. Le LLM répond alors avec une information à jour — sans avoir été réentraîné.

Cas d’usage entreprise : un agent support client qui répond sur la base des fiches produit actuelles, sans jamais halluciner une caractéristique obsolète. [INTERNAL LINK: découvrez comment Agentsia gère le traitement documentaire → https://www.agentsia.fr/traitement-automatique-documents-agents-ia/]

Technique 2 — Ne jamais injecter tout le contexte

C’est une erreur classique des équipes qui débutent avec RAG : injecter l’intégralité d’un document dans le prompt parce que « le modèle a une grande fenêtre de contexte ».

Pourquoi c’est une mauvaise idée :

Le coût en tokens explose (et donc la facture API)
La qualité de la réponse diminue — les LLM sont moins précis quand le contexte est bruité
La latence augmente mécaniquement

La règle Stanford : récupérer uniquement les chunks pertinents à la requête. Trois à cinq chunks bien ciblés surpassent systématiquement vingt chunks injectés en vrac.

Technique 3 — Taille de chunk optimale : ~500 tokens

La taille de chunk est l’un des paramètres les plus sous-estimés d’un pipeline RAG. Trop petit : le chunk perd son contexte, l’embedding ne capture pas le sens complet. Trop grand : l’embedding dilue les signaux sémantiques, la précision de retrieval chute.

Le consensus Stanford : ~500 tokens (avec un overlap de 50 à 100 tokens entre chunks adjacents pour ne pas couper les idées à la frontière).

Règle pratique :

Documents techniques denses → chunks de 400-600 tokens
FAQ ou procédures courtes → chunks de 200-300 tokens
Contrats ou documents légaux → chunking sémantique par clause (ignorer la taille fixe)

Techniques 4 à 6 — Retrieval en deux étapes, bi-encodeurs et BM25

Technique 4 — Two-stage retrieval

Le retrieval en une seule étape choisit entre la vitesse (mais imprécis) et la précision (mais lent). La solution : deux étapes complémentaires.

Étape 1 — Candidate retrieval : maximiser le recall. Récupérer un large ensemble de candidats potentiellement pertinents (top-50, top-100). La vitesse prime.
Étape 2 — Ranking : maximiser la precision. Sur ces candidats, appliquer un modèle plus puissant pour ne garder que les 3 à 5 meilleurs chunks.

Technique 5 — Bi-encodeurs (SBERT)

Les bi-encodeurs encodent la requête et le document séparément, puis calculent la similarité cosinus entre les deux vecteurs. C’est ce qui propulse la recherche sémantique rapide : les embeddings des documents sont précalculés et stockés en base vectorielle. À l’inférence, seule la requête est encodée — la comparaison est quasi-instantanée.

Modèles recommandés : sentence-transformers/all-MiniLM-L6-v2 (léger), text-embedding-3-large d’OpenAI (haute qualité).

Technique 6 — BM25 pour le matching exact

BM25 est un algorithme de recherche full-text classique (la base de moteurs comme Elasticsearch). Il excelle quand la requête contient des termes précis : un numéro de référence, un nom propre, un identifiant produit.

Cas d’usage : un agent qui doit retrouver la fiche du « Contrat-Cadre n°2024-FR-1872 » dans une GED. La recherche sémantique échoue sur les identifiants exacts — BM25 les retrouve parfaitement.

Techniques 7 à 9 — Hybrid retrieval, HyDE et contextual retrieval

Technique 7 — Hybrid retrieval : embeddings + BM25

Ni la recherche sémantique ni BM25 ne sont universellement supérieures. La combinaison des deux bat les deux méthodes séparément sur la quasi-totalité des benchmarks.

Architecture typique :

Requête utilisateur
    ├── Recherche vectorielle (SBERT) → top-50 chunks sémantiques
    └── BM25 → top-50 chunks par mots-clés
              ↓
        Fusion (RRF - Reciprocal Rank Fusion)
              ↓
        Top-5 chunks finaux → LLM

Technique 8 — HyDE (Hypothetical Document Embeddings)

HyDE résout un problème subtil : la requête d’un utilisateur (« comment configurer le SSO ? ») a une structure sémantique très différente des documents qui y répondent (« Guide d’administration — Configuration SAML 2.0… »).

La technique : demander au LLM de générer d’abord un document hypothétique qui répondrait à la question, puis embedder ce document hypothétique pour chercher les vrais documents similaires. L’embedding d’une réponse hypothétique est sémantiquement plus proche des documents réels que l’embedding de la question elle-même.

Résultat : amélioration mesurable du recall sur les requêtes complexes ou ambiguës.

Technique 9 — Contextual retrieval

Problème classique : un chunk extrait de son document perd son contexte. « Il a signé le contrat le 15 mars » — qui est « il » ? Quel contrat ?

La solution : avant d’embedder chaque chunk, lui préfixer un résumé de son contexte (« Dans le contrat de prestation de service entre Agentsia et le client X, daté du 10 mars 2024, concernant le déploiement d’agents IA… »). Le chunk devient auto-porteur. La qualité de retrieval s’améliore significativement.

[INTERNAL LINK: problèmes de RAG en production → https://www.agentsia.fr/semantic-collapse-agents-rag-production/]

Bloc 2 — Optimisation des coûts et de la précision (techniques 10 à 12)

Technique 10 — Prompt caching : diviser les coûts par 10

Quand un pipeline RAG traite plusieurs chunks, il répète souvent les mêmes éléments dans chaque appel API : le system prompt, les instructions, le contexte statique. Sans caching, vous payez ces tokens à chaque appel.

Le prompt caching (disponible sur Anthropic Claude, OpenAI) permet de mettre en cache les préfixes de prompt coûteux. Les tokens mis en cache sont facturés 10x moins cher (ou parfois gratuits) lors des appels suivants.

Calcul d’impact :

System prompt : 2 000 tokens × 1 000 appels/jour = 2M tokens/jour
Avec caching : 200 000 tokens facturés au tarif normal + 1,8M tokens au tarif réduit
Économie estimée : 60-80% sur la facture API

Cas d’usage entreprise : un agent de support qui traite 500 tickets/jour avec le même contexte produit de 3 000 tokens. Le ROI du caching est immédiat.

Technique 11 — Cross-encoders pour le re-ranking

Les bi-encodeurs sont rapides mais imprécis : ils comparent des vecteurs précalculés séparément. Les cross-encoders font mieux : ils prennent la requête ET le chunk ensemble, les passent dans un modèle de transformer, et produisent un score de pertinence précis.

La différence en pratique :

Bi-encoder : « Cette phrase est proche de cette autre phrase » (comparaison de vecteurs)
Cross-encoder : « Cette réponse répond-elle vraiment à cette question ? » (compréhension croisée)

Architecture recommandée :

Bi-encoder → top-50 candidats (rapide)
Cross-encoder → re-ranking → top-5 finaux (précis)

Modèle de référence : cross-encoder/ms-marco-MiniLM-L-6-v2 (Hugging Face).

Technique 12 — Évaluation rigoureuse : NDCG, MRR, Precision, Recall

« Evaluate with NDCG, MRR, Precision, Recall — not just vibes. »

C’est probablement la technique la plus négligée en entreprise. La plupart des équipes évaluent leur pipeline RAG en demandant à quelques collègues si « ça semble bien ». C’est insuffisant.

Les métriques qui comptent :

Métrique	Ce qu’elle mesure	Quand l’utiliser
Precision@K	% de chunks pertinents parmi les K récupérés	Quand la précision prime (support client)
Recall@K	% de chunks pertinents retrouvés parmi tous les pertinents	Quand le recall prime (recherche légale)
MRR (Mean Reciprocal Rank)	Position du premier chunk pertinent	Quand le premier résultat doit être le bon
NDCG (Normalized Discounted Cumulative Gain)	Qualité du classement global	Évaluation complète du retrieval

Outil recommandé : le framework RAGAS permet d’évaluer automatiquement la fidélité, la pertinence et la complétude des réponses RAG.

Bloc 3 — Tool Calling : transformer le LLM en agent actif (techniques 13 à 21)

Techniques 13 à 15 — Définition, API et flux en 3 étapes

Technique 13 — Qu’est-ce que le tool calling ?

Un LLM seul est passif : il génère du texte. Un LLM avec tool calling est actif : il peut déclencher des actions dans des systèmes externes — appeler une API, exécuter du code, lire une base de données, envoyer un email.

Définition Stanford : « Tool calling = LLMs completing tasks by accessing external resources dynamically. »

Technique 14 — Définir les outils avec des APIs claires

Chaque outil doit être défini avec :

Un nom de fonction explicite (get_customer_order, pas function_1)
Des arguments typés avec descriptions précises
Une documentation qui explique quand utiliser l’outil
Pas d’implémentation dans la définition — seulement l’interface

Exemple d’une bonne définition d’outil :

{
  "name": "get_contract_status",
  "description": "Retrieves the current status of a contract by ID. Use this when the user asks about a specific contract.",
  "parameters": {
    "contract_id": {"type": "string", "description": "The unique contract identifier (e.g., 'CTR-2024-1872')"},
    "include_history": {"type": "boolean", "description": "Whether to include modification history", "default": false}
  }
}

Technique 15 — Le flux en 3 étapes

1. LLM prédit → quel outil appeler + quels arguments
2. Exécution → le système exécute l'outil et récupère le résultat
3. LLM synthétise → il intègre le résultat et génère la réponse finale

Ce flux est répété autant de fois que nécessaire. Un agent peut enchaîner 5, 10, 20 appels d’outils pour accomplir une tâche complexe.

Techniques 16 à 18 — SFT, prompting et itération

Technique 16 — Supervised Fine-Tuning (SFT) pour le tool calling

Pour entraîner un modèle à utiliser des outils, Stanford recommande deux types de paires d’entraînement :

Paire 1 : [requête utilisateur] → [appel d'outil correct avec arguments]
Paire 2 : [résultat de l'outil] → [réponse en langage naturel]

Les deux sont nécessaires. Entraîner uniquement sur la première paire produit un modèle qui appelle les bons outils mais génère des réponses robotiques.

Technique 17 — Pour les modèles code-fluents : skip the SFT

Si vous utilisez un modèle déjà entraîné sur du code (GPT-4o, Claude Sonnet, Gemini Pro), le SFT n’est souvent pas nécessaire. Ces modèles comprennent nativement les structures JSON, les signatures de fonctions et les appels d’API.

La stratégie : des prompts détaillés avec des chaînes de raisonnement (chain-of-thought) sont plus efficaces et moins coûteux que le fine-tuning.

Technique 18 — Itérer sur les prompts avec des sets d’évaluation

Ne jamais modifier un prompt « à l’instinct ». La méthode rigoureuse :

Construire un jeu d’évaluation de 50-100 cas représentatifs
Mesurer la performance du prompt actuel sur ce jeu
Modifier le prompt
Mesurer à nouveau
Laisser un modèle de raisonnement (o1, o3) déboguer les instructions qui échouent

Techniques 19 à 21 — Catégories d’outils, routing et MCP

Technique 19 — Les trois catégories d’outils

Stanford classe les outils en trois catégories :

Catégorie	Exemples	Risque
Information retrieval	Recherche web, requête BDD, lecture fichier	Faible
Computation	Calcul, exécution de code, analyse de données	Moyen
Action execution	Envoi d’email, modification de BDD, paiement	Élevé

Plus la catégorie est « action », plus les gardes-fous sont nécessaires.

Technique 20 — Tool routing : critique au-delà de 10 outils

Avec 5 outils, le LLM choisit facilement le bon. Avec 50 outils, deux problèmes apparaissent :

Context overload : décrire 50 outils dans le prompt consomme des milliers de tokens
Confusion de sélection : le modèle hésite entre des outils similaires

La solution : un sélecteur d’outils LLM en amont qui, à partir de la requête, filtre les 3 à 5 outils pertinents parmi des centaines. C’est une étape de routing qui précède l’agent principal.

Technique 21 — MCP (Model Context Protocol) : la standardisation

Sans standard, chaque intégration d’outil est réimplémentée pour chaque LLM. Anthropic a proposé le MCP (Model Context Protocol) comme standard ouvert pour définir, exposer et consommer des outils de manière uniforme.

Avantage concret : un outil MCP développé pour Claude fonctionne sans modification avec GPT-4o ou Gemini. La portabilité devient réelle.

[INTERNAL LINK: protocoles agents IA MCP, A2A, ACP, AGP → https://www.agentsia.fr/protocole-agent-ia-mcp-a2a-acp-agp-2026/]

Bloc 4 — Architecture des agents IA : la boucle ReAct (techniques 22 à 27)

Technique 23 — Définition d’un agent IA autonome

« Agent = autonomous system that pursues goals through reasoning + tool use loops. »

Un agent IA n’est pas un chatbot sophistiqué. La différence est fondamentale :

Un chatbot répond à une question → s’arrête
Un agent reçoit un objectif → planifie → agit → observe le résultat → replannifie → agit à nouveau → jusqu’à atteindre l’objectif

L’autonomie vient de cette boucle de raisonnement-action. L’agent ne demande pas la permission à chaque étape. Il prend des décisions intermédiaires seul.

[INTERNAL LINK: définition complète d’un agent IA pour l’entreprise → https://www.agentsia.fr/quest-ce-quun-agent-ia-definition-pour-lentreprise/]

Technique 24 — La boucle ReAct : Observe → Plan → Act

ReAct (Reasoning + Acting) est le pattern architectural central de tout agent IA en production. C’est la boucle qui transforme un LLM passif en système autonome.

┌─────────────────────────────────────┐
│           BOUCLE ReAct              │
│                                     │
│  [Objectif reçu]                    │
│         ↓                           │
│    OBSERVE ──→ Comprendre l'état    │
│         ↓                           │
│     PLAN ──→ Décider l'action       │
│         ↓                           │
│      ACT ──→ Exécuter l'outil       │
│         ↓                           │
│   [Résultat] ──→ Objectif atteint ? │
│         │              │            │
│        Non            Oui           │
│         └──→ OBSERVE ← ┘ → STOP    │
└─────────────────────────────────────┘

La boucle tourne jusqu’à ce que l’objectif soit atteint — ou jusqu’à une condition d’arrêt (nombre max d’itérations, timeout, confidence threshold).

Techniques 25 à 27 — Détail de chaque phase de ReAct

Technique 25 — OBSERVE : traduire l’intention en état actionnable

La phase Observe ne se contente pas de « lire » la requête. Elle :

Extrait l’intention réelle de l’utilisateur (pas toujours ce qui est dit)
Consulte la mémoire de l’agent (historique de la conversation, état précédent)
Évalue l’état courant du système (quels outils ont déjà été appelés, quels résultats obtenus)
Produit une représentation d’état structurée qui alimentera la phase Plan

Technique 26 — PLAN : décider la prochaine action

À partir de l’état observé, le LLM décide :

Quel outil appeler en priorité ?
Avec quels arguments ?
Faut-il décomposer la tâche en sous-tâches ?
L’objectif est-il déjà atteint ?

La qualité du Plan dépend directement de la qualité du system prompt et de la clarté de la définition des outils.

Technique 27 — ACT : exécuter et réinjecter

L’action est exécutée (appel d’outil, requête API, calcul). Le résultat est réinjecté dans le contexte de l’agent, qui peut alors observer le nouvel état et planifier l’étape suivante.

Cas d’usage entreprise : un agent RH qui doit traiter une demande de congé.

Observe : demande de congé du 15 au 22 juillet pour l’employé ID-4521
Plan : vérifier le solde de congés → appeler check_leave_balance(employee_id="4521")
Act : solde = 12 jours, demande = 5 jours → OK
Observe : solde suffisant, vérifier les conflits d’équipe
Plan : appeler check_team_availability(dates="2024-07-15/22", team="engineering")
Act : 2 collègues déjà absents → alerte
Plan : notifier le manager → appeler send_notification(manager_id="M-012", ...)
Objectif atteint → réponse à l’employé

Bloc 5 — Systèmes multi-agents et sécurité (techniques 28 à 30)

Technique 28 — Multi-agents et protocole Agent2Agent

Quand une tâche est trop complexe pour un seul agent, on orchestre plusieurs agents spécialisés. Mais cette orchestration pose un problème fondamental : comment les agents communiquent-ils entre eux ?

Sans standard, chaque système multi-agents réinvente sa propre API de communication. Google a proposé le protocole Agent2Agent (A2A) comme standard ouvert pour la communication inter-agents.

Architecture typique :

Agent orchestrateur
    ├── Agent RAG (recherche documentaire)
    ├── Agent Analytics (analyse de données)
    ├── Agent Communication (emails, Slack)
    └── Agent Validation (vérification des résultats)

Chaque agent expose ses capacités via A2A. L’orchestrateur délègue, collecte les résultats, et synthétise la réponse finale.

[INTERNAL LINK: plateforme d’orchestration d’agents IA → https://www.agentsia.fr/plateforme-orchestration-agents-ia/]

Techniques 29 à 30 — Sécurité : gardes-fous et classifieurs d’inférence

Technique 29 — Les trois vecteurs d’attaque critiques

Stanford identifie trois risques majeurs pour les agents en production :

Data exfiltration : un agent avec accès à des données sensibles peut être manipulé pour les exfiltrer via des prompt injections
Harmful actions : un agent avec des outils d’action (envoi d’email, modification BDD) peut être détourné pour exécuter des actions malveillantes
Jailbreaks : contournement des instructions de sécurité via des prompts adversariaux

Technique 30 — Deux couches de protection

Couche 1 — Training-time safeguards : entraîner le modèle à refuser les requêtes dangereuses. Efficace mais coûteux à maintenir à jour.

Couche 2 — Inference-time classifiers : un modèle léger qui analyse chaque requête avant qu’elle atteigne l’agent principal. Si la requête est classifiée comme dangereuse, elle est bloquée.

Architecture de sécurité recommandée :

Requête utilisateur
    ↓
[Classifieur de sécurité] → Bloqué si score > seuil
    ↓
[Agent principal]
    ↓
[Validation des actions] → Confirmation humaine si action à risque élevé
    ↓
Réponse / Action exécutée

Technique 31 — La règle d’or : commencer petit

Prototype → optimisation : la méthode Stanford

« Start small: prototype with simple tools on capable models, then optimize. »

C’est peut-être la technique la plus importante — et la plus contre-intuitive pour des équipes techniques qui veulent « faire les choses bien dès le départ ».

La méthode Stanford en 4 phases :

Phase 1 — Prototype : un seul agent, 2-3 outils simples, le modèle le plus capable disponible (GPT-4o, Claude Sonnet). Pas d’optimisation des coûts. Pas de fine-tuning. L’objectif est de valider que le cas d’usage fonctionne.

Phase 2 — Évaluation : construire le jeu d’évaluation. Mesurer les métriques (Precision, Recall, taux de succès des tâches). Identifier les points de défaillance.

Phase 3 — Optimisation ciblée : maintenant seulement, optimiser ce qui en vaut la peine — chunking, re-ranking, prompt caching, routing d’outils.

Phase 4 — Scale : passage à un modèle plus léger (si la qualité est maintenue), infrastructure de production, monitoring continu.

L’erreur à éviter : commencer par l’architecture la plus complexe (multi-agents, fine-tuning, infrastructure distribuée) avant d’avoir validé le cas d’usage. Vous optimiserez quelque chose qui ne fonctionne peut-être pas.

Comment Agentsia applique ces 31 techniques en production

De la théorie Stanford à la plateforme d’orchestration

Ces 31 techniques ne sont pas des concepts abstraits. Elles sont le fondement de ce que la plateforme Agentsia implémente pour les entreprises françaises qui déploient des agents IA en production.

Sur le RAG : Agentsia intègre nativement le hybrid retrieval (embeddings + BM25), le contextual retrieval avec résumés de chunks, et le re-ranking par cross-encoder. La taille de chunk est configurable par type de document — pas un paramètre figé.

Sur le tool calling : la plateforme expose un catalogue d’outils standardisés MCP (connecteurs CRM, ERP, GED, API métier) et intègre un router intelligent qui sélectionne les 3 à 5 outils pertinents parmi plusieurs dizaines selon le contexte de la requête.

Sur l’architecture agents : chaque agent Agentsia implémente la boucle ReAct avec mémoire persistante, gestion des états et logging complet pour l’audit. La plateforme supporte nativement les architectures multi-agents avec orchestration via le protocole A2A.

Sur la sécurité : un classifieur d’inférence analyse chaque requête avant qu’elle atteigne les agents. Les actions à risque élevé (modification de données, envoi de communications) passent par une validation configurable.

[INTERNAL LINK: découvrir la plateforme d’orchestration Agentsia → https://www.agentsia.fr/plateforme-orchestration-agents-ia/]

Vous n’avez pas à implémenter ces 31 techniques vous-même. Vous pouvez déployer votre premier agent en production en quelques jours — avec toutes les bonnes pratiques Stanford déjà intégrées.

Le lien vers la vidéo : Stanford CME295 Transformers & LLMs | Autumn 2025 | Lecture 7 – Agentic LLMs

FAQ — Les 31 techniques RAG avancées de Stanford

Qu’est-ce que le RAG et pourquoi est-il essentiel pour les agents IA ?

Le RAG (Retrieval-Augmented Generation) est une technique qui permet à un LLM d’accéder à des connaissances externes et actualisées sans réentraînement. Il résout la knowledge cutoff des modèles en injectant dynamiquement les informations pertinentes dans le contexte de chaque requête. Pour les agents IA en entreprise, c’est le fondement de tout système basé sur des données internes à jour.

Quelle est la taille de chunk idéale pour le RAG ?

Stanford recommande ~500 tokens comme point de départ, avec un overlap de 50 à 100 tokens entre chunks adjacents. Cette taille équilibre la préservation du contexte sémantique et la qualité des embeddings. Pour des documents très structurés (contrats, procédures), le chunking sémantique par section est préférable à une taille fixe.

Qu’est-ce que la boucle ReAct dans un agent IA ?

ReAct (Reasoning + Acting) est le pattern architectural central des agents IA autonomes. Il se décompose en trois phases répétées en boucle : Observe (comprendre l’état et l’intention), Plan (décider la prochaine action), Act (exécuter l’outil et réinjecter le résultat). La boucle continue jusqu’à ce que l’objectif soit atteint.

Comment évaluer la performance d’un pipeline RAG ?

Stanford recommande quatre métriques objectives : Precision@K (% de chunks pertinents parmi les K récupérés), Recall@K (% de chunks pertinents retrouvés), MRR (position du premier résultat pertinent) et NDCG (qualité du classement global). Le framework RAGAS permet d’automatiser cette évaluation en mesurant fidélité, pertinence et complétude des réponses générées.

Qu’est-ce que le prompt caching et comment réduit-il les coûts ?

Le prompt caching permet de mettre en cache les préfixes de prompt répétitifs (system prompt, contexte statique) entre plusieurs appels API. Les tokens mis en cache sont facturés 10x moins cher par les principaux fournisseurs (Anthropic, OpenAI). Pour un agent traitant des centaines de requêtes quotidiennes avec le même contexte de base, l’économie peut atteindre 60 à 80% de la facture API.