Specification and Detection of LLM Code Smells
Dieses Paper führt das Konzept der LLM-Code-Smells ein, indem es fünf wiederkehrende problematische Kodierungspraktiken für die LLM-Inferenz formalisiert, das Tool SpecDetect4AI zu deren Erkennung erweitert und durch eine Untersuchung von 200 Open-Source-Systemen nachweist, dass diese Smells über 60 % dieser Systeme mit hoher Erkennungspräzision beeinflussen.
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
Stellen Sie sich vor, Sie hätten gerade einen super-intelligenten Roboter-Assistenten (ein Large Language Model, oder LLM) gebaut und ihn eingeladen, in Ihrer Software zu leben. Es ist, als würde man einen genialen Zauberer anheuern, um beim Ausführen von Zaubersprüchen in Ihrem Code zu helfen. Aber hier ist der Haken: Wenn Sie dem Zauberer keine klaren Regeln, eine stetige Hand und eine Karte geben, kann es chaotisch werden. Der Roboter könnte verwirrt werden, seine Magie aufbrauchen oder anfangen, Unsinn zu schreien.
Dieses Paper ist wie ein Detektiv-Leitfaden, um die „schlechten Angewohnheiten“ aufzuspüren, die sich Entwickler versehentlich aneignen, wenn sie diese Zauberer in ihren Code einladen. Die Autoren – Brahim, Zacharie, Naouel, Quentin und Florent – erkannten, dass zwar jeder weiß, wie man Code schreibt, aber niemand eine formale Liste der spezifischen „Gerüche“ (diese subtilen, schlechten Angewohnheiten, die den Code nicht sofort zum Absturz bringen, aber die Software später krank machen) aufgeschrieben hat, die speziell beim Einsatz von LLMs auftreten.
Die fünf „schlechten Angewohnheiten“ (die Gerüche)
Das Team durchforstete Forschungsarbeiten, Tech-Blogs und echten Code aus der Praxis, um fünf wiederkehrende Probleme zu finden. Betrachten Sie dies als die „Top 5 Wege, um die Arbeit Ihres Zauberers zu vermasseln“:
- Der „Unendliches Budget“-Geruch (Unbounded Max Metrics): Stellen Sie sich vor, Sie sagen Ihrem Zauberer: „Schreib eine Geschichte, aber hör nicht auf, bis dir das Papier oder die Zeit ausgeht.“ In der realen Welt haben APIs Limits. Wenn Sie kein Limit festlegen, wie viele Wörter (Tokens) der Zauberer ausspucken darf oder wie lange er nachdenken darf (Timeouts), erhalten Sie vielleicht eine halbfertige Geschichte, oder schlimmer noch, Ihr Computer bleibt ewig in Wartestellung hängen, während Sie ein Vermögen bezahlen. Die Lösung? Legen Sie immer ein hartes Stopp-Limit für die Länge und die Zeit fest.
- Der „Sich bewegende Ziel“-Geruch (No Model Version Pinning): Stellen Sie sich vor, Ihr Zauberer heißt „GPT-4“. Aber was, wenn das Unternehmen hinter dem Zauberer morgen heimlich das Gehirn im Inneren des „GPT-4“-Körpers durch ein anderes austauscht? Wenn Sie Ihren Code nicht an eine spezifische Version binden (wie „GPT-4 vom 20. November 2024“), wird Ihre Software heute funktionieren und morgen völlig seltsam agieren, weil der Zauberer sich verändert hat. Die Lösung? Binden Sie den Zauberer an eine spezifische, unveränderliche Version.
- Der „Kein Chef“-Geruch (No System Message): Stellen Sie sich vor, Sie schicken Ihren Zauberer in einen Raum, ohne ihm zu sagen, wer er ist oder was die Regeln sind. Er könnte sich wie ein Komiker verhalten, wenn Sie einen Lehrer wollten, oder wie ein Poet, wenn Sie einen Programmierer wollten. Ohne eine „System Message“, die den Ton und die Rolle festlegt, sind die Ergebnisse unvorhersehbar und schwer zu kontrollieren. Die Lösung? Geben Sie dem Zauberer immer eine klare Stellenbeschreibung, bevor er mit der Arbeit beginnt.
- Der „Unordentlicher Schreibtisch“-Geruch (No Structured Output): Stellen Sie sich vor, Sie bitten Ihren Zauberer um eine Liste von Zutaten, aber er liefert Ihnen einen Absatz mit ausschweifendem Text anstatt einer ordentlichen Liste. Wenn Ihre Software eine ordentliche Liste (wie JSON) erwartet, um ihre Aufgabe zu erfüllen, wird sie beim Versuch, das Chaos zu lesen, abstürzen. Die Lösung? Zwingen Sie den Zauberer, in einem strikten Format zu schreiben, wie etwa einer Checkliste, damit Ihre Software es leicht lesen kann.
- Der „Achterbahn“-Geruch (Temperature Not Explicitly Set): Stellen Sie sich den „Kreativitätsregler“ Ihres Zauberers vor. Wenn Sie ihn nicht einstellen, könnte der Zauberer heute super ernst und morgen völlig chaotisch sein, je nachdem, was die Standardeinstellung gerade ist. Dies macht Ihre Software unzuverlässig, da dieselbe Frage jedes Mal eine andere Antwort erhält. Die Lösung? Drehen Sie den Regler immer auf eine spezifische Zahl, damit sich der Zauberer jedes Mal gleich verhält.
Was sie herausgefunden haben (Die Beweise)
Um zu sehen, wie verbreitet diese schlechten Angewohnheiten sind, baute das Team ein spezielles Werkzeug namens SpecDetect4LLM. Betrachten Sie es als einen Rechtschreibprüfer, der nur nach diesen fünf spezifischen zauberbezogenen Fehlern sucht. Sie ließen dieses Tool auf 200 verschiedenen Open-Source-Softwareprojekten laufen, die LLMs verwenden.
Hier ist die große Enthüllung: 60,50 % dieser 200 Projekte wiesen mindestens eine dieser schlechten Angewohnheiten auf. Das ist mehr als die Hälfte!
Das Tool war ziemlich gut darin, die echten Probleme aufzuspüren, mit einer Präzision von 86,06 %. Das bedeutet, dass das Tool, wenn es sagte: „Hey, du hast eine schlechte Angewohnheit hier“, in 86 von 100 Fällen richtig lag.
Sie brachen auch auf, wie oft jeder Geruch auftrat:
- No Structured Output (NSO): Am häufigsten, gefunden in 40,50 % der Systeme.
- Unbounded Max Metrics (UMM): Gefunden in 38,00 % der Systeme.
- No Model Version Pinning (NMVP): Gefunden in 36,00 % der Systeme.
- LLM Temperature Not Explicitly Set (TNES): Gefunden in 36,50 % der Systeme.
- No System Message (NSM): Gefunden in 34,50 % der Systeme.
Was sie nicht wissen (Die Grenzen)
Es ist wichtig anzumerken, was dieses Paper nicht getan hat. Die Autoren haben nicht versucht zu zählen, wie viele schlechte Angewohnheiten sie übersehen haben (sie haben nicht die „Recall“ gemessen). Sie haben nur geprüft, wie genau ihr Tool war, wenn es tatsächlich etwas gefunden hat. Zudem betrachtet ihr Tool den Code auf dem Papier (statische Analyse), es kann also nicht sehen, was passiert, wenn der Code tatsächlich läuft und mit dem Zauberer kommuniziert. Sie schlagen vor, dass zukünftige Arbeiten diese laufenden Effekte untersuchen könnten, aber für den Moment haben sie nur den Code analysiert, wie er in den Dateien liegt.
Das Fazit
Der Hauptpunkt ist nicht, dass diese Systeme irreparabel kaputt sind. Es ist vielmehr, dass Entwickler diese mächtigen KI-Werkzeuge oft wie magische Boxen behandeln, ohne die Bedienungsanleitung zu lesen. Indem sie diese fünf „Gerüche“ definiert und ein Werkzeug zu deren Identifizierung gebaut haben, geben die Autoren den Entwicklern eine Checkliste an die Hand, um ihre KI-integrierte Software zuverlässiger, kostengünstiger im Betrieb und später leichter reparierbar zu machen. Sie sagen nicht, dass sie das gesamte Problem der KI-Sicherheit gelöst haben, aber sie haben definitiv die ersten fünf Schlaglöcher auf der Straße gefunden und Warnschilder aufgestellt, damit alle anderen sie vermeiden können.
Ertrinken Sie in Arbeiten in Ihrem Fachgebiet?
Erhalten Sie tägliche Digests der neuesten Arbeiten passend zu Ihren Forschungsbegriffen — mit technischen Zusammenfassungen, in Ihrer Sprache.