当向量RAG不足以处理时，可借助基于本体的上下文工程。

某项业务规则往往分散在代码和文档中。本体论能将这些零散部分转化为可用于上下文工程的导航路径。

那些庞大的遗留系统——数百万行的C和C++代码、PHP MVC框架、PL/SQL代码，以及数百份经过版本管理的非结构化文档——使得仅依赖向量检索的方法无法发挥作用，因为其语义具有关联性且受版本限制。基于本体论的上下文工程能够弥补这一缺陷：可将其与RAG和GraphRAG进行对比，了解RDF/OWL/SKOS/SHACL及相关标准，选择合适的技术组合，然后将其应用于真正的数百万行代码的系统中。

1. 问题所在：语义从未集中在一处

那些文档齐全的现代新建应用可能不会面临这种问题，但遗留系统却会。某个概念的含义被拆分开了：

• C/C++代码仅展示数值的计算方式，很少说明计算原因

PL/SQL包将关键规则隐藏在数千个过程之中

PHP Smarty模板负责编码用户与数据交互的方式

各种规范、版本说明及迁移指南会解释在多个版本中为何会出现相互矛盾的情况

许多知识仅存在于那些已经离职的人手中

试问当客户在月中更改合同时，发票会如何处理？答案并非存于某个单一文件中，而是分散在C模块、PL/SQL包、一张表格、2017年的规范文件以及2021年的修正说明中。没有哪一部分文本能完整包含答案，它实际上是以“路径”的形式存在于各类文档之中，在让大型语言模型处理这些信息之前必须先对其结构进行建模。

2. 什么是基于本体的上下文工程？

上下文工程负责为模型准备其可能看到的内容。基于本体的上下文工程会使用由类型与关系构成的明确图结构——包括模块、包、表格、文档、版本及已废弃项——在相似度搜索对其中的段落进行排序之前就选定相关对象。该图结构能够确定哪些对象和版本在考虑范围内，随后嵌入模型便会在该范围内挑选相应的表述。

那嵌入模型呢？

嵌入模型用于捕捉相似性，而本体则用于表达含义。向量存储能够识别出“外观相似”的段落。本体可以记录有类型约束的关联关系：哪个包使用了哪个表，哪个引擎调用了该包，哪版规范规定了相关规则，以及哪个版本标志着该包已过时。这些都是事实。这些技术按照固定顺序结合使用：事实决定模型可以关注什么；相似性则决定在该范围内哪个段落是答案。这种顺序就是设计的核心。

3. 当前技术格局：RAG、GraphRAG与本体

在决定使用本体之前，大多数团队会先尝试更简单的数据源。对于只需一步即可解答的问题，Vector RAG表现优异且部署成本更低。但当需要处理各种关系和版本含义时，它就力不从心了——比如哪个版本的规范优先于哪个版本、哪个包实现了哪条规则、哪份文档仍然有效。GraphRAG虽然能在数据块中加入图结构，但除非有明确的架构设计，否则仍可能无法充分体现版本策略和类型化关系。本体则将类型、谓词和约束视为核心要素，从而使查询能够根据版本和关系进行筛选，而无需依赖数据之间的接近度来推断。

Vector RAG并非“糟糕”的技术，只是当含义存储在链接和版本中时它显得不够完善。

4. 标准：RDF、OWL及其相关技术

语义网这个名称听起来很复杂，但其核心理念其实很容易理解。

• RDF：以主体 → 谓词 → 客体的三元组作为数据模型（如:BillingEngine :calls :PKG_INVOICE）。
• RDFS：轻量级模式——包括类、子类、域和范围——通常足以满足简单本体的需求。
• OWL：具备更丰富的描述逻辑结构，可用于推理（如不相交性、基数、传递性、等价性）。
• OWL 2 DL：可判定子集，适用于HermiT等推理工具；表达能力较强但学习曲线较陡。
• OWL 2 EL：适用于大型本体及可扩展推理的场景（如ELK），但会牺牲一定的表达能力。
• OWL 2 QL：专为处理大型关系数据查询而设计。
• SKOS：用于构建业务术语表中的词汇表、同义词及分类体系。

SHACL：用于根据约束条件验证RDF图结构的工具。

SPARQL：RDF的查询语言。

R2RML / OBDA：用于将关系模式映射为虚拟知识图谱的工具。

那么，哪种更好？

这个问题问错了。应从标准层角度考虑。一个实际的遗留系统组合应为：用RDF存储事实，用RDFS处理简单层次结构，用SKOS管理业务术语，用SHACL进行验证，用SPARQL执行查询，用R2RML暴露数据库功能，而仅在需要推理的场景（如影响分析、派生链接、废弃规则）中使用OWL。过度使用OWL会让项目变得脆弱，而分层式的实用主义才能让项目持续运行。

如何选择：决策标准

