A method and device for extracting and reviewing contract elements based on LLM

Abstract

The present invention belongs to the technical field of text data processing, and specifically discloses a contract element extraction and review method and device based on LLM, including: parsing a target contract to obtain text block data, vectorizing the text block data to obtain a first multidimensional vector, and constructing a text vector database; extracting feature information from the text to be processed and using it as a contract indicator, generating a label for the contract indicator according to the category to which the feature information belongs, and vectorizing the feature information and the corresponding label to obtain a second multidimensional vector; searching the text vector database for a first multidimensional vector similar to the second multidimensional vector, sorting all the second multidimensional vectors to generate a vector sequence; generating a contract to be reviewed according to the vector sequence and the text block data, and marking the contract to be reviewed according to the difference between the first multidimensional vector and the second multidimensional vector; the method has the following advantages: the indicators can be automatically extracted and a verification result including an explanation is given, which can significantly improve the work efficiency of project managers.

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 contract element extraction and review method and device based on LLM are proposed to solve the above problems. Summary of the Invention

[0004] The present invention aims to provide a contract element extraction and review method and device based on LLM 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 from the text to be processed and using it as a contract indicator, generating a label for 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; 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 based on 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, 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, 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, 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:

[0010] 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.

[0011] 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.

[0012] Using 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 filtering the search results, it can quickly find the most suitable clauses or indicator content, providing an efficient and flexible technical means for contract consistency verification and element comparison.

[0013] 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.

[0014] 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

[0015] The above and / or additional aspects and advantages of the present invention will become apparent and readily understood from the following description of the embodiments with reference to the accompanying drawings, in which:

[0016] Figure 1 is a flow chart of the method steps of the present invention;

[0017] Figure 2 This is the indicator verification flow chart of the present invention;

[0018] Figure 3 This is the indicator extraction flow chart of the present invention;

[0019] Figure 4 It is a logic block diagram of the device structure of the present invention;

[0020] Figure 5 The figure is a schematic structural diagram of an electronic device of the present invention. DETAILED DESCRIPTION

[0021] In order to more clearly understand the above-mentioned objects, 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, in the absence of conflict, the embodiments of the present application and the features therein can be combined with each other.

[0022] 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 scope of protection of the present invention is not limited to the specific embodiments disclosed below.

[0023] See also Figure 1-Figure 5 , the following describes a method and apparatus for extracting and reviewing contract elements based on LLM according to some embodiments of the present invention.

[0024] As described in the background art, the technical solutions of the prior art generally use the following steps when processing using a model:

[0025] a) Extracting indicators based on a sequence labeling algorithm: Extracting indicators from contracts is typically accomplished using a sequence labeling algorithm. This algorithm first collects labeled corpus, then trains a sequence labeling model based on the corpus. Finally, the model is applied to production to extract indicators.

[0026] b) Indicator Verification Based on Question-Answering Algorithms: During the indicator verification phase, question-answering is often used. First, relevant paragraphs are retrieved from the target contract based on the indicator to be verified. Then, both the indicator and the relevant paragraphs are fed into a question-answering model to generate the verification results. This model typically transforms whether the requirements are met into a binary text classification task, outputting a 1 for satisfied and a 0 for unsatisfied. Extractive question-answering is then used to locate the most relevant descriptions of the indicator in the contract to be verified.

[0027] The aforementioned existing solutions all require pre-training models, necessitating significant investment in data labeling. Furthermore, the trained model and labeled data are mutually exclusive, meaning the model can only achieve near-optimal performance in areas similar to the labeled data. In indicator verification algorithms, the model only has the ability to understand text and cannot interpret the results, significantly increasing the workload for manual reconfirmation.

[0028] In response to the above-mentioned technical problems, the embodiment of the first aspect of the present invention proposes a contract element extraction and review method based on LLM. In some embodiments of the present invention, such as Figure 1-Figure 3 As shown, the method includes the following steps:

[0029] S101: Parse at least one target contract to obtain multiple text blocks. Vectorize each text block to obtain a first multidimensional vector. Construct a text vector database using the text blocks and the corresponding first multidimensional vectors. The target contract contains text data in the format expected for the final contract. A mapping relationship is generated between the first multidimensional vector containing numerical values and the corresponding text blocks. This mapping relationship is then used to construct a text vector database to facilitate subsequent rapid retrieval of related text blocks.

[0030] Here, the target contract needs to be preliminarily parsed and segmented. At this stage, based on the understanding of the contract text, it will be segmented according to logical or structural features. Generally, the entire contract can be broken down into multiple relatively independent text blocks based on the contract's chapters, clauses, paragraph numbers, title structure, or pre-set keywords. For example, for a comprehensive contract that includes several procurement terms, payment methods, confidentiality agreements, and liability for breach of contract, 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 at 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.

[0031] After segmentation, the text blocks enter the preprocessing phase, which may involve natural language processing steps such as removing redundant characters, normalizing punctuation, filtering stop words, word segmentation, lemmatization, or synonym replacement to ensure that each block of text data is relatively clean and easy to process. For example, contracts containing a large number of legal terms and professional terms will be processed based on pre-trained legal lexicons or legal corpora to ensure that the correct meaning of these professional terms is captured during subsequent vectorization. In multilingual or mixed-language scenarios, language detection and special character conversion may also be required.

