---
title: "本体资产是 RAG 知识库还是 skill？资产保全智能体的三种用法与一个判据"
date: "2026-10-05"
description: "接续《资产保全智能体的本体论与知识图谱怎么配套建》，回答被反复追问的架构问题：本体论形成的资产究竟该作为智能体的 RAG 知识库，还是 skill？本文的答案都不是——本体资产有三种用法，对应知识在生成链上的三个不同作用点：作为检索的骨架（OG-RAG 实证召回率 +55%、正确率 +40%）、作为校验的约束（SHACL 形状是唯一能承载监管硬约束的层）、作为能力的目录（Knowledge-as-Skill 指出传统知识库把文档暴露为匿名文本块、智能体根本不知道库里有什么）。给出一个三问判据判断每项知识该放哪一层，并把两个业务场景各自的三层配比算清楚：保全方案路径设计是生成型任务，骨架与目录占大头；核销转让审查是判断型任务，校验层占大头。"
tags: ["本体论", "知识图谱", "RAG", "OG-RAG", "Knowledge-as-Skill", "skill", "SHACL", "资产保全", "智能体", "金发2026-8号", "知识工程", "检索增强", "语义层", "银行AI治理", "技术风险", "押品管理", "不良资产处置"]
schema_type: "Article"
references:
  - title: "OG-RAG: Ontology-grounded retrieval-augmented generation for large language models"
    url: "https://aclanthology.org/2025.emnlp-main.1674/"
    source: "Proceedings of the 2025 Conference on Empirical Methods in Natural Language Processing (EMNLP 2025)，Sharma, Kumar, Li，pp. 32962–32981，ACL，CC BY 4.0"
  - title: "microsoft/ograg2 - OGRAG Release Version"
    url: "https://github.com/microsoft/ograg2"
    source: "GitHub 开源仓库（MIT License，149 star，Python，2025-04-25 创建，2026-03-12 最后推送）"
  - title: "Knowledge-as-Skill: A Structural Design for Autonomous Knowledge-Base Use by LLM Agents"
    url: "https://arxiv.org/abs/2609.25991"
    source: "arXiv preprint (Wu, Jiangxu，2026-09-22)"
  - title: "Ontology Learning and Knowledge Graph Construction: A Comparison of Approaches and Their Impact on RAG Performance"
    url: "https://arxiv.org/abs/2511.05991"
    source: "arXiv preprint (da Cruz, Tavares, Belo，2025-11-08)"
  - title: "指标算得对≠机器能推理：上下文图、本体与银行 AI 的真实缺口"
    url: "https://bi-chao.com/articles/semantic-layer-vs-context-graph-banking"
    source: "本站已发布文章（本系列前作，含金发〔2026〕8号第十一条与第二十二条原文引用、LLMs4OL 挑战赛实测对照、NeOn-GPT 形式化缺陷、重庆银行数智尽调平台案例）"
  - title: "本体构建方法论综述：Talisman 六阶段管线与 LLM 参与构建的实证，以及银行场景仍缺的三块"
    url: "https://bi-chao.com/articles/ontology-pipeline-llm-review"
    source: "本站已发布文章（本系列前作，657 三元组银行资产保全本体骨架自述与 ICEIS 2025 七条失效模式）"
  - title: "FIBO 没有资产保全本体：银行不良处置建模的复用边界、自建清单与治理陷阱"
    url: "https://bi-chao.com/articles/fibo-asset-preservation-ontology"
    source: "本站已发布文章（本系列前作，对 edmcouncil/fibo 全部 295 个本体逐词核查）"
  - title: "资产保全的智能化升级需要什么样的 FDE——当监管边界比模型能力更早决定自动化的上限"
    url: "https://bi-chao.com/articles/asset-preservation-fde-capability-challenges"
    source: "本站已发布文章（本系列前作，GB/T 45251-2025 催收频次红线与金发〔2026〕8号高风险应用准入）"
  - title: "资产保全智能体的本体论与知识图谱怎么配套建：两个真实业务场景的路径设计、自动化管线与快速落地清单"
    url: "https://bi-chao.com/articles/asset-preservation-agent-ontology-knowledge-graph"
    source: "本站已发布文章（本文的直接前作，九阶段转让流程与十九条核销标准的完整拆解、pySHACL 工具链核实、十二个能力问题与三条 SHACL 形状示例）"
# Note: this file does not embed the AIGC implicit label block (ProduceID / ReservedCode).
# Under current labeling rules, AIGC metadata (Label, ContentProducer, ProduceID, PropagateID,
# ReservedCode1, ReservedCode2) must be issued per-article by the labeling platform.
# ProduceID and ReservedCode cannot be inferred or fabricated by the author or the generating tool.
# Leave these fields empty here; complete them after the platform issues the identifiers.
---

**先纠正问题的提法：这不是二选一。本体资产有三种用法，对应知识在生成链上的三个不同作用点——检索的骨架、校验的约束、能力的目录。混淆它们是本体项目最常见的失败原因。**

