Testen von KI-Modellen: Warum einfache Checks scheitern

Testen von KI-Modellen bedeutet, eine Magic Box zu bewerten: ein System, dessen Verhalten weder kontrolliert noch verstanden noch auf andere Weise als sicher bekannt ist. Weil kein Mensch die Konstruktion eines Machine-Learning-Modells vorgibt, reichen einfache Checks von Ausgaben nicht. Getestet wird durch Erleben, Erkunden und Experimentieren, während Inputs, Outputs, Trainingsdaten und Guardrails beobachtbar bleiben.

Das Wichtigste in Kürze

• Machine-Learning-Modelle entwirft kein bewusst handelnder Mensch; Michael Bolton vergleicht sie mit Petrischalen, aus denen man die Kultur nimmt, die einen Erreger am besten abtötet.
• Beim Testen von KI-Modellen sind einfache Checks von Funktionsausgaben aussichtslos, denn sie taugen nur für deterministische Software, die Entwickler verstehen und instrumentieren können.
• Wer sich bei wichtigen Aufgaben auf Magie verlässt, muss sie testen; ein lustiges Gedicht für die Weihnachtsfeier birgt kein Risiko, medizinische Ratschläge eines Bots ein großes.
• Testbarkeit entsteht auch ohne Quellcode, wenn Teams Inputs und Outputs überwachen und Trainingsdaten, Guardrails, Context Window sowie Aufrufe externer Services kennen; das verkleinert die Magie.
• Sprachmodelle täuschen wie ein Mentalist auf der Bühne, weil Textmuster nach Erkenntnis aussehen, die in Wahrheit erst beim Leser entsteht, der dem Output einen Sinn gibt.

Was hat das Testen von KI-Modellen mit Magie zu tun?

Wer sich ans Testen von KI-Modellen macht, steht vor einer Box, deren Innenleben niemand vollständig kennt. Michael Bolton nennt so ein System eine Magic Box und definiert den Begriff genau. Eine Box ist in dem Maß magisch, in dem ihr Verhalten weder kontrolliert noch verstanden noch auf andere Weise als sicher bekannt ist. Manche Boxen sind schwach magisch, manche stark. Ein Sprachmodell gehört zu den stark magischen. Die Frage, wie man Sprachmodelle testet, wird damit zur Frage, wie viel Magie man sich leisten will und was mit dem Rest passiert.

Der Begriff stammt aus einem Buch. Michael schreibt mit seinem Co-Autor seit rund 30 Jahren an „Taking Testing Seriously: The Rapid Software Testing Approach“, so richtig ernsthaft seit fünf Jahren. Kurz vor dem Ende fehlte noch ein Kapitel über KI, und beide wussten, dass es veraltet sein würde, bevor die Tinte trocken ist. Also schrieben sie ein Kapitel über Magie. Das sollte halten. Die Technik in der Box ändert sich ständig, das Problem bleibt: Man verlässt sich auf etwas, das man nicht versteht.

Schwache Magie gibt es überall, und meistens ist sie harmlos. Für Michael ist der Python-Interpreter eine Magic Box. Konzeptionell weiß er, wie er funktioniert, die Details kennt er nicht. Sein Verhalten kann er zum Teil steuern, das nimmt etwas Magie heraus. Sicher fühlt er sich vor allem wegen des sozialen Beweises. Eine weltweite Community nutzt Python, eine kleinere Gruppe versteht die Interna und hat sie im Griff. Zieht man das Kaninchen aus dem Hut und es ist eine Ratte, behebt jemand den Fehler. Genau das meint „auf andere Weise als sicher bekannt“. Ein Sprachmodell bietet davon viel weniger.

Machine-Learning-Modelle wachsen in Petrischalen

