1、理解 AI 产品的工程化
现阶段的大模型有哪些局限性,这些局限性哪些是可以通过模型迭代得到解决的,哪些是不能的。
从更底层的业务角度去分析,大模型在商业意义上真正的价值在哪?注意,这里强调的是业务视角,不是让产品经理去读论文。
2、大模型的局限性是什么?
2.1、一些可能永远都无法被解决的问题
2.1.1、成本、性能与响应速度
直接造成的金钱成本;
响应速度;
收集目前用户的 Query;
从解决难度、隐私、对时效性的要求、对准确性的要求对 Query 进行分类;
设计基准测试,获得大小模型分界的标准;
持续追踪优化;
2.1.2、窗口大小与不稳定
研究能否把长文本切成多个段文本,并且不影响最终的结果;
研究怎么给 AI 外挂一些能够超长时间记忆的记忆库;
2.1.3、函数本身不可能被自调用
2.2、一些工程上的难点
2.2.1、不再互联的互联网
上哪搞到更好的数据;
如何让 AI 调用别人家的 API 并且把结果拿来为自己所用;
怎么把苹果最新的 Ferret-UI 研究明白;
2.2.2、爹味十足的厂商
2.3、目前存在,但是未来可能会被解决的问题
2.3.1、较弱的意图理解/创作/推理能力
2.3.2、跨模态数据读取/生成能力
3、从《理解媒介》的角度探讨大模型的更底层的长处是什么
3.1、关于媒介的小故事
模态:人类与现实世界的交互模式,通常与感知器官有紧密联系,常见的模态有文字、静态/动态图像、声音等;
内容:内容是人类通过感知器官对于现实世界进行数据采集,处理和再加工的产物;
媒介:针对特定内容的一种承载、编排与传播范式,把 10 张照片按照顺序放在博物馆里面,作为一个展览展出。在这句话里面,照片是媒介(因为照片本身是一张纸,是物质的),10 张是编排方式,博物馆和展览也可以认为是一个媒介,只有照片里面的图像才是内容;
互联网平台:一种特定媒介,它们的特点就是会通过数字化手段严格限制媒介的格式、展示方式、分发逻辑,并且它们通常不会自行生产内容;
3.2、内容具有原生媒介
3.3、媒介之间的本质区别
3.4、AIGC 的意义在于降低内容跨媒介甚至跨模态的门槛
3.5、为什么要从媒介的角度去理解大模型的商业价值
4、以 RAG 的进化来探讨围绕大模型的长处和短处来制作产品
4.1、AI Agent 是什么?
4.2、Auto GPT,第一个出圈的 AI Agent
4.3、RAG 和 AutoGPT 的区别
MVP 版本实现起来很简单,使用 NextJs
做全栈开发,一个界面 + 两个接口。两个接口分别是:
/api/rag-search
这个接口调用 serper.dev
的接口,获取谷歌的检索内容。输入用户的查询 query,输出谷歌搜索的前 10 条信息源。
/api/chat
这个接口选择 OpenAI 的 gpt-3.5-turbo
作为基座模型,把上一步返回的 10 条检索结果的 title + snippet 拼接成上下文,设置提示词,请求大模型做问答输出。以上文字引用自: https://mp.weixin.qq.com/s/25eXZi1QgGYIPpXeDzkQrg
RAG 的流程是一个串行流而不是一个循环,它没有所谓的自我检查然后重新生成的过程,一方面是为了响应速度,另一方面也是为了避免自我检查造成的死循环;
RAG 的流程中,是检索+生成,检索的部分并不是由大模型完成的,而是通过传统的搜索引擎(向量数据库、关键词匹配)来完成的,这和 AutoGPT 中几乎所有关键节点都是用 GPT 4 完成是有天壤之别的,这意味着大家意识到一个问题,在一些对上下文窗口有要求的,输出精确排序的场景,GPT 一点也不好用;
RAG 并不是万能的,它设计出来也不指望自己能解决所有问题,实际上它更多的是解决“如何快速给答案”这个问题,有 10 篇文档,怎么快速到找用户需要的答案;
4.4、RAG 的缺陷是什么?
4.5、Graph RAG — 一种 RAG 的进化版本
把待搜索的知识做向量化处理(可离线处理);
当用户提出来一个关键词 or 问题,根据相似性查询查出来最相关的内容(必须是在线服务);
将查询出来的 Top N 的相关内容作为上下文,和用户提出的问题一起交给大模型来生成内容(必须是在线服务);
将待搜索的知识进行一个三元组抽取(主谓宾),这个抽取的动作需要 LLM 介入,存入图数据库中(可离线处理);
将用户提出来的关键词,用 LLM 做一次扩散,扩散出来同义词,近义词等,然后在图数据库进行检索,找到相关文档(必须是在线服务);
将查询出来的相关内容作为上下文,和用户提出的问题一起交给大模型来生成内容(必须是在线服务);
4.6、RAG 再进化(雕花)
5、为什么我们曾经高估了大模型的影响力
5.1、我们原本设想的端到端的场景问题是什么?
看一下市面上热门视频的共性,往往依靠标签
根据热门标签生产一些脚本;
拍摄;
发到线上看数据反馈,再做迭代;
模型的上下文窗口限制
模型的成本太高
5.2、所有应用都值得用 AI 重做一遍吗?
5.3、LUI 是万能的吗?
5.4、复杂的 UI 是一段弯路吗?
5.5、大模型真正的价值是什么?
6、对产品经理的工作方法启示是什么?
6.1、业务!业务!业务!数据!数据!数据!
6.2、看论文不是产品经理避免 FOMO 的最佳途径,动手尝试可以避免 FOMO
6.3、产品经理必须要学会自己调用 API
6.4、几个 AI Agent 实践的建议
6.4.1、设计 Agent 的关键思路
能执行
无法拆解复杂问题
执行顺序可能是有问题的,你如果不规定执行顺序,会怎么样?可能会拖慢项目进度
记忆力一般,一下子太多任务记不住,可能会忘记
可能会出错,所以最好有交叉验证
6.4.2、把任务拆小拆细,避免互相影响
6.4.3、区分离线任务和在线任务
将待搜索的知识进行一个三元组抽取(主谓宾),这个抽取的动作需要 LLM 介入,存入图数据库中(可离线处理);
将用户提出来的关键词,用 LLM 做一次扩散,扩散出来同义词,近义词等,然后在图数据库进行检索,找到相关文档(必须是在线服务);
将查询出来的相关内容作为上下文,和用户提出的问题一起交给大模型来生成内容(必须是在线服务);
6.4.4、每一个离线任务都可以考虑用模型来解决
6.4.5、成本和效果要做 Trade off
6.4.6、Agent、微调、提示词之间的边界与最佳实践
提示词工程相当于你在布置任务的时候说的很详细。
Agent 建设相当于你给这个人布置任务的时候,把 SOP 拆清楚,并且告诉他公司里面有哪些工具可以用。
模型微调相当于做培训。
这个团队有没有牛逼的基准测试参考答案;
这个团队能不能有一个平台可以更快的验证自己的设计是不是合理的;