AIGC技术正以惊人的速度重塑着创新的边界,InfoQ 首期《大模型领航者AIGC实践案例集锦》电子书,深度对话30位国内顶尖大模型专家,洞悉大模型技术前沿与未来趋势,精选10余个行业一线实践案例,全面展示大模型在多个垂直行业的应用成果,同时,揭秘全球热门大模型效果,为创业者、开发者提供决策支持和选型参考。关注「AI前线」,回复「领航者」免费获取电子书。
大模型增强下的图智能在金融场景的应用与实践
嘉宾 | 贾志鹏 枫清科技(Fabarta)图智能解决方案架构师
在日前举办的 ArchSummit 全球架构师峰会上,枫清科技(Fabarta) 图智能解决方案架构师贾志鹏结合自身的实践经验,分享了大模型与图智能技术结合的三种方式和当前图智能在金融领域落地过程中遇到的挑战,以及图智能结合大模型在营销场景和金融知识库下的应用案例,帮助企业更好地了解行业现状和未来发展趋势,获取实践经验。
8 月 16-17 日,FCon 全球金融科技大会将在上海举办。本届大会由中国信通院铸基计划作为官方合作机构,将邀请国内外金融机构及金融科技公司专家分享其实践经验与深入洞察。AIGC、RAG、Agent 智能体等作为焦点话题,届时也将有多个议题分享,广发银行信用卡中心商业智能负责人徐小磊将分享《AIGC 在银行线上渠道的应用实践》,工银科技技术总监孙科伟将分享《人工智能技术在金融科技领域的应用探索》,蚂蚁集团投研支小助技术负责人纪韩将带来《多智能体协同范式在金融产业中的应用实践》...... 大会更多演讲议题已上线,访问链接可查看详情:https://fcon.infoq.cn/2024/shanghai/
以下是分享全文(经 InfoQ 进行不改变原意的编辑整理)
枫清科技(Fabarta) 公司是一家初创公司,主要是做一些支撑大模型落地的 AI 数据基础设施方面的产品,比如处理符号化数据图和向量的多模态智能引擎。我之前在 IBM 工作,负责内部架构管理工具的研发,当时研发的架构管理工具,就是通过图智能的方式把 IBM 内部的解决方案架构全部管理起来,做到迅速响应新的业务需求,快速地推送之前沉淀的架构,因此比较早地接触了图智能,也陆续有想法尝试应用图智能技术解决其他场景的问题。随后在加入枫清科技(Fabarta)之后,我参与了很多银行方面的图智能分析项目的落地工作,包括概念验证(POC),积累了一些经验和思考,在此和大家进行分享;
首先,在开始之前,想和大家来同步一下我们对于图技术的理解。相信大家对于作为计算机科学中的基础课程——图论都很清楚了。图就是通过实体和关系来表达现实中的关联。我们常说的一句话是“一图观万物,一图胜千言”,终其原因是由于图智能是一种可解释的智能;图可解释原因在于,一旦我们清晰的构建并呈现图数据后,背后隐藏的决策因素或者数据的情况就自然的显现出来了。
举个例子,金融机构在提供 APP 服务的同时,在用户允许的前提下,会采集用户操作时的 IP 地址或者 MAC 地址,用于辅助识别用户的行为。我们围绕信用卡申请业务,将这部分数据加工入图后,通过画布进行图数据展示,就可以直观地看到围绕某个 IP 地址有多少用户提交了信用卡申请,同时在相同 IP 地址下,有多少用户使用了相同的 MAC 地址;这样的展示的已经比较直接,通过这样的图数据,我们就可以发现很多有意思的事情;比如,某些 IP 地址可能关联着大量的用户(原因可能该 IP 地址属于某栋建筑的共享 IP 地址),在这种情况下我们可以进一步查看属于同意 IP 地址的用户是否属于同意 MAC 地址;一旦出现围绕某个 MAC 地址有聚集性的用户出现,这个时候就需要重点关注了,客户涉诈的风险就变得较高了,在此基础上在图上围绕这些用户再进行其他关联信息的查询,会发现某些情况下这些用户具有相同的客户经理或者推荐人,这就涉及到另外一种合规模式了。
当我们拥有这样一张完整的图数据的时候,通过直观的图数据展示和分析,我们就可以很快的得出数据背后存在的结论,以及所带来的决策和影响,这就是为什么我们说图智能是一种可解释的智能。
那么,为了实现这样的可解释的目标,我们在使用图智能技术的同时往往会包含以下几个方面:
第一,图数据库技术。我们需要图数据来对图数据进行存储,并且能够支撑高效的查询。例如刚才的例子中提到的关联网络的查询,如果换成结构化数据库来做,可能需要 5~6 次的联合查询,在数据量大的情况下,可能就没有办法实时了;但是由于图数据库的特性,对于这种 5~6 跳的查询,相对来说是容易的;
第二,图计算引擎。在数据存储之后,需要计算引擎来执行各种算法。图算法即包含从学术界到工业界应用的各种算法外,也需要能够支持定制化的算法。需要应用这些算法对数据做进一步的处理和分析;
第三,图可视化。让数据和分析的结果能够更直观的呈现给分析师或者终端用户。图数据可视化是理解复杂关系网络,并发现模式的一个关键手段,同时也能够帮助用户直观的理解数据背后的信息;
第四,图分析。综合应用也上多种手段,围绕业务目标采集数据,构建图谱并进行相应的分析工作,才能最大化的释放图数据的价值。
图智能技术在业界的应用前景广阔,大家对于图技术的应用的期望也很高。Gartner 在 2022 年的报告中预测图智能技术将能够更广泛的应用在数据分析等创新领域。我们总结下来,其应用的方式基本如下:首先会将企业持有的结构化数据、非结构化数据和半结构化数据进行图化的加工处理,随后通过应用结果建立知识图谱、基础图谱和图智能分析应用,并用于后续的具体业务场景。
一直以来,在金融领域,大家对于图智能技术的应用场景都进行了积极的尝试,看是不是能够创造新的价值,或者说带来突破性的手段来解决现有问题;总结下来会针对五大类的场景进行尝试:
首先是知识库服务,这不仅仅限于知识图谱,还会更进一步,比如把企业文档形成一个知识库的管理,类似我在 IBM 里面所做的事情,方便不同的用户或业务方轻松获取所需的知识。
其次是反洗钱、反欺诈和智能风控这三类,它们本质上会涉及到团体性的行为,不是一个人来完成,因此必然存在团体的关联关系。所以在这些场景中,我们会首先用核心的交易数据构建它们的交易图谱。在交易图谱的基础上,也会通过外部数据采集的方式获取更多信息。比如,对公,我们会获取相应的工商管理信息深入分析。另外,在风控的过程中,针对信用卡业务,我们会应用提交的各种信息,比如填写的共同地址、IP 地址或者 Mac 地址。
最后,还有一类特殊的应用是智能营销。在互联网行业是普遍采用图神经网络或者图卷积网络进行搜索推广和营销活动,原因是他们有大量已标记或后台处理的数据,商品上架系统也有相应的支持。但是对于金融行业和银行来说就比较困难。一是因为,金融产品种类较少,缺乏标准化的数据标记。另外金融产品比较具象性,提供的产品是服务于特定的用户群体。我们的策略不是在产品标注上下功夫,而是专注于客户之间的关系。举例来说,可以进行一些对公或者对私的穿透,通过分析对公客户,找到高净值的个人客户,去进行相应的金融产品推广或者私人银行服务产品的营销。这种方法也适用于反向操作。如果我们尝试通过企业间的产业链来获取数据,这对于银行或者金融机构来说确实相对困难。目前这还只是停留在概念阶段。
针对上述的业务场景,我们可以将下层的技术支撑归纳为三类,就是我们说的三类图谱的方式,即知识图谱、基础图谱和图智能分析应用:
第一类是知识图谱。这是大家比较熟悉的。最开始接触图,可能更多的都是从知识图谱开始的。知识图谱造成的影响使得我们后面可能会把所有的采购项目都叫图谱,虽然它实际上是关于图分析的内容;
第二类是基础图谱。它可以帮助我们企业内部的数据关联起来,特别是集团实控人等这些关系。基础图谱不是围绕着某个业务目标,只是去做把数据整理起来的事情;
第三类是图智能分析应用。在建立基础图谱之后,我们希望能够应用更多的数据分析手段对数据进行分析以释放数据价值。在分析过程中,不仅仅使用图技术,还会结合其他的 AI 技术进行分析,互相补足;同时,我们还会应用图算法、图神经网络和图卷积网络技术对数据进行分析,以来支撑上层应用;
针对上述三种方式,我们来展开介绍下各自的构建方式
知识图谱的构建过程,首先是要获取数据,这个过程中可能会遇到一些问题,尤其是如何处理结构化和非结构化数据,也就是怎么处理文本。文本数据需要进行标注,想要把它变成知识,就得打标。接着是训练不同模型来去进行实体的关系抽取,然后就是整合知识并进行质量评估。最后是上线存储,后续计算。整个过程非常清晰,但每个步骤都有相应的代价。
另一个问题是,尽管知识图谱被业界广泛认为是有用的,但它有用的时效性是不一定的。为什么呢?因为知识其实是会过时的,特别是源数据,也就是我们刚刚所说的标签数据,如果没有持续维护标签数据,或者我们的模型没有及时地根据新数据进行调整,最终实体抽取的准确率就会逐渐下降,最后就会影响整个知识图谱的使用情况。
在我们开始之前,已经有很多知识图谱的厂商在进行类似的工作。我们也考虑过增强,但实际上来说比较困难,主要是因为运维成本高,而不是说难点在技术上。
在做整个知识图谱的过程中,企业会发现,是没有办法去一直维护文本性的数据。于是开始尝试着在处理结构化数据方面构建一些基础性的突破。特别是对于银行来说,还是比较关注客户关联。用对公来举例,我们希望能够构建整个对公的企业图谱,包括实控人图谱和集团图谱。这样做的好处在哪里?首先在于它的数据大多数是结构化的,来源于它本身的客户管理系统。其次,即使是我们在外部采集的数据,不管是征信报告还是企业工商信息,不管是以 API 的形式订阅,还是以文件的形式订阅,基本上都是稳定的,短期内基本不太会改变的结构化数据。
通过这些结构化数据,我们可以把其加工入图,然后采用不同的编程计算方式计算。举例来说,股权穿透就是能在市面上拿到的,企查查能拿到的数据,能够提供企业之间的控股关系,比如 A 控股 B 50% ,B 控股 C 40% 这样的关系。在这里面使用特定的穿透算法来分析这些控股关系,超过 50% 的控股可能会有实际控制权。包括一些特殊类型的企业,比如国央企下属的公司,尽管它们控股比例可能很低,但实际上是具有一定的控制能力在的。所以我们需要用不同的算法进行分析,保证整个过程相对来说是比较稳定的。
目前业界开始的第一步都是尝试构建基础图谱,因为它逻辑可编程,数据结构化又比较稳定,只需要周期性执行算法或者补充算法。目前的挑战不算特别大,主要的挑战在于需要梳理对应的业务算法逻辑。
有了知识图谱、基础图谱或者构建了其他的图数据,我们就要做分析。图智能分析的流程和进行其他数据分析项目的流程是大同小异的。
首先,业务理解,在这个阶段需要澄清一点,业务需要面对的方向是非常广泛的。例如,像风险管理、反欺诈听起来是基础的交易数据,但实际操作的时候需要进一步细分。面对不同的客户,要求都是不一样的,我们需要选择不同的数据处理方式。
比如在信用卡申请风控方面,对于 IP 地址、MAC 地址和真实的地址处理的方式都是不一样的。如果是一个对公的风控,它的 IP 地址应该与哪些关系打上联系?这些都会有细节上的差异。我们在落地的过程一般不建议客户一开始就建立完整的大图进行分析,而是在建立基础图谱的基础上,根据需求加工特征图,然后输入到我们分析的图的网络中。这个过程中,可以逐步积累一些图的数据,逐渐完善大图。建立一个完整的全行业或者全企业级的图谱应用。一旦确定了业务之后,需要决定图谱的类型。在分析过程中,图谱的类型是不太一样的。如果用于可视化分析,可能需要更丰富的节点类型和编码,让它能够更好地展示关系。但是真正要跑算法的时候,需要把数据折叠,做成同构图,才能跑聚类算法。
下一步骤是确认数据来源,包括我们当前可以获取的各种数据的来源。在真正落地的过程中,银行或者其他金融机构都会碰到一些问题。有些数据来源于交易数据,虽然各个机构都有交易数据,但这些数据可能会中断。比如,如果一个银行的客户进行了一笔转账,而转账的对象是其他银行的客户,那么这笔交易在数据库中就会中断,因为交易的对象不属于该银行的客户。所以面对这种情况,就需要采取一些补足措施进行数据处理。
梳理完整的数据和业务主题后,我们就设计好图谱,进行实体关系的加工。在加工完成之后,我们就会做探查的工作,类似可视化数据的呈现。在没有黑样本的情况下,就从聚类的情况出发,随机渲染部分数据进行探查。如果有黑样本,可以围绕黑样本去找它结构性的特征。比如说,关于一些结构性交易,包括循环转账交易,都是在图上直接可见的。我们需要识别这些特征,把结构性的特征变成图模式去跑,结合图智能算法分析。将对整个群体进行聚类后,可以深入探查每个聚类里的情况。在这些聚类里面,也可以用度中心性的算法来评估每个节点的影响力,最典型的是 Page Rank 算法。我们可以利用它来确定这是不是一个关键的节点,通过路径分析来识别它具不具有潜在的关联交易。得到分析结果之后,我们会通过 API 或者可视化的方式将结果传递出去。
我们尝试过以低代码或者画布的形式传递整个数据,但效果不是很理想。这种方法对于具备数据分析能力或者相关背景的业务客户可能比较直观,但对于风控或者反欺诈的实际案例,最终还是需要把结果传递给客户经理。客户经理可能了解银行业务,但是他不一定精通数据分析,所以这个信息传递可能不会那么直观。
总结来说,图智能分析的第一个环节是理解业务诉求并将业务诉求转化为模型设计。在中间环节,包括如何调整和映射我们已有的算法,如何运用算法进行分析。最后的环节是业务应用,就是怎么把价值快速地传递给终端的业务用户。在这个过程中,我们首先可能面临业务理解方面的挑战,在最终的数据应用阶段也会遇到一些挑战。
总结起来,在应用图智能技术时,我们一般会遇到两大类问题:
第一类问题是关于底层数据的挑战。现有数据通常是非结构化或者半结构化的。目前图还是很广泛地应用在分析方面,还是做 AP。像 TP ,银行交易系统很少直接用图数据库去做。所以我们需要花大量精力在知识图谱实体提取、基础图谱加工和图智能分析上进行迭代调整。这些工作会带来很大的成本,尤其是知识图谱的构建和后续运维成本。
第二类问题是使用的问题。构建好知识图谱之后,关键的问题还是怎样有效地使用它。在使用的过程中,就要面临两个问题。首先是如何理解业务需求,怎么选择适当的模式。在构建知识图谱之后,我们需要考虑如何使用它。在使用过程中,我们面临两个主要问题:如何理解业务需求并选择适当的模式。比如说我们如何针对反洗钱的业务背景或者业务规则把它转换成集中转入分集这样的模式去做?在这个过程中,需要人为去分析、选择或者尝试。怎么加速这个过程?怎么更好地呈现?类似风控或者反洗钱,有的最终需要上送数据,有的需要上送报告,怎么去处理这个事情呢?不能直接上送数据,让业务人员自行总结,然后撰写报告。
大模型推出之后,我们也尝试结合大模型从两个方向出发来解决以上的挑战:
首先,通过大型模型辅助我们逐步构建这个过程,我们可以分为两大类,第一类是自动建图,第二类是半自动建图。所谓的半自动,是在确定性场景下需要人为参与和干预图谱的质量校验。在分析和实际应用的过程中,可能是自动地进行映射,不断地、周期地同步数据。
在自动过程中,第一步需要梳理元数据之间的关系,类似于 schema。在整理元数据之后,我们需要处理结构化数据,也就是交易数据。从核心的交易系统或者数仓里面获取的数据,这些结构化的数据的列是确定的,需要对这些数据进行加工,加工成点表或者工程边表,最后形成结构化的映射,大模型可以做到这种方向的自动发现。对于非结构化数据,大模型也很擅长处理,比如文本中的实体关系提取,包括本身的一些文档或者在切片之后,给切片打标签。
在实施过程中需要特别强调的是,尽管大模型可以处理实体关系的提取,但在落地过程中必须进行权衡。也就是说,大模型可以达到 85% 的准确率,但剩余的 15% 可能无法覆盖某些特定场景,特别是在要求比较高的权威性、严肃的银行业务中。比如说风控,如果我们发现一个用户可能存在问题,我们不能上报说他有 85% 的问题,会涉及到准确性和权威性的问题,需要特别注意。
大模型可以帮我们发现结构化和非结构化数据的关系。比如,在结构化数据中存储了企业信用代码,要在征信报告中找到相应的数据,把这些关系建立或者后续的引用关系都可以通过大模型进行初步筛选和挖掘,建立映射关系。
这是我们尝试的几个方向之一,目的是加速构图的过程。但在真正的落地过程中,会发现大模型只能起到加速作用。特别是在金融行业,数据的权威性和严谨性要求比较高,管理层面上来说还需要投入额外的核查成本。无论选择哪种大模型,虽然在实际落地的过程中,我们不会自己开发大模型,而是会对接现有的一些大模型,去做一些落地工作,但是不管换成什么大模型,都无法避免这个问题。因此在这个过程中,需要有一套系统来支持和确保这些操作的验证。
关于元数据构图,需要先用大模型辅助我们补齐元数据。元数据指的是原始元数据,可能会有一些数据字典。在把这些字典真正形成图之前,需要做一些补充工作,因为可能会缺乏中文释义。在建库的时候,有些表格在命名时采用了拼音或英文,但这些名称背后实际上都对应着相同的事。比如,“KHBH”这个缩写,第一次看会比较懵,但经过了解,会发现它实际上代表“客户编号”。这类知识向银行业务人员咨询,他们会告诉你,“KHBH”可能对应英文中的“cust number”,实际上是一种从中文拼音到英文的转换。在没有释义的情况下,我们在构建知识图谱时会大量地咨询业务人员。后期我们也尝试通过大模型直接补全这些信息,先把中文释义补充全。在补充中文释义的时候,我们会进行一些调整,做一些映射关系表,在大模型的基础上补全。这样,就能够把所有的字段都补充完整,比如将“KHMC”补充为“客户名称”,并补充经营范围、统一更新代码等。
补齐元数据是一个准备工作,完成了之后,我们就可以开始进行映射。在这个映射过程中,实际上会涉及到两个映射,第一步是要将原始结构化信息中的关系建立起来。比如说,构建一个集团图谱,包括集团图谱的各个实体之间的担保关系。有了中文释义之后,可以使用相差相似度的方式或者通过的节点的出度、入度去确定哪些是点,哪些是边。简单来说,客户编号“KHBH”是节点,是因为当提取出来之后,发现它字段中文名叫客户号,在集团语言表里也多次出现客户号,这本身就代表背后是一个实体关系。
然后是构图。这其中有一部分是关于担保合同或其他文件,需要找出具体的内容条款,包括企业征信报告。有些资料是纸质的,特别是征信报告,不是电子化的文件,我们需要直接提取,然后存储它们。在存储的过程中,我们要映射这些文件或报告到对应的企业,建立起关联。整个过程中,我们会使用大模型来做三类事情:补全信息;建立映射关系,包括结构化和非结构化数据;最终生成图模式。
完整的图模式最终展示的是客户之间的集团成员关系,以及不同担保合同之间的各种情况等信息。在获取了这些元数据之后,能带来什么好处?第一个好处是它能够根据已有的数据初步展示能够建立的图形关系。第二个好处是我们可以应用元数据在数据治理和数据血缘分析等情况上,也可以用到类似的技术在数据图的生成过程中。我们可以进行结构化和非结构化数据的生成。
举一个在 POC 阶段的示例, 它的目标是为了实现去年下半年银行业务中普遍存在的绑卡业务的业绩,即新户绑定微信或支付宝账户。以前,银行在做营销时方法通常是直接赠送一些抵用券,转化率也不高。
想要改进这种情况,我们制定了一个新的方案,通过分析客户的交易记录以及他们在手机 App 内浏览的一些产品的情况,建立标签关联和数据关联。比如,我们会根据客户过去的交易记录,他们曾经在某个商场购买童装,或者在乐天大世界带小孩玩过这样的信息,推导出他们可能是亲子类型的客户。同时,我们还可以分析他们的店铺消费记录和位置数据。比如,如果客户曾在高新区消费过,然后通过亲子和高新区这些标签,可以在客户的下一次消费节点前为他推送相应的优惠券,推荐他进行银行卡的绑定。为了达到这个目标,要做的就是建立起人、物和场景三个标签的联系。
要给客户打“物”的标签,这个“物”就是我们提供的金融产品,包括企业内部上架的应用。对于“场”,就是标记商户本身的位置。这些数据的来源主要是结构化的客户信息和交易数据。但是,商户本身的标签是非结构化的,比如在银行手机 App 中上架的产品,不会像电商平台那样有严格的筛选。有一些金融产品的描述其实都是业务经理去撰写的,有时并不能准确地表达。所以我们需要利用大模型来提取这些标签信息。
通过大模型把整个标签提取出来,构建一个基础的标签图谱,可以是人物,也可以是商户等的一些关联关系。在后续的营销过程中去做相应的推荐。我们在实际落地过程中尝试区分了结构化和非结构化数据,比如客户信息和交易记录属于结构化数据,而图片、视频这些就可以通过一些其他的技术处理。
如何提高标签图谱的实际使用效果?我们的计划是通过大模型来增加它的使用。我们有三个使用场景,简单介绍一下。
第一个使用场景是帮助风控经理进行深度探索。比如,风控经理可能会想了解当前贷款企业的实控人和他三度以内的交易关系。这在前两年房地产市场爆雷的时候特别重要,我们可以通过这个信息来查看贷款资金是否流向了房地产行业,或者贷款的还款来源是否涉及房地产领域。这里面是有这样的一个交互的诉求在的。
第二个使用场景是图分析结果的应用。业务客户可能会关心企业是否存在关联交易。我们提供的是图分析的结果,客户虽然可能不知道具体的分析方法,但他们会问一些有关关联交易的问题,比如客户可能想要查看某个企业在 2024 年全年是否存在关联性的交易行为。
第三个使用场景是从数据中检索信息,自动生成报告。在没有大模型之前,我们会使用映射或者报告模板的方式进行处理。现在有了大模型之后,我们重新审视了整个落地过程,我们手里有图的 schema 信息,还有我们不断积累的图模式,即关联交易。图模式背后是一个三角技术的算法,就是 a、b、 c ,即 a 给 b 转账了, b 也给 c 转账,可以简单地表现为资金通过不同的链路向 a 到 c 转移的过程。这些图模式实际上代表了高度关联的交易类型,可能有几十种这样的图模式。另外,我们日常跑的图文分析任务中,可能会有一个洗钱账户的示例数据。在它的结构化交易活动中,会发现其他数据。总结起来,这就是我们最终得到的数据。另外,我们之前也为生成报告存储了模板。现在有了这四个要素,包括用户给到诉求之后,就可以利用大模型来建立它们之间的关系。
关于图智能在金融风控下的应用,我们会从内部持有或者外部获取的各种数据中,使用各种风控手段进行标注。这些标记的数据,我们帮它构造成一个围绕核心构造成的基础交易图谱,构建起客户关系的全貌。
此外,图智能分析并不是说取代了传统的分析手段,而是与之相结合。传统的分析手段能够更有效地帮助我们发现个体异常,特别是在没有黑样本的情况下,通过传统手段去发现异常的个体,进一步通过个体在关联网中找到它的群体。这种方式能够总结出交易类型和各种实体关联、资金网络等详细分析结果。
在分析完成后,我们可以运用大模型,去解读我们之前的报告文档,并生成相应的图谱或者规则关系。在这样基础上,第一件事是选择模式,第二件事是自动生成风控报告,第三件事是政策解读和知识问答。第三件事的形态类似于构建知识库或知识图谱,但实际上,我们并不是通过传统的知识图谱构建方式来实现,而是利用大型模型和图谱技术相结合的方法来实现。在这种情况下,随着我们不断地进行跨领域的构图和应用,我们的图智能技术会逐渐完善和迭代,产出一些高质量的图谱。
高质量图谱能够实现什么呢?就是图增强的 RAG。最初我们计划在 4 月提出,但没想到微软在 5 月率先提出了要做图增强的召回。为什么图增强的召回比向量召回更好呢?这是因为图是可解释的,是确定性的知识。
从技术上来说,大家都能尝试进行图召回或者混合图召回和向量召回混合,生成拼接,生成答案,但关键在于如何做得好。这就取决于技术的先进性,也取决于图的质量是否高。图的质量高意味着这个图是真正面向业务去创建的。针对不同的场景和问题类型,我们需要分类构建相应的图谱。
我们还有尝试应用到了前面提到的各种构图方式,把非结构化的数据提取出来,存储成图关系,同时也包括一些向量的存储。应用到向量是因为单点的定位其实还是向量速度更快,图只是方便实现快速的关系探查,所以我们实际上采用了一种混合模式。
案例四:图智能结合大模型在金融知识库下的应用
在我们内部,作为一家研发公司,我们会有代码的助手,叫 Arc42。它可以做什么呢?比如,问当前公司内哪位员工对存储引擎技术了解最深?这类问题涉及到对人和技术的理解,以及对最了解的判断。它就会做一个判定,通过飞书中的文档,包括员工提交的代码、各种会议纪要等内容,来提取关键信息和组织结构。最后,综合多方信息进行评估,得出判断。
第一个判断是判断这个员工是不是处于引擎研发的组织下。第二个评判是这个员工在会议或者提供架构文档时的价值贡献,第三个判断是员工提交的代码量。综合考虑后,将其整合并进行信息提取后,进行召回。在生成相关报告和最终答案时,依然会保持透明和逻辑的完整性。
在图应用过程中面临的数据构建挑战,以及应用过程中的各种挑战,可以利用大模型来自动化、半自动化地构建图谱,并通过大模型改进互动方式,比如通过问答形式和自动生成报告来加速应用和落地。最后,通过图的快速构建,可以反哺到大模型优化过程中,进一步提高答案质量。
今日荐文
微信扫码关注该文公众号作者