Probleme mit den aktuellen LLMs

Last Update: 2025-12-11

Ich habe in meiner Freizeit kürzlich eine TUI zur Code-Generierung über LLMs entwickelt namens scriptschnell. Dies gab mir einige Einblicke darin, was aktuellen LLMs derzeit fehlt.

Geschwindigkeit

Nach der Nutzung von Cerebras und Groq (mit q) in geringerem Umfang, lässt die Geschwindigkeit, die OpenAI's Modelle gpt-5.1-codex oder gpt-5.1-codex-mini bieten, zu wünschen übrig.

Die Code-Generierung erfordert viel Nachschlagen aktueller Implementierungsdetails, Erstellen oder Ändern von Dateien und anschließendes Validieren des Ergebnisses. All dies erfordert viele Tokens (nach meiner Erfahrung allein das Durchsuchen der Codebasis benötigt mindestens 20k Tokens).

Einige Code-Generierungs-Anwendungen wie Windsurf nutzen ein deutlich schnelleres Modell, um einige Aufgaben wie das Erkunden der Codebasis zu beschleunigen.

Tool-Calls

Man kann erkennen, dass viele Modelle darauf trainiert sind, spezifische Tool-Calls zu verwenden. Z.B. versucht Kimi K2 Instruct bei der Eingabe von nur "ls" einen Tool-Call namens shell zu verwenden, obwohl dieser nicht existiert.

Genauer gesagt erforderte es viele Versuche und Irrtümer, um LLM-Modelle dazu zu bringen, komplexere Programme für meinen Golang-Sandbox-Tool-Call zu schreiben (z.B. Erstellen einer Anwendung und Extrahieren von Schlüsselfehlern mit einer Summarize-Methode).

Eingebaute Annahmen

Die Modellleistung scheint derzeit am besten zu sein, wenn man eingebaute Annahmen verwendet, die während des Trainingsprozesses eingeprägt wurden. Dies ist besonders problematisch, wenn man neuere externe Bibliotheken verwendet als den Wissens-Cutoff-Zeitpunkt des Trainings.

Probleme mit dem Kontextfenster

Die aktuellen Kontextfenster sind bei State-of-the-Art-Modellen mindestens 128k groß.

Aber wenn bereits ein Teil davon durch den System-Prompt und Tool-Beschreibungen belegt ist und anschließend die Untersuchung der Codebasis erfolgt, ist das Kontextfenster zu klein.

Das größte Problem hierbei ist, dass die Modellleistung scheinbar abrupt einbricht, wenn große Teile des gegebenen Kontextfensters genutzt werden.

z.B. bei Claude Opus 4.5, dem neuesten, größten und teuersten Modell zum Zeitpunkt des Schreibens, scheint es zu lieben, den Code-Stil der Codebasis zu ignorieren, wenn 3/4 seines Kontextfensters verbraucht sind.

Die Komprimierung des Kontextfensters, um nahtlos endlose Sitzungen zu ermöglichen, ist auch schwer erfolgreich zu steuern. Die Übertragung von Informationen über Code-Stil und gelöste Probleme über die Zusammenfassungs-Grenze fühlt sich wie ein Glücksspiel an. Auch das Modell nur die halbe Geschichte zu erzählen, führt zum Scheitern, da dann das Modell beginnt, die Codebasis erneut zu durchsuchen und wertvolle Tokens verbraucht.

Vision

Vision funktioniert immer noch nicht wirklich. Selbst einfachere Aufgaben wie das Erstellen einer HTML-Datei oder SVG-Datei aus einem Screenshot machen das Modell inkompetent wirken (z.B. Erstellen eines SVG aus einem Firmenlogo).

Abschließende Worte

Ich denke, wir haben mit dem aktuellen Zustand der Transformer-Modelle noch einen langen Weg vor uns.

Wenn man Agenten für spezifische Aufgaben erstellt, muss man sein Programm für die spezifische Modellfamilie optimieren.

Wir sind mit der aktuellen LLM-Technologie wirklich weit gekommen und ich denke, dass viele Hacks, die auf den aktuellen Implementierungen aufsetzen, den derzeitigen Zustand noch erheblich verbessern können.

Quellen