Page 286 - 《软件学报》2025年第10期
P. 286
李靓果 等: 结合大语言模型和领域知识库的证券规则规约方法 4683
4 案例研究与评估
4.1 案例研究
本节以《深圳证券交易所债券交易规则文档》 为例, 应用本文所提出的方法对该文档进行了规则过滤、需
[1]
求信息抽取、需求可操作化和关系识别等处理, 生成形式化的需求规约. 该文档包含 10 个章节, 详细介绍了深圳
证券交易所债券交易的各项规定, 包括交易参与者的资格标准、不同类型的债券交易流程以及交易操作的基本原
则等内容, 共计 164 条以自然语言描述的业务规则. 表 1 展示了该文档在每个步骤的输出统计信息, 包括规则表示
形式、业务规则数及处理时间等. 下面, 我们对每一步的处理过程和结果进行详细说明.
表 1 深圳证券交易所债券交易规则文档处理统计概览
步骤 规则表示形式 业务规则数 处理时间 (s) 涉及的领域知识数 规则关系数 规约中涉及的业务路径数
业务规则过滤 自然语言 98 3.89 - - -
需求信息抽取 FBR形式 135 约3 000 - - -
需求可操作化 FBR形式 2 308 0.37 28 - -
需求关系识别 FBR形式 2 562 5.46 12 326 2 562
(1) 业务规则过滤. 我们使用微调好的分类模型执行规则过滤任务. 首先, 文档被按句划分为 366 个独立的句
子. 然后, 我们将这些句子逐个输入规则过滤模型进行分类. 分类结果显示, 文档包含 98 条软件需求相关规则、
226 条软件需求无关规则以及 42 条领域知识. 抽取出的 42 条领域知识随后被算法自动整合到领域知识库中, 同
时, 98 条软件需求相关的规则将会进入后续的需求信息抽取步骤. 在这个任务中, 规则过滤主要由过滤模型自动
完成, 无需需求人员的参与, 处理案例文档中的 366 条数据仅耗时 3.89 s.
(2) 需求信息抽取. 我们首先使用 GPT-4 对筛选出的 98 条软件需求相关规则进行预处理. 预处理过程包括结
合上下文对规则进行深入的语义理解, 对规则中的指代、省略等部分进行补全, 以及将描述多个场景的规则拆分
为更小的、仅描述一个交易场景的子规则. 这些步骤能够使规则集合更加精细和具体, 有助于提高后续步骤抽取
的效率和准确性. 经过这一系列的预处理步骤, 我们最终得到了一个包含 135 条子规则的集合, 每条子规则由条件
和结果两部分组成.
基于预处理的结果, 我们使用需求信息抽取模型对每条子规则的条件部分按照预定义的 15 种实体类型进行
需求信息抽取. 对于每条规则, 抽取模型提取其中与需求规约相关的实体, 并赋予其对应的实体类型, 形成若干结
构化的“实体类型-实体”元素对. 这种结构化的数据去除了规则中冗余的部分, 保留了需求规约相关的要素, 提高
了规则的可读性, 也使得规则更加容易被计算机处理和分析. 预处理和需求信息抽取步骤主要通过人工将规则输
入给 GPT-4, 并获取其回答而完成. 对于案例文档的 98 条规则, 与 GPT-4 进行交互并完成整个过程所需时间大约
为 3 000 s.
最后, 规则组装算法对抽取出的实体及其对应的实体类型进行组装, 最终生成了 135 条形式化的需求. 这些需
求不仅展现出高度的形式化和标准化特点, 而且能够清晰地表达出每条需求的语义内容和逻辑关系. 尽管如此, 通
过需求信息抽取得到的需求严格忠于原始文本, 由于需求内部缺乏必要的领域特定约束、需求之间缺乏系统性的
联系等原因, 这些需求尚未形成一个可操作的整体.
(3) 需求可操作化. 我们基于交易概念领域知识对上一步得到的形式化需求进行需求可操作化. 由于每条需求
都隐含着特定的上下文约束, 我们结合领域知识库对全部的 135 条形式化需求进行了必要约束补全, 以确保需求
的完整性和准确性. 在此过程中, 我们将 6 条形式化需求中的抽象表述替换为具体约束. 这一步骤共引入了 28 条
相关的领域知识, 涵盖了交易方式的分类、交易申报的要素等方面. 此外, 我们还处理了 3 条相互嵌套的需求以
及 57 处同属性项组合. 这些被组合的属性项包括时间、数量、价格等与需求紧密相关的约束条件, 每条需求都针
对交易场景的一个特定方面进行了描述, 通过组合形成了完整的约束网络. 在整个需求可操作化阶段, 我们结合领
域知识对所有需求进行处理, 最终得到了 2 308 条经过需求可操作化后的需求. 这些需求包含了描述一个完整交易

