两万字讲清楚：怎么成为一个“懂”AI的产品司理？

优异的 AI 产品，离不开好的大模型。但 API 仅仅第一步，真实面向用户的是产品。

从 API 到产品，中心的工程转化进程很少被人提起，而这，正是 AI 产品司理真实需求重视和聚集的当地。

本文作者汐笺是一位产品司理，这篇两万字的长文，叙述了作为一个 PM，继续重视的大模型约束性、利益和其间的时机。

一些有意思的点：

• 比起大模型产品，产品司理更应该重视大模型自身（API）。

• 把 AI 和移动互联网类比，是不恰当的。而且，不是每一个 App 都值得用 AI 重做一遍，考虑一遍就会发现，值得重做的只要 10%。

• 产品司理要学会自己调用 API。未来 AI 产品团队的才干，不取决于谁家模型更强（横竖开源模型必定终究会变得最强），而取决于谁能用好 AI 模型。

• 大模型底层利益，在于跨过不同的内容前言，乃至跨模态。经过 AIGC，不需求人力，低门槛将文本转换为录音，图片扩展为视频，到达“惹是生非”的境地。

• 站在微观视点，不难发现大模型的约束十分多：高本钱、上下文长度、错觉、数据壁垒、厂商安全机制、待提高准确度的创造……这些空间，也诞生着产品前进和晋级的时机。

作者注：本文成文于 2024 年 9 月 1 日，跟着时刻推移，文章中的定论或许会产生变化。此外，本文面向的读者对错算法团队的产品司理，为了确保文章的可读性，或许会省掉部分细节，一起文章要点是工程落地而非学术探讨，不具有任何辩经的价值。

一、比起大模型产品，要更重视 API

坦率来说，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. 从更底层的事务视点去剖析，大模型在商业意义上真实的价值在哪？

留意：这儿着重的是事务视角，不是让产品司理去读论文。

二、大模型或许永久都无法处理的问题

1. 本钱、功能与响应速度

本钱、功能与响应速度难以处理。想要寻求功能越强的大模型，就越需求越高的核算本钱。核算本钱会带来两个问题：

• 直接形成的金钱本钱；

• 响应速度；

下图是 Apple Intelligence 的架构图，其间在端上有两个模型，而在云端还有一个依据隐私云核算的大模型。

为什么苹果要做这种工程上巨细模型的规划？

由于苹果期望大模型的响应速度能够追上 Siri 现在的功能，一起移动设备对功耗自身是有要求的，再加上苹果十分重视隐私，期望 80% 的问题能够在用户本地得到处理，所以采用了这样的架构。运转 meta 最新开源的 llama 3.1，70 b 版别需求大约 70 GB 的显存，405 b 版别或许需求 400 GB 的显存，或许需求并联 100 台 iPhone 才干运转这些模型。

这种巨细模型的规划，需不需求产品司理，当然需求，什么问题合适小模型处理，什么问题合适大模型处理，这显着不仅仅是 RD 需求去答复的，也需求有产品司理参加，担任如下部分：

• 搜集现在用户的 Query；

• 从处理难度、隐私、对时效性的要求、对准确性的要求对 Query 进行分类；

• 规划基准测验，取得巨细模型分界的规范；

• 继续追寻优化。

  
  

在未来至少很长一段时刻，仍是会有许多的本地/联网之争的，这个便是产品司理的时机。

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）并没有发布任何的论文或许更实践的东西。仍是那句话，最大窗口和有用作业窗口是两个概念。此外，多模态的开展某种视点来说会加重窗口巨细缺乏的问题。

3. 函数自身不或许被自调用

有的时分会测验在提示词里边编撰，比方我给你一个 xml，期望你能够遍历。一般来说，大模型是不会履行这个要求的。原因很简略，它自身作为一个函数，无法自我调用，而这个函数由于错觉的问题，也不或许做到准确回复，乃至会把 N 行数据稠浊在一起去剖析，所以这类循环遍历的要求，一般得不到满意。

