业务为王，浙江移动大模型应用的成功经验分享

大模型热潮起来之后，这大半年时间一直在琢磨它在公司里到底能怎么落地，尤其盼着能在数据治理这块搞出点名堂来。到今天，也算走了一趟完整的探索历程，下面就把这七个阶段掰开说说。

做数据相关的工作，总是会碰到各种各样的问题。ChatGPT一出来，它那强悍的问答能力马上就变成了身边最趁手的“小助手”。但凡有拿不准的地方，都会先跑去找它问问，准确率能有个八九成。说实话，GPT的出现让整个世界的信息差变小了——说得直白点，它很大程度上打破了知识的不对称。以前一个普通人想了解某个算法的原理，得翻各种文章、买书、找人问，还得自己提炼总结，门槛不低。现在倒好，GPT把前面的事全包了，用户只需要向它提问，它就是一个24小时在线、不会累的老师。也总有人拿领域知识去为难GPT，觉得它没啥用。但冷静想想，能解决85%的问题就已经很好了，剩下的15%留给人类自己去钻研，这有什么问题？而且很多时候，不是GPT不行，而是没有对应的语料去训练它。

经历过ChatGPT这种产品的洗礼，对李彦宏那句“大模型值得把企业应用全部重构一遍”是真心认同。与此同时，老板也希望大家在这个方向上多思考、多布局。于是，团队便一头扎进了大模型应用的探索之旅。

ChatGPT是个问答系统，但凡用过的人，谁不想给自己企业也搞一个？也就是基于垂直领域的知识去回答问题，企业的大问题不就解决了吗？比如，打造一个客服系统版的ChatGPT，直接代替人工客服去回答问题。但对数据团队来说，搞大模型应用还是有些门槛的——离业务有点远，既不管业务，也不负责系统建设，甚至连测试的机会都很难捞到。

机缘巧合的是，除了管理数据，还同时负责公司管信系统的建设和运营，人力、财务、供应链、综合这些后端部门都是服务对象。这样一来，在场景选择上就多了些余地，很快就找到了一个自以为合适的场景。这些年，管信在人力、财务等领域做了不少问答机器人，用户输入关键字就能查到公司政策信息和菜单入口，业务部门还是很欢迎的。但开发一个问答机器人确实太麻烦了：第一，需要业务人员去手动整理知识图谱，对各种功能菜单、政策文件梳理分类，耗时耗力不说，更新也难，还丢失了大量原始信息；第二，机器人只能基于关键字模糊匹配，场景很有限。比如“五金一险”，如果没提前设成关键词，它就没法回答。

于是，团队决定用大模型重构这个问答机器人的核心引擎——让大模型把公司所有“资料”都吃进去，再借助大模型的语义理解和生成能力来精准回答。这是个典型的垂直大模型应用场景，团队给这个新机器人取名叫“智乎”。做“智乎”那会儿，开源比较有名的是ChatGLM2基础大模型，团队基于CVL搭建了推理引擎，框架如下图所示：

但“智乎”问答测试的结果并不理想。相比ChatGPT4超过90%的准确率，“智乎”只有40%-60%，**幻象问题层出不穷**。团队只好不停给它“打补丁”，弥补基础大模型能力的不足：

• 把问答机器人原来的知识图谱、FAQ也纳入进来，尝试缓解幻象问题；
• 对Llama、Llama2、通义千问等各类开源大模型进行评估试用，看能不能找到语义理解能力更强的模型；
• 按人力、财务等不同领域分别构建领域大模型，避免领域间语料相互污染；
• 优化向量数据库，解决分词导致语义被截断的问题。

折腾了一圈，结果还是不太行。就算移动端应用的原型都开发出来了（见下图），最终还是没敢放出去——自己这关都过不了，就别指望别人能认可了。

当时得出的结论是：**在垂直领域、对准确性要求很高的聊天敏感场景里，如果开源大模型的能力没有质的提升，那只能靠微调来解决。但微调对技术和硬件资源的要求都很高，团队当时确实没那个能力。** 所以，“智乎”算是折了。不过这段路也不是白走的，收获也不少：

ChatGPT给所有做大模型应用的团队制造了一个幻象——问答系统似乎是最容易“复制粘贴”成功的。但经过“智乎”这轮尝试，大家很清楚：问答系统靠简单的Prompt根本搞不定。一方面是开源基础大模型能力有限，另一方面又跟企业的领域语料、微调能力和算力紧密相关。对刚起步的团队来说，想一口气啃下这些硬骨头，难度太大。只能换个思路，在场景选择上花更多心思，于是把目光转回数据领域。

