Warum derselbe Prompt unterschiedliche Ergebnisse liefert

Derselbe Prompt kann zu unterschiedlichen Antworten führen. Für die Arbeit zählt zuerst, welche Art von Unterschied vorliegt. Eine andere Satzstellung ist oft unproblematisch. Eine wechselnde Zuständigkeit, ein anderer Betrag oder eine neue Zusage verändert dagegen das Ergebnis. Wer jede Abweichung als Fehler behandelt, prüft unnötig viel. Wer nur auf einen ähnlichen Ton achtet, übersieht fachliche Instabilität.

Dieser Artikel entwickelt einen wiederholbaren Test für eine kleine Klassifikationsaufgabe. Die Fälle und Zahlen sind synthetisch. Die Beispielauswertung zeigt, wie du Ergebnisse vergleichst; sie beschreibt keinen gemessenen Test eines bestimmten Anbieters. Ziel ist eine begründete Einsatzentscheidung für eine eingegrenzte Aufgabe.

Was genau ist beim zweiten Lauf gleich?

Oft bleibt nur der sichtbare Fragesatz gleich. Im ersten Gespräch standen davor bereits drei Dokumente, eine Korrektur und eine Rollenbeschreibung. Im zweiten Gespräch fehlt dieser Kontext. Oder ein Wissensassistent findet andere Textstellen, obwohl der Nutzer dieselbe Frage stellt. Das ist kein Vergleich identischer Eingaben.

Dokumentiere deshalb den vollständigen Auftrag, das mitgegebene Material, den bisherigen Gesprächsverlauf und die verwendete Vorlagenversion. Wenn das Werkzeug weitere Einstellungen oder eine Modellbezeichnung zeigt, halte sie ebenfalls fest. Nicht sichtbare Systembestandteile bleiben als nicht prüfbar markiert.

Ein Screenshot der letzten Frage reicht für die Rekonstruktion nicht aus. Besser ist ein Testpaket mit nummerierten Quellen und einer gespeicherten Vorlage. Der Artikel zur Versionierung von KI-Arbeitsvorlagen beschreibt die Pflege dieses Arbeitsstands.

Bei einem System mit Dokumentensuche gehören die gefundenen Fundstellen zur Prüfung. Zwei Antworten mit unterschiedlichen Quellen sind zunächst zwei unterschiedliche Verarbeitungssituationen. Erst nach diesem Vergleich lässt sich beurteilen, ob die Formulierung oder bereits die Materialauswahl schwankt.

Warum die Textgenerierung variieren kann

Die Dokumentation von Hugging Face zu Generierungsstrategien unterscheidet unter anderem die Auswahl des wahrscheinlichsten nächsten Tokens von einer zufallsbasierten Auswahl aus einer Wahrscheinlichkeitsverteilung. Damit erklärt sie einen technischen Mechanismus für unterschiedliche Texte. Sie beschreibt nicht sämtliche internen Abläufe eines beliebigen gehosteten Assistenten.

Für die praktische Prüfung bedeutet das: Du darfst aus einem unveränderten Prompt keine Garantie für wortgleiche Antworten ableiten. Gleichzeitig erklärt der Mechanismus nicht jeden fachlichen Fehler. Eine mehrdeutige Aufgabenstellung, widersprüchliche Quellen oder eine veränderte Suchauswahl müssen getrennt untersucht werden.

Ich empfehle, zunächst beobachtbare Bedingungen zu erfassen. Spekulationen über interne Modellprozesse helfen wenig, wenn bereits der zweite Lauf eine andere Dokumentenversion verwendet. Technische Einstellungen sind nur ein Teil des Arbeitsprozesses.

Drei Arten von Abweichungen unterscheiden

Die erste Art betrifft die Oberfläche. "Die Freigabe fehlt" und "Eine Freigabe liegt nicht vor" sagen im betrachteten Fall dasselbe. Solange der Stil zur Aufgabe passt, entsteht daraus kein fachlicher Fehler.

Die zweite Art betrifft die Vollständigkeit. Zwei Antworten können jeweils richtige Aussagen enthalten, aber unterschiedliche offene Punkte nennen. Wenn eine Antwort eine notwendige Prüfung auslässt, reicht semantische Ähnlichkeit einzelner Sätze nicht aus.

Die dritte Art betrifft die Entscheidung. Ein Fall wird einmal als offen und einmal als freigegeben bezeichnet. Hier muss die Vorlage oder der Prozess vor dem Einsatz untersucht werden. Ein sprachlich eleganter Mehrheitsbefund repariert die falsche Entscheidung nicht.

