AI PM 面试精华：幻觉、RAG、评测与 Agent 取舍怎么答
本期用「模型自信但答错」这道高频 AI 产品经理面试题做主案例，拆解诊断路径、参考回答和三个延伸考点：RAG 取舍、eval 设计、Agent 使用边界。
如果面试官只给你一道 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 名词更像一个真正的软件产品经理。
References
- 1AI Product Manager Interview Questions (2026 Guide)
tryexponent.com
- 2Beyond vibe checks: A PM’s complete guide to evals
lennysnewsletter.com
- 3Building effective agents
anthropic.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.