公司的手机经营分析应用（手机经分）已经用了好多年，使用门槛一直不低。团队想着，如果能用自然语言提问的方式来提升它的便捷性，那就好了。于是启动了增强分析的探索，后来大家叫它ChatBI。设想中的APP产品界面大致如下：

假如老板问一句“5G用户数多少”，手机经分APP能基于大模型的语义理解能力，自动匹配到最合适的指标来回答。下面的提示词模板，就是当时用来帮大模型找最匹配指标的：

“现在你是一个搜索引擎，你的任务是从指定的指标名称全集中，根据用户输入的指标，找出全集内相似度最高的20个指标，并根据相似度从高到低将这20个指标排序。不用输出思考过程，只需要结果。以下是指标名称全集：{} 用户输入的问题是：{}”

看似简单的场景，真正实现起来并不容易。**最大的挑战还是领域语料问题。** 除了一些通用的财务指标，公司90%以上的指标都有明确的领域属性。比如“移动新入网用户数”“移动云盘新增用户数”“家庭组网发展用户数”“咪咕爱看用户数”等等，很多指标甚至还有公司内部的默认叫法。比如光说“用户数”，特指的就是通信用户数。这些领域知识，基础大模型根本不了解，只能靠微调来解决。但手头没有现成的领域语料，只能靠人工准备和标注。比如要把所有指标用业务化的语言说清楚，同时列出可能的同义词、简写……工作量巨大。也想过用ChatGPT4来生成标注数据，但质量差强人意，最后微调出来效果也不好。

像团队这种刚起步探索大模型的，没钱、没技术、没算力，如果还能搞成，唯一的可能性就是：**选对了场景**。运气还算不错，在数据治理领域找到了一个近乎完美的场景——有一定实用价值、对准确度要求不高，更关键的是，领域语料居然有现成的。这个场景就是利用大模型的生成能力，对数据目录的元数据进行补充。团队据此打造了一个产品，叫“智典”，它的优势有三：

团队对B域数据还算清楚，但对O域（网络域）完全是“门外汉”。可O域恰恰是个标准化程度极高的领域——接入网、传输网、核心网这些概念都是全球通用的。大模型在通用知识领域的内容生成能力非常强，完全可以弥补团队在专业知识上的短板。**这是“智典”能成的前提。**

就算对B域很熟，团队里也不是人人都有出色的文字表达能力，很难用完整、准确又通俗的语言把专业知识转化成数据目录的元数据信息。而这正好是大模型擅长的——给它足够的上下文，让它写个通俗易懂的摘要，绰绰有余。

前期在数据目录运营上花费了大量精力。每次扫描到新的数据资源，不仅要补录元数据信息，还得业务人员和管理人员审核，整个流程很长，人工的大量介入让“数据一键入湖”这个目标迟迟实现不了。理想状态是：整个入湖过程完全自动化、零人工介入，同时还要保证数据目录质量。如果能把基于大模型的元数据生成能力做成API、嵌入流程里，就有可能实现。而且，对元数据维护这种价值间接的工作，性价比一定要优先考虑——API代价太大也不行。

大模型正好是梦寐以求的解决方案。有了前面踩坑的经验，“智典”的建设反而比较顺利。团队选用通义千问作为基底大模型，基于存量的数据目录元数据，构建了一个6000多条的规范化问答数据集，采用LORA进行微调。为了验证“智典”生成字典信息的准确性，还在各领域随机选了430张表，请业务专家人工审核。结果是：**准确率高达97%。** 在这个场景下，大模型生成的内容质量基本达标了。下面是个生成的示例：

有了大模型加持，数据目录元数据信息的质量明显提升。O域的专业人员评价是：不低于他们手工维护的水平。成本也降了——ETL配置团队直接裁撤了，大家能把精力投入到更有价值的业务中。效率也提高了，数据资源纳管的周期缩短到了小时级。

“智典”算得上团队第一个比较成功的大模型应用。坦率地说，这次成功挺偶然的，更多是**企业实际 + 场景选择**的胜利。比如公司本身就有一个在线上发挥重要作用的数据目录，做元数据补录才显得价值大。如果有的企业连在线数据目录都没有，那“智典”这种应用再炫也毫无意义。

然而，“智典”说到底只是数据团队自己提升效率的一个场景，好坏自己说了算。**大模型能不能真正去服务业务部门，收到用户最真实的反馈，才是衡量大模型应用价值的真正标尺，也是对团队能力的真正考验。** 团队碰到的第一个由业务部门驱动的大模型应用，就是智能核稿。

智能核稿是办公领域AI应用的典型场景，可以自动稽核格式、标点、错别字、语义、专业用语，在公文起草环节特别有用。原本以为错别字纠正对大模型来说是小菜一碟，但一测试才发现，基础大模型对领域错别字的识别准确率**不到40%**。比如“力量大厦”是领域专有名词，不能写成“力量大楼”，但基础大模型根本识别不出来。类似的情况比比皆是。