Diese Ebenen gehören in die Abnahme vor dem ersten Test. Sonst wird eine unerwartete Ausgabe nachträglich so bewertet, dass sie zur eigenen Erwartung passt.

Der Übungsfall: Sechs Anfragen, fünf Läufe

Das fiktive Team klassifiziert Serviceanfragen als Störung, Bedienfrage, Änderungswunsch oder unklar. Die fachlichen Definitionen stehen im Prompt. Sechs Fälle decken eindeutige und unklare Meldungen ab. Eine Person legt die Soll-Kategorien fest, eine zweite prüft sie anhand derselben Definitionen.

Die fünf Läufe pro Fall sind ein überschaubarer Übungsumfang. Sie liefern keinen statistischen Nachweis für seltene Fehler. Bei einer Aufgabe mit hohen Fehlerkosten braucht die Prüfung mehr Abdeckung und eine fachlich begründete Einsatzgrenze.

Alle Läufe starten mit dem gleichen gespeicherten Material in getrennten Sitzungen. Wenn das Werkzeug diese Trennung nicht ermöglicht, wird die Einschränkung dokumentiert. Die Reihenfolge der Fälle bleibt zunächst fest, damit die erste Auswertung nicht mehrere Änderungen vermischt.

Ein vollständig gerechnetes Beispiel

In der synthetischen Auswertung sind A, B und C jeweils fünfmal richtig. D ist dreimal richtig und zweimal fälschlich eine Bedienfrage. E ist viermal richtig und einmal unklar. F ist fünfmal fälschlich ein Änderungswunsch.

Insgesamt sind 22 von 30 Ausgaben richtig, also rund 73,3 Prozent. Vier der sechs Fälle liefern in allen fünf Läufen dieselbe Kategorie. Davon ist einer durchgehend falsch. Genau deshalb müssen Richtigkeit und Stabilität getrennt ausgewiesen werden.

Eine reine Mehrheitsentscheidung erreicht im Beispiel fünf richtige Kategorien für sechs Fälle. Das klingt besser als 22 von 30 Einzelantworten, verschleiert aber die durchgehend falsche Behandlung von F. Außerdem benötigt dieses Verfahren fünf Ausgaben pro Fall. Der zusätzliche Aufwand gehört in die Entscheidung, wie der Artikel zum Prüfaufwand bei KI-Ausgaben zeigt.

Die Fehlerursache anhand eines Falls untersuchen

Bei F lautet die Meldung: "Wie speichere ich diese Ansicht?" Im fehlerhaften Beispielpaket kommt das Wort speichern nur in Änderungswünschen vor. Die Vorlage scheint daher eine ungewollte Zuordnung zu begünstigen. Das ist zunächst eine Hypothese, keine Beobachtung eines internen Modellmechanismus.

Zur Prüfung ergänzt das Team die Definition der Bedienfrage um den Unterschied zwischen Nutzung und Funktionswunsch. Anschließend ersetzt es ein redundantes Beispiel durch eine vorhandene Funktion, deren Bedienung unklar ist. Alle sechs Fälle werden erneut geprüft, zusätzlich kommen neue Fälle mit anderen Verben hinzu.

Wird F danach richtig behandelt, ist die Änderung im Test hilfreich. Der Befund beweist trotzdem nicht, dass die vermutete interne Ursache exakt getroffen wurde. Er zeigt eine beobachtete Verbesserung unter dokumentierten Bedingungen. Der Artikel zu Beispielen im Prompt erläutert die Auswahl solcher Gegenfälle.

Eine Änderung pro Vergleich

Wenn du gleichzeitig Modell, Prompt, Beispiele und Quellen änderst, bleibt die Ursache einer Verbesserung offen. Für eine kleine Fehleranalyse reicht deshalb ein Vergleich mit einer klar benannten Änderung. Die übrigen sichtbaren Bedingungen bleiben gleich.

Der Testbericht enthält die Ausgangsversion, die Änderung, die Erwartung und das Ergebnis. Eine geeignete Erwartung lautet: "F wird als Bedienfrage erkannt, ohne dass C als Änderungswunsch verloren geht." Diese Formulierung schützt vor einer Reparatur, die lediglich die Kategorien in die andere Richtung verschiebt.

Danach folgt ein neuer Fall, der noch nicht zur Optimierung genutzt wurde. Beispielsweise: "Wo finde ich die Filterverwaltung?" So wird zumindest geprüft, ob die Regel über den ursprünglichen Satz hinaus trägt. Eine kleine Zahl neuer Fälle bleibt eine begrenzte Prüfung, keine allgemeine Freigabe für alle Formulierungen.

