从业务到数据，大模型应用成功的再思考！

不过话说回来，数据团队做AI应用，挑战真的不小。今天不聊大道理，就说说我们团队当前碰到的几个真实问题，顺便聊聊初步的破局思路，希望能给同类团队一点参考。

企业搞大模型，应用为王——这句话最近都快被说烂了，但说得越多，越说明一个问题：真正搞过大模型的团队都明白，缺的不是技术，而是实打实的业务场景。

相比CRM、ERP、人力、财务这类直接服务一线的业务团队，数据团队能切入的场景本来就少。但话说回来，数据管理和数据分析本身也是一种业务——ChatBI、ChatSQL这些方向，自然就成了数据团队尝试的首选。

但问题来了：场景虽然明确了，它真的成立吗？

举个例子，我曾经设想过老板用ChatBI的场景——比如对着APP说一句“我要看下近三个月的欠费指标”。但实际调研发现，老板从来不会这么用。你想想，老板需要什么数据，自有人安排好，不需要他自己动手去“对话”。

再比如，不少团队在研究ChatSQL时，脑子里浮现的画面是：业务人员动动嘴，SQL自动生成，报表秒出，IT部门从此解放。我当时就跟项目经理说：“你先别脑补了，亲自去一线调研，看看这是真需求，还是你想象出来的。”结果他说某个地市的某个渠道人员确实有这个需求。我追问：“一共有几个人需要？现在IT支撑流程很麻烦吗？提需求不方便吗？”问完之后，答案就清楚了。

说白了，20年前老外就开始讲BI，20年过去了，咱们的BI用好了吗？老外可能习惯自己DIY数据，但国内企业的文化和机制完全不一样。所以，一定要实事求是、因地制宜，不要帮用户“发明需求”。

有朋友说：“我们可以培养用户习惯啊。”我说，这需要老板强力支持，加上大量运营资源。不到万不得已，谁愿意改习惯？咱们又不是乔布斯。

我并不反对数据团队往ChatBI、ChatSQL方向努力。但必须分析清楚：公司里什么样的角色，有哪些高频、简单的报表和取数场景？比如，为渠道人员灵活生成特定考核指标，这个就靠谱。而且由于开源模型能力受限，场景越细越好——越简单，对技术门槛的要求就越低。

所以，对于“ALL IN AI”这类话，看看就好。回到企业，核心还是那句话：

。

这波浪潮最让人眼热的是技术人员。就像当年大数据刚起来时一样，技术大佬们争相发声，讨论技术趋势，仿佛这是技术圈的主场。但对企业搞应用来说，本质还是回归商业——赚钱或提效。所以，懂业务的人必须走在前面，由他们来把控方向和选择场景。

举个例子，我们团队做了一个叫“智典”的应用，专门做数据目录元数据的自动生成，效果不错。其实我就是这个项目的首席产品经理。做了二十年数据管理和治理，我对这个场景太熟了。我知道元数据问题到底出在哪，原始语料够不够用，误判率到什么程度能接受，做出来的东西最低能用在哪个环节——这些判断，光靠技术视角很难做出来。

同理，如果是报表取数场景，最理想的产品经理应该是前端的需求管理员。他们不懂大模型没关系，在干中学就行。但因为大家日常事务太多，组织可能需要调整岗位职责，才能释放出这部分精力。

当然，光有懂业务的人，没有数据团队配合也不行。跨专业团队会战非常关键。我正好同时管理管信和数据两支团队，所以在ChatOA、公文核稿这类大模型应用上做了深度融合。管信团队熟悉人力、财务、办公、供应链这些业务，产品和场景由他们来定；数据团队负责语料和建模，各司其职。

组织架构决定系统架构。我们第一个成功的AI应用——“智能核稿”，就是这种协作模式的产物。有条件的企业如果真想搞大模型，一定要想清楚：组织要不要变？怎么变？

这一波生产力革命，组织肯定要跟着调整。说得直白点：

那些没有前端人员参与、纯粹由技术组主导的大模型项目，几乎都会失败。技术人员的敏感度和激情，并不能直接转化为业务上的成功。

现在很多应用卡在技术上，大家总觉得技术问题最重要。这一点我不否认。但技术水平到了一定阶段后，就会转化为业务问题。比如“幻觉”问题，本就是AIGC的特征，解决到一定程度后，我们能做的、也是最该做的，就是在特定场景中解决特定的幻觉，而这完全取决于场景的选择和业务方对“出错”的容忍度。

