从银行角度，大数据的核心使命在于推动运营的智能化决策。

1）数据在物理上的大规模集中

为便于对数据进行整合和归集，数据仓库随之出现。在银行领域，大量数据实现线上化、电子化处理，并通过数据仓库实现大量的物理数据集中。

2）各类主题集市的分分合合

集中之后追求应用各类主题化集市。在建制过程中，某些数据由于其结构、使用或生成的关系而被整合在一起。随着使用的不断深入进行相应的拆分，在不同的实践中形成了各自的最佳路径。

3）追求极致的消费数据——实时流

完成数据归集之后，开始追求消费数据的时效性。通过实时消息订阅，如使用Kafka作为中心化的实时流程，实现对实时数据的利用。

4）跨模态数据分析

如今已经从结构化数据拓展到非结构化数据。借助AI的通用大模型学习能力，并结合传统的机器学习能力，进行跨模态数据分析。

1）数据仓库：知道过去发生了什么

所有的数据完成归集后，真实记录各项数据的最终结果。展示形式是以统计分析为主，通过数据报表进行展示。

2）大数据平台：知道为什么发生

通过构建指标体系或标签体系，从数据管理或数据治理的角度进行延展。

3）大数据2.0：知道未来会发生什么

开始融合机器学习或深度学习算法，进行预测性工作。

4）大数据2.0：知道如何影响未来

初期，为了适应AI的通用性，考虑在数据工程方面可能要做一定程度的妥协。大语言模型本质上是一个概率输出模型，具有不确定性。这种不确定性在文本领域的应用相对更为合适，而数据领域恰恰对确定性有着极高的要求。这种差异在许多项目中，比如智能问数项目中体现得尤为明显，即对数据确定性的要求与AI中概率输出模型的底层逻辑存在差异。

在该阶段，有四个值得思考的议题。

①如何解决多模态数据的融合？

主要体现在结构化数据和非结构化数据之间的整理。

②如何促进AI和Data的深度协同，形成飞轮效应？

一方面已具备自有数据基础，另一方面也拥有本地化部署的大模型与公网通用大模型能力。二者能够在特定层面形成协同，协同的衔接点在于语义层面的匹配，以此高效赋能数据应用、数据治理，助力AI实现更深层次的理解。

③如何提升数据治理工艺，实现数据质量规模化提升？

随着数据管理范围由结构化数据延伸至非结构化数据，同时数据工程逐步向适配AI场景的知识工程转型，数据治理面临全新要求。相关变革不仅涉及技术层面，同样覆盖管理制度、跨部门组织协同，例如企业内部部门职能也需相应调整与升级。

④如何提升数据语义表达，缩短数据到业务的链路？

让AI承接并打通传统从BI到自助分析等各类工具的使用路径。

异构数据类型主要包含结构化数据和非结构化数据。

整体由下至上：从原始明细仓库、明细层，再到汇总层，完成各类共性指标的加工整理，最后到数据的应用。这套传统数据分层模式存在两处短板：

1）该体系更多记录的是数据结果，过程性数据存在缺失；

2）对于非结构化数据的语料或知识层面的内容没有纳入关注范围。

参照传统数仓的分层架构，提出一套与之对应的非结构化数据的数据治理体系。如何在传统软件工程与传统数据体系之间找到一脉相承的逻辑连贯性，是需要思考的点。只有保持技术逻辑连贯统一，才能在方向规划与落地执行层面顺利开展内部沟通，便于全员理解认知。无论是项目预期管控，还是落地最佳实践路径探索，都能找到最佳平衡点，避免缺乏一脉相承的内在逻辑。

1）原始文件层

在原始文件层完成数据接入与采集。例如最典型的主流湖仓一体架构，支持数据以原始结构进行存储，同时依托机器查询及相关技术组件，无需入库解析即可实现数据预览、变更与编辑操作。

2）语料明细层

该层级重要工作是形成数据目录，对标传统CA级数据字典开展目录规整。数据目录形成后，同步完成关键主数据的语义标签梳理。例如在银行提出的数据安全管理办法，其中有按照核心、重要、一般的分级规范（或者四级、五级等等），将数据标识等以标签形式打在元数据上。此类管理方式同样可延伸应用于非结构化数据治理，理论和实践皆行之有效。

3）语料汇总层

该层构建的核心点是语义。无论是初始构建时保证清晰，还是后续为了检索进行增强，这些工作都是为了支撑语义层的使用。与传统结构化数据的逻辑保持一致的是，在理解非结构化数据的语义时，结合具体文件格式（PDF、PPT、TXT）会更直观，比如典型的用户行为日志。

