周末做的一套 AI Agent / RAG 面试题自测，共 19 题，记录我的回答和修正。

AI Agent（题目 Summary）

Q1：MinerU 解析出来是 Markdown，相比纯文本，层级结构对检索有啥好处？

  • MinerU 是文档解析工具。
  • 层级检索存在标题，相较于纯文本，标题更能涵盖文本的大致含义。

Q2：你流程里的 VLM，是在检索阶段就参与，还是只在最后生成答案时才参与？

VLM（视觉语言模型）的处理流程：

图片
 |
Vision Encoder
 |
Image Embedding
 |
Projector
 |
Visual Tokens
 |
LLM
 |
最终文本输出
  • 检索阶段：输入图片和文字，VLM 对图片进行 Embedding 嵌入 -> 得到 VectorDB；对向量数据库进行整合，找出相似度最高的 Png，VLM 对 Png 进行分析。
  • 生成答案阶段：在知识库中存在图片，搜索到 Chunk -> VLM 解析。

VLM 在检索阶段和生成阶段有什么区别？

区别在于检索对象不同。检索阶段参与时，图片本身会建立 Embedding 索引，Retriever 可以直接检索图片；生成阶段参与时，Retriever 检索的是文本 Chunk，只是在召回的 Chunk 中如果引用了图片，再调用 VLM 对图片进行理解。前者属于多模态检索（Multimodal Retrieval），后者属于多模态生成（Multimodal Generation），企业知识库更常见的是后者，因为实现简单、成本更低。

  • Embedding：回答的是"像不像？"，用于相似度检索。
  • VLM 理解：回答的是"图片里是什么？"，用于生成答案。

Q3：Ragas 评测里 Faithfulness（忠诚度）得分低，说明模型出了什么问题？

Ragas（RAG assessment）是 RAG 测评框架，Faithfulness 衡量模型生成的答案是否忠实于检索到的上下文，有没有编造或扩展事实。

我的思考：

  • 得分低，说明模型没有认真检索上下文，自由度太高了，侧面说明 Temperature 太高。
  • 出现了幻觉、无依据推测或者额外补充信息。
  • 为什么不能 Summary 一下 retriever？（待深究）

GPT 优化建议：

  • 提高 Retriever 的召回质量（确保相关内容被检索到）。召回器：从知识库中尽可能找出与用户问题相关的内容。
  • 使用 Reranker，对召回结果重新排序，减少无关内容（将召回器找出的结果进行最优排序）。
  • 优化 Prompt，明确要求模型仅依据 Context 回答。
  • 适当降低 Temperature，减少自由发挥。
  • 提供更完整、更高质量的上下文。

Q4：LangGraph 里 Node 和 Edge 各代表业务流中的什么？

Node 是"谁来干活"，Edge 是"下一步该谁干活，以及为什么去找他"。

Q5：长短期记忆在实现上差在哪？短期记忆通常存在哪？

（待补答案）

Q6：Agent 怎么识别该用哪个工具？靠名称还是靠功能描述？

  • Tools description，也就是功能描述。
  • 同时会参考工具名称、参数定义和用户当前上下文。
  • LLM 会判断哪个工具最适合完成当前任务，然后生成对应的工具调用。

Q7：向量检索和关键词检索，各有什么优缺点？

向量检索：先用 embedding model 将文本、图片转换成向量，再根据向量之间的相似度进行检索。

  • 优点：
    • 支持同义词、近义词、不同方式表达
    • 对自然语言提问效果好
    • 支持多模态（图片、文本）
  • 缺点：
    • 需要提前 embedding，计算成本较高
    • 建设和维护向量数据库需要资源
    • 检索结果可解释性较弱，不容易说明为什么命中
    • 对专业术语、编号等精确匹配不如关键词检索

关键词检索：基于倒排索引（Inverted Index），按照关键词进行匹配，典型算法如 BM25。

  • 优点：
    • 检索速度快
    • 对编号、产品型号、函数名、错误码等精确匹配效果很好
    • 不需要 Embedding，部署简单
    • 结果可解释性强
  • 缺点：
    • 不理解近义词
    • 同义词、近义词易漏召回
    • 用户表达与文档表达不同时，可能检索不到

混合检索：一般企业使用的时候，采用的是混合检索。

  • 关键词检索（BM25）：保证精确匹配，如产品型号、错误码、函数名。
  • 向量检索（Embedding）：补充语义召回，覆盖同义表达。
  • 融合排序（Rerank）：综合两种检索结果，选出最相关的内容，再交给 LLM 生成答案。

Q8：为什么 RAG 比直接问大模型更能减少事实性错误？

  • RAG（Retrieval-Augmented Generation，检索增强生成）会先从可信知识库中检索相关内容，再基于这些内容生成答案，而不是直接依赖模型参数中的知识。
  • RAG 会首先检索公司知识库，根据文档回答问题。
  • LLM 的知识库通常截止于训练时的数据。
  • RAG 通过先检索可信知识，再基于检索结果生成答案，为 LLM 提供事实证据，减少了依赖参数记忆进行推测，降低幻觉，提高答案的准确性和时效性。

Q9：原始文档改了，向量库里的索引怎么保证同步更新？

  • 我的回答：根据文档标题和文档内容进行重新 Embedding，检索的时候增强检索到的可能性。
  • 正确回答：文档更改后，需要重新切分发生变化的内容并且重新生成 Embedding，然后同步更新向量知识库中的索引，保证检索的数据来自最新版本。

