Wann Prompting ausreicht

Bevor Sie zu Fine-Tuning greifen, betrachten Sie Prompting als Nullhypothese. Moderne Frontier-Modelle verfügen über genügend latente Fähigkeiten, sodass die meisten Aufgaben ein Abruf- und Instruktionsproblem sind und kein Problem, das eine Änderung der Gewichte erfordert.

Der kostspielige Fehler, den Teams machen, besteht darin, einen Trainingslauf zu starten, obwohl ein gut strukturierter Prompt, einige Beispiele und Toolzugriff die Lücke ohne zusätzliche Trainingskosten geschlossen hätten. Fine-Tuning ist nur dann gerechtfertigt, wenn Prompting nachweislich an eine Grenze stößt.

• Prompting ändert sich pro Anfrage, Fine-Tuning ändert das Modell
• Prompting lässt sich in Sekunden rückgängig machen; ein feinabgestimmter Checkpoint ist ein festgelegtes Artefakt
• Beginnen Sie mit der kostengünstigen Option und gehen Sie nur auf Grundlage von Belegen weiter

Vergleichen Sie Ansätze anhand von drei unabhängigen Kostenachsen, nicht nur anhand von Geldbeträgen:

• Iterationskosten - Wie schnell können Sie das Verhalten ändern? Prompting: Minuten. Fine-Tuning: Stunden bis Tage pro Zyklus.
• Inferenzkosten - Beim Prompting zahlen Sie bei jedem Aufruf pro Token für lange Anweisungen und Beispiele; ein feinabgestimmtes Modell kann dieses Verhalten in die Gewichte integrieren und den Prompt verkleinern.
• Wartungskosten - Ein Prompt lebt in der Versionsverwaltung und ist auditierbar; ein Checkpoint muss jedes Mal erneut feinabgestimmt werden, wenn das Basismodell abgekündigt wird.

Prompting ist bei Iteration und Wartung überlegen; Fine-Tuning kann bei hohem Volumen die Inferenzkosten senken.

Das Argument für Fine-Tuning aufgrund der Inferenzkosten gilt nur oberhalb einer Volumenschwelle. Modellieren Sie den Umschlagpunkt explizit: Ein langes Few-Shot-Prompt, das pro Aufruf 2.000 Eingabetokens hinzufügt, verursacht laufende Kosten; ein getuntes Modell verteilt die Trainingskosten auf das Volumen.

Liegt Ihr Traffic unterhalb des Break-even-Punkts, ist das Few-Shot-Prompt eindeutig günstiger und flexibler.

Das stärkste Argument für Prompting ist die Handlungsfähigkeit unter Unsicherheit. Anforderungen ändern sich: ein neuer Grenzfall, eine Richtlinienänderung, ein neues Ausgabefeld. Mit Prompting passen Sie Text an; mit einem getunten Modell müssen Sie Daten neu erfassen und erneut trainieren.

Wenn sich die Aufgabendefinition noch verändert – in einer frühen Produktphase, bei einer unklaren Spezifikation oder häufigen Änderungen durch Stakeholder – ist Prompting fast immer die richtige Wahl. Fixieren Sie die Gewichte erst, wenn sich das Ziel nicht mehr verändert.

Viele Probleme, bei denen man meint, sie erforderten Tuning, lassen sich mit Techniken auf Prompt-Seite lösen:

• Formatbefolgung – strukturierte Ausgabe / JSON-Schema-Einschränkungen, nicht Training
• Domänenton – ein Block mit Stilbeispielen plus eine explizite Beschreibung der Stimme
• Reasoning-Tiefe – Zerlegung, Chain-of-Thought oder ein Planungsschritt
• Wissenslücken – Retrieval (RAG) liefert Fakten; Tuning backt veraltete Fakten ein

Greifen Sie nur für Dinge zu Tuning, die Prompting strukturell nicht leisten kann: latenzsensitive Prompt-Komprimierung, stark eigensinnige Formate oder Verhalten, gegen das sich das Modell trotz klarer Anweisungen sträubt.

Eine häufige Verwechslung: Teams führen Fine-Tuning durch, um Wissen einzubringen, obwohl sie es abrufen sollten. Fine-Tuning eignet sich schlecht zum Vermitteln von Fakten – es ist verlustbehaftet, teuer zu aktualisieren und neigt zu halluzinierten Interpolationen zwischen Trainingsbeispielen.

Faustregel: Wenn die Lücke darin besteht, was das Modell weiß, verwenden Sie Retrieval. Wenn die Lücke darin besteht, wie sich das Modell verhält, ziehen Sie Tuning in Betracht. Wissen ändert sich täglich; Verhalten ändert sich selten.

