AI知识库

53AI知识库

学习大模型的前沿技术与行业应用场景


融合企业内部数据,赋能工业场景多模态智能决策
发布日期:2024-08-09 14:18:38 浏览次数: 1717





工业场景内,结构化数据与非结构化数据多散落在内部系统里,数据孤岛会造成企业分析决策的一大瓶颈,严重阻碍发展进程。如何利用好多模态数据进行分析是工业场景的重中之中,本文将从四个方面对其进行介绍。

分享嘉宾|胡也畅  Fabarta 企业智能分析平台(ArcPilot)产品负责人

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


01

多模态决策智能的现状与路径

1.1工业场景下的多模态数据现状

根据 IDC 报告显示,目前企业结构化数据仅占到全部数据量的 20%,其余 80% 都是以文件形式存在的非结构化和半结构化数据。该现状在工业场景下只多不少,横向观察工业场景的数据现状:

1、结构化数据已经实现一定程度上的数据智能(BI)。以可视化监造、 TPM 、 MES 、 IoT 系统 、通用仪表大盘为典型代表。结构化数据通过数据智能或者商业智能在一定程度上实现了智能性表达。
2、非结构化、半结构化数据的分析与决策还在非常早期阶段。非结构化数据的代表是以文件为主的传统知识库,包含设备部件参数、设备操作手册、故障运维手册等等。非结构化数据部分对大多企业来说,还处于早期阶段,多数仅有内部知识库产品,把相应手册、文档材料往上放,供内部人员使用和分享。
3、在决策智能场景下,将结构化数据和非结构化数据融合,可以进一步放大数据融通后的价值,提供更多的决策支持。在未来,无论是面向不同任务意图的大小模型串联,或是根据智能体构建的相关工具进行编排和调用等触发智能决策,目前都处于初期阶段,这也是本文重点讨论的内容。
1.2结构化数据的智能决策之路
从上世纪80 开始,以 Oracle 、 PG 数据库为代表的经典数据库,再到 2010 年代大数据产品的爆炸和兴起,以及在同一时间兴起的工业界 IoT 相关传感器数据,长期都以 BI 作为数据的出口。
在 BI 领域,有句话是“得益于 BI 的同时苦于 BI ”, 主要因为 BI 的开发周期相对较长,而业务迭代快。部分制造业客户反馈,“业务迭代速度 3- 6 个月左右,但等到 BI 报表开发出来,业务窗口已经过半。”另外 BI 的业务逻辑、口径较复杂,一旦业务逻辑和口径理解不一致,会直接导致最后的数值偏差大。在此过程中,数据的消费者从传统数据开发者逐步过滤到业务用户,这是当前数据的现状。
大模型的兴起使其逐步成为传统BI的挑战者。无论是通过 text2SQL 将自然语言转化成数据库的查询语言,还是通过 text2metrics 依托于现有指标系统将自然语言转化为指标系统的查询方法,亦或是通过 text2API 将自然语言转化为不同数据库或系统的 API 调用,这些技术都致力于将自然语言转化为数据查询。网上有很多 Demo 搭建教程,但搭建 Demo 很容易,然而将 Demo 的落地却很困难,最常见的难题是问不准。主要原因有三个:
首先,在询问具体事件时,语义模糊会影响整个识别过程以及最后的结果。其次,问题类自然语言较为复杂,有时人都不能百分百理解准确,大模型也不能理解。例如“总量”这个概念在不同企业和不同场景定义都不一样,有时是加权,有时是求和。最后一点,大模型给出的结果缺乏可解释性。当企业用户对数据产生质疑时,便会对整个系统产生质疑。这三点是利用大模型进行数据决策时会遇到的问题。

枫清科技(Fabarta)去年专注解决问得准的问题,目前已经有比较完备的解决方案,但同时也遇到了新的问题。我们发现,业务用户对于“问得准”需求后的满足时间阈值只有 3- 6 个月。之后客户会提出新的需求:如何让数据准确引导决策?举个例子,当我们已经解决“某某工厂的产量与能耗分别是多少”这个问题,接下来领导层会更加关注以下几个问题:哪个工厂能耗最高?哪个最低?能耗高的原因是什么?哪些方面的改进能够减少能耗?同时,客户也会关注,在获取数据后能否将企业内部已经有的机器学习、 AI 学习模型或者生产制造中的机理模型串联起来,并根据问题将结果生成对应的报告,让大模型参与落地和自主执行。这部分更多是大模型落地的深水区,我们也在不同的角度反复自问:

  • Infra Ready for AI ?在大模型自主判断的场景时,数据基础设施是否准备就绪?

  • Data Ready for AI ?准备判断的数据本身是否值得信任,质量是否过关?

  • AI Ready for Apps ?当前以上两个问题都被解决了以后,要更深入地思考 AI 的自主决策是否能够实际帮助到线上的业务系统,业务应用能否直接产生价值。

