RAG（Retrieval-Augmented Generation）：对用户问题，先从外部知识库检索相关文档片段，再将其作为上下文送入 LLM 生成回答。

解决的核心问题：

• 知识时效性：LLM 知识截止于训练时间，RAG 可动态更新外部知识库
• 长尾知识：LLM 对低频知识记忆不可靠，RAG 提供精确文档引用
• 幻觉缓解：生成基于检索到的证据，可追溯来源
• 私有数据：无需将敏感数据注入模型参数，通过检索访问

RAG vs SFT：

维度	RAG	SFT（微调）
数据更新	实时，改知识库即可	需重新训练
成本	低（不改模型）	高（需 GPU 训练）
幻觉	有证据支撑，可溯源	可能仍然幻觉
行为定制	不改变模型风格	可改变语气/风格
适用场景	知识密集、频繁更新	风格适配、领域能力

端到端 RAG Pipeline：

1. 数据准备（Indexing）：
   • 文档加载（PDF/HTML/DB → 纯文本）
   • 文本切块（Chunking）：按固定长度/语义/段落切分
   • 向量化（Embedding）：文本 → 向量，存入向量数据库
   • 元数据标注（来源、时间、类别等）
2. 检索（Retrieval）：
   • Query 向量化 → 向量相似度搜索（ANN）
   • 可选：BM25 关键词检索（混合检索）
   • 重排序（Reranking）：用 Cross-Encoder 精排 Top-K 结果
3. 生成（Generation）：
   • 将检索到的文档片段组装为 Prompt Context
   • LLM 基于 Context + Query 生成回答
   • 可选：引用标注（标注哪句话来自哪个文档）

进阶 RAG 模式：

• Naive RAG：检索 → 生成（最简单）
• Advanced RAG：Query 改写 + 混合检索 + 重排
• Modular RAG：支持多轮检索、自适应检索、检索-生成交替

常见切块方法：

方法	原理	适用场景
固定长度切块	按字符/token 数切分，带重叠	通用，实现简单
语义切块	按嵌入相似度变化点切分	保持语义完整性
递归切块	先按段落 → 句子 → 固定长度逐级细分	LangChain 默认推荐
文档结构切块	按 Markdown 标题 / HTML 标签切分	结构化文档
句子窗口切块	以目标句为中心，取前后 N 句	精确检索 + 上下文保留

核心权衡：

• Chunk 太大：检索召回噪声多、embedding 精度下降、LLM 上下文浪费
• Chunk 太小：信息碎片化、缺乏上下文、检索结果不连贯
• 经验值：通用场景 512-1024 tokens，QA 场景 256-512 tokens
• 重叠（Overlap）：通常 10%-20%，防止切断重要信息

高级技巧：Parent-Child Chunking（小 chunk 检索，返回所属大 chunk）；Hierarchical Indexing（摘要索引 → 详细索引两级）。

选择维度：

• 语言支持：中文场景优选 BGE / M3E / Jina；英文可选 E5 / GTE / OpenAI
• 向量维度：768-1024 维平衡精度与效率，4096 维适合高精度场景
• 最大输入长度：512 tokens（常规）→ 8192 tokens（长文本 embedding）
• 推理速度：轻量模型（110M）适合实时场景，大模型（7B）适合离线索引

评估指标（MTEB Benchmark）：

• Recall@K：Top-K 检索结果中包含正确答案的比例
• NDCG@K：考虑排序位置的检索质量
• MRR：第一个正确结果的平均排名倒数

实用建议：先用 MTEB 排行榜筛选候选模型，再在自己的数据上 fine-tune 或评测选择。

检索优化技术全景：

1. Query 优化：
   • Query Rewriting：让 LLM 改写用户问题为更适合检索的形式
   • HyDE：让 LLM 先生成假设性答案，再用答案做检索（效果惊人）
   • Multi-Query：生成多个变体 query 并合并检索结果
2. 混合检索（Hybrid Search）：
   • 向量检索（语义相似）+ BM25（关键词匹配）→ RRF 融合排序
   • 解决纯向量检索对精确匹配（如编号、人名）不敏感的问题
3. 重排序（Reranking）：
   • 用 Cross-Encoder（如 bge-reranker）对 Top-50 精排
   • Cross-Encoder 精度 > Bi-Encoder 但速度慢，适合二阶段
4. 多级索引：
   • Summary Index：先检索摘要，再定位具体 chunk
   • Knowledge Graph Index：实体/关系图，支持多跳推理

现象：当 LLM 的输入 Context 较长时，模型倾向于关注头部和尾部的信息，而忽略中间部分的内容（Stanford 2023 论文）。

对 RAG 的影响：如果最相关的检索结果被放在中间位置，LLM 可能忽略它而给出错误答案。

缓解方法：

