原始文本、embedding、向量库和相似度搜索

RAG 最朴素的一层，其实只有四个东西。

• 原始文本：人类语言。
• embedding：机器用的坐标。
• 向量库：存这些坐标的地图。
• 相似度搜索：在地图上找离你最近的点。

假设有一段文档写着：“深圳企业投资电影《给阿嬷的情书》，主要看中侨批题材、家庭观影和海外华人情感传播。”这句话对人来说是一段文本。对机器来说，它先要被 embedding 模型转成一串数字，比如 768 维、1024 维或 3072 维的向量。

这串数字不是给人读的。它像一个坐标，把这段文本放进一个高维空间。语义接近的文本，坐标更近；语义差得远的文本，坐标更远。向量库负责存这些坐标，相似度搜索负责在用户提问时找附近的点。

用户问：“为什么有人愿意投这部电影？”系统也把这个问题转成 embedding，再去向量库里找离它最近的几段文本。找出来的文本被塞进 prompt，大模型基于这些上下文生成回答。

这就是传统 RAG 的基本链路。

它有效，因为模型不需要把所有知识都记在参数里。它也危险，因为“相似”不等于“能回答”。

问“投资原因”时，相似度搜索可能找回“电影使用方言”“影片讲述家庭故事”“深圳企业参与投资”。这些片段看起来都相关，但如果没有把它们串成一条证据链，模型只能自己猜。猜得顺，就是好答案；猜偏了，就是幻觉。

RAG 的第一层难题，不是找不到文本，而是找到的文本之间没有结构。

RAG 到底补了大模型的哪块短板

原始大模型像一个压缩过的世界模型。它知道很多东西，但知识有三个问题。

第一，知识可能过期。训练结束之后发生的事，模型不知道。

第二，知识没有来源。模型说出一句话，你很难知道它来自哪篇文档、哪条记录、哪个版本。

第三，知识不可控。企业内部文档、客户数据、项目状态，不可能都靠模型预训练解决。

RAG 的作用，是在生成前加一个检索层。模型先查资料，再回答。它不是让模型变聪明，而是给模型一张临时打开的参考书。

典型 RAG 流程大致是这样：

1. 把文档切成 chunk。 2. 给每个 chunk 生成 embedding。 3. 存进向量库。 4. 用户提问时，检索 top-k 相关 chunk。 5. 把 chunk 放进 prompt。 6. 大模型生成答案。

这条链很适合 FAQ、客服知识库、产品文档问答、内部制度检索。因为这类问题大多是单跳的：问题和答案通常在同一段或相邻几段文本里。

比如“报销发票抬头怎么填？”“某个 API 的 rate limit 是多少？”“这个按钮在哪里配置？”普通 RAG 很够用。你不需要知识图谱，也不需要本体。BM25 加向量检索，再配一个 reranker，大部分情况下就能做出可用系统。

难点出现在另一类问题上。

用户问的不是“哪段文档写了这个”，而是“几件事合起来说明什么”。答案散在多个文档、多个时间点、多个实体之间。传统 RAG 找到的是相似片段，不一定找得到关系链。

这就是 GraphRAG、HippoRAG、LightRAG、SAG 这些路线出现的背景。

本体：先规定世界里有什么

本体，英文是 ontology。它听起来玄，其实很朴素：先规定这个世界里有哪些东西，这些东西之间允许发生什么关系。

在一个企业知识系统里，本体可能会定义：

• Person：人。
• Organization：组织。
• Project：项目。
• Document：文档。
• Decision：决策。
• Event：事件。
• ProductRoadmap：产品路线。

它还会定义关系：

• person works_for organization。
• person owns project。
• decision affects roadmap。
• event mentions entity。
• document supports claim。
• decision supersedes decision。

本体不是事实库。它不负责说“张三在 A 公司工作”。它只规定“人可以在组织工作”“决策可以影响产品路线”“一个旧决策可以被新决策取代”。

这层约束很有价值。

如果没有本体，LLM 抽关系时可能什么都抽：A 公司喜欢 B 项目、某个 API 伤害某个用户、一个日期领导一个产品。机器不会天然知道哪些关系合法。它只是在文本里找语言模式。

有本体以后，系统至少能做三件事：

• 限制抽取范围，减少胡乱造关系。
• 统一实体和关系名称，方便查询。
• 让下游系统知道数据能怎么用。

