[BidClub_]
42章经 · · 41 min

AI 下半场:聊透 Benchmark 与 Evaluation | 对谈前 Kimi 产品经理丁丁

曲凯丁丁

Podcast
TL;DR
  • 丁丁完全认同 AI 已进入“下半场”: 竞争重心正从刷通用 benchmark,转向定义贴近真实业务的问题与 evaluation。曲凯以模型在榜单上达到“研究生、博士生”水平、落地时却“最多连个实习生的水平都还算不上”为例;丁丁解释,最终体验是基座模型、system prompt、搜索 API、知识库与接口等环节共同作用的结果,而非单项分数。
  • 曲凯把 DeepSeek 视为从产品与 DAU 重新关注智能的警钟; 丁丁明确的是,RL 的效果必须建立在优秀基座模型和 pre-train 之上。模型能力提升后,复杂提示词的重要性会下降,但 prompt 不会消失,只会回归“简单、清晰、明确”,专职“提示词工程师”则可能消失。
  • DAU 是资本市场和组织管理容易采用的代理指标,却不能直接代表智能进步。 用户规模能带来独家数据,但快手来的用户与连续 50 轮产出调研报告的输入价值完全不同;关键不在数据越多越好,而在高质量数据与目标模型能力是否 align。
  • 曲凯把 Benchmark 比作决定模型把有限“技能点”点向哪里的工具;丁丁认为 benchmark 也是模型公司的核心资产。 好的测试集要真实、有难度梯度和区分度,并随模型迭代不断淘汰、补充;她可能会保留一套算法团队也不知道的隐藏 benchmark,避免模型针对题目作答或被 hack。
  • Benchmark 必须与真实用户指标正相关,否则 evaluation 本身就该被重做。 丁丁以 Manus 为例,提出更有意义的指标可能不是传统 DAU,而是“用最少步骤完成、且结果被下载或引用的比率”;auto eval、human eval 与端到端体验也要持续互相校验。
  • 生产力产品的 evaluation 相对确定,情感陪伴则暴露了“什么是好”没有统一答案。 用户说“我失恋了”,有人要解决方案,有人要追问和 memory callback,有人只想被抱抱,甚至有人喜欢被怼;所谓个性化仍须抽象成模型能力,而“足够聪明,以至于可以扮蠢”本身也是指令遵循。
  • 垂直 AI 的机会不在赌基座模型停滞,而在把领域 know-how、独家数据、反馈机制和工程能力组合成闭环。 好的 AI 产品经理因此要更全栈:高频试用最佳模型与 API、看论文、亲手做 demo,并保留古典产品经理对结构、调性和全局体验的判断,不能只靠 A/B test 把局部指标“做正”。
Digest · the substance, structured for research

1. AI 下半场的矛盾,是榜单智能没有转化为真实效用

  • 2024 年初加入 Kimi、参与 App 早期建设并工作一年多后,丁丁对“AI 下半场”的判断是“完全认可”。她先划清概念:evaluation 是分析模型表现的过程,benchmark 则是用于测试的一套套题。

  • 曲凯指出,模型刷榜时看似已有研究生、博士生水平,真实业务中却“最多连个实习生的水平都还算不上”。丁丁补充,下半场更稀缺的是产品经理式的问题定义,关注实际体验和效用。

  • 丁丁提醒,端到端产品不能只测基座模型;system prompt、搜索 API、知识库、接口和整条工作流会共同决定结果。通用测试题与用户真实输入分布不同,自然可能出现榜单高分、产品难用。

2. 上半场证明了基座模型优先,提示词工程则从职业退回工具

  • 曲凯将国内上半场大致放在 2023 年初至 2024 年底或 2025 年初;丁丁总结,核心仍是提升基座模型、挖掘 pre-train 潜力。Kimi 很早关注 RL,但 RL 的效果必须建立在优秀基础模型和 pre-train 上,DeepSeek 的成功再次验证了这一点。

  • 过去一年,各家也尝试把现有能力包装成生产力产品:Kimi 做 App,字节做豆包,MiniMax 走 Talkie、星野等方向;在基模能力不足或训练范式尚未调整时,提示词工程被推到了非常重要的位置。

  • 模型变强后,用户只需“更加简单、清晰、明确”地描述目标,也可能得到超越过去复杂 prompt 的结果。丁丁对 Sam Altman 说法的解释是:专门的提示词工程师可能不存在,但提示词本身“一定会存在”。

3. DAU 是必要反馈入口,却是容易被误当目标的代理变量

  • 曲凯的观察是,行业一度从追 AGI 转向卷产品 DAU,DeepSeek 又把注意力拉回智能本身。丁丁认为,单一追求 DAU 是移动互联网经验的惯性,也有“有点偷懒”的成分:当模型优劣难以客观表达时,组织、资本和用户最容易理解的只剩规模。

  • 她并不否定 DAU:“你必须要有用户,你才能获得反馈。”Benchmark 的来源既包括通用测试集,也包括线上反馈、人工构造和合成数据;足够规模确实能沉淀独家数据,问题在于噪音和目标错配。

  • 最尖锐的对比是:来自快手的用户输入,与连续 50 轮上下文、最终要求生成调研报告的输入,不具备同等训练价值。用户数据只有经过筛选,并与希望提升的能力 align,才会成为智能进步的燃料。

  • 曲凯追问:OpenAI 数据显著更多,Anthropic 为什么仍能追上?丁丁的回答不是否认数据,而是强调结果来自层层乘积:pre-train、SFT 激活、RL、训练范式与支撑 RL 的 infra,任何一环都可能改变最终体验。

4. 是否承接海量用户,首先是资源约束而非产品信仰

  • 面对“如果你是半年前的梁文锋,要不要接这些 DAU 和数据”,丁丁的答案是:“如果资源充足,我一定想接。”她承认产品经理看到大量用户很难没有承接冲动,但前提恰恰是资源是否足够。

  • 丁丁认为,DeepSeek 后来的处理看起来更像顺其自然,没有特意去承接全部流量。这里没有“用户数据无用”的结论,只有更现实的排序:数据价值要和资源条件、训练链路及各个模型环节一起衡量。

  • 用户数据还能补足产品经理自身的认知边界:公司内部的人不可能是每个行业的专家,也无法穷尽不同模态和用法。高质量输入再结合专家访谈、调研,才更可能帮助模型公司理解真实需求并定义新 benchmark。

