Startseite / Artikel / Ontologie-bewusstes GraphRAG: Wenn Vektoren typisierte Beziehungen benötigen

graphrag ontology rag knowledge-graph retrieval security

Ontologie-bewusstes GraphRAG: Wenn Vektoren typisierte Beziehungen benötigen

Wie Identifikatoranker, Ontologieverträge, Rangfusionsverfahren sowie Zitieren-oder-Ablehnen-Schwellenwerte RAG-Fehler bei CVEs, mehrstufiger Eigentumsverteilung sowie unausgesprochenen Graphenfakten beheben.

2819 Wörter

Dichte Informationsabrufverfahren beantworten viele Fragen gut, scheitern aber dennoch auf bestimmte Weise: bei exakten Identifikatoren, mehrstufigen Beziehungen sowie Fakten, die nur in Form einer Graphstruktur existieren. Ontologie-basiertes GraphRAG betrachtet diese Fehler als Designanforderungen – nicht als Grund, Vektoren aufzugeben, sondern als Anlass, neben ihnen eine typisierte Wissensschicht hinzuzufügen.

Teil 1 – Wie RAG genau funktioniert

Klassisches RAG embedt eine Frage, holt die nächstgelegenen Textabschnitte ab und generiert auf der Grundlage dieses Kontextes. Bei einer Anfrage nach Schwachstellen wie folgt:

question: "path traversal apache httpd"

Können sich Vektor- und lexikalische Ranglisten unterscheiden:

VECTOR (cosine)                       LEXICAL (keyword overlap)
1. CVE-2021-41773  0.746  ← correct   1. CVE-2021-28544  6.60
2. CVE-2021-23797  0.735              2. CVE-2021-40525  6.47
3. CVE-2021-32643  0.728              5. CVE-2021-41773  5.57  ← correct, buried

Wenn die richtige CVE vorhanden ist, aber nicht dominiert, erfindet die Generierung selbstbewusst Inhalte. Domänen mit vielen Identifikatoren (CVE, SKU, Ticket-IDs) zeigen diesen Mangel schnell auf.

Teil 2 – Die Grenzen, die es trifft, gemessen

Fehler 1 – exakte Identifikatoren

Eine lexikalische Übereinstimmung hilft zwar, doch störende „Nachbarn“ gewinnen dennoch. Die abgerufte Prosa kann sogar die Darstellung der Schwachstelle ablehnen:

[S1] "Rejected reason: This vulnerability does not meet the criteria for a
      security vulnerability…"

Dann spiegelt die Generierung den falschen „Nachbarn“ wider.

Fehler 2 – relationale Vollständigkeit

„Welche Produkte sind betroffen?“ erfordert Verbindungen, nicht nur den nächstgelegenen Absatz. Die Ähnlichkeitsanalyse liefert verwandte CVEs; sie folgt jedoch nicht den „AFFECTS“-Verknüpfungen.

Fehler 3 – Fakten, die niemand aufgeschrieben hat

Einige Antworten existieren nur als Schnittpunkte zwischen Entitäten – niemals als Satz. Kein Textabschnitt enthält diese Verbindungen; nur ein Graph tut dies.

Teil 3 – Was ein Wissensgraph hinzufügt

Getypte Knoten und Kanten machen Identifikatoren sowie Beziehungen zu erster Klasse:

(:Vulnerability {cve_id: 'CVE-2021-41773', cvss_base_score: 9.8, cvss_severity: 'CRITICAL'})
   -[:AFFECTS {version: '2.4.49'}]-> (:Product {key: 'apache:http_server'})
   -[:HAS_WEAKNESS]->                (:Weakness {cwe_id: 'CWE-22'})

Durchquerungen beantworten relationale Fragen; Vektoren helfen weiterhin, wenn Prosa die richtigen Beweise liefert.

Ontologie versus Wissensgraph – ein operationeller Unterschied

Eine Ontologie ist der Vertrag: welche Entitätsarten, welche Kantenarten sowie welche Eigenschaften erforderlich sind. Ein Wissensgraph ist die gemäß diesem Vertrag gefüllte Instanz. Ohne Ontologie führt die Extraktion zu Abweichungen und Verknüpfungen werden unzuverlässig. Mit einer Ontologie prüfen Pipelines schlechte Tripel und lehnen sie ab, bevor sie die Suche beeinträchtigen.

Drei Bedeutungen von „GraphRAG“

Graph als Index – Chunks werden gespeichert, aber über graphische Nachbarn abgerufen.
Graph als Speicher – Entitäten/Kanten bilden den Hauptspeicher; Text dient als Beleg.
Graph als Planer – Der Agent plant die Schritte und holt anschließend den Text ab.

Ontologie-basierte Designs kombinieren in der Regel (2) und (1): strukturierte Fakten für Präzision sowie Quelltexte für Zitierbarkeit.

Teil 4 – Die Architektur, Schicht für Schicht

