记忆与 RAG
Day 15 - Weekly Review 3: Memory + RAG Design
今日目标
能输出《知识库问答 Agent 设计 v0.1》，理清记忆、上下文与外部知识的边界。
学习安排
| 时间 | 模块 | 做什么 |
|---|---|---|
| 0-10 分钟 | 产出盘点 | 翻出 Day 11-14 的四份产物，对照交付物清单逐项核对。 |
| 10-25 分钟 | 概念回顾 | 快速复述记忆、RAG、metadata 的关键概念，标出说不清的点。 |
| 25-45 分钟 | 综合设计 | 把四天产物整合成《知识库问答 Agent 设计 v0.1》，补齐七个模块。 |
| 45-55 分钟 | 追问与反思 | 回答追问练习，重点想冲突消解与评估问题。 |
| 55-60 分钟 | 复盘与作业 | 整理查漏清单，定下阶段 4 开始前要补的一点。 |
核心概念
| 术语 | 中文解释 | 应用场景 |
|---|---|---|
| memory vs RAG | 记忆与 RAG 的分工：记忆管用户的个性化信息，RAG 管外部知识，两者共同进入上下文 | "按我的格式出报告"用记忆，"怎么排查 Nginx 503"用知识库 |
| source priority | 来源优先级：记忆、知识库、模型内置知识冲突时，按什么顺序采信 | 知识库说 A、模型说 B 时以知识库为准并提示 |
| conflict resolution | 冲突消解：记忆与知识库矛盾时的处理策略 | 用户项目已下线，但记忆里还存着旧项目名 |
| correction mechanism | 纠正机制：用户指出错误后，如何修正记忆与知识库 | 用户说"这个命令过期了"，触发文档修订流程 |
| retrieval evaluation | 检索评估：用命中率、精确率等指标衡量检索质量 | 每周用 10 个标准问题回归检索效果 |
| knowledge base | 知识库：经过清洗、切分、索引的外部知识集合 | 测试文档库：排障手册、模板、规范 |
| citation | 引用：答案标注来源，让用户可核验 | 回答末尾附来源文件名与片段编号 |
| feedback loop | 反馈闭环：用户反馈 → 更新记忆或知识库 → 再验证 | 纠正一次错误后，同类问题不再答错 |
阅读重点
- 对应章节：第 3 章整体回顾：用户记忆与知识库（跨会话记忆、用户画像、RAG、结构化索引、检索质量）
- 关注点：记忆、短期上下文、外部知识三者的边界：各管什么、如何进入上下文
- 关注点：冲突处理与纠正机制：记忆与知识库矛盾时怎么办
- 关注点：安全边界：哪些信息能进系统、哪些必须人工把关
- 关注点：评估：RAG 质量怎么度量、怎么持续改进
- 补充材料：回看第 2 章上下文工程，确认记忆与检索结果在上下文中的位置
- 补充材料：检索评估相关材料：recall@k 与人工抽查结合的做法
理解检查
- 用户记忆和 RAG 的区别是什么？各回答哪类问题？
- 回答用户问题时，优先用记忆还是知识库？判断依据是什么？
- 如果记忆和知识库冲突怎么办？处理流程是什么？
- 如何让用户纠正错误记忆？纠正后会发生什么？
实践任务
背景：阶段 3 的交付物是一份完整设计。把 Day 11-14 的产物整合成《知识库问答 Agent 设计 v0.1》，为 Day 16 之后接入工具做准备。
- 盘点四份产物：记忆边界清单、RAG 流程设计、metadata schema、最小 Demo
- 按模板补齐七个模块：用户输入、记忆读取、知识库检索、回答生成、来源引用、反馈更新、安全边界
- 每个模块写清：输入、处理、输出、依赖哪个 Day 的产物
- 最后写一段"v0.1 不做的事"，控制范围，这是复盘日最容易忽略的一步
输出模板
# 知识库问答 Agent 设计 v0.1
## 1. 用户输入
- 输入形式：[自由文本问题]
- 需要补充的信息：[如环境、项目、时间范围]
## 2. 记忆读取
- 读取策略：[按用户与任务类型读取 user profile / preference memory]
- 读取时机：[会话开始 / 回答之前]
## 3. 知识库检索
- 数据来源：[文档清单，可引用 Day 12]
- 过滤条件：[environment / project 等 metadata，可引用 Day 13]
- 检索方式：[关键词或向量]，top_k=[5]
## 4. 回答生成
- 生成约束：[只基于片段回答，信息不足时说明]
- 冲突处理：[知识库优先于记忆，记忆优先于模型内置知识]
## 5. 来源引用
- 引用格式：[文件名 + 片段编号]
- 不可引用时：[明确标注"知识库未覆盖"]
## 6. 反馈更新
- 用户纠正后：[更新记忆 / 标记知识库待修订]
- 更新条件与审核：[谁可以改，改前是否确认]
## 7. 安全边界
- 绝不处理的信息：[敏感身份信息等，可引用 Day 11 清单]
- 需要人工确认的操作：[高风险结论、删除操作]
## v0.1 不做的事
- [如：不做多轮追问、不做权限系统、不做自动更新]示范输出
# 知识库问答 Agent 设计 v0.1
## 1. 用户输入
- 输入形式：自由文本问题，如"如何排查 Nginx CPU 升高"
- 需要补充的信息：环境（默认 prod）、项目（默认 order-service）、时间范围（可选）
## 2. 记忆读取
- 读取策略：读取用户输出格式偏好与常用项目名
- 读取时机：会话开始时加载 user profile，生成前读取 preference memory
## 3. 知识库检索
- 数据来源：nginx-cpu-spike.md、load-test-report-template.md、defect-report-guideline.md
- 过滤条件：environment=prod AND project=order-service
- 检索方式：关键词加向量混合，top_k=5
## 4. 回答生成
- 生成约束：只基于片段回答，片段没提的标注"知识库未覆盖"
- 冲突处理：知识库优先于记忆，记忆优先于模型内置知识
## 5. 来源引用
- 引用格式：[文件名 #片段编号]
- 不可引用时：明确标注"知识库未覆盖，以下为通用建议"
## 6. 反馈更新
- 用户纠正后：输出格式类纠正直接更新 preference memory；内容错误标记文档待修订，由 owner 确认后修改
- 更新条件与审核：知识库修改需 owner 确认，记忆修改需用户确认
## 7. 安全边界
- 绝不处理的信息：账号密码、未公开的版本计划
- 需要人工确认的操作：涉及删除、修改生产配置的建议
## v0.1 不做的事
- 不做多轮追问、不做用户权限系统、不做知识库自动更新追问练习
- 如何评估 RAG 系统质量？除了检索指标，答案层面还要评估什么？
- 记忆和知识库冲突时如何取舍？"知识库优先"在所有情况下都成立吗？
- 这个设计最大的风险是什么？如果明天上线，你最担心哪一环？
- 阶段 4（Day 16-20）要接入工具了，这个设计里哪些模块会与工具产生交互？
常见误区
- 把记忆与 RAG 混为一谈：记忆是"用户相关"，RAG 是"外部知识"，回答两类问题的来源不同。
- 有引用但没有可信度分层：知识库内容也会过期，有引用不等于答案正确。
- v0.1 想一次做全：范围失控是复盘日最常见的失败原因，写清"不做的事"与"要做的事"同等重要。
- 把设计文档写成代码：v0.1 的目标是理清边界与顺序，实现细节留给阶段 4。
进阶扩展
- 分层记忆架构：episodic / semantic / preference 分层存储与检索，是生产级 Agent 的常见形态。
- RAG 评估体系：检索端 recall@k 加答案端忠实度、有用性人工评估，形成持续改进回路。
- 知识库运营：文档 owner、版本审批、变更通知，让知识库像代码库一样被治理。
今日作业
- 完成《知识库问答 Agent 设计 v0.1》，七个模块齐全。
- 对照 Day 11-14 的四份产物，列出设计文档里"还没做"的 3 项。
- 写 3 个下阶段（工具、MCP、Coding Agent）想解决的问题。
- 明天开始前，用 5 分钟向同事讲一遍这个设计的七模块流程。