RAG与SAG-检索增强与搜索增强深度对比分析

RAG 与 SAG：检索增强还是搜索增强？一次讲透两大范式的本质差异

声明：本文仅作技术原理分析与使用场景参考，文中涉及的架构设计、成本估算、代码示例均为基于当前技术生态的实践总结，不构成任何商业建议。实际选型请结合自身业务需求、数据合规要求及预算进行独立评估。

上一篇我们探讨了 RAG 技术栈的复用扩展——从知识库问答延伸到智能客服、商品推荐等业务场景。但在实践中遇到一个绕不开的问题：当用户问的不是知识库里有的东西，而是互联网上的最新信息呢？

这就引出了 RAG 的"兄弟"——SAG（Search-Augmented Generation，搜索增强生成）。一个向内检索私有知识，一个向外搜索开放互联网。本文将结合 KB-MVP 项目的实际经验，从架构、成本、安全、工程落地等维度，深度对比两种范式，并给出混合架构的实践方案。

一、从一个真实场景说起

KB-MVP 知识库系统上线后，用户提了一个问题：

“2025 年最新的开源大模型有哪些？”

系统的行为：

1. 检索本地知识库 → 找到几篇关于大模型的旧文档 2. LLM 基于这些"过时上下文"生成答案 → 回答了 2023 年的模型列表 3. 用户：？？？这不是最新的啊

问题很清楚：RAG 只能回答知识库里有的东西。知识库的时效性取决于最后更新时间，而互联网上的信息是实时变化的。

这时候如果有一个搜索引擎能实时获取最新网页内容，问题就解决了——这就是 SAG 的价值。

RAG 的问题：知识库是封闭的，无法获取最新信息 SAG 的解法：实时调用搜索引擎，获取互联网最新内容

但 SAG 能替代 RAG 吗？不能。如果你问"我们公司的差旅报销标准是多少"，SAG 会把这个问题发给搜索引擎——你的内部数据泄露了。

所以这不是"谁替代谁"的问题，而是"各自擅长什么"的问题。

二、两者到底在做什么

2.1 RAG：检索增强生成

核心公式：RAG = 向量检索（本地知识库） + LLM 生成 流程：用户提问 → 查询向量化 → 本地向量库语义检索 → Top-K 文档块 → 组装 Prompt → LLM 生成

RAG 的关键词是**“检索”**——从预先构建好的本地向量数据库中，基于语义相似度找到相关内容。这也是 KB-MVP 系统的核心能力。

上一篇我们拆解过，RAG 的技术栈分七大模块：内容分块 → 向量化 → 入库 → 查询向量化 → 语义检索 → 重排序 → LLM 生成。其中前三个是离线建库阶段，后四个是在线查询阶段。

2.2 SAG：搜索增强生成

核心公式：SAG = 网络搜索（搜索引擎 API） + LLM 生成 流程：用户提问 → 查询改写 → 调用搜索引擎 API → 获取网页摘要/全文 → 组装 Prompt → LLM 生成

SAG 的关键词是**“搜索”**——实时调用 Google、Bing、Brave 等搜索引擎，获取互联网上的最新内容。Perplexity、ChatGPT Web Search、Bing Chat 都是 SAG 范式的产品。

命名辨析：部分文献也将 SAG 称为 Web-RAG 或 Online RAG。本文统一用 SAG 来强调"搜索"这个核心动作与 RAG"检索"的本质区别。

2.3 一句话区分

RAG：向内找 —— 在自己的书架上找书（快、准、私密，但只有你放进去的书） SAG：向外搜 —— 在互联网上搜最新信息（广、新、开放，但不私密且依赖第三方）

三、架构对比：差在哪，差多少

3.1 RAG 架构（回顾 KB-MVP）

