剖解企业AI大模型建设路径，提升未来核心竞争力

原创爱分析ifenxi 2024-09-12 11:59 920浏览 0评论 0点赞

EPC专家实战拆解：电机能效优化技巧 4.23杭州！半导体产业链测试全链路解密

AI大模型时代的到来，让很多企业都感受到了技术发展的魅力，但由于当前大环境，越来越多的企业对于IT的投入会更加谨慎，而根据过往经验，企业落地AI大模型确实会遇到一些问题，本文主要从大模型的建设路径与2个实际案例进行分析。

分享嘉宾｜李喆 爱分析合伙人兼首席分析师

内容已做精简，如需获取专家完整版视频实录和课件，请扫码领取。

基于过去一年的交流经验，我们总结出目前企业对于 AI 大模型落地过程中的几个重点关注问题。

1、当前很多应用场景多处于 POC 验证阶段，因为其实际效果和最终收益的不确定性，所以成功落地案例尤为重要且备受关注。

2、落地和建设路径方面有几个问题较受关注，第一，是模型本身，研发能力不足的企业用户，是否自身要去做模型训练？现阶段是否一定要有企业内部专属大模型？第二，如果做训练和微调，现有的数据量是否足够？第三，算力是否需要投入？如果增加算力投入，整体项目预算量级会上升一个级别。第四，如何量化最终收益？第五，是项目可行性问题，大多数企业用户在过去一年都已经做过大模型尝试，准确性、幻觉问题一直存在，如何解决？

3、合规，模型本身是否自主可控？数据是否安全合规？信创要求。

4、选型，现在市面上第一类大模型由互联网大厂，像阿里、腾讯、华为等大厂研发的相关产品。那第二类是专注单点应用的小厂，比如专注于 Agent 平台和 Agent 应用开发。第三，现有垂直供应商。所有企业用户都会关注选型问题，虽然大模型大厂本身技术能力很强，但不一定特别理解企业自身业务场景，而现有的垂直厂商本身技术能力会受到多方质疑，所以选型是重点关注的问题。

建设路径的首要问题是模型本身落地问题，到底需不需要去做模型的训练和微调？

现在两种主要的落地方式，第一种是直接调用通用大模型能力，在上面加些提示词、思维链、外挂知识图谱、内部知识库，用 RAG 的方式实现。

应用层分成两类，1、直接嵌入传统 SaaS 应用或软件中，做个机器人实现，2、应用给到服务团队，比如内容生成、素材生成是非常大的应用场景，面向于营销端，靠服务团队解决，用Agent工具可以降低服务团队的成本，提升效率。用该方式解决幻觉，或者说最后一公里的兜底问题。

第二种落地方式是直接做微调训练或全参数预训练。有些企业选择精调，灌输行业或企业自己的数据集，给到技术大模型，精调后形成行业大模型或垂直大模型，基于之上提供服务，这两种是现在较常见的落地方式。

现阶段更建议选择直接调用大模型，这里有几点原因。第一，整个基础模型的迭代速度非常快，开源模型的能力在持续提升。对于很多场景，基于基础大模型做精调不够经济，花了很多成本和精力后，由于基础模型能力的提升，反而不需要太多精调，从模型本身的迭代速度来看，直接调用的效果与性价比更好。

第二，进行精调或微调的过程中，模型的泛化能力在下降。精调只是把模型在单点任务或特定任务场景能力做提升，但在其他场景的任务能力在下降，这意味着在场景探索和尝试阶段，做精调反而会损失很多能力，探索的可能性效果相对不佳。除非任务场景相对明确，这时通过大模型解决的问题才能够被定义得很清楚，而且一定时间内确定性不会转变，做精调才有价值。

对于大部分企业用户来说，目前处于基于基础模型的迭代和场景探索阶段，我们建议直接调用模型，也就是从模型本身的接入。

RAG 对企业而言是非常好的方式，现在企业面临的大部分场景是基于知识问答向上延伸的，比如设备维修、项目管理等案例，拆解成底层能力，本质上都会用到知识库检索。所以我们认为，RAG 是当前重要的落地实现手段。

大模型准确性很大程度上依赖于知识库，其影响远远大于微调。其中企业专有的知识积累非常关键。但企业具体需要积累哪些知识？因为企业原有的积累知识，很多时候并不能完全满足用户实业需求。

且现在RAG会做非常多工程化工作。比如设置拒答逻辑，让大语言模回答问题之后，完全只从知识库里检索，可以有效减少幻觉现象。包括合规、敏感词现象，都是工程化里较好实现的。

案例一：设备维修场景

简述下案例情况，当维修人员看到了些故障现象，需要根据现象诊断背后原因，同时基于原因给出维修方案和建议，定位更像是设备维修助手，辅助于工程师的场景。

