LLM-Coding-Experiment: Ein generisches Informationsextraktionssystem#

Teil einer Serie über methodische Erkenntnisse aus LLM-gestützten Entwicklungsprojekten

Ausgangslage und Zielsetzung#

Im Rahmen einer Reihe von Experimenten zur LLM-gestützten Softwareentwicklung entstand ein generisches System zur Informationsextraktion aus Webseiten. Das Projekt war kein reines Lernexperiment, sondern adressierte ein konkretes Problem: Ein bestehendes Kartierungssystem für KI-Initiativen an deutschen Hochschulen war zu unflexibel, um verschiedene Arten von Steckbriefen zu erzeugen. Für jede neue Anforderung – ob KI-Handreichungen, Services oder Forschungsprojekte – wäre individueller Programmieraufwand nötig gewesen.

Die zentrale Anforderung lautete daher: Ein System, das unterschiedliche Kartierungen ermöglicht, konfigurierbar durch Prompts statt durch Code. Die Flexibilität sollte nicht durch Programmierung, sondern durch strukturierte Konfiguration erreicht werden.

Was das System leistet#

Das entwickelte System crawlt Webseiten, extrahiert strukturierte Informationen und generiert daraus Steckbriefe. Der Kern ist ein prompt-basiertes Konfigurationskonzept: Statt Code zu schreiben, definiert man einen Steckbrief als Markdown-Template mit Variablen. Für jede Variable existiert ein Extraktions-Prompt, der beschreibt, welche Information gesucht wird, und ein Qualitätssicherungs-Prompt, der das Ergebnis bewertet.

Der Extraktionsprozess läuft zweiphasig ab. In der ersten Phase extrahiert ein LLM die Rohdaten aus dem gecrawlten Markdown. Der Prompt enthält präzise Anweisungen und Beispiele für korrekte sowie inkorrekte Extraktionen. In der zweiten Phase bewertet ein separater LLM-Aufruf die Qualität des Ergebnisses. Diese Validierung prüft Kriterien wie Eindeutigkeit, Plausibilität und Übereinstimmung mit dem Quelltext. Das Ergebnis ist ein Confidence-Score zwischen 0 und 1.

Felder unterhalb eines konfigurierbaren Schwellenwerts landen automatisch in einer Review-Queue zur manuellen Prüfung. So wird sichergestellt, dass nur qualitativ hochwertige Extraktionen in die Steckbriefe einfließen.

Ergänzend normalisiert das System Entitäten wie Hochschulnamen. Die Varianten “TU Berlin”, “Technische Universität Berlin” und “TUB” werden automatisch auf einen kanonischen Namen abgebildet. Dies ermöglicht übergreifende Suchen und konsistente Verlinkungen.

Der Entwicklungsprozess#

Der Entwicklungsprozess folgte einem strikten Phasenmodell. Zunächst wurden Funktionalitäten intensiv diskutiert, bis klare Lösungskonzepte definiert waren. Dann folgten technische Architektur-Diskussionen, in denen verschiedene Umsetzungsvarianten bewertet wurden. Erst als die Gesamtarchitektur stand, begann die eigentliche Implementierung.

Die erstellten Spezifikationsdokumente sind bemerkenswert detailliert: ASCII-Diagramme für Architekturen, vollständige Datenbank-Schemas, Code-Beispiele für zentrale Services und klare MVP-Abgrenzungen. Diese Detailtiefe führte dazu, dass die Code-Generierung durch das LLM weitgehend fehlerfrei verlief.

Methodische Erkenntnisse#

Vom Groben zum Feinen: Bei umfangreichen Projekten funktioniert LLM-Coding, wenn man von der Gesamtarchitektur zu Modulen zu Funktionen fortschreitet. Große Teile wurden zunächst als Gesamtspezifikation entwickelt, dann in separaten Sessions modular verfeinert. Die Architektur muss belastbar sein, bevor Details implementiert werden.

Architektur-Diskussion als Schutz vor Overengineering: LLMs neigen dazu, zu komplexe Lösungen vorzuschlagen. Intensive Diskussionen zu Architekturentscheidungen und explizite Vorgaben zur Einfachheit wirkten dem entgegen. Die Wahl von htmx + Alpine.js statt eines SPA-Frameworks war eine bewusste Entscheidung für Simplizität.

LLM-initiierte Patterns: Einige robuste Architekturmuster wie der Circuit Breaker für das LLM-Backend entstanden als LLM-Vorschläge während der Diskussion. Das zeigt, dass LLMs nicht nur Code generieren, sondern auch architektonische Best Practices einbringen können, die man selbst nicht sofort auf dem Radar hat.

Umfang und Ergebnisse#

Das Projekt umfasst 95 Dateien mit insgesamt 43.000 Zeilen, davon 37 Python-Dateien mit etwa 22.000 Zeilen und 20 HTML-Templates. Die Entwicklung verteilte sich auf circa 10 Sessions über zwei Monate, mit drei größeren Architektur-Iterationen.

Aktuell sind etwa 100 Prompts in vier Kategorien konfiguriert. Das System hat bisher rund 100 Quellen verarbeitet, wobei eine Quelle je nach Komplexität zwischen 10 und 60 Sekunden benötigt. Die Zwei-Phasen-Extraktion erreicht die angestrebten Qualitätsziele: Über 80 Prozent der Felder werden mit ausreichender Confidence extrahiert. Das System funktioniert nach Entwickleraussage “besser als gedacht”. Besonders die QS-Schicht bewährt sich – sie filtert unzuverlässige Extraktionen zuverlässig heraus.

Fazit#

Das Experiment zeigt, dass LLM-gestützte Entwicklung auch bei umfangreichen Projekten funktioniert, wenn drei Bedingungen erfüllt sind: eine belastbare Architektur vor Implementierungsbeginn, ein modularer Ansatz vom Groben zum Feinen, und aktive Steuerung gegen Overengineering. Die investierte Zeit in Spezifikation und Architektur-Diskussion zahlt sich durch weitgehend fehlerfreie Implementierung aus.