亮网络解锁器,解锁网络数据的无限可能 了解详情
写点什么

辩证看待“幻觉”问题,蔚来汽车在 AI 和大模型领域的应用实践

  • 2024-04-28
    北京
  • 本文字数:6620 字

    阅读完需:约 22 分钟

大小:3.24M时长:18:50
辩证看待“幻觉”问题,蔚来汽车在AI和大模型领域的应用实践

随着新能源汽车大战进入“智能化”的下半场,受政策、技术、市场的驱动,车企竞相踏入 AI 大模型这片蓝海。就在几天前,蔚来自研的 NOMI GPT 端云多模态大模型也正式上线。


作为中国高端纯电动汽车市场的引领者,蔚来在人工智能领域是如何布局的?目前 AI 大模型应用已经在哪些场景落地?在研发过程遇到了哪些挑战、又将继续深耕哪些细分领域?在日前举办的“人工智能 X 金融科技创新大会”上,蔚来汽车用户数字产品算法专家兼副总监潘鹏举回答了这些问题,并分享了自己对 AI 大模型架构、大模型发展难题的见解。


本文整理自其演讲,内容经 InfoQ 进行不改变原意的编辑。


本次演讲内容分为四部分:第一,简单介绍一下蔚来的业务;第二,分享一下蔚来的 AI 大模型应用架构是怎样布局、设想的;第三、第四部分,分别是从整个人工智能算法应用和大模型应用的两个角度出发介绍蔚来在这一领域的实践。


关注「InfoQ 数字化经纬」公众号,后台回复「蔚来」即可获取本次演讲 PPT

人工智能应用布局要围绕业务展开


之所以要先介绍蔚来的业务背景,是因为无论是哪个公司,其人工智能应用如何布局都取决于业务范畴。蔚来的业务就如这个罗盘图所示,包含四个维度:产品、服务、社区和数字化。



在产品方面,蔚来的核心产品是纯电的智能电动汽车,“智能化”在产品上的体现就是自动驾驶,因此蔚来在智能驾驶上投入的资源很多,这也是蔚来的核心竞争力。下图展示了蔚来目前已推出的 9 款车构成的产品矩阵。



围绕智能电动汽车,蔚来以“创造愉悦的生活方式”为使命,以“成为用户企业”为愿景,希望通过以智能电动汽车为起点,为用户提供高品质的服务与创新的解决方案,打造一个充满活力的社区,和用户共同成长。这是蔚来业务体系中较为特殊的一点。


蔚来提供的一系列与“车”紧密相关的服务,包括补能、换电、充电,都与其配套。下图为蔚来的充换电设施布局分布图。截至 2024 年 3 月 25 日蔚来已经有 2392 座换电站,3737 座充电站,两万多根桩。



围绕整个产品、服务、社区应该怎么做?核心就是数字化和智能化。

场景优先、注重工程化架构,更新 AI 三要素概念


提到最著名的人工智能“三要素”,毋庸置疑就是“数据、算法、算力”。除了这三个最常提及的要素,我认为还要加上另外两个要素,一个就是“场景(Scenario)”,它要置于“数据、算法、算力”之上,因为在 AI 实际应用中“场景”是决定 AI 能否真正帮助到公司的重要因素,如果场景选择失误,将对整个投入和业务产出带来非常大的影响。


另一个要素是工程化(Engineering)。很多时候即使人工智能算法做得特别好,但因为响应时间过长,在实际业务场景中难以落地。举个例子,APP 的个性化推荐,对算法响应时长有很强的时效性要求。对有些用户而言 500 毫秒甚至 200 毫秒都非常多、不愿意等待,响应时间多一秒都会流失很多用户。所以在工程化方面,时长是非常重要的体验因素,决定了用户的满意度。



算法(Algorithm)层面,分为传统的小模型和大模型两套范式。蔚来的人工智能应用从整体方向上来说是以大小模型双轮驱动的方式在做。我们会把很多的重心放在大模型上面,但也不会忽略小模型的应用。


在 AI 平台层,有两处被标红的地方,“AI 训练框架”和“AI 推理引擎”,这两个环节在大模型应用中非常重要,要求算力和工程化架构都足够好。目前很多公司的算力都不足够支撑人工智能应用。在整个人工智能应用架构里,“算力”以及“工程化”也就是怎么去更好地部署人工智能,也是关键问题。


无论是场景、数据、算法、算力、流程化中的哪一方面,人工智能“五要素”实质是围绕用户和服务展开的。在蔚来,围绕产品层面,我们要做自动驾驶(AD)、智能座舱,围绕用户触达的渠道我们要做 NIO House、服务中心、交付中心。


