LLM-based contract element extraction and auditing method and device
Through the LLM-based method, the contract text is parsed and vectorized, the text vector database is constructed, and contract elements are extracted and marked, which solves the problem of quickly extracting and reviewing contract indicators, and achieves efficient contract consistency checksum factor comparison.
Patent Information
- Application Number
- CN202510368303.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-03-27
- Publication Date
- 2025-05-02
- Estimated Expiration
- 2045-03-27
AI Technical Summary
It is difficult for prior art to quickly extract contract indicators from pending texts and ensure that the contracts to be reviewed meet these indicator requirements.
Using an LLM-based method, the target contract is parsed to obtain text block data, vectorized and constructed a text vector database; extract feature information in the text to be processed, vectorized and search for similar vectors in the text vector database, generate vector sequences and label differences.
It realizes rapid extraction and review of contract elements, improves the efficiency of contract consistency checksum factor comparison, and reduces the complexity of manual review.
Smart Images

Figure CN119918514A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the technical field of text data processing, and in particular to a method and device for extracting and reviewing contract elements based on LLM. Background Art
[0002] From project bidding to project acceptance, multiple contracts will be signed in the middle. How to quickly extract indicators from the text to be processed and how to quickly verify whether the contract to be reviewed fully meets the indicator requirements in the text data of the original contract have become the primary issues faced by project managers.
[0003] Therefore, a method and device for extracting and reviewing contract elements based on LLM is proposed to solve the above-mentioned problems. Summary of the invention
[0004] The present invention aims to provide a method and device for extracting and reviewing contract elements based on LLM, so as to solve or improve the above-mentioned technical problem of how to quickly extract indicators from the text to be processed and ensure that the contract to be reviewed meets the requirements of these indicators.
[0005] In view of this, a first aspect of the present invention is to provide a contract element extraction and review method based on LLM.
[0006] A second aspect of the present invention is to provide a device.
[0007] The first aspect of the present invention provides a contract element extraction and review method based on LLM, comprising the following steps: parsing at least one target contract to obtain multiple text block data, vectorizing each of the text block data to obtain a first multidimensional vector, and constructing a text vector database through the text block data and the corresponding first multidimensional vector; extracting feature information in the text to be processed and using it as a contract indicator, generating a label of the contract indicator according to the category to which each feature information belongs, and vectorizing each of the feature information and the corresponding label together to obtain a second multidimensional vector; searching the text vector database for multiple first multidimensional vectors that are close to the second multidimensional vector, and sorting all the second multidimensional vectors according to the first multidimensional vector to generate a vector sequence; generating a contract to be reviewed based on the vector sequence and the text block data, and marking the feature information and / or the text block data on the contract to be reviewed through the difference between the first multidimensional vector and the second multidimensional vector.
[0008] The second aspect of the present invention provides a device, including: a text parsing and vectorization module, which is used to receive and parse at least one target contract to obtain multiple text block data; perform vectorization processing on each text block data to generate a corresponding first multidimensional vector; construct a text vector database based on the text block data and its corresponding first multidimensional vector; a text indicator extraction module, which is used to extract feature information from the text to be processed as a contract indicator; generate a corresponding label according to the category to which each feature information belongs; vectorize each feature information and the corresponding label together to obtain a second multidimensional vector; an indicator vector retrieval and sorting module, which is used to retrieve multiple first multidimensional vectors that are semantically similar to the second multidimensional vector in the text vector database; sort all second multidimensional vectors according to the semantic similarity between the first multidimensional vector and the second multidimensional vector to generate a vector sequence; a contract generation and annotation module, which generates a contract to be approved based on the above-mentioned vector sequence and the corresponding text block data; based on the difference information between the first multidimensional vector and the second multidimensional vector, annotate the corresponding feature information and / or text block data in the generated contract to be approved.
[0009] Compared with the prior art, the present invention has the following beneficial effects: Splitting the original contract text into multiple text blocks and vectorizing them not only supports hierarchical processing of long texts, but also establishes a semantic index foundation for rapid retrieval and positioning through the text vector database, thereby taking into account the flexibility of massive document processing and the scalability of data management.
[0010] By extracting and labeling the feature information of the text to be processed, the generated second multidimensional vector can capture the semantic features of different types of elements (such as Party A, Party B, time, function, performance, etc.), achieve accurate positioning and classification for different contract scenarios, and provide more solid data support for subsequent verification and generation processes.
[0011] The use of vectorized text representation for similarity matching is no longer limited to traditional keyword matching or rule retrieval. It can identify the semantic associations between different text blocks at a deeper level. By sorting and screening the search results, the most suitable clauses or indicator content can be quickly found, providing an efficient and flexible technical means for contract consistency verification and element comparison.
[0012] Under the guidance of the vector sequence, the elements extracted and sorted from the original contract and the text to be processed are integrated to generate a new contract text; at the same time, annotations are made based on the differences between the first multidimensional vector and the second multidimensional vector, which significantly improves the ability to discover and visualize differences. This not only reduces the complexity of manual review, but also provides convenience for legal or project management personnel to complete contract review accurately and quickly.
[0013] Additional aspects and advantages of embodiments according to the present invention will become apparent in the following description or may be learned through practice of embodiments according to the present invention. BRIEF DESCRIPTION OF THE DRAWINGS
[0014] The above and / or additional aspects and advantages of the present invention will become apparent and easily understood from the description of the embodiments in conjunction with the following drawings, in which: Figure 1 is a flow chart of the method steps of the present invention; Figure 2 This is the indicator verification flow chart of the present invention; Figure 3 It is the indicator extraction flow chart of the present invention; Figure 4 It is a logic block diagram of the device structure of the present invention; Figure 5 The figure is a schematic diagram of the structure of an electronic device of the present invention. DETAILED DESCRIPTION
[0015] In order to more clearly understand the above-mentioned purpose, features and advantages of the present invention, the present invention is further described in detail below in conjunction with the accompanying drawings and specific embodiments. It should be noted that the embodiments of the present application and the features in the embodiments can be combined with each other without conflict.
[0016] In the following description, many specific details are set forth to facilitate a full understanding of the present invention. However, the present invention may also be implemented in other ways different from those described herein. Therefore, the protection scope of the present invention is not limited to the specific embodiments disclosed below.
[0017] See also Figure 1-Figure 5 , the following describes a method and device for extracting and reviewing contract elements based on LLM according to some embodiments of the present invention.
[0018] As described in the background technology, the technical solutions of the prior art generally adopt the following steps when using the model for processing: a) Extract indicators based on sequence labeling algorithm: For the task of extracting indicators from contracts, a sequence labeling algorithm is generally used. In this algorithm, first collect the labeled corpus, then train the sequence labeling model based on the corpus, and finally apply the model to production to extract indicators.
[0019] b) Indicator verification based on question-answering algorithm: In the indicator verification stage, question-answering is often used. First, the relevant paragraphs are retrieved from the target contract based on the indicator to be verified, and then the indicator and the relevant paragraphs are input into the question-answering model to obtain the verification result. This model generally converts whether the requirements are met into a text binary classification task, that is, the output 1 represents the requirements are met, and 0 represents the requirements are not met, and uses extractive question-answering to locate the description most relevant to the indicator from the contract to be verified.
[0020] The above existing technical solutions all require model training in advance, so a lot of effort needs to be invested in data labeling. In addition, the trained model and the labeled data are bound to each other, that is, the model can only achieve close to expected performance in fields similar to the labeled data. In the indicator verification algorithm, the model only has the ability to understand text and cannot explain the given results, which increases the workload of manual reconfirmation to a certain extent.
[0021] In view of the above-mentioned technical problems, the first aspect of the present invention proposes a method for extracting and reviewing contract elements based on LLM. In some embodiments of the present invention, Figure 1-Figure 3 As shown, the method comprises the following steps: S101, parse at least one target contract to obtain multiple text block data, vectorize each text block data to obtain a first multidimensional vector, and construct a text vector database through the text block data and the corresponding first multidimensional vector. The target contract contains the format and text data expected in the final generated contract, and a mapping relationship between the first multidimensional vector containing a numerical value and the corresponding text block data is generated, and such a mapping relationship is used to construct a text vector database to facilitate subsequent rapid retrieval of related text blocks.
[0022] Here, the target contract needs to be parsed and segmented. At this stage, the contract text will be segmented according to logical or structural features based on the understanding of the contract text. Usually, the entire contract can be broken down into multiple relatively independent text blocks based on the contract chapters, clauses, paragraph numbers, title structure or pre-set keywords. For example, for a comprehensive contract containing several procurement terms, payment methods, confidentiality agreements and breach of contract liability, the system will treat each natural paragraph, each clause or each key element as a text block that can be stored and processed separately. The reason for such detailed decomposition here is mainly because the subsequent element extraction and semantic retrieval need to be carried out within a finer granularity. If only large sections or the entire contract text are retained, it will be difficult to locate the specific elements during search, matching and review.
[0023] After segmentation, the text block preprocessing phase will begin, which may involve natural language processing steps such as removing redundant characters, punctuation normalization, stop word screening, word segmentation, word form restoration or synonym replacement to ensure that each text block data is in a relatively clean and easy-to-process state. For example, when a contract contains a large number of legal terms and professional terms, targeted processing will be performed based on the pre-trained legal vocabulary or legal corpus to ensure that the correct meaning of these professional terms can be captured during subsequent vectorization. In multilingual or mixed language scenarios, language detection and special character conversion may also be required for the text.
[0024] Next, a first multidimensional vector is generated for each preprocessed text block, and a deep learning model or vectorization tool is used to map the natural language text into a vector space with controllable dimensions and rich semantics. The present invention adopts LLM (Large Language Model) to capture word associations, context clues and logical structures within the text block. By forward inference or embedding calculation of the text block, a set of vectors containing numerical features will be obtained. These features not only capture the text keywords, but also contain multiple layers of information such as the overall semantics, syntactic structure and even emotional orientation of the text. For example, if a certain text content of the target contract mainly discusses elements such as "payment method", "phased settlement" and "contract amount limit", the vectorization process may make these concepts relatively close in the vector space, which is convenient for subsequent retrieval and matching.
[0025] After the text block is vectorized, a one-to-one correspondence will be established between the "original text block data" and the "corresponding first multidimensional vector", and these mapping relationships will be uniformly stored in the text vector database. This database can not only save the correspondence between the text block and its vector, but also record the position, paragraph number, related clause title and possible context information of each text block in the original contract. This storage method greatly improves the efficiency and accuracy of subsequent retrieval, comparison and feature extraction: when a specific element needs to be queried or reviewed, or when a new text vector needs to be compared with an existing text block in the database for similarity, as long as the query vector or new text goes through the same vectorization steps and is compared with the vector in the database, the closest text block can be found in a very short time. This not only speeds up the location of relevant contract terms or elements, but also makes automated contract review and comparison possible.
[0026] It is worth noting that the construction of the text vector database also enables large-scale contract data to be managed in a unified manner. When there are multiple or hundreds of contracts to be processed in actual use, this database structure can accommodate vector representations of a large number of text blocks and support distributed retrieval and indexing, making full use of the powerful semantic understanding capabilities brought by LLM. Whether the user needs to check the expected text format of the contract or needs to conduct compliance inspections on certain key elements, batch operations and automated comparisons can be efficiently achieved through the text vector database.
[0027] As can be seen from the above, the text vector database constructed based on this processing constitutes the underlying foundation of the present invention in contract element extraction and review. By carefully splitting each paragraph or clause in the original contract text into text blocks, and then using deep learning or other natural language processing models to generate a mapping relationship between the first multidimensional vector and the text block, an effective means is obtained that can both identify local semantic features and quickly perform similarity retrieval. This provides accurate and scalable support for subsequent tasks such as element extraction, element comparison, risk assessment, contract generation and review, thereby greatly improving the automation and intelligence level of the contract review and management process.
[0028] Specifically, the step of parsing at least one target contract to obtain a plurality of text block data includes: Obtain the target contract to obtain text data, and extract the contract framework information in the text data.
[0029] Split the text data to obtain multiple text block data. Since LLM generally has a word limit on text input, too long input will also reduce the accuracy of the model output. Therefore, first split the text data into multiple text blocks of appropriate length; add the contract framework information to each text block data so that the text block data can retain the relevant information in the original target contract.
[0030] In view of the above specific description, in the process of acquiring the target contract to obtain text data, the main purpose is to convert all the text content of the target contract into plain text or readable format for subsequent processing. This usually means parsing or converting the contract document to extract continuous character data from any common document form (such as some electronic document or image form). This step focuses on maintaining the integrity of the body of the contract and retaining potential structural information related to the contract as much as possible, such as chapter titles, page numbers, paragraph numbers, or other clues that can help identify how the text is organized. By rigorously acquiring text data, subsequent natural language processing or large language model processing can be performed on a relatively clean and structured basis.
[0031] When extracting contract framework information from text data, it is necessary to extract the core information that can reflect the overall structure of the contract based on the existing title hierarchy, clause division, numbering specifications, and paragraph identification within the target contract. Because most contracts will arrange clauses or chapters in a certain logical order, if they are simply regarded as disordered text streams, many valuable hierarchical clues will often be lost in subsequent analysis. By extracting and recording relevant framework information, it can help the system maintain or reconstruct the original hierarchical and sequential relationship of the contract text in subsequent stages, providing a reliable reference for retrieval, annotation, and review. In addition, the process of extracting contract framework information can also include identifying contract titles, document descriptions, contract party identifications, clause serial numbers, etc., so that in subsequent processing links, it is easier to trace back to the location or paragraph context of the specific clause.
[0032] Next, since large language models often have certain restrictions on the length of the input text, and too long input content may cause the model's recognition accuracy or reasoning efficiency to decrease, it is necessary to first clarify the segmentation strategy in the step of segmenting the text data to obtain multiple text block data. This strategy usually uses a certain amount of text or symbols as a standard, combined with the necessary semantic information boundaries, to orderly decompose the entire contract text into several paragraphs or semantic units. For longer contracts, you can cut at the line breaks or paragraph separators that come with the text, and try to avoid splitting a sentence or a clause with a complete meaning across blocks. Segmentation in this way can reduce the interference caused by a single text block being too bloated, allowing the model to focus more on processing local semantics and retain necessary contextual information to avoid a large number of duplications or omissions when merging results.
[0033] After the block division is completed, the contract framework information is added to each text block data, which can further enhance the accuracy and convenience of subsequent analysis, retrieval and review. At this time, the contract framework information is no longer stored separately in the external structure, but is embedded in the beginning of the corresponding text block, a specific identifier or other appropriate location. The purpose of this is to enable each text block to still carry the source, clause number, chapter name or other related information that may guide the semantic understanding of the model when it is used or transmitted independently. Through this operation, not only does it provide the model with hints that help context inference when calling large language models for processing later, but it can also achieve more efficient search and traceability based on the retained framework information when storing the text block data in a vector database or other retrieval system. The process of combining block division with meta information requires a cautious attitude towards the logical organization of the text to ensure that the body of the contract can still be assembled or mapped back to the original chapter order when necessary.
[0034] From the above, we can see that by obtaining the target contract, extracting the framework information, performing appropriate text segmentation and supplementing sufficient meta-information in each block, the structured context in the original contract can be retained to the greatest extent, and a feasible and accurate corpus source can be provided for subsequent steps such as element extraction, vectorized storage, semantic matching, and annotation review. In this process, any practice of ignoring the contract framework information or arbitrarily segmenting the text may make it difficult for the model to understand the logical relationship between the clauses or cause information loss. The detailed segmentation and information embedding in the above manner significantly reduces the probability of such problems and improves processing efficiency and quality.
[0035] In any of the above embodiments, the contract framework information includes the contract name information of the target contract, the chapter information where the text block data is located, and the category information to which the text block data belongs; in order to improve the model's understanding of the text block, the contract name and the chapters it describes and other information will be added to it.
[0036] In this embodiment, the contract name information refers to a type of identification data that can clearly identify the entire contract subject or document source. This information can be a procurement contract for a project, a cooperation agreement between companies, or a file title with limited descriptions such as time and unit name. Attaching the contract name information to the text block allows the subsequent processing model or retrieval system to distinguish different contract sources, and even when processing multiple documents, it is easy to determine the specific contract to which each text block belongs. In practice, if various contracts are extracted or audited on a large scale, it will be difficult to effectively trace the specific file to which the text block belongs without clear contract name information. It can be seen that this information is particularly necessary when dealing with multi-contract environments (such as batch audits or centralized archiving). It can not only improve the model's understanding of the meaning of the text, but also allow the subsequent manual review to quickly locate the source of the text block, ensuring the traceability and relevance of the data.
[0037] The chapter information where the text block data is located is a further refined structural identifier, which reflects the exact position of the text block in the contract content hierarchy. Because the usual contract text will organize relevant clauses, regulations and details in the form of chapters, sections, articles or clauses. If the contract is only broken down into several fragments without recording their contextual relationship at the chapter level, it is very easy to cause ambiguity in subsequent analysis or ignore the structural logic. For example, in some contract clauses, "Chapter 3 Payment Agreement" and "Chapter 4 Confidentiality and Intellectual Property" may have completely different content scopes. If the chapter information is missing, the model cannot immediately know the location of the text block when processing it, and thus cannot use other semantic connections to clarify the context environment that this text block should have. By adding chapter information, the model can preliminarily judge whether the text block being processed is related to the "payment terms" or the "rights and obligations" part when inputting data. This information can play a prompt or guide role in the understanding or generation process of the model, making the output of the model closer to the structural requirements of the real contract.
[0038] The category information to which the text block data belongs can help classify and manage the text blocks at a higher level. The category information is usually based on the functional division of the contract content or the classification of general legal terms, and may involve labeled descriptions such as "liability for breach of contract", "payment terms", "confidentiality obligations", and "dispute resolution mechanisms". After the text blocks are labeled with appropriate categories, the system can quickly filter or focus on them according to the categories during subsequent processing. For example, if the auditor only wants to view the part of the contract related to fees or payment terms, he can directly retrieve or filter the text blocks of the corresponding category without having to traverse the entire content. For large language models, category information can also provide a clearer contextual hint. For example, when the model receives a text block labeled "confidentiality clause", it will be more inclined to associate it with key points such as confidentiality obligations, responsibility boundaries, and confidentiality clauses when generating semantic analysis or answers, thereby outputting more accurate or targeted results. Conversely, if such classification information is missing, even a language model with high accuracy will need to spend more calculations and reasoning steps to guess the functional attributes of the text.
[0039] Specifically, the step of vectorizing each text block data to obtain a first multi-dimensional vector includes: The contract name information, chapter information, category information and text block data are respectively converted into numerical values, and the numerical values are used to form a first multidimensional vector, so that when the original contract is subsequently processed by the first multidimensional vector and the corresponding text block data, a new contract template can be generated for the text to be processed of the current original contract without a standard contract template.
[0040] In view of the above specific description, as far as the digitization of "contract name information" is concerned, this part of information often contains the basic positioning of the entire contract identity, such as the business field of the contract, the name of the signing entity, or the type of cooperation implied in the contract title. By processing this type of text content through an appropriate Embedding algorithm or other numerical representation model, the system can retain the "semantic fingerprint" of the information when generating the first multidimensional vector. The advantage of this is that when the text block needs to be mapped back to its source contract later, or when the same type of text blocks are compared between multiple contracts, the "context environment" and "business label" carried by the contract name can make additional distinctions between the text blocks in the vector space. For example, if the system needs to distinguish between certain common terms in "procurement contracts" and "technology development contracts", the distinguishing information carried by the contract name will help the vector search engine to more accurately classify these text blocks in cosine similarity or vector distance calculations, making them more suitable for on-demand combination or splicing.
[0041] The digitization of chapter information maps the organizational position of the text block in the overall contract hierarchy into numerical features that can be understood and utilized by the model. Chapter information has a highly structured meaning in many contracts: from general provisions, definitions, authority and responsibilities to confidentiality clauses, payment procedures, dispute resolution, etc., different chapters often present a clear logical context. By vectorizing this information and placing it in a fusion vector with the core content of the text block, the system can more accurately determine "whether the context or subject of the text block matches the query requirements" during the retrieval stage, and can also help generate new contracts. When the text blocks under the same chapter can be quickly combined with fewer trial and error steps, the coherence of the contract structure is preserved. Especially when it is necessary to summarize, compare or select clauses of the same subject and chapter across multiple contract source files, the "hierarchical identification" provided by the chapter information will make the vector comparison more targeted and reduce the noise in the search results.
[0042] The digitization of category information is to map the functional classification of text blocks manually or automatically, such as element labels such as "payment terms", "breach of contract liability", and "confidentiality obligations", to corresponding numerical representations and incorporate them into the fusion vector. The significance of category information is that even if different paragraphs in the same chapter have completely different functional attributes, they can be more finely distinguished through category labels. On the contrary, if two text blocks in different contracts are both labeled with "breach of contract clauses", the system does not need to make additional guesses about their possible commonalities in business logic, but can directly enhance their similarity in the vector space through the numerical representation of category information. When a new contract template is generated later, the system can aggregate or filter out all text blocks with the same label with one click, quickly sort, compare or merge them, and automatically produce a merged draft covering the required category elements, thereby improving efficiency and reducing the burden of manual review.
[0043] The digitization of text block data is to transform the natural language content of the text block itself into a vector in a high-dimensional semantic space through models such as Embedding. This vector often contains rich information dimensions such as vocabulary selection, syntactic structure, semantic association, and context clues. The vectorization of text block data brings real intelligent possibilities for contract review, element extraction, and contract generation. It can not only be used as the basis for semantic similarity calculation, but also be merged with the aforementioned contract name, chapter information, and category information into a more comprehensive first multidimensional vector, so that the semantic content and external labels and structural positions of the text block can be considered at the same time during retrieval. The effect of this merger is that even if two texts are very similar in language, if they belong to different chapters or categories, the system can also open up the gap in the vector space; or when the texts are slightly different in language expression, but the labels and structural information are highly consistent, the system will increase their degree of association in retrieval ranking.
[0044] As can be seen from the above, for original contracts or multiple original documents that do not have standardized templates, a set of numerical representation mechanisms compatible with multi-dimensional attributes has been established, so that subsequent applications based on LLM or other semantic retrieval algorithms can easily associate text content with contract structure information, providing strong technical support for further review, clause comparison, element extraction, automatic draft generation and even compliance inspection. In this vectorization strategy for multi-dimensional information fusion, each text block not only carries its own content, but also has clear context clues to minimize data confusion caused by disordered text or multi-source documents, and ultimately provides a highly flexible and scalable operating space for contract generation or review in different scenarios.
[0045] In any of the above embodiments, the corresponding values of the category information and the text block data are in the leading dimension or the trailing dimension in the dimensional position sorting of the first multidimensional vector; since the second multidimensional vector and the first multidimensional vector themselves have at least one dimension of data, it is necessary to use the second multidimensional data dimensionality upgrade operation to supplement the missing contract name information and chapter information, but the contract name information and chapter information are not compared in the two-dimensional vector to reduce errors; and when performing the comparison, it is necessary to align the values in the second multidimensional vector, and select the leading dimension or the trailing dimension in the first multidimensional vector as the category information and the text block data, so that the corresponding values of the same data can be compared when comparing vectors of different dimensions.
[0046] In this embodiment, in the dimensional position sorting of the first multidimensional vector, it is necessary to clarify how the positions of the category information and the text block data are arranged in the entire vector. The first multidimensional vector can be regarded as a fixed-length numerical sequence, and its sequence index corresponds to different semantics or data sources from the beginning to the end. Assuming that the system puts the numerical value of the category information into the first several dimensions of the first multidimensional vector and the numerical value of the text block data into the latter several dimensions, then when comparing with other vectors in the future, as long as both parties of the comparison follow this "dimensional encoding rule", it can be ensured that the same type of data (category information or text block semantics) appears in the same dimensional paragraph, thereby achieving the same type of alignment and same-dimensional comparison. Therefore, when calculating the cosine similarity or Euclidean distance, each numerical value can be compared with the numerical value of the corresponding purpose, and there will be no meaningless mixing phenomenon that the first several dimensions are category information but the text block content of the latter several dimensions of the other party is mixed.
[0047] Selecting the leading dimension or trailing dimension in the first multidimensional vector as category information and text block data respectively has a more flexible scheduling significance in practice. If the system is designed to give priority to category information with the first few dimensions, and then to use the latter dimensions for text block content, then in all comparison operations, the beginning of these vectors will focus on the alignment of category labels (such as "default clause", "payment clause" and other information), while the tail dimension is the digital expression of the specific semantics of the text. Conversely, if the category information is arranged at the end of the first multidimensional vector, a similar alignment effect can be achieved, provided that all comparison vectors follow the same dimensional division rules. The advantage of this is that the dimension length occupied by the category, the dimension length occupied by the text block data, and the vectorization model used when generating or retrieving vectors can be adjusted according to different business needs to ensure that the dimensional division can accommodate all the required additional information (such as transaction amount, time node, etc.). At the same time, it can also leave a certain amount of expandable space for subsequent expansion to more label attributes or more complex semantic data.
[0048] It ensures that at the data structure level, the second multidimensional vector and the first multidimensional vector have the same dimensional position mapping; by excluding or weakening fields such as contract name and chapter information in the similarity or matching algorithm, it can focus on the "category information" and "text block data" dimensions that really need to be compared; it ensures that the similarity score will not be affected by differences in contract name or chapter information (which may be irrelevant to this comparison), thus avoiding the introduction of errors.
[0049] Specifically, the semantic meanings corresponding to the dimensions of the first multidimensional vector are first uniformly defined at the system level (e.g., the first dimension is category information, the second dimension is contract name information, the third dimension is chapter information, and the fourth dimension is text block data). Then, the second multidimensional vector containing only category information and text block data is filled with zero vectors or reserved placeholders in the missing contract name information and chapter information positions, so that the two types of vectors are consistent in the number and order of dimensions. At the same time, the weights of these two dimensional placeholder information can be selectively ignored or weakened when performing similarity calculations or retrievals to avoid interfering with the accurate comparison of the core semantics (category information and text block data); similarly, if the subsequent business scenarios need to use the contract name or chapter information, the real value can be filled in at any time and the corresponding comparison function can be enabled. Through this method, not only the unified dimensionality increase and controllable alignment of the second multidimensional vector are achieved, but also the flexibility and scalability are better taken into account in the overall system structure and subsequent processes.
[0050] In any of the above embodiments, the numerical size of the chapter information is set according to the position of the chapter information in the target contract. Since the chapter information itself has a sequential attribute in the target contract, the order of each text of the overall framework of the contract is more smooth by using the chapter information to attach the chapter information; the vector sequence is generated by the chapter information of the first multidimensional vector to ensure that the generated vector sequence essentially follows the description order in the target contract.
[0051] In this embodiment, by setting the numerical value corresponding to the chapter information according to the order of the chapter information in the target contract, the multi-dimensional vector obtained by vectorization processing can more directly reflect the structural order and hierarchical relationship of the contract text. In specific operations, the chapter information is not only regarded as a label or identifier to which the text belongs, but is also assigned a numerical value reflecting its position in the target contract. For example, when a certain text block corresponds to "Chapter 1", its chapter information value can be set relatively small; and if the text block belongs to "Chapter 5" or later chapters, its chapter information value can be increased in sequence. Through this scalar setting that gradually increases according to the order of chapters, the system can naturally present the order in which the text is arranged according to the original chapters of the contract when performing subsequent multi-dimensional vector comparison or sorting.
[0052] When it comes to contracts, if it is necessary to generate a new vector sequence or perform retrieval and comparison based on the structural order of each paragraph in the overall text, the numerical gradient of the chapter information will automatically give the text order a relative weight, thereby playing the role of "respecting the original contract chapter order" or "preserving the original text hierarchy" in the similarity calculation or vector sorting stage. In other words, whether the system aggregates, filters, and annotates text blocks, or automatically generates new contracts, the chapter information in the multidimensional vector will allow the sorting algorithm to give priority to the structural dimension of "chapter order", rather than just relying on the semantic similarity of the text block content.
[0053] By setting chapter information values that conform to the sequential attributes in the first multidimensional vector, it can be further ensured that the subsequently generated vector sequence fundamentally follows the intrinsic description order of the target contract. In many scenarios, the contract terms are not arranged in an arbitrary order, but are divided into chapters, sections, and clauses according to a certain legal or business logic. If the system organizes text blocks only based on semantic similarity, it may cause chapter misalignment and fail to reflect the original text hierarchy. However, with the help of the numerical expression of chapter numbers or related sequence values, the final vector sequence can take into account both semantic similarity and clause order, and present an arrangement that is closer to the original contract structure when the text blocks are further sorted or assembled.
[0054] S102, extracting feature information from the text to be processed and using it as a contract indicator, so as to extract key feature information of the text to be processed in the original contract, generating a label of the contract indicator according to the category to which each feature information belongs, and vectorizing each feature information and the corresponding label together to obtain a second multidimensional vector, so as to compare and search with the first multidimensional vector processed previously.
[0055] Here, first of all, it is necessary to identify and extract various key information closely related to the content of the contract, namely "feature information". In an actual scenario, these feature information may include but are not limited to: Party A's name, Party B's name, contract execution time, contract effective date, payment method, performance guarantee, responsibilities and obligations, breach of contract clauses, dispute resolution methods, etc. By performing natural language analysis or semantic understanding based on large language models (LLM) on the text to be processed (such as the original contract or the text paragraph that the present invention needs to pay attention to), the above-mentioned domain vocabulary, key phrases or sentences can be captured, thereby generating a series of "feature information" lists that can reflect the contract subject, core terms and indicator elements. For example, in a "software development service contract", element information such as "service delivery time", "acceptance criteria", "payment ratio" and "intellectual property ownership" may be identified; in a "purchase contract", feature information such as "quantity of goods", "specification parameters", "delivery period", "price and settlement method" and "after-sales service" may be identified.
[0056] These feature information identified from the text are regarded as contract indicators, and are subsequently labeled and vectorized. The reason for defining these feature information as contract indicators is mainly to quickly determine whether the target contract text (or the contract version to be reviewed) completely contains, accurately corresponds to, or fully reflects the above key elements in the subsequent steps. By abstracting the feature information into indicators, the system can use the same set of retrieval and matching mechanisms when processing different types of contracts, so as to achieve field-independent or multi-field expansion.
[0057] In order to enable the system to better organize, retrieve and compare various types of feature information in complex and ever-changing contract scenarios, this step will generate corresponding "contract indicator labels" according to the category to which each feature information belongs. The role of this label is to classify and structure the extracted feature information, so that the system can perform more targeted comparisons or reviews based on different label categories. For example: If the characteristic information is "Party A Company: ABC Co., Ltd.", it can be assigned a label such as "Party A" or "Subject Information"; If the characteristic information is "This contract shall take effect from March 1, 2025", it can be assigned a label such as "time" or "effective date"; If the characteristic information is "a penalty of one ten-thousandth of the contract amount shall be paid every day for overdue payment", it can be assigned labels such as "breach of contract clause" or "breach of contract liability".
[0058] Through this labeling method, the scattered elements in the contract text can be converted into a highly manageable list of indicators, and the processing logic for such indicators can be quickly called in the subsequent comparison process.
[0059] After completing the confirmation of the feature information and its label, this step continues to vectorize it. It is worth noting that here it is not just embedding the feature information or the label itself, but combining the two together for vectorization, so that the generated vector can cover the semantic information of both "feature content" and "label category" at the same time. Example: Assume that there is a feature information "Party A is Shanghai XX Technology Co., Ltd." and its label is "Party A". The system can first merge the two (such as "[Party A]: Shanghai XX Technology Co., Ltd."), and then input them into the selected vectorization model (such as BERT, Sentence-BERT or other Embedding models), so as to obtain a second multidimensional vector that can reflect the feature information and its label attributes. The second multidimensional vector here is not strictly two-dimensional (it may be hundreds or thousands of dimensions in numerical dimension), but refers to a semantic vector that integrates the two dimensions of "label information" and "feature information" at the logical level, which is used to compare with the first multidimensional vector generated in step S101. This common vectorization processing method ensures that in subsequent retrieval, it is possible to directly match whether there are similar or identical elements in the target text block based on the "label + feature information".
[0060] Each "second multidimensional vector of contract indicators" obtained in this step will be used as a subsequent query vector or comparison benchmark to perform similarity calculation, retrieval or matching with the "first multidimensional vector" generated for the target contract text block in step S101. In this way, the system can quickly and accurately locate the text position that best conforms to the semantics of the feature information in massive text blocks or multiple contract versions, and realize automated element review, omission detection or compliance verification. If the similarity between the vector corresponding to the contract indicator and the target contract text block vector reaches the threshold, it indicates that the text block fully or well reflects the required feature information; if the similarity is insufficient, it means that the text or contract content may be missing elements, missing clauses or inconsistent, and additional prompts or manual review are required during the review process.
[0061] As can be seen from the above, by combining feature information and its labels for vector processing, this step significantly improves the system's semantic recognition and management capabilities for various contract elements, laying a solid foundation for subsequent verification and review. The traditional manual review of contract terms is cumbersome and error-prone, while this step can use LLM or corresponding NLP technical means to automatically complete the identification and labeling of core information and dimensions, reduce a lot of repetitive work, and help legal personnel, project managers or auditors improve work efficiency. The feature information is uniformly managed through the label mechanism, and the same set of vectorized logic is used, which can be easily extended to contracts of different types or industries. The entire system process can be reused by simply setting corresponding labels and parsing rules for key features in different fields. In the entire LLM-based contract element extraction and review process, the extraction and labeling of feature information is a core pre-work. This step effectively links the text parsing, semantic analysis and review processes, enabling the system to concisely and accurately pass complex contract elements to the subsequent search, matching, review and report generation stages.
[0062] S103, searching for multiple first multidimensional vectors similar to the second multidimensional vector in the text vector database, and obtaining similarity through vectorized numerical difference calculation, sorting all second multidimensional vectors according to the first multidimensional vector to generate a vector sequence, so as to arrange the disordered second multidimensional vectors into the text narrative form expected by the target contract.
[0063] Here, after completing the above steps (S101 and S102), the first multidimensional vectors from multiple text blocks of the target contract have been saved in the text vector database. These vectors are usually high-dimensional vector representations obtained by semantic vectorization of the original text blocks by the pre-trained Embedding model. At the same time, in step S102, the feature information and its corresponding labels are vectorized to obtain the second multidimensional vector for retrieval or matching. In this step, the core work is to measure the similarity of these "second multidimensional vectors of contract indicators" one by one with the first multidimensional vector in the "text vector database" to find the text block vector closest to it and perform a certain sorting or arrangement.
[0064] Each contract indicator (including feature information and labels) that has been vectorized will generate an independent second multidimensional vector. At this time, the second multidimensional vector is regarded as a "query vector (Query Embedding)" and input into the retrieval interface of the text vector database. The text vector database usually adopts efficient vector retrieval technology, such as indexes constructed based on cosine similarity, Euclidean distance, inner product, etc. (such as FAISS, Milvus or other vector database technologies). When the query vector enters the retrieval system, it will compare the first multidimensional vectors of all text blocks in the database, and calculate the similarity scores with the query vector in turn according to the pre-set similarity calculation method (such as cosine similarity). By comparing the similarity or distance, a series of first multidimensional vectors that are closest to the query vector can be screened out. For example, the results with the highest similarity (or lowest distance) of the first N (such as the first 10 or the first 20) can be selected as candidate text blocks, and their similarity scores, index IDs and original text block information can be returned together. For example, if a contract indicator vector represents the element "Party B shall pay 50% of the contract amount within 30 working days after the delivery and acceptance are qualified", the text blocks with the highest similarity will be found in the text vector database during the search process. It may contain descriptions such as "For the payment method under this contract, Party A shall pay 50% within 30 days after the acceptance is completed", so as to match or compare the consistency or difference between this clause and the original contract text.
[0065] After obtaining the candidate results, the system will make a more refined measurement of the similarity or difference between the query vector (the second multidimensional vector) and the candidate text block vector (the first multidimensional vector). Common methods include: cosine similarity: calculate the cosine value of the angle between the two vectors (if the vectors have been L2 normalized, the inner product value can reflect the cosine similarity); Euclidean distance: calculate the distance between the vector differences in multidimensional space; Manhattan distance or other variants. According to these values, the candidate text blocks are arranged in descending or ascending order (depending on the definition of similarity or distance), and the text block that best reflects the semantics of the indicator is placed at the front for subsequent processing.
[0066] It is not only necessary to find the corresponding text block for a single contract indicator vector by similarity, but also to merge and sort "all second multidimensional vectors" to form a complete vector sequence. Since there may be dozens or even hundreds of contract indicators, the number of second multidimensional vectors corresponding to these indicators is also huge. For each second multidimensional vector, the text vector database will be searched to obtain the most similar text block vector and determine its similarity score. After merging the search results of all indicators, in order to arrange the originally scattered and disordered indicator vectors according to the expected text narrative order of the target contract, the system may adopt some comprehensive sorting strategies. For example: sorting according to the order of chapters appearing in the original contract; sorting according to the similarity score within the chapter; or directly sorting all second multidimensional vectors globally according to the similarity score, and making corresponding layouts according to the logical position of the original contract when displaying. For example, suppose that when the system searches for the indicator vector related to Party B's obligations, it finds that the text blocks closest to it are concentrated in Chapter 3 and Chapter 6 of the target contract; and when searching for the indicator vector related to Party A's rights, it has a higher similarity with the text vector of the clauses in Chapter 4. By arranging these search results in order, we can form a global perspective and quickly determine whether the target contract fully and consistently describes Party A's rights and Party B's obligations.
[0067] Combining the search of the first multidimensional vector and the overall sorting of the second multidimensional vector of the index, an ordered vector sequence is output. The vector sequence semantically corresponds to the narrative order expected by the original contract, or can be matched to a more reasonable arrangement of clauses in the generation of a new contract text, thereby achieving a logical and structured induction of the entire contract elements.
[0068] As can be seen from the above, through retrieval and sorting, the originally discrete and disordered feature indicators are matched one by one with the contract text blocks to avoid omissions or misalignment. After the matching results of all contract indicators are organized into a sequence, the degree of similarity can be used in subsequent steps to determine whether specific clauses are covered, or to mark potential omissions or conflicts. Automated sorting using numerical differences or similarities is more adaptable and scalable than traditional keyword-based or manual comparison methods. For legal personnel or project managers, the result list sorted by vector similarity can be presented intuitively, quickly locating the corresponding text blocks in the document for further review or revision.
[0069] S104, generating a contract to be reviewed based on a vector sequence with correct feature information in the document to be processed and text block data contained in the target contract, marking the feature information and / or text block data on the contract to be reviewed by the difference between the first multidimensional vector and the second multidimensional vector, and the marking can help the final manual review to determine whether there are any discrepancies between the text in the contract to be reviewed and the original contract, and whether there are any missing descriptions between the contract to be reviewed and the target contract.
[0070] Here, in the above steps (especially S103), a complete "correct vector sequence" has been generated based on the similarity calculation and sorting mechanism. At the semantic level, this sequence reflects the reasonable order or structure of the feature information that the text to be processed (i.e., the original contract or key contract indicators) should contain for the target contract. At the same time, the text vector database also retains multiple text block data of the target contract and its corresponding first multidimensional vector representation. This step first compares each second multidimensional vector in the correct vector sequence with the matching result between the first multidimensional vector of the target contract text block, and matches or merges them one by one, thereby constructing a new version of the contract text, i.e., the contract to be reviewed. For example, in a software development service contract case, it is assumed that the "correct vector sequence" contains vector tags of elements such as "service scope", "delivery and acceptance", "payment cycle", "intellectual property", "liability for breach of contract", and "dispute resolution"; at the same time, the text of the corresponding chapters is also recorded in the target contract text block. For example, in the chapter "Article 4 Delivery and Acceptance", there are several paragraphs describing the service delivery process. The correct vector sequence will be compared with the text vector corresponding to "Article 4" in the target contract for the "Delivery and Acceptance" part, and then the text content that meets the requirements will be combined and inserted into the specified position of the contract to be reviewed, so as to obtain a contract draft that is closer to the initial (or expected) contract specifications in terms of structure and clause order.
[0071] In steps S101 and S102, the "target contract text block data" and "text feature information to be processed (including labels)" have been vectorized respectively to obtain the first multidimensional vector and the second multidimensional vector. There must be differences in the dimensional values between the two: on the one hand, the semantic information of the text block itself covers a wider range or has redundancy; on the other hand, the vector expression of the feature information combined with the label may be more accurate and more targeted. By calculating the cosine similarity or other forms of numerical difference between the first multidimensional vector and the second multidimensional vector, it can be found which parts have a high degree of fit and which parts are missing or conflicting. The annotation methods include the following: Explicit highlighting or annotation: The locations with large differences are highlighted in red or marked with annotation boxes to remind the reviewer that there is a significant gap between the contract text and the ideal feature information and may need to be supplemented or corrected.
[0072] Similarity score annotation: A similarity score is added next to the paragraph with a high degree of fit to inform the reviewer of the extent to which the clause meets the original contract elements or business requirements. If the similarity is above a certain threshold, it means that the text is basically consistent with the established feature information; if it is below the threshold, it means that the clause here is not yet complete or there is a substantial difference from the original text.
[0073] Unified marking structure: In the document structure of the contract to be reviewed, a corresponding "contract indicator label" (such as "payment node" or "liquidated penalty") can be set for each characteristic information, and marked in the corresponding text block of the main text to facilitate subsequent quick retrieval and comparison.
[0074] For example, if the text to be processed (the original contract) requires "payment of 50% of the total contract amount within 30 working days after the project is completed", and the target contract text block states "payment of 10% within 15 working days after the project is accepted", the system will get a mismatch or low match score when calculating the similarity. Immediately, the contract to be reviewed will add a note such as [may be inconsistent with the original contract time limit and payment ratio] near the text, and mark it in red and prompt whether manual review is required to modify or supplement it.
[0075] In the legal or business environment, contract review still requires a lot of manual experience judgment and legal confirmation. By automatically marking the differences on the text of the contract to be reviewed in this step, legal personnel or project managers can intuitively see where the differences between the two versions are, whether there are any key clauses missing, and which clauses or indicators have been preserved intact. This visual assistance greatly reduces the workload of manual verification, making the review process more efficient and accurate. In actual scenarios, contracts often go through multiple revisions, additions or negotiation versions. The generation mechanism of the contract to be reviewed enables users to quickly integrate the key differences of each version into the same document view, marking the differences between each version and the initial expectations or other basic versions, avoiding the loss of important clauses or inadvertent modification of risk factors in multiple edits. By accurately marking the differences between the first multidimensional vector and the second multidimensional vector, potential risk points such as "lack of description of breach of contract liability", "unclear payment terms", "changes in performance guarantee terms" can be identified in a timely manner, and highlighted to relevant reviewers, so that enterprises or legal advisors can discuss and adjust in advance, rather than discovering problems after the contract officially takes effect. In addition, the marked information can be stored in a structured manner in the database to form data that can be used for subsequent statistics, mining or auditing. For example, the risk clauses marked in a large number of contracts can be aggregated and analyzed to find some common loopholes or controversial issues, providing a basis for the company's future contract template design.
[0076] From the above, it can be seen that the difference annotations on the contract to be reviewed can allow readers to understand the similarities or mismatches without switching back and forth between multiple documents, which greatly reduces repeated reading and comparison actions. With the help of automated annotation methods, subjective errors or neglects in manual clause comparison are reduced, providing more powerful tool support for rigorous legal review and project management. Compared with the traditional method of relying solely on keyword or string comparison, the present invention uses LLM vectorization technology for semantic analysis, and combined with difference marking, it can more accurately discover the deep meaning differences of the text, thereby generating more reliable contracts to be reviewed. This method is not only suitable for comparing different versions of the same contract, but can also be used to find differences in similar agreements or framework contracts, and mark their specific locations for quick modification, thereby improving the efficiency of contract clause reuse or derivative version management.
[0077] Specifically, the steps of generating a contract to be reviewed based on the vector sequence and text block data include: The contract template corresponding to the text to be processed is generated through the vector sequence. This contract template can be adaptively generated according to the specific content recorded in the original contract to avoid the interference of the rigid preset contract template on the current original contract. The text block data is filled into the corresponding position in the contract template to ensure that the content accurately recorded in the current original contract is included in the adaptive contract template.
[0078] In view of the above specific description, in the previous steps, the text blocks have been semantically segmented, structurally identified, and sequentially located through multidimensional vectors, and these feature information have been constructed into a vector sequence. This sequence not only reflects the basic attributes of each text block (such as category information, chapter information, tags, etc.), but also retains its semantic context and sequential context in the target contract. With this sequence, the system can automatically generate a "contract template" according to pre-set rules. The template is no longer a simple, fixed-format preset file, but is based on the distribution and content characteristics of the original contract clauses that are actually identified, and the chapters, clauses, and paragraphs are adaptively laid out.
[0079] Once the chapters and clauses of the adaptive contract template are confirmed, each text block can be accurately filled into the corresponding area of the template according to its category and order attributes according to the guidance of the text block in the vector sequence. For text blocks related to payment terms, they are automatically placed in paragraphs containing labels such as "payment method" or "fee settlement"; if the text block carries the "breach of contract clause" label, it will enter the "breach of contract liability" or "contract liability" paragraph.
[0080] Traditional pre-set contract templates are often a relatively fixed structure. For contracts in diverse scenarios or different industries, it is often difficult to meet the flexibility requirements, and conflicts or omissions may occur when they are integrated into the original contract text. By using adaptive templates generated by vector sequences, a balance can be found between "maintaining the original contract meaning and structural integrity" and "ensuring reasonable distribution of clauses and clear layout levels", which can significantly reduce the workload of manual sorting or comparison, and ensure that the contract text will not be interrupted, skipped, or miss key elements when adapting to the new layout.
[0081] As can be seen from the above, through a series of filling operations, the final generated contract to be reviewed reflects the general framework of the target contract in terms of format and order, and the clauses and terms are a collection of specific information, data or clause descriptions stated in the original contract text block. For legal personnel or audit departments, such a finished product not only retains the most important business and legal elements, but also allows for direct comparison, modification, signing and other work links in the new environment (such as the audit system, approval process or automated risk control platform) without having to re-format or copy and paste paragraph by paragraph, which is time-consuming and labor-intensive.
[0082] Specifically, the steps of generating a contract template corresponding to the text to be processed through a vector sequence include: The similarity between each second multidimensional vector and all corresponding first multidimensional vectors is calculated, and the first k first multidimensional vectors are sorted from high to low by retaining the similarity value. In the second multidimensional vector, only the similarity between the values of the two dimensions corresponding to the first multidimensional vector is calculated.
[0083] The contract name information and chapter information of the feature information of the text to be processed are determined through the k first multidimensional vectors of all the second multidimensional vectors, and the contract template is generated in conjunction with the vector sequence. The most identical contract name information and the most identical chapter information in all the currently selected first multidimensional vectors are used as the final mapping adjustment to ensure that the maximum probability of the selection fits the actual situation.
[0084] According to the above specific description, the similarity between each second multidimensional vector and all corresponding first multidimensional vectors is calculated. The second multidimensional vector can be regarded as the semantic expression of the current clause or feature element of the "text to be processed"; while the first multidimensional vector represents the high-dimensional vector representation of the text blocks, labels, chapters and contract names that already exist in the "target contract". In this process, the same type of dimensions (such as category information, text block data) of the two are aligned or mapped, and the cosine similarity, Euclidean distance and other methods are selected for calculation as needed. The purpose of this is: if a second multidimensional vector has a relatively higher similarity with a batch of first multidimensional vectors, it usually means that it is closer to the clauses, chapters or names represented by this batch of first multidimensional vectors in terms of category attributes or text block semantics. Based on this, a quantitative assessment can be made on whether the corresponding parts of the "text to be processed" and the "target contract" are similar.
[0085] When targeting vectors of multiple dimensions, you can selectively focus on comparing the most important or relevant dimensional information. Usually, some business scenarios only need to focus on the similarity of the two dimensions of "category information" and "text block data", and may temporarily ignore other dimensions (such as chapter information or contract name information) to avoid being disturbed by too many contextual elements in a specific process. This allows the system to first focus on judging the semantics and functional characteristics of the text entity itself, and then consider other factors such as chapter order or name consistency in subsequent steps. This is particularly suitable for use in the stage where the core content of the "text to be processed" is still uncertain and the closest clauses need to be found for verification.
[0086] From the above, we can see that by analyzing the similarity between each second multidimensional vector and all first multidimensional vectors, retaining the Top-k candidates, voting to select the most frequently appearing names and chapter information, and finally integrating them into the overall layout generated by the vector sequence, the system can efficiently locate the most matching target contract comparison information in a large amount of text, and ensure the accuracy and consistency of the contract name and chapter identification with a high probability. The "contract template for pending text" generated on this basis is also closer to the actual business needs, and plays a key role in promoting subsequent review, automated merging or revision, and realizes high flexibility adaptation to the contract scenario without a fixed template.
[0087] In any of the above embodiments, when processing the target contract, the text to be processed and the contract to be approved, text tasks are set respectively to determine the input data and output data of the language model.
[0088] In this embodiment, by setting different text task instructions for the extraction of contract indicators for "text to be processed" and the proofreading and verification of "contract to be verified", the system can generate the most effective semantic analysis and reasoning output in different scenarios with the help of a large language model. This structured instruction system of four elements, namely role-task-text-output format, fundamentally reduces the risk of the model "going off topic" or "misjudgment", allowing it to make more targeted reasoning about available information, and also making subsequent automated integration or review more orderly. At the same time, since each type of scenario can independently expand its task description and output format requirements, it can also ensure that the system is still highly flexible and scalable in large-scale applications.
[0089] Specifically, when performing contract indicators for text to be processed, the text tasks are as follows: Role definition: You are a contract indicator extraction expert; Task description: Please extract the contract indicators one by one from the given text and assign labels such as Party A, Party B, time, function, performance, etc. Text: Fill in the text block; Output format: Output item by item according to (indicator, category).
[0090] Specifically, when proofreading a contract to be reviewed, the text tasks are as follows: Role: You are a contract element verification expert; Indicators to be verified: fill in the indicators to be verified; Task description: Please read the target contract carefully and confirm whether its description meets the requirements of the indicators to be verified. Please provide an explanation and the most relevant text fragments of the indicator description. Target contract: / / Fill in the retrieved target contract text block; Output format: The output must include fields such as results, explanation, and the most relevant description of the target contract.
[0091] The present invention provides a contract element extraction and review method based on LLM, which can greatly improve the accuracy and speed of contract element processing while reducing the burden of manual comparison. It can also more accurately locate and match clauses through vectorized retrieval at the semantic level, reducing missed detections and false detections caused by simple keywords or rules, so that enterprises or legal departments have stronger scalability and consistency when processing large quantities or multiple versions of contracts, and also provides a solid technical foundation for the subsequent automatic generation of contract texts, compliance review and risk control.
[0092] The embodiment of the second aspect of the present invention proposes a device 2, such as Figure 4 As shown, the device 2 comprises: The text parsing and vectorization module 201 is used to receive and parse at least one target contract to obtain multiple text block data; perform vectorization processing on each text block data to generate a corresponding first multi-dimensional vector; and construct a text vector database based on the text block data and its corresponding first multi-dimensional vector.
[0093] The text index extraction module 202 is used to extract feature information from the text to be processed as a contract index; generate a corresponding label according to the category to which each feature information belongs; and perform vectorization processing on each feature information and the corresponding label to obtain a second multi-dimensional vector.
[0094] The indicator vector retrieval and sorting module 203 is used to retrieve multiple first multidimensional vectors that are semantically similar to the second multidimensional vector in the text vector database; and sort all the second multidimensional vectors according to the semantic similarity between the first multidimensional vector and the second multidimensional vector to generate a vector sequence.
[0095] The contract generation and annotation module 204 generates a contract to be approved according to the above vector sequence and the corresponding text block data; based on the difference information between the first multidimensional vector and the second multidimensional vector, annotates the corresponding feature information and / or text block data in the generated contract to be approved.
[0096] The device provided by the present invention combines text splitting, vector retrieval, element extraction and automatic generation closely. The present invention takes into account both high efficiency and high accuracy when dealing with scenarios of massive and diversified contracts. While ensuring the complete retention and flexible multi-dimensional management of key contract information, it also lays a solid technical foundation for the automation and traceability of contract review and clause verification.
[0097] Embodiments of the third aspect of the present invention provide electronic devices. In some embodiments of the present invention, such as Figure 5 As shown, an electronic device is provided, which includes: electronic devices such as desktop computers, notebooks, handheld computers, and cloud servers. The electronic device 3 may include but is not limited to a processor 301 and a memory 302. Those skilled in the art will understand that Figure 5 The electronic device 3 is merely an example and does not limit the electronic device 3 , and may include more or less components than those shown in the figure, or different components.
[0098] The processor 301 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.
[0099] The memory 302 may be an internal storage unit of the electronic device 3, for example, a hard disk or memory of the electronic device 3. The memory 302 may also be an external storage device of the electronic device 3, for example, a plug-in hard disk, a smart memory card (Smart Media Card, SMC), a secure digital (Secure Digital, SD) card, a flash card (FlashCard), etc. equipped on the electronic device 3. The memory 302 may also include both an internal storage unit of the electronic device 3 and an external storage device. The memory 302 is used to store computer programs and other programs and data required by the electronic device.
[0100] The embodiment of the fourth aspect of the present invention proposes a computer-readable storage medium. In some embodiments of the present invention, a computer-readable storage medium is provided, and when the computer-readable storage medium is executed by the processor 301, the steps of the above method are implemented. Therefore, the computer-readable storage medium provided by the fourth aspect of the present invention has all the technical effects of the above steps, which will not be repeated here.
[0101] The technicians in the relevant field can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional units and modules is used as an example for illustration. In practical applications, the above-mentioned function allocation can be completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiment can be integrated in a processing unit, or each unit can exist physically separately, or two or more units can be integrated in one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of software functional units. In addition, the specific names of the functional units and modules are only for the convenience of distinguishing each other, and are not used to limit the scope of protection of this application. The specific working process of the units and modules in the above-mentioned system can refer to the corresponding process in the aforementioned method embodiment, which will not be repeated here.
[0102] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this disclosure.
[0103] In the embodiments provided in the present disclosure, it should be understood that the disclosed devices / electronic devices and methods can be implemented in other ways. For example, the device / electronic device embodiments described above are merely schematic. For example, the division of modules or units is only a logical function division. There may be other division methods in actual implementation. Multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection of devices or units, which may be electrical, mechanical or other forms.
[0104] If the integrated module / unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the present disclosure implements all or part of the processes in the above-mentioned embodiment method, and can also be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium, and the computer program can implement the steps of the above-mentioned various method embodiments when executed by the processor. The computer program may include computer program code, and the computer program code may be in source code form, object code form, executable file or some intermediate form. The computer-readable medium may include: any entity or device capable of carrying computer program code, recording medium, U disk, mobile hard disk, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electric carrier signal, telecommunication signal and software distribution medium. It should be noted that the content contained in the computer-readable medium can be appropriately increased or decreased according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, the computer-readable medium does not include electric carrier signals and telecommunication signals.
[0105] The above embodiments are only used to illustrate the technical solutions of the present disclosure, rather than to limit them. Although the present disclosure has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present disclosure, and should all be included in the protection scope of the present disclosure.
Claims
1. A contract element extraction and review method based on LLM, characterized in that: The steps include: Parsing at least one target contract to obtain a plurality of text block data, vectorizing each of the text block data to obtain a first multi-dimensional vector, and constructing a text vector database through the text block data and the corresponding first multi-dimensional vector; Extracting feature information from the text to be processed and using it as a contract indicator, generating a label of the contract indicator according to the category to which each feature information belongs, and vectorizing each feature information and the corresponding label to obtain a second multidimensional vector; Searching the text vector database for a plurality of first multidimensional vectors that are close to the second multidimensional vector, and sorting all the second multidimensional vectors according to the first multidimensional vectors to generate a vector sequence; A contract to be reviewed is generated according to the vector sequence and the text block data, and the characteristic information and / or the text block data are marked on the contract to be reviewed by the difference between the first multidimensional vector and the second multidimensional vector.
2. The method for extracting and reviewing contract elements according to claim 1, characterized in that: The step of parsing at least one target contract to obtain a plurality of text block data comprises: Acquire the target contract to obtain text data, and extract contract framework information from the text data; The text data is divided to obtain a plurality of the text block data, and the contract framework information is added to each of the text block data.
3. The method for extracting and reviewing contract elements according to claim 2 is characterized in that: The contract framework information includes the contract name information of the target contract, the chapter information where the text block data is located, and the category information to which the text block data belongs.
4. The method for extracting and reviewing contract elements according to claim 3 is characterized in that: The step of vectorizing each of the text block data to obtain a first multi-dimensional vector comprises: The contract name information, the chapter information, the category information and the text block data are respectively converted into numerical values, and the first multidimensional vector is composed of the numerical values.
5. The method for extracting and reviewing contract elements according to claim 4 is characterized in that: The category information and the corresponding values of the text block data are located in the leading dimension or the trailing dimension in the dimensional position sorting of the first multidimensional vector.
6. The method for extracting and reviewing contract elements according to claim 4 is characterized in that: The numerical value of the chapter information is set according to the position of the chapter information in the target contract, and the vector sequence is generated by the chapter information of the first multidimensional vector.
7. The method for extracting and reviewing contract elements according to claim 3 is characterized in that: The step of generating a contract to be reviewed according to the vector sequence and the text block data comprises: A contract template corresponding to the text to be processed is generated through the vector sequence, and the text block data is filled into the corresponding position in the contract template.
8. The method for extracting and reviewing contract elements according to claim 7, characterized in that: The step of generating a contract template corresponding to the text to be processed through the vector sequence includes: Calculate the similarity between each of the second multidimensional vectors and all corresponding first multidimensional vectors, and sort the first k first multidimensional vectors by retaining the similarity values; The contract name information of the text to be processed and the chapter information of the characteristic information are determined through k first multidimensional vectors of all second multidimensional vectors, and the contract template is generated in conjunction with the vector sequence.
9. The method for extracting and reviewing contract elements according to any one of claims 1 to 8, characterized in that: When processing the target contract, the text to be processed and the contract to be approved, text tasks are respectively set to determine input data and output data of the language model.
10. A device for implementing the contract element extraction and review method according to any one of claims 1 to 9, characterized in that: include: A text parsing and vectorization module, used for receiving and parsing at least one target contract to obtain a plurality of text block data; Performing vectorization processing on each text block data to generate a corresponding first multi-dimensional vector; constructing a text vector database based on the text block data and its corresponding first multi-dimensional vector; The text index extraction module is used to extract feature information from the text to be processed as the contract index; generate corresponding labels according to the category to which each feature information belongs; and perform vectorization processing on each feature information and the corresponding label to obtain a second multi-dimensional vector; An indicator vector retrieval and sorting module is used to retrieve a plurality of first multidimensional vectors with semantic similarity to the second multidimensional vector in the text vector database; sort all the second multidimensional vectors according to the semantic similarity between the first multidimensional vector and the second multidimensional vector to generate a vector sequence; The contract generation and annotation module generates a contract to be reviewed based on the above-mentioned vector sequence and the corresponding text block data; based on the difference information between the first multidimensional vector and the second multidimensional vector, annotates the corresponding feature information and / or text block data in the generated contract to be reviewed.
Citation Information
Patent Citations
Automatic contract generation method and device, server, medium and product
CN114091415A
Contract classification method and system based on deep learning and related equipment
CN115905535A
Intelligent contract auditing method based on element extraction
CN118967068A
Content extraction-based contract intelligent auditing method and device, equipment and medium
CN119249109A
System and method for business intelligence through data-driven contract analysis
US20180315141A1
Cited By
EPC project engineering information extraction method and device, equipment and medium
CN120849603A
Methods, devices, equipment, and media for extracting engineering information from EPC projects.
CN120849603B
Bond product issuing document auditing method and system based on large model agent
CN121301577A
Contract element extraction method and related device
CN121542444A
Intelligent contract review system based on multi-agent collaborative tool enhanced orchestration
CN121685203A