导读 本次分享围绕大模型技术在银行数据体系中的融合实践展开，介绍了结构化与非结构化数据的整合、大模型与业务系统的融合模式、智能体服务的标准化封装，以及借助 DiFY 平台实现数据流程编排、跨系统协同与敏捷运维的探索路径。

主要介绍以下部分：

1. 银行业数据应用的困局与觉醒

2. 数据融合的底层逻辑重构

3. 破解之局：构建新型数据底座

分享嘉宾｜范彬彬 富邦华一银行 大数据研发团队负责人/数据专家

编辑整理｜neil

内容校对｜郭慧敏

出品社区｜DataFun

01

银行业数据应用的困局与觉醒

银行业传统数据具有三个显著特点：

一是数据在采集之后通常会经过整理，以便于业务人员识别使用。数据所对应的概念高度清晰，主要体现在账户名称、客户名称、交易对手、交易金额等字段层面，属于非常明确的字段级表现形式。二是高度依赖历史序列进行对比和管理。银行内部普遍采用账务日期作为切片筛选，所有数据的存放和检索都按照每日维度进行处理，以“规规矩矩”的方式组织。这种结构强调对每日数据的精准对比和稳态管理。三是符合外部监管要求。银行的数据建设在很大程度上是从监管报送需求出发的。监管一方面具有必要性，另一方面具有强制性。随着监管机构陆续发布明确的数据校验规则，监管报送逐渐成为数据建设过程中最容易落地的抓手，也是最常用的切入点。

在数据构成方面，传统银行系统主要保留的是面向业务结果的数据，遵循“数据消费驱动”原则。系统通常仅保留业务最终结果，在经过预设规则清洗之后进行数据存储，形成主题化的数据结构。这些数据主题在数据仓库建设中较为常见，具有显著的业务导向性。

受上述特点影响，传统银行数据体系存在明显局限：

第一，仅能反映事后结果，缺乏对业务过程的记录与支持。第二，过程类数据长期缺失。由于长期重视结果类数据，像审批过程、运营节点、审批流程等信息通常未被记录，也未受到重视。第三，非结构化数据被长期闲置。银行系统中虽保留了大量如影像件、音视频等非结构化数据，但从实际使用角度来看，这些数据基本未被调用和利用，处于闲置状态。

在长期的数据治理和数据资产管理过程中，非结构化数据始终处于被忽视的状态，结构化与非结构化数据之间形成了明显的不平衡。这种失衡主要体现在以下几个方面：

首先是所谓的“三七定律”。银行业长期以来将约 70% 的数据资源结构投入到结构化数据中，而这部分数据也被视为可直接纳入数据资产管理范畴。然而，与之对应的是，这样的结构化数据治理只带来了大约 30% 的业务价值产出。这种投入与产出的不对等，引发了对数据治理机制和性价比的讨论，也使得业务价值的挖掘成为数据治理的必然诉求。

第二个方面是结构化数据对“稳定性”的固守。在数仓一体的架构中，银行通常以“共性主题建模”为核心方法，通过抽取共性度最高的数据内容进行统一加工和复用。这种建模方法本质上要求数据结构保持高度稳定，因为只有在稳定的基础上，数据的使用和交付才是安全的。因此，整个从设计到开发再到测试的流程，都天然地抗拒系统的演进与变化。这种抗拒机制虽然保障了系统的安全性，但也抑制了灵活性与适应能力。

第三，结构化数据存在天然的“封装性”和“滞后性”问题。结构化数据的形成依赖于专家经验对数据的梳理与预处理，其本质是一种“有限集合”的封装操作。这种封装带来的结果是，数据从生产到被消费之间存在明显的周期延迟。周期越长，数据滞后的程度也就越高。这种滞后性在面对非结构化数据时尤为突出，从发现非结构化数据的存在，到真正具备能力进行整合和应用，还存在明显的距离和技术鸿沟。

在业内，非结构化数据常被比喻为“暗物质”，具有广泛的分布与巨大但未被激发的潜力。从数据量来看，在银行等金融机构的典型场景中，每日新增的非结构化数据量约为结构化数据的三倍以上，主要包括系统日志、用户操作行为日志、双录影像、签字影像件等。但在这些数据中，真正被有效利用的仅占十分之一左右，主要集中在RPA、OCR 等规则式、流程式的应用场景中。

