工程与产品的胜利,深度剖析ChatGPT和聪明地设计基础架构

简介: 工程与产品的胜利,深度剖析ChatGPT和聪明地设计基础架构


机器之心转载

来源:Suits and Hoodies

这里转载一篇深度剖析ChatGPT成功的一篇好文章:ChatGPT 实际上并不是普通人眼中的「黑科技」,而 是持续开放科研的产物 是工程与 品的胜利。 它将促使 Infrastructure 成为最大的赢家

在这个 AI 时代,语言模型已经成为了人机交流的关键工具。而 ChatGPT 则是其中的佼佼者,这个由 OpenAI 训练的模型,以其卓越的理解和生成能力,成为了一个人人景仰的网红:所以第一篇写 ChatGPT ,抛砖引玉,仅代表个人意见,不代表现在或之前供职的企业的观点。

太长了我懒得看没关系,主要是四个观点:

  1. ChatGPT 并不是黑科技,是持续开放科研的产物。
  2. ChatGPT 是工程、产品的胜利。
  3. ChatGPT 不会让人失业,反而会带来更多的机会。
  4. Infrastructure 会是这一场仗当中的赢家,但是要聪明地设计Infra。


有兴趣的读者可以进一步往下读。ChatGPT 是持续开放科研的产物ChatGPT 背后的技术,最主要的一篇文章是 2022 年 OpenAI 发表的论文 InstructGPT 。InstructGPT 的核心思路是之前两条研究线路所带来的:一个是自然语言理解的大规模语言模型 LLM,另一个是带人类反馈的增强学习 RLHF。
大规模语言模型 LLM 在前面几年方兴未艾,从 GPT 开始,往回可以推到 Bert ,这两种都是基于所谓的 Transformer 结构来设计的。而Transformer 的出现本身又是为了解决早期的序列模型(比如说LSTM 和 RNN)的问题所提出来的。很有意思的是这一系列模型多少都采取了不带太强结构的统计方法:“根据周边的词语来预测中间的词语”,或者“根据前面的文字来生成后面的词语”。这和传统的基于语法树的方法很不一样,感兴趣考古的读者可以去看看 PCFG,计算语言学当中很经典的一个算法。RLHF 也是一个近年以来比较流行的算法。增强学习最经典的书应该是 Sutton & Barto 所写的同名著作《Reinforcement Learning》。2004年,Pieter Abbeel 和吴恩达就利用 RL 提出了叫做 Apprenticeship Learning 的方法,来让机器学会复杂的动作,比如说让直升机进行空中转体:2017年开始DeepMind 的一系列工作(电子游戏、围棋等)让 RL 深入人心,ChatGPT 对于对话系统的训练也深得前面这些工作的影响。因此,整体而言,ChatGPT的一系列工作,都在前面有着很深的铺垫,应该说是站在开放科研的肩膀上做出的工作,其中的功底不得不让人叹服。这不是别人做出大模型之后,简单跟进说“我们可以做得更大”,而是在原有的基础上做更多创新的成果。ChatGPT 是工程和产品的胜利有一个问题:ChatGPT 的训练数据,是从哪里来的?我们可以猜测,基础的语言模型,例如GPT-3,训练的数据来源有很多类似 LAION 这样的从网上抓取下来的数据。在此基础上, InstructGPT 的文章当中提到了很有意思的一点:

Starting with a set of labeler-written prompts and prompts submitted through the OpenAI API, we collect a dataset of labeler demonstrations. of the desired model behavior.