5. Benchmark 不只是测量工具,它直接规定模型进化的方向

  • 丁丁从搜索产品转向模型产品后,最大的认知变化是测试集的生命周期。搜索可以长期复用一套相对稳定的数据集;模型一旦解决某个维度,旧 benchmark 就“生命周期结束”,必须不断定义新的维度和难度梯度。

  • 一个深度搜索题可以是:“把腾讯过去十年的财报都找出来,并且预测一下今年它的净利润会上升多少。”输入、模型输出及对输出好坏的评价,共同构成 benchmark 的最小颗粒度。

  • 同一道“好答案”不能跨业务复制。深度搜索需要基于全部数据源,尽量真实、全面;情感陪伴若回答“根据你的心情状态,我有以下几个建议:一……二……”,即使结构清晰,也可能恰恰暴露产品失败。

  • 丁丁的核心判断是:“最终让各家模型产品拉开差距或表现出各自特点的,恰恰是它们对 benchmark 出题这件事的不同定义。”题的难度、好答案的标准,以及新旧能力之间如何取舍,都会牵引训练方向。她还提醒,不能只是把模型 A 训练好的东西直接套到模型 B 上,新一代要继续增长哪些能力本身也是取舍。

6. 好测试集要真实、分层、动态,还要能解释用户指标

  • 丁丁给出的原则是:题目来自真实需求;具备难度与区分度,而非所有题处在同一层;随模型迭代流转,已解决的题可以退出,新能力对应的新题加入。坏 benchmark 则通常“特别简单”,或集中在单一维度、单一难度。

  • Benchmark 最终必须落到产品效果。若测试表现改善,相关用户指标却没有改善,就应修改 benchmark,让二者不断 align;否则“你的评估就没有意义”,预期关系至少应当是正相关。

  • 传统对话轮次、频次、时长和留存未必是最佳指标。丁丁以 Manus 为例,猜测更贴近任务价值的指标可能是:模型用最少步骤交付结果,同时结果被用户下载或引用的比例。

7. 四百道题可以作为假设,但头部 query 不能代表全部需求

  • 曲凯以 400 道题为例询问创业初期的规模;丁丁认为题量并非越多越好,只要足以衡量产品表现即可。把用户 prompt 排序、抽取最高频的 400 条,确实类似搜索时代的高频 query 评测,却必须先过滤噪音和无效输入。

  • 曲凯给出一百万 QV 的假设:头部 400 条也许只覆盖 20 万,剩余 80 万仍是长尾需求。丁丁因此反对只盯 top query,测试集应尽量贴合完整线上分布,同时重点收录点踩等强负反馈,用来识别产品底线。

  • 随用户规模扩大,需求分布会从单一走向分化,评价维度也必须补充或调整。Benchmark 没有固定更新周期;丁丁说“越快越好”,同时强调还是要看数据。

  • 组织结构也会影响质量。大厂常由数据团队制作标注和评测集,再交给策略、功能或端侧产品,链条中存在多个断点;创业团队更小、沟通更短,反而可能更快迭代对“什么是好”的认知。

8. 主观偏好无法消除,只能被建模、分层和个性化

  • 数学和代码存在 ground truth,因此容易评价,也更容易被采用;语言风格、表达方式则缺少百分之百共识。DeepSeek 出圈时被认为“有哲思和优雅”,说明团队必然把这种文风隐含地定义为好,而此前其他公司未必把它当成重要指标。

  • 曲凯据此提出两种未来:不同模型形成不同性格,或针对不同人群乃至每位用户建立 benchmark。丁丁指出现在已经存在一些场景偏好——编程可能优先选 Claude,深度搜索可能选 o3——但个性化未必需要“一千个用户、一千套题”,也可以抽象为 memory 等产品或模型能力。

  • 关于用户“就喜欢蠢的”是否与底模追求更聪明冲突,丁丁的回答很干脆:不冲突,因为装蠢也是指令遵循,“要让他足够聪明,以至于他可以扮蠢”。曲凯把它概括为“大智若愚”。

9. 情感陪伴揭示了 evaluation 最难的一层:人类价值观也没有标准答案

  • 丁丁用“我今天失恋了”拆解 Character.AI 的难题。较差的模型会立即列出跑步、见朋友等建议;更像真人的回答也许只是“怎么了?”,有 memory 时还会追问:“不是上个星期你跟我讲,你们俩之间好好的吗?”

  • 另一种较好的回复可能是询问发生了什么,也可能只是“抱抱你,我一直都在这里陪你”。心理咨询师的视角则可作为参照:先关注情绪变化、让用户倾诉,而不是急于提供方案;曲凯指出,有人恰恰想解决问题,有人喜欢被安慰,还有人希望对方怼一句“失恋了又怎么样”。

  • 因而一套 benchmark 可能只能照顾约 80% 的用户,剩余需求留给个性化、强基座模型和小众产品。更深的疑问是:模型的评价标准本质上是人类价值观映射,但这种映射是否真的正确?两人都没有给出确定答案。

10. Benchmark 会成为秘密资产,垂直壁垒则来自领域反馈闭环

  • 生产力场景拥有较明确的正确性和交付标准,因此 benchmark 相对好定;陪伴类产品虽可能催生小众机会,却更难形成统一评价。曲凯由此问到未来是否会像偷代码一样“偷 benchmark”;丁丁认为 benchmark 是核心资产。

  • 丁丁说自己可能维护一套只有自己知道的隐藏测试集,“甚至算法团队的同学也不应该知道”。原因是训练者知道题目后,可能不由自主地让模型针对性作答,也可能被 hack;因此她倾向于在上线前用秘密集复测。

  • 对“技能树点长板还是平均发展”,丁丁分成两层:基座模型越强,通常在垂类也会自然表现更好,“一个博士生就是比一个小学生更聪明”;但垂直产品仍可通过工程能力、独家数据和业务理解,设计出更准确的反馈信号。

  • 以销售为例,真正的壁垒不只在模型能力,而在团队比别人更懂销售交互、正反馈和奖励机制。深领域 know-how 加上模型理解,能让创业公司更快完成结合、积累用户,并形成行业认知。