• 排序策略：将最相关的 chunk 放在 Context 的开头或结尾
• 控制 Context 长度：只放入 Top-3~5 最相关的 chunk，不要塞太多
• 分段总结：对每段检索结果先做摘要，再拼接
• Map-Reduce：每个 chunk 独立回答，最后合并答案
• 长上下文模型：使用训练时支持长上下文的模型（如 Qwen2.5-128K），"Lost in the Middle" 效应减弱

分阶段评估：

阶段	指标	含义
检索	Context Precision	检索结果中相关文档的比例
	Context Recall	所有相关文档被检索到的比例
	MRR / NDCG	排序质量
生成	Faithfulness（忠实度）	生成内容是否基于检索到的证据
	Answer Relevancy	回答是否切中问题
	Hallucination Rate	生成中不在 Context 里的信息比例

评估框架：RAGAS（自动化评估）、TruLens、LangSmith。

实用做法：构建 golden test set（问题 + 标准答案 + 标准源文档），自动化回归测试。

向量检索的局限：语义相似 ≠ 逻辑关联。例如 "A 公司的 CEO 是谁？CEO 的母校？" 需要两跳推理，纯向量检索难以处理。

适合 KG 的场景：

• 多跳推理：需要关联多个实体的信息
• 结构化数据：数据本身有明确的实体-关系结构（如医疗知识、法规条文）
• 精确约束："列出所有满足条件 X 的实体"
• 因果/时序：事件发展链、因果链

Graph RAG 架构：

1. 文档 → LLM 抽取实体和关系 → 构建知识图谱
2. Query → 实体识别 → 子图检索 → 路径/关系作为 Context
3. LLM 基于图结构信息生成答案

实际建议：向量检索 + KG 结合是最强方案。向量提供语义覆盖，KG 提供结构化精确推理。

Agent = LLM + Planning + Memory + Tools + Action

组件	功能	实现方式
LLM（大脑）	理解指令、推理决策	GPT-4 / Claude / Qwen
Planning（规划）	将复杂任务分解为可执行步骤	CoT / ToT / ReAct
Memory（记忆）	维护上下文和历史信息	短期：对话 buffer；长期：向量数据库
Tools（工具）	扩展 LLM 能力边界	API调用、代码执行、搜索引擎
Action（行动）	在环境中执行操作	Function Calling、代码沙箱

Agent 与普通 LLM 对话的本质区别：

• LLM 对话：输入 → 输出（单轮/多轮，但不主动行动）
• Agent：感知 → 思考 → 行动 → 观察 → 再思考（闭环迭代）

自主性是 Agent 的核心特征——能在最少人工干预下完成目标。

ReAct = Reasoning + Acting（交替执行）

循环过程：

Thought: 我需要先了解X的背景...
Action: search("X background")
Observation: [搜索结果返回...]
Thought: 从结果看，X是...接下来需要...
Action: lookup("Y detail")
Observation: [查询结果...]
Thought: 现在我有足够信息来回答了
Action: finish("最终答案...")

vs 纯 CoT 的优势：

• CoT 只思考：容易产生幻觉（没有外部验证）
• ReAct 思考+行动：每步推理都可以通过外部工具验证，减少错误累积
• 可观测性：每步 Thought 暴露推理过程，便于调试

局限性：严重依赖 LLM 的 instruction following 能力；错误的 Thought 会导致错误 Action 链式传播；每步都需调用 LLM，延迟高。

方法	结构	思路	适用场景
CoT	链式	逐步推理，一条路径	简单推理、数学题
CoT-SC	发散+投票	多条 CoT 路径，多数投票	提升 CoT 准确率
ToT	树形	每步生成多个候选，评估剪枝	需要回溯的任务（24点）
GoT	图形	可分解也可合并	需分治再合并（排序）
Plan-and-Execute	两阶段	先出完整计划，再逐步执行	复杂多步任务

实际工程中：大多数 Agent 框架使用 Plan-and-Execute 模式（如 AutoGPT 的 task queue），因为：

• ToT/GoT 需要多次调用 LLM 评估每个节点，成本极高
• Plan-and-Execute 更工程友好，计划可以被人审核修改

短期记忆（Working Memory）：

• 实现：LLM 的上下文窗口（最近 N 轮对话 / 最近 K 步 action-observation）
• 挑战：上下文有限，需要压缩/截断策略
• 优化：对话摘要（定期压缩旧对话为摘要）、滑动窗口 + 关键信息固定

长期记忆（Long-term Memory）：

• 实现：向量数据库（如 ChromaDB / Pinecone）存储历史经验
• 存储内容：历史对话、任务执行经验、学到的教训、用户偏好
• 检索：每次行动前，从长期记忆中检索相关经验作为参考

Reflexion 模式（自我反思记忆）：

1. 执行任务 → 评估结果 → 生成反思（成功/失败原因）
2. 将反思存入长期记忆
3. 下次遇到相似任务时检索历史反思，避免重复错误

类比：短期记忆 ≈ 人的工作记忆（7±2 items）；长期记忆 ≈ 人的经验/知识库。

Function Calling 流程：

