CN115687647A

CN115687647A - Notarization document generation method and device, electronic equipment and storage medium

Info

Publication number: CN115687647A
Application number: CN202211355130.8A
Authority: CN
Inventors: 陈艳; 许静
Original assignee: Faxin Gongzhengyun Xiamen Technology Co ltd
Current assignee: Faxin Gongzhengyun Xiamen Technology Co ltd
Priority date: 2022-11-01
Filing date: 2022-11-01
Publication date: 2023-02-03

Abstract

The embodiment of the application provides a notarization document generation method and device, electronic equipment and a storage medium, and relates to the technical field of text processing. Wherein, the method comprises the following steps: acquiring case information, and constructing a case information map based on the case information; carrying out knowledge fusion on the case information map and the notarization field map to generate a notarization document individual case map; determining parameters in a notarization document template, and searching case information corresponding to the parameters in the notarization document individual case map; and filling the searched case information to the position of the parameter in the notarization document template to generate a notarization document. The embodiment of the application solves the problems that in the related technology, the notarization documents need to be manually written, the efficiency is low, and the stability of the notarization document quality can not be ensured.

Description

Notarization document generation method and device, electronic equipment and storage medium

Technical Field

The present application relates to the field of text processing technologies, and in particular, to a notarization document generation method and apparatus, an electronic device, and a storage medium.

Background

As an embodiment of notary's notary right, notary documents play an extremely important role in judicial activities and daily certification activities. Therefore, it is the most important responsibility of the notarization institution to provide a notarization document with regular form and valid legal content. However, the quality of the manually written notarization documents completely depends on the level of business of notarization personnel and the strict and complete auditing mechanism and auditing capability of notarization organizations. To improve the writing level of notary documents, notary agencies have to invest more resources in training the writing abilities of notary personnel. Even in this case, the stability of the quality of the official document cannot be ensured. This has led to the now-presented notary documents representing the national empowerment force being of varying quality.

Therefore, how to improve the writing efficiency of the notarization documents and stabilize the notarization quality of the notarization documents becomes an urgent problem to be solved.

Disclosure of Invention

Embodiments of the present application provide a notarization document generation method, apparatus, electronic device and storage medium, which can solve the problems of manual writing of notarization documents, low efficiency and unstable quality of issued notarization documents in the related art. The technical scheme is as follows:

according to an aspect of an embodiment of the present application, a notarization document generation method, the method comprising: acquiring case information, and constructing a case information map based on the case information; carrying out knowledge fusion on the case information map and the notarization field map to generate a notarization document individual case map; determining parameters in a notarization document template, and searching case information corresponding to the parameters in the notarization document individual case map; and filling the searched case information to the position of the parameter in the notarization document template to generate a notarization document.

In an exemplary embodiment, the obtaining of case information includes: collecting certification material and/or interview notes; and extracting the case information from the proving materials and/or the interview record.

In an exemplary embodiment, the collection interview transcript includes: inquiring a problem guide strategy tree and determining a current problem node; obtaining a response aiming at the current question node, and searching a first entity matched with the named entity in the response in a question-answer knowledge graph; according to the searched first entity, obtaining an answer aiming at the current question node from the question-answer knowledge graph; receiving a feedback message aiming at the answer, and continuously querying the question guide strategy tree based on the feedback message until the query of the question guide strategy tree is finished; and generating the interview record based on the inquired questions in the question nodes and the corresponding answers and answers.

In an exemplary embodiment, the knowledge fusion of the case information graph and the notarization field graph to generate the notarization document case graph includes: second entity third entity the second entity third entity obtains the second entity in the notarization field map and the third entity in the case information map, and determines the similarity between each second entity and each third entity; determining a correspondence of the second and third entities that are similar based on the determined similarities; and based on the determined corresponding relation, embedding the case information in the case information map into the example layer of the notarization field map to obtain the notarization document individual case map.

In an exemplary embodiment, the embedding case information in the case information map into the case layer of the notarization field map based on the determined corresponding relationship to obtain the notarization document individual case map includes: performing entity alignment and/or coreference resolution on the similar second entity and third entity based on the corresponding relation; and after entity alignment and/or coreference resolution, pointing the second entity chain of the case information map to the third entity corresponding to the notarization field map to obtain the notarization document case map.

In an exemplary embodiment, said finding case information corresponding to said parameter in said notarization document case atlas includes: searching candidate entities matched with the parameters in the notarization document individual case atlas in a regular matching mode; performing entity disambiguation on the candidate entity to obtain a target entity; and inquiring case information matched with the target entity at an example layer of the notarization document individual case atlas as case information corresponding to the parameters.

In an exemplary embodiment, the training set includes case information, historical notarization documents and legal documents referred to by the notarization, and the knowledge graph includes case information graph and notarization field graph; the method further comprises the following steps: constructing the knowledge graph according to the training set; the constructing the knowledge-graph according to the training set comprises: identifying the named entities in the training set to obtain a plurality of named entities; the named entity comprises a second entity in the case information and a third entity in the historical notarization document; extracting the relationship among the named entities by adopting a rule-based relationship extraction algorithm; storing each named entity to each node respectively, and taking the relation between two corresponding named entities as a path for connecting adjacent nodes; and constructing the knowledge graph according to the nodes and the paths.

According to an aspect of an embodiment of the present application, a notary document generation apparatus, the apparatus comprising: the information map building module is used for obtaining case information and building a case information map based on the case information; the knowledge fusion module is used for carrying out knowledge fusion on the case information map and the notarization field map to generate a notarization document individual case map; the case information searching module is used for determining parameters in the notarization document template and searching case information corresponding to the parameters in the notarization document individual case map; and the document generation module is used for filling the searched case information to the position of the parameter in the notarization document template to generate a notarization document.

According to an aspect of an embodiment of the present application, an electronic device includes: at least one processor, at least one memory, and at least one communication bus, wherein the memory has a computer program stored thereon, and the processor reads the computer program in the memory through the communication bus; the computer program, when executed by the processor, implements the notary document generation method as described above.

According to an aspect of an embodiment of the present application, a storage medium has stored thereon a computer program which, when executed by a processor, implements the notary document generation method as described above.

The beneficial effect that technical scheme that this application provided brought is:

in the technical scheme, case information is obtained, and a case information map is constructed based on the case information; carrying out knowledge fusion on the case information map and the notarization field map to generate a notarization document individual case map; determining parameters in a notarization document template, and searching case information corresponding to the parameters from the notarization document individual case map; and replacing the case information to the position of the parameter in the notarization document template to generate the notarization document. Namely, the case information map and the notarization field map are constructed by utilizing the characteristics of the notarization document in a normal form, the case information corresponding to the parameters in the notarization document template is read by inquiring the notarization document individual map after the knowledge is fused, and the case information is filled in the position of the parameters of the notarization document template, so that the notarization document is rapidly and automatically generated, the manual generation of the notarization document is replaced, the stability of the quality of the generated notarization document is ensured, and the problems of low efficiency and unstable quality of the issued notarization document due to manual writing of the notarization document in the related technology can be effectively solved.

Drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings used in the description of the embodiments of the present application will be briefly described below.

FIG. 1 is a schematic illustration of an implementation environment to which the present application is directed;

FIG. 2 is a flow diagram illustrating a notary document generation method in accordance with an exemplary embodiment;

FIG. 3 is a schematic diagram illustrating a case information map, according to an exemplary embodiment;

FIG. 4 is a flowchart illustrating a named entity predictive model training process in accordance with an exemplary embodiment;

FIG. 5 is a flow diagram illustrating a process for building a notary domain graph in accordance with an exemplary embodiment;

FIG. 6 is a flow diagram for one embodiment of step 230 in the corresponding embodiment of FIG. 2;

FIG. 7 is a flowchart of one embodiment of step 235 in the corresponding embodiment of FIG. 5;

FIG. 8 is a schematic diagram illustrating a chain finger process in accordance with an exemplary embodiment;

FIG. 9 is a flow diagram for one embodiment of step 250 in the corresponding embodiment of FIG. 2;

FIG. 10 is a flowchart illustrating a process for obtaining case information in accordance with an exemplary embodiment;

FIG. 11 is a flowchart illustrating a process of collecting interview notes, according to an exemplary embodiment;

FIG. 12 is a flowchart illustrating a construction process of a knowledge-graph of question and answer in accordance with an exemplary embodiment;

FIG. 13 is a schematic diagram of a specific implementation of a notarization document generation method in an application scenario;

FIG. 14 is a block diagram illustrating the structure of a notary document generating device in accordance with an exemplary embodiment;

FIG. 15 is a schematic diagram illustrating the structure of a server in accordance with an exemplary embodiment;

FIG. 16 is a hardware block diagram of an electronic device shown in accordance with an example embodiment.

Detailed Description

Reference will now be made in detail to the embodiments of the present application, examples of which are illustrated in the accompanying drawings, wherein like reference numerals refer to the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary only for explaining the present application and are not construed as limiting the present application.

As used herein, the singular forms "a", "an", "the" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises" and/or "comprising," when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. It will be understood that when an element is referred to as being "connected" or "coupled" to another element, it can be directly connected or coupled to the other element or intervening elements may also be present. Further, "connected" or "coupled" as used herein may include wirelessly connected or wirelessly coupled. As used herein, the term "and/or" includes all or any element and all combinations of one or more of the associated listed items.

As mentioned above, the existing notarization document generation method has the defects that the notarization document is written manually, the efficiency is low, and the quality of the issued notarization document is unstable.

At present, a plurality of notarization affairs can be completed only by relying on the manual and mental operations of notarization personnel; for example, a notary document is written. Writing a notary document is an indispensable task in the daily business of notary, and the notary document refers to process files and result files generated throughout the whole process of notary affairs, including but not limited to interview notes, notification books, acceptance notice books, notarization books and the like. Because of the numerous and complicated notarization affairs, notarization personnel need to put a great deal of effort and repeated labor when writing notarization documents, which undoubtedly causes great waste of human resources.

In addition, notary documents play a vital role in judicial activities and daily certification activities, and especially notarization with specific judicial attestations effectiveness is considered an important category of notary documents. Therefore, it is the most important responsibility of the notarization institution to provide a notarization document with regular form and valid legal content. However, the quality of manually written notarization documents depends completely on the service level of notarization personnel and the strict and complete auditing mechanism and auditing capability of notarization organizations, and the stability of the quality of the notarization documents cannot be ensured. This has led to the now-presented notary documents representing the national empowerment force being of varying quality. To increase the level of writing of notary documents, notary agencies have to devote more resources in training the writing abilities of notary personnel. Even in this case, the stability of the quality of the official document cannot be ensured.

Therefore, if the dependence on manpower is reduced when writing the notary document, the writing of the notary document is intelligentized, so that the efficiency of writing the notary document is greatly improved, the writing quality of the notary document is improved, and the waste of human resources is reduced.

Therefore, the defects that the writing of the notarization documents depends on manpower, the efficiency is low, and the quality of the issued notarization documents is unstable still exist in the related technology.

Therefore, the notarization document generating method provided by the application can automatically generate the notarization document, and avoids relying on manual notarization document writing, so that the notarization document writing efficiency is effectively improved, the notarization quality of the notarization document is fully ensured, and accordingly, the notarization document generating method is suitable for the notarization document generating device which can be deployed in electronic equipment which can be computer equipment configured with a Von Neumann architecture, for example, a desktop computer, a notebook computer, a server and the like.

To make the objects, technical solutions and advantages of the present application more clear, the following detailed description of the embodiments of the present application will be made with reference to the accompanying drawings.

FIG. 1 is a schematic diagram of an implementation environment involved with a notary document generation method. It should be noted that this implementation environment is only one example adapted to the present invention and should not be considered as providing any limitation to the scope of use of the present invention.

The implementation environment includes a collection side 110 and a server side 130.

Specifically, the collection terminal 110 may be an electronic device having a function of collecting at least one or more data of pictures, texts, and multimedia, and is not limited in this respect.

The server 130 may be an electronic device such as a desktop computer, a notebook computer, a tablet computer, a server, or the like, or may be a computer device cluster formed by a plurality of servers, or even a cloud computing center formed by a plurality of servers. The server 130 is configured to provide a background service, for example, the background service includes, but is not limited to, a notarization document generation service, and the like.

