作为一名数据团队的管理者,已经带着团队入局大模型一年有余,关于大模型应用方面的探索,自己在《业务为王,大模型应用的探索和思考!》一文中进行了介绍。其实不只是我们,相信很多数据团队也在进行大模型应用的尝试,大家都认为这是一次机会。客观的讲,数据团队搞大模型,挑战还是很大的,我这里主要谈谈自己团队当前面临的挑战,同时也谈谈初步的解决思路,供大家参考。第一,就是想清楚why和what,寻找最合适的,最细分的业务场景。企业搞大模型,应用为王,这是业界的共识。但很多想搞大模型的团队,其实是缺乏业务场景的。比如数据团队相对于CRM、ERP、人力、财务、综合办公、客户服务等业务团队,那应用场景就少太多了。当然对于数据团队来讲,数据管理、数据分析本身也算是一种业务,因此ChatBI、ChatSQL等都是可以尝试的方向。但即使有了方向,也一定要想清楚在哪个合适的业务场景进行切入,我曾经想象老板使用ChatBI的场景,比如对着APP说“我要看下近三个月的欠费指标“,但老板这种自助要指标的场景实际是不存在的。很多研究ChatSQL的数据团队设想的场景是业务人员嘴巴一说,SQL就写好了,然后取数和报表呈上来了,然后大家就解放了。我就对项目经理说:“你到实际一线调研看看,这是真实的场景,还是你想象出来的需求?”项目经理回来告诉我某个地市某渠道人员有这个需求,我说有几个人有?现在的支撑流程有很大问题吗?人家提个需求给IT也很方便,为啥要自己动手?然后......。20年前,老外就开始提BI这个概念,20年过后,我们的BI用的很好吗?也许老外喜欢自己DIY数据,但国内大多数企业不是这样的,这里面有机制和文化的原因。因此还是要实事求是,因地制宜,不要脑补需求。有人就讲,我们可以培养用户习惯啊。我说这需要公司老板的支持,还要很多的运营资源,不到必要时,谁愿意改变工作习惯啊,因此一定要慎重,毕竟咋们不是乔布斯。我并不否认数据团队要往ChatBI、ChatSQL这些方向努力,但一定要分析清楚公司什么样的角色,针对哪些特定的报表、指标、取数场景,有简单的、高频的这类分析需求,比如为某类渠道人员提供灵活的特定考核指标的生成能力,鉴于受限的开源大模型能力,场景的选择还要越细越好,因为简单能降低对技术的要求。因此,对于各种“ALL IN AI”的说法,大家看看就好,回到企业,还是要“业务为王,场景细分,谨慎入局”。第二、就是想清楚who来做,大模型应用的成功概率与业务参与度成正比。就像大数据刚起来的时候一样,当前技术人员是最有激情去做大模型应用的,现在各种技术大佬都在宣传大模型,畅谈对大模型的看法,感觉大模型就是技术界的盛宴。但普通企业做大模型应用,还是要回归商业本质,就是为了赚钱或者提升效率,因此,一定是要让懂业务的人员来进行方向的把控和场景的选择。例如,我们做了数据目录元数据自动生成的“智典”大模型应用,效果还是不错的。其实我就是这个大模型应用的首席产品经理,因为我做了20年的数据管理和治理,我对这个业务场景有足够的发言权,比如我知道数据目录元数据的问题在哪里,原始的语料够不够用,对误判率的容忍度有多高,做出来的东西最低限度可以用在哪个环节等等。例如,针对报表取数这种场景,一定是前端人员(比如需求管理员)走在最前面,应该由他们去担任产品经理,不懂大模型也不要紧,在干中学就可以了。考虑到大家平时忙于日常事务,组织可能还需要做出岗位和职责的调整。但光有懂业务的人员,没有数据团队的支持也不行,因此一定要做好业务团队和数据团队的协同,组建跨专业的项目团队是一种可行的方式。我正好同时管理着管信和数据两只团队,因此在chatoa、公文核稿这类大模型的应用场景上做了深度融合的尝试,管信团队由于对人力、财务、办公、供应链等业务非常熟悉,因此由其做产品经理是非常适合的,数据团队的人员则负责语料和建模,这样就可以发挥各自所长。组织架构决定系统架构,我们的第一个成功的大模型应用”智能核稿“就是两者成功合作的产物,有条件的企业如想搞大模型,一定要想清楚如何优化组织架构以适配新的生产力的要求。面对这一波生产力革命,组织一定要进行变革。可以这么说,一个企业搞大模型应用成功的概率,与这个企业当前调动了多少业务力量成正比,与业务和数据协同的深度成正比。没有多少前端人员参与的各种大模型应用,几乎都会失败,我承认技术人员在面对一项新技术时会更加敏感,也更富激情,但这些都不足以让其在业务上获得成功。现在很多大模型应用卡在技术上,大家都觉得技术很重要,这一点我也承认,但技术到了一定的水平后,需要转化为业务问题来解决。比如幻象问题本身就是AIGC的一个特征,在解决到一定程度后,我们能做的,就是基于特定的业务场景解决特定的幻象问题,而这个也完全依赖场景的选择和业务对幻象问题的接受度。第三,就是想清楚how,而语料是企业大模型应用成功的决定因素大家都知道要做大模型,场景+算力+算法+数据缺一不可,当然很多人会说平台和工具也很重要,但考虑到当前大多数企业都在从0到1做大模型应用,离规模化还为时尚早,因此,诸如MaaS这种平台当前建设或购买的必要性还不是很大,至少迫切性不是那么高。那么,除了前面说到的场景,算力+算法+数据这三者,哪个是企业大模型应用成功的决定性因素呢?算力显然不是,当前有智算的企业的确抢了先机,但毕竟智算还是能买到,或者至少慢慢大家都会有,随着量化等算法的推出,也许100亿参数对企业大模型就足够了。算法在机器学习时代可能大家差距很大,但到了深度学习阶段变小了,而到了大模型阶段,基础大模型和开源大模型让大家在算法上的差距抹的更平了,基础大模型成为社会的基础设施是必然的趋势,就像水电煤一样。现在各类基础大模型你方唱罢我登场,大家其实都是为了争取生态位置,跟大多数企业没啥关系,基础大模型成为不了企业大模型的竞争力,你要做的就是做好测试和选择,不同的基础大模型在不同业务场景的表现可能天差地别。最后决定企业大模型成功的关键因素,其实是语料+微调能力,微调能力随着各种平台工具的推出,门槛会越来越低,直到大家都差不多,预计这种平台马上会成为红海,当前现在还是比较稀缺的。只有这个语料,是所有通用基础设施都提供不了的,它是企业特有的生产资料,这种特有的生产资料创造了特有的生产力,体现了企业领域大模型独一无二的价值。但现实情况是,大多企业并没有做好自身语料的准备工作,未来越来越多的企业会深陷“巧妇难为无米之炊”的困境,根本原因是数字化水平低了,或者数据治理能力不够,这将极大限制企业大模型的应用拓展和深化。首先,AIGC需要的语料大多是非结构化数据,但大多企业对非结构化数据的的管理能力非常薄弱,大量的非结构化的日志数据没有保留,大量的文档数据散落在各个系统。比如我们团队虽然已经做了多年的数据治理,但也仅仅是把结构化数据管好了,但非结构数据的记录、采集、解析还处于刚起步的阶段,我想大多数企业的大模型团队都会有“数到用时方恨少”的感叹。其次,大量的业务系统都是匆忙上马,关于业务系统本身的元数据信息极度缺乏,没有任何Chat的基础,准备语料的工作繁杂而艰巨,而由草台班子构建起来语料准备团队很难保证数据的质量,而低质量的语料又很容易导致很差的微调效果。对于大多数企业来讲,这是一个大模型语料数据极度匮乏的时代,我们以前以为把系统和应用文档写好了聊胜于无,大家都是实用主义,急着上线,现在发现原来它们是全面智能化的基础。举个例子:我们想做个管信系统的应用导航功能,发现管信对各类应用系统的描述信息非常少,比如商旅100是公司订酒店和机票的系统,但没有足够的元数据信息,当用户在大模型上输入”订酒店“想找到商旅100这个应用时,大模型就推理不出来了。为了做这个应用,我们只能重新去梳理和完善每个应用的元数据描述信息,其工作量很大,难度很高,因为公司的应用太多了,我们几乎不可能调动公司这么多资源去梳理这些语料,目的就是为了一个导航功能,因此很多大模型应用的想法很好,但实际上落地的代价极大。最后,语料的梳理和完善是个苦活累活,现在非结构数据的管理还是个技术活,企业如果没点基本的数据治理能力和技术能力,门槛还是挺高的。当初我们做错别字大模型的时候,为了高质量语料处理了上万的文档,足足花了几个月时间,效率还是很低的。我们并没有为语料准好准备,每次大模型应用在数据准备上的代价太大了。李彦宏说出了未来应用都可以用大模型重构一遍的论断,意味着企业所有的应用的数据采集模式需要重构一遍,未来数据治理的要求会贯穿在任何一个应用的构建过程中,不留存数据不允许应用上线还真的成为了可能,这凸显了企业数据治理的巨大价值。大模型时代,数据团队最重要的一个工作,就是把公司的大模型数据集供给体系建立起来,这一定是大模型应用的最重要的基础,而有没有足够的语料,将成为企业评判是否要上马一个大模型应用的黄金标准,数据团队真的是三生有幸,每10年都碰到一次建功立业的机会。在大模型应用上,想清楚为什么做,做什么,由谁来做,怎么提供生产资料,这是大模型应用建设的大道,这些工作,大多时候比攻克一个技术难题重要的多。Be different, not better,希望于你有所启示!