Page 284 - 《软件学报》2025年第10期

李靓果 等: 结合大语言模型和领域知识库的证券规则规约方法 4681

(2) 抽象需求具体化. 证券业务文档中存在着许多抽象的表达, 需要将这些抽象需求具体化. 这一步骤主要依
赖于领域知识, 将需求中的抽象表述替换成可操作的具体概念, 确保生成可执行的需求. 以上述需求 4.4.4.1 为例,
“竞买预约要素”是一个抽象概念, 要使该条需求可操作, 需要将其替换成具体的竞买预约要素内容. 根据交易概念
知识库中的相关知识“竞买预约要素应当包括以下内容: 竞买方式、证券代码、价格区间、数量、竞买时间等”,
具体化后需求如下. 其中, 突出显示部分是在此步骤中补充的约束.
rule 4.4.4.1
if 交易市场 is “深圳证券交易所” and 交易方式 is “竞买成交” and 交易品种 is “债券” and 时间 is “竞买日前”
and 操作人 is “卖方” and 操作 is “修改” and 操作部分 is “竞买预约要素” and 竞买预约要素 is “竞买方式、证券代
码、价格区间、数量、竞买时间等”
then 结果 is “成功”
(3) 嵌套需求处理. 需求中经常涉及一个需求直接引用或引述另一个需求的情况. 对于这样需求嵌套的情况,
我们将会把该需求及其引用的需求结合起来, 从而使单条需求中包含完整的约束. 例如, 对于规则 3.3.2“本所交易
系统在本规则第 3.1.5 条规定的交易时间内, 接受相应的债券交易申报”, 该规则显式要求与规则 3.1.5 进行组合.
在处理这样的嵌套需求时, 会将需求 3.3.2 和 3.1.5 进行组合, 生成一条新的需求.
(4) 同属性项组合. 需求通常是独立的, 分别描述不同的交易场景, 但也可能出现多条需求都约束同一属性的
情况. 对于这些需求, 我们会将其进行组合, 目的在于识别并整合约束相同属性的需求, 以确保某个字段的完整约
束得以在一条需求中表达. 对于包含相同属性项的两条需求, 若它们描述不同的交易场景, 例如一条需求专门针对
匹配成交, 另一条专门针对竞买成交, 这种情况下需求不应该组合; 相反, 如果两条需求描述相同的交易场景, 那么
它们之间的各项约束不会发生冲突, 因此可以进行组合. 例如, 规则“债券交易的单笔最大申报数量不得超过 100
亿元面额”与规则“债券交易的申报数量应当为 10 万元面额或其整数倍”都包含同一交易场景下关于申报数量的
约束, 两者之间不存在冲突, 因此这两条规则对于申报数量的约束同时有效, 应该将这些约束合并到一条需求中.
通过这种方式, 可以确保相关属性的约束在单一需求中得到完整且一致的表述.
3.3 需求关系识别

我们基于上一步需求可操作化的结果, 结合交易操作序列知识库进行需求间基于语义的和基于操作序列的隐
式依赖关系识别, 并生成数据流形式的规约.
(1) 基于语义的隐式依赖关系识别. 一些业务需求在语义中隐含了与其他需求的依赖关系. 这种关系通常体现
为前置与后置的逻辑关系, 一般使用“在…前”“在…后”“直到”等时间介词表达需求之间的顺序. 这些介词对于理
解和执行需求至关重要, 因为它们指定了事件发生的相对时间顺序. 对于需求信息抽取模型抽取出的每个事件, 我
们会从中提取这些时间介词, 并将其分为前置条件或后置条件分别进行处理.
前置条件是在执行需求之前必须满足的条件. 为了处理前置条件, 我们采用中文自然语言处理工具 HanLP [21]
进行词性标注, 提取事件中的操作、操作人、操作部分, 并将它们写为一条单独的需求, 补充为原需求的前置需
求. 例如, 针对需求“报价方发出报价后, 未成交部分, 可以修改价格和数量等报价要素”, 我们在原始需求前添加一
条前置需求, 其操作人为“报价方”, 操作为“发出”, 操作部分为“报价”, 结果为成功.
后置条件是在执行需求之后必须满足的条件. 为了处理后置条件, 我们采取添加反例需求的方法. 我们通过将
原始需求的结果设置为失败构造了一个反例需求, 用以明确指出在不满足特定条件的情况下, 即在后置条件所规
定的时间点之后执行的需求将不能成功. 例如, 对于需求“在应价方提交有效的应价申报前, 卖方申请并经本所认
可后, 可以撤销竞买发起申报”, 我们会为其补充一条反例需求, 即“在应价方提交有效的应价申报之后, 卖方撤销
竞买发起申报将会失败”.
(2) 基于操作序列的隐式依赖关系识别. 对于一些需求, 尽管隐式依赖关系在其具体描述中并没有直接体现,
但在实际的执行过程中, 这些需求必须遵循要特定的先后依赖关系. 例如, 在证券领域中, 可能会要求先存在一笔