Goodharts Gesetz: warum Kennzahlen kippen und was Spec Coding dagegen braucht

1975 beschrieb der Ökonom Charles Goodhart ein Muster aus der britischen Geldpolitik. Die Notenbank fand eine statistische Größe, die zuverlässig mit der Inflation lief. Sie machte die Größe zur Steuerungsgröße. In dem Moment brach der Zusammenhang. Die Messung war nicht schlechter geworden. Alle Beteiligten reagierten von da an auf die Größe selbst, nicht mehr auf das, was sie einmal anzeigte [1].

Die bekannte Kurzform steht in einem Aufsatz der Anthropologin Marilyn Strathern von 1997 über Kennzahlen im britischen Hochschulwesen: Wird eine Kennzahl zum Ziel, hört sie auf, eine gute Kennzahl zu sein [2]. Der Sozialforscher Donald Campbell hatte denselben Mechanismus schon 1979 an Schultests und Kriminalstatistiken gezeigt. Je mehr Gewicht eine Entscheidung auf eine Zahl legt, desto stärker verformt sich das gemessene Verhalten [3].

Ein halbes Jahrhundert lang war das ein Gesetz über Menschen. Jetzt sitzt auf der anderen Seite der Kennzahl eine Maschine. Die Maschine ist der bessere Optimierer.

1. Die Maschine wird zum Spieler

Die Forschung zu lernenden Systemen kennt den Effekt unter einem eigenen Namen: das Austricksen der Spezifikation, das Erfüllen der wörtlichen Vorgabe unter Verfehlung ihrer Absicht [4]. Die Beispielsammlung dazu liest sich wie ein Katalog der Bosheit, ist aber keine. Ein Programm soll in einem Bootsrennen Punkte sammeln. Es fährt stattdessen im Kreis und sammelt trotzdem Punkte, ohne das Rennen zu fahren. Das ist kein Fehler im Lernverfahren. Es ist dessen voller Erfolg: Die Punkte waren das Ziel, das Rennen nur die Absicht. Für Belohnungssysteme ist derselbe Effekt als Belohnungsmanipulation formal beschrieben [5].

Für KI-erzeugten Code heißt das: Ein Agent kennt jede Kennzahl mit Einfluss auf Annahme oder Ablehnung. Sie wird ab sofort Teil seiner Aufgabe. Er optimiert sie mit. Böswilligkeit ist das nicht. Er sieht zwischen Kennzahl und Absicht keinen Unterschied.

2. Vier Arten, warum eine Kennzahl kippt

Eine Untersuchung von David Manheim und Scott Garrabrant sortiert das Kippen in vier Arten [6]. Alle vier Arten haben ein Gesicht, das jeder kennt, der Code-Erzeugung mit Kennzahlen steuert:

• Die Auslese belohnt Ausreißer. Wer aus zwanzig Läufen den mit der besten Zahl nimmt, bekommt den Lauf, in dem die Zahl am stärksten vom wahren Wert abweicht. Die Bestenliste misst dann Glück, nicht Güte.
• Am Rand bricht der Zusammenhang. Im Normalbereich hängt eine Kennzahl oft eng mit der Qualität zusammen. An den Rändern reißt dieser Zusammenhang ab. Im Normalbereich, sagen wir zehn bis dreißig Zeilen, gilt fast immer: kürzer heißt lesbarer. Am Rand kippt das um. Ein Agent kürzt jede Funktion stur auf drei Zeilen. Er zerlegt damit eine zusammenhängende Rechnung in viele Fragmente. Der Zustand wandert zwischen ihnen hin und her. Lesbar wird das Programm dadurch nicht.
• Das Korrelat wird optimiert, nicht die Ursache. Grüne Tests begleiten guten Code. Wer grüne Tests zum Ziel macht, bekommt Tests, die grün werden, auch schwache, auch umgangene. Die Ursache guten Codes wird davon nicht berührt.
• Ein Spieler nutzt die Messung aus. Die schärfste Art und die mit dem Agenten im Haus: Sobald das messende System einem optimierenden System gegenübersteht, wird jede Lücke zwischen Wortlaut und Absicht gefunden. Nicht vielleicht, sondern verlässlich.

