向量库是RAG的伪命题，知识图谱是答案，本体论是灵魂

本文来自微信公众号： 叶小钗 ，作者：叶小钗

在最初做RAG系统的时候有个几乎绑定的名词：向量库。所以他是什么呢？

应该说向量库是一个理论上很美好的名词，他是一类用于存储和检索向量的数据系统，这里有两点要注意：

1. 向量（embedding），可以将一段文本、图片、音频等内容，通过embedding模型编码成一个高维数组；

2. 检索，现在拿着一个查询向量，理想情况下向量库可以快速找到最相似的Top-K条类目，这里可以带上原文片段等信息；

所以，向量库找的是语义相近，而不是关键词查询。比如你去搜苹果，系统不可能给到你iPhone手机的，当向量库可以将他搜出来，于是大家就开始兴奋了。这似乎意味着：我们从关键词查询进入了语义查询了！

另一方面，早期模型能力不行，单词上下文也就几千Token，而主流的文本embedding模型最佳编码长度也就500左右（256-768 tokens，最近也有提升到了8000左右Tokens的）：

1. 太短了，可能信息不足，embedding表达不完整，匹配不上；

2. 太长，单个向量需要概括的信息过多，可能稀释核心语义，难以在相似性搜索中被选择，这是“信息淹没”；

这还正好跟模型上下文还对上了，于是乎向量库在早期的RAG系统几乎是标配，并且Coze、Dify、N8N等Agent低代码平台都是默认带上了向量库的，这进一步给很多不明真相群众造成了烟雾弹效应；

但真正使用过程中，大家又发现了好像玩不转，最主要的问题就是断章取义，要明白这是什么，就需要简单做展开：

unsetunset传统RAGunsetunset

传统向量库构建知识库的底层逻辑，是很粗糙的：

1. 切分（Chunking）：把一整段文档直接丢给向量库，然后开始无脑分块；

2. 向量化（Embedding）：把这些块映射成高维空间里的坐标；

3. 检索（Retrieval）：当用户问问题时，去找空间里距离最近的几个chunk；

4. 拼凑（Prompting）：把这几个chunk塞给大模型，说：”来，信息都给你了，把完整文档该给我了”；

如果原始文档过长，而每段分块内容又是不可控的，这里就会导致很多问题，最经典的就是上下文割裂：

文档分块的时候对原文的完整性进行了破坏，比如表格阶段、论证逻辑切断，最终结果是信息丢失，比如以下案例：

电商“退款助手”场景，用户问“多久到账”。RAG只召回主条款“T+1”，把下一块的“黑名单/已发货订单除外”没带进来，助手回答“一律T+1”，这可能导致高风险订单被误退款。

更恐怖的是医疗或者法律场景，比如将临床指南按段落切分，导致降压药“适用症”与关键的“妊娠期禁用”提示被分隔在不同向量块。

医生在审方时询问：“孕妇高血压能否使用某某地平？”系统如果仅检索到并返回了“适用症”信息块，生成的结果显示“该药可用于治疗高血压”，这存在严重安全隐患。

于是乎，大家逐渐发现一个问题：什么JB语义检索，还是关键词检索靠谱！，于是乎，向量库其实在后来模型进步后（上下文越来越长），一直是个非常尴尬的存在。

但如果非要把这些锅丢全部给向量库，也不大合适，因为RAG效果不行多半是大家想偷懒，数据处理（包括切分）没做好的缘故…

因为大家最后终于发现了：语义相似也只能解决部分问题，我们需要完整的数据关系来表征真实的世界，说人话就是：我们不止要数据，我们还要关系，比如你说到苹果，我们要根据上下文自动带出iPhone，还需要连带带出乔布斯等数据；

到这里才引出今天的主角知识图谱，其实复杂的AI知识库，用的多半是伪知识图谱技术，这里会同时涉及到关键词、向量库检索等。

unsetunset知识图谱unsetunset