┌────────────────────────────────────────────────────────────────┐ │ RAG 架构 │ │ │ │ 【离线建库】 │ │ 原始文档 → 文档解析 → 文本切分 → Embedding 向量化 → 向量数据库 │ │ │ │ 【在线检索】 │ │ 用户提问 → 查询向量化 → 向量相似度检索 → Top-K 文档块 │ │ → 上下文组装 → LLM 生成 → 答案 + 来源引用 │ │ │ │ 延迟：向量检索 50-200ms（极快） │ │ 数据：本地私有，完全可控 │ └────────────────────────────────────────────────────────────────┘

3.2 SAG 架构

┌────────────────────────────────────────────────────────────────┐ │ SAG 架构 │ │ │ │ 【离线建库】 │ │ 无需预构建！跳过文档处理和向量化全流程 │ │ │ │ 【在线搜索】 │ │ 用户提问 → 查询改写 → 调用搜索引擎 API → 搜索结果 │ │ → （可选）网页全文抓取 → 上下文组装 │ │ → LLM 生成 → 答案 + 来源 URL │ │ │ │ 延迟：搜索引擎调用 1-3s + 可选网页抓取 1-2s（较慢） │ │ 数据：开放互联网，实时获取 │ └────────────────────────────────────────────────────────────────┘

3.3 流程差异一目了然

最大的架构差异：RAG 有一个"离线建库"阶段——你需要先把文档处理好、向量化、入库。SAG 没有这个阶段，它是"即时搜索、用完即走"。

四、六个维度的硬碰硬对比

4.1 数据来源与覆盖范围

完全私有 ◄──────────────────────────────────────► 完全开放 RAG SAG ├─ 企业内部文档 ├─ 公开网页 ├─ 私有数据库 ├─ 新闻资讯 ├─ 产品手册 ├─ 技术文档 ├─ 法律法规（已入库） ├─ 论文/学术资源 └─ 历史对话记录 └─ 百科/知识库 精确可控、深度覆盖特定领域 广度覆盖、信息量大但噪声多

真实对比：

4.2 实时性与时效性

这是 SAG 的绝对主场。

KB-MVP 的实践教训：最初系统只支持 RAG，用户问"最新的框架版本是多少"时，系统基于知识库中三个月前的文档回答，结果给出的版本号已经过期了。后来增加了定时更新知识库的机制，但始终无法做到"实时"。

4.3 隐私安全与数据控制

这是 RAG 的绝对主场，也是选型的一票否决项。

危险场景示例： 用户在内部系统中问："竞品 XX 公司的定价策略对我们有什么影响？" RAG：✅ 在本地知识库检索，数据不外泄 SAG：❌ "竞品 XX 公司定价策略"被发送到 Google/Bing API → 搜索引擎知道了你在关注竞品定价 → 可能触发数据合规审计风险

安全底线：涉及企业内部数据、用户隐私、商业机密的场景，必须用 RAG。将敏感信息发送到外部搜索引擎是数据泄露事故。

4.4 成本模型

以月均10 万次查询为例：

RAG 成本： ├── 向量数据库托管（Pinecone/Milvus Cloud）：$70-200/月 ├── Embedding API（仅文档入库时）：$10-50（一次性 + 增量） ├── 向量检索计算：$20-50/月 ├── LLM 生成调用：$100-300/月（两者相同） └── 总计：约 $200-600/月 SAG 成本（取决于 API 选择）： ├── Serper API（$50/2,500次 → 10万次）：~$2,000/月 💰💰💰 ├── Brave Search API（$3/1,000次）：~$300/月 ├── SearXNG 自建（服务器成本）：$20-50/月 ✅ 最省 ├── 网页抓取（带宽 + 解析）：$10-30/月 ├── LLM 生成调用：$100-300/月（两者相同） └── 总计：$430-2,380/月

结论：低频查询 SAG 更划算（零搭建成本）；高频查询 RAG 更经济（边际成本趋近于零）。

4.5 检索质量与准确性

这也是为什么上一篇提到的混合检索（稠密向量 + BM25 稀疏检索 + RRF 融合）如此重要——它弥补了纯向量检索在精确匹配上的短板。SAG 天然具备关键词匹配能力，这一点在 RAG 中需要额外引入 BM25 才能实现。