Q10：Query Rewrite 是个啥？能解决用户提问中的什么问题？

  • 在用户提问时，用户不会准确地描述出自己的问题，需要对问题进行一轮标准改写，使其更能准确打中数据库中内容。
  • 在检索前优化用户问题，使其更加完整、规范、易于检索，从而提高知识召回率和最终回答的准确性。

Q11：Temperature 调高和调低，模型输出会有什么变化？

  • Temperature 用于控制模型输出的随机性。值越低，回答越稳定、越准确；值越高，回答越多样、更有创造力。RAG 场景通常会将 Temperature 设置得较低，以减少模型脱离检索内容进行自由发挥。
  • Temperature 主要影响生成阶段（LLM 输出），不会影响向量检索、Embedding、BM25、Rerank 等 RAG 检索流程。它是在检索完成之后，LLM 根据召回内容生成最终答案时发挥作用的参数。这样也解释了为什么它常和 RAG 一起讨论，但本质上属于 LLM 的生成参数。

Q12：CoT 的原理讲讲？为什么它能让模型搞定复杂任务？

  • Chain of Thought（思维链）。
  • 引导模型先生成中间的推理过程，再得到最终答案。把复杂问题拆分为多个简单步骤。

Q13：Agent 执行任务时，Thought、Action、Observation 是怎么循环的？

我的回答：思考 / 调用工具 / 工具返回。Agent 首先进行思考，思考后开始行动调用工具，结果返回后 Agent 思考调用是否合适。

标准回答：Thought -> Action -> Observation

  • Thought：模型分析当前任务，决定下一步应该做什么、是否需要调用工具。
  • Action：模型生成 Tool Calling 请求，调用相应工具。
  • Observation：工具执行后返回结果，Agent 将结果作为新的上下文。
  • 整个过程会重新进入 Thought，根据 Observation 判断是否已经完成任务，还是继续调用其他工具。

Q14：对话长度超过模型上下文窗口了，怎么处理？

  • Conversation Summary：对话总结后，只保留（Summary + 最近几轮对话 + 当前问题）。
  • 滑动窗口：保留最近的几轮对话。
  • 长期记忆：保留重要信息。
  • RAG 检索历史：将历史聊天存入向量知识库，新问题来了先检索历史聊天。切 Chunk -> Embedding -> Retriever -> 取 Chunk。
  • CLAUDE.md 类似长期上下文/项目记忆，手动更新，创作者监管。

Q15：模型做工具调用（Tool calling）时，输出的直接是结果，还是一串带参数的 JSON？

  • 一串带参数的 JSON。
  • 模型输出的不是工具执行结果，而是工具调用请求，外部程序执行工具后，再把结果返回给模型，由模型生成最终回答。
问：北京天气怎么样？
程序：收到一串 json 指令 tools: get_weather; city: beijing
执行后返回："temperature": 28, "weather": "晴"
模型生成：北京今天晴，28 度

Q16：系统提示词和用户提示词，哪个约束力更强？差在哪？

  • System Prompt 用于定义模型的角色、行为和约束，优先级通常高于 User Prompt。
  • User Prompt 用于描述当前任务，需要在 System Prompt 允许的范围内执行。

Q17：HNSW 是个什么索引？为什么比暴力搜索快？

  • 近似最近邻（ANN）索引，Hierarchical Navigable Small World。
  • HNSW 会提前建立一张多层图：每个向量不仅保存自己的数据，还会记录附近有哪些相似向量。
  • HNSW 是一种基于多层图结构的近似最近邻（ANN）索引算法。相比暴力搜索需要遍历所有向量，HNSW 通过图导航逐步逼近目标，只访问少量候选节点，因此能够在保证较高召回率的同时，大幅提升向量检索速度。

为什么 RAG 基本都用？

因为企业知识库往往有几十万到上千万条向量。暴力搜索虽然精确，但查询延迟较高；HNSW 能在几乎不影响检索质量的前提下，大幅降低查询时间，因此成为很多向量数据库默认或常用的索引方式。

Q18：开发 Agent 时，怎么判断一个任务该用 7B 小模型还是 70B 大模型？

  • 7B 左右：速度快、成本低，适合分类、摘要、信息抽取等简单任务。
  • 70B 左右：推理能力更强，更适合复杂规划、代码生成、多工具 Agent 等场景，但推理成本更高。
  • Answer：看任务的复杂度、成本、延迟和准确率要求。简单任务比如分类、改写、摘要、信息抽取，可以用 7B 的模型或者便宜 API。复杂的任务，比如多步规划、工具选择、代码生成、长链路推理，应该用 70B 或者更强模型。实际工程里通常会做模型路由，用小模型处理高频简单任务，大模型兜底复杂任务，这样能平衡成本和效果。

Q19：Agent 老重复执行同一个错误的工具调用，你从哪个环节修？

  • 找寻系统日志，看这个问题描述，为什么最终采用了这个错误的工具。
  • 反推 Tools Description，看是不是写错了。
  • 标记大模型，让模型知道这个路径是错误的。优化 Prompt 或 Tool Description，引导模型正确选择工具。
  • Summary：我会先查看 Agent Trace 或日志，定位模型为什么选择了错误工具；然后检查 Tool Description、System Prompt 和 Tool 返回结果是否存在问题；最后根据情况优化 Prompt、工具描述或调用策略，并设置合理的重试和退出机制，避免 Agent 重复执行同一个错误的 Tool Calling。