07-RAG+Agent：知识库增强的智能体

RAG + Agent：知识库增强的智能体

纯大模型知识有限且会过时，加上 RAG（检索增强生成）的知识库，Agent 才能回答企业内部的专业问题。这篇讲 RAG 和 Agent 怎么结合：检索工具怎么设计、什么时候检索、怎么提升检索质量、Agent + RAG 的典型架构。

大家好，我是黒漂技术佬。

Agent 光靠大模型本身的知识不够用，特别是企业场景：产品文档、内部手册、客户案例、历史工单……这些模型训练数据里没有。怎么办？接上 RAG。

RAG（检索增强生成）就是先从知识库搜相关内容，再让模型根据搜到的内容回答。Agent + RAG，就是让智能体拥有企业专属的知识库。

这篇讲 RAG 和 Agent 怎么结合：检索工具设计、检索策略、质量优化、典型架构。

---

一、为什么 Agent 需要 RAG？

大模型的知识局限

1. 知识截止：训练数据有截止日期，之后的事不知道
2. 没有私有知识：企业内部文档、产品信息、客户数据都没有
3. 幻觉问题：不知道的容易瞎编
4. 知识更新难：重新训练成本高，跟不上变化

RAG 怎么解决

用户提问 → 检索知识库 → 拿到相关内容 → 拼到prompt里 → 模型根据资料回答

模型照着资料回答，就不容易瞎编，也能回答私有知识的问题。

Agent + RAG = 有专业知识的智能体

普通 Agent 只会调用通用工具，加上 RAG 之后：

• 能回答公司内部的专业问题
• 回答有依据，可溯源
• 知识库更新方便，不用重新训练模型

---

二、RAG 基础回顾

RAG 工作流程

索引阶段（离线）

文档 → 解析 → 分块 → 向量化 → 存入向量数据库

查询阶段（在线）

问题 → 向量化 → 向量检索 → 拿到相关片段 → 拼进Prompt → 模型生成回答

核心组件

组件	作用	常见方案
文档解析	读取 PDF/Word/网页，提取文本	PyPDF、Unstructured、LangChain
分块（Chunking）	把长文档切成合适大小的片段	固定大小、语义分块
Embedding 模型	把文本转成向量	OpenAI、BGE、M3E、Qwen-Embedding
向量数据库	存储和检索向量	Chroma、Pinecone、Milvus、Qdrant
大模型	根据检索结果生成回答	GPT、Claude、Qwen、DeepSeek

---

三、RAG 作为 Agent 的工具

最简单的方式：把检索做成一个工具

{
    "name": "search_knowledge_base",
    "description": "从公司知识库中搜索产品文档、FAQ、操作手册等内部资料。
                    回答产品相关问题、内部流程问题时使用。",
    "parameters": {
        "type": "object",
        "properties": {
            "query": {
                "type": "string",
                "description": "搜索关键词或问题"
            }
        },
        "required": ["query"]
    }
}

Agent 判断需要查知识库的时候，调用这个工具，拿到结果继续回答。

工具实现

def search_knowledge_base(query: str) -> str:
    # 1. 问题向量化
    query_vec = embedding_model.encode(query)
    
    # 2. 向量检索
    results = vector_db.search(query_vec, top_k=5)
    
    # 3. 整理成文本
    context = "\n\n".join([
        f"[文档{i+1}] {r['content']}" 
        for i, r in enumerate(results)
    ])
    
    return context

跟普通搜索工具的区别

• 普通搜索（Google/Bing）：搜互联网公开信息
• 知识库检索：搜企业内部私有资料

Agent 可以同时配两个工具，内部问题查知识库，外部信息搜互联网。

---

四、什么时候检索？

策略 1：每次都检索（Always-Retrieve）

不管什么问题，先搜一下再说。

• 优点：简单，不会漏
• 缺点：简单问题也搜，浪费时间和钱，可能反而干扰

策略 2：模型自己判断（Tool-Call 方式）

把检索做成工具，模型自己判断要不要调用。

• 优点：灵活，该搜才搜
• 缺点：模型可能判断错，该搜的不搜，瞎回答

策略 3：分类判断

先用一个分类模型/规则判断问题类型：

• 寒暄闲聊 → 直接回答

• 常识问题 → 直接回答

• 产品/内部问题 → 检索知识库

• 实时信息 → 搜互联网

• 优点：准确，效率高

• 缺点：多一步，要维护分类逻辑

策略 4：先回答，答不上再检索

模型先尝试回答，回答不了或者不确定，再去搜。

• 优点：简单问题快
• 缺点：慢的问题更慢，而且模型可能「以为自己知道」其实答错了

推荐

企业知识库场景，推荐策略2 + 系统提示词强调：

• 做成工具，模型自己判断
• 系统提示词里明确：「涉及产品、内部流程、客户案例等问题，必须先检索知识库再回答，禁止仅凭训练知识回答」

再加上兜底校验，回答里引用的内容必须来自检索结果。

---

五、提升 RAG 质量

检索质量直接决定 Agent 回答的准确性。

1. 混合检索（Hybrid Search）

向量检索 + 关键词检索（BM25）结合，召回率更高。

• 向量检索：语义相关，能搜到同义词
• 关键词检索：精确匹配，专有名词、编号更准