但本体也有成本。设计本体需要懂业务，也需要长期维护。业务还没稳定时，过早做一套庞大本体，很容易变成知识工程项目。最后写代码的人不敢改，业务的人不愿填，系统停在半路。

所以实际做 Agent 和 RAG，通常不应该先做大而全本体。更合理的是先做轻本体。只定义少数关键对象：事件、实体、证据、状态、决策、结论。等系统跑起来，再把高频关系沉淀进去。

知识图谱：把事实按关系存起来

本体规定语法，知识图谱存事实。

如果本体说“公司可以收购公司”，知识图谱里就可以存：

• Facebook acquired Instagram。
• Microsoft invested_in OpenAI。
• Anthropic partnered_with Google Cloud。

如果本体说“人可以创建项目”，知识图谱里就可以存：

• Kevin Systrom founded Instagram。
• Guido van Rossum created Python。

知识图谱的核心不是“图看起来很漂亮”，而是事实被拆成节点和边。节点通常是实体，边通常是关系。图结构适合回答一类问题：从一个点出发，沿关系走几步，找到另一个点或一组证据。

比如用户问：“某条产品路线受谁影响？”普通向量检索会找“产品路线”附近的文本。知识图谱可以从路线节点往外走：

• 产品路线关联了哪些项目？
• 项目由谁负责？
• 负责人之前在哪些公司或项目工作？
• 哪些外部事件改变了路线？
• 哪些决策支持或推翻了旧判断？

这种多跳关系，是图的强项。

但知识图谱有两个老问题。

第一个是抽取难。文本里的事实不是天然三元组。人类说话常常一段话里包含背景、时间、条件、态度和隐含因果。把它强行拆成“主体-关系-客体”，会损失语境。

第二个是维护难。实体会重名，别名会变化，关系会失效，旧事实会被新事实覆盖。如果图谱承担的是生产系统，实体合并、关系归一、版本管理、权限控制、审计追溯，都会变成长期成本。

知识图谱能解决关系问题，但它会把成本前置到建模和维护上。

GraphRAG：把图结构接进检索

GraphRAG 的想法很直接：既然普通 RAG 只会找相似文本，不会顺关系找证据，那就先把文本抽成图，再让检索过程利用图。

微软 GraphRAG 是这条路线里最有代表性的系统之一。它会从文档中抽取实体、关系和声明，构建图结构，再通过社区发现和摘要，把局部关系组织成更高层的主题报告。查询时，系统不只拿相似 chunk，而是结合图里的实体、关系、社区摘要和原文证据来生成回答。

这套方法在全局问题上很强。

比如你不是问“某个条款怎么写”，而是问“这一批客户投诉反映了哪些主要问题”“这组研究论文里有哪些共同主题”“某个组织网络的核心矛盾是什么”。普通 RAG 容易抓几段局部文本，GraphRAG 更容易把主题、群组、关系和全局摘要一起拿出来。

GraphRAG 的价值不在“用了图”，而在它把检索从局部相似度扩展到关系和主题结构。

它的问题也来自这里。

建图很贵。抽实体、抽关系、做消歧、做社区、生成摘要，每一步都可能调用模型，每一步都可能错。文档一多，图谱更新也重。新资料持续进入时，哪些社区要重算，哪些摘要要刷新，哪些实体要合并，都不是小事。

另一个问题更隐蔽：很多 GraphRAG 系统建图很认真，查询时却没有充分沿图推理。最后还是把图节点或社区摘要当成“更高级的 chunk”来检索。这样当然有收益，但收益没有达到知识图谱本来承诺的上限。

GraphRAG 适合什么？

• 全局主题总结。
• 组织关系分析。
• 大规模文档集合的结构化理解。
• 需要解释“哪些群组、哪些主题、哪些关系共同导致某个结论”的场景。

它不适合什么？

• 高频增量写入、低延迟要求很强的业务主链路。
• 本体和实体治理能力还没准备好的早期团队。
• 简单 FAQ 和单跳知识库。

很多团队第一次做 RAG，真正需要的是 hybrid search，不是 GraphRAG。BM25、向量检索、metadata filter、reranker、引用回链这些基础没做好，上图只会把问题变复杂。

HippoRAG 和 LightRAG：图路线的两个侧面

GraphRAG 之外，还有两条常被一起讨论的路线。

HippoRAG 受人类记忆机制启发，强调从线索出发，在图中激活相关节点，再通过图排序算法扩散。HippoRAG 2 进一步把 RAG 往长期记忆和多跳检索方向推。它的优势是能处理需要沿关系链找证据的问题，尤其是多跳问答。