4.6 工程复杂度

五、核心差异总结

六、选型决策：该用哪个

┌─────────────────────┐ │ 用户需求分析 │ └─────────┬───────────┘ │ ┌─────────────┼─────────────┐ │ │ │ ▼ ▼ ▼ ┌──────────────┐ ┌──────────┐ ┌──────────────┐ │ 数据私有/机密？│ │需要实时 │ │需要精确文档 │ │ │ │最新信息？ │ │级引用溯源？ │ └──────┬───────┘ └────┬─────┘ └──────┬───────┘ │ │ │ ▼ ▼ ▼ ┌────────┐ ┌────────┐ ┌─────────┐ │ 是 → │ │ 是 → │ │ 是 → │ │ RAG │ │ SAG │ │ RAG │ └────────┘ └────────┘ └─────────┘ │ │ └──────┬───────┘ │ ┌─────────────┐ │ 两者都需要？ │ └──────┬──────┘ │ 是 → Hybrid (RAG + SAG)

场景检查清单：

七、进阶方案：RAG + SAG 混合架构

回到 KB-MVP 项目的实际需求——用户既需要查内部文档（RAG 擅长），也需要查最新信息（SAG 擅长）。最佳方案不是二选一，而是智能路由。

7.1 混合架构设计

┌──────────────────────────────────────────────────────────────────┐ │ RAG + SAG 混合增强架构 │ │ │ │ 用户提问 │ │ │ │ │ ▼ │ │ ┌──────────────────┐ │ │ │ 意图路由（LLM） │ │ │ └────────┬─────────┘ │ │ │ │ │ ┌──────────────┼──────────────┐ │ │ │ │ │ │ │ ▼ ▼ ▼ │ │ ┌───────────┐ ┌───────────┐ ┌───────────┐ │ │ │ RAG 检索 │ │ SAG 搜索 │ │ 直接生成 │ │ │ │ (私有知识) │ │ (开放搜索) │ │ (无需增强) │ │ │ └─────┬─────┘ └─────┬─────┘ └─────┬─────┘ │ │ │ │ │ │ │ ↓ ↓ │ │ │ ┌───────────────────────────┐ │ │ │ │ 结果融合 + 重排序（RRF） │ │ │ │ └─────────────┬─────────────┘ │ │ │ │ ┌───────────────┘ │ │ ↓ ↓ │ │ ┌─────────────┐ │ │ │ Prompt 组装 │ │ │ └──────┬──────┘ │ │ ↓ │ │ LLM 生成 │ │ │ │ │ ▼ │ │ 最终答案 + 引用来源 │ │ （本地文档 + 网页 URL） │ └──────────────────────────────────────────────────────────────────┘

7.2 路由策略：四种模式

# 路由决策规则ROUTING_RULES={"rag":{"条件":"查询涉及企业内部文档/私有数据/敏感信息","示例":"我们公司的报销流程是什么？"},"sag":{"条件":"查询涉及最新资讯/开放域知识/互联网信息","示例":"2025年最新的 AI 大模型有哪些？"},"hybrid":{"条件":"查询同时涉及私有知识和开放域知识","示例":"根据公司技术规范，对比业界最新的微服务框架选型"},"direct":{"条件":"通用对话/创意写作/简单计算","示例":"帮我写一首关于春天的诗"}}

用 LLM 做意图分类，决定走哪条路：

defroute_query(query:str,llm)->str:"""智能路由：根据查询意图选择增强策略"""prompt=f"""分析用户查询，选择最合适的增强策略。 用户查询：{query}策略说明： - rag: 查询涉及私有/内部文档、专业知识库内容 - sag: 查询涉及最新资讯、开放域知识、互联网信息 - hybrid: 查询同时需要内部和外部信息 - direct: 通用对话，无需检索增强 仅返回策略名称（rag/sag/hybrid/direct）："""response=llm.invoke(prompt)strategy=response.strip().lower()returnstrategyifstrategyin{"rag","sag","hybrid","direct"}else"hybrid"