不支撑自调用的原因也很简略，一次恳求交互内，假如支撑循环，那么就或许在 API 内直接调用大模型成百上千次，这个调用本钱 API 的供给方是不或许承当的，由于大模型自身是高度不稳定的，所以咱们会十分需求经过一个循环/条件判别往来不断操控它。

不支撑自调用就意味着，咱们有必要要在外部经过工程化来完成哪怕在人类看来最简略的遍历操作。

三、大模型现在工程上的难点

在工程上有两个难点，别离是数据问题和厂商设置的安全机制问题。

首要，Apple 创始了移动互联网年代，可是也形成了一个最为人诟病的现象——花园围墙。

本来大部分网站是面向查找引擎和人类树立的，也便是说爬虫能够很简略地获取一个网站逾越 90% 的内容。到了移动互联网年代，网站是能够树立数据壁垒的，而数据关于 AI 来说至关重要。

举个比方，针对同一个问题，豆包的答复质量显着比混元更差，说一句又臭又长不过火（RAG 范畴的最新进展的确是微软开源的 GraphRAG，这点在豆包的答复里边底子没有体现）。

比较逗的是，腾讯混元引用了火山引擎的材料，可是豆包引用了一个不知道什么野鸡媒体的材料。

豆包的模型才干是比腾讯的混元大模型要强的，（混元大模型用腾讯内部的话说，狗都不必），但为什么从终究的出现成果来说，豆包的成果不如混元呢？

由于豆包用的头条数据没有腾讯微信大众号的数据好。

为了处理互联网不再互联的问题，Apple 期望从操作体系层面把 UI 打造的面向大模型更友爱，而且发布了一篇名为《Ferret-UI：依据多模态大言语模型的移动 UI 了解》的论文，可是我觉得愈加敞开的 API 和内容才是底子途径，由于苹果的互联互通是仅限于 iOS 生态的。

而关于产品司理来说这些天然也是发挥的空间：

• 上哪搞到更好的数据；

• 怎样让 AI 调用他人家的 API 而且把成果拿来为自己所用；

• 怎样把苹果最新的 Ferret-UI 研讨了解；

这些都是十分值得研讨的出题。

其次，一切的大模型都自带安全机制。爹味十足。

这个安全机制是写死在模型里边的，不是说 API 有个开关能够把安全机制关掉，你能够挑选把安全等级调低，可是这玩意是没办法封闭的。

市道上仍是有许多打破安全机制的办法，可是这些都算是缝隙，被厂商发现之后很简略被封堵。

比方，你和大模型说我和他人吵架吵输了，你教我怎样谩骂，大模型会回绝。就我自己而言，我以为把安全机制做在模型里边而且不给开关的行为真的很爹味，可是这个没办法。

所以市道上有许多的本地布置的模型的卖点便是没有安全机制，黄赌毒色情暴力 18+，怎样黄暴怎样来。这也是一个时机，值得各位 PM 重视。

此外有一点值得重视——相同的内容，在不同的言语下面安全的阈值是不相同的。

举个比方：经过 Google Gemini Pro 1.5 翻译西单人肉包子故事，翻译成英语/西语的时分，模型会报错，提示内容过于黄暴，模型回绝生成，可是日语版别就没有任何问题。

阐明什么？阐明日语的语料真的很反常，直接能够阐明日本人的确是全世界最反常的人。

四、大模型未来或许会被处理的问题

1. 较弱的意图了解/创造/推理才干

大模型的意图了解，创造和推理才干，现在来看全体和人类的顶尖水平仍是有较大距离的，但未来或许能够进一步处理。

假如企图让大模型做一些“创造性”的作业，就需求十分强的提示词工程。不同水平的提示词下，大模型的水平差异的确会十分大。

不过我以为跟着模型的迭代，咱们的提示词对模型生成的成果质量影响会越来越小，首要的效果是提高准确性。

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

所以要不要对模型的提示词做许多优化呢？

