Ein gutes Beispiel im Prompt: Was es vorgibt und was offenbleibt

Ein Beispiel im Prompt zeigt der KI, wie eine Antwort aussehen soll. Es liefert aber keine verlässliche Trennung zwischen einer beabsichtigten Regel und zufälligen Eigenschaften des Beispiels. Wenn jede Musterantwort eine Frist nennt, kann eine neue Ausgabe ebenfalls eine Frist enthalten, obwohl der neue Fall keine Frist belegt. Deshalb braucht ein gutes Beispiel einen klaren Geltungsbereich und einen Test an abweichenden Fällen.

Dieser Artikel zeigt die Arbeit mit Beispielen an der Klassifikation interner Serviceanfragen. Das gesamte Material ist synthetisch. Die Kategorien, Testfälle und Auswertungen sind eigene Arbeitsvorschläge. Sie beschreiben keine gemessene Leistung eines bestimmten Produkts. Du kannst damit eine Vorlage prüfen, ohne echte Kundeninformationen zu verwenden.

Zuerst die Entscheidung festlegen

Das fiktive Serviceteam unterscheidet vier Ausgaben: Störung, Bedienfrage, Änderungswunsch und unklar. Eine Störung liegt vor, wenn eine bisher verfügbare Funktion nach Aussage des Meldenden nicht mehr funktioniert. Eine Bedienfrage betrifft die Nutzung einer vorhandenen Funktion. Ein Änderungswunsch verlangt eine zusätzliche oder veränderte Funktion. Unklar gilt, wenn die Meldung keine ausreichende Zuordnung erlaubt.

Diese Definitionen stehen vor den Beispielen. Sonst übernimmt das Modell die Aufgabe, aus wenigen Fällen eine unausgesprochene Fachregel abzuleiten. Das Team kann dann kaum erkennen, ob eine abweichende Ausgabe auf einer anderen Interpretation oder auf einem Verarbeitungsfehler beruht.

Die Kategorie beschreibt nur den gemeldeten Sachverhalt. Sie bestätigt weder eine technische Ursache noch die tatsächliche Existenz der Funktion. Der Satz "Der Export funktioniert seit heute nicht mehr" rechtfertigt in dieser Übung die Klasse Störung. Er belegt keinen Serverausfall und keine fehlerhafte Softwareversion.

Was die Forschung über Beispiele zeigt

Lu und Kollegen untersuchten 2022 die Reihenfolge von Beispielen in Prompts. In ihren Klassifikationsversuchen änderte die Reihenfolge die Ergebnisse teils stark. Eine gute Reihenfolge bei einem Modell ließ sich außerdem nicht zuverlässig auf ein anderes übertragen. Das ist ein Befund aus den untersuchten Modellen und Aufgaben, keine aktuelle Fehlerquote für dein Werkzeug.

Für die Praxis folgt daraus eine Prüfaufgabe: Ein überzeugendes Ergebnis mit einem einzelnen Beispielpaket reicht nicht als Nachweis einer stabilen Vorlage. Der folgende Vergleich von Beispieltypen und zurückgehaltenen Testfällen ist eine eigene Arbeitsmethode. Die Forschung belegt nicht, dass genau die hier gewählte Zahl an Fällen ausreicht.

Ein Beispiel hat mehrere Funktionen

Ein Muster kann das Format, den Sprachstil, die Entscheidungsregel oder den Umgang mit fehlenden Angaben zeigen. Diese Funktionen lassen sich getrennt prüfen. Für die Serviceklassifikation ist das Format eine Tabelle mit Fall-ID, Kategorie, Belegstelle und offener Frage. Der Stil ist knapp und sachlich. Die Entscheidungsregel folgt den vier Definitionen. Fehlende Informationen bleiben sichtbar.

Ein Beispiel mit einer vollständigen Kundenantwort vermischt diese Aufgaben unnötig. Es enthält vielleicht Anrede, Namen, Fristen und Lösungsversprechen, obwohl zunächst nur eine Kategorie gebraucht wird. Ich empfehle deshalb, das kleinste Beispiel zu verwenden, das die beabsichtigte Entscheidung tatsächlich zeigt.

Diese Trennung lässt sich direkt in die Vorlage schreiben: "Übernimm die Struktur und die Entscheidungsregel. Übernimm keine Namen, Fristen, Ursachen oder Falldaten aus den Beispielen."

Drei Beispiele mit verschiedenen Aufgaben

Das erste Beispiel zeigt einen klaren Normalfall. Eingabe: "Seit dem Update lässt sich die bisher genutzte Exportfunktion nicht mehr öffnen." Ausgabe: Störung. Belegstelle: "bisher genutzte Exportfunktion nicht mehr öffnen". Offene Frage: "Welche Fehlermeldung erscheint?" Die zeitliche Angabe zum Update bleibt eine Beobachtung des Meldenden. Sie wird nicht als bestätigte Ursache ausgegeben.

