## 相关实体 - [Tcjndrk4Frmumngmboih W](https://github.com/QianJinGuo/wiki/blob/main/entities/tcjndrk4frmumngmboih-w.md) - [Google Workspace Updates Small Businesses Can Now Import Use](https://github.com/QianJinGuo/wiki/blob/main/entities/google-workspace-updates-small-businesses-can-now-import-use.md) - [Identity Behavior Context Itdr Solution](https://github.com/QianJinGuo/wiki/blob/main/entities/identity-behavior-context-itdr-solution.md) - [Openclaw Cloud Storage Config Guide Wechat](https://github.com/QianJinGuo/wiki/blob/main/entities/openclaw-cloud-storage-config-guide-wechat.md) - [Microsoft Is Quietly Shopping For An Openai Replac](https://github.com/QianJinGuo/wiki/blob/main/entities/microsoft-is-quietly-shopping-for-an-openai-replac.md) → [原文存档](https://github.com/QianJinGuo/wiki-book/tree/main/docs/raw/articles/PGpkC04XfF7ilMDb9vOcNQ.md) - [Gbrain 8Layer 51Cto](https://github.com/QianJinGuo/wiki/blob/main/entities/gbrain-8layer-51cto.md) - [实践教程真实Ai客服落地全流程意图识别混合检索到数据飞轮 V2](https://github.com/QianJinGuo/wiki/blob/main/entities/实践教程真实ai客服落地全流程意图识别混合检索到数据飞轮-v2.md) - [向量库是Rag的前菜知识图谱是答案本体论是灵魂 V2](https://github.com/QianJinGuo/wiki/blob/main/entities/向量库是rag的前菜知识图谱是答案本体论是灵魂-v2.md) ## 深度分析 1. **PDS是OpenClaw云端存储的核心基础设施**：网盘与相册服务（PDS）为OpenClaw提供云端文件存储能力，支持文件级权限管控和多空间隔离，是AI Agent访问云端文件的基础 2. **双重授权机制确保安全与灵活的平衡**：通过超级管理员绑定和可选的细粒度权限配置，OpenClaw可以在拥有足够能力的同时避免过度授权 3. **插件化集成实现无缝使用体验**：网盘功能以插件形式安装，通过自然语言对话即可调用各项能力，无需命令行操作 4. **多模态检索能力大幅扩展应用场景**：支持通过自然语言检索文档、图片和视频，实现跨格式的内容发现和理解 5. **客户端增强提供企业级文件管理特性**：可选安装网盘客户端，获得文件秒传、并发上传、带宽限制和同步备份等企业特性 ## 实践启示 1. **安全优先：使用专用低权限账号**：不要使用超级管理员账号授权OpenClaw，应创建一个具有基础预览/上传/下载权限的专用账号，以最小权限原则降低数据泄露风险 2. **容量规划：根据团队规模选择合适套餐**：网盘支持5~1000用户购买规格，购买前应根据实际使用人数和存储需求选择规格，并注意按包年包月计费 3. **效率提升：充分利用客户端特性**：安装网盘客户端后，可利用文件秒传避免重复上传，并发上传最多10个任务，以及同步备份功能保护本地文件 4. **测试验证：配置完成后进行功能测试**：配置完成后应测试文件查询、多模态检索和文件上传下载等核心功能，确保OpenClaw能正确访问网盘内容 5. **运维准备：提前了解升级卸载流程**：生产环境应提前了解插件升级和卸载命令（`openclaw plugins uninstall pds --force`），以便在出现问题时能快速回滚 --- ## Ch10.002 Identity Behavior Context Itdr Solution > 📊 Level ⭐ | 6.0KB | `entities/identity-behavior-context-itdr-solution.md` ## See exactly what every identity did, and why. Real-time behavior monitoring across humans, machines, and AI — with full session context, risk signals, and timeline clarity — to act in minutes, not hours.  WHAT YOU CAN'T SEE, YOU CAN'T STOP FRAGMENTED AUDIT LOGS NO CROSS-SYSTEM CONTEXT MANUAL LOG CORRELATION AI SESSIONS INVISIBLE ## 相关实体 - [Identity Behavior Context Itdr Solution Teleport](https://github.com/QianJinGuo/wiki/blob/main/entities/identity-behavior-context-itdr-solution-teleport.md) - [Harness Engineering Framework](https://github.com/QianJinGuo/wiki/blob/main/entities/harness-engineering-framework.md) - [Pgpkc04Xff7Ilmdb9Vocnq](https://github.com/QianJinGuo/wiki/blob/main/entities/pgpkc04xff7ilmdb9vocnq.md) - [Openclaw Cloud Storage Config Guide Wechat](https://github.com/QianJinGuo/wiki/blob/main/entities/openclaw-cloud-storage-config-guide-wechat.md) - [Microsoft Agent Framework Python Full Guide Zizhi](https://github.com/QianJinGuo/wiki/blob/main/entities/microsoft-agent-framework-python-full-guide-zizhi.md) → [原文存档](https://github.com/QianJinGuo/wiki-book/tree/main/docs/raw/articles/identity-behavior-context-itdr-solution.md) ## 深度分析 **统一身份链可见性是 ITDR 的核心差异化能力。** 传统安全运营中，身份日志分散在 Okta、AWS CloudTrail、GitHub、Kubernetes 等多个系统，安全团队需要手动关联拼凑才能还原一次完整的访问会话。Teleport 的方案将跨 IdP 的身份活动统一到单一时间线，关联来自 Okta 的认证事件、GitHub 的操作记录、AWS 的资源访问以及 Teleport 本身的 SSH/Kubernetes/Database 会话，实现"一个身份从登录到资源访问的完整链路"可见。这种统一视图将调查时间从小时级压缩到分钟级，是 ITDR 从"检测已知威胁"升级到"还原完整攻击叙事"的关键能力 。 **AI Agent 和 MCP 工具会话的审计盲区是现实威胁。** 当 AI Agent 通过 MCP 协议调用工具、查询数据库、操作云资源时，传统的 SIEM 和 audit log 无法记录这些行为——因为 AI Agent 使用的是 MCP 工具而非原生 API。Teleport 的方案将 AI Agent 的所有操作（prompts、queries、tool calls、data touched）纳入与人类和机器身份同等的审计框架，解决了 AI Native 时代身份安全最重要的盲区。Access Graph 的 Crown Jewels 监控可以标记 AI Agent 常访问的敏感资源，为 AI 权限滥用提供精准检测能力 。 **上下文驱动的检测与响应打破告警疲劳循环。** 传统 SIEM 规则依赖预定义的异常模式，但新威胁（如新型攻击向量、AI 驱动的权限滥用）往往无法被规则捕获。Teleport 的 50+ 身份漏洞类型检测（ privilege escalation、lateral movement、standing privileges、unmanaged keys 等）结合身份上下文（该身份通常访问什么、什么是异常）进行判断，显著提升检测准确性，减少误报。配合 1-Click Identity Lock，可以在检测到可疑行为时立即终止所有会话，而无需手动在 Okta、AWS、GitHub 等多个系统逐一撤销访问权限 。 **跨系统的 impossible travel 检测是差异化能力。** 大多数身份安全产品仅在单一 IdP（如 Okta）内检测不可能旅行——如果一个账号 10 分钟前在北京登录、10 分钟后在伦敦登录则触发告警。Teleport 将这一能力扩展到跨 GitHub、Okta 和 Teleport 三个系统的关联分析，这在多云和混合架构企业中更具现实意义——攻击者可能通过窃取的 GitHub token 横向移动到云资源，而不仅仅是非法登录一个 SaaS 应用 。 **Access Graph + SQL Editor 为平台工程师提供原生工作流。** 安全工具最大的敌人是工具不用。Teleport 没有要求安全分析师学习新的专有界面，而是提供 SQL Editor 让熟悉数据库查询的工程师用 SQL 探索身份到资源的访问关系，以及 Graph Explorer 进行可视化路径遍历。这种设计降低了工具采用门槛，使安全能力真正下沉到平台工程师日常工作流中 。 ## 实践启示 - **AI Agent 身份审计应优先落地。** AI Agent 使用 MCP 工具产生的会话记录是大多数安全工具的盲区，建议优先部署 Teleport 的 AI Session Recording 功能，建立 AI 行为的基线可见性，再逐步扩展到人类和机器身份的全面监控 。 - **用 Access Graph 清理过权限身份。** 部署后第一件事是用 Access Graph 扫描所有身份的权限分布，重点关注跨 1800 个 repo 持有 super-admin maintainer 权限的工程师账号这类场景——这些过权限身份是潜在攻击跳板，应通过 Access Request 机制改为按需临时授权 。 - **Anomaly Detection 需要基线学习期。** 50+ 身份漏洞检测需要先建立正常行为基线再开启告警，避免大量误报冲垮安全团队。建议在"观测模式"下运行 2-4 周，手动审查触发最多的检测类型，调整阈值后再切换到主动告警模式 。 - **1-Click Identity Lock 是应急响应核心能力。** 发生疑似账户被盗时，1-Click Identity Lock 应作为 Incident Response Playbook 的第一步——立即切断所有会话，再进行取证分析，比传统的手动逐一撤销更快速且不留遗漏。该功能支持按用户、角色、服务器、MFA 设备等维度精细锁定 。 - **与 SIEM/SOAR 的集成应作为第二阶段目标。** Teleport 支持通过 HTTP 将审计事件导出到 Splunk、Datadog、Elastic 和 Panther，同时支持 S3 长期存储配合 Amazon Athena 查询。建议在完成内部身份基线建设后，再配置 SIEM 集成将身份安全事件纳入企业级安全运营体系，避免核心能力尚未稳定时就引入过多外部依赖 。 --- ## Ch10.003 向量检索、知识图谱与 LLM Wiki：RAG 被嘲笑了三年，但企业还是离不开它 > 📊 Level ⭐ | 0.9KB | `entities/向量检索知识图谱与-llm-wikirag-被嘲笑了三年但企业还是离不开它-3.md` > -> [原文存档](https://github.com/QianJinGuo/wiki-book/tree/main/docs/raw/articles/向量检索知识图谱与-llm-wikirag-被嘲笑了三年但企业还是离不开它-3.md) RAG在网上已经死过很多遍了，谁用谁Low，但是实际上很多的企业知识库仍然在使用，并且依然是主流选择方案。 ## 来源 - 原文: [向量检索、知识图谱与 LLM Wiki：RAG 被嘲笑了三年，但企业还是离不开它](https://github.com/QianJinGuo/wiki-book/tree/main/docs/raw/articles/向量检索知识图谱与-llm-wikirag-被嘲笑了三年但企业还是离不开它-3.md) --- ## Ch10.004 向量检索、知识图谱与 LLM Wiki：RAG 被嘲笑了三年，但企业还是离不开它 > 📊 Level ⭐ | 0.9KB | `entities/向量检索知识图谱与-llm-wikirag-被嘲笑了三年但企业还是离不开它-2.md` > -> [原文存档](https://github.com/QianJinGuo/wiki-book/tree/main/docs/raw/articles/向量检索知识图谱与-llm-wikirag-被嘲笑了三年但企业还是离不开它-2.md) RAG在网上已经死过很多遍了，谁用谁Low，但是实际上很多的企业知识库仍然在使用，并且依然是主流选择方案。 ## 来源 - 原文: [向量检索、知识图谱与 LLM Wiki：RAG 被嘲笑了三年，但企业还是离不开它](https://github.com/QianJinGuo/wiki-book/tree/main/docs/raw/articles/向量检索知识图谱与-llm-wikirag-被嘲笑了三年但企业还是离不开它-2.md) --- ## Ch10.005 向量检索、知识图谱与 LLM Wiki：RAG 被嘲笑了三年，但企业还是离不开它 > 📊 Level ⭐ | 0.9KB | `entities/向量检索知识图谱与-llm-wikirag-被嘲笑了三年但企业还是离不开它-1.md` > -> [原文存档](https://github.com/QianJinGuo/wiki-book/tree/main/docs/raw/articles/向量检索知识图谱与-llm-wikirag-被嘲笑了三年但企业还是离不开它-1.md) RAG在网上已经死过很多遍了，谁用谁Low，但是实际上很多的企业知识库仍然在使用，并且依然是主流选择方案。 ## 来源 - 原文: [向量检索、知识图谱与 LLM Wiki：RAG 被嘲笑了三年，但企业还是离不开它](https://github.com/QianJinGuo/wiki-book/tree/main/docs/raw/articles/向量检索知识图谱与-llm-wikirag-被嘲笑了三年但企业还是离不开它-1.md) --- ## Ch10.006 图灵平台：万亿级轨迹数据的秒级检索实战 > 📊 Level ⭐ | 0.8KB | `entities/turing-platform-trillion-trajectory-retrieval-baidu-2026-07-22.md` > -> [原文存档](https://github.com/QianJinGuo/wiki-book/tree/main/docs/raw/articles/turing-platform-trillion-trajectory-retrieval-baidu-2026-07-22.md) - 底库：近 10 万亿轨迹点（180 天长尾低级路历史轨迹） ## 来源 - 原文: [图灵平台：万亿级轨迹数据的秒级检索实战](https://github.com/QianJinGuo/wiki-book/tree/main/docs/raw/articles/turing-platform-trillion-trajectory-retrieval-baidu-2026-07-22.md) - 原始链接: : "https://mp.weixin.qq.com/s/Nmgink4YE0KVu8dTuEplyg --- ## Ch10.007 高德广告工程的 AI Native 知识库体系 > 📊 Level ⭐ | 0.8KB | `entities/gaode-ad-engineering-ai-native-knowledge-base-2026-07-22.md` > -> [原文存档](https://github.com/QianJinGuo/wiki-book/tree/main/docs/raw/articles/gaode-ad-engineering-ai-native-knowledge-base-2026-07-22.md) | 接入层 | 统一知识入口，以 Skill 形态嵌入各类研发 Agent | ## 来源 - 原文: [高德广告工程的 AI Native 知识库体系](https://github.com/QianJinGuo/wiki-book/tree/main/docs/raw/articles/gaode-ad-engineering-ai-native-knowledge-base-2026-07-22.md) - 原始链接: : "https://mp.weixin.qq.com/s/1d9LDoD2SOcEZ19mDwiE-Q --- ## Ch10.008 Karpathy又封神！掀翻RAG，把你的笔记变成第二大脑 > 📊 Level ⭐ | 0.7KB | `entities/karpathy又封神掀翻rag把你的笔记变成第二大脑.md` > -> [原文存档](https://github.com/QianJinGuo/wiki-book/tree/main/docs/raw/articles/karpathy又封神掀翻rag把你的笔记变成第二大脑.md) source_url: https://mp.weixin.qq.com/s/G7Fna5qK20lFji4Lqx8GMA ## 来源 - 原文: [Karpathy又封神！掀翻RAG，把你的笔记变成第二大脑](https://github.com/QianJinGuo/wiki-book/tree/main/docs/raw/articles/karpathy又封神掀翻rag把你的笔记变成第二大脑.md) - 原始链接: : "https://mp.weixin.qq.com/s/G7Fna5qK20lFji4Lqx8GMA --- ## Ch10.009 向量库是RAG的前菜，知识图谱是答案，本体论是灵魂 > 📊 Level ⭐⭐ | 49.6KB | `entities/向量库是rag的前菜知识图谱是答案本体论是灵魂.md` [向量库是Rag的前菜知识图谱是答案本体论是灵魂](https://github.com/QianJinGuo/wiki-book/tree/main/docs/raw/articles/向量库是rag的前菜知识图谱是答案本体论是灵魂.md) > AI训练营9 ** 期 ** ，5 ** 月7日 ** 开班，欢迎咨询 在最初做RAG系统的时候有个几乎绑定的名词： ` 向量库 ` 。所以他是什么呢？ 应该说向量库是一个理论上很美好的名词，他是一类用于存储和检索向量的数据系统，这里有两点要注意： 1. ** 向量（embedding） ** ，可以将一段文本、图片、音频等内容，通过embedding模型编码成一个高维数组； 2. ** 检索 ** ，现在拿着一个查询向量，理想情况下向量库可以快速找到 ** 最相似的Top-K ** 条类目，这里可以带上原文片段等信息； 所以， ` 向量库找的是语义相近，而不是关键词查询。 ` 比如你去搜苹果，系统不可能给到你iPhone手机的，当向量库可以将他搜出来，于是大家就开始兴奋了。这似乎意味着： ` 我们从关键词查询进入了语义查询了！ ` 另一方面，早期模型能力不行，单词上下文也就几千Token，而主流的文本embedding模型最佳编码长度也就500左右（256-768 tokens，最近也有提升到了8000左右Tokens的）： 1. 太短了，可能信息不足，embedding表达不完整，匹配不上； 2. 太长，单个向量需要概括的信息过多，可能稀释核心语义，难以在相似性搜索中被选择，这是"信息淹没"； 这还正好跟模型上下文还对上了，于是乎向量库 ` 在早期 ` 的RAG系统几乎是标配，并且Coze、Dify、N8N等Agent低代码平台都是默认带上了向量库的，这进一步给很多不明真相群众造成了烟雾弹效应； 但真正使用过程中，大家又发现了好像玩不转，最主要的问题就是 ` 断章取义 ` ，要明白这是什么，就需要简单做展开： ## unset unset 传统RAG unset unset 传统向量库构建知识库的底层逻辑，是很粗糙的： 1. ** 切分（Chunking）： ** 把一整段文档直接丢给向量库，然后开始无脑分块； 2. ** 向量化（Embedding）： ** 把这些块映射成高维空间里的坐标； 3. ** 检索（Retrieval）： ** 当用户问问题时，去找空间里距离最近的几个chunk； 4. ** 拼凑（Prompting）： ** 把这几个chunk塞给大模型，说："来，信息都给你了，把完整文档该给我了"； 如果原始文档过长，而每段分块内容又是不可控的，这里就会导致很多问题，最经典的就是 ** 上下文割裂 ** ： 文档分块的时候对原文的完整性进行了破坏，比如表格阶段、论证逻辑切断，最终结果是信息丢失，比如以下案例： 电商"退款助手"场景，用户问"多久到账"。RAG 只召回主条款"T+1"，把下一块的"黑名单/已发货订单除外"没带进来，助手回答"一律T+1"，这可能导致高风险订单被误退款。 更恐怖的是医疗或者法律场景，比如将临床指南按段落切分，导致降压药"适用症"与关键的"妊娠期禁用"提示被分隔在不同向量块。 医生在审方时询问："孕妇高血压能否使用某某地平？"系统如果仅检索到并返回了"适用症"信息块，生成的结果显示"该药可用于治疗高血压"，这存在严重安全隐患。 于是乎，大家逐渐发现一个问题： ` 什么JB语义检索，还是关键词检索靠谱！ ` ，于是乎，向量库其实在后来模型进步后（ ** 上下文越来越长 ** ），一直是个非常尴尬的存在。 但如果非要把这些锅丢全部给向量库，也不大合适，因为RAG效果不行多半是 ` 大家想偷懒，数据处理（包括切分）没做好的缘故 ` ... 因为大家最后终于发现了： ` 语义相似也只能解决部分问题，我们需要完整的数据关系来表征真实的世界 ` ，说人话就是：我们不止要数据，我们还要关系，比如你说到苹果，我们要根据上下文自动带出iPhone，还需要连带带出乔布斯等数据； 到这里才引出今天的主角 ` 知识图谱 ` ，其实复杂的AI知识库，用的多半是 ` 伪知识图谱 ` 技术，这里会同时涉及到关键词、向量库检索等。 ## unset unset 知识图谱 unset unset 知识图谱和知识库非常相似，可以说 ** 知识图谱是知识库的一种有机表现形式。 ** 在逻辑上，知识库通过关系链的建立也能够形成图谱结构。 具体来说，知识库是对各种知识的组织、存储和管理，而知识图谱则是在此基础上通过图的结构（实体、关系和属性）来呈现知识的内在联系和结构。 知识图谱通常包括三大元素： 1. ** 实体（Entities）： ** 即图中的节点，代表真实世界中的事物、概念等（如人、地点、物品、概念、类别）。 2. ** 关系（Relations）： ** 实体之间的连接或联系，描述实体之间的互动。 3. ** 属性（Attributes）： ** 描述实体或关系的特征信息，如一个实体的具体属性值。 通过这种标准化的表示形式，知识图谱不仅能够展示实体之间的关联，还能够进行语义分析，帮助计算机理解和推理这些关系。 它为我们提供了一种更加直观、结构化的方式来管理和呈现知识库中的信息。 > 更粗暴的理解可以是： ** 图谱就是强制将知识库按照实体、关系、属性 ** 的标准做结构化，两者间界限很模糊 为方便理解给一个案例，首先是 ** 没有关系的知识库 ** ： 疾病: { 名称: "糖尿病", 类型: "慢性疾病", 并发症: ["心血管疾病", "肾脏病", "神经损伤"] } 症状: [ { 名称: "口渴", 常见疾病: "糖尿病" }, { 名称: "频繁排尿", 常见疾病: "糖尿病" }, { 名称: "体重下降", 常见疾病: "糖尿病" }, { 名称: "疲劳", 常见疾病: "糖尿病" } ] 药物: { 名称: "胰岛素", 类型: "药物", 用途: "控制血糖", 使用方法: "注射" } 然后是 ** 有关系的知识图谱： ** 实体: [ 疾病("糖尿病"): { 类型: "慢性疾病" }, 并发症("心血管疾病"): {}, 并发症("肾脏病"): {}, 并发症("神经损伤"): {}, 症状("口渴"): { 常见疾病: "糖尿病" }, 症状("频繁排尿"): { 常见疾病: "糖尿病" }, 症状("体重下降"): { 常见疾病: "糖尿病" }, 症状("疲劳"): { }, 药物("胰岛素"): { 类型: "药物", 用途: "控制血糖", 使用方法: "注射" } ] 关系: [ (疾病("糖尿病") - 表现为 -> 症状("口渴")), (疾病("糖尿病") - 表现为 -> 症状("频繁排尿")), (疾病("糖尿病") - 表现为 -> 症状("体重下降")), (疾病("糖尿病") - 表现为 -> 症状("疲劳")), (疾病("糖尿病") - 引发 -> 并发症("心血管疾病")), (疾病("糖尿病") - 引发 -> 并发症("肾脏病")), (疾病("糖尿病") - 引发 -> 并发症("神经损伤")), (疾病("糖尿病") - 治疗 -> 药物("胰岛素")) ] > PS：上述只是为了便于各位理解图谱是什么，真实的情况会更复杂，但大体是这么个意思 > > 比如常见的贝叶斯预测：P(糖尿病|多饮+多尿) = P(多饮|糖尿病) x P(多尿|糖尿病) x P(糖尿病) / P(多饮+多尿) 在大模型时代，当前模型对于 ** 根据症状推导常见疾病已经非常擅长 ** ，但是依旧会由于幻觉有各种问题，这里知识图谱的意义就来了： 输入：咳嗽 + 呼吸急促 + 发热 + 胸痛 图谱推理路径： 症状 → 咳嗽、呼吸急促、发热、胸痛 症状 → [常见疾病类别] → 呼吸系统疾病 可能的疾病：肺炎、支气管炎、慢性阻塞性肺疾病（COPD） 进一步筛查 → [检查指标] → 血氧饱和度、白细胞计数、胸部影像 如果胸部影像显示肺部浸润阴影，高度怀疑肺炎或肺结核 影像学特征差异 → [不同疾病影像学差异] → 肺炎（浸润阴影） vs 肺结核（钙化灶） 若影像学表现为浸润阴影，进一步考虑细菌性肺炎 最终诊断 → [关联知识库] → 确定细菌性肺炎可能性 若有相关临床史（如吸烟史、基础疾病），可能进一步确定为慢性阻塞性肺疾病合并肺炎。 综上，大模型其实就是我们所谓的快思考而知识图谱（知识库）就是我们所谓的慢思考了，在快慢结合下，医疗AI的答案将更为靠谱。 ## unset unset 知识图谱 → CDSS unset unset 医疗是知识图谱最经典的场景，而大模型出现之前最经典的图谱类产品是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的本质是医学知识库，更进一步可以衍生出一套 ** 医学知识图谱 ** ，这套图谱在之前由于 ** 泛化能力不足所以不好用 ** ，但在大模型时代技术鸿沟的问题被弥合了，所以知识图谱也就开始焕发新生了。 ## unset unset 图谱 VS 知识库 unset unset 从存储方式来说图谱区别于知识库的差异在于 ** 图结构 VS 表结构 ** ，其实更深一步来说，其差异是认知的差异，或者说点状或网状： 传统的知识库以表分类知识： 传统知识库如同中药房的百子柜，每个抽屉（数据库表）存放着严格分类的知识： 1. ** 疾病表： ** ICD-11编码、标准名称、所属科室； 2. ** 药品表： ** 化学名、适应症、禁忌证； 3. ** 症状表： ** 标准化描述、关联器官； 这种结构的致命缺陷在2020年新冠疫情中暴露无遗：当患者同时出现 ** 发热、腹泻、味觉丧失 ** 时，系统无法自主发现这些跨科室症状的新型关联模式。 其实这里疾病和症状表之间可以通过多重关系表（如症状与疾病的"表现为"关系）建立更多动态的联接，这能更好地发现症状之间的组合关联模式。 但即便如此，这种关系依然是 ** 预先定义好的 ** 。这里的意思是： ** 知识库 + 关系表在已知关系的场景中可以满足大部分需求，尤其是在数据结构比较明确且稳定的情况下。 ** 而知识图谱的核心优势是 ** 开放系统的可扩展性，以及它能够应对更加动态、复杂和未知的情况， ** 举个例子： ### 二甲双胍的案例 二甲双胍是治疗2型糖尿病的一zhong药物，但我们发现： 1. 长期服用后体重可能下降； 2. 可能通过抑制肝糖异生、改善胰岛素敏感性间接影响脂肪代谢； 3. 在非糖尿病人群中也可能产生代谢调节作用； 这类 ** 跨领域 ** 的关联关系在传统医学知识库中往往缺失，因为不是糖尿病治疗重点，所以一般不会存在，但知识图谱可以低成本扩展。 假设某医学数据库的结构如下： 当需要添加【二甲双胍→减肥】关系时： 1. 需要修改数据库模式（新增字段或关联表）； 2. 需临床指南明确认可该用途才能入库； 3. 无法表达间接作用机制（如通过AMPK通路影响代谢）； PS：从这里也可以看出来，图谱的存在其实是为了解决工程维护问题 但以上问题在知识图谱规则中就比较简单了： 当新研究发现时，只需添加三元组： 以上算是产品视角层面图谱与知识库的核心差异。 ### 生成手段 传统知识库通常由 ** 权威专家（至少会有专家校验） ** 手工录入数据，所有信息都经过严格审核，确保每条记录都能追溯到权威文献（顶级期刊）或临床指南（最差也得是教材）。 这种方式使得数据具有高度的准确性和权威性，便于医生查证数据的来源，提高医疗决策时的信心。 知识图谱的话除了从结构化的数据（比如知识库）生成外，还会从非结构化数据（比如文章、文献、网页甚至影像等）提取关系和实体。 毕竟舒服的工作是他自己就将结构提取好了，比如之前我们研究的阿里KAG框架，可以直接提取我文章形成图谱： 《第一节：经理的能力模型》（现在公众号不允许外链，我这里就不发出来了） > PS：只不过实际提取的还不太好，现在也没太更新，总之不好用... ### 医疗置信度 在当前医疗大模型产品中， ** 溯源（可追溯性）和医疗置信度 ** 是至关重要的，因为它们直接关系到诊断决策的安全性和可靠性。 指能够追踪每一条信息的来源，从原始文献、临床指南、专家共识到数据采集的具体过程。 溯源性越高，医生越能确信系统给出的结论有明确的依据，从而在临床决策中更有信心使用这些数据。 只要医疗信息可溯源，加之算法清晰合理，其医疗置信度自然就高了。 综上，图谱与知识库各有优劣但大家也不必纠结，一起使用就好， ** 其实可以看出，图谱会更适应于大模型时代的搜索使用 ** 。 至此进入今天的正题： ** 知识图谱+大模型提升解决医疗幻觉问题 ** ## unset unset 图谱+LLM unset unset 如上所述，AI1.0时代的CDSS根本无法满足医生的基本使用，而大模型时代的DeepSeek依旧在 ** 模型幻觉 ** 等问题上让医疗人员 ** 犹豫不决 ** ，比如以下案例： 在急诊分诊、手术抢救等情境下，错误的诊断不仅会延误治疗，还可能使患者失去最佳抢救时机，极大地危及生命。 因此， ** 降低大模型幻觉风险、提高生成答案的可信度成为关键任务。 ** > ** 而知识图谱结合大模型的使用会是解决模型幻觉乃至增强医疗置信度的有效手段 ** > > _ PS：这类应用其实有很多，比如前面所述的KAG乃至GraphRAG（由微软研究院开发的一种 ** 新型检索增强生成框架 ** ，它旨在利用知识图谱和大型语言模型来提升信息处理和问答能力）。 _ ### 医疗置信度的四个维度 为了保证诊断建议的准确性和临床安全性，我们需要考虑四个维度： 1. ** 数据溯源 ** 。 每条诊断结论都应能追溯到权威指南、临床文献和历史病历数据。只有明确溯源，医生才能信任系统的判断。 2. ** 一致性 ** 。 综合患者的主诉、检查数据、影像资料等多方面信息，确保不同数据源之间推理结果的一致性。多模态一致性有助于消除单一数据带来的偏差。 3. ** 动态性 ** 。 系统必须能够 ** 实时更新 ** ，根据最新的医学研究和临床指南动态调整诊疗路径。动态适配确保了诊断建议始终反映最新临床证据。 4. ** 可解释推理链 ** 。 生成的答案应附带详细的推理链和证据来源，让医生了解每一步判断的依据，从而对系统的决策过程有充分信任。 ### 医学知识结构化 医疗知识图谱可以形成一张庞大的知识网络。例如，对于2型糖尿病： 通过这种结构化方式，系统可以明确展示各医学实体之间的因果和关联关系，形成完整的知识链条。 这样，在实际诊断过程中，知识图谱不仅能提供丰富的背景知识，还能对大模型的生成过程进行实时约束，从而降低幻觉风险。 并且，图谱的更新速度可以很快，以进一步保障医疗的及时性。 ## unset unset 图谱+RAG unset unset 在实际应用中，将知识图谱与RAG技术结合，可以构建一个多层次的诊断体系： 该系统通过路由、查询规划，形成了一个自上而下的三层防御体系，确保生成答案具有置信度和可解释性： 在此架构中，系统首先对输入问题进行初步判断：对于简单、标准的查询直接由RAG基础层处理； 而对于复杂、多模态或涉及实体关系的问题，则交由图谱推理层进一步分析。 无论哪种路径，最终结果都经过置信度验证，当系统置信度超过预设阈值（如90%）时直接输出，否则提交专家复核。 以下是 ** 通过知识图谱实现对复杂问题的结构化推理 ** 案例： 为了更直观展示知识图谱+LLM对提高医疗置信度的效果，下面通过三个层次的案例进行对比分析，以下是基本输入： ** 一、大模型（无RAG技术） ** ** 二、大模型+RAG ** 这里的输出其实已经不错了，只不过组装的信息缺少逻辑性。 ** 二、大模型+图谱+RAG ** 这种在输出前结合CoT的功能，再集合溯源的功能，医生还不被迷得死死的... 本体论 聊到图谱就不得不提最近一个偶尔被提起的新词： 本体论，Ontology 。 所谓本体论，如果放到 AI 知识系统中，他核心想要做的事是， 去表述这个世界应该被如何定义，要注意，这个世界可以很小 。 所以，图谱更像一张网，本体论可以是这张网背后的建模逻辑，从这里就可以看出他们的关联性很大了，这也是为什么本体论做完了看上去和图谱差不多的原因： 这里大家可能看不懂，我们继续回归前面CDSS相关案例，我们不能随便把 发热、肺炎、抗生素、白细胞升高 ，都等价为图谱上的节点，因为这些东西根本不是同一类对象： * 发热是症状； * 肺炎是疾病； * 抗生素是药物类别； * 白细胞升高是检查结果； * 细菌感染可能是病因； * 用药禁忌又属于约束条件。 本体论的价值在于，它先定义清楚几件事： 1. ** 实体类型是什么： 疾病、症状、药物、检查、指南、禁忌证、适应证； ** 2. ** 实体之间允许什么关系： 疾病表现为症状，药物治疗疾病，药物禁用于某类人群； ** 3. ** 关系的语义强度是什么： 是因果、相关、并发、风险提示，还是弱关联； ** 4. ** 推理规则是什么： 哪些关系可以传递，哪些关系不能传递，哪些结论必须结合证据等级。 ** 举个简单例子： > 二甲双胍 —— 治疗 —— 2型糖尿病 > 二甲双胍 —— 可能导致 —— 体重下降 > 二甲双胍 —— 通过AMPK通路影响 —— 代谢调节 这三条关系都是对的，但它们的医学含义完全不同： * 第一条是明确适应证，置信度高； * 第二条是临床观察或副作用层面的关联； * 第三条是作用机制层面的解释。 如果没有本体论，系统可能会把它们粗暴理解成：二甲双胍可以减肥，这显然是不对的。 这就回到了知识图谱的问题了，图谱这个技术本身是没有KnowHow的，也就是是我们这批不懂医学的程序员做出来的，但我们做出来的东西肯定会存在很多问题，其中最重要的就是： 这个领域里的知识，应该按照什么规则被理解？ 这也是为什么医疗、法律、金融这类高风险行业，不能只靠大模型自动抽取三元组就完事， 大模型可以帮我们提高抽取效率，但本体论决定了这些抽取结果能不能被正确使用 。 说到底，关系千千万，我们需要的逻辑是什么，这个反而最重要。 这里我下个结论： 本体论是让知识图谱具备行业 KnowHow 的建模规则... ## unset unset 结语 unset unset 最后总结一下：向量库从来都不是RAG必须的选择，他的问题很大， ` 它将知识压缩为孤立的"点" ` ，这种所谓语义检索是很脆弱的。 相应的，知识图谱的"回归"，则是对知识本质的回应： ** 它不满足于点与线的偶然关联，而是着力构建实体、属性和关系的确定网络。 ** 它带来的不是"更像"，而是"更相关"与"更可信"，通过可解释的逻辑链，将检索从概率匹配提升到关系推理。 事实上做过复杂AI知识库业务的同学会理解： ` 伪知识图谱就是CoT本身了 ` 。 最后，工程实践也正在走向务实与融合，但依旧有很多问题需要处理，其中最大的问题是 ` 人们很"懒惰"，他们并不想去处理烦躁的数据 ` 。于是乎市面上也出了很多自动数据处理的框架，比如PageIndex： 他通过层级化、结构化的索引，检索可以变为先定位、后精读的"规划-取证"流程。 向量库在此体系中，作用是处理模糊问法的补充工具，这可能才是他真正需要去到的角色。 ` 真实的系统，往往是关键词、规则路由、向量检索与图谱查询的混合体。 ` 这里再说下下阶段的可能：未来的AI知识系统，或许将不再显式区分这些组件，而是将其内化为自主规划、多步推理、自我校验的Agent能力。从"检索增强"走向"推理增强"，让机器不仅找到片段，更能理解因果，最终交付确信的答案。 我反正看进来Google的NoteBookLLM表现是很不错的，他的技术路径可能是个方向。 好了，文章很长了，希望对大家有用！ ** 点击上方卡片关注叶小钗公众号 ** ## 深度分析 ### 向量库的局限性本质 向量库作为早期RAG的核心组件，其本质缺陷在于**将知识压缩为孤立的"语义点"**。这种处理方式存在三个根本性问题： 1. **上下文割裂**：Chunking过程中对原始文档完整性的破坏，导致关键信息被分隔 2. **信息淹没**：长文本的向量表示需要概括过多信息，稀释核心语义 3. **语义脆弱性**：依赖"语义相似性"而非"关系推理"，容易出现断章取义 向量库的衰落与模型上下文能力的增长呈负相关——当上下文窗口从4K扩展到128K甚至更高时，向量库的"折中"价值急剧下降。 ### 知识图谱的范式价值 知识图谱的"回归"本质上是对**关系推理**的回归。与向量库的"概率匹配"不同，图谱提供： - **确定性关联**：实体-关系-属性的标准化表示 - **可解释推理链**：从症状到疾病的逻辑推导可追溯 - **开放扩展性**：新关系可低成本添加，无需修改数据库模式 更深层地，知识图谱体现了**慢思考**的认知模式——与LLM的快思考（直觉生成）形成互补，这在医疗、法律等高风险场景中尤为关键。 ### 本体论的建模意义 本体论（Ontology）是知识图谱背后的**建模逻辑**，决定了： - 实体类型定义（疾病、症状、药物、检查等） - 允许的关系类型及其语义强度 - 推理规则的传递性约束 没有本体论的图谱是"没有KnowHow的骨架"——这也是为什么高风险行业（医疗、法律、金融）不能仅靠LLM自动抽取三元组，必须有领域专家参与本体论建设。 ### 图谱+LLM的演进路径 从CDSS失败到GraphRAG兴起，知识图谱与LLM的结合经历了： 1. **CDSS阶段**：纯规则驱动，依赖专家手工录入，泛化能力不足 2. **向量RAG阶段**：语义检索，但上下文割裂问题严重 3. **GraphRAG阶段**：图谱+LLM结合，实现置信度验证和可解释推理 未来方向：从"检索增强"走向"推理增强"，将知识系统内化为Agent的多步推理、自我校验能力。 ## 实践启示 ### 1. 重新评估向量库的定位 向量库不应再被视为RAG的"标配"，而应是： - **模糊问法的补充检索工具** - **非结构化内容的预筛选层** - **与关键词检索、规则路由混合使用** 真实系统往往是：关键词路由 + 向量检索 + 图谱查询的混合体。 ### 2. 构建领域知识图谱的优先级 对于高风险行业（医疗、法律、金融）： 1. **先建本体论**：明确实体类型、关系语义、推理规则 2. **再建图谱**：基于本体论构建领域知识网络 3. **最后引入LLM**：用LLM增强图谱的构建效率和推理能力 关键认知：LLM可以提高抽取效率，但本体论决定了这些结果能否被正确使用。 ### 3. 医疗AI系统的设计建议 基于本文分析，医疗AI系统应具备四维置信度： - **数据溯源**：每条诊断结论可追溯到权威指南 - **一致性**：多模态数据（症状、检查、影像）推理结果一致 - **动态性**：实时更新最新医学研究 - **可解释推理链**：附带详细判断依据 架构建议：路由层 → 简单查询由RAG基础层处理，复杂多模态问题交由图谱推理层，最终经置信度验证后输出。 ### 4. 数据处理的工程实践 不要再"偷懒"——数据处理（包括切分）的好坏直接决定RAG效果： - 使用层级化、结构化的索引（如PageIndex） - 检索流程：先定位、后精读的"规划-取证"模式 - 避免无脑chunking，考虑文档结构（表格、论证逻辑） ### 5. 关注技术演进方向 - **Google NotebookLLM** 可能是未来方向之一 - 从"检索增强"走向"推理增强" - 未来的AI知识系统将不再显式区分组件，而是内化为Agent的自主规划、多步推理、自我校验能力 ## 关联阅读 ## 相关实体 - [Google Agentic Rag Sufficient Context Agent Framesqa](https://github.com/QianJinGuo/wiki/blob/main/entities/google-agentic-rag-sufficient-context-agent-framesqa.md) - [Architecture Data Foundations For Ai Powered Search](https://github.com/QianJinGuo/wiki/blob/main/entities/architecture-data-foundations-for-ai-powered-search.md) - [Rag技术框架的演进方向](https://github.com/QianJinGuo/wiki/blob/main/entities/rag技术框架的演进方向.md) - [Skill Rag Tsinghua Sra](https://github.com/QianJinGuo/wiki/blob/main/entities/skill-rag-tsinghua-sra.md) - [Harness Engineering Framework](https://github.com/QianJinGuo/wiki/blob/main/entities/harness-engineering-framework.md) → [原文存档](https://github.com/QianJinGuo/wiki-book/tree/main/docs/raw/articles/向量库是rag的前菜知识图谱是答案本体论是灵魂-v2.md) --- ## Ch10.010 RAG → 知识图谱 → 本体论：三层知识架构 > 📊 Level ⭐⭐ | 28.7KB | `entities/rag-vector-knowledge-graph-ontology.md` # rag-vector-knowledge-graph-ontology 向量库是RAG的前菜，知识图谱是答案，本体论是灵魂 2026年5月4日 10:39 四川 标题已修改 在最初做RAG系统的时候有个几乎绑定的名词：向量库。所以他是什么呢？ 应该说向量库是一个理论上很美好的名词，他是一类用于存储和检索向量的数据系统，这里有两点要注意： 向量（embedding），可以将一段文本、图片、音频等内容，通过embedding模型编码成一个高维数组； ## 相关实体 - [Three Rag Architectures Classic Graph Agentic](https://github.com/QianJinGuo/wiki/blob/main/entities/three-rag-architectures-classic-graph-agentic.md) - [Nvidia Multimodal Rag Knowledge Systems](https://github.com/QianJinGuo/wiki/blob/main/entities/nvidia-multimodal-rag-knowledge-systems.md) - [Rag技术框架的演进方向](https://github.com/QianJinGuo/wiki/blob/main/entities/rag技术框架的演进方向.md) - [Skill Rag Tsinghua Sra](https://github.com/QianJinGuo/wiki/blob/main/entities/skill-rag-tsinghua-sra.md) - [Harness Engineering Framework](https://github.com/QianJinGuo/wiki/blob/main/entities/harness-engineering-framework.md) → [原文存档](https://github.com/QianJinGuo/wiki-book/tree/main/docs/raw/articles/rag-vector-knowledge-graph-ontology.md) - [knowledge base layer architecture: from rag to agent-native](https://github.com/QianJinGuo/wiki/blob/main/entities/pyramid-kb-knowledge-context-layer-banya.md) - [MOC](https://github.com/QianJinGuo/wiki/blob/main/moc/rag-knowledge-retrieval.md) ## 深度分析 **一、向量库的"语义检索"神话在工程实践中存在根本性脆弱性。** 向量库将知识压缩为孤立的"向量点"，依赖语义相似度匹配（Top-K检索），但这无法捕捉完整上下文。典型失败场景是：文档分块导致"上下文割裂"——如医疗场景中药物适用症与妊娠期禁用警示被切分到不同向量块，召回时只返回部分信息，导致误诊风险。文章犀利指出"什么JB语义检索，还是关键词检索靠谱"，揭示了向量检索在实际生产环境中的局限被长期低估 。 **二、知识图谱的核心价值在于将知识从"点状存储"升级为"关系网络"。** 知识图谱由实体（节点）、关系（边）和属性构成，能够显式表达"糖尿病→表现为→口渴"、"糖尿病→治疗→胰岛素"等确定性关联。这种网状结构使得推理路径可追溯、可解释，而不像向量检索那样只能提供"概率相似的片段"。在医疗、法律、金融等高风险领域，这种可解释性直接决定系统能否被信任和使用 。 **三、本体论是知识图谱具备行业KnowHow的建模规则，是三者中最被低估的层次。** 本体论定义了"实体类型是什么、允许什么关系、关系语义强度如何、哪些推理规则可以传递"。二甲双胍的案例极具说明性——"治疗糖尿病"（明确适应证）、"可能导致体重下降"（副作用观察）、"通过AMPK通路影响代谢"（作用机制）是三条语义强度完全不同的关系，没有本体论的约束，系统可能将其粗暴理解为"二甲双胍可以减肥"。这解释了为什么医疗、法律等高风险行业不能只靠大模型自动抽取三元组 。 **四、RAG架构正在从"检索增强"向"推理增强"演进，混合架构是当前最优解。** 真实系统往往是关键词路由、向量模糊匹配、知识图谱推理的混合体。向量库在其中扮演的角色正在从"主力检索"退化为"模糊问法的补充工具"，真正复杂的实体关系推理必须交给知识图谱和路由层。这一趋势已在Google NotebookLLM等产品中得到验证 。 **五、知识图谱+LLM的融合是降低医疗幻觉的有效路径，但前提是医疗置信度四维度的完整建设。** 医疗置信度需要同时满足：数据溯源（每条结论追溯到权威文献）、一致性（多模态数据推理结果一致）、动态性（实时更新最新医学研究）、可解释推理链（附详细依据和来源）。知识图谱+CoT+溯源的组合架构已在实验性场景中展现显著优于纯RAG的效果，但距离规模化落地仍有工程成熟度差距 。 ## 实践启示 1. **重新评估向量库在RAG架构中的定位。** 向量库并非RAG的必选组件，其语义检索能力存在边界——长文档切分导致的上下文割裂和"信息淹没"问题在复杂场景中不可忽视。建议将向量库定位为"模糊匹配的补充工具"，核心检索逻辑交由结构化程度更高的知识图谱或规则路由层承担。 2. **在高风险应用场景（医疗、法律、金融）必须引入知识图谱而非单纯依赖向量RAG。** 这些领域的知识具有强关联性和高置信度要求，向量检索的"概率匹配"无法满足"谁说了什么、证据等级如何、结论是否可传递"的推理需求。知识图谱提供的确定性关系网络和多跳推理能力是降低误诊、误判风险的关键基础设施。 3. **本体论建设应先于知识图谱抽取工程。** 在开始用大模型自动抽取三元组之前，应先与领域专家共同定义清楚：实体类型体系、允许的关系类型、语义强度分级、推理传递规则。否则大模型抽取出的"关系"会因为语义边界模糊而失去可用性，甚至引入误导性关联（二甲双胍→减肥的错误推导）。 4. **采用三层防御架构处理不同复杂度的查询。** 简单标准化查询走RAG基础层，复杂多跳或实体关系推理走图谱推理层，两路结果都经置信度验证（阈值如90%）后才输出或提交专家复核。这一架构已在医疗诊断场景中验证有效，适合作为复杂知识问答系统的设计参考。 5. **关注RAG向"推理增强"的演进方向，而非继续在向量检索上内卷。** 未来的AI知识系统将不再显式区分检索组件，而是将其内化为Agent的自主规划、多步推理、自我校验能力。开发者和企业应储备Agent架构和推理链设计能力，而非持续优化切分策略或向量模型。 6. **拥抱混合架构，但优先投资数据治理而非模型调优。** 文章最后的判断"人们很懒惰，不想处理烦躁的数据"是行业痛点也是机会点——自动数据处理框架（PageIndex等）正在涌现，但最终决定系统效果的仍是数据质量。在图谱和本体论上的数据投入，回报远超在向量模型或Embedding策略上的微调。 --- ## 第 2 来源 — Zleap AI 团队「SAG (SQL-Retrieval Augmented Generation)」(2026-06-16) > Source: [第2原文存档](https://github.com/QianJinGuo/wiki-book/tree/main/docs/raw/articles/sag-sql-retrieval-augmented-generation-zleap-ai-2026-06-16.md) > Author: 尹John (AGI Hunt) > Team: Zleap AI > Date: 2026-06-16 第 1 来源 (2026-05-04) 讲 **向量库/知识图谱/本体论** 三种知识组织形态的对比。第 2 来源是 **Zleap AI 团队 SAG 新 SOTA RAG** —— 用 **event-entity 超边模型 + MySQL + Elasticsearch 双存储 + 双路并行检索 + SQL JOIN 多跳** 替代传统 GraphRAG,在多跳问答基准上**领先 HippoRAG 2 (当前 SOTA) 11.1 个百分点**,已在 **5 亿生产数据**规模稳定运行。本来源填补 wiki 中"RAG 新 SOTA / 新一代架构"的视角空白。 ### 核心数据(HippoRAG 2 vs SAG) | 指标 | HippoRAG 2 | SAG (Zleap AI) | 提升 | |------|-----------|---------------|------| | MuSiQue Recall@2 | 49.5% | **64.1%** | +14.6 | | 三个基准平均 Recall@2 | 68.2% | **79.3%** | +11.1 | | Recall@5 (MuSiQue) | - | **80.04%** | - | | 生产数据规模 | - | **5 亿+** | - | **三个基准**: HotpotQA / 2WikiMultiHopQA / MuSiQue **统一配置**: BGE-Large-EN-v1.5 (embedding) + Qwen3.6-Flash (LLM) ### 三大 RAG 范式演进(本来源独家时间线) #### 范式 1: 传统向量 RAG (只会看脸) **逻辑**: 把每段文本变成一个向量 → 问题来了找最"像"的文本。 **优势**: 快 / 便宜 / 好部署 / 简单问答够用 **根本短板**: 向量搜索只知道"像不像",**不知道"谁跟谁有关系"** **经典失败案例**(本来源独家): > "A 公司收购了 B 公司,B 公司的 CTO 后来加入了 C 项目,C 项目影响了哪个产品路线?" > 答案分散在 3 篇完全不同文档,单独拿出任意一篇都和"问题不太像",只有**连起来才是完整答案**。向量 RAG 稳定找到这条链的概率"相当之低"。 **核心比喻**: 只会"看脸",不会"顺藤摸瓜"。 #### 范式 2: GraphRAG / HippoRAG 2 (图谱太重) **思路**: 从文本里把实体和关系抽出来 → 建知识图谱 → 沿着图谱做多跳检索。 **问题 1 - 三元组抽取**: 把每件事拆成"头实体 → 关系 → 尾实体" → 把完整的事拆得支离破碎。质量高度依赖每条"关系"抽得准不准。 **谓词不稳定**(本来源独家观察): 同一件事,不同模型可能抽出"使用"/"基于"/"提出"/"支持"四个不同谓词 → 真实数据里差异迅速放大,一发不可收拾。 **问题 2 - LLM 每步推理**: 抽取实体 → 归一化名称 → 合并重复 → 发现社区 → 生成摘要 → **每步靠 LLM**,跑一遍又慢又贵。 **问题 3 - 增量更新困难**: 新实体/新关系不断出现,旧关系可能过时 → 持续更新是难题。 **HippoRAG 2 的核心痛点**(本来源独家): 依赖**全局 Personalized PageRank** 做图排序,在 benchmark 规模下还行,但数据量上来且每天增量增长时,**全局 PageRank 负担相当大**。 **核心比喻**: "你每次往图书馆加一本新书,就得把整个图书馆的书重新排列一遍"。 #### 范式 3: SAG (索引卡片 + SQL JOIN) —— 本来源重点 **核心创新**: 不建图谱 / 不做三元组 / 不搞全局图。 **索引卡模型**: 给每个文本 chunk 加一张"索引卡": - **一个 chunk → 一个 event**(事项摘要,保留完整语义) - **同时抽取多个 entity**(实体,11 种类型标签: 人物/组织/地点/时间/产品/话题 等) - **event 保留完整语义,entity 负责索引和连接** - 两者通过 SQL 关联查询建立**多对多连接**,共同定义一条**潜在的超边(hyperedge)** ### event-entity 超边 vs 三元组(本来源独家对比) | 维度 | 三元组 | SAG 超边 | |------|-------|---------| | **结构** | 头 → 关系 → 尾 | event ⟷ entities | | **语义保留** | 拆碎,质量依赖每条关系 | 完整事项 + 多实体桥接 | | **LLM 负担** | 抽取实体 + 关系(每条关系都要抽对) | 抽取 event(完整事项) + entity(应提尽提) | | **谓词稳定性** | 不稳定(同件事不同模型可能抽 4 个不同谓词) | 不需要关系谓词,只有事项摘要 | | **图结构** | 两点之间的一条线 | 超图中一条超边: event 同时连多个 entity | | **检索友好** | 关系准才能用 | event 独立可搜,不依赖上下文 | **为什么 SAG 比三元组更轻、效果反而更好**(本来源独家): > "RAG 到最后还是要回到原文证据,三元组太碎,容易丢上下文。而 SAG 的 event 则保留了上下文,同时提供了可检索、可扩展的结构。" **代词消歧代码细节**(本来源独家): > SAG 在抽取 event 时,**强制做代词消歧** —— 子事项必须把所有"他"/"该公司"/"这个产品"替换成完整名称。从而每个 event 就是一段**独立可搜的完整描述,不依赖上下文就能被理解**。 ### SAG 完整架构 #### 离线阶段 1. 把文档切成 chunk 2. 每个 chunk 提取一个 event + 多个 entity 3. 写进 MySQL (存储结构化关系) 4. 同时写入 Elasticsearch 的向量索引和全文索引 **细节**(本来源独家): - 每条 event-entity 关系自身也带一段描述文本 + 自己的 embedding 向量 - 同一个实体"OpenAI"在不同 event 里的角色描述完全不同: - "OpenAI,发布 GPT-5 的公司" - "OpenAI,Sam Altman 创立的公司" - 在向量空间里是**不同的点** → 实体召回更精准 #### 在线检索阶段(双路并行)