我以为这个取决于优化提示词的意图是什么。假如是为了确保格局和输出成果的稳定性以及一致性，是很有必要的。许多时分咱们的产品事务上需求这个一致性，比方要求大模型输出的格局有必要是 Josn，确保下流体系能够正常展示。

假如是为了提高质量，我以为是没有必要的。由于模型会晋级，晋级之后带来的提高必定比提示词工程雕花带来的提高要多。

吴恩达的提示词工程课程，应该是现在市道上最威望的提示词工程课程，而且供给中英文双版别。

此外，长链路的 SOP、作业流和推理进程，我主张经过多个 AI Agent 完成，而非企图在一轮对话里边处理，原因在上下文约束性那部分现已说的很清楚了。

2. 跨模态数据读取/生成才干

假如这儿有一个视频，期望 AI 总结视频的内容，应该怎样完成？

以 5.1K Star 的闻名开源项目 BibiGPT 为比方。这个项目最早的一个版别应该是只做了一件作业（依据体现逆向猜想的），用 OCR 辨认字幕，一起把视频转音频，ASR 出来文字，然后让 GPT 3.5 去总结。

当然更新到今日这个项目必定不是做得这么简略多了，比方应该运用了许多的视频截图然后要求支撑多模态的模型去辨认里边的要害内容。

可是让咱们回到 BibiGPT 第一个版别，它其实仍是做了一个视频转文字的这样的动作。

这样的动作理论上来说现在现已没有必要做了，由于 Google 最新的模型 Gemini 现已支撑对视频自身的解析了，只不过用起来很贵。（ Google 官方供给的 Gemini 处理视频、音频和图片的文档。）

我个人并不主张咱们在跨模态这个作业去做一些雕花的作业。由于用工程手法处理跨模态最大的问题是会形成信息的损耗。此外模型迭代必定是会端到端处理跨模态的问题的，咱们应该要点处理上面说到的或许永久无解的问题。不要去和模型内卷，是不或许卷赢的。

需求着重的是，把一个博客网页的文本去提取出来转化成 MD 格局，或许把一个 PDF 转化成 MD 格局，这个不是跨模态，仅仅数据清洗，需求严厉差异二者的联系。

数据清洗这件作业，最好仍是用工程办法处理。

五、从 RAG 视点了解大模型产品 

1. RAG 和 AutoGPT 的差异

GoogleMind 和普林斯顿联合宣布了一篇论文《ReAct: Synergizing Reasoning and Acting in Language Models》，被公以为依据 LLM 的智能体的开山之作。

研讨人员发现，在问答和现实验证使命中，ReAct 经过与简略的 Wikipedia API交互，克服了推理中普遍存在的错觉和过错传达问题。

这个比去强化模型练习强许多倍，原因是什么？大模型的大脑现已很强壮了，许多时分再练习下去边沿功效递减很严峻，给他一个 API，相当于给这个大脑添加“五官”，它天然就一会儿进化了。

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 是有缺点的，比方它很简略堕入死循环，或许是不能很好地处理不确定性的，带有探究性质的问题，可是这个思路自身给咱们带来了十分多的提示。（Auto GPT 作业原理：https://www.leewayhertz.com/autogpt）

RAG 是检索+生成的缩写，能够被视为是一种针对特定事务场景的 AI Agent。它的首要效果便是从特定的当地检索出来信息，然后再以愈加友爱的办法展示出来。

假如一个产品有十几篇阐明文档，那么 RAG 就如同是一个熟读了文档的客服。最简略的 RAG 能够参阅 AI 查找引擎 ThinkAny 第一版的原理。

MVP 版别完成起来很简略，运用 NextJs 做全栈开发，一个界面 + 两个接口。两个接口别离是：

1. /api/rag-search：这个接口调用 serper.dev 的接口，获取谷歌的检索内容。输入用户的查询 query，输出谷歌查找的前 10 条信息源。

2. /api/chat：这个接口挑选 OpenAI 的 gpt-3.5-turbo 作为基座模型，把上一步回来的 10 条检索成果的 title + snippet 拼接成上下文，设置提示词，恳求大模型做问答输出。

它和 AutoGPT 最