首页 / 文章 / 具备本体认知的GraphRAG：当向量需要类型化关系时

graphrag ontology rag knowledge-graph retrieval security

具备本体认知的GraphRAG：当向量需要类型化关系时

标识符锚点、本体契约、排名融合以及引用或拒绝机制如何解决 CVE 相关的 RAG 故障、多跳所有权问题以及隐含的图结构事实问题。

2819 词

密集检索虽能很好地回答许多问题，但仍会在某些方面出现缺陷：精确的标识符、多跳关系以及仅以图结构存在的事实。具备本体认知能力的GraphRAG将这类缺陷视为设计上的考量——并非放弃向量技术的理由，而是需要在向量技术之外添加类型化知识层的依据。

第一部分 — RAG的具体工作原理

传统的RAG技术会将问题嵌入模型，获取最近的文本片段，并基于这些上下文进行生成。以关于漏洞的查询为例：

question: "path traversal apache httpd"

向量和词汇排名可能会出现不一致：

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

当正确的CVE存在但并非最突出的时候，生成结果往往会凭空编造内容。那些以标识符为主的领域（如CVE、SKU、工单编号）会很快暴露出这种缺陷。

第二部分 — 其面临的局限及衡量标准

缺陷1 — 精确的标识符

词汇匹配虽有帮助，但噪声较大的“邻居”仍会胜出。检索到的文本甚至可能否定这种脆弱性分析：

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

随后生成的内容会模仿错误的“邻居”。

失败案例2——关系完整性

“哪些产品受到影响？”这个问题需要的是关联边，而非最接近的某一段文字。相似度分析能找出相关的CVE，但无法追踪“受影响”关系链。

失败案例3——未被记录的事实

有些答案仅以实体间的交叉形式存在，从未以完整句子的形式出现。没有任何文本片段包含这些关联信息，只有图结构才能体现。

第三部分——知识图谱的贡献

带类型的节点和边使标识符与关系成为核心要素：

(: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'})

遍历操作可以回答关系类问题；当文本是合适证据时，向量技术依然有用。

本体与知识图谱——操作层面的区别

本体是一份规范，明确了需要哪些实体类型、边类型以及属性。而知识图谱则是依据该规范构建的实际实例。没有本体，数据抽取就会出现偏差，关联操作也会变得不可靠；有了本体，处理流程就能在不良三元组影响检索结果之前对其进行验证并剔除。

人们所说的“GraphRAG”包含三层含义

图作为索引——存储数据块，但通过图的邻接关系进行检索。
图作为内存——实体和边是主要存储内容，文本则是佐证。
图作为规划器——智能体先规划路径，再获取文本。

具备本体意识的设计通常会结合（2）和（1）：利用结构化事实确保精确性，同时保留源文本以便引用。

第四部分——逐层解析架构

该系统会提取本体中的实体/关系，写入图结构中的事实信息，保留原始文本片段，并为文本构建向量/词汇索引。查询时首先通过标识符定位，扩展图结构中的邻域节点，执行密集检索/词汇检索，融合不同检索结果的排名，最终生成包含独立事实和证据部分以及引用规则的提示内容。

数据迫使做出的三项决策

当存在CVE/产品标识符时，标识符定位方式优于模糊匹配。
对于基于标识符的查询，必须通过加权融合提升图结构中的排名，同时避免因叙事类查询而淹没正文内容。
真实性检查必须排除那些引用缺失标签或与图结构属性相矛盾的答案。

第五部分 —— 一个问题，端到端处理

问题：

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

定位解析结果：

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

当使用标识符作为锚点时的融合权重：

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

竞争列表：

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)

互反排名融合得分：

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

为模型打包的图结构信息：

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

来源证据：

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…"

包含引用信息的结构化答案：

{"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"}

生成后的过滤机制：

✓ 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

未能通过过滤机制的劣质答案：

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

拒绝理由：

✗ 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

相同的机制，多一步处理

库存关联功能将“受影响产品”转化为“受影响的顶级应用及对应团队”：

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

相同的锚点与融合机制；通过应用关联多进行一步处理。

第六部分 — 结果、成本与缺陷