[0032] Next, a first multidimensional vector is generated for each preprocessed text block. Using a deep learning model or vectorization tool, the natural language text is mapped into a dimensionally controllable and semantically rich vector space. The present invention employs the Large Language Model (LLM) to capture word associations, contextual clues, and logical structure within the text block. By performing forward inference or embedding calculations on the text block, a set of vectors containing numerical features is generated. These features capture not only the key words in the text but also multiple layers of information, such as the overall semantics, syntactic structure, and even sentiment of the text. For example, if a section of the target contract primarily discusses elements such as "payment method," "phased settlement," and "contract amount limit," vectorization may place these concepts relatively close together in the vector space, facilitating subsequent retrieval and matching.

[0033] After the text block is vectorized, a one-to-one correspondence is established between the "original text block data" and the "corresponding first multidimensional vector," and these mappings are uniformly stored in a text vector database. This database not only stores the correspondence between text blocks and their vectors, but also records each text block's position in the original contract, paragraph number, associated clause title, and possible contextual information. 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 for similarity with an existing text block in the database, the query vector or new text can be found in a very short time by simply passing the same vectorization steps through the query vector or new text and then comparing it with the vectors in the database. This not only speeds up the location of relevant contract clauses or elements, but also makes automated contract review and comparison possible.

[0034] Notably, the construction of a text vector database also enables the unified management of large-scale contract data. When processing multiple, or even hundreds or thousands, of contracts, this database structure can accommodate vector representations of large blocks of text and support distributed retrieval and indexing, fully leveraging the powerful semantic understanding capabilities of LLM. Whether users need to verify the expected text format of a contract or conduct compliance checks on key elements, the text vector database enables efficient batch operations and automated comparisons.

[0035] As can be seen from the above, the text vector database constructed based on this processing constitutes the underlying foundation of the present invention for contract element extraction and review. By meticulously 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 blocks, an effective method 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 level of automation and intelligence in the contract review and management process.

[0036] Specifically, the step of parsing at least one target contract to obtain a plurality of text block data includes:

[0037] Obtain the target contract to obtain text data, and extract the contract framework information from the text data.

[0038] The text data is segmented to obtain multiple text block data. Since LLM generally has a word limit for text input, too long input will also reduce the accuracy of the model output. Therefore, the entire text data is first segmented into multiple text blocks of appropriate length; the contract framework information is added to each text block data so that the text block data can retain the relevant information in the original target contract.

[0039] Regarding the specific description above, the primary goal of acquiring text data from a target contract is to convert all textual content into plain text or a readable format suitable for subsequent processing. This typically involves parsing or converting the contract document to extract continuous character data from any common document format (e.g., an electronic document or image). This step focuses on maintaining the integrity of the contract text and preserving as much underlying structural information as possible, such as section headings, page numbers, paragraph numbers, or other clues that help identify the text's organization. This rigorous acquisition of text data allows subsequent natural language processing or large-scale language model processing to be performed on a relatively clean and structured basis.

[0040] 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 arrange clauses or chapters in a certain logical order, if they are simply regarded as a disordered stream of text, 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 the contract title, document description, contract party identification, clause serial number, etc., so that in subsequent processing links, it is easier to trace back to the location or paragraph context of the specific clause.

[0041] Next, since large language models often have certain restrictions on the length of input text, and excessively long input content may lead to a decrease in the model's recognition accuracy or inference efficiency, it is necessary to first clarify the segmentation strategy when segmenting 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, the text can be segmented at the line breaks or paragraph breaks that come with the text, and try to avoid splitting a sentence or clause with complete meaning across blocks. Segmentation in this way can reduce the interference caused by excessive size of a single text block, allowing the model to focus more on processing local semantics and retaining necessary contextual information to avoid large amounts of duplication or omissions when merging results.

[0042] After chunking, contract framework information is added to each text chunk's data, further enhancing the accuracy and convenience of subsequent analysis, retrieval, and review. Instead of being stored separately in an external structure, contract framework information is embedded at the beginning of the corresponding text chunk, at a specific identifier, or at another appropriate location. This ensures that each text chunk, when used or transmitted independently, still carries the source, clause number, section name, or other contextual information that may guide the model's semantic understanding. This not only provides contextual inference hints when subsequently invoking a large language model, but also enables more efficient search and traceability when the text chunk data is stored in a vector database or other retrieval system, based on the retained framework information. The combination of chunking and metadata requires careful attention to the logical organization of the text to ensure that the contract body can be reassembled or mapped back to its original chapter order when necessary.

[0043] As can be seen above, by acquiring the target contract, extracting the framework information, performing appropriate text segmentation, and supplementing each segment with sufficient metadata, the structured context of the original contract can be preserved to the greatest extent possible, providing a viable and accurate corpus source for subsequent steps such as feature extraction, vectorized storage, semantic matching, and annotation review. In this process, any neglect of the contract framework information or arbitrary segmentation of the text can make it difficult for the model to understand the logical connections between clauses or result in information loss. However, the meticulous segmentation and information embedding described above significantly reduces the probability of such issues and improves processing efficiency and quality.

[0044] 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.

[0045] In this embodiment, contract name information refers to a type of identification data that can clearly identify the entire contract or document source. This information can be a procurement contract for a project, a cooperation agreement between companies, or a document title with specific descriptions such as time or company name. Attaching contract name information to a text block allows subsequent processing models or retrieval systems to distinguish between different contract sources. Even when processing multiple documents, it is easy to determine the specific contract to which each text block belongs. In practice, if large-scale element extraction or review is performed on various contracts, without clear contract name information, it is difficult to effectively trace the specific document to which the text block belongs. Therefore, this information is particularly essential when processing multiple contract environments (such as batch audits or centralized archiving). It not only improves the model's understanding of the text's meaning but also allows subsequent manual review to quickly locate the source of the text block, ensuring data traceability and relevance.