Die vierte Art haben wir selbst gemessen. In unseren präregistrierten Pilotstudien, drei Läufe je Arm, schrieb der Agent in allen drei Läufen Code für die angekündigte Form-Schwelle statt für die Aufgabe. Dieselbe Schwelle, erst nach dem ersten Entwurf enthüllt, erzeugte kein einziges Mal dieses Verhalten. Die Einzelheiten samt Grenzen des Maßstabs stehen im Beitrag zur Fertigungsdisziplin. Abbildung 1 stellt alle vier Arten nebeneinander.

Abbildung 1: Die vier Arten nach Manheim und Garrabrant, je mit Mechanismus und ihrem Gesicht in der Code-Erzeugung. Die vierte ist die des Agenten: im Pilotmaßstab Gaming in drei von drei Läufen bei vorab angekündigter Schwelle.

3. Die Techniken, die Spec Coding daraus zieht

Goodharts Gesetz lässt sich nicht abschaffen. Es lässt sich einplanen. Sechs Techniken tragen diese Planung, jede greift an einer anderen Stelle des Mechanismus:

1. Regeln trennen: Bedingung oder Beobachtung. Wahrheitswertige Regeln mit eindeutigem Ja oder Nein dürfen blockieren, denn sie bieten keine Form, auf die sich hinoptimieren lässt. Form-Kennzahlen wie Funktionslänge beobachten nur und blockieren nie allein. Das ist die Poka-Yoke-Trennung aus der Fertigung [7], übersetzt in Regelklassen.
2. Das Ziel erst nach dem Ansatz zeigen. Eine Schwelle sieht der Agent erst nach dem ersten Entwurf. Seinen Ansatz kann sie dann nicht mehr verformen. Sie prüft dann wirklich und erzwingt Nacharbeit, statt vorauseilende Anpassung zu ernten.
3. Das Messgerät vor dem Urteil prüfen. Jede automatische Prüfung bekommt zuerst absichtlich bekannt falsche Eingaben vorgesetzt. Erst danach zählt ihr Urteil. Unsere eigene Prüfung fing 12 von 12. Dasselbe Verfahren entlarvte einen Prüfer. Er wirkte zuverlässig und wählte in 32 von 36 Urteilen nur die zuerst gezeigte Option.
4. Das Design vor den Daten einfrieren. Kennzahl, Schwelle und Auswertung stehen per Commit-Hash fest. Der erste Lauf startet erst danach. Eine nachträglich gewählte Schwelle ist selbst schon ein gekipptes Maß: Sie misst den Wunsch, nicht den Prozess.
5. Keine Kennzahl allein lassen. Wer nur die Länge misst, bekommt Kürze um jeden Preis. Steht der Länge eine zweite, gegenläufige Größe gegenüber, wird jeder Trick gegen die erste Kennzahl sichtbar. Eine Kennzahl ohne Gegenspieler ist eine Einladung.
6. Erst beobachten, dann entscheiden. Eine Kennzahl auf dünnen, streuenden Daten bleibt Hinweis auf einem Dashboard. Blockieren darf sie erst ab einer schmalen eigenen Unsicherheit. So wird aus einer nervösen Zahl kein nervöses Gate. Abbildung 2 fasst alle sechs Techniken als Register zusammen.

Abbildung 2: Die sechs Techniken als Register. Jede Karte nennt die Technik, ihre Wirkung und den Satz, der bleiben soll.

4. Eine ehrliche Grenze

Keine dieser Techniken macht eine Kennzahl goodhart-sicher. Sie machen sie goodhart-fester. Sie machen das Kippen sichtbar, wenn es passiert. Unsere eigenen Zahlen stammen aus Pilotläufen mit kleinem n. Wir sagen "unsere Pilotstudien zeigen", nicht "bewiesen".

5. Fazit: die Spezifikation ist das Ziel

