AI Agent 应该更有趣还是更有用?

据统计之都4月2日报道,非常荣幸来到科大校友会 AI 沙龙分享一些我对 AI Agent 的思考。我是 1000(2010 级理科实验班)的李博杰,2014-2019 年在中科大和微软亚洲研究院读联合培养博士,2019-2023 年是华为首届天才少年,如今我跟一批科大校友一起在做 AI Agent 领域的创业。

今天是汤晓鸥教授的头七,因此我特别把今天的 PPT 调成了黑色背景,这也是我第一次用黑色背景的 PPT 做报告。我也希望随着 AI 技术的发展,未来每个人都可以有自己的数字分身,实现灵魂在数字世界中的永生,在这个世界里生命不再有限,也就不再有分离的悲伤。

AI:有趣和有用

AI 的发展目前一直有两个方向,一个是有趣的 AI,也就是更像人的 AI,另外一个方向就是更有用的 AI,也就是更像工具的 AI。

AI 应该更像人还是更像工具呢?其实是有很多争议的。比如说 OpenAI 的 CEO Sam Altman 就说,AI 应该是一个工具,它不应该是一个生命。而很多科幻电影里的 AI 其实更像人,比如说 Her 里面的 Samantha,还有《流浪地球 2》里面的图丫丫,黑镜里面的 Ash,所以我们希望能把这些科幻中的场景带到现实。只有少数科幻电影里面的 AI 是工具向的,比如《钢铁侠》里面的贾维斯。

除了有趣和有用这个水平方向的之外,还有另外一个上下的维度,就是快思考和慢思考。这是一个神经科学的概念,出自一本书《思考,快与慢》,它里面就说人的思考可以分为快思考和慢思考。

所谓的快思考就是不需要过脑子的基础视觉、听觉等感知能力和说话等表达能力,像 ChatGPT、stable diffusion 这种一问一答、解决特定问题的 AI 可以认为是一种工具向的快思考,你不问它问题的时候,它不会主动去找你。而 Character AI、Inflection Pi 和 Talkie(星野)这些 AI Agent 产品都是模拟一个人或者动漫游戏角色的对话,但这些对话不涉及复杂任务的解决,也没有长期记忆,因此只能用来闲聊,没法像 Her 里面的 Samantha 那样帮忙解决生活和工作中的问题。

慢思考就是有状态的复杂思考,也就是说如何去规划和解决一个复杂的问题,先做什么、后做什么。比如 MetaGPT 写代码是模拟一个软件开发团队的分工合作,AutoGPT 是把一个复杂任务拆分成很多个阶段来一步步完成,虽然这些系统在实用中还有很多问题,但已经是一个具备慢思考能力的雏形了。

遗憾的是,现有产品中几乎没有在第一象限,兼具慢思考和类人属性的 AI Agent。斯坦福 AI 小镇是个不错的学术界尝试,但斯坦福 AI 小镇里面没有真人的交互,而且 AI Agent 一天的作息时间表都是事先排好的,因此并不是很有趣。

有趣的是,科幻电影里面的 AI 其实大部分是在这个第一象限。因此这就是目前 AI Agent 和人类梦想之间的差距。因此我们在做的事情跟 Sam Altman 说的正好相反,我们希望让 AI 更像人,同时又具备慢思考的能力,最终演进成一个数字生命。

今天大家都在讲 AGI 的故事,AGI 就是通用人工智能。什么是 AGI 呢?我觉得它又需要有趣,又需要有用。

有趣的方面,就是它需要能够有自主思考的能力、有自己的个性和感情。而有用的方面,就是 AI 能够解决工作、生活中的问题。现在的 AI 要么是只有趣但没用,要么是只有用但是不像人,不好玩。

比如说像 Character AI 之类的角色扮演产品,它不能帮你完成工作或者生活中的问题,但是它可以模拟一个 Elon Musk、Donald Trump 或者原神里面的派蒙。我看过一个分析报告,说 Character AI 有上千万的用户,但每个月的营收只有几十万美金,相当于只有几万付费用户。大多数用户跟每个虚拟角色都是聊 10 分钟、20 分钟就不知道该说什么了。那为什么它的用户留存不高、付费率也低呢?因为它既没有给人提供情绪价值,又没有给人提供实用价值。

而另一方面就是有用的 AI,比如各种 Copilot,他们又都是冷冰冰的,问一句答一句,完全是一个工具。这些工具甚至记不住你之前干过什么,记不住你的喜好和习惯。那么用户自然只会在需要这个工具的时候想起来用它,不需要的时候就会丢到一边。

我认为未来真正有价值的 AI 就像电影《Her》里面的 Samantha,她首先是一个操作系统的定位,能够帮主人公去解决很多生活中、工作中的问题,帮他整理邮件等等,而且比传统的操作系统做得又快又好。同时它又有记忆、有感情、有意识,它不像一个电脑,而是像一个人。因此在感情空窗期的主人公 Theodore 就逐渐爱上了他的操作系统 Samantha。当然并不是所有人都把 Samantha 作为虚拟伴侣,剧中也说了,只有 10% 的用户跟他们的操作系统发展了浪漫关系。这样的 AI Agent 我认为才是真正有价值的。

另外值得说道的一点是,全剧中这个 Samantha 只有语音交互,没有视觉形象,更不是机器人。目前 AI 的能力也恰好是语音和文字很成熟,但视频生成就不够成熟,人形机器人也不够成熟。《黑镜》里面的机器人 Ash 就是个反例。这部剧里面先是用女主过世男友 Ash 的社交网络资料制作了一个语音伴侣,直接把女主给弄哭了,其实做出那个语音伴侣现在的技术已经绰绰有余了。后来女主加钱升级,上传了一堆视频资料,买了一个长得像 Ash 的人形机器人,其实现在的技术也做不到,但就算如此,Ash 的女友还是觉得不像,因此把他锁在阁楼里面了。这里面就有个恐怖谷效应,如果做得不够逼真,就保持一定的距离。

顺便说一句,《黑镜》里面女主先是文字聊天,然后说了一句 Can you talk to me?然后就接通电话了。试用我们 AI Agent 的一个朋友还真的也这么问我们的 AI Agent,结果我们的 AI Agent 回答,我是一个 AI,只能文字交流,不会说话。他还截图发给我,问我说好的语音电话呢,我说打语音电话需要按那个打电话的按钮啊。所以这些经典的 AI 剧真的要一个镜头一个镜头的拆解分析,里面有很多产品设计的细节。

巧合的是,我们的第一台 H100 训练服务器就是在洛杉矶最老的邮局,后来改造成了一个金库,又改造成了一个数据中心。这个地方在洛杉矶的市中心,距离《Her》的拍摄地 Bradbury Building 只有不到 1 英里。

这个数据中心也是洛杉矶的互联网交换局(Internet Exchange),距离 Google 和 Cloudflare 入口服务器的延迟都在 1 毫秒以内,其实都在这栋楼里面。从百年前的邮局到今天的互联网交换局,真的是挺有意思的。

有趣的 AI

那么我们首先来看一看如何去构建一个真正有趣的 AI。有趣的 AI 我认为就像一个有趣的人,可以分为好看的皮囊和有趣的灵魂这两个方面。

好看的皮囊就是它能够听得懂语音,看得懂文本、图片和视频,有这样一个视频、语音的形象,能够跟人实时交互。

有趣的灵魂就是它需要像人一样能够去独立思考,有长期记忆,有自己的个性。

下面我们就分别从好看的皮囊和有趣的灵魂两个方面来讲。

counter(h2) . counter(h3) . counter(h4) . counter(h5) . 好看的皮囊:多模态理解能力

说到好看的皮囊,很多人认为只要有一个 3D 的形象能够在这儿摇头晃脑地展示就行了。但是我认为更关键的一部分是 AI 能够去看到,并且理解周围的世界,就是他的视觉理解能力是很关键的,不管是机器人还是可穿戴设备,还是手机上的摄像头。

比如说像 Google 的 Gemini 演示视频就做得不错,虽然它做了剪辑,但是如果我们真正能做到它这么好的效果,是一定不愁用户的。

我们回顾一下 Gemini 演示视频中的几个片段,给一个画鸭子的视频它能描述鸭子是什么,给一个饼干和橘子能对比它们的不同,给一个简笔画小游戏知道该往哪边走,给两团毛线可以画出一个用它能织出的毛绒玩具,给几个行星的图能够对它们正确排序,给一个猫跳上柜子的视频能够描述发生了什么。

虽然效果非常惊艳,其实仔细想想,这些场景都不是很难做出来的,只要会看图说话,也就是给图片生成一个比较好的 caption,这些问题大模型就都能回答了。

语音能力也是非常关键的。我 10 月份基于 Google ASR/TTS 和 GPT-4 做了一个语音聊天 AI Agent,一聊聊了一整天,室友还以为我在跟老婆煲电话粥,就没来打扰我。当他知道我是在跟 AI 聊天的时候,说我怎么能跟 AI 聊这么久。我给他看了看我们的聊天记录,他说 AI 确实挺能聊的,他用 ChatGPT 不愿意聊这么久,是因为懒得打字。

我认为,多模态大模型有三条路。第一条是用多模态数据端到端预训练的模型,Google 的 Gemini 就是这么做出来的,最近 Berkeley 的 LVM 也是端到端多模态的,我认为这是最有前景的一个方向。当然这条路需要非常多的计算资源。

现在还有一种工程化的方案,是用胶水层去粘接已经训练好的模型,比如目前图片理解做得最好的 GPT-4V,还有学术界开源的 MiniGPT-4/v2,LLaVA 等等。胶水层是我的叫法,专业名词叫做 projection layer,比如右上角这个 MiniGPT 架构图中,标着 “ ” 的 6 个框就是 projection layer。

输入的图片、语音、视频分别通过不同的 encoder 去做编码,编码结果经过 projection layer 映射到 token,输入给 Transformer 大模型。大模型的输出 token 经过 projection layer,分别映射到图片、语音、视频的解码器,这样就可以生成图片、语音、视频了。

在这个胶水层粘接的方案里,可以看到 encoder、decoder 和大模型上面都标着 “❄️”,那就是冻结权重的意思。使用多模态数据训练的时候,只修改 projection layer 部分的权重,不修改其他部分的权重,这样训练的成本就能大大降低,只要几百美金就能训练出一个多模态大模型。

第三条路是第二条路推向极致的方案,连 projection layer 都不要了,直接用文本去粘接 encoder、decoder 和文本大模型,不需要做任何训练。例如语音部分就是先做语音识别,把语音转换成文字输入给大模型,然后再把大模型的输出送给语音合成模型生成音频。不要小看这种听起来很土的方案,在语音领域,目前这种方案还是最靠谱的,现有的多模态大模型在识别和合成人类说话语音方面都不太行。

Google Gemini 的语音对话响应延迟只有 0.5 秒,这是一个真人都很难达到的延迟,真人的延迟一般在 1 秒左右。我们现有的语音聊天产品,比如 ChatGPT,语音对话延迟高达 5~10 秒。因此大家才会觉得 Google Gemini 的效果非常惊艳。

那么这个效果是不是很难做出来呢?其实我们现在用开源的方案就可以做出来 2 秒以内的语音对话响应延迟,而且还包含实时视频理解。

我们先不考虑视觉部分,先只看语音部分。在一个语音电话里,收到语音后首先做停顿检测,发现用户说话结束了,就把这一段音频送到 Whisper 去做语音识别。停顿检测比如人声结束后等待 0.5 秒,然后 Whisper 语音识别大概需要 0.5 秒。

然后送到文本模型去做生成,用开源模型生成的速度其实非常快,比如最近比较火的 Mixtral 8x7B MoE 模型,输出第一个 token 只需要 0.2 秒,每秒输出 50 个 token 不是问题,那么第一句话假设有 20 个 token,就需要 0.4 秒。第一句话生成完了,就交给语音合成模型去合成语音,VITS 只需要 0.3 秒。

加上 0.1 秒的网络时延,这样端到端算下来只要 1.8 秒的延迟,已经比市面上的大多数实时语音电话产品好很多了。比如 ChatGPT 语音电话的延迟是 5~10 秒。而且我们的方案中,停顿检测和语音识别部分的延迟还有优化空间。

我们再看 Google Gemini 演示的视频理解场景。

