Lektion 05 · Planung

Domänenwissen bei Bedarf laden

"Don't put everything in the system prompt. Load on demand."

⏱ ~10 Min · 📝 3 interaktive Widgets · 🧑‍💻 Basiert auf shareAI-lab · s05_skill_loading.py

Die Falle des vollständigen System-Prompts

Du hast 20 Skills, jeden gut dokumentiert: pdf-processing, code-review, git-workflow... Der naheliegende Ansatz: alles ins System-Prompt packen, damit das Modell jederzeit nachschlagen kann.

Das Ergebnis:

  • Jeder API-Aufruf verbraucht 15–30K Input-Token — selbst wenn die Frage keinen einzigen Skill braucht.
  • Die Aufmerksamkeit des Modells wird verdünnt — die Befolgung langer System-Prompts nimmt mit der Länge ab.
  • Ändert man einen Skill, wird der gesamte Cache aller bisherigen Gespräche ungültig.

s05 löst das mit einer Zwei-Schichten-Architektur.

Zwei-Schichten-Architektur

Schicht 1 · Günstig: Im System-Prompt stehen nur Name und ein Satz Beschreibung pro Skill (ca. 100 Token). 20 Skills = 2K Token — vertretbar.

# Skill-Liste im 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.

Schicht 2 · On-Demand: Will das Modell einen Skill nutzen, ruft es load_skill(name="pdf") auf. Der vollständige Skill-Body (5–10K Token) wird via tool_result in den Context geladen. Ungenutzte Skills kosten keinen einzigen Token.

# tool_result enthält den vollständigen Skill
<skill name="pdf">
  Step 1: Use pdfplumber for extraction...
  Step 2: Handle OCR fallback when needed...
  Step 3: Structure output as Markdown table...
</skill>

Token-Kosten vergleichen

Konkretes Szenario: 20 Skills, durchschnittlich 3.000 Token pro Body. Der Nutzer stellt eine Frage, die vermutlich keinen Skill benötigt.

Format der SKILL.md-Datei

Skill-Dateien verwenden YAML-Frontmatter und Fließtext:

---
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...

Frontmatter wird für Schicht 1 verwendet (name/description/tags), der Fließtext für Schicht 2. Das Format ist von statischen Blog-Generatoren (Jekyll, Hugo) inspiriert — wer damit vertraut ist, versteht es sofort.

Interaktiv

Widget 1 · Token Economy · Zwei Architekturen im Vergleich

Links: alles ins System-Prompt. Rechts: Zwei-Schichten-Architektur. Schieberegler auf 20 Gespräche stellen und kumulierte Token vergleichen.

Alles im System-Prompt
System-Prompt: 60000 tokens
(20 × 3000-Token-Skills)
× Gespräche: 1

Gesamt: 60000 tokens
Zwei-Schichten-Architektur
System-Prompt: 2000 tokens
(20 Beschreibungen × ~100 Token)
+ Nachgeladene Skill-Bodies: 0 tokens
(alle 5 Gespräche ein Skill)

Gesamt: 2000 tokens
1
0% gespart
Interaktiv

Widget 2 · Frontmatter Parser · Skill-Metadaten extrahieren

Gib eine SKILL.md ein und sieh, was Schicht 1 und Schicht 2 jeweils bekommen.

SKILL.md (editierbar)
Schicht 1 · Im System-Prompt

          
Schicht 2 · load_skill tool_result

          
Interaktiv

Widget 3 · Auffindbarkeit · Gute Beschreibungen helfen dem Modell

Schicht-1-Beschreibungen sind das Auswahlkriterium des Modells. 3 Vergleichspaare — wähle die bessere Beschreibung. Manche Formulierungen machen einen Skill praktisch unsichtbar.

0 / 3 richtig