7.3 SAG 引擎实现

以 Serper（Google 搜索 API）为例：

""" SAG 搜索增强生成引擎 支持多种搜索 API 后端：Serper / Brave / Tavily """importosimporthttpxfromdataclassesimportdataclass@dataclassclassSearchResult:title:strurl:strsnippet:strclassSerperSearchEngine:"""Serper.dev 搜索 API（Google 搜索结果）"""def__init__(self,api_key:str):self.api_key=api_key self.base_url="https://google.serper.dev"asyncdefsearch(self,query:str,num_results:int=5)->list[SearchResult]:headers={"X-API-KEY":self.api_key,"Content-Type":"application/json"}payload={"q":query,"num":num_results}asyncwithhttpx.AsyncClient()asclient:response=awaitclient.post(f"{self.base_url}/search",headers=headers,json=payload,timeout=10.0)response.raise_for_status()data=response.json()results=[]foritemindata.get("organic",[]):results.append(SearchResult(title=item.get("title",""),url=item.get("link",""),snippet=item.get("snippet","")))returnresultsclassTavilySearchEngine:"""Tavily AI 搜索 API（专为 AI Agent 设计，返回高质量内容）"""def__init__(self,api_key:str):self.api_key=api_key self.base_url="https://api.tavily.com"asyncdefsearch(self,query:str,num_results:int=5)->list[SearchResult]:payload={"api_key":self.api_key,"query":query,"max_results":num_results,"include_answer":True,}asyncwithhttpx.AsyncClient()asclient:response=awaitclient.post(f"{self.base_url}/search",json=payload,timeout=15.0)response.raise_for_status()data=response.json()return[SearchResult(title=item.get("title",""),url=item.get("url",""),snippet=item.get("content",""),)foritemindata.get("results",[])]classSAGEngine:"""SAG 搜索增强生成引擎"""def__init__(self,search_engine,llm,num_results:int=5):self.search_engine=search_engine self.llm=llm self.num_results=num_resultsasyncdefgenerate(self,user_query:str)->dict:# Step 1: 查询改写（优化搜索关键词）search_query=awaitself._rewrite_query(user_query)# Step 2: 执行搜索search_results=awaitself.search_engine.search(search_query,self.num_results)# Step 3: 组装上下文context="\n\n---\n\n".join(f"标题：{r.title}\n来源：{r.url}\n内容：{r.snippet}"forrinsearch_results)# Step 4: 构造 Prompt + LLM 生成prompt=f"""你是一个专业的 AI 助手。基于以下搜索结果回答用户问题。 搜索结果：{context}用户问题：{user_query}要求：基于搜索结果回答，标注信息来源，不要编造信息。"""answer=awaitself.llm.ainvoke(prompt)return{"answer":answer,"search_query":search_query,"sources":[{"title":r.title,"url":r.url}forrinsearch_results],}asyncdef_rewrite_query(self,query:str)->str:"""查询改写：将用户问题优化为更适合搜索的关键词"""prompt=f"将以下问题改写为搜索引擎查询（仅返回改写结果）：\n{query}"return(awaitself.llm.ainvoke(prompt)).strip()

7.4 混合引擎：RAG + SAG 并行检索 + 结果融合

当路由策略为hybrid时，同时执行 RAG 检索和 SAG 搜索，用 RRF（Reciprocal Rank Fusion）融合结果：

