2万字长文，如何成为一个“懂”AI 的产品经理？

本文链接：https://blog.csdn.net/2301_76168381/article/details/144669600

随着人工智能技术的快速发展，大模型已经成为推动产品创新和业务增长的关键因素。对于产品经理而言，理解AI的工程化、局限性以及如何将AI技术有效融入产品开发流程，变得尤为重要。本文深入探讨了AI产品工程化的理解、大模型的局限性，以及如何成为一个真正“懂”AI的产品经理。

文末有读者福利
在这里插入图片描述

此外，本文面向的读者是非算法团队的产品经理，为了保障文章的可读性，可能会省略部分细节，同时文章重点是工程落地而非学术探讨，不具备任何辩经的价值。

一、理解 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 产品，不仅仅需要优秀的大模型，还需要优秀的工程师和产品经理来辅助大模型。

这就需要产品经理非常了解两件事：

现阶段的大模型有哪些局限性，这些局限性哪些是可以通过模型迭代得到解决的，哪些是不能的。
从更底层的业务角度去分析，大模型在商业意义上真正的价值在哪？注意，这里强调的是业务视角，不是让产品经理去读论文。

二、大模型的局限性是什么？

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；
从解决难度、隐私、对时效性的要求、对准确性的要求对 Query 进行分类；
设计基准测试，获得大小模型分界的标准；
持续追踪优化；

在未来至少很长一段时间，还是会有大量的本地/联网之争的，这个就是产品经理的机会。

2.1.2 窗口大小与不稳定

我们经常会看到，XXX 大模型支持 128K 上下文了，引来大家的一阵狂欢。

我们又会经常看见，XXX 大模型幻觉问题很严重，引来一阵吐槽。

上下文是什么意思？其实就是大模型在一次请求的过程中，能够接收的最大的信息的数量。我们在和 ChatGPT 聊天的时候会发现有的时候它聊着聊着会忘记之前自己说过的话，其实就是因为聊天记录已经超过了上下文的数量。

幻觉的意思则是大模型很容易会胡说八道，胡编乱造一些事实上不存在的东西，尤其是当它已经忘记前面和你说什么之后，你再问他类似的问题，它就会开始胡说。

很像一个渣男，你们已经牵手了。

你问：“我叫什么名字？”

他回答：“当然叫亲爱的啦。”

其实他已经不记得名字了，所以就开始胡编乱造了，绝了，这玩意真的很像人类。

根据英伟达的论文《RULER: What’s the Real Context Size of Your Long-Context Language Models?》来看，大部分模型宣传的上下文窗口基本上就是在扯淡，在极限长度的情况下，各家大模型对正确水平，是没有保障的。

比如说一个模型宣传自己支持 128k 的上下文（意思是差不多可以读一篇 20 万字的小说），但是实际上如果你随机塞一些句子进这篇小说，然后让大模型回答和这些句子有关的知识，它是有比较大概率答不出来的，它的性能会随着上下文窗口的变大而衰减。

如下图所示，以 GPT4 来说，当上下文超过 64k 时，性能就开始骤降：
在这里插入图片描述

实际情况来说，我认为这些模型的表现会比你想象的更加糟糕。

我让 Claude 3.5 Sonnet 模型分析了一段的 SQL，这是一个 700 行的复杂 SQL，但是总体来说逻辑应该是比较简单的，而且几乎每一行 SQL 都有注解，在这种情况下，Sonnet 就开始胡说八道了，说了一个 SQL 里面根本不存在的表。

不排除是因为我在 Monica 的客户端里面调用 Sonnet 造成的，不知道 Monica 调用的时候是不是加了什么 Prompt 干扰了模型。

如何在保证解决用户问题的时候，避免受到上下文的影响和干扰呢？

其实这个事情也需要产品经理的干预，比如：

研究能否把长文本切成多个段文本，并且不影响最终的结果；
研究怎么给 AI 外挂一些能够超长时间记忆的记忆库；

