RAG 入门讲解

RAG 知识库问答:从 LLM 缺陷 到 Agent / MCP

学完这份 PPT,能建立四个基本理解:为什么需要 RAG、RAG 如何工作、怎么评估效果、Agent / MCP 分别解决什么问题。

Why

LLM 为什么不够用

上下文、幻觉、私有知识、长上下文注意力。

How

RAG 怎么落地

离线建库、在线检索、排序、提示词生成。

Extend

复杂任务怎么扩展

Agent 负责流程,MCP 负责连接工具。

问题

LLM 会说,但不知道你公司的最新事实

在企业知识问答里,答案必须有依据、能追溯、能控权限。

方案

RAG 先找证据,再回答

把知识库变成可检索、可引用、可更新的外部记忆。

扩展

跨系统办事,再上 Workflow / Agent

MCP 负责把外部工具和数据规范地接进来。

RAG Knowledge Base QA
开场直接说明:这份 PPT 用一条主线讲清 RAG 的来龙去脉。重点不是技术炫技,而是让听众理解系统为什么这样设计。
01

学习路线:从“模型会说话”到“系统能办事”

先理解模型边界,再理解 RAG、Agent 和 MCP 各自解决什么问题。

Learning Map
1

LLM 是什么

理解它擅长语言生成,但不是事实系统。

2

LLM 的缺陷

上下文有限、幻觉、私有知识缺失、注意力漂移。

3

RAG 的方案

先检索知识库,再把资料交给 LLM 生成。

4

知识库流程

资料准备、切片、向量化、检索、排序、引用。

5

Agent / MCP

复杂任务要规划和工具连接,不只是问答。

理解顺序:

先看业务问题
再看系统链路
最后看指标和风险
Learning Path
这页不要展开细节,只把学习路径建立起来。后面每页都服务这条路线。
02

LLM 是语言引擎,不是企业事实库

先把模型边界说清楚,后面引出 RAG 才自然。

Language Model
它擅长

理解语义,组织表达

把用户问题转成可处理的意图总结、改写、解释、翻译、生成结构化答案根据给定上下文做推理和表达
它不是

可靠的事实来源

不知道你的内部文档和实时制度不能天然保证每句话有出处拿不到资料时仍可能生成看似合理的答案

产品理解:LLM 负责“读懂和表达”,事实依据必须由外部知识或工具提供。

LLM Boundary
这一页是基础定义。讲成“语言引擎”比直接展开算法细节更容易让听众理解。
03

为什么 LLM 不适合直接回答复杂企业知识问题

在企业知识问答场景里,裸用模型通常不利于新鲜度、权限、成本和可追溯。

Limitations
1
上下文窗口有限

输入再长也有上限;越长越贵、越慢、越容易混乱。

2
事实会过期或缺失

内部知识、最新政策、业务数据通常不在模型参数里。

裸用
通常
不稳
3
幻觉风险

资料不足、冲突或提示不清时,可能编造细节。

4
长上下文利用不均

重点可能被噪声稀释,中间信息尤其容易被忽略。

结论:企业问答要先筛出“小而准”的上下文,再交给 LLM。

Context · Hallucination · Freshness · Attention
这一页是引出 RAG 的关键。不能只说“LLM 有幻觉”,要把上下文、私有知识、注意力顺序一起说明白。
04

为什么不把所有知识一次性给 LLM

RAG 不是任何场景都必须上;文档多、更新快、要权限和引用时才更有价值。

Need Retrieval

响应变慢

长上下文会拉高推理时间,用户体验变差。

成本变高

每次都读大量文档,token 成本不可控。

答案变乱

无关资料越多,模型越难抓住真正依据。

权限风险

不该给用户看的资料可能进入上下文。

不适合的做法

全量塞文档

资料多、权限复杂时,把知识管理问题转移给模型,效果不可控。

RAG 思路

先筛资料

先用检索和排序选出少量相关资料。

生成答案

基于证据回答

让 LLM 在受控上下文里生成。

长上下文适合“资料少、位置已知、可以整包读完”;RAG 适合“资料多、常更新、答案位置不确定、要权限和引用”。两者经常组合:先检索,再把少量证据放进上下文。

Why Retrieval Before Generation
这一页回答常见疑问:既然大模型能读长文本,为什么还要 RAG。
05

知识库问答产品,本质是“带证据的回答系统”

RAG 不是一个模型功能,而是一条产品链路。

Product View
用户问题

“这个退款能不能批?”

