Von starren Kartierungs-Tools zu flexibler Konfiguration: Ein System zur Informationsextraktion¶

Wir haben ein System entwickelt, das strukturierte Informationen aus Webseiten extrahiert – konfigurierbar durch Prompts statt durch Code. Das löst ein häufiges Problem: Für jede neue Anforderung musste bisher individuell programmiert werden.

Was war die Herausforderung?¶

Ein bestehendes Kartierungssystem für KI-Initiativen an deutschen Hochschulen war zu unflexibel. Für jede neue Art von Steckbrief – ob für Services, Handreichungen oder Forschungsprojekte – wäre separater Programmieraufwand nötig gewesen.

Wir wollten ein System, das verschiedene Kartierungen ermöglicht. Die Flexibilität sollte durch strukturierte Konfiguration entstehen, nicht durch Programmierung.

Was kann das System?¶

Webseiten crawlen und Informationen extrahieren (aus Hochschul-Seiten, Projekt-Dokumentationen, Service-Beschreibungen)
Steckbriefe per Prompt konfigurieren (Markdown-Templates mit Variablen statt hartkodierter Felder)
Zwei-Phasen-Qualitätssicherung (erst Extraktion, dann automatische Bewertung mit Confidence-Score)
Automatisches Review-Routing (unsichere Ergebnisse landen zur manuellen Prüfung in einer Warteschlange)
Entitäten normalisieren (z. B. werden „TU Berlin", „Technische Universität Berlin" und „TUB" auf einen Namen vereinheitlicht)

So entsteht eine konsistente Datenbasis ohne manuelle Nacharbeit.

Wie haben wir es entwickelt?¶

Wir haben einen strikten Phasenansatz verfolgt:

Phase 1 (mehrere Sessions): Funktionalitäten diskutiert, bis klare Lösungskonzepte standen
Phase 2 (parallel): Technische Architektur bewertet und Umsetzungsvarianten verglichen
Phase 3 (nach Architektur-Freigabe): Implementierung mit LLM-Unterstützung

Gesamtaufwand: Etwa 10 Sessions über zwei Monate, mit 3 größeren Architektur-Iterationen

Ergebnis: 95 Dateien mit 43.000 Zeilen Code, davon 37 Python-Dateien mit etwa 22.000 Zeilen

Warum lief es so gut?¶

Weil wir viel Zeit in detaillierte Spezifikationen investiert haben.

Die erstellten Dokumente enthielten ASCII-Diagramme für Architekturen, vollständige Datenbank-Schemas und Code-Beispiele für zentrale Services. Diese Detailtiefe führte dazu, dass die Code-Generierung durch das LLM weitgehend fehlerfrei verlief.

Erste Tests zeigen: Das System funktioniert besser als erwartet. Über 80 Prozent der Felder werden mit ausreichender Confidence extrahiert. Besonders die Qualitätssicherungs-Schicht bewährt sich – sie filtert unzuverlässige Extraktionen zuverlässig heraus.

Wichtige Erkenntnisse¶

Vom Groben zum Feinen arbeiten

Bei umfangreichen Projekten funktioniert LLM-gestützte Entwicklung, wenn man von der Gesamtarchitektur zu Modulen zu Funktionen fortschreitet. Wir haben große Teile zunächst als Gesamtspezifikation entwickelt, dann in separaten Sessions modular verfeinert.

Architektur-Diskussionen schützen vor Overengineering

LLMs neigen dazu, zu komplexe Lösungen vorzuschlagen. Intensive Diskussionen und explizite Vorgaben zur Einfachheit haben dem entgegengewirkt. Die Wahl von htmx + Alpine.js statt eines SPA-Frameworks war eine bewusste Entscheidung für Simplizität.

LLMs bringen architektonische Best Practices ein

Einige robuste Muster wie der Circuit Breaker (ein Schutzmechanismus gegen Backend-Überlastung) entstanden als LLM-Vorschläge. Das zeigt: LLMs können nicht nur Code generieren, sondern auch Patterns einbringen, die man selbst nicht sofort auf dem Radar hat.

Was können andere davon lernen?¶

Die Architektur muss belastbar sein, bevor Details implementiert werden.
Detaillierte Spezifikationen zahlen sich durch fehlerfreie Implementierung aus.
Aktiv gegen Overengineering steuern – LLMs schlagen gerne komplexe Lösungen vor.
LLM-Vorschläge zu Architektur-Patterns ernst nehmen und prüfen.

Fazit¶

✔ LLM-gestützte Entwicklung funktioniert auch bei großen Projekten – mit klarer Architektur vorab

✔ Zeit in Spezifikation investieren zahlt sich durch fehlerfreie Implementierung aus

✔ Modularer Ansatz vom Groben zum Feinen ist der Schlüssel

Dies ist Teil einer Serie über Erkenntnisse aus LLM-gestützten Entwicklungsprojekten. Der Fokus liegt darauf, was man aus solchen Projekten lernen kann – nicht nur auf den technischen Ergebnissen.