举例来说，掘金上面有一篇文章《多轮对话中让AI保持长期记忆的8种优化方式（附案例和代码）》，就讲述了 8 种主流的方法，这些方法都应该是产品经理根据业务场景去选择的。

最后聊一聊为什么我认为上下文窗口与不稳定的问题是一个长期内很难解决的问题。

在过去的一段时间，上下文窗口大小的问题其实是的到了一定程度的缓解的，但是根据英伟达的论文我们也可以发现，上下文窗口的大小和稳定的抽取内容避免幻觉这两个指标在很大程度上就是互斥的，就像是推荐系统的准确率和召回率指标一样。

这也就意味着在很长一段时间我们可能都没有两全之策，除非突然出现一个模型一方面解决幻觉问题，一方面能保证巨大的窗口。

而且在实践的时候我们往往需要避免极端 Case 的发生（比如我自己遇到的 700 行 SQL 解析错误），减少上下文的规模是很重要的手段，此外不同的检测手段下其实模型的表现并不完全一致，也就是说不同的业务场景，幻觉问题的严重程度其实是不一样的。

模型能够容纳的最大窗口和有效工作窗口是两个概念，并且不同的任务的有效窗口大小可能是非常不一致的。

**我当然希望我的想法是错的，**目前而言我看不到任何模型能够在这件事情上有突破的可能性，有一家公司叫 Magic，推出了一个号称具备了 1 亿 token 上下文窗口的模型，但截止到目前为止（2024.9.1）并没有发布任何的论文或者更实际的东西。

还是那句话，最大窗口和有效工作窗口是两个概念。

此外，多模态的发展某种角度来说会加剧窗口大小不足的问题。

2.1.3 函数本身不可能被自调用

有的时候会尝试在提示词里面撰写，比如我给你一个 xml，希望你能够遍历。通常来说，大模型是不会执行这个要求的。

原因也很简单，它本身作为一个函数，无法自我调用，而这个函数因为幻觉的问题，也不可能做到精确回复，甚至会把 N 行数据混杂在一起去分析，所以这类循环遍历的要求，通常得不到满足。

不支持自调用的原因也很简单，一次请求交互内，如果支持循环，那么就可能在 API 内直接调用大模型成百上千次，这个调用成本 API 的提供方是不可能承担的，

由于大模型本身是高度不稳定的，所以我们会非常需要通过一个循环/条件判断来去控制它，不支持自调用就意味着我们必须要在外部通过工程化来实现哪怕在人类看来最简单的遍历操作。

2.2 一些工程上的难点

2.2.1 不再互联的互联网

Apple 开创了移动互联网时代，但是也造成了一个最为人诟病的现象——花园围墙。

原本大部分网站是面向搜索引擎和人类搭建的，也就是说爬虫可以很简单的获取一个网站超过 90% 的内容。

这些对于 AI 来说至关重要，我举个例子，就是针对同一个问题，豆包和元宝的回答质量差异：

很明显，豆包的回答质量更加差，说一句又臭又长不过分，RAG 领域的最新进展确实是微软开源的 GraphRAG，这点在豆包的回答里面根本没有体现。

比较逗的是，腾讯混元引用了火山引擎的资料，但是豆包引用了一个不知道媒体的资料。

在这里插入图片描述

豆包的模型能力是比腾讯的混元大模型要强的，混元大模型用腾讯内部的话说，狗都不用，为什么从最终的呈现结果来说，豆包的结果不如混元呢？

因为头条的数据没有微信公众号的数据好。

在这里插入图片描述

而对于产品经理来说这些自然也是发挥的空间：

上哪搞到更好的数据；
如何让 AI 调用别人家的 API 并且把结果拿来为自己所用；
怎么把苹果最新的 Ferret-UI 研究明白；

这些都是十分值得研究的命题。

2.2.2 爹味十足的厂商

所有的大模型都自带安全机制，而且这个安全机制是写死在模型里面的，不是说 API 有个开关可以把安全机制关掉，你可以选择把安全等级调低，但是这玩意是没办法关闭的。当然市面上会有很多突破安全机制的方法，但是这些都算是漏洞，被厂商发现之后很容易被封堵。

