Zum Inhalt

Flex-Kartierung — Funktionen

Flex-Kartierung deckt den vollständigen Weg von einer URL zur Veröffentlichung als Steckbrief ab: Konfiguration der Erfassung, Crawling, mehrstufige Extraktion, manuelle Nachbearbeitung, Entity-Vereinheitlichung, Übersetzung sowie Generierung einer statischen Website. Die folgenden Abschnitte beschreiben die Anwendung aus Nutzersicht.

Anwendungsszenarien

  • Forschungsprojekte einer Hochschule erfassen. Eine Liste von Projekt-Webseiten wird in der Anwendung hinterlegt; das System extrahiert Projektname, Institution, Förderinformationen, Laufzeit, Team, Schlagworte und Beschreibungen und stellt die Ergebnisse als einheitliche Steckbriefe bereit.

  • Bestand an KI-Diensten an einer Einrichtung inventarisieren. Aus den Webseiten der hochschuleigenen KI-Angebote werden Servicebezeichnung, Zielgruppe, Zugangsvoraussetzungen, Verfügbarkeit, Lizenz und Kontaktinformationen ausgelesen und in einer durchsuchbaren Übersicht zusammengeführt.

  • Handreichungen und Leitfäden sammeln. Vorhandene Leitfäden zu KI-Nutzung in Studium und Lehre werden über ihre Webseiten erfasst; aus Titel, Zielgruppe und Inhalten entstehen Steckbriefe, die ohne Wechsel auf die Originalseite vergleichbar sind.

  • Kooperative Dienste mehrerer Einrichtungen kartieren. Standortübergreifende Angebote werden mit beteiligten Institutionen, Trägerschaft und Zugangswegen erfasst; durch die Entity-Normalisierung erscheinen Hochschulen mit einer einheitlichen Schreibweise.

  • Datenqualität iterativ verbessern. Ergebnisse mit niedriger Confidence werden in einer Review-Queue nachbearbeitet; Prompts können angepasst und einzelne Felder oder ganze Quellen erneut extrahiert werden, ohne andere Ergebnisse zu verändern.

  • Öffentliche Übersicht zweisprachig veröffentlichen. Aus den geprüften Steckbriefen entsteht eine statische Website in Deutsch und Englisch mit Kategorieseiten, Detailseiten, Volltextsuche und einer JSON-API für externe Konsumenten.

Auf einen Blick

  • Konfiguration neuer Inhaltstypen über YAML-Dateien (Kategorie, Feldgruppen, Prompts, Steckbrief-Template).
  • Web-Crawler mit Multi-Page-Modus (bis zu fünf verlinkten Unterseiten), robots.txt-Beachtung und domain-spezifischem Rate-Limit.
  • Zweistufige Extraktion (Extract + Validate) mit Confidence-Score, Qualitätsklasse und Begründung pro Feld.
  • Review-Queue für niedrig bewertete Ergebnisse, Inline-Editor und gezielte Re-Extraktion einzelner Quellen oder Felder.
  • LLM-gestützte Entity-Verwaltung für Hochschulen und Orte mit Varianten, Auto-Linking und manueller Bestätigung.
  • Feldweise Übersetzung der validierten Ergebnisse Deutsch → Englisch mit Regeln zum Schutz von Eigennamen, URLs und Fachabkürzungen.
  • Export als Markdown-Steckbriefe und als statische Website (HTML + Suche + Sitemap + API), getrennt nach Sprache.

Konfiguration und Steckbrief-Definition

Die Erfassung wird vollständig über YAML-Kategoriedateien beschrieben. Eine Kategorie legt einen Inhaltstyp fest und besteht aus einem internen Namen, einem Anzeigenamen, einer Liste von Feldgruppen, einer Auswahl der im Steckbrief sichtbaren Gruppen und einem Markdown-Template mit Platzhaltern. Zu jedem Feld gehört ein Prompt mit Extraktionsanweisung, Format- und Fallback-Vorgabe, optional einer Validate-Anweisung sowie einer Markierung, ob das Feld übersetzbar ist. Vorkonfiguriert sind die Kategorien projekt (Forschungsprojekte), ki_service (KI-Dienste), handreichung (Leitfäden) und kooperativer_dienst (kooperative Dienste). Eigene Kategorien werden als zusätzliche YAML-Dateien hinzugefügt und beim Reload synchronisiert.

Konnektoren

Flex-Kartierung bindet vier Quellen- bzw. Backend-Systeme an. Externe Konnektoren sind detailliert beschrieben; interne Konnektoren werden nur grob umrissen, da sie Standard-Infrastruktur darstellen.

  • Web-Crawler (extern, HTTP/HTTPS). Liest öffentliche Webseiten ein und konvertiert das HTML in Markdown. Der Crawler unterstützt einen Multi-Page-Modus, in dem ausgehend von einer Hauptseite eine konfigurierbare Anzahl verlinkter Unterseiten derselben Domain mitverarbeitet wird, sowie eine Liste manuell ergänzter Zusatz-URLs. Pro Domain greift ein Rate-Limit; robots.txt-Regeln werden ausgewertet und können bei Bedarf abgeschaltet werden. Die SSL-Prüfung ist optional, um auch Einrichtungen mit selbstsignierten Zertifikaten zu erfassen.

  • LLM-Backend (extern aus Anwendungssicht, intern in der Betriebsumgebung). Das System spricht eine OpenAI-kompatible Chat-Completion-Schnittstelle an und ist auf den Betrieb gegen ein lokal vorgehaltenes Modell ausgelegt. Adresse, Modellname, Temperatur, Token-Limit, Anfragenrate pro Minute und Mindestabstand zwischen Aufrufen sind konfigurierbar.

  • PostgreSQL (intern). Persistente Speicherung aller Stammdaten, Quellen, Markdown-Inhalte, Extraktionen, Steckbriefe und Übersetzungen.

  • Redis (intern). Job-Queue für die Pipeline-Schritte sowie Cache für betriebsinterne Zwischenstände.