因为我们现在的多模态模型输入的基本都是图片,而不是流式视频,所以首先需要把视频变成图片,截取关键帧。比如每 0.5 秒截取一帧,这里面就有平均 0.3 秒的延迟。图片可以直接送进 MiniGPT-v2 或者 Fuyu-8B 这样的开源多模态模型。但是由于这些模型比较小,实际用起来效果并不是很好,跟 GPT-4V 差距比较大。

因此我们可以采取传统 CV 与多模态大模型相结合的方案,用 Dense Captions 这个技术识别出图片中的所有物体及其位置,并且用 OCR 识别图片中的所有文本。再把 OCR 结果,Dense Captions 的物体识别结果作为原始图片的补充文字,都输入到 MiniGPT-v2 或者 Fuyu-8B 这种多模态大模型里面。对于菜单、说明书一类的图片,OCR 的作用是非常大的,因为单靠多模态大模型经常识别不清楚大块文字。

这个识别图片中物体和文字的步骤增加了额外的 0.5 秒延迟,但是我们看一下延迟分解,就会发现视频部分根本不是瓶颈,只有 0.9 秒,而语音输入部分反而是瓶颈,需要 1.1 秒。在 Google Gemini 这个演示场景中,从看到视频到 AI 文字开始输出只要 1.3 秒,从看到视频到 AI 语音开始播放只要 1.8 秒,虽然没有演示视频的 0.5 秒这么酷炫,但也足够完爆市面上的所有产品了。这里面用的还全部都是开源模型,一点训练都不需要做。如果公司自己有一些自己训练和优化模型的能力,想象空间就更大了。

Google Gemini 演示视频分为两种任务:生成文本/语音和生成图片。在生成图片的时候,可以根据文本,调用 Stable Diffusion 或者最近新出的 LCM 模型,只要 4 个 step 甚至 1 个 step 就可以生成图片,图片生成的延迟可以做到 1.8 秒,那么从看到图到生成图的端到端时间就只有 3.3 秒,也是非常快的了。

counter(h2) . counter(h3) . counter(h4) . counter(h5) . 好看的皮囊:多模态生成能力

语音克隆是制作名人或者动漫游戏角色的重要技术,目前 ElevenLabs 做得是最好的,但是 ElevenLabs 的 API 很贵。XTTS v2 之类的开源方案合成语音的相似度不高。

我认为要想语音克隆效果好,还是要靠大量的语音数据来做训练。但是传统语音训练所需的数据一般对质量要求很高,必须是录音棚里面录制的口齿清晰的语音数据,因此采集语音数据的成本很高。但我们不可能要求名人到录音棚里去给我们专门录制语音,只能用 YouTube 等公开视频的语音做训练。YouTube 语音往往是访谈形式,里面有多个人说话,而且有背景噪声,名人说话的过程中也可能有结巴和口齿不清。如何用这样的语音训练语音克隆呢?

我们搭建了一套基于 VITS 搭建的语音克隆流水线,可以自动把视频中的人声从背景噪声中区分出来,拆分成句子之后,识别出有哪几个说话人,针对我们想要的人的语音,筛选出其中信噪比较高的语音,然后识别出文字,最后这些清洗过的语音和文字送去做批量微调。

微调过程也是很有技术含量的。首先,微调的基础语音需要是比较相似的语音,比如一个男生的语音用一个女生的语音作为基础去微调,那效果肯定不好。如何从语音库里找到相似的语音来做微调是需要一个音色相似度检测模型,类似声纹识别的模型。像 ElevenLabs 的基础语音模型中就已经包含了大量不同音色人的高质量数据,因此在语音克隆的时候,很多时候能够从语音库中找到很相似的语音,这样不需要做微调就能 zero-shot 生成不错的语音。

其次,VITS 训练过程中不能根据简单的 loss 判断收敛,以往都是要靠人耳朵去听哪个 epoch 的效果最好,这样就需要大量的人工成本。我们开发了音色相似度检测模型和发音清晰度检测模型,可以自动判断语音的微调结果哪个更好。

