Zum Inhalt springen
GraphRAG Compass
  • Grundlagen
  • Architekturen
  • Praxis
  • Business Cases
  • Lernpfad
  • Simulation
  • Landkarte
GraphRAG Compass

Öffentlicher Field Guide für GraphRAG, Knowledge Graphs, AI-Architekturen und bessere Entscheidungen in komplexen Wissenssystemen.

Erkunden

  • Grundlagen
  • Architekturen
  • Praxis
  • Business Cases
  • Simulation
  • Landkarte

Lernen

  • Lernpfad
  • Mini-Use-Case
  • GraphRAG Poster
  • Glossar

Über

  • About
  • LinkedIn

Discovery

  • llms.txt
  • llms-full.txt
  • sitemap.xml

Rechtliches

  • Impressum
  • Datenschutz

© 2026 Meierhoff Systems · GraphRAG Compass

Orientierung für Entscheidungen in Wissenssystemen

Zurück zu Praxis

Praxis · Graph nutzen

Graph Querying / Cypher / SPARQL

Graph Querying übersetzt fachliche Fragen in Beziehungsmuster: Welche Dinge sind verbunden, über welche Pfade, mit welchen Bedingungen?

Graph nutzen
Graph Querying
Querschnittsthema

Wie fragt man Graphwissen praktisch ab?

2 Min LesezeitGraph nutzen

Warum es wichtig ist

Graphen werden erst wertvoll, wenn Teams und Agenten präzise nach Beziehungen fragen können: Abhängigkeiten, Pfade, Nachweise, Themencluster oder Lücken.

Kernideen

Die wichtigsten Prinzipien dieses Themas auf einen Blick.

1

Graphabfragen suchen Beziehungsmuster zwischen Datensätzen.

2

Cypher passt gut zu Neo4j und Property Graphs; SPARQL passt zu RDF- und Ontologie-nahen Graphen.

3

Gute Abfragen hängen an guter Modellierung: Kantenrichtung, Typen und Eigenschaften müssen verständlich sein.

4

Für Agenten sollten Graphabfragen oft als sichere Tools mit klaren Eingaben gekapselt werden.

Startfragen

Diese Fragen machen das Thema praktisch prüfbar. Hak sie ab – sie eignen sich als Einstieg für Workshops, Pilotvorhaben oder Architekturreviews.

0/4 geprüft

Die Grundidee

Graph Querying bedeutet: Du fragst nach passenden Textstellen, Tabellenzeilen und nach einem Beziehungsmuster. Eine gute Graphfrage sagt, welche Dinge gesucht werden, wie sie verbunden sind und welche Bedingungen gelten. Für GraphRAG ist das wichtig, weil der Graph dann nicht bloß Speicher ist und Antwortlogik liefert: Pfade, Nachbarschaften, Abhängigkeiten und Nachweise.

Cypher

Cypher ist die typische Abfragesprache für Property Graphs wie Neo4j. Sie ist stark, wenn du Knoten, Beziehungen, Eigenschaften und Pfade in einem konkreten Graphmodell abfragen willst.

SPARQL

SPARQL wird im RDF- und Ontologie-Umfeld genutzt. Es passt gut, wenn Wissen als semantische Aussagen modelliert wird: Subjekt, Beziehung, Objekt. Also etwa: ACME hat Vertrag V1.

Typische Fragemuster

Für den Einstieg ist es hilfreicher, erst Fragemuster zu verstehen als sofort Syntax zu lernen.

Nachbarschaft

Welche Dinge hängen direkt an dieser Entität?

Welche Systeme sind mit Vertrag X verbunden?

Gut für erste Orientierung, Impact-Analysen und Kontextpakete.

Pfad

Über welche Beziehungen sind zwei Dinge verbunden?

Wie hängt Lieferant A mit Produkt B und Risiko C zusammen?

Gut für Mehrsprung-Fragen, Begründungen und Auditpfade.

Filter

Welche Beziehungen zählen nur unter bestimmten Bedingungen?

Welche aktiven Verträge laufen in den nächsten 90 Tagen aus?

Gut, wenn Zeit, Status, Rolle oder Berechtigung die Antwort verändert.

Aggregation

Wie viele, wie stark, wie häufig oder wie zentral ist etwas?

Welche Systeme haben die meisten kritischen Abhängigkeiten?

Gut für Priorisierung, Monitoring und Management-Übersichten.

Kleine Beispielabfragen

Die Beispiele sind bewusst klein. Sie zeigen die Denkweise.

Cypher: Beziehungspfad in Neo4j

Cypher liest sich fast wie ein gezeichnetes Muster: Knoten stehen in Klammern, Beziehungen in eckigen Klammern. Diese Abfrage sucht Risiken, die über Verträge mit einem Kunden verbunden sind.

Cypher
MATCH (kunde:Kunde {name: "ACME"})-[:HAT_VERTRAG]->(vertrag)-[:HAT_RISIKO]->(risiko)
RETURN vertrag.titel, risiko.name, risiko.status

SPARQL: Muster in einem RDF-Graph

SPARQL wird oft bei RDF- und Ontologie-nahen Graphen genutzt. Die Abfrage beschreibt Subjekt-Prädikat-Objekt-Muster: Kunde hat Vertrag, Vertrag hat Risiko.

SPARQL
SELECT ?vertrag ?risiko
WHERE {
  :ACME :hatVertrag ?vertrag .
  ?vertrag :hatRisiko ?risiko .
}

Worauf du praktisch achten solltest

Graph Querying wird dann produktiv nützlich, wenn Abfragen funktionieren, begrenzt, erklärbar und wiederverwendbar sind.

  • Zu freie Abfragen für Agenten: Ein Agent sollte selten beliebige Cypher- oder SPARQL-Abfragen ausführen dürfen.
  • Unklare Kantenrichtung: Wenn nicht klar ist, ob Vertrag -> Kunde oder Kunde -> Vertrag modelliert wurde, werden Queries schwer lesbar.
  • Zu lange Pfade: Mehr Hops bedeuten nicht automatisch bessere Antworten. Lange Pfade erzeugen schnell Rauschen.
  • Keine Quellen: Eine Graphantwort ohne Quellen oder Herkunft ist für GraphRAG oft nicht belastbar.

Verwandte Konzepte

Knowledge GraphsMCP & A2A
Vorheriges ThemaTemporal KnowledgeDaten vorbereitenNächstes ThemaProvenance & TrustGraph nutzen