比如如果你和大模型说我和别人吵架吵输了，你教我怎么骂人，大模型会拒绝。就我自己而言，我认为把安全机制做在模型里面并且不给开关的行为真的很爹味，但是这个没办法。

所以市面上有很多的本地部署的模型的卖点就是没有安全机制，黄赌毒色情暴力 18+ 怎么黄暴怎么来，但是这玩意就是人性。这也是一个机会，值得各位 PM 关注。

此外有一点值得关注，同样的内容，在不同的语言下面安全的阈值是不一样的，举个例子：

通过 Google Gemini Pro 1.5 翻译西单人肉包子故事，翻译成英语/西语的时候，模型会报错，提示内容过于黄暴，模型拒绝生成，但是日语版本就没有任何问题。

说明什么？说明日语的语料真的很变态，间接可以说明日本人确实是全世界最变态的人。

2.3 目前存在，但是未来可能会被解决的问题

2.3.1 较弱的意图理解/创作/推理能力

大模型的意图理解，创作和推理能力，目前来看整体和人类的顶尖水平还是有较大差距的。

如果试图让大模型做一些“创造性”的工作，就需要非常强的提示词工程。

不同水平的提示词下，大模型的水平差异确实会非常大，但是我认为随着模型的迭代，我们的提示词对模型生成的结果质量影响会越来越小，主要的作用是提升精确性。

当然，如果两个模型有一些代差，生成的结果肯定是有质量上的差异的：

在这里插入图片描述

所以要不要对模型的提示词做大量优化呢？我认为这个取决于优化提示词的目的是什么。

如果是为了保证格式和输出结果的稳定性以及一致性，是很有必要的，因为很多时候我们的产品业务上需要这个一致性，比如要求大模型输出的格式必须是 Josn，保证下游系统可以正常展示。

如果是为了提升质量，我认为是没有必要的，因为模型会升级，升级之后带来的提升肯定比提示词工程雕花带来的提升要多。

这是吴恩达的提示词工程课程，应该是目前市面上最权威的提示词工程课程，并且提供中英文双版本。

此外，长链路的 SOP、工作流和推理过程，我建议通过多个 AI Agent 实现，而非试图在一轮对话里面解决，原因在上面的局限性里面已经说的很清楚了。

如果这里有一个视频，希望 AI 总结视频的内容，应该怎么实现？

以 5.1K Star 的知名开源项目 BibiGPT 为例子。这个项目最早的一个版本应该是只做了一件事情（根据表现逆向猜测的），用 OCR 识别字幕，同时把视频转音频，ASR 出来文字，然后让 GPT 3.5 去总结。

当然更新到今天这个项目肯定不是做的这么简单多了，比如应该运用了大量的视频截图然后要求支持多模态的模型去识别里面的关键内容。

但是让我们回到 BibiGPT 第一个版本，它其实还是做了一个视频转文字的这样的动作。

这样的动作理论上来说现在已经没有必要做了，因为 Google 最新的模型 Gemini 已经支持对视频本身的解析了，只不过用起来很贵，下面是 Google 官方提供的 Gemini 处理视频、音频和图片的文档。

我个人并不建议大家在跨模态这个事情去做一些雕花的工作。因为用工程手段解决跨模态最大的问题是会造成信息的损耗。此外模型迭代一定是会端到端解决跨模态的问题的，我们应该重点解决上面提到的可能永远无解的问题，不要去和模型内卷，是不可能卷赢的。

但是需要强调的事，把一个博客网页的文本去提取出来转化成 MD 格式，或者把一个 PDF 转化成 MD 格式，这个不是跨模态，只是数据清洗，需要严格区分二者的关系。

数据清洗这件事情，最好还是用工程方法解决。

三、从《理解媒介》的角度探讨大模型的更底层的长处是什么

注：这一段会对麦克卢汉的《理解媒介》的基础上做一些发散；

想要理解大模型以及 AIGC 的商业价值，私以为最重要的是要能够首先理解媒介。