Normale Software baut ein Mensch, der vorgibt, was sie tun soll. Ein Machine-Learning-Modell entwickelt kein Mensch, der bewusst und absichtsvoll handelt. Michael beschreibt es mit einer Reihe von Petrischalen. Viele Kulturen wachsen nebeneinander, eine davon tötet ein fieses Bakterium ab, und die nimmt man heraus, weil sie am besten aussieht. Entworfen hat sie niemand. Sie wurde ausgewählt.

Mit solchen Modellen zu arbeiten ist, als suchte man nach guten Antibiotika in der Zeit vor der DNA-Analyse. Heute erklären Proteomik und Genomik ungefähr, welche Mechanismen hinter einem Antibiotikum stecken, und mit CRISPR lässt es sich sogar editieren. So weit sind wir bei Sprachmodellen nicht. Niemand weiß genau, wie sie funktionieren, und das bringt eigene Probleme und Risiken mit sich.

Ein zweiter Punkt kommt dazu. Den Quellcode dieser Modelle hat niemand, und selbst mit Quellcode bliebe ihr Verhalten zum Teil stochastisch. Für das Testen heißt das: Das Modell lässt sich nicht instrumentieren wie eigener Code. Die Magie muss von außen kleiner werden.

Solltest du dich auf Magie verlassen, wenn es darauf ankommt?

Michaels Antwort ist eine kurze Reihe von Prinzipien, und das erste ist das schärfste. Wenn dir etwas sehr wichtig ist, solltest du dich wahrscheinlich nicht auf Magie verlassen, um es zu bekommen. Ist es sehr wichtig und gibt es wirklich keinen anderen Weg, kannst du es mit Magie versuchen. Dann ist es aber deine Aufgabe, die Abhängigkeit davon so klein wie möglich zu halten.

Mit dem dritten Prinzip kommen die Tester ins Spiel. Wer für etwas Wichtiges Magie einsetzt, muss es testen, das verlangt die Verantwortung. Wer in der Softwarebranche arbeitet, hat eine Sorgfaltspflicht gegenüber den eigenen Kunden und deren Endkunden, und eine Magic Box setzt diese Pflicht nicht außer Kraft. Das vierte Prinzip folgt daraus: Wenn du testest, maximiere die Testbarkeit. Das fünfte regelt den Rest. Was sich nicht oder nicht gründlich genug testen lässt, braucht einen Haftungsausschluss. Und selbst dann bleibt die Verantwortung bei dem, der es anderen Leuten vorsetzt.

Wie hart diese Prinzipien greifen, hängt am Risiko. Ein Modell, das für die Weihnachtsfeier ein lustiges Gedicht über einen Kollegen schreibt, trägt kein Risiko. Gefällt dir das Gedicht nicht, wirfst du es weg. Ein Bot, der medizinische Ratschläge gibt, trägt ein großes. Dort ist es klug, genau festzulegen, was der Bot sagen darf, oder magische Technologie an dieser Stelle ganz zu meiden.

Wie lässt sich die Testbarkeit eines LLM-Systems erhöhen?

Vieles, was Tester unter Testbarkeit verstehen, fällt hier weg, weil sich das Modell selbst nicht instrumentieren lässt. Was bleibt, ist die Box um das Modell herum. Michael zählt auf, was ein Team beobachten und steuern kann:

• Inputs und Outputs, genau überwacht
• die Trainingsdaten, die in das Modell eingeflossen sind
• die Guardrails auf beiden Seiten, vor dem Prompt und nach der Response
• das Context Window mit seiner Größe, seinem Inhalt und dem, was per Retrieval hineingeholt wurde
• die Aufrufe des Systems an Datenbanken und externe Services

Jeder Punkt auf dieser Liste, den ein Team kennt, steuert und beobachtet, nimmt der Box etwas Magie. In der Mitte steckt ein GPT, und das lässt sich nicht öffnen. In die größere Box drumherum kann man aber kleine Fenster einbauen, Sonden setzen oder kleine Kameras hineinstecken. Die Testbarkeit eines KI-basierten Systems entsteht vor allem auf dieser Ebene.