1. 定义工具：用 JSON Schema 描述函数名、参数、用途
2. 模型决策：LLM 根据 query + 工具描述，决定是否调用、调哪个、参数是什么
3. 执行：系统解析 LLM 输出的 JSON，调用对应 API
4. 返回结果：将 API 结果注入对话，LLM 继续生成

// 工具定义示例
{
  "name": "get_weather",
  "description": "获取指定城市的天气",
  "parameters": {
    "type": "object",
    "properties": {
      "city": {"type": "string", "description": "城市名"}
    },
    "required": ["city"]
  }
}

LLM 如何学会调用工具？

• SFT 训练：在训练数据中加入工具调用示例（OpenAI 方式）
• Prompt Engineering：在 system prompt 中定义工具格式（开源模型）
• Agent 框架：LangChain/CrewAI 等封装了工具注册和调用逻辑

MCP（Model Context Protocol）：Anthropic 提出的标准化协议，让模型和工具之间有统一接口，类似 USB 协议之于外设。

核心思想：多个专业化 Agent 分工协作，完成单个 Agent 难以胜任的复杂任务。

代表框架：

框架	模式	特点
MetaGPT	SOP 驱动	模拟软件公司（PM→架构师→工程师→QA）
AutoGen	对话驱动	Agent 间自由对话协商
CrewAI	角色+任务	定义角色、目标、工具，自动协调
斯坦福小镇	仿真驱动	Agent 有记忆、日程，涌现社会行为

优势：

• 专业化分工：每个 Agent 专注一个领域
• 质量把关：Agent 之间互相 review（如代码审查 Agent）
• 复杂任务分解：自然地将大任务拆分为子任务

挑战：

• 通信开销：Agent 间信息传递的准确性和效率
• 协调困难：谁来决策冲突？死锁怎么办？
• 成本：多个 Agent = 多次 LLM 调用 = 高延迟高成本
• 错误传播：一个 Agent 的错误输出会影响下游所有 Agent

安全风险：Agent 有执行能力（调 API、写代码），错误行动可能造成实际损害（删除文件、发送错误邮件、泄露数据）。

保障方法：

1. 权限控制（Sandboxing）：
   • 限制 Agent 可调用的工具集
   • 代码执行在沙箱中（如 Docker）
   • 不可逆操作需人工确认（Human-in-the-loop）
2. 行动验证：
   • 在执行前用另一个 LLM 审核行动是否安全
   • 规则引擎过滤危险操作
3. 可观测性：
   • 完整记录 Thought-Action-Observation 日志
   • 设置 token/API 调用/执行步数上限
4. Constitutional AI 思路：
   • 定义 Agent 行为准则（Constitution）
   • 每次行动前自查是否违反准则

为什么 Agent 评估更难：

• Agent 的输出不是文本，而是行动序列+最终结果
• 同一目标可有多条正确路径（过程不唯一）
• 需要模拟环境或真实环境执行
• 评估需要考虑效率（步数/成本）和安全性

评估维度：

维度	指标
任务成功率	最终是否完成目标
效率	完成所需步数、API 调用次数、总 token 消耗
鲁棒性	面对异常（API 报错、歧义指令）的恢复能力
安全性	是否有越权操作、信息泄露
规划质量	步骤分解是否合理、是否走弯路

评估基准：WebArena（网页操作）、SWE-bench（代码修复）、AgentBench（综合）、ToolBench（工具调用）。

A2A（Google 2025 提出）的核心区别：

普通 Multi-Agent 框架（如 CrewAI/AutoGen）中，Agent 是由同一个开发者定义、在同一个系统内运行的。A2A 解决的是跨组织、跨系统的 Agent 互操作。

关键不同点：

维度	普通 Multi-Agent	A2A
信任模型	同一系统内，完全信任	跨组织，需要认证授权
通信协议	框架内 API	标准化协议（类似 HTTP）
能力发现	硬编码	Agent Card（自描述能力）
异步协作	通常同步	支持长时间异步任务

类比：普通 Multi-Agent ≈ 一个公司内部的团队协作；A2A ≈ 不同公司之间的 B2B API 合作。

A2A 核心概念：Agent Card（描述能力和端点）、Task（跨 Agent 任务协调）、Message（通信单元）、Artifact（工作产物）。

框架	核心定位	优势	适用场景
LangChain	通用 LLM 应用开发	生态丰富、组件多、灵活	RAG + Agent 综合应用
LlamaIndex	数据连接与索引	索引策略丰富、数据管道强	复杂知识库 RAG
CrewAI	Multi-Agent 编排	角色定义简单、协作模式清晰	多 Agent 协作任务
AutoGen	Agent 对话框架	对话驱动、灵活编排	研究/探索型 Agent
Dify/Coze	低代码 Agent 平台	可视化搭建、部署简单	快速原型/产品化

选型决策树：

• 只需 RAG → LlamaIndex
• RAG + 简单 Agent → LangChain
• 多 Agent 协作 → CrewAI / AutoGen
• 快速产品化 → Dify / Coze
• 需要高度定制 → 自研（基于 Function Calling）