Wenn ein KI-Skript läuft und trotzdem falsche Ergebnisse liefert

Ein KI-generiertes Skript kann ohne Fehlermeldung laufen und trotzdem ein falsches Ergebnis liefern. Der erfolgreiche Prozessabschluss zeigt zunächst nur, dass keine entsprechend behandelte Laufzeitstörung auftrat. Fachliche Richtigkeit braucht eigene Prüfungen: erwartete Zuordnungen, nachvollziehbare Summen und Regeln, die bei unzulässigen Ergebnissen tatsächlich stoppen.

Dieser Artikel entwickelt einen eigenen Prüfablauf anhand einer fiktiven Datenverknüpfung. Das Beispiel verwendet Rechnungen und Kundenzuordnungen. Es ist keine Buchhaltungssoftware und enthält keine echte Kundendatei. Die Grundidee lässt sich auf viele Datenaufgaben übertragen, muss aber an deren fachliche Regeln angepasst werden.

Den Unterschied zwischen Laufzeit und Bedeutung verstehen

Ein Programm kann eine Tabelle erfolgreich lesen, zwei Listen verbinden und eine Datei schreiben. Wenn der verwendete Schlüssel nicht eindeutig ist, entstehen dabei möglicherweise zusätzliche Zeilen. Für die Programmbibliothek ist diese Operation zulässig. Für die fachliche Aufgabe kann sie falsch sein.

Das gleiche Problem entsteht bei einem Filter, der gültige Fälle ausschliesst, oder bei einer Datumsspalte, die anders interpretiert wird als erwartet. Eine syntaktische Prüfung findet solche Fehler nicht automatisch. Der Code erfüllt seine technische Anweisung, aber die Anweisung passt nicht zum gewünschten Ergebnis.

Beginne deshalb mit einer fachlichen Beschreibung von Eingabe und Ausgabe. Welche Einheit beschreibt eine Zeile? Welche Zuordnung ist erlaubt? Welche Werte müssen erhalten bleiben? Diese Fragen bilden die Prüfbasis, bevor die KI Code erzeugt oder ein bestehendes Skript verändert.

Ein fiktiver Bestand mit drei Rechnungen

Die Rechnungsliste enthält R1 über 100 Euro für Kunde K1, R2 über 200 Euro für K2 und R3 über 50 Euro für K3. Die Ausgangssumme beträgt 350 Euro. Jede Rechnung besitzt eine eindeutige Kennung. Das Ziel ist eine Anreicherung mit einer Kundengruppe, ohne zusätzliche Rechnungen zu erzeugen.

Die Stammdatentabelle enthält K1 einmal, K2 jedoch zweimal mit unterschiedlichen Gruppen. K3 fehlt. Ein unkontrollierter Join kann deshalb R2 verdoppeln und R3 je nach Verknüpfungsart entfernen. Beide Fehler entstehen aus der Zuordnung, nicht aus einer falschen Addition.

Eine korrekte Verarbeitung des Beispiels meldet die beiden Zuordnungsprobleme. Sie erklärt den Bestand nicht als vollständig angereichert. Wenn die fachliche Regel eine eindeutige Kundengruppe verlangt, bleibt die nachgelagerte Gesamtauswertung bis zur Klärung gesperrt.

Warum eine plausible Summe täuscht

Ein Left Join mit beiden K2-Zeilen liefert vier Ergebniszeilen und eine Summe von 550 Euro. R2 steht doppelt im Ergebnis. Ein Inner Join mit derselben fehlerhaften Stammdatentabelle liefert drei Zeilen und 500 Euro, weil zusätzlich R3 entfällt. Die scheinbar unveränderte Zeilenzahl drei verdeckt hier zwei gegenläufige Fehler.

Nach einer fachlich korrekten Bereinigung von K2, aber weiterhin fehlendem K3, liefert ein Inner Join nur R1 und R2 mit zusammen 300 Euro. Ein Left Join erhält alle drei Rechnungen und 350 Euro, zeigt jedoch weiterhin die fehlende Gruppe bei R3. Die Summe allein beweist also keine vollständige Zuordnung.

