Notes pratiques : Ingénierie du contexte agentique : un guide pas à pas pour les machines.
Guide pratique détaillé : Ingénierie du contexte agentique : un guide pas à pas pour les machines, incluant des contrats, des vérifications et des emplacements de code prêts à l’emploi pour les équipes utilisant ce modèle.
Les notes suivantes reconstituent une approche pratique basée sur « Agentic Context Engineering : Un guide pas à pas pour les ingénieurs en apprentissage automatique ». L’accent est mis sur les contrats, les vérifications et les placeholders de code à insérer, plutôt que sur une présentation motivante. Lors de l’étape d’aperçu, notez d’abord le contrat : les entrées requises, le signal de succès et ce qui se passe en cas d’échec partiel. Cette liste de contrôle permet de rester honnête lors des modifications ultérieures du code. Documentez à la fois le parcours normal et le parcours de récupération. Les tentatives répétées, les contrôles humains et la gestion des messages non livrés font partie intégrante du produit, et non d’une mise en forme ultérieure.
1. Commencez par la question fondamentale : Qu’est-ce que le contexte ?
La phase « Start With » fonctionne le mieux lorsqu’elle est considérée comme une surface mesurable. Capturez un exemple réussi, un cas d’échec et la note de réversion avant d’élargir le périmètre. Préférez des unités petites et testables aux scripts complexes. Lorsqu’une étape échoue, l’erreur doit indiquer une seule responsabilité plutôt qu’un processus embrouillé. Maintenez l’état du graphe plat et typé. Les blocs imbriqués cachent le fait que tel nœud a écrit telle champ et perturbent la reprise après interruption.
Context → LLM → Output
User question
+
Model configuration
+
Recent evaluation metrics
+
Training dataset statistics
+
Recent production images
+
Deployment history
+
Data distribution statistics
+
Recent code changes
↓
LLM
↓
Diagnosis
2. L’ingénierie des prompts n’est pas l’ingénierie du contexte
La phase d’ingénierie des prompts fonctionne le mieux lorsqu’elle est considérée comme une surface mesurable. Capturez un exemple réussi, un cas d’échec ainsi que la note de réversion avant d’élargir le périmètre. Considérez cette phase comme un contrat entre les entrées et les sorties validées. Donnez des noms aux artefacts, définez des critères de succès et refusez les complétions partielles silencieuses. Fixez un budget de tokens par tour et par session. Les outils agents élargissent lourdement le contexte ; des plafonds stricts empêchent que les démonstrations ne se transforment en factures inattendues.
Ingénierie des prompts
L’étape d’ingénierie des prompts fonctionne le mieux lorsqu’elle est considérée comme une surface mesurable. Capturez un transcript idéal, un cas d’échec et la note de réversion avant d’élargir le périmètre. Enregistrez les temps d’exécution ainsi que le coût en tokens ou en requêtes à côté des résultats fonctionnels. Une visibilité précoce des coûts évite les factures inattendues lorsque le processus passe de la démonstration aux environnements partagés. Fixez un budget en tokens par tour et par session. Les outils agents élargissent de manière importante le contexte ; des plafonds stricts empêchent que les démonstrations ne se transforment en factures inattendues. L’étape d’ingénierie des prompts fonctionne le mieux lorsqu’elle est considérée comme une surface mesurable. Capturez un transcript idéal, un cas d’échec et la note de réversion avant d’élargir le périmètre. Documentez ensemble le parcours réussi et celui de récupération. Les tentatives de réessai, les contrôles humains et la gestion des messages non traités font partie intégrante du produit, et non d’une mise en forme ultérieure.
You are an expert ML engineer.
Analyze the following anomaly detection results
and identify the most likely causes of the performance drop.
Consider:
1. Data distribution shift
2. Model degradation
3. Label quality
4. Hardware changes
5. Preprocessing changes
Ingénierie du contexte
Pendant l’étape d’ingénierie du contexte, il convient de définir les entrées, le responsable de l’étape et les critères d’arrêt avant de modifier du code. Les opérateurs doivent pouvoir relancer l’étape à partir d’un point de contrôle connu, sans avoir à deviner l’état caché. Préférez des unités petites et testables aux scripts complexes. Lorsqu’une étape échoue, l’échec doit indiquer une seule responsabilité et non un processus embrouillé. Faites approuver par des humains les actions qui entraînent des dépenses ou modifient des données de production. Une connexion en temps de compilation ne garantit pas la complétude du processus métier.
┌──────────────┐
│ User Request │
└──────┬───────┘
↓
┌──────────────┐
│ Agent State │
└──────┬───────┘
↓
┌────────────┴────────────┐
↓ ↓
Retrieval Tools
↓ ↓
Documentation Metrics / DB
└────────────┬────────────┘
↓
┌──────────────┐
│ Context │
└──────┬───────┘
↓
LLM
↓
Action
3. Pourquoi le contexte devient difficile pour les agents
Pour le contexte des 3 « Pourquoi », qui constitue une étape, il convient de définir les entrées, le responsable de l’étape et les critères de fin avant de modifier du code. Les opérateurs doivent pouvoir relancer l’étape à partir d’un point de contrôle connu, sans avoir à deviner l’état caché. Considérez cette étape comme un contrat entre les entrées et les sorties validées. Donnez des noms aux artefacts, définites des vérifications de succès et refusez les terminaisons partielles silencieuses. Faites approuver par un humain les cas où de l’argent est dépensé ou où des données de production sont modifiées. La connexion en temps de compilation ne revient pas à une complétude opérationnelle.
User → LLM → Answer
User
↓
Agent
↓
Search documentation
↓
Read results
↓
Call database
↓
Analyze data
↓
Call another tool
↓
Observe result
↓
Modify hypothesis
↓
Search again
↓
Take action
↓
Final answer
4. Les quatre problèmes fondamentaux de contexte
Pour la phase des Quatre Fondamentaux, définissez les entrées, le responsable de l’étape et les critères d’arrêt avant de modifier le code. Les opérateurs doivent pouvoir relancer l’étape à partir d’un point de contrôle connu sans deviner l’état caché. Enregistrez les temps d’exécution ainsi que le coût des tokens ou des requêtes à côté des résultats fonctionnels. Une visibilité précoce des coûts évite les factures inattendues lorsque le processus passe d’un environnement de démonstration à des environnements partagés. Faites approuver par un humain les étapes qui entraînent des dépenses ou modifient des données de production. La connexion en temps de compilation ne garantit pas la complétude du processus métier. Pour la phase des Quatre Fondamentaux, définissez les entrées, le responsable de l’étape et les critères d’arrêt avant de modifier le code. Les opérateurs doivent pouvoir relancer l’étape à partir d’un point de contrôle connu sans deviner l’état caché. Documentez conjointement le parcours idéal et le parcours de récupération. Les tentatives de réexécution, les contrôles humains et la gestion des messages non livrés font partie intégrante du produit, et non d’une mise en forme ultérieure.
Problème 1 : Manque de contexte
Lors de l’étape « Problème 1 : Manque de contexte », notez d’abord les éléments essentiels du contrat : les entrées requises, le signal de succès, ainsi que ce qui se passe en cas d’échec partiel. Cette liste de contrôle permet de rester honnête lors des modifications ultérieures du code. Préférez des unités petites et testables plutôt que des scripts complexes. Lorsqu’une étape échoue, l’échec doit indiquer une seule responsabilité et non un processus embrouillé. Faites des points de contrôle après les étapes coûteuses. Le système de reprise ne doit pas facturer à nouveau la même appel du LLM lorsque l’opérateur réessaie un nœud ultérieur.
Agent:
"The model may be suffering from data drift."
Reality:
The model was recently changed from ViT-B to ViT-L.
Problème 2 : Contexte irrelevant
Lors de l’étape du contexte irrélevant pour le Problème 2, notez d’abord les conditions du contrat : entrées requises, signal de succès, et ce qui se passe en cas d’échec partiel. Cette liste de contrôle permet de garantir l’honnêteté des modifications ultérieures du code. Considérez cette étape comme un contrat entre les entrées et les sorties validées. Donnez des noms aux éléments générés, définez des vérifications de succès, et refusez toute exécution partielle silencieuse. Faites un point après les étapes coûteuses. Le système de reprise ne doit pas facturer à nouveau la même appel du LLM lorsque l’opérateur réessaie un nœud ultérieur.
Query
↓
Vector database
↓
50 documents
↓
LLM
Problème 3 : Contexte obsolète
Lors de la phase « Contexte obsolète » du Problème 3, notez d’abord le contrat : les entrées requises, le signal de succès et ce qui se passe en cas d’échec partiel. Cette liste de contrôle permet de garantir l’intégrité des modifications ultérieures du code. Enregistrez les temps d’exécution ainsi que le coût des tokens ou des requêtes à côté des résultats fonctionnels. Une visibilité précoce des coûts évite des factures inattendues lorsque le processus passe d’un environnement de démonstration à des environnements partagés. Créez un point de contrôle après les étapes coûteuses. La reprise du processus ne doit pas facturer à nouveau la même appel de LLM lorsque l’opérateur réessaie un nœud ultérieur. Lors de la phase « Contexte obsolète » du Problème 3, notez d’abord le contrat : les entrées requises, le signal de succès et ce qui se passe en cas d’échec partiel. Cette liste de contrôle permet de garantir l’intégrité des modifications ultérieures du code. Documentez ensemble le parcours normal et le parcours de récupération. Les tentatives de réessai, les contrôles humains et la gestion des messages non traités font partie intégrante du produit, et non d’améliorations ultérieures.
Current production model:
anomaly-detector-v4
Old documentation:
anomaly-detector-v2
Problème 4 : Contexte mal structuré
La phase de problème 4 concernant une structure insuffisante fonctionne le mieux lorsqu’elle est traitée comme une surface mesurable. Capturez un transcript exemplaire, un cas d’échec et la note de réversion avant d’élargir le périmètre. Préférez des unités petites et testables aux scripts complexes. Lorsqu’une étape échoue, l’échec doit indiquer une seule responsabilité plutôt qu’un processus embrouillé. Maintenez l’état du graphe plat et typé. Les blocs imbriqués masquent le fait que tel nœud a écrit telle champ et perturbent la reprise après interruption.
Accuracy: 0.91
Accuracy: 0.87
Accuracy: 0.84
Model: anomaly-detector-v4
Dataset: Production
Metric: Image-level AUROC
Previous week: 0.91
Current week: 0.84
Change: -7.7 percentage pointsDeployment:
- Version: v4.2
- Date: 2026-08-12
- Preprocessing: resize=336
5. Un modèle mental utile : le contexte en tant que pipeline de données
La phase 5 « A Useful Mental » fonctionne le mieux lorsqu’elle est considérée comme une surface mesurable. Capturez un exemple réussi, un cas d’échec et la note de réversion avant d’élargir le périmètre. Traitez cette phase comme un contrat entre les entrées et les sorties validées. Donnez des noms aux artefacts, définez des critères de succès et refusez toute mise en œuvre partielle silencieuse. Allouez des crédits par tour et par session. Les outils agents élargissent l’échelle du contexte de manière importante ; des plafonds stricts empêchent que les démonstrations se transforment en factures inattendues.
Raw Data
↓
Cleaning
↓
Feature Extraction
↓
Transformation
↓
Model
↓
Prediction
Raw Information
↓
Retrieval
↓
Filtering
↓
Ranking
↓
Transformation
↓
Compression
↓
Context Assembly
↓
LLM
↓
Action
↓
New Observation
↓
Context Update
6. Étape 1 — Définir l’objectif de l’agent
La phase 1 des 6 étapes, « Définir », fonctionne le mieux lorsqu’elle est considérée comme une surface mesurable. Capturez un enregistrement idéal, un cas d’échec et la note de réversion avant d’élargir le périmètre. Notez les temps d’exécution ainsi que le coût des tokens ou des requêtes à côté des résultats fonctionnels. Une visibilité précoce des coûts évite les factures inattendues lorsque le processus passe de la démonstration aux environnements partagés. Gardez l’état du graphe simple et bien typé : les blocs imbriqués masquent l’identité du nœud qui a modifié tel champ et perturbent la reprise après interruption. La phase 1 des 6 étapes, « Définir », fonctionne le mieux lorsqu’elle est considérée comme une surface mesurable. Capturez un enregistrement idéal, un cas d’échec et la note de réversion avant d’élargir le périmètre. Documentez ensemble le parcours optimal et le parcours de récupération. Les tentatives de réessai, les contrôles humains et le traitement des messages non livrés font partie intégrante du produit, et non d’une mise en forme ultérieure.
Objective:
Diagnose production degradation
7. Étape 2 — Identifier les sources de contexte
Pour l’étape 7, Étape 2 : Identification, définissez les entrées, le responsable de l’étape ainsi que les critères de fin avant de modifier du code. Les opérateurs doivent pouvoir relancer l’étape à partir d’un point de contrôle connu sans deviner l’état caché. Préférez des unités petites et testables aux scripts complexes. Lorsqu’une étape échoue, l’échec doit indiquer une seule responsabilité et non un processus embrouillé. Faites approuver par des humains les actions qui entraînent des dépenses ou modifient des données de production. Une connexion en temps de compilation ne garantit pas la complétude du processus métier.
ML Debugging Agent
│
┌─────────────────┼─────────────────┐
↓ ↓ ↓
Metrics DB Git Repository Experiment DB
│ │ │
↓ ↓ ↓
Performance Code changes Experiments
│ │ │
└─────────────────┼─────────────────┘
↓
Context
Documents
Pour l’étape des Documents, définissez les entrées, le responsable de l’étape et les critères de fin avant de modifier le code. Les opérateurs doivent pouvoir relancer l’étape à partir d’un point de contrôle connu sans deviner l’état caché. Considérez cette étape comme un contrat entre les entrées et les sorties validées. Nommez les artefacts, définissez des vérifications de succès et refusez toute finalisation partielle silencieuse. Faites approuver par un humain les cas où de l’argent est dépensé ou où des données de production sont modifiées. La connexion en temps de compilation ne revient pas à une complétude opérationnelle.
Bases de données
Pour l’étape des bases de données, définissez les entrées, le responsable de l’étape et les critères d’arrêt avant de modifier le code. Les opérateurs doivent pouvoir relancer l’étape à partir d’un point de contrôle connu sans deviner l’état caché. Enregistrez les temps d’exécution ainsi que le coût des tokens ou des requêtes à côté des résultats fonctionnels. Une visibilité précoce des coûts évite les factures inattendues lorsque le processus passe d’un environnement de démonstration à des environnements partagés. Imposez une approbation humaine pour les actions qui entraînent des dépenses ou modifient des données de production. La configuration en temps de compilation ne garantit pas une complétude fonctionnelle pour l’entreprise. Pour l’étape des bases de données, définissez les entrées, le responsable de l’étape et les critères d’arrêt avant de modifier le code. Les opérateurs doivent pouvoir relancer l’étape à partir d’un point de contrôle connu sans deviner l’état caché. Documentez conjointement le parcours normal et les scénarios de récupération. Les tentatives de réexécution, les contrôles humains et la gestion des messages échoués font partie intégrante du produit, et non d’améliorations ultérieures.
Outils
Lors de la phase des outils, notez d’abord le contrat : les entrées requises, le signal de succès et ce qui se passe en cas d’échec partiel. Cette liste de contrôle permet de rester honnête lors des modifications ultérieures du code. Préférez des unités petites et testables à des scripts complexes. Lorsqu’une étape échoue, l’échec doit indiquer une seule responsabilité plutôt qu’un processus embrouillé. Enregistrez le nom de l’outil, le hash des arguments, la latence et le résultat de chaque appel. Sans cette trace, les boucles d’analyse débogage gaspillent des heures.
Mémoire
Lors de la phase de mémoire, notez d’abord le contrat : les entrées requises, le signal de succès et ce qui se passe en cas d’échec partiel. Cette liste de contrôle permet de garantir l’honnêteté des modifications ultérieures du code. Considérez cette phase comme un contrat entre les entrées et les sorties validées. Donnez des noms aux artefacts, définez des vérifications de succès et refusez les terminations partielles silencieuses. Faites un point après des étapes coûteuses. Le système de reprise ne doit pas facturer à nouveau la même appel du LLM lorsque l’opérateur réessaie un nœud ultérieur.
Environnement
Lors du travail sur l’étape Environnement, notez d’abord le contrat : les entrées requises, le signal de succès et ce qui se passe en cas d’échec partiel. Cette liste de contrôle permet de garantir l’intégrité des modifications ultérieures du code. Enregistrez les temps d’exécution ainsi que le coût des tokens ou des requêtes à côté des résultats fonctionnels. Une visibilité précoce des coûts évite des factures inattendues lorsque le processus passe de la démonstration aux environnements partagés. Créez un point de contrôle après les étapes coûteuses. La reprise du processus ne doit pas facturer à nouveau la même appel de LLM lorsque l’opérateur réessaie un nœud ultérieur. Lors du travail sur l’étape Environnement, notez d’abord le contrat : les entrées requises, le signal de succès et ce qui se passe en cas d’échec partiel. Cette liste de contrôle permet de garantir l’intégrité des modifications ultérieures du code. Documentez ensemble le parcours normal et le parcours de récupération. Les tentatives de réessai, les contrôles humains et la gestion des messages non livrés font partie intégrante du produit, et non d’améliorations ultérieures.
8. Étape 3 — Récupérer uniquement ce qui est essentiel
La phase de récupération du 3e étape en 8 pas fonctionne le mieux lorsqu’elle est considérée comme une surface mesurable. Capturez un transcript exemplaire, un cas d’échec et la note de réversion avant d’élargir le périmètre. Préférez des unités petites et testables aux scripts complexes. Lorsqu’une étape échoue, l’échec doit pointer vers une seule responsabilité plutôt que vers un processus embrouillé. Séparez la politique de segmentation de la politique de récupération. Modifier l’une ne doit pas obliger à réécrire l’autre lorsque les métriques de qualité changent.
Question
↓
Embedding
↓
Vector DB
↓
Top 10 chunks
↓
LLM
1. Find current deployment
2. Find previous deployment
3. Compare configurations
4. Retrieve associated code changes
5. Retrieve metric changes
9. Étape 4 — Utiliser un contexte structuré
La phase 4 de l’étape 9 fonctionne le mieux lorsqu’elle est considérée comme une surface mesurable. Capturez un transcript parfait, un cas d’échec et la note de réversion avant d’élargir le périmètre. Considérez cette phase comme un contrat entre les entrées et les sorties validées. Nommez les artefacts, définez des vérifications de succès, et refusez toute complétion partielle silencieuse. Maintenez l’état du graphe plat et typé. Les blocs imbriqués masquent le fait que tel nœud a écrit telle champ et perturbent la reprise après interruption.
The deployment happened recently and the model seems
to have lower performance and there were some preprocessing
changes and the new version uses 336 resolution...
{
"model": "anomaly-detector-v4",
"deployment": "v4.2",
"deployment_date": "2026-08-12",
"image_size": 336,
"previous_image_size": 224,
"auroc_previous": 0.91,
"auroc_current": 0.84
}
image_size:
224 → 336
AUROC:
0.91 → 0.84
10. Étape 5 — Séparer les faits, les hypothèses et les actions
La phase « 10 Étapes 5 Séparés » fonctionne le mieux lorsqu’elle est considérée comme une surface mesurable. Capturez un enregistrement idéal, un cas d’échec et la note de réversion avant d’élargir le périmètre. Enregistrez les temps d’exécution ainsi que le coût des tokens ou des requêtes à côté des résultats fonctionnels. Une visibilité précoce des coûts évite les factures inattendues lorsque le processus passe de la démonstration aux environnements partagés. Maintenez l’état du graphe plat et typé. Les blocs imbriqués masquent le fait que tel nœud a écrit telle champ et perturbent la reprise après interruption. La phase « 10 Étapes 5 Séparés » fonctionne le mieux lorsqu’elle est considérée comme une surface mesurable. Capturez un enregistrement idéal, un cas d’échec et la note de réversion avant d’élargir le périmètre. Documentez ensemble le parcours réussi et le parcours de récupération. Les tentatives répétées, les contrôles humains et la gestion des messages non livrés font partie intégrante du produit, et non d’une mise en forme ultérieure.
Faits
Pour l’étape des faits, définissez les entrées, le responsable de l’étape et les critères de fin avant de modifier le code. Les opérateurs doivent pouvoir relancer l’étape à partir d’un point de contrôle connu sans deviner l’état caché. Préférez des unités petites et testables aux scripts complexes. Lorsqu’une étape échoue, l’échec doit indiquer une seule responsabilité plutôt qu’un processus embrouillé. Faites approuver par un humain les actions qui entraînent des dépenses ou modifient des données de production. La connexion en temps de compilation ne garantit pas la complétude du processus métier.
Current AUROC = 0.84
Previous AUROC = 0.91
Image resolution changed from 224 to 336
Hypothèses
Pendant l’étape des hypothèses, définissez les entrées, le responsable de l’étape et les critères de fin avant de modifier le code. Les opérateurs doivent pouvoir relancer l’étape à partir d’un point de contrôle connu sans deviner l’état caché. Considérez cette étape comme un contrat entre les entrées et les sorties validées. Donnez des noms aux artefacts, définites des vérifications de succès et refusez les terminaisons partielles silencieuses. Faites approuver par un humain les cas où de l’argent est dépensé ou où des données de production sont modifiées. La connexion en temps de compilation ne revient pas à une complétude opérationnelle.
Hypothesis:
The resolution change may have caused distribution mismatch.
Actions
Pour l’étape Actions, définissez les entrées, le responsable de l’étape et les critères d’arrêt avant de modifier le code. Les opérateurs doivent pouvoir relancer l’étape à partir d’un point de contrôle connu sans deviner l’état caché. Enregistrez les temps d’exécution ainsi que le coût des tokens ou des requêtes à côté des résultats fonctionnels. Une visibilité précoce des coûts évite les factures inattendues lorsque le processus passe d’un environnement de démonstration à des environnements partagés. Faites approuver par un humain les étapes qui entraînent des dépenses ou modifient des données de production. La connexion en temps de compilation ne garantit pas la complétude du processus métier. Pour l’étape Actions, définissez les entrées, le responsable de l’étape et les critères d’arrêt avant de modifier le code. Les opérateurs doivent pouvoir relancer l’étape à partir d’un point de contrôle connu sans deviner l’état caché. Documentez ensemble le parcours idéal et le parcours de récupération. Les tentatives de répétition, les contrôles humains et la gestion des messages non livrés font partie intégrante du produit, et non d’une mise en forme ultérieure.
Action:
Evaluate v4.2 on the previous preprocessing configuration.
{
"facts": [
"AUROC dropped from 0.91 to 0.84",
"Image resolution changed from 224 to 336"
],
"hypotheses": [
{
"claim": "Resolution change caused degradation",
"confidence": 0.65
}
],
"actions_completed": [
"Compared deployment configurations"
],
"next_action": "Run controlled preprocessing experiment"
}
11. Étape 6 — Compresser le contexte
Lors de l’étape 6 consistant à compresser le contexte, notez d’abord les éléments requis : les entrées nécessaires, le signal de succès, ainsi que ce qui se passe en cas d’échec partiel. Cette liste de contrôle permet de maintenir l’honnêteté des modifications ultérieures du code. Préférez des unités petites et testables plutôt que des scripts complexes. Lorsqu’une étape échoue, l’échec doit indiquer une seule responsabilité et non un processus embrouillé. Faites des points de contrôle après les étapes coûteuses. Le système de reprise ne doit pas facturer à nouveau la même appel du LLM lorsque l’opérateur réessaie un nœud ultérieur.
Investigation Summary
Objective:
Diagnose production AUROC degradation.Observed:
- AUROC decreased 0.91 → 0.84.
- Deployment v4.2 introduced 336px preprocessing.
- Model weights unchanged.
- Data volume unchanged.Ruled out:
- Model checkpoint change.
- Infrastructure failure.Current hypothesis:
Preprocessing change may be responsible.Next experiment:
Evaluate v4.2 using 224px preprocessing.
12. Étape 7 — Fournir à l’agent une mémoire de travail
Lorsque vous travaillez sur l’étape 7 des 12 étapes, notez d’abord le contrat : les entrées requises, le signal de succès et ce qui se passe en cas d’échec partiel. Cette liste de contrôle permet de rester honnête lors des modifications ultérieures du code. Considérez cette étape comme un contrat entre les entrées et les sorties validées. Donnez des noms aux artefacts, définez des vérifications de succès et refusez les terminations partielles silencieuses. Faites un point après des étapes coûteuses. Le système de reprise ne doit pas facturer à nouveau la même appel du LLM lorsque l’opérateur réessaie un nœud ultérieur.
Agent Memory
│
┌──────────────┼──────────────┐
↓ ↓ ↓
Working Memory Long-Term External
Memory Knowledge
│ │ │
↓ ↓ ↓
Current task Past decisions Documents
Current facts User preferences Databases
Hypotheses Past results APIs
Mémoire de travail
Lors de la phase de mémoire de travail, notez d’abord le contrat : les entrées requises, le signal de succès et ce qui se passe en cas d’échec partiel. Cette liste de contrôle permet de garantir l’intégrité des modifications ultérieures du code. Enregistrez les temps d’exécution ainsi que le coût des tokens ou des requêtes à côté des résultats fonctionnels. Une visibilité précoce des coûts évite les factures inattendues lorsque le processus passe d’un environnement de démonstration à des environnements partagés. Créez un point de contrôle après les étapes coûteuses. La reprise du processus ne doit pas facturer à nouveau la même appel de LLM lorsque l’opérateur réessaie un nœud ultérieur. Lors de la phase de mémoire de travail, notez d’abord le contrat : les entrées requises, le signal de succès et ce qui se passe en cas d’échec partiel. Cette liste de contrôle permet de garantir l’intégrité des modifications ultérieures du code. Documentez ensemble le parcours normal et le parcours de récupération. Les tentatives de réessai, les contrôles humains et la gestion des messages non livrés font partie intégrante du produit, et non d’améliorations apportées ultérieurement.
Mémoire à long terme
La phase de mémoire à long terme fonctionne le mieux lorsqu’elle est considérée comme une surface mesurable. Capturez un exemplaire idéal, un cas d’échec et la note de réversion avant d’élargir le périmètre. Préférez des unités petites et testables aux scripts complexes. Lorsqu’une étape échoue, l’échec doit pointer vers une seule responsabilité plutôt qu’un processus embrouillé. Maintenez l’état du graphe plat et typé. Les blocs imbriqués masquent le fait que tel nœud a écrit telle champ et perturbent la reprise après interruption.
Connaissances externes
La phase de connaissance externe fonctionne le mieux lorsqu’elle est considérée comme une surface mesurable. Capturez un transcript exemplaire, un cas d’échec et la note de réversion avant d’élargir le périmètre. Considérez cette phase comme un contrat entre les entrées et les sorties validées. Nommez les artefacts, définez des vérifications de succès, et refusez toute complétion partielle silencieuse. Maintenez l’état du graphe plat et typé. Les blocs imbriqués masquent le fait que tel nœud a écrit telle champ et perturbent la reprise après interruption.
13. Étape 8 — Laissez l’agent déterminer quel contexte il a besoin
La phase 13 Step 8 Let fonctionne le mieux lorsqu’elle est considérée comme une surface mesurable. Capturez un enregistrement idéal, un cas d’échec et la note de réversion avant d’élargir le périmètre. Enregistrez les temps d’exécution ainsi que le coût des tokens ou des requêtes à côté des résultats fonctionnels. Une visibilité précoce des coûts évite les factures inattendues lorsque le processus passe de la démonstration aux environnements partagés. Maintenez l’état du graphique plat et typé. Les blocs imbriqués masquent le fait que tel nœud a écrit telle champ et perturbent la reprise après interruption. La phase 13 Step 8 Let fonctionne le mieux lorsqu’elle est considérée comme une surface mesurable. Capturez un enregistrement idéal, un cas d’échec et la note de réversion avant d’élargir le périmètre. Documentez ensemble le parcours réussi et le parcours de récupération. Les tentatives répétées, les contrôles humains et la gestion des messages non livrés font partie intégrante du produit, et non d’une mise en forme ultérieure.
Question
↓
Retrieve
↓
LLM
↓
Answer
Question
↓
LLM
↓
"What information am I missing?"
↓
Retrieve
↓
Observe
↓
"What else do I need?"
↓
Tool call
↓
Observe
↓
Update hypothesis
↓
Retrieve again
↓
Answer
I need:
1. Current metrics
2. Historical metrics
3. Recent deployments
I see a preprocessing change.
I now need:
4. Code/config diff
5. Evaluation by preprocessing version
The degradation occurs only on the new preprocessing path.
Hypothesis strengthened.
14. Un exemple concret : l’agent de débogage d’apprentissage automatique
Pour l’étape « Un exemple concret » n°14, il convient de définir les entrées, le responsable de l’étape ainsi que les critères d’arrêt avant de modifier du code. Les opérateurs doivent pouvoir relancer l’étape à partir d’un point de contrôle connu sans deviner l’état caché. Préférer des unités petites et testables aux scripts complexes. Lorsqu’une étape échoue, l’échec doit indiquer une seule responsabilité et non un processus embrouillé. Faire approuver par des humains les actions qui entraînent des dépenses ou modifient des données de production. Une connexion effectuée en temps de compilation ne garantit pas la complétude du processus métier.
Image-level AUROC
Monday: 0.94
Tuesday: 0.93
Wednesday: 0.92
Thursday: 0.85
Contexte initial
Pendant la phase de contexte initial, définissez les entrées, le responsable de l’étape et les critères d’arrêt avant de modifier du code. Les opérateurs doivent pouvoir relancer l’étape à partir d’un point de contrôle connu sans deviner l’état caché. Considérez cette phase comme un contrat entre les entrées et les sorties validées. Donnez des noms aux artefacts, définites des vérifications de succès et refusez les terminaisons partielles silencieuses. Faites approuver par un humain les cas où de l’argent est dépensé ou où des données de production sont modifiées. La connexion en temps de compilation ne revient pas à une complétude opérationnelle.
Task:
Diagnose the AUROC degradation.
Current metric:
0.85Previous metric:
0.92
Appel d’outil 1 : système de déploiement
Pour l’étape de déploiement « Appel d’outil 1 », définissez les entrées, le responsable de l’étape et les critères de fin avant de modifier le code. Les opérateurs doivent pouvoir relancer l’étape à partir d’un point de contrôle connu sans deviner l’état caché. Enregistrez les temps d’exécution ainsi que le coût des jetons ou des requêtes à côté des résultats fonctionnels. Une visibilité précoce des coûts évite les factures inattendues lorsque le parcours passe de l’environnement de démonstration aux environnements partagés. Authentifiez-vous au niveau du gateway et réautorisez-vous au niveau du plan de données. Un simple jeton porteur ne constitue pas une frontière entre les tenants.
Current model:
v4.2
Previous model:
v4.1
Pour l’étape de déploiement liée à l’appel d’outil 1, définissez les entrées, le responsable de l’étape ainsi que les critères d’arrêt avant de modifier le code. Les opérateurs doivent pouvoir relancer l’étape à partir d’un point de contrôle connu, sans avoir à deviner l’état caché. Documentez conjointement le parcours normal et le parcours de récupération. Les tentatives répétées, les contrôles humains et la gestion des messages non livrés font partie intégrante du produit, et non d’améliorations ultérieures.
Appel d’outil 2 : registre de modèles
Lors du travail sur l’étape du modèle « Appel d’outil 2 », notez d’abord le contrat : les entrées requises, le signal de succès, ainsi que ce qui se passe en cas d’échec partiel. Cette liste de contrôle permet de rester honnête lors des modifications ultérieures du code. Préférez des unités petites et testables à des scripts complexes. Lorsqu’une étape échoue, l’échec doit indiquer une seule responsabilité plutôt qu’un processus embrouillé. Mémorisez les instructions du système stables ainsi que les schémas des outils. Envoyer à nouveau un préambule identique est une cause fréquente de gaspillage.
Weights:
v4.1 == v4.2
Appel d’outil 3 : service de configuration
Lors de la phase de configuration de l’appel d’outil 3, notez d’abord le contrat : les entrées requises, le signal de succès, ainsi que ce qui se passe en cas d’échec partiel. Cette liste de contrôle permet de rester honnête lors des modifications ultérieures du code. Considérez cette phase comme un contrat entre les entrées et les sorties validées. Donnez des noms aux artefacts, définez des vérifications de succès, et refusez les terminations partielles silencieuses. Enregistrez le nom de l’outil, le hash des arguments, la latence et le résultat de chaque appel. Sans cette trace, les boucles d’agent de débogage perdent des heures.
Resize:
224 → 336
Normalization:
unchanged
Appel d’outil 4 : service d’évaluation
Lors de l’étape d’évaluation des appels à l’outil 4, notez d’abord le contrat : les entrées requises, le signal de succès et ce qui se passe en cas d’échec partiel. Cette liste de contrôle permet de garantir l’intégrité des modifications ultérieures du code. Enregistrez les temps d’exécution ainsi que le coût en tokens ou en requêtes à côté des résultats fonctionnels. Une visibilité précoce des coûts évite des factures inattendues lorsque le processus passe de l’environnement de démonstration à des environnements partagés. Journalisez le nom de l’outil, son hash d’arguments, la latence et le résultat de chaque appel. Sans ces traces, le débogage de boucles d’agent prend des heures inutilement.
v4.2 + 224px:
AUROC = 0.93
v4.2 + 336px:
AUROC = 0.85
Lors de l’étape d’évaluation des appels à l’outil 4, notez d’abord le contrat : les entrées requises, le signal de succès et ce qui se passe en cas d’échec partiel. Cette liste de contrôle permet de garantir l’intégrité des modifications ultérieures du code. Documentez en même temps le parcours normal et les procédures de récupération. Les tentatives de réessai, les contrôles humains et la gestion des messages non livrés font partie intégrante du produit, et non d’améliorations ultérieures.
Finding:
The performance degradation is strongly associated with
the preprocessing change from 224px to 336px.
Evidence:
- Model weights unchanged.
- Deployment introduced 336px preprocessing.
- 224px evaluation restores AUROC to 0.93.
- 336px evaluation produces AUROC of 0.85.Recommendation:
Roll back preprocessing to 224px while investigating
why the new preprocessing configuration causes degradation.
15. Ingénierie du contexte et RAG
L’étape d’ingénierie du contexte fonctionne le mieux lorsqu’elle est considérée comme une surface mesurable. Capturez un transcript exemplaire, un cas d’échec et la note de réversion avant d’élargir le périmètre. Préférez des unités petites et testables plutôt que des scripts complexes. Lorsqu’une étape échoue, l’échec doit pointer vers une seule responsabilité et non vers un processus embrouillé. Séparez la politique de segmentation des données de la politique de récupération. Modifier l’une ne doit pas obliger à réécrire l’autre lorsque les métriques de qualité changent.
Query
↓
Retriever
↓
Documents
↓
LLM
Goal
↓
Agent
↓
Determine missing context
↓
Retrieve / Query / Execute
↓
Evaluate results
↓
Update state
↓
Retrieve again
↓
Compress
↓
Assemble context
↓
LLM
↓
Action
16. L’ingénierie du contexte est similaire à l’ingénierie des fonctionnalités
L’étape 16 de l’ingénierie du contexte fonctionne le mieux lorsqu’elle est considérée comme une surface mesurable. Capturez un transcript exemplaire, un cas d’échec et la note de réversion avant d’élargir le périmètre. Considérez cette étape comme un contrat entre les entrées et les sorties validées. Donnez des noms aux artefacts, définez des critères de succès et refusez toute completion partielle silencieuse. Maintenez l’état du graphe plat et typé. Les blocs imbriqués masquent le fait que tel nœud a écrit telle champ et perturbent la reprise après interruption.
Raw data
↓
Feature engineering
↓
Feature selection
↓
Model
↓
Prediction
Raw information
↓
Context retrieval
↓
Context filtering
↓
Context transformation
↓
Context selection
↓
LLM
↓
Decision
17. Évaluation de la qualité du contexte
Bad retrieval
↓
Bad context
↓
Bad reasoning
↓
Bad action
↓
Bad answer
Qualité de la récupération
Qualité du contexte
Qualité du raisonnement
Qualité de l’action
Succès de la tâche finale
Retrieval
↓
Context
↓
Reasoning
↓
Action
↓
Outcome
18. Erreurs courantes
Erreur 1 : « Mettre simplement tout dans le prompt »
Erreur 2 : Considérer la recherche vectorielle comme la solution complète
Erreur 3 : Conserver un historique de conversation infini
Recent details
+
Compressed historical state
+
Relevant retrieved information
Erreur 4 : Mélanger faits et suppositions
Erreur 5 : Ignorer le contexte temporel
timestamp
version
deployment
experiment
data snapshot
environment
19. Une architecture pratique pour votre premier agent
┌──────────────┐
│ User │
└──────┬───────┘
↓
┌──────────────┐
│ Agent │
└──────┬───────┘
↓
┌─────────────────┐
│ Context Manager │
└───────┬─────────┘
↓
┌────────────┼────────────┐
↓ ↓ ↓
Search Database Tools
│ │ │
└────────────┼────────────┘
↓
Context Assembly
↓
LLM
↓
Action
↓
Observation
↓
Context Update
20. Où va l’ingénierie du contexte agent
LLM + Tools
LLM
+
Memory
+
Retrieval
+
State
+
Tools
+
Environment
+
Context Management
Conclusion
Prompt Engineering
↓
RAG
↓
Memory
↓
Tool Use
↓
State Management
↓
Agentic Context Engineering