Deine Testumgebung wird dich anlügen, noch bevor dein Modell es tut

Dein Evaluations-Scoreboard besagte, dass beide Engines fehlgeschlagen sind.

Llama3.2 ist in 5 von 6 Fällen fehlgeschlagen. Anthropic Sonnet ist in 6 von 6 Fällen fehlgeschlagen.

Das Label lautete „malformed“. Aber die Ursachen waren unterschiedlich.

Ein Fehler war ein API-Fehler, weil das Guthaben aufgebraucht war. Ein Fehler wurde durch Terminal-Steuerzeichen eines CLI-Befehls verursacht, die den Text korrumpierten. Ein Fehler war gültiges JSON, das in Markdown-Code-Blocks eingeschlossen war, die der Parser nicht lesen konnte.

Wenn ich diese erste Zusammenfassung veröffentlicht hätte, hätte ich gelogen. Ich hätte den Modellen Fehler in meinem eigenen Code angelastet.

Ich habe diese Bugs gefunden, indem ich mir die Rohdaten angesehen habe, anstatt der Zusammenfassung zu vertrauen.

Der erste Bug trat auf, weil ich einen CLI-Subprozess verwendet habe, um Ollama aufzurufen. Der Befehl erzeugte Terminal-Animationen wie Spinner und Cursorbewegungen. Diese ANSI-Steuerzeichen landeten in meinen Daten. Der Parser sah unsichtbare Zeichen und stürzte ab.

Die Lösung: Wechsel von einem CLI-Subprozess zu einer direkten HTTP-API.

Der zweite Bug trat auf, weil LLMs JSON oft in Markdown-Code-Blocks einschließen. Mein Parser verwendete json.loads() auf dem Rohstring. Er sah die Backticks und schlug fehl.

Die Lösung: Eine Funktion hinzufügen, um Code-Fences vor dem Parsen zu entfernen.

Sobald ich die Pipeline korrigiert hatte, zeigten sich die tatsächlichen Ergebnisse.

Die Modelle waren nicht „tot“. Sie wurden lediglich durch die Testumgebung verfälscht. Nach der Korrektur wurde der Qualitätsunterschied zwischen den beiden Modellen sichtbar und messbar.

Lektionen für deine KI-Evaluations-Pipeline:

  • Behalte den Roh-Output. Wenn die Zusammenfassung „malformed“ meldet, ist der Roh-Output deine einzige Quelle der Wahrheit.
  • Protokolliere den Grund für das Scheitern. Sage nicht einfach nur „malformed“. Sage „API-Fehler“ oder „Parse-Fehler“.
  • Friere deine Teststandards ein. Ändere deine Regeln nicht, um Ergebnisse besser aussehen zu lassen.
  • Betrachte die Testumgebung als Teil des zu testenden Systems.

Das Modell ist nicht das Einzige, das auf dem Prüfstand steht. Dein Code auch.

Quelle: https://dev.to/kenielzep97/your-harness-will-lie-to-you-before-your-model-does-662

Optionale Lern-Community: https://t.me/GyaanSetuAi