AI PM 面试精华：AI 搜索的引用、深搜与指标怎么答
本期用 AI 搜索和 Deep Research 做主案例，拆解面试中如何回答快速搜索与深度研究分流、引用可信度、延迟管理和评估指标，让你把「设计 AI 搜索产品」讲成一套可落地的产品方案。
面试官问「设计一个 AI 搜索产品」时，别急着讲搜索框、RAG 或 Agent。更稳的开场是先把问题拆成两类：用户要的是几秒内的事实答案，还是愿意等几分钟换一份可核查的研究报告。OpenAI 自己也把 ChatGPT 的 search 和 deep research 分开讲：前者适合查近期事实和单点信息，后者适合多步骤、开放式、需要综合判断的问题；deep research 可能运行 5-30 分钟，并要求输出带清晰引用的报告。1
这道题考的不是「你懂不懂检索」。它更像在问：当答案由模型生成、来源来自网页、延迟和成本都不低时，你怎么把一个看起来聪明的 demo 做成用户敢用的产品。
今日主案例：把 AI 搜索答成一个产品系统
可以这样设定场景：你在做一款面向知识工作者的 AI 搜索产品，用户输入「帮我比较三家竞品的企业版定价和安全能力」。产品不能只返回一段顺滑总结，它至少要回答四个问题：查了哪些来源，哪些结论来自哪些来源，哪些地方不确定，什么时候该让用户继续追问或改成深度研究。
一个可复述的回答骨架是：
- 先分流意图：事实型问题走快速搜索，复杂研究型问题走深度模式。OpenAI Academy 对 search 和 deep research 的区分就是很好的例子：search 更像快速拿到最新信息，deep research 则会规划、搜索、评估来源、改写查询并综合多份材料。1
- 再拆检索过程：Google 介绍 AI Mode 时提到 query fan-out，会把问题拆成多个子主题，同时发起多条相关查询。这个机制对应到产品表达，就是别让用户以为系统只查了一个关键词。2
- 然后设计答案层：把结论、引用、反例和下一步追问分开。Perplexity 帮助中心说，每个答案都会包含指向原始来源的编号引用，方便用户核验和继续阅读。3
- 最后补上失败路径：如果来源不足、来源冲突、或者问题本身需要付费库和内部数据，就别硬编完整答案。产品应该提示「当前公开来源只能支持到这一步」，并建议用户补充文件、限定网站或切换到人工复核。
你可以在面试里把这段话压成 30 秒：
我会把 AI 搜索设计成「快速答案 + 深度研究」两层。快速答案服务明确事实，深度研究服务复杂决策。底层先做意图识别和 query fan-out，再检索、排序、综合答案；前端必须把结论和来源绑在一起，让用户能看到每个关键判断从哪里来。上线时不只看点击率，还要看来源支持率、错误引用率、用户追问率和人工纠错率。
考点 1：引用不是装饰，是信任产品
很多候选人会说「我们给答案加 citation」。这句话太薄。面试官通常会追问：引用怎么放、引用错了怎么办、用户是否真的会点开看？
更好的回答是把引用当成一个产品模块，而不是脚注。Google Search Central 对 AI Overviews 和 AI Mode 的说明里提到，这类功能会展示支持性网页链接，帮助用户快速、可靠地找信息，也帮助用户探索原本可能没发现的内容。4 这给 PM 一个很明确的设计方向：引用要服务核验和继续探索，不是为了让页面显得严谨。
面试里可以这样展开：
| 追问 | 不够好的回答 | 更好的回答 |
|---|---|---|
| 怎么判断引用质量？ | 看来源权威不权威。 | 看这条引用是否真正支撑相邻结论，来源是否可访问，时间是否足够新，多个来源是否互相印证。 |
| 引用放哪里？ | 放在答案末尾。 | 关键事实句旁边放引用，复杂结论下面给「依据」和「不确定点」，让用户不用猜哪句话对应哪个来源。 |
| 指标怎么看？ | 看 citation 点击率。 | 点击率只是一个信号，还要看错误引用率、无来源结论占比、用户纠错率、以及引用后用户是否完成任务。 |
可复述的话术是：
我不会把引用当成页面底部的来源列表，而是当成答案可信度的一部分。每个关键判断都要能回到具体来源；如果来源只支持事实 A，模型却推到结论 B，这就是引用漂移，需要在评测里单独抓出来。
考点 2：深度研究为什么慢，慢在哪里要讲清楚
AI 搜索产品很容易被问到延迟。用户平时习惯搜索秒回，但深度研究不会秒回。OpenAI 的 deep research 说明里写到，它会独立发现、推理并整合网页信息，输出可能需要 5 到 30 分钟；OpenAI 2026 年更新还强调可以实时跟踪进度，并中途用追问或新来源打断细化。5
Google 也把普通 AI Mode 和 Deep Search 分开。Google 称 Deep Search 会把 query fan-out 进一步放大，可以发起数百次搜索，跨不同信息片段推理，并在几分钟内生成完整引用的报告。2
这部分面试不要只说「做 loading」。可以拆成三个产品动作：
- 给用户选择权：默认快速答案，复杂任务提示「可切换深度研究，预计耗时更长」。
- 给过程可见性：展示正在拆问题、查哪些方向、已找到多少类来源，而不是一个空转进度条。
- 给中途纠偏：用户发现方向错了，可以补充约束、排除来源、上传文件或停止任务。
可复述的话术是：
深度研究的慢不是 bug，而是产品承诺变了。快速搜索承诺「马上给你一个可用入口」，深度研究承诺「花更多时间换更完整的证据链」。所以我会把延迟显性化，让用户知道系统正在查什么、还能怎么纠偏，并用任务完成率和中途取消率判断这个等待值不值。
考点 3：评估别只看「答案好不好」
AI PM 面试里，评估往往是分水岭。KORE1 的 AI PM 面试指南把 model evaluation 单独列成核心信号，并指出强候选人要能区分离线评估和线上指标，还要讲清楚模型第一次自信答错时的 fallback。6
放到 AI 搜索题里，可以把指标分成四层：
| 层级 | 该看什么 | 面试里怎么说 |
|---|---|---|
| 检索层 | 召回率、来源覆盖、来源新鲜度、重复来源占比 | 「先保证系统查到了该查的材料，而不是只会总结前几条结果。」 |
| 引用层 | 结论是否被引用支撑、引用是否可访问、引用是否对应正确段落 | 「引用错位比没有引用更危险，因为它会制造假的安全感。」 |
| 答案层 | 事实错误率、遗漏率、结构清晰度、是否标注不确定 | 「不能只用人工主观打分，要准备高频问题集和反例集。」 |
| 产品层 | 任务完成率、追问率、保存/分享率、用户纠错率、深度模式取消率 | 「用户多追问不一定是好事，可能是答案没解决问题。」 |
KORE1 的同一篇指南还提醒，RAG 题里要听候选人是否提到 retrieval metrics，比如 recall@k 和 mean reciprocal rank，并且要配合生成结果的 faithfulness，而不是只说「相关性」。6 对产品经理来说，不一定要推公式，但要知道这些指标各自回答什么问题：有没有找到、排得靠不靠前、生成时有没有忠于材料。
可复述的话术是：
我会把 AI 搜索评估拆成检索、引用、答案和产品四层。检索层看有没有找对材料，引用层看证据有没有绑对句子，答案层看事实和结构，产品层看用户是否真的完成任务。这样能避免一个危险情况：用户觉得答案流畅，指标也显示使用时长上升，但事实质量正在变差。
2 个简评案例，面试时可以顺手引用
OpenAI deep research：适合用来说明「复杂研究任务」和「进度可见」。它强调多步骤研究、来源引用、5-30 分钟运行时间，以及 2026 年更新后的实时进度跟踪和中途细化能力。5 面试里引用它时，重点不要放在「很强」，而要放在「产品怎样管理等待和证据」。
Google AI Mode：适合用来说明「问题拆解」和「多查询并行」。AI Mode 使用 query fan-out，把问题拆成子主题并同时发起多条查询；Google 的站长文档也说 AI Overviews 和 AI Mode 可能跨子主题和数据源发起多条相关搜索。4 面试里可以把它转成产品语言：用户问的是一句话，系统内部要拆成一组可验证的小问题。
当日练习题
面试题：
你负责一个面向企业销售团队的 AI 搜索助手。销售问「这家客户最近有哪些风险信号，适合推哪款产品？」系统需要搜索公开网页、公司内部 CRM 备注和历史邮件。你会怎么设计产品、权限、引用和评估指标？
练习时按这个顺序答：
- 先问清楚使用场景：销售是在会前准备、会中实时查询，还是会后写跟进邮件。
- 再分来源权限：公开网页、CRM、邮件分别需要不同授权；内部材料不能混进可对外复制的答案。
- 设计答案结构：风险信号、推荐产品、依据来源、不可确认信息、下一步建议分开写。
- 设计引用和审计：公开来源给链接，内部来源给可追溯记录；高风险建议必须保留谁查了、查了什么、用了哪些来源。
- 设计指标：销售采纳率、会前准备耗时、错误引用率、客户信息误用率、用户纠错率，以及人工抽检通过率。
最后一句可以这样收：
这类产品的难点不在于「搜得多」，而在于把公开信息和内部信息分清楚，把每个建议绑定到证据，并允许销售在不确定时快速回到人工判断。
Related content
- Sign in to comment.