大模型出来后，自己就一直在思考大模型在公司的应用场景，也特别希望大模型在数据治理领域有所作为，至今已有大半个年头，今天就跟大家来聊聊这个探索之旅，共分为七个阶段：
1、ChatGPT的启蒙
2、“智乎”问答的幻象
3、ChatBI能力之殇
4、完美的“智典”场景
5、智能核稿的考验
6、实践的六个总结
7、后续工作的思考
1、ChatGPT的启蒙
自己从事数据相关工作，经常碰到各种问题，ChatGPT出现后，其强大的问答能力马上成为了我工作上的助手。凡是有不懂的地方，都会先去听听GPT的解释，准确率八九不离十。
应该来讲，GPT的出现让世界变得更平了，犀利一点的说，就是GPT很大程度上打破了知识的不对称。
假如你是个普通人，想了解某个算法的原理，如在以前，你得查找各种文章，买书，找人问，然后还要自己提炼总结，了解专业技术的门槛其实挺高，现在GPT把前面的事都干了，你只要向它提问就可以了，它就是24小时在线的老师。
有人拿着领域知识去为难GPT，认为它没什么用，但GPT只要解决85%的问题就可以了，剩下的那15%，就留给自己钻研吧，况且，也不是GPT不行，而是没有相应的语料。
有了ChatGPT产品的使用经历，我认同李彦宏的“大模型值得把企业的应用全部重构一遍”的论断。与此同时，BOSS也希望大家在这一领域进行更多的思考和布局，因此我们就开启了在大模型应用上的探索之旅。
2、“智乎”问答的幻象
ChatGPT是个问答系统，任何一位用过ChatGPT的人，都会想着去打造一个企业的ChatGPT，即能基于垂直领域的知识回答问题，这样就能解决企业的大问题，比如打造一个客服系统的ChatGPT，然后代替客服人员回答用户的问题。
当然数据团队搞大模型应用，还是有些门槛，因为离业务有点远，既不管业务，也不负责建设，甚至连测试的机会都没有。
机缘巧合的是，自己除了负责数据管理，还承担着公司管信系统的建设和运营，人力、财务、供应链、综合等后端部门都是我的服务对象，这样在场景上就多了些选择，很快就找到了一个自认为合适的场景。
这几年管信在人力、财务等领域做了很多问答机器人，用户输入关键字查询就可以找到自己想要了解的公司的政策信息和菜单入口，业务部门还是非常欢迎的。
但要开发问答机器人非常麻烦：
第一、需要业务人员去整理知识图谱，要对各种功能菜单、政策文件进行梳理和分门别类，不仅耗时耗力，更新难度大，而且丢失了大量的原始信息。
第二、问答机器人只能基于关键字模糊匹配，使得问答机器人的适用场景有限，比如“五金一险”如果没有预设为关键词，问答机器人就没法回答。
我们决定用大模型重构这个问题机器人的核心引擎，让大模型把公司的所有“资料”都吃进去，然后基于大模型的语义理解能力和生成能力精准回答，这是一个典型的垂直大模型的应用场景，我们把这个新的机器人叫作“智乎”。
做“智乎”的时候，开源比较有名的是ChatGLM2基础大模型，然后我们基于CVL构建了推理引擎，框架如下所示：
但“智乎”问答测试的结果并不是很好，相对于ChatGPT4 90%以上的准确率，“智乎”的准确率只有40-60%，幻象问题频出，我们只能不停的给“智乎”打补丁，以弥补基础大模型能力的不足。
（1）把问答机器人原来的知识图谱、FAQ也纳入进来，尝试解决幻想的问题
（2）对Llama、Llama2、通义千问等各类开源大模型进行评估试用，解决基础大模型语义理解和推理能力不够的问题
（3）按照人力、财务等领域分别构建领域大模型，解决不同领域间知识库语料相互污染的问题
（4）优化向量数据库，解决分词导致的语义被截断的问题
最后的结果还是不太理想，即使在移动端的应用都开发出了原型，如下所示，但最终我们还是没敢放出这个产品，自己这关都过不了，就不要想着别人能认可了。
我们当时得出的结论就是：在垂直领域对准确性要求较高的chat敏感场景，如果开源大模型的能力没有得到质的提升，那只能用微调的方式去解决。
但微调对技术和硬件资源的要求比较高，而我们当时的确能力有限，因此，“智乎”算是失败了，但这段经历还是获得了很多收获：
（1）在采集端，把管信领域的非结构文档数据都做了统一归集，形成了向量库，进一步拓展了数据治理的边界，这是典型的“以用促治”的场景。
（2）在模型端，对各类大模型做了测试，对相关能力也有了基本的了解。
（3）在平台端，我们构建了CVL的引擎，打造了一个非常方便的训练、部署和推理环境。
（4）在管理上，打造了融合数管和管信人员的大模型团队，双方起到了优势互补的作用，后来管信团队的业务能力帮到了大忙。
3、ChatBI能力之殇
ChatGPT给了所有做大模型应用团队一个幻象，就是问答系统似乎是最容易COPY成功的。
但通过智乎，我们发现问答系统当前无法通过简单的Prompt实现的，一方面受限于开源基础大模型的能力，另一方面也跟企业的领域语料、微调能力和算力有关。对于刚起步的团队，一口啃下这些硬骨头难度很大。
我们只能在场景选择上下功夫，然后视野回到了数据领域。
公司的手机经分已经做了很多年，但现在里面的指标很，大家的使用门槛还是比较高的，我们就想着能否用自然语言提问的方式提升手机经分的使用便捷性，然后就启动了增强分析（后来叫作ChatBI）的探索，我们设想的APP产品界面如下：
假如老板问：“5G用户数多少”，手机经分APP能基于大模型的语义理解能力自动适配到合适的指标进行回答。
比如下面是测试时用的提示词模板，用于找到最匹配的指标：
“现在你是一个搜索引擎，你的任务是从指定的指标名称全集中，根据用户输入的指标，找出全集内相似度最高的20个指标，并根据相似度从高到低将这20个指标排序。不用输出思考过程，只需要结果。以下是指标名称全集：{} 用户输入的问题是：{}”
看似简单的场景实际上要实现并不容易，最大的挑战就是领域语料的问题，除了一些通用的财务指标，公司的90%以上的指标几乎都带有明确的领域属性。
比如移动新入网用户数、移动云盘新增用户数、家庭组网发展用户数、咪咕爱看用户数等等，特别是很多指标公司还有默认的叫法，比如讲用户数的时候，特指通信用户数。这些领域知识不为基础大模型所了解，只能通过微调方式解决。
但我们手头并没有多少现成的领域语料，只能靠人工去准备和标注，比如需要把所有指标用业务化的语言说明清楚，同时把可能得同义词、简写都列出来，这需要耗费大量的精力，曾经也想着利用chatgpt4帮助生成标注数据，但标注数据的质量差强人意，最后微调的效果也不好。
如果说智乎的受挫归因于基础大模型的不给力，那么ChatBI的失败则主要受限于高质量的语料和基本的微调能力，ChatBI让我们意识到简单的CVL模式是支撑不了领域大模型的进一步要求的。
4、完美的“智典”场景
可以看到，像我们这种初探大模型的团队，起步的时候往往无技术无数据无算力，如果说竟然能搞成功，那唯一的可能就是：选对了场景。
我们运气不错，在数据治理领域找到了一个几乎完美的场景，其有一定实用价值，准确度要求不高，关键领域语料还有现成的。这个场景就是利用大模型的生成能力实现数据目录元数据的补充，我们据此还打造了一个产品，即“智典”，其有三个优势：
第一、打破领域知识壁垒
我们的团队对B域数据还是比较清楚的，但对于O域（网络域）的专业非常陌生，而O域又是一个标准化程度非常高的领域，诸如接入网，传输网、核心网等概念全世界通用，大模型在这种通用性知识领域的内容生成能力非常强，可以完美的弥补团队在专业知识方面的缺陷，我认为这是"智典"成功的前提。
第二、用通俗的语言诠释
即使我们对B域非常熟悉，但大家的文字表达能力参差不齐，很难用完整，准确且通俗易懂到的文字把掌握的专业知识转化成数据目录的元数据信息，而这正是大模型所擅长的，你只要给它足够的上下文信息，让它写个通俗易懂的摘要绰绰有余。
第三、数据目录的自动化
前期我们在数据目录的运营上花费了大量的精力，每次扫描到新的数据资源，不仅要进行元数据信息的补录，还需要业务人员的和管理人员的审核，整个确认流程非常长，人工的大量介入让数据一键入湖的目标迟迟无法实现。
而我的理想是整个入湖过程全部自动化，零人工介入，并且还要确保数据目录的质量。如果能把基于大模型的元数据生成能力做成API，并且嵌入到这个流程中，就有可能达成目标。
同时，对于数据目录元数据维护这种价值呈现比较间接的工作，性价比一定要优先考量，如果API代价太大，那也无法做。
大模型正是我梦寐以求的解决方案，而且有了前面大模型的经验，“智典”的建设比较顺利。
我们将通义千问模型作为基底大模型，基于存量的数据目录元数据信息构建了一个拥有6000余条规范化问答结构（）的指令数据集，如下所示：
我们采用LORA进行了微调，为验证“智典”生成的字典信息准确性，随机选择各领域的430张表，并邀请业务专家进行人工审核。经验证，其准确率高达97%，在这个场景，大模型生成的内容质量基本可以达标。下面是一个生成示例：
有了大模型的加持，我们的数据目录元数据信息的质量上了一个档次，O域专业人员的评估是并不低于他们手工的维护水平。我们也降本了，完全裁撤了ETL配置团队，大家能把精力更多的投入到业务中去。效率也提升了，数据资源纳管的周期已经缩短至小时级。
“智典”算是我们第一个比较成功的大模型应用，当然这次成功是比较偶然的，更多是企业实际+场景选择的胜利。
比如我们的企业数据目录已经在生产中发挥着重要作用，做元数据补录的这个事情价值就比较大，而有些企业可能连在线数据目录都没有，“智典”这种大模型应用场景就显得毫无意义。
在啥都一穷二白的前提下，如果想搞大模型，那选对场景一定是第一位的，很多场景价值不大但对大模型要求极高，而有些场景是反过来的，这需要我们深入到业务中寻找合适的机会。
5、智能核稿的考验
但“智典”毕竟只是数据团队自己提升效率的一个场景，好坏一定程度是自己说了算。我们的大模型能否直接去服务业务部门，得到用户的真实反馈，才能更好的衡量大模型的应用价值，这对团队的能力也是真正的考验。
我们碰到的第一个业务部门驱动的大模型应用是智能核稿。智能核稿是办公领域AI应用的一个典型场景，其可以实现格式、标点、错别字、语义、专业用语的自动稽核和快速纠错，在公文起草的时候特别有用。
我们以为错别字纠正对大模型是小菜一碟，但测试发现基础大模型对于领域的错别字识别准确率不到40%，比如“力量大厦”是领域的专有名词，不能写成“力量大楼”，但基础大模型识别不出来，这种情况很多。
我们选择了baichuan大模型进行微调，投入大量时间和精力去搜集历史公文和网上公开的错别字集，通过音似、形似等方法进行自动标注，最终形成了上千万的训练语料数据，通过lora微调，最终将错别字识别准确率提升到85%左右，这是一个巨大的飞跃。
由于智能核稿要上生产系统，需要考虑大量的工程问题，比如响应速度（小于7秒），并发能力（同时20人使用）等等，受限于有限的GPU硬件资源，我们后来通过拆分公文、引入llm加速框架来解决性能问题。
智能核稿将我们的大模型工作从研究态加速推向了生产态，在经历了业务部门严苛的测试，顶住了准确率的压力后，现在的智能核稿终于可以上线了，虽然课题不大，但对我们的意义很大。即使智能核稿还面临性能、泛化、运营等系列问题。
我们的结论是：在当前开源基础大模型能力有限的情况下，掌握微调技术是必须的，而数据+算力对领域大模型的成功起到了决定作用。在处理领域语料的时候，数据团队的数据治理能力又是一个关键，很多团队的大模型准确率上不去，是受限于数据管理水平的。
6、实践的六个总结
大家可以看到，大模型的应用面很容易铺开，因为到处都是机会。这个时候拉通团队信息、总结经验很重要。因此我们开了数次研讨会，下面是我当前的六个观点：
第一、大模型已经从概念普及迅速过渡到落地阶段，画画蓝图啥的已经价值不大，因为理论上，大模型几乎可以把企业内的所有应用重构一遍，战略方向不是问题。
第二、企业在领域大模型有很多的机会，但开源基础大模型的能力极大限制了企业的应用场景，我们当前正处于“眼高手低”的阶段，因此选择到合适的场景对于企业搞大模型是第一位的，比如“智乎”的失败和“智典”的成功都是由场景决定的。
第三、在选对场景情况下，要用产品思维去构建大模型应用，要想清楚我最终是要解决业务问题，而不是证明技术有多成功。因此在基础大模型不给力的情况下不要头铁，可以采用各种补偿手段，最后如果仍然不行，那就果断换一个。
第四、微调正成为领域大模型成功的关键，但微调成功的关键除了各种微调方法，比如以LORA为代表的高效微调，更为关键的还是数据能力，即训练的语料是否高质量，这又跟企业的数据治理能力息息相关。
搞领域语料是个苦活累活，但的确是朴实无华而有价值的工作。某个领域有没有足够的、现成的语料是判断领域大模型能否成功的关键。从这个角度看，大模型数据集的管理是未来数据治理领域的一个重要方向。
第五、大模型对GPU的特殊要求导致很多企业无法靠盘活存量CPU资源进行大模型的有效探索，在未证明大模型的价值之前很少有团队能马上获得公司的GPU投资，鸡生蛋和蛋生机是个问题，因此最大程度降低对GPU资源的消耗成为了大模型工程上的一个挑战（比如QLoRA的微调和tensorrt-llm推理加速框架），这在以前是很少碰到的情况。
第六、我以前只知道用CVL，根本不知道有那么多高效微调的方法，可见在这个特殊时期懂点大模型训练的人才是多么稀缺，但我相信马上这些技术会普及，最终企业还是要靠场景+数据取胜，因此企业要提前培养和储备自己的大模型人才，不要以为外来的和尚能一直念经。
7、后续工作的思考
关于后续工作我有三点思考。
第一，产品思维
很多公司策划了大模型应用的美好蓝图，但要实现其中的哪怕最小的那个场景也要耗费公司的大量资源。真正能用的大模型应用不是规划出来的，而是自己一步步趟出来的，没点产品思维成功不了，具体干活团队要忍住不停show的冲动。
现在有个很好的词叫做“守正创新“，意思是先把已经做的运营好，打好基础，然后再去创新，别好高骛远。
我自己就犯了同样的毛病，比如刚搞了“智典”上线，就想着去做另外的亮点大模型应用，分散了很多精力。但事实上，“智典”远未完善，比如“智典”的领域知识的推理能力还比较弱，虽然我们已经想到了一些解决办法，但并没有及时去优化，产品这样下去一定会泯然众人矣。
第二、业务为王
“智乎”失败了，我一直想着挽救方法，偶然有一次跟管信的主管聊天，他说其实不用做的这么重，现在ERP的功能已经成百上千，有大量的轻量级的大模型应用场景，比如做好菜单的智能导航就能有效降低员工的查询、办理的门槛，其实这个跟OpenAI提出的GPTs有异曲同工之妙，想像空间很大。
主管的回答让我豁然开朗，让我意识到业务理解实在是太重要了，如果当初能多听听相关人员的意见，给出更多的ABCD选项，也许会少走些弯路。
跟多年前搞大数据碰到的情况一样，现在企业搞大模型，技术和业务的隔离还是比较大的，比如对大模型感兴趣的往往是IT或数据团队，但其只有技术没有场景，而有场景的业务人员对大模型又不太清楚，这个GAP非常大，因此理顺生产关系很重要，未来企业设立大模型的专门组织是必然的。
第三、诗与远方
ChatBI失败了，但自助取数一直是我的梦想，如果有时间的话，我一定会好好去研究ChatSQL，基于思维链+基础大模型的能力构建一个ChatSQL，从而解决业务语言到数据语言的转化问题，让SQLBOY这个岗位消失，在ChatGPT4上，我几乎看到了希望。
下面是ChatGPT4针对”分地区统计昨天购物金额的同比增长情况“这个统计需求给出的SQL。
希望未来的业务人员只要动动嘴，就能获得所需的数据，取数人员则能获得解放，有机会去从事更有价值的工作，这应是未来BI的方向。
当然还远不止这些，大模型带给我们技术创新和赋能业务的机会前所未有，从基础大模型、Transformer、向量数据库、微调技术、ChatCatalog、ChatBI、ChatSQL、ChatDev、ChatDataOps再到ChatAnything ，很庆幸我们能有机会参与其中，正如当年的大数据一样。
中国第二批大模型备案获批4336
如何最简单、通俗地理解GPT的Transformer架构？1950
如何打造一个拖垮公司的大模型？3763
模型、算法、模型结构、数据模型、训练到底是不是一回事？看这里就对了！2942
点击左下角“阅读原文”查看更多精彩文章，公众号推送规则变了，如果您想及时收到推送，麻烦右下角点个在看或者把本号置顶！
186
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