大家都知道搞大模型离不开场景、算力、算法、数据这四样东西。很多人还会加上平台和工具。我承认它们重要，但考虑到大多数企业还在从0到1的阶段，大规模化还早，所以像MaaS这类平台，暂时没必要急着建或买。

那么，除了前面说的场景，剩下的三个——算力、算法、数据，哪个才是决定性因素？

算力显然不是。当前有智算的企业确实抢了先机，但算力未来总能买到，或者大家慢慢都会有的。随着量化等算法成熟，说不定100亿参数对企业就够用了。

算法方面，机器学习时代大家差距可能很大，但到了深度学习阶段已经缩小了很多。到了大模型时代，基础大模型和开源模型更是拉平了差距。基础大模型会成为社会的基础设施，像水电煤一样。各家你方唱罢我登场，本质是在争生态位，跟大多数企业其实没啥关系。基础大模型成不了你的竞争力，你要做的，就是做测试、做选择——同一模型在不同场景的表现可能差出去十万八千里。

所以最后决定企业大模型成败的，其实就两样：语料 + 微调能力。微调的门槛会随着工具平台普及而迅速降低，这很快就会变成红海。语料就不一样了——它是企业特有的生产资料，是所有通用基础设施都提供不了的。正是这种特有的生产资料，创造了特有的生产力，也体现了企业模型独一无二的价值。

但现实是，大多数企业并没有为语料做好准备。未来会有一大批企业陷进“巧妇难为无米之炊”的困境。究其根本，数字化水平不够，数据治理能力不足，这会极大限制大模型应用的拓展和深化。

先说第一点：AIGC需要的语料，大部分是非结构化数据。但绝大多数企业对非结构化数据的管理能力非常薄弱——日志没留，文档散落，很多系统各管各的。我们团队做了多年数据治理，也仅仅是管好了结构化数据，非结构数据的记录、采集、解析，才刚刚起步。相信很多同行都会有同样的感慨：数到用时方恨少。

第二点，大量业务系统都是匆忙上线，系统自身的元数据极度匮乏，没有半点“Chat”的基础。语料准备这项工作，又繁又难。更糟糕的是，很多语料准备工作临时拉了一个草台班子来做，数据质量到处是坑。低质量的语料，很容易把微调效果搞得惨不忍睹。

我们其实处在一个大模型语料极度匮乏的时代。以前大家总觉得文档写得差不多就够了，实用主义嘛，先上线再说。现在才发现，原来这些“差不多”的东西，才是智能化的基础。

举个例子。我们想给管信系统做一个应用导航功能，但发现管信里对每个应用系统的描述信息极少。比如“商旅100”是订酒店和机票的系统，但没有足够元数据。当用户输入“订酒店”想找这个应用时，大模型根本推理不出来。为了做这个功能，我们只能逐个梳理和完善应用描述信息。工作量之大、难度之高，几乎不可能。公司应用太多了，不可能调集这么多资源来只为做一个导航功能。很多大模型应用想法很好，但落地的代价极其沉重。

第三点，语料的梳理和完善本身就是个苦活累活。非结构化数据管理至今还是个技术活，企业要是没有基本的数据治理能力和技术储备，门槛不低。当初我们做错别字检测模型时，为了准备高质量的语料，处理了上万份文档，足足花了几个月时间。效率非常低。我们似乎从未真正为语料做好准备，每次应用，数据准备阶段的代价都太大了。

李彦宏说，未来所有应用都可以用大模型重构一遍。这句话意味着，企业所有应用的数据采集模式都得重构。未来的数据治理要求，会贯穿在每个应用的构建过程里。不留存数据就不能上线——这个标准真的有可能成真。这恰好凸显了数据治理的巨大价值。

可以说，大模型时代，数据团队最重要的一个任务，就是把公司的大模型数据集供给体系建起来。这一定是所有大模型应用最重要的基础。有没有足够的语料，将成为评判要不要上马一个大模型应用的黄金标准。数据团队真的是三生有幸，每隔十年就能迎来一次建功立业的机会。

在大模型应用这件事上，想清楚

、、、——这些才是正道。它们大多时候，比攻克一个技术难题重要得多。

Be different, not better. 希望这些分享，对你有点价值。