Bevor Sie Prompting für unzureichend erklären, durchlaufen Sie die vollständige Leiter. Die meisten Teams geben bei Stufe zwei auf:

• Stufe 1: klare Anweisung + Rolle + expliziter Ausgabevertrag
• Stufe 2: Few-Shot-Beispiele, die Grenzfälle abdecken
• Stufe 3: Zerlegung in mehrere verkettete Aufrufe
• Stufe 4: Tool-Nutzung / Retrieval, um Wissen und Berechnungen auszulagern
• Stufe 5: Selbstkritik- oder Verifier-Durchläufe

Erst wenn Sie die Stufen 1–5 mit einem separaten Evaluationsset ausgeschöpft haben, wird Fine-Tuning vertretbar.

Lange Prompts kosten mehr als Geld – sie kosten Zeit. Eingabetokens bestimmen in vielen Serving-Stacks maßgeblich die Zeit bis zum ersten Token. Ein Prompt aus 4.000 Tokens mit Anweisungen und Beispielen verursacht pro Aufruf einen messbaren Latenzaufwand.

Hier verliert Prompting bei großem Maßstab tatsächlich: Wenn Sie sowohl das Verhalten eines langen Prompts als auch Antworten in unter 100 ms benötigen, ist es richtig, dieses Verhalten in ein kleines getuntes Modell zu destillieren. Bestätigen Sie jedoch, dass das Latenzbudget tatsächlich gilt und nicht nur angenommen wird.

Entscheiden Sie anhand der Gesamtkosten über die Lebensdauer des Artefakts, nicht anhand der ersten Rechnung. Ein getunter Checkpoint bringt versteckte laufende Kosten mit sich:

• Erneutes Tuning, wenn der Anbieter das Basismodell abkündigt (oft alle 6–12 Monate)
• Eine Datenpipeline und einen Labeling-Prozess, die Sie dauerhaft betreiben müssen
• Evaluationsinfrastruktur, um nach jedem erneuten Tuning Regressionen zu erkennen
• Komplexität durch Versionierung, Rollback und A/B-Serving

Die Gesamtbetriebskosten von Prompting bestehen größtenteils aus einer Textdatei und einem Evaluationsset. Für Teams ohne MLOps-Reife hält diese Asymmetrie Prompting allein oft viel länger vorn als erwartet.

Prompting reicht aus, wenn Sie die meisten dieser Fragen mit JA beantworten können:

• Ändert sich die Aufgabenspezifikation noch von Monat zu Monat?
• Liegt das Volumen unterhalb Ihrer berechneten Break-even-Schwelle?
• Geht es um Wissen, das sich abrufen lässt, und nicht um Verhalten?
• Zeigt eine separate Evaluation, dass Prompting nach dem Durchlaufen der Leiter eine akzeptable Qualität erreicht?
• Ist Ihr Latenzbudget mit der Prompt-Länge vereinbar?
• Fehlt Ihrem Team eine dauerhaft gepflegte Pipeline für Tuning und Evaluation?

Drei oder mehr JA-Antworten bedeuten: Bleiben Sie beim Prompting und prüfen Sie die Entscheidung erst erneut, wenn sich die Antworten ändern.

Bilden Sie die Entscheidung als Daten ab, nicht nach Gefühl. Eine kleine Bewertungsfunktion zwingt das Team, Annahmen zu Volumen, Latenz und Stabilität der Spezifikation explizit zu formulieren, und macht die Empfehlung später nachvollziehbar.

Ein Team möchte, dass das Modell Fragen zu Dokumenten beantwortet, die täglich aktualisiert werden. Welcher Ansatz ist am geeignetsten und warum?

Prompting ist der Standard; Fine-Tuning ist die Eskalationsstufe. Bleiben Sie beim Prompting, solange sich die Spezifikation verändert, das Volumen unterhalb des Break-even-Punkts liegt und die Lücke Wissen statt Verhalten betrifft.

• Vergleichen Sie Iterations-, Inferenz- und Wartungskosten – nicht nur die Ausgaben
• Berechnen Sie den Volumen-Break-even, bevor Sie annehmen, dass Tuning Geld spart
• Durchlaufen Sie die vollständige Prompt-Optimierungsleiter, bevor Sie Prompting für unzureichend erklären
• Rufen Sie Wissen per Retrieval ab; reservieren Sie Tuning für hartnäckiges Verhalten oder latenzbedingte Prompt-Komprimierung
• Bewerten Sie die Gesamtbetriebskosten über die Lebensdauer, einschließlich der Abkündigung des Basismodells