Import- und Exportformate

  • Import: URLs (einzeln oder mit Liste zusätzlicher Unterseiten) über die Bedienoberfläche und über die Admin-API; YAML-Dateien für Kategorien und Prompts; Skripte zum Vorbefüllen von Hochschul-Stammdaten.
  • Export Steckbriefe: Markdown-Steckbriefe pro Quelle, optional als HTML; Generierung gegen ein kategorie-spezifisches Markdown-Template.
  • Export Website: vollständig statische HTML-Site mit Kategorieseiten, Detailseiten, Such-Seite, Impressum, Sitemap und schema.org-Markup; pro Sprache (Deutsch / Englisch) eine eigene URL-Struktur.
  • Maschinelle Schnittstellen: Public-API mit Kategorie-, Steckbrief- und Statistik-Endpunkten sowie einem Such-Index als JSON für die clientseitige Volltextsuche; OpenAPI-Dokumentation der Admin- und Public-API.
  • Konfiguration: Export aller Kategorie-Definitionen als ZIP zur Versionierung außerhalb der Anwendung.
  • Betriebsmetriken: Prometheus-Metriken am /metrics-Endpunkt sowie strukturierte JSON-Logs.

Qualitätssicherung

Die Qualitätssicherungsschicht ist als eigene Pipeline-Stufe modelliert und nicht nur als Prüfung am Ende. Jede Aussage über ein Feld trägt eine Bewertung, eine Herkunftsangabe und gegebenenfalls einen manuellen Eingriff.

  • Validate-Phase. Für jeden Prompt führt das System nach der Extract-Phase eine zweite LLM-Anfrage durch, die das Rohergebnis bewertet und in eine Qualitätsklasse, einen Score und eine Begründung überführt. Das validierte Ergebnis kann von der Rohextraktion abweichen.
  • Required-Confidence pro Prompt. Jedes Feld definiert eine eigene Mindest-Konfidenz; Werte darunter werden als prüfbedürftig markiert.
  • Review-Queue mit Inline-Editor. Niedrig bewertete Felder werden in einer eigenen Ansicht zusammengeführt, mit Quell-Markdown als Kontext und mit der Möglichkeit, den Wert direkt zu korrigieren. Manuelle Korrekturen werden separat ausgewiesen.
  • Entity-Normalisierungs-Queue. Extraktionen mit Entity-Bezug werden gegen den bestehenden Entity-Bestand inklusive Varianten abgeglichen. Oberhalb einer Auto-Link-Schwelle wird automatisch verknüpft, in einem mittleren Bereich entsteht eine Review-Aufgabe, unterhalb wird die Verknüpfung verworfen.
  • Prompt-Dependencies. Felder mit Abhängigkeiten werden erst ausgeführt, wenn die Quellfelder vorliegen; das System löst die Reihenfolge automatisch in Wellen auf und erkennt zyklische Abhängigkeiten.
  • Re-Extract / Re-Validate / Re-Generate. Einzelne Quellen, Felder oder Steckbriefe können erneut verarbeitet werden, ohne andere Daten zu beeinflussen; manuelle Korrekturen bleiben dabei erhalten oder werden gezielt überschrieben.
  • Vollständige Trennung der Verarbeitungsstufen. Pro Extraktion sind Rohergebnis, validiertes Ergebnis, manuelle Korrektur und Übersetzung als separate Felder verfügbar; das gecrawlte Markdown bleibt zur Nachvollziehbarkeit erhalten.
  • Robustheit gegenüber Backend-Fehlern. Ein Circuit Breaker schützt vor wiederholten LLM-Fehlern; transiente Fehler werden über einen Retry-Manager mit exponentiellem Backoff und Jitter abgefangen.

Mehrsprachigkeit

Die Übersetzung deutscher Steckbriefe ins Englische erfolgt feldweise als eigener Pipeline-Schritt. Pro Feld bestimmt die Kategorie-Definition, ob es übersetzt werden soll; Eigennamen, URLs und technische Abkürzungen werden gemäß einer expliziten Regel nicht angetastet. Englische Anzeigenamen für Felder und Kategorien sowie ein zweisprachiges UI-Vokabular werden über i18n-Dateien gepflegt; die statische Website wird pro Sprache erzeugt und ist über einen Sprachumschalter verbunden.

Bedienoberfläche

Die Admin-Oberfläche ist serverseitig gerendert und nutzt htmx und Alpine.js für interaktive Bestandteile, ohne separaten Frontend-Build-Schritt. Sie umfasst ein Dashboard mit Status- und Qualitätsmetriken, Verwaltungsansichten für Kategorien, Prompts, Quellen, Extraktionen, Entitäten und Steckbriefe sowie Auslöser für die Site-Generierung, Übersetzung und Wartungsaufgaben. Niedrig bewertete Extraktionen sind direkt in der Liste editierbar; der Status laufender Aufträge wird über Polling aktualisiert.