**一种用法已被实证有效：OG-RAG（EMNLP 2025，微软已开源）把本体作为检索的锚，召回率 +55%、响应正确率 +40%、归因速度 +30%、事实推理准确率 +27%。注意本体不是被检索的文本块，它是给检索提供结构的东西。**

**另一种用法最被低估，也唯一能承载监管硬约束：SHACL 形状在生成之后做断言，而不是被模型读进去再"理解"。催收每日 3 次上限、20% 检查覆盖面这类红线，只能放这一层——放进 prompt 的知识模型可以忽略，写进校验层的知识不可绕过。**

**第三种用法回答"智能体凭什么知道库里有货"：Knowledge-as-Skill 指出传统知识库把文档暴露为匿名文本块、缺范围用途溯源与关系，智能体不知道能检索什么。本体天然自描述，它不是 skill 的内容，是 skill 的目录。**

**本文给一个三问判据：这项知识需要被模型理解并转述吗（放检索层）、需要在输出后被强制执行吗（放校验层）、需要让模型知道自己能用吗（放目录层）。两个场景的配比不同：保全方案路径设计是生成型任务，骨架与目录占大头；核销转让审查是判断型任务，校验层占大头。**

**一条诚实的边界：三层不是本体的专利。前作核实的重庆银行数智尽调平台，约束逻辑由规则引擎而非本体承担，平均自动化完成率 60%——校验层未必需要本体，但校验层必须存在。**

---

> 素材说明：本文事实来源为 4 份外部文献与本站 5 篇系列前作，性质与边界如下。
>
> 1. OG-RAG（来源1，EMNLP 2025）：Sharma、Kumar、Li 三位作者发表于 2025 年自然语言处理经验方法会议（苏州），ACL Anthology 编号 2025.emnlp-main.1674，页码 32962–32981，CC BY 4.0。本文引用其摘要自述的四个提升数字（准确事实召回率 +55%、响应正确率 +40%、归因速度 +30%、事实推理准确率 +27%，跨四个不同 LLM）与其机制（把领域文档建成超图表示，每条超边封装一组由领域本体锚定的事实知识，用优化算法为给定查询检索最小超边集合）。这些数字是论文自述的基准对比，非第三方复现。
> 2. microsoft/ograg2（来源2）：OG-RAG 的官方代码仓库，本文经 GitHub API 核实为 MIT License、149 star、Python 语言、2025-04-25 创建、2026-03-12 最后推送。核实时间与本文撰写日相同。仓库自述为 Release Version。
> 3. Knowledge-as-Skill（来源3，arXiv 2609.25991）：作者 Wu Jiangxu，2026-09-22。本文引用其核心诊断（传统检索增强生成的检索-拼接-生成管线代替模型做检索决策；新的瓶颈是智能体可能不知道知识库里有什么；传统知识库把文档暴露为匿名文本块，缺少关于范围、用途、溯源或关系的信息）、其三层设计（发现层、导航层、知识层，知识层文档带 YAML 前置元数据记录主题类型溯源与生命周期，遵循 Open Knowledge Format 与 Skill 协议且不修改智能体框架）、以及在 WixQA 企业客服基准上的初步评测（本文方法 0.889 Factuality 与 0.816 Context Recall，对比已报告的 Corpus2Skill 数值 0.767 与 0.708；Faithfulness 与 Context Precision 略低、交互轮数更多）。作者自述这些结果是与另一工作不同的模型提示与知识包构建下的方向性跨工作证据，不是受控比较。
> 4. 本体学习与知识图谱构建对照研究（来源4，arXiv 2511.05991）：da Cruz、Tavares、Belo，2025-11-08。本文引用其结论（本体引导的知识图谱在纳入文本块信息后达到与先进框架有竞争力的表现，显著优于向量检索基线；由关系数据库构建的本体引导图与由文本提取的本体引导图表现相当，但前者只需一次性本体学习过程、大幅降低 LLM 使用成本，并避免文本方法固有的本体合并复杂性）。该文用词是 competitive（有竞争力）而非 outperform（超越）。
> 5. 本站前作《指标算得对≠机器能推理》（来源5）：本文引用其已核实的五项事实。其一，金发〔2026〕8号第十一条「推进知识工程建设」原文（支持金融机构构建企业级知识管理体系，坚持服务业务的价值导向，构建核心知识模型，建立知识萃取、整合、共享机制流程，建立从知识创建、审核、发布、更新到归档的全流程管理规范，鼓励利用人工智能技术提升知识萃取、表示、融合和对齐能力）。其二，该文件第二十二条要求涉及客户权益或有实质性财务影响的关键决策须设人工复核节点，完整保留原始数据、推理路径及阈值触发记录。其三，LLMs4OL 2024 挑战赛实测（分类发现 DBO 子任务传统 ML 队伍 F1 0.2109 对 LLM 加检索队伍 0.0164；术语类型化微调后 0.9716；Schema.org 子任务 0.6157）。其四，NeOn-GPT 的形式化缺陷（LLM 生成本体的类表达式普遍限于包含关系类型、缺乏合取与析取，属性限制主要限于 HasValue、缺失基数限制与存在量词和全称量词限制）。其五，重庆银行数智尽调平台案例（规划工期 12 个月四个阶段，试点 8 家分支机构，累计处理任务近 300 条，产出上百份尽调报告，平均自动化完成率 60%，采用开源大模型加图数据库，约束逻辑由规则引擎而非本体承担）。
> 6. 本站前作《本体构建方法论综述》（来源6）：本文引用其自述的 657 三元组银行资产保全本体骨架（AnnotationVocabulary、CollateralScheme 含四个正交分面 29 个 SKOS 概念、Lifecycle 含 6 个逾期阶段 8 项保全措施顺位 1–6 与 7 类角色、Mapping 含 33 条到 FIBO 的显式有损映射）、Talisman 六阶段管线、以及 ICEIS 2025 论文记录的 LLM 参与构建失效模式（ChatGPT 初始回复包含不存在的本体；无状态导致另开会话时已修正错误回退）。
> 7. 本站前作《FIBO 没有资产保全本体》（来源7）：本文引用其对 edmcouncil/fibo 全部 295 个本体的核查结论（可复用边界限于 FND/FBC 基础层与 Collateral 及其子类；不良处置领域核心词 workout、repossess、charge-off、perfection、security interest 零命中；FIBO 唯一的违约类 LoanDefaultProceeding 的定义字段面值为无定义、所在文件成熟度为 Provisional）。
> 8. 本站前作《资产保全的智能化升级需要什么样的 FDE》（来源8）：本文引用其两条监管红线（GB/T 45251-2025 第 5.3.1.8 条告知式语音催收含智能语音对单一债务人每日合计不超过 3 次；金发〔2026〕8号要求人工智能高风险应用须经风险管理委员会批准）。
> 9. 本文直接前作《资产保全智能体的本体论与知识图谱怎么配套建》（来源9）：本文引用其已完成的场景拆解与工具核实（转让场景九阶段流水线与卖方尽调样本金额不低于批次 80%；核销场景 19 条认定标准与账销案存；pyshacl 0.40.1 Apache-2.0、rdflib 7.6.0、owlrl 7.6.2 的 PyPI 官方版本核实；十二条能力问题；三条 SHACL 形状示例）。本文是其架构追问的延续，不重复其场景拆解细节。
> 10. 本文未获取 MNEME（Zenodo 23001062）的正文（访问返回 403），故不引用其任何内容。arXiv 2609.25991 的 Skill 协议与 Open Knowledge Format 本文仅按摘要描述引用，未核实其规范文档原文。

