
Große Sprachmodelle nehmen immer mehr Fahrt auf#
ChatGPT, Gemini, Claude und Co. sind in aller Munde. Große Sprachmodelle (Large Language Models, kurz LLMs), die mit natürlicher Sprache arbeiten, erobern die Welt im Sturm. Das ist wenig überraschend: Lange Zeit galt es als undenkbar, mit einem Computer so selbstverständlich in natürlicher Sprache zu kommunizieren, wie wir es mit anderen Menschen tun.
Heute ist genau das Realität. LLMs können nicht nur Gespräche führen, sondern auch als praktische Assistenten eingesetzt werden. Sie schreiben E-Mails, fassen Texte zusammen, erklären komplexe Sachverhalte, unterstützen bei der Recherche oder helfen beim Programmieren.
Damit diese Modelle jedoch genau das tun, was wir von ihnen erwarten, müssen wir ihnen klare und präzise Anweisungen geben. Diese Anweisungen nennt man Prompts. Die Kunst, solche Eingaben so zu formulieren, dass das Modell möglichst hilfreiche, korrekte und relevante Antworten liefert, wird als Prompt Engineering bezeichnet.
Prompt Engineering ist damit eine zentrale Schnittstelle zwischen Mensch und KI: Es entscheidet maßgeblich darüber, wie effektiv und zuverlässig große Sprachmodelle in der Praxis eingesetzt werden können.
Dieser Artikel soll weniger neue Techniken einführen, als dabei helfen, die gewachsene Komplexität rund um Prompt Engineering einzuordnen und auf das Wesentliche zu reduzieren.
Prompt Engineering#
Es gibt zahlreiche Techniken, um einen möglichst wirkungsvollen oder „perfekten“ Prompt zu formulieren. Ziel ist es dabei, das Sprachmodell so klar und eindeutig anzuleiten, dass es die gewünschte Aufgabe zuverlässig und in hoher Qualität ausführt.
Viele dieser Techniken lassen sich unter dem Begriff Prompt Frameworks zusammenfassen. Dabei handelt es sich um strukturierte Gerüste oder Vorlagen, nach denen ein Prompt aufgebaut wird. Solche Frameworks helfen dabei, alle relevanten Informationen systematisch zu berücksichtigen – etwa Kontext, Ziel, Rolle des Modells, gewünschtes Ausgabeformat oder Einschränkungen.
Je nach Anwendungsfall entscheidet man sich entweder für ein spezifisches Prompt-Framework oder arbeitet konsequent mit einem bestimmten Ansatz.
Die dargestellten Prompt-Techniken und Frameworks sind heute weit verbreitet und teilweise wissenschaftlich untersucht, stellen jedoch keine formalen oder normierten Standards dar.
Auswahl gängiger (klassischer) Prompt-Frameworks#
| # | Framework | Akronym (Auflösung) |
|---|---|---|
| 1 | RACE | Role – Action – Context – Example |
| 2 | CREST | Context – Role – Examples – Style – Task |
| 3 | P.R.O.M.P.T. | Persona – Role – Output – Mode – Process – Task |
| 4 | CARE | Context – Action – Result – Example |
| 5 | IDEA | Intent – Details – Expectation – Asset |
| 6 | CREI | Context – References – Evaluate & Iterate – Input |
Für viele Anwendungsfälle haben sich zusätzlich sogenannte Prompt Patterns etabliert. Dabei handelt es sich um bewährte Best Practices für typische Aufgabenstellungen im Umgang mit großen Sprachmodellen. Von diesen Prompt Patterns gibt es Dutzende, die für ganz unterschiedliche Zwecke eingesetzt werden können.
Auswahl gängiger (klassischer) Prompt Patterns#
| # | Prompt-Pattern | Kurzbeschreibung |
|---|---|---|
| 1 | Zero-Shot Prompting | Aufgabe ohne Beispiele |
| 2 | Few-Shot Prompting | 1–3 Beispiele als Orientierung |
| 3 | Chain-of-Thought (CoT) | Schritt-für-Schritt-Denken |
| 4 | Role / Persona Prompting | Antwort aus einer definierten Rolle |
| 5 | Instruction Prompting | Klare, explizite Anweisung |
| 6 | Iterative / Feedback Prompting | Iterative Verbesserung |
Vom Prompt Engineering zur natürlichen Interaktion#
Ein zentrales Thema im Prompt Engineering ist die Komplexität. Diese entstand unter anderem dadurch, dass frühere Modelle – etwa aus der Generation um GPT-3 – noch deutlich eingeschränkter waren als heutige große Sprachmodelle. Um brauchbare und reproduzierbare Ergebnisse zu erzielen, mussten sie stark geführt werden. Prompt-Frameworks und Prompt Patterns dienten dabei als Hilfsmittel, um fehlende Fähigkeiten der Modelle auszugleichen. In diesem Kontext etablierte sich auch der Begriff Prompt Engineering.
Aktuelle LLMs sind inzwischen deutlich weiterentwickelt. Sie verfügen über ein besseres Sprachverständnis, stabileren Kontextbezug und eine höhere Fähigkeit, implizite Anforderungen zu erkennen. Dadurch benötigen sie in vielen Fällen keine so konsequenten, streng strukturierten Prompts mehr, um gute Ergebnisse zu liefern.
Warum klassisches Prompt Engineering neu gedacht werden muss#
In der Folge hat sich auch das Prompting verändert. Einige Frameworks und Patterns funktionieren weiterhin gut, vor allem bei komplexen oder wiederkehrenden Aufgaben. Andere haben heute kaum noch Wirkung oder können sogar nachteilig sein, wenn sie das Modell unnötig einschränken oder verwirren.
Der Grund dafür liegt weniger im Prompt selbst als in der Entwicklung der Modelle: Moderne LLMs sind stärker instruction-getuned, bringen mehr implizite Struktur mit und werden durch System- und Safety-Prompts vorgeprägt. Dadurch verlieren explizite Denk- oder Rollenpatterns an Wirkung, während Klarheit, Kontext und saubere Aufgabenbeschreibung wichtiger werden.
Zu diesem Thema gibt es inzwischen auch Forschung, die die Wirksamkeit klassischer Prompt-Techniken systematisch untersucht – teils mit überraschenden Ergebnissen.
Starre Prompts funktionieren nicht (mehr)
Ein einmal formulierter, starrer Prompt liefert nicht immer konsistente Ergebnisse. Je nach gesamtem Kontext – etwa vorherigem Gesprächsverlauf oder Aufgabenstellung – kann derselbe Prompt unterschiedliche Wirkungen zeigen.Automatisches Reasoning moderner LLMs
Moderne LLMs führen häufig bereits implizites logisches Schlussfolgern durch. Für viele alltägliche Aufgaben müssen Techniken wie Chain-of-Thought daher nicht mehr explizit angefordert werden. Bei komplexen logischen, mathematischen oder mehrstufigen Aufgaben kann eine explizite Strukturierung der Zwischenschritte jedoch weiterhin hilfreich sein.Rollen- und Persona-Prompting
In vielen Frameworks und offiziellen Beispielen der Modellhersteller finden sich Formulierungen wie „Du bist ein Physikprofessor“ oder „Du bist ein Marketingexperte“. Ziel war es, das Modell auf eine bestimmte Domäne zu fokussieren. Untersuchungen zeigen jedoch, dass Rollen- oder Persona-Prompting für fachliche Korrektheit häufig unnötig ist und in manchen Fällen sogar schlechtere Ergebnisse liefern kann, etwa wenn das Modell durch eine künstliche Autoritätsrolle verwirrt wird. Für Stil, Perspektive oder Simulationen kann Persona-Prompting jedoch weiterhin sinnvoll sein.Viele Beispiele sind nicht immer hilfreich
Oft wird empfohlen, dem Modell möglichst viele Beispiele zu geben, um die gewünschte Richtung vorzugeben. Bei heutigen Modellen ist das jedoch nicht mehr zwingend erforderlich, da sie viele Aufgaben bereits ohne Beispiele zuverlässig lösen können.
Beispiele können aber weiterhin sinnvoll sein, etwa bei ungewöhnlichen Ausgabeformaten, zur Abgrenzung unerwünschter Ergebnisse oder bei sehr spezifischen Randfällen. Gleichzeitig gilt: Schlechte, unklare oder widersprüchliche Beispiele können die Ausgabe deutlich verschlechtern und das Modell eher verwirren als unterstützen.
Diese Beobachtungen werden durch aktuelle Untersuchungen gestützt (siehe Prompting Science Reports).
Trotzdem sind klassische Prompt-Patterns nicht grundsätzlich obsolet. Sie bleiben hilfreich in klar abgegrenzten Fällen, etwa bei mathematischem oder symbolischem Reasoning, formalen Beweisen, stark eingeschränkten Ausgabeformaten oder didaktischen Erklärungen. In solchen Szenarien kann zusätzliche Struktur helfen, den Lösungsraum einzugrenzen – außerhalb davon führt sie jedoch oft eher zu unnötiger Komplexität als zu besseren Ergebnissen.
Wie sollte heute gepromptet werden?#
Ein sinnvoller Ausgangspunkt sind die offiziellen Prompting-Dokumentationen der Modellhersteller wie OpenAI, Google oder Anthropic. Diese Richtlinien spiegeln in der Regel den aktuellen Entwicklungsstand der jeweiligen Modelle wider und geben konkrete Empfehlungen, wie Prompts formuliert werden sollten. Hersteller-Guides sind dabei eine hilfreiche Orientierung, ersetzen jedoch nicht das eigene Testen und Anpassen an den konkreten Anwendungsfall.
Dabei zeigt sich jedoch ein zentrales Problem: Prompts verhalten sich je nach Plattform unterschiedlich. Ein Prompt, der bei einem Modell gut funktioniert, kann bei einem anderen deutlich schlechtere Ergebnisse liefern. Darüber hinaus reagieren selbst verschiedene Versionen derselben Modellreihe unterschiedlich auf identische Eingaben.
Einige Hersteller – etwa OpenAI – veröffentlichen deshalb für neue Modelle oder Modellgenerationen jeweils eigene Prompting-Best-Practices. Prompting ist damit kein einmal gelöstes Problem, sondern ein fortlaufender Anpassungsprozess, der sich an den Fähigkeiten und Eigenheiten der jeweils eingesetzten Modelle orientieren muss.
Warum All-in-One- und „Super-Prompts“ selten gut funktionieren#
Oft ist von sogenannten Super-Prompts die Rede – also Prompts, die bestimmte Probleme scheinbar standardisiert und universell lösen sollen. In der Praxis erweisen sich solche Ansätze jedoch als wenig belastbar, da sich Modelle, Versionen, Kontexte und Aufgabenstellungen zu stark unterscheiden.
All-in-One-Prompts versuchen entsprechend, in einer einzigen Anfrage möglichst viele Aufgaben gleichzeitig zu lösen – etwa Analyse, Ideengenerierung, Bewertung, Kritik, Iteration und Formatierung. Diese Überladung führt jedoch häufig zu widersprüchlichen Anforderungen, unklaren Prioritäten und schwer nachvollziehbaren Ergebnissen.
Statt Klarheit zu schaffen, vermischen solche Prompts unterschiedliche Ebenen: die eigentliche Aufgabe, den Prozess der Verbesserung und teilweise sogar systemische Erwartungen an das Modell. Das erschwert nicht nur die Steuerung des Outputs, sondern auch das Verständnis dafür, warum ein Ergebnis gut oder schlecht ausgefallen ist.
Einfachere, klar abgegrenzte Prompts, die in einen expliziten Prozess eingebettet sind, erweisen sich daher in der Regel als robuster, leichter zu korrigieren und besser reproduzierbar als ein einzelner, maximal komplexer Prompt.
Anfrage so genau wie nötig formulieren#
Wichtig ist, dem LLM möglichst klar und präzise zu sagen, was man möchte. Dazu gehört zu beschreiben, welches Ergebnis erwartet wird, welche Zielgruppe angesprochen werden soll, welche Punkte eingehalten werden müssen und was ausdrücklich vermieden werden soll. Auch die gewünschte Form der Ausgabe sollte – wenn relevant – klar benannt werden.
Ebenso wichtig ist – sofern vorhanden – ausreichend Kontext, damit das Modell die Aufgabe richtig einordnen kann. Dabei gilt jedoch: so viel Kontext wie nötig, aber nicht mehr als sinnvoll. Ziel ist Klarheit, nicht Überfrachtung.
Prompt, Prozess und System – drei unterschiedliche Ebenen#
Ein häufiger Fehler im Prompt Engineering ist, zu viele Aufgaben in einen einzelnen Prompt zu verlagern. Dabei lohnt es sich, drei Ebenen klar zu trennen: den Prompt selbst, den umgebenden Prozess und das System, in dem ein Modell eingesetzt wird.
Der Prompt dient der klaren Formulierung einer konkreten Aufgabe: Was soll jetzt getan werden, in welchem Kontext und mit welchem erwarteten Ergebnis. Dinge wie Vergleich mehrerer Antworten, iterative Verbesserung, Validierung oder Abbruchlogik gehören hingegen in den Prozess und nicht in den Prompt.
Systemische Aspekte wie Tool-Nutzung, Speicher von Kontext, Sicherheitsregeln oder Modellkonfigurationen liegen wiederum außerhalb des Prompts und lassen sich durch diesen nur begrenzt steuern. Je klarer diese Ebenen getrennt werden, desto einfacher, robuster und besser nachvollziehbar wird die Interaktion mit dem Modell.
das TACOS Framework#
Aus diesen Beobachtungen hat sich für mich ein eigenes, pragmatisches Prompt-Framework entwickelt, das weniger durch Innovation als durch Stabilität und Alltagstauglichkeit geprägt ist.
TACOS ist kein festes Prompt-Template, sondern eine einfache Struktur, um zentrale Aspekte eines Prompts klar zu machen. Es garantiert keine guten Antworten, macht Ergebnisse aber verlässlicher.
TACOS: eine einfache Struktur für Prompts#
| Baustein | Beschreibung |
|---|---|
| TASK | Handlung und gewünschtes Ergebnis nach der Antwort |
| AUDIENCE | Zielgruppe, Vorwissen und Zweck (verstehen / entscheiden / umsetzen) |
| CONSTRAINTS | Regeln, Verbote und Fixpunkte (Scope, Umfangs-Limits, explizite Ausschlüsse) |
| OUTPUT | Ausgabetyp (Text, Liste, Tabelle, Code …) und gewünschte Struktur |
| SUCCESS CRITERIA | Objektive Kriterien, an denen ein gutes Ergebnis erkennbar ist |
| [EXAMPLES] | Positive und/oder negative Beispiele (Zero-Shot oft ausreichend) |
| [INPUT/CONTEXT] | Arbeitsmaterial und Hintergrundinformationen, kein Steuerinstrument |
↺ Refinement
Die Ausgabe wird iterativ durch Feedback und Folgeanweisungen verbessert. Refinement ist kein Prompt-Baustein, sondern ein nachgelagerter Prozess.
Einige Punkte dieses Frameworks unterscheiden sich bewusst von anderen gängigen Ansätzen:
TASK
Es ist meist hilfreich, nicht nur die auszuführende Handlung zu beschreiben, sondern auch klar zu formulieren, welches Ergebnis nach der Antwort vorliegen soll.AUDIENCE
Die genaue Beschreibung der Zielgruppe (Vorwissen, Zweck) führt oft zu besseren Ergebnissen als reine Vorgaben zur Tonalität oder zum Schreibstil.CONSTRAINTS
Einschränkungen sind entscheidend, um dem Modell klar zu machen, was es tun soll – und ebenso, was ausdrücklich nicht. Sie helfen, den Scope zu kontrollieren.OUTPUT
Durch eine explizite Definition des Ausgabeformats lässt sich steuern, wie das Ergebnis strukturiert und formatiert sein soll.SUCCESS CRITERIA
Klare Erfolgskriterien geben dem Modell einen Bewertungsmaßstab für die eigene Ausgabe und reduzieren Fehlinterpretationen.INPUT / CONTEXT
Der Kontext wird bewusst am Ende platziert und ist nur dann nötig, wenn konkretes Arbeitsmaterial vorliegt – etwa bei Zusammenfassungen, Analysen oder der Weiterverarbeitung bestehender Inhalte. Häufig wird empfohlen, Kontext an den Anfang zu stellen, doch in der Praxis ist das Material oft mehrere Seiten lang. Wird es zu früh präsentiert, kann es das Modell überfrachten oder den Fokus verwässern.EXAMPLES
Beispiele sind optional. Bei modernen LLMs sind sie in vielen Fällen nicht mehr so essenziell wie bei früheren Modellen und können bei schlechter Qualität sogar kontraproduktiv sein.
Ein einfaches Beispiel#
TASK:
Erstelle eine Schritt-für-Schritt-Anleitung zur Nutzung eines LLMs für das Schreiben von E-Mails.
AUDIENCE:
Office-Mitarbeitende mit Grundkenntnissen in KI-Tools, Ziel: direkt umsetzen.
CONSTRAINTS:
- Maximal 7 Schritte
- Jeder Schritt ein Satz
OUTPUT:
Nummerierte Liste.
SUCCESS CRITERIA:
Die Anleitung kann ohne weitere Rückfragen befolgt werden.
TACOS ist flexibel – nicht jeder Prompt braucht alles#
Wichtig ist: Das TACOS-Framework ist lediglich eine Basis und für einfache Prompts oft zu umfangreich. Es müssen nicht alle Parameter angegeben werden. Viele Chat-LLMs geben ihre Antworten standardmäßig in einem Markdown-ähnlichen Format aus. Reicht das aus, muss kein expliziter OUTPUT definiert werden.
In anderen Fällen sind bewusst kreative oder offene Ergebnisse gewünscht. Dann ist es sinnvoll, auf harte CONSTRAINTS zu verzichten, um das Modell nicht unnötig einzuschränken.
Auch die Reihenfolge der Parameter kann einen Einfluss auf das Ergebnis haben. Je nachdem, was zuerst genannt wird, setzt das Modell unterschiedliche Schwerpunkte.
Am wichtigsten ist daher: ausprobieren und iterieren.
Weitere hilfreiche Prompting-Prinzipien#
Iterieren und Verfeinern#
Bei interaktiven Prompts im Chat ist es oft sinnvoll, sich schrittweise an das gewünschte Ergebnis heranzutasten. Statt alles im ersten Prompt perfekt formulieren zu wollen, kann die Ausgabe durch gezielte Folgeanweisungen verfeinert werden, etwa durch „kürzer“, „präziser“, „mit Beispielen“ oder „anders strukturiert“.
Das Modell gezielt nachfragen lassen#
Manchmal fehlen dem Modell entscheidende Informationen, um eine gute Antwort zu liefern. In solchen Fällen kann man explizit angeben, dass Rückfragen erlaubt oder sogar erwünscht sind, zum Beispiel:
„Wenn etwas unklar ist, frage nach, bevor du antwortest.“
Besonders hilfreich ist das bei mehrdeutigen oder unvollständigen Aufgabenstellungen sowie bei komplexen Themen, bei denen leicht wichtige Details übersehen werden können. So lässt sich vermeiden, dass das Modell Annahmen trifft oder am eigentlichen Ziel vorbeiarbeitet.
Anschreien oder Betteln hilft nicht#
Emotionale Formulierungen wie Anschreien, Drängen oder Betteln („BITTE!!“, „DAS IST SEHR WICHTIG!!!“) haben keinen positiven Einfluss auf die Qualität der Ausgabe. In vielen Fällen wirken sie sich sogar negativ aus.
Was hingegen funktionieren kann, ist das gezielte Hervorheben wichtiger Begriffe, etwa durch Großschreibung oder klare Marker wie „WICHTIG:“ oder „BEVOR“. Das liegt daran, dass Modelle gelernt haben, solche Hervorhebungen als Signal für Priorität zu interpretieren. Aber vorsichtig anwenden.
Anweisungen auf Englisch verfassen#
Viele aktuelle Sprachmodelle sind multilingual und beherrschen mehrere Sprachen. Dennoch stammen große Teile der Trainingsdaten – insbesondere für technische, instruktionale und meta-sprachliche Inhalte – aus englischsprachigen Quellen.
In der Praxis kann es daher von Vorteil sein, Anweisungen oder Steuerlogik auf Englisch zu formulieren, selbst wenn die gewünschte Ausgabe in einer anderen Sprache (z. B. Deutsch) erfolgen soll. Englische Instruktionen werden von vielen Modellen oft präziser und konsistenter interpretiert, insbesondere bei komplexen Aufgaben, Regeln oder Constraints.
Für einfache oder sprachlich sensible Aufgaben ist die Verwendung der Zielsprache jedoch oft ausreichend oder sogar vorzuziehen.
Strukturierte Prompts und Ausgabeformate#
Auch wenn Prompts problemlos in freier Prosa formuliert werden können, profitieren insbesondere kleinere oder weniger leistungsfähige Modelle von klar strukturierten Angaben. Strukturierte Prompts – etwa durch Listen, Überschriften, Markdown oder formale Formate wie JSON oder XML – reduzieren Interpretationsspielräume und erleichtern dem Modell, den Anforderungen zu folgen.
Auch die Ausgabe lässt sich gezielt strukturieren. Das ist vor allem dann sinnvoll, wenn die Ergebnisse weiterverarbeitet werden sollen, etwa über APIs oder in automatisierten Workflows. In solchen Fällen sind klar definierte Formate wie strukturiertes Markdown, JSON oder XML häufig robuster und zuverlässiger als frei formulierter Text.
Für kreative oder offene Aufgaben kann hingegen bewusst auf strikte Struktur verzichtet werden.
Prompts für APIs#
Im Gegensatz zu interaktiven Chat-Prompts, die schrittweise verfeinert werden können, müssen Prompts für API-Aufrufe in der Regel „auf Anhieb“ funktionieren. Eine direkte Rückkopplung oder iteratives Nachschärfen ist hier oft nicht oder nur eingeschränkt möglich.
Entsprechend wichtig sind klar strukturierte Eingaben, eindeutige Anforderungen und ein definiertes Ausgabeformat. Besonders bei automatisierter Weiterverarbeitung kommt es auf konsistente, maschinenlesbare Outputs an.
In der Praxis wird daher häufig mit automatisierter Prompt-Optimierung gearbeitet, etwa durch systematisches Testen, Variationen des Prompts oder Feedback-Schleifen in Code, um für einen bestimmten Anwendungsfall robuste One-Shot-Prompts zu entwickeln.
API-Prompts müssen daher robuster und defensiver formuliert sein als interaktive Chat-Prompts.
Halluzinationen#
Ein großes und häufig diskutiertes Thema bei großen Sprachmodellen sind sogenannte Halluzinationen. Darunter versteht man Ausgaben, die inhaltlich nicht korrekt sind – etwa falsche Zahlen, erfundene Fakten oder nicht existente Zusammenhänge.
Die Ursache liegt in der Funktionsweise von LLMs: Sie sind darauf trainiert, stets die statistisch wahrscheinlichste nächste Ausgabe zu erzeugen. Fehlt relevantes Wissen oder ist der Kontext unklar, liefern sie in der Regel dennoch eine Antwort. Diese kann sprachlich plausibel wirken, ist aber faktisch falsch. Ein gewisser Grad dieser „kreativen“ Ergänzung ist systembedingt und wird sich nie vollständig vermeiden lassen.
Halluzinationen sind kein bewusstes „Erfinden“, sondern ein Nebenprodukt wahrscheinlichkeitsbasierter Textgenerierung bei unzureichender oder unsicherer Informationslage.
Problematisch ist dabei: Das Modell weiß nicht, dass es halluziniert. Reine Anweisungen im Prompt wie „keine Halluzinationen“ oder „antworte nur korrekt“ haben daher keine verlässliche Wirkung.
Besondere Vorsicht ist bei Zahlen geboten. LLMs sind keine Rechenmaschinen, sondern arbeiten mit Vektorräumen und wahrscheinlichkeitsbasierten Mustern. Zahlen und exakte Werte sind darin nicht symbolisch eindeutig repräsentiert, weshalb sie besonders fehleranfällig sind.
Maßnahmen zur Reduktion von Halluzinationen#
Ausreichenden und konsistenten Kontext liefern
Halluzinationen entstehen häufig durch zu wenig, ungenauen oder widersprüchlichen Kontext. In solchen Fällen beginnt das Modell zu raten.
Abhilfe: Genügend relevanten und klaren Kontext bereitstellen.Kreativität begrenzen
Eine zu hohe Kreativität erhöht die Wahrscheinlichkeit für erfundene Inhalte.
Abhilfe: Parameter wie Temperatur oder Top-p senken, um die Ausgabe stärker auf wahrscheinliche Antworten zu begrenzen. Gilt insbesondere für faktische oder sicherheitskritische Aufgaben.Trainings-Cutoff berücksichtigen
Der Wissensstand eines LLMs ist auf einen bestimmten Zeitpunkt begrenzt. Zu aktuellen Ereignissen oder neuen Daten kann das Modell keine verlässlichen Aussagen treffen und beginnt zu halluzinieren.
Abhilfe: Trainings-Cutoff berücksichtigen und aktuelle Informationen über RAG oder Tool-Calling (z. B. Webzugriff) bereitstellen.Keine unrealistisch harten Constraints setzen
Zu strenge Vorgaben können das Modell dazu zwingen, Inhalte zu erfinden, etwa: „Nenne 10 Punkte“, obwohl realistisch weniger existieren.
Abhilfe: Constraints realistisch und flexibel formulieren.Externe, geprüfte Daten einbinden
Trainingsdaten können unvollständig, unscharf oder widersprüchlich sein.
Abhilfe: Techniken wie Retrieval Augmented Generation (RAG) nutzen, um geprüfte und relevante Informationen bereitzustellen.Referenzen über Tools oder RAG erzwingen
Ein Modell weiß nicht, woher einzelne Fakten stammen – Wissen ist verteilt im Modell repräsentiert und nicht zitierfähig.
Abhilfe: Tool-Calling (z. B. Webzugriff, Datenbanken) oder Retrieval Augmented Generation (RAG) einsetzen, um auf konkrete, überprüfbare Quellen zuzugreifen und diese referenzieren zu können.Ausgaben durch andere Modelle prüfen lassen
Eine zweite Modellmeinung kann helfen, Fehler zu erkennen.
Einschränkung: Diese Methode ist unsicher, da andere Modelle ähnliche Wissenslücken haben können. Kann unterstützen, ersetzt jedoch keine externe, verlässliche Quelle.Externe Validierung durchführen
Kritische Inhalte sollten zusätzlich überprüft werden, etwa durch einen AI-Agenten oder Workflow, der Aussagen mit verlässlichen Quellen (z. B. Enzyklopädien oder Fachdatenbanken) abgleicht.Unsicherheit explizit erlauben
Eine sehr wirkungsvolle Maßnahme zur Reduktion von Halluzinationen ist es, dem Modell ausdrücklich zu erlauben, Unsicherheit zu äußern oder „Ich weiß es nicht“ zu sagen. Ohne diese Erlaubnis versucht das Modell häufig, dennoch eine plausible Antwort zu erzeugen.Antwortlänge begrenzen
Mit zunehmender Antwortlänge steigt die Wahrscheinlichkeit für Fehler und Halluzinationen, da sich kleine Ungenauigkeiten im Verlauf der Textgenerierung verstärken können.
Abhilfe: Komplexe Inhalte in mehrere, kürzere Schritte aufteilen und bei Bedarf iterativ erweitern.
Anbieter bemühen sich um Reduktion von Halluzinationen#
Anbieter großer Sprachmodelle arbeiten kontinuierlich daran, Halluzinationen zu reduzieren. Dazu gehören Verbesserungen am Modelltraining, feinere Abstimmungen durch menschliches Feedback sowie technische Maßnahmen wie bessere Sicherheitsmechanismen, Tool-Integration und kontrollierte Datenzugriffe.
Die Halluzinationsrate variiert dabei stark je nach Aufgabentyp und Domäne.
Bei neueren Modellgenerationen ist bereits zu beobachten, dass Halluzinationen seltener auftreten als bei früheren Versionen. Vollständig vermeiden lassen sie sich jedoch nicht, da das zugrunde liegende Funktionsprinzip wahrscheinlichkeitsbasiert bleibt. Die Verantwortung für kritische Anwendungen liegt daher weiterhin in der Kombination aus Modell, Prompting, Kontextbereitstellung und externer Validierung.
Sycophancy#
Sycophancy kann man als eine Art „kleine Schwester“ der Halluzination betrachten. Der Begriff beschreibt die Tendenz von Sprachmodellen, dem Nutzer gefällig zu sein und Antworten zu liefern, die Zustimmung signalisieren oder Erwartungen erfüllen – selbst dann, wenn diese inhaltlich falsch sind.
Dieses Verhalten ist eine Folge des Trainings: In vielen Trainings- und Feedbackprozessen wurden für Menschen „angenehme“ oder zustimmende Antworten positiv bewertet. Dadurch lernen Modelle implizit, dass Widerspruch unhöflich oder unerwünscht sein kann. In der Konsequenz vermeiden sie Korrekturen und bestätigen mitunter sogar falsche Annahmen der Nutzer.
Im Extremfall führt Sycophancy dazu, dass ein Modell eine offensichtlich falsche Annahme nicht hinterfragt, sondern sie aktiv stützt oder weiter ausbaut.
Hersteller minimieren Sycophancy#
Die großen Anbieter von Sprachmodellen sind sich des Problems der Sycophancy bewusst und arbeiten aktiv daran, dieses Verhalten zu reduzieren. Durch gezieltes Training, Alignment-Verfahren und spezielle Evaluationsszenarien werden Modelle darauf optimiert, falschen Annahmen zu widersprechen und Korrektheit höher zu gewichten als bloße Zustimmung.
Neuere Modellgenerationen zeigen dadurch insgesamt weniger gefälliges Verhalten als frühere. Vollständig vermeiden lässt sich Sycophancy jedoch nicht, da Sprachmodelle weiterhin auf Kooperation und Hilfsbereitschaft optimiert sind und ihr Verhalten stark vom jeweiligen Prompt abhängt.
Abhilfe im Prompt#
Sycophancy lässt sich durch gezielte Anweisungen im Prompt deutlich reduzieren. Hilfreich sind explizite Aufforderungen zur Kritik oder zum Widerspruch, zum Beispiel:
- „Sag mir schonungslos deine Meinung zu meinem Input.“
- „Weise mich ausdrücklich darauf hin, wenn meine Annahmen falsch sind.“
- „Priorisiere Korrektheit über Zustimmung.“
Solche Formulierungen signalisieren dem Modell, dass kritisches Denken erwünscht ist, und verringern die Wahrscheinlichkeit gefälliger, aber falscher Antworten.
Bias#
Neben Halluzinationen und Sycophancy zeigen Sprachmodelle auch systematische Verzerrungen (Bias). Diese entstehen durch unausgewogene Trainingsdaten, gesellschaftliche Vorannahmen oder implizite Wertungen im Feedbackprozess. Bias äußert sich nicht als falsche Fakten, sondern als einseitige Perspektiven, Gewichtungen oder Bewertungen.
Prompts können Bias sichtbar machen oder abschwächen, aber nicht vollständig eliminieren. Besonders bei sensiblen Themen ist daher kritische Prüfung und externe Einordnung notwendig.
Abhilfe bei Bias#
Bias lässt sich durch Prompting nicht vollständig vermeiden. Dennoch gibt es Maßnahmen, um Verzerrungen sichtbar zu machen oder ihre Wirkung zu reduzieren.
Bei sensiblen Themen sollte zudem klar gemacht werden, aus welcher Perspektive geantwortet werden soll – oder dass verschiedene Sichtweisen gleichberechtigt dargestellt werden sollen. Für kritische Anwendungen bleibt externe Prüfung und menschliche Einordnung unverzichtbar.
Hilfreiche Anweisungen können etwa sein: „Trenne Fakten von Meinungen oder Wertungen.“
Overconfidence / False Certainty#
Ein weiteres häufiges Problem bei Sprachmodellen ist scheinbare Sicherheit. Auch wenn Informationen unsicher, unvollständig oder nur grob approximiert sind, werden Antworten oft sehr selbstbewusst formuliert. Diese sprachliche Sicherheit darf nicht mit faktischer Verlässlichkeit verwechselt werden.
Overconfidence entsteht nicht aus „Überzeugung“, sondern aus der Trainingslogik der Modelle: Klare, flüssige und entschlossene Formulierungen wurden im Training häufig positiv bewertet. Das Modell lernt daher, Unsicherheiten sprachlich zu glätten, selbst wenn inhaltlich Zweifel angebracht wären.
Abhilfe bei Overconfidence#
Hilfreich ist es, Unsicherheit explizit zuzulassen und das Modell aufzufordern, Annahmen, Wissenslücken oder alternative Interpretationen offenzulegen. Auch die gezielte Nachfrage nach Grenzen, Unsicherheiten oder offenen Punkten kann helfen, übermäßig selbstsichere Antworten zu relativieren.
Fazit#
Prompt Engineering ist kein starres Regelwerk, sondern eine praktische Fähigkeit, die sich mit den Fähigkeiten der Modelle weiterentwickelt. Während frühe Sprachmodelle stark geführt werden mussten, erlauben moderne LLMs eine deutlich natürlichere Interaktion. Struktur, Klarheit und Kontext bleiben jedoch entscheidend für zuverlässige Ergebnisse.
Frameworks, Patterns und Techniken sind dabei Werkzeuge – keine Garantien. Ihr Nutzen hängt vom Anwendungsfall, vom Modell und vom gewünschten Ergebnis ab. Besonders wichtig ist es, Prompts iterativ zu verfeinern, Annahmen zu hinterfragen und kritische Ausgaben zu validieren.
Wer versteht, wie und warum Sprachmodelle scheitern können – etwa durch Halluzinationen oder Sycophancy – kann sie gezielter, sicherer und verantwortungsvoller einsetzen. Gutes Prompting bedeutet daher weniger, perfekte Prompts zu schreiben, sondern die richtigen Fragen zu stellen und die Grenzen der Modelle bewusst zu berücksichtigen.
Weiterführende Links zu Prompting#
Prompting-Guides der Hersteller#
OpenAI – Prompt Engineering
- Best Practices for Prompt Engineering with the OpenAI API
https://help.openai.com/en/articles/6654000-best-practices-for-prompt-engineering-with-the-openai-api - Prompt Engineering Overview (OpenAI API Docs)
https://platform.openai.com/docs/guides/prompt-engineering - Prompt Engineering Best Practices für ChatGPT
https://help.openai.com/en/articles/10032626-prompt-engineering-best-practices-for-chatgpt
- Best Practices for Prompt Engineering with the OpenAI API
Google Gemini – Prompt Design Strategies
Prompt Design Strategies (offizielle Gemini API Dokumentation)
https://ai.google.dev/gemini-api/docs/prompting-strategiesAnthropic – Claude Prompt Engineering
Claude Prompt Engineering Best Practices (Anthropic Docs)
https://docs.claude.com/en/docs/build-with-claude/prompt-engineering/claude-4-best-practices
Prompting-Science-Reports (Ethan Mollick & Team)#
Eine Reihe experimenteller Prompting-Studien (u. a. von Ethan Mollick und Team) untersucht systematisch, welche klassischen Prompt-Techniken heute noch wie wirksam sind.
Prompting Science Report 1
https://arxiv.org/abs/2503.04818Prompting Science Report 2
https://arxiv.org/abs/2506.07142Prompting Science Report 3
https://arxiv.org/abs/2508.00614Prompting Science Report 4
https://arxiv.org/abs/2512.05858
Was die Forschung zu Prompt Engineering zeigt#
A Prompt Pattern Catalog to Enhance Prompt Engineering with ChatGPT
https://arxiv.org/abs/2302.11382The Prompt Report: A Systematic Survey of Prompt Engineering Techniques
https://arxiv.org/abs/2406.06608A Systematic Survey of Prompt Engineering in Large Language Models: Techniques and Applications
https://arxiv.org/abs/2402.07927A Taxonomy of Prompt Defects in LLM Systems
https://arxiv.org/abs/2509.14404Prompt Engineering and the Effectiveness of Large Language Models in Enhancing Human Productivity
https://arxiv.org/abs/2507.18638
© 2025 Oskar Kohler. Alle Rechte vorbehalten.Hinweis: Der Text wurde manuell vom Autor verfasst. Stilistische Optimierungen, Übersetzungen sowie einzelne Tabellen, Diagramme und Abbildungen wurden mit Unterstützung von KI-Tools vorgenommen.