团队选择了baichuan大模型进行微调，投入大量时间和精力，去搜集历史公文和网上公开的错别字集，用音似、形似等方法自动标注，最终形成了上千万的训练语料数据。通过LoRA微调，**把错别字识别准确率提升到85%左右——这是巨大的飞跃。** 因为智能核稿要上生产系统，还得考虑大量工程问题：响应速度要小于7秒，并发要能支撑20人同时使用……在有限的GPU硬件资源下，团队通过拆分公文、引入LLM加速框架来搞定性能问题。

智能核稿把大模型工作从研究态推向了生产态。经历业务部门严苛的测试、扛住准确率压力后，现在的智能核稿终于可以上线了。课题虽然不大，但对团队意义非凡。当然，它还面临性能、泛化、运营等一系列问题。

可以看到，大模型的应用面其实很好铺开——因为到处都是机会。这时候拉通团队信息、总结经验就特别重要。团队开了好几次研讨会，下面是当前阶段总结出的六个观点：

比如“智乎”的失败和“智典”的成功，都是由场景决定的。

基础大模型不给力的时候别头铁，可以用各种补偿手段；如果还是不行，果断换场景。

搞领域语料是个苦活累活，但确实是朴实无华而价值巨大的工作。某个领域有没有足够的、现成的语料，是判断领域大模型能否成功的关键。从这个角度看，大模型数据集管理是未来数据治理的一个重要方向。

在没有证明大模型价值之前，很少有团队能马上拿到公司的GPU投资——鸡和蛋的问题一直存在。因此，最大程度降低对GPU资源的消耗，成为大模型工程上的一个新挑战（比如QLoRA微调、tensorrt-llm推理加速框架）。这在以前是很少碰到的情况。

可见在这个特殊时期，懂点大模型训练的人才是多么稀缺。不过相信这些技术很快就会普及，最终企业还是要靠场景+数据取胜。所以企业要提前培养和储备自己的大模型人才，不能指望外来的和尚能一直念经。

关于后续工作，有三点思考。

很多公司策划了大模型应用的美好蓝图，但要实现里面哪怕最小的一个场景，也要耗费大量资源。真正能用的大模型应用不是规划出来的，而是自己一步步“趟”出来的，没点产品思维成不了。具体干活的团队要忍得住不停“show”的冲动。现在有个很好的词叫“守正创新”——先把已经做的东西运营好、打好基础，再去创新，别好高骛远。坦白说，自己也犯过同样的毛病：“智典”刚上线就想着去做另一个亮点大模型应用，结果分散了很多精力。但事实上“智典”远未完善，比如领域知识的推理能力还比较弱。虽然已经想到了一些解决办法，但没及时去优化，再这样下去，产品一定会泯然众人矣。

“智乎”失败后，一直在想怎么挽救。偶然一次跟管信的主管聊天，他说其实不用做那么重——现在ERP有成百上千的功能，大量轻量级的大模型应用场景等着挖掘，比如做好菜单的智能导航，就能有效降低员工查询、办理的门槛。这跟OpenAI提出的GPTs有异曲同工之妙，想象空间很大。这句话让人豁然开朗，意识到**业务理解实在太重要了。** 如果一开始能多听听相关人员的意见，给出ABCD选项，也许能少走些弯路。跟多年前搞大数据时的情况类似，现在企业搞大模型，技术和业务之间的隔阂仍然很大。比如对大模型感兴趣的往往是IT或数据团队，他们有技术但没有场景；有场景的业务人员对大模型又不太了解，这个GAP不小。因此，理顺生产关系很重要，未来企业设立专门的大模型组织势在必行。

ChatBI失败了，但“自助取数”一直是个梦想。如果有时间，肯定会好好研究ChatSQL，基于思维链和基础大模型的能力去构建它，解决业务语言到数据语言的转化问题，让“SQL Boy”这个岗位消失。在ChatGPT4上，几乎看到了希望。下面是ChatGPT4针对“分地区统计昨天购物金额的同比增长情况”这个统计需求给出的SQL：

希望未来业务人员只要动动嘴，就能获得所需数据，取数人员能获得解放，去从事更有价值的工作。这才是未来BI该有的样子。当然，还远不止这些。**大模型带来的技术创新和赋能业务的机会前所未有——从基础大模型、Transformer、向量数据库、微调技术，到ChatCatalog、ChatBI、ChatSQL、ChatDev、ChatDataOps，再到ChatAnything……** 很庆幸有机会参与其中，就像当年的大数据一样。