但它仍然依赖图。只要依赖全局图，就绕不开图的构建、更新和排序成本。学术 benchmark 里这条路很漂亮，真实业务里要看数据规模、写入频率和查询延迟能不能扛住。

LightRAG 的思路更偏轻量。它尝试把图索引和向量检索结合起来，用更低成本取得关系检索收益。它代表了另一种工程方向：不追求完整知识图谱，而是把图做成检索增强结构。

这两条路线都说明了一件事：RAG 需要结构，但结构不能无限重。

真正的问题不是“要不要图”，而是“图的成本放在哪里”。

• 离线阶段多做，查询时轻。
• 查询阶段动态展开，离线少做。
• 全局图强一致，维护重。
• 局部图临时生成，解释性强但不一定稳定。

SAG 的位置，就在这个取舍里。

SAG：不是 SQL 很神，而是把关系压成事件和实体

SAG 的全称是 SQL-Retrieval Augmented Generation。名字容易让人误解，好像它只是“用 SQL 做 RAG”。重点不在 SQL，而在数据结构。

它没有一上来把文本拆成严格三元组，也没有先建一张完整全局知识图谱。它先把 chunk 整理成两类对象：

• event：一件相对完整的事。
• entity：这件事里涉及的人、组织、地点、项目、概念、作品、时间等。

一个 chunk 可以对应一个 event。一个 event 可以连接多个 entity。一个 entity 也可以出现在多个 event 里。

这其实是一种超边结构。普通图的一条边通常连接两个节点；event 像一张事项卡，把多个实体绑在一起。它不急着判断所有实体之间的精确关系，而是先保留“这些实体共同出现在一件事里”。

这一步很关键。

一段新闻或项目记录，常常不是一个简单关系。比如“深圳企业投资《给阿嬷的情书》，看中侨批题材的文化价值、海外华人情感连接和家庭观影传播潜力”。如果强行拆成三元组，可能得到：

• 深圳企业 投资 电影。
• 电影 使用 方言。
• 侨批 具有 文化价值。
• 海外华人 关注 家庭情感。

每条都对，但整件事被剪碎了。投资判断的语境没了。

SAG 用 event 保住这件事的完整性，再用 entity 让它能被连接。查询时，它通过共享 entity 动态展开局部线索网。

用户问“为什么有人投资这部电影？”系统可能先识别出投资、电影、深圳企业、侨批、海外华人等入口实体。然后用 SQL 查这些实体关联的 event。找到 seed events 后，再从这些 event 反查更多实体，再扩一跳 event。

这一套本质上是 join。

它不是在全局图上跑复杂图算法，也不是提前把世界所有关系都算好。它在问题发生时，只围绕当前问题展开局部关系。

SAG 和 GraphRAG 的关键差别

GraphRAG 更像提前修一座知识宫殿。先抽实体关系，建图，做社区，生成摘要。查询时从这座宫殿里找路。

SAG 更像建立一套事项档案。每张卡记录一件事，卡上贴着实体标签。查询时从几张相关卡出发，沿标签翻出附近的卡。

这两个比喻不只是修辞，它们对应不同工程成本。

GraphRAG 的前置成本高。它希望离线结构足够完整，查询时能利用全局结构。适合稳定文档集、全局主题分析、研究型知识库。

SAG 的前置成本较低。它只要求每个 chunk 能抽出 event 和 entity，然后在线阶段用 SQL、向量索引、全文检索和 rerank 组合。适合持续增量写入、需要多跳线索、又不想维护重型全局图的系统。

差别可以压成几个维度：

| 维度 | 普通 RAG | GraphRAG | SAG | |---|---|---|---| | 基本单元 | chunk | entity / relation / community | event / entity | | 主要检索方式 | 向量相似度、关键词 | 图结构、社区摘要、原文证据 | SQL join、向量、全文、rerank | | 结构成本 | 低 | 高 | 中 | | 增量写入 | 容易 | 较重 | 相对容易 | | 多跳能力 | 弱 | 强 | 中到强 | | 解释路径 | chunk 引用 | 图路径 + 摘要 | event 链 + 原文 chunk | | 适合场景 | FAQ、文档问答 | 全局主题、关系分析 | 多跳业务检索、Agent 记忆、事项档案 |

SAG 的创新不是把 GraphRAG 干掉，而是把其中一部分能力换成了更便宜的数据工程形式。