1. 需要自动推理功能？对于大多数事实，使用RDF/RDFS；仅将那些适合自动分类的特定场景留给OWL处理。
2. 在有多个贡献者的情况下需要质量保障？从一开始就采用SHACL并持续进行验证。
3. 真理存在于何处？关系型数据库（Oracle + PL/SQL）→ 作为虚拟知识图的R2RML/OBDA；文档 → 导入RDF（可选地搭配OWL）或属性图；无需进行虚拟化处理。
4. 需要业务术语表？传统的同义词集合非常适合用SKOS来管理。
5. 互操作性与查询效率之间如何权衡？长期使用的共享图谱更适合W3C标准体系；而那些需要图算法的内部工具，则可以添加从语义真实源同步而来的属性图投影。

标准所在之处

资源实际上是文本。OWL、SKOS、SHACL和R2RML可以以Turtle文件的形式存储在git中。ontology/目录结构用于定义系统中存在的内容——类、关系、层次结构以及元数据——通常仅使用基础OWL语法进行定义，并谨慎运用rdfs:range属性。需记住：范围本身并非约束条件。若将:writesTable指令应用于非表格类型，推理引擎可能会将其视为:DbTable而非拒绝该指令。实际的成员关系检查则由SHACL负责。配置文件的选择应由使用该系统的引擎决定，而非仅取决于文件本身。

5. 在大型传统代码库中的应用经验

该系统的代码量超过了200万行C/C++代码，还有庞大的PHP层、包含大量业务逻辑的PL/SQL代码

最初尝试的方法及为何不够用

对代码和文档进行分块处理后使用向量RAG技术，虽然能回答简单问题，但在处理涉及不同文档、对版本敏感的问题时就会失效——因为没有统一规则来混合使用SPEC v2和v3标准。缺乏类型化版本语义的朴素GraphRAG仍然会检索出相互矛盾的内容。而人工编写的提示词则无法实现规模化应用。这些方法的失败模式都是一样的：缺乏受控的关系和版本管理，仅有相似度判断。

本体论方法

模型模块、包、表、文档、版本、调用关系、写入操作、实现方式、替代关系、适用版本以及已废弃内容。从分析工具和词典中收集信息，通过SHACL进行验证，按版本存储带名称的图结构，在任何嵌入操作之前通过上下文服务根据用户所选版本进行过滤，从而提供SPARQL（及MCP工具）接口。

十二种类别：如何找到它们

这些类别是从各种工件中提取出来的，并非简单列举所有名词。典型的核心类别包括模块、函数、包、表、列、文档、章节、版本、批处理作业、API、用户界面屏幕以及业务术语（SKOS概念）。关系则从调用图、《ALL_DEPENDENCIES》/PL/Scope、PHP路由以及文档元数据中挖掘而来。领域专家会为这些术语指定同义词，随后由SKOS将其正式化。

该存储库构建了什么

本体仓库存储用于表示本体、形状、SKOS、查询及映射的Turtle格式数据。持续集成系统通过SHACL样例、推理一致性检查以及配置文件验证来确认拉取请求的合理性。数据收集器会将候选事实发送到暂存区；形状模块则会通过报告标记出违规项。事实存储库负责保存已被认可的事实以及关于数据隔离的人为决策——这是重建过程无法复制的唯一内容。三元组存储库则是由仓库、事实存储库及推理结果共同生成的构建输出。原始数据的权威性仍属于源系统，而表示形式与验证则由仓库负责。

通过R2RML实现的虚拟副本会按照Oracle模式（每个模式对应一个版本）进行关联，将数据写入与已收集事实同名的图结构中，这样上下文服务便能无需额外记录即可按版本进行合并。已退役的版本会保留已收集的事实，但不会对应活跃的虚拟副本。

图谱的初始化方式

在收集器启用之前，需先确定每个类别对应的标准——即每种提取器的规范。随后扫描 C/C++ 代码中的函数调用和表访问操作、PL/SQL 的 Oracle 字典、PHP 的路由机制以及文档存储库。记录文档的来源、生成日期及可检测的版本信息，并将其映射到本体术语中，通过 SKOS 合并重复项；可选地让大型语言模型为文档分类提出建议，再交由人工处理。同时加载 SHACL 规则。对于解析结果存在歧义的情况（如动态 SQL、函数指针），会为其标注置信度等级，降低其可信度。

图谱的更新方式

Deltas遵循软件治理流程：提出建议 → 在Turtle平台上创建PR → 自动进行SHACL/reasoner/profile检查 → 审核 → 合并 → 重新构建受影响的图结构。收集器会为每个版本重新运行相关流程；新事实会被放入暂存区；隔离分类则用于区分收集器错误、过于严格的形状/本体修复，以及应被排除的虚假事实。早期的基准版本需要多次迭代——通常在数周内进行十次左右的收集/修复循环——且仅使用大语言模型来对违规项进行分类，而不会用来接受任何事实。只有在模型提出内容供人工审核时，文档才会成为例外。

大语言模型的使用方式