Diese Varianten zeigen, warum mehrere Kontrollen nötig sind. Prüfe eindeutige Rechnungskennungen, Zeilenzahl, Betragssumme und Zuordnungsstatus. Jede Kontrolle erfasst eine andere Eigenschaft. Ein einzelnes grünes Ergebnis darf die übrigen offenen Prüfungen nicht ersetzen.

Bibliotheksfunktionen gezielt für Prüfungen nutzen

Die pandas-Dokumentation zu merge beschreibt Prüfoptionen für die Kardinalität einer Verknüpfung und einen Indikator für die Herkunft der Ergebniszeilen. Sie weist auch auf das besondere Verhalten bei leeren Schlüsseln hin. Diese Funktionen helfen bei technischen Kontrollen; die richtige fachliche Beziehung muss dein Team festlegen.

Im Beispiel erwartet jede Rechnung genau eine passende Stammdatenzeile, während mehrere Rechnungen zum selben Kunden gehören dürfen. Das entspricht einer Many-to-one-Beziehung von Rechnungen zu Stammdaten. Eine Prüfung dieser Beziehung muss die doppelten K2-Stammdaten zurückweisen, statt sie still zu übernehmen.

Ein erlaubter Many-to-many-Join ist kein allgemeiner Ausweg aus einer Fehlermeldung. Wenn das Fachmodell Eindeutigkeit verlangt, muss der Datenfehler geklärt werden. Eine gelockerte Prüfeinstellung ändert die fachliche Anforderung nicht. Der Beitrag zum Abgleich von Excel-Listen erläutert dieselbe Schlüsselprüfung ohne Bindung an ein einzelnes Werkzeug.

Soll-Ergebnisse unabhängig vom Skript bestimmen

Ein Test ist wenig aussagekräftig, wenn die KI erst den fehlerhaften Code und danach eine passende Erwartung aus demselben Code erzeugt. Das Soll-Ergebnis muss aus der Aufgabenbeschreibung und einem nachvollziehbaren kleinen Datensatz kommen. Für das Beispiel lässt es sich von Hand überprüfen.

Schreibe deshalb die erwarteten Rechnungskennungen und Summen vor dem Lauf auf. Halte ausserdem fest, welche Fehler gemeldet werden müssen. Der korrekte Test für die ursprünglichen Stammdaten erwartet keine erfolgreiche vollständige Anreicherung, sondern eine Sperre wegen Mehrdeutigkeit und eine sichtbare fehlende Zuordnung.

Eine zweite Person kann diese kleine Referenzrechnung unabhängig prüfen. Bei komplexeren Aufgaben braucht es entsprechend andere belastbare Vergleichswege. Die Unabhängigkeit der Erwartung ist wichtiger als die Zahl automatisch erzeugter Tests, die alle denselben Denkfehler wiederholen.

Invarianten als fachliche Grenzen formulieren

Eine Invariante ist hier eine Eigenschaft, die unter der erlaubten Verarbeitung erhalten bleiben muss. Im Beispiel darf jede Rechnungskennung nach der reinen Anreicherung höchstens einmal vorkommen. Die Betragssumme darf sich durch das Hinzufügen einer Kundengruppe nicht ändern. Ungeklärte Zuordnungen müssen sichtbar bleiben.

Diese Regeln gelten für den beschriebenen Zweck. Bei einer bewusst positionsweisen Aufteilung kann eine Rechnung mehrfach erscheinen, dann braucht die Aufgabe ein anderes Modell und eine andere Summenkontrolle. Übertrage Invarianten deshalb nicht blind auf einen veränderten Verwendungszweck.