The server 130 and the collection terminal 110 are connected in advance through wired or wireless network communication, and data transmission between the server 130 and the collection terminal 110 is realized through the network communication connection. The data transmitted includes, but is not limited to: case information, etc.

Through the interaction between the acquisition end 110 and the server 130, the acquisition end 110 acquires case information from the certification materials and/or the interview notes and sends the case information to the server 130, and the server 130 processes the acquired case information by combining the knowledge graph, so that the notarization document template can be converted into the formal text of the notarization document.

Of course, the collection end 110 and the server 130 may be integrated in the same server according to the actual operation requirement, so that the generation of the notarization document is completed by the same server, which is not limited herein.

Referring to fig. 2, an embodiment of the present application provides a method for generating a notary document. The method is applicable to an electronic device, which may be specifically a computer device, for example.

In the following method embodiments, for convenience of description, the main execution subject of each step of the method is taken as an electronic device for illustration, but the method is not particularly limited to this configuration.

As shown in fig. 2, the method may include the steps of:

step 210, obtaining case information, and constructing a case information map based on the case information.

The case information refers to information related to notarization affairs such as certification materials and interview notes provided by the parties. That is, in one possible implementation, case information may come from the certification material, as well as from interview notes.

Taking the notarization affair of 'house buying and selling contract notarization' as an example, the principal provides certification materials including identity certification and house ownership certification, so that the notarization party obtains case information such as principal identity information and house information from the certification materials.

After the case information is obtained, the case information can be used as a training set to construct a case information map. In other words, the case information map is constructed based on case information of the individual case, namely, the case information of the individual case is stored in the case information map.

In a possible implementation manner, the case information graph building process may include the following steps: identifying named entities in case information to obtain a plurality of second entities; extracting to obtain the relationship between the second entities by adopting a rule-based relationship extraction algorithm; respectively storing each second entity to a node, and constructing a path between corresponding nodes based on the relationship between the named entities; and constructing a case information map according to each node and each path. The named entity identification may be implemented by a rule-based method, an unsupervised learning method, a supervised learning method, a deep learning method, and the like, which is not limited herein. Besides the rule-based relationship extraction algorithm, the relationship between the second entities may also be implemented by a predefined relationship type, deep learning, and the like, which is not specifically limited herein. Fig. 3 is a schematic diagram illustrating a case information map, in fig. 3, a party a XXX and a party b YYY provide certification materials such as identification (name, ID card No.) including their own identity information and house information (property, location) for house transfer with house a, respectively, and a case information map constructed based on the certification materials includes a plurality of nodes through which case information such as owner information and house information before and after house transfer is stored in a KEY-VALUE manner.

And step 230, carrying out knowledge fusion on the case information map and the notarization field map to generate a notarization document individual case map.

As described above, the case information graph is constructed by a plurality of nodes and paths, the nodes are used for storing named entities in the case information, and the paths are used for storing relationships among the named entities in the case information. Similarly, the notarization field knowledge map is composed of a plurality of nodes and paths, the nodes are used for storing the historical notarization documents and named entities in the legal documents related to the notarization, and the paths are used for storing the relationships among the named entities in the historical notarization documents and the legal documents related to the notarization.

In a possible implementation manner, the process of constructing the notarization field atlas may include the following steps: identifying named entities in historical notarization documents and legal documents related to the notarization to obtain a plurality of third entities; extracting to obtain relationships among a plurality of third entities by adopting a rule-based relationship extraction algorithm; respectively storing each third entity to the nodes, and constructing paths among the corresponding nodes based on the relationship among the third entities; and constructing a notarization field map according to each node and each path. The named entity identification may be implemented by a rule-based method, an unsupervised learning method, a supervised learning method, a deep learning method, and the like, which is not limited herein. Besides the rule-based relationship extraction algorithm, the relationship between the third entities may also be implemented by a predefined relationship type, deep learning, and the like, which are not specifically limited herein.

The following describes the construction process of the notarization field map in detail with reference to fig. 4 to 5:

in one possible implementation, named entity recognition is implemented by invoking a deep learning based named entity prediction model. The named entity prediction model is obtained by training a neural network model, and the specific training process is shown in fig. 4.

Step 301, obtaining historical notarization documents and legal documents related to the notarization.

Wherein, the historical notarization documents include but are not limited to: unstructured data acquired from notary paper roll documents by Optical Character Recognition (OCR) techniques, and structured data acquired from notary service platform databases.

Step 303, a corpus is constructed.

Specifically, unstructured data acquired by the OCR technology are converted into structured data, and a corpus is formed by combining the structured data in a notarization service platform database.

And 305, generating a notarization text after marking according to the marking rule.

Specifically, a labeling rule is configured to label the historical notarization documents in the corpus and the legal documents related to the notarization based on the labeling rule, so as to generate a notarization text after labeling. It should be noted that the labeling rules are configured according to notarization-related laws (such as civil court ceremony), regulations, judicial interpretation, and the like.

The labeling rule may be a BIO labeling rule (B-prefix of named entity, I-non-prefix of named entity, O-non-named entity), or a BIO labeling rule (B-prefix of named entity, I-non-prefix of named entity, O-non-named entity, E-suffix of named entity, S-independent word), etc., which is not limited herein. Taking the BIO labeling rule as an example, if the house belongs to Jia, it is labeled "B (the) I (house) O (in) B (Jia) I (some)".

And 307, performing single-hot coding on the marked notarization text, and inputting the notarization text into an embedding layer.

Specifically, the notarization text after being marked is subjected to one-hot coding to obtain one-hot vectors, and then the one-hot vectors are converted into character vectors through a character embedding matrix embedded into an embedding layer.

Step 309, inputting the character vector into the BilSTM module.

Specifically, the character vector is used as the input of a bidirectional long-short-time memory BilSTM module so as to start the training of the BilSTM model.

And 311, processing various labeling scores output by the BilSTM module, and inputting the processed labeling scores into a CRF module to obtain a named entity prediction model with initialized parameters.