11. AI 产品经理必须全栈,但古典产品判断仍不可替代

  • 丁丁认为产品经理的核心仍是“翻译能力”:发现问题,把用户和业务场景抽象出来。过去落到交互和结构,如今还要把完整业务流程翻译成 evaluation 标准、观测指标和反馈节点;数据质量与模型能力边界的重要性则显著上升。

  • 她建议持续使用最好的模型与 API,每隔一两个月感受版本变化,并“把所有你觉得想做的事情先用 AI 做一遍”。GPT-4o 的“言出法随”式图像生成、多轮指令修改,就是只有亲自体验后才能更新的边界。

  • 她主张丢掉模块流转意识,把自己同时当产品经理、设计师、前端,甚至尝试后端,亲手闭合全流程;看论文同样是必备习惯,但产品经理理解原理的深度无需复制算法同学。

  • 微信经历留下的原则依旧有效:先定产品结构再做功能,四个 tab、扫码入口和朋友圈承接多头像需求,体现模块之间的有机联系。A/B test 可以跑 8 个甚至 20 个实验,却无法生成微信的内敛简洁或 Instagram 的 fancy 调性;局部指标还可能被 hack,最终伤害全局。

12. 招到好 AI 产品经理,要看端到端经历、作品和真实使用习惯

  • 丁丁会优先考虑在初创模型团队或小公司完成过从零到一、端到端工作的候选人,因为这类经历更能证明其全栈能力,而非只负责成熟流程中的单个模块。

  • 候选人利用业余时间做过小 demo 或产品,是非常好的信号;作品不必突出,但必须证明他亲手跑过流程、验证过一些东西、碰过模型边界。

  • 即使前两项都不满足,也可以直接问:“你最喜欢哪个模型?平时用得最多的是哪个?在什么场景用?为什么?”具体回答能体现其行业理解、热情和专注度。

曲凯

我们今天很开心请到丁丁。丁丁从 2024 年初开始加入 Kimi,那个时候 Kimi 的 App 刚上线,相当于是去了以后参与上线 Kimi 的 App,之后一直做 Kimi 的 App,做了大概 1 年多的时间,也算是 Kimi 早期的产品同学之一。最近丁丁刚出来。

我们可以从最近比较火的一篇文章先切入,正好通过那篇文章聊一下模型的上下半场。前两天 OpenAI 的那个人写了一篇文章,标题大概就是《AI 的下半场》。我看他里面讲的核心点是,大家对于当下模型能力的开发其实已经到了一定阶段,之前很多 evaluation 用的一些 benchmark 可能没有那么有效了,应该需要一些新的、更偏向实际落地的 evaluation benchmark。

我不知道你是怎么看这个问题的。

丁丁

1. 定义 AI 下半场

在聊这个问题之前,可能还是要先讲一个最基础的概念:什么是 evaluation?其实就是对模型性能的好坏进行分析和评估的过程,而 benchmark 则是一系列基准测试。你也可以理解为给模型出的一套套题,然后看它表现怎么样。

“下半场”那篇文章传播得非常广,其中最重要的一个观点就是,在这个阶段,定义问题可能会比把现有 benchmark 刷分更重要。其实这些 benchmark 跟业务的真实场景,或者用户的实际需求之间,还是存在一定 gap 的。

我记得文章里面有个观点,说鼓励研究者用产品经理的思维,去关注实际的产品体验和效用问题。不然就会出现所谓的智能水平越来越高,但是实际解决问题的效用并没有提升的状况。

曲凯

对。它里面提了一个点,我觉得其实挺对的:现在各种模型看刷分的结果,可能很多 AI 已经达到研究生、博士生的水平了,但实际上落地的时候,可能最多连个实习生的水平都还算不上。

这个背后的原因到底是什么?是 benchmark 设定的问题吗?

丁丁

实际上在真实的业务场景里,除了基准测试之外,我们还会关注很多结合业务和用户真实使用情况的 benchmark。因为刚刚提到的这些基准测试,和真实世界中模型产品在不同业务里的表现,偏差还是会比较大的。

比如说你是一个端到端的模型产品,那你要评估的除了基座模型本身的能力之外,可能还包括整个流程当中的 system prompt、搜索 API、知识库以及接口等一系列环节,它们共同构成了用户体验。

另外,在不同业务或者不同领域内,实际的输入可能跟我们看到的那些基准测试题目完全不一样。基于这个前提,就会出现 benchmark 分数很高,但如果完全拿来即用,在真实业务场景中的表现却并不会特别好的情况。

曲凯

所以你是认可“AI 下半场”这个说法的吗?

丁丁

我完全认可。

曲凯

回顾上半场,至少从国内的认知来讲,应该是从 2023 年初开始,一直到 2024 年底或者 2025 年初,差不多这两年的时间。在你做 Kimi 的这些经验里,包括你看到国内这些大模型公司的发展来看,上半场我们可以总结出哪几个阶段?大家核心提炼出了哪些认知和答案?

丁丁

2. 上半场押注基座模型

首先,上半场大家还是在努力提升基座模型的能力,或者说还在努力挖掘 pre-training 的潜力。对 Kimi 来讲,其实也很早就意识到了 RL 的重要性,但是 RL 的效果最终必须建立在一个很好的基础模型,或者很好的 pre-training 环节之上。DeepSeek 的成功经验其实也验证了这一点。

另外,我觉得大家在过去一年当中,都在积极尝试用现有基座模型的能力,去包装出一些好的生产力产品。但是我们也会同时看到,在过去基座模型能力还不够好的情况下,或者训练范式还没有调整的情况下,提示词工程会被提到一个非常重要的维度。

我记得应该是在去年的上半年,大家还在说你一定要成为一个提示词工程师,或者这可能是一种新的职业。今天不是说提示词不重要,而是相比过去非常复杂的提示词,随着基座模型能力的提升,可能只需要更加简单、清晰、明确地描述你想要的结果,就能输出跟以前一样、甚至超越之前的结果。

曲凯

我记得之前 Sam Altman 说过,好像提示词工程未来是不存在的。

丁丁

我觉得他说“不存在”的意思是,专门的提示词工程师这个职业可能不存在,但是提示词本身一定会存在。

曲凯