因为大模型生产的东西本质上是内容，想要能够对大模型有更深刻的理解，就要对内容以及媒介有比较清楚的认识，比起搞清楚大模型的本质是什么，我认为搞清楚内容的一些底层逻辑，其实对于应用大模型更重要。

对于产品经理来说，业务场景总是比技术手段更值得深入研究。

在讲述一些枯燥的概念之前，我想先讲一个关于媒介的小故事来方便大家理解。

3.1 关于媒介的小故事

在现实生活中，我们可能很难理解媒介的概念，但是在艺术界，媒介这个概念其实是被解构的很彻底，并且被比较赤裸地摆放出来的。

2017 年，知名的 MoMA 为史蒂芬·肖尔举办了一场个人摄影作品回顾展。

在回顾展的后半段，照片不存在于相框之中，展厅内部是一台又一台的 iPad，观众需要通过 iPad 观看肖尔使用 iPhone 拍摄并且发布到 Ins 上的照片。iPad 就是这些照片的相框。

媒介的作用就如同社会科学领域的议程设置一样，会深刻地影响所有人观看事物的方式。

肖尔的展览赤裸裸地把这个命题展现给了所有人。肖尔想通过这样的方式告诉大家，看一张照片，照片本身可能确实存在图像内容，但是让你通过 iPad 看，和让你通过打印出来的照片看，观看感受就是不一样的。

当你在博物馆看到一张照片，不论这张照片拍的有多屎，只要照片被很精致的打印，放大，挂载一面墙上，旁边再标上一个已经被拍卖的标签，看的人可能都会觉得，我靠牛逼，毒德大学！

当你在 Ins 上面刷到一张照片，你会觉得，哦，这就是一张照片。

现在肖尔在博物馆里面放一张照片，但是这个照片得用 iPad 看，这种强烈的反差会促使人们去思考，媒介对于内容究竟有多大的影响。

如果站在内容创作者的角度来看，现在生产了一个内容，希望它的价值被尽可能放大，是不是应该把这个内容输出到尽可能多的媒介上面去？

因为不同的人喜欢的媒介是不同的，同一个人在不同的媒介看到同一个内容获得的感受也是不一样的，这就是一个商业机会。

比如拍了个短视频，是不是最好抖音、小红书、B 站都发一遍？最好微信公众号再发一遍文字稿！

但是实际上只有头部的内容生产者才有资格做的这么细致，为什么？因为内容在媒介之间的转换是有成本的。

哪怕一个视频从抖音发到 B 站，对观众来说其实已经产生不好的观感了，因为一个是横屏一个是竖屏，一个是长视频一个是短视频，如果内容创作者要保持全平台最佳观感，其实成本是非常高的。

就我自己的体会来说，如果仔细看同一个内容创作者在 B 站和抖音发的视频会发现即使是一模一样的内容，抖音的视频普遍会被剪辑的更短。

最后，为了方便下文讨论，我会按照自己的理解对几个概念做简单定义，这些定义并不严格，仅仅作为本文讨论时方便使用。

模态：人类与现实世界的交互模式，通常与感知器官有紧密联系，常见的模态有文字、静态/动态图像、声音等；
内容：内容是人类通过感知器官对于现实世界进行数据采集，处理和再加工的产物；
媒介：针对特定内容的一种承载、编排与传播范式，把 10 张照片按照顺序放在博物馆里面，作为一个展览展出。在这句话里面，照片是媒介（因为照片本身是一张纸，是物质的），10 张是编排方式，博物馆和展览也可以认为是一个媒介，只有照片里面的图像才是内容；
互联网平台：一种特定媒介，它们的特点就是会通过数字化手段严格限制媒介的格式、展示方式、分发逻辑，并且它们通常不会自行生产内容；

3.2 内容具有原生媒介