Specifically, after various marking scores output by the BilSTM module are processed, the marking scores are firstly input into a CRF module; and then obtaining an optimal solution of a tagging sequence output by the BilSTM module through the CRF module according to the relation between adjacent part-of-speech tags, namely obtaining a parameter-initialized named entity prediction model.

And 313, carrying out hyper-parameter optimization to obtain a named entity prediction model.

Specifically, in the training of the BilSTM-CRF model, a drop-drop technique is adopted, namely a part of neurons are randomly dropped during each training, and the dropped neurons do not influence propagation, so that the network does not depend on a neuron weight change method too much to adjust parameters, and the overfitting problem is relieved.

And collecting and storing the optimal parameters obtained by each training, and packaging the BiLSTM-CRF model passing the test into a named entity prediction model.

After the training process is completed, the named entity prediction model has the named entity recognition capability suitable for the historical notarization documents, so that named entity recognition can be performed on the historical notarization documents to obtain a third entity in the historical notarization documents, and a notarization field map is constructed. As shown in fig. 5, in one possible implementation, the process of constructing the notary domain graph may include the following steps:

and 331, acquiring the historical notarization documents and the legal documents related to the notarization, and performing named entity identification on the historical notarization documents and the legal documents related to the notarization to obtain a plurality of named entities.

As mentioned above, the named entity recognition can be performed on the historical notarization documents in the corpus by methods such as rule-based, unsupervised learning, supervised learning and deep learning, and the obtained recognition results are a plurality of named entities.

In one possible implementation, the named entities in the historical notarization document are identified by invoking the named entity prediction model trained in step 313 to obtain a number of named entities.

It should be noted that, in other embodiments, the named entities may also be obtained by using a notary entity dictionary to perform word segmentation on the historical notary documents in the corpus. The notarization entity dictionary is constructed in advance by carrying out named entity recognition on the historical notarization documents in the corpus through the named entity prediction model obtained by training in the step 313. Similarly, the notary legal dictionary may also perform named entity recognition on notary-related legal documents (e.g., "national common and national common practice rules of the people's republic of China") through the named entity prediction model, and perform word segmentation on notary-related legal documents by using the notary legal dictionary to obtain a plurality of named entities with association to be extracted.

And 333, extracting the relationship among the named entities by adopting a rule-based relationship extraction algorithm.

First, a number of named entities are part-of-speech tagged by NLP (Natural Language Processing) text tagging tools (e.g., doccano part-of-speech tagging tools). Furthermore, the named entities are subjected to part-of-speech tagging according to tagging rules set by notarization-related laws and regulations, judicial interpretation and the like.

Then, the "national official certification comprehensive management information system technical code" is used to configure the "relationship extraction rule", as shown in table 1.

Table 1 relationship extraction rules

And finally, based on the relation extraction rule, extracting the relation among the named entities with part of speech tagging by using a pattern matching method. The pattern matching is a basic operation of character strings in a data structure, and at least one substring which is the same as the substring is required to be found in a certain character string given one substring. For example, as shown in table 1, if a substring "belongs" is given, and if the substring "belongs" exists in a character string formed by a plurality of named entities which are part-of-speech labeled in a historical notarization document, the relationship among the plurality of named entities is considered as a dependency relationship.

Step 335, storing each named entity to each node, and constructing a path between corresponding nodes based on the relationship between each named entity.

First, it is explained that the notarization field knowledge graph includes nodes and paths, where the nodes are used to store named entities and attribute information of the named entities, such as format attributes, and the paths are used to connect corresponding nodes having relationships, and store relationships between corresponding nodes (i.e. corresponding to two named entities), such as "belong to" and "yes".

When there is a relationship between the two corresponding nodes, a path may be constructed based on the relationship, and the two corresponding nodes may be connected. For example, the relationship between the named entities "plum" and "house" is that the house belongs to plum, and a path is constructed for both, resulting in "plum < - > -belong to-house".

And 337, constructing a notarization field knowledge graph according to each node and each path.

After the relationship among the nodes is extracted, a path can be constructed for each node based on the relationship, and then the corresponding two nodes are connected through the path to obtain the notarization field knowledge map. In one possible implementation, the notary domain knowledge graph is represented by a Neo4j graph database, so that named entities and associations are stored and displayed in the Neo4j graph database, and the method is not limited herein.

Thus, the construction of the notarization field atlas is completed.

Similarly, the construction process of the case information map is basically the same as that of the notarization field knowledge map, and the difference lies in the training set, the training set of the case information map is the case information, and the training set of the notarization field knowledge map is the historical notarization document and the legal document related to the notarization, which are not repeated here.

After the case information map and the notarization field knowledge map are obtained, the construction of the notarization document individual case map can be further carried out. The notarization document individual case map is a notarization document map fused with case information of individual cases, namely, the case information aiming at individual cases, a notarization document entity suitable for individual cases and a relation between the case information and the notarization document entity suitable for individual cases are stored in the notarization document individual case map, in other words, the notarization document individual case map is suitable for specific individual cases.

The inventor realizes that the knowledge graph usually comprises a certain abstract layer knowledge and a large amount of example layer knowledge, and based on the knowledge graph, the case information graph can be embedded into the example layer of the notarization field graph in a knowledge fusion mode, so that the notarization document individual case graph is formed.

As shown in fig. 6, in one possible implementation, step 230 may include the following steps:

step 231, obtaining second entities in case information maps and third entities in notarization field maps, and determining similarity between each second entity and each third entity.

Wherein, the process of determining the similarity comprises the following steps: and performing word vectorization on the second entity and the third entity, and calculating the vector distance between the second entity and the third entity, so that the similarity between the second entity and the third entity is determined according to the vector distance between the second entity and the third entity. It should be understood that the smaller the vector distance, the more similar the second entity is to the third entity.

Step 233, determining a corresponding relationship between the similar second entity and the third entity based on the determined similarity.

In a possible implementation manner, the correspondence between the second entity and the third entity may refer to the same correspondence, or may refer to a correspondence existing in the upper and lower layer concepts. For example, if the second entity is a policy housing and the third entity is real estate, the second entity and the third entity have a corresponding relationship between upper and lower concepts.

And 235, embedding the case information in the case information map into an example layer of a notarization field map based on the determined corresponding relation to obtain a notarization document individual case map.