明白。我的感知是,从 2023 年开始,几家模型厂商都在追求 pre-training 的极致,追求 AGI。但过去一年多的时间里,大家其实各自都落在了产品上面。

比如 Kimi 落在它的 App 上,字节落在豆包上,MiniMax 最后可能选择了 Talkie、星野这些方向。大家开始去卷谁的 DAU 更高。DeepSeek 出来以后,反而像是一个警钟,大家又发现,原来智能更高以后,前面这些东西可能都没有那么重要。

所以现在我的感觉是,大家又回到追求 AGI 的路线。从你的视角来讲,是不是这么回事?

丁丁

3. DAU 不是智能指标

首先,我觉得一味地或者单一指标地追求 DAU,某种程度上是一种经验惯性,或者有点偷懒的行为。

过去在移动互联网时代,大家用什么来衡量产品是否成功?用户规模可能就是一个非常直接的指标。其实这正好也跟 benchmark 相关:大家没有一个客观指标能够评价你的东西到底做得怎么样,很难讲我的模型做了一年就比别人强多少。Benchmark 大家又都知道可以刷分,所以不管是内部定 OKR、KPI,还是对外面向资本市场和用户,能够评价的可能就是 DAU。

所以我觉得这也是一个必然结果。我觉得 DAU 并不是不重要,而且其实你必须要有用户,才能获得反馈,获得真实的用户输入。只是说,一味地追求 DAU,对模型能力的提升可能没有帮助。

这里面我觉得也可以从 benchmark 的来源来理解。我们所说的 benchmark 有哪几种来源?一种是刚刚说的基准通用 benchmark;还有一种可能是用户线上真实的反馈,可能跟 DAU 或者用户使用情况相关;另外还有人工构造的 benchmark,包括合成数据 benchmark。

刚刚我们说的 DAU,会积累用户数据,而且你有一定的 DAU 规模,一定能够帮助你获得独家数据。但问题是,用户输入很多时候噪音太大了。比如一个快手来的用户,和一个真正把模型当生产力工具、聊 50 轮上下文,最终输出一份调研报告的用户,他们的数据可能完全不一样。

也就是说,用户数据仍然重要,但是高质量的用户数据和我们想要提升的模型能力之间,必须是 aligned 的。你必须挑选准确的 benchmark,才能对模型智能的提升有帮助。

曲凯

我们一直在讲,数据对于模型来讲特别重要,长期以来也一直在讲数据是壁垒。大家会说 ChatGPT 发得早,有这么多用户使用,所以有很多数据,模型效果会更好。

但过去几个月,很多人在讨论 DeepSeek 到底要不要接这些用户,这些数据到底对 DeepSeek 有没有用。所以你觉得这些数据对于模型进展、对于智能水平提升,作用有多大?

丁丁

当然重要。当你没有用户数据的时候,公司的人或者产品经理本身也是有局限的。他不是每个行业的专家,也没有亲自尝试模型所有的用法,更没有尝试各种模态的混合输入。

我觉得用户数据或者高质量数据,恰恰能够提供这些行业视角。如果你能结合一些专家访谈、调研之类的工作,我觉得就能帮助每一家基座模型公司更好地理解用户,以及定义出更好的 benchmark。

曲凯

但你看,OpenAI 的数据肯定远高于其他家,Anthropic 一样追上来了。这个原因是什么?是不是数据肯定有用,但是用处还没有那么大?

丁丁

因为最终的表现其实有非常多的环节。你的 pre-training 基模训得好不好,后训练的过程做得好不好,SFT 激活得好不好,当时有没有使用 RL,还是大家都在使用 SFT,都会产生影响。

RL 也依赖高效的 infra 基建,以及对这个范式的绝对笃定。这些环节层层相乘,最终共同构成了它是不是一个好的体验。

曲凯

所以以你的模型产品视角,如果你是半年前的梁文锋,你要不要接那些 DAU 和数据?

丁丁

如果资源充足,我一定想接。

曲凯

但前提是资源充足,对吧?恰恰就是资源不够充足。

丁丁

还是想接,这是不是古典产品经理的通病?

曲凯

你会吧?对吧?你这么多用户来,还是有这个想法的,我觉得。

丁丁

但从最后结果来讲,他们好像就顺其自然,对吧?他也没有特意的要去接这个东西。

曲凯

然后我们讲回到你在模型公司做的那段时间。最终总结下来,你觉得最大的几个收获和经验是什么?

丁丁

4. Benchmark 进入实战

我觉得还是对模型评估,以及对整个 benchmark 的认知。

我之前做过搜索产品,搜索以前也会有一些评测,这个工作还是有点类似的。但在过去做搜索的时候,评测数据集变化的速度可能没有那么快,你可以用一套相对通用的测试集,使用很长一段时间。

但是在模型公司,因为模型能力本身也是动态迭代的。当模型某一个维度上的能力通过一个 benchmark 已经解决了,这个 benchmark 的生命周期可能就结束了。之后你可能就需要定义很多不同维度、不同梯度的 benchmark,一步步推进模型的进步。

最终,模型智能的体现就是 benchmark 的难度。无非就是说你出什么样的题,得到一个什么样的结果。最终让各家模型产品拉开差距、表现出各自特点的,恰恰是它们对 benchmark 出题这件事的不同定义。

曲凯

我能不能简单理解为,evaluation 肯定是最重要的?对于模型的表现和产品最终表现来讲,evaluation 就是通过 benchmark 来进行评估和实现。Benchmark 可能是第三方,或者产品内部自己出的一套题。

你能不能举一些例子?这些题大概是什么样的?

丁丁

比如一个典型的深度搜索题,可能会是:“你能帮我把腾讯过去 10 年的财报都找出来,并且预测一下今年它的净利润会上升多少?”

这个时候模型会有一个输出,然后会有另外一个 reward 来评价模型的输出到底好不好。刚刚看到的输入、输出,以及对输出的评价,就构成了一个 benchmark 最小颗粒度的单位。

但实际上,在不同业务当中,评测标准或者在意的点是非常不一样的。比如刚刚讲到,如果你做深度搜索,你可能希望模型能够基于检索到的所有数据源,给出一个尽量真实且全面的结果。

但如果你是一个 Character.AI,它可能是一个情感陪伴类产品,那刚才的标准就变得不重要了。你不希望它在情感陪伴的时候说:“根据你的心情状态,我有以下几个建议:一,什么;二,什么。”

