原华为“天才少年”4万字演讲,谈谈天才眼中的AI
首先它会尝试去找一些查天气的 API，还真的会去查这些 API 文档，尝试写代码调用，但是都失败了，因为这些 API都是付费的。这就说明大模型缺少一些常识，比如 API 一般是需要付费的，而且在尝试多个 API失败之后，没有向用户求助，而是不断在死胡同里尝试。现实世界中一个人完成任务遇到困难会去求助，有用的 AI也应该这样，及时向用户反馈进展，有问题及时求助用户。
API 查询失败之后，AutoGPT 就会开始尝试从网页里面读取天气。AutoGPT的搜索词和搜索到的页面都是正确的，但仍然不能正确提取出天气信息。因为 AutoGPT 看的是 HTML 代码，HTML代码乱七八糟的，它看不懂，其实我作为一个人也看不懂。
AutoGPT也会尝试把网页内容转换成文本之后再提取，但是像右面这个天气网页，提取出纯文本之后也有问题。这个网页上有很多不同的温度，有的是别的城市的，有的是别的时间的，单靠纯文本很难区别。文本丢掉了太多的网页结构信息，HTML代码又不好看懂，怎么办？
比较靠谱的方案其实是把渲染出来的网页截图放到多模态模型里面去。比如 GPT-4V 读取这个天气截图就没有问题。但是用MiniGPT-4/v2 这些开源多模态模型仍然很困难。它的主要问题是并不支持任意分辨率的输入，只支持 256 x 256的小分辨率，网页截图压到这么小的分辨率后根本就看不清上面的字了。因此 Fuyu-8B这些开源多模态模型支持任意分辨率是一个非常关键的事情。
从上面两个查论文和查天气的例子可以看到，复杂任务的规划和分解很大程度上是模型基础能力的问题，需要依靠 scalinglaw，模型基础能力上去了，自然就解决了。在系统方面，与用户交互式解决复杂任务是很重要的，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就知道后面输出的是工具调用代码而非普通文本。工具调用完成之后，再把工具的结果输入到模型，生成下一个工具调用，或者给用户的输出。
ChatGPT 这种路线确实解决了根据任务类型按需使用工具的问题。但由于 prompt的长度有限，它只能使用内置的有限几种工具，不可能调用 GPT Store中的上万种工具。因为上万个工具的说明书如果都摊开在桌面上，就太长了。
那么如何让大模型学会自动按需使用上万种工具呢？这里有两种观点。
第一种观点认为，工具使用属于过程记忆，使用场景和条件不是语言可以明确描述的。工具本身的使用方法确实可以用语言描述清楚，这就是说明书，关键是何时使用何种工具。比如，GPT-4经常算错数，它就需要知道在算数的时候调用计算器这个工具。这就需要使用 fine-tuning方法告诉模型一些工具使用的样例，甚至在预训练时就加入。这种方案的主要缺点是工具更新复杂，要想更新工具就要重新做fine-tuning。
第二种观点认为，工具使用可以用代码形式表达，因此属于代码生成能力。这样，就可以使用 RAG方法匹配用户输入的文字，找到候选的工具集合，把工具的说明书像 ChatGPT 那样放进prompt，然后就可以使用了。这种方案的主要缺点是依赖 RAG的准确率。此外，如果工具是在输出过程中临时需要使用的，这种方法就不奏效。例如 GPT-4算错数的例子，可能用户输入文字中并没有显式要求它算数，但解决问题的过程中需要算数，这时候它肯定就不知道应该调用计算器这个工具。
幻觉是大模型的基础问题，更大的模型幻觉相对会较少，幻觉的消除根本上还是要靠 scalinglaw，靠基础模型的进步。但也有一些工程方法减少现有模型的幻觉。这里介绍两种典型的方法：事实性校验和多次生成。
事实性校验（Factual Checking）就是首先用大模型生成回答，然后用 RAG的方法，用搜索引擎、向量数据库、倒排索引或者知识图谱找出与回答内容匹配的原始语料，然后将回答内容和原始语料送进大模型，让大模型判断回答与原始语料是否相符。
事实性校验方法有两个问题：首先，幻觉有多种种类，事实性校验只能发现编造事实类的幻觉，但不能发现答非所问类的幻觉。比如我问中国的首都是哪里，它回答中国是一个有悠久历史的大国，用事实性校验也挑不出毛病，但这并没有正确回答问题。其次，原始语料的内容不一定就是事实，互联网上有大量不准确的信息。
多次生成是 SelfCheckGPT这篇论文提出的，它的思想也很简单，就是多次生成同一问题的回答，然后把这些回答都放进大模型里，让大模型从中挑出最一致的那个。多次生成方法可以解决偶发的幻觉问题，但不能解决系统性偏差。例如让GPT-3.5 Turbo 讲讲 “林黛玉倒拔垂杨柳”的故事，几乎每次都会编一个类似的出来，而没有发现这个事件在历史上就不存在，这种幻觉就是多次生成很难消除的。
AI Agent：路在何方
有趣和有用的 AI 谁价值更高
刚才我们提到了有趣的 AI 和有用的 AI 两个方面，这两个 AI 哪个价值更高呢？
我认为长期来看有用的价值更高，短期来看有趣的价值更高。这就是我们为什么在商业模式上选择有趣的 AI，同时持续探索有用的AI。
因为比如说语音闲聊，一块钱一个小时已经很不容易了，Character AI可能有上千万的用户，但是它每个月实际收入只有上千万美金，大多数是不付费的。但是如果一些在线教育、甚至是更专业领域的比如心理咨询、法律咨询等等它可能收入更高，但是这里边更关键的问题是需要质量和品牌才能产生一个更高的附加价值。
更长远来看，我们的终极目标是 AGI，那么AGI 一定更多是有用的，可以扩展人类能力的边界，让人类做到之前做不到的事情。
但是就目前基础模型的能力而言，有用的 AI距离真正解决复杂问题、扩展人类能力的边界还差得远，只能达到初级水平，达不到专家水平。同时由于幻觉问题，很难用于需要高可靠性的场景。这些问题还很难通过外置系统彻底解决，只能等待基础模型的进步。因此有用的AI 目前最适合做的就是个人生活、工作、学习助手，更适合手机厂商、操作系统厂商和智能硬件厂商去做。
而目前大模型的基础能力已经足以做很多有趣的 AI。如前面所讲的，有趣 AI的好看皮囊和有趣灵魂大多是外置的一套系统，而不是模型本身的基础能力。比如文本大模型的基础能力做到再好，也没办法实现 1.5秒的语音电话延迟，没办法实现长期记忆和 Agent 社交。这套模型外围的系统就是 AI 公司的护城河。
当然有人会说，我做一个支持超长上下文的端到端多模态大模型，超长上下文的成本还足够低，延迟问题和记忆问题就都解决了。我认为基础模型做成这样当然是更好的，但不确定什么时候能出来。产品不能等待未来的未知技术，现在的工程方案也挺好用，而且确实有一定的技术护城河。等到新的模型出来了，再改技术栈就行。就像我们原来用的是VITS 做了一整套语音数据自动清洗和训练的流水线，GPT-soVITS 一出来，用 1 分钟语音 zero-shot的效果就比用几个小时语音微调的 VITS 好很多，原来流水线里的大部分功能就用不到了。
一些人对 “有趣的 AI” 有一些偏见，主要是因为以 Character AI 为代表的产品做得还不够好。CharacterAI 反复强调，自己是基础模型公司，beta.character.ai 这个应用至今还挂在 beta域名上，就是一个测试版的产品。人家根本就没打算用现在形态的 Character AI 赚钱。但很多人看到了它是目前除了 ChatGPT以外最大的 to C 应用，就以为这是一个很好的产品形态，Character AI 的克隆版或者改进版层出不穷。
受到 Character AI 的影响，很多人都以为，有趣的 AI Agent就等于名人、动漫游戏角色的数字分身，用户跟它唯一的交互方式就是闲聊。但很多人都做错了。如果只是闲聊，用户很容易聊个 10～20分钟就不知道该聊什么了，因此用户粘性和付费意愿都低得吓人。
2024 年 1 月初我参加知乎 AI 先行者沙龙的时候，一位嘉宾的发言我认为很有道理：有趣的 AI价值更高，因为娱乐、社交是人的天性，最大的几家互联网公司大部分是娱乐、社交领域的。如果一个好的 AI伴侣真的能给人带来情绪价值，或者游戏中的 AI 真的能让用户沉浸感更强，这样的 AI 不愁没人付费。
成本
大模型广泛应用的一个很大的挑战是成本问题。比如如果我做一个游戏的 NPC，跟玩家不停的交互，如果用 GPT-4来做，成本会高达每小时每个玩家 26 美元，没有任何游戏能烧的起这么多钱。
这是怎么算出来的？假设玩家每分钟交互 5 次，一小时就是 300 次；每次交互需要 8K token 的上下文，500token 的输出，每次交互的成本就是 $0.095；乘一下，成本就是每小时 26 美元。很多人在计算成本的时候只考虑到了输出token，没有考虑输入 token，其实很多场景下输入 token 才是成本的大头。
那么这个成本有没有可能降低 100 倍甚至 1000 倍？答案是肯定的。
我们主要有三个方向：用小模型替代大模型、推理 infra 优化、算力平台优化。
首先，to C应用中的大多数问题用小模型其实就足够了。但有一些复杂问题是小模型解决不了的，这时候就需要找大模型。我们人类社会其实一直就是用这种方式工作的，比如电话客服的普通接线员就足够处理大多数的问题，少数棘手的问题上升到经理解决，这样就可以合理控制成本。
大小模型结合的一个挑战是克服小模型的幻觉，也就是当它自己不知道的时候，不要胡说八道，而要说我不知道，这样才有机会交给更大的模型处理。
其次，推理 infra 中其实有很多值得优化的点。例如现在多模态领域的很多开源模型都没有支持 batching 和 FlashAttention，它们的 GPU 利用率其实不够高。当我们有很多 LoRA 微调模型时，最近也有一些学术界的工作可以实现大量LoRA 的批量推理。持久化 KV Cache 虽然很多人都在提，做成有状态的 API降低每次都重新计算的成本，但没有一个开源软件真的实现了。
最后就是自建算力平台，使用消费级 GPU 做推理。对 24 GB 内存就足够放下的模型，4090 显然是比 H100 和A100 更划算的。
使用开源模型和自建算力平台能够节约多少成本呢？我们在这里对比闭源的 GPT-4、GPT-3.5，以及开源的 Mixtral8x7B 和 Mistral 7B，分别在第三方 API 服务和自建算力平台上的成本。
假设我们的需求都是 8K token 的输入上下文，500 token 的输出。如果我们用 GPT-4，每 1000 个请求就要$135，这是相当贵了。如果用 GPT-3.5，就可以便宜 15 倍，只要 $9，但这也还是挺贵的。
Mistral 8x7B MoE 模型的能力大致与 GPT-3.5 是相当的，用 Together AI 的 API 服务需要$5，又比 GPT-3.5 便宜了一半。如果自己搭建 H100 集群来服务这个 8x7B 模型，价格还能降低一半多，只需要$2。
那么为什么自己服务比 Together AI 的便宜呢？因为任何云服务都要考虑到资源不是 100%占满，用户的请求是有波峰波谷的，平均下来资源利用率能到 30% 就不错了。像我们这种客户算力需求波动很大的小公司，经常出现租了几十块GPU 卡但闲置一个月的情况。因此如果考虑到用户请求的波峰波谷，自己搭建 H100 集群去服务 8x7B 模型未必比调用 API更省钱。
要想进一步省钱，还可以用 7B 模型，Mistral 7B 模型的性能也不错，特别是 UC Berkeley 使用 RLAIF的方法搞了一个基于 Mistral 7B 的 Starling 模型，性能甚至超过 LLaMA 13B 模型。
7B 模型如果使用 Together AI API，只要 $1.7，比 GPT-3.5 便宜 5 倍。如果在 4090上自己搭，只要 $0.4，又便宜了 4 倍。能便宜这么多的主要原因是 Together AI 之类大厂一般是用数据中心级的 GPU做推理，如果我们用消费级的 GPU，成本相比数据中心 GPU 就可以至少降低一半。
4090 上跑 7B 模型的成本比 GPT-3.5 便宜 23 倍，比 GPT-4 便宜 346 倍。原来 $26一个小时的互动游戏 NPC，用 4090 和 7B 模型，就可以做到 $0.075一个小时，这虽然还有点高，但已经是可以接受的了。再加上一些输入上下文的压缩技术，可以把 7B 模型的成本降到 GPT-4 API的千分之一，也就是 $0.026 一个小时，这就是可以接受的了。
其实到了 $0.026 每个小时这种量级，会发现CPU 成本也变成不可忽略的了，因此 CPU上的软件优化也是很重要的。大多数公司的后端服务都是用 Python写的，虽然开发效率高，但是执行效率比较低。因此我们公司最近把后端的核心业务逻辑切换到了 Go，在 CPU 效率上有明显的提升。
上面我们只算了文本模型，其实语音识别模型、语音合成模型、多模态图片识别模型、图片生成模型、视频生成模型也都有很多可以优化的点。
前面讲语音合成的时候，我们提到基于开源的 VITS 自己做语音合成模型可以比 ElevenLabs API 便宜 360倍，如果要达到接近 ElevenLabs 效果的语音克隆，用 GPTs-soVITS，也可以比 ElevenLabs 便宜 100倍。这种成本数量级上的降低是可以从根本上改变商业逻辑的。
再如视频生成，OpenAI 的 Sora 生成 1 分钟的视频大概需要 50 美金的成本，Runway ML 的 Gen2 生成1 分钟视频大概需要 10 美金成本。但如果我们不要这么高的质量，就用 Stable Video Diffusion 去生成，1分钟的视频只要一块 4090 跑 1 个小时，只要 0.5 美金成本。Sora 的视频质量比 SVD 高太多，100倍的成本也许是值得的。但 Runway ML 生成的视频质量可能就不值 20 倍的成本了。
这也是为什么我不建议贸然自己去做基础模型。如果没有拳打 OpenAI、脚踢 Anthropic的实力，在效果上比不过最好的闭源模型，成本上也比不上开源模型。我相信 Runway ML 的 Gen2 推理成本也不会比 StableVideo Diffusion 高太多，ElevenLabs 的语音合成推理成本也不会比 GPT-soVITS高太多，但是这些模型的研发成本高到可怕，都要平摊到 API 的溢价里。
还没有人评论
还可输入500个字！