Daraus folgt noch etwas. Alles in einem KI-basierten System, was ganz normale, klassische Software ist, lässt sich testen wie Software schon immer. Die deterministischen Teile, das Retrieval, die Anbindungen: alles prüfbar. Nur das Modell in der Mitte braucht einen anderen Zugang.

Warum einfache Checks bei Sprachmodellen scheitern

Testen auf Checks von Funktionsausgaben zu reduzieren, war schon immer ein enges Bild vom Job. Michael hält es für nützlich, vor allem für Entwickler, die deterministische Software verstehen und instrumentieren können. Gegen ein LLM ist es hoffnungslos. Ein Check setzt voraus, dass dieselbe Eingabe dieselbe Ausgabe liefert und ein einzelner erwarteter Wert die Sache klärt. Ein Sprachmodell bricht beide Annahmen.

Was trägt, ist die Definition von Testen, die Michael und seine Kollegen über viele Jahre verfeinert haben: ein Produkt bewerten, indem man es kennenlernt, durch Erleben, Erkunden und Experimentieren. Mit dieser Definition wird alles testbar, auch eine Magic Box. Erfahrung damit sammeln geht immer. Es bewerten, indem man etwas darüber lernt, auch. Experimente damit laufen lassen ebenso. Der Prozess ist von Natur aus explorativ, weil es keinen vorgegebenen Weg gibt, etwas kennenzulernen, das noch niemand richtig kennt.

Teams merken diese Verschiebung in der Praxis. Manche, die sich ohnehin von geskripteten Testfällen wegbewegen, stellen sich mit dem Aufkommen von KI wieder die Fragen, die immer schon die richtigen waren. Welche Risiken gibt es? Welche Qualität wollen wir? Was bedroht den Wert des Produkts für die Menschen, die uns wichtig sind? Tester stellen diese Fragen schon ewig. Mit KI hören mehr Leute zu.

Ein Sprachmodell testen ist wie Zwiebelschälen

Michaels eigene Experimente mit Sprachmodellen laufen iterativ und arbeiten sich spiralförmig nach innen. Er vergleicht sie mit dem Schälen einer Zwiebel. Je mehr man schält, desto mehr scheint da zu sein, unter jeder Schicht noch eine. Wie in der Szene aus Peer Gynt, in der der Held eine Zwiebel schält, Schicht um Schicht findet und zu dem Schluss kommt, die Natur sei witzig.

Unter den Schichten kommen Muster von Inkonsistenz und Unzuverlässigkeit zum Vorschein, und zwar auf der untersten Ebene, wenn man das Modell direkt abfragt. In Michaels Experimenten läuft Haiku 4.5 viel schneller und viel bizarrer aus dem Ruder als Haiku 3.5. Interessanter ist der zweite Befund: Alle Modelle tun das. Michael vermutet, dass genau das hinter der Klage mancher Leute steckt, Claude Code sei früher gut gewesen und in letzter Zeit ziemlich mies geworden. Das Verhalten ganz unten erklärt nicht, warum das passiert. Wie es sich auswirkt, kann man aber genau beobachten.

Zwei Dinge machen diese Arbeit praktikabel. Erstens ein experimentelles Framework, das dieselben Experimente immer wieder ausführt, damit Muster und seltsame Ausreißer sichtbar werden und Software hilft, sie aufzuspüren. Zweitens Tools, die Masse erzeugen. Ein Sprachmodell verlangt so viel statistische Analyse, dass alles jenseits eines allerersten Hürdentests große Mengen generierter Requests und Responses braucht. Ausgerechnet ein LLM eignet sich gut dafür. Es generiert Unmengen von Varianten derselben Frage, und du beobachtest, was sich in den Antworten ändert. Ein einziges zusätzliches oder geändertes Wort kann die Ausgabe dramatisch beeinflussen. Tester wollen wissen, wie stark, wie oft und wie weit sich dabei die Bedeutung umkehrt.