这很重要。很多公司不是没有图数据库，也不是不知道知识图谱好，而是没人能长期维护一张干净的大图。SAG 这种事件中心结构，把“完美关系”降级成“可用线索”，工程上反而更容易活下来。

SAG 的 benchmark 应该怎么看

SAG 论文和 benchmark repo 报告了 HotpotQA、2WikiMultiHopQA、MuSiQue 等多跳问答数据集上的结果。文中提到，在统一配置下，SAG 的平均 Recall@2 和 Recall@5 高于 HippoRAG 2；在 MuSiQue 上，SAG 的 Recall@5 也明显领先。

这组数字有参考价值，但不要把它理解成“RAG 已经被 SAG 统一了”。

第一，指标主要是 Recall@K。它衡量的是证据有没有被召回到前 K 条里，不等于最终回答质量。证据找对是必要条件，不是充分条件。

第二，benchmark 数据集和企业数据差别很大。HotpotQA、2WikiMultiHopQA、MuSiQue 都是多跳问答数据集，适合测结构化检索能力。但企业内部数据会有脏数据、重复记录、权限边界、版本冲突、时间有效性和业务缩写。

第三，项目方提到的大规模部署和秒级延迟，在没有独立复现和详细架构披露之前，只能当作作者自述。可以重视，不能直接当作行业结论。

第四，LLM rerank 很关键。SAG 的候选集最后仍然需要模型或 reranker 判断。这个环节带来质量，也带来成本、延迟和稳定性问题。

所以更稳妥的判断是：SAG 在多跳证据召回上展示了有意思的结构优势，尤其适合事件和实体密集的数据；它不是所有 RAG 场景的新默认。

本体、知识图谱、RAG、GraphRAG、SAG 的关系

这几个词最容易混在一起。可以按层看。

本体是规则层。它规定有哪些对象、哪些关系、哪些约束。

知识图谱是事实层。它把具体事实按节点和边存起来。

RAG 是检索生成方法。它先检索外部资料，再让模型回答。

GraphRAG 是 RAG 的一种结构增强。它让检索利用图结构、实体关系和主题社区。

SAG 是另一种结构增强。它不强调全局图，而是用 event 和 entity 做可查询的局部关系网。

放在一条数据流里，大致是：

1. 原始文本进入系统。 2. 切 chunk，生成 embedding，进向量库。 3. 抽 event 和 entity，进关系表。 4. 可选：按本体约束实体类型和关系类型。 5. 可选：构建知识图谱或社区摘要。 6. 查询时，向量检索、关键词检索、SQL 扩展、图检索共同召回候选。 7. reranker 或 LLM 选择证据。 8. 大模型基于证据生成回答，并返回引用路径。

不是每个系统都要做全套。恰恰相反，好的系统通常知道自己不做什么。

如果问题大多是单跳，普通 RAG 足够。把钱花在文档清洗、chunk 策略、metadata、hybrid search、reranker 和引用展示上。

如果问题经常跨文档、跨实体、跨时间，才值得引入结构层。

如果结构关系稳定，且全局主题分析重要，可以考虑 GraphRAG。

如果数据持续增长、事件密集、业务需要追线索而不是追完美关系，SAG 这类事件中心方案更合适。

为什么 Agent 比聊天机器人更需要这层结构

普通聊天机器人答错了，用户追问一句就结束了。Agent 不一样。Agent 会基于检索结果继续行动。

它可能会：

• 查数据库。
• 调工具。
• 写报告。
• 改代码。
• 发邮件。
• 更新 CRM。
• 调度下一个子任务。

第一步检索错了，后面不是答错一句话，而是整条任务链跑偏。

Agent 需要的数据底座，至少要有四种能力。

第一，证据可追溯。系统要知道每个结论来自哪条原始记录，而不是只给模型几段匿名文本。

第二，关系可展开。用户问一个项目，系统能找到相关客户、负责人、决策、风险、历史版本。

第三，状态可更新。旧判断失效、新决策生效、用户偏好改变，这些变化不能只变成聊天记录。

第四，过程可回放。出错后能看到模型查了什么、用了什么证据、沿哪条线索走到了错误结论。

传统 RAG 只能覆盖第一点的一部分。知识图谱覆盖第二点，但维护重。带时间维度的图谱覆盖第三点，但实现更难。AgentScope 这类运行时强调消息和状态，解决第四点的一部分。SAG 的吸引力在于，它用事件卡片把第一点和第二点做得比较轻，还给第三点留下了空间。