Das zweite Beispiel zeigt eine fehlende Grundlage. Eingabe: "Export geht anders als erwartet." Ausgabe: unklar. Belegstelle: "anders als erwartet". Offene Frage: "Welche Funktion wurde erwartet und was passiert tatsächlich?" Das Beispiel verhindert, dass jede negative Formulierung automatisch als Störung behandelt wird.

Das dritte Beispiel zeigt eine Grenze zwischen zwei plausiblen Klassen. Eingabe: "Der Export funktioniert. Ich brauche zusätzlich eine Auswahl nach Kostenstelle." Ausgabe: Änderungswunsch. Belegstelle: "zusätzlich eine Auswahl nach Kostenstelle". Offene Frage: "Welche Auswahlwerte werden benötigt?" Die vorhandene Funktion wird ausdrücklich als funktionsfähig beschrieben.

Jedes Beispiel hat damit einen Zweck. Drei fast identische Störungsmeldungen liefern weniger fachliche Abdeckung als diese unterschiedlichen Fälle. Die Anzahl allein ist kein Qualitätsmaß. Ein weiteres Beispiel lohnt sich, wenn es eine bisher ungeprüfte Unterscheidung erklärt.

Eine verwendbare Prompt-Vorlage

Die folgende Vorlage bleibt bewusst auf die erste Einordnung begrenzt. Sie startet keinen Serviceprozess und verschickt keine Antwort.

Aufgabe: Ordne jede neue Serviceanfrage einer Kategorie zu.
Kategorien und Definitionen: [freigegebene Definitionen einfügen]

Nutze ausschließlich die neue Anfrage als Quelle für Falldaten.
Die Beispiele zeigen Regeln und Ausgabeformat, keine Fakten des neuen Falls.
Erfinde keine Ursache, Zuständigkeit oder Bearbeitungsfrist.
Wenn eine Meldung mehrere unabhängige Anliegen enthält, markiere sie
als mehrteilig und ordne die Teilanliegen getrennt zu.
Fehlt eine notwendige Information, nutze unklar und stelle eine Rückfrage.

Ausgabe: Fall-ID | Kategorie | wörtliche Belegstelle | offene Frage.
Beispiele: [freigegebenes Beispielpaket]
Neue Anfragen: [getrennt gekennzeichnetes Material]

Die wörtliche Belegstelle ist eine kurze Passage aus der jeweiligen synthetischen Anfrage. Sie dient der Nachprüfung. Eine passende Belegstelle beweist noch nicht, dass die Kategorie richtig ist. Genau diese Verbindung muss die prüfende Person beurteilen.

Testfälle zurückhalten

Ein Beispiel erklärt eine Regel. Ein Testfall prüft, ob die Vorlage diese Regel auf neues Material überträgt. Wenn derselbe Fall beide Rollen erfüllt, prüfst du überwiegend die Wiederholung des sichtbaren Musters. Lege deshalb vor der Optimierung ein kleines, getrenntes Testpaket an.

Für die Übung enthält das Paket acht Fälle: zwei eindeutige Störungen, zwei Bedienfragen, zwei Änderungswünsche und zwei unklare Meldungen. Die Soll-Kategorien entstehen aus den Definitionen. Eine zweite fachkundige Person prüft sie vor dem Modelllauf. Bei Uneinigkeit muss zuerst die Fachregel geklärt werden.

Vier weitere Fälle ergänzen andere Formulierungen derselben Kategorien. Zusätzlich kommt ein mehrteiliger Fall außerhalb der einfachen Acht-Fälle-Auswertung hinzu: "Ich finde den Export nicht und brauche künftig einen automatischen Versand." Hier muss die Ausgabe zwei Anliegen erkennen. Eine einzige Kategorie verliert Information.

Ohne Beispiele und mit Beispielen vergleichen

Führe denselben Test zunächst mit Definitionen und Ausgabeformat allein aus. Danach ergänzt du das Beispielpaket. Halte Modellbezeichnung, Einstellungen, vollständigen Prompt und Zeitpunkt fest. Ein neuer Chat reduziert zumindest die Vermischung mit einem vorherigen Gespräch; er garantiert keine identischen technischen Bedingungen.

Die folgende Auswertung ist ein Rechenbeispiel, kein Testergebnis: Ohne Beispiele passen sechs von acht Kategorien. Mit Beispielen passen sieben von acht. Das entspricht 75 Prozent und 87,5 Prozent innerhalb dieses winzigen Pakets. Daraus folgt weder eine allgemeine Genauigkeit noch eine gesicherte Verbesserung im produktiven Betrieb.

Prüfe außerdem, welche Fehler verschwinden und welche neu entstehen. Wenn die Vorlage eine kritische Störung jetzt als Änderungswunsch ablegt, verdeckt eine höhere Gesamtquote einen relevanten Nachteil. Die Fehlerliste muss deshalb Fall-ID, Soll, Ist, Belegstelle und praktische Folge enthalten.

Danach vertauschst du die Reihenfolge der drei Beispiele und wiederholst den Lauf. Ein abweichendes Ergebnis ist ein Anlass zur Untersuchung. Die fachliche Definition kann zu unscharf sein, ein Beispiel kann eine Nebenregel transportieren oder der Prozess kann insgesamt instabil reagieren. Die Prüfung unterschiedlicher Prompt-Ergebnisse vertieft diese Unterscheidung.

