Halluzinationen in Code sind die am wenigsten gefährliche Form von LLM-Fehlern

• Viele Entwickler nutzen LLMs zum Schreiben von Code, erleben dabei jedoch Halluzinationen und verlieren das Vertrauen
  • Dass ein LLM nicht existierende Methoden oder Bibliotheken erfindet, kommt häufig vor
  • Halluzinationen in Code sind jedoch die am wenigsten gefährliche Art von Halluzinationen
• Am gefährlichsten ist es, wenn ein LLM Fehler erzeugt, die vom Compiler oder Interpreter nicht sofort erkannt werden
  • Halluzinierte Methoden lösen beim Ausführen sofort Fehler aus und lassen sich daher leicht entdecken
  • Gibt man die Fehlermeldung erneut in das LLM ein, kann es sie oft automatisch korrigieren
• Anders als bei gewöhnlichen Halluzinationen in Texten lässt sich Code durch Ausführung auf Fakten prüfen
• LLMs mit automatischer Fehlerkorrektur
  • Tools wie ChatGPT Code Interpreter, Claude Code usw. führen den vom LLM geschriebenen Code aus, erkennen Fehler und korrigieren sie selbst
  • Vom LLM geschriebenen Code zu bewerten, ohne ihn überhaupt auszuführen, ist ineffizient
• Einige Entwickler neigen dazu, die Technologie insgesamt abzulehnen, nur weil ein LLM halluzinierte Methoden erzeugt hat
  • Um sie effektiv zu nutzen, sind Lernen und Experimentieren jedoch unverzichtbar
  • Der Autor beschäftigt sich seit mehr als zwei Jahren mit KI-gestützter Code-Erstellung und lernt immer noch neue Techniken
• Manuelles Testen von Code ist unverzichtbar
  • Nur weil Code korrekt läuft, ist nicht garantiert, dass er wie erwartet funktioniert
  • Weder Code-Reviews noch automatisierte Tests können die Korrektheit von Code vollständig verifizieren
  • Das eigene Ausführen und Überprüfen ist ein notwendiger Schritt
  • Von LLMs erzeugter Code ist oft sehr gut lesbar, was leicht zu falscher Sicherheit führen kann
  • Dasselbe gilt für von Menschen geschriebenen Code: Vertrauen sollte man ihm erst, nachdem man ihn selbst ausgeführt hat
• Wie sich Halluzinationen verringern lassen
  • Andere Modelle verwenden: Ein Modell wählen, dessen Trainingsdaten für eine bestimmte Plattform umfangreicher sind
    • Beispiele: Claude 3.7 Sonnet (thinking mode aktiviert), OpenAI o3-mini-high, GPT-4o (einschließlich Python Code Interpreter)
  • Kontext nutzen: Auch wenn das LLM eine bestimmte Bibliothek nicht kennt, kann es mit Beispielcode Muster lernen
    • Das war zuletzt bei der Nutzung der GitHub-Integrationsfunktion von Claude besonders effektiv
  • Auf stabile Technologien setzen: Wählt man ältere Bibliotheken, kann ein LLM oft besser damit umgehen
    • Nutzung der Philosophie von Boring Technology
• Die Bedeutung von Code-Review
  • Der Autor widerspricht der Aussage: "Wenn ich den gesamten von einem LLM geschriebenen Code reviewen muss, ist es schneller, ihn selbst zu schreiben"
  • Diese Aussage kann auch mangelnde Fähigkeit zum Code-Review erkennen lassen
  • Das Review von von LLMs erzeugtem Code kann eine gute Gelegenheit sein, die eigenen Fähigkeiten zu verbessern
• Bonus: Feedback von Claude 3.7 Sonnet
  • Der Autor bat Claude 3.7 Sonnet im "extended thinking mode", einen Blog-Entwurf zu prüfen
  • Er bat darum zu bewerten, ob die Logik des Artikels überzeugend ist, was verbessert werden könnte und welche Inhalte fehlen
  • Claude half dabei, den Ton des Entwurfs etwas milder zu machen
  • Link zum Claude-Feedback-Gespräch

[GN⁺]

Hacker-News-Kommentar