Die Eingabeverarbeitung extrahiert Entitäten/Beziehungen aus der Ontologie, schreibt Graph-Fakten auf, speichert die Quelltextabschnitte und erstellt gleichzeitig einen Vektor-/Lexikalindex aus dem Text. Die Abfristelle verwendet Identifikatoren als Anker, erweitert die Nachbarschaften des Graphen, führt dichte/lexikalische Suchverfahren durch, fügt die Ranglisten zusammen und erstellt eine Anfrage mit getrennten Abschnitten für FAKTE und BEWEISE sowie Zitierregeln.

Drei Entscheidungen, die durch die Daten erzwungen wurden

Identifikator-Anker sind besser als ungenaue Abgleiche, wenn ein CVE-/Produkt-Token vorhanden ist.
Gewichtete Fusion muss die Ranglisten des Graphen bei Identifikatorabfragen erhöhen, ohne den Prosa-Teil bei narrativen Anfragen zu überlagern.
Prüfungen auf Treue müssen Antworten ablehnen, die fehlende Tags zitieren oder den Eigenschaften des Graphen widersprechen.

Teil 5 – Eine Frage, von Anfang bis Ende

Frage:

Q: "which products are affected by CVE-2021-41773"

Lösung der Anker:

ANCHOR  Vulnerability  CVE-2021-41773  method=identifier  conf=1.00

Fusion-Gewichte, wenn ein Identifikator als Anker dient:

weights = {graph: 2.0, vector: 1.0}     # identifier match
# a lexical product match would be 1.2; no anchor at all, 0.0

Konkurrierende Listen:

VECTOR  1. CVE-2021-21022 (Magento IDOR)   2. CVE-2021-27385  …
GRAPH   1. CVE-2021-41773 (anchor)         2. CVE-2021-25216 (shares netapp:cloud_backup)

Reciproke Rang-Fusion-Werte:

CVE-2021-41773   2.0/(60+1) = 0.03279   ← graph, rank 1
CVE-2021-21022   1.0/(60+1) = 0.01639   ← vector, rank 1

Für das Modell komprimierte Graphen-Informationen:

FACTS (from the knowledge graph):
[G1] CVE-2021-41773 | CRITICAL 9.8 (CVSS 3.1) | CWE: CWE-22
     affects: apache:http_server 2.4.49, fedoraproject:fedora 34,
              fedoraproject:fedora 35, netapp:cloud_backup,
              oracle:instantis_enterprisetrack 17.1 / 17.2 / 17.3
     source: https://nvd.nist.gov/vuln/detail/CVE-2021-41773

Quellenbelege:

EVIDENCE (source text):
[S1] "A flaw was found in a change made to path normalization in Apache
      HTTP Server 2.4.49. An attacker could use a path traversal attack…"

Gestrukturierte Antwort mit Quellenangaben:

{"answer": "CVE-2021-41773 is CRITICAL with a CVSS base score of 9.8 [G1].
            It affects apache:http_server 2.4.49, fedoraproject:fedora 34,
            fedoraproject:fedora 35 [G1].",
 "sources": ["G1"],
 "entities": [{"label": "Vulnerability", "key": "CVE-2021-41773"}],
 "confidence": "high"}

Post-Generierungs-Filter:

✓ every cited tag exists in the context
✓ the answer cites something at all
✓ every CVE id in the answer appears in the context
✓ entity labels are real ontology classes
✓ numbers that look like CVSS scores match the graph facts
→ ACCEPTED

Eine schlechte Antwort, die die Filter nicht besteht:

{"answer": "CVE-2021-41773 scores 4.3 and affects nginx [G1]."}

Gründe für die Ablehnung:

✗ states 4.3 but the graph facts say [9.8]
✗ entity Product nginx:nginx is not in the context
→ REJECTED → one repair attempt → still bad → REFUSAL

Dieselbe Mechanik, ein Schritt weiter

Die Verknüpfung von Beständen wandelt „betroffene Produkte“ in „betroffene Tier-1-Anwendungen sowie zuständige Teams“ um:

application        criticality  team            library  pinned    match_precision
checkout-web       tier1        payments        httpd    2.4.49    version-exact
log-aggregator     tier2        infrastructure  httpd    2.4.49    version-exact
api-gateway        tier1        platform-core   httpd    1.15.17   product-level

Dieselbe Anker- und Fusion-Mechanik; ein zusätzlicher Schritt über die Anwendungsverbindungen.

Teil 6 – Ergebnisse, Kosten und Fehler

Bei Identifikatoren und Mehrschritt-Suiten verbessert die ontologiebasierte Fusion die Genauigkeit im Vergleich zu Baselines, die nur Vektoren verwenden; bei reinen Prosafragen ist der Verbesserungseffekt geringer – daher sollten Vektoren beibehalten werden. Die Kosten entstehen durch die Extraktion, Graphenoperationen sowie etwas längere Anfragen – nicht dadurch, dass Embeddings weggelassen werden.

Die Fehler, denn sie bilden den eigentlichen Inhalt

Typische Produktionsfehler sind: Ontologiedrift (neuer Kantentyp taucht auf), Halluzinationen des Extraktors (falsche Schweregradangabe), Fehler bei der Kopier-Verschreib-Operation von Fusionsgewichten, Zitieretiketten, die im Kontext nicht vorhanden sind, sowie Caches, die nach einem CVE-Update veraltete Graphensnapshots liefern. Jeder Fehler lässt sich mit einem Test abdecken: Schema-Validierung, Prüfung der Eigenschaftsgrenzen, Fusionstests, Überprüfung auf Existenz von Zitierungen sowie TTL- und Invaliderungsprüfungen.