Specifically, as shown in fig. 7, in one possible implementation, step 235 may include the steps of:

step 2351, based on the corresponding relation, performing entity alignment and/or coreference resolution on the similar second entity and third entity;

similar entities in different knowledge maps are processed based on the corresponding relation between the entities, so that the processing process can be more accurate, and the quality of the document generation is improved.

Specifically, whether the corresponding relationship between the second entity and the third entity is the same is determined.

And aiming at the second entity and the third entity with the same corresponding relation, fusing the second entity and the third entity in an entity alignment mode.

For example, if the second entity and the third entity are both "buyer", "seller", "inheritor" and "adobe", the second entity and the third entity are merged by means of entity alignment. Namely, the entities in different knowledge maps are named as buyer, seller, inheritor and inheritor.

And aiming at the second entity and the third entity of which the corresponding relation has the upper and lower layer concepts, fusing the second entity and the third entity in a coreference resolution mode.

For example, if the second entity is "buyer" or "seller", and the third entity is "first party XXX" or "second party YYY", the second entity and the third entity are merged by means of coreference resolution. That is, the entities in the different knowledge-graphs may all be named "buyer" and "seller". That is, coreference resolution refers to removing any one of the second entity and the third entity that have correspondence between the upper and lower layer concepts. In one possible implementation, the coreference resolution refers to removing a lower-layer concept entity from two entities in correspondence with the upper-layer and lower-layer concepts, and retaining the upper-layer concept entity.

Step 2353, after entity alignment and/or coreference resolution, the second entity chain of the case information map is directed to a third entity corresponding to the notarization field map to obtain the notarization document individual case map.

The link refers to establishing a link pointing relationship between a second entity of the case information map and a third entity corresponding to the notarization field map.

As shown in fig. 8, the third entity is "buyer" and "seller", the second entity is "first party XXX" and "second party YYY", a link direction relationship (represented by arrow 701) is established between the second entity "XXX" and the third entity "seller", and a link direction relationship (represented by arrow 702) is established between the second entity "yyyy" and the third entity "buyer".

Thus, the construction of the notarization document individual case map is completed.

And step 250, determining parameters in the notarization document template, and searching case information corresponding to the parameters in the notarization document individual case map.

First, the notary document template is determined based on user selection. In one possible implementation, the user may be a notary who needs to generate a notarization document by operation.

The notarization document template is from a plurality of notarization document templates stored in advance. The notary document template can be made manually or generated automatically.

On one hand, the notarization document template is manually manufactured, a notarization worker is required to collect various typical notarization documents as template samples, case information in the notarization documents is manually identified and identified based on the notarization field experience, the case information is replaced through parameters, corresponding verification rules are configured for the parameters, and therefore the notarization document template is formed.

On the other hand, a notarization document template is automatically generated, a named entity prediction model is required to be built, a list of case information to be filled is required to be formulated, so that entities in the notarization document sample are identified by the named entity prediction model, and whether the identified entities meet the replacement rule corresponding to the list of the case information to be filled is judged; and if the notarization document template accords with the replacement rule, replacing the entity in the notarization document sample document with the parameter, and configuring the verification rule corresponding to the parameter, thereby forming the notarization document template.

Based on the process, the notarization document template with the replaceable parameters can be generated, so that the notarization document can be automatically written better, and the normalization and the reliability of the document format are ensured.

It should be understood that the notary document template and the notary document differ in that the parameters in the notary document template correspond to case information in the notary document. Then, in order to generate the notarization document, it is essential that the parameters in the notarization document template are replaced with case information. Based on this, before generating the notarization document, case information capable of replacing parameters in the notarization document template needs to be obtained.

Specifically, as shown in fig. 9, in one possible implementation, step 250 may include the following steps:

and 251, searching candidate entities matched with the parameters in the individual case atlas of the notarization document by a regular matching mode.

And step 253, carrying out entity disambiguation on the candidate entities to obtain target entities.

Step 255, at the instance layer of the notarization document case atlas, case information matched with the target entity is inquired as case information corresponding to the parameters.

After determining the case information that can be replaced into the notary document template, the notary document template can be converted into the formal text of the notary document.

And 270, filling the searched case information to the position of the parameter in the document template to generate the document.

Through the process, manual generation of the notarization documents is replaced, the problem that manual writing possibly causes inconsistent document generation quality due to personal reasons can be avoided, the document generation process is standardized, and the stable quality of the generated notarization documents is ensured.

As mentioned above, the case information may be from the certification material and also from the interview bibliography, and the following describes the case information acquisition process in detail:

as shown in fig. 10, in an exemplary embodiment, acquiring case information includes the following steps:

at step 510, the certification material and/or interview chronicle is collected.

In one aspect, the certification material is a document submitted by the party containing case information, which may be in the form of paper material or an electronic document.

For example, when the certification material is collected, if the certification material submitted by the party is paper material, the paper material is scanned by the OCR technology to generate an electronic document, and the electronic document is stored. If the material is proved to be an electronic document, the material is directly stored.

On the other hand, the interview record is a document containing case information formed by the response of the party to the questions related to the notary affairs, and the form of the document can be generated by a notary in a mode of recording by hands based on the access inquiry of the party, and can also be automatically generated by a background.

Now, with reference to fig. 11 to 12, a process of automatically generating an interview record in the background is described in detail:

as shown in fig. 11, in one possible implementation, acquiring an interview directory may include the following steps:

step 511, querying the problem guiding strategy tree to determine the current problem node.

Wherein the question-guided policy tree is used for deciding the question-answering process when automatically generating the interview record.

In one possible implementation, different question guidance policy trees are configured according to different notarization transactions, so that question answering guidance can be performed on different notarization transactions. In one possible implementation, the problem-oriented policy tree includes a number of problem nodes, each storing therein a problem with respect to the notarized transaction.

Of course, in other embodiments, a problem-oriented policy tree may be configured for different notarization transactions, and is not specifically limited herein.

Step 513, obtain the answer for the current question node, and find the first entity matching the named entity in the answer in the question-answer knowledge graph.

Firstly, the question-answer knowledge graph is used for acquiring the first entity from the question-answer knowledge graph when generating the interview record, so that a basis is provided for acquiring answers, and the interview record can be generated quickly.