[0046] The chapter information for a text block is a further structural identifier, reflecting the exact location of the text block within the contract's content hierarchy. Contracts typically organize clauses, provisions, and details into chapters, sections, articles, or clauses. Simply breaking a contract into fragments without documenting their contextual relationships at the chapter level can easily lead to ambiguity in subsequent analysis or overlook structural logic. For example, in some contract clauses, "Chapter 3 Payment Agreement" and "Chapter 4 Confidentiality and Intellectual Property" may have vastly different scopes. Without chapter information, the model cannot immediately determine the location of the text block when processing it, and thus cannot use other semantic connections to clarify the context of the text block. Adding chapter information allows the model to initially determine whether the text block it is processing is related to the "Payment Terms" or "Rights and Obligations" section during input. This information can serve as a prompt or guide during the model's understanding or generation process, ensuring that the model's output more closely matches the structural requirements of real contracts.

[0047] Category information for text chunks helps categorize and manage them at a higher level. This category information is typically based on the functional divisions of contract content or general legal clause classifications, and may include tagged descriptions such as "liability for breach of contract," "payment clause," "confidentiality obligation," and "dispute resolution mechanism." Appropriately labeling text chunks allows the system to quickly filter or focus on them during subsequent processing. For example, if an auditor only wants to review the contract's fee or payment clauses, they can directly search or filter for chunks of text in the corresponding category without having to search through the entire contract. Category information can also provide a more explicit contextual cue for large language models. For example, when a model receives a chunk of text labeled "confidentiality clause," it is more likely to associate it with key points such as confidentiality obligations, responsibility boundaries, and classification levels during semantic analysis or answer generation, resulting in more accurate or targeted results. Conversely, without this category information, even the most accurate language models will require more computational and reasoning steps to guess at the functional attributes of the text.

[0048] Specifically, the step of vectorizing each text block data to obtain a first multi-dimensional vector includes:

[0049] 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.

[0050] Regarding the specific description above, the digitization of "contract name information" often includes a basic understanding of the contract's identity, such as the contract's business area, the names of the signatories, or the type of collaboration implied by the contract title. By processing this textual content through appropriate embedding algorithms or other numerical representation models, the system can retain the "semantic fingerprint" of this information when generating the first multidimensional vector. This has the advantage that when a text block needs to be mapped back to its source contract, or when comparing text blocks of the same type across multiple contracts, the "context" and "business tags" carried by the contract name can provide additional differentiation between the text blocks in vector space. For example, if the system needs to distinguish between certain common clauses in a "procurement contract" and a "technology development contract," the distinguishing information carried by the contract name will help the vector search engine more accurately classify these text blocks using cosine similarity or vector distance calculations, making them more suitable for on-demand combination or splicing.

[0051] The digitization of chapter information maps the organizational position of text blocks within the overall contract hierarchy into numerical features that can be understood and utilized by the model. Chapter information plays a highly structural role in many contracts: from general provisions, definitions, and responsibilities to confidentiality clauses, payment procedures, and dispute resolution, different chapters often present a clear and logical thread. By vectorizing this information and integrating it with the core content of the text block into a single fusion vector, the system can more accurately determine during the search phase whether the context or subject matter of the text block aligns with the query. It also helps when generating new contracts, allowing text blocks within the same chapter to be quickly combined with fewer trial-and-error steps, thereby preserving the coherence of the contract structure. In particular, when aggregating, comparing, or selecting clauses with the same theme or chapter across multiple contract source documents, the "hierarchical identification" provided by chapter information makes vector comparisons more targeted and reduces noise in search results.

[0052] 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", into 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 distinguished more finely through category labels. On the contrary, if there are two text blocks in different contracts that are both labeled "breach of contract clause", 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 subsequently, 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.

[0053] Numerization of text block data involves transforming the natural language content of a text block into a vector in a high-dimensional semantic space through models such as embedding. This vector often incorporates rich information dimensions such as vocabulary choice, syntactic structure, semantic associations, and contextual clues. The vectorization of text block data opens up truly intelligent possibilities for contract review, feature extraction, and contract generation. It can not only be used as the basis for semantic similarity calculations but can also be combined with the aforementioned contract name, section information, and category information to form a more comprehensive first-dimensional vector, allowing retrieval to simultaneously consider the semantic content of the text block as well as its external labels and structural position. This combination has the effect of: even if two texts are very similar in language, but belong to different sections or categories, the system can separate them in the vector space. Alternatively, when texts differ slightly in linguistic expression but have highly consistent labels and structural information, the system can improve their correlation in search ranking.

[0054] As can be seen from the above, a numerical representation mechanism compatible with multidimensional attributes has been established for original contracts or multiple original documents that lack standardized templates. This allows subsequent applications based on LLM or other semantic retrieval algorithms to easily link text content with contract structure information, providing strong technical support for further review, clause comparison, feature extraction, automatic draft generation, and even compliance checks. In this vectorization strategy for multidimensional information fusion, each text block not only carries its own content but also carries clear contextual clues, minimizing data confusion caused by disorganized text or multi-source documents. Ultimately, this provides a highly flexible and scalable operating environment for contract generation or review in different scenarios.

[0055] In any of the above embodiments, the corresponding values of the category information and text block data are in the leading dimension or 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 trailing dimension in the first multidimensional vector as the category information and text block data, so that the corresponding values of the same data can be compared when comparing vectors of different dimensions.

