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#

  1. 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.

  1. 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.

  1. 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.