在提问环节：实体关联 → 图遍历 → 上下文整合。通过SKOS标签/同义词将问题映射到对应实体；运行SPARQL查询，筛选条件为用户指定的版本相关图谱以及共享图谱（根据:appliesToRelease字段进行过滤）；随后将关联的事实及对应内容片段传递给大语言模型。向量搜索仍能定位到允许范围内的文档中的段落。图谱则负责确定哪些文档和代码资源会被纳入分析，从而避免不同版本混杂。

对于诸如“哪个规范适用于2022.2版本的比例计费”这类问题，两者的差异十分明显。Vectors返回了无效的SPEC_INV_V2和V3；而该系统选择了V3，因为它适用于2022.2版本，并且根据规则优先于v2，同时指定PKG_INVOICE作为实施方。这些答案都带有可追溯路径：模块→包→表格→文档→版本——开发者可以对其进行验证，而不像一堆类似的碎片信息那样难以追溯。

流程概览

1. 分析阶段。为每个工件系列确定标准；生成核心本体和决策表作为收集规则。
2. 收集阶段。进行静态分析、数据字典挖掘、PHP路由分析以及文档仓库检索——每条信息都会标注来源、日期，已知的话还会注明发布时间。

转换。将数据映射到本体术语，合并同义词，由人工验证大语言模型的输出结果，通过SHACL进行隔离处理，再通过OBDA加载或暴露数据。

版本控制。每次发布时重新运行数据收集工具；维护带名称的图结构；确保映射关系与实时模式保持一致。

服务提供。上下文服务用于解析实体、执行精心设计的查询、打包小型上下文，并以MCP工具的形式提供接口。

生成内容。大语言模型基于打包好的上下文生成答案；在选定的文档中可选择性添加向量信息。

第1至4阶段属于数据工程范畴（第1阶段为决策环节，第2至4阶段在每次发布时执行持续集成流程）。第5至6阶段则属于上下文工程范畴。本体则是连接这两者的契约。

成本与执行顺序

初期建模虽需时间，但远低于那些无法处理版本更新的无限循环的RAG调优工作。价值在于能持续更新图结构的流程，而非静态的Turtle文件。从某个子系统开始，在几周内证明其价值，再逐步扩展覆盖范围。

@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix owl:  <http://www.w3.org/2002/07/owl#> .
@prefix :     <https://example.com/legacy#> .

<https://example.com/legacy> a owl:Ontology ;
    owl:versionInfo "1.4.0" .

:CModule        a owl:Class ; rdfs:label "C module" .
:PlsqlPackage   a owl:Class ; rdfs:label "PL/SQL package" .
:BusinessRule   a owl:Class ; rdfs:label "Business rule" .
:DbTable        a owl:Class ; rdfs:label "Database table" .

:calls          a owl:ObjectProperty . # no range on purpose: a call crosses PHP, C and PL/SQL
:writesTable    a owl:ObjectProperty ; rdfs:range :DbTable .
:implementsRule a owl:ObjectProperty ; rdfs:range :BusinessRule .

@prefix owl:  <http://www.w3.org/2002/07/owl#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix :     <https://example.com/legacy#> .

# a module that calls a package implementing a rule reaches that rule
:reachesRule    a owl:ObjectProperty ;
                owl:propertyChainAxiom ( :calls :implementsRule ) .
:implementsRule rdfs:subPropertyOf     :reachesRule .

# a specification that supersedes a superseded one supersedes it as well
:supersedes     a owl:ObjectProperty , owl:TransitiveProperty .

@prefix :    <https://example.com/legacy#> .
@prefix g:   <https://example.com/legacy/graph/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

# structural facts, as collected from the sources of release 2022.2
g:R2022_2 {
    :BillingEngine a :CModule ;
        rdfs:label "Billing engine (C)" ;
        :calls :PKG_INVOICE ;
        :readsTable :T_CONTRACT .

    :PKG_INVOICE a :PlsqlPackage ;
        rdfs:label "PKG_INVOICE" ;
        :hasProcedure :CALC_PRORATA ;
        :writesTable :T_INVOICE ;
        :implementsRule :ProRataRule ;
        :describedBy :SPEC_INV_V3 .

    :CALC_PRORATA a :PlsqlProcedure ;
        rdfs:label "CALC_PRORATA" ;
        :implementsRule :ProRataRule .
}

# facts that span releases: documents, business rules, lifecycle
g:shared {
    :PKG_INVOICE
        :deprecatedInRelease :R2024_1 ;
        :replacedBy :PKG_INVOICE_V2 .

    :SPEC_INV_V3 a :SpecificationDocument ;
        :appliesToRelease :R2021_1, :R2022_2 ;
        :supersedes :SPEC_INV_V2 .

    :ProRataRule a :BusinessRule ;
        rdfs:label "Mid-month contract change is invoiced pro rata" .
}

6. 结论