大模型架构层层递进


我们对大模型应用架构的布局和构想,与行业主流做法比较接近。以开源大模型做基座,再结合公司的数据做垂类大模型的开发,整体架构包括基建层、模型层、开发层、应用层四个层面,重点支撑不同领域的垂类的大模型的开发和应用。基建层包括一些工具和资源,其上是一些基座大模型,再向上有很多工具链,最顶层是应用层。应用层是结合我们自己的数据后形成的,也分为了自动驾驶、用户服务与社区等等不同的维度。



有了架构之后具体怎么做?其实核心还是刚刚提到的“大小模型驱动”,保留小模型的同时,在不同的特定场景下结合大模型的能力升级智能体验。


最近我们在自动驾驶领域做了一些尝试,探索的核心目的是希望能通过过去所有路况信息来生成一个真实的世界,我们内部也已经取得了一些结果。其次我们聚焦 NOMI 机器人,在过去机器人研发成果的基础上进一步结合大模型技术做整体智能化体验升级,最终将它运用于座舱智能客服,与客户对话交互。


蔚来的人工智能应用分为 to B 和 to C 两大板块,本质上仍然是用人工智能为业务赋能,只是各个层面在赋能的程度上稍有不同,有偏向辅助的、有替代人工的、也有可以成为机器人的。我认为 AI 替代人工的过程其实是慢慢地从简单到高级的,未来我们的 AI 有可能发展成一个真正的智能体。从这几个角度出发,我们在不同的场景做了不同的设计,在 to C 端和 to B 端的设计思路也不太一样。

人工智能算法应用实践

案例一:错峰充电

人工智能算法相关实践方面,我举的第一个例子是一个能源解决方案,它比较特殊、大家平时很少接触,是我们公司遇到的比较独特的问题。换电服务中换电站需要提前给电池充好电,不同时间段的充电价格是不同的,在用户需求量较大时电价也会较高,用户什么时候充电就会影响电费成本。


假设现在有两千多座换电站,一个换电站十块电池,那就有两万多块电池;一个换电站一天充一度电,那就是两万多块钱。我们的实际成本比这个假设还要多得多,因此电费的成本巨大。那么有什么方法、机制和算法能够实现每一天的充电成本最小化呢?在此背景下,我们做了“错峰充电”这个项目。“错峰”的概念指的是让换电站在电价较低时提前给电池充电,在电价较高时换电给用户。


进行“错峰”的第一步是预测用户的需求订单。如果用户不来充电,换电站就可以少充甚至不充以节约成本。首先要准确的预测用户什么时候来换电,才能进行何时充电、充多少电的决策。这一过程有很多约束条件,要在满足用户体验的前提下进行决策。


这个方案与智能驾驶的逻辑比较相像。第一,通过时序预测感知到用户的需求量。第二,用运筹优化算法计算充多少电能达到收益最大化。最后,指令下发、决策和策略的执行。为了规避整个业务系统在诸多环节中出现的问题,我们还要通过一系列策略设计来实现流程闭环。


我们尝试了很多时序预测算法并进行效果对比,就整体而言,深度学习算法的预测能力比传统算法或树模型好很多,并且不同深度学习模型之间的效果大致接近。



在有了需求预测后应该怎么去决策呢?下图展示了如何进行运筹优化算法以实现收益最大化。这个环节的核心在于将“怎么算”这件事和具体的业务逻辑抽象成多个结果,从这些结果出发去计算当前每充一块钱电能获得多少收益,基于这套逻辑不断修正模型。



接下来展示的这张图中,下半张图是电价随时间变化的折线图,上半张图是应用不同充电策略后的电费成本,我们工作的核心就是降低在尖峰时刻的充电量。



最近业界有一些声音在探讨 AI 的未来是不是要与能源挂钩,其实从这个案例中我们会发现,无论是 AI 的应用,还是我们业务的各方面,能源对它们产生的影响其实非常大。对蔚来而言,通过这个算法我们大概能节省几千万的成本,带来很高的收益。随着未来 AI 算力越来越高,其本身能源的消耗量也将大得惊人。从这个角度出发,我们能看到 AI 应用向节能领域发展的一个趋势

案例二:智能运维


与大家平时经常听到的智能营销不同,第二个案例是智能运维方案,这是我们这一行业经常遇到的问题。当充电枪长期使用后会出现劣化的情况,导致后续的用户跳枪或者无法充电,我们就需要对所有换电站和充电桩的每一个设备、每一个零件进行监测,以及时发现哪些枪头有劣化迹象,进而提升用户体验。


