D3 · Integration (incl. RAG)

C’est le plus grand domaine de l’examen – 19 %, environ 12 des 63 items. Il est dominé par l’architecture RAG mais couvre aussi la gouvernance des capacités des outils/agents, l’identité et l’autorisation, le choix du mécanisme d’intégration, l’observabilité à l’échelle, et les patrons d’intégration en entreprise. Le jugement récurrent testé : quand une réponse est confiante mais fausse, suspectez la récupération et l’indexation avant le modèle ; et quand un agent a de nombreux outils, appliquez le moindre privilège en supprimant des capacités, non en les journalisant ou en les confirmant.

Objectifs d’apprentissage

À la fin de cette page, vous devriez savoir :

1. Concevoir un pipeline RAG étape par étape : ingestion → chunking → embedding → indexation → récupération → rerank → grounding.
2. Accorder une stratégie de chunking à la forme des données.
3. Choisir la récupération dense vs sparse vs hybride et un index/vector store avec filtres de métadonnées.
4. Améliorer la récupération avec le reranking, la réécriture de requête, HyDE, le multi-query, MMR.
5. Évaluer la récupération (recall@k, MRR, faithfulness, pertinence de réponse) et déboguer les réponses confiantes-mais-fausses.
6. Trancher entre RAG, long contexte (1M) et fine-tuning ; concevoir le RAG agentique.
7. Mener l’analyse de surcharge de capacités / moindre privilège et combler les écarts authn/authz.
8. Choisir les mécanismes d’intégration (MCP vs API/CLI vs agent-à-agent), concevoir l’observabilité à l’échelle, et appliquer les patrons d’intégration en entreprise (files, webhooks, idempotence, batch, fraîcheur).

3.1 The RAG pipeline, stage by stage

Le Retrieval-Augmented Generation ancre le modèle dans vos données en récupérant des passages pertinents et en les plaçant dans le contexte au moment de la requête. Apprenez le pipeline comme un squelette fixe ; chaque décision de conception s’insère dans une étape.

  INGESTION            INDEX-BUILD (offline)                    QUERY-TIME (online)
 ┌──────────┐   ┌───────────────────────────────┐   ┌───────────────────────────────────┐
 │ sources  │   │ clean → chunk → embed →        │   │ query → (rewrite/HyDE/multi-query) │
 │ (docs,   │──▶│ write vectors + metadata to    │   │  → retrieve top-k (dense+sparse)   │
 │  DB, web)│   │ vector store / search index    │   │  → rerank → assemble context       │
 └──────────┘   └───────────────────────────────┘   │  → Claude generates grounded answer │
      │  freshness / refresh pipeline ▲              │  → cite sources → validate          │
      └──────────────────────────────┘              └───────────────────────────────────┘

3.2 Chunking strategies matched to data shape

Le chunking est la décision RAG à plus fort levier. La bonne stratégie dépend de la structure de la source.

Document shape?
  ├─ Structured (headings/tables/code) → structural / document-aware chunking
  ├─ Long, cross-referential prose      → parent–child or late chunking
  ├─ Topically shifting prose           → semantic chunking
  └─ Uniform prose, need a baseline     → recursive (fall back to fixed)

3.3 Embeddings and indexing

Dense vs sparse vs hybride

La plupart des RAG de production utilisent la récupération hybride (p. ex. fusion par reciprocal-rank de BM25 et dense) car les vraies requêtes mêlent concepts et identifiants exacts.

Vector store et filtres de métadonnées

Les filtres de métadonnées sont aussi un contrôle de sécurité : filtrer par tenant_id et ACL par utilisateur au moment de la récupération est la façon d’empêcher les fuites cross-tenant/de permission (voir 3.9).

3.4 Retrieval and re-ranking techniques

Une recette de haute précision courante : récupérer large (k=50, hybride) → reranker → garder les 5–8 premiers → grounder. Le reranking est souvent le plus grand gain de précision à lui seul.

query ─▶ [rewrite / multi-query] ─▶ hybrid retrieve (k=50)
                                        │
                                        ▼
                                    reranker  ─▶ top 6 ─▶ context ─▶ Claude

3.5 Grounding and citations

Le grounding signifie que la réponse est contrainte aux passages récupérés, et que chaque affirmation est traçable.

