图谱RAG太笨重，SAG轻量多跳性能暴涨30%
RAG 问一个需要跨段落推理的问题，传统方案只会把最相似的几个文本块塞给模型。块和块之间没有关联，模型只能硬猜。
解决方案大家都知道——建知识图谱。但代价有点大：三元组抽取质量不稳定、图数据库运维成本高、关系变更时整图重建。
SAG 的做法是在 chunk 和知识图谱之间加一个轻量中间层。
不建完整图谱，只做两件事：从每个文本块里提取 1 个事件和 N 个实体，然后用 SQL 多跳查询代替图数据库。
在HotpotQA / 2WikiMultiHop / MuSiQue三个多跳问答基准上，对比 HippoRAG 2，平均 Recall@2 从 68.14% 提升到 79.30%。
整个系统分写入和检索两条管线，下面完整拆一遍。
写入pipeline：chunk → event → entities
第一步 文档切分： 上传文档是按 Markdown 标题层级做 chunking——不是固定字数切分，而是按内容结构。
第二步 提取事件：SAG 对每个 chunk 只提取 1 个事件。在源码extractor.ts里，提取函数最后一行是.slice(0, 1)——不管 LLM 返回多少个候选事件，只保留第一个。
为什么是 1 个？传统 RAG 直接用 chunk 做检索单元，问题是 chunk 是物理切分，语义边界模糊。
GraphRAG 走另一个极端——从 chunk 里抽三元组（subject-predicate-object），但一句话可能拆成四五个三元组，原始语义碎片化严重。
SAG 取中间态：1 个事件保留完整语义（“谁在什么背景下做了什么”），同时把其中的实体拆出来做索引。
每个事件包含:标题、摘要、完整内容和关联实体列表。
实体有 11 种类型定义——人物、组织、地点、时间、产品、指标、动作、作品、群体、主题、标签。提取 prompt 用 few-shot 示例引导 LLM 按这个 schema 输出 JSON，并且自动检测输入语言——中文文档产出中文字段，英文文档产出英文字段。
第三步 向量化：事件标题和实体名称分别做 embedding，写入 PostgreSQL + pgvector。到这里，一份文档在数据库里的结构是：
chunk（原文块） └─ event（语义事件，1:1） └─ entities（实体列表，1:N） └─ 其他 event 的 entities（跨事件关联）事件是检索的最小信息单元，实体是跳转的路标。
检索流水线
第 1 步：理解问题。这里分两条路。
- Fast 模式直接拿用户原文在实体库做 BM25 全文匹配，不调 LLM，速度快；
- Standard 模式让 LLM 从问题中抽取命名实体，再按名称精确匹配 + 按实体向量语义匹配，精度高但多一轮 API 调用。
第 2-3 步：双路召回。拿到匹配的实体后，通过 entity → event 关联查出一批候选事件，这是"实体路径"。同时用查询向量直接在事件标题向量上做相似度召回，这是"向量路径"。两条路径的结果合并成种子事件集。
第 4 步：多跳扩展。这是 SAG 区别于普通 RAG 的核心。从种子事件里收集所有关联实体 ID → 通过这些实体 ID 找到新的事件 → 再从新事件里收集新实体 → 继续跳。 源码expandFixedHops里实现的就是这个 BFS 循环——每一跳是一次 SQL JOIN，不需要图数据库。
为什么 SQL 就够？因为 SAG 的关系结构只有两种节点（event 和 entity）和一种边（关联），用 PostgreSQL 的 JOIN 就能完成广度优先遍历。引入 Neo4j 反而增加部署复杂度。
第 5-6 步：粗排 + 精排。扩展后的候选事件集先按内容向量相似度粗排，再做精排。
- Fast 模式用
qwen3-rerank模型排序， - Standard 模式让 LLM 直接从候选里选最相关的 top-K。 精排有一个兜底：如果返回空集，自动回退到粗排结果。
第 7 步：回取原文。精排选出的事件 ID 反查关联的原始 chunk，作为上下文交给 LLM 生成答案。如果事件路径返回的 chunk 数量不够，系统会自动补充普通向量搜索的结果。
这个"多跳是增强，向量是兜底"的架构让我觉得设计者在生产环境里踩过坑。
多跳检索不可能覆盖所有情况，但也不能因为偶尔失效就不做——SAG 的处理方式是让两条路径共存，多跳能命中就走多跳，命中不了就降级回向量。不追求理论上的完美覆盖，追求工程上的不出空结果。
还有一个值得一提的架构选择：Fast 和 Standard 两种搜索模式共用同一套 event/entity 索引，只是上游匹配策略和下游排序策略不同。
这意味着写入管线只需要跑一次，检索时按场景切换模式就行——原型验证用 Fast 跑通流程，上线前切 Standard 提精度。
在 MuSiQue Recall@5 上，SAG 从 HippoRAG 2 的 65.13% 提升到 80.04%。换用 NV-Embed-v2 后进一步到 81.71%——但从 80.04 到 81.71 只涨了 1.67 个点，说明增益主要来自 event/entity 结构本身，而非更强的 embedding 模型。对做 RAG 的团队来说，这个发现很有价值：架构层面的改进比换模型更有效。
学AI大模型的正确顺序，千万不要搞错了
🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！
有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！
就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋
📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇
学习路线:
✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经
以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！
我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～