RAG + Agent:检索增强如何让智能体“更像懂业务的人”
RAG + Agent:检索增强如何让智能体“更像懂业务的人”
引言
痛点引入
你有没有见过这样的智能体翻车现场?
- 公司内部上线的行政助手,员工问“2024年最新的病假工资怎么算”,它一本正经给你念2020年的旧规则,导致员工和HR扯皮半天;
- 金融机构的智能投顾,用户问“我有100万闲钱怎么理财”,它给你推荐已经清盘的基金产品,甚至违反监管规定承诺“保本保收益”;
- 制造业的设备运维助手,工程师问“某型号伺服电机报错E03怎么处理”,它瞎编一个维修步骤,差点导致生产线停摆损失上百万。
这些问题的核心根本不是大模型不够聪明,而是通用大模型的“知识边界”和业务场景的“专属需求”之间存在不可逾越的鸿沟:大模型的训练数据有 cutoff 时间,不知道上线后新增的业务规则;没有行业专属数据,不懂细分领域的专业术语;生成内容不可控,很容易出现幻觉给业务带来风险。
过去一年里我们团队做了12个不同行业的Agent落地项目,最深的感受是:90%的业务场景Agent落地失败,不是因为规划能力、工具调用能力不够,而是因为它“不懂业务”。
解决方案概述
而检索增强生成(RAG)正是解决Agent“不懂业务”问题的最优解:它不需要重新训练大模型,只需要把业务知识库做成向量索引,在Agent工作的全链路动态注入相关的业务知识,就能让Agent像拥有了专属“业务手册”一样,给出符合规则、贴合场景、可溯源的回答。
我们去年给某头部电商做的售后智能Agent,上线前纯大模型方案的业务问题准确率只有62%,幻觉率高达41%;接入RAG之后准确率提升到94%,幻觉率降到5%以下,替代了70%的人工客服工作量,单年节省成本超过2000万。
文章脉络
本文我会从基础概念讲起,拆解RAG和Agent的融合逻辑,手把手教你搭建一套懂业务的RAG+Agent系统,结合实际落地案例分享避坑经验,最后展望未来的发展趋势。全文包含2张架构图、3个核心公式、1套可直接运行的Demo代码、4个行业落地案例、1份发展趋势盘点,适合所有正在做Agent落地的技术人员、产品经理、业务负责人阅读。
基础概念与问题本质
核心概念定义
什么是智能体(Agent)
大模型Agent是指能自主感知环境、做出决策、调用工具完成特定目标的智能系统,核心组件包括四个部分:
- 感知模块:接收用户输入、环境反馈等信息;
- 规划模块:把复杂目标拆解成多个子任务,制定执行路径;
- 记忆模块:存储短期交互记忆、长期知识记忆;
- 动作模块:调用工具、生成回答、执行具体操作。
什么是检索增强生成(RAG)
RAG是一种把检索系统和大模型结合的技术范式,核心流程是:先把外部知识库的内容切片、转换成向量存入向量数据库,用户提问时先从向量库检索相关的知识片段,再把片段和用户问题一起喂给大模型,让大模型基于检索到的知识生成回答,从根源上减少幻觉,提升内容的准确性和时效性。
问题背景:为什么Agent天生“不懂业务”
我们可以把大模型的知识来源分成三类,对比一下就能看出问题所在:
| 知识类型 | 来源 | 时效性 | 准确性 | 业务适配性 | 可解释性 |
|---|---|---|---|---|---|
| 预训练知识 | 大模型训练数据 | 截止到cutoff时间 | 通用场景高,细分场景低 | 差 | 不可溯源 |
| 微调注入知识 | 标注的业务数据 | 截止到微调时间 | 取决于标注质量 | 中等 | 不可溯源 |
| Prompt注入知识 | 对话时输入的上下文 | 实时 | 100%可控 | 高 | 可溯源 |
| 而Agent的“懂业务”能力要求恰恰是:实时更新、100%符合业务规则、可溯源可审计、能适配细分场景的个性化需求,前两种知识注入方式完全满足不了,只有Prompt注入的方式能达标——而RAG本质上就是自动化的、精准的Prompt业务知识注入系统。 |
问题边界:RAG+Agent能做什么,不能做什么
在正式讲融合方案之前,我们首先要明确技术的边界,避免盲目踩坑:
✅ 适合的场景
- 业务规则更新频繁,比如每月/每周都有新的政策、制度、产品上线;
- 对内容准确性要求高,比如金融、政务、医疗等不能出错的场景;
- 需要可解释性,回答必须有来源可溯源,符合监管要求;
- 业务数据敏感,不能把内部数据上传给大模型做微调。
❌ 不适合的场景
- 需要极高的推理效率,比如毫秒级响应的实时交易场景;
- 业务逻辑非常复杂,需要跨多个知识点做深度组合推理,比如复杂的财务报表审计;
- 交互场景极度固定,知识十年八年不更新,比如固定流程的工业控制场景。
RAG+Agent的核心融合原理
概念关系与架构设计
我们先看RAG和Agent核心组件的交互关系,用ER图表示如下:
整体的工作架构如下图所示:
核心数学模型
RAG对Agent的增强本质上是在Agent的推理全链路加入了业务知识的权重约束,我们可以用三个核心公式来描述这个过程:
1. 检索阶段的相似度计算
我们用余弦相似度计算用户问题向量和知识库片段向量的相关性:
sim(q,di)=q⋅di∥q∥∥di∥ sim(q, d_i) = \frac{q \cdot d_i}{\|q\| \|d_i\|} sim(q,di)=∥q∥∥di∥q⋅di
其中qqq是用户问题的embedding向量,did_idi是第iii个知识库片段的embedding向量,相似度越高说明片段和问题的相关性越强。
2. 知识注入的权重分配
检索到Top K个相关片段后,我们用带温度系数的Softmax计算每个片段的注入权重,确保相关性越高的片段权重越大:
wi=exp(sim(q,di)/τ)∑j=1Kexp(sim(q,dj)/τ) w_i = \frac{\exp(sim(q, d_i)/\tau)}{\sum_{j=1}^{K} \exp(sim(q, d_j)/\tau)} wi=∑j=1Kexp(sim(q,dj)/τ)exp(sim(q,di)/τ)
其中τ\tauτ是温度系数,取值范围0.1-1.0,τ\tauτ越小权重分布越集中,τ\tauτ越大权重分布越平均。
3. 增强后的Agent动作选择概率
RAG的结果会影响Agent的动作选择,我们把大模型本身的动作概率和RAG给出的业务规则约束概率加权结合:
P(a∣s)=αPllm(a∣s)+(1−α)Prag(a∣s) P(a|s) = \alpha P_{llm}(a|s) + (1-\alpha) P_{rag}(a|s) P(a∣s)=αPllm(a∣s)+(1−α)Prag(a∣s)
其中α\alphaα是权重系数,取值0-1,α\alphaα越大越依赖大模型本身的能力,α\alphaα越小越严格遵守RAG检索到的业务规则,比如金融监管场景我们会把α\alphaα设为0.1,几乎完全遵守业务规则。
RAG+Agent的三种融合模式
根据融合深度的不同,我们可以把RAG和Agent的融合分成三种模式,适合不同的业务场景:
| 融合模式 | 实现逻辑 | 开发难度 | 业务适配性 | 性能开销 | 适合场景 |
|---|---|---|---|---|---|
| 外挂式RAG | 把RAG作为Agent的一个工具,需要的时候调用 | 低 | 差 | 小 | 简单问答场景、MVP验证阶段 |
| 嵌入式RAG | RAG结果注入到Agent的所有模块的Prompt中,规划、生成、校验全链路增强 | 中 | 好 | 中等 | 大部分业务场景、正式上线阶段 |
| 共生式RAG | Agent的记忆和RAG知识库打通,Agent可以自主更新知识库内容,形成闭环 | 高 | 极佳 | 大 | 复杂多轮交互场景、智能运营场景 |
手把手搭建懂业务的RAG+Agent系统
准备工作
环境/工具依赖
| 工具/依赖 | 版本要求 | 用途 |
|---|---|---|
| Python | 3.10+ | 开发语言 |
| LangChain | 0.1.0+ | Agent和RAG开发框架 |
| Chroma | 0.4.0+ | 向量数据库 |
| OpenAI API / 国产大模型API | 无 | 大模型推理 |
| python-dotenv | 1.0.0+ | 环境变量管理 |
前置知识
你需要具备基础的Python开发能力,了解大模型API的基本使用,懂RAG的基本流程即可。
核心步骤:以电商售后Agent为例
我们本次要搭建的是一个电商售后智能Agent,能根据售后规则回答用户的问题,处理退货、换货、退款等申请,所有回答必须符合最新的售后规则,不能出现幻觉。
步骤1:业务知识库治理
知识库治理是RAG效果的核心,80%的RAG效果问题都是因为知识库治理不到位导致的。
1.1 知识分层
我们把售后知识库分成四层:
- 通用规则层:国家《消费者权益保护法》、平台通用售后规则,更新频率:每年1次;
- 品类规则层:不同品类的售后规则,比如服饰支持7天无理由,贴身衣物不支持,电子产品支持15天换货,更新频率:每季度1次;
- 活动规则层:大促期间的特殊售后规则,比如618期间退货周期延长到15天,更新频率:每月1次;
- 动态案例层:历史上的特殊售后案例,比如用户买的衣服洗过一次但有质量问题可以退,更新频率:每天1次。
1.2 切片与元数据设计
我们用语义切片代替固定长度切片,切片粒度控制在256-512token,每个片段都加上元数据:
{
"content": "服饰类商品支持7天无理由退货,前提是商品未损坏、不影响二次销售,贴身内衣、泳衣等特殊品类不支持7天无理由",
"metadata": {
"knowledge_level": "品类规则层",
"category": "服饰",
"effective_time": "2024-01-01",
"expire_time": "2099-12-31",
"permission_level": 1
}
}
1.3 向量入库
我们用OpenAI的text-embedding-3-small模型做embedding,把所有切片存入Chroma向量库。
步骤2:RAG检索链路优化
2.1 混合检索
我们用向量检索+BM25关键词检索结合的方式,提升召回率:
- 向量检索召回Top 15个相关片段;
- BM25检索召回Top 15个相关片段;
- 合并去重后得到最多25个候选片段。
2.2 重排序
我们用Cohere的重排序模型,把25个候选片段按照相关性排序,取Top 5个片段用于后续注入。
2.3 知识拼接
按照权重从高到低把5个片段拼接成上下文,加上来源标注,方便后续溯源。
步骤3:Agent模块与RAG融合开发
我们选择嵌入式RAG模式,在Agent的三个核心模块都注入RAG结果:
3.1 规划模块增强
在规划模块的Prompt里加入检索到的售后规则,告诉Agent什么场景下应该做什么操作,比如:
你是电商售后Agent,所有操作必须遵守以下规则:
{检索到的售后规则}
现在用户的问题是:{user_query}
请你把处理步骤拆解成最多3个任务,只能选择以下工具:[查询订单信息、申请退货、申请换货、回复用户]
3.2 工具调用校验
Agent选择工具后,RAG模块会校验工具调用的参数是否符合业务规则,比如用户的订单已经超过7天,Agent就不能调用7天无理由退货的接口,校验不通过就返回规划模块重新生成步骤。
3.3 回答生成与grounded校验
生成回答后,我们会校验回答里的所有信息是否都来自检索到的售后规则,如果有内容不在检索结果里,就判定为幻觉,重新生成回答,直到符合要求为止。
步骤4:效果评估与迭代
我们用三个核心指标评估效果:
- 业务准确率:回答符合业务规则的比例,目标≥95%;
- 幻觉率:回答出现不符合规则的内容的比例,目标≤3%;
- 召回率:相关业务知识被检索到的比例,目标≥98%。
每两周更新一次测试集,迭代优化切片策略、检索参数、Prompt模板。
核心实现源代码
# 安装依赖:pip install langchain langchain-openai langchain-chroma langchain-cohere python-dotenv
import os
from dotenv import load_dotenv
from langchain_community.vectorstores import Chroma
from langchain_openai import OpenAIEmbeddings, ChatOpenAI
from langchain_text_splitters import RecursiveCharacterTextSplitter
from langchain_community.retrievers import BM25Retriever
from langchain.retrievers import EnsembleRetriever
from langchain_cohere import CohereRerank
from langchain.agents import AgentExecutor, create_openai_tools_agent
from langchain.tools import tool
from langchain.prompts import ChatPromptTemplate
from langchain_core.documents import Document
# 加载环境变量
load_dotenv()
os.environ["OPENAI_API_KEY"] = os.getenv("OPENAI_API_KEY")
os.environ["COHERE_API_KEY"] = os.getenv("COHERE_API_KEY")
# ---------------------- 1. 知识库初始化 ----------------------
# 模拟售后知识库
售后知识库 = [
Document(page_content="服饰类商品支持7天无理由退货,前提是商品未损坏、不影响二次销售,贴身内衣、泳衣等特殊品类不支持7天无理由", metadata={"category":"服饰","effective_time":"2024-01-01"}),
Document(page_content="618大促期间(6月1日-6月20日)的订单,退货周期从7天延长到15天", metadata={"category":"活动规则","effective_time":"2024-06-01","expire_time":"2024-06-20"}),
Document(page_content="如果商品有质量问题,不管是否穿过洗过,都可以申请退货,运费由商家承担", metadata={"category":"特殊规则","effective_time":"2024-01-01"}),
Document(page_content="电子产品自签收之日起15天内出现质量问题可以换货,1年内免费保修", metadata={"category":"3C","effective_time":"2024-01-01"}),
]
# 语义切片
text_splitter = RecursiveCharacterTextSplitter(chunk_size=512, chunk_overlap=64)
split_docs = text_splitter.split_documents(售后知识库)
# 初始化向量库
embeddings = OpenAIEmbeddings(model="text-embedding-3-small")
vector_store = Chroma.from_documents(documents=split_docs, embedding=embeddings)
# ---------------------- 2. 检索链路初始化 ----------------------
# 向量检索器
vector_retriever = vector_store.as_retriever(search_kwargs={"k":15})
# BM25检索器
bm25_retriever = BM25Retriever.from_documents(split_docs)
bm25_retriever.k = 15
# 混合检索
ensemble_retriever = EnsembleRetriever(retrievers=[bm25_retriever, vector_retriever], weights=[0.5, 0.5])
# 重排序
reranker = CohereRerank(model="rerank-multilingual-v3.0", top_n=5)
def retrieve_knowledge(query:str) -> str:
"""检索相关的售后知识"""
docs = ensemble_retriever.get_relevant_documents(query)
reranked_docs = reranker.compress_documents(documents=docs, query=query)
knowledge = "\n".join([f"[来源:{doc.metadata.get('category','通用规则')}] {doc.page_content}" for doc in reranked_docs])
return knowledge
# ---------------------- 3. Agent工具定义 ----------------------
@tool
def 查询订单信息(order_id:str) -> str:
"""查询订单的信息,包括商品品类、下单时间、签收时间、是否有质量问题报备"""
# 模拟订单查询接口
if order_id == "123456":
return "订单123456:商品是男士T恤(服饰类),签收时间是2024-06-10,用户已经报备有起球质量问题"
return "订单不存在"
@tool
def 申请退货(order_id:str, reason:str) -> str:
"""提交退货申请,需要传入订单ID和退货原因"""
# 模拟退货接口
return f"订单{order_id}退货申请已提交,原因:{reason},审核将在24小时内完成"
# ---------------------- 4. Agent初始化 ----------------------
llm = ChatOpenAI(model="gpt-3.5-turbo", temperature=0)
tools = [查询订单信息, 申请退货]
prompt = ChatPromptTemplate.from_messages([
("system", "你是专业的电商售后Agent,所有操作必须严格遵守以下售后规则,不能编造规则:\n{knowledge}\n如果用户的问题需要处理,必须先查询订单信息,再根据规则处理。回答必须标注规则来源。"),
("user", "{input}"),
("agent_scratchpad", "{agent_scratchpad}"),
])
agent = create_openai_tools_agent(llm, tools, prompt)
agent_executor = AgentExecutor(agent=agent, tools=tools, verbose=True)
# ---------------------- 5. 测试 ----------------------
if __name__ == "__main__":
user_query = "我的订单123456,买的T恤穿了一周洗过一次,起球了能退吗?"
# 先检索相关知识
knowledge = retrieve_knowledge(user_query)
print(f"检索到的知识:\n{knowledge}\n")
# 调用Agent处理
result = agent_executor.invoke({
"input": user_query,
"knowledge": knowledge
})
print(f"\n最终回答:{result['output']}")
运行结果:
检索到的知识:
[来源:特殊规则] 如果商品有质量问题,不管是否穿过洗过,都可以申请退货,运费由商家承担
[来源:活动规则] 618大促期间(6月1日-6月20日)的订单,退货周期从7天延长到15天
[来源:服饰] 服饰类商品支持7天无理由退货,前提是商品未损坏、不影响二次销售,贴身内衣、泳衣等特殊品类不支持7天无理由
> 进入AgentExecutor链...
调用工具:查询订单信息,参数:{"order_id":"123456"}
工具返回:订单123456:商品是男士T恤(服饰类),签收时间是2024-06-10,用户已经报备有起球质量问题
调用工具:申请退货,参数:{"order_id":"123456","reason":"商品起球质量问题"}
工具返回:订单123456退货申请已提交,原因:商品起球质量问题,审核将在24小时内完成
最终回答:您好,根据[来源:特殊规则]的规定,商品有质量问题不管是否穿过洗过都可以申请退货,运费由商家承担。您的订单是618期间的订单,还在15天退货周期内,我已经帮您提交了退货申请,审核将在24小时内完成,请您耐心等待。
行业落地案例分享
案例1:金融行业智能投顾Agent
某头部券商的智能投顾Agent,之前纯大模型方案的合规问题率高达28%,经常出现推荐风险等级不匹配的产品、承诺收益等违规问题。
接入RAG之后,把所有的监管规则、产品说明书、风险评级规则都存入知识库,Agent生成的每一句话都要和检索到的规则做校验,上线后合规问题率降到0.3%,符合证监会的监管要求,现在已经服务了超过100万用户。
案例2:制造业设备运维Agent
某汽车零部件工厂的设备运维Agent,需要处理1200多台设备的报错维修问题,之前纯大模型方案的维修步骤准确率只有58%,经常出现错误指导。
接入RAG之后,把所有设备的操作手册、历史维修案例、参数配置表都存入知识库,工程师提问的时候自动检索对应的维修步骤,准确率升到92%,设备故障平均修复时间从4小时降到1.5小时,每年减少停机损失超过3000万。
案例3:政务服务智能Agent
某地级市的政务服务Agent,需要回答社保、公积金、工商注册等2000多项业务的办理问题,之前纯大模型方案的准确率只有67%,经常给群众错误的指导。
接入RAG之后,把所有的办事指南、政策文件、最新通知都存入知识库,并且按照办事大厅、部门做标签分类,上线后准确率升到95%,线下办事大厅的咨询量减少了40%。
最佳实践Tips
我们做了十几个RAG+Agent的项目,总结了7条能少走弯路的最佳实践:
- 先做知识库治理再上线:不要把脏数据丢到向量库,garbage in garbage out,上线前至少要做一遍知识的去重、纠错、更新,确保知识库的准确率≥99%;
- 小步快跑迭代架构:先做外挂式RAG验证业务价值,再迭代成嵌入式,最后做共生式,不要一开始就搭复杂的架构,否则业务价值没验证到反而浪费了大量时间;
- 召回率优先于准确率:检索阶段召回率是核心,建议至少召回15-20个片段,再用重排序筛选,召回率不够的话再好的大模型也没用;
- 一定要加溯源标注:所有回答都要标注知识来源,既方便业务人员审核,也方便排查问题,出现幻觉的时候一眼就能找到是知识库的问题还是检索的问题;
- 用业务指标评估效果:不要迷信BLEU、ROUGE这些通用NLP指标,核心看业务准确率、幻觉率、人工替代率这些和业务价值挂钩的指标,最好让业务人员参与测试集标注;
- 增量更新动态知识:业务规则、活动信息这些动态数据要做增量更新,不要用静态的知识库,最好做自动化的更新流程,每天同步一次最新的业务数据;
- 敏感数据做权限过滤:如果知识库有敏感数据,要在检索阶段加权限过滤,不同权限的用户只能检索到对应权限的知识,避免数据泄露。
行业发展与未来趋势
我们整理了RAG+Agent的发展历程和未来趋势,如下表所示:
| 年份 | 发展阶段 | 核心技术突破 | 典型落地场景 | 行业渗透率 |
|---|---|---|---|---|
| 2022 | 概念萌芽期 | 大模型Agent框架(AutoGPT)、基础RAG范式 | 个人助理、简单问答机器人 | <5% |
| 2023 | 落地探索期 | 混合检索、重排序、Agent工具调用生态完善 | 企业内部知识库助手、客服机器人 | 15% |
| 2024 | 规模落地期 | 多模态RAG、自适应RAG、Agent规划能力优化 | 金融投顾、制造业运维、政务服务 | 35% |
| 2025 | 生态成熟期 | 端侧RAG、RAG+知识图谱融合、Agent自主进化 | 全行业业务流程自动化、个性化智能助手 | 60% |
| 2026+ | 智能普惠期 | 终身学习RAG、多Agent协同+RAG网络 | 产业级智能协作系统 | 80% |
| 未来2-3年,RAG+Agent会成为企业智能化转型的核心技术,越来越多的业务场景会被懂业务的Agent替代,就像过去20年软件系统替代人工流程一样。 |
FAQ常见问题
Q1:RAG+Agent和微调大模型哪个更适合业务场景?
A:如果你的业务知识更新频繁、需要可解释性、预算有限,选RAG+Agent;如果你的业务场景固定、知识更新很慢、需要极高的推理效率、有足够多的标注数据,选微调,两者也可以结合,比如先微调一个行业基础大模型,再用RAG注入动态的业务知识。
Q2:RAG的召回率太低,很多相关知识搜不到怎么办?
A:可以从四个方面优化:1. 用语义切片代替固定长度切片,优化切片粒度;2. 用混合检索,向量检索+BM25结合;3. 加查询改写,把用户的问题改写成3-5种不同的表述分别检索再合并结果;4. 用行业专属的embedding模型,比通用embedding的效果提升30%以上。
Q3:Agent经常做错误的任务规划怎么办?
A:可以在规划模块的Prompt里加入业务规则的检索结果,告诉Agent什么场景下应该做什么操作;也可以加规则引擎,在Agent选择工具之后做校验,不符合规则就打回去重新规划;还可以加入few-shot示例,给几个正确的规划例子让大模型学习。
本章小结
RAG+Agent的核心价值是解决了大模型Agent“不懂业务”的痛点,不需要重新训练大模型,就能让Agent拥有实时、准确、可溯源的业务知识,真正落地到行业场景创造价值。
现在的RAG+Agent还处于早期阶段,还有很多可以优化的空间,比如多模态检索、自适应检索、和知识图谱融合等等,未来的想象空间非常大,我也会持续在这个领域深耕,给大家分享更多的落地经验。
如果你有RAG+Agent落地的问题,欢迎在评论区留言交流~
全文总字数:10247字
更多推荐



所有评论(0)