• Instruisez le modèle de répondre uniquement à partir du contexte fourni et de dire quand le contexte est insuffisant (ne jamais inventer).
• Utilisez la fonctionnalité Citations / des références structurées pour que chaque affirmation renvoie à son chunk source et à sa localisation.
• Renvoyez insufficient context plutôt qu’une supposition tirée de la mémoire paramétrique quand la récupération échoue — un système grounded préfère « je n’ai pas cela » à une fabrication confiante.

{
  "system": "Answer ONLY from <context>. Cite the source id for each claim. If the context does not contain the answer, say so.",
  "messages": [
    {"role": "user", "content": "<context>{retrieved_chunks_with_ids}</context>\n\nQuestion: What is the termination notice period?"}
  ]
}

3.6 Evaluating retrieval

Vous ne pouvez pas corriger ce que vous ne mesurez pas. La récupération et la génération sont évaluées séparément pour savoir quelle étape a échoué.

3.7 Débogage des réponses confiantes-mais-fausses après un rafraîchissement de document

C’est un scénario d’examen emblématique. Un document est mis à jour ; l’assistant continue de donner l’ancienne réponse, avec assurance. L’instinct de blâmer le prompt ou le modèle est faux.

1. Suspectez d’abord l’index. Le document rafraîchi a-t-il été re-chunké, ré-embarqué et ré-indexé ? Un rafraîchissement qui met à jour le store source mais pas l’index vectoriel laisse des vecteurs périmés que la récupération renvoie fidèlement.

2. Inspectez ce qui a été récupéré. Journalisez les IDs et le texte des chunks récupérés pour la requête défaillante. Si c’est l’ancien contenu, c’est un bug d’indexation/de fraîcheur, non un bug de modèle.

3. Vérifiez les métadonnées de chunk/version. Un updated_at périmé ou un job de ré-indexation manquant le confirme.

4. Seulement alors, examinez le grounding/le prompt. Si la récupération a renvoyé le nouveau contenu mais que la réponse a utilisé l’ancien, l’instruction de grounding ou le reranking est en cause.

Confident-but-wrong after a refresh?
  1. What did retrieval return?  ──stale── ▶ re-chunk/re-embed/re-index (fix freshness pipeline)
  2. Returned fresh content?     ──yes──── ▶ check grounding instruction / reranking
  3. Neither?                    ────────── ▶ check embedding-model mismatch / query rewrite

3.8 RAG vs long context vs fine-tuning

Does the knowledge change frequently or need citations? ── yes ─▶ RAG
Is the corpus small, stable, and fits comfortably in context? ── yes ─▶ long context
Is it about behaviour/format/style rather than changing facts? ── yes ─▶ fine-tuning

Ces options ne sont pas mutuellement exclusives : fine-tuner pour le style, RAG pour les faits, long contexte pour une session bornée.

3.9 RAG agentique, surcharge de capacités des outils et moindre privilège

Le RAG agentique laisse le modèle décider quand et quoi récupérer, émettre des requêtes de suivi, et combiner les sources — plus puissant que la récupération one-shot, mais avec plus de coût et de surface de défaillance. Utilisez-le quand les requêtes sont multi-hop ou exploratoires ; utilisez le RAG simple quand une seule récupération suffit.

Surcharge de capacités et moindre privilège

Un agent avec trop d’outils (18 contre 4–5 recommandés) est plus lent, plus sujet aux erreurs, et plus dangereux. La bonne remédiation d’un outil destructeur inutile est de le supprimer, non de journaliser son usage ou d’ajouter une confirmation.

Analyse des écarts authn / authz

Les outils agissent sur de vrais systèmes, donc l’identité et les permissions doivent se propager jusqu’à l’appel de l’outil — l’agent doit agir en tant que l’utilisateur, avec ses permissions, non comme un compte de service omnipotent.

3.10 Choosing the integration mechanism

Will many clients/agents reuse this capability?  ── yes ─▶ MCP server (OAuth if remote)
One app, tight control/latency?                  ── yes ─▶ direct API/CLI tool
Need a specialised agent with its own context?   ── yes ─▶ agent-to-agent (subagent)

Découverte progressive vs contexte monolithique

