分享
2万字长文,如何成为一个“懂”AI 的产品经理?
输入“/”快速插入内容
2万字长文,如何成为一个“懂”AI 的产品经理?
飞书用户2749
2024年9月12日修改
1、理解 AI 产品的工程化
坦率来说 2024 年围绕大模型,产品的发展速度比之前预期的要低一些,比如在 BI 领域,Chat BI 声量很大,但落地下来效果并不好,这个也很正常,因为每个人总是会在短期内高估技术带来的价值,而在长期范围低估技术带来的价值。
这里面有客观的原因,一项技术基底在真的应用到行业的方方面面本身就是需要过程的,因为这项技术需要去和原本的实现方案做竞争,就像俞军给的知名的需求公式:
很多时候即使用了新技术,收益可能也没有想象的那么大,这是一个事实。
另一个原因就是从业者的理解问题,哪怕是在一些大型互联网公司内部,大部分人对大模型的优势和劣势分别是什么,这个“事实”是存在一些理解上的代差的。
因为现在技术进步的很快,各种实践路径五花八门,有的人会觉得这玩意无所不能,有的人会觉得这个东西根本没法用。
为什么不同的人对这个东西理解的差异这么大?很大程度上是因为他们没有理解大模型作为一个接口和大模型作为一个产品的区别。
大模型可以被视作为是一个函数,一个 API,它本身只能被调用,而大模型产品才是真正面向用户的东西。
比如我给大模型的 API一个 Excel,它会告诉我,不好意思我没办法读取这个文件的内容。但是我们在 Kimi 的聊天框里面,就可以让 Kimi 解释 Excel 内的内容,为什么有这个差异?
因为 Kimi 是大模型产品,背后跑的是 Moonshot-v1 的模型,Kimi Chat 会读取你的 Excel,然后转化成XML 信息给到大模型。
模型在做工程化变成产品的时候往往会添加很多限制,这些限制可能是做在产品层面的, 而不是 API 本身限制的,比如很多产品为了降低成本会限制用户上传 PDF 的大小,但是如果用 API,就没有这个限制,或者限制可以放的很大,但前提是需要首先把 PDF 转化成模型能够理解的文件形式。
市面上产品做了很多的工程转化,甚至是 Function Recall 的工作,直接使用产品,不利于产品经理了解大模型的优势和劣势,就不利于应用大模型,改进现有产品。
那么为什么我认为产品经理比起大模型产品,更应该关注大模型本身(API),因为从 API 到产品,这中间的工程转化过程,是产品经理们最需要关注的。
大模型好比是一个大脑,工程师和产品经理就需要给大模型设计五官,躯干和四肢。脑残和手残都是残,所以工程师和产品经理对于决定一个 AI 产品最后好不好用是非常重要的,头脑发达四肢简单和四肢发达头脑简单最终都解决不了用户的产品。
甚至可能前者对于用户来说会更糟糕一些。
要做出优秀的 AI 产品,不仅仅需要优秀的大模型,还需要优秀的工程师和产品经理来辅助大模型。这就需要产品经理非常了解两件事:
1.
现阶段的大模型有哪些局限性,这些局限性哪些是可以通过模型迭代得到解决的,哪些是不能的。
2.
从更底层的业务角度去分析,大模型在商业意义上真正的价值在哪?注意,这里强调的是业务视角,不是让产品经理去读论文。
2、大模型的局限性是什么?
2.1、一些可能永远都无法被解决的问题
2.1.1、成本、性能与响应速度
想要追求性能越强的大模型,就越需要越高的计算成本。计算成本会带来两个问题:
•
直接造成的金钱成本;
•
响应速度;
下图是 Apple Intelligence 的架构图
,其中在端上有两个模型,而在云端还有一个基于隐私云计算的大模型。
为什么苹果要做这种工程上大小模型的设计?
因为苹果希望大模型的响应速度能够追上 Siri 现在的性能,同时移动设备对功耗本身是有要求的,再加上苹果非常重视隐私,希望 80% 的问题能够在用户本地得到解决,所以采用了这样的架构。
运行 meta 最新开源的 llama 3.1,70 b 版本需要大概 70 GB 的显存,405 b 版本可能需要 400 GB 的显存,可能需要并联 100台 iPhone 才能运行这些模型。这种大小模型的设计,需不需要产品经理,当然需要,什么问题适合小模型解决,什么问题适合大模型解决,这显然不仅仅是 RD 需要去回答的,也需要有产品经理参与,负责如下部分:
💾
•
收集目前用户的 Query;