问题进来
   ↓
LLM 识别关键实体
   ↓
   ├── 路径 A: 结构化召回
   │    实体 → 向量索引找相近实体 → SQL JOIN 查关联 event → 找到 chunk
   │
   └── 路径 B: 语义召回
        问题向量 → 相似度检索 → 找到语义接近的 event
   ↓
合并 + 查询时扩展(从已找到 event → SQL 反查 entity → 找新 event)
   ↓
每一轮只引入之前没出现过的新内容
   ↓
筛选 event 映射回原始 chunk → 回答基于原文证据

rmmod esp4 esp6 rxrpc
printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/fragnesia.conf

echo 1 | tee /proc/sys/vm/drop_caches

1. Transformer(FA2)        # 基础 Transformer，使用 Flash Attention 2
2. Pooling(cls)             # CLS pooling 策略（实验证明优于 mean pooling）
3. Dense(H, H, bias=False, GELU)  # 中间非线性层
4. LayerNorm(H)            # 层归一化
5. Dense(H, 1, scores)     # 输出单标量 relevance score

from sentence_transformers import CrossEncoder

model = CrossEncoder("cross-encoder/ettin-reranker-32m-v1")
scores = model.predict([
    ("Where was Apple founded?", "Apple Inc. was founded in Cupertino, California in 1976 by Steve Jobs, Steve Wozniak, and Ronald Wayne."),
    ("Where was Apple founded?", "The Fuji apple is an apple cultivar developed in the late 1930s."),
])

# [11.393298  2.968891]  <- larger means more relevant

from sentence_transformers import CrossEncoder

model = CrossEncoder(
    "cross-encoder/ettin-reranker-32m-v1",
    model_kwargs={
        "dtype": "bfloat16",
        "attn_implementation": "flash_attention_2",
    },
)

from sentence_transformers import SentenceTransformer, CrossEncoder

# 阶段1：快速 embedding 检索（亚毫秒级）
embedder = SentenceTransformer("sentence-transformers/static-retrieval-mrl-en-v1")
reranker = CrossEncoder("cross-encoder/ettin-reranker-68m-v1")

# 编码 + 检索 top-100
query_emb = embedder.encode_query(query, convert_to_tensor=True)
corpus_emb = embedder.encode_document(corpus, convert_to_tensor=True)
scores = embedder.similarity(query_emb, corpus_emb)[0]
top_k_idx = scores.topk(min(100, len(corpus))).indices.tolist()

# 阶段2：精排序
top_k_docs = [corpus[i] for i in top_k_idx]
ranked = reranker.rank(query, top_k_docs, top_k=5, return_documents=True)