💻 computer science

Task Abstention for Large Language Models in Code Generation

Dieser Artikel schlägt eine theoretisch fundierte, verteilungsfreie Methode vor, mit der Large Language Models von Codegenerierungsaufgaben, die wahrscheinlich zu Halluzinationen führen, absehen, indem sie die Generierungskonsistenz anhand von Codeausführungsergebnissen bewerten, wodurch sicherere und robustere automatisierte Codierung ohne Abhängigkeit von externen Testfällen ermöglicht wird.

Ursprüngliche Autoren: Yanke Zhou, Yuhao Tan, Senrong Xu, Zenan Li, Yuan Yao, Taolue Chen, Xiaoxing Ma

Veröffentlicht 2026-05-19

📖 5 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Yanke Zhou, Yuhao Tan, Senrong Xu, Zenan Li, Yuan Yao, Taolue Chen, Xiaoxing Ma

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

Das Kernproblem: Der „übermütige Koch"

Stellen Sie sich vor, Sie stellen einen brillanten, aber übermütigen Koch (das Large Language Model oder LLM) ein, um ein komplexes Gericht nach einer vagen Rezeptbeschreibung zu kochen. Manchmal ist der Koch fantastisch und zaubert ein perfektes Mahl. Doch oft wird der Koch selbstbewusst und kreiert ein Gericht, das aussieht, als wäre es köstlich, aber schrecklich schmeckt oder sogar giftig ist (dies wird als „Halluzination" bezeichnet).

Derzeit finden die meisten Sicherheitsprüfungen nach dem Kochen des Gerichts statt. Sie probieren das Essen, um zu sehen, ob es gut ist. Wenn es schlecht ist, werfen sie es weg. Aber bis dahin hat der Koch bereits Zeit und Zutaten verschwendet, und Sie wurden mit einer schlechten Mahlzeit bedient.

Dieses Papier stellt eine andere Frage: Können wir dem Koch beibringen, zu sagen: „Ich weiß nicht, wie man das kocht," bevor er überhaupt anfängt, Gemüse zu schneiden?

Dies nennt man Task Abstention (Aufgabenverzicht). Es geht darum zu wissen, wann man eine Aufgabe ablehnen muss, um einen Fehler zu vermeiden.

Die Lösung: CODEREFUSER

Die Autoren haben ein System namens CODEREFUSER entwickelt. Stellen Sie sich dies als einen „Sicherheitsmanager" für den Koch vor. Dieser Manager schaut nicht nur auf das Rezept; er führt eine Simulation durch, um zu sehen, ob der Koch wahrscheinlich Erfolg haben wird, bevor er grünes Licht gibt.

Hier ist, wie der Sicherheitsmanager funktioniert, aufgeteilt in drei einfache Schritte:

1. Der „Probelauf" (Kalibrierungsphase)

Bevor der Sicherheitsmanager Entscheidungen treffen kann, muss er die Grenzen des Kochs lernen.

Die Analogie: Stellen Sie sich vor, der Manager gibt dem Koch 100 Übungsrezepte. Für jedes davon versucht der Koch, es 64 Mal zu kochen.
Die Wendung: Der Manager schaut sich nicht nur das fertige Gericht an. Er bittet den Koch auch, einen „Geschmackstest" (Testfälle) für jedes Rezept zu erfinden.
Das Problem: Manchmal ist der Koch so schlecht darin, Geschmackstests zu erfinden, dass der Test selbst defekt ist (z. B. wenn nach einer negativen Anzahl von Eiern gefragt wird).
Die Lösung (Sample-Test Dual Filtering): Der Manager verwendet einen cleveren Trick namens Sample-Test Dual Filtering. Er betrachtet die 64 Versuche des Kochs. Wenn der „Geschmackstest" des Kochs zu 64 verschiedenen, chaotischen Ergebnissen führt (einige explodieren, andere stürzen ab), erkennt der Manager: „Hey, dieser Test ist kaputt, nicht der Koch!" Er verwirft den schlechten Test und behält die guten. Dies stellt sicher, dass der Manager nicht durch die eigene Verwirrung des Kochs getäuscht wird.

2. Die Regeln festlegen (Die „Risikotoleranz")

Sobald der Manager geübt hat, legt er die Regeln für die reale Welt fest.

Das Ziel: Der Manager möchte sicherstellen, dass, wenn er sagt „Fang an zu kochen", die Wahrscheinlichkeit sehr hoch ist, dass der Koch Erfolg haben wird.
Die Mathematik (vereinfacht): Der Manager verwendet eine statistische Methode namens „Multiple Hypothesis Testing" (Multiple Hypothesentests). Stellen Sie sich vor, der Manager hat eine Liste von 1.000 verschiedenen „Stopp-Schildern" (Schwellenwerten). Er testet sie alle gegen die Übungsdaten, um die spezifischen Schilder zu finden, die garantieren, dass der Koch nicht öfter als etwa 20 % der Zeit scheitert.
Das Ergebnis: Der Manager erstellt ein strenges Regelbuch: „Wenn das Selbstvertrauen des Kochs unter X liegt oder wenn die Testergebnisse zu chaotisch sind, STOPP."

3. Der echte Auftrag (Testphase)

Jetzt bestellt ein echter Kunde ein Gericht.

Der Koch versucht, es ein paar Mal zu kochen (generiert Code-Beispiele).
Der Koch erfindet einen neuen Geschmackstest für dieses spezifische Gericht.
Der Sicherheitsmanager führt erneut das Sample-Test Dual Filtering durch, um etwaige defekte Tests zu bereinigen.
Der Manager prüft das Regelbuch.
- Szenario A: Die Versuche des Kochs sind alle konsistent und bestehen die Tests. Der Manager sagt: „Zugeben: Mach weiter, du kannst das kochen."
- Szenario B: Die Versuche des Kochs sind völlig durcheinander, oder die Tests sind zu verwirrend. Der Manager sagt: „Verzicht: Es tut mir leid, ich kann dich das nicht kochen lassen. Es ist zu riskant."

Warum dies besser ist als andere Methoden

Das Papier vergleicht ihre Methode mit anderen Wegen, Fehler zu erkennen:

Statische Methoden (Die „Grammatik-Polizei"): Diese Methoden lesen den Code nur, um zu sehen, ob er richtig aussieht, wie eine Rechtschreibprüfung. Das Papier zeigt, dass dies für Code nutzlos ist, weil ein Satz perfekt geschrieben sein kann, aber trotzdem keinen Sinn ergibt (z. B. „Die blaue Farbe fraß die Zahl").
Alte Ausführungsmethoden: Diese versuchen, den Code auszuführen, bereinigen aber nicht die schlechten Tests. Sie werden oft durch die eigenen schlechten Testfragen des Kochs verwirrt und verweigern dem Koch die Erlaubnis zum Kochen, selbst wenn er Erfolg gehabt hätte.

Das Ergebnis: CODEREFUSER ist viel besser darin zu wissen, wann man „Ich weiß es nicht" sagen muss. In Tests verbesserte es die Fähigkeit, gefährliche Aufgaben zu erkennen, um etwa 26 % im Vergleich zu den besten bestehenden Methoden.

Das Fazit

Dieses Papier stellt eine Möglichkeit vor, AI-Coder sicherer zu machen. Anstatt darauf zu warten, dass die AI einen Fehler macht und ihn dann zu beheben, agiert dieses System wie ein intelligenter Vorgesetzter, der weiß, wann die AI überfordert ist. Es zwingt die AI, „Ich weiß es nicht" zu sagen, bevor sie Code generiert, und verhindert so die Erstellung von defekter oder gefährlicher Software.

Kernaussage: Es ist besser für eine AI, zuzugeben, dass sie eine Aufgabe nicht bewältigen kann, als sie selbstbewusst falsch zu erledigen. CODEREFUSER lehrt die AI, wie sie diese Anerkennung sicher und zuverlässig ausspricht.

Technische Zusammenfassung: Aufgabenabstention für Large Language Models in der Code-Generierung

Problemdefinition

Die Arbeit adressiert das kritische Problem der Halluzination bei Large Language Models (LLMs) im Kontext der Code-Generierung. Während sich die bestehende Forschung weitgehend auf Sample-Halluzinationen konzentriert (das Erkennen einzelner Code-Snippets, die nicht ausführbar sind oder die Anforderungen nicht erfüllen), identifiziert diese Arbeit eine grundlegendere Fehlerquelle: Aufgaben-Halluzination. Dies tritt auf, wenn ein LLM aufgrund von mehrdeutigen Prompts oder inhärenten Modellgrenzen grundsätzlich unwahrscheinlich ist, eine spezifische Codierungsaufgabe zu lösen, unabhängig davon, wie viele Samples generiert werden.

Die Autoren formalisieren das Problem der Aufgabenabstention: die Bestimmung, ob ein LLM eine spezifische Code-Generierungsanfrage verweigern sollte, um die Erzeugung funktional fehlerhaften Codes zu vermeiden. Das Ziel ist die Definition einer Verweigerfunktion $r(x)$ , die Aufgaben identifiziert, bei denen die Wahrscheinlichkeit, eine korrekte Lösung zu generieren, gering ist, insbesondere wenn die Metrik $H@k$ (die Wahrscheinlichkeit, dass $k$ zufällig generierte Samples alle falsch sind) eine vom Benutzer definierte Risikotoleranz $\alpha$ überschreitet.

Methodik: CODEREFUSER

Der vorgeschlagene Ansatz, CODEREFUSER, basiert auf dem Learn Then Test (LTT)-Rahmenwerk und nutzt multiple Hypothesentests, um rigorose, verteilungsfreie theoretische Garantien zu bieten. Die Methode arbeitet in zwei Phasen:

1. Kalibrierungsphase

Aufbau des Kalibrierungsdatensatzes: Im Gegensatz zu Standard-NLP-Aufgaben besteht der Kalibrierungsdatensatz aus Aufgaben-Prompts, die mit Oracle-Testfällen (Ground Truth) gepaart sind.
Definition des Zulassungsrisikos: Das Risiko wird als die Wahrscheinlichkeit definiert, dass eine Aufgabe zugelassen wird (nicht verweigert), der LLM jedoch innerhalb von $k$ Versuchen keine korrekte Lösung generiert ( $H@k$ ).
Score-Funktionen: Um die syntaktische Vielfalt semantisch äquivalenten Codes zu handhaben, schlagen die Autoren ausführungsbasierte Score-Funktionen anstelle statischer linguistischer Metriken vor. Diese stützen sich auf das Clustern von Code-Samples basierend auf ihren Ausführungsergebnissen gegenüber Testfällen:
- Cluster Ratio (CR): Misst den Anteil der Samples, die zum dominanten semantischen Cluster gehören (Modellkonsens).
- Semantische Entropie (SE): Quantifiziert die Unsicherheit der Aufgabe durch Messung der Vielfalt der resultierenden Cluster-Verteilung.
Schwellenwertauswahl: Mithilfe von multiple Hypothesentests identifiziert die Methode eine Menge gültiger Schwellenwerte ( $\Lambda_{valid}$ ), die garantieren, dass das Zulassungsrisiko mit hoher Konfidenz ( $1-\delta$ ) unter der Toleranz $\alpha$ bleibt.

2. Testphase

Duale Generierung: Für einen neuen Test-Prompt generiert der LLM sowohl Code-Lösungen als auch entsprechende Testfälle.
Sample-Test Dual Filtering (STDF): Ein neuer Mechanismus, um das Problem zu adressieren, dass von LLMs generierte Testfälle ungültig oder fehlerhaft sein können.
- Fehlerraten-Filterung: Entfernt Testfälle, die zu weit verbreiteten Ausführungsfehlern in der Sample-Population führen.
- Ausgabe-Diversitäts-Filterung: Entfernt Testfälle, die eine hohe semantische Entropie hervorrufen (was undefiniertes Verhalten oder ungültige Eingaben anzeigt), während das Pruning-Verhältnis begrenzt wird, um das Verwerfen valider Tests zu vermeiden.
Entscheidungsfindung: Die verfeinerten Testfälle werden verwendet, um die Code-Samples zu clustern. Die Abstentionsentscheidung wird getroffen, indem die kalibrierten Schwellenwerte auf die Cluster-Ratio- oder Semantische-Entropie-Scores angewendet werden. Wenn die Kriterien nicht erfüllt sind, abstiniert das Modell.

Hauptbeiträge

Formalisierung der Aufgabenabstention: Die Arbeit führt das Konzept der Aufgabenabstention in der Code-Generierung ein und formalisiert es, wobei sie diese von der Sample-Ebene-Halluzinationserkennung unterscheidet.
Theoretisch garantiertes Rahmenwerk: Sie schlägt eine Methode vor, die auf multiple Hypothesentests basiert und eine rigorose, verteilungsfreie Garantie bietet, dass das Risiko, eine „schlechte" Aufgabe zu akzeptieren, unter einem spezifizierten Schwellenwert kontrolliert wird.
Ausführungsbasierte Bewertung mit STDF: Die Autoren führen ein Bewertungsschema ein, das auf Laufzeitausführungsergebnissen basiert, sowie einen Sample-Test Dual Filtering (STDF)-Mechanismus. Dies ermöglicht dem System den Betrieb ohne Abhängigkeit von Oracle-Testfällen während der Testphase, während gleichzeitig das durch modellgenerierte Tests eingeführte Rauschen gemindert wird.
Minimale Abhängigkeit von Oracles: Der Ansatz erfordert Oracle-Testfälle nur während der Kalibrierungsphase, was ihn für den Einsatz in Umgebungen praktikabel macht, in denen Ground-Truth-Tests für jede neue Aufgabe nicht verfügbar sind.

Experimentelle Ergebnisse

Die Autoren evaluierten CODEREFUSER auf den Benchmarks HumanEval und MBPP unter Verwendung von vier Open-Source-Code-LLMs (DeepSeek-Coder, Qwen2.5-Coder, CodeLlama und WizardCoder).

Leistung: CODEREFUSER übertraf bestehende Baselines, einschließlich statischer Methoden (PPL, NLI, CLM) und ausführungsbasierter Detektoren (CodeHalu, Execution), signifikant. Im Durchschnitt erzielte es eine absolute Verbesserung der Abstentionspräzision um 26,5 % im Vergleich zum besten existierenden Konkurrenten.
Statisch vs. Ausführung: Experimente zeigten, dass statische Methoden (selbst bei vervierfachter Sample-Größe) die Leistung ausführungsbasierter Methoden nicht erreichen konnten, was bestätigt, dass das Ausführen von Code für eine genaue Risikoschätzung in diesem Bereich notwendig ist.
Transferierbarkeit: Die Methode zeigte eine robuste Transferierbarkeit und behielt eine hohe Leistung bei, wenn die Kalibrierung auf MBPP und der Test auf HumanEval durchgeführt wurde, trotz des Verteilungswechsels.
Risikokontrolle: Empirische Ergebnisse bestätigten die theoretischen Garantien und zeigten, dass das Zulassungsrisiko in über 90 % der Fälle erfolgreich unter die Zieltoleranz $\alpha$ kontrolliert wurde. Darüber hinaus erreichte CODEREFUSER diese Risikokontrolle mit einer signifikant niedrigeren Abstentionsrate (Verweigerung weniger valider Aufgaben) im Vergleich zu Baseline-Methoden wie PPL.

Bedeutung und Behauptungen

Die Arbeit beansprucht Fortschritte hin zu beweisbar korrekter LLM-Code-Generierung darzustellen. Indem sie Modellen ermöglicht, für Aufgaben, die sie unwahrscheinlich lösen können, selbstbewusst „Ich weiß es nicht" zu sagen, bietet der Ansatz einen zuverlässigen Mechanismus für eine sicherere und robustere Code-Generierung.

Die Autoren erkennen bescheiden Limitationen an:

Verteilungswechsel: Die theoretische Garantie beruht auf der Annahme, dass Kalibrierungs- und Testdaten unabhängig und identisch verteilt (i.i.d.) sind. Obwohl Experimente eine Robustheit gegenüber moderaten Verschiebungen zeigen, könnten extreme Abweichungen in der realen Welt die Garantien abschwächen.
Determinismus: Die Methode geht davon aus, dass Aufgaben deterministische Lösungen haben. Sie ist möglicherweise nicht direkt auf nicht-deterministische oder interaktive Softwaresysteme anwendbar.
Sprachumfang: Die aktuelle Evaluation ist auf Python beschränkt; die Wirksamkeit in anderen Sprachen (z. B. C, Java) mit unterschiedlichen Speicher- oder Zeigercharakteristika erfordert weitere Evaluation.

Die Arbeit schlägt keine neuen Anwendungen vor, sondern vielmehr eine grundlegende Sicherheitsschicht, die in bestehende Code-Generierungs-Workflows integriert werden kann, um das Risiko von Halluzinationen zu mindern.