该场景的技术架构底层用了模型与知识库，将知识库变成知识图谱，前端是问答页面，这是整个技术架构。

在实际落地中，案例是比较关键且当前阶段相对缺乏的。在实际跟客户交流的过程中，大家都具有基本的维修标准点检基准书。日常维修时，有一定制造规模的企业都具备工单数据，比如故障记录、巡检日检表等基本信息，但案例方面较为欠缺，案例的构成包括基于故障现象背后的原因及解决方案、维修结果。

大模型在调用知识库时最希望能出现这种案例，但目前大多企业的案例积累相较匮乏，这是接下来要重点积累的，在未来也会成为核心竞争力。

对于知识密集型的场景，资深人员和一般工程师的差别在于资深人员有一套自己的维修方法论，虽然不一定能将其精准表达，但关于维修的内部方法是烂熟于心的。老师傅见到问题多，对应的解决方案见得也多。这部分案例沉淀下来之后，对于设备工程师来说，也就具备了资深工程师的部分能力。

这部分案例对于企业用户非常关键，要持续积累，对于企业用户的长远发展，底层模型的价格在持续降低。案例本身会作为企业积累的专业知识库和内容，是企业未来落地时的核心竞争力，虽然当前阶段可直接调用大模型，但未来大模型技术相对成熟之后，企业开始做训练和微调时，这些案例非常关键。

实践当中大模型可以做案例的积累和反馈，大多企业用户常用的模型基本具备简单的点、采功能，本质上是做案例的反馈，模型可记录好的案例，比如针对某现象的无效维修方案，哪些现象会导致无效结果，反面案例的积累会持续更新底层设备的知识库和知识图谱，模型能力会越用越强。

大语言模型对于传统 NLP 或知识图谱而言，大模型处理非结构化数据的能力更强，可自动化实现案例的处理和沉淀。GRAPH RAG 架构最近的热度很高，该架构本质上是把知识图谱和知识库分开的形式，如果未来能够联动到一起，真正实现自动化处理知识库，形成知识图谱、持续迭代。

目前，企业用户都较关注准确性的问题，大模型与过传统 NLP 有很大的区别，大模型具有有效的反问机制。企业用户基于知识图谱的检索的过程中会遇到多个故障，其中能检测到具体故障的准确率，如果用传统方式，只能以概率最大地去回答结果，结果准确率无法保证。这时如果有反问机制，能够基于底层知识图谱之外确认故障的结果，反问机制是对比传统 NLP 知识图谱的优势。在设备、问数场景，好的方案和案例都能帮助我们解决问题。

案例二：项目助理场景

很多公司都上线项目管理系统，是为了更好地管控项目，保证管理人员日了解项目进度，项目经理可按照项目 SOP 执行，管控流程和项目风险。但实际落地的过程中，对于一线项目经理，可能不愿意填写系统，因为系统的日常工作是填写大量、繁琐的表单，包括定期填写周报、日报文件。但从公司管控角度来说，这又是必要的工作。每次项目经理在结项前，因为公司的要求需要一股脑将信息填进去，所以项目管理系统基本失去了实际价值。

因为大模型擅长处理非结构化数据，客户落地项目经理为了进行交流和沟通，一类通过大量邮件交互，另一类是通过钉钉、飞书群工具。只需要助理快速处理邮件和钉钉群中的信息。一方面自动化将更关注的信息形成项目管理系统需填写的表单和文件，降低重复性劳动。另一方面，其中包含大量信息，信息的查找并不容易，可通过项目助理的交互，定期了解文档、项目的进度与风险点等信息。

对于项目经理来说，能够帮助解答问答、降低劳动工作量、提升效率。从管理人员角度，真实性、时效性比原来有所提升。相对真实地反馈项目进度，数据对于管理人员来说是非常关键的，而系统里会存储时效性强的真实数据。

项目助理背后会挂知识库，可以把项目经理的经验沉淀下，经验本身可以复用到其他项目。同时项目管理系统中的数据是真实的，可以做项目端的洞察，这些都具有价值，所以大模型的落地案例与现有数字化系统是很好的补充。

项目助理类或助理类的 Agent 应用，第一出发点还是认为未来会作为入口，替换原有的数字化系统。但在落地时，我们认为其可行性不高，因为对于业务新人来说，熟悉新系统难度较大，所以当前阶段更好的方式是增强现有系统的能力，真正让一线人员便捷使用数字化系统或过往信息化管理系统，提升使用体验，这意味着可以存储更多真实数据，更真实地反馈实际情况，使系统未来的价值度更高。

大模型擅长非计划数据处理，不擅长做数值计算，所以围绕着邮件、 IM 信息的处理是大语言模型擅长的。案例中体现的更多是对邮件内容的处理，包括加入自动化 RPA 工具，做自动转发，以及对于风险情况自动打标。