CN114610954A - 信息处理方法及装置、存储介质和电子设备 - Google Patents

信息处理方法及装置、存储介质和电子设备 Download PDF

Info

Publication number
CN114610954A
CN114610954A CN202210225153.0A CN202210225153A CN114610954A CN 114610954 A CN114610954 A CN 114610954A CN 202210225153 A CN202210225153 A CN 202210225153A CN 114610954 A CN114610954 A CN 114610954A
Authority
CN
China
Prior art keywords
rule
graph
sub
pattern
substring
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN202210225153.0A
Other languages
English (en)
Other versions
CN114610954B (zh
Inventor
李维
林天兵
刘郑勇
彭滢
秦海龙
穆啸天
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Shanghai Hongji Information Technology Co Ltd
Original Assignee
Shanghai Hongji Information Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Shanghai Hongji Information Technology Co Ltd filed Critical Shanghai Hongji Information Technology Co Ltd
Priority to CN202210225153.0A priority Critical patent/CN114610954B/zh
Publication of CN114610954A publication Critical patent/CN114610954A/zh
Application granted granted Critical
Publication of CN114610954B publication Critical patent/CN114610954B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90Details of database functions independent of the retrieved data types
    • G06F16/901Indexing; Data structures therefor; Storage structures
    • G06F16/9024Graphs; Linked lists
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90Details of database functions independent of the retrieved data types
    • G06F16/903Querying
    • G06F16/90335Query processing
    • G06F16/90344Query processing by using string matching techniques
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00Handling natural language data
    • G06F40/20Natural language analysis
    • G06F40/205Parsing
    • G06F40/211Syntactic parsing, e.g. based on context-free grammar [CFG] or unification grammars
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00Handling natural language data
    • G06F40/20Natural language analysis
    • G06F40/279Recognition of textual entities
    • G06F40/289Phrasal analysis, e.g. finite state techniques or chunking
    • G06F40/295Named entity recognition

Abstract

本申请提供一种信息处理方法及装置、存储介质和电子设备。信息处理方法包括:获取目标数据对象和所述目标数据对象对应的抽取规则;对所述抽取规则进行分解处理,获得分解后的抽取规则;所述分解后的抽取规则包括:子串模式规则、子图模式规则和自由节点规则中的至少一种规则;获取待处理数据对象对应的解析数据;所述解析数据包括:串数据和图数据;将所述分解后的抽取规则与所述解析数据进行匹配,获得匹配结果;根据所述匹配结果确定所述待处理数据对象中所述目标数据对象的抽取结果。该方法用以增加自然语言规则在业务场景信息抽取任务应用上的灵活性、精准性和鲁棒性,降低培训成本。

Description

信息处理方法及装置、存储介质和电子设备
技术领域
本申请涉及自然语言处理技术领域,具体而言,涉及一种信息处理方法及装置、存储介质和电子设备。
背景技术
自然语言处理,可用于实现文本信息的抽取任务。目前,可通过符号规则系统实现文本信息的抽取任务。
传统的符号规则系统中,可采用两种方式:方式一,编写子串模式的规则代码直接在语言表层序列上实现信息抽取;方式二,先通过Parser(一种图结构解析工具)把语言序列结构化,然后编写子图模式的规则代码在语言结构上实现信息抽取。
上述的方式一,由于缺乏结构条件的约束,精准率难以保证;并且需要编写大量的规则代码。上述的方式二,容易出现错误放大的情况,精准率也存在问题;并且,子图规则需要语言学结构知识,前期对规则编写人员投入的培训成本较高。
发明内容
本申请实施例的目的在于提供一种信息处理方法及装置、存储介质和电子设备,用以增加自然语言规则在业务场景信息抽取任务应用上的灵活性、精准性和鲁棒性,降低培训成本。
第一方面,本申请实施例提供一种信息处理方法,包括:获取目标数据对象和所述目标数据对象对应的抽取规则;对所述抽取规则进行分解处理,获得分解后的抽取规则;所述分解后的抽取规则包括:子串模式规则、子图模式规则和自由节点规则中的至少一种规则;获取待处理数据对象对应的解析数据;所述解析数据包括:串数据和图数据;将所述分解后的抽取规则与所述解析数据进行匹配,获得匹配结果;根据所述匹配结果确定所述待处理数据对象中所述目标数据对象的抽取结果。
与现有技术相比,本申请在获取目标数据对象对应的抽取规则之后,对抽取规则进行分解处理。通过对抽取规则进行分解处理,使得输入的抽取规则的形式不受限制,对于不同的规则编写人员来说,可以根据自己的能力选择输入何种规则,大大降低培训成本,也提高了抽取规则的灵活性。分解后的抽取规则包括:子串模式规则、子图模式规则和自由节点规则中的至少一种规则。将分解后的抽取规则与串数据和图数据进行匹配,则,信息抽取的应用既可以是纯子图模式的匹配,也可以是纯子串模式的匹配,还可以是两种模式的任意叠加或者拼接。因此,该方法允许子串条件与子图条件的耦合使用,是一种更为灵活,且更富有表现力的模式匹配机制,并且最终的结果的精准率也能得到保证。
进而,通过上述的方法,能够增加自然语言规则在业务场景信息抽取任务应用上的灵活性、精准性和鲁棒性,降低培训成本。
作为一种可能的实现方式,所述子串模式规则用于表征词节点之间的线性关系,包括:基于兼容子串模式规则转换得到的子串模式规则、基于包含自由词序的子串模式规则分解得到的子串模式规则、基于图串嫁接模式规则分解得到的子串模式规则、基于图串叠加模式规则分解得到的子串模式规则中的至少一种规则。
在本申请实施例中,子串模式规则可以包括上述的各种子串模式规则中的任意一种规则,提高子串模式规则的灵活性和可解释性,便于规则编写人员编写规则。
作为一种可能的实现方式,所述兼容子串模式规则中,用于表示词节点之间的线性次序的伪码为与子图模式规则兼容的伪码。
在本申请实施例中,兼容子串模式规则中的用于表示词节点之间的线性次序的伪码为与子图模式规则兼容的伪码,提高子串模式与子图模式之间的兼容性,也便于规则编写人员编写规则。
作为一种可能的实现方式,所述包含自由词序的子串模式规则中,词节点之间的线性关系为自由次序;所述包含自由词序的子串模式规则对应的多个分解子串模式规则分别用于表征词节点之间的不同线性关系。
在本申请实施例中,通过包含自由次序的子串模式规则,可以表征词节点之间的不同线性关系,实现不同线性关系的整合,减少规则代码的编写量。
作为一种可能的实现方式,所述子图模式规则用于表征词节点之间的结构关系,包括:兼容子图模式规则、基于图串嫁接模式规则分解得到的子图模式规则、基于图串叠加模式规则分解得到的子图模式规则中的至少一种规则。
在本申请实施例中,子图模式规则可以包括上述的各种子图模式规则中的至少一种规则,提高子图模式规则的灵活性和可解释性,便于规则编写人员编写规则。
作为一种可能的实现方式,所述图串嫁接模式规则中,子串模式和子图模式交错使用;所述图串叠加模式规则中,线性约束和子图约束具有叠加约束关系。
在本申请实施例中,通过图串嫁接模式规则,允许子串模式和子图模式的交错使用。通过图串叠加模式规则,允许线性约束和子图约束具有叠加约束关系。
作为一种可能的实现方式,所述对所述抽取规则进行分解处理,获得分解后的抽取规则,包括:依次识别所述抽取规则中的兼容子图模式规则、兼容子串模式规则、包含自由词序的子串模式规则、图串嫁接模式规则、图串叠加模式规则;将所述兼容子图模式规则确定为子图模式规则;对所述兼容子串模式规则和所述包含自由词序的子串模式规则进行分解,获得子串模式规则;对所述图串嫁接模式规则和所述图串叠加模式规则分别进行分解,获得子串模式规则和子图模式规则;识别所述抽取规则中的自由节点规则进行识别,获得自由节点规则。
在本申请实施例中,通过各种形式的子串模式规则和子图模式规则的识别,实现子串模式规则和子图模式规则的抽取;通过自由节点规则的识别,实现自由节点规则的抽取。
作为一种可能的实现方式,所述分解后的抽取规则包括:子串模式规则、子图模式规则和自由节点规则;所述将所述分解后的抽取规则与所述解析数据进行匹配,获得匹配结果,包括:将所述自由节点规则与所述解析数据进行匹配,获得第一匹配结果;所述第一匹配结果用于表征所述自由节点规则中的必选项是否与所述解析数据匹配成功,若所述自由节点规则中的必选项与所述解析数据匹配成功,代表所述自由节点规则与所述解析数据匹配成功;将所述子串模式规则与所述解析数据进行匹配,获得第二匹配结果;所述第二匹配结果用于表征所述子串模式规则中的必选项是否与所述解析数据匹配成功,若所述子串模式规则中的必选项与所述解析数据匹配成功,代表所述子串模式规则与所述解析数据匹配成功;将所述子图模式规则与所述解析数据进行匹配,获得第三匹配结果;所述第三匹配结果用于表征所述子图模式规则中的必选项是否与所述解析数据匹配成功,若所述子图模式规则中的必选项与所述解析数据匹配成功,代表所述子图模式规则与所述解析数据匹配成功;根据所述第一匹配结果、所述第二匹配结果和所述第三匹配结果确定最终的匹配结果。
在本申请实施例中,通过将各个分解后的规则与解析数据分别进行匹配,并确定分别对应的匹配结果,最后再结合各个匹配结果实现最终的匹配结果的有效确定。
作为一种可能的实现方式,所述自由节点规则包括必选自由节点规则和可选自由节点规则,所述必选自由节点规则允许查询一个不受其他节点约束的节点作为必要条件,所述可选自由条件规则允许查询一个不受其他节点约束的节点作为可选条件。
在本申请实施例中,通过必选自由节点规则,增强规则系统在应用场景抽取信息的概括性和灵活性;通过可选自由节点规则,增强规则系统在应用场景低代码抽取尽可能丰富信息的可维护性。
第二方面,本申请实施例提供一种信息处理装置,包括:用于实现第一方面以及第一方面的任意一种可能的实现方式中所述的信息处理方法的各个功能模块。
第三方面,本申请实施例提供一种电子设备,包括:处理器;与所述处理器通信连接的存储器;所述存储器存储有可被所述处理器执行的指令,所述指令被所述处理器执行,以使所述处理器能够执行如第一方面以及第一方面的任意一种可能的实现方式中所述的信息处理方法。
第四方面,本申请实施例提供一种计算机可读存储介质,所述计算机可读存储介质上存储有计算机程序,所述计算机程序被计算机运行时,执行如第一方面以及第一方面的任意一种可能的实现方式中所述的信息处理方法。
附图说明
为了更清楚地说明本申请实施例的技术方案,下面将对本申请实施例中所需要使用的附图作简单地介绍,应当理解,以下附图仅示出了本申请的某些实施例,因此不应被看作是对范围的限定,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他相关的附图。
图1为本申请实施例提供的基于子图抽取规则的信息抽取流程图;
图2为本申请实施例提供的基于子串抽取规则的信息抽取流程图;
图3为本申请实施例提供的依存图的第一示例图;
图4为本申请实施例提供的信息处理方法的流程图;
图5为本申请实施例提供的分解抽取规则的流程图;
图6为本申请实施例提供的规则匹配的流程图;
图7为本申请实施例提供的依存图的第二示例图;
图8为本申请实施例提供的依存图的第三示例图;
图9为本申请实施例提供的依存图的第四示例图;
图10为本申请实施例提供的信息处理装置的结构示意图;
图11为本申请实施例提供的电子设备的结构示意图。
图标:200-信息处理装置;210-获取模块;220-处理模块;300-电子设备;310-处理器;320-存储器。
具体实施方式
下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行描述。
本申请实施例提供的技术方案可以应用于各种需要信息抽取的应用场景中。例如:从大量的文本中抽取“产品发布”事件;或者抽取其他信息等。
基于信息抽取的应用场景,该技术方案对应的硬件运行环境可以是信息抽取平台,该信息抽取平台的形式可以是:服务器、服务器+客户端、服务器+浏览器等,在本申请实施例中不作限定。
本申请实施例提供的技术方案结合符号规则的线性模式与子图模式两种匹配方式,可以使得规则系统的代码更加鲁棒和灵活,从而加速实现语言解析结构赋能真实场景的信息抽取应用。为了阐明技术方案的技术流程和细节,接下来先对现存的一些背景手段做介绍。
NLP(Natural Language Processing,自然语言处理)符号规则一般要定义一个条件模式,基于该条件模式实现信息抽取的匹配。最基本的条件模式为线性子串模式,其构成的两要素是符号条件和次序条件。另一种条件模式是结构子图模式,其构成的两要素是符号条件和结构条件。NLP中,符号通常指的是词(包括标点和其他特殊符号),符号条件就是词匹配需要满足的条件。
其中,线性子串模式基于子串模式规则实现信息抽取的匹配,子串模式规则用于表征词之间的线性关系。结构子图模式基于子图模式规则实现信息抽取的匹配,子图模式规则用于表征词之间的结构关系。
例如,[xx]的符号条件就是要匹配输入文本中的单词“xx”(软件业称为“直接量”),即匹配带有单词“xx”特征的词。具体的,[human]的符号条件就是匹配带有human特征的词,所以,输入文本中的“服务员”、“工程师”、“张三”、“he”、“Mary”都是满足条件的匹配,叫特征匹配条件,与直接量相对。
在本申请实施例的形式语言机制(formalism)中,作为约定,系统用英文保留字来命名词的特征,例如[human],汉字(无论加引号与否)则表示单词直接量,例如,[火车票]等价于[“火车票”],只匹配“火车票”这个中文单词。如果要匹配英文单词直接量,需,用引号:[“human”]匹配英文单词直接量“human”,而[human]则匹配表示人的单词或短语。
自然语言是非结构化数据,语言文句的线性字符串形式就是非结构化的表示,因此线性子串模式可以直接与字符串匹配。最简单的子串模式规则是软件界常用的正则表达式(regular expression,regex),它以字符(字母、符号或汉字)为符号单位(也叫做节点)做线性模式匹配。NLP中常见的子串模式规则是正则表达式的扩展版,节点从字符符号提升到词符号,就是逐词依序匹配。
例如,输入字符串是“昨天约翰买了新手机”,NLP前处理对它进行分词处理,获得由6个词节点构成的词串:昨天/约翰/买/了/新/手机。系统设计上表示词串通常用一种内部数据结构,例如定义为一个由词节点构成的列表,作为符号NLP系统的数据模型和工作对象。词节点存放解析的基础符号,它表示自然语言的词汇词条(单词或固定成语,包括词典未收录的生词或其他符号)。
每个词节点不仅仅包含有词直接量,而且也包含词的各种属性特征(通过查词典可以得到该词的词典特征,例如“产品”会得到[product]特征),这就为词节点匹配直接量或特征都提供了条件。
下列4元线性模式规则伪码就可以匹配输入字符串的子串(从“约翰”一直匹配到“手机”):输入:昨天<约翰买了新手机>;规则:<[noun][买][]*[noun]>。
其中,<…>是词串线性模式的一种表示,<>标明目标字段子串的左右边界;[直接量]或[feature]是词节点匹配条件;[]表示任何词(没有词条件约束);*与正则一样,表示出现任意次(可有可无);noun(名词)是词类(Part-of-speech,POS)特征。这是NLP系统通过查词典以及早期的词类标注模块为每一个词节点添加的基础特征之一。
特征匹配(例如[verb])比直接量匹配(例如[买])具有概括性,是规则节点泛化的基本手段。特征可以构成特征内部的层级体系,例如本体知识库(如HowNet)里面的概念特征形成上下位特征的链条。NLP符号规则可以检索本体知识库来帮助实现模式匹配中的知识推理,例如,依据本体知识库里面的链条profession→human→animate→life……,可以让词节点条件[human]成功匹配“工程师”,因为“工程师”的词典特征是profession,而profession可以推理是human。词节点匹配的特征概括性以及由此引入的知识库推理能力,是符号NLP平台及其线性规则模式比软件界通用的正则表达式工具强大的一个重要原因。
符号NLP规则系统对于业务场景的信息抽取任务有两种策略:编写子串模式的规则代码直接在语言表层序列上实现信息抽取;两步走,先通过Parser把语言序列结构化,然后编写子图模式的规则代码在语言结构(图结构)上实现信息抽取。
两种方法各有利弊。采用两步走的策略以Parser的结构解析赋能信息抽取,Parser先把文句结构化,信息抽取利用结构子图模式匹配目标数据点实现抽取,其流程图见图1。其中,目标数据点可以理解为应用场景或产品所需要抽取的信息。例如,智能助理场景中的问句理解,对于“订票”的问题,需要抽取的目标数据点包括:日期、出发地、目的地等。
与之对比,在没有Parser的情况下,只需要经过简单的常规前处理(查词典、分词),线性子串规则也可以在语言表层直接匹配实现信息抽取,具体可以如图2所示。
先对图2的信息抽取方式进行分析,下列子串模式规则为匹配机制的抽取规则伪码,可以匹配前面的样例:昨天<约翰买了新手机>。这条线性规则击中三个相关的数据节点,抽取出“购买事件”动作及其该事件中的两个不同的角色“购买者”与“所购物品”。用函数式SetRole(角色)表示相关实体数据点的角色抽取,用SetEvent(事件)表示相关事件动作数据点的抽取。
子串模式规则:<[noun:SetRole(购买者)]?[买|购买:SetEvent(购物)][]*[noun:SetRole(所购物品)]>。
这种子串规则有自己的优点,简单直观、易于编写和调试、培训成本低(会正则的人很快就可以上手)。但也有缺陷:由于缺乏结构条件的约束,精准率可能受到影响,容易带进来噪音,即反例也可能被击中,例如匹配“购买合同”会导致把“合同”抽取出来作为“所购物品”。其他缺点包括:效率低下,缺乏概括性;召回率不佳,代码量高。同样信息的不同变体常常需要编写不同的规则代码才能捕捉。例如,“新手机约翰买了三部”中“手机”是宾语前置,上面的线性规则抽取不了,需要另外编写规则应对变化的句式。
再对图1的信息抽取方式进行分析,其中第一步是Parser的解析。对于Parser,输入是文句,最常用的输出是反映句法结构的依存图,其中的依存链接发生在父节点与子节点之间。例如,前面的例句作为输入,Parser输出的依存图见图3。
在图3中,子节点“昨天”是父节点“买”的状语(Adv);子节点“约翰”是父节点“买”的主语(Subj);子节点“手机”是父节点“买”的宾语(Obj);子节点“了”(表示时体的助词)是父节点“买”的X(X表示其他成分);子节点“新”是父节点“手机”的定语(Mod)。
在Parser建立了依存图以后,下列子图模式规则伪码可以匹配图3样例依存图,通过SVO子图匹配,击中相关的数据点,抽取出“购买事件”的动作及其该事件中的不同角色“购买者”与“所购物品”:
^1[买|购买:SetEvent(购物)]
[^1.Obj=noun:SetRole(所购物品)][^1.Subj=noun:SetRole(购买者)]?
子图模式规则的主要缺陷是“错误放大”:Parser难免出错,会严重影响下游的子图抽取模块的质量。其他的缺陷是技术人员的培训成本:子图规则需要语言学结构知识,编写子图模式规则代码的培训成本很高。
申请人通过对现有的信息抽取方式进行分析,设计出一种新方案,在两种模式上做深度融合的创新,增加NLP在业务场景信息抽取任务应用上的灵活性和鲁棒性,降低规则代码编写的培训成本。
接下来请参照图4,为本申请实施例提供的信息处理方法的流程图,该信息处理方法包括:
步骤110:获取目标数据对象和目标数据对象对应的抽取规则。
步骤120:对抽取规则进行分解处理,获得分解后的抽取规则。分解后的抽取规则包括:子串模式规则、子图模式规则和自由节点规则中的至少一种规则。
步骤130:获取待处理数据对象对应的解析数据。解析数据包括:串数据和图数据。
步骤140:将分解后的抽取规则与解析数据进行匹配,获得匹配结果。
步骤150:根据匹配结果确定待处理数据对象中目标数据对象的抽取结果。
与现有技术相比,本申请在获取目标数据对象对应的抽取规则之后,对抽取规则进行分解处理。通过对抽取规则进行分解处理,使得抽取规则的编写形式不限,对于不同的规则编写人员来说,可以根据自己的能力选择编写何种规则,大大降低培训成本,也提高了抽取规则的灵活性。分解后的抽取规则包括:子串模式规则、子图模式规则和自由节点规则中的至少一种规则。将分解后的抽取规则与串数据和图数据进行匹配,则,信息抽取的应用既可以是纯子图模式的匹配,也可以是纯子串模式的匹配,还可以是两种模式的任意叠加或者拼接。因此,该方法允许子串条件与子图条件的耦合使用,是一种更为灵活,且更富有表现力的模式匹配机制,并且最终的结果的精准率也能得到保证。
进而,通过上述的方法,能够增加自然语言规则在业务场景信息抽取任务应用上的灵活性、概括性、精准性和鲁棒性,降低培训成本。
接下来对该信息处理方法进行详细介绍。
在步骤110中,目标数据对象可以理解为需要抽取的数据对象,例如,前述实施例中介绍的“产品发布”事件,便可以理解为目标数据对象。
目标数据对象对应的抽取规则,可以理解为代码编写人员针对当前待抽取的目标数据对象,所编写的用于匹配的抽取规则。
在本申请实施例中,在NLP符号规则的开发平台上,设计一套新的图串耦合模式规则的形式机制,它是更加灵活与富有表现力的模式匹配形式机制。该机制允许模式匹配同时合法使用子串条件与子图条件,但模式匹配后的结论形式保持不变。在此基础上,本方案对于图串耦合规则采取分解子模式、解释子模式与合并子模式的执行策略,实现图串耦合的鲁棒性目标。
在新机制形式下,抽取规则可以是多个新机制规则中的一种形式,也可以是多种形式的组合。新机制规则包括:兼容子图模式规则、兼容子串模式规则、自由词序模式规则、图串嫁接模式规则、图串叠加模式规则和自由节点规则。接下来分别对这几种新机制规则进行介绍。
为了便于理解下述实施例中的一些规则,在介绍规则之前,先对规则伪码进行介绍,规则伪码可以理解为规则对应的伪代码,是一种规则的表现形式。例如,抽取“产品发布”的事件的结构规则伪码:
^1[发布|推出:SetEvent(产品发布)][^1.Obj=product][^1.Subj=company]?
这是一条典型的依赖主语谓语宾语(主谓宾,即SVO)结构子图的模式规则。词节点前数字^n是该词的编号(ID,也叫指针)。该规则要求从^1号词谓语直接量“发布/推出”出发,根据Parser生成的句子结构,查询^1号词的宾语(^1.Obj)是[product],并且查询^1号词的主语(^1.Subj)是[company],问号与正则(regex)一样表示可选项,就是说主语也可以不出现。如果该子图模式匹配成功,则规则击中目标数据点(即数据匹配上了规则),抽取出了“产品发布”事件。冒号后是结论,此处结论是规则匹配成功后的事件标注动作,用函数式SetEvent(事件名)表示。
在下述规则的实施例中,应当理解,所举例的规则伪码均是一种示例,在其他实施例中,这些规则伪码可以结合具体的应用场景作灵活的变动,不构成对本申请实施例的限制。
第一种规则:兼容子图模式规则,规则模式由词节点序列组成,词节点在规则模式中总是从左至右依序编号。作为一种可选的实施方式,词节点前的前缀可通过伪码“^n(^n[])”表示。那么,第一个节点^1为1号词,以此类推:^1[]^2[]…^n[]。^n是该节点的唯一指针和代表,用于匹配子图模式中父节点与子节点的结构关系。
为了伪码形式的简洁,前缀^n可以省略,但指针仍然以隐藏的方式在模式中依序编号。就是说下面三条SVO(主谓宾)子图规则【1a】、【1b】和【1c】是等价的。
【1a】^1[买|购买]^2[^1.Obj=noun]^3[^1.Subj=noun]//前缀指针全部是显式
【1b】^1[买|购买][^1.Obj=noun][^1.Subj=noun]//部分前缀指针显式
【1c】[买|购买][^1.Obj=noun][^1.Subj=noun]//前缀指针全部是隐式
其中,^1[买|购买]:^1是指当前节点的唯一指针是^1。^2[^1.Obj=noun]中^2是指当前节点的唯一指针是^2,^1.Obj=noun是节点条件,意思是,当前节点是第一个节点的Obj(宾语),且须满足宾语是noun(名词)的条件。
第二种规则:兼容子串模式规则。为了与子图模式规则协调表示,词节点之间的线性次序不再用伪码列表<[]…[]>表示,而是用与子图模式规则兼容的伪码表示,即,兼容子串模式规则中,用于表示词节点之间的线性次序的伪码为与子图模式规则兼容的伪码。
作为一种可选的实施方式,[]--[]表示左右紧邻,[]-*-[]表示二节点间可以有任意多词的间隔,[]-n-[]表示二节点间的最大间隔是n个词节点。例如:下述传统的线性规则伪码【2a】在新的机制中的等价表示为【2b】。
【2a】<[noun][]*5[time][买|购买][]*[noun]>
【2b】[noun]-5-[time]--[买|购买]-*-[noun]
需要说明的是,这种新表示只是为了与没有前后位置的子图模式在同一个机制下耦合做出的形式改变,并不影响模式的逻辑含义。在后续应用该模式规则时,会对模式规则进行分解,分解后的子串模式伪码(如【2b】)会重新转写为现存子串模式伪码(如【2a】),以便调用某个现存的线性规则系统执行。
第三种规则,包含自由次序的子串模式规则,可理解为允许自由次序规则。在这种规则中,允许词节点之间的线性关系是自由次序。
作为一种可选的实施方式,用符号[]~~[]表示自由次序的相邻,用[]~*~[]表示自由次序的二节点间可以有任意多词的间隔,用[]~n~[]表示自由次序的二节点间的最大间隔是n个词节点。例如:下述传统的两条线性规则伪码【3a】与【3b】,在新的机制中可以等价表示为一条规则【3c】。
【3a】<[买|购买][]*5[product]>//例1:他买了台新款产品
【3b】<[product][]*5[买|购买]>//例2:新款产品他买了两部
【3c】[买|购买]~5~[product]//一条规则可以涵盖自由词序,例1和例2
需要说明的是,这种表示减少了代码量,但不改变其内含两条规则的“逻辑或”的含义。在后续应用时,仍然会对规则进行分解,就是说【3c】会分解为两条子串规则【3a】和【3b】,以便调用现存的线性规则系统遵循规则之间为逻辑或关系的常规原则来执行。
第四种规则,图串嫁接模式规则,在这种规则中,允许同一条规则中线性子模式规则与子图模式规则交错使用。例如,考虑到多数中文Parser解析宾语(Obj)比主语(Subj)关系更加可靠,为了让一条SVO规则更加鲁棒,可以用线性次序的子模式来查询可能的主语(Subj)实体,同时用子图模式来查询宾语(Obj)实体,构成一个图串嫁接的耦合模式。
例如,下述的SVO纯子图模式规则【4a】可以引进子串约束[]-5-[],改写为更加鲁棒、泛化的线性子图交错模式规则【4b】。
【4a】[买|购买][^1.Obj=noun][^1.Subj=noun]//纯子图模式SVO规则
【4b】[noun]-5-[买|购买][^2.Obj=noun]//图串嫁接模式规则
需要说明的是,后续在应用时,会将图串嫁接模式规则【4b】分解为两条子规则【4c】与【4d】,其中【4d】进一步自动转写为现存子串模式【4e】,然后分别调用现存的子图系统与线性系统执行,保证两条子规则【4c】与【4e】同时匹配成功才算整体规则匹配成功。
【4c】[买|购买][^1.Obj=noun]//分解后纯子图模式VO规则
【4d】[noun]-5-[买|购买]//分解后纯子串模式规则
【4e】<[noun][]*5[买|购买]>//与【4d】等价的现存纯子串模式规则
第五种规则,图串叠加规则,该规则允许同一条规则中的节点叠加使用线性约束与子图约束,叠加约束是“逻辑与”的关系,就是说,同一节点的两种约束必须同时成立。例如:考虑到Parser解析远距离主语(Subj)关系容易出错,前置宾语也可能出错,可以在查询主语的时候增加一个线性距离n(例如5)的约束,以及在查询宾语的时候排除前置宾语。
例如,下面的SVO纯子图模式规则【5a】与现存纯子串模式【5b】的等价变体【5c】可以叠加,改写为新机制中的图串叠加规则伪码【5d】。
【5a】[^2.Subj=noun]?[买|购买][^2.Obj=noun]//纯子图模式SVO规则
【5b】<[noun]?[]*5[买|购买][]*[noun]>//现存纯子串模式规则
【5c】[noun]?-5-[买|购买]-*-[noun]//与【5b】等价的纯子串规则
【5d】[^2.Subj=noun]?-5-[买|购买]-*-[^2.Obj=noun]//【5a】【5c】图串叠加规则
需要说明的是,在后续应用时,将图串叠加规则【5d】重新分解为两条子规则【5a】与【5c】,其中【5c】进一步自动转写为现存子串模式【5b】,然后分别调用现存的线性系统以及子图系统执行,保证两条子规则【5a】与【5b】同时匹配成功才算整体规则匹配成功。
第六种规则,自由节点规则,作为规则组成成文,呈单节点子模式规则形式。作为一种可选的实施方式,自由节点规则分为两种,必选自由节点规则和可选自由节点规则。
必选自由节点规则,该规则允许查询一个不受其他节点约束(无论线性约束还是结构约束)的节点作为必要条件。作为一种可选的实施方式,该规则的伪码用特别前缀ANYWHERE[…]表示。这一扩展增强了规则系统在应用场景抽取信息的灵活性和鲁棒性。例如,为了抽取作为飞机(实体标签是airplane)的747,把它与数字747区分开来,可以增加一个共现条件ANYWHERE[波音],这样无论“波音”出现在输入的什么位置,系统都可以准确抽取747。
【6a】[747:SetFeature(airplane)]ANYWHERE[波音]//例:波音多年前就推出747了
可选自由节点规则,该规则允许查询一个不受其他节点约束(无论线性约束还是结构约束)的节点作为可选条件。作为一种可选的实施方式,该规则的伪码用特别前缀ANYWHERE[…]?表示。
这一扩展增强了规则系统在应用场景低代码抽取信息的可维护性。对于很多事件的时间、地点等信息点的抽取常常要用到它。因为时间和地点经常以附加语(包括状语、定语)的角色出现在描述事件的句子中,而附加语的特点是随机性强,可能出现也可能不出现,而且出现的位置也很随意,可以在句首、主语前或后、谓语前甚至在句末。可选自由节点的手段用来保证如果数据点附加语出现,系统不会放过对它的信息抽取。例如:
2021年9月14日,xx公司在加州库比提诺宣布推出新款产品系列手机。
xx2021年9月14日在加州库比提诺宣布推出新款产品系列手机。
2021年9月14日在加州库比提诺发布会上,xx宣布推出新款产品系列手机。
Xx公司推出新款产品系列手机是2021年9月14日在加州库比提诺发布会上。
从上面这类句子抽取“产品发布”事件及其角色就可以用下列低代码的规则伪码表示。如果没有可选节点ANYWHERE[…]?,【6b】就需要通过排列组合编写许多规则代码,才有可能把该事件的角色细节抽取完备。
【6b】[发布|推出:SetEvent(产品发布)]
[^1.Obj=product:SetRole(发布产品)][^1.Subj=company:SetRole(发布者)]?
ANYWHER[time:SetRole(发布时间)]?ANYWHER[place:SetRole(发布地点)]
通过上述各个新机制规则的介绍可以看出,新机制规则耦合了子串规则与子图规则,因此,在步骤120中,需要对抽取规则进行分解处理,获得分解后的抽取规则,才能对抽取规则进行准确的应用。
结合前述实施例中的介绍,分解后的抽取规则包括:子串模式规则、子图模式规则和自由节点规则。可以理解,子串模式规则为现存的纯子串模式规则,子图模式规则为现存的纯子图模式规则,具体可以参照前述实施例的介绍。
作为一种可选的实施方式,子串模式规则包括:基于兼容子串模式规则转换得到的子串模式规则、基于包含自由词序的子串模式规则分解得到的子串模式规则、基于图串嫁接模式规则分解得到的子串模式规则、基于图串叠加模式规则分解得到的子串模式规则中的至少一种规则。
作为一种可选的实施方式,子图模式规则包括:兼容子图模式规则、基于图串嫁接模式规则分解得到的子图模式规则、基于图串叠加模式规则分解得到的子图模式规则中的至少一种规则。
作为一种可选的实施方式,步骤120的分解过程可以参见图5所示的流程,在图5中,依次对各个规则进行识别,完成抽取规则的分解。以及,子图子模式理解为子图模式规则下的子规则,多个子规则组成一个整体的子图模式规则,子串子模式同理。
具体的,分解过程可以包括:依次识别抽取规则中的兼容子图模式规则、兼容子串模式规则、包含自由词序的子串模式规则、图串嫁接模式规则、图串叠加模式规则;将兼容子图模式规则确定为子图模式规则;对兼容子串模式规则和包含自由词序的子串模式规则进行分解,获得子串模式规则;对图串嫁接模式规则和图串叠加模式规则分别进行分解,获得子串模式规则和子图模式规则;识别抽取规则中的自由节点规则进行识别,获得自由节点规则。
此外,在识别过程中,当确定出某个规则的类型之后,可以为其设置规则分类标签,最后在输出分解后的抽取规则时,按照规则分类标签将规则输出即可。
在识别兼容子图模式规则时,如果整条规则不是纯子图模式规则形式,则进行兼容子串模式规则的识别;否则,保留纯子图模式规则输出,规则分类标签为“子图子模式”。
在识别兼容子串模式规则时,如果整条规则不包含自由词序,则将兼容子串模式规则转换为现存子串模式输出,规则分类标签为“子串子模式”;否则,进行包含自由词序的子串模式规则的识别与分解。
在一些实施例中,可以通过正则表达式字符串的替换,从形式上将兼容子串模式规则转换为现存子串模式。例如,子串模式伪码【7a】转换为现存子串模式伪码【7b】。
【7a】[human]-5-[time]--[买|购买]-*-[product]
【7b】<[human][]*5[time][买|购买][]*[product]>
通过上述两种模式规则的识别可以看出,本申请实施例的技术方案是现存方案的扩展,完全兼容现存方案的线性规则与结构规则。这为熟练程度不同的规则代码开发人员提供了统一的机制平台,对于刚入门的初级开发人员,他们可以继续开发类似正则的子串模式规则。随着知识的积累和培训的逐步增强,他们可以探索低代码的子图模式规则。最后,熟悉了两种模式以后,学习利用本方案提供的各种图串耦合方式便会很简单。这会大大增强NLP信息抽取落地领域场景的空间和潜力。
在进行包含自由词序的子串模式规则的识别与分解时,如果识别到包含自由词序的子串模式规则,将其进行分解。如果没有识别到,则进行下一步的图串嫁接模式规则的识别。
在分解包含自由词序的子串模式规则时,将该模式规则分解为不含自由词序的n(n>1)条模式的“逻辑或”(OR)输出,规则分类标签为“子串子模式”。例如:伪码【8a】转换为【8b】:
【8a】[买|购买]~5~[product]
【8b】<[买|购买][]*5[product]>OR<[product][]*5[买|购买]>
可以理解,自由词序子串模式规则逻辑上等价于多条线性规则的紧缩形式,有助于低代码规则的编写和维护,因此,对应的分解过程是一个机械转写过程,同样可以利用正则表达式的替换功能实现。
在识别图串嫁接模式规则时,如果未识别到图串嫁接模式规则,则进行下一步的图串叠加模式规则的识别;如果识别到图串嫁接模式规则,则对该图串嫁接模式规则进行分解。
在分解图串嫁接模式规则时,先将图串嫁接模式规则分解为子串模式和子图模式,规则分类标签分别为:“子串子模式”和“子图子模式”。其中,子串模式还需转写为现存子串模式。例如:图串嫁接模式伪码【9】分解为两条子规则模式【9a】与【9b】。
【9】[company:SetRole(公司A)]-3-[money:SetRole(价格)]?-2-[购并|购买:SetEvent(公司购并)][^2.Obj=company:SetRole(公司B)]//例:xx公司日前宣布以2500万美元购买ABC有限公司。
【9a】标签“子图子模式”:
[购并|购买:SetEvent(公司购并)][^1.Obj=company:SetRole(公司B)]
【9b】标签“子串子模式”:
[company:SetRole(公司A)][]*3[money:SetRole(价格)]?[]*2[购并|购买:SetEvent(公司购并)]
可以理解,后续在进行这两种规则的匹配时,会实现原规则所需要的“子模式之间的逻辑与”操作,即:只有所有子模式均匹配,规则才算匹配成功。
在识别图串叠加模式规则时,如果未识别到图串叠加模式规则,则进行下一步的自由节点规则的识别;如果识别到图串叠加模式规则,则对图串叠加模式规则进行分解。
与图串嫁接模式规则的分解过程类似,先将图串叠加模式规则分解为子串模式和子图模式,规则分类标签分别为:“子串子模式”和“子图子模式”。其中,子串模式还需转写为现存子串模式。例如,图串叠加模式伪码【10】分解为两条子规则模式伪码【10a】【10b】。
【10】[^2.Subj=human]-5-[买|购买:SetEvent(购物)]-*-[^2.Obj=product]
【10a】标签“子图子模式”:
[^2.Subj=human][买|购买:SetEvent(购物)][^2.Obj=product]
【10b】标签“子串子模式”:
<[human][]*5[买|购买:SetEvent(购物)][]*[product]>
可以理解,后续在进行这两种规则的匹配时,会实现原规则所需要的“子模式之间的逻辑与”操作,即:只有所有子模式均匹配,规则才算匹配成功。
在进行自由节点规则的识别时,如果未识别到自由节点规则,则规则的分解流程结束;如果识别到自由节点规则,则将其中的自由节点分解出来再输出,分类标签为“ANYWHERE”。例如:
【11a】[发布|推出:SetEvent(产品发布)]
[^1.Obj=product:SetRole(发布产品)][^1.Subj=company:SetRole(发布者)]?
ANYWHER[time:SetRole(发布时间)]?ANYWHER[place:SetRole(发布地点)]?
【11b】标签“ANYWHERE”:
ANYWHER[time:SetRole(发布时间)]?ANYWHER[place:SetRole(发布地点)]?
在步骤130中,获取待处理数据对象对应的解析数据。此处的待处理数据对象可以理解为需要进行信息抽取的数据。在解析数据中,串数据可以理解为具有次序关系的多个词节点。图数据可以理解为通过Parser输出的依存图:依存图包括多个词节点,这多个词节点之间具有结构关系。
对于该步骤,不管是线性词节点列表的获取方式,还是依存图的获取方式,都可以参照本领域成熟的技术,在此不作详细介绍。
在步骤140中,将分解后的抽取规则与解析数据进行匹配,获得匹配结果。
作为一种可选的实施方式,步骤140的匹配过程如图6所示。在图6中,依次将解析数据与自由节点规则、子串模式规则、子图模式规则进行匹配。
作为一种可选的实施方式,分解后的抽取规则中包括必选项,即图6中的必选部分,针对各个分解后的抽取规则,若其中的必选项与解析数据匹配成功,代表该分解后的抽取规则与解析数据匹配成功。即,必选项可以理解为分解后的抽取规则中的指定部分,只有该指定部分与解析数据匹配成功,解析数据才可命中分解后的抽取规则。
在不同的应用场景中,必选项可以不相同,可以是抽取规则中的某一个词,或者两个词之间的关系,或者其他等,可以由规则编写者指定,在此不作一一举例。
具体的,匹配过程可以包括:将自由节点规则与解析数据进行匹配,获得第一匹配结果;第一匹配结果用于表征自由节点规则中的必选项是否与所述解析数据匹配成功,若自由节点规则中的必选项与解析数据匹配成功,代表自由节点规则与所述解析数据匹配成功;将子串模式规则与所述解析数据进行匹配,获得第二匹配结果;第二匹配结果用于表征子串模式规则中的必选项是否与解析数据匹配成功,若子串模式规则中的必选项与解析数据匹配成功,代表子串模式规则与解析数据匹配成功;将子图模式规则与解析数据进行匹配,获得第三匹配结果;第三匹配结果用于表征子图模式规则中的必选项是否与解析数据匹配成功,若子图模式规则中的必选项与解析数据匹配成功,代表子图模式规则与解析数据匹配成功;根据第一匹配结果、第二匹配结果和第三匹配结果确定最终的匹配结果。
其中,如果三个匹配结果均表征对应的必选项与解析数据匹配成功,则代表各个规则均匹配成功,则,目标数据匹配成功,可根据匹配成功的规则确定最终的抽取结果。
可以理解,上述各个子模式规则的匹配顺序不限于图6所示的顺序,在实际应用时,可以对各个子模式规则的匹配顺序作灵活变更。
作为一种可选的实施方式,ANYWHERE子模式(即自由节点规则)的匹配过程包括:从串数据逐词匹配自由节点规则的词节点条件[…],记录匹配结果。如果该自由节点规则中的必选项,没有任何的词节点与之匹配成功,则整个规则匹配失败。
作为一种可选的实施方式,子串子模式的匹配过程包括,从串数据逐词匹配子串子模式限定的线性次序条件。如果子串子模式规则中的必选项,没有任何的词串与之匹配成功,则整个规则匹配失败。如果存在词串与之匹配成功,则子串子规则匹配成功。
作为一种可选的实施方式,子图子模式的匹配过程包括,将各个子图依次与子图子模式规则进行匹配。如果子图子模式规则中的必选项,在内部数据结构依存图中没有任何子图与之匹配成功,则整个规则匹配失败。如果存在依存图与之匹配成功,则子图子规则匹配成功。
最后,如果规则中所有子模式必选项均匹配成功,说明整条规则匹配成功。
进而,在步骤150中,根据匹配结果的内部记录,综合各子模式所匹配的节点,执行规则的所有结论部分。即,将规则的结论部分作为整条规则匹配成功后的抽取结果。
为了便于更清楚的理解本申请实施例所提供的技术方案,接下来介绍两个实例。
实例1
在企业情报领域,一个典型的例子是抽取重要的企业相关的事件,包括产品发布、企业并购、高管变动、股市波动等。以“产品发布”与“企业并购”事件分别为例,其纯结构子图规则伪码如下:
【12】[发布|推出:SetEvent(产品发布)]
[^1.Obj=product:SetRole(发布产品)][^1.Subj=company:SetRole(发布者)]?
【13】[购并|并购|购买:SetEvent(企业并购)]
[^1.Obj=company:SetRole(企业B)][^1.Subj=company:SetRole(企业A)]
上述主谓宾(SVO)规则很容易理解,规则本身蕴含了该类事件的常识,基本上就是根据事件的定义形成SVO的结构:(1)产品发布就是某公司(S)发布(V)某产品(O);(2)企业并购就是公司A(S)并购(V)公司B(O)。如果Parser能够完美解析SVO,这些规则是非常强大有效的。
但实际上,自然语言Parser很难完美,中文的解析更加困难。其结果是,这样的纯结构子图的规则虽然抽取精准率高,但召回率却不高,因为Parser对于SVO的表层变式难以覆盖全。
因此,在子图耦合新机制下,除了兼容纯子图规则外,抽取规则集合还可以兼容纯线性子串规则,以及扩展补充其他图串融合规则。开发者可以根据样例句式数据驱动,在新机制规则编码中做各种图串模式的调整,增强其召回率和鲁棒性。
例如,【12a】是不同词序的纯子串模式,不再依赖SVO,而是利用词序和距离约束(最多相隔5个词),外加节点约束(发布者必须是company,发布产品必须是product),在原始实际数据(例如开发集)上单元测试它们,也能抽取常见的事件表述,并保证较高的精准率。【12b】则是部分利用了子图模式,查找匹配动宾关系(Obj)来抽取事件。但发布者却不再依靠结构关系抽取,而是改成查找自由位置带有company标签的词节点来确定。【13a】与【13b】的扩展也是类似的考量。
数据调查表明,报道产品发布事件的句子里面常有公司省略的情况,而报道公司并购事件的句子却几乎总是同时提到两家公司。这是二者的主要区别,表现在规则伪码上就是“发布者”是可选项[…]?,而“企业A”与“企业B”一样均是必选项。
【12a】[product:SetRole(发布产品)]-5-[company:SetRole(发布者)]?
-5-[发布|推出:SetEvent(产品发布)]
【12b】[发布|推出:SetEvent(产品发布)][^1.Obj=product:SetRole(发布产品)]
ANYWHERE[company:SetRole(发布者)]?
【13a】[company:SetRole(企业A)]-5-[购并|并购|购买:SetEvent(企业并购)]-5-[^1.Obj=company:SetRole(企业B)]
【13b】[购并|并购|购买:SetEvent(企业并购)][^1.Obj=company:SetRole(企业B)]
ANYWHERE[company:SetRole(企业A)]
从原始数据中收集开发集如下,它们是抽取系统的输入处理对象:
[14a]xx公司上周末隆重推出新款产品。
[14b]新款产品发布后立即成为热销产品。
[14c]新款产品不久前由xx公司在秋季发布会上正式推出。
以产品发布事件规则集伪码【12】、【12a】与【12b】为例,根据本方案,规则的分解流程以及对开发集的匹配执行流程如下所述。
【12】与【12a】很简单,前者是纯子图模式规则,后者是纯子串模式规则,都是新机制框架下的现存兼容模式,分别交给现存模式规则的解释器解释执行即可。例如,【12】子图匹配成功,击中开发集样例[14a]:[xx公司]上周末隆重[推出]新款[产品],子图匹配图示见图7与图8。
【12a】的子串匹配则击中开发集样例[14c]“新款/[产品]/不久前/由/[xx公司]/在/秋季/发布会/上/正式/[推出]”。Parser在这样的前置宾语远距离的句式上往往无法正确解析出SVO结构,【12】自然难以奏效,但不依赖SVO结构的模式规则【12a】却能成功抽取。在距离约束与节点特征约束的双重限制下,这样的非结构子串模式规则也可以取得很好的精准率,缺点是纯子串模式开发抽取规则的规则量很大。
【12b】是图串融合规则,其分解解析流程如下。
对于【12b】分解输出的三类子模式分别是:
【12b】[发布|推出:SetEvent(产品发布)][^1.Obj=product:SetRole(发布产品)]
ANYWHERE[company:SetRole(发布者)]?
1.ANYWHERE:ANYWHERE[company:SetRole(发布者)]?
2.子串子模式:(空)
3.子图子模式:[发布|推出:SetEvent(产品发布)][^1.Obj=product:SetRole(发布产品)]
解释程序首先匹配ANYWHERE[company:SetRole(发布者)]?。匹配方式很简单,就是从Tokenlist逐词匹配前缀ANYWHERE后的词节点条件[…],记录匹配结果。
例如,对于开发集样例[14b]“新款产品发布后立即成为热销产品”,可选项匹配失败(company没有出现)。对于样例[14a]“[xx公司]上周末隆重推出新款产品”与样例[14c]“新款产品不久前由[xx公司]在秋季发布会上正式推出”,ANYWHERE子模式均匹配成功,可选项分别击中数据点[xx公司]和[xx公司],系统记录该数据点匹配现场,等规则的所有子模式的必选条件均满足后,执行该数据点的“发布者”角色抽取:SetRole(发布者)。因为ANYWHERE是可选项,无论匹配成功与否,均继续匹配其他子模式。
其中,对于可选项,可以理解为一个规则中除必选项外的其他部分。在一个规则中,必须有必选项;可以有可选项,也可以没有可选项。在必选项的基础上再加上可选项,可以使得规则“搭必选项模式的顺风车”,增加信息抽取的丰富性,从而减少规则的数量。
若不存在子串子模式,解释程序用现存子图模式方式匹配该子图子模式:[发布|推出:SetEvent(产品发布)][^1.Obj=product:SetRole(发布产品)]中的动宾关系匹配击中开发集样例[14a]“xx公司上周末隆重[推出]新款[产品]”与样例[14b]“新款[产品][发布]后立即成为热销产品”,系统记录动宾这两个数据点的匹配现场,等规则的所有子模式均满足必选条件后执行这些数据点的信息抽取:SetEvent(产品发布),SetRole(发布产品)。
该规则中所有子模式必选项均匹配成功的是[14a]与[14b],说明规则模式匹配成功。[14c]虽然成功匹配子模式ANYWHERE[company],击中“Apple”,但后续子模式匹配失败,因此规则失败。对于匹配成功的句子,根据匹配结果的内部记录,综合各子模式所匹配的节点,执行规则的所有结论部分,分别输出[14a]与[14b]抽取结果如下:
样例[14a]抽取结果输出:
产品发布:[推出]
发布者:[xx公司]
发布产品:[产品]
样例[14b]抽取结果输出:
产品发布:[发布]
发布产品:[产品]
可以理解,这组规则中两条规则都击中了样例[14a],抽取结果相同。这是常见的现象,说明不同的规则利用不同子模式约束条件,对于语言现象的涵盖会有交集。召回率的提高往往就是这些有交集的规则捕捉语言现象后的“逻辑或”的总结果。上述规则在开发集中的反例(如下)保持良好的不匹配效果,说明新机制提供的手段在增强鲁棒和召回的同时,可以保障精准率。
反例:
xx市公安局出入境管理局最新推出一批便利举措。
科技部发布国家重点基础研究发展计划。
xx组织发布COVID-19相关儿童多系统炎症综合征治疗指南。
实例2
在金融领域,一个场景是客户要求对招股说明书做财务一致性核对,以便取代人工核对的低效率。业务要求从招股说明书中自动标注四种信息点,并抽取它们的关系,以便与财务报表中的数据一一核对。
这是一个典型的领域NLP应用场景,输入处理对象是中文文本数据(招股说明书),输出的是四类字段及其关系,四类字段是:year,item,money,percent,需要核对的关系包括:Time(财务数据的年度)、ItemMoney(财务科目的钱款数)、ItemUp(财务科目的增长数或增长率),ItemDown(财务科目的减少数或负增长率)等。与很多领域NLP任务一样,该项目只有招股说明书的原始历史文档,没有标注数据。因此,本申请NLP领域落地的图串融合方案是一个合适的应用。
多数Parser对于上述四种目标字段的自动标注已经有很好的支持,直接沿用即可(少数例外现象可以收入领域词典直接匹配处理)。该场景的NLP挑战主要集中在目标字段之间四种关系的抽取上:SetTime(year),SetItemMoney(item),SetItemUp(item),SetItemDown(item)。
输入1:
2020年度收到其他与投资活动有关的现金较上年增加548.83%。
Parser字段抽取输出:
[2020年度:year]收到[其他与投资活动有关的现金:item]较上年增加[548.83%:percent]
Parser的自动结构解析结果如图9所示,图串耦合的关系抽取规则样例如下:
【15】[year]-5-[^3.Subj=item]-5-[增加|增长]--[percent:SetTime(^1),SetItemUp(^2)]
规则成功匹配输入1后的最终关系抽取输出是:
Time(2020年度,548.83%)
ItemUp(其他与投资活动有关的现金,548.83%)
输入2:
2018年度,发行人期间费用较2017年增加2,246.66万元,增幅92.71%,主要系随着发行人融资规模扩大,利息费用增加所致。
Parser字段抽取输出:
[2018年度:year],[发行人期间费用:item]较[2017年:year]]增加[2,246.66万元:money],增幅[92.71%:percent],主要系随着发行人融资规模扩大,利息费用增加所致。
图串融合的关系抽取规则样例如下:
【16】[year]?-5-[^3.Subjitem]-5-[增加|增长]
[^3.Obj=money:SetTime(^1),SetItemUp(^2)]-2-
[增幅]--[percent:SetTime(^1),SetItemUp(^2)]
规则成功匹配输入2后的最终关系抽取输出是:
Time(2018年度,2,246.66万元)
Time(2018年度,92.71%)
ItemUp(发行人期间费用,2,246.66万元)
ItemUp(发行人期间费用,92.71%)
通过这两个实例的介绍以及前述实施例中的介绍,可以看出,本申请的技术方案具有以下优点:
1)图串融合的模式匹配方案为利用Parser的NLP符号规则系统规模化落地各领域场景信息抽取任务建立了包容的平台机制,使得下游抽取规则的开发灵活鲁棒,可以包容Parser的错误。自然语言的复杂使得Parser不可能完善,这是Parser虽然具有巨大的结构赋能潜力却迄今没有大规模落地NLP应用的根本原因。本方案从图串耦合的机制创新及其解释执行的流程创新上为克服这个瓶颈提供了可行的解决办法。
2)图串耦合的模式匹配方案兼容现存的子串模式与子图模式,降低了规则开发人员的培训成本,并且为开发人员的渐进式提升开发技能提供了条件。初级开发人员可以从他们熟悉的正则表达式开始,很快学会被兼容的子串模式立即投入项目开发。中高级人员也可以利用相同的机制平台使用被兼容的低代码子图模式开发。在此基础上,进阶到高效鲁棒的图串耦合规则的开发便成为一个自然的经验实操结果。
3)图串耦合的模式匹配方案既可以利用结构约束,也可以利用线性约束,融合二者,取长补短,为应对复杂的自然语言现象提供了多维度的支持。比起传统的单一机制的规则系统,数据质量(精准率和召回率)以及系统的鲁棒性均可以得到更好的保障。
基于同一发明构思,请参照图10,本申请实施例中还提供一种信息处理装置200,包括获取模块210和处理模块220。
获取模块210用于:获取目标数据对象和所述目标数据对象对应的抽取规则;处理模块220用于:对所述抽取规则进行分解处理,获得分解后的抽取规则;所述分解后的抽取规则包括:子串模式规则、子图模式规则和自由节点规则中的至少一种规则;获取模块210还用于获取待处理数据对象对应的解析数据;所述解析数据包括:串数据和图数据;处理模块220还用于将所述分解后的抽取规则与所述解析数据进行匹配,获得匹配结果;根据所述匹配结果确定所述待处理数据对象中所述目标数据对象的抽取结果。
在本申请实施例中,处理模块220具体用于:依次识别所述抽取规则中的兼容子图模式规则、兼容子串模式规则、包含自由词序的子串模式规则、图串嫁接模式规则、图串叠加模式规则;将所述兼容子图模式规则确定为子图模式规则;对所述兼容子串模式规则和所述包含自由词序的子串模式规则进行分解,获得子串模式规则;对所述图串嫁接模式规则和所述图串叠加模式规则分别进行分解,获得子串模式规则和子图模式规则;识别所述抽取规则中的自由节点规则进行识别,获得自由节点规则。
在本申请实施例中,处理模块220具体用于:将所述自由节点规则与所述解析数据进行匹配,获得第一匹配结果;所述第一匹配结果用于表征所述自由节点规则中的必选项是否与所述解析数据匹配成功,若所述自由节点规则中的必选项与所述解析数据匹配成功,代表所述自由节点规则与所述解析数据匹配成功;将所述子串模式规则与所述解析数据进行匹配,获得第二匹配结果;所述第二匹配结果用于表征所述子串模式规则中的必选项是否与所述解析数据匹配成功,若所述子串模式规则中的必选项与所述解析数据匹配成功,代表所述子串模式规则与所述解析数据匹配成功;将所述子图模式规则与所述解析数据进行匹配,获得第三匹配结果;所述第三匹配结果用于表征所述子图模式规则中的必选项是否与所述解析数据匹配成功,若所述子图模式规则中的必选项与所述解析数据匹配成功,代表所述子图模式规则与所述解析数据匹配成功;根据所述第一匹配结果、所述第二匹配结果和所述第三匹配结果确定最终的匹配结果。
信息处理装置200的各个功能模块与前述的信息处理方法的各个步骤对应,因此,各个功能模块的实施方式参照前述实施例的介绍,在此不再重复介绍。
基于同一发明构思,请参照图11,本申请实施例中还提供一种电子设备300,包括处理器310和存储器320;处理器310和存储器320通信连接,可通过通信线通信连接。该电子设备300可作为前述的信息处理方法的执行主体。
存储器320存储有可被处理器310执行的指令,指令被处理器310执行,以使处理器310能够执行前述实施例中所述的信息处理方法。
本申请实施例提供一种计算机可读存储介质,所述计算机可读存储介质上存储有计算机程序,所述计算机程序被计算机运行时,执行前述实施例中所述的信息处理方法。
在本申请所提供的实施例中,应该理解到,所揭露装置和方法,可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的,例如,所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,又例如,多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口,装置或单元的间接耦合或通信连接,可以是电性,机械或其它的形式。
另外,作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
再者,在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分,也可以是各个模块单独存在,也可以两个或两个以上模块集成形成一个独立的部分。
在本文中,诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来,而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。
以上所述仅为本申请的实施例而已,并不用于限制本申请的保护范围,对于本领域的技术人员来说,本申请可以有各种更改和变化。凡在本申请的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本申请的保护范围之内。