Wenn Beispiele die falsche Regel vermitteln

Ein häufiger Fehler entsteht durch eine zufällige gemeinsame Eigenschaft. Enthalten alle Störungsbeispiele das Wort "Update", kann die Vorlage Meldungen ohne dieses Wort schlechter einordnen. Das Testpaket braucht deshalb eine Störung ohne Updatebezug und eine Meldung mit Updatebezug, die keine Störung ist.

Ein zweiter Fehler betrifft die Länge. Wenn nur unklare Meldungen sehr kurz sind, kann Kürze ungewollt zum Signal für unklar werden. "Wo ist der Export?" ist kurz, aber eine verständliche Bedienfrage. "Der Export im neuen Berichtssystem unterscheidet sich in mehreren Punkten von meiner bisherigen Erwartung" ist länger, bleibt ohne nähere Angaben trotzdem unklar.

Ein dritter Fehler ist eine Antwort, die den Stil perfekt kopiert und dabei die Belege verliert. Eine ordentlich formatierte Tabelle ist dann optisch überzeugend, fachlich aber unbrauchbar. Der Artikel zur Prüfung von KI-Ergebnissen hilft, Format und sachliche Richtigkeit getrennt abzunehmen.

Beispiele ändern und wieder entfernen

Jedes neue Beispiel braucht einen dokumentierten Grund. "Das Modell lag bei T04 falsch" reicht als Ausgangspunkt, aber nicht als fertige Begründung. Beschreibe die fehlende Unterscheidung: "Eine vage negative Bewertung reicht nicht zur Einstufung als Störung." Erst dann entsteht ein Beispiel, das eine allgemeine Regel erklärt.

Nimm den bisherigen Fehlerfall anschließend aus dem unabhängigen Testbestand heraus, wenn er als sichtbares Beispiel dient. Ergänze einen neuen Fall mit derselben fachlichen Schwierigkeit. Sonst verbessert sich die dokumentierte Testquote allein dadurch, dass die Lösung nun im Prompt steht.

Prüfe auch das Entfernen überholter Beispiele. Ein Paket wächst sonst bei jedem Fehler und enthält irgendwann widersprüchliche Regeln. Die Versionierung von KI-Arbeitsvorlagen hält fest, welche Definition und welches Beispielpaket zusammengehören.

Formattreue separat abnehmen

Ein weiterer Test verändert nur die gewünschte Ausgabe: Statt einer Tabelle wird eine Liste mit denselben vier Feldern verlangt. Bleibt die fachliche Zuordnung richtig, ist die Regel zumindest in diesem Test nicht an die Tabellenform gebunden. Ändert sich gleichzeitig die Kategorie, muss die Abhängigkeit untersucht werden.

Für die spätere Weiterverarbeitung wird zusätzlich geprüft, ob jedes Pflichtfeld vorhanden ist und die Fall-ID exakt erhalten bleibt. Eine richtige Kategorie ohne eindeutige Zuordnung zum Eingabefall ist operativ unbrauchbar. Besonders ähnlich formulierte Anfragen dürfen nicht vertauscht werden.

Das Beispielpaket erhält deshalb zwei getrennte Abnahmen: fachliche Zuordnung und Ausgabestruktur. Ein Fehler in der Struktur führt zunächst zur Korrektur dieses Teils. Die fachlichen Testfälle werden danach erneut geprüft, damit die Formatänderung keine neue Bedeutungsverschiebung verdeckt.

Abnahme für den ersten Einsatz

Für die beschriebene Übung lautet die Abnahme: Alle Kategorien besitzen eine verständliche Definition; jedes Beispiel hat einen benannten Zweck; die neuen Falldaten bleiben von den Mustern getrennt; die zurückgehaltenen Fälle sind fachlich geprüft; mehrteilige und unklare Anfragen bleiben erkennbar. Eine fachkundige Person entscheidet anhand der einzelnen Fehlerfolgen über den Einsatz.

Wenn ein Beispiel lediglich die gewünschte Tonlage zeigt, bezeichne es ausdrücklich als Stilbeispiel. Wenn es eine Entscheidungsregel zeigt, dokumentiere die Regel zusätzlich in Worten. Diese Zuordnung erleichtert spätere Änderungen: Eine neue Anrede verändert dann nicht versehentlich die fachliche Klassifikation.

Bewahre das Beispielpaket zusammen mit dem Testbestand und der geprüften Vorlagenversion auf. So lässt sich beim nächsten Fehler nachvollziehen, welche Regel die Vorlage vermitteln muss und an welcher Stelle die neue Ausgabe davon abweicht.

Quellenstand: 22.10.2026. Lu und Kollegen: Abstract geprüft. Beispiele, Arbeitsmittel und Rechenwerte sind eigene synthetische Ausarbeitungen; ihre Wirkung im jeweiligen Betrieb muss separat geprüft werden.