把 Agent 记忆写成 event，比写成聊天摘要更自然。

比如：

• 用户在 2026-06-12 说，后续文章偏好技术博客风，不要营销腔。
• 项目 A 在 2026-06-18 决定先发 staging，再发 production。
• 客户 B 在 2026-06-20 否定了原报价，原因是交付周期太长。
• Agent 在一次代码审查里发现支付回调缺少幂等处理。

这些都不是普通“文本块”。它们是发生过的事。每件事涉及用户、项目、文件、客户、决策、状态和证据。用 event + entity 存，后面更容易检索、追踪和作废。

应用场景：哪些地方真需要 GraphRAG 或 SAG

第一类是企业内部知识和项目记忆。

一个公司里的知识不是一本手册，而是邮件、会议纪要、飞书消息、代码提交、PRD、工单、客户访谈和财务记录混在一起。问题也很少是“某条规则是什么”，更多是“为什么这个项目当时这么决策”“这个客户的真实阻力是什么”“哪个旧判断后来被推翻了”。

这类问题适合事件中心结构。每条会议纪要、工单、客户反馈都可以抽成 event，再挂上项目、客户、负责人、时间和状态。查询时动态展开线索。

第二类是研究和情报分析。

比如产业链分析、公司关系、投资事件、产品路线、论文脉络。这些问题天然多跳。A 公司投资 B，B 的创始人离职做 C，C 的技术路线影响 D 产品。单段文本经常答不全。

GraphRAG 适合做全局图谱和主题社区，SAG 适合做持续增长的事件档案。前者更像研究数据库，后者更像线索检索系统。

第三类是客服和销售。

普通客服 FAQ 用 RAG 足够。但复杂客服会涉及订单、用户历史、产品版本、旧工单、政策变更和人工处理记录。销售也一样，客户偏好、预算变化、竞品比较、上次会议结论，都需要按事件回溯。

这时不一定要完整知识图谱，但需要 event 化记忆。

第四类是代码和软件工程 Agent。

代码库里的知识不是只有文件内容。还有 issue、commit、PR review、架构决策、线上事故、测试失败记录。一个 bug 为什么出现，往往要跨文件、跨提交、跨讨论找线索。

普通代码向量检索只能找相似代码。事件中心结构可以记录“某次改动引入了什么行为变化”“哪次 review 提到过风险”“哪个测试后来覆盖了这个路径”。

第五类是医疗、法律、金融这类高风险场景。

这些场景不能只靠相似文本。证据来源、时间有效性、版本、权限和审计都很重要。GraphRAG 和 SAG 都可能有用，但必须配合严格本体、权限模型和人工审核。这里不能只谈召回率。

什么时候不要上结构化 RAG

结构化 RAG 有价值，但不是默认答案。

以下几种情况，先别急着上 GraphRAG 或 SAG。

第一，文档量小。几十篇文档、几百个页面，普通 hybrid search 加人工整理就够了。

第二，问题单跳。用户问的内容通常能在一段文本里回答，上结构只会增加成本。

第三，没有稳定数据清洗流程。原文去重、chunk、权限、元数据、更新时间都没做好，抽 event 和 entity 只会制造新的脏数据。

第四，没有评测集。你不知道当前 RAG 错在哪里，就很难证明结构化方案真的提升了结果。

第五，没人维护。本体、实体表、抽取规则、rerank 策略都需要迭代。没有 owner 的结构化 RAG，会慢慢变成一堆没人敢删的中间表。

技术路线的顺序通常应该是：

1. 先做好普通 RAG。 2. 加关键词检索和 metadata filter。 3. 加 reranker 和引用展示。 4. 建一组真实问题评测集。 5. 找出多跳失败样本。 6. 再决定用 GraphRAG、SAG，还是只补少量结构字段。

不要用架构替代诊断。

一个可落地的最小 SAG 设计

如果真要在业务系统里试 SAG 思路，不需要一上来复刻论文。可以从一个很小的 schema 开始。

核心表只要六张：

CREATE TABLE documents (
  id TEXT PRIMARY KEY,
  title TEXT NOT NULL,
  source TEXT NOT NULL,
  created_at TIMESTAMP NOT NULL
);

CREATE TABLE chunks (
  id TEXT PRIMARY KEY,
  document_id TEXT NOT NULL,
  text TEXT NOT NULL,
  embedding VECTOR,
  FOREIGN KEY (document_id) REFERENCES documents(id)
);

