AI 应用面试百题精讲（中）：RAG

每题结构：答（面试可说的口径）+ Review（纠偏、补强、追问点）。Review 里的坑往往比标准话术更值得先记。

系列导航

五、RAG 与知识增强

Q45. 什么是 RAG？它适合解决什么问题？

答： RAG 就是 Retrieval-Augmented Generation，先检索外部知识，再让模型基于检索结果生成答案。它特别适合企业知识库问答、文档助手、客服知识支持这类知识更新快、需要引用来源、又不适合频繁微调模型的场景。

Review： 说完适合场景后，补局限：检索错则生成跟着错；库外问题与被曲解的引用仍可能幻觉。

Q46. 一个完整的 RAG 流程一般包含哪些步骤？

答：通常是文档采集、清洗、切分、向量化、建索引，然后在线阶段做查询理解、检索、重排、上下文拼接、模型生成和结果引用。很多人以为 RAG 只是「向量库加大模型」，其实真正影响效果的是整个链路的每一步质量。

Review： 链路观比「向量库+模型」更站得住。常被追问：卡在清洗、切块、改写还是重排。

Q47. 文档切块为什么重要？切太大或太小分别有什么问题？

答：切块太大，会把很多无关信息一起送进上下文，噪声高、成本高，还会影响召回精度；切块太小，语义上下文可能断裂，模型拿到的片段不完整，回答也容易失真。所以切块本质上是在做「召回精度、语义完整性、上下文成本」三者之间的平衡，通常还要结合标题层级、段落边界和业务场景去设计。

Review： 切块是三要素权衡。实践：按标题/段落切 + overlap；表格与代码常需单独策略。

Q48. Embedding 模型怎么选？

答：我会看几个维度：第一，是否支持目标语言和领域术语；第二，离线评测效果，比如召回率和命中率；第三，向量维度、推理成本和时延；第四，是否方便私有化部署。面试里可以直接说，没有「通用最优」的 embedding，只有适不适合当前数据和场景。

Review： 没有通用最优。一定要在自己的语料上测召回；中文与领域词是常见翻车点。

Q49. 向量数据库在 RAG 里扮演什么角色？

答：它主要承担相似度检索和索引管理，把文本向量存起来，并在查询时快速找出最接近的候选文档。它解决的是「如何高效召回相关片段」，但它本身并不理解业务，也不负责最终答案质量，所以不能把效果问题全甩给向量库。

Review： 别神话向量库。选型看规模、过滤、运维、混合检索；效果问题先查数据与切块。

Q50. TopK 和相似度阈值应该怎么调？

答： TopK 决定一次拿回多少候选，阈值决定相似度低到什么程度就不要了。TopK 太小可能漏召回，太大又会引入噪声；阈值太高容易过严，太低又容易把不相关内容混进来。一般需要结合离线数据集做评测，再看线上反馈做动态调整，不能靠拍脑袋定死。

Review： 用离线集调，别拍脑袋。阈值在不同 embedding 空间不可比；有时「无阈值 + Rerank」更稳。

Q51. 为什么很多 RAG 系统会加 Rerank？

答：因为第一阶段向量召回更像「粗筛」，速度快但不够精。Rerank 会把问题和候选文档更细致地放在一起比较，重新排序，把真正最相关的内容顶上来。尤其在文档很多、表述相似、领域术语密集的时候，Rerank 往往能明显提升最终答案质量。

Review： 粗排+精排标准架构。说清代价：只对 TopK 重排；术语密集语料收益最大。

Q52. 什么是混合检索？什么时候比纯向量检索更好？

答：混合检索通常是把关键词检索和向量检索结合起来。因为纯向量检索更擅长语义相似，但对精确名词、编号、报错码、文件名这类词可能不够敏感；关键词检索在这些场景下反而更稳。所以如果业务里有很多精确术语、产品型号、接口名、法规编号，混合检索通常比纯向量检索更靠谱。

Review： 错误码/型号/法规编号——举例就加分。实现常见：向量 + BM25/关键词，再融合分数。

Q53. 什么是 Query Rewrite 或 Multi-Query？

答：就是在正式检索前，先把用户原问题改写得更适合检索，或者扩展成多个表达方式再一起检索。因为用户提问有时很口语、很模糊，而知识库里的表达可能很正式。做 Query Rewrite 的目的不是改变用户意图，而是缩短「用户语言」和「文档语言」之间的距离。

Review： 缩短用户语言与文档语言差距。Multi-Query/HyDE 有用但增成本；改写不能扭曲意图。

Q54. Metadata Filter 在 RAG 里有什么作用？

