Schätzwert statt Messwert

Am 27. September 2026 wurde ein Bericht im Projekt Coherent Chess zurückgezogen und neu gerechnet. Eine seiner Größen war aus einer Konfigurationsdatei gelesen und nicht gemessen worden. Sie sah aus wie eine Messung und stand in einer Datei voller echter Messungen, war aber eine Schätzung, die jemand Monate zuvor eingetragen hatte, damit sich Aufträge planen lassen. Alles Folgende stammt aus den Laufdateien und der Konfiguration der Messfarm, nicht aus dem Testregister, und nichts davon betrifft die Spielstärke.

Schätzung und Messung

Die Konfiguration eines Messauftrags enthält ein Feld für die erwarteten Sekunden je Partie. Die Verteilung plant damit, wie viele Aufträge auf einen Rechner passen und wie lange eine Charge dauert. Das Wort „geschätzt“ steht im Namen des Feldes.

Die Laufdateien halten fest, was tatsächlich geschah: die Laufzeit und die Zahl der Partien, die nebeneinander liefen. Aus diesen beiden Werten ergeben sich die wirklichen Kosten je Partie. Über alle fertigen Aufträge dieser Art, mehr als 15.000 mit zusammen mehr als 1,5 Millionen Partien, liegen die gemessenen Kosten bei etwas über einem Fünftel des Schätzwerts in der Konfiguration.

Kaputt war nichts, und für die Planung, ihren Zweck, war die Schätzung nie falsch. Eine Planungskonstante wird nicht an der Wirklichkeit nachgeführt, weil nichts davon abhängt, dass sie stimmt. Sobald sie als Messwert dient, erbt alles, was daraus gerechnet wird, einen unsichtbaren Fehler, während das Ergebnis weiterhin Einheiten, eine Quelldatei und eine Dezimalstelle hat.

Ein Feld, das weniger bedeutet, als es heißt

In denselben Laufdateien steht ein Feld für Prozessorsekunden, der naheliegende Ausgangswert für eine Kostenrechnung. Für diese Aufträge meldet es wegen der Art, wie es erhoben wird, nur einen kleinen Bruchteil der tatsächlich verbrauchten Prozessorzeit. Für bare Münze genommen, hätte es die Last eines Messauftrags um mehr als eine Größenordnung zu niedrig angesetzt. Für eine andere Auftragsart am selben Ort ist das Feld dagegen richtig; wer es einmal an der falschen Stichprobe prüft, zieht einen zuversichtlichen und falschen Schluss.

Der Bericht leitet daraus eine enge Lehre ab: Der Name eines Feldes sagt, wofür es gedacht war, nicht was es misst. Bevor eine Zahl in ein Argument eingeht, muss sie eine Frage bestehen: Wie sähe dieser Wert aus, wenn er falsch wäre? Bei Prozessorsekunden eines Auftrags, der einen Kern vier Minuten lang auslastet, hätte eine Zeile Rechnung die Antwort geliefert. Diese Rechnung wurde nicht gemacht.

Was sich geändert hat

Jede Größe in einem Bericht des Projekts trägt jetzt eine Kennzeichnung, gemessen, Planwert oder unbekannt, zusammen mit der Stelle, von der sie stammt. Eine Zahl ohne diese Kennzeichnung gilt als Behauptung, nicht als Befund. Die Regel ist älter als dieser Fehler; sie besteht wegen früherer.

Was daraus nicht folgt

Die berichtigte Größe ist ein Kostenwert je Partie auf bestimmten Rechnern bei einer bestimmten Einstellung. Sie zeigt nicht, dass die Messfarm schneller oder langsamer wäre als angenommen; sie hat eine falsche Zahl durch eine richtige ersetzt, nicht ein schlechtes Ergebnis durch ein gutes.

Wertlos waren die früheren Berichte ebenfalls nicht. Der berichtigte Schluss war eine Empfehlung, welche Maschine welche Arbeit übernehmen soll, und die Berichtigung hat die Größe dieses Arguments verändert, nicht seine Richtung. Laut Bericht ist das der Normalfall: Die meisten falschen Zahlen kehren einen Schluss nicht um, sondern lassen ihn unbelegt, und ein unbelegter Schluss, der zufällig stimmt, ist trotzdem kein Befund.