CREATE TABLE events (
  id TEXT PRIMARY KEY,
  chunk_id TEXT NOT NULL,
  event_text TEXT NOT NULL,
  occurred_at TIMESTAMP,
  confidence REAL NOT NULL,
  FOREIGN KEY (chunk_id) REFERENCES chunks(id)
);

CREATE TABLE entities (
  id TEXT PRIMARY KEY,
  name TEXT NOT NULL,
  normalized_name TEXT NOT NULL,
  type TEXT NOT NULL,
  embedding VECTOR
);

CREATE TABLE event_entities (
  event_id TEXT NOT NULL,
  entity_id TEXT NOT NULL,
  role TEXT,
  PRIMARY KEY (event_id, entity_id)
);

CREATE TABLE evidence_links (
  event_id TEXT NOT NULL,
  chunk_id TEXT NOT NULL,
  span_start INTEGER,
  span_end INTEGER
);

上线第一版时，甚至不需要复杂实体消歧。先做保守归一：大小写、空格、常见别名、同 source 下同名同类型复用。宁可多几个重复实体，也不要把不该合并的实体硬合并。

查询流程也可以很朴素：

1. 从 query 抽入口实体和关键词。 2. 用实体表的全文检索和向量检索找候选 entity。 3. join event_entities 找 seed events。 4. 从 seed events 反查相关 entities。 5. 用这些 entities 再扩一跳 events。 6. 同时跑普通 chunk 向量检索。 7. 合并候选，rerank。 8. 返回答案、event 链和原文 chunk 引用。

这套系统不是为了证明自己“像知识图谱”。它只回答一个工程问题：能不能比普通 RAG 更早、更稳地找到关键证据链。

评测：别只看答案漂不漂亮

RAG 系统最容易被 demo 骗。

一个好看的回答，可能只是模型会写。真正要测的是证据有没有找对、证据是否足够、引用是否真实、错误能不能定位。

最少要测五类指标。

• Recall@K：关键证据有没有进入前 K 条。
• MRR / nDCG：关键证据排得够不够靠前。
• Answer correctness：最终答案是否正确。
• Faithfulness：答案是否只基于给定证据。
• Trace quality：引用链是否能让人复核。

对 GraphRAG 和 SAG，还要额外测两类。

第一，扩展成本。一次查询扩出多少实体、多少 event、多少 token、多少 rerank 调用。结构化检索最怕“相关线索”爆炸。

第二，增量更新成本。新增一批文档后，要重算多少东西；旧结论怎么失效；实体表怎么保持可用。

如果没有这些指标，只比较“回答看起来更完整”，很容易把成本藏起来。

综合评判：SAG 值得看，但别神化

SAG 真有意思。

它切中的不是一个小技巧，而是 RAG 从“找相似文本”走向“找证据链”的核心矛盾。它也避开了 GraphRAG 的一部分重成本：不急着构建完美全局图，而是把文本组织成事件卡，再用实体做查询时局部展开。

这个取舍很适合 Agent 时代。

Agent 不只是回答问题，它要沿线索继续做事。它需要知道一条信息从哪里来，和哪些事有关，下一步还能查什么。event + entity 的结构，比一堆 chunk 更适合承载这种运行时记忆。

但 SAG 不是银弹。

它依赖 LLM 抽取 event 和 entity。抽错了，结构就会带错。它允许不完美实体合并，但实体膨胀到一定程度，查询扩展会变脏。它用 rerank 提升质量，但 rerank 也会带来成本。它在多跳 benchmark 上表现好，不代表在每个业务知识库里都赢。

最稳的结论是：

普通 RAG 是基础能力，先把它做好。GraphRAG 是重结构方案，适合全局关系和主题分析。SAG 是事件中心方案，适合多跳线索、持续增量和 Agent 记忆。

它们不是互斥关系。一个成熟系统很可能同时有三层：

• 底层用普通 RAG 做快速语义召回。
• 中层用 SAG 式 event/entity 做局部线索扩展。
• 高层在少数稳定领域里建本体和知识图谱。

这比争“谁是新 SOTA”更接近真实工程。

RAG 的下一步，大概不会是更大的向量库。它会变成一套证据系统：文本有坐标，事件有时间，实体有身份，关系有来源，结论有引用，旧状态能被新状态覆盖。

到那一步，RAG 才不只是给大模型递资料。它开始像一个可以被审计的数据底座。