也就是说,OpenAI 前序所推出的 playground、GPT-3 API 等等,一边在进行产品和市场的适配的途中,另一方面也给后续的科研带来了大量的数据输入。根据 InstructGPT 的文章披露,当时 OpenAI 雇佣了约 40 名左右的标注人员来提供手工写的文字;这个数字在最近披露的报道中上升到了 1000 名左右。计算机领域有一个短语叫做 human in the loop,将一篇科研文章变成一个prototype,然后再将用户的体验、数据的回流、标注、再训练这个闭环做得非常精准,ChatGPT 在这一个领域当中体现出了高超的工程能力。另外一个问题是,ChatGPT 为什么能够比其他的类似的聊天机器人更加不让人讨厌?除了技术能力超群之外(ChatGPT 的会话质量的确超过之前的会话模型),我认为这和产品边界的定义是非常相关的。ChatGPT 的定位是很轻量级的“Chat”,所以它就算回答出错,也不像其他的产品(尤其是大厂的产品)那样让人讨厌,反而变成一种有趣的谈资。同时,最简的界面让人非常容易上手,“没事聊两句”也是一个不显得有科技产品的距离感的体验。甚至我家女儿也试图上去捉弄 ChatGPT:(我其实觉得,如果有一个像 wx 聊天机器人这样的方式,也许可以进一步做病毒营销,但是 OpenAI 并没有相关的产品可以相互引流,就更显得产品力的强大。当然聊天机器人是不是会有其他各种内容限制,这是另一个话题了。)工程和产品体验会给 ChatGPT 的下一代带来更大优势。试想,一亿人每个月在给 ChatGPT 生成对话数据训练下一代模型,这是现在任何一个研究院,包括一线大厂,所无法企及的。ChatGPT带来更多的机会这个话题稍微有一点被说烂了我就不多说了。我从浙江一个高中长大,30年前,学校采用的油印机是要用“蜡纸”的:老师们的一大技能就是在蜡纸上,用尖头的铁笔刻出手写的试卷来,然后卷到一个油印机的滚筒上面,油印机印的页数多了,蜡纸也就旧了,一张蜡纸能印个几百张,怎么刻字刻得足够深而不破,是核心技能。后来90年代末有了打印机复印机,老师们不再需要手工刻试卷,我听到过他们怀念当年刻字的经历,但没有听到谁想回到过去。有了更好的工具,为什么要回去呢?从技术的角度讲,ChatGPT 依然是一种基于统计的方式(虽然神经网络不像当年的概率图模型、统计机器学习那么有明显的“统计”的色彩)来实现的机器学习算法。所以,它的能力也和场景的“常见程度”有关:只要是简单重复的人类劳动,它都能做得很好。从技术的角度举例子,冒泡排序写过一百遍,写出来很简单,AI 一问就会。让它写个更牛的自己出来... 抱歉,暂时还不行。然后我们发现它写各种企业“战略”写得很不错。这是不是从一个角度体现出来,部分“战略”其实就是统计意义上的简单重复呢?之前有人开玩笑,说 xx 厂和 yy 厂和 zz 厂的 ppt 大图长得一模一样,只要把颜色调成红黄蓝当中的一种。这样的工作,只要有训练数据,当然 ChatGPT 能做得非常好。说笑归说笑,我觉得 ChatGPT 从一个大数据的角度让我们重新审视了“什么是创新” - 很多我们认为是创新的东西,也许并不是。但是 ChatGPT 给真正的创新带来了更多的机会。一个广为人知的故事是,达芬奇在创作《岩间圣母》的时候,很多背景部分不是他画的 - 这些简单重复的地方就让他的助手画了。今天 ChatGPT 就是助手,当内容创作者能够花更少的时间做重复劳动的时候,创新会变得更多 - 这是历史上多次证明的。聪明地设计 Infra硅谷著名风投 A16Z 在最近一篇对于 AIGC 的文章当中提到那么一句话:“目前看基础设施提供商是这个市场当中最大的赢家”。不过要做这个赢家,就要更加聪明地设计 infra 才行。AI 计算不同于传统上所说的“云计算”,而更加接近于我们所说的“高性能计算” HPC - 当你听见这个词语感觉我老学究的时候,且慢,听我道来。云计算很多时候在关注资源的池化和虚拟化:

  • 怎么把计算,存储,网络,从物理资源变成虚拟的概念,“批发转零售”;
  • 如何在这种虚拟环境下把利用率做上去,或者说超卖;
  • 怎么更加容易地部署软件,做复杂软件的免运维(比如说,容灾、高可用)等等,不一而足。


但是 AI 的计算不一样。对于 AI 而言,尤其是今天 AI 的训练:

  • 并不要求特别强的虚拟化。一般训练会“独占”物理机,除了简单的例如建立虚拟网络并且转发包之外,并没有太强的虚拟化需求。
  • 需要很高性能和带宽的存储和网络。例如,网络经常需要几百 G 以上的 RDMA 带宽连接,而不是常见的云服务器几 G 到几十 G 的带宽。
  • 对于高可用并没有很强的要求,因为本身很多离线计算的任务,不涉及到容灾等问题。
  • 没有过度复杂的调度和机器级别的容灾。因为机器本身的故障率并不很高(否则 GPU 运维团队就该去看了),同时训练本身经常以分钟级别来做 checkpointing,在有故障的时候可以重启整个任务从前一个 checkpoint 恢复。


