考察点
这是美团小美 Agent 产品岗一面的题,表面问「豆包和 DeepSeek 哪个好」,实际在考你有没有真正做过模型选型。面试官想听的答案结构是:先讲场景需要什么能力,再讲候选模型在这些维度上的实测表现,最后才是结论。直接说「因为豆包多模态强」或者「DeepSeek 更便宜」都是不及格的——这说明你只看了榜单没跑过评测。追问一般会往「你的评测集怎么建的」「如果 DeepSeek 补齐了多模态你换不换」「成本怎么算细账」这几个方向走。
参考答案
选型的起点是场景,不是榜单
小美这类 Agent 产品的典型交互是:用户拍一张小票问报销、发一段语音问「这附近有什么适合带娃的店」、截图问「这家店我会员能不能打折」。拆下来对模型的硬性要求是:多模态理解(图片+语音是高频入口,不是锦上添花)、低延迟(对话场景首 token 超过 1.5 秒用户就能感觉到卡)、Function Calling 稳定(Agent 要调美团的商户、订单、优惠等一堆内部接口,调用格式错一次整个任务就断)。这三条是门槛项,过不了门槛,跑分再高也没用。
当时选豆包的实际理由
第一是能力匹配。我们在自建评测集上跑过对比,图片理解类题目(小票识别、菜单识别、截图理解)豆包的准确率明显更好,语音链路的端到端延迟也更可控。DeepSeek 当时的主力模型是纯文本路线,多模态要靠外挂视觉模型拼接,链路长、错误会级联,延迟压不下来。第二是成本结构。C 端 Agent 的调用量是大进大出,豆包背靠火山引擎,token 单价和峰值弹性都好谈,我们估算过按预期 DAU 跑一年,推理成本差出接近一倍。第三是工程配套。Function Calling 的格式遵循率、长上下文下的指令保持、以及出问题能找到人一起排查——这些「软」因素在项目后期比 benchmark 上两三个点的差异重要得多。
但也要把话说全:DeepSeek 不是不好
DeepSeek 的文本推理能力和开源生态是实打实的优势,尤其 R1 出来之后,复杂推理类任务(比如多步的比价计算、行程规划)它反而更强。我们的结论从来不是「豆包全面优于 DeepSeek」,而是「在小美当前的主场景里,豆包的综合分更高」。所以架构上我们刻意做了模型路由层:意图分类之后,多模态和工具调用密集的请求走豆包,纯文本的深度推理请求可以路由到其他模型。这个设计多花了一周工程量,但把「选型」从一次性赌博变成了可以随时调整的运营动作。
给面试官看的选型方法论
我自己做选型固定四步:先从真实流量里捞 500-1000 条有代表性的 case 建评测集,按场景分层(不能全用简单题);然后候选模型离线跑一遍,看分场景准确率和 P95 延迟;再算成本账,按真实调用链路的 token 消耗折算单次请求成本;最后小流量 AB 两周,看业务指标(任务完成率、用户是否继续追问)。模型选型没有终局,评测集和路由层才是长期的资产,模型本身半年就换一代。
可能的追问
- 评测集怎么保证不失真? 答:从线上真实 query 按意图分布分层采样,去掉隐私字段,标注用「双人标注+第三人仲裁」,标注标准先写清「什么算对」——比如商户推荐类,推荐了不存在的店直接判错,这比准确率数字本身更难做。
- 如果 DeepSeek 补齐多模态,你会换吗? 答:先看差距是「追平」还是「反超」。追平不换,迁移有 prompt 调优、评测重建、灰度三笔成本;反超 10 个点以上才值得动,而且先走影子流量验证。
- 成本账具体怎么算? 答:按单次会话的平均 token 消耗(我们当时输入输出合计约 3-4K token)乘以日会话量,再留出大促峰值弹性;别忘了把 Function Calling 带来的多轮上下文膨胀算进去,那部分常常比主回复还费 token。
- 为什么不用美团自研模型? 答:自研模型在内部知识和业务术语上有优势,是长期方向;但冷启动阶段用成熟的外部模型把产品体验先跑通、把评测体系建起来,再逐步替换,比一开始就背自研的坑更稳。
- 豆包自己版本迭代很快,你们怎么跟? 答:固定节奏跟进,每个大版本先在评测集上全量回归再决定切不切,绝不无脑跟新——我们踩过一次坑,新版本通用能力涨了但工具调用的格式遵循率回退,线上 Agent 失败率直接抬头,从那以后「先回归后切换」就成了铁律。小版本(官方声称只修 bug 的)也要抽测核心场景,只是不做全量。