Lección 05 · Planificación

Conocimiento de dominio cargado bajo demanda

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

⏱ ~10 min · 📝 3 widgets interactivos · 🧑‍💻 Basado en shareAI-lab · s05_skill_loading.py

El problema de «meter todo en el system prompt»

Tienes 20 skills, cada una bien detallada: pdf-processing (cómo leer PDFs), code-review (checklist de review), git-workflow (flujos habituales de git)… Lo más intuitivo: concatenarlas todas en el system prompt para que el modelo las consulte cuando quiera.

Resultado:

  • Cada llamada quema 15-30K tokens de entrada aunque la pregunta no use ninguna skill.
  • La atención del modelo se diluye — las reglas mencionadas en un system prompt largo tienen peor tasa de cumplimiento.
  • Modificar una skill invalida la caché de toda la conversación.

La solución de s05 es dividirlo en dos capas.

Arquitectura de dos capas

Capa 1 · barata: el system prompt solo lleva el nombre y una descripción de una línea por skill (≈100 tokens cada una). 20 skills = 2K tokens — aceptable.

# Lista de skills en el 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.

Capa 2 · bajo demanda: cuando el modelo necesita una skill, llama a load_skill(name="pdf") y el cuerpo completo (5-10K tokens) llega por tool_result. Las skills no usadas no añaden ni un token.

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

Comparativa del coste en tokens

Hagamos números reales. 20 skills, promedio de 3000 tokens por cuerpo. El usuario hace una pregunta (por ejemplo, «arregla el bug en el endpoint de login») que probablemente no necesita ninguna skill.

Formato del archivo SKILL.md

Los archivos de skill usan YAML frontmatter + cuerpo de texto:

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

El frontmatter alimenta la Capa 1 (name/description/tags); el cuerpo alimenta la Capa 2. Este formato está inspirado en los blogs estáticos (Jekyll, Hugo) — quien lo conoce, lo entiende de un vistazo.

Interactivo

Widget 1 · Token Economy · comparativa de las dos arquitecturas

Izquierda: todo en el system prompt. Derecha: arquitectura de dos capas. Mueve el slider y observa los tokens acumulados.

Todo en el system prompt
System prompt: 60000 tokens
(20 skills × 3000 tokens cada una)
× Conversaciones: 1

Total: 60000 tokens
Arquitectura de dos capas
System prompt: 2000 tokens
(20 descripciones × ~100 tokens cada una)
+ Skills cargadas bajo demanda: 0 tokens
(1 carga por cada 5 conversaciones)

Total: 2000 tokens
1
Ahorro 0%
Interactivo

Widget 2 · Frontmatter Parser · extrae los metadatos de una skill

Escribe un SKILL.md y observa qué recibe la Capa 1 y qué recibe la Capa 2 según la lógica de parseo de s05.

SKILL.md (editable)
Capa 1 · esto va en el system prompt

          
Capa 2 · tool_result al llamar load_skill

          
Interactivo

Widget 3 · Discoverability · una buena descripción ayuda al modelo a encontrar la skill

La descripción de la Capa 1 es lo que el modelo usa para elegir qué skill cargar. Tres comparativas — elige la descripción más útil.

Correctas 0 / 3