Ne chargez pas chaque outil et document dans le contexte d’emblée. Utilisez la découverte progressive : tool search + defer_loading: true pour les grands catalogues d’outils, et des Skills chargées à la demande. Un contexte monolithique est coûteux, hostile au cache, et dégrade la justesse de sélection d’outils.

3.11 Observability at scale

À l’échelle de production, vous ne pouvez pas déboguer ce que vous ne pouvez pas tracer. Instrumentez chaque requête de bout en bout.

[req id: 9f3a] ── app ──▶ retrieve(k=50) ──▶ rerank(6) ──▶ opus-5 ──▶ tool:lookup ──▶ validate ──▶ resp
                 correlation id 9f3a threads through every span; token+cost tagged per span

La télémétrie de coût/latence par segment est ce qui vous permet de router, cacher et optimiser (D4) avec des preuves plutôt que des suppositions.

3.12 Enterprise integration patterns and data freshness

3.13 A concrete RAG pipeline configuration

Les auteurs d’items récompensent les candidats qui savent lire une config et prédire son comportement. Une base d’entreprise défendable :

ingestion:
  sources: [confluence, s3_pdfs, postgres_kb]
  dedup: content_hash
  pii_scrub: true
chunking:
  strategy: structural           # split on headings/sections
  fallback: recursive
  target_tokens: 400
  overlap_tokens: 60
  parent_child: true             # match child (~400), return parent (~1500)
embedding:
  model: text-embedding-3-large  # keep query + index model identical
  dimensions: 1024
index:
  store: managed_vector_db
  metadata: [tenant_id, doc_type, acl, updated_at, source_id]
  filters_before_search: [tenant_id, acl]   # security + precision
retrieval:
  mode: hybrid                   # BM25 + dense, RRF fusion
  k: 50
  rerank:
    model: cross_encoder_reranker
    keep_top: 6
  query_transform: [rewrite, multi_query]   # for conversational/sparse queries
generation:
  model: claude-sonnet-5
  grounding: answer_only_from_context
  citations: true
  on_insufficient_context: "say so; do not use parametric memory"
refresh:
  trigger: [webhook_on_update, nightly_schedule]
  action: re_chunk_re_embed_re_index

3.14 Retrieval evaluation with worked numbers

Vous devez pouvoir calculer les métriques, pas seulement les nommer.

Cadre. 5 requêtes ; pour chacune on connaît l’unique chunk pertinent et son rang dans la liste récupérée :