长期被忽视的根本原因，在于工具能力尚不具备规模化处理非结构化数据的能力，当前主要面临三方面困境：

第一是特征提取的难度。非结构化数据涵盖音视频、影像、图片、文本等多种形式，而在音视频中常常涉及方言问题，文本中又包含大量行业术语、缩略语、中英文混杂等“行业黑话”，使自然语言处理（NLP）在识别时准确率不高，波动性大，识别效果不稳定。

第二是“幻觉”的生成问题。现有技术难以在非结构化内容与结构化数据之间建立清晰的因果或逻辑关系。例如，一个客户在前期通过电话进行投诉，随后出现资金转出的交易行为，理论上两者存在直接关联。然而在实际处理过程中，很难通过传统数学方法建模或解释该关系。缺乏可解释性，也意味着难以在交易前或交易中介入，无法实现对客户的及时挽留或有效营销。

第三是计算资源的瓶颈。对于中小银行而言，计算资源始终是制约因素。从硬件投入到软件开发与维护，均需要遵循“最低成本、最小必要”的原则。根据现有测算，仅处理一个小时的理财双录视频所需的 GPU 成本就远高于常规处理资源的多个量级，资源消耗巨大。

embedding 模型和大语言模型的能力，将非结构化数据及长时间序列数据转换为数值向量，并通过专业的向量数据库进行存储和检索。通过建立数学关系进行相似度计算，最终回到语义层，才能连接到具体的银行业务场景中。

在实际操作中，非结构化数据的向量化并不以替代原始数据为目的，而是一种技术手段。整个处理过程保留了原始数据和向量数据两个版本，以保障数据完整性。在后续多维分析与处理时，虽然可获得更高表达能力，但复杂度也相应上升。

02

数据融合的底层逻辑重构

在探索结构化与非结构化数据融合的底层逻辑时，整体可分为两个核心部分。第一部分是利用已有的结构化数据，结合尚未充分挖掘的非结构化数据，构建一套融合使用的逻辑体系。非结构化数据的有效使用，关键在于找到其与结构化数据之间的业务关联组件。具体有两个关键点：跨模态实体对齐与实体识别建模。

“跨模态”指不同模态之间的数据转换，通常需要借助图神经网络等学习框架，实现跨源异构数据的采集、处理与清洗。实体识别则涉及到各行业对关键实体的长期积累工作，这也是通用大模型在不同企业或行业落地效果差异显著的根本原因之一。我们通常将实体划分为三个层次：

第一层为核心实体，对应传统主题化设计，如机构信息、客户信息、产品信息、账户信息、交易信息，以及更具体的如交易对手、交易金额、币种等；第二层为业务实体，是在核心实体基础上进一步映射转换的结果，将主题类数据维度化处理，例如将订单抽象客户经理维度、客户维度等指标等；第三层为语义实体，尤其在处理非结构化数据时必不可少。传统数仓架构中，语义部分常为加速使用而被省略；而在融合数据场景中，需要重新构建实体之间的语义关联，尤其涉及客户情绪、外部舆情事件等语义化内容，通过客户号、账户号等关键业务标识建立数据关联。

第二部分是构建本地行业领域级知识库，用于支撑结构化与非结构化知识的融合应用。无论通用模型能力如何演进，企业内部的知识库建设仍需从零开始逐步积累，涵盖术语体系与表达规范。例如，“薪资购汇”与“薪资速汇”在字面上向量距离非常接近，但在银行业务中却是完全不同的产品。又如，一些向量距离较远的术语，可能在业务语义中表达的是同一概念。在智能问答或自然语言转 SQL 场景下，这类术语往往具有行业约定俗成的表达习惯，但在模型向量空间中却不具备对应的语义邻近性。

因此，必须将行业知识库结构化、模板化，并支持通用模型版本升级时的同步更新，包括上传已有知识并重新训练推理流程。这样不仅可将本地知识资产最大程度发挥价值，也能更好地适配并对接主流通用大模型的能力提升。

03

构建新型基础设施

随着结构化与非结构化数据的共同发展，数据治理体系面临融合重构的必要性。整体方法论可分为四个方面：源数据管理、质量评估矩阵、生命周期管理，以及治理体系的价值体系构建。这一体系的设计，已从传统仅涵盖结构化数据的范围，延伸至非结构化数据，强调在全类型数据上统一建立源数据模型，并推进标准化建设。

