Leçon 05 · Planification

Chargement à la demande des connaissances métier

« Ne mettez pas tout dans le system prompt. Chargez à la demande. »

⏱ ~10 min · 📝 3 widgets interactifs · 🧑‍💻 Basé sur shareAI-lab · s05_skill_loading.py

Le piège du « tout dans le system prompt »

Vous avez 20 skills bien documentés : pdf-processing (comment lire des PDF), code-review (checklist de revue), git-workflow (patterns git courants)… Réflexe naturel : tout concaténer dans le system prompt pour que le modèle puisse s'y référer à tout moment.

Résultat :

  • Chaque appel consomme 15 à 30 K tokens en entrée — même quand la question n'a rien à voir avec aucun skill.
  • L'attention du modèle se dilue — dans un long system prompt, le respect des règles mentionnées décroît.
  • Modifier un seul skill invalide le cache de toutes les conversations précédentes.

L'approche de s05 : découper en deux couches.

L'architecture à deux couches

Couche 1 · bon marché : le system prompt ne contient que le nom et une description en une phrase (environ 100 tokens par skill). 20 skills = 2 K tokens, acceptable.

# liste des skills dans le system prompt
Skills available:
  - pdf: Process PDF files. Extract text, tables, metadata.
  - code-review: Systematic code review checklist.
  - git-workflow: Common git branching and rebase patterns.

Couche 2 · à la demande : quand le modèle a besoin d'un skill, il appelle load_skill(name="pdf") et le corps complet du skill (parfois 5 à 10 K tokens) est injecté via un tool_result. Les skills non utilisés ne consomment pas un seul token.

# le tool_result retourne le skill complet
<skill name="pdf">
  Step 1: Use pdfplumber for extraction...
  Step 2: Handle OCR fallback when needed...
  Step 3: Structure output as Markdown table...
</skill>

Comparer les coûts en tokens

Testons sur un cas réel. Supposons 20 skills, chacun pesant en moyenne 3 000 tokens. L'utilisateur pose une question (par exemple « corrige ce bug dans le contrôleur de login ») — qui n'utilise probablement aucun skill.

Format d'un fichier SKILL.md

Un fichier skill utilise un frontmatter YAML suivi du corps :

---
name: pdf
description: Process PDF files. Extract text, tables, metadata.
tags: document,parsing
---

Step 1: Use pdfplumber for extraction. Handle multi-column layouts...
Step 2: For scanned PDFs, fall back to OCR via tesseract...

Le frontmatter alimente la Couche 1 (name/description/tags), le corps alimente la Couche 2. Ce format s'inspire des générateurs de sites statiques (Jekyll, Hugo) — familier pour quiconque les a pratiqués.

Interactif

Widget 1 · Token Economy · comparaison des deux architectures

À gauche : tout dans le system prompt. À droite : architecture à deux couches. Observez les tokens cumulés après N conversations.

Tout dans le system prompt
System prompt : 60000 tokens
(20 skills × 3 000 tokens chacun)
× nombre de conversations : 1

Total : 60000 tokens
Architecture à deux couches
System prompt : 2000 tokens
(20 descriptions × ~100 tokens chacune)
+ skills chargés à la demande : 0 tokens
(1 chargement toutes les 5 conversations)

Total : 2000 tokens
1
Économie : 0%
Interactif

Widget 2 · Frontmatter Parser · extraire les métadonnées d'un skill

Saisissez un fichier SKILL.md et observez ce que la logique de parsing YAML de s05 extrait pour la Couche 1 et la Couche 2.

SKILL.md (éditable)
Couche 1 · inséré dans le system prompt

          
Couche 2 · tool_result retourné par load_skill

          
Interactif

Widget 3 · Discoverability · une bonne description, c'est ce qui permet au modèle de trouver le skill

La description de la Couche 1 est la seule base sur laquelle le modèle choisit un skill. Parmi 3 paires de descriptions, sélectionnez la meilleure — certaines formulations empêchent le modèle de trouver le skill.

Correct : 0 / 3