RAG（Retrieval-Augmented Generation，检索增强生成）对做 Agent 很关键：它让模型“先查再答”，把回答锚定在你自己的知识库/工具结果上，而不是只靠参数记忆。
1) 用 RAG 解决哪类问题
常见目标不同，架构也不同：
- 问答（QA）：用户提问 → 找相关片段 → 组合上下文 → 生成答案（可引用来源）。
- 搜索/浏览（Search）：更像“给用户相关资料列表”，生成只是润色。
- 多文档综合/对比：需要“检索 + 结构化提取 + 汇总/对照”，常要多轮检索或分阶段。
- “工具型 Agent”：检索只是其中一个工具；要有决策逻辑（何时检索/何时调用 API/何时追问用户）。
在 Agent 里，RAG 最怕“什么问题都一把梭”：你要定义 何时需要检索、检索失败怎么办、召回不确定时是否追问。
2) RAG 的核心不是“向量库”，而是“可控的证据链”
需要确保：答案能追溯到检索到的证据，否则就是“看起来像用了 RAG，实际上还是在编”。
工程上通常要做：
- 强制引用：答案里必须带
source_id/URL/段落号。 - 基于证据回答：提示词或解码策略要求“只用上下文信息回答；没有就说不知道/需要更多信息”。
- 置信度与拒答：当检索相似度低或证据不足时，触发澄清问题或拒答。
3) 分块（Chunking）决定了上限
把文档怎么切，直接影响召回与可读性：
- 块太大：召回到一大坨无关内容，模型读不动/容易忽略关键句。
- 块太小：语义断裂，答案需要的上下文不在同一块里。
常见做法：
- 按自然结构切：标题/小节/列表/函数注释/FAQ 条目。
- 用重叠窗口（overlap）保留跨段信息。
- 为每个 chunk 保留元数据：文档名、章节路径、更新时间、权限、语言等（后面做过滤和引用很关键）。
对代码库/接口文档：按“模块/文件 + symbol（类/函数）+ 注释块”切通常比按固定字数更好。
4) 检索不止向量：“混合检索 + 过滤”
单靠向量相似度经常在以下场景翻车：精确术语、版本号、报错码、用户名/订单号、短 query。
你要会组合：
- BM25/关键词检索：对精确词、错误码、专有名词更稳。
- 向量检索：对语义相近、同义改写更稳。
- Hybrid 融合：加权/学习排序/规则融合。
- 元数据过滤：例如只查
product=xxx、lang=zh、version>=1.8、tenant_id。 - 时间衰减：优先新文档（尤其是产品/政策/接口更新频繁时）。
5) Query 改写与多跳检索（Multi-hop）
真实用户问题经常不适合直接检索：
- Query rewrite：把口语问题改成可检索的关键词/结构化查询（补全产品名、同义词、限定版本）。
- 分解问题：先问“这指的是哪个系统/哪个版本/哪类用户？”或把复杂问题拆子问题分别检索。
- 多跳：先检索“概念定义”，再检索“具体参数/步骤”，最后综合。
Agent 里常见策略：plan → retrieve → read → (if missing) retrieve again → answer with citations。
6) Context building
把 topN chunk 原样拼接经常导致：
- 重复内容
- 相互矛盾
- 关键句被淹没
更稳的方式：
- 去重/聚类：同一段落不同版本只保留一份。
- 按问题维度组织：例如“定义/步骤/限制/示例/注意事项”。
- 冲突检测：同一问题多个来源冲突时，显式说明差异，并按更新时间/权威性排序。
7) 评估与监控
至少要建立三层指标：
- 检索指标：Recall@K、MRR、命中率（ground truth chunk 是否被召回）。
- 生成指标：基于引用的正确率、回答完整率、是否出现“无证据断言”。
- 线上指标：用户满意度、二次追问率、人工纠错率、延迟与成本。
并且要做日志与可观测性：
- 记录 query、改写后的 query、召回列表、相似度、最终引用了哪些 chunk。
- 这样你才能定位是“检索错”还是“模型编”还是“chunk 切坏了”。
8) 常见失败模式
- “看起来很像”但答错：召回没命中关键段落；或排序错。
- 引用了但结论不对应：模型把证据“扭曲”了 → 需要更强的证据约束/回答格式。
- 版本/时效性错误：缺少时间过滤、没有按版本检索。
- 权限泄露：多租户/内网文档未做 ACL 过滤（这在企业场景是致命问题）。
- 长上下文失真：上下文太长导致模型忽略关键句 → 控制 N、做摘要式 context、或重排后只保留最相关片段。
RAG 技术全景图
https://github.com/langchain-ai/rag-from-scratch
核心骨架：从问题到答案的主线
首先看图片中间那条横向的黑色实线，这是 RAG 的运行时流（Runtime Flow）：
- Question (输入)：用户提出问题。
- 处理节点 (圆圈)：问题经过“翻译”和“路由”。
- Data Sources (数据库)：根据路由结果，从图数据库、关系型数据库或向量数据库中提取信息。
- Documents (文档)：提取出的原始资料。
- Filter (漏斗)：对资料进行精炼和重排序。
- Brain (LLM)：大模型结合资料进行推理。
- Answer (输出)：生成最终回答。
六大功能模块（彩色区块）
图中用不同颜色的虚线框标出了 RAG 的六个核心增强环节，这是理解高级 RAG 的关键：
A. Indexing (蓝色 - 索引阶段)
这是离线准备阶段，决定了数据如何被“喂”给系统。
- Chunk Optimization: 比如 Semantic Splitter，不再生硬地按字符切分，而是按语义逻辑切分。
- Multi-representation: 比如 Parent Document，存储详细原文但索引简要摘要。
- Hierarchical Indexing: 比如 RAPTOR，构建文档树，实现跨层级的语义检索。
B. Query Translation (红色 - 查询翻译)
在检索之前，先对用户的问题进行“整容”。
- Multi-query / Step-back: 将复杂问题拆解或抽象成更容易检索的关键词。
- HyDE (Hypothetical Document Embeddings): 先让 AI 生成一个伪答案，用伪答案去检索，通常比直接用问题检索更精准。
C. Query Construction (黄色 - 查询构建)
将自然语言转换为数据库能懂的语言。
- Text-to-SQL: 针对关系型数据库。
- Text-to-Cypher: 针对图数据库。
- Self-query: 自动从问题中提取元数据过滤器（如“查找2023年的文档”）。
D. Routing (橙色 - 路由)
决定去哪里找答案。
- Logical Routing: 根据逻辑判断该去哪个库。
- Semantic Routing: 根据语义相似度选择不同的 Prompt 或知识库。
E. Retrieval (绿色 - 检索与精炼)
检索出来后，对结果进行二次加工。
- Post-processing: 包含 Re-Rank（重排序）和 CRAG（验证检索内容是否相关，不相关则去搜网页）。
- Active Retrieval: 如果初始结果不够好，系统会自动发起二次检索。
F. Generation (紫色 - 生成增强)
在最后生成阶段加入纠错机制。
- Self-RAG / RRR: 模型在生成时会自我检查：“我引用的对吗？”或者“我需要重新检索吗？”。
理解“闭环”与“动态性”
注意图中紫色的回流箭头。这代表了主动 RAG (Active RAG) 的思想：生成不再是终点。如果生成的质量不高，或者检索到的文档无法回答问题，系统会触发重新改写问题或重新检索的循环，直到答案满意为止。