📖 目录

一、 RAG
1.1 原理与流程
1.2 如何提高RAG准确率
1.3 评估与故障排查类
二、 Agent 高频面试题与深度解析
2.1 核心概念与框架类
2.2 系统设计与工程实践类
2.3 多Agent与高级话题类
三、 面试实战技巧与高频考点总结

一、 RAG

1.1 原理与流程类

Q1: 请简述 RAG 的基本原理和工作流程，并说明其核心价值。

✅ 标准答案 (Star Answer):
RAG (检索增强生成) 通过结合检索与生成来增强LLM的能力。其工作流程分为离线和在线两部分：

• 离线索引：将知识库文档进行分割、向量化，存入向量数据库。
• 在线查询：
  1. 检索：将用户查询向量化，从向量库中召回Top-K相关片段。
  2. 增强：将检索到的片段与原始查询组合成增强提示词。
  3. 生成：将增强后的提示词输入LLM，生成最终答案。

核心价值：

1. 突破知识局限：让LLM能利用训练数据外的实时、专有知识。
2. 减少幻觉：答案基于检索证据，更具事实准确性。
3. 可追溯性：答案可关联到源文档，便于验证。
4. 低成本更新：更新知识库即可，无需重训大模型。

---

Q2: RAG 与传统的微调 (Fine-tuning) 相比，各有何优劣？应如何选择？

✅ 标准答案:

• RAG 优势：
  • 知识更新快：修改知识库即可，分钟级生效。
  • 可解释性强：答案有出处。
  • 成本低：无需大量算力训练。
  • 避免灾难性遗忘：不影响模型原有能力。
• RAG 劣势：
  • 依赖检索质量：检索不到则无法正确回答。
  • 上下文长度限制：检索到的内容受LLM上下文窗口限制。
  • 延迟较高：涉及检索和多次LLM调用。
• 微调优势：
  • 风格/格式固化：能将特定风格、格式内化到模型中。
  • 推理速度快：单次前向传播。
  • 对私有数据模式学习深：适合学习数据中的复杂模式。
• 微调劣势：
  • 知识更新成本高：需要重新训练。
  • 可能导致幻觉或遗忘。
  • 数据需求量大。

选择策略：

• 选RAG：当知识需要频繁更新、要求答案可追溯、或数据涉及大量长尾知识时。
• 选微调：当需要模型学习特定风格（如法律文书格式）、特定推理模式，或任务对延迟极其敏感时。
• 结合使用：常见方案是“RAG为主，微调为辅”，用RAG获取知识，用微调优化模型对特定任务指令的遵循能力。

1.2 如何提高RAG准确率

1. 数据处理优化
   **采用动态切分+重叠窗口：**利用NLP模型根据文本语义进行切分，采用滑动窗口保留10%-20%的内容重叠，保证相邻片段语义连贯
2. Query预处理优化
   语义相似度校验： 利用嵌入模型计算余弦相似度，设定相似度不低于0.8，作为质量过滤
3. 混合检索优化
   采用向量检索+BM25+重排序： 采用 BM25 + 向量检索做混合召回，得到 Top‑10 候选，再用 BGE-Reranker 重排序取 Top‑3。
4. 痛点： 针对重排序模型耗时过高的问题引入“策略路由”简单问题走向量检索，复杂问题走重排

2.3 评估与故障排查类

Q5: 如何评估一个 RAG 系统的效果？有哪些关键指标？

✅ 标准答案:

1. 检索阶段评估：

• 召回率 (Recall@K)：前K个检索结果中包含标准答案的比例。衡量检索的全面性。
• 命中率 (Hit Rate@K)：前K个结果中至少包含一个正确答案的比例。
• 平均倒数排名 (MRR)：正确答案排名的倒数的平均值。衡量检索结果中正确答案的位置好坏。

2. 生成阶段评估：

• 事实一致性/忠实度 (Faithfulness)：生成答案是否严格基于提供的上下文，有无“幻觉”。可通过LLM或规则判断。
• 答案相关性 (Answer Relevance)：答案是否直接、完整地回答了问题。
• 上下文相关性 (Context Relevance)：检索到的上下文是否与问题高度相关，是否包含冗余信息。

