RAG 问一个需要跨段落推理的问题传统方案只会把最相似的几个文本块塞给模型。块和块之间没有关联模型只能硬猜。解决方案大家都知道——建知识图谱。但代价有点大三元组抽取质量不稳定、图数据库运维成本高、关系变更时整图重建。SAG 的做法是在 chunk 和知识图谱之间加一个轻量中间层。不建完整图谱只做两件事从每个文本块里提取 1 个事件和 N 个实体然后用 SQL 多跳查询代替图数据库。在HotpotQA / 2WikiMultiHop / MuSiQue三个多跳问答基准上对比 HippoRAG 2平均 Recall2 从 68.14% 提升到 79.30%。整个系统分写入和检索两条管线下面完整拆一遍。写入pipelinechunk → 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 Recall5 上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时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】