核心技术层面，仍需构建数据血缘体系，其本质是信息图画。对应的技术处理方式，是将全部信息或知识转化为图画，从而完成血缘的构建。在传统数仓的数据血缘架构中，无论采用inmon还是kimbor等不同建模思路，会衍生出星型模型、雪花模型等。其中雪花模型在维度拆分与分层扩展之后，基本不太会形成图示化的链式回路。但在非结构化数据的知识层面，这种链式回路是有可能出现的。而这种情况，会对未来数据的使用、分析，甚至编写代码时调用数据产生一定影响。

4）语料应用层

应使用更好的通用大模型构建。

总结：两套管理体系具备深厚关联，整体思考逻辑一脉相承。事实上非结构化数据相关业务场景一直存在，只是过往长期忽视其建设，在数据存储、加工、传输、应用及权限管控等环节能力相对薄弱，如今依托现有技术条件与落地场景，可对该部分内容开展强化建设与深度挖掘。

随着行业逐步走向数据工程与AI的融合发展，会发现二者落地的过程中缺少对知识工程层面的认知和理解。当前行业普遍提及范式转移的方法，那如何实现结构化、非结构化全量数据的数据工程向知识工程的转移？知识工程建设的前提，是助力AI更好地理解业务内容，也是其存在与发展的根本意义。下文将结合实例，界定数据与知识的边界。

案例：

该知识相比原始的数据更好被AI理解的原因：原始数据信息密度较低，同时存在大量冗余内容。特征工程从事物客观事实出发，在逻辑层面进行提炼总结，融入人类长期沉淀的实践经验。经过加工处理后逻辑更加完整，既可以高度凝练原始信息，又能够对后续业务开展形成预测与指导价值，避免结果偏向概率化输出。而当下Harness工程，本质是对AI施加确定性约束。数据处理并非无序开展，而是依照固定规则进行加工，这类规则正是金融业历经数十年乃至上百年积累形成的行业经验。

另外，现有数据中台已具备实时引擎、即席查询等技术能力，同时依托数据目录、传统指标及标签体系沉淀形成标准化数据资产。当前行业正逐步实现范式转型，由数据中台向知识中台演进，通过知识库建设、知识表示、推理引擎等等，形成AI可高效调用、高可用性的知识中台。

除技术层面问题外，管理层面同样存在诸多问题。结合过往探讨的DataOps理念，引入配套管理方法，历经DevOps、DataOps，逐步发展至当前大模型MLOps全流程体系，整体逻辑与前文思路一脉相承。通过全流程规范化管理体系，构建高质量数据集。

1）知识资产的运营。包括迭代更新，即知识的更新。

2）多模态知识融合。融合如此重要的一个原因在于现状的不可改变或难改变性。无论是在哪家企业工作还是创业，几乎不可能完全从零开始，也不能保证从头开始就不会成为过去的负担。因此，需学会在管理认知和技术方法上与现状相处，接受它，理解它。这样的过程将激发对融合更强烈的渴望，以实现可用性。

3）知识权限管理与质量控制。银行业长期以来都非常强调的是权限管理以及数据质量。

1）知识库规划

在规划层面，重点完成文件资产目录的编排以及解析和采集工作，从源头把控数据。主要是以下两个环节：

①知识采集：采集部分即文件同步预览的处理方式。

②知识资产化：即目录的整理。

2）知识自动化加工

即知识加工或者知识流水线，该过程分为以下两个环节：

①知识标注清洗：也称为数据清洗。

②知识增强：补充QA或者专家的经验。通过预设模板与自定义架构模板，结合大数据分布式计算平台能力，实现策略全流程处理，或者将部分环节交由大模型智能化处理，整体运行效果具备较强可预见性。

3）知识库使用和管理

考虑到有众多不同的用户和机构，必然会有不同的角色和权限，数据管理变得尤为重要。需确保物理和语义层面之间存在严格的对应关系，以防止数据越权问题的发生。主要有以下两个环节：

①知识更新：即文件和QA的对比&更新。

②知识召回：涉及向量化知识的索引、召回范围和排序等问题。

这套体系涵盖了项目设计、管理、开发测试等多个层面，需要大家共同完善。

接下来以银行营销场景为例。

先关注PPT的右下部分，即客户的行为轨迹，这些数据可以通过埋点技术获取。当出现高净值客户流失情况时，可调取该客户过往手机银行操作日志进行分析。以下是该客户的决策路径：