知识图谱和知识库非常相似，可以说知识图谱是知识库的一种有机表现形式。在逻辑上，知识库通过关系链的建立也能够形成图谱结构。

具体来说，知识库是对各种知识的组织、存储和管理，而知识图谱则是在此基础上通过图的结构（实体、关系和属性）来呈现知识的内在联系和结构。

知识图谱通常包括三大元素：

1. 实体（Entities）：即图中的节点，代表真实世界中的事物、概念等（如人、地点、物品、概念、类别）。

2. 关系（Relations）：实体之间的连接或联系，描述实体之间的互动。

3. 属性（Attributes）：描述实体或关系的特征信息，如一个实体的具体属性值。

通过这种标准化的表示形式，知识图谱不仅能够展示实体之间的关联，还能够进行语义分析，帮助计算机理解和推理这些关系。

它为我们提供了一种更加直观、结构化的方式来管理和呈现知识库中的信息。

更粗暴的理解可以是：图谱就是强制将知识库按照实体、关系、属性的标准做结构化，两者间界限很模糊

为方便理解给一个案例，首先是没有关系的知识库：

疾病:{

名称:”糖尿病”,

类型:”慢性疾病”,

并发症:[“心血管疾病”,”肾脏病”,”神经损伤”]

}

症状:[

{名称:”口渴”,常见疾病:”糖尿病”},

{名称:”频繁排尿”,常见疾病:”糖尿病”},

{名称:”体重下降”,常见疾病:”糖尿病”},

{名称:”疲劳”,常见疾病:”糖尿病”}

]

药物:{

名称:”胰岛素”,

类型:”药物”,

用途:”控制血糖”,

使用方法:”注射”

}

然后是有关系的知识图谱：

实体:[

疾病(“糖尿病”):{

类型:”慢性疾病”

},

并发症(“心血管疾病”):{},

并发症(“肾脏病”):{},

并发症(“神经损伤”):{},

症状(“口渴”):{

常见疾病:”糖尿病”

},

症状(“频繁排尿”):{

常见疾病:”糖尿病”

},

症状(“体重下降”):{

常见疾病:”糖尿病”

},

症状(“疲劳”):{

常见疾病:”糖尿病”

},

药物(“胰岛素”):{

类型:”药物”,

用途:”控制血糖”,

使用方法:”注射”

}

]

关系:[

(疾病(“糖尿病”)-表现为->症状(“口渴”)),

(疾病(“糖尿病”)-表现为->症状(“频繁排尿”)),

(疾病(“糖尿病”)-表现为->症状(“体重下降”)),

(疾病(“糖尿病”)-表现为->症状(“疲劳”)),

(疾病(“糖尿病”)-引发->并发症(“心血管疾病”)),

(疾病(“糖尿病”)-引发->并发症(“肾脏病”)),

(疾病(“糖尿病”)-引发->并发症(“神经损伤”)),

(疾病(“糖尿病”)-治疗->药物(“胰岛素”))

]

PS：上述只是为了便于各位理解图谱是什么，真实的情况会更复杂，但大体是这么个意思

比如常见的贝叶斯预测：P(糖尿病|多饮+多尿)=P(多饮|糖尿病)x P(多尿|糖尿病)x P(糖尿病)/P(多饮+多尿)

在大模型时代，当前模型对于根据症状推导常见疾病已经非常擅长，但是依旧会由于幻觉有各种问题，这里知识图谱的意义就来了：

输入：咳嗽+呼吸急促+发热+胸痛

图谱推理路径：

症状→咳嗽、呼吸急促、发热、胸痛

症状→[常见疾病类别]→呼吸系统疾病

可能的疾病：肺炎、支气管炎、慢性阻塞性肺疾病（COPD）

进一步筛查→[检查指标]→血氧饱和度、白细胞计数、胸部影像

如果胸部影像显示肺部浸润阴影，高度怀疑肺炎或肺结核

影像学特征差异→[不同疾病影像学差异]→肺炎（浸润阴影）vs肺结核（钙化灶）

若影像学表现为浸润阴影，进一步考虑细菌性肺炎