1.3非结构化数据的智能决策之路

非结构化数据与结构化数据的智能决策稍有不同。非结构化数据以知识库产品为代表。根据观察,大部分中国制造业企业处于 1.0 阶段,内部有类似于 Sharepoint 的文档管理系统,将不同部门的文档进行上传,在文档之间做检索。一般而言没有语义理解的搜索产品,更多的还是文档归档和分发。

随着深度学习技术的出现,有了更多的基于深度学习和图谱的知识问答—— KGQA ,也就是2.0时代。过去利用深度学习训练一些 BERT 语言模型,进行意图识别、对话识别。同时会遇到两个瓶颈性问题:一是小模型的泛化能力较弱,一旦数据与问题发生了变化,回答的准确度很有可能无法覆盖。二是如果采用了 KGQA 图谱问答方案,企业会耗用大量时间在图谱构造的标注工作上。
大模型在企业落地的最经典场景是大模型加外挂知识库,同时也是我们所说的 3.0 时代。目前企业有望于直接从 1.0 时代跃迁到 3.0 时代,主要有以下几个原因:首先,在大模型的泛化推理能力显著增强,我们没有必要拿着相同的逻辑重复训练大模型。其次,随着大模型能力的加强,对非结构化数据的解析有了极大程度的提升。举个例子,做大数据相关产品时,有一句话“ trash in trash out ”,当系统位数据质量非常低,或系统无法理解时,往往系统无法给出建设性答复或分析,而大模型在非结构化数据解析和理解上有了很大程度的提高。所以很多企业逐步采用大模型的外挂知识库来解决对非结构化数据的理解问题。
在实际业务落地中,基于简单的 RAG 的检索问答方案,无法检索复杂文档之间的关联关系,从而导致检索精度相对较低,检索出的内容有大量噪音,导致回答出现幻觉以及不准确。这也是我们在 3.0 时代致力解决的问题。

对于非结构化数据如何参与到企业决策智能,其中最重要是需要把海量文档间的关系进行梳理,包括文档之间、文档作者之间、文档中细节知识片段的关系,在整个检索增强链路中都会取到非常重要的联系,提高知识问答的准确率。对于如何通过内容的理解参与决策,例如利用知识库里的标准内容对上传的方案进行分析,甚至给到修改建议,这些都是建立在对海量知识理解的基础之上做决策。最终决策方案将与业务系统做深度的融合,赋能已有的制造业领域系统。

02

多模态决策智能的数据基础

回到制造业行业,该行业的特点在于数据分散,设备相关手册与资料存在于众多系统里。当多模态数据无法融合时,知识本质上会以一个个知识孤岛的形式存储在不同的业务系统中。知识孤岛成为了大部分企业进行业务分析的瓶颈。

2.1 Data Ready for AI: 统一语义层

做好数据基础设施的要点之一是统一语义层。谈到统一语义层时会涉及到元数据,元数据是描述数据的数据。有了语义层后,无论哪种数据来源,首先都会用元数据进行收口,同时用更智能的方式补齐元数据,发现、构建元数据之间的关联关系,最终将相似的语义进行统一,实现面向业务的语义层。
有了面向业务的语义层后,可以帮助大模型更好的感知,当遇到特定任务、话题后,将采取哪些语义层数据解决问题,统一语义层再分发到具体的数据源上获取相应的数据,实现大模型理解数据意图能力的进步。统一语义层中有两个功能分支较为重要。

  • 元数据 for AI 。提供规范的元数据,让大模型更好地理解元数据、更好地落地。

  • AI for 元数据。半结构化、非结构化数据的元数据质量相对较差,利用 AI 技术帮助异构元数据进行智能补齐与关联发现。从而为统一层的梳理提供更好的基础表达。

2.2 图+向量的融合方案
相比于传统的向量解决方案,对于有关联、确定性知识,我们提供是“图+向量”融合的解决方案。这里的“图”并不是指传统意义的图片,而是存储关联关系的图数据库。在大模型领域,大家对向量数据库普遍比较熟悉,因为向量数据库可以处理许多基于概率的信息,而大模型多基于概率进行推演。另外,前文所提到所有的关联关系,更适用于原生存储在图数据库系统里,图数据库更多关注多源异构数据之间的关系,可解释的智能。有了向量数据库和图数据库两种技术加持,可更好地将数据转化成图和向量融合的知识。

企业内部数据进入向量数据库与图数据库的判断标准是什么?对于数据间的关联关系,比如说元数据、结构化数据、非结构化数据的关联关系,都可以作为确定性知识存储在图数据库中;同时,将文本、图片、音频等多模态数据存储在向量数据库当中。当确定性知识和概率性知识融合后,多模态智能引擎作为 AI 数据基础设施,可以显著优化大模型实际场景落地的质量。

03

实际落地案例