但也许这种结构化输出,在研报等很多场景下又非常适用。所以这又回到了刚刚讲的:在不同业务场景中,评估标准的好坏会有非常大的区分度。

曲凯

所以我听起来,这个问题其实就是用户在真实场景中会给的一段 prompt,对吧?它作为一个问题,然后你去评估的时候,可能不是简单地判断对错或者好坏,而是分好几个维度,甚至会有一个很复杂的表格来评价这段话。

丁丁

我觉得最终一定能够抽象出几个维度,然后让模型学习你对“好”的判断。

曲凯

但这几个“好”也是有优先级的吗?我在想,有的场景里,给用户的回复是不是足够口语化、长度是不是适中,可能是好几个标准。这几个标准有时候可能是相悖的:有可能这个是 A 好,那个是 B 好,那最后怎么定义好呢?

丁丁

还是会回到真实的用户场景。比如 Character.AI 的场景,产品侧的业务视角已经做了一层判断:对用户意图的理解和口语化,可能比其他指标更重要。

所以在这个过程中,你抽象的不只是元素和分类,同时也会抽象它们的重要性。

这里面有一个非常有意思的例子,就是当时 DeepSeek 出圈的时候,很大的原因是大家觉得 DeepSeek 的文风特别有意思,显得非常有哲思和优雅。但其实这背后反映的是,他们的团队对于什么是“好”这件事情,一定有一条隐含标准:模型这样回答是好的。

在那之前,没有任何一家公司,哪怕把时间倒回到 DeepSeek 出现之前,我们在内部说这种文风很重要,大家一定会觉得它是一个好的指标吗?我觉得也未必。

所以模型评估本身就是特别难的一件事情。我觉得,所有人都有共识且 100% 正确的评价标准,其实不太好制定。

曲凯

我听起来,这个世界上好像就没有百分之百确定的标准。它还是一个比较偏人类喜好的结果。

丁丁

要看是哪些领域。数学题肯定有,代码题肯定有,这些有 ground truth 的题目就比较好做。今天大家也会非常偏好采用这类题目,因为它有一个标准答案。

但对于一些不好量化的层面,比如语言风格、表达方式等,我觉得这些其实不太好制定,甚至没有共识。

曲凯

从这个角度,我在想两个问题。

一个问题是,如果是这样,未来会不会应该有更多模型?每个模型都有自己的性格,有的人喜欢这个,有的人喜欢那个。

另外一种可能是,未来 benchmark 会不会细到给不同人群做分类?比如我有 1,000 个用户,极端一点,我甚至有 1,000 个 benchmark,分别对应不同的用户,每个人得到的结果都不一样。

丁丁

5. Benchmarks Become Personal

对于第一点,我觉得是的,其实现在已经有一些偏好了。比如当你编程的时候,第一优先级肯定会选择 Claude;但如果你做一些深度搜索,可能今天就会去用 o3。

对于第二个问题,我觉得可以换一个角度,最终还是要把这种个性化抽象到某种模型能力或者产品能力上。举个最简单的例子:能不能通过 memory 来解决你刚刚说的个性化偏好?我觉得有这个可能性。

OpenAI 本身也在努力做这件事。所以可能不一定需要像你说的那样,把 benchmark 细分到那么多,但它一定会通过某种模型内化的能力,帮助你达成最终目标。

曲凯

我又想了一个极端例子。假设还是一个 Character.AI 产品,公司本身希望这个产品的情商越来越高、智商越来越高。但如果有个用户说:“我就喜欢蠢的。”他会通过各种对话去调教这个 bot,希望这个 bot 变得越来越蠢。

但同时,这家公司的底模就是想把它变得越来越聪明。这是不是一个矛盾?

丁丁

我觉得不是。用户希望它“蠢”,本质上是一种指令遵循能力,也是模型的基础能力。要让它足够聪明,以至于它可以扮蠢。

曲凯

最顶尖的人,我觉得也是可以做到这样,大智若愚。面对不同的人,完全可以去迎合对方的喜好。

Benchmark 我听起来,好像大家能想到的应该差不多。所以有没有一两个例子,是你觉得特别巧妙、别人不太容易想到,但定出来以后对产品和模型提升特别有帮助的?

你刚才说的那种,我觉得大家坐在那里硬想,总归能写出各种题目,包括去看用户互动的数据、提问的数据,做个排序,大概也能分出来一些。最终 A 公司和 B 公司,通过 benchmark 定义的不同,带来的结果不同。这个 benchmark 的不同到底体现在哪儿?

丁丁

首先在同一领域,benchmark 的难度可能就不一样,而这个难度通过什么体现?就是通过你怎么理解这个业务。

比如一开始你做搜索的时候,会用一些特别简单的题目,当时可能会觉得这就是用户输入。但再过一段时间,你会发现,有些金融领域的用户可能会通过上下 5 到 10 轮对话,提出一个比较复杂的 prompt,然后让模型直接一步到位输出结果。

这时候你可能就会有一个更难的 benchmark。对于这个 benchmark,什么是好的标准,各家公司一定也会有差异,而这个差异会直接引领模型迭代的方向。

另外,过去模型确实可能会出现这样的情况:你把模型 A 训练好了,可能就直接丢到了模型 B 上。但我们最希望出现的场景,是在前一代模型的基础上,新的能力不断增长。

这个时候你更看重哪个方向的能力,我觉得也是一种取舍。

曲凯

Benchmark 的好坏,是不是还是一个相对主观的事情?有哪些客观指标能够衡量?

丁丁

6. Benchmark 需要持续迭代

一个比较好的 benchmark,可能有几个原则。

首先,它一定是真实的,能够反映线上用户的需求;同时也要有一定的难度和区分度,不能所有题目的难度都一样。

其次,benchmark 要随着整个模型迭代的生命周期流转。刚刚说过,你可能会抛弃旧 benchmark,也可能加入新的题目。

曲凯

古典产品经理看的指标,可能是用户使用频次、使用时长,对吧?放到 AI 里面,可能就是对话轮次,以及留存这类数据。那 benchmark 和这些数据是挂钩的吗?

丁丁

它一定存在关联关系。Benchmark 本质上反映的是模型某一方面的能力到底好不好用,而好不好用本质上又会转化成用户指标。

