
今天讲的是 **SAG（SQL 检索增强生成）**，一种让 AI 在回答复杂问题时，能从一堆文档里“顺藤摸瓜”找到证据的技术。

---

### 一、基础概念类

- **LLM（大语言模型）**\
  &#x20;就是类似 ChatGPT 的 AI，能读懂文字、生成回答。但它不知道你私有的文档内容，所以需要配合检索。
- **RAG（检索增强生成）**  \
  &#x20;核心思路：**先查资料，再回答**。\
  &#x20;比如你问 AI 一个公司内部问题，它先从公司文档库里检索相关段落，再把段落和问题一起给它，让它“看着资料回答”。
- **Dense Retrieval（密集检索）**\
  &#x20;把文档和问题都变成“语义指纹”（向量），然后找指纹最像的段落。不是靠关键词，而是靠意思相近。
- **Multi-hop QA（多跳问答）**\
  &#x20;需要“跳”好几次才能回答的问题。\
  &#x20;比如：*“小明所在城市的市长是谁？”* → 先找小明在哪个城市，再找这个城市的市长。中间有两跳。
- **Knowledge Graph（知识图谱）**\
  &#x20;把实体（人、地点、组织等）和关系画成一张网。比如：`张三 –认识– 李四`。
- **Triple（三元组）**\
  &#x20;知识图谱里的最小事实格式：`实体A –关系– 实体B`。比如 `北京 –是首都– 中国`。
- **Hyperedge（超边）**\
  &#x20;普通一条边只连两个点，超边可以同时连多个点。\
  &#x20;比如“一次会议”同时连接所有参会人，这个“会议”就是一条超边。
- **Entity（实体）**\
  &#x20;文本中具体的对象，比如人名、地名、公司名、时间等。
- **Event（事件）**\
  &#x20;一段完整的事实描述，比如“苹果公司在2024年发布了新手机”。\
  &#x20;在 SAG 中，每个文档块会被浓缩成一个事件。
- **Chunk（块）**\
  &#x20;长文档被切成一段一段的小块，方便检索。
- **Index（索引）**\
  &#x20;为了快速找东西而建的“目录”。比如按实体建的索引，就能通过实体名快速找到所有提到它的文档。
- **Append-only（仅追加）**\
  &#x20;只允许往数据里加新内容，不允许改旧内容。\
  &#x20;好处是写入速度快、好扩展，但缺点是无法更新旧事件。

---

### 二、SAG 自己的核心设计

- **Event-Entity Index（事件-实体索引）**  \
  &#x20;SAG 不建完整的知识图谱，只建一张表：每个事件对应一行，旁边挂一串实体。  \
  &#x20;相当于每个文档块 = 一个事件 + 它的参与实体。
- **Latent Hyperedge（潜在超边）**  \
  &#x20;因为一个事件连着多个实体，它天然就像一条“超边”，但平时不画出来。  \
  &#x20;等查询来了，用 SQL 一联，这条超边才被“激活”。
- **SQL Join（SQL 连接）**\
  &#x20;数据库操作，把有共同字段的记录关联起来。\
  &#x20;在 SAG 里，就是通过“共享实体”把不同事件连起来，比如两个事件都提到“威尼斯”，它们就被连在一起。
- **Seed Retrieval（种子检索）**\
  &#x20;第一步先找“起点事件”。\
  &#x20;两条路：
  1. 用问题中的实体去数据库找；
  2. 用问题的语义向量去搜相似事件。
- **Query-time Expansion（查询时扩展）**\
  &#x20;从种子事件开始，“朋友的朋友也是朋友”。\
  &#x20;比如：种子事件提到实体 A → 找所有也提到 A 的事件 → 这些事件里可能藏着第二步需要的证据。\
  &#x20;默认只扩一轮，防止范围爆炸。
- **Final Selection（最终选择）**\
  &#x20;扩展得到很多候选事件后，让 LLM 通读这些候选，挑出最有用的事件（最多5个），再把对应的原始文本返回给回答阶段。