3.1统一语义层增强的多模态知识融合分析
统一的语义层如何助力多模态知识的融合和分析?这是较经典的知识库场景,假设企业存在上万文档,而一个话题背后对应的潜在切片能达到百万甚至千万级别。这种情况下,普通 RAG 会召回非常多的相关片段,直接导致回答不准确。当有了统一元数据的加持以后,效果明显更准确。首先当用户登录到系统里后,可以准确识别其身份,用户问道“某设备的具体参数分别是什么?”,与其直接做向量数据召回,更多要思考问题和提问者背后的关联属性,如:
  • 结构化数据:如提问人所属工厂的信息。

  • 非结构化数据:如相关的设备参数文档。

  • 语义关联拓扑:如设备类型、生产商、文档信息。

有了数据表达后,能更精准定位到关联关系,如提问人所属具体工厂、问了哪些设备。来自哪些生产商以及相关文档等。虽然 Bad case 和 Good case 都可以给出回答,但是只有 Good case ,数据来源基于语义和数据的关联关系,更为精准,这种方案才能显著提升回答的质量和精准程度。

上图的例子中还需强调一点,用户提问到某起重机的具体参数,虽然在该提问者工作的工厂知识库中没有找到相关资料,但是在其他工厂有该设备的材料。系统会将这些资料根据其所属的工厂进行分门别类地进行回答和摘要总结,并不像普通 RAG 把所有资料打包直接输出。所以有了关联关系后,可以对知识本身进行扩展,进行更加准确的分析、理解和表达。

3.2统一语义层增强决策智能体
以问数为例,语义可以显著提升系统的智能化程度。在问数领域,大模型原生的理解能力,不管是对数据的理解能力,还是对 SQL 的理解能力,大概只能解决 30% - 50% 的问数常见问题,距离生产可用仍有非常大的差距。
首先,我们会在大模型原生能力基础之上加入对于语义的基础描述如表与字段的含义,完成后准确率会提升到 70%- 80% 级别,相比于原生理解能力有了很大的进步。但仍不足以保证生产可用,所以需进一步引入基于语义的业务含义描述,包括动态少样本学习、思维链。有了语义描述后,将准确率提升至 85% 甚至以上。在我们刚结束的一个  POC 项目中,已实现 100% 业务语义覆盖度。统一语义以及基于语义的业务描述会对智能决策产生非常显著的影响。

只有解决了问数、取数才可以迈向下一阶段,也就是数据的归因分析与自主决策。

第一要解决问的到与问的准,很难实现一线用户都能使用学术性词汇表达自己的问题。所以我们不仅会对关键词做模糊匹配,同时问题涉及多个可能的字段,也会做一个澄清,说明具体含义。

第二要解决问得清和看得明。当用户提问的同时还需要另外两个指标,这里都能提供正确回答,这时会有类似 BI 的需求,我们不仅仅能给用户生成智能图表,把数据库的数据进行原始表达,也能基于对业务语义的理解生成对应的图表展示,包括摘要总结,能够在会话里获得更多信息和资料。

04

大模型智能体应用构建平台

大模型智能体应用构建平台,从产品定位角度而言,向下更多会做大模型的能力支持,包括通用基础大模、专业领域小模型。向上则通过平台对接大模型的典型场景,如智能对话、应用助理、数据分析、行业领域的决策支撑等。同时对接企业里不同数据,把数据全部都融汇到私有记忆体中,为所有决策分析提供数据保障。

枫清科技(Fabarta)正在进行和落地的案例之一:引入智能体解决高阶复杂的制造业问题。在智能体领域,核心解决方案是利用内外循环思路。问与查都是较简单的数据表达,复杂情况需要智能体能力进行数据调度。为解决复杂问题,利用外循环规划 Agent  实现任务拆解,再根据不同任务在内循环中选择合适的调用工具,包括反思。整个这个过程同步反馈到计划的主智能体,由智能体进行迭代学习、反思,对任务进行修改。

举个较简单的例子,当用户问:“明天天气怎么样?”,这个问题对于人类而言非常简单。但把问题进行逐一拆解,首先在外循环中对问题的解决做明确主题计划,要明确用户所在地,通过问询、 IP 、网络信号等获得,还要获得需要查询天气的日期。只有以上两个条件都确定后,最终才会执行天气的查询。每个任务都会进入到内循环状态,实时对任务、工具的选择进行感知。在实际工业场景中,智能体方案落地时,往往会带来大量的工具反复调用,包括工具间串行和并行的执行,这也是深水区解决复杂任务的最大挑战。


53AI,企业落地应用大模型首选服务商

产品:大模型应用平台+智能体定制开发+落地咨询服务

承诺:先做场景POC验证,看到效果再签署服务协议。零风险落地应用大模型,已交付160+中大型企业

联系我们

售前咨询
186 6662 7370
预约演示
185 8882 0121

微信扫码

与创始人交个朋友

回到顶部

 
扫码咨询