AI PM 面试精华：幻觉、RAG、评测与 Agent 取舍怎么答 (2026)

如果面试官只给你一道 AI PM 技术题，很可能不是让你解释 RAG、温度或幻觉的定义，而是把它们塞进一个产品事故里：用户说 Gemini「看起来很确定，但答案是错的」，你怎么处理？Exponent 在 2026 版 AI PM 面试指南里把这类题列为真实候选反馈中的高频技术追问，和 token cost、retrieval、latency、hallucination handling 放在一起考察。1

这道题的坑在于，很多人会直接说「加 RAG」「加引用」「做人工审核」。这些手段都对，但如果你没先说清楚问题发生在哪个用户场景、错到什么程度、产品愿意为正确性付出多少延迟和成本，答案就会像在背技术词表。

今日重点案例：用户说 AI「自信但错」，AI PM 怎么复盘

先把题目翻译成产品问题

面试里的原题通常是：「用户反馈 Gemini confident but wrong，你会怎么修？」Exponent 的样例回答把它归类为 hallucination 问题，但它真正考的是系统诊断：训练时就学错了，还是推理时被上下文带偏了；是知识过期，还是回答时没有暴露不确定性。1

你可以这样开头：

我会先把「自信但错」拆成两件事：答案错误，以及错误被包装成确定语气。前者影响任务完成，后者影响信任。排查时我会先看错误集中在哪些场景，比如事实问答、长文总结、工具调用后的解释，还是用户让模型做判断题。

这一段比「我们会降低幻觉率」更像 PM，因为它先定义了用户损失。

决策过程：不要一上来就上 RAG

更稳的回答可以按 5 步走：

圈定高风险场景。 先查错误是否集中在医疗、法律、财务、公司政策、产品价格这类不能乱答的场景。低风险闲聊和高风险决策，不该共用一套阈值。
分清根因。 如果模型不知道最新信息，优先考虑可信检索；如果模型知道但总是过度推断，要改提示词、输出格式或拒答策略；如果工具返回就错了，要先修数据源。
给答案加可检查性。 对需要事实依据的回答，要求引用可追溯来源，并把「我不确定」设计成可接受的产品状态，而不是让模型硬答。
建立 eval，而不是靠感觉。 Lenny’s Newsletter 的 evals 指南把 evals 定义为衡量 AI 系统质量和效果的方法，并区分 human evals、code-based evals、LLM-based evals。2 面试里要说清楚：你会拿什么样本集、用什么判定标准、看上线前后哪几个指标。
灰度上线。 先在低风险流量里验证，再逐步放大；如果错误会导致不可逆动作，比如自动发邮件、自动下单、自动改用户资料，要加入人工确认或撤销机制。

这套回答的核心不是「我知道 RAG」，而是「我知道什么时候该用 RAG，什么时候该先修产品边界」。

参考回答骨架

面试时可以压缩成 90 秒：

我会先定义这类错误的风险等级。比如事实问答里，错一个日期和错一个药物建议不是同一种问题。接着我会抽样看错误来源：知识过期就加可信检索和引用；上下文混乱就改 prompt、截断策略和输出格式；工具返回错就先修数据源。
之后我不会只看用户投诉量，因为投诉很稀疏。我会建一套 eval：准备覆盖高频场景和边界场景的样本，人工标注一部分 ground truth，再用自动评测持续跑回归。核心指标包括事实正确率、引用命中率、拒答准确率、低置信转人工比例、用户重试率。
如果这是高风险功能，我会接受更保守的回答和更高延迟。宁可让产品说「我不能确认」，也不要让它用很确定的语气给错答案。

注意最后一句不是空泛价值观，它落在产品权衡上：正确性、信任、延迟、成本，哪个优先。

简评 1：RAG、微调、提示词，怎么选

这类题常被问成「什么时候用 RAG，什么时候 fine-tune？」Exponent 提到，Perplexity 等公司会直接考这类判断，因为检索是它们产品能力的核心。1

回答不要背表格。你可以按问题类型说：

问题类型	更优先的手段	面试里要说出的理由
模型回答格式不稳定	提示词 / 输出约束	成本低，迭代快，先修可控层
需要最新或私有知识	RAG	让回答基于当前、可信、可追溯的资料
需要稳定的专业风格或特定行为	微调	当提示词和检索解决不了行为一致性，再考虑数据和成本
多步任务频繁出错	工作流拆分 / 工具边界	先把复杂任务拆成可验证步骤，而不是直接「上 Agent」

一句话版本：先用最便宜、最可解释的手段解决问题；只有当问题来自知识缺口、行为缺口或流程缺口时，才升级到 RAG、微调或多步工作流。

简评 2：Eval 不是「上线后看用户骂不骂」

AI PM 面试越来越爱问「怎么定义好坏」。Lenny’s Newsletter 那篇 evals 指南提到，AI 产品团队常见的误区是盯着 prompt 和新模型，却没有掌握评测这个隐藏杠杆。2

回答 eval 题时，至少说出 4 个层次：

任务样本。 从真实用户问题、边界 case、失败日志里建样本集。
成功标准。 先定义什么算好答案，什么算危险答案。
评测方式。 主观任务用人工标注或 LLM-as-judge，确定性任务用代码检查。
上线监控。 看正确率、拒答率、重试率、用户改写率、人工接管率，而不是只看 DAU 或会话数。

如果面试官追问「LLM-as-judge 可靠吗」，不要硬说可靠。更好的说法是：我会先用人工标注的小样本校准 judge，再让它跑大规模回归；关键决策仍保留人工抽检。

简评 3：Agent 题的安全答案，是先证明为什么不用 Agent

Anthropic 在「Building effective agents」里把 workflows 和 agents 分开：workflows 是预定义代码路径里的 LLM 和工具编排，agents 则由 LLM 动态决定流程和工具使用。3 它还明确提醒，agentic systems 往往用更高的延迟和成本换取更好的任务表现，所以要先判断这种交换是否值得。3

这给了 AI PM 一个很实用的面试姿势：当题目说「设计一个 AI 助理」时，不要马上说「做成 Agent」。先问三件事：

任务路径是否固定？固定就用 workflow。
用户是否能接受更慢、更贵？不能就别追求全自动。
错误是否可逆？不可逆就加确认、回滚和人工卡点。

一句好用的回答是：

我不会默认把它做成完全自治的 Agent。先用单次 LLM 调用、RAG 或预定义 workflow 覆盖 80% 高频场景；只有当任务步骤无法提前枚举，而且用户愿意为结果质量接受更高延迟和成本时，才让模型自己规划步骤。

这句话听起来保守，但在面试里很加分。AI PM 的成熟度，往往体现在知道哪些能力不该过早上线。

今天的练习题

拿下面这道题练 5 分钟：

「我们要给企业知识库做一个 AI 问答助手。内测用户说回答速度慢，但答案质量确实比旧版好。你会怎么判断是否上线？」

练习时别急着回答「优化 latency」。先把答案拆成：用户场景、质量指标、延迟阈值、成本约束、可降级方案、灰度策略。能把这 6 件事讲清楚，比背 20 个 AI 名词更像一个真正的软件产品经理。

AI PM 面试精华：幻觉、RAG、评测与 Agent 取舍怎么答