Die kleinste Kleinigkeit bewirkt manchmal gar nichts und manchmal ein völlig bizarres neues Verhalten. Diese Unberechenbarkeit hält die Arbeit explorativ. Eine Beobachtung führt zu einer Hypothese, die Hypothese zu einem neuen Vorgehen, das Vorgehen zu einer neuen Entdeckung.

Wie täuschen uns Sprachmodelle wie ein Mentalist?

Mechanisch reiht ein Sprachmodell einen Token an den nächsten. Stephen Wolframs Essay „What Is ChatGPT Doing and Why Does It Work?“ erklärt diese Seite gut. Die psychologische Seite behandelt ein Essay von Baldur Bjarnason mit dem Titel „The LLMentalist Effect“. Er beschreibt, wie Large Language Models die Mechanismen der Hellseher-Masche nachbilden. Michael empfiehlt beide Texte allen Testern, die mit diesen Systemen arbeiten.

Die Masche geht so. Ein Cold Reader sagt schnell etwas und hofft auf einen Treffer. Letzte Woche war ein bisschen stressig für dich. Irgendwann gab es eine technische Komplikation, Mittwoch oder Donnerstag, irgendeine Software, die dich eine halbe Stunde gekostet hat. Ob das stimmt, ist egal. Spannend ist, was dabei in deinem Kopf passiert: Du versuchst sofort, die Aussage einem Ereignis zuzuordnen. Textmuster lassen uns glauben, da stecke Erkenntnis drin, wo keine ist. Die Erkenntnis, die entsteht, kommt aus unserer eigenen Anstrengung, die Ausgabe zu deuten und ihr einen Sinn zu geben.

Michaels Lieblingszauberer sind Penn & Teller, weil sie oft genau zeigen, wie ein Trick funktioniert. Ihre Nummer mit Bechern und Bällen spielen sie mit durchsichtigen Plastikbechern, das Publikum sieht jede Bewegung. Man sieht, wie clever Zauberer sind, und man sieht, wie leicht man sich täuschen lässt. Wer den Mechanismus kennt, fällt seltener herein, wenn jemand einen anderen Trick vorführt. Bei Technologie ist es genauso. Wer versteht, wie ein Sprachmodell mechanisch funktioniert und was es mit dem menschlichen Kopf macht, lässt sich schwerer täuschen. Dann geht die Anerkennung dorthin, wo sie hingehört, zu den Menschen, die denken. Und das Gespräch mit dem Kunden kann sich der praktischen Frage zuwenden. Liefert dieses Ding konsistente, zuverlässige Ergebnisse, und spielt Zuverlässigkeit in diesem Fall überhaupt eine Rolle?

Tester werden dafür bezahlt, für andere zu lernen

Die Art von Testen, die ein Produkt untersucht, mit besonderem Fokus auf der Suche nach Problemen, ist für KI bereit. Michael sieht das Testen gerade im Rampenlicht. Die enge Version des Jobs, Ausgaben gegen erwartete Werte prüfen, hat gegen eine Magic Box keine Chance. Die breite Version hat alles, was sie braucht, dazu Tools, um sie zu skalieren.

„Wir werden dafür bezahlt, Dinge stellvertretend für andere Leute zu lernen. Was gibt’s für einen besseren Job?“

(Michael Bolton)

Testen hat schon immer Spaß gemacht, wenn man es richtig macht. Wessen Team klagt, KI sei nicht testbar, dem rät Michael: die Technologie verstehen, sich damit auseinandersetzen, Tools nutzen und die Risikofrage vor alles andere stellen. Wo viel auf dem Spiel steht, lieber weniger Magie. Wo Magie unvermeidlich ist, testen, für das nicht Testbare die Haftung ausschließen und die Verantwortung tragen, die bleibt.