3. 端到端评估：

• 人工评估：黄金标准，但成本高。
• 自动化框架：
  • RAGAS：专门评估RAG的框架，提供Faithfulness、Answer Relevance等指标。
  • TruLens：提供基于LLM的评估链，可定制评估维度。
• 实用指标：延迟 (Latency)、吞吐量 (Throughput)、成本 (Cost)。

---

Q6: 如果用户反馈 RAG 系统回答不准确或“胡言乱语”，你的排查思路是什么？

✅ 标准答案:
这是一个典型的开放性排查题，可按以下链路逐层排查：

1. 确认问题复现：获取具体的错误查询和回答。
2. 检查检索阶段（最常见的问题源）：

• 检索结果是否相关？查看系统返回的Top-K个chunk内容。如果不相关：
  • 检查查询向量化是否正常（嵌入模型服务是否正常）。
  • 检查向量数据库索引是否最新、是否包含所需知识。
  • 分析查询是否太短/模糊，考虑引入查询扩展或HyDE。
  • 检查分块策略是否合理，答案是否被切碎。
• 相关文档是否在Top-K中？如果相关但排名靠后，考虑引入重排序 (Re-ranker) 模型。

3. 检查生成阶段：

• 提示词 (Prompt) 是否合理？查看构建的最终Prompt，确保上下文被正确拼接，指令清晰。
• LLM是否“忽略”了上下文？在Prompt中强化指令，如“请严格根据以下上下文回答，如果上下文没有相关信息，请说‘我不知道’”。
• 上下文是否过长或噪声大？考虑上下文压缩或选择更相关的片段。

4. 检查数据源：知识库文档是否准确、完整、最新？
5. 检查评估指标：回顾系统的评估报告，看Faithfulness和Answer Relevance指标是否偏低。

三、 Agent 高频面试题与深度解析

3.1 核心概念与框架类

Q1: 请解释什么是 ReAct 框架，并说明它在 Agent 设计中的重要性。

✅ 标准答案:
ReAct (Reasoning + Acting) 是一个让LLM以循环迭代方式解决复杂任务的框架。其核心循环是：

1. 思考 (Think/Reason)：分析当前状态、任务目标和可用工具，决定下一步行动。
2. 行动 (Act)：执行决策，通常是调用一个工具 (Tool Calling)，并生成格式化的调用请求。
3. 观察 (Observe)：接收工具执行的结果，将其作为新的信息输入。

重要性：

1. 透明性与可调试性：将推理过程（Think）显式化，便于开发者理解Agent的决策逻辑，方便调试。
2. 动态适应性：Agent可以根据上一步行动的结果（Observe）动态调整下一步计划，应对不确定性。
3. 结合外部能力：通过工具调用，突破了LLM在计算、实时信息获取、专业操作等方面的限制。
4. 实现复杂目标：通过多步推理和行动，能够完成单个LLM调用无法解决的复杂、长期任务。

---

Q2: Agent 中的“记忆”(Memory)有哪些类型？各自解决什么问题？

✅ 标准答案:
记忆是Agent拥有“状态”的关键，主要分为：

1. 对话记忆 (Conversation Memory)：

   • 存储内容：当前会话的完整历史（用户消息、Agent回复、工具调用及结果）。
   • 解决问题：实现多轮对话的连贯性，让Agent记住上下文。
   • 实现方式：通常受限于LLM的上下文窗口长度，可采用滑动窗口或摘要压缩。

2. 短期记忆/缓存 (Short-term Memory/Cache)：

   • 存储内容：当前任务执行过程中的中间状态、工具调用结果、临时变量。
   • 解决问题：支持ReAct循环，为下一步推理提供即时上下文。

3. 长期记忆 (Long-term Memory)：

   • 存储内容：跨会话的、需要持久化的信息（如用户偏好、历史交互关键点）。
   • 解决问题：实现个性化体验和跨会话的知识持续积累。
   • 实现方式：常借助向量数据库实现，将信息向量化存储，需要时检索。

4. 实体记忆 (Entity Memory)：

   • 存储内容：关于特定实体（如用户、产品、地点）的详细信息。
   • 解决问题：快速存取和更新实体属性，实现更精准的交互。