监测的方法有很多,比较传统的方法就是直接收集设备所处环境的温度、湿度等各方面影响因素的数据并进行预估,就能大致得出设备能否正常充电的结论了。下面这张图展示的就是⼯业机理分析的结果,即根据充电枪的充电电流、电压、温度等物理信号建立物理模型得到枪头的温升系数物理量,并以此为信号进⾏故障诊断。从结果来看这种机理模型其实也有一定效果,但正常枪头信号和异常枪头信号结果之间的差异不够显著。



对此我们进一步做迭代,输入了整体的、持续的数据,并基于输入的数据去判断波形和趋势有无异常,把机理模型升级到基于 Conceptor-AI 算法检测模型 + 机理模型。这一方案其实并没有完全抛弃传统做法、只使用深度学习算法,而是融合了人类经验知识与机器算法,最终使误报警数减少⾄20%,准确率提升了 10pct。


案例三:APP 个性化推荐


第三个案例和很多互联网公司 APP 遇到的问题很相近。蔚来的 APP 内容本身很丰富,除了售车信息,还有汽车资讯、相关商品售卖、充电地图服务等等内容。不同板块下的相关内容推荐的场景和入口都不相同,因为不同内容推荐对应的业务领域有不同目标。比如对于资讯类内容,我们追求的是高点击率;对于商品,我们追求的是 GMV(商品交易总额)。


一个 APP 内要做很多场景、每个场景有不同的目标,那么每个场景都需要用不同的算法去实现对应的目标吗?其实不然,我们最终只做了两件事。针对这么多的场景,不形成一套系统就很难支撑这么多业务,因此我们做的第一件事就是把个性化推荐的系统架构抽象出来。其中较为特殊的是,我们把搜索和推荐合并为一套,而不是单纯只做推荐系统,这与搜索只存在于索引步骤的情形有区别。


第二件事是围绕业务背景对算法目标体系进行整体优化和提升。其实我们最终想解决的只有一个问题,就是能不能通过一些非常简单的数据、用 1 到 2 个核心算法去解决所有业务场景的问题。


这是我们现在正在尝试的一个解法,即打通所有底层数据。完成数据共通之后,我们在算法层面又引入了一个目前比较好的方法,即专家网络(MoE)。在不同的业务场景里使用不同的专家网络去学习不同的权重,然后再做一些应用层,围绕最终业务目标,输出不同的业务指标,从而尽量降低整体维护的工作量。


为什么要这么做?另一个原因是场景化开发方式对每个业务人员的依赖度很高,会对不同业务领域有很强的业务理解,比如造特征造得如何。但其实项目进行得越多,我们发现可以用一些比较简单的数据和复杂的模型来解决下游推荐效果的问题提高整体迭代效率和输出成果。这是我们在 APP 个性化推荐方面的一些想法和做法。

大模型应用场景探索


蔚来在大模型应用方面的探索可分为四大板块:知识洞察、内容生成、Copilot(智能助手)、Agent(数字代理)。



这里我想着重提到的一个点是知识洞察。知识洞察涉及到许多方面。在过去,我们与用户交互时的很多数据并没有得到充分挖掘。比如公司和用户在语音交互过程中的各个触点都能产生很多的数据。在过去,对电话销售数据的挖掘方式是定义很多标签来分类,这一方式效率很低。在过去,我们对业务的结构化数据挖掘比较多,但对非结构化数据的挖掘还不够深,因此我们也在这方面投入了很多精力。


回到大模型能力本身,有两个能力可以利用:第一,大模型的理解能力特别强;第二,生成能力特别强。围绕这两个层面我们都做了一些尝试,利用 AIGC 的生成能力提升效率。


其实从生成的角度上来说,大模型幻觉不一定是件坏事。因为在某些场景下,特别是在创意类的场景里,幻觉是恰恰是有帮助的。如果生成出的内容非常中庸,也难以为工作提供启发。但是在理解的层面,仍然要考虑怎么去避免幻觉的问题。在不同的业务场景里,大模型要解决的问题是不同的。


针对 Copilot 和 Agent,我们重点围绕智能客服做迭代升级。Copilot 方面,我们其实做了很多应用,特别是在用户服务层面我们有非常多的知识,我们利用 Copilot 对这些知识如何分发、如何检索做一些尝试。整体上对于内部工作有一些提升,但并没有我们想象的那么惊艳。Agent 方面,我们用大语言模型的范式重新做了整套智能客服,有一些效果、但依然有很多问题要解决。

案例一:内容质量标签

