智能对话技术在近几年来取得了惊人的进步,最近爆火的 ChatGPT 更是将智能对话推到了至高潮。像 ChatGPT 这样的聊天机器人有着广泛的用途,然而想要让其达到真正的智能水平,还有很多挑战需要克服,比如自然语言处理、上下文理解、逻辑推理、情感表达等技术能力都需要进一步迭代。
如今智能对话技术已经发展到什么程度了?当前有什么好的智能对话产品实践经验?智能对话技术的下一步演进将是怎样的?为了得到这些问题的答案,3 月 11 日下午,OPPO 数智在线下举办了主题为《畅谈“智能对话”,共启“交互未来”》的 OGeek 小布沙龙。OPPO 小布助手首席研究员杨振宇博士作为本次沙龙的内容出品人,邀请到了清华大学计算机科学与技术系长聘副教授黄民烈博士、百度 AI 主任研发架构师 & 小度算法团队技术负责人谢剑博士及 OPPO 小布助手算法专家索宏彬博士来到现场进行了硬核的技术干货分享及精彩绝伦的圆桌论坛。
据悉,“OGeek”是由 OPPO 数智工程事业部主办的行业技术沙龙品牌,旨在为技术爱好者搭建一个技术交流和分享的开放平台。沙龙主要围绕“科技为人、以善天下”的品牌使命,聚焦于为智能终端提供安全高效的数据、算力、算法、云服务方面的前沿技术,打造技术互动的行业生态,探索技术在行业应用的实践、突破及未来发展方向。
以下为本次 OGeek 小布沙龙的精华内容整理:
生成式对话模型的图灵测试逐渐接近人类水平,高质量对话也让人误以为 AI 有意识和人格觉醒。特斯拉和小米均在研发人形机器人,国际上也投入了大笔资金立项,似乎“AI- 人”和谐共融的社会将成为必然。基于以上背景,黄民烈指出,随着硬件成本越来越低、执行部件越来越灵敏,机器人的大脑将显得尤为重要。
基于规则时代,1966 年计算机发展之初,MIT 的教授基于规则研发了用于心理治疗的 Eliza;
智能助手时代,资本一顿狂追,成果则良莠不齐;
深度学习时代,如今,以深度学习为代表的大模型数据神经对话系统如 ChatGPT 正在开启 AI 发展的第三阶段——深度学习阶段。
黄民烈认为,聊天机器人可分为两个分支——“功能型 AI”及“拟人型 AI”。前者可以不停地完成任务和指令,如传统的智能助手、大模型阶段的 ChatGPT;后者则一般是基于检索的智能机器人、基于生成大模型的 LaMDA 等。
纵观大模型发展历程,由微软研发的 DialoGPT 是相对较早的系统,它完全基于 GPT 架构,从 Reddit 上抽取 147M 对话数据,实现了互信息最大化。谷歌研发的 Meena 系统提出了人工评价体系 SSA,性能显著超越了 DialoGPT。清华 CoAI 小组研发的 CDial-GPT,依托 Decoder-0nly 架构,建立了大规模高质量中文开放域对话数据集 LCCC,其人工评测结果优于原始 Transformer 模型和中文 GPT-2 模型,得到了学术界的认可。
第一代:已具备开放域闲聊及多技能融合的能力;
第二代:模型结构与第一代相同,数据能力有所增强。
第三代:迭代为 Decoder-Only 结构,功能模块化与流水线配合执行,完成开放域任务并实现终身学习。
2021 年初,清华 CoAI 小组研发了 EVA,共有两个版本。其中,EVA1.0 包含 28 亿参数,在 181G WDC-Dialogue 上训练而成,开源首个十亿级别中文对话模型;EVA2.0 在精细清洗的 60G WDC-Dialogue 上训练而成,开源多规模版本模型以方便研究者使用。
当我们把目光放到当下的技术产品中,由百度研发的 PLATO 系列模型现已更新至第四代。前两代模型结构相同,参数量均为 1.6B。第三代 PLATO-XL,参数量达到 11B,在连贯性、一致性、信息量、事实性、趣味性上均取得优异表现。第四代 PLATO-K 版本旨在解决开放域对话系统中信息量缺乏和事实不准确的问题,在知识性上有大幅提升。由 Google 研发的 LaMDA 以 Decoder-Only 为架构,参数量达到 137B,在 2.81T 的 token 上进行了预训练,能够在合理、趣味、安全的开放域闲聊。引入 Toolset (TS),在生成质量、安全性、有根据性上取得明显提升。
去年,清华 CoAI 小组联合聆心智能研发了 OPD。它采用 UniLM 架构,在预训练阶段引入了 Soft Prompt。参数量为 6.3B,具有 70GB 高质量对话数据,兼顾出色的闲聊能力与知识问答能力。
遵循指令能力出色,在多轮交互中均能很好地遵从指令;
对话历史建模能力突出,在多轮交互中具有很强的长程记忆能力;
多语言能力强,支持各类主流语言。再者是回复信息性强,倾向于生成较长的回复。最后是安全性好,安全漏洞很少且仍在持续优化。
黄民烈指出,ChatGPT 更突出功能属性,强调提高效率、解放生产力,提升创造力。而 Character AI 和 AI 乌托邦则更关注人格属性,试图满足社交、情感、陪伴、支持等需求。黄民烈将 AI 乌托邦称为 Mini 版的 ChatGPT,它既可以回答刁钻的问题,还可以让不同角色实现跨时空的对话。对于一个问题,ChatGPT 可能会给出一个比较官方的回复,而 AI 乌托邦则会根据不同的角色性格给出不同的回答。
在本次演讲的最后,黄民烈就对话大模型特点做出了总结:
1. 模型架构、预训练任务趋于统一;
2. 参数规模持续增大,下一代对话预训练模型将普遍进入千亿量级;
3. 数据重要性日益凸显,中等规模、高质量的对话数据将显著提升对话预训练模型的交互能力;
4. 人类在模型训练过程的介入和参与不断增加,模型对人类行为的模仿、与人类偏好和价值取向的对齐不断增强;
5. Tool-learning 引起关注,检索、记忆、计算等可插拔的外部模块将成为标配;
6. 新的落地应用场景涌现,以 Character.AI、ChatGPT 为代表的对话模型具有众多潜在的落地应用场景。
谢剑认为,智能助手的智能化体验将主要围绕以下几个维度进行进化。首先是“交互自然度”,交互自然度不仅体现在语音交互,更侧重于多模态的交互。现在市场上的语音助手基本是一次唤醒一次交互,这种方式并不够智能。其次是“对话智能度”,即智能对话系统要足够聪明。对于同一个问题,不同的提问方式均能得到准确的回答。从基础满足进阶到拟人智能,有人格化、人像化的形象将会与人产生情感的连接。然后是“感知与影响度”,即实现对物理世界更丰富的感知和更强的影响。
小度助手在这个进化蓝图下,主要围绕自然交互和对话智能展开探索。针对自然交互,谢剑指出,无论是把双工交互引进来,还是把“小度小度”变成“小度”,都是为了使用户和设备之间的交互成本更低。对话智能则侧重于不同技术路线应对不同的对话需求,小度个性化持续自学习的统一对话系统,可以在保护用户隐私的情况下进行用户分析,将满意的部分持续积累,不满意的部分通过样本挖掘产生正确的标签,实现系统的自学习。
从工业界的视野来看,谢剑认为对话理解正面临着三个挑战——大规模持续增长的理解体系、语音识别错误和口语化问题的鲁棒性挑战、需要满足不同用户的个性化需求。为此小度助手进行了对话理解层面、对话引导层面的技术迭代。
在对话理解层面,建立大规模个性化多轮对话需求追踪模型。将 NLP 与推荐技术交叉融合,针对用户的需求空间做整体建模,如此便绕开了文本出错的问题。同时,应用个性化和上下文信息融合的注意力网路,进而实现全空间可比的连续概率变化追踪。该模型的端到端纠错和 NLU 能力、上下文理解能力、垂类知识能力以及个性化纠错与消歧能力非常强悍,其中“个性化纠错与消歧能力”尤为突出。
在对话引导层面,谢剑强调智能的对话体验应是:知之为知之,不知为不知,即智能助手一定要知道自己有不知道的边界。通俗来讲,用户与小度聊天,当聊到它没听清或听不懂的问题时,它能够知道自己不知道,而不是答非所问。于是,小度团队构建了深度满意度模型——离线时基于下文 Dialogue Act 的序列行为判别模型,在线时基于离线模型样本,预判最佳结果是否满足用户。
面对 ChatGPT 的成功,谢剑将其背后的强大能力拆解为三个维度,分别是对话交互维度、NLP 全任务能力维度以及泛化能力维度。谢剑认为,ChatGPT 最大的亮点是语言智能统一范式的飞跃,在此之前整个学术界也一直在探索。
先有通用的语言能力后再去做具体任务是通向语言智能的关键;
语言背后的世界常识、逻辑应是相同的;
不少单独的十分垂直的 NLP 研究子方向受到巨大冲击。
关于“ChatGPT 能否代替语音助手”这个问题,谢剑的答案是“不能直接完全替换,但是基于 LLM 的新技术范式升级能够带来革命性的体验”。具体而言,ChatGPT 本身的满足方式还是文本信息,无法直接连接数字世界的服务和 API,比如订闹钟、播放音乐等,而这些都是已有助手需要解决的问题,同时还存在事实性的问答错误以及时效性信息的更新问题,因此无法直接替换。
然而以 ChatGPT 为代表的 LLM 拥有极强的语言推理、总结和生成能力,以 LLM 作为大脑,结合外部工具的调用(包括搜索、服务 API 等)既能够满足现在用户对于语音助手的需求,还能够满足和激发原本满足不好的需求(内容生成、复杂长文本理解等)。
小度助手结合 LLM 新技术范式的升级会朝着 Chain of Reason and Act 方向去进化,用户的需求来了之后首先进行推理,思考需要调用和应用外部的什么服务和工具(比如 搜索、音乐播放服务、视频等),而后基于外部服务和工具的内容返回继续推理,看看是否能够满足用户的需求,在能够满足和不能满足的情况下自主的去生成更合适的内容返回给用户,这种"推理 - 执行 - 推理"链能够大幅的增强 LLM 的能力,进而满足用户对助手的各种需求。
当然这种技术和融合也有很多的挑战,包括成本的挑战、生成式大模型的安全挑战等等,另外在拥有 LLM 大模型的强大能力的同时还需要能够保持原本助手的个性化、自学习等特征,在这些关键问题下,小度团队也在紧锣密鼓的开展研究中。
小布助手是一个多模态、多终端、对话式的智能助手,以“机智”“有用”“温暖”为产品理念,致力于提供多场景、智慧有度的用户体验。
人机语音交互是基于语音输入的一种交互模式,即通过说话就可以得到反馈结果。语音助手则是一款智能型的应用程序,人机之间通过语音进行对话与问答。它的终极目标是全领域通过图灵测试,通俗说就是“能听”“会说”“懂你”。
模型生产能否保证高效,比如把链路里的语音技术点、VAD/KWS/ASR 等基础模型生产置于统一框架之下,并相应地进行流程化改造;
算力部署,要把算法进行高效封装,使其迅速产生推理依据,随后部署到端侧和云侧。将语音处理接口进行抽象,以实现各种各样的语音服务编排。
即便小布助手链路已经构建得相当完整,但使用过程中仍然存在着许多问题。其中,索宏彬认为低功耗信号处理的主要挑战是非平稳噪声、高回放音和空间混响。目前的解决方案是单、双麦降噪,传统信号处理方法与神经网络方法并行,当前小布助手已完成立体声 AEC 算法仿真初版,在最大音量下,MIC1 回声抑制收益可超过 10dB。未来小布助手研发团队将聚焦多场景的 AEC 算法适配,布局远场交互的 Mic 阵列技术,为 OPPO 更多产品形态做好准备。
面对当前行业里“语音唤醒”功能实现中存在的“低功耗”、“高噪声场景下如何保持高水位的唤醒率同时抑制误唤醒率”技术难题,小布完成了唤醒底层算法的开发,从 0 到 1 构建了芯、端、云三级 (DSP/AP/Cloud) 唤醒方案。
关于声纹应用,为了应对人噪干扰、多人交谈、跨信道、短时交互的场景挑战,OPPO 小布研发团队基于 SpeechBrain 框架,选型了 Vector 算法框架及综合性解决方案算法框架 ECAPA-TDNN,并且基于距离度量的无监督聚类技术,进行数据自动化清洗。
在目标语音增强方面,小布助手团队尝试了基于声纹模板更新的主讲人话音检测算法(TSVAD),尝试通过主讲人语音注册环节,对模板进行更新,提升主讲人语音分离模型在实际场景使用时的鲁棒性能,提升后端语音识别准确率;
在自定义 TTS 方面,传统的声音自定义技术方案,录入时间长,效率低。同时,小布助手的用户群体背景及使用场景复杂,因此在复杂的环境和海量数据情况下,如何挑选满足条件的音频作为训练数据成为了一个巨大的挑战。于是小布助手研发团队自研了“纯语音 VAD”与“语音语义深度结合 VAD”的解决方案,同时应用了“预训练 + 在线自适应”的技术方案。
方案一:声码器从 HiFiGAN 升级至 SiFiGAN,通过引入 Source-Filter 模型,模拟发音过程,实现基频(F0)可控,MOS 得分有显著提升;高保真歌声合成,从 24K 升级至 48K,可以保留 12K 以上的高频细节信息;引入 PN 技术,将 Diffusion 模型中的差分方程分解为“Gradient”和“Transfer”两部分,在“Gradient”部分选择“Linear Multi-Step”方法加速计算,并实现了实时推理。
方案二:小样本歌声合成使用 Conditional LayerNorm 技术,Finetune 时只更新与说话人音色相关的参数即可,训练数据从 3 小时降低至 40 分钟以内;同时改进了时长模型 Differentiable Durator,一定程度解决训练和推理过程不匹配的问题,提高自然度。
在本次 OGeek 小布沙龙的最后,杨振宇与黄民烈、谢剑、索宏彬一起围绕“智能对话技术的‘下半场’在哪?”这一主题展开了圆桌论坛。几位博士均表示,爆火的 ChatGPT 给智能对话领域带来了深远的意义和影响。黄民烈认为,ChatGPT 最大的意义是让所有公众意识到了 AI 的能力以及 AI 能够突破传统认知上的局限”;谢剑和索宏彬都提到了“人机共生”的理念,他们表示 ChatGPT 的出现将启发人们思考,在未来的工作场景中如何实现人机共生。
当提到智能对话等人工交互领域最有前景的方向时,来自学术界和工业界的博士们分别给出了不同的答案,黄民烈认为未来将是千人千面的;谢剑在个性化助手的方向基础上,抛出了“增强语言模型”的观点,让 LLM 结合外部的各种信息和工具来大幅提升 LLM 的能力;索宏彬则认为,从交互模态上看,input 会变得更加丰富。四位博士完美地勾勒出了智能对话技术的美好未来。通过他们的分享,我们可以预见,智能对话与人机交互在未来一定会给我们带来更多的惊喜。
就像出品人杨振宇说的那样,“即使有像 ChatGPT 这样的新技术出现,挑战也仍然存在,包括内容安全与 AI 伦理、长时记忆与个性化、共情能力与拟人化、反馈驱动与自学习。但机遇与挑战并存,随着技术的快速迭代,智能对话领域正在迎来最好的时代。”
附:圆桌论坛环节精彩整理
黄民烈:学术界现在的趋势是以神经网络模型为主,工业界的趋势则是朝 OpenAI 的方向持续狂奔。从学术界角度来讲,由于资源受限,无法支撑太多大规模的模型和试验。整个学术界的研究方式正在与工业界的方式趋同和对齐,很多有影响力的论文都是由名校和大厂共同产出的。
学术界当下需要考虑如何学习外界工具方法来解决自身研究的问题。工业界数据是最好的方法,但学术界也需要用有原则性的方法突破它。比如乌托邦个性化对话平台的很多行为要靠数据解决,里面也有很关键的算法,这时既要考虑算法在原理层面是否合适,同时也要注意规避算法短时间内难以克服的缺陷。
谢剑:不单是智能对话,我们可以思考任何计算机领域包括科学领域,学术界和工业界的侧重点是什么。个人看来,学术界侧重突破新的可能。比如不考虑任何成本,智能最终极限将是什么样的。工业界则侧重于解决问题,他们更看重“捅破天花板”的技术最终能应用于哪些场景以解决用户的需求。近年,工业界产品的用户体量很大,也需要再往前走一走。刚刚黄老师提到,现在许多大厂和高校之间都有合作。那么工业界也将与学术届合作,一起捅破“天花板”。
索宏彬:目前,OPPO 小布也在和学校进行合作,该项目的出发点主要围绕两个方向,一是跨领域、多模态领域,涉及语音、图像以及语义结合,可以看出学术界在这些领域是比较关注的。第二个是问题驱动,这其中包括很多技术挑战点,高校工作也比较关注。回到本质上,目前智能助手业务应用上,跟高校的合作还是主要围绕用户体验、围绕问题驱动。
谢剑:2B 最后也是 2C,最终都是要满足用户的需求,当然它们也会各有侧重。2B 的客户往往是开发者,他们看重是否具有泛化能力,能否降低开发者成本。2C 的大部分用户不是开发者,他们希望交互一次就能满足需求。所以,从智能对话上来讲,这可能是比较明显看到的区别。也许,新的时代 2B 和 2C 会模糊掉。如果开发者用很简单的自然语言就能开发,就意味着人人都能成为开发者,中文也能变成世界上最强的编程语言之一。所以,2B 和 2C 的模糊,一定程度上也能带动整个社会生态的蓬勃发展。
索宏彬:小布的产品定位正在发生变化,尤其在备受热议的 ChatGPT 出来之后,小布的目标是朝着“有用”的方向走。原来的小布侧重于“有趣”,现在则在向“有用”的方向走,这是很典型的一个变化。
黄民烈:我理解人类有两类基本需求,一类是信息需求,一类是情感需求。信息需求本质上是做事情,怎么把它完成的更好。情感需求本质是要消磨时光,有情感的寄托,有情绪上、心理上的支持和疏导。所以,我们希望今天的助手能和人产生更强的连接,有情感的、社会的、信任的关系,不仅要完成信息类的任务,还要完成情感类的任务。从人类两大需求角度来看,无论是信息的还是情感的,最终都将融到一起,尤其现在技术发展越来越快,势必会产生很多新的应用场景。随着技术的成熟和变革,一定会有新的拐点和机会到来,这也是我们现在想试着做 AGI 的重要驱动点。
杨振宇:无论是 2B 还是 2C,都要考虑到底最终为用户希望发挥的价值是什么,以及在此之上给用户提供的体验是怎么样的。2C 与 2B 的核心需求侧重点目前虽然稍微有点不同,但本身都还在演进、融合的过程中。
索宏彬:大家在演讲过程中提了很多挑战,如果选一个最大的,那就是“自然”,不是 AGI 的,而是更往上走,真的达到拟人化或者跟人产生情感连接。实现无负担的交互。
谢剑:挑战很多,如果说最大的我个人觉得是如何做到 All in one,我怎么说都行,怎么说它都能搞定,背后一定程度上隐隐朝向 AGI 的挑战。其他的新场景泛化,信息需求和情感需求都能满足,本质都是需要 All in one。现在发现预训练的大模型能够把它整合,但依然还有很多问题,目标是希望能够 All in one 用一个大脑,这是我理解最大的挑战。
黄民烈:最大的挑战是如何实现 Human-like conversation。从现在看,我们已经接近类人的对话能力,但有些应用场景仍存在差距,比如多模态的信息、上下文理解等,尤其是如何连接到外部世界和知识,以及外部背景信息。总体来讲还是挺难的,AGI 有很长的路要走。
杨振宇:针对这个问题也分享一下我的想法,非常赞同今天各位专家提到的未来大模型用的越来越广泛的时候,怎么解决安全性的问题,怎么解决 AI 伦理的问题,特别是直接面向 to C 用户生成内容的时候。当讨论未来最大挑战的时候,多样性还蛮强的,在场各位专家完全不用担心未来没高价值工作可以做了,挑战还有很多。
黄民烈:现在技术发展很快,很多东西不太能够预测。我想未来电子宠物或者电子陪伴类的产品也许会卖的很好,因为它们能满足用户的情感需求。
杨振宇:大家在猜想 XR 设备会不会有下一个爆品,如果它发展起来,会不会对智能对话的领域有很大的影响。
黄民烈:前提是一定要脱离对设备本身的强依赖。如果设备本身的使用门槛或者使用场景不够自然,门槛很高,也许未来在手机装一个超级 APP 类似于 ChatGPT 的时候,可能就会很好。
索宏彬:XR 拓宽更多的交互模态,是增强人机交互的一种手段。
谢剑:人们所需要的最理想的助手,终极形态一定是多模态的助手形态。XR 有虚拟增强的设备,设备本身在拓宽 input 和 output 的模块。音箱是一个节点,从没屏幕变到有屏幕了,从只能听、能说,到后面有摄像头、能看、会说,再往后能不能有更虚拟的现实增强。回到智能助手,如果 XR 设备发展成熟了,多模态的助手就有了很好的承载设备,语言的理解就要还原到物理真实环境里,交互的各个方面都会有新的挑战。我相信新的技术挑战会带来新的技术机遇。
索宏彬:我比较认同当前类似 XR 的模式,即往多模态方向走,未来交互形态一定是自然表达,类比“人人”交互。
黄民烈:理想的一定是“情景式”的,有很多的交互场景。比如在车里,假设有一个人可以很好的与之交流,并且车内的场景交互一定是多模态的,有很多摄像头监测到肢体的状态等。其次是有很高的智能水平,可以自主也可以被动,智能到感知用户的全面状态,根据状态做出最有利于用户的决策。一定要具备综合决策能力,在特定场景下可以主动,大部分情况被动。
谢剑:关于理想态,我认为第一点是“个性化”。每个人在不同场景下都具有一个满足该场景需求的助手,或者每个人有一个“个性化助手”,它能在不同场景下扮演不同的能力和满足需求的形态。第二,未来的助手应满足市场供给。市场上有很多律师、作家、卖手等等,相信未来各个领域都会有助手。原本找律师的咨询费是比较贵的,而一些基本问题就可以咨询价格更实惠的智能助手。因此理想的形态,一是能满足个性化情景需求,二是市场上应该会有公共的产生知识供给的助手。
黄民烈:我认为 ChatGPT 最大的意义是让所有公众意识到了 AI 的能力以及 AI 能够突破传统认知上的局限。每个行业、每个人都开始思考应该如何和 AI 相处,这是它最大的意义。ChatGPT 给我们带来的仍然是想象的空间,在当前的时代和节点下,大模型能够带给我们什么想象空间,过去不敢想的事情,是不是今天能够去想、能够去做,这个意义是比较重大的。为什么说是 AI 里程碑,因为它比过去所有事情带来的冲击都要更大。
谢剑:影响还是很大的,我们可以分类来看。针对普通用户,他们要思考在未来的工作场景中如何实现人机共生,只有拥抱人机共生才能做 AI 之上的人。很多人会比较悲观,但其实人不可能被工具杀死,人加上工具自然会超过工具。对于 NLP 和从业工程师来说影响也是巨大的,不管在工业界还是在学术界都是如此。影响巨大的原因是,原本从 AI 技术来看,大家认知 NLP 是皇冠上的明珠,突然间发现 All in one 做任务并不差,甚至效果更好,这对从业工程师的挑战还蛮大的。学术界有很多做某个单点方向的,此时就要寻找新的方式参与进去。
索宏彬:谢老师提到了 AI 共生的理念,我非常认同。不知道大家有没有用到 Bing 和 ChatGPT 的结合版,Bing 的效率非常高。Bert、ChatGPT 等大模型的演进路线,给很多 AI 从业者提供了新的方向,带来一定冲击的同时也增强了大家的信心。大家会沿着这条路做更多的探索,有挑战、有危机,同时也有机遇、有机会。
黄民烈:我认为最有前景的方向还是“个性化”,未来肯定是千人千面的。无论是教育场景,还是金融服务场景,每个用户对不同类型机器了解的方式是不一样的,从这个层面来看个性化是最大的商业价值点。
谢剑:我补充一个点,"增强语言模型",以大语言模型为大脑,利用其强大的常识、推理等语言能力,结合和借助外部的信息、知识以及工具,来增强大语言模型,实现能够推理、执行动作再推理等反复的思考 - 动作链,通过这种方式能够更好的实现广泛场景的落地。
索宏彬:个人认为从交互模态上,input 会变得更加丰富。其次是表达侧的表现,生成式人工智能是当下特别炙手可热的技术点,我们也在做一些探索和尝试。
杨振宇:我个人的期待是,未来的助手是可进化的,是越来越聪明的。通过进化实现个性化和知识增强,对外界知识有更强的理解。如果能实现可进化,一定会有更好的前景。
本文最初发布于 Discord 官方博客。
2017 年,我们写了一篇关于我们如何存储数十亿条消息的博文,分享了我们开始时如何使用 MongoDB,但又将数据迁移到 Cassandra 的过程,因为我们正在寻找一个扩展性和容错性比较高而维护成本相对较低的数据库。我们确信自己会发展,而且我们确实做到了!
我们想要一个能随着我们的发展而演进的数据库,但又不希望它的维护需求会随着我们的存储需求而增长。遗憾的是,我们发现事实并非如此——我们的 Cassandra 集群出现了严重的性能问题,光是维护就需要花费很多的精力,更不用说改进了。
近 6 年过去了,我们已经改变了很多,我们存储消息的方式也发生了变化。
我们把信息存储在一个名为 cassandra-messages 的数据库中。顾名思义,它运行 Cassandra 来存储消息。2017 年,我们运行了 12 个 Cassandra 节点,存储了数十亿条消息。
2022 年初,节点数达到 177 个,而消息有数万亿条。令人懊恼的是,这是一个高强度的系统——我们的随叫随到团队经常接到反馈数据库问题的电话,延迟不可预测,因为成本过高,我们不得不减少维护操作。
是什么导致了这些问题?首先,让我们来看一条消息。
CREATE TABLE messages (
channel_id bigint,
bucket int,
message_id bigint,
author_id bigint,
content text,
PRIMARY KEY ((channel_id, bucket), message_id)
) WITH CLUSTERING ORDER BY (message_id DESC);
上面的 CQL 语句是我们最小的消息模式版本。我们使用的每个 ID 都是用雪花算法生成的,按时间顺序排序。我们根据消息的发送通道以及桶(一个静态时间窗口)进行消息分区。这种分区意味着,在 Cassandra 中,特定通道和桶的所有消息将存储在一起,并在 3 个节点(取决于设置的复制因子)上复制。
这种分区有潜在的性能缺陷:只有一小群人使用的服务器发送的消息往往比有数十万人使用的服务器少几个数量级。
在 Cassandra 中,读的开销比写大。写操作会被追加到提交日志,并写入内存中一个名为 memtable 的结构,最后再刷写到磁盘。然而,读操作需要查询 memtable,还可能要查询多个 SSTable(磁盘上的文件),其成本更高。当用户与服务器交互时,大量的并发读取会使一个分区成为热点,我们可以称其为“热分区”。这些访问模式在遇到我们的数据集规模时,导致我们的集群陷入了困境。
当我们遇到热分区时,它经常会影响整个数据库集群的延迟。一个通道 - 桶对接收了大量的流量,节点为之提供服务会越来越吃力,延迟会越来越大,越落越远。
该节点上的其他查询也会受到影响,因为它的速度跟不上。由于我们的读写操作都是仲裁一致性级别的,所以在为热分区提供服务的节点上,所有查询的延迟都会增加,进而对最终用户产生更广泛的影响。
集群维护任务也经常引起麻烦。我们很容易在压缩上落后,为了获得更高的读性能,Cassandra 会压缩磁盘上的 SSTable。这样一来,不仅读取的开销增大,而且当节点试图压缩时,还会产生级联延迟。
我们经常执行一种我们称之为“八卦舞”的操作。我们让一个节点退出轮换,让它在停止接收流量的情况下进行压缩,然后让它重新加入轮换,从 Cassandra 获取暗示切换线索,然后再重复,直到待压缩项为空。我们还花了大量时间对 JVM 的垃圾收集器和堆设置进行调优,因为 GC 暂停会导致显著的延迟尖峰。
消息集群并不是我们唯一的 Cassandra 数据库。我们还有其他几个集群,每个集群都展现出类似的缺陷(尽管可能没有那么严重)。
在上文提到的那篇文章中,ScyllaDB 引起了我们的兴趣,那是一个用 C++ 编写的数据库,兼容 Cassandra。它承诺提供更好的性能、更快的修复、更强的工作负载隔离(通过其按核分片架构),而且无垃圾回收,听起来相当吸引人。
尽管 ScyllaDB 也不一定没问题,但它没有垃圾收集器,因为它是用 C++ 而不是 Java 编写的。长期以来,我们的团队在 Cassandra 的垃圾收集器上遇到过许多问题,从 GC 暂停影响延迟,到连续超长时间的 GC 暂停,甚至运维人员必须手动重启问题节点才能将其恢复到健康状态。这些问题导致了大量的随叫随到工作,也是我们消息集群中许多稳定性问题的根源。
在对 ScyllaDB 进行试验并在测试中观察改进效果之后,我们决定迁移所有的数据库。虽然这个决定本身可以单独写成一篇博文,但简单来说,截止 2020 年,除一个数据库之外,我们已经将其他所有的数据库都迁移到了 ScyllaDB 上。
最后剩下的那个是我们的朋友,cassandra-messages。
为什么我们还没有迁移它呢?首先,这是一个很大的集群,有数万亿条消息和近 200 个节点,任何迁移工作都会很复杂。此外,我们对新数据库进行了性能调优,希望它们能够达到最佳状态。我们还希望能够积累更多在生产环境使用 ScyllaDB 的经验,了解它的陷阱。
我们还针对我们的用例改进了 ScyllaDB 的性能。我们在测试中发现,反向查询的性能不足以满足我们的需求。在以与表排序相反的顺序扫描数据库时,例如按升序扫描消息时,将执行反向查询。ScyllaDB 团队优先改进并实现了高性能的反向查询,为我们的迁移计划消除了最后的数据库障碍。
我们并没有指望在系统上加一个新数据库就能让一切神奇地变好。热分区在 ScyllaDB 中仍然存在。因此,我们还希望投资改进数据库上游系统,为数据库增加一道屏障,进一步提升数据库的性能。
对于 Cassandra,我们遇到了热分区的麻烦。到特定分区的高流量会导致无限并发,进而导致级联延迟,后续查询的延迟会继续增加。如果可以控制热分区的并发流量,我们就可以保护数据库不被压垮。
为了完成这项任务,我们编写了所谓的数据服务——介于 API 单体和数据库集群之间的中介服务。在编写数据服务时,我们选择了一种在 Discord 中应用越来越多的语言:Rust。我们在之前的几个项目中用过它,它没有辜负我们的期望。它为我们提供了媲美 C/C++ 的速度,而且没有牺牲安全性。
无惧并发是 Rust 引以为豪的主要优势之一——该语言使编写安全并发代码变得更容易。它提供的库也非常符合我们的预期。Tokio 生态系统是构建异步 I/O 系统的坚实基础,并且该语言提供了 Cassandra 和 ScyllaDB 的驱动程序。
此外,我们还发现,Rust 编译器提供的帮助、清晰的错误消息、语言结构及其对安全性的重视,让编码变得很有乐趣。我们非常喜欢的一点是,Rust 程序一旦通过编译,通常就可以运行。不过,最重要的是,我们可以说我们用 Rust 进行了重写(模因声誉非常重要)。
我们的数据服务介于 API 和 ScyllaDB 集群之间。大致上,它们为每个数据库查询提供一个 gRPC 端点,并且故意不包含业务逻辑。数据服务的一大特色是请求合并。如果多个用户同时请求同一行,我们将只查询数据库一次。第一个发出请求的用户会触发数据服务中的工作者任务。后续请求将检查该任务是否存在并订阅它。该工作者任务将查询数据库并把行返回给所有订阅者。
这就是 Rust 的强大之处:它使编写安全并发代码变得更简单。
让我们想象一下,在一个大型服务器上,有一条 @所有人的重要公告:用户将打开应用程序并阅读消息,向数据库发送大量流量。以前,这可能会导致热分区,并且可能需要随叫随到工程师帮助恢复系统。通过数据服务,我们能够显著降低数据库的流量峰值。
魔法的第 2 部分在数据服务的上游。为了实现更有效的合并,我们实现了一致的基于哈希的数据服务路由。我们为每个数据服务请求提供一个路由键。对于消息,这是一个通道 ID。这样一来,对同一通道的所有请求都会发送到服务的同一实例。这种路由方式帮助我们进一步减少了数据库的负载。
这些改进对我们帮助很大,但并不能解决所有问题。我们仍然会在 Cassandra 集群上看到热分区和延迟增加,只是不那么频繁了。那为我们赢得了一些时间,让我们可以准备最优的 ScyllaDB 集群并执行迁移。
我们的迁移需求非常简单:我们需要在不停机的情况下迁移数万亿条消息,而且需要快速完成,因为虽然 Cassandra 的情况有所改善,但我们还是经常处于灭火状态。
第一步很简单:使用超级磁盘存储拓扑准备一个新的 ScyllaDB 集群。借助本地 SSD 来提高速度,并利用 RAID 将数据镜像到持久盘。这样,我们既从附加的本地磁盘那里获得了速度,又从持久盘那里获得了持久性。集群启动后,我们就可以开始向其中迁移数据了。
我们第一版的迁移计划旨在快速获取价值。我们开始使用崭新的 ScyllaDB 集群来处理新数据,然后找一个切换时间迁移历史数据。这带来了更多的复杂性,但每个大型项目都会有额外的复杂性,不是吗?
对于新数据,我们开始执行双重写入,即同时写入 Cassandra 和 ScyllaDB。与此同时,我们还开始准备 ScyllaDB 的 Spark 迁移器。那需要大量的调整,设置完成之后,我们估计了完成时间:3 个月。
对于这个期限,我们并不满意。我们希望可以更快地获取价值。因此,我们团队组织了一场头脑风暴,看看如何加快速度,直到我们记起来,我们已经编写了一个快速的高性能数据库库,我们可以对它进行扩展。我们选择参与了一些模因驱动工程,并用 Rust 重写了数据迁移器。
有一天下午,为了执行大规模数据迁移,我们扩展了数据服务库。它从数据库中读取令牌范围,通过 SQLite 在本地进行检查,然后将它们送入 ScyllaDB。我们连接到经过改进的新迁移器,并重新估计了工期:9 天!如果能够这么快的迁移数据,我们就可以抛开我们基于时间的复杂方法,一次性地切换所有内容。
我们启动它并让它保持运行,以每秒 320 万条消息的速度迁移。几天后,我们看到迁移已达 100%。不过我们意识到,它被卡在了 99.9999%(是真的)。我们的迁移器在读取数据的最后几个令牌范围时超时了,因为它们包含了巨大的墓碑范围,而且从未压实。在我们把那个令牌范围压实几秒钟后,迁移就完成了!
通过向两个数据库发送一小部分读数请求并比较结果,我们完成了自动数据验证,一切看起来都很好。在全生产流量的情况下,集群依然运行良好,而 Cassandra 却遇到了越来越频繁的延迟问题。我们的团队聚在现场,按下开关,让 ScyllaDB 成为主数据库,并分享了庆祝蛋糕!
2022 年 5 月,我们切换了消息数据库,但自那以后它的运行状况如何呢?
它是一个安静、乖巧的数据库(这么说没关系,因为这周我不用随叫随到)。我们周末不用长时间救火了,也不用为了保持正常运行时间而同时处理多个集群节点。这个数据库更高效——我们的 Cassandra 节点有 177 个,而 ScyllaDB 节点只有 72 个。每个 ScyllaDB 节点有 9TB 的磁盘空间,而每个 Cassandra 节点的平均磁盘空间为 4TB。
我们的尾部延迟也得到了大幅改善。例如,从 Cassandra 获取历史消息的 p99 延迟在 40-125 毫秒之间,在 ScyllaDB 上只有 15 毫秒;向 Cassandra 插入消息的 p99 延迟在 5-70 毫秒之间,而 ScyllaDB 为稳定的 5 毫秒。得益于前面提到的性能改进,我们还解锁了新的产品用例。现在,我们对消息数据库很有信心。
2022 年底,全世界的人都在收看世界杯。我们很快就发现,监控图上显示了总进球数。这非常酷,因为那不仅让我们可以在系统中看到真实世界的事件,还让我们团队在会议期间观看足球比赛有了正当的理由。我们不是“在会议期间观看足球比赛”,而是“在主动监控系统的性能”。
实际上,我们可以通过消息发送图来讲述世界杯决赛的故事。这场比赛非常精彩。梅西试图完成职业生涯的最后一项成就,带领阿根廷队夺得冠军,但才华横溢的姆巴佩和法国队试图阻挡他的前进之路。
1. 梅西罚进点球,阿根廷 1-0 领先。
2. 阿根廷再次得分,2-0 领先。
3. 中场休息。用户谈论比赛,有一个持续 15 分钟的平稳期。
4. 这里的大尖峰是因为姆巴佩为法国队进球,90 秒后又进球扳平了比分!
5. 常规时间的比赛结束了,这场重要的比赛将进入加时赛。
6. 加时赛的前半段什么也没发生,但到了中场休息时,用户们在聊天。
7. 梅西再次进球,阿根廷取得领先!
8. 姆巴佩反击扳平!
9. 加时赛结束了,要踢点球了!
10. 在点球大战中,兴奋感和压力不断增加,直到法国队罚丢,而阿根廷队命中!阿根廷赢了!
每秒合并消息数
全世界的人们都在观看这场不可思议的比赛,但与此同时,Discord 和消息数据库却毫无压力。我们在信息发送和处理方面做得很好。我们基于 Rust 的数据服务和 ScyllaDB 能够承受这些流量,并为用户提供一个交流的平台。
原文链接:
https://discord.com/blog/how-discord-stores-trillions-of-messages
在过去的一周,经过评审后,JDK 20 提案 JEP 438(Vector API 第 5 轮孵化)从 Proposed to Target 状态 提升 到 Targeted 状态。在 Panama 项目 的支持下,该 JEP 融合了针对前 4 轮孵化反馈的改进:JEP 426(Vector API 第 4 轮孵化)在 JDK 19 中交付;JEP 417(Vector API 第 3 轮孵化)在 JDK 18 中交付;JEP 414(Vector API 第 2 轮孵化)在 JDK 17 中交付;JEP 338(Vector API 首轮孵化)在 JDK 16 中作为 孵化器模块 交付。JEP 438 提议增强 Vector API,根据 JEP 424(外部函数和内存 API 预览)的定义,从MemorySegment
中加载和向MemorySegment
存储向量。
JDK 21 提案 JEP 431(序列集合)已经从 Candidate 状态提升到 Proposed to Target 状态。该 JEP 提议引入“一个新的接口族,用于表示集合的概念,这些集合的元素按照预定义的序列或顺序排列,它们是作为集合的结构属性。”这一提案的动机是由于集合框架中缺乏预定义的顺序和统一的操作集。评审预计将于 2023 年 3 月 16 日结束。要了解更多关于 JEP 431 的更多细节,可以阅读 InfoQ 的这篇新闻报道。
在过去的一周,JEP 439(Generational ZGC)从 Draft 8272979 状态提升到 Candidate 状态。这个 JEP 提议“通过扩展 Z 垃圾收集器(ZGC)来为年轻对象和老对象维护单独的代,以此提高应用程序的性能。这将使 ZGC 能够更频繁地收集年轻对象,它们往往会在年轻时死亡。”
Oracle 首席产品经理 Dalibor Topic 曾提议解散并归档 JDK 6 项目,原因是:过去两年没有明确的项目负责人或邮件列表流量;过去四年的访问量为 0。InfoQ 后续将带来更详细的新闻报道。
JDK 20 仍处于发布候选阶段,GA 版本预计将于 2023 年 3 月 21 日发布。Build 36 仍然是 JDK 20早期访问构建 的当前构建。要了解关于这个版本的更多细节,请查看发布说明。
JDK 21 的早期访问构建Build 13 也于上周发布,其中包括来自 Build 12 的更新,该更新修复了各 问题。要了解关于这个版本的更多细节,请查看发布说明。
对于 JDK 20 和 JDK 21,我们鼓励开发人员通过 Java Bug 数据库报告 Bug。
Spring Cloud Data Flow 2.10.2发布,修复了 Bug,库升级到 Spring Boot 2.7.9 和 Spring Cloud 2021.0.6。它还升级了子项目依赖项,如:Spring Cloud Dataflow Build 2.10.2、Spring Cloud Dataflow Common 2.10.2、Spring Cloud Dataflow UI 3.3.2、Spring Cloud Deployer K8S 2.8.2。要了解关于这个版本的更多细节,请查看发布说明。
Spring Modulith 0.5发布,库升级到 Spring Boot 3.0.4 和 jMolecules 2022.2.4。它还带来了如下改进:重命名了触发 JDBC 数据库初始化的属性,从spring.modulith.events.schema-initialization.enabled
改为spring.modulith.events.jdbc-schema-initialization.enabled
。要了解关于这个版本的更多细节,请查看更新日志。
Quarkus 3.0.0 的第 5 个(也是最后一个)Alpha 版本 发布,支持:Hibernate ORM 6.0 和StatelessSession
接口;新的 Dev UI;Gradle 8.0;在 REST Client Reactive 中通过@ClientRedirectHandler
注解自定义重定向处理程序;通过@Scheduled
注解设置 cron 时间表的时区。要了解关于这个版本的更多细节,请查看更新日志。
Quarkus 2.16.14.Final 是第 4 个维护版本,带来了一些显著的改进,例如:传播 Quarkus 相关的故障安全系统属性;当服务器响应是 204 No Content 时,从 REST 客户端返回一个空的InputStream
;改进了DevServicesKubernetesProcessor
类中的日志记录。要了解关于这个版本的更多细节,请查看更新日志。
IBM 发布了 Open Liberty 23.0.0.2,新特性包括:用 Admin Center 测试数据库连接;server stop
命令新增命令行选项--timeout
;修复了 CVE-2022-45787 漏洞(在 Apache James Mime4J 中,TempFileStorageProvider
类使用的临时文件被赋予了不恰当的懒惰权限,可能会导致信息泄露给其他本地用户)。
Micronaut 基金会发布了 Micronaut 3.8.7,带来了 Bug 修复、文档改进和模块更新,涉及 Micronaut Serialization、Micronaut CRaC、Micronaut Kafka、Micronaut AOT 和 Micronaut GCP。SnakeYAML 2.0 也进行了更新,解决了 CVE-2022-1471 漏洞(使用 SnakeYAML Constructor()
类进行类型反序列化为攻击者恶意远程执行代码提供了机会)。要了解关于这个版本的更多细节,请查看发布说明。
Oracle 发布了 Helidon 2.6.0,带来了一些显著的变化,其中包括:仅当enable
标志设置为true
时才注册OciMetricsSupport
服务;依赖项升级到 SnakeYAML 2.0;通过移除未部署的工件来清理 Helidon BOM;从文档中删除了将指标从服务器传播到客户端的说明。
Apache Tomcat 11.0.0 的第 4 个里程碑版本发布,新特性包括:恢复原先基于系统属性加载自定义 URL 协议处理程序的方法;提供了一个不依赖于java.beans
包的 JavaBeans 支持实现;在 NIO2 中异步操作后恢复内联状态,解决实现抛出的意外异常。要了解关于这个版本的更多细节,请查看 更新日志。
Apache Camel 4.0.0 的第 2 个里程碑版本提供了 Bug 修复、依赖项升级和新特性,其中包括:在camel-minio
组件中用于连接到云服务的预签名 URL;为camel-health
组件中具有连接验证扩展的组件添加健康状况检查;camel-jbang
组件的目录输现在采用 JSON 格式。要了解关于这个版本的更多细节,请查看发布说明。
JobRunr 6.1.1 发布,修复了两个 Bug:使用JobLambda
接口执行重复作业时的错误;在使用 Yasson 时,由于作业 JSON 缺少属性而导致的NullPointerException
。
Andres Almiray 面向 Java 社区发布了 Jarviz(一个新的 JAR 文件分析工具) 0.3.0 版本。这个新版本修复了一些 Bug,并提供了一些新特性,包括:新命令extract
,用于按名称或模式提取 JAR 条目;新命令validate
,用于验证包名;新的命令行选项--output-format
,用于指定所需的输出。
Hilla 出自 Vaadin 开发者之手,其 2.0 版本已经发布。这是一个整合了 Spring Boot Java 后端和响应式 TypeScript 前端的开源框架。这个新版本支持:JDK 17;Jakarta EE 10;Spring Boot 3.0;Reactive 端点;GraalVM 原生镜像编译;以及一个 SSO 工具包,用于快速为 Hilla 应用程序添加单点登录功能。要了解关于这个版本的更多细节,请查看发布说明和 InfoQ 的新闻报道。
原文链接:
https://www.infoq.com/news/2023/03/java-news-roundup-mar06-2023/
相关阅读:
Java 近期新闻:NetBeans 17、Spring 及 Tomcat 多项更新、JDk 20 版本 GraalVM
虚拟线程:大规模 Java 应用的新基石 (https://www.infoq.cn/article/YaBqqD7fd6kX97GbhkGm)
声明:本文为 InfoQ 翻译,未经许可禁止转载。
点击底部阅读原文访问 InfoQ 官网,获取更多精彩内容!
微软Office正式融入GPT-4;文心一言正式发布,百度股价次日涨超16%;TikTok回应美国要求字节跳动出售持股|Q资讯
刚过去的一周,对于技术圈而言,实在是太“热闹”了:
OpenAI 发布史上最强模型 GPT-4,谷歌开放大语言模型 PaLM API,百度「文心一言」正式亮相,微软 Office 全家桶被 GPT-4 革新。
这一颗颗“重磅炸弹”所带来的余韵还未散去,赶在周末的尾巴,创新工场 CEO 李开复昨日在朋友圈宣布:“我正在亲自筹组 Project AI 2.0,一个致力打造 AI 2.0 全新平台和 Al-first 生产力应用的全球化公司。”
李开复直言,Project Al 2.0 要做的“不仅是中文版 ChatGPT”,更为关注基于 AI 2.0 能力的潜在应用前景。
在进入正题之前,我们先了解一下李开复口中的“AI 2.0”时代。
在上周举行的 “AI 1.0 到 AI 2.0 的新机遇”趋势分享会上,李开复定义的 AI 1.0,是以 CNN 卷积神经网络模型为核心的计算机视觉技术,拉开 AI 感知智能时代的序幕。但其单领域、多模型的限制,使得 AI 1.0 未能真正实现商业上的成功。
“在深度学习的重大突破之后,AI 已经来到从 1.0 迈入 2.0 的拐点。”李开复认为,AI 1.0 到 AI 2.0 之间最大的跃迁在于:AI 2.0 时代,人们可以基于一个具有跨领域知识的“基础模型”,用无需人工标注的超级海量数据去训练或微调,即可执行各种五花八门的任务。
而 AI 2.0 时代的第一个现象级应用,就是生成式 AI,即最近国内流行的 AIGC:AI 聊天工具 ChatGPT, AI 绘图工具 Stable Diffusion,AI 代码生成工具 GitHub Copilot……
但对此,李开复指出:“如今看到的应用都还只是 AI 2.0 能力的开端,不该限制了人们对 AI 2.0 未来潜力的想象。”
基于此,聚焦“AI 2.0 未来潜力”的 Project AI 2.0 应运而生。
如同美团元老王慧文声称要造中国版 OpenAI 后广发 AI 英雄帖,李开复在宣布筹建 Project AI 2.0 的同时,也公开“抢人”了,并明确了招聘范围:
“这(Project AI 2.0)是一家由技术愿景驱动,拥有卓越中国工程底蕴的创新企业,在全球范围号召世界级的人才,加入我们一起打造这个世界级的公司……首批广招大模型、多模态、NLP、AI 算法工程与研究、分布式计算/Infrastructure 等方向的顶级人才推荐自荐。”
据了解,创新工场相关人士透露:“已有多位具有全球大厂带领大型团队的技术管理人才,确认了加入意向。”
与此同时,Project Al 2.0 的资金、算力陆续到位,创新工场方面也在积极寻找 AI 2.0 技术和应用相关的投资机会,争取加速打造 A1 2.0 的全新创业生态:“对于 Al 2.0 的未来,我们具有更多更大的想象。”
目前,处于新项目筹备启动初期的 Project AI 2.0 将由李开复亲自带队,即由他牵头组建这支“世界级”的全新管理团队。等 Project AI 2.0 CEO 正式到任,李开复再进行交接:“新公司期权由新团队绝对主导。”
据李开复所说,Project AI 2.0 是创新工场塔尖孵化的第 7 家公司。其它已曝光的公司包括创新奇智、澜舟科技和呈元科技——其中,创新奇智所采取的模式和 Project AI 2.0 很相似,即前期先由李开复带领,找到 CEO 后再全权交棒。
参考创新奇智的发展史,不少人对于 Project AI 2.0 的成立抱以期待:
成立于 2018 年的创新奇智,诞生至今刚满 5 年就已成功实现从 0 到 1,并于 2022 年 1 月 27 日在港交所上市,成为“AI + 制造第一股”,且 2022 年上半年营收 6.46 亿元,同比增长 76.1%。
实际上,早在李开复之前,就有不少业界大佬陆续宣布入局:美团元老王慧文,前京东 AI 掌门人周伯文,清华计算机教授唐杰等。多年来聚焦 AI 领域的李开复,此前虽一直“按兵不动”,却也可以看出他的时刻关注和默默布局:
今年 2 月,他在微博发布了两篇影响力颇大的文章:“ChatGPT 可能引发失业的 20 种工作”和“面对 ChatGPT 最能打的 20 个‘金饭碗’工作”。这两篇文章的主要观点取自于他写的书《AI · 未来》和《AI 未来进行式》。
上周,即 3 月 14 日,李开复举办了一场规模不小的“AI 趋势分享会”,并做了一个关于 AI 2.0 时代的全面演讲。会后,对于这场分享的各种报道广为流传,如“李开复最新万字演讲”,“AI 2.0 是绝对不能错过的一次革命”等。
舆论影响力有了,技术影响力也有了,此时李开复决定加入这场中文版 ChatGPT 的“混战”,或许并不意外。
正如李开复在朋友圈最后所说,AI 是他 40 年前就决定的主场,而 40 年后的如今,他将“继续撸起袖子”:
参考链接:
https://www.chuangxin.com/blog/ai-2-0
https://weibo.com/kaifulee
☞李彦宏谈文心一言:市场反馈符合预期;OpenAI CEO 承认害怕 ChatGPT;Twitter 将开源推荐算法源码|极客头条 ☞FSF 公布 2022 年自由软件获奖名单 ☞前苹果工程师吐槽:“Siri” 代码过时且复杂,不可能变得像 ChatGPT 一样强大
出品 | CSDN程序人生(ID:coder_life)
多模态 GPT-4 拿出傲人成绩
(图源:ABC 新闻截图)
背后的风险让 Sam Altman “彻夜难眠”
眼看着, GPT-4 朝着 OpenAl 最终构建的 AI 目标向前迈进,却不料它的强大和成功,却好像在 Sam Altman 的心中埋下了一颗“定时炸弹”般,背后的风险让 Sam Altman 彻夜难眠。
他曾表示:“我特别担心这些模型可能会被用于大规模的虚假信息,如今它在编写计算机代码方面做得越来越好,不排除用于攻击性网络攻击。”
因此,Sam Altman 强调 OpenAl 需要监管机构和社会尽可能地参与。ChatGPT 的迭代中,需要有效的阻止该技术可能对人类造成的潜在负面影响。
随后,他补充说道:“他们在 OpenAI 有一个政策制定者团队,他们决定哪些信息进入 ChatGPT,以及允许 ChatGPT 与用户共享哪些内容。我们正在与各种政策和安全专家交谈,对系统进行审计,试图解决这些问题,并产出更安全和优质的东西。”
职业被取代 or 个人成为赢家
无论 AI 技术的优势和劣势在何处,最令大家担忧的仍是工作是否被替代的问题。
Sam Altman 也坦言道:“可能不久的将来会取代一些工作”,并对这种情况发生的速度表示担心。
但值得一提的是, Sam Altman 也鼓励人们将 ChatGPT 视为一种工具,而并非替代品:“人类的创造力是无限的,我们可以从中找寻新的工作和新的事情。”
IT 招聘公司 The Bridge 的主管 Andy Wadsworth 认为,像 ChatGPT 这样的服务是公众进入潘多拉魔盒的第一个窗口,这个魔盒有可能成为工业革命 3.0 ,这其中会产生赢家和输家。他表示:“毫无疑问,一些工作将被人工智能取代,但是那些学会使用生成式人工智能的人,可以更好的适应新公司和成为赢家。”
伴随着# ChatGPT 之父承认他有点害怕#等话题登上热搜,也不禁引发起许多中国网友的激烈讨论。一些网友持消极态度,表示:“感觉人的思考能力会弱化”、“我就是执行层面的工作,还是很惶恐”,但也有人对 AI 的发展保持乐观,表示:“或许替代了,人们可以去做更高级的事”、“这也将增加不少有门槛的岗位”……
现阶段,你感受到来自 ChatGPT 的威胁了吗?可以在评论区留言或讨论。
参考链接:
https://abcnews.go.com/Technology/openai-ceo-sam-altman-ai-reshape-society-acknowledges/story?id=97897122
https://www.businessinsider.com/sam-altman-little-bit-scared-chatgpt-will-eliminate-many-jobs-2023-3
https://abcnews.go.com/Technology/openai-releases-gpt-4-claims-chatbot-significantly-smarter/story?id=97858074
https://www.jiemian.com/article/8870188.html
☞李开复加入“中文版 ChatGPT”大战:宣布筹组新公司,招募世界级人才! ☞安装量远超 100 亿,代码行数过 15 万,curl 25 年蜕变史! ☞每四个员工就有三个从事研发,腾讯 2022 年研发数据发布!
"运维"的英文是 Operations,简写为 Ops,直译就是"操作",指的是各种服务器操作。
简单说,运维工程师就是管理服务器、保障代码运行环境的人。
这是很重要的工作,公司理应非常重视。但是实际上这几年,运维岗位一直在缩减,Ops 工程师被要求转型 DevOps 工程师。据我知道,很多运维工程师其实很苦恼。
应该怎么看待这种变化?运维有没有前途?将来会怎么发展?
最近,我读到一篇老外的文章,标题就叫《运维的未来是平台工程》。
"The future of Ops is platform engineering."
作者系统地回答了上面这些问题,认为运维最终将会消失,演变成一种新的工种----"平台工程"(platform engineering)。
我觉得他的文章很有启发,让我对运维的看法清晰了很多,分享给大家。
最早的时候,并没有运维,程序员同时负责编写和运行软件。
但是,编写软件和运行软件,其实是两种不同的技能:前者需要熟悉代码,后者需要熟悉服务器。
互联网软件发展起来以后,这两种技能就逐渐分家了。
开发工程师负责编写代码,运维工程师负责运行代码(即保障服务器运行环境)。
事实证明,开发和运维分家是一个巨大的错误。
写代码的人不了解服务器环境,管理服务器的人不了解代码在干什么,这样不利于做出优秀的产品,也不利于排查问题。
因此,有些公司就推动,开发与运维重新合在一起:编写软件的人也要负责运行软件。
这就是 DevOps 的由来,它等于 Dev(开发)+ Ops(运维)。
另一方面,互联网公司的核心资产和竞争力,更多的是代码,而不是运维。所以,公司也有意愿,把更多的力量投入在开发上,逐步压缩专门的运维团队,积极外包尽可能多的基础设施。
这两方面因素决定了,运维作为一个单独的工种,正在逐渐消失。
但是,DevOps 实际上没有办法取代运维。
越来越复杂的业务,注定了系统和基础设施也越来越复杂,同时还必须稳定可靠。
普通的开发工程师,根本不可能做到这一点。他既不了解所有基础设施,也达不到专业运维的系统管理水平。
这种情况下,公司就会选择外包,采购外部的云服务,把基础设施外包给专业的云服务商, 最大化压缩自身成本。
虽然总体上,运维是管理服务器,但是可以细分成两方面的职责:构建基础架构 + 管理运行环境。
"构建基础架构"指的是硬件的采购、安装、上架、联网这些工作。
"管理运行环境"指的是保障业务软件的运行。
DevOps 出现后,"构建基础架构"这一职责逐渐消失,变成了采购云服务,"管理运行环境"这一职责则是转给了 DevOps 工程师。
于是,新的问题出现了:谁负责采购和整合云服务?
采购合适的云服务,并不是一件简单的事情。
云服务纷繁复杂,各种 API、SDK 和配套工具令人眼花缭乱,即使经验丰富的运维工程师也不容易说清楚。
因此,需要有专职人员来做出正确决策,选择一套满足需要的云服务,并且负责编写工具,整合所有采购来的云服务,供业务开发使用。
这种角色就叫做平台工程,他负责评估、采购、整合各种云服务,作为自身的基础设施,并在外部云服务基础上构建自己的平台,让开发工程师能够在其上自助服务,将自己的代码投入生产。
上面的定义有几个要点。
(1)基础设施是外包的,以求成本和开发周期最小化。
(2)平台工程师负责整合外包的基础设施,构建成一个平台。
(3)开发工程师在该平台上,自主搭建和管理运行环境,自己运行代码。
平台工程与运维,存在几个显著区别。
(1)平台工程需要开发软件,包括编写测试和代码审核,团队的运作方式很像开发团队,有产品经理、甚至设计师和前端工程师。
运维一般不开发应用软件,最多就是写一些自动化脚本。
以前,有的工程师写代码,有的工程师跑代码。今后,所有工程师都编写代码,并且运行自己的代码,不管你是开发工程师、DevOps 工程师或者平台工程师,不同之处只在于按层或功能划分的职责范围不同。
(2)平台工程是云原生的,所有工作都存在于云上。
运维不是云原生的,需要自己管理硬件,只能说是支持云的。
(3)平台工程采购云服务,运维采购的是硬件。
随着传统的运维角色的消失,现有的运维工程师必然面临着转型,不外乎有三种出路可以选择。
(1)如果喜欢开发业务软件,可以选择成为 DevOps 工程师。
(2)如果喜欢开发平台软件,可以选择做平台工程,专注于基础设施的整合。
(3)如果更喜欢硬件和底层,可以选择加入"基础设施即服务"(IaaS)的云公司,深入研究基础设施。
(完)