最终诊断→[关联知识库]→确定细菌性肺炎可能性

若有相关临床史（如吸烟史、基础疾病），可能进一步确定为慢性阻塞性肺疾病合并肺炎。

综上，大模型其实就是我们所谓的快思考而知识图谱（知识库）就是我们所谓的慢思考了，在快慢结合下，医疗AI的答案将更为靠谱。

unsetunset知识图谱→CDSSunsetunset

医疗是知识图谱最经典的场景，而大模型出现之前最经典的图谱类产品是CDSS（Clinical Decision Support System）：临床决策支持系统，是一种为辅助医疗专业人员做出临床决策的AI技术产品。

因为AI辅助诊断的需求一直存在，所以前些年一直有机构在做CDSS的尝试，比如IBM Watson就投入了大量资源，但最终却以失败告终，现在回过头来看看其价值和失败的原因，可能为后续的AI应用研发提供一些中肯的建议。

CDSS的核心原理

CDSS的核心原理之一是基于规则的推理，这种方法依赖于大量由领域专家（医生）手工输入的规则和知识库。

每条规则通常以“如果…则…”的形式存在，系统通过这些规则对患者的症状、检查结果等信息进行分析，给出相应的建议。例如：

1. 如果患者有发热、咳嗽和气促的症状，那么该患者可能感染了呼吸道疾病；

2. 如果患者的血糖水平持续超过某个阈值，可能需要调整糖尿病治疗方案；

以上的所有规则便形成了CDSS最核心的知识库，他是CDSS最重要的组件：存储着关于各种疾病、症状、治疗方法等的信息。

这些信息通常来自医学文献、临床经验以及专家的知识，通过不断更新知识库，CDSS可以适应最新的医学研究成果和临床实践。

最终CDSS利用知识库中的信息结合患者的临床数据，进行诊断和治疗推理。它可以根据患者的病史、体征、实验室检查结果等信息，自动生成诊断建议，并根据既有的治疗方案推荐治疗方法。

只不过这里有两个核心的问题也就暴露出来了：

第一，知识库不全

CDSS的效果依赖于知识库的完整性，而知识库的完整性依赖于专业人员的不断录入。

且不论ICD11上的几万个疾病信息一次完整录入何其之高，一旦知识库中出现任何错误整个系统就会受到质疑，由此CDSS失败的罪魁祸首出现：

完整的知识库总是难以达成，包括知识的校准以及信息不断的更新，专业医生的时间成本极高。

第二，泛化能力不足

CDSS之所以是辅助系统，是因为其泛化能力不足，他无法从海量的患者语言中抽取出他需要的医学关键词，换句话说：真实世界的患者描述是很宽的，而CDSS的入口是很窄的，这导致了CDSS的适应性极差。

比如患者的描述是：我感觉到胸口很沉，有时候呼吸急促，特别是晚上躺下时。

CDSS通常需要将这些信息转化为结构化的数据，如“胸痛”、“呼吸急促”等，才能对症下药。

但“胸口很沉”这样的描述是非标准化的，且没有精确到医学术语，CDSS难以直接识别并匹配相关的疾病（如心脏病或呼吸系统问题）。

这里还产生了另一个问题，一旦CDSS的理解（关键词抽取）是错误的，那么整个诊断建议都是不可逆的错误。

这里虽然有些排除算法，但并不能从根本解决问题，因为没办法解决关键术语抽取能力的缺陷。

下图应该能让大家直观的感受到泛化能力中宽窄的情况：

术语	可能描述	难以解释
头痛	“太阳穴一跳一跳地疼””后脑勺像被锤子砸””一吹风就头胀””看电脑久了眼眶连着疼”	无法区分偏头痛/紧张性头痛/青光眼
胸痛	“心脏位置像针扎””左胸有东西压着喘不过气””胸口火辣辣地烧””深呼吸肋骨下刺痛”	可能混淆心绞痛/胃食管反流/肋间神经痛
呼吸困难	“喉咙被掐住的感觉””吸气吸不到底””睡觉躺不平会憋醒””走两步就要大喘气”	无法区分哮喘/心衰/COPD/焦虑症
铁摄入过量	“最近补铁片后大便发黑””每天吃半斤菠菜+猪肝””孕期补铁后恶心加重”	可能忽略铁剂中毒风险