只不过今天的用户指标可能像我们刚刚说的那样:模型好,并不一定代表 DAU 好。在不同业务下,相关的用户指标可能会变化。它最佳的用户指标,也可能是某种我们还没有想到、但更好的指标。

曲凯

我前两天还在想一件事:Manus 火出圈了,Manus 的核心用户指标有可能是什么?我能想到的可能是最少步骤,以及结果被用户下载或者引用的比率。

所以 benchmark 跟最终的用户指标是强关联关系吗?你们会不会看,比如我今天出了这个 benchmark,如果它变得更好,理论上这些用户指标应该也变得更好?

丁丁

是的。如果没有变得更好,就要去改你的 benchmark,至少要让它们不断 align,不然你的评估就没有意义。它们应该是正相关的。

另外,在做 evaluation 的时候,可能会涉及 auto eval 和 human eval:一个是用大模型评价自己模型的任务完成效果,另一个是用人最终评价端到端的效果。

我理解这两种 eval 也需要不断校验。不然就会出现模型自动打分,打出来的结果却跟真实用户体验之间存在 gap 的情况。这个过程本身也是动态的。

曲凯

就你现在跟 AI 公司产品经理交流下来,你觉得大家对于 benchmark 的理解和实践,已经差不多在同一个水平了吗?还是会有哪些差异化的东西?

丁丁

首先,创业公司和大厂可能会有一些分化。

大厂里我看到的是,不同团队还在按照以前的方式流转:高质量数据标注和评测集,完全由数据团队去做;评测或者策略产品拿到结果以后,再去跟功能侧或者端侧产品沟通。我觉得这里面的断点其实比较多。

但对于创业公司来讲,因为团队足够小,或者组织方式不一样,大家的认知迭代其实比较快。

曲凯

Benchmark 多久变一次比较合理?

丁丁

我觉得没有标准答案,越快越好,还是要看数据。

曲凯

对,越快说明你们模型能力迭代得越快。但对于很多创业公司来讲,如果它不动模型,迭代的应该是预制的 prompt 和工程侧的能力,然后影响它的结果。

丁丁

我补充一点:一开始用户基数比较少的时候,评价维度可能相对单一,因为用户分化也不严重。当用户变得更广之后,用户需求分布会越来越不一样。

在这种情况下,你仍然要适应不同用户,达到最好的效果,那你的标准可能也会进行补充或者调整。

曲凯

我又想到几个问题。一个是你觉得市场里,尤其是创业公司来讲,它的 benchmark 大概在多少量级比较合理?

比如说今天你自己要做一个创业公司,一开始会出多少道题来测这个产品?假设是 400 道题,这个题是越多越好,还是越少越好?

丁丁

我觉得不是越多越好,而是你能够衡量模型的表现就可以了。

曲凯

那我能不能先让产品上线,让用户使用起来,然后把用户所有的 prompt 排序,或者做一个类似模糊搜索的东西,最后排出前 400 个,就把它们作为我的 benchmark?

丁丁

你说的这个特别有意思,因为这就是以前搜索 benchmark 之一:对高频 query 的效果进行评测。

但还是那个问题,你可能要过滤一些噪音,或者没有那么有效的用户数据。另外,跟搜索一样,很多需求可能非常长尾。你如果只解决头部的 400 个,剩下的需求怎么办?

曲凯

假设整个 QV 量是 100 万,头部 400 个可能只覆盖其中 20 万,那剩下的 80 万要不要解决?

丁丁

肯定要解决。所以又回到我们刚刚说的原则:还是要尽量符合线上用户的分布,而不是单一地只看头部。

但我们确实会更关注大家都会去看的一些强烈负反馈信号,这种信号可能更能帮助你判断底线问题。

曲凯

如果现在给你一家公司,它的 benchmark 是 400 道题、40 道题或者 100 道题,你能很快分辨出这个 benchmark 的好坏吗?大概会是什么样的?

丁丁

我觉得首先要看它是不是我所了解的领域。假设是我了解的领域,当然可以,因为你能知道它的 benchmark 是否有梯度,是否符合你对产品的理解、用户需求以及真实数据分布。

曲凯

你举一个典型的坏 benchmark 的例子。

丁丁

我做了这么多好的 benchmark,从来没人问过我一个坏 benchmark 长什么样。

比如它特别简单,或者 benchmark 里的题目单一地集中在某一个维度、某一个困难程度上,那就是一个非常糟糕的 benchmark。

曲凯

我听到这里,感觉给模型表现做 benchmark,有点像给你一堆点数,让你去点不同的技能树。

有没有一种可能,我把所有点数都点在某一项上,让长板足够长,用户对我这个产品的长板感知足够明显,反而可以脱颖而出?还是说平均地去点这些点数才是最好的选择?

丁丁

这个问题可能得分两层看。

一个是基座模型的能力。我们会看到,基座模型能力越强,它在一些垂类里的表现确实也会越好,这就是泛化能力。你什么都不做,天然一个博士生就是比一个小学生更聪明。

但另外一个视角是,在此之上,确实存在一些垂直产品、模型或者 agent 的机会。它不完全只基于模型能力,而是加入很多其他因素,比如工程能力、独家数据,以及对业务本身的理解。

比如有一个业务就是做销售,那么它可能比其他任何公司或者任何人,都更了解销售这件事情中的交互,以及抽象出的正反馈信号。这样一来,它就可能设计出更好的基于模型的产品,也能告诉模型到底应该奖励什么。

曲凯

明白。那我们举一个例子,大家日常可能都用过类似 Character.AI 这样的聊天类产品。

假设现在你做一个 AI 陪聊类产品,难点可能在哪里?要怎么做这件事?

丁丁

情感聊天或者陪伴这个场景,因为没有 ground truth 或者标准答案,所以评估标准到底怎么定才完全准确,这件事情还挺难衡量的。

比如现在你在跟一个陪伴型产品聊天,你说:“我今天失恋了,跟我的对象分手了。”你预期模型会怎么回复你?

如果没有做过口语化或者情绪识别回复的模型,它可能会说:“听到这件事我很难过,我给你推荐以下几种方式来放松心情:一,下楼跑一跑;二,去见见朋友。”

曲凯