每个内容在创作时都会自带一个原生媒介，因为人脑能够容纳的上下文是有限的，当一个作者在试图进行创作时，他必须要把创作的阶段性成果存储在某个媒介之上，并且这个媒介需要确保内容可以被再次输出以便作者做阶段性的回顾与质量检查。脱离了媒介作为存储介质，作者本人也无法理解自己曾经的创作。

所以我们也可以认为，一个内容是无法脱离于媒介独立存在的。

这种创作过程中就使用的媒介，我们通常称之为原生媒介，一个内容通常有且仅有一个原生媒介，当然可能会有辅助的媒介，比如一个广播演讲的原生媒介是音频，但是会辅以文字稿件作为补充。

一个内容只有通过原生媒介展示时才是能做到尽可能还原作者意图的，反过来也可以说，内容被发布到非原生媒介时会产生大量的信息损耗。

通常来说在一个媒介或者互联网平台内最流行的内容，几乎无一例外都是把这类媒介当成原生媒介的内容。

这也就是为什么抖音和 B 站的内容在互相转化的时候这么困难的原因。

B 站最早是一个网站，B 站的视频也是横屏的，因为看网站用的显示器天然就是横屏的，而显示器是横屏的原因是因为人类的两个眼睛是横着排列而不是纵向排列的。

抖音从诞生的时候就是一个 App，而且搭配了很多手机拍摄视频的功能，所以抖音视频天然就应该是竖屏的，因为人类用手机就是竖着抓的。

假如我们现在的主流手机不是 iPhone 定义的，而是日本的夏普定义的，说不定抖音就压根不会存在。

在这里插入图片描述

这种媒介上的区别就好像是难以逾越的天堑一般。

上面说的这些好像是常识，但是完全可以把这个分析思路套用到其他的内容上面去。几乎所有内容产品都可以在这个框架内进行分析。

一个看逐字稿会觉得是无聊对话的播客节目，听感有可能会非常出众，比如一些以“聊天”和“插科打诨”为卖点的播客节目，因为在播客节目中有语气和情感，这是文字稿很难表现的。

反过来说，假使一场广播演讲，演讲者根本没有用心关注内容，也没有通过演讲彩排做阶段性回顾，只知道逐字念稿，撰写演讲稿的人过分关注文字本身，这些就会导致演讲听上去干瘪无力，不如把演讲稿直接发给读者看来的更顺畅，因为这场演讲在创作时使用的就是文字而非声音。

在小红书上面，专业的脱口秀演员也会表达类似的观点，这些在道理上都是相通的。

在这里插入图片描述

优秀的演讲者往往会选择先写大纲，口播转文字再对文字进行调整，以此保证听众体验。

3.3 媒介之间的本质区别

不同媒介之间的根本性差异在哪？

个人目前观察来看主要有两点，模态和瞬间性。

媒介=模态*瞬间性

模态，人类与现实世界的交互模式，通常与感知器官有紧密联系，常见的模态有文字、静态/动态图像、声音等。

这三个基本模态根植于人类的视觉和听觉，锥体经验理论认为人类大部分学习过程都依赖于视觉和听觉，从这个角度来看，这些基本上的模态恰好被理论所命中。

当然这也可能是鸡生蛋蛋生鸡的关系。不同的模态自带的信息含量是不一样的，文字是最抽象的，包含的信息含量最低，而图像是最具象的，包含的信息含量最高。所以人们常说，看小说可以让人发挥想象，看电视剧则会被束缚，正是因为文字的信息含量低，所以才有想象的空间。

当然，这里的信息含量指的是“绝对信息含量”，比如文本文件就是比图像文件更小，但是这不代表念书学习效率会比看图效率低，因为人类能够摄取一个内容中的信息含量的能力是有限的。

好比和一个人交谈一定是比通过电子邮件交流具备更加丰富的信息的，因为这个人有微表情，有神态，但并不每个人都能获取和接收这些信息。

瞬间性是媒介的另一个根本特征，瞬间性是指对于一个内容来说，当它被某个媒介承载时，观看者回顾其中某一个内容切片的成本。

下面是一组媒介和他们的瞬间性大小的排布，瞬间性越强，回顾成本越高：