Claims (10)

1.一种信息处理方法,其特征在于,包括:
获取目标数据对象和所述目标数据对象对应的抽取规则;
对所述抽取规则进行分解处理,获得分解后的抽取规则;所述分解后的抽取规则包括:子串模式规则、子图模式规则和自由节点规则中的至少一种规则;
获取待处理数据对象对应的解析数据;所述解析数据包括:串数据和图数据;
将所述分解后的抽取规则与所述解析数据进行匹配,获得匹配结果;
根据所述匹配结果确定所述待处理数据对象中所述目标数据对象的抽取结果。
2.根据权利要求1所述的信息处理方法,其特征在于,所述子串模式规则用于表征词节点之间的线性关系,包括:基于兼容子串模式规则转换得到的子串模式规则、基于包含自由词序的子串模式规则分解得到的子串模式规则、基于图串嫁接模式规则分解得到的子串模式规则、基于图串叠加模式规则分解得到的子串模式规则中的至少一种规则。
3.根据权利要求2所述的信息处理方法,其特征在于,所述兼容子串模式规则中,用于表示词节点之间的线性次序的伪码为与子图模式规则兼容的伪码。
4.根据权利要求2所述的信息处理方法,其特征在于,所述包含自由词序的子串模式规则中,词节点之间的线性关系为自由次序;所述包含自由词序的子串模式规则对应的多个分解子串模式规则分别用于表征词节点之间的不同线性关系,所述多个分解子串模式规则为对包含自由词序的子串模式规则按照不同的线性关系进行分解得到的规则。
5.根据权利要求1所述的信息处理方法,其特征在于,所述子图模式规则用于表征词节点之间的结构关系,包括:兼容子图模式规则、基于图串嫁接模式规则分解得到的子图模式规则、基于图串叠加模式规则分解得到的子图模式规则中的至少一种规则。
6.根据权利要求2或者5所述的信息处理方法,其特征在于,所述图串嫁接模式规则中,子串模式和子图模式交错使用;所述图串叠加模式规则中,线性约束和子图约束具有叠加约束关系。
7.根据权利要求1所述的信息处理方法,其特征在于,所述对所述抽取规则进行分解处理,获得分解后的抽取规则,包括:
依次识别所述抽取规则中的兼容子图模式规则、兼容子串模式规则、包含自由词序的子串模式规则、图串嫁接模式规则、图串叠加模式规则;
将所述兼容子图模式规则确定为子图模式规则;
对所述兼容子串模式规则和所述包含自由词序的子串模式规则进行分解,获得子串模式规则;
对所述图串嫁接模式规则和所述图串叠加模式规则分别进行分解,获得子串模式规则和子图模式规则;
识别所述抽取规则中的自由节点规则进行识别,获得自由节点规则。
8.根据权利要求1所述的信息处理方法,其特征在于,所述分解后的抽取规则包括:子串模式规则、子图模式规则和自由节点规则;所述将所述分解后的抽取规则与所述解析数据进行匹配,获得匹配结果,包括:
将所述自由节点规则与所述解析数据进行匹配,获得第一匹配结果;所述第一匹配结果用于表征所述自由节点规则中的必选项是否与所述解析数据匹配成功,若所述自由节点规则中的必选项与所述解析数据匹配成功,代表所述自由节点规则与所述解析数据匹配成功;
将所述子串模式规则与所述解析数据进行匹配,获得第二匹配结果;所述第二匹配结果用于表征所述子串模式规则中的必选项是否与所述解析数据匹配成功,若所述子串模式规则中的必选项与所述解析数据匹配成功,代表所述子串模式规则与所述解析数据匹配成功;
将所述子图模式规则与所述解析数据进行匹配,获得第三匹配结果;所述第三匹配结果用于表征所述子图模式规则中的必选项是否与所述解析数据匹配成功,若所述子图模式规则中的必选项与所述解析数据匹配成功,代表所述子图模式规则与所述解析数据匹配成功;
根据所述第一匹配结果、所述第二匹配结果和所述第三匹配结果确定最终的匹配结果。
9.根据权利要求1所述的信息处理方法,其特征在于,所述自由节点规则包括必选自由节点规则和可选自由节点规则,所述必选自由节点规则允许查询一个不受其他节点约束的节点作为必要条件,所述可选自由条件规则允许查询一个不受其他节点约束的节点作为可选条件。
10.一种电子设备,其特征在于,包括:处理器;与所述处理器通信连接的存储器;所述存储器存储有可被所述处理器执行的指令,所述指令被所述处理器执行,以使所述处理器能够执行如权利要求1-8任一项所述的信息处理方法。
CN202210225153.0A 2022-03-09 2022-03-09 信息处理方法及装置、存储介质和电子设备 Active CN114610954B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210225153.0A CN114610954B (zh) 2022-03-09 2022-03-09 信息处理方法及装置、存储介质和电子设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210225153.0A CN114610954B (zh) 2022-03-09 2022-03-09 信息处理方法及装置、存储介质和电子设备

