Wann was verwenden
Kernideen
- Zuerst die Aufgabenart bestimmen, dann das Vorgehen wählen
- Einfache Aufgaben brauchen kein aufwendiges Pattern, nur einen klaren Auftrag
- Denkführende Patterns lohnen sich, wo mehrere Schritte oder Fallunterscheidungen nötig sind
- Prüfende Patterns lohnen sich, wo ein Fehler teuer wäre
- Fehlt dem Modell Wissen, hilft kein Pattern, sondern nur Kontext
- Für Rechnen, exakte Zahlen und Reproduzierbarkeit ist Code das bessere Werkzeug
Erklärung
Diese Seite ist der Einstieg in den Bereich. Sie ordnet zu, was auf den anderen Seiten ausgeführt wird: die Bausteine eines Prompts, die grundlegenden Patterns, die denkführenden Patterns, die prüfenden Patterns und die fertigen Prompts für die Datenarbeit.
Der erste Schritt: um welche Art von Aufgabe geht es
Die meisten Fehlgriffe entstehen nicht an der Formulierung, sondern an der Einordnung. Wer eine Wissensfrage stellt, wo eine Rechenaufgabe vorliegt, bekommt eine flüssig formulierte falsche Zahl.
| Art der Aufgabe | Woran erkennbar | Vorgehen |
|---|---|---|
| Umformulieren, kürzen, übersetzen | Der Inhalt liegt vor, nur die Form ändert sich | Klarer Auftrag mit Zielformat, kein Pattern nötig |
| Erklären lassen | Etwas ist verstanden worden oder auch nicht | Persona plus Zielgruppe, danach eine Verständnisfrage stellen |
| Strukturieren, gliedern | Viel unsortiertes Material | System-2 Attention, dann Gliederung anfordern |
| Mehrstufig schliessen, planen | Die Antwort hängt von Zwischenergebnissen ab | Plan-and-Solve oder Chain-of-Thought |
| Rechnen, zählen, exakt vergleichen | Es geht um Zahlen, die stimmen müssen | Program-of-Thoughts: Code erzeugen und ihn selbst ausführen |
| Code schreiben oder verstehen | Eine Datei, eine Funktion, ein Fehler | Kontext mitgeben, Beispielaufruf verlangen, danach selbst testen |
| Entscheiden zwischen Optionen | Mehrere Wege, unklare Kriterien | Step-Back, dann Kriterien und Bewertung getrennt anfordern |
| Prüfen, gegenlesen | Ein Entwurf liegt vor | Self-Refine oder gezielt nach Gegenargumenten fragen |
| Fakten nachschlagen | Es geht um Wissen, das stimmen muss | Kein Pattern, sondern Quelle: Dokumente mitgeben oder in einer Referenz nachschlagen |
Der zweite Schritt: wie viel Aufwand lohnt sich
Ein Pattern ist Aufwand, und Aufwand lohnt sich nur bei entsprechendem Nutzen. Als Faustregel:
- Ein Satz genügt, wenn die Aufgabe klar, die Antwort kurz und ein Fehler billig ist. Ein Umformulierungsauftrag braucht keine Rollenzuweisung.
- Struktur lohnt sich, sobald Format, Zielgruppe oder Umfang eine Rolle spielen. Das ist der Fall der Prompt-Bausteine.
- Denkführung lohnt sich, wenn die Aufgabe in Schritte zerfällt oder wenn Zwischenergebnisse aufeinander aufbauen.
- Prüfung lohnt sich, wenn das Ergebnis weiterverwendet wird: in einem Bericht, in Code, in einer Entscheidung.
Der teuerste Fehler ist nicht das zu einfache Prompt, sondern das ungeprüfte Ergebnis.
Welches Modell
Die Modelllandschaft ändert sich schnell, die Kategorien bleiben stabil.
| Kategorie | Wofür | Worauf achten |
|---|---|---|
| Kleines, schnelles Modell | Umformulieren, Klassifizieren, Standardauskünfte, viele Aufrufe | Bei mehrstufigen Aufgaben brechen die Schlüsse früh ab |
| Standardmodell | Der Normalfall: Erklären, Entwerfen, Code, Analysen mittlerer Tiefe | Denkführende Patterns wirken hier am deutlichsten |
| Reasoning-Modell | Schwierige Schlüsse, Planung, Aufgaben mit vielen Abhängigkeiten | Höhere Kosten und Wartezeit; das Modell denkt selbst in Schritten, deshalb bringen Denkführungs-Patterns wenig zusätzlich |
| Modell mit Werkzeugzugriff | Rechnen, Dateien lesen, Suche, Code ausführen | Nur so gut wie die Werkzeuge und deren Daten |
Bei Reasoning-Modellen verschiebt sich die Arbeit von der Denkführung zur präzisen Aufgabenbeschreibung: Was genau soll herauskommen, in welcher Form, unter welchen Randbedingungen.
Wann kein Sprachmodell
Es gibt Aufgaben, bei denen ein Sprachmodell die falsche Wahl ist, unabhängig von Modell und Formulierung:
- Exakte Rechnungen und Aggregationen. Eine Summe über 5000 Zeilen gehört in pandas oder SQL, nicht in einen Chat.
- Reproduzierbare Auswertungen. Was im Bericht steht, muss beim nächsten Datenstand automatisch stimmen, siehe Reproduzierbarkeit.
- Statistische Entscheidungen. Welcher Test passt, entscheidet der Entscheidungsbaum; ein Modell kann die Wahl erklären, aber die Voraussetzungen prüfen die Daten.
- Vertrauliche Daten in Werkzeugen ohne geklärte Verarbeitung.
- Fragen, deren Antwort niemand prüfen kann. Wo keine Prüfung möglich ist, ist die Antwort wertlos, egal wie überzeugend sie klingt.
Die Kurzfassung als Entscheidungsbaum
- Muss die Antwort exakt sein und lässt sie sich rechnen? Dann Code, nicht Prompt.
- Braucht das Modell Wissen, das es nicht hat? Dann Kontext mitgeben (Dokumente, Auszüge, Zahlen), siehe Context Engineering.
- Ist die Aufgabe in einem Schritt lösbar? Dann klarer Auftrag mit Format, fertig.
- Zerfällt sie in mehrere Schritte? Dann erst planen lassen, dann ausführen.
- Wird das Ergebnis weiterverwendet? Dann eine Prüfrunde anhängen und selbst gegenlesen.
Verständnisfragen
Diese Seite rechnet nichts: Im Build gibt es keinen Modellzugriff, und Modellantworten wären auch damit nicht reproduzierbar, weil dasselbe Prompt je nach Modellstand und Zufall verschieden beantwortet wird. Die Beispiele sind deshalb Prompts und Antwortauszüge zum Lesen, nicht ausgeführte Chunks. Was sich dagegen reproduzieren lässt, ist die Prüfung einer Antwort an den Daten, siehe Prompts für die Datenarbeit.
Eine Tabelle mit 40 000 Zeilen soll nach Monat aggregiert werden. Was ist der richtige Weg?
Für eine schwierige Planungsaufgabe steht ein Reasoning-Modell zur Verfügung. Was ändert sich am Prompt?