• RAG并未消亡。当含义分散在代码、数据库、文档及不同版本中时，RAG就显得力不从心。
• 本体论具有实用性。RDF + RDFS + SKOS + SHACL可构成可行的技术框架；仅在分类规则需要较高复杂度时才使用OWL。
• 类型化图结构能为语义层工具提供所需支持。语言模型擅长处理文字表达，而本体论则负责筛选哪些事实、属于哪个版本，并提供可追溯的路径。

在拥有数百万行代码的遗留系统中，基于键值收集器与数据结构的检索设计是唯一能够应对实际约束的方案。

此方案仅涵盖了提取工程的基础部分——能够从C/C++、PL/SQL以及数十年的文档中获取可靠的数据，且不会引发运行混乱——这一领域值得进行更深入的研究。

经实际生产环境验证的实用技巧

在 collectors 和 R2RML（rr:graph）中，始终以发布版本为依据为图命名。绝不能让不受约束的 LLM 输出生成三元组。保持隔离结构的可读性：节点、形状、约束条件。必须频繁备份事实存储库。将推理器配置视为在持续集成中经过测试的部署选项。在本体中明确记录替代策略，以便能够查询“最新适用规范”，而非依赖内部惯例。通过针对特定发布版本设计的、能解决 RAG 之前无法处理的问题的黄金问题来衡量答案质量。

当利益相关者仅要求“嵌入向量”时，应同时展示混合版本的失败结果及对应的图路径。采用某项技术的前提是其可验证性。当工程师担心 OWL 的复杂性时，可展示包含可选 OWL 层级的架构结构。当运维人员担心新增数据库时，需让他们明白三元组存储库是可以重建的；而事实存储库和 git 本体才是最核心的部分。

基于本体的上下文工程并非关乎某种奇特的人工智能技术，而是要弄清意义的真正所在，并将这一真相编码下来，从而防止模型悄悄混用系统中不兼容的各个阶段。

关于收集器与置信度的深入说明

C和C++的静态分析能够生成调用关系及部分表访问点；而运行时生成的SQL语句以及通过函数指针进行的间接调用则仍不完整。为这些关系赋予置信度分数可以避免生成过度自信的图结构。通过Oracle字典提取PL/SQL代码虽然能更清晰地展现依赖关系，但在动态SQL占主导地位时仍需人工审核。PHP的路由机制会将用户可见的入口点与后端符号对应起来，从而使与界面相关的问题能够被纳入相应的代码包中处理。

那些仅嵌入PDF文件而不添加发布标签的文档收集工具会重蹈原有的错误。建议使用能在将各部分与包关联之前检测“适用于发布”范围的流程——该范围通过启发式方法提出并由人工确认。

将隔离作为产品功能

尽早对数据量进行隔离是一种信号，而非丑闻。收集工具的错误、复杂的结构以及错误的提取方式都需要不同的负责人来处理。将大语言模型的辅助功能用于对违规情况分类，可在不授予写入权限的情况下加快问题处理速度。一旦基准状态稳定下来，隔离的数据量应逐渐减少；而在新版本发布后数据量出现激增，则说明出现了新的语言结构或结构发生了变化。

为何命名图很重要

在没有命名图谱的情况下，2019年和2024年版本中的三元组会共存且没有标签，查询也无法进行精确限定。而有了命名图谱后，上下文服务会为用户当前使用的版本加上相应的图模式或FROM NAMED规则，同时还会使用共享的恒定事实。这一机制比提示警告更能有效避免SPEC v2/v3版本之间的混淆。

MCP与开发者体验

将经过筛选的SPARQL封装工具作为MCP工具提供，可以让编程代理直接询问“2022.2版本中有哪些功能调用了此包？”，而无需针对生产环境自行编写SQL语句。这些工具应设置为只读模式，并根据版本参数进行配置；当查询结果会影响生产环境变更时，还需记录工具的输入参数以便审计。

与BMAD及动态规范的关系

本体上下文能够补充那些确保人工智能生成的代码正确的流程框架：该图结构提供了这些流程可以引用的有依据、可版本控制的事实。动态规范会变成与实现包相连的节点，而非孤立的维基页面。

应避免的反模式

• 将整个本体嵌入提示词中而非进行查询。
• 因为“收集器是可信的”而跳过SHACL的使用。
• 从一开始就在所有地方使用OWL基数约束。
• 仅构建属性图，之后又因缺乏同步方案而需要OWL级别的语义支持。
• “以防万一”让向量搜索在所有版本上无过滤地运行。

避免这些做法，架构才能对需要验证路径的架构师和开发人员保持可解释性。

实际案例：月中合同变更

回到发票相关问题。在图中，计费引擎节点会连接到用于计算按比例费用的程序包；这些程序包负责生成发票表格；系统会选中那些标明:appliesToRelease用户发布版本并:describes相应程序包的文档；根据规则，过时的版本会被排除。上下文程序包可能包含PL/SQL过程名称、涉及的表列以及规范文档中的两段内容，而非五份相互矛盾的PDF文件。随后，大型语言模型会通过引用图表中的边并让开发人员能够点击这些引用，来解释相关行为。

