opengovai4d

Wissensdiagramm

Knowledge Graph AI4Deliberation modelliert öffentliche Konsultationen als strukturierte IBIS-Hierarchie (Issue-Based Information System): Die Konsultationen enthalten Artikel (Rechtsvorschriften), in denen die Standpunkte der Bürgerinnen und Bürger (Änderungsvorschläge) akzeptiert werden, die jeweils durch Argumente unterstützt werden. Analysen, die über LLM aus mehreren Konsultationsdatensätzen extrahiert werden, werden über eine ETL-Pipeline in RDF-Triples umgewandelt, die in einem Virtuoso-Triple-Store gespeichert sind. Ein RAG-Dienst mit mehreren Agenten (Übersetzer → Validator → Erzähler) beantwortet Fragen in natürlicher Sprache, indem er SPARQL-Abfragen in diesem Diagramm erstellt und ausführt.

Wie es funktioniert Wissensdiagramm;

1. Daten
Die Quelle sind griechische Konsultationsdaten, die aus mehreren SQLite-Datenbanken bestehen, eine pro Gesetzgebungsartikel. Jede Datenbank enthält Kommentare von Bürgern, die im Voraus von einem Tool verarbeitet wurden, das aus jedem Kommentar einen strukturierten JSON extrahierte: eine Liste der Planstellen (vorgeschlagene Änderungen mit Änderung _type: Hinzufügung, Entfernung, Änderung oder Vorschlag) und Argumente nach Ort (jeweils mit Polarität: positiv, negativ oder neutral).


2. ETL-Pipeline
Die Pipeline läuft in zwei Phasen:
Ausfuhr: Es liest jede SQLite-Datenbank und analysiert JSON. Behält die gesamte verschachtelte Struktur bei: Beratung → Artikel → Kommentar → Positionen → Argumente. Metadaten zu Artikeln und Konsultationen (Titel, Ministerium, Daten) werden von der Hauptdatenquelle der Konsultation durchsucht.
Umwandlung: Konvertiert die extrahierten Daten mithilfe der IBIS-Ontologie in RDF-Triaden:

  • Jede Konsultation und jeder Artikel wird zum ibis:Issue Hub
  • ibis:questions verknüpft eine Konsultation mit jedem ihrer Artikel
  • Jede exportierte Position wird zu ibis:Position mit ibis:respondsTo, das in seinem Artikel angezeigt wird
  • Beiträge mit Änderungsantrag _type: Entfernung oder Änderung erwerben auch ibis:objectsTo → Artikel
  • Jedes Argument wird zu ibis:Argument mit ibis:supports oder ibis:objectsZur Anzeige in seiner Position
  • Erste Bürgerkommentare werden als og:Kommentarknoten gespeichert, die über og:extractedFrom mit Standorten verbunden sind

3. Wissensgrafik speichern
Die Pipeline serialisiert den Graphen im ttl-Dateiformat. Diese Turtle-Datei wird in einen Virtuoso-Triple-Store geladen, der einen SPARQL 1.1-Endpunkt freilegt.


4. RAG-Dienstleistung
Ein FastAPI-Service umfasst eine Pipeline von drei Agenten, die von LLMs unterstützt werden:

  • Agent des Übersetzers: Es nimmt die natürliche Sprachfrage des Benutzers (zusammen mit dem Konversationsverlauf) und generiert eine SPARQL-Abfrage nach den IBIS-Transitregeln.
  • Agent-Validator: Es überprüft die generierte SPARQL auf strukturelle Korrektheit, wie gültige Präfixe, gültige Eigenschaften, korrekte mehrstufige Kreuzung, ohne falsche Prädikate, und genehmigt sie entweder oder gibt eine Korrektur zurück.
  • Erzähler des Agenten: Führt die validierte Abfrage in Virtuoso aus, empfängt die rohen Ergebniszeilen und komponiert je nach Frage eine kohärente natürliche Sprachantwort in Griechisch oder Englisch.

5. Benutzerinteraktion
Benutzer senden eine Frage (mit optionalem Chatverlauf) an den Endpunkt. Die drei Agenten werden nacheinander ausgeführt. Wenn die Abfrage keine Ergebnisse liefert, gibt Narrator sie klar an, anstatt eine Antwort zu erfinden. Mehrrundengespräche werden unterstützt, indem bei jeder Anfrage vorherige Paare (Frage, Antwort) übertragen werden.