报告编委 报告指导人张扬 爱分析 联合创始人&首席分析师 报告执笔人李进宝 爱分析 高级分析师 外部专家(按姓氏拼音排序)林庆治 飞算科技 首席数据官 吕鑫 滴普科技 大模型产品总监 张皎 拓尔思 金融和产业大脑产品中心运营总监 特别鸣谢(按拼音排序) 目录 1. 报告综述 " 2. 市场洞察 # 3. 数据分析市场 $ 4. 知识库/智能客服市场 "% &' 结语 (& 关于爱分析 () 产品服务 (* 法律声明 (% 报告综述 5|2024爱分析·大模型应用实践报告 1.报告综述 人工智能大模型,是指通过在海量数据上依托强大算力资源进行训练后能完成大量不同下游任务的模型。大模型以其在模型精度和泛化能力等多个指标上超越传统AI模型的表现,以及赋能千行百业的巨大潜力,成为当今世界各国人工智能技术发展的核心方向。 大模型经过近一年半的高速发展,已在政府、医院、学校、企业等各类需求群体中建立初步认知。其中一部分需求群体设立专项预算、开放业务场景,对大模型进行试点应用。通过试点应用,需求群体加深了对大模型能力和价值的认同感,进而普遍希望在未来继续增加相关预算,将大模型与实际业务进行更深入、更广泛的融合。 大模型应用百花齐放,其中数据分析和知识库/智能客服是企业在2024年关注度最高的是两个应用场景,成为企业落地大模型的重要抓手。调研数据显示,准备在2024年应用大模型的企业中,有78%计划在数据分析场景落地,有70%计划在知识库/智能客服场景落地。基于此,本报告将重点研究数据分析和知识库/智能客服两个特定市场。 图表1:2024年大模型重点应用场景 1|2024爱分析大模型应用实践报告 市场洞察 2|2024爱分析大模型应用实践报告 2.市场洞察 通过对近百家大型企业的调研,爱分析归纳出大模型落地应用过程中普遍存在的挑战,它们遍布规划、立项、选型、实施和运营等全流程。本报告将选取三个重点挑战进行论述并提出解决方案。 挑战1:大模型项目未与企业保持战略一致性 一般情况下,大模型通常是由上至下推动的,由董事长或CEO等企业一把手宣布大模型必须落地的任务。该任务无论分配到哪个团队,都会启动一个以大模型为主题的项目,并展开一系列汇报工作。在汇报过程中,企业一把手询问的首个问题往往是大模型项目与公司战略的关联。但是,在大多数汇报中,项目负责人的回答仅局限于大模型技术和应用,例如“大模型+知识库”赋予一线员工的能力提升、“大模型+数据分析”提高了业务人员使用数据的便捷性等。这些价值与企业战略间并无必然联系,即大模型项目与企业战略之间没有必然联系,进而导致大模型项目难以顺利过审。某大型化学用品公司CIO向总经理汇报2024年度IT项目规划和预算情况,但汇报并不顺利,重点问题在于大模型项目的业务价值没有打动总经理。因此,爱分析建议首先要解决如何保持大模型项目与企业战略一致性的问题。 实际上,多数企业在2023年年末至2024年年初期间会做2024年企业战略规划,其中必然涉及到战略目标设定以及战略解码的过程。爱分析认为,大模型项目必须在战略解码的过程中找到自身的核心定位,或者说确定其与战略的紧密联系,这对于项目的顺利进行至关重要。 下图为一个常见的战略解码过程,涵盖了从整体公司级战略到管理层设定的KPI目标,再到业务执行层的每个项目。无论是采用战略地图或者其他形式,都可以帮助企业进行战略解码的工作。其主要作用是在整个战略解码的过程中,尤其是在最终的执行层(项目)中,真正找到符合企业自身情况的战 略对齐,从而提升大模型项目的价值。 图表2:战略解码过程示意图 某金融机构在每年年底和第二年年初时,需要对整个十四五规划进行全方位回顾。在考虑十四五规划时,一个颇为关键的战略是自主可控,这也被明确写入公司的十四五信息化战略规划之中。因此,大模型项目负责人就是从十四五战略规划中出发,从中挑选出适合的项目。该金融机构最终选中的落地项目是“大模型+运维”,选择原因其实是它比较好地解释了自主可控。这里的自主可控不局限于外资软件或基础设施,更多的是对外部供应商的自主可控。在此过程中,大模型与运维的联合价值显得尤为重要,因为可以对金融机构现有自身内部能力进行强化,也就是大模型可以提升公司内部运维人员的技能,例如通过知识库、BI以及其他能力赋能内部运营的人员。运维人员在这个过程中,可以减少对云厂商或外资硬件服务器厂商等存在的高度依赖,从而以更好的程度体现出自主可控性。该项目从立项到实施都较为顺利,因为在项目之初便将整个公司的十四五战略规划中的自主可控性纳入其中,是一个非常优秀且值得借鉴的金融机构案例。 挑战2:大模型业务收益难设定 大模型项目负责人在设定业务收益时,头绪繁多,但缺乏找到行之有效的收益项。当前常见的大模型业务收益主要包括提升企业/品牌形象、减少资本支出和运营支出、业务收入增加、提升客户满意度、 提升员工人均产出、缩短流程时间、加快新产品上市节奏等。如果大模型项目负责人追求“多多益善”,而不是“有的放矢”,企业内部往往难以就业务收益达成共识,进而导致项目推进困难。 爱分析将提供一种易于操作且可行性较强的业务收益设定方式。在设定大模型业务收益时,需要从顶层开始进行考虑。这种策略的优势是从管理层出发,历经部门领导,直至执行团队,这是实现大模型落地的最佳路径。其背后原因在于,大模型本身需要获得来自管理层的大力支持,以及在公司范围内推动这项工作,那么针对管理层的大模型的应用赋能,或探讨如何使这个模型为管理层带来价值,无疑是更为有效的切入点。 某主机厂计划在2024年落地大模型,在应用场景上曾经过多次内部筛选,首先以面向管理层的场景作为首个目标。例如,在每月的经分会上,依托完全基于大模型生成的报表进行经分会的召开,报表主要展示了一些核心的日常经营指标。再例如,由于该主机厂规模较大,对于管理层而言,年终述职 报告便显得尤为必要,大多数领导可能需要花费长达一个月甚至更长的时间来撰写这份报告。因此,大模型项目团队根据日常运营分析中的一些核心基础数据生成报告帮助领导减轻年终报告的负担。由此可见,即便都是进行数据分析,在面向管理层时整体的业务收益会更易得到认可。 挑战3:提升数据分析结果的准确率 数据分析是很多企业在2023和2024年落地大模型应用的首要场景,但生成结果的准确率较低,困扰着大模型项目负责人。导致该困境的主要原因之一在于大模型数据分析是基于语言交互的方式,无法限制用户的提问方式,因此理解问题和生成结果的难度偏高。以下通过一些来自用户的真实问题具体说明。 含义清晰的单任务问题最简单。例如“最近7天xx产品的订单总量是多少?”这个问题大模型 理解起来比较轻松,因为这是一个单任务,并且订单量、产品、时间等指标比较明确。 含义模糊的单任务问题对于大模型而言,难度也不大。例如“xx产品今年累计卖了多少?”大模型开始发挥优势,因为大模型擅长将模糊语义对齐标准语义。 一些涉及多表数据处理的问题,开始给大模型增加难度。例如“今年xx品牌在国内和国外的整体销量是多少”国内外销量经常存在两张表,两个销量的字段都定义为sales_count,如果对每个sales_count都做标注的情况下,针对两张表做unionall或者做关联的时候会导致生成的SQL结果不准确。这种情况采取的解决方案,是把所有数据通过数据模型打宽或预打宽,通过语义理解然后对齐到相应的指标字段。 不限制问题长度的复杂问题带来更大挑战。例如“xx品牌最近3个月国内销量最好的产品是哪一款?每个产品平均每月销量是多少?”大模型需要先查询过去某品牌三个月每个产品的销量,再基于查询的结果找到排序最好的几款产品,然后根据第二步任务结果找到排序最好的产品,计 算平均每月的销量。 复杂且需要调用专业算法的问题最为困难。例如“华北地区xx的效率月环比为什么下降了?”大模型不仅要查上个月的数据,还要针对前一个月的环比数据作计算,并且判断是否下降。在此基础上,还要调用归因能力,归因的算法能力不是大模型本身所具备的,所以要通过插件化的方式让大模型去调度,把之前的结果做参数解析填充到对应插件里,并生成最终的结果。 将上述每个问题的难点进行总结,影响生成结果准确性的原因主要在于语义对齐和任务多样性两个方面。语义对齐是指对齐用户口语化的查询和指标字段、维度字段、甚至是其它API的输入参数。任务多样性是指用户在提一个复杂问题或者目标时,大模型肯定无法直接执行,因此需要把目标或复杂任务拆解成多个子任务后,每个子任务做协同执行,再完成用户最终的提问需求。 针对语义对齐的问题,可以通过语义增强配置的方式来解决。用户在提问时并不一定准确知道什么场景下该问什么指标,而是进行场景描述。因此要把企业的业务数据做指标语义化相关的生成和配置, 包括指标名称、业务口径、应用场景等。针对用户提问,基于相似度和索引找到对应指标。针对任务 多样性,可以通过引入Agent方式来解决。Agent具备规划拆解能力,并且在此之后通过调用插件执行子任务。比如,Agent基于指标查询会把指标、维度和时间三要素解析出来,填充到标准化的接口。Agent还会调用归因、预测、异常检测等算法。 数据分析市场 8|2024爱分析大模型应用实践报告 3.数据分析市场 数据分析有两个落地要点,一是如何借助大模型实现更准确的意图理解和SQL生成,二是如何借助大模型实现深度分析。实现这两个要点,才能推动到大模型数据分析从“可用”到“好用”。 第一个落地要点是如何借助大模型实现更准确的意图理解和SQL生成。传统的取数过程中,用户需要 明确掌握SQL语言和相应的数据库结构来提取所需信息。随着NL2SQL技术兴起,用户只需使用自然语言描述需求,由后端系统将其转换为适当的SQL语句,简化了查询过程。但NL2SQL技术仍有缺陷,其自然语言处理能力较弱,在处理模糊查询和复杂意图查询方面存在挑战。例如,NL2SQL技术难以解决像“我想查询公司内部有多少本科以上学历的员工”这种问题,该模型可以准确识别“本科”一词,但难以理解“本科以上”这四个字。大模型为NL2SQL带来了更强大意图理解能力,在处理模糊、多义或复杂的用户查询时,系统可以更准确地识别用户的真实需求。当然,在大模型出现之前,市场上也存在解决以上问题的方法。这是主要依靠项目化的方法,通过不断的配置和人工微调的方式来解决查询模板无法处理的问句。该方法导致项目交付周期长、成本投入大,并且长期需要运维人员持续维护。 为保证准确率,目前主要采用限定查询边界的解决思路。具体而言,有两种实现路径。一是基于指标平台,这一点与前面提到的语义层颇为相似,是把常见的指标先基于宽表进行计算,如果再运用自然语言查询指标,其精确度会相对较高且基本上具备可控性。这种方式能够在一定程度上降低幻觉现象。二是将大模型与宽表或语义层相结合,运用宽表和数据源来构建语义层,继而在该语义层上进行相应的匹配和查询。这类模式的具体操作方式是,先去精准地匹配到语义层,如果未能实现精准匹配,一般会通过一个亿级别的小模型先去精准地匹配到宽表,然后基于宽表再用大模型去做理解。 第二个落地要点是如何借助大模型实现深度分析。取数可以视为分析的前置动作,也可以视为浅层分析。其属于描述性分析,用于回答“发生了什么?”,核心要求是呈现全面、准确、实时、可视化的 数据。除此之外,企业还需要诊断性、预测性和处方性数据分析。诊断性分析用于回答“为什么会发生”,核心要求是能够深入了解问题的根本原因。预测性分析用于回答“未来可能发生什么”,核心要求是通过历史数据来预测未来。处方性分析用于回答“现在我应该做什么”,核心要求基于数据和分析技术提出具体建议。诊断性、预测性和处方性数据分析需要用相关性分析、预测性分析、因果推 断等分析方法来具体实现。企业对对话式分析的期待不局限于取数,而是希望它在深度分析方面可以发挥更大价值。 企业需要和具备训练或微调大模型能力的厂商进行合作。企业可以直接用基础大模型进行相关性