如果没有该图表，检索系统会返回与“发票合同变更”最接近的PDF片段，往往是一些过时的说明。虽然模型给出的答案听起来很肯定，但具体路径却无法验证。

收集器设计模式

C/C++：在可行情况下解析用于调用的翻译单元以及SQL字符串字面量；记录文件和符号的来源信息；标记未解析的间接调用。PL/SQL：利用字典视图和PL/Scope来识别依赖关系；捕捉包/过程的详细层次结构。PHP：将路由和控制器映射到后端入口符号。文档：提取章节、标题以及可能的发布标签；绝不会自动提交推测性的链接。

在输出事实信息的同时，还需附带来源三元组：由谁在何时从哪个路径、源代码的哪个Git标签处收集了该信息。当触发隔离机制时，来源信息能帮助确定应打开哪个收集者的记录。

用文字描述的SHACL结构示例

这些规则可能要求每个:writesTable边都必须指向某个:DbTable，每份文档至少包含一个:appliesToRelease，且每个包都必须有非空的标签。一旦违反这些规则，系统会指出对应的焦点节点及约束条件。团队在了解语料库中的特殊现象后会不断优化这些规则——临时的放宽措施也会经过与本体类相同的PR审核流程，以确保历史记录可追溯。

灵活运用推理器而非固守教条

在PR上执行一致性检查，以便尽早发现不一致性问题。使用传递性calls的物化操作时需格外谨慎，过大的闭包可能会导致存储空间爆炸。对于某些遍历操作，建议采用查询时的属性路径。性能分析（EL与DL）应作为CI矩阵的组成部分：在ELK环境中有效的验证方法可能与HermiT的预期不同，因此需固定引擎版本。

属性图投影

如果社区检测之类的算法有助于对紧密关联的包进行聚类，那就定期生成带标签的属性图。以RDF作为真实数据源，将LPG视为衍生索引。需记录同步延迟情况，避免有人在过时的版本中排查本体错误。

人工审核队列

文档分类建议会以队列项的形式出现：推荐的包链接、版本范围、章节类型等。审核人员可以选择接受、修改或拒绝，相关决策会被存储到事实库中。根据接受率指标来判断是否需要改进提示规则或启发式方法。绝不能为“显而易见”的案例绕过审核队列——正是这类情况导致了隐蔽错误的出现。

服务层细节

上下文服务会验证用户身份，确定其使用的版本，执行实体关联操作（字符串匹配、SKOS altLabels，或仅基于标签的简单嵌入），从queries/中选择SPARQL模板，在相应的命名图上执行查询，构建一个有限数量的令牌包，并将其与路径元数据一起返回。通过对三元组和分段字符设置上限，可防止查询洪流。还会以（版本、实体集、查询模板）为键暂时缓存已构建的上下文，以应对重复的IDE查询。

MCP工具目录概要

示例包括：lookup_symbol、list_writers_of_table、governing_specs_for_package、impact_of_deprecating。每个工具都需指定所使用的版本。响应中会包含URI和人类可读的标签。智能体可以串联使用这些工具，但服务器仍会强制使用只读SPARQL查询。

叙述形式的对比表

向量RAG：成本低，但在版本管理方面表现较弱。GraphRAG-lite：结构更优，但容易出现配置不足的问题。完整的本体+SHACL+命名图：构建成本较高，路径可验证，上下文更安全。混合模式：本体过滤机制加上文档内的向量技术——通常是处理旧系统时的最佳选择。

管理时间表

每个版本发布流程：运行数据收集器，对数据进行分类隔离，合并本体相关的提交请求，重新构建三元组存储库，对关键问题进行测试，如果工具发生变更则发布MCP架构。为数据结构、收集器及文档队列分配负责人。没有时间表的话，该图谱就会像它所取代的维基一样逐渐失效。

安全与访问控制

某些包或文档属于机密内容。应在图中标注访问权限，或通过上下文服务根据用户角色进行过滤。对于无法读取源文件的用户，切勿将未加限制的子图放入提示信息中。

故障演练

在测试环境中删除三元组存储，然后从代码仓库和事实存储重新构建，以验证数据可恢复性。定期恢复事实存储的备份。模拟不良的收集器部署情况，确保隔离机制能在数据加载前将其拦截。这些演练能将架构设计转化为实际操作能力。

引入第二个子系统

复制决策表，仅在收集器需要时添加类，重复使用SHACL模式；如果标签存在冲突，则按领域分别维护SKOS概念方案。避免创建会拖慢每个代码提交速度的庞大本体，采用带有精简上层词汇表的模块化导入方式效果更好。

重要的指标

• 各版本中“黄金问题”的准确率
• 每个收集器的隔离率
• 上下文包大小的中位数
• 包含完整路径的答案占比
• 从版本标签发布到图表数据更新的时间
• 文档队列中人工审核的延迟时间

应关注这些指标而非单纯的三元组数量。一个庞大且不规范的图表比一个小而可靠的图表更糟糕。

扩展文章中间标准映射

