然而，数据团队做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的平台，当前无需急于自建或采购。

那么，除场景外，剩余三个要素——算力、算法、数据——哪一个才是决定性因素？

算力显然不是决定因素。当前拥有智能算力的企业固然抢占了先机，但算力未来可随时采购，或逐渐普及。随着量化等算法逐步成熟，或许百亿参数级模型对企业便已够用。

在算法层面，机器学习时代企业间差距可能很大，但进入深度学习阶段后差距已大幅缩小。进入大模型时代，基础大模型与开源模型进一步拉平了差距。基础大模型将演变为社会基础设施，如同水电煤一般。各家轮番登场，本质是在争夺生态位，与大多数企业并无直接关联。基础大模型无法构成你的核心竞争力，你需要做的，便是测试与选择——同一模型在不同场景下的表现可能天差地别。

因此最终决定企业大模型成败的因素，实为两样：语料与微调能力。微调门槛将随工具平台普及而迅速降低，这一领域很快将沦为红海。语料则截然不同——它是企业专属的生产资料，是所有通用基础设施无法提供的。正是这种专属的生产资料，创造了独特的生产力，也彰显了企业模型的独特价值。

然而现实是，多数企业尚未为语料做好储备。未来将有一大批企业陷入“巧妇难为无米之炊”的困境。究其根源，数字化水平不足，数据治理能力欠缺，这将严重制约大模型应用的拓展与深化。

首先第一点：AIGC所需的语料，大部分为非结构化数据。然而绝大多数企业对非结构化数据的管理能力极为薄弱——日志未留存，文档分散各处，众多系统各自为政。我们团队从事多年数据治理，也只是管好了结构化数据，非结构化数据的记录、采集与解析才刚刚起步。相信许多同行都有同感：数到用时方恨少。

其次第二点：大量业务系统仓促上线，系统自身的元数据严重缺失，毫无“Chat”基础。语料准备工作繁重且艰难。更糟的是，许多语料准备工作临时拼凑草台班子承担，数据质量处处是坑。低质量语料，极易导致微调效果惨不忍睹。

我们实际上处于一个大模型语料极度匮乏的时代。过去人们普遍认为文档写得差不多即可，奉行实用主义，先上线了事。如今才发觉，原来这些“差不多”的文档，才是智能化的基石。

举例来说，我们计划为管信系统开发应用导航功能，但发现管信系统中各应用系统的描述信息极少。例如“商旅100”是预订酒店与机票的系统，但缺乏足够元数据。当用户输入“订酒店”意图查找该应用时，大模型根本无法推理。为实现此功能，我们只能逐一梳理并完善应用描述信息。工作量之大、难度之高，几乎难以实现。公司应用众多，无法调集如此多资源仅为了一个导航功能。许多大模型应用创意虽好，但落地代价极为沉重。

第三，语料的梳理与完善本身就是一项艰苦任务。非结构化数据管理至今仍是一个技术难题，企业若缺乏基本的数据治理能力与技术储备，门槛相当高。此前我们构建错别字检测模型时，为准备高质量语料，处理了上万份文档，耗时数月。效率极低。我们似乎始终未真正为语料做好准备，每次应用，数据准备阶段的成本都过于高昂。

李彦宏曾提到，未来所有应用都可用大模型重新构建。这句话意味着，企业所有应用的数据采集模式都需要重新设计。未来的数据治理标准，将贯穿于每个应用的构建过程。不留存数据便不能上线——这一标准真有可能成为现实。这恰恰凸显了数据治理的重大价值。

可以断言，在大模型时代，数据团队最为关键的任务，便是构建公司的大模型数据集供给体系。这无疑是所有大模型应用最重要的根基。是否具备充足的语料，将成为评估是否启动大模型应用的黄金标准。数据团队着实三生有幸，每隔十年便能迎来一次建功立业之机。

在大模型应用这一课题上，理清为什么做、做什么、由谁来做、生产资料从哪来——这些方为正道。它们多数时候，比攻克一项技术难题重要得多。

Be different, not better. 希望这些分享能为你带来一些价值。