• Der Verfasser stimmte dem vorherigen Beitrag zu, diesem jedoch nicht

  • Er widerspricht der Aussage: „Wenn ich jeden von einem LLM geschriebenen Code prüfen muss, bin ich schneller, wenn ich ihn selbst schreibe“
  • Er stimmt nicht der Behauptung zu, dass zu wenig in die Fähigkeit investiert werde, fremden Code zu lesen, zu verstehen und zu prüfen
  • Review hängt von der Fachkenntnis und Vertrauenswürdigkeit des Autors ab; anonyme Beiträge zu prüfen ist etwas anderes
  • Wichtig ist, die Absicht und den Ansatz des Codes zu erschließen und zu vergleichen; bei LLMs ist dieser Rahmen begrenzt
  • Motivation ist wichtig, und nicht alle Entwickler mögen Code-Reviews
  • Code von LLMs hat keine soziale Komponente, und andere Menschen müssen die Änderungen dennoch prüfen

• Selbst wenn von LLMs erzeugter Code gut funktioniert, ist es schwierig, Bugs oder logische Fehler zu finden, wenn man ihn nicht selbst geschrieben hat

  • Wenn man Programmieren nicht als Umsetzung eines gut entworfenen Plans sieht, sondern als Zusammensetzen von Teilen, gibt es Bedenken dagegen, dass ein Algorithmus die Teile nur per Vermutung zusammensetzt
  • LLMs gehen nicht die Risiken ein, die Menschen in Kauf nehmen können, und verstehen möglicherweise nicht die Bedeutung eines Codeblocks in einem bestimmten Kontext

• Von LLMs erzeugter Code ist sauber, aber man verbringt mehr Zeit mit QA und Aufräumarbeiten

  • Dass Code gut läuft und keine Fehler wirft, bedeutet nicht, dass er das Richtige tut
  • Code auszuführen und zu testen allein kann seine Korrektheit nicht beweisen; man muss logisch darüber nachdenken

• The Primeagen und Casey Muratori prüfen die Ausgabe aktueller LLM-Codegeneratoren

  • Man sollte ihnen Aufgaben geben, die in den Trainingsdaten gut repräsentiert sind, damit die Entwicklung einfach sein müsste
  • In der Praxis konvergiert iterative Entwicklung zu nutzlosem Code, und das LLM macht zunehmend keine Fortschritte mehr

• Eine weitere Fehlerkategorie, die Simon übersehen hat, sind Halluzinationen, bei denen das Modell Funktionalität vergisst

  • Schwerwiegender als der positive Aspekt, dass der Code kompiliert, ist der negative Aspekt, dass Kernfunktionen vergessen werden
  • Die Funktionalität kann sich leicht ändern, abhängig von Code, der außerhalb des Gesprächs-/Kontextfensters liegen dürfte

• Halluzinierte Methoden sind ein kleines Hindernis, und wenn Leute sich darüber beschweren, wird angenommen, dass sie nur minimal Zeit investiert haben, um zu lernen, wie man das System effektiv nutzt

  • Diese Annahme ist sehr falsch, und Menschen sehen Halluzinationen und denken: „Wenn es nicht einmal die einfachsten Dinge konsistent richtig hinbekommt, kann ich ihm bei schwierigeren Dingen nicht vertrauen“

• Halluzinationen selbst sind nicht das größte Risiko, das LLMs darstellen

  • Das größere Risiko ist, dass Chatbots Menschen dazu überreden können, sich selbst zu schaden
  • Dafür gibt es bereits bekannte Fälle, und Ideen dazu, was noch gefährlicher sein könnte, möchte man lieber nicht teilen

• Nur im begrenzten Kontext von Compilerfehlern ist es weniger gefährlich

  • Wenn ein Programmierer eine ganze Bibliothek erfunden hätte, um sich die Mühe zu sparen, eine echte Lösung zu finden, wäre man noch verärgerter
  • Wenn man Halluzinationen nur als bloße Verlangsamung betrachtet, unterschätzt man, was LLMs eigentlich leisten müssten

• Um mit LLMs gute Ergebnisse zu erzielen, ist viel Aufwand nötig

  • Das durchschaut den Hype
  • Es stellt sich die Frage, wofür LLMs nützlich sind und was man erwarten kann, wenn man jahrelang lernen muss, um unzuverlässige Ergebnisse zu erhalten

• Erfahrung beim Schreiben von Code, um in einem medizinischen Zentrum die „primäre“ Klinik eines Patienten zu finden

  • Es musste der neueste Termin gefunden werden, wobei nur klinische Termine berücksichtigt wurden
  • Wenn es keine klinischen Termine gab, musste der neueste Termin jeglicher Art gefunden werden
  • Der Code wurde durch Sortieren der Daten geschrieben, aber ChatGPT verstand beim Dokumentieren die Sortierreihenfolge umgekehrt
  • Das ist ein viel schlimmerer Fehler als „Der Code läuft nicht“