一、RAG 基础原理
Q1：什么是 RAG？请描述其核心原理和三阶段流程
答：
RAG（Retrieval-Augmented Generation，检索增强生成）是一种将信息检索与生成式模型结合的技术，本质是给大模型"外挂一个实时知识库"，解决大模型的知识截止、幻觉等问题。
三阶段流程：
检索（Retrieve）→ 增强（Augment）→ 生成（Generate）
| 阶段 | 核心操作 | 关键技术 |
|---|---|---|
| 检索阶段 | 将用户 Query 向量化，从外部知识库搜索相关文档片段（Chunk） | Embedding 模型、向量数据库（Milvus/Faiss/ES）、ANN 搜索 |
| 增强阶段 | 将检索到的文档片段与原始问题拼接构建 Prompt | Prompt Engineering、上下文组织 |
| 生成阶段 | 将增强后的 Prompt 输入 LLM，生成最终答案 | GPT/Qwen/GLM 等大模型 |
完整工作流（6 步）：
- 用户提问
- 数据准备：文档清洗、切块（PDF→文本切片）
- 向量化：Embedding 模型（BGE、text-embedding-3 等）将文本转为高维向量
- 索引存储：向量存入向量数据库
- 检索增强：用户 Query 向量化后从库中检索 Top-K 相关片段
- 生成答案：检索结果 + 问题 → LLM → 最终回答
Q2：RAG 相比大模型微调（Fine-tuning）的优劣势是什么？
答：
| 维度 | RAG | Fine-tuning |
|---|---|---|
| 成本 | 低（无需训练） | 高（GPU 训练、数据标注） |
| 更新速度 | 实时（修改文档即生效） | 慢（需重新训练） |
| 知识私密性 | 知识在外部库，相对安全 | 知识融入模型权重 |
| 可解释性 | 高（可追溯检索来源） | 低（知识黑盒化） |
| 适用场景 | 私域知识、实时数据、长尾知识 | 风格迁移、领域能力提升 |
| 幻觉风险 | 较低（有文档锚定） | 较高（无来源验证） |
结论： 生产环境中通常优先考虑 RAG，Fine-tuning 用于风格/格式对齐，二者可结合使用。
Q3：RAG 的常见失败场景有哪些？如何解决？
答：
| 失败场景 | 原因 | 解决方案 |
|---|---|---|
| 检索空洞 | Query 与文档语义差异大 | Query 改写、HyDE、多路检索 |
| 召回不准 | 分块策略不当、向量模型差 | 优化分块大小、微调 Embedding 模型 |
| 上下文溢出 | 检索文档超过 LLM 上下文限制 | 压缩摘要、动态截断、Rerank 排序 |
| 多文档冲突 | 不同文档答案矛盾 | 权威度加权、多视角输出、提示词控制 |
| 时效性问题 | 知识库未更新 | 增量索引、添加时间敏感性提示 |
| 幻觉拼凑 | LLM 忽视检索结果凭空捏造 | 强制引用约束、Self-RAG 信号机制 |
Q4：解释 HyDE（Hypothetical Document Embeddings）的原理和应用场景
答：
原理： HyDE 的核心思路是"用假设答案代替真实 Query 做检索"：
- 将用户 Query 输入 LLM，让其生成一段假设性答案文本（不要求正确）
- 对这段假设答案进行 Embedding 向量化
- 用该向量在真实知识库中检索相似文档
为什么有效：
- 用户 Query 通常很短（5~20字），而知识库文档是长文本，二者向量分布有差异
- 假设答案与文档风格更接近，向量相似度更高，检索更准确
适用场景：
- Query 极短或模糊（如："推荐算法"）
- 用户 Query 与文档术语不一致（口语 vs 专业术语）
二、RAG 系统构建与优化
Q5：RAG 的文本分块（Chunking）策略有哪些？如何选择？
答：
| 分块策略 | 适用场景 | 优缺点 |
|---|---|---|
| 固定大小分块 | 通用场景 | 简单快速，可能打断语义完整性 |
| 句子级分块 | 语义要求高 | 语义完整，但大小不均匀 |
| 段落级分块 | 结构化文档 | 保留文章结构，但 chunk 可能过大 |
| 重叠分块（Sliding Window） | 上下文连贯性要求高 | 保留边界上下文，存储冗余 |
| Small-to-Big 检索 | 长文档精确定位 | 先检索小块定位，再扩展到大块提供上下文 |
| 语义分块（Semantic Chunking） | 高质量检索 | 按语义边界切割，效果好但计算成本高 |
实践建议：
- Chunk 大小通常在 512~1024 token
- 重叠（overlap）建议 10%~20%
- 标题/元数据应随 chunk 一起存储，便于过滤
Q6：如何优化 RAG 的检索召回率？
答：
方案一：Query 扩展
- 同义词替换（如"机器学习" → "ML、人工智能训练"）
- LLM 改写（生成多个查询变体，合并结果）
- HyDE（生成假设文档检索）
方案二：混合检索（Hybrid Search）
- 稠密检索（Dense Retrieval）：基于 Embedding 向量的语义检索
- 稀疏检索（Sparse Retrieval）：基于 BM25 的关键词检索
- 通过 RRF（Reciprocal Rank Fusion）融合两路结果，同时覆盖语义和关键词
方案三：重排序（Reranking）
- 初步召回 Top-50，再用 Reranker 模型（如 BGE-Reranker、Cohere Rerank）精排 Top-5
- 二阶段检索显著提升精确率
方案四：优化分块和 Embedding
- 多粒度分块（chapter→paragraph→sentence）
- 针对业务领域微调 Embedding 模型
Q7：什么是迭代检索（Iterative Retrieval）？与普通 RAG 有何区别？
答：
普通 RAG（单轮）：
Query → 检索 → 生成答案（一次完成）
迭代 RAG（多轮）：
Query → 检索₁ → LLM生成中间答案 → 以中间答案为新Query → 检索₂ → 最终生成
（可循环多次直到满足终止条件）
适用场景： 复杂推理、多跳问题（需要先查A再查B）
相关变体：
- FLARE：LLM 在生成过程中主动触发检索，检测到低置信词时检索补充
- Self-RAG：模型生成特殊 token（如
[Retrieval]）来决定何时需要检索
Q8：RAG 如何处理多文档冲突信息？
答：
冲突产生的原因：不同文档对同一问题有不同甚至矛盾的描述（如不同时间版本的政策文件）。
解决策略：
- 权威度加权：根据来源可信度排序（官方文档 > 学术论文 > 博客），优先采信高权威来源
- 时间戳优先：选择最近更新的文档
- Prompt 引导：在系统提示中明确告知 LLM "如遇到矛盾信息，列出各观点并标注来源"
- 多视角输出：呈现多种观点，让用户判断，适用于争议性问题
- 置信度投票：多文档支持的观点获得更高权重
Q9：如何优化长文档的 RAG 检索效果？
答：
方案一：层次化检索
- 第一层：文档摘要级别索引，快速定位相关文档
- 第二层：段落/句子级索引，精确定位答案片段
方案二：Small-to-Big（子父块检索）
- 索引时：小 chunk 做检索（精准定位）
- 返回时：扩展为包含该小 chunk 的大 chunk（提供更完整上下文）
方案三：知识图谱增强
- 将文档内容抽取为实体-关系三元组，构建知识图谱
- 检索时同时走向量检索 + 图查询，解决多跳推理问题（GraphRAG）
方案四：位置感知分块
- 保存 chunk 在原文中的位置信息（章节标题、页码）
- 检索时可合并相邻 chunk，保证上下文连贯
Q10：RAG 如何适配实时更新的知识库？
答：
| 方案 | 实现方式 | 特点 |
|---|---|---|
| 增量索引 | 新文档入库时直接 Embedding 并写入向量库 | 接近实时，无需全量重建 |
| 定时全量重建 | 每日/每周重建索引 | 适合低频更新场景 |
| 数据分区 | 冷热数据分离，热数据频繁更新 | 平衡性能和实时性 |
| 时间戳过滤 | 检索时加入时间范围过滤条件 | 确保使用最新文档 |
注意： 知识库更新无需重新训练生成模型，这是 RAG 相比 Fine-tuning 的核心优势之一。
三、RAG 评估与质量保证
Q11：如何评估 RAG 系统的检索质量？
答：
核心评估指标：
| 指标 | 含义 | 计算方式 |
|---|---|---|
| Precision@K | Top-K 结果中相关文档的比例 | 相关结果数 / K |
| Recall@K | 所有相关文档中被检索到的比例 | 检索到的相关数 / 总相关数 |
| MRR（Mean Reciprocal Rank） | 第一个正确结果排名的倒数均值 | 反映排名质量 |
| NDCG | 综合考虑相关度和排名位置 | 适合多级相关性评估 |
测试流程：
- 构建测试集：人工标注 200~500 组 QA 对，每组含问题 + 标准答案 Chunk
- 批量检索：将测试问题批量输入检索模块
- 对比计算：将返回结果与标准答案对比，计算上述指标
- 持续监控：在生产环境中设置指标报警
Q12：如何评估 RAG 生成答案的质量？
答：
自动评估指标：
- ROUGE/BLEU：生成文本与参考答案的字面重叠度（适合封闭域，需谨慎）
- RAGAS 框架：专为 RAG 设计的评估框架，包含以下维度：
faithfulness（忠实度）：答案是否忠实于检索文档answer_relevancy（答案相关性）：答案是否回答了问题context_precision（上下文精确率）：检索文档是否相关context_recall（上下文召回率）：相关文档是否被检索到
人工评估维度：
- 事实准确性：对比标准答案，答案是否正确
- 引用精确度：引用内容与源文档的一致性
- 完整性：是否覆盖所有关键信息
- 无害性：是否存在有害或歧视性内容
四、向量数据库
Q13：向量数据库的核心原理是什么？
答：
向量数据库将非结构化数据（文本、图片、音频）转换为高维向量存储，通过近似最近邻（ANN）搜索快速找到语义相似内容。
核心三步：
原始数据 → [Embedding模型] → 高维向量 → [ANN索引] → 毫秒级相似搜索
主流索引算法：
| 算法 | 原理 | 特点 |
|---|---|---|
| HNSW | 分层导航小世界图，多层跳跃结构 | 搜索复杂度 O(log N)，高召回率，内存占用大 |
| IVF（倒排文件） | 将向量空间分区，只搜索相近分区 | 内存友好，召回率略低 |
| PQ（乘积量化） | 将高维向量压缩为低维编码 | 大幅压缩内存，速度快 |
| LSH（局部敏感哈希） | 相似向量大概率映射到同一哈希桶 | 实现简单，精度较低 |
对比传统数据库：
| 特性 | 传统数据库 | 向量数据库 |
|---|---|---|
| 数据类型 | 结构化数据 | 高维向量 |
| 检索方式 | 精确匹配（SQL） | 近似最近邻（ANN） |
| 典型场景 | 订单查询 | 语义搜索、推荐 |
Q14：常见向量数据库有哪些？如何选型？
答：
| 向量库 | 特点 | 适用场景 |
|---|---|---|
| Milvus | 分布式、高性能、开源、功能丰富 | 大规模生产部署（>1亿向量） |
| Qdrant | Rust 实现，高性能，支持过滤 | 中大型项目，对性能要求高 |
| Weaviate | GraphQL API，支持多模态 | 需要复杂查询和图关系的场景 |
| Chroma | 轻量级，易于上手 | 开发调试、小规模项目 |
| FAISS | Meta 开源，纯向量检索库 | 嵌入到自研系统中 |
| Elasticsearch | 支持混合检索（BM25 + 向量） | 已有 ES 基础设施，混合检索场景 |
| pgvector | PostgreSQL 插件 | 已用 PostgreSQL，轻量接入 |
选型原则：
- 小型项目 / 快速验证：Chroma 或 pgvector
- 生产环境大规模：Milvus 或 Qdrant
- 需要混合检索：Elasticsearch（8.x 已支持 HNSW）
五、AI Agent 核心概念
Q15：什么是 AI Agent？与普通 LLM 应用的区别？
答：
AI Agent（智能体） 是能够自主规划、调用工具、执行多步任务的 AI 系统。
核心组成（四要素）：
感知（Perception）→ 规划（Planning）→ 行动（Action）→ 记忆（Memory）
| 组件 | 职责 |
|---|---|
| LLM 核心 | 理解用户意图、制定计划、推理决策 |
| 工具集（Tools） | 搜索引擎、代码执行、数据库查询、API 调用 |
| 记忆系统（Memory） | 短期（对话历史）+ 长期（向量存储）记忆 |
| 规划器（Planner） | 任务拆解、多步执行、错误恢复 |
与普通 LLM 的区别：
| 对比项 | 普通 LLM | AI Agent |
|---|---|---|
| 执行步骤 | 单轮问答 | 多步迭代执行 |
| 工具使用 | 无 | 可调用外部工具 |
| 自主性 | 被动响应 | 主动规划执行 |
| 状态维护 | 无（或简单） | 有上下文状态管理 |
Q16：Agent 中的幻觉问题如何解决？
答：
幻觉产生的原因：LLM 训练数据偏差、知识截止、过度拟合训练分布。
解决方案：
- RAG 接地气：让 Agent 检索真实文档后再回答，有据可查
- 工具验证：提供计算器、搜索引擎等工具，让模型去验证而不是猜测
- Chain-of-Thought（CoT）：强制分步推理，减少跳跃式幻觉
- Prompt 约束：明确指示"如果不确定请说不知道，不要猜测"
- 输出结构化：强制 JSON Schema 输出，减少自由发挥空间
- RLHF/DPO 对齐：通过人类反馈强化"拒绝回答"的正确行为
- 事实验证工具：集成知识图谱或权威数据库做事实核查
六、Agent 工具调用与协议
Q17：什么是 Function Calling？工作流程是什么？
答：
Function Calling（函数调用）是 LLM 与外部工具交互的标准机制，允许模型在对话中触发预定义函数。
工作流程：
1. 开发者定义工具（JSON Schema描述工具名、参数、功能）
2. 将工具定义 + 用户问题一起发给 LLM
3. LLM 决策：需要调用工具时，返回结构化 JSON（包含工具名和参数）
4. 客户端解析 JSON，调用实际函数/API
5. 将函数返回结果发回 LLM
6. LLM 基于结果生成最终自然语言答案
示例：
// 用户问："上海明天天气怎么样？"
// LLM 返回 Function Call：
{
"name": "get_weather",
"arguments": {
"city": "上海",
"date": "tomorrow"
}
}
Q18：MCP 是什么？与 Function Calling 有何区别？
答：
MCP（Model Context Protocol，模型上下文协议） 是 Anthropic 推出的 AI 工具集成标准协议，类比于"AI 世界的 USB 接口"——实现 AI 与外部数据源/工具的标准化连接。
MCP vs Function Calling 对比：
| 维度 | Function Calling | MCP |
|---|---|---|
| 标准化程度 | 各厂商各自定义，不统一 | 统一协议标准，跨模型通用 |
| 工具注册方式 | 每次请求携带定义 | Server 独立运行，Client 连接 |
| 状态维护 | 无状态 | Server 可维护状态 |
| 适用范围 | 单次工具调用 | 复杂持久化工具集成 |
| 生态 | OpenAI/Anthropic 等各自实现 | 开放标准，已有大量 Server |
MCP 核心架构：
- MCP Client：AI 应用（如 Claude Desktop）
- MCP Server：工具服务（文件系统、数据库、搜索引擎等）
- 通信方式：stdio（本地）或 SSE/HTTP（远程）
Q19：A2A（Agent to Agent）协议是什么？与 MCP 的区别？
答：
A2A（Agent-to-Agent） 是 Google 提出的多 Agent 通信协议，专注于异构 Agent 之间的协作。
| 维度 | MCP | A2A |
|---|---|---|
| 通信对象 | AI ↔ 工具/数据源 | Agent ↔ Agent |
| 场景 | 单个 Agent 调用外部工具 | 多 Agent 任务分发与协作 |
| 设计目标 | 工具接入标准化 | Agent 能力发现与委托 |
| 互补关系 | 底层工具集成 | 上层 Agent 编排 |
简单理解：
- MCP：Agent 如何使用工具（锤子、扳手）
- A2A：多个 Agent 如何分工协作（工头 → 工人）
七、Agent 规划与推理
Q20：什么是 ReAct 框架？为什么它是 Agent 的主流范式？
答：
ReAct（Reasoning + Acting） 是一种将推理和行动交替进行的 Agent 执行框架。
执行循环：
观察（Observation）→ 思考（Thought）→ 行动（Action）→ 观察（Observation）→ ...
示例（查询"2024年诺贝尔物理学奖获得者"）：
Thought: 我需要搜索最新信息
Action: search("2024 Nobel Prize Physics")
Observation: 搜索结果返回 "Geoffrey Hinton 和 John Hopfield..."
Thought: 已获得答案，可以回复用户
Action: Final Answer("2024年诺贝尔物理学奖颁给了...")
优势：
- 推理过程透明可审计
- 工具调用有依据，减少随机性
- 适合多步复杂任务
- 支持错误恢复（观察到错误后重新规划）
局限：
- Token 消耗大（每步都要推理）
- 长链路容易循环或卡死
- 对基础模型推理能力要求高
Q21：Agent 如何进行任务规划（Planning）？主流方案有哪些？
答：
任务规划是 Agent 将复杂目标分解为可执行步骤的能力。
主流规划方案：
| 方案 | 原理 | 特点 |
|---|---|---|
| Chain-of-Thought（CoT） | 逐步推理链，Prompt 引导思考过程 | 简单有效，适合中等复杂度 |
| Tree-of-Thoughts（ToT） | 探索多条推理路径，树状搜索 | 适合需要回溯的复杂问题 |
| ReAct | 推理+行动交替执行 | 工具调用场景标准范式 |
| Plan-and-Execute | 先生成完整计划，再逐步执行 | 适合结构化任务，计划可审查 |
| Reflexion | 自我反思机制，执行后评估并改进 | 自动纠错，多轮迭代提升质量 |
实践建议：
- 简单查询任务 → ReAct
- 需要审查和修改的任务 → Plan-and-Execute
- 需要高质量输出的创作 → Reflexion
Q22：如何解决 Agent 的"无限循环"和"早期停止"问题？
答：
无限循环原因： Agent 陷入反复调用同一工具却无法收敛的状态。
解决方案：
- 最大步骤限制：设置
max_iterations=10，超出则强制返回当前最优答案 - 重复检测：检测到相同 Action 序列时提前终止
- 思考链压缩：超过一定轮次后摘要压缩历史 Thought
- 工具调用去重：相同参数的工具调用结果缓存，避免重复执行
早期停止原因： Agent 在任务未完成时就认为已完成。
解决方案：
- 明确的完成标准 Prompt：在系统提示中定义"任务完成"的判断条件
- 人机确认节点：关键步骤加入人工确认（Human-in-the-loop）
- 验证工具：让 Agent 在回答前调用验证工具检查结果完整性
八、多 Agent 协作
Q23：多 Agent 系统有哪些常见架构模式？
答：
| 架构模式 | 描述 | 适用场景 |
|---|---|---|
| 主从架构（Orchestrator-Subagent） | 一个主 Agent 协调多个专业子 Agent | 复杂任务分工，如代码生成+测试+部署 |
| 管道架构（Pipeline） | Agent 串行处理，上一个输出是下一个输入 | 数据处理流水线 |
| 投票架构（Voting/Debate） | 多个 Agent 独立给出答案，最终投票 | 提高输出质量，减少单点幻觉 |
| 平行架构（Parallel） | 多 Agent 并行执行不同任务，最终汇总 | 速度优先场景 |
| 群体架构（Swarm） | Agent 去中心化自组织协作 | 复杂开放式任务 |
热门框架对应：
- LangGraph → 主从 / 状态机架构
- AutoGen → 对话式多 Agent 协作
- CrewAI → 角色扮演多 Agent 分工
Q24：多 Agent 系统如何保证任务不重复、不遗漏？
答：
关键设计：
- 任务分配协议（Task Queue）：使用消息队列（如 Redis / Celery）统一管理任务，每个任务有唯一 ID
- 状态跟踪：共享状态存储（如 Redis / 数据库）记录每个任务的执行状态（pending/running/done）
- 幂等性设计：工具调用和 Agent 操作保证幂等，重试不会产生副作用
- 主 Agent 监控：Orchestrator 定期检查子 Agent 状态，发现超时则重新分配
- 结果汇总层：在所有子 Agent 完成后，由汇总 Agent 统一整合输出
九、Agent 记忆机制
Q25：AI Agent 的记忆分类及实现方式？
答：
Agent 记忆分为四类：
| 记忆类型 | 描述 | 实现方式 | 时效性 |
|---|---|---|---|
| Sensory Memory（感觉记忆） | 当前输入的原始内容 | 当前 Prompt 中的输入文本 | 即时 |
| Short-Term Memory（工作记忆） | 当前对话上下文历史 | LLM 上下文窗口（Messages List） | 本次会话 |
| Long-Term Memory（长期记忆） | 跨会话的持久化知识 | 向量数据库（存储对话摘要） | 持久 |
| Episodic Memory（情节记忆） | 特定事件的经过记录 | 结构化日志 / 向量存储 | 持久 |
工程实现：
# 短期记忆：直接维护 messages 列表
messages = [
{"role": "user", "content": "..."},
{"role": "assistant", "content": "..."},
]
# 长期记忆：对话摘要存入向量数据库
summary = llm.summarize(conversation)
vector_store.add(summary, metadata={"user_id": "xxx"})
# 检索时：先从向量库召回相关历史
relevant_memories = vector_store.search(current_query, top_k=3)
Q26：如何解决 Agent 上下文窗口过长的问题？
答：
| 方案 | 原理 | 适用场景 |
|---|---|---|
| 对话摘要压缩 | 定期将早期对话摘要为简短文本 | 长对话场景 |
| 滑动窗口 | 只保留最近 N 轮对话 | 对历史上下文依赖不强的场景 |
| 关键信息提取 | 只保留实体、事实、用户偏好 | 任务型对话 |
| 向量化记忆检索 | 将历史存入向量库，按需检索 | 需要精确历史回忆 |
| 层次化摘要 | 多轮摘要，逐层压缩 | 超长期对话 |
实践推荐：
- 短期：滑动窗口 + 关键信息提取
- 长期：向量数据库存储对话摘要，检索增强