用户通常用口语表达,不会精确匹配文档标题。

知识库证据

政策、流程、版本、权限

系统先找到可用资料,并保留来源。

LLM 答案

结论 + 理由 + 来源

回答不只是顺口,还要能追溯和复核。

准确

答案来自可信资料。

及时

多数知识更新可先更新知识库,不必依赖重训模型。

可追溯

能展示引用来源。

可控权限

检索前先过滤用户权限。

Knowledge Base QA
这一页把 RAG 落到产品形态。这里要强调“带证据”,不是“聊天更聪明”。
06

RAG = 离线建索引 + 在线检索生成

把这句话讲清楚,基本就进入 RAG 的门了。

Architecture
离线:让资料可被找到

清洗

去重、去噪、统一格式。

切片

长文档拆成小知识块。

建索引

建立向量、关键词或混合索引,并保存元数据。

在线:让回答有依据

检索

按问题找候选片段。

排序

筛出最相关、最可信资料。

生成

LLM 基于上下文回答。

RAG 的关键不是“有没有向量库”,而是资料能否被正确检索、正确排序、正确使用。

Offline Indexing + Online Retrieval
这一页建立总架构。可以先用离线和在线两段讲,再展开细节。
07

离线建库:资料准备比模型选择更先决定上限

这部分最容易被忽略,却往往最先决定知识库问答的效果上限。

Indexing
资料盘点
确定业务范围:客服 FAQ、产品手册、制度、合同、接口文档标清来源、负责人、更新时间、适用对象
清洗治理
删除重复、过期、目录噪声、网页导航、无效表格统一标题、层级、术语,避免同义词混乱
索引入库
切片、向量化、保存元数据,写入向量库或混合检索索引准备评测问题集,后续用来验证召回和答案质量
Source Governance · Chunking · Embedding
这一页讲产品工作:资料范围、治理、版本、权限、评测集。不要只讲技术名词。
08

切片不是随便截断,而是让知识块能独立回答问题

切片粒度、重叠、元数据,会直接影响召回质量。

Data Design
示例:退款政策文档

切片 A:退款条件

购买后 7 天内,且未使用核心服务,可以申请全额退款。

切片 B:不可退场景

已开票、已交付定制服务、超过合同期限,不支持自动退款。

切片 C:审批路径

超过 5 万元的退款,需要客户成功经理和财务双审批。

产品要关注
太大:噪声多,模型抓不住重点太小:语义断裂,缺少必要上下文需要重叠:避免关键信息跨片丢失元数据:来源、版本、时间、权限、业务线
Chunk Size · Overlap · Metadata
讲切片时一定用例子。听众能理解“为什么切片决定检索效果”。
09

在线检索:先召回候选,再排序决定给 LLM 什么

召回解决“找得到”,排序解决“排得对”。

Retrieval

理解问题

识别意图,必要时改写查询。

召回候选

向量检索、关键词检索或混合检索。

过滤

按权限、业务线、版本、时间过滤;强权限可在索引或检索阶段提前做。

重排

把最相关、最新、可信的片段排前面。

拼上下文

控制长度,去重,保留来源。

候选排序示例

1
退款政策 v2026Q2
直接回答,版本最新
96
2
大客户审批流程
金额超过 5 万时补充
82
3
历史退款 FAQ
相关但版本较旧
41

理解检索要抓住的点

向量检索适合语义相近,但不一定精确关键词适合编号、术语、代码、合同条款搜索负责找资料,RAG 负责“找资料 + 选证据 + 组织回答”权限过滤最好发生在进入上下文之前
Query Rewrite · Hybrid Search · Rerank · Top-K
这一页把“排序”讲清楚。很多人只知道向量库,但不知道召回和重排的区别。
10

生成阶段:Prompt 规定 LLM 如何使用资料

检索负责找证据,提示词负责使用规则。

Prompt
SYSTEM
你是客服知识库助手。只能基于 CONTEXT 回答;资料不足时说“不确定”,不要编造。输出必须包含:结论、依据、来源。

CONTEXT
[退款政策 v2026Q2] 购买后 7 天内且未使用核心服务,可全额退款。

USER
客户买了 3 天,还没使用,可以退吗?
系统提示词要约束什么

角色

你是谁,服务什么场景。

边界

只能基于资料,不够就说不确定。

格式

结论、理由、来源、下一步。

安全

权限控制主要在数据层/检索层做,Prompt 是最后一层约束。

RAG 的答案质量 = 检索质量 × 上下文组织 × 提示词约束;权限安全不能只靠 Prompt。