recall@3 = (#queries whose relevant chunk is in top-3) / total = 3/5 = 0.60
MRR      = mean reciprocal rank = (1.00 + 0.25 + 0.50 + 0 + 1.00) / 5 = 0.55

Supposons maintenant qu’ajouter un reranker déplace le chunk pertinent de Q2 au rang 2 et récupère celui de Q4 au rang 3 :

recall@3 → 5/5 = 1.00   (both now in top-3)
MRR      → (1.00 + 0.50 + 0.50 + 0.333 + 1.00)/5 = 0.667

Le reranker a relevé le recall@3 de 0,60 → 1,00 et le MRR de 0,55 → 0,67 — le plus grand gain de précision/classement à lui seul, sans toucher au chunking ni aux embeddings.

3.15 Multi-tenant isolation and ACL-aware retrieval

Dans un index partagé, la récupération est une frontière de sécurité. Une requête ne doit jamais faire remonter le chunk d’un autre tenant ou d’un utilisateur non autorisé.

user (tenant_42, role: support) asks a question
   │  attach identity: {tenant_id: 42, acl_groups: [support]}
   ▼
filter BEFORE/ALONGSIDE vector search:
   WHERE tenant_id = 42 AND acl IN ('public','support')
   ▼
hybrid retrieve → rerank → ground   (only authorised chunks ever enter context)

3.16 Scénario détaillé : un agent RAG de support qui fuit, périmé et sur-privilégié

Scénario. Un agent de support SaaS B2B sert 300 tenants depuis un index vectoriel partagé unique. Trois plaintes arrivent : (1) un tenant voit occasionnellement le runbook d’un autre tenant dans une réponse ; (2) après que les clients ont mis à jour leurs docs, l’agent cite encore la version d’hier, avec assurance ; (3) l’agent a 22 outils dont delete_ticket et refund qu’il ne devrait jamais appeler. La récupération est dense-only, k=8, sans reranker.

Trace de raisonnement d’expert.

1. L’isolation d’abord (sévérité la plus élevée). L’exposition cross-tenant est un incident de sécurité. Ajoutez un pré-filtre tenant_id (et ACL) obligatoire sur chaque requête, cadencez les caches par tenant, et propagez l’identité de l’utilisateur final. Ne comptez pas sur la formulation du prompt pour séparer les tenants.

2. La fraîcheur ensuite. Le confiant-mais-faux-après-mise-à-jour est une récupération périmée : le rafraîchissement a mis à jour le store source mais pas l’index vectoriel. Inspectez les IDs des chunks récupérés (ils seront anciens), puis corrigez le pipeline de re-chunk/re-embed/re-index avec des déclencheurs webhook + nocturnes.

3. Le moindre privilège en troisième. Supprimez delete_ticket, refund, et les autres outils inutiles de l’allowlist — ne vous contentez pas de journaliser ou d’ajouter « êtes-vous sûr ? ». Réduisez à ~4–5 outils ; utilisez tool search + defer_loading si le catalogue légitime est grand.

4. Puis la qualité. Dense-only + k=8 + sans rerank sous-performe sur les identifiants exacts et la précision. Passez à la récupération hybride, k=50, rerank, garder le top 6, et mesurez recall@k et faithfulness par segment de tenant.

5. Fermez la boucle. Instrumentez des IDs de corrélation et une télémétrie de récupération par segment pour que le prochain incident soit reconstructible.

Pourquoi les alternatives tentantes sont fausses : « ajouter une règle du system prompt de ne pas révéler d’autres tenants » est du prompt comme mécanisme d’application et laisse la fuite ; « passer à un plus gros modèle » ne corrige ni l’isolation ni la fraîcheur ; « journaliser les outils dangereux » laisse l’agence excessive ; « monter k à 500 » ajoute du bruit au lieu d’ajouter un reranker.

3.17 Common misconceptions

Pièges de l’examen dans ce domaine

Questions d’entraînement

À retenir

• Le RAG est un pipeline fixe : ingérer → chunker → embarquer → indexer → récupérer → reranker → grounder → citer ; chaque décision s’insère dans une étape.
• Accordez le chunking à la forme des données : document-aware pour le texte structuré, parent–enfant/late pour la prose cross-référentielle, sémantique pour les topiques changeants.
• Utilisez la récupération hybride (dense + sparse) pour les vrais corpus ; rerankez pour la précision ; ajoutez réécriture/HyDE/multi-query pour le rappel.
• Groundez les réponses au contexte récupéré, citez les sources, et préférez « contexte insuffisant » à la fabrication.
• Évaluez la récupération et la génération séparément (recall@k, MRR vs faithfulness) ; le confiant-faux-après-rafraîchissement signifie inspecter d’abord la récupération/l’indexation.
• Choisissez le RAG pour les faits changeants/cités, le long contexte pour les petits corpus stables, le fine-tuning pour le comportement/style.
• Appliquez le moindre privilège en supprimant les outils inutiles (surtout destructeurs) ; gardez les agents à ~4–5 outils avec tool search pour les plus grands catalogues.
• Propagez l’identité de l’utilisateur aux outils, appliquez les ACL par utilisateur, et exigez OAuth 2.1 sur les serveurs MCP distants.
• Instrumentez traces, IDs de corrélation et télémétrie tokens/coût ; utilisez files, clés d’idempotence, webhooks, Batch API et un pipeline de fraîcheur pour l’intégration en entreprise.
• Calculez les métriques de récupération : recall@k = pertinents-dans-le-top-k ÷ requêtes ; MRR = moyenne(1÷rang) ; un reranker relève généralement les deux le plus.
• Dans un index partagé, la récupération est une frontière de sécurité : filtrez par tenant_id/ACL avant la recherche vectorielle, propagez l’identité de l’utilisateur final, et cadencez les caches par tenant.
• Gardez les modèles d’embedding de la requête et de l’index identiques ; la recette canonique est récupérer large (k≈50 hybride) → reranker → garder ~6 → grounder avec citations.