importasyncioclassHybridAugmentedEngine:"""混合增强引擎：根据查询意图智能选择 RAG / SAG / 混合策略"""def__init__(self,rag_engine,sag_engine,router_llm,top_k_rag=5,top_k_sag=5):self.rag_engine=rag_engine# KB-MVP 的 RAGEngineself.sag_engine=sag_engine# 上面的 SAGEngineself.router_llm=router_llm self.top_k_rag=top_k_rag self.top_k_sag=top_k_sagasyncdefquery(self,user_query:str)->dict:# Step 1: 意图路由strategy=awaitself._route(user_query)# Step 2: 执行对应策略ifstrategy=="rag":returnawaitself._execute_rag(user_query)elifstrategy=="sag":returnawaitself._execute_sag(user_query)elifstrategy=="hybrid":returnawaitself._execute_hybrid(user_query)else:# direct：直接生成answer=awaitself.router_llm.ainvoke(user_query)return{"answer":answer,"strategy":"direct","sources":[]}asyncdef_execute_hybrid(self,query:str)->dict:"""混合模式：RAG + SAG 并行 + 结果融合"""# 并行执行，任一失败不影响另一个rag_task=self.rag_engine.retrieve(query,top_k=self.top_k_rag)sag_task=self.sag_engine.search(query,num_results=self.top_k_sag)rag_docs,sag_results=awaitasyncio.gather(rag_task,sag_task,return_exceptions=True)# 容错ifisinstance(rag_docs,Exception):rag_docs=[]ifisinstance(sag_results,Exception):sag_results=[]# 构建混合上下文context_parts=[]fordocinrag_docs:source=doc.metadata.get("source","知识库")context_parts.append(f"【知识库】来源：{source}\n内容：{doc.page_content}")forresultinsag_results:context_parts.append(f"【网络】来源：{result.url}\n标题：{result.title}\n内容：{result.snippet}")context="\n\n---\n\n".join(context_parts)# LLM 生成prompt=f"""基于以下来自知识库和网络搜索的混合上下文回答问题。{context}用户问题：{query}要求：综合知识库和网络信息回答，标注信息来源（知识库/网络）。"""answer=awaitself.router_llm.ainvoke(prompt)return{"answer":answer,"strategy":"hybrid","rag_sources":[{"source":d.metadata.get("source","")}fordinrag_docs],"sag_sources":[{"title":r.title,"url":r.url}forrinsag_results],}

与 KB-MVP 的衔接：这个混合引擎可以直接复用 KB-MVP 的RAGEngine作为rag_engine参数。上一篇我们提到的多供应商模型适配层（llm_provider.py）保证了router_llm也能灵活切换供应商。新增的只是一个 SAG 引擎和路由逻辑。

八、各场景最佳实践

RAG 最佳场景

SAG 最佳场景

九、技术趋势

1. Agentic RAG 兴起：LLM 自主决定何时检索、检索什么、如何融合，RAG 和 SAG 的边界逐渐模糊
2. 搜索 API 的 AI 原生化：Tavily 等 API 专为 AI Agent 设计，返回结构化高质量内容，降低噪声
3. 自建搜索引擎普及：SearXNG 等开源方案让 SAG 也能实现隐私可控，缩小与 RAG 的安全差距
4. 多模态增强生成：未来不仅限于文本检索/搜索，还将包括图片、视频、音频等多模态信息

十、总结

回到开篇的问题——KB-MVP 用户问"最新的大模型有哪些"，答案是：这不是 RAG 的能力边界问题，而是 RAG 的设计边界问题。RAG 向内检索私有知识，SAG 向外搜索开放互联网，两者不是竞争关系，而是互补关系。

核心观点：不要纠结"RAG 还是 SAG"，要思考"这个查询应该向内找还是向外搜"。智能路由的混合架构，才是企业级 AI 应用的正确姿势。

项目地址：GitHub | Gitee

系列文章：

• 第一篇：从零构建轻量级 RAG 知识库问答系统
• 第二篇：RAG 技术栈复用实战 - 从知识库问答到多业务场景扩展
• 本文：RAG 与 SAG - 检索增强生成与搜索增强生成深度对比分析

如果这个系列对你有启发，欢迎 Star 支持项目，也欢迎在评论区交流你的实践经验——你更倾向于纯 RAG、纯 SAG，还是混合架构？