As shown in fig. 12, in one possible implementation, the construction process of the question-answer knowledge graph may include the following steps:

step 610, collecting historical interview bibliographies, and combining with an open-source question and answer corpus to form a question and answer corpus.

The historical interview record and the open source question and answer corpus are databases containing historical question and answer information. It should be understood that as the historical interview record and the historical question-answer information in the open source question-answer corpus are more abundant, the quality of the question-answer knowledge graph is improved, and the generation quality of the interview record is further improved.

Step 630, conducting named entity recognition on the interview script in the question and answer corpus to obtain a plurality of first entities.

In one possible implementation, the naming entity process specifically refers to: preprocessing the question and answer corpus by a BERT (Bidirectional Encoder retrieval from transformations) model, and after preprocessing the question and answer corpus, identifying the named entities in the question and answer corpus by methods such as combining a Bi-LSTM and a conditional random field CRF and the like to obtain a plurality of first entities.

And 650, extracting the relationships among the plurality of first entities by adopting a rule-based relationship extraction algorithm.

Wherein, the relationship among the plurality of first entities includes but is not limited to: belong to, include, are equal dependencies; and conceptual relationships such as yes, match, etc.

Of course, in other embodiments, the manner of extracting the relationship may also be through predefined relationship types, deep learning, and the like, which is not limited herein.

Step 670, generating a question-answer knowledge graph based on the plurality of first entities and the relations thereof.

The question-answer knowledge graph is formed by a plurality of nodes and paths connecting the corresponding nodes, each node is used for storing each first entity, and the paths are used for indicating the relationship among the first entities.

Based on the process, the construction of the question-answer knowledge graph is realized, a foundation is provided for obtaining the first entity, and the interview record can be automatically generated in a follow-up mode.

After the question-answer knowledge graph is constructed, the first entity matched with the named entity in the answer can be found based on the first entity in the question-answer knowledge graph and the relation of the first entity.

Specifically, each first entity in the question-answer knowledge graph is mapped to a vector space to obtain a word vector of each first entity, so that the similarity between the named entity in the answer and the first entity is calculated, and the matched first entity can be found according to the calculated similarity. It should be appreciated that the higher the similarity, the more the first entity matches the named entity in the answer.

Step 515, according to the found first entity, obtaining an answer to the current question node from the question-answer knowledge graph.

Specifically, the answer of the party is semantically analyzed, the searched first entities are sorted based on the semantic analysis result, the first entity most relevant to the answer is selected, the entity attribute of the first entity most relevant to the answer is determined based on a question-answer knowledge graph, and the answer aiming at the current question node is obtained by combining a natural language algorithm.

And 517, receiving a feedback message aiming at the answer, and continuously querying the problem guiding strategy tree based on the feedback message until the query of the problem guiding strategy tree is finished.

That is, by presenting the answer of the current one question node to the party in the form of voice and/or text, a feedback message for the answer can be obtained.

Receiving a feedback message generated by the party aiming at the answer, and analyzing the feedback message, thereby determining whether the feedback message conforms to the interview information standard required to be collected by the transaction; .

If the result of analyzing the feedback message shows that the feedback information accords with the interview information standard required to be collected by the transaction, continuing to inquire the problem guide strategy tree to jump to the next problem node of the interview process; i.e., returning to step 511, the question-answering process described above is repeated. If the result of analyzing the feedback information shows that the feedback information does not accord with the interview information standard needing to be collected by the affair, the question guide strategy tree is continuously inquired to jump to the next question of the question node in the interview process (namely the system makes further questions;)

When the next problem node does not exist in the problem guiding strategy tree, the query of the problem guiding strategy tree is stopped, and at this time, it can be considered that the query of the problem guiding strategy tree is finished, that is, the step jumps to step 519.

And step 519, generating an interview record based on the inquired questions in the question nodes and the corresponding answers and answers.

Therefore, by combining the question guide strategy tree and the question and answer knowledge graph, the questions in the question nodes of each round of the question guide strategy tree, the answers given by the question and answer knowledge graph and/or the answers given by the parties can be stored as interview scripts in a time sequence mode. For example, assume that the problem in the current problem node is: what type of notary affairs you are going to do? For the current question node, the principal's answer is: what notations should be dealt with if i just bought a house and did not pass the house? Based on the knowledge graph of the question and answer, the answer aiming at the question node can be obtained and shown to the party, and if the party considers that the answer is not the answer which the party wants, a feedback message aiming at the answer is returned.

After receiving the feedback message, continuing to query the problem guiding strategy tree, and jumping to the next problem node, assuming that the problem in the next problem node is: is your house a futuristic or present house? For this question node, the principal's answer is: the house is made; based on the knowledge graph of the question and answer, the answer to the question node is 'you can choose to handle the contract notations of buying and selling in the commodity house', and the answer is displayed to the party.

Assuming the principal considers the answer to be the answer it wants, the question leads the query of the policy tree to be stopped.

Finally, an interview bibliography for the party is generated according to the questions and the answers generated in the process.

Step 530, case information is extracted from the certification material and/or interview bibliography.

Under the cooperation of the embodiment, the automatic collection of the case information from the certification materials or the interview notes is realized, the standardization of the case information collection process is realized, the problems of low efficiency and unstable quality of manual collection of the case information are solved, and the quality and the standardability of the generated official documents are further improved.

Fig. 13 is a schematic diagram of a specific implementation of a notarization document generating method in an application scenario.

In this application scenario, through step 801, a plurality of notary document templates are stored, each notary document template corresponding to a different notary transaction, and each notary document template having stored therein replaceable parameters.

Constructing a notarization field knowledge graph (namely a notarization field graph) and a case information knowledge graph (a case information graph) through the step 802; the case information knowledge graph is a case specific to specific notarization affairs.

Through step 803, the notarization field knowledge map and case information knowledge map are subjected to knowledge fusion to obtain the case notarization document knowledge map. The case notarization document knowledge map is suitable for cases of specific notarization affairs. After the case public certificate document knowledge graph is obtained, case information aiming at the case can be searched by using the case public certificate document knowledge graph.

Based on the user selection, a notary document template is obtained, via step 804. It should be understood that the parameters vary from notary document template to notary document template; it is also believed that the notary document template is applicable to cases of a particular notary transaction.