3.2 系统设计与工程实践类

Q3: 在设计 Agent 时，如何确保其工具调用的可靠性和安全性？

可靠性方面：

1. 清晰的工具定义：为每个工具提供精确的名称、详细的描述和严格的参数JSON Schema，减少LLM误解。
2. 输入验证与清洗：在执行工具前，对LLM生成的参数进行类型检查、范围校验、格式验证，并过滤潜在的恶意输入（如SQL注入、命令注入）。
3. 完备的异常处理：工具执行可能失败（网络超时、API错误、资源不足）。必须捕获异常，并将清晰的错误信息反馈给Agent，使其能调整策略或重试。
4. 设置超时与重试：为工具调用设置合理的超时时间，并实现带退避策略的重试机制。
5. 结果验证：对工具返回的结果进行合理性检查（如格式、范围），避免将错误结果传递给后续步骤。

安全性方面：
6. 权限最小化原则：为Agent分配完成任务所需的最小权限集。对工具进行分级，高风险工具（如文件删除、数据库写操作）需要更严格的管控。
7. 操作确认机制：对于高风险操作，可以设计“二次确认”流程，例如让Ag

面试项目

这个智能健康档案问答系统是我独立完成的全栈项目，核心是用 RAG 架构解决大模型在医疗场景下的幻觉和不可追溯问题。技术上我做了四个关键设计：一是基于 LangChain 链式编排的全流程自动化 RAG 链路；二是可插拔的多模型适配层，支持四种模型灵活切换并内建了降级重试；三是引入 BGE-Reranker 交叉编码器做重排序，让问答准确率提升了约 20%；四是设计了动态熔断降级机制保证服务高可用，以及精细化的文档分块和元数据过滤来提升检索质量。这个项目从前端 Gradio 界面到后端 FastAPI，再到 ChromaDB 向量库和容器化部署，都是我一个人完成的闭环交付。

面试题

1. 这个项目的 RAG 整体流程是怎样的？

整个 RAG 链路分离线建库和在线问答两条线。离线阶段，我把健康档案文档加载进来，按照语义边界做智能分块，每个分块带上元数据，然后用 BGE 嵌入模型向量化存入 ChromaDB。在线问答时，用户提问先做同样的向量化，在 ChromaDB 中检索出 Top-K 个候选片段；接着用 BGE-Reranker 交叉编码器对候选片段做精细相关性打分，重排序后取 Top-3 最相关片段；最后把这 3 个片段作为上下文，连同用户问题组装成 Prompt，送给大模型生成带引用来源的回答。整个链路由 LangChain 编排，实现了加载、分块、向量化、检索、重排、生成的自动化串联。

2. 为什么选择 ChromaDB 而不是 FAISS 或其他向量数据库？

ChromaDB 和 FAISS 我都评估过。FAISS 是 Meta 的向量检索库，性能很强，但它更像一个算法库而不是数据库，需要自己管理持久化和元数据。ChromaDB 是专门为 LLM 应用设计的向量数据库，自带持久化、元数据过滤和简单的 API，和 LangChain 集成非常丝滑。我的项目数据量没有到亿级别，ChromaDB 的性能完全够用，反而它的元数据过滤能力对我做“先过滤再检索”的策略帮助很大，开发效率更高。如果未来数据量暴增，可以平滑迁移到 Milvus 或 Qdrant，但当下 ChromaDB 是性价比最高的选择。

3. BGE-Reranker 为什么能提升 20% 的准确率？它的原理是什么？

向量检索用的是双塔模型，问题和文档分别编码成向量，再算余弦相似度。这种方式速度快，但问题是问题和文档在编码阶段没有交互，对细微语义差异不够敏感。BGE-Reranker 是交叉编码器，它把问题和候选片段拼成一对，让模型直接判断两者的匹配程度，相当于从“背对背比相似”变成了“面对面打分”。因为有了充分的 token 级交互，它对相关性判断更准。我的做法是初检拿 Top-10 或 Top-20，再用重排器精筛出 Top-3，这样既控制了计算开销（只对少量候选做精细计算），又把真正最相关的片段送进大模型，问答准确率提升了约 20%。

4. 多模型适配层是怎么设计的？切换模型需要改代码吗？