也就是说,对于 AI 的用户而言而言,尤其是今天那么大规模的训练,性能和规模是第一位的,传统云服务所涉及到的一些能力,是第二位的。
这其实很像传统的高性能计算的领域的需求。实际上,在 2017 年的时候,我们在 Facebook 提出了一个概念叫做 return of MPI:用传统高性能计算的方式,来看待 AI 计算的问题。例如,与其使用更加“容灾”的异步通信等方式,不如启用高性能计算领域常见的MPI Allreduce / send / recv 算子等“老方法”,实现更高性能的分布式训练。2017 年,我在 Facebook 的团队和 FAIR 一起,将 ImageNet 训练的速度降到了一个小时以内。今天不少的 AI 软硬件设计,都依然透出着高性能计算的影子。例如,阿里云在 2022 年提出的飞天智算集群“灵骏”,通过 GPU 的高速互联以及轻量级的平台 PAI,来管理万卡级别的AI计算的需求;微软 Azure 在云上提供了这样一个专为高性能 AI 设计的机型:8xA100 GPU + 8x200G Infiniband。Meta 在 2022 年公布了自己万卡数量的科研集群 RSC:这些产品的设计都是明显为了高性能 AI 计算来提供的。对于提供基础设施的供应商来说,AI 计算是一个新的机会,也是一个关键的时机,需要重新审视长期提供通用云服务而形成的思维模式。AI 计算未来可期本来想写得通用一些,但是一写就写得很技术。AI 领域永远不缺惊喜,原以为计算机视觉已经走到了尽头,忽然 AIGC 柳暗花明又一村;原以为 Stable Diffusion 已经审美疲劳,忽然 ChatGPT 又打开无数的应用。最后没什么可说的了,作为一直战斗在 AI platform 一线的老兵,用 Richard Sutton的一句话来做结语:

The biggest lesson that can be read from 70 years of AI research is that general methods that leverage computation are ultimately the most effective, and by a large margin.
Richard Sutton: "The Bitter Lesson"

Bon voyage.== Credits ==
题图: Unsplash
   https://unsplash.com/@andyadcon
直升机图: Stanford University
蜡纸图: Taobao

相关文章
|
8月前
|
SpringCloudAlibaba Java 网络架构
【Springcloud Alibaba微服务分布式架构 | Spring Cloud】之学习笔记(二)Rest微服务工程搭建
【Springcloud Alibaba微服务分布式架构 | Spring Cloud】之学习笔记(二)Rest微服务工程搭建
184 0
|
2月前
|
搜索推荐
|
3月前
|
缓存 前端开发 JavaScript
前端的全栈之路Meteor篇(二):容器化开发环境下的meteor工程架构解析
本文详细介绍了使用Docker创建Meteor项目的准备工作与步骤,解析了容器化Meteor项目的目录结构,包括工程准备、环境配置、容器启动及项目架构分析。提供了最佳实践建议,适合初学者参考学习。项目代码已托管至GitCode,方便读者实践与交流。
|
8月前
|
存储 运维 关系型数据库
2024年最全ceph的功能组件和架构概述(2),Linux运维工程面试问题
2024年最全ceph的功能组件和架构概述(2),Linux运维工程面试问题
2024年最全ceph的功能组件和架构概述(2),Linux运维工程面试问题
|
4月前
|
负载均衡 数据库 开发工具
|
5月前
|
安全 IDE Java
从0到1探索淘宝短视频流的架构再设计和工程重构
随着视频流业务的发展,业务的复杂性越来越高,视频流老工程在架构设计、代码质量、工程能力等方面的问题也逐渐凸显。本次重构是一次对大型业务工程进行架构再设计和重构的探索,本文是对这次探索的一次梳理与总结。
|
6月前
|
Kubernetes 关系型数据库 分布式数据库
PolarDB产品使用问题之PolarDB-X的架构形态有什么区别
PolarDB产品使用合集涵盖了从创建与管理、数据管理、性能优化与诊断、安全与合规到生态与集成、运维与支持等全方位的功能和服务,旨在帮助企业轻松构建高可用、高性能且易于管理的数据库环境,满足不同业务场景的需求。用户可以通过阿里云控制台、API、SDK等方式便捷地使用这些功能,实现数据库的高效运维与持续优化。
|
5月前
|
敏捷开发 测试技术 持续交付
阿里云云效产品使用合集之如何管理企业的组织架构
云效作为一款全面覆盖研发全生命周期管理的云端效能平台,致力于帮助企业实现高效协同、敏捷研发和持续交付。本合集收集整理了用户在使用云效过程中遇到的常见问题,问题涉及项目创建与管理、需求规划与迭代、代码托管与版本控制、自动化测试、持续集成与发布等方面。
|
8月前
|
存储 Cloud Native 对象存储
AutoMQ:基于阿里云计算与存储产品实现云原生架构升级
AutoMQ[1] 是新一代基于共享存储架构实现的云原生 Kafka。得益于其存算分离的共享存储架构,通过和阿里云合作,深度使用阿里云可靠、先进的云服务如对象存储OSS、块存储 ESSD、弹性伸缩ESS以及抢占式实例实现了相比 Apache Kafka 10倍的成本优势并且提供了自动弹性的能力。
84362 27
AutoMQ:基于阿里云计算与存储产品实现云原生架构升级
|
6月前
|
敏捷开发 前端开发 测试技术
软件开发工作流【详解】(含公司产品研发流程图、大厂研发架构图、大厂研发流程图)
软件开发工作流【详解】(含公司产品研发流程图、大厂研发架构图、大厂研发流程图)
1506 1

热门文章

最新文章