Wenn die Quellen zwischen den Läufen wechseln

Bei einem Wissensassistenten beginnt die Analyse vor der Textgenerierung. Prüfe, welche Dokumente gefunden wurden, welche Versionen sie haben und ob die relevante Passage überhaupt enthalten war. Ein sprachlich genauer Prompt kann eine fehlende Fachquelle nicht ersetzen.

Ein Beispiel: Die Frage nach einer Pilotfreigabe führt einmal zu einer verbindlichen Entscheidung und einmal zu einer älteren Besprechungsnotiz. Die abweichenden Antworten entstehen dann möglicherweise bereits durch die Quellenauswahl. Der Test muss die Suchergebnisse und die Antwort getrennt erfassen.

Das Arbeitsmittel zur Auswahl der passenden Unterlagen hilft bei kontrollierten Dokumentenpaketen. Für ein produktives Suchsystem braucht die gleiche Logik zusätzlich eine nachvollziehbare Verbindung zwischen Frage, gefundenem Material und Ausgabe.

Wann menschliche Prüfung dauerhaft dazugehört

Ein System kann für eine Aufgabe hilfreich sein, obwohl seine Formulierungen variieren. Bei der Vorbereitung eines internen Entwurfs prüft eine Person das Ergebnis ohnehin. Die Abnahme richtet sich dann nach sachlicher Richtigkeit, Vollständigkeit und dem verbleibenden Aufwand.

Anders liegt der Fall, wenn eine Ausgabe automatisch eine Zusage, Buchung oder Änderung auslöst. Dort muss die Einsatzentscheidung die Fehlerfolgen und die vorhandenen Kontrollen berücksichtigen. Aus einem kleinen Klassifikationstest entsteht keine Freigabe für solche Aktionen.

Für die Serviceübung bleibt die Ausgabe ein Vorschlag. Unklare und mehrteilige Meldungen gehen zur fachlichen Prüfung. Das Team dokumentiert, welche Fälle außerhalb des getesteten Umfangs liegen. Diese Grenze ist konkreter als die pauschale Aussage, die KI ist zuverlässig.

Ein Abbruchkriterium für den Test festlegen

Vor dem Einsatz legt die fachliche Verantwortung fest, welcher Fehler den Versuch unterbricht. In der Serviceübung führt eine unklare Anfrage zunächst zur manuellen Prüfung. Eine automatische Zusage aus einer bloßen Klassifikation ist dagegen außerhalb des Auftrags und stoppt die Weiterverarbeitung.

Diese Regel gilt auch dann, wenn die übrigen Ausgaben richtig sind. Eine hohe durchschnittliche Trefferquote macht eine nicht freigegebene Aktion nicht zulässig. Der Testbericht nennt daher neben den Quoten jede Verletzung einer solchen Grenze einzeln.

Nach einer Korrektur wird der auslösende Fall zusammen mit benachbarten Gegenfällen erneut geprüft. Die Wiederaufnahme gilt nur für den dokumentierten Umfang. Eine bestandene Reparatur am Klassifikationsschema erweitert die Befugnisse des Systems nicht automatisch auf Versand, Terminbestätigung oder andere nachgelagerte Schritte.

Ein Prüfblatt für wiederkehrende Tests

Das Prüfblatt enthält Fall-ID, Soll-Ergebnis, zulässige Varianten, Quellenstand, Vorlagenversion, sichtbare Modellangabe, Laufnummer und Ist-Ergebnis. Die Fehlerbewertung nennt die praktische Folge. Ein fehlendes Komma erhält dadurch nicht dasselbe Gewicht wie eine erfundene Freigabe.

Wiederhole den Test bei einer relevanten Änderung: neue Vorlage, geänderte Fachregel, anderes Modell oder neue Suchkonfiguration. Bewahre alte Ergebnisse auf, damit ein Rückschritt sichtbar bleibt. Auch ein zunächst stabiler Fehler gehört in den Bestand, bis die fachliche Regel eindeutig umgesetzt ist.

Eine brauchbare Prüfung endet mit einer begrenzten Aussage: Welche Aufgabe wurde unter welchen Bedingungen geprüft, welche Abweichungen sind akzeptabel und welche verhindern den Einsatz? Diese Angaben tragen die Entscheidung besser als die Forderung nach identischen Antworten auf jeden wiederholten Prompt.

Quellenstand: 22.10.2026. Hugging Face: Dokumentation zu Greedy Search und Sampling geprüft. Beispiele, Arbeitsmittel und Rechenwerte sind eigene synthetische Ausarbeitungen; ihre Wirkung im jeweiligen Betrieb muss separat geprüft werden.