SKOS ConceptSchemes按领域（计费、护理、资源配置）对业务术语进行分类。AltLabels记录了大家仍在使用的三种旧名称。当集成项目需要时，ExactMatch可在不同方案之间建立关联。如果机构使用双语，SHACL可要求用两种语言标注概念——欧洲的许多传统机构就是如此。

R2RML映射应像SQL视图一样进行审查：错误的rr:class会污染类型推断结果。请将映射文件与模式迁移文件放在一起，以便数据库管理员能够查看。当某个列被废弃时，对应的映射及本体论弃用公理也应一同纳入同一版本中。

queries/目录中的SPARQL查询库属于产品代码。需为版本和实体URI添加参数，并对相关代码进行审查。此外还应添加用于健康检查的ASK查询（即“该版本图是否存在？”），以便上下文服务在启动时使用。

为何技术顺序总被反复强调

各团队总是在嵌入模型之后试图“添加图结构”，却从不改变先检索再读取的顺序。如果向量仍然首先从所有版本中选择文档，那么图结构就只会起到装饰作用。应倒转处理流程：先按图结构筛选，然后再进行读取。请在架构说明文档中反复强调这一要点，直至其深入人心。

通往深度数据提取的过渡桥梁

C宏、生成代码及多字节编码的抽取工具值得拥有专门的说明书。经过OCR处理的PDF文件和扫描版的发布说明也是如此。上述本体映射假设这些抽取工具已经存在或将来会出现；没有它们，最完善的OWL文件也无法生成事实数据。需按比例投入资源：提升建模的清晰度、保证抽取工具的实用性以及设置验证机制。

通过实际运行症状完善问题描述

当信息分散时，所有支持工单的表现都类似：用户界面显示一种状态，批处理任务显示另一种状态，而仓库又显示第三种状态。工程师即便打开三个数据存储库，仍无法确定在特定工作日哪份信息才是权威的。通过对这些存储库进行向量搜索，虽然能找到因与工单词汇相同而看似相关的句子，但检索到的段落描述的都是已废弃的处理流程。本体论方法并不能神奇地统一这些数据存储库；它只是强制要求明确指定哪个类别负责哪些事实，以及哪個收集器有权声明这些事实。

这种分散式的含义也体现在入职培训过程中。新员工需要花费数周时间去学习仅存在于聊天记录中的“部落地图”。通过SHACL约束生成的图形化结构便成了一幅可导航的地图：从Contract开始，沿着hasParty找到Counterparty，再通过governedBy找到PolicyVersion，最终抵达执行该政策的代码模块。这条路径是可审计的，而相似度得分则无法做到这一点。

结合故障模式重新审视嵌入技术

嵌入模型能够压缩局部共现信息。当答案本身就是陈述事实的段落时，这类模型表现优异；但当答案需要跨系统关联信息——比如在部分迁移完成的情况下，确定哪份合同在哪个日期适用了哪个政策版本——时，它们就会失效。图结构中的边用于表示这些关联关系。在图形结构缩小候选节点范围后，嵌入模型仍可对它们进行排序或提供解释。正是由于将嵌入模型视为唯一的检索工具，许多RAG演示在基于常见问题集的数据上效果显著，却在传统平台上表现不佳。

维度大小与分块长度会加剧这种缺陷。过短的分块会增加热词的召回率，却降低多句式流程的召回率；而过长的分块则会因大量冗余内容而稀释向量表示。这两种设置都无法生成文本中根本不存在的外键。本体构建工具则是从解析器、配置映射表以及迁移表格中生成——或者更准确地说，是定义——这些键的。

不加宣传语的GraphRAG对比

GraphRAG风格的处理流程会从文本中提取实体与关系并将其构建成图结构，随后再检索子图用于提示生成。当数据源即为系统记录时，这种方法十分有效。在传统系统中，系统记录通常由代码、数据库以及操作手册组成。仅依靠文本提取无法发现配置中那些隐含的默认设置。基于本体的上下文构建则是从模式意图出发：首先定义十二个类别，然后再编写能够确定各谓词所在位置的提取工具。从散文文本中提取信息仅适用于处理非结构化知识，无法作为硬性约束的依据。

混合设计是可行的：在文档模块中使用GraphRAG，在事务处理核心中使用本体收集器，然后将两者合并为带有来源信息的命名图。服务层必须标注哪些三元组来自哪种方法，这样模型才能优先选择置信度高的收集器事实而非推测结果。

标准选择范围扩展

当需要全局标识符、SPARQL以及数据交换功能时，RDF更为适用；而当遍历用户体验和开发人员熟悉度更为重要时，属性图则更合适。OWL提供了用于约束和推断类型的词汇表；应选择推理引擎实际支持的配置文件。JSON-LD则是API之间的实用桥梁。SHACL无需完整的OWL推理即可验证实例数据。请选择最精简的方案，使其能够满足每周验证、为提示查询子图以及为审计人员导出数据的需求。

实际决策标准：