- **Dual-path Output（双路径输出）**\
  &#x20;最后答案由两路组成：
  - **结构路径**：通过实体关系扩展来的事件； &#x20;
  - **语义路径**：直接相似度最高的文本。\
    &#x20;两者合并，互相补充。
- **Bounded Activation（有界激活）**\
  &#x20;不把整个语料库都翻一遍，而是先通过向量检索圈定一个小范围（比如前500篇），然后只在这个范围内做 SQL 扩展和 LLM 选择，控制计算成本。

---

### 三、评估指标类

- **Recall@k（召回率@k）**\
  &#x20;每道题返回前 k 个结果，如果正确答案在里面，就算命中。\
  &#x20;比如 Recall@5 = 80%，意思是 100 道题里，有 80 道题所需证据都出现在前5个结果中。
- **F1**\
  &#x20;综合“找得准不准（精确率）”和“找得全不全（召回率）”的一个分数，最高100分，越高越好。
- **EM（Exact Match）**\
  &#x20;生成的答案和标准答案**一字不差**才算对。很严格。
- **LLM-as-a-judge（用LLM当评委）**  \
  &#x20;让另一个 AI 模型来判断回答好不好，打分维度包括答案正确性、覆盖度、上下文相关性等。

---

### 四、其他方法和技术名词

- **Embedding（嵌入/向量化）**\
  &#x20;把一段文字变成一串数字，意思相近的文字，数字也相近。\
  &#x20;这样就能用数学办法算“相似度”。
- **HNSW**\
  &#x20;一种快速搜索向量的算法。相当于给海量向量建了立体的“导航”，能在超大库里快速找到最像的几个。
- **Personalized PageRank（个性化网页排名）**\
  &#x20;一种图上排序算法：从一个起点出发，沿着关系传播分数，分数高的节点就是“和你起点有关”的节点。\
  &#x20;HippoRAG 2 用这个方法，但分数越传越弱，所以长链条证据容易丢。
- **GraphRAG / HyperGraphRAG / LightRAG 等**\
  &#x20;这些是论文对比的其他方法。它们要么预先建知识图谱，要么建超图，维护成本高；SAG 则是查询时才动态连接。
- **BM25**\
  &#x20;传统关键词检索算法，根据词频等计算文档和查询的匹配程度，速度快但不懂语义。
- **Entity Disambiguation（实体消歧）**\
  &#x20;把“苹果公司”和“Apple Inc.”识别成同一个实体。  \
  &#x20;论文**故意不做完整的消歧**，只做简单的字符串统一和去重，因为这样能保证数据持续快速写入，不会因为要全局整理而卡住。

---

### 总结

> SAG 就像给每个文档块贴一张卡片，正面写“事件”，背面写“涉及的实体”。查询时先找几张相关的卡片，再用背面共同的实体把更多卡片串起来，最后让 AI 挑出最管用的几张，回去翻原文回答你。它不建知识图谱，所以新文档随时能加，成本低又扛得住持续增长。

## 六、两张总览图：方法对比与整体架构

