rag系列文章目录

---

前言

目前市场上大模型agent越来越多，几乎每家公司都在搞，希望通过agent解决实际的业务问题。Agent的重点和难点在于任务的规划，也就是planning，如果任务规划正确，结果大概率正确。

其次，每个业务场景对任务出错的容忍度不一样，ToC场景，如果客户觉得不满意，可以再多次使用，或者放弃使用，不会有严重的后果。但是对于医疗、法律、金融等场景，就不太可能接受错误，或者出错会有很大的影响。

基于此，可以尝试基于知识图谱的agent。

---

一、Ontology（本体）

说知识图谱，首先介绍下本体。

在计算机科学和人工智能中，本体是指：
一个形式化的、明确的规范，用于描述某个领域中的概念、实体、属性、关系以及约束规则。

本体会定义概念类别和语义关系，比如：

• 类（Concepts）：疾病、致病因子、研究文献、药物 …
• 关系（Relations）：
  o 疾病 由 致病因子 引起
  o 疾病 相关研究 研究文献
  o 药物 治疗 疾病

这些就是“语义骨架”。

二、知识图谱

本体只是框架，知识图谱是基于本体填充各种实体以及它们之间的边。

比如糖尿病是疾病的一个实体，肠道菌群是一个实体，a文献是一个实体，有一个关系是糖尿病和a文献的研究关系，还有一个关系是肠道菌群和a文献的研究关系。

如果客户提问“有哪些新研究表明肠道菌群与糖尿病有关？”，那么可以首先进行语义解析，解析出实体：肠道菌群、糖尿病。然后再解析出意图，找到和两者有关系的实体（即文献），那么可以基于图sql进行查询即可。

知识图谱数据库，有两种类型，RDF Store (Resource Description Framework)和 Property Graph。
它们之间的对比如下：

维度	RDF Store	Property Graph
数据结构	纯三元组 (S-P-O)	节点 + 边 + 属性
标准化	严格遵循 W3C 标准 (RDF/OWL/SPARQL)	没有统一标准（Cypher, Gremlin, GQL 正在标准化）
语义能力	强（支持推理、约束、本体）	弱（多用于工程逻辑）
易用性	偏学术/语义网，开发门槛高	工程友好，建模直观
性能	适合复杂推理、跨库整合，但性能可能瓶颈	高性能查询，适合推荐、社交、金融风控
应用场景	语义网、知识集成、需要严格推理的 AI agent	工程应用、实时分析、图推荐、业务 agent

在大模型 Agent 中怎么选？

• 需要保证语义一致性、用本体约束 → RDF Store 更合适
  （比如医疗、法律、科研助理）
• 偏重工程任务规划、实时推荐、路径计算 → Property Graph 更合适
  （比如电商推荐、客服流程规划、运维 Agent）
• 混合方案：也有人用 RDF Store 管理语义 & 本体，然后同步到 Property Graph 做高性能查询。

三、基于图谱推理

使用知识图谱来做agent，一般有以下流程：

1. 本体建模（Ontology Layer）
   o 建立金融知识本体（投资人、基金、产品、监管规则、合规条款…）
   o 定义关系：
    Person → manages → Fund
    Fund → hasPerformance → PerformanceData
    Fund → compliesWith → Regulation

2. 知识库 & 推理规则（OWL + SWRL Layer）
   o OWL：定义类、实体和属性（例如“公募基金”“私募基金”“基金经理”）。
   o SWRL：写推理规则，例如：
    如果某基金经理涉及处罚记录 → 则基金被标记为“高风险”
    如果基金年化收益率 > 8% 且波动率 < 5% → 则基金为“稳健型”

3. 数据接入（Data Layer）
   o 接入基金公告、Wind/同花顺数据库、监管处罚名单。
   o 使用 ETL 或 API 将结构化数据转换为 RDF 或 Property Graph。

4. Agent 架构（Hybrid Reasoning Agent）
   o LLM：自然语言理解 → 将用户问题转化为查询意图。
   o 本体推理引擎（Pellet, HermiT, GraphDB）：执行OWL/SWRL推理。
   o 图数据库（Neo4j / Stardog / RDF4J）：存储和检索。
   o 合规模块：对返回结果进行合规过滤（例如屏蔽预测性评价，只允许溯源数据）。

---

总结

把知识图谱（KG）与 LLM 结合是当前的主流趋势之一，它可以一定程度上解决大模型幻觉，推理不稳定的问题，在严格有合规要求的场景具有很大的意义。

参考文档