• 团队技能：谁能够编写SPARQL、Cypher以及自定义遍历代码？
• 互操作性：合作伙伴是否必须使用RDF数据导出格式？
• 验证频率：对于许多系统而言，每晚进行一次SHACL验证就已足够。
• 推理需求：封闭世界假设下的检查往往比开放世界OWL模型带来的意外情况更可靠。
• 工具支持：MCP服务器是否已能与您的存储系统对接？

标准存在的形式并非关键，重要的是在代码仓库中与相关工具一起对标准进行版本控制。本体文件与工具代码之间的差异会导致隐性故障。

十二个类别：需求调研工作坊脚本

与领域专家共同举办半天的研讨会，收集事故报告、发布检查清单以及监管问卷中出现的名词，然后将重复项归类。对于每一组剩余的类别，需明确：什么能唯一标识该实例、谁有权限创建它、哪些属性必须始终存在，以及哪些系统会修改它。12这个数字并非神奇，只是适合工作记忆容量的大小而已。如果发现有30个类别，则应将其划分到不同的上下文中，并以联合图的形式组织，而非将所有内容混为一谈。

需为每个类别记录以下信息：首选标签、备用标签、标识符规则、生命周期状态以及负责收集该类别数据的主体。如果没有明确的负责人，整个图结构就会变得混乱无序。

易于维护的存储库架构

将本体模块、数据收集包、验证任务、服务接口以及提示词模板分开处理。生成的三元组不应存入 git，而形状定义和固定数据则应保存在 git 中。当黄金固定数据上的 SHACL 规则出错时，CI 流水线应失败。即便三元组是临时的，也需以 semver 格式为本体版本打标签，因为提示词模板会固定谓词名称。

初始化详解

启动顺序为：加载 TBox（类与属性），加载从不来自数据收集器的参考实体（例如标准环境名称），对变化较慢的主数据运行数据收集器，接着对变化迅速的事务数据片段运行数据收集器，随后执行 SHACL 规则处理，最后发布带名称的图结构快照标识。在没有快照固定的情况下，大语言模型绝不会读取正在变化的 HEAD 数据；可重复性比表面上的新鲜度更重要。

更新详解

建议使用以水印为键的增量式收集器。在模式发生变化时，先迁移形状数据，再处理收集器，最后进行补充填充。对于无法通过形状验证的三元组应将其隔离而非悄悄删除。需输出相关指标：新增的三元组数量、被隔离的三元组数量以及按类别划分的形状违规情况。在部署后隔离率急剧上升时需通知相关人员。

LLM使用深度解析

检索方案：通过受限的命名实体识别功能，根据已知的IRI从用户文本中解析出实体；利用跳转限制和谓词允许列表来扩展查询范围；将结果序列化为紧凑的Turtle格式或Markdown表格，并附上数据来源及置信度信息；最后使用能够按需进行额外跳转的工具来调用模型。在建立审查机制之前，禁止在生产环境中使用自由形式的SPARQL查询，应提供参数化工具替代。

流程步骤详解

1. 接收事件或按计划触发处理。
2. 收集器负责获取数据并进行标准化处理。

映射器会输出带有来源信息的候选三元组。

SHACL负责验证；失败项会被放入隔离图中。

合并器使用幂等键更新快照。

索引器会更新服务用的投影数据。

评估器会在离线状态下运行测试用例。

MCP工具可为助手提供类型化的读取功能。

遥测系统用于闭环监控。

若跳过任何一步，重建的RAG演示系统都会十分脆弱。

成本排序的现实性

人工成本占主导地位。首先从对系统支持影响最大的三类任务入手，实现其收集流程的自动化。统计工单处理效率及错误答案率。只有当服务延迟和验证结果保持良好时，才扩大任务覆盖范围。用于嵌入计算的GPU成本通常低于工程师在没有词汇表的情况下为同义词问题争论数周所耗费的时间。

保障系统在生产环境中稳定运行的实用建议

在出现故障时，将快照编号嵌入提示语中。为每个模型输出的结果记录子图哈希值。为内部用户提供“为何是此上下文”的说明面板。将本体相关的变更请求视为API变更请求：需包含审阅者、兼容性说明以及已废弃谓词的停用时间表。

收集器与置信度评分

置信度并非主观感受，而应基于数据来源的优先级（主数据库 > 辅助缓存 > 维基）、数据的新鲜度以及解析的确定性来计算。需谨慎加权各评分项，不可因某个极低的致命信号而平均稀释整体置信度。应以结构化元数据的形式向模型呈现置信度，而非将其混入提示语中的形容词堆砌中。

隔离功能的用户体验

隔离功能本身也是一种产品。应展示待处理的三元组、出错的节点结构、建议的处理负责人，以及一键确认或修复的链接。若缺乏良好的用户体验，隔离功能就会变成杂物箱，进而导致信任度下降。

命名图作为契约

每个收集器都会向其命名的图结构写入数据。合并视图是一种带有明确策略的图之图结构。回滚意味着删除某个命名图结构的版本，而非在单一的三重存储转储中进行历史追溯。