### 1. NaiveRAG、GraphRAG 与 SAG 的方法对比
![sag-00-paradigm-comparison.png](https://developer.qcloudimg.com/http-save/yehe-11976585/2a971d6cb9c63d0f7ce58ca0e545aa8f.png)

**图 A：三种 RAG 范式对比（保留所提供原图）。** 先从这张图了解三种方法如何组织和检索知识，再阅读后面的细化流程。右侧的速度、成本等标签是图中的定性概括，具体表现需要结合论文实验配置理解。

### 2. SAG 的离线建库与在线查询整体架构

![sag-00-architecture-overview.png](https://developer.qcloudimg.com/http-save/yehe-11976585/cf6f8c77ffacab3eb9540325abfffb07.png)


**图 B：SAG 整体架构（保留所提供原图）。** 上半部分展示离线建库，下半部分展示在线检索与输出。图中的“最多 5 个结构事件”和“语义路径补齐到 10 块”，在后面的查询下半段细图中展开说明。

## 七、三张图看懂 SAG 的核心技术流程

前面介绍了技术名词，接下来把建库和查询拆开，沿着数据实际流动的顺序看一遍。

三张图依据论文正文第 3 节、实验分析及附录整理。图中的存储字段是便于理解的逻辑示意，不代表项目源码的完整物理表结构。

### 1. 建库细化版：抽取什么、存在哪里、仅追加有什么代价？

![sag-01-indexing.png](https://developer.qcloudimg.com/http-save/yehe-11976585/4eefe3f155efd722b1a87f11d128ad21.png)


**图 1：建库链路。事件负责压缩语义，实体负责关联，原始文档块负责提供证据。**

每个文档块通过一次结构化大模型调用，产出一个综合事件和相应实体。为了直观看到抽取结果，可以看下面这个简化示例，外层结构参照附录示例，内容为讲解构造：

```json
{
  "type": "response",
  "data": {
    "items": [
      {
        "title": "Xiaoming's residence",
        "content": "Xiaoming lives in City A.",
        "entities": [
          {
            "type": "person",
            "name": "Xiaoming",
            "description": "The person who lives in City A."
          },
          {
            "type": "location",
            "name": "City A",
            "description": "The city where Xiaoming lives."
          }
        ],
        "is_valid": true
      }
    ]
  }
}
```

实体的角色或关系写在 `description` 中，附录给出的实体字段是 `type / name / description`，没有单独的 `role` 字段。无法抽取事实时，模型返回无效标记和空实体列表。

存储关系可以概括为：

| 逻辑对象 | 关键内容示意 | 作用 |
| --- | --- | --- |
| 原始文档块 | `chunk_id`、原文、来源信息 | 保存最后用于回答的证据 |
| 事件记录 | `event_id`、事件文本、`chunk_id` | 保存简洁描述，并映射回原文 |
| 事件—实体关联 | `(event_id, entity_key)` | 支持从事件找实体、从实体找事件 |
| 向量与全文索引 | 事件、实体及文档块相关检索内容 | 支持种子召回、候选排序和原文直检 |

一个事件关联多个实体，一个实体又可以关联多个事件，因此整体是多对多关系。把同一事件的关联行聚合起来，就能还原它的实体集合；事件文本则保留这些实体在该事件中的关系语义。

建库侧的关键取舍是：**只做字符串规范化和去重，不做完整的全局实体消歧与别名解析。** 因而 `Apple Inc.` 与 `Apple` 不会因为现实中可能指向同一家公司，就自动变成同一个连接键。实体相似度召回可能提供补充，但它不能保证补齐所有别名连接。

这样，新文档块可以独立处理并追加记录，无须先重新整理全库实体或重建全局图。附录中的抽取输入可以携带前一文档块的上下文以解析指代，所以这里的“独立处理”也不等于完全不读取相邻文本。

**仅追加的代价有两类：实体别名可能导致连接缺失；旧事件又缺少修订与淘汰机制。** 此外，追加仍然需要模型抽取、向量计算和索引写入，实际数据库也可能发生锁等待或排队，因此不能把它理解成“写入永不阻塞”。

### 2. 查询上半段：为什么有两个阈值，一轮扩展又走了几跳？

![sag-02-retrieval-expansion.png](https://developer.qcloudimg.com/http-save/yehe-11976585/796e421cc712dbc2986e8d2cffd87e54.png)


**图 2：两路召回找到起点，SQL 扩展补充与起点存在共享实体的事件。**

先区分两种工作集设置：论文主要实验使用完整检索池，即 `D_q = D`；采用有界激活时，先从全库向量索引中取出 `K_pool` 个文档块，再把后续事件与实体操作限制在这个范围内。这里的 HNSW 是全库索引上的近似最近邻搜索，不是逐条扫描全部文档块。

接着同时进行两路种子召回：

- **实体路径**：从问题中识别实体集合 `Q`，用实体向量相似度扩充为 `Q̂`，再通过 SQL 找到关联事件 `R_ent`。
- **事件路径**：直接用问题向量召回语义相关的事件 `R_evt`。

两路使用不同的相似度阈值，有各自的目的：

| 路径 | 默认阈值 | 设计考虑 |
| --- | --- | --- |
| 实体相似度匹配 | `τ_ent = 0.9` | 实体名称通常较短，过于宽松容易把不同实体混为一谈，因此采用较保守的匹配门槛 |
| 事件语义召回 | `τ_evt = 0.4` | 事件是较长的语义陈述，先保留较多候选，把精度控制留给后续排序与选择 |

这两个值是论文采用的默认配置，不代表匹配正确的概率，也不应脱离所用向量模型直接照搬到所有系统。

种子集合并后，扩展沿着下面的路径执行：

```text
R = R_ent ∪ R_evt

当前事件
  → 反向 SQL join：收集关联实体
  → 排除已探索实体，并按前沿预算剪枝
  → 再次 SQL join：查找关联的未访问事件
  → 新增事件集合 X

C = R ∪ X
```

从数学结构看，事件和实体构成一张二部图。**一次“事件 → 实体 → 事件”是二部图上的两跳，对应一轮扩展。** 进行 `L` 轮扩展，新增事件相对种子的距离至多为 `2L` 跳。

这是距离上界。由于系统会剪枝并限制预算，它不保证找全这个距离内的所有事件。扩展轮数也不能直接等同于问答问题中的推理跳数：一个事件可能已经包含多个相互关联的事实要素。

论文默认使用 `L = 1`。在 MuSiQue 消融实验中，增加到 `L = 2～4`，Recall@5 与一轮扩展的差异不超过 0.35 个百分点。这支持的是当前实验设置下“一轮已取得大部分收益”，而不是所有数据集都只需要一轮。

### 3. 查询下半段：先粗排，再动态分配两路输出

![sag-03-selection-output.png](https://developer.qcloudimg.com/http-save/yehe-11976585/f9b1f7abdcfb69df6c1ddbc4f8b3e300.png)

**图 3：结构路径最多选 5 个事件，语义路径补齐剩余文档块，检索默认输出 10 块。**

候选池 `C` 建好后，SAG 根据查询与事件的向量相似度做粗排，默认保留 `K_cand = 100` 个事件交给大模型。

大模型结合候选上下文，选出能够共同支持答案的一组事件。事件之间可能互相补充，所以这里采用联合选择，而不是只给每个事件单独打分。

论文在 MuSiQue 上的消融结果也说明了这一步的作用：把上下文联合选择替换成 Qwen3-Reranker-8B 的逐点排序后，Recall@5 从 80.36% 降到 67.11%，减少 13.25 个百分点。这是该实验配置下的对比结果，不能推广成所有重排模型的通用差距。

接下来是最容易读错的配额关系：

```text
|E_sel| ≤ K_event = 5
D_evt = 把选中的事件映射回原始文档块

K_direct(q) = K_out − |D_evt|
K_out = 10

D_out = D_evt ∪ TopK_direct(q)(R_chunk 去掉 D_evt 后的结果)
```

**5 个结构事件是上限，不是固定配额。** 语义路径填充的数量，要根据当前问题实际选出的结构文档块数量决定：

| 结构路径选中的原始文档块数 | 语义路径去重后补充数 | 默认检索输出总数 |
| --- | --- | --- |
| 0 | 10 | 10 |
| 3 | 7 | 10 |
| 5 | 5 | 10 |

这里还要区分检索接口与评测配置：检索流程默认返回 10 个文档块；论文附录列出的 QA 评测中，SAG 的 Reader 输入是 Top-5 原始段落。不能把 `K_out = 10`、Recall@5 和 Reader 的 Top-5 输入混成同一个参数。

候选预算也有收益与开销的取舍。MuSiQue 上，`K_cand` 从 50 增至 100，Recall@5 提高 1.01 个百分点，F1 提高 0.74 个百分点，同时每题 token 消耗增加 40.1%，端到端延迟增加 10.4%。从 100 继续增至 500，Recall@5 再提高 1.88 个百分点；前面的成本增幅对应的是 **50 → 100**，不能套用到 **100 → 500**。

## 八、参数速查表

下表整理论文主实验的默认配置，以及有界激活分析中需要单独区分的参数。预算用于控制不同阶段的规模，不能互相替代。

| 参数 | 默认值或实验设置 | 控制什么 | 阅读时要注意 |
| --- | --- | --- | --- |
| `τ_ent` | 0.9 | 实体向量相似扩展的门槛 | 较保守的实体匹配阈值，不是置信概率 |
| `τ_evt` | 0.4 | 查询向量直接召回事件的门槛 | 先保证召回，再交给后续筛选 |
| `K_seed` | 50 | 种子阶段预算 | 与最终送入 LLM 的候选预算不同 |
| 前沿实体预算 | 50 | 一轮扩展中继续探索的实体数量 | 剪枝后不保证枚举全部可达事件 |
| `L` | 1 | 事件—实体—事件扩展轮数 | 一轮对应二部图两跳，不等于一道题的一跳推理 |
| `K_pool` | 主结果使用完整检索池；有界激活分析中包括 500 等设置 | 当前查询激活的原始文档块数量 | 500 是文档块数；不是主实验统一默认值 |
| `K_cand` | 100 | 粗排后送给 LLM 联合选择的候选事件数 | 50 是论文讨论的更节省开销的替代配置 |
| `K_event` | 5 | 结构路径最多选择的事件数 | 上限，不是必须填满的固定名额 |
| `K_out` | 10 | 检索流程最终返回的文档块数 | 两路合并、去重后的输出 |
| `K_direct(q)` | `10 − |D_evt|` | 当前问题由语义路径补充的文档块数 | 随实际结构选择数量浮动 |
| Reader 模型 | Qwen3.6-Flash | 根据检索上下文生成答案 | 论文 QA 评测输入为 Top-5 原始段落 |
| 嵌入模型 | BGE-Large-EN-v1.5 | 主实验中的语义检索与粗排 | 论文另有替换嵌入模型的稳健性实验 |

有界激活分析中，在 MuSiQue 上取 `K_pool = 500` 时，Recall@5 为 79.57%；完整 11,656 块检索池对应 80.36%。这说明该设置用较小工作集保留了约 99% 的完整检索池召回水平，但它不等于已经证明任意规模、任意语料都可以固定只取 500 块。

## 参考资料

- 论文：[SAG: SQL-Retrieval Augmented Generation with Query-Time Dynamic Hyperedges](https://arxiv.org/abs/2606.15971v2)，本文依据用户提供的 v2 PDF 整理。
- 论文列出的评测项目：[SAG-Benchmark](https://github.com/Zleap-AI/SAG-Benchmark)。
- 论文列出的工程项目：[SAG](https://github.com/Zleap-AI/SAG)。


今天讲的是 SAG（SQL 检索增强生成），一种让 AI 在回答复杂问题时，能从一堆文档里“顺藤摸瓜”找到证据的技术。

SAG讲解

人工智能

SAG（SQL检索增强生成）是一种查询时动态构建超边的新型RAG技术。它不预先构建知识图谱，而是为每个文档块抽取“事件+实体”并存入数据库。查询时通过实体与语义双路径召回种子事件，再利用SQL连接沿共享实体扩展证据链，最后让LLM从候选中联合选出关键事件。相比GraphRAG，SAG建库成本低、支持流式追加，在MuSiQue基准上Recall@5达80.36%。

知识图谱

代码解释

数据库

GraphRAG

ChatGPT

2026上云采购 | AI焕新·智启新局

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

SAG（SQL检索增强生成）是一种查询时动态构建超边的新型RAG技术。它不预先构建知识图谱，而是为每个文档块抽取“事件+实体”并存入数据库。查询时通过实体与语义双路径召回种子事件，再利用SQL连接沿共享实体扩展证据链，最后让LLM从候选中联合选出关键事件。相比GraphRAG，SAG建库成本低、支持流式追加，在MuSi...

SAG讲解-腾讯云开发者社区-腾讯云

SAG讲解

SAG讲解

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