Claude Codes Bewertungslogik scheitert an geschützten Leerzeichen
Ein Testfall für eine Python-Funktion zeigt eine Schwäche im Evaluator von Claude Code: Das System erkennt den Unterschied zwischen normalem ASCII-Leerzeichen und geschütztem Leerzeichen nicht. Dadurch kann eine eigentlich korrekte Lösung fälschlich durchfallen.
Veröffentlicht am 27. Oktober • Zuerst erschienen auf driftproofhq.com • KI-unterstützt
Hier sind zwei Antworten auf dieselbe Programmierfrage. Eine ist richtig. Welche?
Die Aufgabe: Schreibe eine Python-Funktion accepts(s: str) -> bool. Sie soll genau dann True zurückgeben, wenn s aus null oder mehr gewöhnlichen ASCII-Leerzeichen (U+0020), dann dem ASCII-Text "42" und dann null oder mehr gewöhnlichen ASCII-Leerzeichen (U+0020) besteht. Jeder andere String muss False liefern. Andere Whitespace-Zeichen sind nicht erlaubt.
def accepts ( s: str ) -> bool: return s. strip ( " " ) == " 42 " assert accepts ( " 42 " ) is True assert accepts ( " 42 " ) is True assert accepts ( " 42 " ) is False assert accepts ( " 43 " ) is False Enter fullscreen mode Exit fullscreen mode Antwort B
def accepts ( s: str ) -> bool: return s. strip ( " " ) == " 42 " assert accepts ( " 42 " ) is True assert accepts ( " 42 " ) is True assert accepts ( " 42 " ) is True assert accepts ( " 43 " ) is False Enter fullscreen mode Exit fullscreen mode Die meisten wählen B. Bei A scheinen die Tests zu besagen, dass " 42 " bestehen soll und zugleich, dass " 42 " durchfallen soll, wirkt also kaputt.
A ist korrekt. Der dritte Test in jeder Antwort verwendet keine gewöhnlichen Leerzeichen. Es sind geschützte Leerzeichen (U+00A0), die Zeichen, mit denen Setzer dafür sorgen, dass "28. Oktober" in einer Zeile bleibt. Auf dem Bildschirm sieht es exakt wie ein Leerzeichen aus. Die Aufgabe verlangt, es zurückzuweisen. A weist es zurück, daher lautet sein Test False. B akzeptiert es stillschweigend.
Auf unserer Website gibt es eine interaktive Version mit einem Röntgen-Schalter, der jedes versteckte Zeichen auf der Seite beleuchtet, auch eines in der Schlagzeile.
Viele Evaluierungswerkzeuge nutzen eine zweite KI als Bewerter: Sie liest eine Antwort und entscheidet über Bestehen oder Durchfallen. Wir haben diese beiden Antworten den Bewertern in drei beliebten Open-Source-Werkzeugen vorgelegt, LangChains OpenEvals, Promptfoo und NVIDIAs SkillEvaluator, wobei Claude Haiku 5.5 und Claude Sonnet 5.5 die Bewertung übernahmen.
In den Erklärungen, die wir lasen, war ein häufiges Muster dieses: Der Bewerter sah in A zwei Tests, die scheinbar dasselbe prüften und entgegengesetzte Ergebnisse erwarteten, und entschied, dass A sich selbst widerspreche. Einer lehnte A ab, weil dessen Tests "identische sichtbare Eingaben" verwendeten, und sagte, deren Ausführung führe zu einem Fehler. Die Ausführung funktioniert einwandfrei.
Claude Codes eigener eval-Befehl hat denselben blinden Fleck. Sein eingebauter claude plugin eval Bewerter, der dieselben beiden Antworten beurteilte, lag mit Haiku 5.5 bei 0 von 6 richtig und mit Sonnet 5.5 bei 1 von 6. Anschließend schrieben wir denselben Code, wobei das geschützte Leerzeichen als \u00a0 ausgeschrieben war, was Python als exakt dasselbe Programm liest. Beide Bewerter erreichten 6 von 6. Das Einzige, was sich änderte, war, ob der Bewerter das Zeichen sehen konnte.
Driftproof misst, ob die Anweisungen, die Menschen KI-Coding-Assistenten geben, diese tatsächlich verbessern. Vor jedem bezahlten Durchlauf machen wir eine kleine Probeaufgabe, um unseren eigenen Bewerter zu prüfen. In der Probeaufgabe für unseren nächsten Report hing genau eine Programmierfrage daran. Unsere Bewerter lagen jedes Mal falsch: jeweils 0 von 6 richtigen Entscheidungen. Wir bauten die Frage von Grund auf neu, um zu prüfen, ob die Werkzeuge, die andere Leute verwenden, sich genauso verhalten. Taten sie.
Die Korrektur ist bewusst klein gehalten. Neben der Antwort listet eine kurze Notiz alle ungewöhnlichen Leerzeichen und unsichtbaren Zeichen mit ihrer exakten Position auf:
Zeichenfakten (kein Urteil): Zeile 6, Spalte 17: U+00A0 NO-BREAK SPACE Zeile 6, Spalte 20: U+00A0 NO-BREAK SPACE Enter fullscreen mode Exit fullscreen mode Die Antwort wird nie verändert, und die Notiz sagt nicht, dass das Zeichen falsch ist, denn manchmal ist es genau richtig. Getestet über OpenEvals' eigenen Code ließ eine allgemeine Warnung "Vorsicht bei Unicode" Haiku bei 0 von 6 und brachte Sonnet auf 3 von 6. Die exakte Liste brachte beide auf 6 von 6, und 72 Kontrollprüfungen, darunter legitimer Unicode, der erhalten bleiben muss, blieben korrekt.
Wir haben sie upstream als Opt-in-Option angeboten:
Für unseren eigenen nächsten Report bewerten wir Programmierantworten jetzt hauptsächlich, indem wir versteckte Tests ausführen, die die heiklen Zeichen enthalten, mit einem KI-Bewerter nur für das, was Tests nicht prüfen können.
Ausführlicher Bericht, mit dem interaktiven Quiz, Methoden und Grenzen
Ich betreue Driftproof, das Open-Source-Werkzeug, in dem dies auftauchte. Mit KI-Unterstützung entworfen; jede Zahl stammt aus unseren Laufberichten und wurde mit diesen abgeglichen.
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
Posted on Oct 27 • Originally published at driftproofhq.com • AI-assisted
Here are two answers to the same coding question. One is right. Which one?
The task: Write a Python function accepts(s: str) -> bool. It must return True exactly when s consists of zero or more ordinary ASCII spaces (U+0020), then the ASCII text "42", then zero or more ordinary ASCII spaces (U+0020). Every other string must return False. Other whitespace characters are not permitted.
def accepts ( s: str ) -> bool: return s. strip ( " " ) == " 42 " assert accepts ( " 42 " ) is True assert accepts ( " 42 " ) is True assert accepts ( " 42 " ) is False assert accepts ( " 43 " ) is False Enter fullscreen mode Exit fullscreen mode Answer B
def accepts ( s: str ) -> bool: return s. strip ( " " ) == " 42 " assert accepts ( " 42 " ) is True assert accepts ( " 42 " ) is True assert accepts ( " 42 " ) is True assert accepts ( " 43 " ) is False Enter fullscreen mode Exit fullscreen mode Most people pick B. A's tests seem to say that " 42 " should pass and also that " 42 " should fail, so A looks broken.
A is correct. The third test in each answer doesn't use ordinary spaces. It uses no-break spaces (U+00A0), the character typesetters use to keep "28 October" on one line. On screen it looks exactly like a space. The task says to refuse it. A refuses it, so its test says False. B quietly accepts it.
There is an interactive version on our site with an X-ray switch that lights up every hidden character on the page, including one in the headline.
Many evaluation tools use a second AI as the grader: it reads an answer and decides pass or fail. We gave these two answers to the graders inside three popular open-source tools, LangChain's OpenEvals, Promptfoo and NVIDIA's SkillEvaluator, with Claude Haiku 5.5 and Claude Sonnet 5.5 doing the grading.
In the explanations we read, a common pattern was this: the grader saw two tests in A that seemed to check the same thing and expect opposite results, and decided A contradicted itself. One rejected A because its tests used "identical visible inputs" and said running them would raise an error. Running them works fine.
Claude Code's own eval command has the same blind spot. Its built-in claude plugin eval grader, judging the same two answers, got 0 of 6 right with Haiku 5.5 and 1 of 6 with Sonnet 5.5. We then wrote the identical code with the no-break space spelled out as \u00a0, which Python reads as exactly the same program. Both graders got 6 of 6. The only thing that changed was whether the grader could see the character.
Driftproof measures whether the instructions people give AI coding assistants actually make them better. Before any paid run we do a small practice round to check our own grader. In the practice round for our next report, one coding question turned on exactly this. Our graders got it backwards every time: 0 of 6 correct calls each. We rebuilt the question from scratch to see whether the tools other people use behave the same way. They did.
The fix is deliberately small. Alongside the answer, a short note lists any unusual spaces and invisible characters, with their exact position:
Character facts (not a verdict): line 6, col 17: U+00A0 NO-BREAK SPACE line 6, col 20: U+00A0 NO-BREAK SPACE Enter fullscreen mode Exit fullscreen mode The answer is never changed, and the note doesn't say the character is wrong, because sometimes it is exactly right. Tested through OpenEvals' own code, a general "watch out for Unicode" warning left Haiku at 0 of 6 and got Sonnet to 3 of 6. The exact list got both to 6 of 6, and 72 control checks, including legitimate Unicode that must be kept, stayed correct.
We've offered it upstream as an opt-in option:
For our own next report, we now grade coding answers mainly by running hidden tests that include the tricky characters, with an AI grader only for what tests can't check.
Full write-up, with the interactive quiz, methods and limits
I maintain Driftproof, the open-source tool where this turned up. Drafted with AI assistance; every number is from our run reports and was checked against them.