某大厂 AI 产品经理 | 面试录音(整理版) 在真实业务里,几乎不存在“先问全参数再调工具”或“一句话直接跑完工具链”的纯模式。大多数多轮场景,都是一边补信息、一边查结果,用户中途反悔、插话、看完结果又改条件。所以如果把它设计成线性流程,基本到第四、第五轮就会开始飘。 ⭐ S|Situation 我之前做旅行类、日程类多轮Agent时,几乎全是高不确定性流程,比如查完航班,用户突然改出发地;看完结果,又补一句“最好 7 点以后”;原本想订票,中途又改成“先看看方案”。如果按传统线性设计,模型要么乱跑,要么整条链路崩掉。 ⭐ T|Task 你有没有把多轮任务当成“可被打断、可回滚的链式任务”来设计。而不是追问一套、工具一套,全靠模型自由发挥去拼。 ⭐ A|Action 第一步:把工具链顺序“钉死” 我会先把工具链的主顺序固定下来,比如找目的地→查航班→选方案→下单,无论用户怎么跳、怎么插话,模型都不能随意改变这个顺序。这是稳定行为的第一道约束。 第二步:在每个节点定义清晰的追问规则 我会明确哪些参数缺了必须问,哪些缺了可以用默认值先往前走。比如目的地缺了必须追问,预算不是关键参数,可以先查再筛。规则一旦定好,模型就不会在前面无谓卡住用户。 第三步:状态必须可回滚 我踩过一个很典型的坑:航班结果已经给到用户,他突然说「算了,改成上海出发」。如果状态机不支持回滚,模型就会带着旧参数继续往前乱走。后来我加了明确的中断点,每次工具返回后,状态标记为“可回滚”,用户给出方向性修改时,链路回到最近的安全节点,比如回到“收集出发地”,而不是整个流程重置。这样既不乱,也不浪费前面的信息。 第四点:追问和工具调用一定是交错发生的 现实中经常是用户给了70%信息,模型先查一次,用户看完结果再补条件。这时候模型不能当成新任务,也不能强行继续下单,而是要根据当前状态回退一步,再重新跑筛选。这一步,必须靠状态机驱动,而不是靠模型自由发挥。 ⭐ R|Result 所以在我看来,一个能用的混合多轮结构,核心就三件事: 1️⃣ 追问规则要清晰 2️⃣ 工具链顺序要固定 3️⃣ 状态必须支持回滚 #大模型 #面试题 #互联网大厂 #产品经理 #llm
00:00 / 02:44
连播
清屏
智能
倍速
点赞23
腾讯 AI 产品经理 | 面试录音(整理版) ⭐ S|Situation 很多平台在做电视剧互动时,第一反应都是弹幕太少、评论不活跃,于是想办法“把场面搞热闹”。但我在真实项目里发现,互动起不来,往往不是用户没情绪,而是两个更本质的问题:用户不知道该说什么或者觉得说了也没人接话。结果就是人很多,但互动很冷,看完就走。 ⭐ T|Task 电视剧互动的核心,不是让弹幕变多,而是让用户真的有话想说,并且愿意留下来看别人怎么说。也就是把“一个人看剧”,慢慢变成“有人一起追剧”。 ⭐ A|Action 1️⃣ 先帮用户“开个头”,而不是替他说话 AI介入的第一步,我一定不会做得很吵,而是在剧情关键点给非常轻的引导,比如: “你们觉得男主这波是不是在演?” “这段会不会是后面反转的伏笔?” 这不是替用户发言,而是告诉他:这里是可以讨论的。 实际效果是,很多原本只看不说的人,会开始参与,哪怕只回一句“我也觉得怪怪的”,互动就被启动了。 2️⃣ 解决“没看懂、不敢说”的现实门槛 很多人不参与讨论,其实不是没想法,而是没太看懂剧情,又怕说错。 所以我会用 AI 做一些轻剧情补充,比如: 快速回忆人物关系 提示这一段和前面哪一集有关 当用户确认“我理解得差不多了”,评论区就会开始出现有因果、有判断的讨论,而不是纯情绪输出。 3️⃣ 关注互动能不能“持续”,而不是一集一爆 我更关心的是互动能不能延续到后面。 所以AI抛的问题,会围绕: 角色动机 价值选择 后续走向预测 这些问题容易讨论,但不容易吵崩,让用户从“看完就走”,变成“看完想等别人怎么说”。 4️⃣ 控制互动质量,而不是堆热度 一旦评论区变成哈哈哈、骂战或刷屏,反而会劝退真正想讨论的人。 所以AI更多是做筛选和排序: 把有观点、有信息量、能接话的评论放前面 对明显跑偏、情绪对冲的内容做降噪处理 目标不是“管人”,而是把讨论慢慢拉回剧情本身。 ⭐ R|Result 最后我看的不是单集播放,而是: 参与互动的这批用户,是不是更愿意持续追剧,看得更久、看得更多集。 只要这点成立,短期点击波动我是可以接受的。 在内容平台里,真正值钱的从来不是一集的点击,而是用户愿不愿意围绕一部剧留下来。 #产品经理 #ai产品经理 #llm #大模型 #面试
00:00 / 03:26
连播
清屏
智能
倍速
点赞33
这道AI面试题,我后来发现90%的人都会答错 面试AI/大模型/应用岗的时候有一道题我被反复问到:“如果用户的问题在知识库里查不到,你们系统怎么兜底?”一开始我也以为这是个偏技术的问题,后来才发现这题真正考的,是系统能不能真的上线。 这个问题我一般会从三个层面来看:先确认是不是真的“无匹配”,再设计分层的fallback,最后才是Agent的反思或重试机制,而且一定是受控的。 在真实系统里,很多时候不是“完全没有结果”,而是“结果不够好用”。所以我不会只看“知识库里有没有召回结果”,而是会综合看几类信号: 检索相似度是不是整体偏低 有没有覆盖问题里的关键关键词或实体 模型在当前证据条件下,能不能判断自己可以回答 如果这些信号整体都偏低,我才会明确认定为低置信度,这时候不会强行生成答案,避免模型在证据不足的情况下瞎编。 一旦低置信,就进入fallback 第一层:轻量修复 比如:对用户query做一次改写,换一种问法重新检索,适当放宽条件、扩大topK,一般只允许1~2次,再往后命中率提升很有限,成本和延迟会上得很快。 第二层:澄清式fallback 如果轻量修复之后,系统还是判断信息不足,或者发现问题本身缺少关键条件,那就不会硬答。而是主动向用户确认一到两个关键信息,比如具体对象、时间范围、业务背景,让用户帮我们把问题说清楚一点。 第三层:明确拒答/转人工 如果在澄清之后,或者在一些高风险场景下,还是没有可靠依据,那就会明确拒答,或者引导人工处理。这一步的目标不是“尽量回答”,而是让系统行为安全、可控、可预期。 那Agent会不会一直自己反思、一直重试?这一点我在面试里会刻意说得比较保守。我不会让Agent自由反思、无限重试,而是基于失败原因来做受控重试。比如:是没检索到结果,还是相似度太低,还是问题本身太泛。不同原因,对应不同处理动作,避免它在同一个地方来回打转。 重试次数怎么定? 我一般会从两个维度定:成本和用户体验在常见的知识库问答场景下:和检索相关的重试不超过2次,整体决策步骤不超过3步,超过这个点之后,成功率提升已经很小了,但延迟和成本会上去,用户反而会觉得系统在“兜圈子”。 所以整体设计目标其实很简单:在无匹配的时候不瞎编、不死循环,同时给用户一个清楚的反馈,让他知道现在卡在什么地方、下一步能做什么。 #大模型 #llm #算法 #ai #互联网大厂
00:00 / 02:35
连播
清屏
智能
倍速
点赞5
在面试中聊 Agent,这样说反而更安全 最近在面AI产品/AI应用岗的时候,发现一个现象:Agent几乎成了必聊话题。不管是面试官问,还是候选人主动说,大家都会往Agent上靠。但这个问题,其实我自己在工作和面试准备中反复想过很多次。 在实际项目里,我越来越觉得:Agent本身更像一个中枢,而不是能力本身。它主要负责理解你要干嘛、判断下一步该怎么走,但一个系统能不能稳定跑、能不能真的把事情做好,关键还是在背后的执行能力是不是扎实、可控。主要是因为在一些项目里,我看到过这样一种做法:每来一个业务场景,就包一层新的Agent。短期看确实很快,Demo也很好看,但往后走会慢慢暴露出一些问题。 第一个问题:维护成本会上来 不同Agent各自维护Prompt、状态和逻辑,时间一长,系统会变得越来越复杂,出了问题也很难快速定位。 第二个问题:表现不稳定 每个Agent都在“自己决策”,只要底层能力稍微不稳,整体结果就会出现比较大的波动。这种不确定性,在真实业务里其实是很难接受的。 在一些场景下,我反而会更倾向于:Agent数量尽量少,但底层能力尽量做扎实。也就是用一个相对通用的Agent,去编排一套 结构化、可复用的执行能力。Agent负责理解意图和流程编排,能力模块负责事情稳定、可控地执行好。 这样做的好处是:系统复杂度是可控的,能力边界也比较清楚,不同业务之间还能不断复用和积累。 我并不是不看好Agent,只是更倾向于把它当成入口和调度层,而不是把所有复杂性都堆到Agent里。你在项目或面试中接触到的Agent,更多是帮你简化问题,还是引入了新的复杂度? #LLM #AI产品经理 # #面试问题 #大模型 #互联网大厂
00:00 / 02:36
连播
清屏
智能
倍速
点赞51