Through step 805, case information corresponding to the parameters in the notarization document template is obtained from the case notarization document knowledge graph.

Through step 806, case information is filled in the position of the parameter in the notarization document template, and therefore the notarization document template is converted into the formal text of the notarization document.

The official text of the notary document is pushed to the user, via step 807. For example, the official text of the notary document is presented to the user via a display screen configured with the electronic device.

In the application scene, the notarization document template is constructed, and the notarization field atlas and the case information atlas are fused to generate the notarization document case atlas, so that the case information is replaced to the notarization document template by using the notarization document case atlas, the formal text of the notarization document is obtained, the manual writing of the formal text of the notarization document is avoided, the writing efficiency of the notarization document is improved, and the document quality is improved.

In addition, based on the notarization field atlas, the notarization document conforming to the relevant regulations can be generated, and the standardization and the reliability of the notarization document generation are improved.

The following are embodiments of the apparatus of the present application that may be used to perform the notarization document generation method of the present application. For details which are not disclosed in the embodiments of the apparatus of the present application, reference is made to the embodiments of the method of production of the notational document referred to in the present application.

Referring to fig. 14, in an embodiment of the present application, a notarization document generating apparatus 900 is provided, including but not limited to: the system comprises an information map construction module 910, a knowledge fusion module 930, a case information search module 950 and a document generation module 970.

The information map building module 910 is configured to obtain case information, and build a case information map based on the case information.

And a knowledge fusion module 930, configured to perform knowledge fusion on the case information map and the notarization field map to generate a notarization document case map.

The case information searching module 950 is configured to determine parameters in the notarization document template, and search case information corresponding to the parameters in the notarization document individual case map.

The document generating module 970 is configured to fill the found case information to the position of the parameter in the notarization document template to generate a notarization document.

It should be noted that, when the notarization document generating apparatus provided in the above embodiment performs the notarization document generation, only the division of the above function modules is illustrated, and in practical applications, the above function distribution may be completed by different function modules as needed, that is, the internal structure of the notarization document generating apparatus is divided into different function modules to complete all or part of the above described functions.

In addition, the notarization document generating apparatus provided in the above embodiment and the notarization document generating embodiment belong to the same concept, wherein the specific manner in which each module executes operations has been described in detail in the method embodiment, and is not described herein again.

FIG. 15 illustrates a structural schematic of a server in accordance with an exemplary embodiment. The server is suitable for the notarization document generation method according to the embodiment.

It should be noted that the server is only an example adapted to the application and should not be considered as providing any limitation to the scope of use of the application. Nor should the server be interpreted as having a need to rely on or have to have one or more components of the exemplary server 2000 illustrated in fig. 15.

The hardware structure of the server 2000 may be greatly different due to the difference of configuration or performance, as shown in fig. 15, the server 2000 includes: a power supply 210, an interface 230, at least one memory 250, and at least one Central Processing Unit (CPU) 270.

Specifically, the power supply 210 is used to provide operating voltages for the various hardware devices on the server 2000.

The interface 230 includes at least one wired or wireless network interface 231 for interacting with external devices. Of course, in other examples of the present application, the interface 230 may further include at least one serial-to-parallel conversion interface 233, at least one input/output interface 235, at least one USB interface 237, and the like, as shown in fig. 15, which is not limited herein.

The storage 250 is used as a carrier for resource storage, and may be a read-only memory, a random access memory, a magnetic disk or an optical disk, etc., and the resources stored thereon include an operating system 251, an application 253, data 255, etc., and the storage manner may be a transient storage or a permanent storage.

The operating system 251 is used for managing and controlling each hardware device and the application 253 on the server 2000, so as to implement the operation and processing of the mass data 255 in the memory 250 by the central processing unit 270, which may be Windows server, mac OS XTM, unix, linux, freeBSDTM, and the like.

The application 253 is a computer program that performs at least one specific task on the operating system 251, and may include at least one module (not shown in fig. 15), each of which may include a computer program for the server 2000. For example, the notary document generation means may be considered as an application 253 deployed on the server 2000.

Data 255 may be photographs, pictures, etc. stored in a disk, case information, etc. stored in memory 250.

The central processor 270 may include one or more processors and is configured to communicate with the memory 250 through at least one communication bus to read the computer programs stored in the memory 250, so as to realize the operation and processing of the mass data 255 in the memory 250. The notary document generation method is accomplished, for example, by the central processor 270 reading a form of a series of computer programs stored in the memory 250.

Furthermore, the present application can be implemented by hardware circuits or by hardware circuits in combination with software, and therefore, the implementation of the present application is not limited to any specific hardware circuits, software, or a combination of the two.

Referring to fig. 16, in an embodiment of the present application, an electronic device 4000 is provided, where the electronic device 400 may include: desktop computers, notebook computers, tablet computers, servers, and the like.

In fig. 15, the electronic device 4000 includes a plurality of processors 4001, at least one communication bus 4002, and a plurality of memories 4003.

Processor 4001 is coupled to memory 4003, such as by communication bus 4002. Optionally, the electronic device 4000 may further include a transceiver 4004, and the transceiver 4004 may be used for data interaction between the electronic device and other electronic devices, such as transmission of data and/or reception of data. In addition, the transceiver 4004 is not limited to one in practical applications, and the structure of the electronic device 4000 is not limited to the embodiment of the present application.

The Processor 4001 may be a CPU (Central Processing Unit), a general-purpose Processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array) or other Programmable logic device, a transistor logic device, a hardware component, or any combination thereof. Which may implement or perform the various illustrative logical blocks, modules, and circuits described in connection with the disclosure. The processor 4001 may also be a combination that performs a computational function, including, for example, a combination of one or more microprocessors, a combination of a DSP and a microprocessor, or the like.

Communication bus 4002 may include a path that carries information between the aforementioned components. The communication bus 4002 may be a PCI (Peripheral Component Interconnect) bus, an EISA (Extended Industry Standard Architecture) bus, or the like. The communication bus 4002 may be divided into an address bus, a data bus, a control bus, and the like. For ease of illustration, only one thick line is shown in FIG. 16, but this is not intended to represent only one bus or type of bus.