在质量评估方面，需针对结构化与非结构化数据构建完整的指标体系，保障数据的可用性、准确性与可靠性。为适应不同使用场景，还需建立覆盖冷、温、热存储的数据沉降机制：高频使用的数据被定义为“热数据”，配置于高性能的访问层；而低频访问的数据则自动沉降至冷存储层，如归档文件或备份系统。这类冷数据需满足两项基本要求：访问频率低以及可接受相对较长的数据恢复时间。在新的数据治理架构中，此类策略需重新审视并系统性纳入考量。

此外，数据标准的执行机制也面临调整。银行内部原有的主数据权责划分、标准制定与校验机制，普遍建立于结构化数据之上，流程相对明确。但在非结构化数据扩展之后，从标准制定、校验中检核到落地跟踪，每一环节的协同机制都需重构，原有的数据归属与管理边界亦需重新梳理与认定。

在数据治理体系之外，技术架构的建设同样是关键一环。目前，行内已部署包括 Greenplum（GP）数仓及 Hadoop 大数据平台在内的混合型架构体系。一方面，通过引入 MPP（大规模并行处理）架构，提升并行计算能力，满足高性能计算需求；另一方面，借助存算分离机制，兼顾中小银行在建设成本方面的敏感性与可控性。

存算分离架构具备较高的灵活性：如遇计算资源瓶颈，可单独扩展计算节点；若存储容量不足，也可独立扩展存储资源。行列混合存储进一步优化了读写效率，整体架构在性能与成本之间实现平衡。

为提升大规模数据分析能力，技术栈引入了多类 SDK 与相关工具，旨在减少数据搬运、加快处理效率，尤其在应对文件类非结构化数据场景中，可直接在存储层完成查询与分析操作，降低 I/O 成本，提高响应效率。虽然当前以 T+1 批处理数据为主，即在前一日数据完成清洗与切片后进入使用阶段，确保数据稳定性与可用性，但随着业务对实时性的要求提升，已逐步扩展至 T+0 的实时流数据处理，特别在风控与交易监测等时效性要求高的场景中得到应用。

在数据平台能力方面，亦强调对多模态数据的支持。无论是原始格式的存储，还是结构化后的标准表处理，平台均支持统一的知识建模与编码转换过程。这种设计不仅保留了非结构化数据的原貌，也支持其转换为标准结构化知识体系，极大提升了数据资产的利用效率。平台的数据处理能力亦支撑了多样化的报表加工与分析任务，是数据治理体系中的关键基础能力之一。

在当前银行大数据与大语言模型融合的实践中，需重构三类核心能力的技术底座：其一是传统大数据平台支撑的结构化数据处理能力；其二是大模型驱动的非结构化数据理解与向量化能力；其三则是二者之间的融合机制。该融合的关键在于对已有能力进行标准化封装，使其能以 API 或 agent 形式提供服务，从而在不干扰交易主系统的前提下，实现与客服、信审等核心业务系统的非侵入式集成。

融合的目标是通过智能体的方式，在原有业务系统稳定运行的同时，为客户经理、审批官等角色提供高效的数据服务与智能决策支持。在具体实践中，借助 DiFY 平台展开技术融合探索，主要涵盖三方面能力。

首先，DiFY 提供了较完整的端到端解决方案，集成了通用模型管理、提示词工程（Prompt Engineering）、本地知识库管理、可视化流程编排与 API 接入能力等。其数据封装机制适配银行的多元业务需求，具备较高的通用性和可扩展性。

其次，平台支持以 DataOps 或 DevOps 思维对智能体应用实现敏捷开发与部署，支持迭代调试。例如在财务分析场景中，可将原有管理驾驶舱或财报系统中生成的指标类结构化数据，通过 prompt 和 SQL 编排的方式注入大模型，进而产出贴合管理层关注点的财务摘要。这种跨系统、跨流程的集成方式既保留了业务流程的独立性，也提升了数据驱动的智能水平。

再次，平台支撑多团队协作式开发机制。AI 工程团队可基于智能体开发能力构建服务模块，而业务系统团队则结合场景细节定义需求边界。借助统一的平台实现协同设计与权限管理，在确保合规与安全的前提下，提升数据与智能能力的共享程度，促进跨系统、跨岗位的智能服务整合。

以上就是本次分享的内容，谢谢大家。