宁波通商银行占探：基于大型语言模型的垂直领域智能数据统计实践

宁波通商银行大数据中心总经理 占探

一、背景意义

在确保数据安全的前提下，降低数据自主分析门槛已成为银行业数字化转型的关键要素之一。而在银行现行体系下，监管报送的数据提取需求被优先考虑，数据驱动业务的灵活分析需求则受到一定程度的忽视和限制。一方面科技人员在应对数据提取任务时需要投入大量的沟通成本，从而导致了数据基建的进程相对缓慢；另一方面科技人员与业务人员间存在技术壁垒，尽管通用化的BI工具在一定程度上缓解了需求压力，但是使用这些工具仍然需要业务人员投入学习成本，通用化的报表也无法完全满足业务对灵活分析的需求。

随着ChatGPT的问世，大型语言模型凭借其强大的逻辑推理、情景联系等特点，迅速成为了NL2SQL领域的新范式。大型语言模型的出现，为降低业务自主数据分析门槛提供了解决方案，通过自然语言交互生成代码逻辑的方式，业务人员能够快速进行数据洞察，灵活实现其定制化需求。此外，科技人员可以将注意力集中在更复杂的场景需求上，进一步提高研发生产效率和代码质量。

二、关键问题

虽然大型语言模型已经在各种NL2SQL的数据集上霸榜，但其在银行业务需求垂直领域落地仍然存在一定的困难，主要表现在以下三方面。

1.在复杂数据查询任务上的表现一般

在Din-SQL的研究文献中表明，这类模型在处理逻辑结构复杂的SQL查询任务时，其性能仍有局限性。具体而言，面对涉及逻辑循环、跨表关联运算以及聚合函数运用等场景时，大型语言模型往往难以正确识别和定位相关表或字段。

2.缺乏具体业务场景知识

银行业务需求包含大量专用术语，简单的表达中往往包含了部分隐性条件。大型语言模型在不了解业务、系统、术语之间关联关系的情况下，无法做到输出精准。

以“银行承兑汇票业务”提出的数据提取分析为例：“筛选出票据系统余额与信贷系统余额不一致的承兑汇票号”。在不了解银行业务术语的情况下，大型语言模型易将逻辑理解成为“票据系统余额不等于信贷系统余额条件下，输出银行承兑汇票号”。而此处信贷系统余额是指承兑汇票的正常本金与逾期本金之和。因此，准确的逻辑对应关系应翻译为：“筛选出票据系统余额不等于正常本金与逾期余额之和的银行承兑汇票号”。此外，在最终生成的SQL代码中，还需判断承兑汇票是否有效限定数据分析范围。类似以上场景，都是大型语言模型在业务系统知识缺乏的情况下无法得出的逻辑。

3.大型语言模型调参成本高

对于中小银行而言，即使使用公有云API或私有云部署服务，垂直领域的预训练依然需要较高的算力资源配置与大量的数据采集过程，面临建设周期长、成效难以迅速体现的困难。

三、解决方案

鉴于上述问题，宁波通商银行借鉴了NL2SQL提示词技术，设计了一种新式流程框架（见图1），该框架利用了大型语言模型的强大功能，并将其与持续集成的知识库和丰富的样例库对接，旨在将复杂的业务需求有效地转化为清晰的语言逻辑表达，进而精准映射为SQL代码，以此为核心不断优化和提升数据服务工作的整体效能。

图1 以大型语言模型为核心生产技术的业务数据服务工作的流程框架

在以上工作流程中，首先将业务需求通过提示词与大型语言模型互动，在无须调参的情况下，得到以自然语言表述的筛选条件。在语言逻辑生成的提示词工程设计上，参考了Din-SQL的解决方法，通过建立业务逻辑知识库模块，在提示词工程中为大型语言模型提供与该业务需求相关的信息，包括与该业务相对应的表字段信息、需额外关联的表信息及关联主键、历史上类似业务场景涵盖的隐性筛选条件等。除了以上提到的业务背景信息外，优化提示词的设计可以在一定程度上提高模型输出的准确性。

针对需要对用户进行解释说明而非直接提供结果的场景，使用CoT技巧能够提高模型的表现。在设计提示词时，可通过引导大型语言模型按清晰的步骤执行输出（见图2）：首先，定位到表和字段，并对它们进行解释说明；其次，拆解需求逻辑，并据此逐点归纳筛选条件及对应的代码（见图3）。

图2 引导语言逻辑生成的提示词

图3 大型语言模型在语言逻辑生成环节下的返回结果