## 一、先把问题的提法改掉

「本体资产是 RAG 知识库还是 skill？」这个问法预设了二选一，而二选一本身就是陷阱。

看一下这两种载体在生成链上的位置就明白为什么不能二选一：

- **RAG 知识库**的知识作用在**生成之前**：检索一段文本，拼进上下文，模型读完再输出。知识在这里是**建议性**的——模型可能采纳，也可能忽略，甚至可能与之矛盾地输出。
- **skill** 的知识作用在**生成之外**：模型决定调用某个工具，工具用确定性代码执行，把结果交回。知识在这里是**被封装**的——模型不接触知识本身，只接触执行结果。
- **本体**如果用对，知识作用在**生成之后**：SHACL 形状对输出做断言，违反约束就失败。知识在这里是**强制性**的。

三种作用点，三种强制性等级。**一个本体资产可以同时出现在三个作用点上，但它的每一部分只该待在一个地方。** 把 19 条核销认定标准塞进 RAG 让模型"理解"，与把它们写成 SHACL 让机器校验，结果是两个东西——前者是建议，后者是约束。监管红线不能是建议。

所以正确的问题不是「是 A 还是 B」，而是**「本体的这一部分，该放在哪个作用点」**。本文给一个判据，放在第五节。

## 二、第一种用法：作为检索的骨架

这是被实证最充分的一种，也是回答"本体能不能改善 RAG"这个问题最直接的证据。

**OG-RAG 的机制。** 来源1 的做法不是把本体检索出来，而是**用本体给文档建索引**。它把领域文档表示成一张超图，每条超边封装一组由领域本体锚定的事实知识；给定一个查询，用一个优化算法检索**最小**的超边集合。关键词是"最小"——不是召回越多越好，而是用最少的超边覆盖查询所需的事实。

**四个自报数字。** 论文摘要称：准确事实召回率提升 55%，响应正确率提升 40%（跨四个不同 LLM），响应到上下文的归因速度提升 30%，基于事实的推理准确率提升 27%。代码已开源为 microsoft/ograg2（来源2，MIT License）。