非常有画面感,很多模型确实是这样的。

丁丁

但你觉得比较好的回复,肯定会希望它首先像一个真人一样,可能会问你:“怎么了?”

如果它具有 memory 能力,甚至可能会问:“不是上个星期你还跟我讲,你们俩之间好好的吗?”

有的模型可能会关心具体出了什么问题;但有的模型可能会回复:“抱抱你,我一直都在这里陪你。如果你有什么不开心的,仍然可以跟我分享。”

一个真实的人在这种情况下,到底预期获得什么样的回复,我们没有一个非常细、百分之百正确的答案。我们只能尽量说,在这种情况下,希望模型首先关注到用户情绪的变化;其次,从 memory 的角度,希望它知道用户的情感状态,判断要不要进行 callback。

再从心理咨询师这类专家的角度来说,我们不会急着给解决方案,而是会关心背后到底发生了什么,让用户先把自己的情感状态和具体故事倾诉出来。

曲凯

我听起来就觉得,这件事确实非常难定义。因为有的人可能就是喜欢解决问题;有的人喜欢别人怼他一下,说:“你失恋了又怎么样?别把它当回事。”还有的人就喜欢有一个像闺蜜一样的人去安慰他。

几乎无法定义一个好的 benchmark。

丁丁

从这个角度来讲,我觉得未来一定会出现一些小众、猎奇的产品。因为像你刚刚讲的,benchmark 的定义可能只能照顾到 80% 的用户。也许加上个性化和足够强的基座模型能力,也能够解决一部分问题。

但我其实还在想一个更抽象的问题:我们刚刚在定义很多评价标准或者价值观的时候,会发现它整体上是人类价值观的映射。这件事情对吗?

曲凯

这个确实很抽象。

丁丁

无非就是,你觉得整个人类世界当中,一定存在某个问题上相对更好的答案,所以你再去做这个映射。但这种映射真的是对的吗?我不知道。

我在想,答案可能分两种:一种是社会约定俗成的答案;另外一种可能是更高级版本的答案。比如你在讨论一个问题的时候,身边的朋友都会给你一个答案,但这时可能有一个类似教授角色的人,会给你另外一个答案,你会觉得这个答案可能更有醍醐灌顶的感觉。

我觉得在做题、生产力等很多场景里,这种方式现在还是 work 的。但刚刚讲到的那些场景,有时候就会让人想:这样就是完全准确的吗?不好说。

曲凯

所以从这个角度来讲,生产力类产品的确定性更强,或者说它的标准相对更好找,也就更好做,benchmark 肯定更好定义。

以前不是会有公司说偷竞争对手的代码吗?未来会不会说偷 benchmark?

丁丁

这个话题特别有意思。我觉得 benchmark 确实是一个核心资产。如果是我的话,可能会维护一个只有自己知道的 benchmark,甚至算法团队的同学也不应该知道。

因为如果他们知道了,可能会在训练过程中不由自主地让模型答出这些问题,也不知道会不会被 hack。

我可能每次上线之前测一下,但不会公布 benchmark 具体是什么。所以 benchmark 确实是一个特别特别重要的东西。

曲凯

你之前最早在微信做搜索类产品,后来又在美团做过策略产品,之后在 Kimi 做模型产品。你回过头来看,AI 产品经理和古典产品经理相比,大家相同和不同的地方在哪儿?

丁丁

7. AI 产品经理的新能力

我觉得相同的地方是懂用户。相同的能力点叫做翻译能力,也就是发现问题,并把用户和业务场景进行抽象。

比如过去的抽象,可能是抽象在交互设计和整体结构设计上;今天在模型产品里,就是把业务的整个流程抽象出一种好的评估标准和观测指标。

所以我觉得抽象能力,以及对用户场景和需求的翻译能力,仍然非常重要。

另外,我觉得原来古典产品经理非常重要的一点,是对交互体验的敏锐感知能力:什么是美的,什么是丑的,什么是符合直觉的设计,什么又不是。这种能力仍然需要,而且我觉得是稀缺的。

现在大家谈了很多模型,但今天一个不同产品基于模型能力的最佳交互,其实还没有诞生。在一些垂类产品里,交互可能会更加重要。这种交互甚至会直接反映出,你能不能为模型迭代或者产品迭代设计出合适的反馈节点和反馈信号。

不同的地方在于,对数据的重视程度会发生非常大的变化。现在会比以往更加重视数据质量,还有对模型能力边界的理解。这个过程,我觉得也需要很多时间去积累。

曲凯

这部分我觉得可以展开讲讲,应该是最难也是最重要的一部分。

现在模型进展其实还是很快的,有的人会担心:我现在做的东西,半年后是不是就会被模型颠覆掉、没有用了?或者我做的整个产品,是不是就在模型的发展路线上?

怎么样才能像你刚才讲的那样,更理解模型的边界,并且预判模型的边界?

丁丁

我先说方法层面。这个问题可能也有很多产品经理跟我讨论过。我觉得还是要多用不同的、最好的模型,以及它们的 API。你会理解不同模型在不同领域、不同能力上的表现,也会更加熟悉模型每隔 1 个月、2 个月的变化,因为它一定会有新版本和能力提升。

第二点,之前内部同学也会分享:把所有你觉得想做的事情,先用 AI 做一遍。

比如以前做 C 端产品,除了 PRD 之外,可能还要先画交互。你可以试着把想要的交互逻辑清楚地说出来,然后让 Claude 帮你制作一个交互。在这个过程中,你就会摸到模型能力的边界,以及它能帮你实现什么。

在这种动态地跟模型一起迭代、使用的过程中,你可能会发现,它某个方向的能力比你想象中变得越来越强。

这个例子也可以回到前阵子非常火的 GPT-4o 的“言出法随”图像生成。你在没有体验到它之前,可能会觉得生成一个指令遵循、特别是支持上下文多轮修改的图像非常难。但今天你会发现,GPT-4o 完全能做到。

这就是伴随着模型能力边界的迭代而产生的机会。在这个基础上,你可能又能快速做出一些新的产品。

另外,我觉得你的动手能力要很强。不需要像过去的产品经理一样,有非常强的模块流转意识,而是要完全丢掉这个意识。