The Memory 4003 may be a ROM (Read Only Memory) or other type of static storage device that can store static information and instructions, a RAM (Random Access Memory) or other type of dynamic storage device that can store information and instructions, an EEPROM (Electrically Erasable Programmable Read Only Memory), a CD-ROM (Compact Disc Read Only Memory) or other optical Disc storage, optical Disc storage (including Compact Disc, laser Disc, optical Disc, digital versatile Disc, blu-ray Disc, etc.), a magnetic Disc storage medium or other magnetic storage device, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer, but is not limited thereto.

A computer program is stored in the memory 4003, and the processor 4001 reads the computer program stored in the memory 4003 through the communication bus 4002.

The computer program realizes the notarization document generation method in the above embodiments when executed by the processor 4001.

In addition, in the embodiments of the present application, a storage medium is provided, and a computer program is stored on the storage medium, and when being executed by a processor, the computer program realizes the notarization document generation method in the above embodiments.

A computer program product is provided in an embodiment of the present application, the computer program product comprising a computer program stored in a storage medium. The processor of the computer device reads the computer program from the storage medium, and the processor executes the computer program, so that the computer device executes the notarization document generating method in the above embodiments.

Compared with the prior art, the case information map and the notarization field map are fused by utilizing the paradigm characteristics of the notarization document, the case information corresponding to the parameters is read by inquiring the fused knowledge map, and the case information is replaced to the position corresponding to the parameters of the notarization document template, so that the formal text of the notarization document is quickly and automatically generated.

It should be understood that, although the steps in the flowcharts of the figures are shown in order as indicated by the arrows, the steps are not necessarily performed in order as indicated by the arrows. The steps are not performed in the exact order shown and may be performed in other orders unless explicitly stated herein. Moreover, at least a portion of the steps in the flow chart of the figure may include multiple sub-steps or multiple stages, which are not necessarily performed at the same time, but may be performed at different times, and the order of execution is not necessarily sequential, but may be performed alternately or alternately with other steps or at least a portion of the sub-steps or stages of other steps.

The foregoing is only a partial embodiment of the present application, and it should be noted that, for those skilled in the art, several modifications and decorations can be made without departing from the principle of the present application, and these modifications and decorations should also be regarded as the protection scope of the present application.

Claims

1. A notary document generation method, said method comprising:

acquiring case information, and constructing a case information map based on the case information;

carrying out knowledge fusion on the case information map and the notarization field map to generate a notarization document individual case map;

determining parameters in a notarization document template, and searching case information corresponding to the parameters in the notarization document individual case map;

and filling the searched case information to the position of the parameter in the notarization document template to generate a notarization document.

2. The method of claim 1, wherein said obtaining case information comprises:

collecting certification material and/or interview notes;

and extracting the case information from the proving materials and/or the interview record.

3. The method of claim 2, wherein the collection interview transcript comprises:

inquiring a problem guide strategy tree and determining a current problem node;

obtaining a response aiming at the current question node, and searching a first entity matched with the named entity in the response in a question-answer knowledge graph;

according to the searched first entity, obtaining an answer aiming at the current question node from the question-answer knowledge graph;

receiving a feedback message aiming at the answer, and continuously querying the question guide strategy tree based on the feedback message until the query of the question guide strategy tree is finished;

and generating the interview record based on the inquired questions in the question nodes and the corresponding answers and answers.

4. The method of claim 1, wherein said knowledge fusing said case information graph with a notary domain graph to generate a notary document case graph comprises:

acquiring second entities in the case information map and third entities in the notarization field map, and determining the similarity between each second entity and each third entity;

determining a correspondence of the second entity and the third entity that are similar based on the determined similarity;

and based on the determined corresponding relation, embedding case information in the case information map into the example layer of the notarization field map to obtain the notarization document individual case map.

5. The method of claim 4, wherein said embedding case information in said case information graph into an instance layer of said notarization field graph based on said determined correspondence to obtain said notarization document individual graph, comprises:

performing entity alignment and/or coreference resolution on the similar second entity and third entity based on the corresponding relation;

and after entity alignment and/or coreference resolution, pointing the second entity chain of the case information map to the third entity corresponding to the notarization field map to obtain the notarization document case map.

6. The method of claim 1, wherein said finding case information corresponding to said parameters in said notarization instrument case map comprises:

searching candidate entities matched with the parameters in the notarization document individual case atlas in a regular matching mode;

carrying out entity disambiguation on the candidate entity to obtain a target entity;

and inquiring case information matched with the target entity at an example layer of the individual case map of the notarization document as case information corresponding to the parameters.

7. The method of any one of claims 1 to 6, wherein the training set includes case information, historical notarization documents and notarization-related legal documents, and the knowledge graph includes case information graph and notarization domain graph;

the method further comprises the following steps: constructing the knowledge graph according to the training set;

the constructing the knowledge-graph according to the training set comprises:

identifying the named entities in the training set to obtain a plurality of named entities; the named entities comprise a second entity in the case information, a third entity in the historical notarization document and a legal document related to the notarization;

extracting the relationship among the named entities by adopting a rule-based relationship extraction algorithm;

respectively storing each named entity to each node, and constructing a path among corresponding nodes based on the relationship among the named entities;

and constructing the knowledge graph according to the nodes and the paths.

8. A notary document generation apparatus, said apparatus comprising:

the information map building module is used for obtaining case information and building a case information map based on the case information;

the knowledge fusion module is used for carrying out knowledge fusion on the case information map and the notarization field map to generate a notarization document individual case map;

the case information searching module is used for determining parameters in the notarization document template and searching case information corresponding to the parameters in the notarization document individual case map;

and the document generation module is used for filling the searched case information to the position of the parameter in the notarization document template to generate a notarization document.

9. An electronic device, comprising: at least one processor, at least one memory, and at least one communication bus, wherein,

the memory has a computer program stored thereon, and the processor reads the computer program in the memory through the communication bus;

the computer program, when executed by the processor, implements the notarization document generation method as claimed in any of claims 1 to 7.

10. A storage medium, comprising: stored thereon a computer program which, when executed by a processor, implements the notary document generation method as claimed in any one of claims 1 to 7.