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是指能自主感知环境、做出决策、调用工具完成特定目标的智能系统,核心组件包括四个部分:

  1. 感知模块:接收用户输入、环境反馈等信息;
  2. 规划模块:把复杂目标拆解成多个子任务,制定执行路径;
  3. 记忆模块:存储短期交互记忆、长期知识记忆;
  4. 动作模块:调用工具、生成回答、执行具体操作。
什么是检索增强生成(RAG)

RAG是一种把检索系统和大模型结合的技术范式,核心流程是:先把外部知识库的内容切片、转换成向量存入向量数据库,用户提问时先从向量库检索相关的知识片段,再把片段和用户问题一起喂给大模型,让大模型基于检索到的知识生成回答,从根源上减少幻觉,提升内容的准确性和时效性。

问题背景:为什么Agent天生“不懂业务”

我们可以把大模型的知识来源分成三类,对比一下就能看出问题所在:

知识类型 来源 时效性 准确性 业务适配性 可解释性
预训练知识 大模型训练数据 截止到cutoff时间 通用场景高,细分场景低 不可溯源
微调注入知识 标注的业务数据 截止到微调时间 取决于标注质量 中等 不可溯源
Prompt注入知识 对话时输入的上下文 实时 100%可控 可溯源
而Agent的“懂业务”能力要求恰恰是:实时更新、100%符合业务规则、可溯源可审计、能适配细分场景的个性化需求,前两种知识注入方式完全满足不了,只有Prompt注入的方式能达标——而RAG本质上就是自动化的、精准的Prompt业务知识注入系统

问题边界:RAG+Agent能做什么,不能做什么

在正式讲融合方案之前,我们首先要明确技术的边界,避免盲目踩坑:

✅ 适合的场景
  1. 业务规则更新频繁,比如每月/每周都有新的政策、制度、产品上线;
  2. 对内容准确性要求高,比如金融、政务、医疗等不能出错的场景;
  3. 需要可解释性,回答必须有来源可溯源,符合监管要求;
  4. 业务数据敏感,不能把内部数据上传给大模型做微调。
❌ 不适合的场景
  1. 需要极高的推理效率,比如毫秒级响应的实时交易场景;
  2. 业务逻辑非常复杂,需要跨多个知识点做深度组合推理,比如复杂的财务报表审计;
  3. 交互场景极度固定,知识十年八年不更新,比如固定流程的工业控制场景。

RAG+Agent的核心融合原理

概念关系与架构设计

我们先看RAG和Agent核心组件的交互关系,用ER图表示如下:

渲染错误: Mermaid 渲染失败: Parse error on line 17: ... 动态业务数据 } AGENT ||- ---------------------^ Expecting 'ATTRIBUTE_WORD', got 'BLOCK_STOP'

整体的工作架构如下图所示:

需要业务知识

不需要业务知识

用户输入

感知模块/意图识别

路由判断

RAG检索模块

规划模块

重排序+知识片段拼接

需要调用工具?

工具调用模块

工具返回结果

RAG校验模块

回答生成模块

结果溯源标注

返回给用户

记忆存储/知识库更新

业务知识库

核心数学模型

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∥∥diqdi
其中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(as)=αPllm(as)+(1α)Prag(as)
其中α\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. 通用规则层:国家《消费者权益保护法》、平台通用售后规则,更新频率:每年1次;
  2. 品类规则层:不同品类的售后规则,比如服饰支持7天无理由,贴身衣物不支持,电子产品支持15天换货,更新频率:每季度1次;
  3. 活动规则层:大促期间的特殊售后规则,比如618期间退货周期延长到15天,更新频率:每月1次;
  4. 动态案例层:历史上的特殊售后案例,比如用户买的衣服洗过一次但有质量问题可以退,更新频率:每天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:效果评估与迭代

我们用三个核心指标评估效果:

  1. 业务准确率:回答符合业务规则的比例,目标≥95%;
  2. 幻觉率:回答出现不符合规则的内容的比例,目标≤3%;
  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条能少走弯路的最佳实践:

  1. 先做知识库治理再上线:不要把脏数据丢到向量库,garbage in garbage out,上线前至少要做一遍知识的去重、纠错、更新,确保知识库的准确率≥99%;
  2. 小步快跑迭代架构:先做外挂式RAG验证业务价值,再迭代成嵌入式,最后做共生式,不要一开始就搭复杂的架构,否则业务价值没验证到反而浪费了大量时间;
  3. 召回率优先于准确率:检索阶段召回率是核心,建议至少召回15-20个片段,再用重排序筛选,召回率不够的话再好的大模型也没用;
  4. 一定要加溯源标注:所有回答都要标注知识来源,既方便业务人员审核,也方便排查问题,出现幻觉的时候一眼就能找到是知识库的问题还是检索的问题;
  5. 用业务指标评估效果:不要迷信BLEU、ROUGE这些通用NLP指标,核心看业务准确率、幻觉率、人工替代率这些和业务价值挂钩的指标,最好让业务人员参与测试集标注;
  6. 增量更新动态知识:业务规则、活动信息这些动态数据要做增量更新,不要用静态的知识库,最好做自动化的更新流程,每天同步一次最新的业务数据;
  7. 敏感数据做权限过滤:如果知识库有敏感数据,要在检索阶段加权限过滤,不同权限的用户只能检索到对应权限的知识,避免数据泄露。

行业发展与未来趋势

我们整理了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字

Logo

Agent 垂直技术社区,欢迎活跃、内容共建。

更多推荐