💬 NLP

Comparing Developer and LLM Biases in Code Evaluation

Die Studie stellt das TRACE-Framework vor, das zeigt, dass LLM-basierte Code-Bewertungssysteme in realistischen Szenarien systematisch von menschlichen Präferenzen abweichen und dabei oft andere Gewichtungskriterien anwenden als Entwickler.

Ursprüngliche Autoren: Aditya Mittal, Ryan Shar, Zichu Wu, Shyam Agarwal, Tongshuang Wu, Chris Donahue, Ameet Talwalkar, Wayne Chi, Valerie Chen

Veröffentlicht 2026-03-26

📖 4 Min. Lesezeit☕ Kaffeepausen-Lektüre

CC BY 4.0

Ursprüngliche Autoren: Aditya Mittal, Ryan Shar, Zichu Wu, Shyam Agarwal, Tongshuang Wu, Chris Donahue, Ameet Talwalkar, Wayne Chi, Valerie Chen

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stell dir vor, du bist ein erfahrener Chefkoch in einer großen Küche. Du hast einen neuen, hochmodernen Küchenroboter (den LLM-Judge), der dir helfen soll, deine Gerichte zu bewerten. Dieser Roboter kann Rezepte lesen, Zutaten analysieren und dir sagen, welches Gericht besser ist.

Das Problem? Der Roboter bewertet die Gerichte oft ganz anders als du und deine menschlichen Gäste.

Diese Forschungsarbeit von Carnegie Mellon University nennt sich TRACE und untersucht genau dieses Missverständnis zwischen dem Roboter und den Menschen im Bereich der Programmierung. Hier ist die Erklärung in einfachen Worten:

1. Das Problem: Der Roboter ist nicht im "echten Leben"

Bisher haben Forscher die Küchenroboter oft nur in einer sterilen Umgebung getestet. Sie haben ihnen perfekte, fertige Rezepte aus einem Kochbuch gegeben und gefragt: "Welches sieht besser aus?"
Aber im echten Leben (in der Softwareentwicklung) ist es chaotisch. Entwickler arbeiten mitten im Code, haben unklare Ideen, müssen schnell etwas ändern und denken an den Kontext (z. B. "Wir nutzen das hier in einer Bank-App, also muss es sicher sein").

Die Forscher wollten wissen: Versteht der Roboter wirklich, was ein menschlicher Entwickler gut findet, wenn es um echte, unperfekte Arbeit geht?

2. Die Lösung: TRACE (Der "Geschmacks-Test")

Die Autoren haben ein neues Werkzeug namens TRACE entwickelt. Stell dir TRACE wie einen Geschmacks-Test mit einem Detektiv vor.

Schritt 1: Der Vergleich. TRACE zeigt dem Roboter und einem menschlichen Entwickler zwei verschiedene Lösungen für ein Problem (z. B. zwei Versionen eines Codes).
Schritt 2: Die Frage. Wer findet welche Lösung besser?
Schritt 3: Die Analyse (Das Geniale daran). Wenn der Roboter und der Mensch unterschiedliche Meinungen haben, fragt TRACE: "Warum?"
- Der Roboter sagt vielleicht: "Ich mag Lösung A, weil sie sehr robust ist und Fehler abfängt."
- Der Mensch sagt: "Ich mag Lösung B, weil sie kürzer ist und ich sie sofort verstehe."

TRACE extrahiert diese Gründe automatisch und nennt sie "Rubriken" (wie eine Bewertungskarte mit Punkten für "Robustheit", "Klarheit", "Kommentare" etc.).

3. Was haben sie herausgefunden? (Die Überraschungen)

Die Studie hat drei verschiedene "Küchen" getestet:

Autocomplete: Der Roboter ergänzt deinen Code während du schreibst.
Code-Edit: Der Roboter ändert einen bestehenden Codeabschnitt auf Anweisung.
Chat: Du fragst den Roboter im Chat nach einer Lösung.

Hier sind die wichtigsten Erkenntnisse, übersetzt in Alltagssprache:

Der Roboter ist immer noch nicht so gut wie der Mensch: Selbst die besten Roboter-Judges lagen in ihrer Bewertung um 12 bis 23 % daneben, verglichen mit dem, was die meisten menschlichen Entwickler bevorzugt hätten. Es gibt keinen "Super-Roboter", der immer recht hat.
Der Roboter liebt "Robustheit", der Mensch liebt "Klarheit":
- Beispiel: Bei einem Chat-Code-Problem bevorzugt der Roboter oft lange, ausführliche Erklärungen und sehr sichere, aber sperrige Code-Lösungen.
- Der Mensch sagt: "Nein, ich will eine kurze, klare Lösung, die sofort funktioniert. Ich habe keine Zeit für lange Erklärungen."
Der Roboter vergisst den Kontext:
- Bei Autocomplete (während des Tippens) bewertet der Roboter oft nur, ob der Code funktioniert. Der Mensch achtet aber darauf, ob der Code lesbar ist und gut in den Rest des Programms passt.
- Bei Code-Edits (Änderungen) denkt der Roboter oft nur: "Habe ich die Anweisung befolgt?" Der Mensch fragt sich: "Ist der Code danach noch sauber und verständlich?"
Spezialisten sind nicht immer besser: Man dachte, Roboter, die speziell für das Bewerten trainiert wurden, wären besser als die allgemeinen Chat-Roboter. Aber oft machen sie genau dieselben Fehler. Das Training allein löst das Problem noch nicht.