MCP的人机工程学设计

工具应对应相应的类：getContract、listPoliciesForContract、getDeploymentAffecting。参数为IRI或可转换为IRI的业务键。响应结果仅包含已允许的谓词。超时设置和字节限制可用于保护上下文窗口。

动态规范

本体类应与ADR及动态规范保持一致。当规范更改某条规则时，其结构以及收集器测试也会在同一次拉取请求中同步更新。能够同时读取图结构和规范的辅助工具有助于减少“文档与代码”之间的矛盾。

常见反模式详解

• 使用一个包含大量自由属性的巨大类“Thing”。

仅用于合规性问题的嵌入式检索。

允许模型自行生成IRI。

直接丢弃无效三元组。

使用完整的本体数据集作为提示词。

跳过“黄金问题”评估。

在同一个图中混合不同环境而无需命名空间分隔。

实际应用案例说明

月中时，某份合同的付款条款发生了变化。合同管理工具会显示新版本的记录。相关数据结构需要包含effectiveFrom和approvedBy字段。该更新会被存入名为“contracts”的图中。有用户询问明天适用哪些条款。实体解析会找到对应的合同IRI，邻域查询会返回包含日期的两个版本，提示词仅包含适用版本及变更来源信息，最终答案则会引用审批编号。仅靠向量RAG可能只能检索到仍保存在维基中的旧PDF内容。

合同管理工具的模式

带有水印的JDBC数据提取、用于配置管理的Git树遍历工具、用于服务映射的OpenAPI遍历工具、运行时指标标签收集器，以及用于处理异常的人工CSV上传功能。每种模式都需要可重试的键值机制和死信处理机制。

用操作语言表达的SHACL

这些规则规定：每个契约必须从枚举值中恰好拥有一个当前状态；每个策略版本都必须指向一个字节哈希值；每次部署都必须关联到一个服务。违规情况会转化为可处理的工单，而非无用的日志信息。

推理引擎

在能够消除重复手动标记的情况下使用分类功能。避免那些会虚构新实体的复杂开放世界推理。如果OWL规则让操作人员感到困惑，建议优先使用SPARQL规则或SHACL-SPARQL来进行封闭世界环境下的管理。

属性图投影

如果开发人员习惯以路径思维工作，可每晚将 RDF 导出为属性图以便分析，同时仍以 RDF 作为数据交换与验证的来源。需记录哪些谓词会转化为边，哪些仍为属性。

人工审核队列

某些谓词始终需要人工处理：法律解释标签、异常标记以及重复实体的合并。应建立带有服务级别协议（SLA）的队列。只有当这些队列处理完毕或被明确放弃时，图结构才算完整。

服务层

按（iri、快照、跳数、允许列表哈希值）对邻域序列化结果进行缓存。为快速查询而压缩数据，删除未使用的前缀。同时提供详细的调试模式和简洁的生产环境模式。

工具目录概要

• resolve_entity(text, class_hint)
• get_neighborhood(iri, hops, predicates)
• diff_snapshots(id_a, id_b, class)
• list_quarantine(class, since)

explain_triple(subject, predicate, object)

每个工具都会返回包含来源信息的 JSON 数据。

各选项的对比分析

纯向量 RAG：演示速度快，但在数据关联方面表现较弱。文档型 GraphRAG：在以文本为主的领域中能更好地整合实体信息。本体收集工具：当现有记录系统结构化且需要跨领域理解含义时最为适用。大多数成熟的团队会采用多种方法组合，并明确各自的优先级。

管理时间表

每周对数据结构进行分类整理，每月审查词汇表，每季度举办类别研讨会，并为本体版本号发布更新说明。将这些日期记录在由指定负责人管理的日历上。

安全性

三元组存储库中保存着敏感的商业关系数据。需为每个图结构设置访问控制列表，在服务配置中对相关内容进行脱敏处理，绝不能将机密信息直接嵌入提示词中。同时要对工具调用进行审计。

故障演练

在测试环境中故意让收集器出故障。确认隔离数量是否增加、服务是否仍基于最新的正常快照运行，以及警报是否触发。进行恢复演练。如果演练都让人害怕，那么实际生产环境的情况会更糟。

第二个子系统的引入

复制收集器模板，注册一个新的命名图谱，添加图表元素，设定三个关键问题，在完全切换到辅助系统之前先进行一周的影子写入测试。不要一次性引入多个子系统。

真正具有指导意义的指标

关键问题集的错误率、获取数据的中位数跳数、隔离率、收集器延迟、回答时的快照年龄以及人工干预率。像重复计数这类表面指标会误导判断。

不靠口号的总结

基于本体的上下文工程是一种有章可循的上下文构建方式：包括类型化的实体、经过验证的事实、来源信息，以及能够获取足够相关信息的工具，从而得出有依据的答案。在这种框架下，嵌入技术依然具有实用价值，但它们无法替代对“哪个系统负责何种含义”的理解。