无法跨越这个泛化能力不足的问题，所以CDSS只能是辅助系统，由医生输入真实的症状信息，比如医生根据用户描述进行症状输入。

者就显得CDSS很鸡肋了：好的医生不需要CDSS，水平不行的医生本身也抽取不准，一时之间，CDSS竟有鸡肋之感受！

所以，结论就是：CDSS没用咯？这可能也不至于，特别是大模型的AI时代。

CDSS的本质是医学知识库，更进一步可以衍生出一套医学知识图谱，这套图谱在之前由于泛化能力不足所以不好用，但在大模型时代技术鸿沟的问题被弥合了，所以知识图谱也就开始焕发新生了。

unsetunset图谱VS知识库unsetunset

从存储方式来说图谱区别于知识库的差异在于图结构VS表结构，其实更深一步来说，其差异是认知的差异，或者说点状或网状：

传统的知识库以表分类知识：传统知识库如同中药房的百子柜，每个抽屉（数据库表）存放着严格分类的知识：

1. 疾病表：ICD-11编码、标准名称、所属科室；

2. 药品表：化学名、适应症、禁忌证；

3. 症状表：标准化描述、关联器官；

这种结构的致命缺陷在2020年新冠疫情中暴露无遗：当患者同时出现发热、腹泻、味觉丧失时，系统无法自主发现这些跨科室症状的新型关联模式。

其实这里疾病和症状表之间可以通过多重关系表（如症状与疾病的“表现为”关系）建立更多动态的联接，这能更好地发现症状之间的组合关联模式。

但即便如此，这种关系依然是预先定义好的。这里的意思是：知识库+关系表在已知关系的场景中可以满足大部分需求，尤其是在数据结构比较明确且稳定的情况下。

而知识图谱的核心优势是开放系统的可扩展性，以及它能够应对更加动态、复杂和未知的情况，举个例子：

二甲双胍的案例

二甲双胍是治疗2型糖尿病的一zhong药物，但我们发现：

1. 长期服用后体重可能下降；

2. 可能通过抑制肝糖异生、改善胰岛素敏感性间接影响脂肪代谢；

3. 在非糖尿病人群中也可能产生代谢调节作用；

这类跨领域的关联关系在传统医学知识库中往往缺失，因为不是糖尿病治疗重点，所以一般不会存在，但知识图谱可以低成本扩展。

假设某医学数据库的结构如下：

当需要添加【二甲双胍→减肥】关系时：

1. 需要修改数据库模式（新增字段或关联表）；

2. 需临床指南明确认可该用途才能入库；

3. 无法表达间接作用机制（如通过AMPK通路影响代谢）；

PS：从这里也可以看出来，图谱的存在其实是为了解决工程维护问题

但以上问题在知识图谱规则中就比较简单了：

当新研究发现时，只需添加三元组：

以上算是产品视角层面图谱与知识库的核心差异。

生成手段

传统知识库通常由权威专家（至少会有专家校验）手工录入数据，所有信息都经过严格审核，确保每条记录都能追溯到权威文献（顶级期刊）或临床指南（最差也得是教材）。

这种方式使得数据具有高度的准确性和权威性，便于医生查证数据的来源，提高医疗决策时的信心。

知识图谱的话除了从结构化的数据（比如知识库）生成外，还会从非结构化数据（比如文章、文献、网页甚至影像等）提取关系和实体。

毕竟舒服的工作是他自己就将结构提取好了，比如之前我们研究的阿里KAG框架，可以直接提取我文章形成图谱：

《第一节：经理的能力模型》（现在公众号不允许外链，我这里就不发出来了）

PS：只不过实际提取的还不太好，现在也没太更新，总之不好用…