4. Die große Metapher: Der "Kochbuch-Roboter" vs. Der "Hungernde Gast"

Stell dir vor, du bist hungrig (der Entwickler).

Der Roboter-Judge ist wie ein Koch, der nur auf die Zutatenliste schaut. Er sagt: "Dieses Gericht hat 100% mehr Vitamine und ist sicherer zu essen, also ist es besser."
Der Mensch sagt: "Aber ich will etwas, das schnell zubereitet ist, gut schmeckt und nicht so schwer im Magen liegt."

Der Roboter bewertet nach den "perfekten Regeln" (wie ein strenger Lehrer), während der Mensch nach "praktischem Nutzen" bewertet (wie ein hungriger Gast).

5. Was bedeutet das für die Zukunft?

Die Forscher sagen: Wir können nicht einfach erwarten, dass diese KI-Tools die menschliche Meinung perfekt ersetzen. Sie haben blinde Flecken.

Um das zu beheben, müssen wir die KI nicht nur "besser" trainieren, sondern ihr beibringen, was Menschen wirklich wichtig ist. Wir müssen ihr sagen: "Hey, manchmal ist 'kurz und klar' wichtiger als 'perfekt und sicher'."

Zusammenfassend:
Diese Studie zeigt uns, dass KI-Tools, die Code bewerten, noch nicht so denken wie Menschen. Sie sind wie sehr fleißige, aber etwas steife Assistenten, die die Regeln auswendig gelernt haben, aber den "Vibe" und die praktischen Bedürfnisse eines echten Entwicklers noch nicht ganz verstehen. TRACE ist das Werkzeug, das uns hilft, genau diese Unterschiede zu finden und zu beheben.

1. Problemstellung

Mit dem zunehmenden Einsatz von Large Language Models (LLMs) als „Richter" (Judges) zur Bewertung von Code-Ausgaben besteht ein dringender Bedarf an zuverlässigen Evaluierungsmethoden, die realistische, interaktive Szenarien abbilden. Bisherige Arbeiten konzentrieren sich oft auf statische Umgebungen (z. B. polierter Code aus GitHub-Repositories oder Wettbewerbsaufgaben), die die chaotischen, unvollständig spezifizierten Bedingungen der tatsächlichen Softwareentwicklung nicht erfassen.

Das zentrale Problem ist, dass LLMs als Richter oft systematische Verzerrungen (Biases) aufweisen, die von den impliziten Kriterien abweichen, die Entwickler in der Praxis anwenden. Es ist unklar, inwieweit LLMs menschliche Präferenzen in verschiedenen Interaktionsmodalitäten (Chat, IDE-Autocomplete, Code-Editierung) korrekt vorhersagen und welche spezifischen Qualitätskriterien sie falsch gewichten.

2. Methodik: Das TRACE-Framework

Die Autoren stellen TRACE (Tool for Rubric Analysis in Code Evaluation) vor, ein Framework zur Evaluierung und Interpretation von LLM-basierten Richtern in realistischen Entwickler-Workflows. TRACE durchläuft drei Hauptschritte:

Messung der Übereinstimmung: Es wird geprüft, wie gut ein LLM-Richter die paarweisen menschlichen Präferenzen vorhersagt. Dazu werden Datensätze aus drei Modalitäten verwendet:
- Code Completion: (aus Copilot Arena) – Vervollständigung von Code im IDE-Kontext.
- Instructed Code Edits: (aus EDIT-Bench) – Bearbeiten von Code basierend auf Anweisungen.
- Chat-based Coding: (aus Chatbot Arena) – Offene Programmiergespräche.
- Wichtig: Um Positionsbias zu kontrollieren, werden Antworten vertauscht und nur konsistente Entscheidungen gewertet.
Automatische Extraktion von Rubriken (Rubric Items): Anstatt vordefinierte Kriterien zu nutzen, extrahiert TRACE automatisch interpretierbare Bewertungskriterien, die Unterschiede zwischen den Antworten erklären. Dies geschieht durch eine Kombination aus:
- LLM-generierten Rubriken: Ein LLM analysiert Paare von Antworten und identifiziert Unterschiede.
- Menschlich annotierten Rubriken: Ingenieure liefern Begründungen für ihre Präferenzen, die dann generalisiert werden.
- Diese Kriterien werden aggregiert, um eine umfassende Rubrik zu bilden (z. B. „Fehlerbehandlung", „Klarheit", „Modularität").
Vergleich der Verzerrungen (Bias Analysis):
- Die extrahierten Rubriken werden in numerische Merkmale umgewandelt.
- Es werden separate logistische Regressionsmodelle für menschliche Präferenzen und für jeden LLM-Richter trainiert, um die Gewichtung der Rubriken zu lernen.
- Durch den Vergleich der Koeffizienten ( $\beta_{Judge} - \beta_{Human}$ ) wird quantifiziert, welche Kriterien Richter im Vergleich zu Menschen über- oder unterbewerten.

3. Experimentelles Setup

Datensätze: Über 500 Stichproben pro Modalität (insgesamt drei Modalitäten).
Richter: 13 verschiedene Modelle wurden getestet, darunter:
- Allgemeine Third-Party-Modelle (z. B. GPT-5, GPT-4o, Claude Sonnet 4, DeepSeek-R1).
- Spezialisierte Richter-Modelle (z. B. Prometheus 2, Atla Selene, Skywork Critic).
- Reward-Modelle (z. B. PairRM, GRM).
Human Baseline: Um eine robuste menschliche Referenz zu schaffen, wurden zusätzliche Annotatoren (Ingenieure) hinzugezogen, um eine Mehrheitsentscheidung (Majority-User Agreement) zu bilden.

4. Wichtige Ergebnisse

A. Leistungslücke zwischen LLM und Mensch

Unterkunft: Die besten LLM-Richter liegen in allen drei Modalitäten um 12–23 Prozentpunkte hinter der menschlichen Mehrheitsentscheidung zurück.
Kein dominanter Richter: Kein einzelnes Modell (weder spezialisiert noch allgemein) dominiert konsistent über alle Modalitäten hinweg.
Spezialisierung hilft nur bedingt: Feinabgestimmte Richter-Modelle übertreffen allgemeine Modelle nicht zuverlässig, was darauf hindeutet, dass die aktuellen Trainingsdaten oder -strategien die Hauptursachen für die Fehlausrichtung nicht beheben.
Positionsbias: LLMs zeigen eine starke Abhängigkeit von der Reihenfolge der Eingabe (Position Bias), während Reward-Modelle (die skalare Scores vergeben) immun dagegen sind.

B. Spezifische Fehlausrichtungen (Misalignment)

TRACE identifizierte 35 signifikante Quellen der Fehlausrichtung zwischen Menschen und Richtern:

Code Completion: Richter bewerten „Funktionalität" und „Logische Ausrichtung" übermäßig hoch, während sie „Explizitheit und Klarheit" (z. B. Initialisierung von Basisfällen) unterschätzen. Menschen bevorzugen oft klareren, expliziteren Code, auch wenn er minimal weniger „logisch kompakt" wirkt.
Code Edits: Richter behandeln Edits oft als reine Constraint-Satisfaction-Aufgaben (wurde die Anweisung erfüllt?) und vernachlässigen die Klarheit und Struktur des Codes. Entwickler erwarten jedoch, dass Edits die Codequalität insgesamt verbessern.
Chat: Richter belohnen generische Erklärungen und klare Präsentationen, während Entwickler kontextsensitive, domänenspezifische Lösungen bevorzugen und übermäßige Erklärungen ablehnen.

C. Korrelation mit Software-Engineering-Kriterien

Viele der extrahierten Rubriken entsprechen etablierten Software-Engineering-Kriterien (z. B. Syntax, Formatierung, Robustheit).
Dennoch zeigen sich signifikante Fehlausrichtungen bei 6 von 11 dieser etablierten Kriterien. Dies deutet darauf hin, dass LLMs in ihrer Trainingsphase nicht gelernt haben, menschliche Präferenzen in Bezug auf grundlegende Code-Qualitätsdimensionen korrekt zu gewichten.

5. Bedeutung und Schlussfolgerungen

Realitätsnähe: Das Paper zeigt, dass Evaluierungen in statischen Benchmarks (wie RewardBench) die Leistung von LLMs in realen, interaktiven Entwicklungsumgebungen nicht zuverlässig vorhersagen.
Notwendigkeit neuer Ansätze: Die Ergebnisse belegen, dass die aktuelle „LLM-as-a-Judge"-Paradigma für Code-Evaluierung noch nicht ausgereift ist. Die bestehenden Modelle erfassen die Nuancen menschlicher Präferenzen in komplexen Kontexten nicht.
Zukünftige Richtungen: Um die Lücke zu schließen, sind rubrikbewusste Kalibrierungen oder gezieltes Training erforderlich. Das einfache Einfügen von Rubriken in den Prompt (Rubric Injection) verbesserte die Genauigkeit nicht signifikant. Vielversprechender sind Ansätze wie rubrik-konditionierte Zielsetzungen (Rubric-conditioned objectives) oder Kalibrierungsschichten, die die Gewichtung der Richter an menschliche Koeffizienten anpassen.

Fazit: TRACE liefert ein mächtiges Werkzeug, um nicht nur dass, sondern warum LLMs bei der Code-Evaluierung scheitern, zu verstehen. Es offenbart, dass LLMs oft oberflächliche oder leicht verifizierbare Merkmale überbewerten, während sie tiefere, kontextabhängige menschliche Präferenzen (wie Lesbarkeit im Gesamtkontext oder domänenspezifische Anpassung) unterschätzen.