答：它的作用是先按业务条件缩小检索范围，比如只搜某个租户、某个部门、某个时间段、某个文档类型。这样做一方面能提高检索精度，另一方面也能帮助做权限控制。很多企业级 RAG 项目里，过滤条件和权限体系往往比向量相似度本身还重要。

Review： 企业 RAG 里权限过滤常比相似度更重要。多租户场景答不出 metadata，基本不合格。

Q55. 为什么 RAG 结果最好带引用来源？

答：因为带来源可以提升可信度，也方便用户追溯原文、人工核对和事后审计。尤其是企业知识问答、法务、医疗、金融这类场景，没有引用就很难判断模型到底是在复述文档还是在自由发挥。引用来源本质上是在给答案增加可验证性。

Review： 可验证性 > 口头可信。高风险领域无引用很难过审；引用还要能对齐到具体 chunk。

Q56. RAG 项目里最常见的效果问题有哪些？

答：常见问题包括切块不合理、文档清洗质量差、Embedding 不匹配、检索噪声高、重排缺失、上下文拼接过长、提示词没有明确要求基于资料回答、以及知识库更新不及时。很多团队刚开始做 RAG 时会误以为「模型回答不好」，但真正问题常常出在检索链路前面。

Review： 排查序应对：先查检索再怀疑模型。另：prompt 未强制「仅基于资料」也很常见。

Q57. RAG 应该怎么评测？

答：我会把评测拆成两层。第一层是检索评测，比如命中率、召回率、MRR、NDCG，看有没有把相关文档找回来；第二层是生成评测，比如答案准确性、忠实性、完整性、引用是否对应原文。因为如果只看最终答案好不好，很难定位问题到底出在召回、重排还是生成。

Review： 检索指标与生成忠实度分层——专业。端到端只看分数会掩盖坏召回。

Q58. 知识库内容经常更新时， RAG 系统怎么保证新鲜度？

答：通常需要建立增量更新机制，而不是每次全量重建。比如文档变更后触发重新切分、重新向量化、局部更新索引；对于高频变动的数据，甚至会把向量检索和数据库实时查询结合起来。我的理解是，RAG 的核心优势之一就是知识更新不需要重新训练，所以更新链路一定要设计好。

Review： 增量索引是 RAG 的产品优势所在。热数据可「向量召回 + 实时 DB」混合。

六、智能体基础与架构设计

Q59. 什么是智能体（Agent）？它和普通问答机器人有什么区别？

答：智能体可以理解为「带有目标、状态、工具和行动能力的大模型应用」。普通问答机器人通常是一问一答，最多做一点上下文拼接；而智能体除了回答，还会规划步骤、调用工具、读写记忆、根据环境反馈调整行为，甚至可以持续执行一个任务直到完成。

Review： 目标+工具+状态循环 vs 单轮问答。避免把任何 LLM 包装都叫 Agent。

Q60. Agent 和 Workflow 的区别是什么？

答： Workflow 更像预先设计好的固定流程，步骤、分支和顺序相对确定，可控性强、可预测性高。Agent 更强调动态决策，它会根据中间结果决定下一步做什么，灵活性更强，但不确定性也更高。我的经验是，规则稳定的场景优先 Workflow，开放任务或复杂决策场景才考虑 Agent。

Review： 规则稳用 Workflow——这是工程判断力。Agent 灵活但更贵、更难测、更难审计。

Q61. 一个典型 Agent 一般由哪些组件组成？

答：通常至少有这几部分：目标与指令、模型本体、会话状态、记忆模块、工具集、规划策略、执行循环和结果校验。再往生产级做，还会补权限系统、审计日志、成本控制、失败恢复和人工接管机制。也就是说，Agent 不是一个单独模型，而是一套围绕模型构建的行动系统。

Review： 生产组件：权限、审计、成本、人审。Agent = 行动系统，不是单模型。

Q62. Agent 里的 Planning 常见有哪些模式？

答：比较常见的是一步一判断的短规划模式、先列计划再执行的长规划模式，以及计划执行过程中动态修正的混合模式。短规划灵活，但容易反复试探；长规划可解释性更强，但一旦前提错了，后面可能全偏。真实项目里常见做法是先给一个粗计划，再允许根据执行反馈局部调整。

Review： 短规划 vs 长规划权衡对。混合：粗计划 + 反馈修正，最常见也最好讲。

Q63. 什么是 ReAct 思路？为什么它很常见？

答： ReAct 可以概括成「先推理，再行动，再观察结果，再继续推理」。它常见是因为这个模式很符合智能体和外部世界交互的过程：模型先判断下一步需要什么，再去调用工具，拿到结果后继续往前走。它的优势是透明、可迭代，但缺点是链路变长以后，时延和成本也会增加。

Review： ReAct 好讲也好贵。输出格式不稳会导致解析失败，要有容错与步数上限。