**但数字不是本文想引用的重点，机制才是。** 传统 RAG 的检索单位是文本块，而文本块自己不会说明自己是什么。来源3 把这个问题说得很清楚：传统知识库把文档暴露为**匿名文本块**，缺少关于范围、用途、溯源或关系的信息。一个资产保全的合同片段被向量化之后，它只是一串数字——检索器知道它与查询相似，但不知道它是借款合同还是担保合同，不知道它对应哪个阶段，不知道它能否被对外披露。

**本体补上的正是这四样：范围、用途、溯源、关系。** 这四样不是文本内容，是文本的元结构。把它们放进检索路径，检索就从"相似度匹配"变成"结构定位"。这正是来源4 的独立结论：本体引导的知识图谱在纳入文本块信息后，显著优于向量检索基线；而且由关系数据库构建的本体只需一次性学习、大幅降低 LLM 使用成本。

**在资产保全场景的具体形态。** 本文的前作（来源9）交付的 657 三元组骨架里，CollateralScheme 是押品分面码表（四个正交分面 29 个 SKOS 概念），Lifecycle 是案件生命周期（6 个逾期阶段、8 项保全措施、顺位 1–6、7 类角色）。这两样东西**本身就是检索骨架**：查一个案件时，检索器不是在向量空间里捞相似文本，而是先定位到案件的逾期阶段与顺位，再按阶段与顺位取回该阶段允许的保全措施与所需材料。

**一句话概括这一层：本体不是 RAG 的内容，本体是 RAG 的骨架。** 把本体当内容检索（把三元组转成文本喂给模型）是用错了；把本体当骨架索引（用它组织检索路径）才是这一层。

## 三、第二种用法：作为校验的约束

这一层最被低估，而且是唯一能承载监管硬约束的一层。

**为什么只有这一层能承载。** 想一下催收频次红线。GB/T 45251-2025 第 5.3.1.8 条规定告知式语音催收（含智能语音）对单一债务人每日合计不超过 3 次（来源8）。这条知识有三种放法：

- 放进 RAG：模型每次生成催收建议前去检索这条，然后"记住"它。**可以忽略，且每次生成都可能忽略。**
- 放进 skill：把计数逻辑写成工具，模型调用时工具返回"今日已达上限"。**模型可以选择不调用这个工具。**
- 放进校验层：在催收任务出队前跑一次断言，超限直接拒绝出队。**不可绕过。**

第三种是唯一合规的放法。前两种在监管看来都不算控制措施，算提示。

**SHACL 是这一层的标准工具。** 前作（来源9）已核实 pyshacl 0.40.1（Apache License 2.0）、rdflib 7.6.0、owlrl 7.6.2 三个包的版本与许可，并给出三条可直接动手的形状示例：一个资产包必须有且仅有一份生效转让协议且不得存在回购协议（对抽屉协议禁令的机器化）；一个核销案件必须挂载至少一条认定标准且每项必需证据都有来源指针；每个抽取字段必须带文书与页码位置指针。这三条一旦写成形状，pyshacl 就能在 CI 与运行时各跑一遍，校验报告本身就是审计材料。

**这一层与金发〔2026〕8号的对应关系。** 来源5 已核实的第十一条要求"构建核心知识模型、建立知识萃取、整合、共享机制流程"，第二十二条要求关键决策"完整保留原始数据、推理路径及阈值触发记录"。**"阈值触发记录"这五个字，在技术上说的是一个校验层的输出。** 一段 RAG 检索不产生阈值触发记录；一个 SHACL 校验报告天然就是。监管没有要求银行建本体，但监管要求的结果（可追溯、可审计、阈值有记录）恰好是这一层能提供的。

**但必须说一条对本体不利的事实。** 前作核实的重庆银行数智尽调平台（规划工期 12 个月四个阶段，试点 8 家分支机构，累计处理任务近 300 条，平均自动化完成率 60%），**它的约束逻辑由规则引擎而非本体承担**。这说明校验层未必需要本体——规则引擎、决策表、硬编码的守卫函数都能做到。**本体在这一层的价值不是"能做约束"，而是"约束可被业务方读懂并维护"**：一条 SHACL 形状是声明式的，业务专家能审；一段规则引擎代码是过程式的，业务专家审不了。为可维护性付本体的成本，是这个决策的真实权衡。

## 四、第三种用法：作为能力的目录

这一层回答一个常被忽略的问题：**智能体凭什么知道库里有货？**

**问题的严重性。** 来源3（Knowledge-as-Skill）的诊断是：当工具调用与智能体循环变得更可靠，智能体可以自己决定是否检索、检索什么、何时停止——**这时暴露出的新瓶颈是，智能体可能不知道知识库里有什么**。传统知识库把文档暴露为匿名文本块，缺少关于范围、用途、溯源或关系的信息。结果是智能体要么过度检索（什么都去捞一遍），要么漏检索（不知道有这个东西）。

**这个诊断在资产保全场景是字面成立的。** 一个保全智能体面对一个新案件，它需要知道：本行的知识库里有没有这份合同的担保信息？有没有这个债务人的关联人线索？当前的保全措施清单有哪八项？顺位规则是什么？**如果这些问题的答案不能被智能体"发现"，它就不会去用，知识库就退化成摆设。**