在标识符与多跳查询场景中，具备本体认知能力的融合方法相比仅使用向量的基准方法能提升精度；而在纯文本问题中，提升效果较为有限——因此仍需使用向量。成本主要体现在数据提取、图操作以及稍长的提示词上，而非放弃嵌入表示本身。

缺陷问题，因为它们才是实际内容

常见的生产环境缺陷包括：本体漂移（出现新的边类型）、提取器产生的错误判断（严重程度错误）、融合权重复制粘贴错误、上下文中不存在的引用标签，以及 CVE 更新后仍使用过时图快照的缓存。每种缺陷都对应相应的测试：模式验证、属性范围检查、融合配置校验、引用存在性检测，以及有效期/失效处理。

第7部分 —— 何时应该构建此系统，何时不应

当查询内容包含标识符、多跳归属/影响分析问题，或是从未以句子形式呈现的事实时，应采用此方法进行翻译。若语料库规模小到仅需强大的混合搜索即可应对，或无人负责维护本体结构，则无需使用此方法。GraphRAG并非某种高级技术的象征，而是针对实际故障模式而设计的解决方案。

任何规模下都应保留的五个不变原则

先有本体结构——先定义类型，再构建三元组。
标识符的精确匹配机制——优先采用完全匹配，而非余弦相似度算法。
在提示词中区分事实与证据。
生成结果后设置引用或拒绝的审核环节。
以实际处理的问题作为评估标准，而非仅参考公开的胜率数据。

这些不变量在从笔记本电脑演示到多租户安全知识平台的各种场景中都依然有用。要扩大覆盖范围，应当扩展本体和固定结构，而非在无序的文本块堆上再添加额外的提示指令。除了答案质量指标外，还需关注提取指标（实体和边的精确度/召回率）；否则“更优”的模型可能会悄悄构建出看似合理但实际上会导致审核失败的关系。应像处理API一样对本体进行版本管理：新增内容易于实现，重命名则需要迁移操作，而删除内容则需设置标记，以防旧快照重新恢复被删除的边。在值班期间，应关注网关拒绝率上升以及提取器错误率，而不仅仅是网关延迟——这些信号能在用户察觉到CVE严重性标注错误之前就发现知识平台的问题。最后，在最初几个月内应为有争议的CVE和产品映射设置人工审核队列；这些标签最终会成为回溯分析的重要依据。

随着目录不断扩展，需要通过测试来确保融合权重保持准确。

在评估供应商或框架时，应询问他们如何编码本体约束、如何融合图结构与向量排名，以及如何测试引用的真实性。那些仅展示美观图形界面却无法给出上述三个答案的演示，往往只是用新名称重新出现了同样的RAG问题。相比那些无法说明某条边为何能支撑某种严重性判断的“智能图推理”技术，那些结构清晰、有明确依据的流程更为可靠。正是这种严谨的方式才使得具备本体意识的GraphRAG能够真正投入使用。

应将融合权重视为待测试的配置项：将其与固定问题、候选列表以及预期的顶级ID一同存储。当有人在笔记本中“调整”权重时，必须要求提交更新这些固定配置的拉取请求，这样才能避免因团队内部知识差异而导致的功能退化。

将融合权重视为待测试的配置：将其与固定问题、候选项列表以及预期最高ID的固定值一同存储。当有人在笔记本中“调整”权重时，必须要求提交更新这些固定值的拉取请求，以避免回归问题被隐匿在团队内部的知识中。

将融合权重视为待测试的配置：将其与固定问题内容、候选答案列表以及预期最高ID对应的固定值一起存储。当有人在笔记本中“调整”权重时，必须要求提交更新这些固定值的拉取请求，以避免回归问题被隐匿在团队内部的知识中。

将融合权重视为待测试的配置：将其与固定问题、候选项列表以及预期最高ID的固定值一起存储。当有人在笔记本中“调整”权重时，必须要求提交更新这些固定值的拉取请求，以避免回归问题被隐匿在团队内部的知识中。

将融合权重视为待测试的配置：将其与固定问题内容、候选答案列表以及预期的最佳ID对应的固定值一起存储。当有人在笔记本中“调整”权重时，必须要求提交更新这些固定值的拉取请求，这样才能避免回归问题被隐匿在团队内部的经验知识中。

全部文章发送简报