Evaluating Inference-Time Defenses Against Package Hallucination in LLM-Generated Code

In der modernen Welt der Softwareentwicklung verlassen sich Programmierer oft auf künstliche Intelligenz-Assistenten, um Code zu schreiben. Diese Systeme, bekannt als Large Language Models, fungieren als unermüdliche Partner, die ganze Funktionen vorschlagen oder Fehler in Sekundenschnelle beheben können. Damit ihre Vorschläge funktionieren, empfehlen diese Modelle häufig das Hinzufügen externer Softwarepakete – vorgefertigter Code-Sammlungen, die spezifische Aufgaben übernehmen, wie etwa die Verbindung zu einer Datenbank oder das Erstellen eines Graphen. Das Problem entsteht, wenn die künstliche Intelligenz einen Paketnamen erfindet, der zwar vollkommen echt klingt, aber in keiner offiziellen Softwarebibliothek tatsächlich existiert. Dieses Phänomen wird als „Package Hallucination“ (Paket-Halluzination) bezeichnet. Wenn ein Entwickler dem Vorschlag blind vertraut und versucht, dieses nicht existierende Paket zu installieren, kann er unbeabsichtigt eine bösartige Datei herunterladen, die von einem Hacker erstellt wurde, der den gefälschten Namen registriert hat. Dies schafft eine gefährliche Hintertür in die Software-Lieferkette und ermöglicht es Angreifern, schädlichen Code in Anwendungen einzuschleusen, die Millionen von Menschen nutzen könnten.

Ein Forschungsteam machte sich daran zu verstehen, wie häufig diese Halluzinationen auftreten und ob spezifische Techniken sie stoppen könnten, noch bevor der Code überhaupt fertiggestellt ist. Sie konzentrierten sich auf kleinere Open-Source-KI-Modelle, die weit verbreitet sind, da sie kostengünstiger im Betrieb sind, obwohl sie anfälliger für Fehler sind als ihre größeren Gegenstücke. Die Forscher testeten diese Modelle in vier verschiedenen Programmiersprachen: Python, JavaScript, Ruby und Rust. Sie entdeckten, dass bisherige Methoden zur Messung dieser Fehler fehlerhaft waren. Viele frühere Studien zählten standardmäßige, in einer Programmiersprache enthaltene Werkzeuge als Halluzinationen, nur weil diese Werkzeuge nicht in den externen Paketbibliotheken aufgeführt sind. Durch die Korrektur dieses Zählfehlers stellten die Forscher fest, dass die Rate der Halluzinationen für Python tatsächlich niedriger war als bisher angenommen, wenn auch immer noch signifikant.

Der Kern ihrer Arbeit bestand darin, sieben verschiedene Strategien zu testen, um zu sehen, ob sie die Anzahl der von den Modellen generierten gefälschten Paketnamen reduzieren könnten. Einige dieser Strategien beinhalteten eine Änderung der Art und Weise, wie das Modell sein nächstes Wort auswählt, während andere das Modell dazu aufforderten, seine eigene Arbeit zu überprüfen oder Informationen in einer verifizierten Datenbank nachzuschlagen, bevor es antwortet. Die Forscher fanden heraus, dass keine einzelne Methode in jeder Situation am besten funktionierte. Eine Technik namens „Retrieval-Augmented Generation“, die das Modell dazu zwingt, eine echte Datenbank existierender Pakete zu konsultieren, bevor es spricht, erwies sich für die meisten Sprachen als äußerst effektiv und senkte die Fehlerrate erheblich. Diese Technik führte jedoch bei JavaScript manchmal zu Verschlechterungen, was darauf hindeutet, dass die Lösung stark von der jeweiligen Programmiersprache abhängt. Ein anderer Ansatz, bei dem das Modell gebeten wird, seine eigenen Vorschläge zu kritisieren und umzuschreiben, funktionierte gut bei größeren Modellen, scheiterte jedoch bei den kleinsten, die oft nicht in der Lage waren, ihre eigenen Fehler zu erkennen.

Das Team führte auch eine neue Methode ein, um zu messen, ob die Vorschläge des Modells tatsächlich nützlich waren, nicht nur korrekt. Sie fanden heraus, dass einige Strategien, die Halluzinationen erfolgreich verhinderten, auch das Modell daran hinderten, überhaupt Pakete vorzuschlagen, wodurch der Entwickler mit gar nichts dastand. Der ausgewogenste Ansatz, der Fehler reduzierte und gleichzeitig hilfreiche Vorschläge lieferte, war eine einfache Methode, bei der das Modell einfach immer das wahrscheinlichste nächste Wort wählt, anstatt eine Chance auf weniger wahrscheinliche Optionen zu wagen. Dieser „gierige“ (greedy) Ansatz bot den besten Kompromiss zwischen Sicherheit und Nützlichkeit für die getesteten Modelle.

Die vielleicht bemerkenswerteste Erkenntnis ergab sich, als die Forscher diese Abwehrmaßnahmen in einer feindseligen Umgebung testeten. Sie erstellten Prompts, die gezielt versuchten, die Modelle zu täuschen, indem sie die gefälschten Paketnamen direkt in die Anweisungen einbetteten. Unter diesen adversen Bedingungen schossen die Fehlerraten in die Höhe und stiegen im Vergleich zu normalen Anfragen um bis zu 45 Prozentpunkte. In dieser feindseligen Umgebung versagten die einfachen Tricks der Änderung der Wortwahl vollständig. Nur die Methoden, die auf der Überprüfung gegen eine echte Datenbank oder dem Erzwingen einer Selbstprüfung der eigenen Logik basierten, konnten den Angriff abwehren. Die Forscher kamen zu dem Schluss, dass einfache Anpassungen zwar im normalen Gebrauch helfen können, der Schutz von Software vor entschlossenen Angreifern jedoch ein System erfordert, das Fakten gegen die Außenwelt verifiziert oder seine eigene Logik rigoros prüft. Die Studie unterstreicht, dass die beste Verteidigung keine Einheitslösung ist, sondern eine Wahl, die sorgfältig auf die spezifische Bedrohung und die jeweilige Programmiersprache abgestimmt ist.