Synthese: Technical Literacy
The Big Picture
Abschnitt betitelt „The Big Picture“Du hast fuenf Lektionen durchgearbeitet: wie Prompt Engineering AI-Verhalten steuert, wie RAG dem Modell Zugang zu firmeneigenen Daten gibt, wann Fine-Tuning gerechtfertigt ist, wie Du das richtige Modell waehlst und wie Du AI-Features wirtschaftlich betreibst.
Einzeln sind das technische Werkzeuge. Zusammen bilden sie eine Optimierungshierarchie: Lektion 1 ist der schnellste, guenstigste Hebel. Lektion 2 erweitert das Wissen des Modells. Lektion 3 ändert sein Verhalten. Lektion 4 bestimmt das Qualitaets-Ceiling und den Kosten-Floor. Lektion 5 laeuft quer über alle Ebenen — Caching, Routing, Batching und Monitoring gelten unabhängig davon, welche Techniken Du nutzt.
Der PM, der zu Fine-Tuning greift, bevor er Prompting ausgereizt hat, verschwendet Wochen und Tausende Euro. Der PM, der ein Frontier-Modell für jede Anfrage nutzt, verschwendet Geld für Qualität, die Nutzer nicht brauchen.
Connections
Abschnitt betitelt „Connections“1. Die Optimierungshierarchie
Abschnitt betitelt „1. Die Optimierungshierarchie“Prompt Engineering (L1) ist immer der erste Schritt. Wenn die Output-Qualität nicht stimmt, verbessere zuerst den Prompt. Wenn das Modell aktuelle Daten braucht, fuege RAG hinzu (L2). Wenn konsistentes Verhalten noetig ist und Prompting es nicht schafft, erwaege Fine-Tuning (L3). Die Modellwahl (L4) bestimmt, wie hoch die Qualität maximal steigen kann und wie tief die Kosten fallen können. Cost Optimization (L5) laeuft parallel zu allem.
Für Dich als PM: Dieser Pfad ist kein Vorschlag — er ist ein Kostenschutz. Jede Stufe ist eine Groessenordnung teurer und weniger flexibel als die vorherige.
2. Das Build-vs-Configure-Spektrum
Abschnitt betitelt „2. Das Build-vs-Configure-Spektrum“Jede Lektion steht für einen anderen Punkt auf dem Spektrum zwischen Konfiguration und Entwicklung. Prompt Engineering (Stunden, jederzeit aenderbar, kein Lock-in) steht am einen Ende. Fine-Tuning (Tage bis Wochen, Re-Training zum Aendern, hoher Lock-in) am anderen. RAG und Model Selection liegen dazwischen.
Für Dich als PM: Bevorzuge Konfiguration über Entwicklung. Je tiefer eine Entscheidung eingebaut ist, desto schwerer ist sie zu ändern. Starte flexibel, fixiere erst, wenn Messungen die Investition rechtfertigen.
3. Qualität ist keine einzelne Zahl
Abschnitt betitelt „3. Qualität ist keine einzelne Zahl““Qualität” bedeutet in jeder Lektion etwas anderes: Prompt-Qualität misst Format, Ton und Genauigkeit. RAG-Qualität misst Retrieval-Praezision und Answer Faithfulness. Fine-Tuning-Qualität misst Verhaltenskonsistenz. Model-Selection-Qualität misst Task-spezifische Performance. Cost/Quality misst das Minimum, das Nutzer wertschaetzen.
Für Dich als PM: Definiere “gut genug” konkret und messbar, bevor Optimierungsarbeit beginnt. “Mach es besser” ist keine Produktanforderung.
4. Verbindungen zu frueheren Kapiteln
Abschnitt betitelt „4. Verbindungen zu frueheren Kapiteln“Prompt Engineering (L1) wendet die Token-, Context-Window- und Temperature-Konzepte aus Kapitel 01 direkt an. RAG (L2) ist die primaere Halluzinations-Mitigationsstrategie aus den Foundations. Model Selection (L4) baut auf dem ML-Landscape-Verständnis aus Kapitel 01 auf. Cost/Quality Tradeoffs (L5) sind zentral für die AI-Produktstrategie aus Kapitel 02. Und die Prompt-Qualität bestimmt, was das UX-Design aus Kapitel 03 dem Nutzer zeigen kann.
5. Die technische Entscheidungs-Landkarte
Abschnitt betitelt „5. Die technische Entscheidungs-Landkarte“Wenn Du vor einer technischen AI-Entscheidung stehst, nutze dieses Routing:
| Problem | Relevante Lektion | Erster Schritt |
|---|---|---|
| AI-Output-Qualität stimmt nicht | Prompt Engineering (L1) | Prompt verbessern |
| Modell kennt unsere Daten nicht | RAG (L2) | Retrieval-Pipeline bauen |
| Ton/Stil des Modells passt nicht | Fine-Tuning (L3) | System Prompt zuerst, Fine-Tune nur wenn Prompt versagt |
| Welches Modell sollen wir nutzen? | Model Selection (L4) | Blind-Evaluation auf 50+ Anfragen |
| AI-Kosten sind zu hoch | Cost/Quality (L5) | Model Routing implementieren |
The Meta-Insight
Abschnitt betitelt „The Meta-Insight“Technische Literacy für PMs heisst nicht, selbst Code zu schreiben. Es heisst, die richtigen Fragen zu stellen: “Haben wir den Prompt optimiert, bevor wir Fine-Tuning diskutieren?” und “Was ist die minimale Qualität, die Nutzer wertschaetzen — und was kostet sie?” Wer diese Fragen stellt, trifft bessere Entscheidungen als derjenige, der jeden Benchmark auswendig kennt.
Your Technical Literacy Checklist
Abschnitt betitelt „Your Technical Literacy Checklist“Was Du jetzt können solltest:
- Die richtige Prompting-Technik für die Aufgabenkomplexitaet waehlen (Zero-Shot bis Self-Consistency) — Lektion 1
- Beurteilen, ob ein Feature RAG, Fine-Tuning oder bessere Prompts braucht — Lektion 1, 2, 3
- Eine RAG-Pipeline architektonisch verstehen und Chunking-Qualität als Haupthebel identifizieren — Lektion 2
- Fine-Tuning-Entscheidungen anhand der 6-Fragen-Matrix treffen — Lektion 3
- Modellauswahl basierend auf Task, Kosten und Latenz statt Leaderboard-Ranking treffen — Lektion 4
- Multi-Model Routing als Architekturmuster anwenden — Lektion 4, 5
- AI-Feature-Kosten berechnen und die sechs Optimierungshebel priorisieren — Lektion 5
- “Gut genug” definieren, bevor Optimierung beginnt — Lektion 5
Wenn Du bei einem Punkt unsicher bist, geh zurück zur entsprechenden Lektion. Diese technischen Grundlagen bestimmen, ob Dein AI-Feature Production-ready ist — oder ein teures Experiment bleibt.
Weiter mit: AI Evaluation
Abschnitt betitelt „Weiter mit: AI Evaluation“Du kennst die Technologie. Kapitel 5 zeigt, wie Du AI-Qualität misst und Ship/No-Ship-Entscheidungen triffst.
Self-Assessment
Abschnitt betitelt „Self-Assessment“Drei Szenarien, die mehrere Konzepte aus diesem Kapitel kombinieren. Ueberleg Dir Deine Antwort, bevor Du die Aufloesung oeffnest.
Szenario 1: Der Support-Bot mit Wissensproblem
Abschnitt betitelt „Szenario 1: Der Support-Bot mit Wissensproblem“Dein AI-Support-Bot beantwortet Kundenfragen zu Euren Produkten. Die Antwortqualitaet schwankt stark: Manchmal halluziniert das Modell Features, die nicht existieren. Dein Engineering-Lead schlägt Fine-Tuning auf Euren Support-Daten vor. Wie gehst Du vor?
Aufloesung
Bevor Fine-Tuning (Lektion 3) überhaupt diskutiert wird, pruefe die Optimierungshierarchie von oben nach unten. Halluzinierte Features deuten darauf hin, dass das Modell keinen Zugang zu aktuellen Produktdaten hat — das ist ein RAG-Problem (Lektion 2), kein Verhaltensproblem. Verbessere zuerst den System Prompt mit klaren Anweisungen wie “Antworte nur basierend auf den bereitgestellten Dokumenten” (Lektion 1), baue dann eine RAG-Pipeline auf Eure Produktdokumentation. Fine-Tuning wäre erst gerechtfertigt, wenn Prompting + RAG das Problem nicht loesen.
Szenario 2: Frontier-Modell für alles
Abschnitt betitelt „Szenario 2: Frontier-Modell für alles“Euer AI-Feature nutzt GPT-4o für alle Anfragen — von simplen FAQ-Antworten bis zu komplexen Fehlerdiagnosen. Die monatlichen API-Kosten sind auf 45.000 Euro gestiegen, und das Management will sie halbieren, ohne die Nutzerzufriedenheit zu senken. Was schlaegst Du vor?
Aufloesung
Das ist ein klassischer Fall für Multi-Model Routing (Lektion 4 + 5). Analysiere Deine Anfragen: Einfache FAQ-Fragen (vermutlich 60-70% des Volumens) können von einem guenstigeren Modell bearbeitet werden, waehrend komplexe Diagnosen beim Frontier-Modell bleiben. Kombiniere das mit Caching für häufig gestellte Fragen (Lektion 5). Entscheidend ist, vorher “gut genug” pro Anfragekategorie zu definieren (Lektion 5) und per Blind-Evaluation auf 50+ Anfragen zu validieren (Lektion 4), dass das kleinere Modell für einfache Faelle genuegt.
Szenario 3: Der Stil-Wunsch
Abschnitt betitelt „Szenario 3: Der Stil-Wunsch“Euer Produkt ist eine Lernplattform. Das Produktteam will, dass die AI im Stil eines ermutigenden Tutors antwortet — nicht neutral-sachlich. Nach drei Wochen Prompt-Iteration sagt das Engineering-Team: “Der Ton stimmt in 70% der Faelle, aber in 30% faellt das Modell in den Default-Stil zurück.” Lohnt sich Fine-Tuning?
Aufloesung
Hier sind drei Lektionen relevant: Zuerst prüfen, ob Few-Shot Prompting mit 3-5 Beispielen des gewuenschten Stils die 30% Ausreisser reduziert (Lektion 1). Falls nicht, ist das ein legitimer Fine-Tuning-Kandidat (Lektion 3) — konsistentes Stilverhalten ist genau der Use Case, für den Fine-Tuning sich lohnt, und drei Wochen Prompt-Iteration zeigen, dass Prompting an seine Grenzen stoesst. Vor dem Fine-Tuning aber die Modellwahl prüfen (Lektion 4): Manche Modelle folgen Stil-Anweisungen besser als andere. Ein Modellwechsel kostet Stunden, Fine-Tuning Wochen.
Quellen: Aufbauend auf Lektionen 1-5. IBM RAG vs Fine-Tuning vs Prompt Engineering, a16z LLMflation, DAIR.AI Prompt Engineering Guide, Artificial Analysis LLM Leaderboard, Pinecone RAG Architecture Guide