Fehlende Werte gehören ausdrücklich in die Regeln. Wenn eine unbekannte Kundengruppe als leere Zelle vorliegt, darf eine nachgelagerte Gruppierung die zugehörige Rechnung nicht unbemerkt aus dem Bericht entfernen. Der Artikel Fehlende Werte sind keine Nullen ergänzt diese Bedeutung von fehlenden Daten.

Tests nach Fehlerarten zusammenstellen

Der Testsatz enthält einen korrekten Standardfall, einen doppelten Stammdatenschlüssel, einen fehlenden Schlüssel und eine leere Eingabe. Hinzu kommen eine Rechnung mit null Euro und ein zulässiger negativer Betrag, sofern das Fachmodell solche Werte erlaubt. Die erwartete Behandlung wird jeweils vorher festgelegt.

Die pytest-Dokumentation zur Parametrisierung beschreibt, wie mehrere Eingaben und erwartete Ergebnisse systematisch durch denselben Test geführt werden. Sie belegt das technische Verfahren, nicht die Vollständigkeit deines Testsatzes. Die Auswahl fachlich relevanter Fälle bleibt eine eigene Aufgabe.

Ein Test darf nicht lediglich prüfen, dass eine Datei existiert oder dass das Skript den Rückgabecode null liefert. Solche Prüfungen sind für den technischen Ablauf sinnvoll, sagen aber nichts über die Zuordnung von R2 und R3. Die fachlichen Assertions müssen den tatsächlichen Inhalt kontrollieren.

Veränderungen nutzen, deren Wirkung bekannt ist

Zusätzlich helfen gezielte Varianten des gleichen Datensatzes. Wenn nur die Reihenfolge der Rechnungen verändert wird, müssen Kennungen, Beträge und Zuordnungsstatus gleich bleiben. Ein anderes Ergebnis zeigt eine unerwartete Abhängigkeit von der Reihenfolge.

Wenn eine neue, eindeutig zuordenbare Rechnung über 25 Euro hinzugefügt wird, muss die Kontrollsumme um genau 25 Euro steigen. Diese Variante prüft eine bekannte Beziehung zwischen Eingabe und Ausgabe. Sie ersetzt die Einzelfallkontrolle nicht, ergänzt sie aber um eine andere Perspektive.

Eine Verdopplung der gesamten Eingabe hat dagegen nur dann eine eindeutige Erwartung, wenn der Umgang mit doppelten Rechnungskennungen feststeht. Im Beispiel muss sie eine Dublettenmeldung auslösen. Einfach die doppelte Summe als Sollwert einzusetzen, verletzt die fachliche Identitätsregel.

Fehler nicht durch automatische Bereinigung verdecken

Eine KI schlägt bei doppelten Schlüsseln möglicherweise vor, einfach die erste Zeile zu behalten. Das ist nur zulässig, wenn eine fachliche Regel genau diese Auswahl begründet. Bei unterschiedlichen Kundengruppen entscheidet die Reihenfolge der Datei sonst über das Ergebnis.

Auch das Auffüllen fehlender Gruppen mit einem plausiblen Standardwert verändert den Inhalt. Ein ausdrücklich definierter Status "nicht zugeordnet" kann sinnvoll sein. Er muss jedoch von einer echten Kundengruppe unterscheidbar bleiben und in der weiteren Auswertung sichtbar berücksichtigt werden.

Der Auftrag an die KI lautet deshalb: "Erkläre den verletzten Datenvertrag und schlage eine Prüfung vor. Ergänze keine fachlichen Werte ohne Quelle. Entferne keine Datensätze, nur damit die Verarbeitung ohne Fehler endet." Eine Korrektur muss den Zweck wiederherstellen, nicht bloss die Fehlermeldung beseitigen.

Im laufenden Betrieb dieselben Grenzen beobachten

Auch nach bestandenen Tests können neue Eingaben andere Fehler erzeugen. Pro Lauf werden deshalb geeignete Kontrollwerte erfasst: Eingangsmenge, eindeutige Kennungen, offene Zuordnungen und relevante Summen. Welche Werte gespeichert werden, richtet sich nach Datenminimierung und betrieblichem Bedarf.

