TL;DR
LLM的知识有截止日期,RAG让它能查最新资料;LLM只会聊天,Agent让它能干活。RAG的核心是检索+生成,文档分块策略直接影响效果;Agent的核心是感知+规划+记忆+工具,ReAct架构让它能像人一样思考和行动。本文从8个高频面试题入手,带你搞懂RAG与Agent的核心技术:为什么RAG比微调更实用、文档分块怎么选、向量数据库怎么选、Agent的四大组件是什么、多Agent系统如何协作。读完这篇,你能回答”RAG和微调的本质区别”这种深度问题。
一、RAG原理:检索+生成如何协同工作?
核心思想
RAG = Retrieval-Augmented Generation
问题:LLM知识有限、会过时、会幻觉
解决:检索外部知识库,基于检索结果生成答案
工作流程
用户问题
↓
1. 问题改写(Query Rewriting)
↓
2. 向量检索(Embedding + 相似度搜索)
↓
3. 重排序(Reranking)
↓
4. 上下文注入(Context Injection)
↓
5. LLM生成答案
↓
6. 引用标注(Citation)
关键步骤详解
步骤1:问题改写
原问题:LLaMA 3多少参数?
改写后:LLaMA 3模型的参数规模是多少?包括8B、70B、405B版本。
步骤2:向量检索
1. 把问题转成向量(Embedding)
2. 在向量数据库中搜索Top-K相似文档
3. 返回最相关的5-10个文档片段
步骤3:重排序
用更精确的模型(如Cross-Encoder)对检索结果重新打分
步骤4:上下文注入
Prompt = f"""
参考以下资料回答问题:
【资料1】{doc1}
【资料2】{doc2}
【资料3】{doc3}
问题:{question}
"""
参考资料:Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (arXiv:2005.11401)
二、RAG的优势:为什么不直接微调模型?
RAG vs 微调对比
| 维度 | RAG | 微调 |
|---|---|---|
| 知识更新 | 实时(更新知识库) | 需要重新训练 |
| 成本 | 低(只需存储文档) | 高(GPU训练) |
| 可解释性 | 强(可追溯来源) | 弱(黑盒) |
| 准确性 | 依赖检索质量 | 知识融入模型 |
| 适用场景 | 知识密集型任务 | 任务特定能力 |
RAG的核心优势
1. 知识实时更新
新闻问答:今天的新闻,微调模型根本不知道
企业知识库:文档每天更新,RAG立即生效
2. 成本低
微调7B模型:需要GPU、数据标注、训练时间
RAG:只需上传文档到向量数据库
3. 可追溯验证
RAG:答案来自文档X第Y段 → 可验证
微调:答案来自模型内部 → 无法验证
什么时候用微调?
适合微调的场景:
– 需要改变模型风格(如客服语气)
– 需要学习特定格式(如代码生成)
– 知识相对固定(如医学诊断规则)
适合RAG的场景:
– 知识频繁更新(如新闻、法规)
– 需要引用来源(如学术问答)
– 知识量大(如企业文档库)
参考资料:When to Use RAG vs Fine-Tuning (OpenAI Blog)
三、文档分块策略:固定长度 vs 语义分块 vs 滑动窗口
三种策略对比
| 策略 | 原理 | 优势 | 劣势 |
|---|---|---|---|
| 固定长度 | 每N个字符切一块 | 简单快速 | 可能切断语义 |
| 语义分块 | 按段落/句子切分 | 保持语义完整 | 实现复杂 |
| 滑动窗口 | 重叠切分 | 避免边界丢失 | 存储冗余 |
固定长度分块
实现:
def chunk_by_length(text, chunk_size=512, overlap=50):
chunks = []
for i in range(0, len(text), chunk_size - overlap):
chunks.append(text[i:i+chunk_size])
return chunks
适用:代码、结构化文本
语义分块
实现:
# 按段落切分
chunks = text.split('\n\n')
# 按句子切分(保持chunk_size限制)
sentences = text.split('。')
chunks = []
current_chunk = ""
for sent in sentences:
if len(current_chunk) + len(sent) < chunk_size:
current_chunk += sent + "。"
else:
chunks.append(current_chunk)
current_chunk = sent + "。"
适用:文章、文档
滑动窗口
实现:
chunk_size = 512
overlap = 128 # 25%重叠
chunks = []
for i in range(0, len(text), chunk_size - overlap):
chunks.append(text[i:i+chunk_size])
优势:关键信息不会因为切分位置而丢失
参考资料:LangChain Text Splitters文档
四、向量数据库选型:FAISS vs Milvus vs Pinecone
三大数据库对比(2024-2025)
| 指标 | FAISS | Milvus | Pinecone |
|---|---|---|---|
| 类型 | 相似性搜索库 | 云原生开源数据库 | 完全托管服务 |
| 查询延迟 | GPU加速毫秒级 | <10ms | ~20-50ms |
| 最大规模 | 数十亿级 | 100B+ | 数十亿级 |
| 成本(50M向量) | 自管理 | ~$500-1000/月 | 较高(约3倍Milvus) |
FAISS
优势:
– Meta开源,性能极致
– GPU加速,毫秒级响应
– 支持多种索引算法(IVF、HNSW)
劣势:
– 只是库,不是完整数据库
– 需要自己管理持久化、分布式
适用:研究、原型验证
Milvus
优势:
– 云原生架构,易扩展
– 支持100B+向量
– 2025新特性:RaBitQ 1-bit量化(72%内存减少)
劣势:
– 需要自己部署运维
适用:生产环境、大规模应用
Pinecone
优势:
– 完全托管,零运维
– 开箱即用
劣势:
– 成本高
– 厂商锁定
适用:快速上线、不想运维
参考资料:Milvus 2.6发布公告、FAISS文档
五、Agent核心组件:感知、规划、记忆、工具
四大核心组件
Agent = 感知 + 规划 + 记忆 + 工具
1. 感知(Perception)
作用:理解环境和任务
实现:
– 接收用户输入
– 解析任务目标
– 识别当前状态
2. 规划(Planning)
作用:制定行动计划
两种方式:
– 单路径规划:ReAct(推理→行动→观察)
– 多路径规划:Tree of Thoughts(探索多条路径)
3. 记忆(Memory)
短期记忆:当前对话上下文
长期记忆:历史对话、知识库
实现:
class AgentMemory:
def __init__(self):
self.short_term = [] # 当前对话
self.long_term = VectorDB() # 向量数据库
def add(self, message):
self.short_term.append(message)
self.long_term.store(message)
4. 工具(Tools)
常见工具:
– 搜索引擎(Google、Bing)
– 计算器
– 代码执行器
– API调用
工具调用流程:
1. Agent决定使用哪个工具
2. 构造工具输入
3. 执行工具
4. 获取结果
5. 继续推理
参考资料:LangChain Agent文档
六、Agent架构对比:ReAct vs Self-Ask vs Plan-and-Execute
三种架构对比
| 架构 | 核心思想 | 优势 | 劣势 |
|---|---|---|---|
| ReAct | 推理+行动循环 | 简单高效 | 缺乏全局规划 |
| Self-Ask | 分解子问题 | 逻辑清晰 | 不适合复杂任务 |
| Plan-and-Execute | 先规划后执行 | 全局最优 | 规划成本高 |
ReAct架构
流程:Thought → Action → Observation → Thought → …
适用:需要工具调用的任务
Self-Ask架构
流程:
问题:法国总统的妻子是谁?
子问题1:法国总统是谁? → 马克龙
子问题2:马克龙的妻子是谁? → 布丽吉特
答案:布丽吉特
适用:多跳推理问题
Plan-and-Execute架构
流程:
1. 规划阶段:制定完整计划
- 步骤1:搜索XXX
- 步骤2:分析YYY
- 步骤3:总结ZZZ
2. 执行阶段:按计划执行
3. 反思阶段:检查是否完成
适用:复杂多步骤任务
参考资料:ReAct论文、Plan-and-Solve论文
七、多Agent系统:协作与竞争机制
核心思想
单Agent局限:能力有限、容易陷入局部最优
多Agent优势:分工协作、互相监督、集思广益
协作模式
1. 流水线模式
Agent1(搜索) → Agent2(分析) → Agent3(总结)
2. 辩论模式
Agent1提出方案A
Agent2提出方案B
Agent3评判选择最优方案
3. 投票模式
多个Agent独立完成任务
投票选择最优结果
实战案例:MetaGPT
角色分工:
– Product Manager:需求分析
– Architect:架构设计
– Engineer:代码实现
– QA:测试验证
工作流程:
PM写需求 → Architect设计 → Engineer编码 → QA测试 → 迭代
参考资料:MetaGPT论文、AutoGen论文
八、LangChain vs LlamaIndex vs AutoGPT
三大框架对比
| 框架 | 定位 | 优势 | 劣势 |
|---|---|---|---|
| LangChain | 通用LLM应用框架 | 生态丰富、组件多 | 学习曲线陡 |
| LlamaIndex | 专注数据索引和RAG | RAG能力强 | 功能相对单一 |
| AutoGPT | 自主Agent | 自动化程度高 | 不稳定、成本高 |
LangChain
核心组件:
– Chains:组合多个LLM调用
– Agents:工具调用
– Memory:对话记忆
– Retrievers:文档检索
适用:复杂LLM应用
LlamaIndex
核心能力:
– 数据连接器(100+数据源)
– 索引结构(向量、树、图)
– 查询引擎
适用:RAG应用
AutoGPT
核心特点:
– 自主设定目标
– 自主调用工具
– 自主迭代优化
适用:探索性任务
参考资料:各框架官方文档
小结
本文从8个高频面试题入手,系统梳理了RAG与Agent的核心技术:
- RAG原理:检索+生成,6步工作流程
- RAG优势:实时更新、成本低、可追溯
- 文档分块:固定长度/语义分块/滑动窗口
- 向量数据库:FAISS研究、Milvus生产、Pinecone托管
- Agent组件:感知+规划+记忆+工具
- Agent架构:ReAct简单、Self-Ask清晰、Plan-and-Execute全局
- 多Agent系统:流水线/辩论/投票三种协作模式
- 框架选择:LangChain通用、LlamaIndex专注RAG、AutoGPT自主
下一篇预告:评估与安全篇——如何衡量和保护LLM?






程序员数学扫盲课
AI周刊:大模型、智能体与产业动态追踪
Claude Code 全体系指南:AI 编程智能体实战
Karpathy神经网络零基础课程
最新评论
开源的AI对话监控面板很实用,正好团队在找这类工具。准备试用一下。
折叠屏市场确实在升温,不过售罄也可能是备货策略。期待看到实际销量数据。
从磁盘I/O角度解释B树的设计动机,这个切入点很好。终于理解为什么数据库不用二叉树了。
IT术语转换确实是个痛点,之前用搜狗总是把技术词汇转成奇怪的词。智谱这个方向值得期待。
这个工具结合LLM和搜索API的思路很有意思,正好解决了我在做知识管理时遇到的问题。请问有没有部署文档?
这个漏洞确实严重,我们团队上周刚遇到类似问题。建议补充一下如何检测现有项目是否受影响的方法。
从简单规则涌现复杂性这个思路很有意思,让我想起元胞自动机。不过数字物理学在学术界争议还挺大的。
我也遇到了指令跟随变差的问题,特别是多轮对话时容易跑偏。不知道是模型退化还是负载优化导致的。