Teil 7 – Wann man dies entwickeln sollte und wann nicht

Verwenden Sie diese Methode, wenn der Datenstrom Identifikatoren, Fragen zur Mehrschrittseigentumsverteilung oder Auswirkungen sowie Fakten enthält, die niemals als Sätze formuliert sind. Vermeiden Sie sie, wenn das Korpus klein genug ist, um allein mit einer leistungsstarken hybriden Suche auszukommen, oder wenn niemand eine Ontologie warten wird. GraphRAG ist kein Zeichen für Komplexität; es handelt sich dabei um eine Reaktion auf messbare Fehlermuster.

Die fünf Invarianten, die in jeder Größenordnung beibehalten werden sollten

Ontologie zuerst – Typen vor Tripeln.
Anker für Identifikatoren – exakte Übereinstimmung vor Kosinus-Verfahren.
Trennen Sie Fakten und Beweise im Prompt.
Zitieren oder ablehnen – Prüfmechanismen nach der Generierung.
Messen Sie an eigenen Fragen – nicht nur an öffentlichen Erfolgsraten-Blogs.

Diese Invarianten bleiben von einer Laptop-Demo bis zu einem mehrfach genutzten Sicherheitswissensmodell nützlich. Eine Erweiterung des Anwendungsbereichs sollte bedeuten, dass Ontologien und Fixtures erweitert werden – nicht, dass weitere Anweisungen zu einem unstrukturierten Haufen von Datenblöcken hinzugefügt werden. Behalten Sie die Extraktionsmetriken (Präzision/Auflösung bei Entitäten und Kanten) neben den Antwortmetriken bei; andernfalls kann ein „besseres“ Modell heimlich Beziehungen erfinden, die flüssig erscheinen, bei Audits jedoch versagen. Versionieren Sie die Ontologie wie eine API: additive Änderungen sind einfach, Umbenennungen erfordern Migrationsaufgaben, und Löschungen benötigen „Grabsteine“, damit alte Snapshots nicht gelöschte Kanten wiederbeleben. Für den Notdienst sollten Warnungen bei Anstiegen der Gate-Ablehnungsraten sowie bei Fehlerraten des Extraktors ausgelöst werden – nicht nur bei Gateway-Latenz; diese Signale erkennen Fehler im Wissensmodell, bevor die Nutzer falsche CVE-Schwerigkeitsgrade bemerken. Schließlich sollten in den ersten Monaten eine Warteschlange für menschliche Überprüfungen bei umstrittenen CVEs und Produktzuordnungen eingerichtet werden; die Labels entwickeln sich sonst wieder zurück.

Tests, die die Fusionsgewichte im Laufe des Wachstums des Katalogs zuverlässig halten.

Beim Bewerten von Anbietern oder Frameworks fragen Sie nach, wie sie Ontologiebeschränkungen kodieren, wie sie Graph- und Vektorranglisten fusionieren sowie wie sie die Zuverlässigkeit von Zitaten überprüfen. Demos, die lediglich eine ansprechende Graphen-Oberfläche zeigen, ohne diese drei Antworten zu liefern, erzeugen in der Regel dasselbe RAG-Problem nur unter neuem Namen. Ziehen Sie langweilige, programmierte Pipelines mit expliziten Referenzen vor – anstelle von magischem „aggressivem Graphen-Reasoning“, das nicht zeigen kann, welche Kante eine bestimmte Schwerebewertung rechtfertigt. Genau dieser langweilige Ansatz macht GraphRAG, das Ontologien berücksichtigt, nutzbar.

Betrachten Sie die Fusionsgewichte als zu testende Konfiguration: Speichern Sie sie zusammen mit Fixtures, die eine Frage, die Kandidatenlisten sowie die erwartete Top-ID festlegen. Wenn jemand in einem Notebook die Gewichte „anpasst“, verlangen Sie einen Pull Request, der diese Fixtures aktualisiert, damit Regressionen nicht hinter „stammesbezogenem Wissen“ verborgen bleiben.

Betrachten Sie die Fusionsgewichte als zu testende Konfiguration: Speichern Sie sie neben den Fixtures, die eine Frage, die Kandidatenlisten sowie die erwartete Top-ID festlegen. Wenn jemand die Gewichte in einem Notebook „anpasst“, verlangen Sie einen Pull Request, der diese Fixtures aktualisiert, damit Regressionen nicht in kollektivem Wissen verborgen bleiben.

Betrachten Sie die Fusionsgewichte als zu testende Konfiguration: Speichern Sie sie neben den Fixtures, die eine Frage, die Kandidatenlisten sowie die erwartete Top-ID festlegen. Wenn jemand die Gewichte in einem Notebook anpasst, verlangen Sie einen Pull Request, der diese Fixtures aktualisiert, damit Regressionen nicht in „stammesweisem Wissen“ verborgen bleiben.

Alle Artikel Brief senden