LLM 学习笔记 Day 8
第一部分：工业级 RAG 全景图
1.1 LLM 为什么需要 RAG？
根本原因：Knowledge Frozen（知识冻结）
LLM 的生命周期分两段：
- 训练阶段：吃进海量数据，调整参数
- 推理阶段：参数被固定，世界知识冻结在训练截止日
训练结束后，世界发生的任何新事件（如“今天腾讯发布了新 Agent 框架”）都不会自动进入模型。
两种解决方案对比：
| 方案 | 做法 | 成本 | 适用场景 |
|---|---|---|---|
| 重新训练/微调 | 重新收集数据再训练 | 几百万到几千万 | 大规模知识更新 |
| RAG | 搜索外部知识库，和问题一起给 LLM | 几乎为零 | 实时、灵活的知识获取 |
RAG 的本质不是让 LLM 变聪明，而是给 LLM 提供外部知识。LLM 负责推理，RAG 负责找知识。
1.2 Chunk（切块）—— RAG 的地基
为什么不能整篇 Embedding？
整份文档只生成一个向量，无法精确定位到某个具体段落。用户问“Redis 经验”，Retriever 只能返回整份简历，无法单独捞出 Redis 那个项目经历。
正确流程：
文档 → Chunk → Embedding → 存入向量库Chunk 策略核心原则：语义完整，而非按字数。
| 错误切法 | 正确切法 |
|---|---|
| 按 500 字机械切割 | 一个项目经历 = 一个 Chunk |
| “开发后台 / 管理系统 Redis” | 整个实习经历完整保留 |
Chunk 决定 Recall 的上限。切得好不好，直接决定了后续所有环节能拿到多少有效信息。
1.3 Embedding 深入——谁训练的？
Embedding 模型也是训练出来的神经网络。
训练目标：
- “猫”和“小猫” → 向量距离近
- “猫”和“汽车” → 向量距离远
通过海量文本对不断训练，模型学会了把语义相近的文本映射到向量空间中相邻的位置。
Embedding 的本质不是编码或压缩，而是建立语义空间（Semantic Space）。语义相近的东西，在空间中距离更近。
1.4 Retriever 到底是什么？
Retriever 是“找资料的人”，不是“答题的人”。
| Retriever | LLM | |
|---|---|---|
| 职责 | 召回（Recall） | 推理（Reasoning） |
| 输出 | 相关文档片段 | 自然语言答案 |
| 比喻 | 图书馆检索系统 | 阅读并答题的学生 |
为什么不是普通 Search？
| Keyword Search | Semantic Search (Retriever) | |
|---|---|---|
| 匹配方式 | 字符串匹配 | 语义向量相似度 |
| “后台管理系统”能匹配“Spring Boot”吗？ | ❌ 不能 | ✅ 能 |
| 优势 | 精确查询（版本号等） | 理解同义词、近义词、隐含语义 |
Retriever 看的是语义，不是文字。这是它和传统搜索引擎的根本区别。
1.5 Reranker——工业级的秘密武器
为什么 Top-K 不是最终答案？
向量检索返回的 Top-K 是按距离排序的，但“距离近”不完全等于“最相关”。
例如检索“Redis 项目经历”，Retriever 返回：
- Redis 缓存配置
- Redis 基础知识
- Redis 项目实战 ← 用户真正需要的
Reranker 对 Top-K 进行二次精排，把真正最相关的排到前面。
| Retriever | Reranker | |
|---|---|---|
| 负责 | Recall（召回） | Precision（精度） |
| 速度 | 极快（毫秒级） | 较慢（秒级） |
| 输入 | 全量知识库 | Retriever 的 Top-K（如30条） |
| 输出 | Top-K（如30条） | Top-N（如5条） |
Retriever 负责“找得到”，Reranker 负责“排得准”。这是 RAG 从 Demo 级到工业级的分水岭。
1.6 Query Rewrite 与 Hybrid Search
Query Rewrite（查询改写）：用户输入通常模糊（如“Java”），在进入 Retriever 前让 LLM 改写为更精确的检索查询（如“Java Agent 开发框架 Spring AI”），提升召回率。
Hybrid Search（混合检索）：
- Embedding 搜索擅长语义匹配，但精确查询（如版本号“3.4”）容易模糊
- Keyword 搜索（BM25）擅长精确匹配，但不懂同义词
- Hybrid Search = Keyword Search + Vector Search，结合两者优势，是目前大厂 RAG 系统的主流方案
1.7 工业级 RAG 完整架构
用户问题 ↓ Query Rewrite（查询改写） ↓ Embedding（向量化） ↓ Vector Retriever（向量召回 Top-K） ↓ Reranker（精排到 Top-N） ↓ Prompt Construction（构造 Prompt） ↓ LLM（生成答案）第二部分：Agent 系统架构设计
2.1 Agent 不是一个 LLM，而是一个系统
很多人认为 Agent = User → LLM → Tool → Answer。真正的企业级 Agent 是一个多层系统：
用户 ↓ Agent 入口 ↓ Planner（制定计划） ↓ Executor（执行计划） ↓ Skill（能力集合） ↓ Workflow/Graph（流程调度） ↓ Node（具体功能单元） ↓ Tool（外部能力调用）LLM 只是其中一个模块，负责“思考”和“生成”。规划、调度、记忆、反思需要其他模块协同完成。
2.2 State、Session、Memory、Checkpoint 辨析
| 概念 | 回答的问题 | 生命周期 | 比喻 |
|---|---|---|---|
| Session | 是谁？ | 一次连接/登录 | 会话标识 |
| Memory | 聊过什么？ | 长期、跨会话 | 笔记本 |
| State | 做到哪里了？ | 当前任务执行期间 | 进度条 |
| Checkpoint | 存档点在哪？ | 持久化，用于恢复 | 游戏存档 |
State 详解：State 不是数据结构（dict），而是系统当前所处的执行现场。例如{"current_task": "rewrite", "retrieval_result": [...]}，它标记“现在做到哪一步”。
为什么项目需要两层 State？
- Agent State：关注“整个任务计划”（要做几个 Skill、现在做到哪个 Skill）
- Workflow State：关注“当前 Skill 内部的步骤”（JD 分析→检索→重写，现在卡在哪一步）
State 属于自己的层，不允许跨层污染。Agent 不需要知道 Workflow 内部细节，Workflow 不需要关心后续还有其他 Skill。
2.3 企业级 Agent 分层架构
API 层 ↓ Agent 层（入口、Session 管理） ↓ Planner 层（任务规划） ↓ Executor 层（任务调度） ↓ Skill 层（能力集合） ↓ Workflow 层（Skill 内部流程） ↓ Node 层（具体功能单元） ↓ Tool 层（LLM、API、数据库等）分层的核心目的：可扩展性（Scalability）。当 Skill 数量增长到几十个、Workflow 到几百个时，不分层的系统将无法维护。
第三部分：Reflection——Agent 的自我意识
3.1 为什么需要 Reflection？
LLM 会生成，但不会自我判断。第一次生成的结果只是一个“候选答案”，不是“最终答案”。
Reflection 让 Agent 在犯错后能“停下来想一想”，而不是将错就错。
Reflection 负责让 Agent 停下来思考，而不是盲目执行。
3.2 Reflection 的本质
Reflection 是“裁判（Judge）”，不是“球员（Generator）”。
输入：用户目标 + 当前产物
输出：结构化评价（分数、问题、是否需要重试）
{"score":75,"problem":"项目经历没有体现 Redis 经验","retry":true}Reflection 没有生成新内容，只是做了一个评判。
3.3 Reflection 的四种类型
| 类型 | 检查对象 | 触发位置 | 行动 |
|---|---|---|---|
| Output Reflection | 某个节点的输出 | 节点执行后 | 重做当前步骤 |
| Planning Reflection | Planner 生成的计划 | Planner 之后 | 重新规划 |
| Tool Reflection | 工具返回结果 | 工具调用后 | 调整参数重新调用 |
| Workflow Reflection | 整个 Skill 执行结果 | Workflow 结束后 | 回溯到内部节点或触发新 Skill |
3.4 Graph + Reflection
Node → Reflection ├── Score ≥ 90 → Graph 执行 → 继续 └── Score < 80 → Graph 执行 → 跳回 Retrieve 节点Graph 是“导航”，Reflection 是“司机”。Reflection 负责判断，Graph 负责执行判断结果。
3.5 Planner + Reflection
Planner 生成计划 → Reflection 检查计划 → 触发 Planner 重新规划（Replanning）。
前置 Reflection 的价值：在 Workflow 执行之前就发现计划问题，避免跑完整个流程才发现失败，大幅降低 Token 消耗。
3.6 Self-Reflection vs Self-Consistency
| Self-Reflection | Self-Consistency | |
|---|---|---|
| 方式 | 纵向深入：生成→检查→修正 | 横向比较：生成多个答案→选最佳 |
| 目标 | 提高单个答案质量 | 降低随机性，提高稳定性 |
| 代表技术 | Self-Refine, Reflexion | Self-Consistency |
为什么工业界越来越重视 Reflection？
Agent 最大的痛点不是“不会做”，而是做得不稳定。Reflection 提供了一种低成本、高效的方式来提升输出稳定性和成功率。
3.7 分层 Reflection 体系（Hierarchical Reflection）
工业界不是选一个位置放 Reflection，而是构建分层体系：
| 层级 | 检查内容 | 成本 | 能拦截的错误 |
|---|---|---|---|
| Node 后 | 格式、必填项 | 低 | 低级错误 |
| Workflow 后 | Skill 整体质量 | 中 | 流程内问题 |
| Planner 后 | 计划合理性 | 高 | 决策失误 |
| 最终输出前 | 全局一致性 | 高 | 整体质量 |
第四部分：核心认知总结
RAG 维度
RAG 不是“搜索 + LLM”，而是一条精密的流水线：Query Rewrite → Embedding → Retriever → Reranker → Prompt Builder → LLM。
- Chunk 决定 Recall 的上限
- Retriever 负责“找得到”
- Reranker 负责“排得准”
Agent 架构维度
Agent 不是一个 LLM，而是一个多层系统。每一层有自己的职责边界，State 不能跨层污染。
- Planner 决定“做什么”
- Executor 决定“怎么做”
- State 记录“做到哪了”
- Memory 记住“曾经聊过什么”
- Checkpoint 保证“随时能回来”
Reflection 维度
Reflection 是 Agent 从“自动工具”到“智能体”的质变。它让 Agent 能审视自己、纠正错误。
- Reflection 是 Judge，不是 Generator
- 分层 Reflection 是最佳实践
- Reflection + Graph + Planner = 可自我修正的智能系统