1）客户收到本行短期理财产品到期提醒后，开始查询自身在各家银行的存款情况，并对比多家银行理财产品的预期收益；

2）后续客户进一步关注转账限额相关内容，开始规划资金转出方式与路径；

3）从常识角度可判断，客户正在对比其他金融机构更高利率、更具优惠的产品，并有计划转移资金；

4）期间客户同步咨询转账限额问题，最终完成大额资金转出操作。

该过程并不简单，对于多数银行客户经理而言，存在几方面现实问题：

1）这类原始数据数量庞大、信息密度低，有效内容较为稀疏。

2）客户经理个人的精力有限，客户管理的质量也存在局限。日常还要承担常规工作与业务拓展等各类事务，不可能逐一查看每位客户的零散行为信息，很难依靠这类数据开展存量客户维护工作。

3）目前传统模式下，客户经理仅能查看客户 AUM 规模、账户余额、产品到期情况、转账流水等简单结构化数字信息，仅凭这些数据是远远不够的。

从传统的数据仓库出发，针对主题目录化的客户信息表、交易流程表等主题，无论是模型表、业务表、维度表还是事实表，均可从中抽象出结构化数据的关联关系。这些数据有清晰的标签、业务组件和数据关系。主要优化方向集中在数据时效性层面，按需实现 T+1 或准实时的数据更新，进一步完善数据关联体系。

而另一类非结构化数据，涵盖多渠道客户行为轨迹：包括用户行为向量数据。例如，客户的咨询渠道多元，可发生在手机银行APP、电话客服、线上人工咨询、微信公众号、官方网站以及线下网点等多个场景。

客户在不同渠道咨询的各类问题，往往与其真实行为诉求存在关联。诸如连续浏览汇率、手机银行密码解锁操作、理财产品到期查询、融资咨询、贷款试算等大量原始行为信息，可统一进行意图分类与实体和语义提取。正如前面提到的，通过识别不同信息之间的关系，可以借助通用大模型的技术能力，实现信息间的精准匹配。

基于大模型，结合传统的结构化和非结构化数据，可对单个客户进行深入分析，实现7×24小时不间断分析。分析精度甚至可以下沉到对单个客户，甚至是长尾客户群体。

同时可自动打标签，虽然实现存在一定难度，但具备落地可行性。例如，如果客户获得多笔行业投资利息收入，即可打上投资理财行为活跃标签，在后续推荐产品时可根据这些标签进行筛选。如果客户频繁查看、调整转账限额，即可判定存在大额资金归集或资金转出的潜在需求。

通过整合梳理结构化、非结构化两类数据，完成智能标签沉淀，最终可自动生成客户分析类报告，为业务提供支撑。

最初的设计构想分为两个阶段。

第一阶段是生成具有业务价值性和决策性的标签，并将这些标签提供给客户经理，以引起他们及上级的关注。第二阶段则是实现产品自动推荐。通过自动化流程，结合传统的“千人千面”等方法，进一步提升整体自动化程度。客群越丰富、产品越丰富，这套体系就会形成双飞轮效应；反之，整体应用效果不佳。

当下技术发展日新月异，银行业现阶段的终极目标就是实现一句话银行。

“一句话银行”的核心本质：即提出一个问题之后，它不仅告知答案，还能帮助完成任务。

该目标涉及到智能体和大模型的本质区别。例如元宝、豆包等大模型，初始功能是问答交互。而智能体是在大模型问答能力的基础之上，增加了任务执行能力。只有具备执行任务的能力，才能真正实现“一句话”银行的终极目标。

第一层级为通用互联网大模型产品，例如元宝、豆包、Deepseek等。针对休假相关问题，这类模型仅能输出我国劳动法下的请假休假规则和制度，交互形式为基础问答。

第二层级为本地化大模型结合RAG知识库模式，知识库由企业内部专人维护更新。面对休假问题，除劳动法相关内容外，可进一步精准输出银行内部人事制度，内容范围进一步聚焦企业实际规则，信息精准度更高，本质依旧为问答式交互。

第三层级在本地化大模型 + 企业 RAG 知识库的基础上，叠加大数据能力，所有应用均建立在数据安全与权限隔离的前提下。依托HR系统等个人相关数据，回答休假问题时，可在法规、企业制度之外，同步展示个人专属信息，包含个人剩余假期、本年度休假记录、过往休假情况等，内容更贴合个人实际，使用体验与信息准确性大幅提升。形式上依旧是问答。