**本体的类与属性天然是自描述的。** 一个类有标签、有定义、有适用范围；一个属性有定义域与值域。这些恰好是"能力清单"需要的字段。所以本体作为 skill 的正确形态是：**把本体的类与属性暴露成智能体可发现、可导航的能力目录，而不是把本体本身当 skill 执行。**

**来源3 的三层结构值得照抄。** 发现层（智能体首先访问的入口，回答"这里有什么"）、导航层（每个目录一个入口，回答"这一类下有什么"）、知识层（具体文档，带主题、类型、溯源、生命周期四类前置元数据）。作者强调这个设计遵循 Open Knowledge Format 与 Skill 协议，且**不修改智能体框架**——它是一个组织方案，不是一套新中间件。

**一个可量化的参照。** 来源3 在 WixQA 企业客服基准上的初步评测为其方法给出 0.889 Factuality 与 0.816 Context Recall，对比已报告的 Corpus2Skill 数值 0.767 与 0.708。**必须连同作者自己的限定一起引用**：由于模型、提示与知识包构建都不同，这些结果是方向性的跨工作证据，不是受控比较；而且该方法在 Faithfulness 与 Context Precision 上略低、交互轮数更多。**这不是一个"新方法更好"的结论，是一个"组织方式改变检索行为"的证据。**

## 五、一个判据，与两个场景的配比

### 三问判据

判断某一项知识该放在哪一层，问三个问题：

- **它需要被模型理解并转述吗？** 如果需要，放检索层。例如"什么情况下算强制执行超过一年仍无法收回"这种需要语义判断的条文。
- **它需要在输出后被强制执行吗？** 如果需要，放校验层。例如催收频次上限、材料必备项、抽屉协议禁令。
- **它需要让模型知道自己能用吗？** 如果需要，放目录层。例如本行有哪八项保全措施、顺位规则适用哪类案件。

**三个问题可以同时为真，那就是三项知识、三个存放点。** 一条法规的语义解释放检索层，同一条法规的硬约束放校验层，它的适用范围说明放目录层。这不是重复建设，是同一知识的三个投影。

### 两个业务场景的三层配比

| 层 | 保全方案路径设计（生成型） | 核销转让项目审查（判断型） |
|---|---|---|
| 检索层 | **占大头**。模型需要理解案情、历史处置先例、各类措施适用条件，才能生成路径 | 占小头。主要用于补齐材料缺口提示 |
| 校验层 | 占小头。主要拦时序错误（诉讼时效、过渡期）与必备材料 | **占大头**。19 条认定标准、材料完备性、五类禁转资产、抽屉协议禁令全是硬约束 |
| 目录层 | **占大头**。智能体必须知道有哪八项措施、顺位 1–6 的规则、各阶段允许什么 | 占小头。审查动作本身是固定的，不需要"发现" |

**这个配比差异解释了一个常见现象：** 同一套智能体框架，做路径设计时效果不错，做合规审查时屡屡出事——因为审查场景的知识该放在校验层，而框架把它放在了检索层，模型于是"理解"了 19 条标准然后在该拦住的地方没拦住。**这不是模型不够强，是知识放错了作用点。**

**本文前作（来源9）的三条 SHACL 形状示例，正好分别落在两个场景的校验层上**：转让场景的"唯一生效转让协议且无回购协议"、核销场景的"至少一条认定标准且证据带来源指针"、共享层的"字段必带文书与页码指针"。这三条不解决生成问题，只解决合规问题——这就是校验层的职责边界。

## 六、三个不能搞错的边界

**其一，本体不能由模型自发生成。** 这一条直接决定三层架构能否成立：如果本体本身不可靠，建在其上的检索骨架、校验约束与能力目录全都不可靠。前作（来源5）核实的两组数据说明了原因。LLMs4OL 2024 挑战赛上，同一个分类发现子任务，传统 ML 队伍 F1 0.2109，LLM 加检索队伍只有 0.0164——差 13 倍。NeOn-GPT 记录了更根本的原因：LLM 生成的本体类表达式普遍只有父子层级、缺乏合取与析取，属性限制主要限于 HasValue、缺失基数与量词限制。**缺这些东西，OWL 的推理能力基本失效**——而推理能力正是第一层那"免费的五条推论"所依赖的。所以三层的本体资产必须人工主导建设，LLM 只做候选生成与格式转换。

**其二，三层不是本体的专利，但三层必须都存在。** 重庆银行的案例（规则引擎承担约束、自动化完成率 60%）证明校验层可以不要本体。但一个只做检索不做校验的智能体，在监管语境下不叫控制系统，叫辅助工具。**底线是三层必须有，不是三层必须是本体。** 选型标准是可维护性：业务专家能否审阅、能否版本化、能否在制度变更后单点更新。