你要把自己同时当成一个产品经理、设计师和前端。现在可能还不能完全当后端,但也可以试一试,然后完成全流程的闭环。我觉得这对你理解模型也会更有帮助。

曲凯

所以未来你是不是也觉得,每个人真的都会变成全栈?

丁丁

我觉得是。

曲凯

你自己会看论文吗?之前 HACK 做了一期播客,我们也有很多人听,我是那期的忠实用户。张涛在那期里讲了很多点,他自己会日常去看论文。

你觉得看论文是 AI 产品经理的必备能力吗?

丁丁

我觉得是。这个习惯非常重要,因为理解原理,以及在理解原理的基础上做验证,本来就是一体的。

我没有见过哪个人会使用模型,但完全不关心原理的实现。你肯定会想知道它为什么会这样、为什么某些能力做得比较强。

当然,你理解论文的深度,可能跟算法同学理解论文的深度完全不一样。论文也分很多种类,如果完全是在讲算法,我觉得即使我努力看,也不一定能看懂;但如果是讲一些比较前沿的判断,其实也可以搭配着去看。

曲凯

从你做过模型产品的视角来看,你觉得创业公司,或者正在做 AI 产品的人,做哪些事情不会被未来的模型碾压?能给一些大概的判断标准吗?

丁丁

首先,我觉得他可能需要有很深的领域 know-how,同时又具备对模型的理解。这样他可能会在这个阶段,成为最快把两者结合起来的人,形成一定的产品壁垒或者行业认知,并积累用户。

曲凯

我们最后还是讲回到你在微信的那段经历。稍微回顾一下,你在微信那段经历里,有哪些印象特别深刻的东西?

我们前面讲了很多 AI 产品的东西,但那段经历反而是大家认可的、古典产品经理非常经典的一段经历。

丁丁

我觉得有一些产品原则。

一个是先做产品结构,然后才是功能细节。比如我们会发现,微信里有很多功能,如果都用不同的 tab 来表现,不做层级拆分,那今天可能会非常冗余,也会非常复杂。但直到今天,微信还是比较简单,也只有 4 个 tab。

曲凯

这个真的是张小龙一上来就已经想好的吗?就是说我要这几个 tab,要怎么做朋友圈、做公众号,再怎么做其他功能?

丁丁

我觉得底层结构他从一开始就想得非常清楚。包括他抽象出“扫码”这样一个新的入口,扫码背后提供的是一种服务能力。这些事情甚至在小程序诞生前两年,张小龙就已经想好了。

另外,功能模块之间是有机联系的。当时很多用户都说,微信要是能不只用一个头像就好了,最好有多个头像,可以左滑右滑。

但实际上你会发现,用户背后的需求是想要有更多头像照片展示给别人看。所以这个需求应该由朋友圈来承载,而不是在头像这个单点上做设计。

这就是刚刚说的,功能模块之间是有机联系的。

另外,我们不会主动强教育用户一定要使用哪个功能,而是让用户在使用某个功能、继续往下钻的时候,自己发现一些新的体验,然后触发新的能力。

曲凯

所以你后来在其他公司,包括模型产品公司做过以后,觉得这些东西仍然适用吗?

丁丁

我觉得适用。底层原理其实还是一样的。

我觉得从微信出来的产品经理,有一个被训练出来的点,就是大家都会基于更全局的视角,真正去想什么是好的体验。

但今天在一些公司,因为验证某些能力和功能的设计太简单了,上 A/B 实验又非常方便,你可以跑 8 个实验,甚至 20 个实验,只要选最终把指标做正的那个就可以。

这样一来,年轻同学在做方案的时候,就不会真的去想用户需不需要这个功能、它跟全局有什么联系、这么做到底是不是好的,因为可能只要跑实验就好了。

曲凯

其实我们刚才讲过好几次古典产品经理。但我理解,这个概念最早提出来,是说古典产品经理依靠很多个人经验和感觉,依靠用户感知来做事情。它最早对应的,可能就是更多的 A/B test 和实验型的数据驱动产品。

比较典型的,美国很多大厂会做很多 A/B test,字节也是以这个出名的,对吧?它也做各种 A/B test,最终看数据。如果数据好,哪怕你解释不清楚为什么会这样,它也是好的。

不知道你最后会不会同意这个说法?

丁丁

谈这个问题之前,我觉得可能得再往上说一层:每个产品首先都有自己的个性,或者说有自己的感觉。

比如微信给人的感觉就是比较内敛、极致简单;Instagram 给人的感觉就是很时髦、很漂亮,是一种很 fancy 的感觉。我觉得这种调性肯定不能通过 A/B 实验得到。

你的产品打开以后很乱,但留存比原来高了,这其实是一种价值观取向:你是不是为了追求指标,就能容忍产品增加那么多东西?微信的取向就是绝对不可以。

第二个问题是,你选的指标到底对不对。公司大了以后,每个部门、每个业务的指标,其实都会存在被 hack 的空间。

因为它关注的不是一个统一的大指标,也不一定遵循某种调性或者价值观的体现。它可能只要做正自己业务的指标就可以了,即使这种做法可能非常违反直觉,最后对大指标来说甚至是负的。

曲凯

最后一个问题:如果一家创业公司想招一个好的 AI 产品经理,现在其实挺难找的,也没有一个典型画像能说明这个人就是 AI 产品经理。

你觉得大家到底应该怎么找,或者怎么培养这样的人?

丁丁

8. AI 产品经理的招聘标准

首先,如果从背景上来讲,我可能会更偏好在初创的模型产品或者更小的公司里,完成过从 0 到 1,或者端到端工作的同学。也就是更全栈、自己从头到尾做过一些东西的人。

第二,我也看到过一些同学会利用业余时间,做一些小 demo 或者小产品出来。我觉得这是一个非常好的信号。

因为如果你是一个好的 AI 产品经理,本身就像你说的,可能是个全栈。产品可以不用特别突出,但你肯定自己跑过一些东西,验证过一些东西。

第三,我觉得可以直接问他:“你最喜欢的模型是哪个?你平时用得最多的模型是什么?一般在什么场景下使用?为什么使用它们?”

即使前面两条没有满足,从第三点也可以看出他对整个行业的理解、热情,以及专注度。

AI 下半场:聊透 Benchmark 与 Evaluation | 对谈前 Kimi 产品经理丁丁 | BidClub