代码生成环节下的提示词工程架构如图4所示。在获取大型语言模型生成的自然语言执行逻辑后，为确保逻辑表达的准确无误，需设立严谨的人工审核步骤。逻辑通过验证后，这些经过校准的语言逻辑实例将被系统性地纳入知识库中，实现知识库内容的动态更新与迭代，进一步形成不断充实与完善的良性循环。

图4 代码生成环节下的提示词工程架构

在完成对业务需求的自然语言逻辑转换后，通过历史收集维护的“逻辑-SQL”键值对应的样例库，为Few-Shot提示词提供素材。在这一步的设计上，结合Dial-SQL的方法论，通过Sentence Transformer工具将语言描述向量化，构建匹配的查询机制，在提示词中自动添加类似“问题-SQL答案”的案例，再嵌入到特定设计的提示词模板之中，进一步提升大型语言模型的输出SQL代码的精准度与稳定性（见图5、图6）。

图5引导SQL生成的提示词

图6大型语言模型在代码生成环节下的返回结果

基于高准确度的数据结果要求，大型语言模型在输出SQL代码后，同样会设置一个人工检核的环节，来确保代码成果的可执行性和准确度。经过审核的代码还将作为新的“逻辑-SQL”匹配样例增添至样例库中。

四、模型优势

1.仅建立提示词工程，不进行预训练

工作流程不进行高成本的垂直领域预训练，而是通过建立与知识库、样例库相连接的提示词工程，引导大型语言模型按照步骤完成代码生成任务，降低了大型语言模型的使用门槛，让算力资源、数据资源有限的中小银行也可利用大型语言模型赋能银行数据服务工作。

2.建立样刊库与知识库的索引机制

通过结合调取样例库、知识库的方式，将与需求相关的业务、系统、表、字段之间的关联关系知识嵌入到提示词中，一定程度上弥补了大型语言模型缺乏垂直领域知识的漏洞。

3.添加语言逻辑的中间步骤

在传统的自然语言问题转换到SQL代码的过程中，加入了语言逻辑的中间层。将隐含了诸多指代的、包含了许多复杂和迭代逻辑的业务需求，拆分至若干个简单的SQL查询逻辑步骤，再通过Few-Shot的提示词工程方法组合，规避了大型语言模型在处理复杂SQL查询问题上容易产生的表与字段关联错误问题。

4.人工审核反馈与知识库相连行程闭环

在业务数据关联知识库的建立上，首先通过对历史数据服务的归纳统计，奠定知识库的结构。在此基础上建立收录与更新该知识库的渠道和方法，在日常的数据服务工作中不断优化、扩充大型语言模型的业务知识，持续提升大型语言模型语言逻辑的精准度。

在代码生成的样例库的维护上，将工作流程中人工审核后的结果与样例库相连接，不断提高样例库相关性，进一步优化通过语言逻辑生成SQL代码的提示词工程质量。

五、应用效果

依据上述框架，宁波通商银行对历史数据提取服务需求进行了测验，针对于一些规模化出现、隐性筛选条件较为单一的案例，大型语言模型表现稳定，在超过半数的测试案例中无须额外的人工介入就可得出正确的SQL代码；但在面对一些历史出现频率不高、隐性筛选条件多样、需要较多表间关联的案例中，大型语言模型则需要人工核验的辅助。

图7为银行贷款业务数据提取服务的应用测试范围。在目前的测试阶段中，大型语言模型在“语言逻辑-代码生成”场景下，已经能够做到“AI取数、人工核验”的数字化实现方式。而在“业务需求-语言逻辑”场景下，虽然仍处在“以人工主导、AI配合学习”的阶段中，但在某些业务逻辑较为直接的任务上，大型语言模型已经能够输出稳定且高质量的SQL代码。

图7 银行贷款业务数据提取服务的应用测试范围

随着日常数据提取任务的累积，这一部分的模型表现会持续提高。当然，业务逻辑知识库和“逻辑-SQL”样例库的搭建和完善并非易事，背后涉及大量语义的梳理和完善，对非结构化数据的治理也提出了较高的要求。

除了基础的业务逻辑知识，隐含的业务惯用表述、行业术语训练也是提升大型语言模型准确度的关键。宁波通商银行从数据全生命周期出发，通过完善系统数据录入控制，建立数据质量检测检核机制，同步搭建知识库存储非结构化数据，记录流程中生成的显性及隐性知识，为大型语言模型的应用奠定坚实的基础。

随着知识库与样例库的不断完善，大型语言模型的生成质量将逐步提高，流程中人工介入的频次也将持续减少，稳步推进银行数据提取服务从“人工实现”到“低代码辅助”，最终向“零代码供数”的数据智能化之路前行。