两个结果融合重排序，比单用一种好很多。

2. 重排序（Rerank）

先粗召回一批（比如 20 条），再用 reranker 模型精排，取最相关的前几条。

常用 reranker：BGE-Reranker、Cohere Rerank、ColBERT。

加了 rerank 之后，相关性提升很明显。

3. 查询改写（Query Rewriting）

用户的问题不一定适合检索，让模型改写一下再搜：

原问题：这玩意儿咋用？
改写后：产品使用方法、操作指南、入门教程

或者扩展成多个查询，多路召回。

4. 分块优化

• 块大小：一般 200-500 个 token，太小没上下文，太大噪音多
• 重叠：相邻块重叠一部分，防止截断关键信息
• 语义分块：按段落、标题分，比固定大小好
• 父子块：大块存原文，小块用来检索，搜到了返回大块

5. 元数据过滤

给文档加元数据（部门、产品、时间、类型），检索时先过滤：

• 只搜某个产品的文档
• 只搜最近更新的
• 只搜 FAQ 类型

减少无关内容，提高精度。

6. 多轮对话检索优化

多轮对话时，不能只拿当前一句去搜，要结合上下文：

用户：怎么开通？
（前面聊的是企业版套餐）

检索查询应该是：企业版套餐 开通方法

用模型把多轮上下文整合成一个完整的检索问题。

---

六、Agent + RAG 的典型架构

架构 1：单工具检索（最简单）

用户问题 → Agent → 判断是否需要检索
                    ↓ 需要
                调用检索工具 → 知识库 → 返回结果
                    ↓
                生成回答

适合：简单的知识库问答，90% 的场景够用。

架构 2：检索 + 反思（Self-RAG）

检索 → 生成回答 → 自我检查 → 答得不好就再检索一次

模型自己判断检索到的内容够不够、回答准不准，不够就再搜。

质量更高，但多几轮调用。

架构 3：专门的检索 Agent

一个专门负责检索的 Agent，它自己决定：

• 搜什么关键词
• 搜几次
• 怎么筛选和整理结果

然后把整理好的资料给主 Agent 用。

适合知识库比较复杂、检索策略多的场景。

架构 4：RAG + 工具 + 多 Agent

用户问题
  ↓
调度Agent → 判断问题类型
  ├── 产品问题 → 知识库检索Agent
  ├── 技术问题 → 技术文档 + 代码库检索
  ├── 订单问题 → 数据库查询工具
  └── 闲聊 → 直接回答
  ↓
汇总生成最终回答

企业级复杂场景，多种数据源、多种工具。

---

七、回答溯源和可信度

引用来源

回答里标注信息来自哪篇文档，用户可以点进去看原文：

根据产品手册[1]，开通流程如下：...

[1] 《企业版开通指南 V2.3》

好处

1. 可验证：用户可以查证，增加信任
2. 减少幻觉：模型知道要引用，不容易瞎编
3. 可追责：答错了可以定位是哪份文档的问题

无答案检测

检索不到相关内容的时候，要回答「我不知道」，而不是瞎编：

系统提示词：
只能根据检索到的资料回答。如果资料里没有答案，
就说"抱歉，知识库中没有相关信息"，不要编造。

---

八、常见坑

坑 1：检索到的内容不相关

分块不好、Embedding 不行、查询不对，都可能导致搜出来的没用。

解决：优化分块、换更好的 Embedding、加 rerank、查询改写。

坑 2：模型不引用检索内容，自己瞎编

检索到了但模型还是照着训练知识答，特别是模型「以为自己知道」的时候。

解决：

• 系统提示词强调「只能根据检索资料回答」
• 用小一点的模型（知识少的反而更愿意照资料答）
• 回答后校验，检查答案有没有来源支撑

坑 3：上下文塞太多，模型迷失

搜了十几条全塞进去，太长了模型抓不住重点。

解决：控制 top_k，rerank 之后只留最相关的 3-5 条，长内容先摘要。

坑 4：知识库更新不及时

文档更新了，但向量库里还是旧版本。

解决：建立更新机制，文档变更自动重新索引。

坑 5：多轮对话检索跑偏

只拿当前一句去搜，没结合上下文，搜出来不相关。

解决：先做上下文补全，把多轮对话整合成完整查询再搜。

---

九、本篇小结

• Agent + RAG：让智能体拥有企业私有知识库，回答专业问题，减少幻觉
• RAG 流程：文档分块向量化存库 → 查询时检索 → 模型根据资料回答
• 最简单的方式：把知识库检索做成一个 Function Call 工具，Agent 按需调用
• 检索时机：模型自己判断、强制检索、分类判断，各有优劣
• 质量优化：混合检索、rerank 重排序、查询改写、优化分块、元数据过滤
• 典型架构：单工具（简单场景）、Self-RAG（带反思）、专门检索 Agent、多 Agent 调度
• 回答要带引用来源，可验证，减少幻觉
• 常见问题：检索不相关、模型瞎编、上下文太长、知识库更新不及时

下一篇讲 Agent 框架对比：LangChain、AutoGPT、CrewAI、LlamaIndex 这些框架各有什么特点，怎么选。

我是黒漂技术佬。