我设计了一套基于工厂模式和统一配置的适配层。核心是一个 Config 类，集中管理所有模型的 API 地址、密钥、参数等配置。各个模型都实现同一个基类接口，封装自己的调用逻辑和异常处理。切换模型时，只需要在配置文件中改一个 model_type 字段，比如从 openai 换成 qwen，系统启动时工厂会自动加载对应的适配器，业务代码完全不感知。我还内建了降级链：如果主模型调用失败或超时，可以自动 fallback 到备选模型，保证服务可用。

5. 动态降级和熔断具体是怎么实现的？

我借鉴了微服务里熔断器的设计模式。系统会持续统计每个模型 API 的调用成功率和响应时间，当失败率超过我设定的阈值（比如 50%）或连续失败次数达标时，熔断器自动打开，后续请求不再真正调用模型，而是直接返回预设的兜底回复，避免让用户长时间等待或看到错误。同时熔断器会设一个冷却时间，时间到了就放几个探测请求去试探模型是否恢复，如果恢复了就关闭熔断恢复正常调用。这个机制保证了即使第三方模型服务不稳定，用户端体验也是连续的、有响应的。

6. 文档分块策略有什么讲究？为什么不能简单按固定字数切？

固定字数切分虽然简单，但很容易把一段完整语义切成两半，比如一个病症描述的前半段在上一块、后半段在下一块，检索时哪个块都看不出完整意思。我采用的是基于文档结构的分块策略，优先按段落、标题等自然边界切分，同时设置一个目标块大小和重叠窗口。重叠窗口的意思是相邻块之间保留一部分重复内容，防止关键信息正好落在边界上被割裂。另外每个分块我都会打上元数据标签，比如疾病分类、检查类型，检索时先按元数据过滤缩小范围，再做向量检索，这样做到了检索更聚焦也更高效。

7. 为什么用 FastAPI 做后端？Gradio 在前端扮演什么角色？

FastAPI 是 Python 生态里性能最好的异步 Web 框架之一，天然支持异步 IO，很适合我的场景——调用大模型和向量数据库都是 IO 密集型操作，用 async 能极大提升吞吐。而且它自动生成 OpenAPI 文档，调试和对接很方便。Gradio 是用来快速搭建前端演示界面的，它和 FastAPI 后端通过 REST API 交互。我选 Gradio 是因为它特别适合 AI 项目的快速原型验证，几行代码就能搭出一个可交互的聊天界面，不需要写前端 JS，让我能把精力集中在后端核心逻辑上。

8. 这个项目有做容器化部署吗？怎么做的？

有，我用 Docker 把整个项目容器化了。FastAPI 服务和 Gradio 界面打成一个镜像，ChromaDB 用官方镜像单独部署，两者通过 Docker Compose 编排，统一管理网络和数据卷持久化。这样做好处很明显：一是环境一致性，开发、测试、生产环境完全一样，没有“我机器上能跑”的问题；二是一键部署，拉镜像启动 Compose 就能跑起来；三是扩展方便，后续如果流量大了，FastAPI 服务可以横向扩容，ChromaDB 也可以单独升级配置。

9. 如果用户问一个不在知识库里的问题，系统怎么处理？

这是一个很重要的边界情况。我的做法是结合检索得分和生成阶段的兜底策略。检索阶段如果 Top-3 片段的相关性得分都低于我设的阈值，说明知识库里没有足够相关的信息。这时系统不会强行让大模型“编造”答案，而是直接返回预设的兜底回复，比如“抱歉，当前知识库中未找到相关信息，建议咨询专业医生”。这样避免了模型幻觉，也符合医疗场景对准确性的高要求。

10. 做这个项目你最大的收获是什么？

最大的收获是把 RAG 从论文概念落地成了一个能跑、能用的系统，理解了每个环节的设计权衡。比如分块不是越细越好，太细了语义碎片化，太粗了检索不准；重排序要用交叉编码器，但必须控制候选数量否则太慢；多模型适配不是简单写个 if-else，而是要用工厂模式解耦；熔断降级看起来是防御性设计，但在真实场景中是服务可用性的关键保障。这些权衡和工程化思考，是我认为这个项目最有价值的地方。