Publications (2)

Publication Number Publication Date
CN114610954A true CN114610954A (zh) 2022-06-10
CN114610954B CN114610954B (zh) 2022-11-25

Family

ID=81861143

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210225153.0A Active CN114610954B (zh) 2022-03-09 2022-03-09 信息处理方法及装置、存储介质和电子设备

Country Status (1)

Country Link
CN (1) CN114610954B (zh)

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180121410A1 (en) * 2016-10-28 2018-05-03 Verisign, Inc. Regular expression searching
CN108491385A (zh) * 2018-03-16 2018-09-04 广西师范大学 一种基于依存关系的教学领域本体自动生成方法与装置
CN110147436A (zh) * 2019-03-18 2019-08-20 清华大学 一种基于教育知识图谱与文本的混合自动问答方法
CN110717034A (zh) * 2018-06-26 2020-01-21 杭州海康威视数字技术股份有限公司 一种本体构建方法及装置
CN112541337A (zh) * 2020-12-16 2021-03-23 格美安(北京)信息技术有限公司 一种基于递归神经网络语言模型的文档模板自动生成方法及系统
CN112784578A (zh) * 2021-03-16 2021-05-11 北京华宇元典信息服务有限公司 法律要素提取方法、装置和电子设备
CN113239130A (zh) * 2021-06-18 2021-08-10 广东博维创远科技有限公司 一种基于刑事司法文书的知识图谱的构建方法、装置和电子设备、存储介质
CN113283666A (zh) * 2021-06-10 2021-08-20 中国人民解放军国防科技大学 一种卫星群的启发式智能任务推理与决策方法

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180121410A1 (en) * 2016-10-28 2018-05-03 Verisign, Inc. Regular expression searching
CN108491385A (zh) * 2018-03-16 2018-09-04 广西师范大学 一种基于依存关系的教学领域本体自动生成方法与装置
CN110717034A (zh) * 2018-06-26 2020-01-21 杭州海康威视数字技术股份有限公司 一种本体构建方法及装置
CN110147436A (zh) * 2019-03-18 2019-08-20 清华大学 一种基于教育知识图谱与文本的混合自动问答方法
CN112541337A (zh) * 2020-12-16 2021-03-23 格美安(北京)信息技术有限公司 一种基于递归神经网络语言模型的文档模板自动生成方法及系统
CN112784578A (zh) * 2021-03-16 2021-05-11 北京华宇元典信息服务有限公司 法律要素提取方法、装置和电子设备
CN113283666A (zh) * 2021-06-10 2021-08-20 中国人民解放军国防科技大学 一种卫星群的启发式智能任务推理与决策方法
CN113239130A (zh) * 2021-06-18 2021-08-10 广东博维创远科技有限公司 一种基于刑事司法文书的知识图谱的构建方法、装置和电子设备、存储介质

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
VEENA G 等: "Relation Extraction in Clinical Text using NLP Based Regular Expressions", 《2019 2ND INTERNATIONAL CONFERENCE ON INTELLIGENT COMPUTING, INSTRUMENTATION AND CONTROL TECHNOLOGIES (ICICICT)》 *
王意文: "基于双分解的生物事件抽取", 《中国优秀硕士学位论文全文数据库信息科技辑》 *
郝博: "基于句法模式识别的中文关系抽取方法研究与实现", 《中国优秀硕士学位论文全文数据库信息科技辑》 *