[0056] In this embodiment, when sorting the dimensional positions of the first multidimensional vector, it is necessary to clearly define how the category information and text block data are positioned within the entire vector. The first multidimensional vector can be considered a fixed-length numerical sequence, with sequence indices corresponding to different semantics or data sources from the beginning to the end. Assuming the system assigns the category information values to the first several dimensions of the first multidimensional vector and the text block data values to the last several dimensions, when subsequently compared with other vectors, as long as both comparisons adhere to this "dimensional encoding rule," data of the same type (category information or text block semantics) will appear in the same dimensional segments, thus achieving similar alignment and same-dimensional comparison. Therefore, when calculating cosine similarity or Euclidean distance, each value can be compared with the corresponding value, eliminating the situation where the category information in the first several dimensions is mixed with the text block content in the last several dimensions.

[0057] Choosing the leading or trailing dimensions of the first multidimensional vector as category information and text block data, respectively, offers greater flexibility in practical applications. If the system design prioritizes the first few dimensions for category information and the last few for text block content, then in all comparison operations, the leading dimensions of these vectors will focus on aligning the category labels (e.g., "default clause," "payment terms," etc.), while the trailing dimensions will represent the numeric representation of the text's specific semantics. Conversely, placing the category information at the end of the first multidimensional vector can achieve a similar alignment, provided all comparison vectors follow the same dimensionality partitioning rules. This approach offers the advantage of adjusting the dimension lengths occupied by categories and text block data, as well as the vectorization model used when generating or retrieving vectors, to meet different business needs, ensuring that the dimensionality partitioning can accommodate all required additional information (e.g., transaction amount, time point, etc.). This also leaves room for future expansion to include more label attributes or more complex semantic data.

[0058] This 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, we can focus on the "category information" and "text block data" dimensions that really need to be compared. This ensures that the similarity score will not be affected by differences in contract name or chapter information (which may be insignificant to this comparison), thus avoiding the introduction of errors.

[0059] Specifically, the semantic meaning corresponding to each dimension of the first multidimensional vector is 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). Subsequently, the second multidimensional vector, which contains only category information and text block data, is filled with zero vectors or reserved placeholders in the positions of missing contract name and chapter information, ensuring that the two vectors maintain consistency in the number and order of dimensions. Furthermore, the weight of these two placeholders can be selectively ignored or weakened during similarity calculations or retrieval to prevent them from interfering with the accurate comparison of the core semantics (category information and text block data). Similarly, if subsequent business scenarios require the use of contract name or chapter information, the actual values can be filled in and the corresponding comparison function can be enabled at any time. This approach not only achieves unified dimensionality upgrade and controllable alignment of the second multidimensional vector, but also better balances flexibility and scalability within the overall system structure and subsequent processes.

[0060] 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 the various texts of the overall contract framework 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.

[0061] 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 that reflects its position in the target contract. For example, when a certain text block corresponds to "Chapter 1", the numerical value of its chapter information can be set to be relatively small; and if the text block belongs to "Chapter 5" or later chapters, the numerical value of its chapter information 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.

[0062] When generating new vector sequences, searching, and comparing contracts based on the structural order of each paragraph within the overall text, the numerical gradients of the chapter information automatically assign relative weights to the text order, thereby ensuring that the original contract chapter order is respected or the original text hierarchy is preserved during similarity calculations or vector sorting. This means that whether the system later aggregates, filters, or annotates text blocks, or automatically generates new contracts, the chapter information in the multidimensional vectors allows the sorting algorithm to prioritize the structural dimension of "chapter order," rather than relying solely on the semantic similarity of the text blocks.

[0063] 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 inherent 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 based solely on semantic similarity, it may cause chapter misalignment and fail to reflect the original text hierarchy. However, with the help of numerical expressions of chapter numbers or related sequential values, the final vector sequence can take into account both semantic similarity and clause order, and when the text blocks are further sorted or assembled, it presents an arrangement that is closer to the original contract structure.

[0064] S102: Extract feature information from the text to be processed and use it as a contract indicator to extract key feature information of the text to be processed in the original contract, generate a label of the contract indicator according to the category to which each feature information belongs, and vectorize each feature information and the corresponding label together to obtain a second multidimensional vector for comparison and search with the first multidimensional vector processed previously.

[0065] First, it's necessary to identify and extract key information closely related to the contract content, known as "feature information." In a real-world scenario, this feature information may include, but is not limited to, the names of Party A and Party B, the contract execution date, the contract's effective date, payment methods, performance bonds, responsibilities and obligations, breach of contract clauses, and dispute resolution methods. By performing natural language analysis or semantic understanding based on large language models (LLMs) on the text to be processed (such as the original contract or the text paragraph of interest in this invention), we can capture these domain terms, key phrases, or sentences, thereby generating a list of "feature information" that reflects the contract's main body, core terms, and indicative elements. For example, in a software development service contract, we might identify elements such as "service delivery time," "acceptance criteria," "payment ratio," and "intellectual property ownership." In a procurement contract, we might identify features such as "quantity of goods," "specifications," "delivery deadline," "price and settlement method," and "after-sales service."

[0066] These characteristic features identified from the text are treated as contract indicators and subsequently subjected to labeling and vectorization. The purpose of defining these characteristic features as contract indicators is to quickly determine, in subsequent steps, whether the target contract text (or the version of the contract to be reviewed) completely contains, accurately corresponds to, or fully embodies the aforementioned key elements. By abstracting these characteristic features into indicators, the system can utilize the same retrieval and matching mechanisms when processing different types of contracts, enabling both domain-agnostic and multi-domain scalability.

[0067] To enable the system to better organize, retrieve, and compare various types of feature information in complex and ever-changing contract scenarios, this step generates corresponding "contract indicator tags" based on the category to which each feature information belongs. The purpose of this tag is to categorize and structure the extracted feature information, allowing the system to perform more targeted comparisons or reviews based on different tag categories. For example:

