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.