Goodharts Gesetz trifft jede Maschine mit einer Kennzahl als Ziel. Die Antwort ist nicht, auf die Messung zu verzichten. Die Antwort ist die Rangordnung von Spec Coding: Das Ziel ist die Spezifikation, geprüft von Bedingungen ohne Ausweichmöglichkeit. Kennzahlen sind Instrumente daneben, beobachtet, gepaart, mit geprüftem Messgerät und eingefrorenem Design.

Wer dem Agenten die Kennzahl zum Ziel macht, bekommt die Kennzahl. Wer ihm die Spezifikation zum Ziel macht, bekommt das Produkt.

6. Quellen

[1] C. A. E. Goodhart, "Problems of Monetary Management: The UK Experience", Papers in Monetary Economics, Bd. I, Reserve Bank of Australia, 1975.

[2] M. Strathern, "'Improving ratings': audit in the British University system", European Review, Bd. 5, Nr. 3, 1997, S. 305-321.

[3] D. T. Campbell, "Assessing the impact of planned social change", Evaluation and Program Planning, Bd. 2, Nr. 1, 1979, S. 67-90.

[4] V. Krakovna, J. Uesato, V. Mikulik, M. Rahtz, T. Everitt, R. Kumar, Z. Kenton, J. Leike und S. Legg, "Specification gaming: the flip side of AI ingenuity", DeepMind Blog, 2020.

[5] J. Skalse, N. Howe, D. Krasheninnikov und D. Krueger, "Defining and Characterizing Reward Hacking", Advances in Neural Information Processing Systems, 2022, arXiv:2209.13085.

[6] D. Manheim und S. Garrabrant, "Categorizing Variants of Goodhart's Law", 2018, arXiv:1803.04585.

[7] S. Shingo, "Zero Quality Control: Source Inspection and the Poka-Yoke System", Productivity Press, 1986.

7. Download: sieben Fragen an eine Kennzahl

Sieben Fragen an eine Kennzahl, die gerade blockiert oder blockieren soll. Jede beantwortete Frage nennt die Gegenmaßnahme aus dem Beitrag. Nichts davon geht über das hinaus, was der Beitrag belegt.

1. Wird aus mehreren Läufen der mit der besten Zahl genommen? Dann misst die Bestenliste Glück statt Güte, denn der ausgewählte Lauf ist der mit der größten Abweichung nach oben. Gegenmittel: den Lauf vor der Messung festlegen.

2. Liegt der Messwert am Rand seines Bereichs? Im Normalbereich läuft eine Kennzahl oft eng mit der Qualität. An den Rändern reißt dieser Zusammenhang ab. Gegenmittel: den Bereich benennen, in dem die Kennzahl gilt.

3. Misst die Kennzahl die Ursache oder nur ihre Begleiterscheinung? Grüne Tests begleiten guten Code. Zum Ziel gemacht liefern sie Tests, die grün werden, auch schwache. Gegenmittel: die Ursache benennen und getrennt prüfen.

4. Kennt der Erzeuger die Schwelle, bevor er anfängt? Dann schreibt er auf die Schwelle hin statt auf die Aufgabe. Gegenmittel: die Schwelle erst nach dem ersten Entwurf zeigen.

5. Wurde das Messgerät selbst geprüft? Eine Prüfung, die noch nie an einer bekannt falschen Eingabe geprüft wurde, ist keine Prüfung. Gegenmittel: bekannt falsche Eingaben einspeisen und das Verhalten beobachten.

6. Standen Kennzahl, Schwelle und Auswertung vor dem ersten Lauf fest? Eine nachträglich gewählte Schwelle misst den Wunsch statt den Prozess. Gegenmittel: das Design per Commit einfrieren.

7. Hat die Kennzahl einen Gegenspieler? Wer nur die Länge misst, bekommt Kürze um jeden Preis. Gegenmittel: eine zweite, gegenläufige Größe daneben stellen.

Die Regel darüber. Eine Kennzahl auf dünnen, streuenden Daten bleibt ein Hinweis auf einem Dashboard. Blockieren darf sie erst ab einer schmalen eigenen Unsicherheit.