Was macht assistant-lab?
Selbstverbesserungs-Werkbank für /assistant. Dies ist das Labor, in dem
/assistant Probleme diagnostiziert, neue Modelle trainiert, sie evaluiert und
bestandene Modelle in das Live-Registry übernimmt.
Nicht zu verwechseln mit /monitor-skills – dem Observability-Daemon, der ALLE Skills auf Gesundheit, Drift und Sync-Probleme überwacht. /assistant-lab ist spezifisch die Selbstverbesserungs-Werkzeugkiste.
Der Selbstverbesserungs-Kreislauf
/monitor-skills erkennt Problem ← Observability
↓
/assistant-lab diagnostiziert Grundursache ← dieser Skill
↓
Schattenmodus: Lehrer (scillm) beschriftet Fluss in shadow.jsonl
↓
ModelFactory.auto_improve(task)
├─ liest Schattenübereinstimmungsrate
├─ >= 90%: Promoten → model_registry.json aktualisieren
├─ 80-90%: Plateau → /prompt-lab Neugestaltung
├─ 70-80%: Neu trainieren → /create-gpt oder /create-classifier
└─ < 70%: Aggressiv neu trainieren + Architekturänderung
↓
/gpt-lab Benchmark oder /classifier-lab Evaluierung
↓ bestanden? → ins Live-Registry promoten
↓
/assistant verwendet das verbesserte Modell zur Inferenzzeit
Verfügbare Werkzeuge
| Werkzeug | Zweck | Verwendung |
|---|---|---|
/create-gpt | QLoRA/SFT/GRPO GPT trainieren (Stufe 1.5) | Übereinstimmung < 80% oder kein Modell vorhanden |
/create-classifier | DistilBERT/sklearn Klassifikator trainieren (Stufe 0.5) | Textklassifikationsaufgaben |
/create-regressor | sklearn/XGB Regressor trainieren (Stufe 0.75) | Kontinuierliche Vorhersageaufgaben |
| RunPod Flash | Serverloses GPU-Training via Python SDK (7B–70B) | Modell zu groß für lokale A5000 — ersetzt /ops-runpod für Training |
/gpt-lab | GPT gegen Lehrer-Baseline benchmarken | Nach Training, vor Promotion |
/classifier-lab | Klassifikator-Genauigkeit/F1 bewerten | Nach Klassifikator-Training |
/prompt-lab | Prompts bei Plateauerkennung neugestalten | Übereinstimmung bei 80-90% festgefahren |
/scillm | Stufe 2 Lehrer — erstellt Labels | Immer (Lehrer ist Ground Truth) |
Verwendung
CLI
# Diagnostiziere, was eine Aufgabe benötigt
./run.sh diagnose --task stress-test-grader
# Vollständiger autonomer Verbesserungskreislauf
./run.sh auto-improve --task stress-test-grader
# Spezifischen Modelltyp trainieren
./run.sh train --task stress-test-grader --type gpt
./run.sh train --task sparta-ambiguity --type classifier
# Ein Modell evaluieren
./run.sh evaluate --task stress-test-grader --type gpt
# Ein bestandenens Modell promoten (deaktiviert Schattenmodus)
./run.sh promote --task stress-test-grader --type gpt
# Lehrerlabels aus shadow.jsonl ernten
./run.sh harvest --task stress-test-grader --since 24h
# Schattenübereinstimmungsstatistiken für alle Aufgaben anzeigen
./run.sh status
# Vollständigen Selbsttest ausführen (Train → Eval → Promote-Zyklus auf Testdaten)
./run.sh self-test
Python-API
from assistant_lab import AssistantLab
lab = AssistantLab()
# Diagnose: Was braucht diese Aufgabe?
diagnosis = lab.diagnose("stress-test-grader")
# → {"has_gpt": False, "has_classifier": False, "shadow_agreement": 0.0, ...}
# Auto-Improve: Entscheiden + Trainieren + Evaluieren + Promoten
result = lab.auto_improve("stress-test-grader")
# → {"actions": ["trained gpt", "evaluated (passing=True)", "promoted"]}
# Manuelle Schritte
lab.train("stress-test-grader", model_type="gpt")
lab.evaluate("stress-test-grader", model_type="gpt")
lab.promote("stress-test-grader", model_type="gpt")
Modellfabrik
Die Kernmaschine ist ModelFactory (aus /common/model_factory.py).
/assistant-lab kapselt sie mit CLI + Diagnose + Berichterstattung.
Schwellenwerte der Schattenübereinstimmung
| Übereinstimmungsrate | Aktion | Begründung |
|---|---|---|
| >= 90% | Promoten | Schüler stimmt zuverlässig mit Lehrer überein |
| 80-90% | /prompt-lab Neugestaltung | Plateau — Prompts könnten die Grenze sein |
| 70-80% | Neu trainieren mit mehr Labels | Mehr Daten helfen wahrscheinlich |
| < 70% | Aggressiv neu trainieren | Architektur oder Basismodell ändern |
| < 50 Stichproben | Warten | Nicht genug Daten für eine Entscheidung |
Minimale Trainingsdaten (NICHT VERHANDELBAR)
Rufe NICHT /create-gpt train oder /create-classifier train mit unzureichenden Daten auf.
| Modelltyp | Mindeststichproben | Regel |
|---|---|---|
| GPT (QLoRA SFT) | 1.000+ insgesamt | < 1.000 → bleibt auf Stufe 2 Lehrer |
| Klassifikator (sklearn/SetFit) | 200 pro Klasse | n_samples / n_classes >= 200 |
| Regressor | 100+ insgesamt | Standard sklearn-Richtlinie |
Nachweis: sparta_stress_grading wurde auf 246 Stichproben trainiert → 33,7% Übereinstimmung.
Das sind 4 Monate verschwendeter Schattenlabels, weil das Modell zu früh trainiert wurde.
Erst sammeln, trainieren wenn bereit.
Trainingsdatenfluss
Stufe 2 Lehrer (scillm via Persona)
↓ Labels in shadow.jsonl gespeichert
↓
/assistant-lab harvest --task X
↓ Extrahiert Eingabe+Ausgabe-Paare
↓
/create-gpt train --task X --data labels.jsonl
↓ QLoRA auf Qwen2.5-1.5B (Standard)
↓
/gpt-lab benchmark --task X
↓ Vergleicht Schüler vs. Lehrer
↓
/assistant-lab promote --task X --type gpt
↓ Aktualisiert model_registry.json, shadow_mode=false
Remote-Training (RunPod Flash)
Für Modelle, die zu groß für die lokale RTX A5000 (24 GB VRAM, max ~1,7B mit LoRA) sind,
verwendet assistant-lab RunPod Flash – das serverlose Python SDK ohne Docker,
ohne SSH und ohne rsync-Overhead. Flash ersetzt /ops-runpod für alle Trainingspfade.
/ops-runpod bleibt nur für persistente Inferenzserver erhalten.
Wann Flash verwenden
| Modellgröße | Lokale A5000 | Flash nötig | GPU |
|---|---|---|---|
| 0,5–1,7B | LoRA passt | Nein | ./run.sh train (lokal) |
| 3–7B | Passt nicht | Ja | B200 (bevorzugt) oder H200 |
| 8–13B | Unmöglich | Ja | B200 (bevorzugt) oder H200 |
Flash-GPU-Typen
| GPU | VRAM | Hinweise |
|---|---|---|
B200 | 192 GB HBM3e | Schnellste; 3–5× H200 bei MoE / langem Kontext |
H200 | 192 GB HBM3 | Gute Verfügbarkeit; solide Basislinie |
Abrechnung: Pay-per-Second, maximal 7 Tage Ausführungszeit pro Job.
Flash-Kostenschätzungen (ungefähr)
| Modellgröße | GPU | Geschätzte Trainingszeit | Geschätzte Kosten |
|---|---|---|---|
| 7B QLoRA SFT | B200 | ~1–2 Std. | ~$5–15 |
| 7B QLoRA SFT | H200 | ~2–3 Std. | ~$8–20 |
| 13B QLoRA SFT | B200 | ~2–4 Std. | ~$10–25 |
| 13B QLoRA SFT | H200 | ~3–5 Std. | ~$12–30 |
Befehle
# Schritt 1: Immer zuerst Kosten schätzen
./run.sh estimate --task taxonomy-assessor --target flash --gpu B200 --size 7B
# Schritt 2: Auf Flash B200 trainieren (erfordert --confirm zur Sicherheit)
./run.sh train --task taxonomy-assessor --target flash --gpu B200 --size 7B --confirm
# Auf Flash H200 trainieren
./run.sh train --task taxonomy-assessor --target flash --gpu H200 --size 13B --confirm
# Mit benutzerdefiniertem Basismodell
./run.sh train --task taxonomy-assessor --target flash --gpu B200 --size 8B \
--base-model meta-llama/Llama-3.1-8B-Instruct --confirm
# Mit anderer Quantisierung
./run.sh train --task qra-validator --target flash --gpu B200 --size 7B \
--quantize Q5_K_M --confirm
Flash-Trainingspipeline
estimate --target flash --gpu B200 --size 7B
↓
train --target flash --gpu B200 --confirm
├─ 1. Kostenschätzung + Budgetschranke
├─ 2. Flash serverloser Job übermittelt (Python SDK — kein Docker/SSH)
├─ 3. Dataset zum Flash-Arbeiter gestreamt
├─ 4. QLoRA / SFT Training läuft auf B200/H200 (192 GB VRAM)
├─ 5. Modellgewichte nach /mnt/storage12tb/models/ geholt
├─ 6. create-gpt export --quantize Q4_K_M (GGUF)
└─ 7. Evaluieren + automatisch promoten wenn bestanden
Sicherheitssperren
- Budgetobergrenze:
--max-cost(Standard $15,00) blockiert Training, wenn Schätzung Grenzwert überschreitet - Bestätigung: Muss
--confirmübergeben — ohne wird Kosten angezeigt und beendet - Automatischer Abbau: Flash-Job wird beim Beenden abgebrochen (auch bei Fehlern, via trap)
- Metrikprotokollierung: Jeder Flash-Trainingslauf wird in
lab_metrics.jsonlprotokolliert
Integration mit dem Selbstverbesserungs-Kreislauf
Remote-trainierte Modelle integrieren sich in dieselbe Kaskade wie lokale Modelle:
Stufe 0: Heuristik (kostenlos, sofort)
Stufe 0.5: Klassifikator (lokal, kostenlos)
Stufe 1.5: Lokales GPT ≤1,7B (create-gpt, kostenlos nach Training)
Stufe 1.5: Remote GPT 3-13B (train-remote, kostenlos nach Training) ← NEU
Stufe 2: scillm/DeepSeek V3 (Chutes, $0,12/1K Aufrufe)
Ein 7-13B Modell auf Stufe 1.5 kann Stufe 2 (Chutes) Eskalationen erheblich reduzieren, und damit potenziell seine Trainingskosten durch reduzierte Überschreitungen amortisieren.
Beziehung zu anderen Skills
/monitor-skills ──→ "Skill X ist nicht gesund"
↓
/assistant-lab ──→ Diagnose → Trainieren → Evaluieren → Promoten
↓
/assistant ──────→ Verwendet promoviertes Modell zur Inferenzzeit
/monitor-skills: Beobachtet ALLE Skills. Erkennt Probleme. Meldet Gesundheit./assistant-lab: Repariert die Modelle von /assistant. Trainiert, evaluiert, promoviert./assistant: Führt Inferenz durch. Verwendet Modelle, die das Labor produziert hat.
Vertrag
- Eingabe: Aufgabenname + optionaler Modelltyp
- Ausgabe: Diagnose, Trainingsergebnisse, Evaluierungsergebnisse, Promotionsstatus
- Abhängigkeiten: model_factory.py (aus /common), create-*- und *-lab Fähigkeiten
- Metriken: Hängt an
~/.pi/assistant/lab_metrics.jsonlan