本文来自微信公众号“与数据同行”，作者：傅一平

　　作为一名数据团队的管理者，已经带着团队入局大模型一年有余，关于大模型应用方面的探索，自己在《业务为王，大模型应用的探索和思考！》一文中进行了介绍。其实不只是我们，相信很多数据团队也在进行大模型应用的尝试，大家都认为这是一次机会。

　　客观的讲，数据团队搞大模型，挑战还是很大的，我这里主要谈谈自己团队当前面临的挑战，同时也谈谈初步的解决思路，供大家参考。

　　第一，就是想清楚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，希望于你有所启示！