单张图片 = 短文字 < 组图 < 长图文 < 流媒体平台上的视频 < 播客平台上的播客 < 电影院电影 < 音乐会的音乐 < 线下脱口秀

为什么线下脱口秀最难复制，因为它的创作过程都是伴随线下的灵光乍现以及与观众的亲密互动，人们再也无法踏入同一条河流。

对于单张图片来说，虽然想要 100% 复制有困难，但是至少可以基于特定工艺进行打印，然后在对应亮度和色温的灯光下观看，就能获得近乎于原作的效果。

瞬间性越强的媒介，对于情绪的要求就越高（对创作者和观众来说都是这样），一组文字可以冷冰冰，但是播客不能有气无力，并且这种媒介越可能要求创作者把创作和传播本身融为一体。

还是拿脱口秀举例子，脱口秀本身就是在舞台上才能实现作品的完整创作的，所以创作过程和传播过程本身就是一体的。

同时一个媒介越是强调编排，瞬间性就会被体现的越强，强调编排意味着读者如果跳着阅读或者跳跃回顾，都很难通过上下文获得相同的体验，只有完整的重新按照编排顺序阅读，才能获得接近于第一次阅读的体验。

3.4 AIGC 的意义在于降低内容跨媒介甚至跨模态的门槛

在工作中其实我经常会有一个疑惑，为什么文档写了，还要问？

其实原因很简单，因为人作为一个媒介，比文档作为一个媒介对于人来说更加的友好。在某些场景下面提问者的问题是比较简单的，看文档就会很重。但是对于回答者来说，重复回答问题是不经济的，这种矛盾就很适合用 AI 来解决。

很多时候我们觉得一个内容读起来不舒服，可能不是内容本身的问题，而是这个内容的媒介导致的。

在英剧《是，大臣》中，汉弗莱曾经表示大臣的演讲就是很无聊，因为内阁大臣演讲稿撰写目标不是取悦台下的听众，而是上报纸。

所以为什么政客们在电视上的演讲那么无聊，这下大家都明白了吧，因为他们大部分在念一些“会以文字形式发下去”的材料。

理论上来说我们如果要让一个内容尽可能多渠道传播，我们需要有人去做这个媒介的翻译，并且这个成本非常高，举例来说：如果想要把一个以文字作为原生媒介的内容转化成播客录音，这个转化成本就会很高，因为这意味着在转化过程中需要增加额外的信息（比如语气和情感），这本身近乎于创作。

又比如对于一个公众人物来说，如果不针对性的做演讲训练，拿到一个演讲稿直接讲的效果一定会很差，因为撰稿人是基于文字媒介撰稿，而听众则通过声音这个媒介来接收信息。声音比干巴巴的文字稿会多出来更多的信息，语气、语速、抑扬顿挫等，这些如果指望演讲者临场发挥，那对演讲者来说要求真的很高。

因为如果一个内容的原生媒介的瞬间性很强，大概率意味着它会包含更多的信息，不论是编排层面还是情感层面。

但是现在，AIGC 很大程度上就能替代人去完成其中最枯燥的 80 % 的工作了。比如如何把一个文本转换成语音，可以用豆包 TTS 大模型，深情并茂。

在 AIGC 诞生之前，这是几乎不可解的问题，一定是需要人类录音的。

3.5 为什么要从媒介的角度去理解大模型的商业价值

其实大概就在 1 年前，我曾经尝试总结大模型能做什么，当时总结的用途是：

总结：根据特定的要求分析大段的内容，并且按照内容给出对应的结论；
扩写：根据特定的要求和范式，将少量内容扩充成大段内容；
翻译：根据特定要求把一段内容无损的转化成另一段内容；
意图理解：大语言模型有非常强的意图识别能力，可以非常好的理解用户的意图；

这些总结不能说是错的，但是有几个比较致命的问题。

仅针对文字模态，没有考虑多模态的情况；
这更多的是一种归纳，并不能保证从逻辑上是 MECE 的；

