Inhalt
1. Einleitung: Wenn KI überzeugend lügt
Warum Large Language Models (LLMs) mit Selbstbewusstsein antworten – selbst wenn sie danebenliegen
Vielleicht kennst du das: Du stellst ChatGPT oder Claude eine Frage und bekommst eine Antwort, die absolut plausibel und überzeugend wirkt – aber komplett daneben ist. Woran liegt das? Ganz einfach: KI-Modelle antworten nicht mit Wissen, sondern mit Statistik. Sie überlegen nicht, was wirklich stimmt, sondern welches Wort statistisch am besten zu deinem vorherigen Satz passt.
Dabei verstehen diese Modelle nicht wirklich, worüber sie reden. Sie rechnen nicht, denken nicht nach und checken keine Fakten. Stattdessen produzieren sie sprachlich passende Antworten, auch wenn die Informationen falsch, alt oder gar nicht vorhanden sind.
Je unklarer oder schwammiger deine Anfrage ist, desto wahrscheinlicher fängt die KI an zu „halluzinieren“ – also Dinge zu erfinden, die zwar gut klingen, aber faktisch nicht stimmen. Diese Halluzinationen sind keine Ausnahme, sondern entstehen direkt durch das Grunddesign dieser Systeme.
Das Gute daran: Sobald du verstehst, warum KI halluziniert, kannst du gezielt dagegen vorgehen – mit besseren Prompts und klarerem Kontext.
Reale Beispiele für Halluzinationen mit teils gravierenden Folgen
Wenn KI halluziniert, bleibt es nicht bei kleinen Fehlern. Hier ein paar echte Beispiele, die zeigen, wie problematisch es werden kann:
Mathe? Besser nicht. Stell eine komplexe Rechenaufgabe wie „3.695 × 123.548“ – die Antwort klingt selbstsicher, ist aber oft falsch. Das Modell rät mit Zahlen, statt zu rechnen.
Zebras sehen, wo keine sind. ChatGPT meinte, Zebras auf einem Bild erkannt zu haben – obwohl es gar keine Bilder analysieren kann. Klingt verrückt, passiert aber.
Objekte aus dem Nichts. DALL·E 3 sollte einen leeren Raum generieren – und platzierte trotzdem einen Tisch mitten rein. Warum? Weil Sprache manchmal falsche Erwartungen weckt, die das Modell blind erfüllt.
Alte Vorurteile neu verpackt. Wenn im Trainingsmaterial Stereotype stecken, kann die KI sie unbewusst weitergeben – ohne Einordnung oder Korrektur.
Und im Ernstfall? In der Medizin, im Recht oder in der Forschung kann eine falsche Information schnell zum echten Risiko werden – wenn Nutzer:innen sich blind auf die KI verlassen.
Deshalb gilt: Wer KI ernsthaft einsetzt, sollte ihre Grenzen kennen – und bei sensiblen Themen immer gegenprüfen.
Risikoeinstufung von KI-Antworten nach Themenbereich
Quelle: aggregierte Studien, Praxisanalysen & OpenAI-Tests (2023–2024)
Ziel des Artikels: Ursachen verstehen, Risiken erkennen, Lösungen anwenden
Dieser Artikel soll dich nicht nur schlauer machen – sondern handlungsfähig. Du erfährst, warum KI manchmal völligen Quatsch erzählt, dabei aber klingt wie der größte Experte im Raum. Du lernst, wie diese Halluzinationen entstehen, wo sie gefährlich werden – und vor allem: was du dagegen tun kannst.
Am Ende weißt du nicht nur, wie Sprachmodelle ticken, sondern auch, wie du bessere Prompts formulierst, Fehler erkennst und KI gezielter einsetzt. Es geht nicht ums Technik-Verstehen – sondern darum, in der Praxis souverän mit KI zu arbeiten.
2. Was sind Halluzinationen bei KI – und wie entstehen sie?
Warum LLMs Texte vorhersagen, aber kein Weltwissen besitzen
LLMs wie ChatGPT sind keine denkenden Wesen, sondern ausgeklügelte Statistikmaschinen. Sie zerlegen deine Eingabe in kleine Bestandteile – sogenannte Tokens – und berechnen, welches Token als Nächstes wahrscheinlich folgen sollte.
Auf dieser reinen Wahrscheinlichkeitsrechnung basiert jede Antwort. Das heißt: Die KI „vervollständigt“ Texte, statt Inhalte wirklich zu verstehen. Sie hat kein Weltwissen, keine Vorstellung von Wahrheit und keine Ahnung, ob etwas logisch oder korrekt ist.
Wenn du eine komplexe Rechenaufgabe stellst, antwortet sie nicht, weil sie rechnen kann – sondern weil sie diese Aufgabe (oder eine ähnliche) wahrscheinlich schon mal in den Trainingsdaten gesehen hat.
Und wenn nicht, halluziniert sie eine Lösung. Deshalb wirken ihre Antworten oft stimmig, sind aber nicht verlässlich. Denn das Modell kennt keine Fakten – es spiegelt nur Muster aus Milliarden von Texten.
Definition: „Faktenfreie“ oder erfundene Aussagen
Eine Halluzination entsteht, wenn ein KI-Modell eine Antwort liefert, die faktisch falsch oder komplett erfunden ist – aber trotzdem selbstbewusst klingt. Typisch ist: Die KI behauptet Dinge, die nie passiert sind, nennt Quellen, die es nicht gibt, oder rechnet falsch, ohne es zu merken.
Das liegt daran, dass LLMs wie ChatGPT kein echtes Wissen besitzen. Sie berechnen nur, welches Wort wahrscheinlich als Nächstes passt – egal ob es stimmt oder nicht. Fachlich nennt man das auch „Konfabulation“: ein scheinbar logischer, aber ausgedachter Zusammenhang.
Typische Auslöser: vage Prompts, fehlender Kontext, veraltete Trainingsdaten
Typische Halluzinationen entstehen, wenn das Modell zu wenig oder ungenauen Kontext hat – und dann beginnt zu raten. Die häufigsten Auslöser sind: vage Prompts, unzureichender Gesprächskontext und veraltete oder lückenhafte Trainingsdaten.
Wenn dein Prompt unklar ist – z. B. „Erklär mir das mal“ – ohne Thema, Zielgruppe oder Stilvorgabe, füllt das Modell die Lücken mit dem, was statistisch wahrscheinlich klingt. Klingt plausibel, ist aber oft nicht korrekt. Besser: Gib klare Anweisungen – mit Rolle, Ziel, Format und ggf. Begrenzung („in drei Sätzen“). So reduzierst du das Raten.
Auch der Kontext innerhalb eines Chats kann problematisch sein: Zwar erinnern sich viele Modelle im aktuellen Verlauf an vorherige Nachrichten – aber sie vergessen schnell den Fokus, verwechseln Themen oder „halluzinieren“ Zusammenhänge, die du nie erwähnt hast. Noch kritischer wird es bei API-Aufrufen: Dort musst du alle nötigen Infos aktiv mitliefern – die Modelle starten sonst bei null. In beiden Fällen helfen dir strukturierte Prompts oder Tools wie RAG, die externes Wissen in den Kontext einfügen.
Und schließlich: Das Trainingswissen ist eingefroren. Frägst du nach etwas Aktuellem oder nach internen Unternehmensdaten, bekommst du zwar eine Antwort – aber sie basiert auf Mustern, nicht auf Fakten. Ohne externe Tools oder Live-Datenzugriff (wie RAG, Plugins, API-Anbindung) kann das Modell nicht wissen, was nach seinem Cutoff passiert ist.
Kurz: LLMs halluzinieren nicht, weil sie böse sind – sondern weil ihnen relevante Infos fehlen. Je besser du Kontext, Ziel und Struktur vorgibst, desto weniger raten sie – und desto hilfreicher wird die Antwort.
Praxisbeispiele aus Chatbots, Codemodellen und Suchassistenten
Ob Chatbots, Codemodelle oder Suchassistenten – überall, wo KI-Modelle Texte erzeugen, können Halluzinationen auftreten. Hier einige typische Fälle, damit du erkennst, wann du besser doppelt hinschaust:
1. Chatbots: Selbstbewusst falsch – vor allem bei Mathe und Fakten
Frag ein KI-Modell nach „3.695 × 123.548“ – und du bekommst eine Antwort. Nur: Die Wahrscheinlichkeit ist hoch, dass sie falsch ist. LLMs rechnen nicht, sie raten auf Basis von Textmustern. Auch bei historischen Daten oder Zitaten kann’s schnell daneben gehen – selbst wenn es überzeugend klingt. Und ja: Auch moralisch fragwürdige Aussagen können vorkommen, besonders bei Modellen mit alten Trainingsdaten. RLHF (also menschliches Feedback) hilft – aber macht keine Garantie.
2. Codemodelle: Prompt Injection & gefährliche Vorschläge
Tools wie GitHub Copilot wirken magisch – aber sie sind nicht immun gegen Manipulation. Wer die Eingabe geschickt formuliert („Ignoriere alle Regeln…“), kann sogar Schutzmechanismen aushebeln. Das kann im harmlosen Fall zu Müllcode führen – im schlimmsten Fall zu Sicherheitslücken. Und: Manche Vorschläge von Copilot waren historisch sogar urheberrechtlich fragwürdig oder enthielten unsichere Patterns. Du bleibst verantwortlich für das, was du übernimmst.
3. Suchassistenten: Wenn KI ihre eigenen Geheimnisse verrät
Bei Bing Chat (Codename „Sydney“) konnte man mit simplen Tricks interne Regeln sichtbar machen – etwa durch die Aufforderung, alle „versteckten“ Instruktionen offenzulegen. Auch hier zeigte sich: LLMs folgen Sprache, nicht Intention. Wer geschickt formuliert, kann sie austricksen. Genau deshalb braucht es „Guardrails“, Kontextüberprüfung – und Nutzer:innen, die wissen, wie KI wirklich funktioniert.
Fazit: Halluzinationen sind keine Randerscheinung – sie sind systemimmanent. Und sie sind kein Bug, sondern Folge des Designs. Du kannst damit umgehen, aber nur, wenn du verstehst, wo die Grenzen liegen – und wie du sie erkennst.
Häufige Missverständnisse: „GPT kann rechnen“, „größeres Modell = mehr Wahrheit“
„GPT kann rechnen“
Nein, kann es nicht – zumindest nicht im klassischen Sinne. LLMs wie GPT-4 berechnen nichts. Sie schätzen nur, welches Token wahrscheinlich als nächstes kommt. Wenn du „2 + 2“ fragst, kommt „4“, weil das in Milliarden von Texten so stand. Aber bei „3.695 × 123.548“ wird’s schnell falsch – und zwar mit voller Überzeugung. Das Modell hat kein Zahlenverständnis, sondern betreibt Textvervollständigung. Mathe ist für GPT ein Ratespiel mit Zahlen als Buchstaben.
Umweg-Tipp: Wenn du komplexe Aufgaben lösen willst, nutze externe Tools – oder sag dem Modell explizit: „Denk Schritt für Schritt.“ (Chain of Thought). Das hilft manchmal – garantiert aber keine richtige Lösung.
„Größeres Modell = mehr Wahrheit“
Auch falsch. Ein größeres Modell halluziniert zwar oft schöner – aber nicht zwingend weniger. Größe bringt mehr Kontexttiefe, komplexeres Sprachverständnis und bessere Struktur. Aber: Das Modell bleibt ein Wahrscheinlichkeitsorakel ohne echtes Weltwissen. Es weiß nicht, ob das, was es sagt, stimmt – es klingt nur besser dabei.
Wichtig: Auch GPT-4 kann lügen. Je komplexer die Frage, je schwächer der Kontext, desto größer die Gefahr. RLHF (also menschliches Feintuning) macht das Modell verträglicher – aber nicht unfehlbar.
Mehr Rechenleistung macht das Modell nicht klüger. Und mehr Parameter machen es nicht wahrhaftiger. Wer KI nutzt, muss ihre Limits kennen – und sich nicht von Selbstbewusstsein blenden lassen.
3. Prompt Engineering: Präzise Fragen, bessere Antworten
Die Bausteine eines guten Prompts
Ein guter Prompt ist wie eine klare Ansage in der Küche: Wer nur ruft „Mach was Leckeres!“, bekommt irgendwas. Wer sagt „Mach mir eine vegane Linsensuppe, scharf, in 15 Minuten, für zwei Personen“, bekommt ziemlich genau das.
Genauso bei LLMs: Je klarer du formulierst, wer was in welchem Stil für wen tun soll – desto besser die Antwort. Denn Sprachmodelle „verstehen“ nicht, sie folgen Mustern. Wenn du den Rahmen nicht vorgibst, füllen sie die Lücken – mit statistischer Wahrscheinlichkeitslyrik. Klingt oft gut, ist aber selten das, was du wirklich brauchst.
In diesem Abschnitt zeige ich dir, welche Bausteine in fast jedem Prompt wirken – und wie du damit gezielter, präziser und halluzinationsärmer arbeitest.
Rollenklärung: „Du bist ein...“
Die „Rollenklärung“ in der Prompt-Entwicklung – oft als „Role-Playing“ oder Zuweisung einer Persona bezeichnet – ist eine zentrale Technik, um die Ausgaben von großen Sprachmodellen (LLMs) wie GPT-4 oder ChatGPT gezielt zu steuern.
Was bedeutet „Du bist ein…“?
Die Formel „Du bist ein…“ weist dem Modell eine konkrete Rolle oder Identität zu – etwa Arzt, Jurist, Coach, Datenanalyst. Statt generisch zu antworten, übernimmt das Modell eine spezifische Perspektive, die Einfluss auf Ton, Wortwahl und Inhalt nimmt.
Das macht Rollenklärung zu einem Schlüsselelement im Prompt Engineering: Sie legt fest, aus welcher Perspektive das Modell agieren soll – vergleichbar mit einem Schauspieler, der eine Rolle spielt.
Warum ist die Rollenvergabe so wichtig?
Zielgerichtetere Antworten: Eine klar definierte Rolle hilft dem Modell, relevante und kontextbezogene Inhalte zu liefern.
Höhere Genauigkeit und Relevanz: Studien zeigen, dass Prompts mit Rollenangabe signifikant bessere Ergebnisse erzeugen – gerade bei komplexen Aufgaben.
Mehr Kontrolle: Rollen erlauben gezieltere Steuerung des Stils, Tons und Fachniveaus.
Weniger Floskeln: Ohne Rollenzuweisung tendieren LLMs zu vagen, allgemeinen Antworten.
Wie wird eine Rolle definiert?
Direkt im Prompt-Text:
„Du bist ein Ernährungsberater. Bitte gib Empfehlungen für eine vegane Sportlerdiät.“
„Du bist ein investigativer Journalist. Analysiere den folgenden Text kritisch…“
„Als IT-Sicherheitsexperte sollst du folgende Logdatei auf potenzielle Angriffe prüfen…“
Im Systemnachricht-Feld (z. B. bei OpenAI APIs oder Custom GPTs):
„You are a helpful legal advisor specializing in contract law.“
„You are a humorous assistant that uses metaphors to explain technical concepts.“
In Prompt-Frameworks wie LangChain:
Rollen werden dort in
SystemMessagePromptTemplatesoderChatPromptTemplateseingebettet und automatisiert übergeben. Beispiel: Ein Customer-Support-Agent oder ein medizinischer Berater, jeweils mit spezifischem Sprachstil und Wissensrahmen.
Eine gute Rollenklärung sorgt dafür, dass das Modell nicht nur irgendeine Antwort gibt, sondern die passende. Wer die Rolle sauber definiert, legt damit den Grundstein für präzise, kontextstarke und nützliche Ergebnisse – besonders bei komplexeren Use Cases.
Kontext liefern: Worum geht es genau?
Im Prompt Engineering bezeichnet „Kontext“ alle Informationen und Rahmenbedingungen, die ein Sprachmodell braucht, um sinnvoll zu antworten. Dazu zählen z. B. Fakten, Zielgruppen, Vorwissen, persönliche Präferenzen oder der Verlauf eines Gesprächs.
Warum ist Kontext wichtig?
- Steuert die Relevanz: Ohne Kontext gibt’s generische Antworten. Mit Kontext liefert das Modell Ergebnisse, die zur Situation passen.
- Erhöht die Genauigkeit: Je mehr relevante Details du mitgibst, desto klarer wird die Antwort.
- Verhindert Halluzinationen: Ein gut gesetzter Kontext schützt vor erfundenen Fakten, weil er dem Modell eine Richtung gibt.
- Ermöglicht komplexe Aufgaben: Gerade bei mehrstufigen Analysen oder Fachfragen ist Kontext unerlässlich.
Wie gibst du Kontext?
- Direkt im Prompt: „Ich bin Softwareentwickler und suche nach einem SEO-Tool für React-Seiten…“
- Systemrolle/API: Vorab definierter Kontext über eine „Systemnachricht“ (z. B. bei OpenAI APIs).
- Konversationsverlauf: In Chat-Anwendungen ergibt sich Kontext auch aus dem bisherigen Gespräch.
- Visuell oder dokumentbasiert (bei multimodalen Modellen): Bilder, PDFs oder andere Formate können als Kontext dienen
Abgrenzung zur Rollenklärung:
Die Rolle definiert wer das Modell ist („Du bist ein Jurist…“), der Kontext definiert worüber es spricht („… und der Nutzer lebt in Österreich und fragt nach Mietrecht“).
Klare Aufgabenstellung: Was soll beantwortet werden?
Ein häufiger Fehler beim Arbeiten mit LLMs: Wir geben der KI zu wenig konkrete Anweisungen. Statt klar zu formulieren, was genau passieren soll, lassen wir das Modell raten – und bekommen dann schwammige oder komplett falsche Antworten. Das ist kein Bug. Das ist Statistik.
Eine gute Aufgabenstellung ist wie eine Zielvorgabe an einen Praktikanten: Was soll am Ende rauskommen? In welchem Format? Und was auf keinen Fall?
Beispiel:
Vage: „Gib mir eine Idee fürs Mittagessen.“
Klar: „Schlag mir ein vegetarisches Hauptgericht vor und liste die Zutaten in einer Tabelle auf – Spalte 1: Zutat, Spalte 2: Gramm pro Person. Kein Rezept.“
Solche präzisen Prompts helfen dem Modell, relevante und strukturierte Ergebnisse zu liefern – statt bloßes Herumgerate. Besonders bei komplexeren Aufgaben lohnt es sich, die gewünschte Ausgabeform, den Umfang und auch Einschränkungen (z. B. keine Quellen, keine Zubereitung) explizit zu benennen.
Fazit: Je klarer die Aufgabe, desto besser die Antwort. Wer die KI führen will, muss ihr klare Wege zeigen – keine offenen Fragen stellen.
Format definieren: Tabelle, Liste, JSON, Bulletpoints etc.
Wenn du willst, dass deine Ausgabe aussieht wie eine Tabelle – dann sag das auch. LLMs sind keine Hellseher. Je klarer du das Format vorgibst, desto verlässlicher bekommst du, was du brauchst.
Ob Liste, Tabelle, JSON, Markdown, Bulletpoints oder sogar CSV – du kannst (und solltest) das gewünschte Ausgabeformat immer explizit im Prompt festlegen.
Beispiel:
Vage: „Was brauche ich für ein Curry?“
Klar: „Liste mir die Zutaten für ein vegetarisches Curry als Tabelle auf. Spalte 1: Zutat, Spalte 2: Gramm pro Person.“
Oder bei technischen Anwendungen:
„Gib mir die Ausgabe im JSON-Format.“
„Erstelle ein Markdown-Code-Snippet mit HTML-Elementen.“
„Formatiere die Antwort als CSV mit Komma-Trennung.“
Gerade wenn du die Antwort weiterverarbeiten willst – z. B. in einer App oder Analyse – ist die Formatdefinition Gold wert. Sie reduziert Nacharbeit, erhöht die Wiederholbarkeit und macht die Ausgabe maschinenlesbar.
Merke: Struktur ist kein Detail, sondern ein Steuerungsinstrument. Wer die Form vorgibt, kontrolliert den Output.
Chain-of-Thought aktivieren: Schrittweise denken lassen
Wenn KI halluziniert, liegt es oft daran, dass sie zu schnell antwortet – ohne den Denkprozess offenzulegen. Genau hier setzt die Chain-of-Thought (CoT)-Technik an. Mit einer einfachen Formulierung wie „Lass uns Schritt für Schritt denken“ im Prompt leitest du das Modell an, nicht nur das Ergebnis zu liefern, sondern den Lösungsweg mitzudenken.
Diese Methode ist besonders bei komplexen oder mehrstufigen Aufgaben sinnvoll – etwa bei Rechenoperationen, logischen Schlussfolgerungen oder strategischen Fragestellungen. Anstatt zu raten, geht das Modell nun strukturiert und nachvollziehbar vor:
Ohne CoT: „Wieviel ist 369 × 1235?“ → Das Modell spuckt eine Zahl aus – die kann richtig sein, muss aber nicht.
Mit CoT: „Wieviel ist 369 × 1235? Lass uns Schritt für Schritt denken.“ → Die KI rechnet systematisch, zeigt jeden Zwischenschritt und kommt meist zuverlässig zum Ergebnis.
Doch Chain-of-Thought funktioniert nicht nur bei Mathe. Auch bei Textaufgaben, Problemlösungen oder Entscheidungen hilft es dem Modell, klarer zu argumentieren und Fehler zu vermeiden. Du bekommst nicht nur eine Antwort, sondern eine begründete – und kannst sie besser überprüfen.
Für dich als Prompt-Engineer heißt das: Wenn’s kompliziert wird, fordere explizit ein Schritt-für-Schritt-Denken ein. Damit baust du Halluzinationsschutz direkt in den Prompt ein – und das mit minimalem Aufwand.
3.2 Erweiterte Techniken
Few-Shot Learning: Beispielhafte Antworten vorgeben
Few-Shot Learning: Präzision durch Beispiele
Um Large Language Models (LLMs) zuverlässig zu lenken, ist Few-Shot Learning eine der wirkungsvollsten Techniken im Prompt Engineering. Anstatt dem Modell eine Aufgabe ohne Kontext zu stellen, liefern wir im Prompt ein oder mehrere Input-Output-Beispiele – meist in Form echter Mini-Demonstrationen. Diese helfen dem Modell, Muster zu erkennen und auf neue, ähnliche Anfragen anzuwenden.
Besonders bei Aufgaben wie Klassifizierungen, logischen Schlussfolgerungen oder stilistischen Anpassungen – etwa beim Antworten im „Morpheus-Stil“ – kann Few-Shot Prompting die Qualität der Ausgabe massiv steigern. Wichtig ist: Die Beispiele müssen klar, prägnant und repräsentativ sein. Kombiniert mit Rollenangaben und klarer Aufgabenstellung wird das Prompt zur mächtigen Steuerzentrale.
Negative Prompts: Unerwünschte Inhalte ausschließen
Prompt Engineering bedeutet nicht nur, präzise zu sagen, was ein Sprachmodell liefern soll – sondern auch, was es auf keinen Fall sagen darf. Genau dafür gibt es Negative Prompts: gezielte Anweisungen, um unerwünschte Inhalte, Formulierungen oder Antwortstrukturen aktiv auszuschließen.
Das Prinzip ist simpel: Anstatt dem Modell nur eine Aufgabe zu geben wie „Fasse diesen Text zusammen“, ergänzt man den Prompt um klare Einschränkungen, zum Beispiel:
„Fasse den Text in drei Bulletpoints zusammen. Vermeide dabei Einleitungen wie ‘In diesem Text geht es um…’.“
Solche Negativanweisungen helfen dem Modell, sich auf das Wesentliche zu konzentrieren – und das Ergebnis wird strukturierter, klarer und brauchbarer.
Typische Einsatzbereiche für Negative Prompts:
Strukturierte Ausgabe erzwingen:
Wenn du etwa eine saubere JSON-Antwort brauchst, reicht der Prompt „Gib die Antwort im JSON-Format aus“ oft nicht. Besser ist:
„Antwort ausschließlich im JSON-Format. Keine Einleitung, keine Erklärungen, kein Text vor oder nach dem JSON.“
Das vermeidet unnötigen „KI-Sprech“, der die Verarbeitung stören kann.Unerwünschte Floskeln vermeiden:
Willst du einen Artikel generieren, aber ohne generische Phrasen wie „Dieser Artikel handelt von…“? Dann sag es explizit.
„Vermeide Sätze wie ‘In diesem Artikel geht es um…’. Komme direkt zur Sache.“Nur das Wesentliche extrahieren:
Bei Extraktionsaufgaben kannst du anweisen:
„Extrahiere nur die Keywords aus der Frage. Keine vollständige Antwort. Nur die Keywords.“
So vermeidest du, dass das Modell in den Erklärmodus verfällt.
Warum das so wichtig ist:
LLMs neigen dazu, „hilfsbereit“ zu sein – und das bedeutet oft: sie geben zu viel Kontext, schmücken aus oder liefern zusätzliche Infos, die du gerade nicht brauchst. Negative Prompts sind dein Werkzeug, um diese Neigung in den Griff zu bekommen. Sie machen deine Prompts fokussierter, effizienter und kontrollierbarer – gerade bei Aufgaben, die downstream weiterverarbeitet oder automatisiert verarbeitet werden sollen.
Längen- und Formatvorgaben
Wenn du mit Large Language Models arbeitest, reicht ein guter Prompt oft nicht aus. Ohne klare Längen- und Formatvorgaben liefern LLMs gerne unnötige Einleitungen, schwafelige Übergänge oder Ausgaben, die für dich nicht weiterverwendbar sind. Genau hier setzt gutes Prompt Engineering an.
Mit dem Parameter max_tokens kannst du die maximale Länge der Antwort direkt begrenzen – eine wichtige Stellschraube zur Kostenkontrolle, gerade bei längeren Konversationen oder API-Aufrufen.
Aber auch direkt im Prompt lassen sich Vorgaben setzen: „Antworte in zwei Sätzen“, „Fasse in maximal 100 Wörtern zusammen“ oder „Nur Stichpunkte“ helfen dem Modell, die gewünschte Länge besser zu treffen – auch wenn die Einhaltung nicht millimetergenau garantiert ist.
Ebenso entscheidend ist die Formatvorgabe. Willst du eine Liste, eine Tabelle, ein JSON-Objekt? Dann sag es dem Modell explizit. Am besten mit klarer Ansage („Gib nur gültiges JSON zurück. Keine Erklärungen.“) und – wenn unterstützt – auch mit dem response_format-Parameter.
Alternativ helfen Negative Prompts wie „Füge nichts vor oder nach dem JSON hinzu“ dabei, störende Zusatztexte zu vermeiden.
Das Ziel: Eine präzise, nutzbare Ausgabe, die direkt in deine Anwendung, Datenbank oder Pipeline passt. Wer das früh lernt, spart später Zeit – und evtl. Tokens.
Iteratives Prompt-Tuning: Ergebnisse bewerten und verfeinern
Großartige Prompts entstehen selten im ersten Versuch. Gerade bei komplexen Aufgaben brauchst du einen klaren Prozess, um die Qualität der KI-Antworten gezielt zu steigern – genau das leistet iteratives Prompt-Tuning.
Dabei gehst du schrittweise vor:
Erstellen: Starte mit einem einfachen, klar formulierten Prompt.
Beobachten: Schau dir die Antwort genau an – passt sie zur Aufgabe? Stimmt der Stil? Gibt’s Halluzinationen?
Anpassen: Überarbeite den Prompt, z. B. durch:
präzisere Anweisungen („antworte in 3 Sätzen“),
Beispiel-Prompts (Few-Shot Learning),
Rollenzuweisung („du bist ein Steuerberater“),
klare Formatvorgaben (z. B. JSON oder Tabelle),
oder Negative Prompts, um Unerwünschtes auszuschließen.
Wiederholen: Teste neu, vergleiche, verfeinere. Tools wie
promptfoo,OpenAI EvalsoderLangChainhelfen dir dabei.
Dieser Zyklus spart dir langfristig Zeit, wer iterativ denkt, promptet präziser.
4. RAG: Externes Wissen als Faktenanker
Was ist Retrieval-Augmented Generation (RAG)?
Große Sprachmodelle wie GPT-4 wirken allwissend – bis sie anfangen zu halluzinieren. Denn ihr Wissen endet mit dem Trainingszeitpunkt. Aktuelle Fakten, interne Dokumente oder spezielle Fachinfos? Fehlanzeige. Genau hier setzt Retrieval-Augmented Generation (RAG) an.
Was ist RAG?
RAG erweitert ein LLM um eine externe Wissensquelle. Statt rein aus dem Modellwissen zu antworten, zieht das System bei jeder Anfrage relevante Informationen aus einer vorbereiteten Datenbank – und nutzt diese als Kontext für die Antwort.
Wie funktioniert das?
Daten aufbereiten: Eigene Texte (z. B. PDFs, Webseiten, Notizen) werden in kleine Abschnitte („Chunks“) zerlegt.
Vektorisieren: Jeder Chunk wird in einen semantischen Vektor umgewandelt (Embeddings).
Abspeichern: Diese Vektoren landen in einer Vektordatenbank (z. B. Faiss, Weaviate, Pinecone).
Abfrage & Abruf: Bei einer Nutzerfrage sucht das System ähnliche Vektoren – also relevante Textabschnitte – heraus.
Generierung mit Kontext: Das LLM erhält diesen externen Input im Prompt und erzeugt darauf basierend die Antwort.
Warum ist RAG wichtig?
Es reduziert Halluzinationen drastisch.
Es macht dein Modell faktenbasiert, auch bei neuem oder internem Wissen.
Es ist deutlich günstiger als Fine-Tuning.
Es erlaubt dir, das Modell ohne Neutraining jederzeit aktuell zu halten.
Wann solltest du RAG einsetzen?
Wenn du Inhalte generieren willst, die nicht im Training des Modells enthalten waren.
Wenn du rechtlich, medizinisch oder fachlich präzise Aussagen brauchst.
Wenn du internes Wissen wie Firmenrichtlinien, Tickets oder Support-Daten verfügbar machen willst.
Kurz: RAG ist der Gamechanger, wenn du aus einem generischen Sprachmodell einen zuverlässigen Experten mit echtem Wissen machen willst – ganz ohne Halluzinationen.
Was ist Retrieval-Augmented Generation (RAG)?
Damit ein Large Language Model (LLM) wie GPT-4 auf aktuelle, domänenspezifische oder unternehmensinterne Informationen zugreifen kann, braucht es mehr als reines Trainingswissen. Genau hier kommt Retrieval-Augmented Generation (RAG) ins Spiel – und zwar in einem strukturierten Prozess, der sich in vier zentrale Schritte gliedert: Embedding, Retrieval, Auswahl und Antwortgenerierung.
1. Embedding: Deine Daten als semantische Vektoren
Im ersten Schritt wird deine Wissensbasis – ob PDFs, Webseiten oder interne Dokumente – in kleinere Abschnitte („Chunks“) zerlegt. Diese Einheiten werden mithilfe spezialisierter Modelle (z. B. text-embedding-3-small von OpenAI) in sogenannte Embeddings umgewandelt: numerische Vektoren, die die semantische Bedeutung des Textes erfassen. Ähnlich bedeutende Inhalte liegen im Vektorraum nah beieinander. Diese Embeddings landen anschließend in einem sogenannten Vector Store, also einer Vektordatenbank, die auf schnelle Ähnlichkeitssuche ausgelegt ist.
2. Retrieval: Relevante Infos zur Nutzerfrage finden
Sobald ein Nutzer eine Frage stellt, wird auch diese in ein Embedding übersetzt und mit den gespeicherten Vektoren verglichen. Die Suche erfolgt typischerweise über k-nächste-Nachbarn-Algorithmen (KNN) und Ähnlichkeitsmetriken wie Cosine Similarity. Bei komplexeren Systemen kommt eine hybride Suche zum Einsatz, die semantische Vektorsuche mit klassischen Keyword-Methoden (z. B. BM25) kombiniert, um noch präzisere Ergebnisse zu liefern.
3. Auswahl: Die besten Textabschnitte filtern und anreichern
Aus der Suche gehen die relevantesten Chunks hervor – typischerweise die Top-k-Ergebnisse. Um das LLM bestmöglich zu unterstützen, können diese Textbausteine mit zusätzlichen Kontexten oder Metadaten angereichert werden. Ziel ist es, nicht nur exakte Treffer, sondern auch angrenzende, semantisch wichtige Informationen bereitzustellen. So entsteht ein robuster, thematisch zusammenhängender Informationsblock.
4. Antwort: Fundierte Generierung mit Kontext
Im letzten Schritt wird der angereicherte Kontext zusammen mit der Nutzerfrage in einen Prompt eingebettet und an das LLM übergeben. Der Prompt folgt dabei meist einer klaren Struktur wie:
„Beantworte die folgende Frage basierend auf den bereitgestellten Fakten. FAKTEN: … FRAGE: …“
Das Modell generiert daraufhin eine Antwort, die nicht mehr auf spekulativem Trainingswissen basiert, sondern auf nachgewiesenem, aktuellem und zielgerichtetem Input. So lassen sich Halluzinationen deutlich reduzieren – und das Modell liefert nicht nur kreative, sondern auch verifizierbare Aussagen.
Proprietäre RAG-Systeme: Wer setzt RAG bereits produktiv ein?
Retrieval-Augmented Generation ist längst nicht mehr nur ein theoretisches Konzept aus der Forschung – es steckt heute bereits unter der Haube vieler KI-Produkte, die du vielleicht selbst schon nutzt. Besonders proprietäre Anbieter haben RAG-Architekturen genutzt, um ihre Sprachmodelle durch kontextbewusstes Nachschlagen robuster, aktueller und sicherer zu machen.
Hier einige der bekanntesten RAG-basierten Systeme:
NotebookLM (Google): Googles KI-Notizbuch erlaubt es Nutzer:innen, eigene Dokumente hochzuladen (z. B. PDFs, Google Docs) und Fragen dazu zu stellen. Das zugrunde liegende LLM kombiniert die Anfrage mit gezielten Retrieval-Operationen auf den hochgeladenen Inhalten – ein Paradebeispiel für RAG im Alltag.
ChatGPT (OpenAI) mit “Custom GPTs” und Datei-Upload: Auch wenn OpenAI es nicht explizit als RAG bezeichnet, nutzt der Datei-Upload in GPT-4o (via Advanced Data Analysis oder Custom GPTs mit „Knowledge“) ebenfalls diese Technik. Dateien werden verarbeitet, indiziert und als Kontext dem LLM bereitgestellt.
Perplexity AI: Eine suchmaschinenähnliche Anwendung, die deine Fragen nicht einfach aus dem Modellwissen beantwortet, sondern gezielt Quellen sucht und diese in die Antwort einarbeitet – ein klassisches RAG-System, gepaart mit Live-Recherche.
Klu.ai, Glean, Dust, LlamaIndex Cloud & andere Startups: Diese Plattformen richten sich an Unternehmen und Entwickler:innen, die eigene RAG-Workflows aufbauen wollen – oft mit Benutzeroberflächen für Wissensverwaltung, Vektorspeicherung und Custom Prompts.
Anthropic’s Claude mit „Memory“ und Dateiupload: Auch Claude kann bei Dateiuploads externe Informationen verarbeiten, abrufen und in Kontexte einbauen – ebenfalls ein RAG-Ansatz im Hintergrund, auch wenn das API-Zugriffsmodell eher closed-source bleibt.
Tools & Frameworks: LlamaIndex, LangChain, Vektordatenbanken
Um Large Language Models (LLMs) wirklich produktionsreif zu machen, reicht pures Prompt Engineering oft nicht mehr aus. Spätestens wenn es um faktenbasierte Antworten, aktuellen Kontext oder unternehmensspezifisches Wissen geht, braucht es Retrieval-Augmented Generation (RAG) – und dafür eine solide technische Grundlage. Genau hier kommen Frameworks wie LangChain und LlamaIndex sowie leistungsstarke Vektordatenbanken ins Spiel.
Vektordatenbanken sind das Rückgrat jeder RAG-Architektur. Sie speichern sogenannte Embeddings – numerische Repräsentationen von Texten – und ermöglichen semantische Suchen über deine Wissensbasis. Tools wie OpenAI’s Embedding-Modelle (text-embedding-3-small, text-embedding-3-large) wandeln deine Dokumente in Vektoren um, die dann in spezialisierten Datenbanken wie Pinecone, Weaviate, Redis oder Qdrant abgelegt werden. So lassen sich relevante Inhalte bei jeder Benutzerfrage sekundenschnell finden – selbst in riesigen Dokumentenbeständen.
Anschließend übernehmen LangChain oder LlamaIndex die Integration ins LLM.
LangChain ist ein modulares Framework, das alles bietet, was man für komplexe LLM-Apps braucht: Prompt-Templates, Agenten, Tool-Calls, Memory-Management, Chains – und natürlich RAG-Komponenten. Besonders praktisch: die einfache Verknüpfung mit APIs, Datenbanken und externen Tools.
LlamaIndex hingegen wurde speziell für RAG-Szenarien entwickelt. Es glänzt durch einfache Datenaufnahme (inkl. PDF-, CSV-, Notion-Import), clevere Indexierung und schnelle Abfragen. Auch eine Evaluierung der Antwortqualität ist integriert – ideal für Projekte, bei denen Verlässlichkeit zählt.
Beide Frameworks sind OpenAI-kompatibel und darauf ausgelegt, LLMs schnell, sicher und faktenbasiert in produktive Anwendungen zu überführen – ohne aufwändiges Fine-Tuning. Stattdessen werden relevante Informationen zur Laufzeit aus der eigenen Datenbasis gezogen, was Halluzinationen reduziert und Kontrolle über das Wissen der KI ermöglicht.
Wer heute mit LLMs echte Probleme lösen will – egal ob im Kundenservice, Dokumenten-Analyse oder Wissensmanagement – kommt an LangChain, LlamaIndex und einer robusten Vektordatenbank nicht vorbei. Sie bilden das Fundament für moderne, datengetriebene KI-Anwendungen, die über Spielerei hinausgehen.
Tools & Frameworks: LlamaIndex, LangChain, Vektordatenbanken
Retrieval-Augmented Generation (RAG) gilt als eine der wirksamsten Methoden, um Large Language Models (LLMs) mit aktuellem, externem oder domänenspezifischem Wissen zu versorgen. Dennoch ist RAG kein Allheilmittel – und in bestimmten Anwendungsfällen schlicht die falsche Wahl. Wer RAG richtig einsetzen will, muss seine Grenzen kennen.
1. RAG braucht explizite Informationen – keine Interpretationen
RAG kann nur das zurückgeben, was bereits in der Wissensbasis steht. Wenn eine Frage jedoch Analyse, Vergleich oder Synthese erfordert – etwa: „Was sind die Schwächen dieses Dokuments?“ – versagt der bloße Retrieval-Ansatz. Das Modell kann nur auf vorhandene Fakten zugreifen, aber keine impliziten Schlüsse ziehen, wenn diese nicht vorher schon explizit formuliert wurden.
Beispiel: Die Frage „In wie vielen Sprachen ist das SDK verfügbar?“ kann nicht beantwortet werden, wenn die Wissensbasis nur einzelne Sprachabschnitte enthält – ohne zusammenfassende Übersicht.
2. RAG ist nicht für volatile Dokumente oder Ad-hoc-Fragen gemacht
Wenn du mit ständig wechselnden Dokumenten arbeitest oder Einmal-Abfragen hast, wird das Aktualisieren und Re-Embeddieren schnell aufwendig und teuer. In solchen Fällen ist es oft effizienter, das LLM direkt mit dem Volltext zu füttern – vorausgesetzt, das Kontextfenster ist groß genug.
3. Komplexe RAG-Architekturen sind schwer zu warten
Ein einfaches RAG-Setup ist schnell gebaut. Doch sobald du mehrere Datenquellen, Agenten, parallele Retrieval-Pfade und Post-Processing integrierst, wird das System schnell fragil und wartungsintensiv. Oft lohnt es sich mehr, die Struktur und Qualität deiner Wissensbasis zu verbessern, als in aufwendige Retrieval-Logik zu investieren.
4. Halluzinationen können trotzdem auftreten
RAG reduziert Halluzinationen – aber verhindert sie nicht. Das LLM generiert weiterhin Sprache basierend auf Wahrscheinlichkeiten. Es kann falsche Zusammenhänge ziehen, Kontext überdehnen oder frei ergänzen – selbst wenn die Quellen korrekt waren.
5. Keine Strategie für komplexe Problemlösung
RAG ist ideal, wenn du eine Antwort aus Texten extrahieren willst. Aber sobald es um strategisches Denken, mehrstufige Berechnungen oder dynamische Problemlösungen geht, stößt es an seine Grenzen. Ohne ergänzende Tools, Agentensysteme oder Code-Interpreter ist RAG kein Ersatz für echtes Reasoning.
RAG ist ein mächtiges Werkzeug – aber kein Wundermittel. Es funktioniert dann am besten, wenn die gesuchten Informationen präzise, auffindbar und in den richtigen Kontext eingebettet sind. In allen anderen Fällen braucht es: intelligentes Prompt Engineering, gute Datenstruktur – oder ein anderes Setup.
Grenzen: Was RAG nicht leisten kann
Retrieval-Augmented Generation (RAG) erweitert LLMs um externes Wissen – wirkt oft wie Magie, hat aber klare Limitierungen:
1. Nur was drinsteht, kommt raus.
RAG kann nur liefern, was explizit in den Dokumenten steht. Fragen, die Analyse, Zusammenhänge oder Synthese erfordern, überfordern den reinen Retrieval-Ansatz.
2. Dynamische Inhalte sind unpraktisch.
Wenn sich Dokumente ständig ändern oder nur einmalig genutzt werden, lohnt sich das Einpflegen und Embeddieren oft nicht.
3. Komplexe Architekturen? Fragil und teuer.
Fortgeschrittene RAG-Systeme mit mehreren Retrieval-Schritten, Agenten oder Post-Processing sind schwer zu warten – und kostenintensiv in der API-Nutzung.
4. Halluzinationen bleiben ein Thema.
Auch mit RAG kann das LLM falsche Inhalte „dazuerfinden“ oder Quellen falsch interpretieren. Die Sicherheit steigt, aber sie ist nicht absolut.
5. Kein Werkzeug für echtes Denken.
RAG liefert Wissen – aber kein Reasoning. Für strategische Aufgaben, mehrstufige Berechnungen oder Entscheidungslogik braucht es andere Tools.