Q64. Agent 为什么要用工具，而不是所有事情都让模型直接回答？

答：因为模型擅长生成和归纳，不擅长直接获得实时事实、精确计算、数据库写操作和外部系统动作。如果把所有事情都交给模型「猜」，准确率和安全性都会出问题。工具的意义就是把那些需要真实世界交互的能力外接出来，让模型做决策，让工具做执行。

Review： 决策归模型、执行归工具。实时性、计算、写操作不该让模型「猜」。

Q65. 函数调用和 MCP 这类协议在 Agent 里是什么关系？

答：函数调用更像模型侧的能力，意思是模型能够按指定 Schema 产出结构化调用意图。MCP 更像系统侧的标准协议，目的是把工具、资源和提示能力用统一方式暴露给模型应用。简单说，函数调用解决「模型怎么表达要调什么」，MCP 解决「外部能力怎么被标准化接入」。

Review： 层次不同：Function Calling 是模型如何表达调用；MCP 是工具如何被标准化接入。近年高频考点。

Q66. Agent 的记忆一般分哪几类？

答：常见可以分成短期记忆和长期记忆。短期记忆主要是当前任务相关的上下文、最近几轮对话和中间结果；长期记忆主要是用户偏好、稳定事实、项目约定和长期经验。有的系统还会再区分工作记忆、情节记忆和语义记忆，但本质上都是在回答一个问题：什么信息该临时保留，什么信息值得跨会话持续保留。

Review： 短期 vs 长期按「是否跨会话值得保留」。长期记忆仍要检索质量，不是存了就灵。

Q67. 单智能体和多智能体分别适合什么场景？

答：单智能体适合大多数中小型任务，架构简单，调试和治理成本低。多智能体更适合任务天然可分工，比如一个负责检索，一个负责编码，一个负责审查，一个负责汇总。它的优势是专业化和并行化，但代价是通信复杂度、上下文同步成本和失控风险都会上升。

Review： 默认单 Agent；多 Agent 易 overkill。能讲通信与失控成本，比堆角色酷。

Q68. Agent Loop 最大的风险是什么？

答：最大的风险不是「回答错一句话」，而是它可能在错误前提下持续做错事，比如反复调用无效工具、不断扩大上下文、重复执行同一动作、或者在高权限环境里做出不该做的操作。所以 Agent Loop 一定要有步数上限、工具权限边界、状态检查和中止条件。

Review： 最大风险是持续做错。步数上限、权限、中止条件是必答安全项。

Q69. 怎么防止智能体陷入无限循环？

答：常见做法是限制最大步数、限制同类工具连续调用次数、检测重复动作、要求每一步都说明目标是否推进、并在关键节点加入停止判定。如果连续几步都没有新信息或者结果没有改善，就应该强制结束或请求人工介入。我的理解是，智能体不是越「自主」越好，而是越「可控」越好。

Review： 可控 > 自主。重复动作检测 + 无进展就停/转人工。

Q70. 怎么判断一个 Agent 的任务拆解能力好不好？

答：我会看三个维度。第一，拆出来的步骤是不是覆盖了任务关键路径；第二，步骤之间是否有依赖顺序和可执行性；第三，执行中遇到失败时能不能重新规划，而不是硬着头皮继续。真正好的任务拆解不是把任务拆得很碎，而是拆得刚好能执行、能验证、能回滚。

Review： 可执行、可验证、可回滚——好标准。拆太碎会增加步数与失败面。

Q71. 什么场景必须加 Human-in-the-Loop？

答：凡是涉及真实外部动作、高权限操作、资金流转、对外发送、合同和法律风险、生产数据改写的场景，我都会加人工确认。因为这类场景的错误成本太高，不能只靠模型概率判断。面试里我通常会说，人审不是为了削弱智能体，而是为了把不可逆风险拦在系统外面。

Review： 不可逆动作必须人审。人审是风险闸门，不是「不够智能」。

Q72. 做智能体项目时，最常见的失败原因是什么？

答：最常见的失败原因不是模型不够强，而是目标定义不清、工具设计太粗糙、状态管理混乱、权限边界缺失、评测闭环不足。还有很多项目一开始就把智能体用在不适合开放决策的场景里，结果复杂度远大于收益。我的经验是，智能体项目成败往往取决于系统设计，而不是一句提示词。

Review： 失败多在系统：目标、工具、状态、权限、评测。场景选错 Agent 也是常见败因。

下一篇见系列导航。若你只想先背高频题，优先：Q6/Q10/Q40/Q45–Q52/Q60/Q65/Q68/Q94/Q100。

下一篇见系列导航。若只想先抓高频：Q6 / Q10 / Q40 / Q45–Q52 / Q60 / Q65 / Q68 / Q94 / Q100。