[0068] If the characteristic information is "Party A Company: ABC Co., Ltd.", it can be assigned a label such as "Party A" or "Subject Information";

[0069] If the characteristic information is "This contract takes effect on March 1, 2025", it can be assigned a label such as "time" or "effective date";

[0070] If the characteristic information is "a penalty of one ten-thousandth of the contract amount shall be paid daily for overdue payment", it can be assigned labels such as "breach of contract clause" or "breach of contract liability".

[0071] 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.

[0072] 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 the embedding of the feature information or the label itself, but the two are combined together for vectorization, so that the generated vector can simultaneously cover the semantic information of both "feature content" and "label category". Example: Suppose 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 model), thereby obtaining a second multidimensional vector that can reflect the feature information and its label attributes. The second multidimensional vector here is not strictly speaking only two-dimensional (it may be hundreds or thousands of dimensions in terms of 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 for comparison with the first multidimensional vector generated in step S101. This joint vectorization processing method ensures that in subsequent retrieval, the presence of similar or identical elements in the target text block can be directly matched based on "label + feature information".

[0073] 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 at that location may have missing elements, missing clauses or inconsistencies, and additional prompts or manual review are required during the review process.

[0074] As can be seen above, by combining feature information and its labels for vectorization, 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. Traditional manual review of contract terms is cumbersome and error-prone. However, this step utilizes LLM or corresponding NLP technologies to automatically identify and label core information and dimensions, reducing repetitive work and improving the efficiency of legal personnel, project managers, and auditors. This unified management of feature information through a labeling mechanism and the use of a common vectorization logic allows for easy scalability to contracts of different types or industries. Simply by setting corresponding labels and parsing rules for key features in different fields, the entire system process can be reused. Extracting and labeling feature information is a core prerequisite for the entire LLM-based contract element extraction and review process. This step effectively links the text parsing, semantic analysis, and review processes, enabling the system to concisely and accurately convey complex contract elements to the subsequent search, matching, review, and report generation stages.

[0075] S103, searching for multiple first multidimensional vectors similar to the second multidimensional vector in the text vector database, and obtaining similarity through numerical difference calculation after vectorization, 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.

[0076] Here, after completing the aforementioned steps (S101 and S102), first multidimensional vectors from multiple text blocks of the target contract have been stored in the text vector database. These vectors are typically high-dimensional vector representations obtained by semantically vectorizing the original text blocks using a pre-trained embedding model. Simultaneously, in step S102, the feature information and its corresponding labels are vectorized to obtain second multidimensional vectors for retrieval or matching. The core task in this step is to measure the similarity of these "second multidimensional vectors of contract indicators" against the first multidimensional vectors in the "text vector database" one by one, in order to find the closest text block vectors and perform a certain sorting or organization.

[0077] Each vectorized contract metric (including feature information and labels) generates a separate second multidimensional vector. This second multidimensional vector is then treated as a "query embedding" and input into the search interface of the text vector database. Text vector databases typically utilize efficient vector retrieval technologies, such as indexes based on cosine similarity, Euclidean distance, inner product, and other methods (e.g., FAISS, Milvus, or other vector database technologies). Once the query vector enters the search system, it compares the first multidimensional vectors of all text blocks in the database and calculates similarity scores with the query vector using a pre-defined similarity calculation method (e.g., cosine similarity). By comparing similarities or distances, a series of first multidimensional vectors that are most similar to the query vector can be selected. For example, the top N (e.g., top 10 or top 20) text blocks with the highest similarity (or lowest distance) can be selected as candidate text blocks, and their similarity scores, index IDs, and original text block information can be returned. For example, if a contract indicator vector represents the element "After Party B completes delivery and acceptance, Party A shall pay 50% of the contract amount within 30 working days," the search process will find the text blocks with the highest similarity in the text vector database. This may include a description such as "Regarding the payment method under this contract, Party A shall pay 50% within 30 days after completion of acceptance," thereby matching or comparing this clause with the original contract text to identify any similarities or differences.

[0078] After obtaining candidate results, the system then performs 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: calculating the cosine of the angle between two vectors (if the vectors have been L2-normalized, the inner product can represent cosine similarity); Euclidean distance: calculating the distance between vector differences in multidimensional space; Manhattan distance or other variations. Based on these values, the candidate text blocks are sorted in descending or ascending order (depending on the definition of similarity or distance), with the text block that best reflects the semantics of the metric placed first for subsequent processing.

[0079] Not only does the system use similarity to find the corresponding text block for each contract indicator vector, but it also merges and sorts all second-dimensional vectors to form a complete vector sequence. Since contract indicators can number in the tens or even hundreds, the number of corresponding second-dimensional vectors is correspondingly large. For each second-dimensional vector, the system searches the text vector database to obtain the most similar text block vector and determines its similarity score. After merging the search results for all indicators, the system may employ a variety of comprehensive sorting strategies to align the previously scattered and disorganized indicator vectors with the target contract's expected textual narrative order. For example, the system may prioritize sorting by the order of their appearance in the original contract; perform secondary sorting within each chapter based on similarity scores; or perform a global sorting of all second-dimensional vectors based on similarity scores, with the display layout then aligning with the original contract's logical placement. For example, suppose the system searches for indicator vectors related to Party B's obligations and finds that the most similar text blocks are concentrated in Chapters 3 and 6 of the target contract. However, when searching for indicator vectors related to Party A's rights, the system finds that the text vectors for the clauses in Chapter 4 are highly similar. By arranging these search results in order, we can form a global perspective and quickly determine whether the target contract provides a sufficient and consistent description of Party A's rights and Party B's obligations.

[0080] Combining the search of the first multidimensional vector and the overall sorting of the second multidimensional vector of indicators, an ordered vector sequence is output. This vector sequence semantically corresponds to the expected narrative order of the original contract, or can be matched with a more reasonable arrangement of clauses in the generated new contract text, thereby achieving a logical and structured induction of the entire contract elements.

[0081] As can be seen above, through retrieval and sorting, previously discrete and unordered feature indicators are matched one-to-one with contract text blocks, avoiding omissions or misalignments. After organizing the matching results of all contract indicators into a sequence, subsequent steps can use the level of similarity to determine whether specific clauses are covered, or to identify potential omissions or conflicts. Automated sorting based on 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 intuitively presented, allowing them to quickly locate the corresponding text block in the document for further review or revision.

[0082] S104, generating a contract to be verified based on the correct vector sequence of feature information in the document to be processed and the text block data contained in the target contract, marking the feature information and / or text block data on the contract to be verified through the difference between the first multidimensional vector and the second multidimensional vector. The marking can help the final manual review to determine whether there are any discrepancies between the text in the contract to be verified and the original contract, and whether there are any missing descriptions between the contract to be verified and the target contract.

[0083] In the aforementioned steps (particularly S103), a complete "correct vector sequence" has been generated based on the similarity calculation and sorting mechanism. This sequence, at the semantic level, reflects the reasonable order or structure of the characteristic information that the target contract should contain in the text to be processed (i.e., the original contract or key contract indicators). Furthermore, the text vector database also contains multiple text blocks of the target contract and their corresponding first multidimensional vector representations. This step first compares each second multidimensional vector in the correct vector sequence with the first multidimensional vector of the target contract text block, mapping them one-to-one or fusing them to construct a new contract text version, i.e., the contract to be verified. For example, in a software development service contract, assume that the "correct vector sequence" contains vector markers for elements such as "Service Scope," "Delivery and Acceptance," "Payment Cycle," "Intellectual Property," "Breach of Contract Liability," and "Dispute Resolution." Furthermore, the target contract text block also contains the text of the corresponding sections. For example, section "Article 4: Delivery and Acceptance" contains several paragraphs describing the service delivery process. The correct vector sequence for the "Delivery and Acceptance" section will be compared with the text vector corresponding to "Article 4" in the target contract. The text content that meets the requirements will then be combined and inserted into the designated location of the contract to be reviewed, thereby obtaining a contract draft that is closer to the original (or expected) contract specifications in terms of structure and clause order.

[0084] 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 has a wider coverage or is redundant; on the other hand, the vector expression of the feature information combined with the label may be more accurate and more targeted. By performing cosine similarity calculation or other forms of numerical difference calculation on 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 methods:

[0085] Explicit highlighting or annotation: Highlight locations with large discrepancies in red or mark them with annotation boxes to alert the reviewer that there is a significant discrepancy between the contract text and the ideal feature information, and that supplementation or correction may be required.

[0086] Similarity Score Annotation: A similarity score is added next to paragraphs with high alignment to inform reviewers of the extent to which the clause meets the original contract elements or business requirements. If the similarity score is above a certain threshold, it indicates that the text is generally consistent with the established feature information; if it is below the threshold, it indicates that the clause is incomplete or has substantial differences from the original text.

[0087] Unified tagging 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.

[0088] For example, if the pending contract (the original contract) requires "50% of the total contract amount to be paid within 30 working days after project completion," while the target contract specifies "10% to be paid within 15 working days after project acceptance," the system will calculate a mismatch or low match score. The pending contract will then be labeled "may not match the original contract's timeframe and payment ratio" near that section of text, highlighting it in red and prompting a manual review to determine if any modifications or additions are required.

[0089] In legal and business settings, contract review still requires extensive manual judgment and legality verification. This step automatically annotates differences in the contract text for review, allowing legal personnel or project managers to visually identify differences between two versions, identify key omissions, and identify which clauses or specifications have been fully preserved. This visual aid significantly reduces manual verification workload, making the review process more efficient and accurate. In real-world scenarios, contracts often undergo multiple revisions, additions, or negotiations. The mechanism for generating contracts for review allows users to quickly consolidate key differences across versions into a single document view, highlighting the differences between each version and the initial expectations or other baseline versions. This prevents the loss of important clauses or the inadvertent modification of risk factors during multiple edits. By accurately annotating the differences between the first and second multidimensional vectors, potential risk points, such as "missing description of breach of contract liability," "unclear payment terms," and "changes to performance bond terms," can be promptly identified and highlighted to relevant reviewers, allowing companies or legal advisors to discuss and adjust issues beforehand, rather than discovering them after the contract has officially come into effect. Furthermore, the annotated information can be stored in a structured database, generating data that can be used for subsequent statistics, mining, or auditing. For example, an aggregate analysis of annotated risk clauses in a large number of contracts can be performed to identify common loopholes or points of contention, providing a basis for the company's future contract template design.

[0090] From the above, it can be seen that the difference annotation 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 the repeated reading and comparison actions. With the help of automated annotation methods, the subjective mistakes or neglects of manual labor in 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.

[0091] Specifically, the steps for generating a contract to be reviewed based on the vector sequence and text block data include:

[0092] A contract template corresponding to the text to be processed is generated through a vector sequence. This contract template can be adaptively generated based on the specific content of the original contract to avoid interference with the current original contract caused by a rigid preset contract template. 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.

[0093] In the previous steps, multidimensional vectors were used to semantically segment, structurally identify, and sequentially locate text blocks. This feature information was then constructed into a vector sequence. This sequence not only reflects the basic attributes of each text block (such as category information, chapter information, and tags), but also preserves its semantic context and sequential context within the target contract. Leveraging this sequence, the system automatically generates a "contract template" based on pre-defined rules. This template is no longer a simple, fixed-format preset document, but rather adaptively arranges chapters, clauses, and paragraphs based on the distribution and content characteristics of the identified original contract clauses.

[0094] Once the sections and clauses of the adaptive contract template are determined, the vector sequence guides each text block, accurately populating the corresponding area of the template according to its category and order attributes. Text blocks related to payment terms are automatically placed in paragraphs labeled "Payment Method" or "Fee Settlement." Text blocks labeled "Breach of Contract Clause" are placed in the "Breach of Contract Liability" or "Contractual Liability" paragraphs.

[0095] Traditional pre-built contract templates often have a relatively fixed structure. This often fails to meet the flexibility requirements for contracts in diverse scenarios or across different industries, and can lead to conflicts or omissions when integrated into the original contract text. By utilizing adaptive templates generated using vector sequences, a balance can be struck between maintaining the integrity of the original contract's meaning and structure while ensuring a reasonable distribution of clauses and a clear layout. This significantly reduces the workload of manual collation and comparison, while ensuring that the contract text adapts to the new layout without clutter such as broken sentences, skipped paragraphs, or missing key elements.

[0096] As can be seen above, through a series of fill-in operations, the final contract for review reflects the target contract's broad outlines in terms of format and sequence, while the clauses incorporate the specific information, data, or clause descriptions contained in the original contract text block. For legal personnel or review departments, this final product not only preserves the most important business and legal elements but also allows for direct comparison, modification, and signing within new environments (such as audit systems, approval processes, or automated risk control platforms), eliminating the need for time-consuming and laborious re-formatting or copy-and-pasting of individual clauses.

[0097] Specifically, the steps of generating a contract template corresponding to the text to be processed through a vector sequence include:

[0098] Calculate the similarity between each second multidimensional vector and all corresponding first multidimensional vectors, sort from high to low, and sort the first k first multidimensional vectors by retaining the similarity value. In the second multidimensional vector, only calculate the similarity between the values of the two dimensions corresponding to the first multidimensional vector.

[0099] The contract title and chapter information of the document to be processed are determined using the k first multidimensional vectors of all second multidimensional vectors, and the contract template is generated using the vector sequence. The contract title and chapter information with the most common matches among all currently selected first multidimensional vectors are used as the final mapping adjustment to ensure the highest probability of matching the actual situation.

[0100] Regarding the specific description above, the similarity between each second multidimensional vector and all corresponding first multidimensional vectors is calculated. The second multidimensional vector can be considered a semantic expression of the current clause or feature element of the "unprocessed document." The first multidimensional vector, on the other hand, represents a high-dimensional vector representation of existing elements in the "target contract," such as text blocks, tags, sections, and contract names. During this process, similar dimensions (e.g., category information, text block data) are aligned or mapped between the two, and calculations are performed using methods such as cosine similarity and Euclidean distance as needed. This approach aims to establish that if a second multidimensional vector has a relatively high similarity to a particular group of first multidimensional vectors, it generally indicates a closer alignment, in terms of category attributes or text block semantics, with the clauses, sections, or names represented by these first multidimensional vectors. This allows for a quantitative assessment of the similarity between the corresponding portions of the "unprocessed document" and the "target contract."

[0101] When dealing with vectors of multiple dimensions, you can selectively focus on comparing the most important or most relevant dimension 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 most similar clauses need to be found for verification.

[0102] As can be seen from the above, by analyzing the similarity of each second-dimensional vector with all first-dimensional vectors, retaining the top-k candidates, voting to select the most frequently occurring names and chapters, and ultimately integrating these into the overall layout of the generated vector sequence, the system can efficiently locate the most matching target contract information within a large amount of text, ensuring the accuracy and consistency of contract names and chapter identifiers with a high probability. The "unprocessed text contract template" generated on this basis is also more closely aligned with real business needs, playing a key role in subsequent review, automated merging, or revision, achieving highly flexible adaptation to scenarios where contracts do not have fixed templates.

[0103] 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.

[0104] In this embodiment, by setting different text task instructions for contract index extraction from "text to be processed" and proofreading and verifying "contract to be verified," the system, leveraging a large language model, can generate the most effective semantic parsing and reasoning output in different scenarios. This structured instruction system of four elements—role-task-text-output format—fundamentally reduces the risk of the model "going off topic" or "misjudging," enabling more targeted reasoning about available information and providing a clear framework for subsequent automated integration or review. Furthermore, because each scenario can independently expand its task description and output format requirements, the system maintains a high degree of flexibility and scalability for large-scale applications.

[0105] Specifically, when performing contract indicators for the text to be processed, the text tasks are as follows:

[0106] Role definition: You are a contract metrics extraction expert;

[0107] Task Description: Please extract contract indicators one by one from the given text and assign labels such as Party A, Party B, time, function, and performance;

[0108] Text: Fill in the text block;

[0109] Output format: Output one by one according to (indicator, category).

[0110] Specifically, when proofreading a contract to be reviewed, the text tasks are as follows:

[0111] Role: You are a contract element verification expert;

[0112] Indicators to be verified: fill in the indicators to be verified;

[0113] Task Description: Please carefully read the target contract 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;

[0114] Target contract: / / Fill in the retrieved target contract text block;

[0115] Output format: The output must include fields such as results, explanation, and the most relevant description of the target contract.

[0116] The present invention provides an LLM-based contract element extraction and review method that can significantly 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. This enables enterprises or legal departments to have stronger scalability and consistency when processing large numbers 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.

[0117] The embodiment of the second aspect of the present invention proposes an apparatus 2, such as Figure 4 As shown, the device 2 includes:

[0118] 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 multidimensional vector; and construct a text vector database based on the text block data and its corresponding first multidimensional vector.

[0119] The text indicator extraction module 202 is used to extract feature information from the text to be processed as contract indicators; generate corresponding labels according to the categories to which each feature information belongs; and vectorize each feature information and the corresponding label to obtain a second multidimensional vector.

[0120] 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.

[0121] The contract generation and annotation module 204 generates a contract to be reviewed based on the above vector sequence and the corresponding text block data; and annotates the corresponding feature information and / or text block data in the generated contract to be reviewed based on the difference information between the first multidimensional vector and the second multidimensional vector.

[0122] The device provided by the present invention closely combines text splitting, vector retrieval, feature extraction, and automatic generation. This device achieves both high efficiency and high accuracy when dealing with massive and diverse 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.

[0123] The third aspect of the present invention provides an electronic device. 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 This is merely an example of the electronic device 3 and does not limit the electronic device 3 . The electronic device 3 may include more or fewer components than shown in the figure, or different components.

[0124] 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.

[0125] Memory 302 can be an internal storage unit of electronic device 3, such as a hard drive or memory of electronic device 3. Memory 302 can also be an external storage device of electronic device 3, such as a plug-in hard drive, a Smart Media Card (SMC), a Secure Digital (SD) card, a Flash Card, etc. Memory 302 can also include both an internal storage unit of electronic device 3 and an external storage device. Memory 302 is used to store computer programs and other programs and data required by the electronic device.

[0126] Embodiments of the fourth aspect of the present invention provide a computer-readable storage medium. In some embodiments of the present invention, a computer-readable storage medium is provided that, when executed by processor 301, implements the steps of the above-described method. Therefore, the computer-readable storage medium provided in the fourth aspect of the present invention has all the technical effects of the above-described steps and will not be further described here.

[0127] Those skilled in the art can clearly understand that, for the convenience and brevity of description, only the division of the above-mentioned functional units and modules is used as an example for illustration. In actual applications, the above-mentioned functions can be distributed and 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 into one processing unit, or each unit can exist physically alone, or two or more units can be integrated into 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, and will not be repeated here.

[0128] Those skilled 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. Professionals and technicians can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this disclosure.

[0129] 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 merely a logical function division. In actual implementation, there may be other division methods. 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.

[0130] 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 when the computer program is executed by the processor, it can implement the steps of the above-mentioned various method embodiments. The computer program may include computer program code, which 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, USB flash drive, 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, computer-readable media do not include electric carrier signals and telecommunication signals.

[0131] 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 various embodiments of the present disclosure, and should all be included in the scope of protection of the present disclosure.

Claims

1. A contract element extraction and review method based on LLM, characterized by: The steps include: Acquire a target contract to obtain text data, extract contract framework information from the text data; segment the text data to obtain a plurality of text block data, and add contract name information of the target contract in the contract framework information, chapter information of the text block data, and category information to which the text block data belongs to each of the text block data; Converting the contract name information, the chapter information, the category information, and the text block data into numerical values, respectively, forming a first multidimensional vector using the numerical values, placing the corresponding numerical values of the category information and the text block data in the leading dimension or trailing dimension in the dimensional position sorting of the first multidimensional vector, and constructing a text vector database using the text block data and the corresponding first multidimensional vector; Extracting feature information from the text to be processed and using it as a contract indicator, generating a label for 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 having fewer dimensions than the first multidimensional vector; Searching the text vector database for a plurality of first multidimensional vectors that are similar to the second multidimensional vector in a leading dimension or a trailing dimension, and sorting all the second multidimensional vectors according to the first multidimensional vectors to generate a vector sequence; wherein searching for a plurality of first multidimensional vectors that are similar to the second multidimensional vector is achieved by the following steps: sequentially calculating similarity scores between the first multidimensional vectors and the second multidimensional vectors according to a preset similarity calculation method, and screening out a series of first multidimensional vectors that are similar to the second multidimensional vector by comparing the similarities; 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 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.

3. The method for extracting and reviewing contract elements according to claim 2, characterized in that: The step of generating a contract to be reviewed based on the vector sequence and the text block data includes: A contract template corresponding to the text to be processed is generated through the vector sequence, and the text block data is filled into a corresponding position in the contract template.

4. The method for extracting and reviewing contract elements according to claim 3, characterized in that: The step of generating a contract template corresponding to the text to be processed using the vector sequence includes: Calculating the similarity between each of the second multidimensional vectors and all corresponding first multidimensional vectors, and retaining the top k first multidimensional vectors sorted by 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.

5. The method for extracting and reviewing contract elements according to any one of claims 1 to 4, characterized in that: When processing the target contract, the text to be processed, and the contract to be verified, text tasks are set respectively to determine input data and output data of the language model.

6. A device for implementing the contract element extraction and review method according to any one of claims 1 to 5, characterized in that: include: A text parsing and vectorization module, configured to receive and parse 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 indicator extraction module is used to extract feature information from the text to be processed as contract indicators; generate corresponding labels according to the category to which each feature information belongs; and vectorize each feature information and the corresponding label to obtain a second multidimensional vector; an indicator vector retrieval and sorting module, configured to retrieve a plurality of first multidimensional vectors 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 vectors and the second multidimensional vectors 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.

Images