**其三，别把本体塞进 prompt。** 这是最常见也最隐蔽的错误。把 657 个三元组转成文本拼进上下文，模型既读不完也用不对——它会在推理时重做本体工程，而这恰好是它最不擅长的事（见第一条的 13 倍差距）。**本体对模型的价值，全部通过"结构化的检索路径""不可绕过的校验断言""可发现的能力目录"这三个间接通道实现，从不通过"让模型读本体原文"实现。**

## 七、行动清单

**保全业务条线**

- 用第五节的三问判据，把本部门掌握的业务规则逐条标注归属层。这条标注本身就是一份知识治理台账，且不依赖任何技术工具。
- 先标注监管硬约束（催收频次、材料必备项、五类禁转、抽屉协议禁令），确认它们全部落在校验层而非检索层。这是最容易出错也最致命的一类。
- 对路径设计场景，确认智能体能看到完整的能力目录（八项保全措施、顺位规则、各阶段允许动作），而不是靠模型自己猜本行有什么。

**数据治理条线**

- 按 Knowledge-as-Skill 的三层结构组织知识库：发现层入口回答"这里有什么"，每个目录一个导航入口，每份文档带主题、类型、溯源、生命周期四类元数据。
- 给检索层的内容补上本体提供的四样东西：范围、用途、溯源、关系。这一步不需要推理机，只需要在索引时挂上类与属性标签。
- 校验层的规则必须有版本与生效时间。前作（来源9）记录的工程方法直接适用：业务制度更新后新任务用新版本，历史任务仍能还原当时使用的规则。

**信息科技条线**

- 用 microsoft/ograg2（MIT）作为检索层改造的参照实现，但先在内部做小规模复现验证其 +55% 召回率的可迁移性，不直接照搬论文数字做预算。
- 校验层的技术选型按可维护性决策：业务专家能否审阅。SHACL 形状可审，规则引擎代码不可审——这个差异是本体在校验层的真实价值。
- 目录层不要新造中间件。来源3 明确其设计不修改智能体框架，它是一个组织方案与前置元数据规范，先按现有框架实现。
- 任何一层都不要让 LLM 独立生成本体资产。候选生成可以，建模判断不行。

## 八、FAQ

**Q1：那本体资产到底是不是知识库？**

A1：是知识库的一部分，但不是被检索的那一部分。被检索的是文档与事实，本体是这些文档与事实的索引结构、校验依据与能力目录。把本体当检索内容是把索引当成书来读——OG-RAG 的机制恰恰相反，它用本体建超图索引、检索最小的超边集合，本体本身从不进入上下文。

**Q2：把本体做成 skill 有没有先例？**

A2：有，但形态可能和想象的不同。Knowledge-as-Skill（arXiv 2609.25991）把知识库组织成可发现、可导航、自描述的三层结构，遵循 Skill 协议，让智能体能够自己决定是否检索、检索什么。注意它把"知识"做成了"能力目录"——智能体知道有什么能力可用，再调用对应的检索。本体在这里是 skill 的目录页，不是 skill 的执行体。

**Q3：校验层用规则引擎不就行了，为什么要上本体？**

A3：这是一个真实的权衡，不是本体必胜。重庆银行数智尽调平台的约束逻辑就是规则引擎承担的，平均自动化完成率 60%，没有用本体（来源5 已核实）。区别在可维护性：SHACL 形状是声明式的，业务专家能审阅；规则引擎代码是过程式的，业务专家审不了。如果规则一年改一次、量也少，规则引擎够用；如果规则随制度高频变更且需要业务方确认口径，本体的可审阅性才值回票价。

**Q4：OG-RAG 的 +55% 召回率能直接用在资产保全上吗？**

A4：不能直接照搬。那是论文在其领域文档与四个 LLM 上的自述基准对比，不是第三方复现，也没有在金融不良资产场景验证过。可迁移的是机制（用本体锚定事实、检索最小集合），不是数字。落地时应在内部案卷上做小规模对照，测自己的召回率变化。

**Q5：金发〔2026〕8号有要求银行建本体吗？**

A5：没有直接要求"建本体"。第十一条要求的是"构建核心知识模型"与"建立知识萃取、整合、共享机制流程"，第二十二条要求关键决策"完整保留原始数据、推理路径及阈值触发记录"。**监管规定的是结果（知识有模型、决策可追溯、阈值有记录），不是手段（必须用某种技术架构）。** 本体是实现这些结果的一种路径，不是唯一路径。

**Q6：本文哪些内容最需要人类核实？**

A6：四处。

- **OG-RAG 的四个百分比是论文摘要自述**，非第三方复现，且未在金融场景验证。microsoft/ograg2 仓库本文核实为 MIT License、149 star，但未审阅其代码实现细节。
- **Knowledge-as-Skill 的 WixQA 数字作者自述为方向性跨工作证据**，不是受控比较；且该方法在 Faithfulness 与 Context Precision 上略低、交互轮数更多。其 Open Knowledge Format 与 Skill 协议本文仅按摘要描述引用，未核实规范文档原文。
- **来源4（arXiv 2511.05991）的用词是 competitive（有竞争力）而非 outperform**，本文引用时已保留这个措辞强度，未做升级。
- **第五节的三层配比表与三问判据、第六节三条边界、第七节全部行动清单均为本文提出的设计**，不是既有实施案例。两个业务场景的配比是本文依据任务形态（生成型对判断型）做出的推断，落地前需要用本行数据验证。