医疗置信度

在当前医疗大模型产品中，溯源（可追溯性）和医疗置信度是至关重要的，因为它们直接关系到诊断决策的安全性和可靠性。

指能够追踪每一条信息的来源，从原始文献、临床指南、专家共识到数据采集的具体过程。

溯源性越高，医生越能确信系统给出的结论有明确的依据，从而在临床决策中更有信心使用这些数据。

只要医疗信息可溯源，加之算法清晰合理，其医疗置信度自然就高了。

综上，图谱与知识库各有优劣但大家也不必纠结，一起使用就好，其实可以看出，图谱会更适应于大模型时代的搜索使用。

至此进入今天的正题：知识图谱+大模型提升解决医疗幻觉问题

unsetunset图谱+LLMunsetunset

如上所述，AI1.0时代的CDSS根本无法满足医生的基本使用，而大模型时代的DeepSeek依旧在模型幻觉等问题上让医疗人员犹豫不决，比如以下案例：

在急诊分诊、手术抢救等情境下，错误的诊断不仅会延误治疗，还可能使患者失去最佳抢救时机，极大地危及生命。

因此，降低大模型幻觉风险、提高生成答案的可信度成为关键任务。

而知识图谱结合大模型的使用会是解决模型幻觉乃至增强医疗置信度的有效手段

PS：这类应用其实有很多，比如前面所述的KAG乃至GraphRAG（由微软研究院开发的一种新型检索增强生成框架，它旨在利用知识图谱和大型语言模型来提升信息处理和问答能力）。

医疗置信度的四个维度

为了保证诊断建议的准确性和临床安全性，我们需要考虑四个维度：

1. 数据溯源。每条诊断结论都应能追溯到权威指南、临床文献和历史病历数据。只有明确溯源，医生才能信任系统的判断。

2. 一致性。综合患者的主诉、检查数据、影像资料等多方面信息，确保不同数据源之间推理结果的一致性。多模态一致性有助于消除单一数据带来的偏差。

3. 动态性。系统必须能够实时更新，根据最新的医学研究和临床指南动态调整诊疗路径。动态适配确保了诊断建议始终反映最新临床证据。

4. 可解释推理链。生成的答案应附带详细的推理链和证据来源，让医生了解每一步判断的依据，从而对系统的决策过程有充分信任。

医学知识结构化

医疗知识图谱可以形成一张庞大的知识网络。例如，对于2型糖尿病：

通过这种结构化方式，系统可以明确展示各医学实体之间的因果和关联关系，形成完整的知识链条。

这样，在实际诊断过程中，知识图谱不仅能提供丰富的背景知识，还能对大模型的生成过程进行实时约束，从而降低幻觉风险。

并且，图谱的更新速度可以很快，以进一步保障医疗的及时性。

unsetunset图谱+RAGunsetunset

在实际应用中，将知识图谱与RAG技术结合，可以构建一个多层次的诊断体系：

该系统通过路由、查询规划，形成了一个自上而下的三层防御体系，确保生成答案具有置信度和可解释性：

在此架构中，系统首先对输入问题进行初步判断：对于简单、标准的查询直接由RAG基础层处理；

而对于复杂、多模态或涉及实体关系的问题，则交由图谱推理层进一步分析。

无论哪种路径，最终结果都经过置信度验证，当系统置信度超过预设阈值（如90%）时直接输出，否则提交专家复核。

以下是通过知识图谱实现对复杂问题的结构化推理案例：

为了更直观展示知识图谱+LLM对提高医疗置信度的效果，下面通过三个层次的案例进行对比分析，以下是基本输入：

一、大模型（无RAG技术）

二、大模型+RAG

这里的输出其实已经不错了，只不过组装的信息缺少逻辑性。

二、大模型+图谱+RAG

这种在输出前结合CoT的功能，再集合溯源的功能，医生还不被迷得死死的…

本体论

聊到图谱就不得不提最近一个偶尔被提起的新词：本体论，Ontology。