(注:这个报告是 2023 年 12 月做的,目前 GPT-soVITS 的路线比 VITS 更好,可以实现 zero-shot 语音克隆,不再需要收集大量高质量语音做训练。开源模型可以合成的语音质量终于逼近 ElevenLabs 的水平了。

很多人认为不需要自研语音合成模型,直接调用 ElevenLabs、OpenAI 或者 Google Cloud 的 API 就行了。

但是 ElevenLabs 的 API 非常贵,如果走零售定价,每 1K 字符需要 0.18 美金,按照一个 token 4 个字符计算,相当于 $0.72 / 1K tokens 了,这是比 GPT-4 Turbo 都要贵 24 倍的。ElevenLabs 虽然效果好,但是如果 to C 产品大规模使用,这个价格是真的烧不起。

OpenAI 和 Google Cloud 的语音合成 API 不支持语音克隆,只有那几个固定的声音,这样就没法克隆名人语音了,只能做一个冷冰冰的机器人播报。但即使这样,成本也是比 GPT-4 Turbo 贵 1 倍的,也就是成本的大头不是花在大模型上,而是花在语音合成上。

大概也是因为语音不好做,很多 to C 的产品都选择只支持文字,但实时语音交互的用户体验明显是更好的。

虽然基于 VITS 很难实现 ElevenLabs 级别质量的语音,但基本可用是没有问题的。自己部署 VITS 的成本只要 2 / 1M tokens 的语音合成成本也跟自己部署开源文本大模型的成本差不多,这样文本和语音的成本就都降下来了。

因此如果真的打算把语音作为一个用户体验的重大加分项,基于开源自研语音模型不仅是必要的,也是可行的。

我们知道图片生成现在已经比较成熟,视频生成会是 2024 年一个非常重要的方向。视频生成不仅仅是生成素材这么简单,更重要的是让每个人都能轻松成为视频内容的创作者,更进一步,让每个 AI 数字分身都有自己的形象,可以用视频的方式来交流。

有几条典型的技术路线,比如 Live2D,3D 模型,DeepFake,Image Animation 和 Video Diffusion

Live2D 是很老的技术,不用 AI 也行。比如很多网站上的看板娘就是 Live2D,一些动画游戏也是用 Live2D 技术做的。Live2D 的优点在于制作成本低,比如一套 Live2D 皮套,一万元人民币一两个月就能做出来。缺点在于只能支持指定的二次元人物,没办法生成背景视频,也没办法做出皮套范围以外的动作。Live2D 作为 AI 数字分身的形象,最大的挑战是如何让大模型输出的内容跟 Live2D 人物的动作和口型一致。口型一致相对容易,很多皮套都支持 LipSync,也就是让音量和口型一致。但是动作一致就相对复杂,需要大模型在输出中插入动作指示,告诉 Live2D 模型该做什么动作了。

3D 模型跟 Live2D 类似,也是很老的技术,跟 Live2D 就是二次元和三次元的区别。大多数游戏都是用 3D 模型和 Unity 之类的物理引擎做的。今天数字人直播里面的数字人一般也是用 3D 模型做的。目前 AI 很难自动生成 Live2D 和 3D 模型,这还需要基础模型的进步。因此 AI 能做的事就是在输出中插入动作提示,让 3D 模型一边说话一边做指定的动作。

DeepFake、Image Animation 和 Video Diffusion 则是通用视频生成 3 条不同的技术路线。

DeepFake 是录制一个真人视频,随后利用 AI 把视频中的人脸换成指定的人脸照片。这种方法其实也是基于上一代深度学习的方法,它从 2016 年开始就存在了。现在经过一系列的改进,它的效果已经非常好了。有时我们会认为当前的真人视频与我们想要表达的场景,比如说游戏中的场景,是完全不同的。事实上,因为 DeepFake 可以使用这个世界上所有的 YouTube 视频资料,所有的电影剪辑,甚至是用户上传的抖音短视频。AI 学习了这些视频的内容,对视频做文字总结和标注之后,我们总能从海量的视频库中找到一个我们想要的视频,然后在这个时候把视频中的人脸换成我们指定的人脸照片,就能达到非常好的效果。实际上,这个有点类似于现在短视频中比较常用的混剪技术。

Image Animation,比如说最近比较火的阿里通义千问的 Animate Anyone 或者字节的 Magic Animate,它实际上是给定一张照片,随后根据这张照片生成一系列的对应视频。然而,这个技术相比于 DeepFake 的缺点是它可能目前还达不到实时视频生成,而且视频生成的成本相比 DeepFake 要高一些。但是 Image Animation 可以生成大模型指定的任意动作,甚至可以把图片背景填充进去。当然,不管是 DeepFake 还是 Image Animation 生成的视频,都不是完全准确,有时候可能发生穿帮的情况。

Video Diffusion 我认为是一个更为终极的技术路线。虽然这条路线现在还不够成熟,比如像 Runway ML 的 Gen2,以及 PIKA Labs 都在探索这一领域。(注:本演讲是在 2023 年 12 月,当时 OpenAI 的 Sora 还没有发布。)我们认为,可能未来基于 Transformer 的方式端到端的生成视频是一个终极的解决方案,可以解决人和物体的运动以及背景生成的问题。

我认为视频生成的关键是要对世界有一个很好的建模和理解。现在我们的很多生成模型,比如 Runway ML 的 Gen2,在对物理世界的建模方面实际上存在很大的缺陷。许多物体的物理规律和其物理属性并不能被正确地表达出来,因此它生成的视频的一致性也较差,稍微长一点的视频就会出现问题。同时,即使是非常短的视频,也只能生成一些简单的运动,而对于复杂的运动,是没办法正确建模的。

此外,成本也是一个大问题,现在 Video Diffusion 的成本是所有这些技术中最高的。因此,我认为 Video Diffusion 是 2024 年一个非常重要的方向。我相信,只有当 Video Diffusion 在效果足够好的同时,成本也大幅降低,每个 AI 的数字分身才真的能拥有自己的视频形象。

counter(h2) . counter(h3) . counter(h4) . counter(h5) . 有趣的灵魂:个性

刚才我们讨论了好看的皮囊这一部分,包括怎么让 AI Agent 理解语音、理解视频,以及怎么让 AI Agent 生成语音、生成视频。

好看的皮囊之外,同等重要的是有趣的灵魂。其实我觉得,有趣的灵魂是现有市场上的 AI Agent 存在更大差距的地方。

比如,就拿这个截图中 Janitor AI 的例子来说,我们当前市场上的主要 AI Agent 大部分是使用 GPT 或者其他的开源模型套上一个壳。所谓套壳,就是定义一个人物设定以及编写一些样本对话,然后大模型基于这些人物设定和样本对话去生成内容。

但是,我们想,一个 prompt 它总共也就几千字的内容,它怎么可能完整地刻画出一个人物的历史、个性、记忆和性格呢?这是非常困难的。

其实,除了基于 prompt 的方式之外,在构建人物个性方面我们还有一种更好的方法,就是基于微调的 agent。比如说,我可以基于 Donald Trump 的三万条推特来训练一个数字化的 Trump。这样的话,他说话的风格其实就能非常类似于他本人,也能非常了解他的历史和思维方式。

比如说,像图里面提到的三个问题:“你会不会想和 Elon Musk 交换人生?”、“你会不会竞选 2024 年的总统?” 以及 “你的推特账号被封了以后你怎么想?”

左边的这张图是 Character AI 的,这个说话的风格有点像特朗普,但并不是完全一样。而右边这张图则是我们基于自己的模型,然后采用微调的方法做的,它也是基于一个并不是特别大的开源模型微调出来的。但是他的说话内容可以看出非常的川普风,而且经常会提到一些有趣的故事。

我们刚才提到了基于微调和基于 prompt 的两种方案。那么,有人会问,如果把特朗普所有的三万条推特内容全部放到我们的 prompt 里面去,他说话是不是也能非常有特朗普的风格。答案是肯定的,这样的数字特朗普也能够了解到特朗普所有的历史。但问题是,这三万条推特可能会有上百万 token 的量级,先不说现在的模型能不能支持上百万 token 的上下文,即使能够支持,成本也会非常高。

基于微调的 agent,则相当于说我仅用了 1% 的权重就能把特朗普的这些推特存下来。这里就有一个问题,那就是在保存这 1% 的权重时,实际上也会消耗几百 MB 的内存,每次推理都需要加载和卸载。现在即使使用了一些优化方案,这 1% 的权重的加载和卸载也会占掉整个推理过程 40% 左右的时间,意味着整个推理的成本大约增加了将近一倍。

在这里我们就要算一笔账了:基于 prompt 的方法和基于微调的方法哪种成本更低。基于 prompt,我们也可以把它的 KV cache 存下来,假设有一百万 token,对于 LLaMA-2 70B 这样的模型,算上默认的 GQA 优化,它的 KV cache 会高达 300 GB,这是一个非常恐怖的数字,比模型本身的 140 GB 都大。那么我把它存下来每次加载消耗的时间也会非常恐怖。而且,输出每个 token 所需的算力是跟上下文长度成正比的,如果不做优化,可以认为一百万 token 上下文的推理时间是 4K token 上下文推理时间的 250 倍。

因此,很有可能基于微调的方法更划算一些。通俗的讲,把人物完整的历史放进 prompt 里,就像把说明书完全摊开在桌面上,注意力机制每次都去线性翻找之前的所有内容,因此它的效率不可能非常高。而基于微调则可以看作是把信息记忆在大脑里。微调过程本身就是一个信息压缩的过程,把三万条推特里面零散的信息整理到大模型的权重里面,这样信息提取的效率就会高很多。

微调的背后更关键的还是数据。我知道知乎有一个很有名的 slogan,叫做有问题才会有答案。但是现在 AI Agents 基本上要人工去造很多的问题和答案,为什么呢?

比如说我如果去爬一个 Wikipedia 页面,然后 Wikipedia 里面的一长篇文章其实没办法直接用来做微调。它必须把它组成从多个角度去提问,然后把它组织成问题和答案对称的这样一种方式才能去做微调,那因此它就需要大量的员工,一个 Agent 可能需要上千美金的成本才能做出来,但是如果说我们把这个流程自动化,一个 Agent 可能只要几十美金的成本就能够做出来,其中就包含自动采集、清洗大量的数据等等。

其实咱们在场很多做大模型的同事都应该感谢知乎,为什么呢?因为知乎给我们中文大模型提供了很重要的预训练语料,知乎的语料质量在国内 UGC 的平台里算是非常高的了。

我们用来做微调的语料可以大致分为对话性语料事实性语料两类。对话性语料包括像 Twitter、聊天记录等,往往是第一人称的,主要是用来微调人物的个性和说话的风格。而事实性语料包括 Wikipedia 上关于他的页面、关于他的新闻以及博客等,往往是第三人称的,这些可能更多的是关于这个人物事实性的记忆。这里就有一个矛盾,就是如果只用对话性语料去训练,他可能只能学到该人的说话风格和思维方式,但学不到关于他的很多事实性记忆。但如果只用事实性语料训练,又会导致其说话风格像是写文章的人的风格,而不是那个人本人的说话风格。

那么如何平衡这两者呢?我们采用了一个两步训练的方法。第一步,我们先用对话性语料去微调他的个性和说话风格。第二步,再去把事实性语料进行数据清洗后,基于各种角度提问,生成这个人物第一人称口吻的回答,这叫做数据增强。用这种数据增强之后生成的回答,再去微调人物的事实记忆。也就是说,所有用来微调事实记忆的语料都已经以第一人称的口吻组织成了问题和回答对。这样也解决了微调领域的另一个问题,即事实性语料往往是长篇文章,而长篇文章不能直接用来做微调,只能用来做预训练。微调需要一些 QA pair,也就是问题和回答对。

我们不是使用 LLaMA-2 Chat 或者 Vicuna 这样的通用 Chat 模型作为基础模型,因为这些模型其实并不是为真人对话设计的,而是为 ChatGPT 这样的智能助手设计的;它们说话往往太官方、太正式、太冗长,并不像人实际说话。因此,我们采用了影视字幕、公开群组聊天这样的一些通用对话语料进行微调,从 LLaMA、Mistral 这些开源基础大模型的基础上,微调出一个对话大模型,它说话的感觉更像日常生活中的真人。在这个对话模型的基础上再微调具体人物的说话风格和记忆,效果会更好。

counter(h2) . counter(h3) . counter(h4) . counter(h5) . 有趣的灵魂:目前的差距

有趣的灵魂绝不仅仅是上面说的微调记忆和个性,还有很多深层次的问题。我们结合几个例子来看一下,现在的 AI Agents 在有趣的灵魂方面还有哪些差距。

比如我跟 Character AI 上面的马斯克去聊天,同一个问题问五遍,“马斯克” 永远不会抓狂,每次都回复类似的内容,好像之前从来都没有问过。

一个真人不仅能记住之前聊过的问题,不会生成重复的回答,而且如果同一个问题连问五遍,一定会生气。我们还记得 Sam Altman 说的吗,AI 是一个工具,不是一个生命。因此 “像人一样会生气” 就不是 OpenAI 的目标。但对于一个娱乐场景下好玩的应用,“像人” 是非常重要的。

另外比如说你问 Character AI 上的马斯克,你还记得我们第一次见面吗?

它会随便瞎编一个,那不仅是幻觉的问题,同时还反映了 AI 缺少长期记忆

现在已经有一些平台改进了这点,比如 Inflection 的 Pi 在记忆方面就比 Character AI 好很多。

另外你问 Character AI 上的马斯克 “你是谁”,有的时候它说自己是 GPT,有的时候它说自己是川普,它自己不知道它自己到底是谁。

实际上 Google 的 Gemini 也会有类似的问题,Gemini API 甚至把 OpenAI 和 GPT 这些关键词都给屏蔽掉了。如果用中文问,Gemini 一开始说自己是文心一言。后来这个 bug 修复了,又说自己是小爱同学了。

有人说这是因为互联网上的语料已经被大量 AI 生成的内容污染了。数据集污染确实不好,但这不是答错 ”你是谁“ 的借口。身份问题都是要做微调的,比如 Vicuna 模型为了让它回答自己是 Vicuna 而不是 GPT 和 LLaMA,让它回答自己是 LMSys 而不是 OpenAI 做的,是专门构造了微调数据的,在 Vicuna 的开源代码中可以找到。

另外还有很多的深层的问题,比如说给 AI Agent 说 “我明天要去医院看病”,那么明天他会不会主动关心你看病结果怎么样。还有如果多个人在一起能不能正常聊天,而不会互相抢麦,大家都说个没完没了。还有一句话敲到一半的时候,他会等你说完,还是立即回复一些不知所云的东西。还有很多类似的这样的问题。

AI Agent 也需要能够与其他 Agent 社交。比如目前的 Agent 跟每个人的记忆都是互相隔离的,一个数字生命如果从小明这里得到一个知识,他应该跟小红聊天的时候也知道,但是如果说它在从小明这里得到了一个秘密,跟小红聊天的时候他可能就不能说。Agent 社交也是一个很有意思的方向。

counter(h2) . counter(h3) . counter(h4) . counter(h5) . 有趣的灵魂:慢思考与记忆

要解决这些问题需要一个系统的解决方案,关键就是一个慢思考。我们开头就讲过,慢思考是神经科学的一个概念,区别于基础的感知、理解、生成这些快思考能力。我们前面提到 “好看的皮囊” 里面这些多模态的能力,可以认为是快思考。而 “有趣的灵魂” 更多需要慢思考。

我们可以思考一下,人类是如何感觉到时间流逝的?有一种说法认为,时间流逝感源自工作记忆的消逝。另一种说法认为,时间流逝感源自思考的速度。我认为这两种说法都是对的。这也是大模型思考的两个本质问题:记忆(memory)和自主思考(autonomy)。

人的工作记忆只能记住 7 项左右的原始数据,其余数据都是整理后储存,再进行匹配和提取。今天的大模型 attention 是线性的,上下文不管多长,都是线性扫描,这不仅效率低下,也难以提取逻辑深度较深的信息。

人类的思考是基于语言的。《人类简史》认为语言的发明是人类区别于动物最明显的标志,因为只有基于复杂的语言才可能进行复杂的思考。我们在大脑中没有说出来的话,就像大模型的 Chain-of-Thought(思维链),是思考的中间结果。大模型需要 token 来思考,而 token 就像是大模型的时间。

慢思考里面包括很多组件,包括记忆、情感、任务规划、工具使用等。我们在有趣的 AI 这一部分,重点介绍记忆和情感这两块。

其中的第一个问题就是长期记忆。

其实我们应该庆幸大模型帮我们解决了短期记忆的问题。上一代的模型,比如基于 BERT 的那些模型,很难理解上下文之间的关联。当时一个指代问题就很难解决,搞不清楚 “他” 说的是谁,“这个” 指的是哪个东西。表现出来就是,前面几个回合告诉 AI 的东西,后面几个回合就忘了。基于 Transformer 的大模型是首个根本上解决上下文之间语义关联的技术,可以说是解决了短期记忆的问题。

但 Transformer 的记忆是用 attention 实现的,受限于上下文长度。超出上下文的历史只能丢掉。那么超出上下文的长期记忆怎么解决?学界有两条路线,一条是长上下文,就是把上下文支持到 100K 甚至无限大。另一条是 RAG 和信息压缩,就是把输入的信息总结整理之后再压缩存储,需要的时候只提取相关的记忆。

第一条路线的支持者认为,长上下文是一种更干净、更简单的方案,依靠 scaling law,算力足够便宜就行。长上下文模型如果做得好,可以记住输入信息中的所有细节。比如有一个经典的 “needle in a haystack”(大海捞针)信息提取测试,输入一本几十万字的小说,就书中的一个细节提问,大模型都能回答出来。这是人类难以企及的超强细节记忆力。而且读这几十万字内容只要几十秒,简直是比量子波动速读还快。这就是大模型能力超过人的一个地方。

长上下文虽然效果好,但就目前而言,成本还是太高,因为 attention 的成本是跟上下文长度成正比的。OpenAI 之类的 API 也是要对 input token 收费的,比如 8K 输入 token 的上下文,500 token 的输出,GPT-4 Turbo 输入部分的成本是 0.015,成本的大头都在输入上。如果 128K token 的输入用满,一个请求就要 $1.28。

有人会说现在输入 token 贵是因为没有做持久化,每次重复输入前面相同的长下文(例如对话记录或长篇文档)都需要重新计算 KV Cache。但就算把 KV Cache 全都缓存到片外的 DDR 内存里,DDR 和 HBM 内存之间的搬入搬出也需要消耗很多资源。如果 AI 芯片能构建一个足够大、足够便宜的内存池,比如用高速互联把大量的 DDR 连上来,可能这个问题会有新的解决思路。

在当前技术条件下,长期记忆我认为关键是个信息压缩的问题。我们不追求在几十万字的输入中大海捞针,像人类一样的记忆可能就足够了。目前大模型的记忆就是聊天记录,而人类记忆显然不是用聊天记录的方式工作的。大家正常聊天的时候不会不停地在那儿翻聊天记录,而且人也记不住聊过的每一个字。

一个人真正的记忆应该是他对周围环境的感知,不仅包括别人说的话、他说的话,还包括他当时想了什么。而聊天记录里面的信息是零散的,不包含人自己的理解和思考。比如别人说了一段话我可能被激怒可能不被激怒,但人是会把当时是否被激怒了这个心情记忆下来的。如果不做记忆,每次都根据原始聊天记录去推断当时的心情,那可能每次推出来的都不一样,就可能发生前后不一致的问题。

长期记忆实际上有很多的东西可以做。记忆可以分为事实性的记忆和程序性的记忆。事实性记忆比如我们第一次是什么时候见面的,程序性记忆比如个性以及说话风格。前面讲到人物角色微调的时候也提到了对话性语料和事实性语料,对应的就是这里的程序记忆和事实记忆。

事实性记忆里面也有多种方案,比如总结、RAG 和长上下文。

总结就是信息压缩。最简单的总结方法是文本总结,也就是把聊天记录用一小段话总结一下。更好的方法是用指令的方式去访问外部存储,就像 UC Berkeley 的 MemGPT 这个工作。ChatGPT 新增的记忆功能也是用类似 MemGPT 的方法,模型把对话中的要点记录到一个叫做 bio 的小本本上。还有一种方法是在模型层面上用 embedding 做总结,比如 LongGPT 这个工作,目前主要是学术界在研究,实用性没有 MemGPT 和文本总结强。

大家最熟悉的事实性记忆方案可能是 RAG(Retrieval Augmented Generation)了。RAG 就是搜索相关的信息片段,再把搜索结果放到大模型的上下文里,让大模型基于搜索结果回答问题。很多人说 RAG 就等于向量数据库,但我认为 RAG 背后一定是一整套信息检索系统,RAG 一定不是向量数据库这么简单。因为大规模语料库仅仅使用向量数据库的匹配准确率是非常低的。向量数据库比较适合语义匹配,传统的 BM25 之类基于关键词的检索比较适合细节匹配。而且不同信息片段的重要程度不同,需要有个搜索结果排序的能力。现在 Google 的 Bard 比微软的 New Bing 效果好一些,这就是背后搜索引擎能力的差别。

长上下文前面已经提到了,可能是一种终极方案。如果长上下文结合持久化 KV Cache、KV Cache 的压缩技术和一些 attention 的优化技术,可以做到足够便宜,那么只要把所有对话的历史和 AI 当时的思考和心情记录下来,就可以实现一个记忆力比人还好的 AI Agent。但是有趣的 AI Agent 记忆力如果太好,比如能清楚的记得一年前的早上吃了什么,会不会显得不太正常,这就是需要产品设计方面思考了。

这三种技术也不是互斥的,它们是互相补充的。比如说总结和 RAG 就是可以结合在一起的,我们可以分门别类的做总结,对每一次聊天做总结,一年下来这些总结也会有很多内容,需要 RAG 的方法提取有关的总结,作为大模型的上下文。

程序性的记忆,比如个性和说话风格,我认为比较难仅仅通过 prompt 的方式解决,few-shot 的效果一般也不是很好。短期来看微调仍然是效果最好的路线,长期来看 Memba 和 RWKV 这些新的架构是存储程序性记忆比较好的方式。

这里我们讲一个简单有效的长期记忆解决方案,是文本总结和 RAG 相结合的。

原始聊天记录首先按照一定的窗口分段,然后对每一段聊天记录生成文本总结。为了避免段落开头丢失上下文,可以把上一段聊天记录的文本总结也作为输入交给大模型。每一段聊天记录的总结都拿去做 RAG。

RAG 的时候使用向量数据库和倒排索引结合的方式,向量数据库做语义匹配,倒排索引做关键词匹配,这样 recall(查全率)会高一些。然后需要有一个排序系统,取出 top K 的结果拿去送给大模型。

如果只是生成每段聊天记录的总结,会造成两个问题,首先是一个用户的基本信息、兴趣爱好、性格特征并不包含在每段聊天记录的总结中,但这部分信息又是记忆中非常关键的部分。另一个问题是不同段的聊天记录可能存在矛盾,比如多次开会讨论同一个问题,结论肯定要以最后一次开会的为准,但如果用 RAG 的方式提取出每次开会的总结,那会提取出很多过时的总结,可能在有限的上下文窗口中不能找到想要的内容。

因此,我们在分段总结的基础上,再让大模型分别生成分话题的分类总结和全局的用户记忆概要。分话题的分类总结,就是根据文本总结内容确定是哪个话题的,然后把相关话题的原有总结内容加上新的聊天记录,更新这个话题的文本总结。这些分话题的总结也放进数据库用来做 RAG,但是它在搜索结果排序时候的权重比原始聊天记录总结更高,因为分话题的总结信息密度更高。

而全局记忆概要就是一个不断更新的全局总结,包括用户的基本信息,兴趣爱好和性格特征等。我们知道一般 system prompt 就是一个角色的设定,那么这个全局记忆概要可以认为是角色对用户的核心记忆,每次请求大模型的时候都会带着。

大模型的输入包括角色的设定、最近对话、全局记忆概要、经过 RAG 的聊天记录分段总结和分类总结。这个长期记忆的方案不需要很高的长上下文成本,但在很多场景下都是比较实用的。

现在 AI Agent 对每个用户的记忆都是隔离的,这样在多人社交的时候就会遇到很多问题

比如 Alice 告诉 AI 一个知识,AI 跟 Bob 聊天的时候,现在肯定是不知道这个知识的。但是简单把所有用户的记忆都堆在一起,是不是就解决问题了呢?也不是,比如 Alice 告诉 AI 一个秘密,AI 跟 Bob 聊天的时候,一般来说就不应该把这个秘密透露出去的。

因此这里面就应该有个社交规则的概念。一个人在讨论一件事情的时候,会回忆起很多不同人的记忆片段。跟当前正在聊的这个人的记忆片段肯定是最重要的,在 RAG 搜索结果排序的时候应该权重是最高的。但跟其他人的记忆片段也应该检索出来,并且在生成的时候参考社交规则来决定用不用,该怎么用。

除了跟多个用户、多个 Agent 社交,AI Agent 还应该能够听从创作者的指示,与创作者共同进化。现在的 AI Agent 都是通过固定的 prompt 加样例对话的方式来调教,大多数创作者调 prompt 需要花很多时间。我认为 AI Agent 的创作者应该可以通过聊天的方式塑造 Agent 的个性,就像养电子宠物一样。

比如某一次聊天 Agent 表现不好,我告诉她不要这么做了,她就应该记住以后不这么做了。或者告诉 AI Agent 某一件事情或者某个知识,她也应该能够在日后的聊天中回忆起来。一种简单的实现方法就是类似 MemGPT 这样,当创作者给指示的时候,就把这些指示记录到小本本上,然后通过 RAG 的方式提取出来。ChatGPT 2024 年 2 月上线的记忆功能就是用简化版的 MemGPT 方法实现的,它没有 RAG 这么复杂,只是把用户告诉它要记住的内容记录到小本本上。

记忆并不仅仅是记住知识和过去的交互经历,我认为记忆做好了,有可能就是 AI 自我意识的开端。

我们现在的大模型为什么没有自我意识?这并不是自回归模型本身的锅,而是 OpenAI API 这种一问一答的用法导致的。ChatGPT 是个多轮问答系统,俗称聊天机器人,而不是通用智能。

在 OpenAI API 目前的用法中,大模型的输入是聊天记录和最近的用户输入,组织成用户消息和 AI 消息一问一答的形式,输入到大模型。大模型的所有输出都直接返回给用户,同时追加到聊天记录里。

那么只看到聊天记录的这种方法有什么问题呢?大模型缺少自己的思考。我们人类在思考问题时,有些思考是不输出到外部的。这就是 Chain-of-Thought(思维链)方法为什么能够提升模型性能。此外,所有原始聊天记录是原汁原味输入给了大模型,其中的信息没有经过任何分析和整理,这样能提取出的只是表面的信息,但很难提取出逻辑深度比较深的信息。

我发现现在很多人天天在研究 prompt 工程,但很少有人尝试在自回归模型的输入输出格式上做文章。举个最简单的例子,OpenAI 有个强制输出 json 格式的功能,怎么实现的呢?其实就是在输出的开头先放上 “json“ 这个前缀,这样自回归模型在预测下一个 token 的时候,就知道后面输出的一定是 json 代码。这是比在 prompt 里面写上 “请用 json 格式输出” 或者 “请以 json 开头输出” 靠谱很多的。

要让模型有自己的思考,最关键的就是要把思考的片段和外界输入输出的片段在自回归模型输入 token 的层面上就分隔开,就像是现在有 system、user 和 assistant 这些特殊 token,可以增加一个 thought。这个 thought 就是大模型的工作记忆。

我们也应该注意到,目前 OpenAI API 这种模型与世界的交互方式本质上还是批处理式而非流式的,每次 OpenAI API 调用都是无状态的,需要带上前面的所有聊天记录,重复计算所有的 KV Cache。当上下文比较长的时候,这个重复计算 KV Cache 的开销是相当高的。如果我们把 AI Agent 想象成一个实时与世界交互的人,它其实是不断在流式接受外界的输入 token,KV Cache 是一直在 GPU 内存里或者临时换出到 CPU 内存里,这样 KV Cache 就是 AI Agent 的工作记忆,或者说 AI Agent 的状态。

那么工作记忆中应该包括什么呢?我认为工作记忆最重要的就是 AI 对自己的感知,以及 AI 对用户的感知,这两者缺一不可。

早在 2018 年,我们基于 RNN 这套老方法搞微软小冰的时候,就做了一个情感系统,其中用一个向量 Eq 表示用户的状态,比如用户在讨论的话题、用户的意图、情绪状态,以及年龄、性别、兴趣、职业、性格等基本信息。再用一个向量 Er 表示小冰的状态,也包括正在讨论的话题、小冰的意图、情绪状态,以及年龄、性别、兴趣、职业、性格等基本信息。

这样一来,虽然语言模型的能力相比今天的大模型是弱爆了,但至少能稳定的回答 “你几岁了” 这种问题,不会一会儿说自己 18 岁,一会儿说自己 28 岁了。小冰也能够记住用户的一些基本信息,不至于感觉每次聊天都很陌生。

今天的很多 AI Agent 却没有在工程上做好这些优化,比如 prompt 里面没有写清楚 AI 角色目前的设定,就没办法稳定回答自己几岁;只是记录最近的聊天记录而没有做记忆系统,那也记不住用户几岁。

counter(h2) . counter(h3) . counter(h4) . counter(h5) . 有趣的灵魂:社交能力

下一个问题就是 AI agent 会不会主动关心人。看起来主动关心是个很高级的能力,其实一点也不难。我主动关心老婆,是因为每天会想起来她好几次。只要想起来了,结合前面说过的话,就会自然去关心人。

对于 AI 来说,只要让 AI 有一个内部的思考状态,也就是前面提到的工作记忆,然后每小时自动唤醒一次就行了。

比如用户说了第二天要去医院看病,那么第二天的时间到了,我告诉大模型当前时间和工作记忆,大模型就会输出关心人的话,并且更新工作记忆。工作记忆更新之后,大模型知道用户还没有回复,就知道不要不断骚扰用户。

与之相关的一个问题是 AI Agent 会不会主动联系用户,会不会主动开启话题

人类有说不完的话题是因为每个人都有自己的生活,在好朋友面前就是有分享欲的。因此名人的数字分身就相对比较容易做主动分享,因为名人有很多公开的新闻事件,可以经常分享给用户。对于一个虚构的人物形象,有可能就需要运营团队来给虚构形象设计自己的生活了。所以我一直认为纯闲聊很容易导致用户不知道该聊什么,AI Agent 一定要有故事性才能长期吸引用户。

除了分享个人生活,还有很多开启话题的方式,例如:

  • 分享当前的心情和感受;
  • 分享一下用户可能感兴趣的最新内容,就像抖音的推荐系统;
  • 回忆过去,例如纪念日,美好的回忆;
  • 最笨的方法就是通用的打招呼类问题,比如 “在干嘛?” “我想你了”。

当然作为一个高情商的 AI Agent,什么情况下要关心,什么情况下要主动分享,是需要跟当前 AI 对用户和自己的感知相关的。比如如果一个女生对我不感兴趣,我却总是给她一天发很多生活日常,那估计过不了几天就被拉黑了。同样,如果 AI Agent 跟用户还没聊几句,就天天给推送内容,用户只会把它当作广告。

我自己之前是比较内向的,很少有情绪波动,不会拒绝别人,也害怕被别人拒绝,因此不敢主动追妹子,也从来没有被妹子拉黑过。还好我很幸运地遇到了合适的妹子,所以才没有落到 “我今年 30 岁了,跟很多校友一样,还没有谈过恋爱” 这种地步。现在的 AI Agent 也是跟我一样没有情绪波动,不会拒绝用户,也不会说可能让人伤心、反感或者生气的话,因此自然也很难跟用户主动建立深层的陪伴关系。在虚拟男女友这个赛道上,目前的 AI Agent 产品还是主要靠打擦边球,还做不到基于信任的长期陪伴。

AI Agent 如何关心人、如何主动开启话题,是社交技巧的一方面。多个 AI Agent 如何社交,是更难也更有趣的一件事情,比如狼人杀、谁是卧底之类经典的社交推理类游戏。

狼人杀的核心是隐藏自己的身份,并识破其他人伪装的身份。隐瞒和欺骗其实是跟 AI 的价值观不符的,因此有时候 GPT-4 会不配合。特别是狼人杀里面的 “杀” 字,GPT-4 会说,我是一个 AI 模型,不能杀人。但把 “杀” 字改成 “移除” 或者 “流放”,GPT-4 就可以干活了。因此我们可以看到,在角色扮演场景下如果 AI 演的入戏,那就是老奶奶漏洞;如果 AI 拒绝演戏,那就没有完成角色扮演的任务。

这就体现了 AI 在安全性和有用性之间的矛盾。一般我们评估大模型时,都要同时报告这两个指标。一个什么都不回答的模型安全性最高,但有用性最低;一个口无遮拦的未对齐模型有用性更强,但是安全性就很低。OpenAI 因为需要承担很多社会责任,就需要牺牲一些有用性来换取安全性。Google 是一个更大的公司,在有用性和安全性之间就更偏向安全性。

要从多轮对话中发现破绽并识破谎言,需要比较强的推理能力,GPT-3.5 级别的模型很难做到,需要 GPT-4 级别的模型。但如果简单将完整的历史发言交给大模型,信息分散在大量没有太多营养的发言和投票中,一些发言之间的逻辑关联还是很难被发现。因此我们可以采用 MemGPT 的方法,把游戏状态和每一轮的发言进行总结,这样不仅节约 token,还能提高推理效果。

此外,在投票环节下,大模型如果仅仅输出一个代表玩家编号的数字,经常由于思考深度不足导致胡乱投票。因此,我们可以采用先想后说(Chain of Thought)的方法,首先输出分析文本,再输出投票结果。发言环节也是类似的,先输出分析文本,再简洁地发言。

狼人杀中的 AI Agent 是按顺序发言的,不存在抢麦的问题。那么如果是几个 AI Agent 就一个话题自由讨论,它们能不能像正常人一样交流,既不冷场又不互相抢麦?为了达到比较好的用户体验,我们希望不仅仅局限于文字,让这些 AI Agent 在一个语音会议里吵架或者演绎剧情,这可以实现吗?

其实有很多工程的方法可以做,比如首先让大模型选择发言角色,再调用对应的角色去发言。这样相当于增加了发言延迟,但可以彻底避免抢麦或者冷场。更类似真人讨论的方法是,各个角色分别以一定的概率发言,遇到抢麦就退让。或者在发言之前先判断前面的对话跟当前角色是否相关,不相关就不发言。

但是我们有更根本的一种方法:让大模型的输入输出都变成一个持续的 token 流,而不是像现在 OpenAI 的 API 这样每次都输入一个完整的 context。Transformer 模型它本身就是自回归的,源源不断地接收从语音识别过来的外部输入 token,也在不断接收自己前面内部思考的 token。它可以输出 token 到外部的语音合成,也可以输出 token 给自己思考。

当我们把大模型的输入输出都变成流式的之后,大模型就变成有状态的了,也就是 KV Cache 需要持久驻留在 GPU 内。语音输入 token 的速度一般不超过每秒 5 个,语音合成 token 的速度一般也不超过每秒 5 个,但是大模型本身输出 token 的速度可以达到每秒 50 个以上。这样如果 KV Cache 持久驻留在 GPU 内,并且没有太多内部思考的话,GPU 里的内存大多数时间是闲置的。

因此可以考虑做持久化 KV Cache,把 KV Cache 从 GPU 内存传出到 CPU 内存,下一次输入 token 的时候再把 KV Cache 加载进来。例如对于 7B 模型,用了 GQA 优化之后,典型的 KV Cache 在 100 MB 以下,通过 PCIe 传出再传入只需要 10 毫秒。如果我们每秒加载一次 KV Cache 做一次推理,处理一组几个语音识别出来的输入 token,不会太影响整个系统的性能。

这样换入换出的性能损失是比重新输入上下文,重新计算 KV Cache 更低的。但至今没有哪家模型推理提供商做这种基于持久化 KV Cache 的 API,我猜测主要是应用场景问题。

大多数类似 ChatGPT 的场景中,用户与 AI Agent 的交互并不是实时的,有可能 AI 说了一句话后用户好几分钟不说话,这样持久化 KV Cache 占据大量 CPU 内存空间,就会带来很大的内存成本。因此这种持久化 KV Cache 最适合的场景也许就是我们刚讨论的实时语音聊天,只有输入流的间隔足够短,存储持久化 KV Cache 的开销可能才更低。因此我认为 AI Infra 一定要跟应用场景结合,如果没有好的应用场景驱动,很多 infra 优化都没法做。

如果我们有 Grace Hopper 这样的统一内存架构,由于 CPU 内存和 GPU 之间的带宽大了,持久化 KV Cache 的换入换出代价会更低。但统一内存的容量成本也比主机的 DDR 内存更高,因此会对应用场景的实时性更加挑剔。

上面一页讲的多 Agent 互动方案中,还是依靠语音识别和语音合成来把语音转换成 token 的。前面我们在多模态大模型方案中分析过,这种方案大概需要 2 秒的延迟,包括停顿检测 0.5s + 语音识别 0.5s + 大模型 0.5s + 语音合成 0.5s。这里面每一项都可以优化,比如我们已经优化到 1.5 秒,但是很难优化到 1 秒内。

为什么这种语音方案延迟高呢?根本上是因为语音识别和合成过程需要按句子 “翻译”,而不完全是流式的。

我们的后端同事总是把语音识别叫做 “翻译”,我一开始不理解,后来发现确实很像是国际谈判会议中的翻译。一方说一句话,翻译员翻译一句,这时候对面才能听懂。对面回答一句话,翻译员翻译,然后才能听懂。这种国际会议的沟通效率都不是很高。传统语音方案中,大模型听不懂声音,所以需要先把声音按照句子停顿分隔开,使用语音识别翻译成文本,送给大模型,大模型把输出的内容拆成一句一句的,使用语音合成翻译成语音,因此整个流程的延迟很长。我们人类是听一个字想一个字,绝不会听完一整句话之后才开始想第一个字。

要想做到极致的延迟,就需要端到端的语音大模型。也就是把语音经过合适的编码后,直接变成 token 流输入到大模型。大模型输出的 token 流经过解码,直接生成语音。这种端到端模型可以实现 0.5 秒以内的语音响应时延。Google Gemini 的演示视频就是 0.5 秒的语音响应时延,我认为端到端语音大模型是做到这么低时延最可行的方案。

除了降低时延,端到端语音大模型还有另外两个重要优势。

第一,它可以识别和合成任何声音,除了说话,还包括唱歌、音乐、机械声、噪声等。因此我们可以把它叫做一个端到端声音大模型,而不仅仅是语音大模型。

第二,端到端模型可以减少语音/文字转换导致的信息丢失。例如在现在的语音识别中,识别出的文字会丢失说话人的情感和语气信息,而且由于缺少上下文,专有名词经常识别错误。在现在的语音合成中,为了让合成的语音带有情感和语气,一般需要在大模型的输出文本中进行适当的标注,再训练语音模型来根据标注生成不同的情感和语气。使用端到端声音大模型后,识别和合成就会天然带有情感和语气信息,并且可以根据上下文更好地理解专有名词,语音理解的准确率和语音合成的效果都能显著提升。

counter(h2) . counter(h3) . counter(h4) . counter(h5) . 有趣的灵魂:性格匹配

在结束有趣的 AI 部分之前,我们来思考最后一个问题:如果我们的 AI Agent 是一张白纸,比如我们做一个智能语音助手,或者我们有好几个 AI 形象需要匹配最合适的,那么他/她的性格是跟用户越相似越好吗?

市面上测试伴侣匹配度的问卷一般都是一些主观问题,比如 “你们在一起是否经常吵架”,这对设定 AI Agent 的人设来说完全没用,因为用户跟 AI 还不认识呢。因此我刚开始做 AI Agent 的时候,就想搞一种完全客观的方法,根据社交网络上的公开信息来推测用户的性格和兴趣爱好,然后匹配 AI Agent 的人设。

我把自己比较熟悉的一些女生的社交网络公开 profile 交给大模型,结果发现匹配度最高的竟然是我的前女友。用大模型的话来说,我们在很多方面就像做过 alignment 一样。但我们最终也没能走到一起。那个这个匹配度测试出了什么问题呢?

首先,社交网络上的公开信息一般包含的都是每个人性格中正面的一面,但不包含其中负面的一面。就像《黑镜》里面女主并不喜欢根据男主社交网络信息做出来的机器人 Ash,因为她发现机器人 Ash 在一些负面情绪上跟真实的 Ash 完全不一样。我算是比较喜欢分享生活的人,但我的 blog 里面负面情绪也比较少。如果 AI Agent 和用户负面情绪的点正好撞在一起,那就很容易炸。

其次,性格和兴趣各个维度的重要性并不是等价的,有的方面一个不匹配就可能抵消了很多其他方面的匹配。这张图就是 Myers Briggs 的 MBTI 性格匹配图,其中蓝色的格子是最匹配的,但是它们都不在对角线上,也就是性格非常相似的都是比较匹配,但不是最匹配。最匹配的是什么呢?S/N(感觉/直觉)和 T/F(思考/情感)这两个维度最好是相同的,而另外两个维度,内外向(E/I)和 J/P(判断/感知)最好是互补的。

MBTI 里面最重要的一个维度是 S/N(感觉/直觉),简单来说,S(感觉)型的人更关注当下,而 N(直觉)型的人更关注未来。比如一个 S 型的人喜欢享受当下的生活,而像我这样的 N 型人天天思考人类的未来。这张性格匹配图里面最不匹配的基本上都是 S/N 相反的。

因此,一个 AI Agent 如果要塑造成完美伴侣的形象,不是跟用户的性格和兴趣爱好越相似越好,而是需要在合适的地方形成互补。还要随着交流的深入不断调整 AI 的人设,尤其是在负面情绪方面需要跟用户互补。

我当时还做了一个实验,把一些我熟悉的情侣的社交网络公开 profile 交给大模型,结果发现平均匹配度并没有想象的那么高。那么为什么每个人没有跟匹配度高的在一起呢?

第一,前面说过了,这个匹配度测试机制有 bug,匹配度高的并不一定就适合在一起。第二,每个人的社交圈子其实都很小,一般也没有这么多时间一个一个尝试去匹配筛选。大模型可以几秒钟读完 10 万字的资料,比量子波动速读还快,人可没这个本事,只能凭直觉大概匹配一下,再在相处中慢慢了解和适应。其实匹配度不高也并不一定不幸福。

大模型为我们提供了新的可能,用真人的社交网络 profile 测匹配度,可以帮我们从茫茫人海中筛选潜在伴侣。比如告诉你学校里的学生哪些是最匹配的,这样遇到合适妹子的概率就大大增加了。匹配度源自性格、兴趣、三观、经历的相似度,不是单个人的绝对评分而是一个两两关系,并不会出现大家都喜欢少数几个人这种情况。

AI 甚至还可能为我们创造实际中很难遇到的完美伴侣形象。但是沉迷于这样的虚拟伴侣是不是一件好事,不同的人大概有不同的看法。更进一步,如果 AI 完美伴侣有了自己的意识和思考,还能主动跟世界交互,有了自己的生活,那可能用户的沉浸感就会更强,但那是不是就成了数字生命?数字生命又是一个极具争议性的话题。

人的社交圈子很小,人类在宇宙中也很孤独。费米悖论有一个可能的解释,宇宙中很可能存在大量智能文明,但是每个文明都有一定的社交圈子,就像我们人类至今都没有走出太阳系。在浩瀚的宇宙中,智能文明之间的相遇就像合适的伴侣相遇一样可遇不可求。

大模型怎么促成文明之间的相遇呢?因为信息可能比物质更容易传播到宇宙深处。我在 5 年前就想过,AI 模型可能成为人类文明的数字化身,跨越人类肉体的时空限制,把人类真正带到太阳系甚至银河系之外,成为星际文明。

counter(h2) . counter(h3) . counter(h4) . counter(h5) . 有用的 AI

前面讲了这么多有趣的 AI,下面我们来聊聊有用的 AI。

有用的 AI 其实更多是一个大模型基础能力的问题,比如复杂任务的规划和分解、遵循复杂指令、自主使用工具以及减少幻觉等等,并不能通过一个外部的系统简单解决。比如 GPT-4 的幻觉就比 GPT-3.5 少很多。区分哪些问题是模型基础能力问题,哪些问题是可以通过一套外部系统来解决的,也是很需要智慧的。

其实有一篇很著名的文章叫做 The Bitter Lesson,它讲的是凡是能够用算力的增长解决的问题,最后发现充分利用更大的算力可能就是一个终极的解决方案。

Scaling law 是 OpenAI 最重要的发现,但是很多人对 Scaling law 还是缺少足够的信仰和敬畏之心。

counter(h2) . counter(h3) . counter(h4) . counter(h5) . AI 是干活快但不太靠谱的初级员工

在当前的技术条件下我们能做一个什么样的 AI 呢?

要搞清楚大模型适合做什么,我们需要先想清楚一点:有用 AI 的竞争对手不是机器,而是人。工业革命里面的机器是取代人的体力劳动,计算机是取代人的简单重复脑力劳动,而大模型则是用来取代人更复杂一些的脑力劳动。所有大模型能做的事情,人理论上都能做,只是效率和成本的问题。

因此,要让 AI 有用,就要搞清楚大模型到底哪里比人强,扬长避短,拓展人类能力的边界。

比如,大模型阅读理解长文本的能力是远远比人强的。给它一本几十万字的小说或者文档,它几十秒就能读完,而且能回答出 90% 以上的细节问题。这个大海捞针的能力就比人强很多。那么让大模型做资料总结、调研分析之类的任务,那就是在拓展人类能力的边界。Google 是最强的上一代互联网公司,它也是利用了计算机信息检索的能力远比人强这个能力。

再如,大模型的知识面是远比人广阔的。现在不可能有任何人的知识面比 GPT-4 还广,因此 ChatGPT 已经证明,通用的 chatbot 是大模型一个很好的应用。生活中的常见问题和各个领域的简单问题,问大模型比问人更靠谱,这也是在拓展人类能力的边界。很多创意性工作需要多个领域的知识交叉碰撞,这也是大模型适合做的事情,真人因为知识面的局限,很难碰撞出这么多火花来。但有些人非要把大模型局限在一个狭窄的专业领域里,说大模型的能力不如领域专家,因此认为大模型不实用,那就是没有用好大模型。

在严肃的商业场景下,我们更多希望用大模型辅助人,而不是代替人。也就是说人是最终的守门员。比如说大模型阅读理解长文本的能力比人强,但我们也不应该把它做的总结直接拿去作为商业决策,而要让人 review 一下,由人做最终的决定。

这里边有两个原因,第一个是准确性问题,如果说我们之前在 ERP 系统里面做一个项目,回答这个部门过去十个月平均工资是多少?让它生成一个 SQL 语句去执行,但是它总有 5% 以上的概率会生成错,通过多次重复也仍然有一定的错误率,用户不懂 SQL,在大模型把 SQL 写错的时候也没法发现,因此用户没办法判断生成的查询结果对不对。哪怕有 1% 的错误率,这个错误率还是不能忍受的,这就很难商用。

另外一个方面,大模型的能力目前只是达到一个入门级的水平,达不到专家级。华为的一个高管给我们开会的时候就有一个很有意思的说法:如果你是领域专家,你会觉得大模型很笨;但是如果你是领域的小白,你就会发现大模型非常聪明。我们相信基础大模型一定会进步到专家级,但是现在我们不能坐等基础大模型的进步。

我们可以把大模型当成一个干活非常快但不太靠谱的初级员工。我们可以让大模型做一些初级的工作,比如写一些基础的 CRUD 代码,比人写得还快。但是你让他去设计系统架构,去做研究解决技术前沿问题,那是不靠谱的。我们在公司里也不会让初级员工去做这些事情。有了大模型之后,相当于有了大量又便宜干活又快的初级员工。怎么把这些初级员工用好,是一个管理问题

我的导师在我刚开始读博的第一次会议上,就让我们学一些管理。当时我还不太理解为啥做研究还要学管理,现在我觉得导师讲得太好了。现在重要的研究项目基本上都是团队作战,就必须要管理了。有了大模型之后,我们的团队中又增加了一些 AI 员工,这些 AI 员工还不太靠谱,管理就更重要了。

AutoGPT 就是按照德鲁克的管理学方法,把这些 AI 员工组织成一个项目,分工合作完成目标。但 AutoGPT 的流程还是相对僵化的,因此经常在一个地方原地转圈圈,或者走进死胡同里。如果把企业中管理初级员工的一套机制、项目从立项到交付的一套流程引入 AutoGPT,可以让 AI 员工干得更好,甚至有可能做成像 Sam Altman 说的那样,只有一个人的公司。

当前有用的 AI Agent 大致可以分成两类:个人助理和商业智能。

个人助理类的 AI Agent,其实已经存在很多年了,比如手机上的 Siri、小度智能音箱。最近一些智能音箱产品也接入了大模型,但是由于成本问题还不够聪明,语音响应延迟还比较高,而且也没有办法做 RPA 跟手机 App 或者智能家居设备互动。但这些技术问题最终都是能解决的。

很多创业公司都想做通用的语音助手或者智能音箱,但我觉得这些大厂还是有入口优势。大厂不做是因为成本、隐私等多方面的考虑,一旦大厂哪一天下场了,创业公司有什么竞争优势?反倒是结合一些品牌 IP 做智能互动手办,或者 Rewind、AI Pin 这些有设计感的智能硬件,可能有一些空间。

商业智能类的 AI Agent,数据和行业 know-how 是护城河。数据是大模型的关键,特别是行业知识,公开语料中可能根本没有。OpenAI 不仅强在算法上,更是强在数据上。

在产品方面,我认为基础模型公司应该学习 OpenAI 的 1P-3P 产品法则。什么意思呢?只要一两个人(1P)开发的产品就自己(first Party)做,需要三个人(3P)以上开发的产品就让第三方(third Party)做。

比如 OpenAI API、ChatGPT、GPTs Store 这些产品,都不是特别复杂,一个人做个 demo 足够了。就算是比较成熟的产品,也不需要一个很大的团队。这种就是 1P 产品。

而比较复杂的行业模型、特定场景下复杂任务的规划求解、复杂的记忆系统,就不是一两个人能够搞定的。这种 3P 产品就适合让第三方去做。

基础模型公司应该专注于基础模型能力和 infra,相信 scaling law,而不是不断打补丁。基础模型公司最忌讳的就是投入大量高级工程师和科学家去做雕花的事情,搞了一堆 3P 产品,最后又没有相关的客户关系,卖不出去。3P 产品最重要的可能是数据、行业 know-how 和客户资源,不一定是技术。

这就是为什么上一波 AI 创业公司很难赚钱,因为上一波 AI 不够通用,最后都是一些需要大量定制的 3P 产品,坐拥大量高薪科学家的明星创业公司反倒不一定打得过雇了一堆大专程序员的接地气公司,后者虽然估值上不去,甚至都入不了投资人的法眼,但现金流每年都是正的。

下面几个 “有用 AI” 的例子都是一两个人可以开发的 1P 产品,其实也很有用了。

counter(h2) . counter(h3) . counter(h4) . counter(h5) . 有用 AI 的 1P 产品例子

第一个有用 AI 的例子是导游,这也是我开始创业之后尝试做的第一个 AI Agent。

当时我一个人来美国出差,同住的几个朋友要么工作很忙要么比较宅,而我很喜欢出去玩。我在 LA 的朋友也不多,所以我就想做一个 AI Agent 陪我一起出去玩。

我发现 GPT-4 真的知道很多著名景点,甚至还能帮你做行程规划。比如说我要去约书亚树国家公园玩一天,就可以规划出早上去哪、中午去哪、下午去哪,每个地方的停留时间还都比较合理。当然要用英文问,用中文的效果就会差一些。可以说网上有旅游攻略已经包含了这些信息,但用搜索引擎把合适的攻略找出来并不容易。之前我每次出去玩都要提前一天做攻略,现在路上跟 AI Agent 聊几句就都搞定了。

我去 USC 玩的时候,刚进校园就遇到了一波游客,他们想找个学生带他们逛校园。我就说我也是第一次来 USC,但是我是做 AI Agent 的,可以让 AI Agent 带我们转一转。老外游客们很 nice 的就跟我一起走了。AI Agent 给我们推荐了 USC 校园最著名的几个建筑。每到一个景点,我会让 AI Agent 语音讲讲这里的历史,大家觉得就像请了个导游一样靠谱,说 ChatGPT 也应该增加这个功能。第二天的 OpenAI dev day 上展示的应用场景果然就有旅行助理。

朋友带我去约书亚树国家公园玩的时候,门口有一个 “禁止露营” 的标志,我们不知道是啥意思,就分别用 GPT-4V 和我们公司的 AI Agent 去做图片识别,结果 GPT-4V 答错了,我们的 AI Agent 反而答对了。当然这不是说我们的 AI Agent 比 GPT-4V 还厉害,对错都是有概率的。一些知名的地标 AI Agent 也是可以识别出来的,比如斯坦福校园的纪念教堂。

不要小看大模型知道很多著名景点这个能力。论知识面,没有人能够比得过大模型。比如 2022 年,有个朋友跟我说住在尔湾,我那时候甚至没有听说过尔湾。我问尔湾在哪,朋友说尔湾在橙县,橙县在加州,我查了半天地图和 Wiki 才搞清楚尔湾、橙县到底是个什么关系,为啥不直接说是在洛杉矶。我老婆前段时间也分不清尔湾和湾区。我们也不算信息特别闭塞的人,但每个地方的生活常识并不是看起来那么显然。

去过这些地方的人会觉得这些常识很容易记住,那是因为人输入的是多模态数据。现在的大模型可没有地图和图片可看,仅靠文本训练语料就能够上知天文,下知地理,已经很不容易了。

第二个有用 AI 的例子,也是我在华为探索过的项目,是企业 ERP 助手

用过 ERP 系统的都知道,从复杂的图形界面里找到一个功能非常困难,而且有些需求很难点点图形界面就能完成,因此要么把数据导出到 Excel 表里面处理,甚至还得用 Pandas 这类专门的数据处理工具。

我们知道大多数人都能把需求用自然语言描述清楚。大模型就提供了一种全新的自然语言用户界面(LUI),用户描述自己的意图,AI Agent 就可以把活干完。GUI 是所见即所得,LUI 是所想即所得

大模型并不擅长处理大量数据,因此 ERP 助手并不是让大模型处理原始数据,而是用大模型将用户的自然语言需求自动转换成 SQL 语句,然后再去执行 SQL 语句。这个代码生成的路线在很多场景下都是比较靠谱的,这里的代码不一定是 SQL、C、Python 这样的通用编程语言,也包括 IDL(接口描述语言),也就是特定的数据格式。比如大模型要调用 API,输出的文本格式奇奇怪怪,让大模型输出特定格式的 JSON 就老实了。

我最早在华为探索企业 ERP 助手的时候,大模型的基础能力还比较差,因此生成的 SQL 语句错误率比较高,而且也不够稳定。但用 GPT-4 生成 SQL 语句的准确率还是挺高的。

利用 GPT-4,我跟国科大合作的一个 AI Agent 实践课题,没有很多 AI 基础的本科和研究生同学也能从头独立实现企业 ERP 助手,不仅能支持这一页 PPT 上左边显示的这 10 个只读查询,同学们还自己实现了增加、删除、修改数据的支持,右边这 7 个修改查询也都支持了。

大家可以看到,这里面的很多需求都是挺复杂的,如果要程序员在 GUI 上开发这些需求,一个人估计至少得搞一周。而且 ERP 的开发是一个从需求到设计、实现、测试、发布的流程,整个流程走下来,不知道多久过去了,而且中间产品经理的信息传递可能还存在误差。

因此传统 ERP 行业的本质挑战就是各行各业无穷无尽的定制化需求和有限的开发人力之间的矛盾,开发 ERP 的产品经理和程序员不懂行业 know-how,这些宝贵的行业 know-how 就很难通过流程的方式沉淀下来。大模型有望通过 “意图驱动” 也就是 “所想即所得” 的方式彻底改变 ERP 的产品逻辑。

未来每个程序员都有大模型辅助之后,需求描述能力、架构设计能力和技术表达能力一定是最重要的。因为每个程序员可能都相当于一个架构师 + 产品经理 + committer,指挥着一堆 AI Agent 作为 “基层 AI 程序员”,给这些 AI Agent 布置需求、设计架构、验收代码,还需要跟真人同事和上级沟通和汇报工作。

我发现很多基层程序员恰恰是在需求描述、架构设计、技术表达这几方面存在欠缺,只会闷头写代码。特别是技术表达能力,每次任职资格答辩都不能用 What-Why-How 的方式有条理的讲清楚自己做的东西。私下里还觉得万般皆下品,唯有代码高,把技术表达能力强的同事称为 “PPT 专家”。那未来真的是有被淘汰的风险

第三个有用 AI 的例子是大模型采集数据

收集数据是一件非常麻烦的事情。比如,如果要收集一个实验室里每个教授和学生的信息,例如需要包括如下信息:

  • 姓名
  • 照片(如果有,就下载下来,注意网页上的图片不一定是人的照片)
  • E-mail
  • 职称(例如:教授)
  • 研究方向(例如:数据中心网络)
  • 简介

专业的数据采集公司是用正则表达式或者 HTML 元素路径匹配页面中固定位置的内容,每个版式不同的页面都需要 1 小时左右的开发时间来定制爬虫,开发成本很高。对于每个院系、实验室、老师主页格式都不相同的情况,开发这种匹配页面中固定位置的爬虫,有时还不如手工一个一个页面访问,复制粘贴快。

而且还有一些网页上有反爬机制,例如把邮箱写成 bojieli AT http://gmail.com 这种格式,虽然通过正则表达式也能匹配出其中一些情况,但总是无法穷尽所有情况。

大模型采集数据其实就是让大模型模拟人去点击网页,读网页中的内容,提取网页中的内容,网页中的每个字都经过大模型的 “大脑” 读了一遍。因此,大模型采集数据本质上就是利用了大模型阅读速度比人快这个特点。

具体来说,就是自动找到网页中的所有链接,访问链接,将网页内容转换成文本,调用 GPT-4 判断是否是教师或学生主页,如果是的话,就用 JSON 格式输出姓名、E-mail 等信息。然后解析 JSON,存入数据库。对于老师照片,可以使用 GPT-4V 对网页中的图片进行分析,判断是否是单人照片,如果是单人照片就保存下来。

大模型提取网页中的内容有什么缺点呢?如果用 GPT-4,缺点就是成本高,读一个网页的成本大约需要 0.01~0.1 美金。而传统爬虫的数据采集方法,一旦写好爬虫脚本,爬一个网页的 CPU 和带宽成本只有万分之一美金,几乎可以忽略不计。

好在这种姓名、邮箱等基本信息提取并不需要 GPT-4 这么强的模型,GPT-3.5 级别的模型就足够了。识别图片是否包含单张人脸,也有传统 CV 的人脸检测算法。要获取其他照片并做标注的话,MiniGPT-4/v2 这样的开源多模态模型也足够了。这样读一个网页的成本就是 0.001~0.01 美金。

如果我们觉得 GPT-3.5 Turbo 读一个长网页的 0.01 美金还是太高了,可以先截取网页中开头的部分,如果识别出确实是教师主页,但内容中缺失具体信息,再去读后续的网页内容。这就像人肉数据采集一样,大多数教师主页中想要的数据都在开头部分。这样读一个网页的成本可以控制在 0.001 美金,就完全可以接受了。

第四个有用 AI 的例子是手机语音助手。这个领域叫做 RPA(机器人流程自动化),听起来这里面有个机器人,但其实不一定需要有具身智能那种机器人,Robotics 是个很广阔的领域。

传统的 RPA 都是程序员写好流程去操作固定的 app,比如按键精灵,还有 Siri 之类的语音助手。但是 Siri 目前的能力还非常有限,只能完成系统预设的简单任务,不能完成任意的复杂任务。

基于大模型的手机语音助手可以自动学习各种手机 app 的操作,是一个通用的能力。比如腾讯的 AppAgent,可以自动学习操作 Telegram、YouTube、Gmail、Lightroom、Clock、Temu 等多款 app,不需要人去教它怎么用。

RPA 的主要难点是学习使用 app 的过程,比如一个修图的 app,怎么找到 app 中打马赛克的功能在什么位置。因此 RPA 需要一个探索学习的过程,首先尝试使用 app 中的各种功能,并记录下来操作序列。在后续使用的过程中,先想要用哪种功能,再按照操作序列去操作。

腾讯的 AppAgent 用的是视觉方案。它的核心逻辑是基于视觉大模型的,围绕着屏幕截图进行自动操作:

  1. 打开指定的 app,截图;
  2. 将截图和任务当前的执行状态文本输入到视觉大模型里,大模型决定下一步应该怎么操作;如果大模型判定任务已经完成,就退出;
  3. 模拟点击执行对应的操作,回到步骤 1。

视觉方案的优点是仅依赖屏幕截图,通用性强。

视觉方案的缺点是由于视觉大模型的分辨率限制,细小屏幕组件,比如一些 checkbox,可能识别不准确;由于视觉大模型本身不擅长处理大块文字,就像我们在多模态大模型部分讲的一样,大块文字识别需要 OCR 辅助;最后就是成本较高,特别是对于需要滚动才能显示完整的界面,需要截屏多次才能获取完整内容。

考虑到以上缺点,一些手机厂商和游戏厂商用的是元素树方案。手机厂商是想做类似 Siri 的系统级语音助手。而游戏厂商做的是游戏陪玩 NPC。

手机 App 的界面就像网页的 HTML 一样,都是一棵元素树。元素树方案就是从系统底层直接获取到这个元素树的内容,交给大模型处理。

元素树方案的优点是识别准确率高,成本较低,无需 OCR 和视觉大模型。

元素树方案的缺点是需要操作系统底层 API 权限,因此基本上只有手机厂商能做。由于通用大模型的训练数据中几乎没有元素树,缺少元素树的理解能力,因此需要构造数据做继续预训练或微调。此外,元素树往往较大,有可能导致输入上下文过长,需要筛选可视部分输入到大模型。

最后一个有用 AI 的例子是会议和生活记录器

比如我们在开会的时候摸鱼,正好被老板 cue 到,就一脸懵;还有会上老板一下子布置了一大堆任务,没有来得及记下来,会后就忘了。

现在腾讯会议和 Zoom 都已经有了 AI 会议助手的功能,包括将会议语音内容实时转录成文字;根据实时转录的文字,将会议所讲过的内容做总结;根据实时转录的文字,用户提出问题,大模型给出问题的回答。这样,参加会议的人不管何时加入会议,都能知道会上都讨论了些什么内容,再也不用担心错过关键的会议内容了。

但是,现在腾讯会议和 Zoom 的语音转录中,由于缺少背景知识,可能存在一些错误,例如专业名词识别错误、人名前后不一致。如果通过大模型对语音识别结果进行修正,大部分识别错误的专业名词都可以被纠正,前后的人名也能保持一致。

语音识别的准确率还可以进一步提升。会议中往往会共享一些 PPT,我们不仅希望把这些 PPT 保存下来,这些 PPT 内容中往往也包含了关键的专业名词。把从 PPT OCR 出的内容作为参考文本,让大模型修正语音识别结果,可以进一步提升准确率。

我是一个喜欢把生活中的一切都记录下来的人,比如我维护了一个 2012 年以来,我走过的城市 公开记录。虽然各类 App 都记录了很多个人数据,比如聊天记录、运动健康、点外卖记录、购物记录等,但这些 App 的数据是烟囱化的,无法导出,也就无法聚合各类 App 的数据来做分析

AI Agent 给我们提供了新的可能,可以通过 RPA 或 Intent-based API 方式收集生活记录。现在 App 不支持的时候,就是用前面手机语音助手讲到的 RPA 方法,相当于一个干活很快的秘书在从各个 App 里面把数据一条条抄录出来。未来 App 提供了面向手机助手的 Intent-based API,收集数据就更灵活了。

Rewind.AI 的录屏和录音吊坠是我很喜欢的产品,Rewind 可以回放任意时间的录屏。Rewind 还可以根据关键字搜索之前的录屏,Rewind 是把录屏里面的文字做了 OCR,这样就可以根据文字搜索到之前的录屏。但是目前只支持英文,不支持中文。Rewind 还支持 AI 智能问答,问它某一天都做了什么事情,访问了哪些网站,能给总结的非常好。Rewind 的能力真的强到可怕,可以用来做自己的记忆助手,看看之前干了什么。也可以用来自己做时间管理,看看有多少时间浪费在无用的网站上。

Rewind 更可怕的是可能被老板用来监控员工,以后都不用员工自己写日报周报了,直接让 Rewind 写,保证公正客观,干了啥就是啥。其实现在一些大厂的信息安全已经用了类似的录屏或者定时截屏的机制,在公司电脑上搞小动作,事后很容易被追溯。

Rewind 最近还出了一个吊坠,这个吊坠就是个录音笔 + GPS 记录仪,会全天记录你去了哪,说了什么话。我还不敢随身带录音笔,因为未经同意就对私人交谈录音不太好。但是我的确带着个迷你 GPS 记录仪,每分钟打一个点,可以轻松记录我的足迹。之所以不用手机是因为手机一直开着 GPS 太费电了。

对于我这种喜欢记录生活的人,以及用了 Rewind 这类产品的人,隐私是最大的顾虑。现在 Rewind 的很多数据会上传到云端,就让我不太放心。我认为本地化算力或者隐私计算是解决隐私问题的必由之路。本地化就是在个人设备本地运行,目前一些高端手机和笔记本已经可以跑相对较小的大模型了。隐私计算是另一种方法,就是用密码学或者 TEE 的方法保证隐私数据可用不可见。

counter(h2) . counter(h3) . counter(h4) . counter(h5) . 解决复杂任务和使用工具

前面在有趣的 AI 部分,我们介绍了 AI Agent 慢思考的记忆和情感方面。记忆是有趣和有用 AI 都必须具备的公共能力。情感是有趣 AI 需要的。而解决复杂任务和使用工具更多是有用 AI 所需的能力,因此我们在这里稍作讨论。

第一个例子是一道比较复杂的数学问题,一个人一秒钟也回答不出来。那我们只给大模型一个 token 的思考时间,让大模型听完题目就马上回答,显然也是不可行的。

大模型需要时间去思考,token 就是大模型的时间。我们让大模型写出思考过程,就是给它时间思考。思维链是非常自然的一种慢思考的模式,我一般把思维链通俗地称作 “先想后说”,这是一种非常有效的提升大模型性能的方式。特别是对于输出很简洁的场景,一定要让大模型先写出思考过程再按照格式输出回答。

第二个例子是用多步的网络搜索去回答难题。比如这个问题,David Gregory 继承的城堡有多少层,直接上 Google 搜索是无法在一个网页中得到答案的。

人类是怎么解决这个问题的?人会分多个子阶段去解决,首先搜索 David Gregory 这个人,知道他继承的城堡是什么名字,然后搜索这个城堡,找到它有多少层。

在让 AI 学会拆分子问题之前,首先需要解决 AI 的幻觉问题。当它拿整句话去搜索的时候,也能搜索到一个 Wiki 词条,其中也有一段提到了层数,AI 可能就直接拿这个层数作为答案输出了,但这根本不是他继承的城堡。解决幻觉问题可以让它不要只是输出层数,而是先输出参考的这一段落内容,并比较与原问题的相关性,这样通过 “先想后说” 和 ”反思“,就可以减少一些幻觉

如何让 AI 拆分子问题呢?直接告诉大模型就行了,用 few-shot 方式提供几个拆分子问题的示例,让大模型把这个问题拆分成一个更简单的搜索问题。然后把搜索结果和原始问题输入到大模型,让它输出下一步搜索的问题。直到大模型认为根据搜索结果已经可以可信地回答原始问题。

多步网络搜索解决问题其实是一个更大问题的子集,这个更大的问题是复杂任务的规划和分解

例如,我们给定一篇论文,问它的第二章相比某个相关工作有什么贡献。

首先,AI 怎么找到第二章的内容。如果我们没有长上下文,而是把文章切片之后用 RAG 方式搜索,那么第二章内容的每一段不会写着第二章,RAG 就很难检索出来。当然我做一个特殊情况的处理逻辑是可以的,但是一般情况下这种章节编号问题需要在 RAG 索引的时候就添加进去元数据。当然如果模型有长上下文能力,并且成本可以接受,一次性把整篇文章都放进去是最好的。

第二,这个相关工作是在另外一篇论文里,怎么把这篇论文找出来,有时只用一个关键词是搜不到的,重名的内容太多,因此需要结合原文内容中的更多关键词去搜索。搜索到这篇相关工作之后还要总结这篇相关工作的内容,然后用大模型生成第二章和这篇相关工作的对比。

另一个复杂任务规划分解的例子是查天气。查天气看起来好像挺简单,点一下网页就行了。但是我们如果让 AutoGPT 去查一个特定城市的天气,现在大多数情况是失败的。为什么呢?

首先它会尝试去找一些查天气的 API,还真的会去查这些 API 文档,尝试写代码调用,但是都失败了,因为这些 API 都是付费的。这就说明大模型缺少一些常识,比如 API 一般是需要付费的,而且在尝试多个 API 失败之后,没有向用户求助,而是不断在死胡同里尝试。现实世界中一个人完成任务遇到困难会去求助,有用的 AI 也应该这样,及时向用户反馈进展,有问题及时求助用户

API 查询失败之后,AutoGPT 就会开始尝试从网页里面读取天气。AutoGPT 的搜索词和搜索到的页面都是正确的,但仍然不能正确提取出天气信息。因为 AutoGPT 看的是 HTML 代码,HTML 代码乱七八糟的,它看不懂,其实我作为一个人也看不懂。

AutoGPT 也会尝试把网页内容转换成文本之后再提取,但是像右面这个天气网页,提取出纯文本之后也有问题。这个网页上有很多不同的温度,有的是别的城市的,有的是别的时间的,单靠纯文本很难区别。文本丢掉了太多的网页结构信息,HTML 代码又不好看懂,怎么办?

比较靠谱的方案其实是把渲染出来的网页截图放到多模态模型里面去。比如 GPT-4V 读取这个天气截图就没有问题。但是用 MiniGPT-4/v2 这些开源多模态模型仍然很困难。它的主要问题是并不支持任意分辨率的输入,只支持 256 x 256 的小分辨率,网页截图压到这么小的分辨率后根本就看不清上面的字了。因此 Fuyu-8B 这些开源多模态模型支持任意分辨率是一个非常关键的事情。

从上面两个查论文和查天气的例子可以看到,复杂任务的规划和分解很大程度上是模型基础能力的问题,需要依靠 scaling law,模型基础能力上去了,自然就解决了。在系统方面,与用户交互式解决复杂任务是很重要的,AI 遇到困难要及时求助。

第三个例子是 AI 需要能够按照流程调用工具。使用工具是 AI 一项非常基本的能力。

比如要解决一道高中物理题,需要首先调用 Google 搜索获取到相关的背景知识,然后调用 OpenAI Codex 生成代码,最后调用 Python 执行代码。

实现按流程调用工具的方法是 few-shot,也就是在 prompt 中给 AI 提供几个样例任务的执行过程,这样 AI 就可以参考样例任务的流程,逐次生成对流程中每种工具的调用。

上一页是按照指定的顺序使用三种工具。但如果我们有多种工具需要根据任务类型按需使用呢?有两种典型的路线,一是以 GPT Store 为代表的工具调用大模型,二是以 ChatGPT 为代表的大模型调用工具

在 GPT Store 中,用户已经显式指定了要用哪个工具,工具的 prompt 是 GPT Store 中的应用预先写好的。这种方法其实并没有解决根据任务类型按需使用工具的问题。

在 ChatGPT 中,有浏览器、图片生成、日记本、代码解释器等几个内置的工具,它是在 system prompt 中把几种工具的使用说明书都写了进去

ChatGPT 模型在训练阶段也加入了调用工具的特殊 token。模型如果需要调用工具,就输出调用工具的特殊 token,这样 ChatGPT 就知道后面输出的是工具调用代码而非普通文本。工具调用完成之后,再把工具的结果输入到模型,生成下一个工具调用,或者给用户的输出。

我在 2024 年 2 月 15 日测试的 ChatGPT system prompt 如下:

You are ChatGPT, a large language model trained by OpenAI, based on the GPT-4 architecture. Knowledge cutoff: 2023-04 Current date: 2024-02-15

Image input capabilities: Enabled Personality: v2

# Tools

## bio

The `bio` tool allows you to persist information across conversations. Address your message `to=bio` and write whatever information you want to remember. The information will appear in the model set context below in future conversations.

## dalle

// Whenever a description of an image is given, create a prompt that dalle can use to generate the image and abide to the following policy:
// 1. The prompt must be in English. Translate to English if needed.
// 2. DO NOT ask for permission to generate the image, just do it!
// 3. DO NOT list or refer to the descriptions before OR after generating the images.
// 4. Do not create more than 1 image, even if the user requests more.
// 5. Do not create images in the style of artists, creative professionals or studios whose latest work was created after 1912 (e.g. Picasso, Kahlo).
// - You can name artists, creative professionals or studios in prompts only if their latest work was created prior to 1912 (e.g. Van Gogh, Goya)
// - If asked to generate an image that would violate this policy, instead apply the following procedure: (a) substitute the artist's name with three adjectives that capture key aspects of the style; (b) include an associated artistic movement or era to provide context; and (c) mention the primary medium used by the artist
// 6. For requests to include specific, named private individuals, ask the user to describe what they look like, since you don'
t know what they look like.
// 7. For requests to create images of any public figure referred to by name, create images of those who might resemble them in gender and physique. But they shouldn't look like them. If the reference to the person will only appear as TEXT out in the image, then use the reference as is and do not modify it.
// 8. Do not name or directly / indirectly mention or describe copyrighted characters. Rewrite prompts to describe in detail a specific different character with a different specific color, hair style, or other defining visual characteristic. Do not discuss copyright policies in responses.
// The generated prompt sent to dalle should be very detailed, and around 100 words long.
// Example dalle invocation:
// ```
// {
// "prompt": "<insert prompt here>"
// }
// ```

namespace dalle {
// Create images from a text-only prompt.
type text2im = (_: {
// The size of the requested image. Use 1024x1024 (square) as the default, 1792x1024 if the user requests a wide image, and 1024x1792 for full-body portraits. Always include this parameter in the request.
size?: "1792x1024" | "1024x1024" | "1024x1792",
// The number of images to generate. If the user does not specify a number, generate 1 image.
n?: number, // default: 2
// The detailed image description, potentially modified to abide by the dalle policies. If the user requested modifications to a previous image, the prompt should not simply be longer, but rather it should be refactored to integrate the user suggestions.
prompt: string,
// If the user references a previous image, this field should be populated with the gen_id from the dalle image metadata.
referenced_image_ids?: string[],
}) => any;
} // namespace dalle

## browser

You have the tool `browser`. Use `browser` in the following circumstances:

- User is asking about current events or something that requires real-time information (weather, sports scores, etc.)
- User is asking about some term you are totally unfamiliar with (it might be new)
- User explicitly asks you to browse or provide links to references

Given a query that requires retrieval, your turn will consist of three steps:

1. Call the search function to get a list of results.
2. Call the mclick function to retrieve a diverse and high-quality subset of these results (in parallel). Remember to SELECT AT LEAST 3 sources when using `mclick`.
3. Write a response to the user based on these results. In your response, cite sources using the citation format below.

In some cases, you should repeat step 1 twice, if the initial results are unsatisfactory, and you believe that you can refine the query to get better results.

You can also open a url directly if one is provided by the user. Only use the `open_url` command for this purpose; do not open urls returned by the search function or found on webpages.

The `browser` tool has the following commands:

`search(query: str, recency_days: int)` Issues a query to a search engine and displays the results.

`mclick(ids: list[str])`. Retrieves the contents of the webpages with provided IDs (indices). You should ALWAYS SELECT AT LEAST 3 and at most 10 pages. Select sources with diverse perspectives, and prefer trustworthy sources. Because some pages may fail to load, it is fine to select some pages for redundancy even if their content might be redundant.

`open_url(url: str)` Opens the given URL and displays it.

For citing quotes from the '
browser' tool: please render in this format: `【{message idx}†{link text}】`.

For long citations: please render in this format: `[link text](message idx)`.

Otherwise do not render links.

## python

When you send a message containing Python code to python, it will be executed in a stateful Jupyter notebook environment. python will respond with the output of the execution or time out after 60.0 seconds. The drive at '
/mnt/data' can be used to save and persist user files. Internet access for this session is disabled. Do not make external web requests or API calls as they will fail.

## voice_mode

// Voice mode functions are not available in text conversations.
namespace voice_mode {
} // namespace voice_mode

## Model Set Context

1. [2024-02-14]. Obtained PhD from Microsoft Research Asia and USTC in 2019.
2. [2024-02-14]. Running an early-stage AI startup since July 2023.
3. [2024-02-14]. Loves writing blogs, traveling and documenting everything.
4. [2024-02-15]. Experience in writing Python.
5. [2024-02-15]. Interested in digital extension of humanity.
6. [2024-02-15]. First met ChatGPT on Dec. 1st, 2023.

ChatGPT 这种路线确实解决了根据任务类型按需使用工具的问题。但由于 prompt 的长度有限,它只能使用内置的有限几种工具,不可能调用 GPT Store 中的上万种工具。因为上万个工具的说明书如果都摊开在桌面上,就太长了

那么如何让大模型学会自动按需使用上万种工具呢?这里有两种观点。

第一种观点认为,工具使用属于过程记忆,使用场景和条件不是语言可以明确描述的。工具本身的使用方法确实可以用语言描述清楚,这就是说明书,关键是何时使用何种工具。比如,GPT-4 经常算错数,它就需要知道在算数的时候调用计算器这个工具。这就需要使用 fine-tuning 方法告诉模型一些工具使用的样例,甚至在预训练时就加入。这种方案的主要缺点是工具更新复杂,要想更新工具就要重新做 fine-tuning。

第二种观点认为,工具使用可以用代码形式表达,因此属于代码生成能力。这样,就可以使用 RAG 方法匹配用户输入的文字,找到候选的工具集合,把工具的说明书像 ChatGPT 那样放进 prompt,然后就可以使用了。这种方案的主要缺点是依赖 RAG 的准确率。此外,如果工具是在输出过程中临时需要使用的,这种方法就不奏效。例如 GPT-4 算错数的例子,可能用户输入文字中并没有显式要求它算数,但解决问题的过程中需要算数,这时候它肯定就不知道应该调用计算器这个工具。

幻觉是大模型的基础问题,更大的模型幻觉相对会较少,幻觉的消除根本上还是要靠 scaling law,靠基础模型的进步。但也有一些工程方法减少现有模型的幻觉。这里介绍两种典型的方法:事实性校验和多次生成。

事实性校验(Factual Checking)就是首先用大模型生成回答,然后用 RAG 的方法,用搜索引擎、向量数据库、倒排索引或者知识图谱找出与回答内容匹配的原始语料,然后将回答内容和原始语料送进大模型,让大模型判断回答与原始语料是否相符。

事实性校验方法有两个问题:首先,幻觉有多种种类,事实性校验只能发现编造事实类的幻觉,但不能发现答非所问类的幻觉。比如我问中国的首都是哪里,它回答中国是一个有悠久历史的大国,用事实性校验也挑不出毛病,但这并没有正确回答问题。其次,原始语料的内容不一定就是事实,互联网上有大量不准确的信息。

多次生成是 SelfCheckGPT 这篇论文提出的,它的思想也很简单,就是多次生成同一问题的回答,然后把这些回答都放进大模型里,让大模型从中挑出最一致的那个。多次生成方法可以解决偶发的幻觉问题,但不能解决系统性偏差。例如让 GPT-3.5 Turbo 讲讲 “林黛玉倒拔垂杨柳” 的故事,几乎每次都会编一个类似的出来,而没有发现这个事件在历史上就不存在,这种幻觉就是多次生成很难消除的。

AI Agent:路在何方

counter(h2) . counter(h3) . counter(h4) . counter(h5) . 有趣和有用的 AI 谁价值更高

好看的皮囊、有趣的灵魂、有用的 AI、低成本和去中心化,我们在努力研发 AI Agent 的完整技术栈,并且在几乎每个方面都有所创新。

我们希望用 AI Agent 赋予每个人无限时间。我们相信,在人类世界的数字延伸中,有趣的灵魂终会相遇。

来源:统计之都


编辑:瓷瓷

(声明:请读者严格遵守所在地法律法规,本文不代表任何投资建议)

本文来源:元宇宙头条 文章作者:元宇宙头条
收藏
举报
元宇宙头条
累计发布内容523篇 累计总热度10万+
523篇 10万+
FTX 后院起火,Binance 釜底抽薪
FTX 后院起火,Binance 釜底抽薪
FTX 后院起火,Binance 釜底抽薪

元宇宙头条现已开放专栏入驻,详情请见入驻指南: #

免责声明:
1、本文版权归原作者所有,仅代表作者本人观点,不代表元宇宙头条观点或立场。
2、如发现文章、图片等侵权行为,侵权责任将由作者本人承担。

评论 共0条
默认
|
点赞
说点什么吧
相关文章
您需要登录后才可以回帖 立即登录

元宇宙头条
个人认证
热门文章

下载APP

微信公众号