考察点
这是商汤科技 AI 产品经理岗业务技术面的第一题,也是 AI 公司面 PM 的经典开场刀。商汤是技术立身的公司(CV 起家,后来做日日新大模型体系),面试官默认你既然是 AI 产品经理,就得起「核心算法是什么」这一问——答不上来,或者只答得出「用了大模型」这种粒度,基本就没下文了。这道题真正考的是三层:你的项目叙事是否真实(编的项目讲不出算法层的细节);你能不能用产品语言讲技术(优缺点要落到体验、成本、迭代方式上,不是背论文);你知不知道技术的边界在哪(这为后面「为什么想做产品」的追问埋伏笔)。追问通常走:为什么不用别的方案、缺点在产品上怎么补、效果怎么衡量。
参考答案
先说清楚「核心算法」到底指哪一层
回答这题的第一个坑是层次不清。一个对话机器人里有好几个算法在干活:意图识别、实体抽取、对话管理、答案生成。面试官问「最核心的」,是问撑起这个产品价值的那个,不是让你报菜名。以我做过的客服场景机器人为例,我的回答是:核心是基于大规模预训练语言模型的语义匹配与生成,具体形态是「检索为主、生成为辅」——用户问题先进向量检索在知识库里找候选答案,命中高置信度的直接返回,低置信度的交给大模型基于检索结果生成,兜底走转人工。把这个混合架构讲清楚,比单独吹一个模型重要,因为真实产品里单一算法撑不起体验,讲得出组合逻辑才说明你碰过真东西。
优点:泛化能力是上一代技术给不了的
这套方案相对上一代(规则+关键词匹配+意图分类器)的优点,我能讲出三个有体感的。一是泛化能力:传统方案里用户换一种说法就识别不了,话术维护是个无底洞,我们之前光「修改订单」一个意图就维护了两百多个相似问;换语义检索之后,同义改写的识别率从六成多跳到九成上下,而且新场景上线不用攒语料,知识库文档灌进去就能用。二是长尾问题的覆盖:客服的真实流量是长尾的,头部问题占量,长尾问题占类,传统方案对没配过的话术只能答非所问,生成式方案至少能基于知识库给出相关回答。三是迭代成本结构变了:以前是加意图、加话术,线性堆人力;现在主要成本在知识库治理和 prompt 调优,一个人能管的知识规模大了好几倍。
缺点:每一条都对应一个产品动作
缺点是这题的加分区,我会讲四条,并且每条都带上产品侧的对冲手段,这才是 PM 视角。一是不确定性输出:同样的问法模型可能给出不同质量的回答,这对客服这种要求口径一致的场景是硬伤——我们的对策是置信度分级,高置信检索结果直出,生成内容过敏感词和事实校验,低置信直接转人工,宁可让机器人显得「笨」一点,也不让它自由发挥。二是幻觉:模型会把知识库里没有的信息编得像真的,对策是强制引用——生成的每条事实性陈述必须挂知识库来源,挂不上的不出。三是延迟和成本:大模型推理比传统方案贵一个量级,对策是前面说的分层,检索能解决的绝不动生成。四是黑盒不可调试:badcase 来了没法像规则时代那样「改一条规则就好」,只能归因到数据、prompt 或模型能力,迭代周期长且效果不保证——这条无解,只能接受,它是所有 AI 产品的宿命,PM 的工作就是把 badcase 处理流程化,让迭代尽可能快。
收尾:如果重做一遍,我会怎么选
最后我会补一个反思段,展示判断力:这套方案在当时是对的,但如果今天重做,有两个地方会变。一是小模型的回归——很多高频标准问题其实一个蒸馏后的小模型或纯检索就够了,不需要大模型,成本能再砍一半;二是「检索为主、生成为辅」的配比会更激进地偏向检索,把生成的使用范围压到最低,因为上线后发现,用户对客服的核心诉求是「快且准」,生成带来的那一点点表达自然度,不值得为它承担幻觉风险。这段话的意思是:我的技术判断是被上线后的真实数据教育过的,不是停在方案设计那天。
可能的追问
- 为什么不用纯大模型端到端生成? 答:客服场景的事实必须锚定企业知识库,纯生成无法保证口径一致和事实正确;而且成本和延迟扛不住全量流量。端到端生成适合开放闲聊,不适合有责任主体的服务场景。
- 这套方案的效果怎么向老板证明? 答:业务侧看机器人独立解决率和转人工率的月度变化,模型侧看抽检口径下的答案准确率;我们当时的叙事是「解决率提升了十几个点,同时客服人力没扩」,成本和体验一起算账才有说服力。
- 传统规则方案是不是就一无是处? 答:不是。高频、确定性、有标准答案的场景(查营业时间、查网点)规则/检索又快又准又便宜;甚至很多安全合规相关的拦截,到今天也必须用规则做。技术的正确用法是按场景分工,不是新的把旧的全盘替换。