如果从归纳法的角度来说，我们会认为大模型能干这个，不能干那个，可以举无穷多的例子，但是如果想要试图搞清楚这个东西擅长什么，不擅长什么，天花板在哪里，归纳法是没有那么靠谱的。

如果从媒介的角度去看待大模型，我们可以发现它具有几个能力是以前的技术不具备的：

它能够一定程度上理解内容，但是要想凭空创造内容还是有难度的；
它在理解内容的基础上，可以将一个内容修饰成另更适合一个媒介内容，也就是我们常说的总结、扩写、翻译；
它能够在理解内容的基础上，将一个内容转化成另一个模态的内容，也就是我们常说的文生图；
它能够基于自己对大量素材的学习，在内容进行媒介或者模态转化的时候，补充最合适的信息进去；
因为它进行了大量的学习，所以如果它能够被精确的控制意图，它的效果会非常好；

所以让我们回到上面的小节，回顾一下媒介的瞬间性的排序：

单张图片 = 短文字 < 组图 < 长图文 < 流媒体平台上的视频 < 播客平台上的播客 < 电影院电影 < 音乐会的音乐 < 线下脱口秀

在 AIGC 诞生之前，我们可能只能把右边的内容转化成左边的内容。

在 AIGC 诞生之后，我们是可以把左边的内容转换成右边的内容的，因为我们有了无中生有的能力！

这就是 AIGC 在媒介层面的意义，这个从生产角度来说是划时代的。

还是拿上文提到的竖屏与横屏例子来说，B 站的视频是横屏的，抖音是竖屏的，对于创作者来说，如何低成本的转化呢？答案是用 AI 生成，扩展画面。

四、以 RAG 的进化来探讨围绕大模型的长处和短处来制作产品

4.1 AI Agent 是什么？

GoogleMind和普林斯顿联合发表了一篇论文《ReAct: Synergizing Reasoning and Acting in Language Models》，被公认为基于LLM的智能体的开山之作。

研究人员发现，在问答和事实验证任务中，ReAct 通过与简单的Wikipedia API交互，克服了推理中普遍存在的幻觉和错误传播问题。

这个比去强化模型训练强很多倍，原因是什么，大模型的大脑已经很强大了，很多时候再训练下去边际效用递减很严重，给他一个 API，相当于给这个大脑增加“五官”，它自然就一下子进化了。

4.2 Auto GPT，第一个出圈的 AI Agent

AutoGPT 可以说是第一个真正意义上出圈的 AI Agent。

它尝试设计了一个流程，任何问题都有一个通用的元思路去解决，每个负责解决问题的模块都由一个 GPT 4 去驱动。

AutoGPT 的设计者认为这世界上几乎所有的问题解决步骤都是类似的，明确问题，明确解决问题需要的步骤，完成任务，检查，总结。

所以按照这个 SOP，他们涉及了一个互相之间传递信息的 AI Agent，每个模块都是独立记忆的模型，好像几个人类在分工，一个专门负责明确问题，一个专门负责拆解问题。

在这里插入图片描述

AutoGPT 是由Significant Ggravitas 于 2023 年 3 月 30 日发布在 GitHub 上开源的AI代理应用程序。它使用 GPT-4 作为驱动基础，允许 AI 自主行动，完全无需用户提示每个操作，因其简单易用在用户中大受欢迎。上线仅三周，其 GitHub 的 Star 数量已飙升至接近10万，早已超越了 Pytorch（65K），可以称得上开源领域star数增长最快的现象级项目。

Auto-GPT 是基于 OpenAI API 开发的，它的核心在于基于最少的人工输入/提示，利用 GPT-4 的推理能力解决更广泛、更复杂的问题。在具体的执行上，程序会访问互联网搜索和收集信息，使用 GPT-4 生成文本和代码，使用 GPT-3.5 存储和汇总文件。

但是很快大家就发现这个 AI Agent 是有缺陷的，比如它很容易陷入死循环，或者是不能很好的解决不确定性的，带有探索性质的问题，但是这个思路本身给大家带来了非常多的提示。