## 九、事实来源

- **来源1**：OG-RAG: Ontology-grounded retrieval-augmented generation for large language models（Sharma, Kartik；Kumar, Peeyush；Li, Yunqing）。https://aclanthology.org/2025.emnlp-main.1674/ ；Proceedings of the 2025 Conference on Empirical Methods in Natural Language Processing（EMNLP 2025，苏州），pp. 32962–32981，Association for Computational Linguistics，CC BY 4.0，DOI 10.18653/v1/2025.emnlp-main.1674。本文引用：摘要自述的四个提升（准确事实召回率提升 55%、响应正确率提升 40% 跨四个不同 LLM、归因速度提升 30%、基于事实的推理准确率提升 27%）；机制（领域文档的超图表示，每条超边封装一组由领域本体锚定的事实知识，用优化算法为给定查询检索最小超边集合）。
- **来源2**：microsoft/ograg2 - OGRAG Release Version。https://github.com/microsoft/ograg2 ；GitHub 开源仓库，本文经 GitHub API 核实 MIT License、149 star、37 fork、Python、2025-04-25 创建、2026-03-12 最后推送。该仓库为来源1 的官方代码发布。
- **来源3**：Knowledge-as-Skill: A Structural Design for Autonomous Knowledge-Base Use by LLM Agents（Wu, Jiangxu）。https://arxiv.org/abs/2609.25991 ；arXiv preprint，2026-09-22。本文引用：传统 RAG 的检索-拼接-生成管线代替模型做检索决策，工具调用与智能体循环更可靠后暴露的新瓶颈是智能体可能不知道知识库里有什么；传统知识库把文档暴露为匿名文本块，缺少关于范围、用途、溯源或关系的信息；三层设计（发现层、导航层每目录一入口、知识层文档带 YAML 前置元数据记录主题类型溯源与生命周期）；遵循 Open Knowledge Format 与 Skill 协议且不修改智能体框架；提供把 PDF、Word、网页导出与笔记转换为该结构的 pipeline；WixQA 企业客服基准初步评测 0.889 Factuality 与 0.816 Context Recall 对比已报告的 Corpus2Skill 数值 0.767 与 0.708，Faithfulness 与 Context Precision 略低、交互轮数更多；作者自述因模型提示与知识包构建不同，这些结果是方向性跨工作证据而非受控比较。
- **来源4**：Ontology Learning and Knowledge Graph Construction: A Comparison of Approaches and Their Impact on RAG Performance（da Cruz, Tiago；Tavares, Bernardo；Belo, Francisco）。https://arxiv.org/abs/2511.05991 ；arXiv preprint，2025-11-08。本文引用：RAG 性能严重依赖知识表示方式；对照标准向量 RAG、GraphRAG、以及由关系数据库或文本语料构建的本体知识图谱检索；本体引导知识图谱纳入文本块信息后达到与先进框架有竞争力的表现并显著优于向量检索基线；由关系数据库构建者与由文本提取者表现相当但只需一次性本体学习过程、大幅降低 LLM 使用成本并避免文本方法固有的本体合并复杂性。
- **来源5**：本站已发布文章《指标算得对≠机器能推理：上下文图、本体与银行 AI 的真实缺口》。https://bi-chao.com/articles/semantic-layer-vs-context-graph-banking 。本文引用其已核实的五项：金发〔2026〕8号《关于银行业保险业人工智能安全开发应用的指导意见》（国家金融监督管理总局，2026-06-18，科技监管司，索引号 717804719/2026-365，三十二条款项序号连续）第十一条推进知识工程建设原文（构建核心知识模型、建立知识萃取整合共享机制流程、建立从知识创建审核发布更新到归档的全流程管理规范、鼓励利用人工智能技术提升知识萃取表示融合和对齐能力）与第二十二条（涉及客户权益或有实质性财务影响的关键决策须设人工复核节点，完整保留原始数据、推理路径及阈值触发记录）；LLMs4OL 2024 挑战赛（arXiv:2409.10146）实测对照（分类发现 B.5 DBO 子任务 silp_nlp 传统 ML 即 RF/LR/XGBoost F1 0.2109 对 Phoenixes 的 Mistral-7B 加 DPR 检索 0.0164；B.6 FoodON 零样本 0.0308；非分类关系抽取 C.1 UMLS 少样本 0.0783 对 0.0273；术语类型化 A.1 WordNet 微调 Flan-T5-Small 0.9716；B.2 Schema.org 0.6157；论文自述微调仍是本体学习获得高性能的关键、模型规模的影响既不单调也不一致、非分类关系提取在各规模上都困难）；NeOn-GPT（ESWC 2024）形式化缺陷（LLM 生成本体的类表达式普遍限于包含关系类型并缺乏合取与析取，属性限制类型主要限于 HasValue，缺失基数、存在量词与全称量词限制，可能在推理步骤限制类成员推断的范围）；重庆银行数智尽调平台（规划工期 12 个月四个阶段，试点 8 家分支机构，累计处理任务近 300 条，产出上百份尽调报告，平均自动化完成率 60%，采用开源大模型加图数据库，约束逻辑由规则引擎而非本体承担）。
- **来源6**：本站已发布文章《本体构建方法论综述：Talisman 六阶段管线与 LLM 参与构建的实证，以及银行场景仍缺的三块》。https://bi-chao.com/articles/ontology-pipeline-llm-review 。本文引用其自述的 657 三元组银行资产保全本体骨架（AnnotationVocabulary.rdf 含 hasMaturityLevel 与 mappingLoss 与 mappingBasis；CollateralScheme.rdf 押品分面码表四个正交分面 29 个 SKOS 概念；Lifecycle.rdf 案件与 6 个逾期阶段与 8 项保全措施与顺位 1–6 与 7 类角色；Mapping.rdf 33 条到 FIBO 的显式有损映射）；Talisman 六阶段管线（受控词表、元数据标准、分类法、叙词表、本体、知识图谱）；ICEIS 2025《Pipeline for Ontology Construction Using a Large Language Model: A Smart Campus Use Case》（Lichtnow 等，SCITEPRESS，DOI 10.5220/0013096000003929）记录的失效模式（ChatGPT 初始回复包含不存在的本体；无状态另开会话导致已修正错误回退）。
- **来源7**：本站已发布文章《FIBO 没有资产保全本体：银行不良处置建模的复用边界、自建清单与治理陷阱》。https://bi-chao.com/articles/fibo-asset-preservation-ontology 。本文引用其对 edmcouncil/fibo 全部 295 个本体的逐词核查结论：可复用边界限于 FND/FBC 基础层与 Collateral 及其两个子类；不良处置领域核心词 workout、repossess、charge-off、perfection、security interest 在全库零命中；FIBO 唯一的违约类 LoanDefaultProceeding 的 skos:definition 字面值为无定义、所在文件成熟度为 Provisional。
- **来源8**：本站已发布文章《资产保全的智能化升级需要什么样的 FDE——当监管边界比模型能力更早决定自动化的上限》。https://bi-chao.com/articles/asset-preservation-fde-capability-challenges 。本文引用其两条监管红线：国标 GB/T 45251-2025 第 5.3.1.8 条明确授权金融机构与第三方催收机构可使用人工智能技术开展催收作业，同时规定告知式语音催收（含智能语音）对单一债务人每日合计不超过 3 次；金发〔2026〕8号要求人工智能高风险应用须经风险管理委员会批准。
- **来源9**：本站已发布文章《资产保全智能体的本体论与知识图谱怎么配套建：两个真实业务场景的路径设计、自动化管线与快速落地清单》。https://bi-chao.com/articles/asset-preservation-agent-ontology-knowledge-graph 。本文引用：转让场景九阶段流水线（组包、卖方尽职调查样本资产金额不低于每批次 80%、估值、方案审批、要约邀请、买方尽调、确定受让方签约、公告，严禁抽屉协议或回购条款）；核销场景财金〔2013〕146号的 19 条一般债权呆账认定标准与账销案存；pyshacl 0.40.1（Apache License 2.0）、rdflib 7.6.0、owlrl 7.6.2 的 PyPI 官方版本核实；十二条能力问题（转让六条加核销六条）；三条 SHACL 形状示例（唯一生效转让协议且无回购协议、至少一条认定标准且证据带来源指针、字段必带文书与页码位置指针）。

**本文推论部分（非来源表述）**：第一节三种载体在生成链上的作用点与三种强制性等级的划分；第二节"本体是 RAG 的骨架不是内容"与"本体补上范围用途溯源关系四样"的论断；第三节三种放法（检索层可忽略、skill 层可不调用、校验层不可绕过）的对照与"阈值触发记录在技术上是校验层输出"的对应、以及"校验层未必需要本体但需要可维护性"的权衡；第四节"本体是 skill 的目录页不是执行体"的判断；第五节三问判据与两个业务场景的三层配比表及"知识放错作用点"的故障解释；第六节三条边界（含 13 倍 F1 差距解释为什么不能让模型重做本体工程、以及别把本体塞进 prompt）；第七节全部行动清单；第八节 FAQ 全部回答。文中所有百分比、F1 数值、库规模、版本号与监管条款编号均为来源 1 至 9 的原始记录，凡论文自述、方向性证据与机构自述均已标注。

**本文不构成监管要求、合规意见或技术选型建议。监管引用以本站前作核实的口径为准，正式引用请核对金融监管总局与财政部正式文件。**

*（内容由AI生成，仅供参考）*