Prompt Engineering for RAG
提示词工程不要讲玄学,要讲规则:角色、边界、格式、兜底、安全。
11

RAG 做得好不好,要拆成哪些指标看

不能只说“效果不错”,要能拆成检索、答案、体验、治理。

Evaluation
检索

正确资料是否进候选

离线看 Hit@K、Recall、问题集覆盖;先确认资料找没找到。

重排

正确资料是否排前面

看相关性、时效、权限、来源可信度,避免过期资料进入上下文。

答案

是否基于证据

看 groundedness / faithfulness、引用命中率、拒答是否稳妥。

在线

能不能上线

看延迟、成本、失败率、满意度、人工转接率和线上反馈。

排查顺序:先离线看检索/重排,再看答案是否忠于证据,最后看线上体验和成本。

Retrieval Metrics · Groundedness · Latency · Cost
这页用于建立评估框架。要能把“效果不好”定位到链路中的某一段。
12

RAG 失败时,通常不是“模型太差”这么简单

把失败原因拆到资料、检索、生成和产品机制,才方便定位和迭代。

Failure Modes
资料问题

知识库本身不可信

文档过期、重复、格式混乱、缺少负责人,导致检索出来的证据就错。

检索问题

找不到或找偏

切片粒度不合适、同义词没处理、只用向量导致编号/条款匹配差。

生成问题

模型没有按证据答

上下文太长、提示词边界弱、冲突资料没处理,都会导致幻觉。

治理动作

建立资料负责人、版本规则、过期提醒和灰度发布。

技术动作

混合检索、重排、查询改写、权限过滤、上下文去重。

产品动作

展示来源、允许反馈、低置信度转人工、持续评测。

Failure Analysis
这页用于建立排查思路:如果效果不好,先判断问题出在资料、检索、生成还是产品机制。
13

什么时候从 RAG 走到 Agent

不要为了显得高级而上 Agent;先判断任务是否真的需要动态决策。

Agent

规划

判断任务目标,拆成检索、调用工具、确认结果等步骤。

检索

用 RAG 查政策、流程、历史案例,给后续动作提供依据。

执行

调用工具查订单、建工单、写系统、发送通知,并检查结果。

不需要 Agent

单轮问答或固定流程

路径确定、风险高、规则清晰时,workflow + RAG 往往更稳。

需要 Agent

多步骤动态任务

需要规划、试错、跨系统调用,并根据中间结果决定下一步。

RAG Gives Knowledge · Agent Orchestrates Tasks
不要把 Agent 讲神。它是围绕目标进行计划、工具调用和反馈循环的系统。
14

MCP:AI 应用连接外部能力的标准协议

这是扩展理解点。可以记住一句:MCP 让 AI 应用用统一方式连接工具、数据和提示模板。

Protocol
Host / Client

AI 应用侧

Host 承载用户和模型;Client 负责按 MCP 协议连接 Server。

MCP
连接 tools · resources · prompts
CRM客户资料
工单系统创建 / 查询
数据库实时数据
文件系统内部文档
搜索外部信息
消息通知和审批

关系一句话:RAG 提供知识证据,Workflow / Agent 决定步骤,MCP 负责统一连接外部工具和数据。

Model Context Protocol · Host · Client · Server
MCP 不要讲太深。入门层面只要讲清它解决“模型和工具怎么标准连接”。
15

实战练习:设计一个企业知识库问答系统

按这个结构梳理方案,既有业务视角,也能覆盖技术链路。

Template
0

先判断问题类型

长上下文解决“读得下”,RAG 解决“找得到”,微调更适合风格/格式/任务适配,Agent 解决“做得到”;MCP 是连接协议。

1

定场景

用户是谁?问什么问题?需要结论、解释、引用,还是要执行动作?

2

治理资料

资料从哪里来,谁负责,版本和权限怎么管,是否有评测问题集?

3

设计检索

切片、元数据、向量检索、关键词检索、混合检索、重排和 Top-K。

4

约束生成

系统提示词规定只能基于资料回答,输出来源,不确定就兜底。

5

评估迭代

看召回、排序、groundedness、引用、延迟、成本、权限和用户反馈。

一句话收束:企业 AI 问答要先分清“读得下 / 找得到 / 说得稳 / 做得到”,再决定长上下文、RAG、微调、Agent 分别怎么用。

Solution Design Template
这页是最终方案框架。讲解时可以按 0 到 5 展开,把前面的概念串成一个完整设计。