在最初做RAG系统的时候有个几乎绑定的名词向量库。所以他是什么呢应该说向量库是一个理论上很美好的名词他是一类用于存储和检索向量的数据系统这里有两点要注意向量embedding可以将一段文本、图片、音频等内容通过embedding模型编码成一个高维数组检索现在拿着一个查询向量理想情况下向量库可以快速找到最相似的Top-K条类目这里可以带上原文片段等信息所以向量库找的是语义相近而不是关键词查询。比如你去搜苹果系统不可能给到你iPhone手机的当向量库可以将他搜出来于是大家就开始兴奋了。这似乎意味着我们从关键词查询进入了语义查询了另一方面早期模型能力不行单词上下文也就几千Token而主流的文本embedding模型最佳编码长度也就500左右256-768 tokens最近也有提升到了8000左右Tokens的太短了可能信息不足embedding表达不完整匹配不上太长单个向量需要概括的信息过多可能稀释核心语义难以在相似性搜索中被选择这是“信息淹没”这还正好跟模型上下文还对上了于是乎向量库在早期的RAG系统几乎是标配并且Coze、Dify、N8N等Agent低代码平台都是默认带上了向量库的这进一步给很多不明真相群众造成了烟雾弹效应但真正使用过程中大家又发现了好像玩不转最主要的问题就是断章取义要明白这是什么就需要简单做展开unsetunset传统RAGunsetunset传统向量库构建知识库的底层逻辑是很粗糙的**切分Chunking**把一整段文档直接丢给向量库然后开始无脑分块**向量化Embedding**把这些块映射成高维空间里的坐标**检索Retrieval**当用户问问题时去找空间里距离最近的几个chunk**拼凑Prompting**把这几个chunk塞给大模型说“来信息都给你了把完整文档该给我了”如果原始文档过长而每段分块内容又是不可控的这里就会导致很多问题最经典的就是上下文割裂文档分块的时候对原文的完整性进行了破坏比如表格阶段、论证逻辑切断最终结果是信息丢失比如以下案例电商“退款助手”场景用户问“多久到账”。RAG 只召回主条款“T1”把下一块的“黑名单/已发货订单除外”没带进来助手回答“一律T1”这可能导致高风险订单被误退款。更恐怖的是医疗或者法律场景比如将临床指南按段落切分导致降压药“适用症”与关键的“妊娠期禁用”提示被分隔在不同向量块。医生在审方时询问“孕妇高血压能否使用某某地平”系统如果仅检索到并返回了“适用症”信息块生成的结果显示“该药可用于治疗高血压”这存在严重安全隐患。于是乎大家逐渐发现一个问题什么JB语义检索还是关键词检索靠谱于是乎向量库其实在后来模型进步后上下文越来越长一直是个非常尴尬的存在。但如果非要把这些锅丢全部给向量库也不大合适因为RAG效果不行多半是大家想偷懒数据处理包括切分没做好的缘故…因为大家最后终于发现了语义相似也只能解决部分问题我们需要完整的数据关系来表征真实的世界说人话就是我们不止要数据我们还要关系比如你说到苹果我们要根据上下文自动带出iPhone还需要连带带出乔布斯等数据到这里才引出今天的主角知识图谱其实复杂的AI知识库用的多半是伪知识图谱技术这里会同时涉及到关键词、向量库检索等。unsetunset知识图谱unsetunset知识图谱和知识库非常相似可以说**知识图谱是知识库的一种有机表现形式。**在逻辑上知识库通过关系链的建立也能够形成图谱结构。具体来说知识库是对各种知识的组织、存储和管理而知识图谱则是在此基础上通过图的结构实体、关系和属性来呈现知识的内在联系和结构。知识图谱通常包括三大元素**实体Entities**即图中的节点代表真实世界中的事物、概念等如人、地点、物品、概念、类别。**关系Relations**实体之间的连接或联系描述实体之间的互动。**属性Attributes**描述实体或关系的特征信息如一个实体的具体属性值。通过这种标准化的表示形式知识图谱不仅能够展示实体之间的关联还能够进行语义分析帮助计算机理解和推理这些关系。它为我们提供了一种更加直观、结构化的方式来管理和呈现知识库中的信息。更粗暴的理解可以是图谱就是强制将知识库按照实体、关系、属性的标准做结构化两者间界限很模糊为方便理解给一个案例首先是没有关系的知识库疾病: { 名称: 糖尿病, 类型: 慢性疾病, 并发症: [心血管疾病, 肾脏病, 神经损伤]}症状: [ { 名称: 口渴, 常见疾病: 糖尿病 }, { 名称: 频繁排尿, 常见疾病: 糖尿病 }, { 名称: 体重下降, 常见疾病: 糖尿病 }, { 名称: 疲劳, 常见疾病: 糖尿病 }]药物: { 名称: 胰岛素, 类型: 药物, 用途: 控制血糖, 使用方法: 注射}然后是有关系的知识图谱实体: [ 疾病(糖尿病): { 类型: 慢性疾病 }, 并发症(心血管疾病): {}, 并发症(肾脏病): {}, 并发症(神经损伤): {}, 症状(口渴): { 常见疾病: 糖尿病 }, 症状(频繁排尿): { 常见疾病: 糖尿病 }, 症状(体重下降): { 常见疾病: 糖尿病 }, 症状(疲劳): { 常见疾病: 糖尿病 }, 药物(胰岛素): { 类型: 药物, 用途: 控制血糖, 使用方法: 注射 }]关系: [ (疾病(糖尿病) - 表现为 - 症状(口渴)), (疾病(糖尿病) - 表现为 - 症状(频繁排尿)), (疾病(糖尿病) - 表现为 - 症状(体重下降)), (疾病(糖尿病) - 表现为 - 症状(疲劳)), (疾病(糖尿病) - 引发 - 并发症(心血管疾病)), (疾病(糖尿病) - 引发 - 并发症(肾脏病)), (疾病(糖尿病) - 引发 - 并发症(神经损伤)), (疾病(糖尿病) - 治疗 - 药物(胰岛素))]PS上述只是为了便于各位理解图谱是什么真实的情况会更复杂但大体是这么个意思比如常见的贝叶斯预测P(糖尿病|多饮多尿) P(多饮|糖尿病) x P(多尿|糖尿病) x P(糖尿病) / P(多饮多尿)在大模型时代当前模型对于根据症状推导常见疾病已经非常擅长但是依旧会由于幻觉有各种问题这里知识图谱的意义就来了输入咳嗽 呼吸急促 发热 胸痛图谱推理路径症状 → 咳嗽、呼吸急促、发热、胸痛症状 → [常见疾病类别] → 呼吸系统疾病可能的疾病肺炎、支气管炎、慢性阻塞性肺疾病COPD进一步筛查 → [检查指标] → 血氧饱和度、白细胞计数、胸部影像如果胸部影像显示肺部浸润阴影高度怀疑肺炎或肺结核影像学特征差异 → [不同疾病影像学差异] → 肺炎浸润阴影 vs 肺结核钙化灶若影像学表现为浸润阴影进一步考虑细菌性肺炎最终诊断 → [关联知识库] → 确定细菌性肺炎可能性若有相关临床史如吸烟史、基础疾病可能进一步确定为慢性阻塞性肺疾病合并肺炎。综上大模型其实就是我们所谓的快思考而知识图谱知识库就是我们所谓的慢思考了在快慢结合下医疗AI的答案将更为靠谱。unsetunset知识图谱 → CDSSunsetunset医疗是知识图谱最经典的场景而大模型出现之前最经典的图谱类产品是CDSSClinical Decision Support System临床决策支持系统是一种为辅助医疗专业人员做出临床决策的AI技术产品。因为AI辅助诊断的需求一直存在所以前些年一直有机构在做CDSS的尝试比如IBM Watson就投入了大量资源但最终却以失败告终现在回过头来看看其价值和失败的原因可能为后续的AI应用研发提供一些中肯的建议。CDSS的核心原理CDSS的核心原理之一是基于规则的推理这种方法依赖于大量由领域专家医生手工输入的规则和知识库。每条规则通常以“如果…则…”的形式存在系统通过这些规则对患者的症状、检查结果等信息进行分析给出相应的建议。例如如果患者有发热、咳嗽和气促的症状那么该患者可能感染了呼吸道疾病如果患者的血糖水平持续超过某个阈值可能需要调整糖尿病治疗方案以上的所有规则便形成了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 表结构其实更深一步来说其差异是认知的差异或者说点状或网状传统的知识库以表分类知识 传统知识库如同中药房的百子柜每个抽屉数据库表存放着严格分类的知识**疾病表**ICD-11编码、标准名称、所属科室**药品表**化学名、适应症、禁忌证**症状表**标准化描述、关联器官这种结构的致命缺陷在2020年新冠疫情中暴露无遗当患者同时出现发热、腹泻、味觉丧失时系统无法自主发现这些跨科室症状的新型关联模式。其实这里疾病和症状表之间可以通过多重关系表如症状与疾病的“表现为”关系建立更多动态的联接这能更好地发现症状之间的组合关联模式。但即便如此这种关系依然是预先定义好的。这里的意思是知识库 关系表在已知关系的场景中可以满足大部分需求尤其是在数据结构比较明确且稳定的情况下。而知识图谱的核心优势是**开放系统的可扩展性以及它能够应对更加动态、复杂和未知的情况**举个例子二甲双胍的案例二甲双胍是治疗2型糖尿病的一zhong药物但我们发现长期服用后体重可能下降可能通过抑制肝糖异生、改善胰岛素敏感性间接影响脂肪代谢在非糖尿病人群中也可能产生代谢调节作用这类跨领域的关联关系在传统医学知识库中往往缺失因为不是糖尿病治疗重点所以一般不会存在但知识图谱可以低成本扩展。假设某医学数据库的结构如下当需要添加【二甲双胍→减肥】关系时需要修改数据库模式新增字段或关联表需临床指南明确认可该用途才能入库无法表达间接作用机制如通过AMPK通路影响代谢PS从这里也可以看出来图谱的存在其实是为了解决工程维护问题但以上问题在知识图谱规则中就比较简单了当新研究发现时只需添加三元组以上算是产品视角层面图谱与知识库的核心差异。生成手段传统知识库通常由**权威专家至少会有专家校验**手工录入数据所有信息都经过严格审核确保每条记录都能追溯到权威文献顶级期刊或临床指南最差也得是教材。这种方式使得数据具有高度的准确性和权威性便于医生查证数据的来源提高医疗决策时的信心。知识图谱的话除了从结构化的数据比如知识库生成外还会从非结构化数据比如文章、文献、网页甚至影像等提取关系和实体。毕竟舒服的工作是他自己就将结构提取好了比如之前我们研究的阿里KAG框架可以直接提取我文章形成图谱《第一节经理的能力模型》现在公众号不允许外链我这里就不发出来了PS只不过实际提取的还不太好现在也没太更新总之不好用…医疗置信度在当前医疗大模型产品中溯源可追溯性和医疗置信度是至关重要的因为它们直接关系到诊断决策的安全性和可靠性。指能够追踪每一条信息的来源从原始文献、临床指南、专家共识到数据采集的具体过程。溯源性越高医生越能确信系统给出的结论有明确的依据从而在临床决策中更有信心使用这些数据。只要医疗信息可溯源加之算法清晰合理其医疗置信度自然就高了。综上图谱与知识库各有优劣但大家也不必纠结一起使用就好其实可以看出图谱会更适应于大模型时代的搜索使用。至此进入今天的正题知识图谱大模型提升解决医疗幻觉问题unsetunset图谱LLMunsetunset如上所述AI1.0时代的CDSS根本无法满足医生的基本使用而大模型时代的DeepSeek依旧在模型幻觉等问题上让医疗人员犹豫不决比如以下案例在急诊分诊、手术抢救等情境下错误的诊断不仅会延误治疗还可能使患者失去最佳抢救时机极大地危及生命。因此降低大模型幻觉风险、提高生成答案的可信度成为关键任务。而知识图谱结合大模型的使用会是解决模型幻觉乃至增强医疗置信度的有效手段PS这类应用其实有很多比如前面所述的KAG乃至GraphRAG由微软研究院开发的一种新型检索增强生成框架它旨在利用知识图谱和大型语言模型来提升信息处理和问答能力。医疗置信度的四个维度为了保证诊断建议的准确性和临床安全性我们需要考虑四个维度数据溯源。 每条诊断结论都应能追溯到权威指南、临床文献和历史病历数据。只有明确溯源医生才能信任系统的判断。一致性。 综合患者的主诉、检查数据、影像资料等多方面信息确保不同数据源之间推理结果的一致性。多模态一致性有助于消除单一数据带来的偏差。动态性。 系统必须能够实时更新根据最新的医学研究和临床指南动态调整诊疗路径。动态适配确保了诊断建议始终反映最新临床证据。可解释推理链。 生成的答案应附带详细的推理链和证据来源让医生了解每一步判断的依据从而对系统的决策过程有充分信任。医学知识结构化医疗知识图谱可以形成一张庞大的知识网络。例如对于2型糖尿病通过这种结构化方式系统可以明确展示各医学实体之间的因果和关联关系形成完整的知识链条。这样在实际诊断过程中知识图谱不仅能提供丰富的背景知识还能对大模型的生成过程进行实时约束从而降低幻觉风险。并且图谱的更新速度可以很快以进一步保障医疗的及时性。unsetunset图谱RAGunsetunset在实际应用中将知识图谱与RAG技术结合可以构建一个多层次的诊断体系该系统通过路由、查询规划形成了一个自上而下的三层防御体系确保生成答案具有置信度和可解释性在此架构中系统首先对输入问题进行初步判断对于简单、标准的查询直接由RAG基础层处理而对于复杂、多模态或涉及实体关系的问题则交由图谱推理层进一步分析。无论哪种路径最终结果都经过置信度验证当系统置信度超过预设阈值如90%时直接输出否则提交专家复核。以下是通过知识图谱实现对复杂问题的结构化推理案例为了更直观展示知识图谱LLM对提高医疗置信度的效果下面通过三个层次的案例进行对比分析以下是基本输入一、大模型无RAG技术二、大模型RAG这里的输出其实已经不错了只不过组装的信息缺少逻辑性。二、大模型图谱RAG这种在输出前结合CoT的功能再集合溯源的功能医生还不被迷得死死的…本体论聊到图谱就不得不提最近一个偶尔被提起的新词本体论Ontology。所谓本体论如果放到 AI 知识系统中他核心想要做的事是去表述这个世界应该被如何定义要注意这个世界可以很小。所以图谱更像一张网本体论可以是这张网背后的建模逻辑从这里就可以看出他们的关联性很大了这也是为什么本体论做完了看上去和图谱差不多的原因这里大家可能看不懂我们继续回归前面CDSS相关案例我们不能随便把发热、肺炎、抗生素、白细胞升高都等价为图谱上的节点因为这些东西根本不是同一类对象发热是症状肺炎是疾病抗生素是药物类别白细胞升高是检查结果细菌感染可能是病因用药禁忌又属于约束条件。本体论的价值在于它先定义清楚几件事实体类型是什么疾病、症状、药物、检查、指南、禁忌证、适应证实体之间允许什么关系疾病表现为症状药物治疗疾病药物禁用于某类人群关系的语义强度是什么是因果、相关、并发、风险提示还是弱关联推理规则是什么哪些关系可以传递哪些关系不能传递哪些结论必须结合证据等级。举个简单例子二甲双胍 —— 治疗 —— 2型糖尿病二甲双胍 —— 可能导致 —— 体重下降二甲双胍 —— 通过AMPK通路影响 —— 代谢调节这三条关系都是对的但它们的医学含义完全不同第一条是明确适应证置信度高第二条是临床观察或副作用层面的关联第三条是作用机制层面的解释。如果没有本体论系统可能会把它们粗暴理解成二甲双胍可以减肥这显然是不对的。这就回到了知识图谱的问题了图谱这个技术本身是没有KnowHow的也就是是我们这批不懂医学的程序员做出来的但我们做出来的东西肯定会存在很多问题其中最重要的就是这个领域里的知识应该按照什么规则被理解这也是为什么医疗、法律、金融这类高风险行业不能只靠大模型自动抽取三元组就完事大模型可以帮我们提高抽取效率但本体论决定了这些抽取结果能不能被正确使用。说到底关系千千万我们需要的逻辑是什么这个反而最重要。这里我下个结论本体论是让知识图谱具备行业 KnowHow 的建模规则…unsetunset结语unsetunset最后总结一下向量库从来都不是RAG必须的选择他的问题很大它将知识压缩为孤立的“点”这种所谓语义检索是很脆弱的。相应的知识图谱的“回归”则是对知识本质的回应**它不满足于点与线的偶然关联而是着力构建实体、属性和关系的确定网络。**它带来的不是“更像”而是“更相关”与“更可信”通过可解释的逻辑链将检索从概率匹配提升到关系推理。事实上做过复杂AI知识库业务的同学会理解伪知识图谱就是CoT本身了。最后工程实践也正在走向务实与融合但依旧有很多问题需要处理其中最大的问题是人们很“懒惰”他们并不想去处理烦躁的数据。于是乎市面上也出了很多自动数据处理的框架比如PageIndex他通过层级化、结构化的索引检索可以变为先定位、后精读的“规划-取证”流程。向量库在此体系中作用是处理模糊问法的补充工具这可能才是他真正需要去到的角色。真实的系统往往是关键词、规则路由、向量检索与图谱查询的混合体。这里再说下下阶段的可能未来的AI知识系统或许将不再显式区分这些组件而是将其内化为自主规划、多步推理、自我校验的Agent能力。从“检索增强”走向“推理增强”让机器不仅找到片段更能理解因果最终交付确信的答案。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
在最初做RAG系统的时候有个几乎绑定的名词向量库。所以他是什么呢应该说向量库是一个理论上很美好的名词他是一类用于存储和检索向量的数据系统这里有两点要注意向量embedding可以将一段文本、图片、音频等内容通过embedding模型编码成一个高维数组检索现在拿着一个查询向量理想情况下向量库可以快速找到最相似的Top-K条类目这里可以带上原文片段等信息所以向量库找的是语义相近而不是关键词查询。比如你去搜苹果系统不可能给到你iPhone手机的当向量库可以将他搜出来于是大家就开始兴奋了。这似乎意味着我们从关键词查询进入了语义查询了另一方面早期模型能力不行单词上下文也就几千Token而主流的文本embedding模型最佳编码长度也就500左右256-768 tokens最近也有提升到了8000左右Tokens的太短了可能信息不足embedding表达不完整匹配不上太长单个向量需要概括的信息过多可能稀释核心语义难以在相似性搜索中被选择这是“信息淹没”这还正好跟模型上下文还对上了于是乎向量库在早期的RAG系统几乎是标配并且Coze、Dify、N8N等Agent低代码平台都是默认带上了向量库的这进一步给很多不明真相群众造成了烟雾弹效应但真正使用过程中大家又发现了好像玩不转最主要的问题就是断章取义要明白这是什么就需要简单做展开unsetunset传统RAGunsetunset传统向量库构建知识库的底层逻辑是很粗糙的**切分Chunking**把一整段文档直接丢给向量库然后开始无脑分块**向量化Embedding**把这些块映射成高维空间里的坐标**检索Retrieval**当用户问问题时去找空间里距离最近的几个chunk**拼凑Prompting**把这几个chunk塞给大模型说“来信息都给你了把完整文档该给我了”如果原始文档过长而每段分块内容又是不可控的这里就会导致很多问题最经典的就是上下文割裂文档分块的时候对原文的完整性进行了破坏比如表格阶段、论证逻辑切断最终结果是信息丢失比如以下案例电商“退款助手”场景用户问“多久到账”。RAG 只召回主条款“T1”把下一块的“黑名单/已发货订单除外”没带进来助手回答“一律T1”这可能导致高风险订单被误退款。更恐怖的是医疗或者法律场景比如将临床指南按段落切分导致降压药“适用症”与关键的“妊娠期禁用”提示被分隔在不同向量块。医生在审方时询问“孕妇高血压能否使用某某地平”系统如果仅检索到并返回了“适用症”信息块生成的结果显示“该药可用于治疗高血压”这存在严重安全隐患。于是乎大家逐渐发现一个问题什么JB语义检索还是关键词检索靠谱于是乎向量库其实在后来模型进步后上下文越来越长一直是个非常尴尬的存在。但如果非要把这些锅丢全部给向量库也不大合适因为RAG效果不行多半是大家想偷懒数据处理包括切分没做好的缘故…因为大家最后终于发现了语义相似也只能解决部分问题我们需要完整的数据关系来表征真实的世界说人话就是我们不止要数据我们还要关系比如你说到苹果我们要根据上下文自动带出iPhone还需要连带带出乔布斯等数据到这里才引出今天的主角知识图谱其实复杂的AI知识库用的多半是伪知识图谱技术这里会同时涉及到关键词、向量库检索等。unsetunset知识图谱unsetunset知识图谱和知识库非常相似可以说**知识图谱是知识库的一种有机表现形式。**在逻辑上知识库通过关系链的建立也能够形成图谱结构。具体来说知识库是对各种知识的组织、存储和管理而知识图谱则是在此基础上通过图的结构实体、关系和属性来呈现知识的内在联系和结构。知识图谱通常包括三大元素**实体Entities**即图中的节点代表真实世界中的事物、概念等如人、地点、物品、概念、类别。**关系Relations**实体之间的连接或联系描述实体之间的互动。**属性Attributes**描述实体或关系的特征信息如一个实体的具体属性值。通过这种标准化的表示形式知识图谱不仅能够展示实体之间的关联还能够进行语义分析帮助计算机理解和推理这些关系。它为我们提供了一种更加直观、结构化的方式来管理和呈现知识库中的信息。更粗暴的理解可以是图谱就是强制将知识库按照实体、关系、属性的标准做结构化两者间界限很模糊为方便理解给一个案例首先是没有关系的知识库疾病: { 名称: 糖尿病, 类型: 慢性疾病, 并发症: [心血管疾病, 肾脏病, 神经损伤]}症状: [ { 名称: 口渴, 常见疾病: 糖尿病 }, { 名称: 频繁排尿, 常见疾病: 糖尿病 }, { 名称: 体重下降, 常见疾病: 糖尿病 }, { 名称: 疲劳, 常见疾病: 糖尿病 }]药物: { 名称: 胰岛素, 类型: 药物, 用途: 控制血糖, 使用方法: 注射}然后是有关系的知识图谱实体: [ 疾病(糖尿病): { 类型: 慢性疾病 }, 并发症(心血管疾病): {}, 并发症(肾脏病): {}, 并发症(神经损伤): {}, 症状(口渴): { 常见疾病: 糖尿病 }, 症状(频繁排尿): { 常见疾病: 糖尿病 }, 症状(体重下降): { 常见疾病: 糖尿病 }, 症状(疲劳): { 常见疾病: 糖尿病 }, 药物(胰岛素): { 类型: 药物, 用途: 控制血糖, 使用方法: 注射 }]关系: [ (疾病(糖尿病) - 表现为 - 症状(口渴)), (疾病(糖尿病) - 表现为 - 症状(频繁排尿)), (疾病(糖尿病) - 表现为 - 症状(体重下降)), (疾病(糖尿病) - 表现为 - 症状(疲劳)), (疾病(糖尿病) - 引发 - 并发症(心血管疾病)), (疾病(糖尿病) - 引发 - 并发症(肾脏病)), (疾病(糖尿病) - 引发 - 并发症(神经损伤)), (疾病(糖尿病) - 治疗 - 药物(胰岛素))]PS上述只是为了便于各位理解图谱是什么真实的情况会更复杂但大体是这么个意思比如常见的贝叶斯预测P(糖尿病|多饮多尿) P(多饮|糖尿病) x P(多尿|糖尿病) x P(糖尿病) / P(多饮多尿)在大模型时代当前模型对于根据症状推导常见疾病已经非常擅长但是依旧会由于幻觉有各种问题这里知识图谱的意义就来了输入咳嗽 呼吸急促 发热 胸痛图谱推理路径症状 → 咳嗽、呼吸急促、发热、胸痛症状 → [常见疾病类别] → 呼吸系统疾病可能的疾病肺炎、支气管炎、慢性阻塞性肺疾病COPD进一步筛查 → [检查指标] → 血氧饱和度、白细胞计数、胸部影像如果胸部影像显示肺部浸润阴影高度怀疑肺炎或肺结核影像学特征差异 → [不同疾病影像学差异] → 肺炎浸润阴影 vs 肺结核钙化灶若影像学表现为浸润阴影进一步考虑细菌性肺炎最终诊断 → [关联知识库] → 确定细菌性肺炎可能性若有相关临床史如吸烟史、基础疾病可能进一步确定为慢性阻塞性肺疾病合并肺炎。综上大模型其实就是我们所谓的快思考而知识图谱知识库就是我们所谓的慢思考了在快慢结合下医疗AI的答案将更为靠谱。unsetunset知识图谱 → CDSSunsetunset医疗是知识图谱最经典的场景而大模型出现之前最经典的图谱类产品是CDSSClinical Decision Support System临床决策支持系统是一种为辅助医疗专业人员做出临床决策的AI技术产品。因为AI辅助诊断的需求一直存在所以前些年一直有机构在做CDSS的尝试比如IBM Watson就投入了大量资源但最终却以失败告终现在回过头来看看其价值和失败的原因可能为后续的AI应用研发提供一些中肯的建议。CDSS的核心原理CDSS的核心原理之一是基于规则的推理这种方法依赖于大量由领域专家医生手工输入的规则和知识库。每条规则通常以“如果…则…”的形式存在系统通过这些规则对患者的症状、检查结果等信息进行分析给出相应的建议。例如如果患者有发热、咳嗽和气促的症状那么该患者可能感染了呼吸道疾病如果患者的血糖水平持续超过某个阈值可能需要调整糖尿病治疗方案以上的所有规则便形成了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 表结构其实更深一步来说其差异是认知的差异或者说点状或网状传统的知识库以表分类知识 传统知识库如同中药房的百子柜每个抽屉数据库表存放着严格分类的知识**疾病表**ICD-11编码、标准名称、所属科室**药品表**化学名、适应症、禁忌证**症状表**标准化描述、关联器官这种结构的致命缺陷在2020年新冠疫情中暴露无遗当患者同时出现发热、腹泻、味觉丧失时系统无法自主发现这些跨科室症状的新型关联模式。其实这里疾病和症状表之间可以通过多重关系表如症状与疾病的“表现为”关系建立更多动态的联接这能更好地发现症状之间的组合关联模式。但即便如此这种关系依然是预先定义好的。这里的意思是知识库 关系表在已知关系的场景中可以满足大部分需求尤其是在数据结构比较明确且稳定的情况下。而知识图谱的核心优势是**开放系统的可扩展性以及它能够应对更加动态、复杂和未知的情况**举个例子二甲双胍的案例二甲双胍是治疗2型糖尿病的一zhong药物但我们发现长期服用后体重可能下降可能通过抑制肝糖异生、改善胰岛素敏感性间接影响脂肪代谢在非糖尿病人群中也可能产生代谢调节作用这类跨领域的关联关系在传统医学知识库中往往缺失因为不是糖尿病治疗重点所以一般不会存在但知识图谱可以低成本扩展。假设某医学数据库的结构如下当需要添加【二甲双胍→减肥】关系时需要修改数据库模式新增字段或关联表需临床指南明确认可该用途才能入库无法表达间接作用机制如通过AMPK通路影响代谢PS从这里也可以看出来图谱的存在其实是为了解决工程维护问题但以上问题在知识图谱规则中就比较简单了当新研究发现时只需添加三元组以上算是产品视角层面图谱与知识库的核心差异。生成手段传统知识库通常由**权威专家至少会有专家校验**手工录入数据所有信息都经过严格审核确保每条记录都能追溯到权威文献顶级期刊或临床指南最差也得是教材。这种方式使得数据具有高度的准确性和权威性便于医生查证数据的来源提高医疗决策时的信心。知识图谱的话除了从结构化的数据比如知识库生成外还会从非结构化数据比如文章、文献、网页甚至影像等提取关系和实体。毕竟舒服的工作是他自己就将结构提取好了比如之前我们研究的阿里KAG框架可以直接提取我文章形成图谱《第一节经理的能力模型》现在公众号不允许外链我这里就不发出来了PS只不过实际提取的还不太好现在也没太更新总之不好用…医疗置信度在当前医疗大模型产品中溯源可追溯性和医疗置信度是至关重要的因为它们直接关系到诊断决策的安全性和可靠性。指能够追踪每一条信息的来源从原始文献、临床指南、专家共识到数据采集的具体过程。溯源性越高医生越能确信系统给出的结论有明确的依据从而在临床决策中更有信心使用这些数据。只要医疗信息可溯源加之算法清晰合理其医疗置信度自然就高了。综上图谱与知识库各有优劣但大家也不必纠结一起使用就好其实可以看出图谱会更适应于大模型时代的搜索使用。至此进入今天的正题知识图谱大模型提升解决医疗幻觉问题unsetunset图谱LLMunsetunset如上所述AI1.0时代的CDSS根本无法满足医生的基本使用而大模型时代的DeepSeek依旧在模型幻觉等问题上让医疗人员犹豫不决比如以下案例在急诊分诊、手术抢救等情境下错误的诊断不仅会延误治疗还可能使患者失去最佳抢救时机极大地危及生命。因此降低大模型幻觉风险、提高生成答案的可信度成为关键任务。而知识图谱结合大模型的使用会是解决模型幻觉乃至增强医疗置信度的有效手段PS这类应用其实有很多比如前面所述的KAG乃至GraphRAG由微软研究院开发的一种新型检索增强生成框架它旨在利用知识图谱和大型语言模型来提升信息处理和问答能力。医疗置信度的四个维度为了保证诊断建议的准确性和临床安全性我们需要考虑四个维度数据溯源。 每条诊断结论都应能追溯到权威指南、临床文献和历史病历数据。只有明确溯源医生才能信任系统的判断。一致性。 综合患者的主诉、检查数据、影像资料等多方面信息确保不同数据源之间推理结果的一致性。多模态一致性有助于消除单一数据带来的偏差。动态性。 系统必须能够实时更新根据最新的医学研究和临床指南动态调整诊疗路径。动态适配确保了诊断建议始终反映最新临床证据。可解释推理链。 生成的答案应附带详细的推理链和证据来源让医生了解每一步判断的依据从而对系统的决策过程有充分信任。医学知识结构化医疗知识图谱可以形成一张庞大的知识网络。例如对于2型糖尿病通过这种结构化方式系统可以明确展示各医学实体之间的因果和关联关系形成完整的知识链条。这样在实际诊断过程中知识图谱不仅能提供丰富的背景知识还能对大模型的生成过程进行实时约束从而降低幻觉风险。并且图谱的更新速度可以很快以进一步保障医疗的及时性。unsetunset图谱RAGunsetunset在实际应用中将知识图谱与RAG技术结合可以构建一个多层次的诊断体系该系统通过路由、查询规划形成了一个自上而下的三层防御体系确保生成答案具有置信度和可解释性在此架构中系统首先对输入问题进行初步判断对于简单、标准的查询直接由RAG基础层处理而对于复杂、多模态或涉及实体关系的问题则交由图谱推理层进一步分析。无论哪种路径最终结果都经过置信度验证当系统置信度超过预设阈值如90%时直接输出否则提交专家复核。以下是通过知识图谱实现对复杂问题的结构化推理案例为了更直观展示知识图谱LLM对提高医疗置信度的效果下面通过三个层次的案例进行对比分析以下是基本输入一、大模型无RAG技术二、大模型RAG这里的输出其实已经不错了只不过组装的信息缺少逻辑性。二、大模型图谱RAG这种在输出前结合CoT的功能再集合溯源的功能医生还不被迷得死死的…本体论聊到图谱就不得不提最近一个偶尔被提起的新词本体论Ontology。所谓本体论如果放到 AI 知识系统中他核心想要做的事是去表述这个世界应该被如何定义要注意这个世界可以很小。所以图谱更像一张网本体论可以是这张网背后的建模逻辑从这里就可以看出他们的关联性很大了这也是为什么本体论做完了看上去和图谱差不多的原因这里大家可能看不懂我们继续回归前面CDSS相关案例我们不能随便把发热、肺炎、抗生素、白细胞升高都等价为图谱上的节点因为这些东西根本不是同一类对象发热是症状肺炎是疾病抗生素是药物类别白细胞升高是检查结果细菌感染可能是病因用药禁忌又属于约束条件。本体论的价值在于它先定义清楚几件事实体类型是什么疾病、症状、药物、检查、指南、禁忌证、适应证实体之间允许什么关系疾病表现为症状药物治疗疾病药物禁用于某类人群关系的语义强度是什么是因果、相关、并发、风险提示还是弱关联推理规则是什么哪些关系可以传递哪些关系不能传递哪些结论必须结合证据等级。举个简单例子二甲双胍 —— 治疗 —— 2型糖尿病二甲双胍 —— 可能导致 —— 体重下降二甲双胍 —— 通过AMPK通路影响 —— 代谢调节这三条关系都是对的但它们的医学含义完全不同第一条是明确适应证置信度高第二条是临床观察或副作用层面的关联第三条是作用机制层面的解释。如果没有本体论系统可能会把它们粗暴理解成二甲双胍可以减肥这显然是不对的。这就回到了知识图谱的问题了图谱这个技术本身是没有KnowHow的也就是是我们这批不懂医学的程序员做出来的但我们做出来的东西肯定会存在很多问题其中最重要的就是这个领域里的知识应该按照什么规则被理解这也是为什么医疗、法律、金融这类高风险行业不能只靠大模型自动抽取三元组就完事大模型可以帮我们提高抽取效率但本体论决定了这些抽取结果能不能被正确使用。说到底关系千千万我们需要的逻辑是什么这个反而最重要。这里我下个结论本体论是让知识图谱具备行业 KnowHow 的建模规则…unsetunset结语unsetunset最后总结一下向量库从来都不是RAG必须的选择他的问题很大它将知识压缩为孤立的“点”这种所谓语义检索是很脆弱的。相应的知识图谱的“回归”则是对知识本质的回应**它不满足于点与线的偶然关联而是着力构建实体、属性和关系的确定网络。**它带来的不是“更像”而是“更相关”与“更可信”通过可解释的逻辑链将检索从概率匹配提升到关系推理。事实上做过复杂AI知识库业务的同学会理解伪知识图谱就是CoT本身了。最后工程实践也正在走向务实与融合但依旧有很多问题需要处理其中最大的问题是人们很“懒惰”他们并不想去处理烦躁的数据。于是乎市面上也出了很多自动数据处理的框架比如PageIndex他通过层级化、结构化的索引检索可以变为先定位、后精读的“规划-取证”流程。向量库在此体系中作用是处理模糊问法的补充工具这可能才是他真正需要去到的角色。真实的系统往往是关键词、规则路由、向量检索与图谱查询的混合体。这里再说下下阶段的可能未来的AI知识系统或许将不再显式区分这些组件而是将其内化为自主规划、多步推理、自我校验的Agent能力。从“检索增强”走向“推理增强”让机器不仅找到片段更能理解因果最终交付确信的答案。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