Ein auffälliger Lauf darf keine nachgelagerte Aktion auslösen, bevor der Fehler geklärt ist. Wenn der Bericht bereits verteilt wurde, braucht es einen dokumentierten Korrekturweg. Der Beitrag zum KI-Vorfallbericht beschreibt die dafür notwendigen Angaben zu Wirkung und Bearbeitung.

Trenne technische Überwachung von fachlicher Prüfung. Ein erreichbarer Dienst und kurze Laufzeiten sind gute Betriebsinformationen. Sie zeigen nicht, ob die neue Kundendatei doppelte Schlüssel enthält. Beide Ebenen müssen vorhanden sein, wenn das Ergebnis betrieblich genutzt wird.

Die Korrektur mit einem Regressionstest abschliessen

Nach der Fehlerbehebung läuft der ursprüngliche Problemfall erneut. Zusätzlich werden die bisher richtigen Fälle geprüft. So zeigt sich, ob die Änderung das konkrete Problem löst und andere erlaubte Eingaben weiterhin korrekt verarbeitet. Ein bestandener Einzeltest reicht bei einer veränderten Verknüpfungslogik nicht aus.

Für das Beispiel muss die korrigierte Fassung doppelte K2-Zuordnungen stoppen und K3 als ungeklärt ausweisen. Nach einer fachlich bestätigten Stammdatenkorrektur liefert sie genau R1, R2 und R3 mit 350 Euro. Die Prüfung bestätigt dann Inhalt und Grenzen des Ergebnisses.

Ein Skript ist für seinen definierten Einsatz freigegeben, wenn die erwarteten Inhalte stimmen, unerlaubte Fälle erkannt werden und der Betrieb diese Grenzen überwacht. Der erfolgreiche Programmlauf bleibt ein notwendiger technischer Befund. Die fachliche Abnahme entsteht erst aus den unabhängig geprüften Ergebnissen.

Den Fehler bis zur fachlichen Aussage zurückverfolgen

Wenn die falsche Tabelle bereits in einen Bericht eingeflossen ist, endet die Korrektur nicht beim Skript. Prüfe, welche Aussagen aus dem fehlerhaften Ergebnis abgeleitet wurden. Im Beispiel verändert die Verdopplung von R2 möglicherweise die Gewichtung der Kundengruppen. Eine korrigierte Gesamtsumme allein repariert diese Interpretation nicht automatisch.

Der Bericht erhält einen nachvollziehbaren neuen Stand. Die zuständige Person sieht, welche Daten und Schlussfolgerungen sich ändern. Eine automatische Überschreibung ohne Hinweis erschwert die Einordnung bereits getroffener Entscheidungen. Der Korrekturweg muss deshalb zum tatsächlichen Verwendungszweck des Berichts passen.

Halte ausserdem fest, welcher Test den Fehler künftig erkennt. Für die doppelte K2-Zuordnung ist das die Eindeutigkeitsprüfung der Stammdaten und die Kontrolle der Rechnungskennungen. Ein allgemeiner Test auf Dateigrösse trägt dazu nichts bei. Die neue Prüfung wird zusammen mit dem Fehlerfall gespeichert.

So entsteht aus dem Vorfall eine konkrete Verbesserung der Abnahme. Die Dokumentation muss nicht lang sein, aber sie verbindet Ursache, betroffene Ergebnisse, Korrektur und Regressionstest. Ein Kommentar im Code mit dem Hinweis auf ein früheres Problem ersetzt diese überprüfbare Verbindung nicht.

Quellenstand: 23.10.2026. pandas und pytest belegen die genannten technischen Prüfmechanismen. Datensätze, Rechnungen, Invarianten und Abnahmeregeln sind eigene methodische Vorschläge, keine Aussage über eine geprüfte Produktivimplementierung.