接下来我想举一个典型的大模型应用案例,即在知识洞察层面如何基于大模型打内容质量标签。在过去打内容质量标签很简单,只需要以数量为标准,根据某个内容中有多少张图片、有多少个文字、有多少种主题来打标签,而现在则还需要进一步考虑主题究竟够不够丰富、图片够不够美观。这种内容质量升级就意味着要考虑更多语义信息


如果用传统的方式进行这一工作,就需要大量人力来产生标注数据,告诉我这些海量图片中有哪些维度是比较好的。而如今基于大模型,我们已经有了新的范式,其中有两个点向大家分享。


第一,大模型提效的成果非常显著。只需要告诉大模型“帮我总结这部分内容里大概有多少个主题,图片质量如何”,它就能帮你进行简单的理解。


第二,我们形成了一套新的基于大模型的打标流程。过去无论是用大模型算法还是用传统算法,都是业务给我一个需求,我造样本来实现需求。有了大模型之后,我们和业务人员的协作模式发生了变化,让业务自己写 Prompt(输入大模型的指令或问题),业务在发现得到的样本结果不符合预期时就可以自己调整。



基于这样的协作模式,相比过去有两个优点。第一,解决了业务信任度低的问题。过去合作中很多时候业务会不太信任你,对他们而言算法是个黑盒、不知道如何调优;现在可以把这个逻辑直接交给业务,由业务自己去调整,把黑盒的东西变成了白盒化,业务对算法的控制能力变强了。


第二,提升内部工作效率,让我们能安心做好算法。有了业务给出的 Prompt 后,我们只需要考虑用新样本集做好大模型的微调、部署上线,反向交给业务、再优化 Prompt,业务又会进一步补充样本数据。这个过程中算法做好需要算法调整的工作,而业务也能了解算法是如何成形并优化的。无论是准确率、召回率还是开发周期,用大模型打标签都有较大提升。



为什么举这个例子呢?是因为我们发现其实有很多业务场景都与打标签很相像。比如说智能客服要做的就是理解用户说了什么,如果把用户的意图视作一个标签,那么智能客服实际上也在做打标签这件事。所以基于大语言模型标签范式能够应用在很多业务场景中。接下来我们会把这一套标准流程变得更产品化

案例二:二维码生成


第二个大模型应用案例展示了我们在内容生成方面的一些探索。我们一直在思考一个问题,与用户交互有很多不同形态。从技术本身来说,它不是一件非常难的事。


比如把原有的、用户熟知的交互方式通过大模型转换成新形态,这样的互动能够给用户一些新鲜感、提升用户体验或效率。并且提供了更好玩的玩法之后,用户继续体验的意愿也有可能会提升。因此 AI 大模型在营销领域有非常丰富的应用场景。



将大模型的内容生成能力应用于生成独特的二维码,这一应用还存在一些挑战。首先,每个公司都有自己的品牌调性,Logo 如何设计、放在什么位置都要依循一定的规范,我们还要围绕规范问题不断优化迭代。其次,我们对素材创意生成做了很多尝试,但这个场景应用做的快、上线慢,存在很多天然的问题。

大模型落地 C 端存在四大挑战


对于大模型究竟价值几何的问题,我们肯定要从长期去看,但是大模型本身的短期价值可能并没有大家想象的那么高。大模型要想真正在 to C 端落地还面临很多挑战。


首先就是监管问题。AIGC 一旦面向 C 端用户、进行大规模应用,就需要监管报备,而报备所需的周期很长、牌照也很稀缺,这是绕不开的难题。


第二,大模型幻觉的问题。刚刚也提到过,对于这一问题我们要辩证看待,在不同的场景下,有时幻觉可以给我们带来帮助,但有时需要我们解决。从大模型技术本身来说,业务应用怎么和大模型的幻觉共存是个永恒的话题。无论是什么方式,结合传统的方式也好、还是基于大模型的方式也好,幻觉问题一定是存在的。所以应该怎么把握好共存还是规避的边界,也是一个比较核心的问题。


第三,算力问题。算力很稀缺,每个公司自研大模型难度很大,不仅缺卡,还缺数据。即使是随便做了一些 SFT(Supervised Fine-Tuning,监督微调),花费的时间也不少。如果要完成非常多的大模型优化,那么算力肯定是不可或缺的。


第四,性能问题,也是在我们目前的 AI 大模型应用中遇到的比较大的问题。大模型性能不足、响应时长较长,将会对使用场景产生限制。其实业界已经有很多解决这一问题的框架,但其中很多本身都存在缺陷,需要针对整个框架做一些定向的优化和提升。在不同的应用场景里,对性能的要求也不太一样,需要不断调优。

公众号推荐:

跳进 AI 的奇妙世界,一起探索未来工作的新风貌!想要深入了解 AI 如何成为产业创新的新引擎?好奇哪些城市正成为 AI 人才的新磁场?《中国生成式 AI 开发者洞察 2024》由 InfoQ 研究中心精心打造,为你深度解锁生成式 AI 领域的最新开发者动态。无论你是资深研发者,还是对生成式 AI 充满好奇的新手,这份报告都是你不可错过的知识宝典。欢迎大家扫码关注「AI前线」公众号,回复「开发者洞察」领取。

2024-04-28 16:138745

评论

发布
暂无评论
发现更多内容

科技热点周刊|PHP 基金会成立、Rust 内讧、Amazon Linux 2022 预览版发布

青云技术社区

云计算

实战篇:Security+JWT组合拳 | 附源码

阿Q说代码

spring security JWT 签约计划第二季 权限验证

语法糖甜不甜?巧用枚举实现“状态”转换限制

阿Q说代码

枚举 签约计划第二季 语法糖 订单状态转换

PackML从会到不会——标签(3)

陈的错题集

标准化 PackML

如何设置Activity背景颜色与ProgressBar进度条颜色

Changing Lin

12月日更

【活动报名】Apache ShardingSphere Dev Meetup 重启!

SphereEx

开源项目 开源社区 ShardingSphere Meetup SphereEx

看了这么多年西游记,你可知道孙悟空是如何召唤土地公公的吗?

阿Q说代码

Java 观察者模式 签约计划第二季 事件通知机制

WeTest小程序质量专项方案推出,小程序异常监控内测招募中

WeTest

高校企业双向赋能,首届飞桨启航菁英计划圆满结束

百度大脑

人工智能 百度 飞桨

大数据中不同文件格式的比较

DisonTangor

大数据 云存储

实战篇:断点续传?文件秒传?手撸大文件上传

阿Q说代码

断点续传 签约计划第二季 文件秒传 文件分块 文件合并

恒源云(GPUSHARE)_GPU白嫖大法来袭!

恒源云

深度学习 gpu 算力加速

【量化】股市技术分析利器之TA-Lib(一)

恒生LIGHT云社区

量化投资 量化

Flink CDC 系列 - 构建 MySQL 和 Postgres 上的 Streaming ETL

Apache Flink

大数据 flink 编程 后端 实时计算

用户登录设计之双token设计

CRMEB

后端开发实战总结 | 签约计划第二季|后端

阿Q说代码

内容合集 签约计划第二季 技术专题合集

【量化】股市技术分析利器之TA-Lib(二)

恒生LIGHT云社区

量化投资 量化

Flink 是如何统一批流引擎的

编程江湖

大数据 flink

还在用BeanUtils拷贝对象?MapStruct才是王者!【附源码】

阿Q说代码

Java MapStruct 签约计划第二季 深拷贝与浅拷贝

「Spark从精通到重新入门(一)」Spark 中不可不知的动态优化

尔达Erda

云计算 大数据 spark 开发者 感悟

长连接网关技术专题(六):石墨文档单机50万WebSocket长连接架构实践

JackJiang

websocket 即时通讯 IM 网关

秒过!度目智慧通行让常态化防疫更高效

百度大脑

人工智能 人脸识别

对象存储手把手教七 | 存储空间授权策略 Bucket Policy

QingStor分布式存储

分布式系统 对象存储 分布式存储 分布式,

看了同事写的代码,我竟然开始默默的模仿了。。。

阿Q说代码

策略模式 多态 签约计划第二季 自定义参数解析器 统一验签

『上线』OpenSEC SIGs 终于成立了!

SphereEx

开源社区 ShardingSphere SphereEx 中文开源 OpenSEC

ZEGO 即构科技首发适配鸿蒙系统的 Express SDK 1.0 版本,并正式启动公测!(内附源码)

ZEGO即构

音视频 HarmonyOS 鸿蒙开发 即构科技

Spark从入门到精通

冇先生

IoT Stack 2.0升级物模型及数据交互协议, 大幅提升物联网方案交付速度

百度大脑

人工智能 百度 物联网

博文推荐|使用 Pulsar IO 打造流数据管道

Apache Pulsar

Java 开源 架构 云原生 Apache Pulsar

Linux学习方法《Linux一学就会》Linux系统进程管理

侠盗安全

Linux linux运维 运维工程师 云计算架构师

如果还不懂如何使用 Consumer 接口,来公司我当面给你讲!

阿Q说代码

函数式接口 签约计划第二季 consumer 实战讲解 supplier

辩证看待“幻觉”问题,蔚来汽车在AI和大模型领域的应用实践_企业动态_潘鹏举_InfoQ精选文章