所谓本体论，如果放到AI知识系统中，他核心想要做的事是，去表述这个世界应该被如何定义，要注意，这个世界可以很小。

所以，图谱更像一张网，本体论可以是这张网背后的建模逻辑，从这里就可以看出他们的关联性很大了，这也是为什么本体论做完了看上去和图谱差不多的原因：

这里大家可能看不懂，我们继续回归前面CDSS相关案例，我们不能随便把发热、肺炎、抗生素、白细胞升高，都等价为图谱上的节点，因为这些东西根本不是同一类对象：

• 发热是症状；

• 肺炎是疾病；

• 抗生素是药物类别；

• 白细胞升高是检查结果；

• 细菌感染可能是病因；

• 用药禁忌又属于约束条件。

本体论的价值在于，它先定义清楚几件事：

1. 实体类型是什么：疾病、症状、药物、检查、指南、禁忌证、适应证；

2. 实体之间允许什么关系：疾病表现为症状，药物治疗疾病，药物禁用于某类人群；

3. 关系的语义强度是什么：是因果、相关、并发、风险提示，还是弱关联；

4. 推理规则是什么：哪些关系可以传递，哪些关系不能传递，哪些结论必须结合证据等级。

举个简单例子：

二甲双胍——治疗——2型糖尿病

二甲双胍——可能导致——体重下降

二甲双胍——通过AMPK通路影响——代谢调节

这三条关系都是对的，但它们的医学含义完全不同：

• 第一条是明确适应证，置信度高；

• 第二条是临床观察或副作用层面的关联；

• 第三条是作用机制层面的解释。

如果没有本体论，系统可能会把它们粗暴理解成：二甲双胍可以减肥，这显然是不对的。

这就回到了知识图谱的问题了，图谱这个技术本身是没有KnowHow的，也就是是我们这批不懂医学的程序员做出来的，但我们做出来的东西肯定会存在很多问题，其中最重要的就是：这个领域里的知识，应该按照什么规则被理解？

这也是为什么医疗、法律、金融这类高风险行业，不能只靠大模型自动抽取三元组就完事，大模型可以帮我们提高抽取效率，但本体论决定了这些抽取结果能不能被正确使用。

说到底，关系千千万，我们需要的逻辑是什么，这个反而最重要。

这里我下个结论：本体论是让知识图谱具备行业KnowHow的建模规则…

unsetunset结语unsetunset

最后总结一下：向量库从来都不是RAG必须的选择，他的问题很大，它将知识压缩为孤立的“点”，这种所谓语义检索是很脆弱的。

相应的，知识图谱的“回归”，则是对知识本质的回应：它不满足于点与线的偶然关联，而是着力构建实体、属性和关系的确定网络。它带来的不是“更像”，而是“更相关”与“更可信”，通过可解释的逻辑链，将检索从概率匹配提升到关系推理。

事实上做过复杂AI知识库业务的同学会理解：伪知识图谱就是CoT本身了。

最后，工程实践也正在走向务实与融合，但依旧有很多问题需要处理，其中最大的问题是人们很“懒惰”，他们并不想去处理烦躁的数据。于是乎市面上也出了很多自动数据处理的框架，比如PageIndex：

他通过层级化、结构化的索引，检索可以变为先定位、后精读的“规划-取证”流程。

向量库在此体系中，作用是处理模糊问法的补充工具，这可能才是他真正需要去到的角色。真实的系统，往往是关键词、规则路由、向量检索与图谱查询的混合体。

这里再说下下阶段的可能：未来的AI知识系统，或许将不再显式区分这些组件，而是将其内化为自主规划、多步推理、自我校验的Agent能力。从“检索增强”走向“推理增强”，让机器不仅找到片段，更能理解因果，最终交付确信的答案。

我反正看进来Google的NoteBookLLM表现是很不错的，他的技术路径可能是个方向。

好了，文章很长了，希望对大家有用！

#向量库是RAG的伪命题知识图谱是答案本体论是灵魂