第四层级为本地化大模型+大数据+智能体应用。该层级可识别用户真实意图，不再局限于被动问答，当用户询问休假、提出休假相关需求时，经意图确认后，可自主创建请假单、发起符合企业制度的休假申报流程；同时可通过多轮互动追问，补充代理人、假期类型、剩余额度等必要信息，闭环完成完整任务。该模式还可延伸至预订会议室、预订酒店等各类场景。

切换到银行视角，以第四层级下的转账场景为例：采用语音或文字的交互方式，说出或输入 “帮我给张三转 500 块钱”，完整执行流程大致分为五步。

1）意图识别

依托识别能力，抓取用户描述中的核心语义实体：核心行为为转账、收款对象是张三、转账金额为人民币500元。

2）工具查找

在完成实体识别、明确用户意图后，系统匹配可落地执行业务的工具；在MCP工具列表中检索并找到转账工具。MCP可理解为通用协议，是大模型与传统应用之间的通用通讯标准协议，传统各类API接口，均可封装为MCP工具，开放给大模型调用处理业务。通过智能体发起转账调用，和手机银行、柜面等渠道发起转账调用。

3）安全调用

按照规范格式完成安全校验与调用封装，依照约定格式发起请求，保障调用过程安全可控。

4）执行逻辑

将请求发送至业务服务端，运行交易逻辑代码、完成业务执行，完全回归传统系统路由逻辑；服务端不关注请求来源，只需如实记录请求方、交易等相关信息即可。

5）反馈用户

借助大模型优化输出语言风格，向用户反馈处理结果，告知业务办理完成、提供流水号，同步推送转账回单等相关资料。

补充说明：如果调用 API 时存在必填字段缺失，可通过循环交互、主动向用户追问补充信息。例如缺少开户行信息、需确认是否填写转账用途、交易附言等非必填或关键补充字段。

如果能达到以上目标，相当于在传统结构化数据的基础上，结合自身沉淀的技术能力，引入非结构化数据处理方法，整合非结构化数据；同时用外部快速迭代的通用大模型能力与技术框架，最终在具体业务流程与场景中实现落地应用。

Q1：如何平衡业务的快速响应与数据标准统一之间的矛盾？

A1：从整个从业经验上说，落地难度较高。结合自身经验，可行的方式有前置化解决问题或者推动标准化落地，践行行业里所说的安全左移、标准左移理念，把数据标准工作尽量前置。相关方法论已较为成熟，问题归根结底在于企业组织高层是否真正认可数据治理的重要性。刚刚说的方式只能在一定程度上缓解矛盾，缓冲业务快速响应和数据标准统一之间的矛盾，缩减技术栈带来的成本与代价，很难做到没有。

有一个落地效果不错的案例：在新项目建设招标阶段，将数据标准、数据治理的要求明确写入IFP及招标说明书中，将其划定为项目的一部分，包括费用成本和时间成本。按照这套规则，如果项目无法完成数据规范整改，数据字典不能统一遵循既定标准，该项目就无法推进实施。

想要实现这种模式，核心在于组织自上而下的决心与执行意志。如果具备这样的决心和意志，此前提到的业务快速响应与数据标准的矛盾便不会存在，因为不会一味追求业务的快速响应。只要组织内部协同高效，开发与开发、开发与测试、测试与运维，再延伸至研发与业务需求、业务验证等各环节能够高效运转，落实数据标准，其实并不会拖累业务推进速度。归根结底，受历史包袱等现实因素制约，很多时候只能被迫二选一，优先保障业务推进。但从更高的建设要求来看，业务高效发展和数据标准统一完全可以兼顾，只是实现难度相对较大。

Q2：数据治理失败或者停滞常见的早期信号是什么？

A2：早期信号通常表现为对“数据快速”和“项目业务快速响应”的追求。一般而言，当业务响应速度被强调时，大概率意味着没有数据治理的概念。

Q3：如何设计一个合理的数据服务API体系？

A3：目前主要分为两种建设思路：第一种思路近似建模逻辑，自身有什么样的数据，就对外提供什么样的服务；第二种思路以需求为导向，由消费方前置明确自身需要的内容，提出需求之后，我方再按需进行供给。

在两种思路的指引下，收集整合各类业务需求，再进行数据产品设计。设计过程中需要重点考量数据供给效率：比如API实时查询之前，需将API转换成SQL，是否可提前将SQL通过离线指标的方式加工落地，以此提升查询响应速度；同时还要考虑数据范围、是否要分区分表等处理方式。

API服务最终可采用目录化的形式进行展示，也就是行业内早已普及的数据门户概念。数据门户会将各类数据资产统一目录化管理，支持多维度检索。