Also Published As

Publication number Publication date
CN114610954B (zh) 2022-11-25

Similar Documents

Publication Publication Date Title
Leopold et al. Supporting process model validation through natural language generation
Sagar et al. Conceptual modeling of natural language functional requirements
Meziane et al. Generating natural language specifications from UML class diagrams
Elbendak et al. Parsed use case descriptions as a basis for object-oriented class model generation
Dima et al. Adapting natural language processing for technical text
US20110099052A1 (en) Automatic checking of expectation-fulfillment schemes
CN103443787A (zh) 用于标识文本关系的系统
Lami QuARS: A tool for analyzing requirements
Humphreys et al. Populating legal ontologies using semantic role labeling
US20200143112A1 (en) Fault-tolerant information extraction
Afreen et al. Generating UML class models from SBVR software requirements specifications
Choi et al. Syntactic and semantic information extraction from NPP procedures utilizing natural language processing integrated with rules
Sonbol et al. A Machine Translation Like Approach to Generate Business Process Model from Textual Description
de Almeida Bordignon et al. Natural language processing in business process identification and modeling: a systematic literature review
Javed et al. iMER: Iterative process of entity relationship and business process model extraction from the requirements
Rajbhoj et al. DizSpec: Digitalization of requirements specification documents to automate traceability and impact analysis
Jurkiewicz et al. Automated events identification in use cases
Nistala et al. Towards digitalization of requirements: generating context-sensitive user stories from diverse specifications
CN114610954B (zh) 信息处理方法及装置、存储介质和电子设备
Ashfaq et al. Natural language ambiguity resolution by intelligent semantic annotation of software requirements
Wiśniewski et al. ReqTagger: A rule-based tagger for automatic Glossary of Terms extraction from ontology requirements
Moeljadi et al. Building cendana: a treebank for informal indonesian
Liu et al. X-IM framework to overcome semantic heterogeneity across XBRL filings
Cybulski Patterns in software requirements reuse
Rajbhoj et al. DocToModel: Automated Authoring of Models from Diverse Requirements Specification Documents

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant