Context Engineering — Section 13 : Playbooks

Assembler les briques : des recettes architecturales éprouvées pour des cas d'usage réels.

Playbooks Architecturaux

Des patrons de conception pour construire des applications RAG, des copilotes, des assistants de code et plus encore. Cliquez pour explorer.

Panorama : Des Concepts aux Architectures

Un playbook est une **recette architecturale** pour un cas d'usage LLM spécifique. Il combine les différentes briques de Context Engineering (Retrieval, Structuration, Mémoire, Agents, etc.) en un pipeline cohérent et éprouvé. L'objectif est de fournir un point de départ solide pour accélérer le développement et éviter les erreurs communes.

Le Principe Directeur : Commencez toujours par le playbook le plus simple qui répond au cœur de votre problème (souvent le RAG de Q&A) et n'ajoutez de la complexité (agents, mémoire long terme) que lorsque c'est justifié par une évaluation rigoureuse.

Playbook 1 : RAG de Q&A sur Documents

Le cas d'usage le plus fondamental : permettre à un utilisateur de converser avec une base de connaissances.

Objectif

Répondre à des questions factuelles en se basant **exclusivement** sur une collection de documents fournis, en citant les sources.

Pipeline Architectural

1. Input: User Query 2. Retrieve: Hybrid Search (Vector + BM25) -> Top 50 chunks 3. Re-rank: Cross-Encoder -> Top 5 chunks 4. Compress: Extractive (garder les phrases clés) 5. Structure: Assembler le contexte avec des balises XML 6. LLM Call: Modèle équilibré (ex: Claude 3 Sonnet) 7. Output: Réponse + Citations des sources

Techniques Essentielles

- Retrieval & Reranking (pour la pertinence)
- Compression Extractive (pour le coût et la performance)
- Structuration (pour la robustesse)
- Évaluation (mesurer la Faithfulness est critique)

Playbook 2 : Copilote d'Application

Transformer le langage naturel en actions dans une application existante (CRM, ERP, etc.).

Objectif

Permettre à un utilisateur de piloter une application par la parole ou le texte, en traduisant ses intentions en appels d'API ou en actions GUI.

Pipeline Architectural

1. Input: "Crée un contact pour Jean Dupont, acme@corp.com" 2. Tool Definition: Outil `create_contact(name: str, email: str)` est disponible. 3. LLM Agent (ReAct Loop): - Thought: "L'intention est de créer un contact. Je dois utiliser l'outil `create_contact`." - Action: `create_contact(name='Jean Dupont', email='acme@corp.com')` 4. Tool Execution: L'application exécute l'action via son API interne. 5. Observation: `{"status": "success", "contact_id": 123}` 6. LLM Synthesizer: "Le contact a bien été créé avec l'ID 123."

Techniques Essentielles

- Agents & Orchestration (le cœur du système)
- Structuration (définition des outils et parsing des appels)
- Sécurité (validation des actions avant exécution)

Playbook 3 : Agent de Recherche & Synthèse

Pour les questions complexes qui nécessitent de croiser des informations de plusieurs sources pour former une nouvelle connaissance.

Objectif

Produire un rapport de synthèse complet et sourcé en réponse à une question ouverte, en utilisant des outils de recherche (web, documents internes).

Pipeline Architectural

1. Input: "Quels sont les impacts du RGPD sur l'IA générative ?" 2. Planner Agent: Décompose en sous-questions (ex: "Qu'est-ce que le RGPD?", "Quelles sont les spécificités de l'IA gen?", "Quels articles s'appliquent?"). 3. Executor Agent (boucle sur les sous-questions): - Utilise l'outil `web_search` ou `internal_doc_search`. - Distille les résultats en KeyFacts + Citations. 4. Synthesizer Agent: Reçoit tous les KeyFacts et rédige un rapport structuré et cohérent.

Techniques Essentielles

- Agents (Multi-Agent) & Orchestration
- Compression & Distillation (pour extraire les faits)
- Traçabilité (pour conserver les sources)

Playbook 4 : Chatbot Personnalisé

Un assistant conversationnel qui apprend de ses interactions pour offrir une expérience sur mesure.

Objectif

Maintenir une conversation cohérente et personnalisée en se souvenant du contexte de la session en cours et des informations clés des sessions précédentes.

Pipeline Architectural

1. Input: User message 2. Memory Retrieval: - Court Terme: Récupérer les 5 derniers messages. - Long Terme: Recherche vectorielle dans la DB de l'utilisateur pour des faits pertinents. 3. Context Assembly: Prompt structuré avec l'historique et les souvenirs. 4. LLM Call: Génération de la réponse. 5. ASYNC -> Memory Extraction: Un LLM analyse la conversation et met à jour la mémoire long terme avec de nouveaux faits sur l'utilisateur.

Techniques Essentielles

- Mémoire (court et long terme)
- Caching (pour la performance)
- Sécurité & Gouvernance (pour la gestion des données personnelles)

Comment Choisir son Playbook ?

Utilisez ce tableau pour vous orienter vers le playbook de départ le plus adapté à votre besoin.

Si votre objectif principal est de...	Alors votre point de départ est le Playbook...
... répondre à des questions sur des documents existants (PDFs, Confluence, etc.).	RAG de Q&A
... permettre aux utilisateurs d'agir dans votre logiciel via le langage.	Copilote d'Application
... répondre à des questions qui n'ont pas de réponse directe dans vos documents.	Agent de Recherche
... créer un assistant qui se souvient des préférences et de l'historique de l'utilisateur.	Chatbot Personnalisé
... aider les développeurs à travailler sur une base de code.	Assistant de Code (une variante du RAG de Q&A)

Méta-Playbook : Comment Implémenter un Playbook

Suivez cette approche itérative pour construire votre application de manière robuste.

1. Choisir le Playbook le plus simple. Identifiez le playbook qui correspond au cœur de votre besoin et commencez par celui-ci.
2. Construire les composants de base. Mettez en place chaque brique du pipeline de manière isolée (ex: construisez et testez d'abord uniquement votre retriever).
3. Évaluer chaque composant. Créez des évaluations spécifiques pour chaque brique. Mesurez la `Context Precision` de votre retriever avant de vous soucier de la `Faithfulness` de la réponse finale.
4. Assembler le pipeline de bout en bout. Connectez les composants. Mettez en place une télémétrie complète (tracing) pour pouvoir suivre une requête à travers tout le pipeline.
5. Évaluer le système complet. Déployez votre pipeline d'évaluation (sur votre "golden set") pour mesurer la performance de bout en bout.
6. Itérer en se basant sur les données. Analysez les échecs révélés par votre évaluation. Est-ce un problème de retrieval ? De prompt ? De modèle ? Améliorez le composant défaillant et recommencez le cycle.