Intention anchoring and rule pluggable auditing method and system for multi-modal proposals

Abstract

The present application belongs to the technical field of bid auditing, and provides a multi-modal bid intention anchoring and rule pluggable auditing method and system to solve the auditing blind spot caused by information silos. The multi-modal bid intention anchoring and rule pluggable auditing method includes parsing and elementizing the original bid file; generating a document structure tree; performing cross-modal information alignment and consistency checking on the document structure tree; parsing the auditing intention into a structured instruction package containing context and guiding subsequent operations, traversing the checked document structure tree to generate a hierarchical outline with type annotation, and injecting it into the prompt word together with the structured instruction package as context, and then anchoring the auditing intention based on the prompt word guidance and closed-loop verification; and calling the rule engine and starting the rule engine to perform auditing operations according to the anchored auditing intention. It can improve the auditing quality, quickly adapt to changing business rules and different industries, and meet the needs of different types of bid auditing.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of bid review, and particularly relates to a multi-modal bid intention anchoring and rule pluggable review method and system. BACKGROUND

[0002] The statements in this section merely provide background information related to the application and do not necessarily constitute the prior art.

[0003] The bid is the core file in the bidding process, and the efficiency and accuracy of the review work become the key factors affecting the smoothness of the bidding process. At present, the bid review system mainly relies on the following technical means: 1. Use OCR (Optical Character Recognition) technology to extract text information in the bid, and then combine preset keyword matching or simple logic rules to perform compliance checking to complete the basic review work; 2. Introduce structured analysis technology to identify the chapter level of the bid, and some systems can analyze the chapter, section, and article structure of the bid and associate the corresponding review items; 3. Some systems try to integrate image recognition functions to extract information from certificate images.

[0004] However, the existing bid review technology has the following defects: insufficient understanding of the structure of complex documents, difficulty in accurately associating abstract review requirements with specific evidence locations, and inability to perform deep cross-verification of information in different modalities such as text, tables, and images. The review blind spot caused by information silos affects the review quality; the review logic is hard-coded, and cannot quickly adapt to changing business rules and different industry and type of bid review requirements. SUMMARY

[0005] To solve the above technical problems, the application provides a multi-modal bid intention anchoring and rule pluggable review method and system, which can solve the review blind spot caused by information silos, improve the review quality, and quickly adapt to changing business rules and different industry and type of bid review requirements.

[0006] To achieve the above purpose, the application adopts the following technical solutions:

[0007] The first aspect of the application provides a multi-modal bid intention anchoring and rule pluggable review method.

[0008] In one or more embodiments, a multi-modal bid intention anchoring and rule pluggable review method is provided, comprising:

[0009] The original bid file is parsed and elementized and split to obtain a plurality of elements; each element retains its location information and unique path ID in the original bid file to ensure its context attribution relationship;

[0010] all elements are classified according to whether they are title classes, a tree-like logical structure is constructed from top to bottom according to the level of the title class elements and their order in the original bidding document file, and non-title class elements are mounted under the nearest parent title node in the logical structure according to the nearest principle to generate a document structure tree;

[0011] The document structure tree is subjected to cross-modal information alignment and consistency verification, and whether the document structure tree is modified is determined according to the verification result until the verification meets the preset requirements;

[0012] The audit intention is parsed into a structured instruction package containing context and guiding subsequent operations, a hierarchical outline with type annotation is generated by traversing the verified document structure tree, and it is injected into the prompt word together with the structured instruction package as context, and then the audit intention is anchored based on the prompt word guidance and closed-loop verification;

[0013] According to the anchored audit intention, the rule engine is called and the rule engine is started to perform the audit operation to obtain the audit result; wherein the rule engine is associated with the plug-in rule file under each directory in the original bidding document file.

[0014] As an implementation, a classifier is used to classify all elements according to whether they are title classes, and the process is as follows:

[0015] The basic layout features, content mode features, relative layout relationship features and content complexity features of each element are extracted using the classifier to form an original feature vector;

[0016] The original feature vector is normalized, and the normalized feature vector and the mapping relationship of the element type are used to obtain the probability that the element belongs to the title class.

[0017] As an implementation, the document structure tree is subjected to cross-modal information alignment and consistency verification, and the process is as follows:

[0018] All entity nodes are extracted and a preliminary knowledge graph within the document range is constructed by traversing the entire document structure tree;

[0019] According to the preliminary knowledge graph, the evidence source and verification logic of each entity node are matched from the cross-modal verification mode library; wherein the cross-modal verification mode library pre-stores a series of verification rules, and each verification rule represents an entity node to be verified and its evidence source and verification logic;

[0020] For the target entity node matched with the cross-modal verification mode library, a corresponding verification task is generated, the nodes in the document structure tree are searched and the target evidence node is located as the evidence source, and the target entity node and the target evidence node are subjected to cross-modal alignment;

[0021] The normalized cross-modal aligned target entity and target evidence are subjected to similarity / consistency calculation, and whether the verification passes is determined according to comparison of a calculation score with a preset threshold.

[0022] As an implementation, in the process of locating the target evidence, the node with the highest confidence is found as the target evidence node by calculating the relevance score of the context text of the node in the document structure tree and the target entity.

[0023] As an implementation, the process of parsing the audit intention into a structured instruction package containing context and guiding subsequent operation is as follows:

[0024] According to the audit intention, evidence clues related to the audit intention are queried from an associated knowledge base;

[0025] The evidence clues queried are used to enhance the audit intention description, and a structured instruction package containing context and guiding subsequent operation is formed.

[0026] As an implementation, the associated knowledge base has a mapping table pre-stored therein, which maps each structured audit to a set of evidence clues related thereto; the evidence clues are artificially pre-defined knowledge.

[0027] As an implementation, in the process of closed-loop verification, the legality of the format and the existence of the verification path ID are checked.

[0028] As an implementation, in the process of starting the rule engine to perform the audit operation, the rule engine binds the rule itself with the specific data of the current audit, and then uses the rule interpreter inside the rule engine to perform the audit operation on the specific data of the current audit.

[0029] The second aspect of the application provides a multi-modal bid document intention anchoring and rule pluggable audit system.

[0030] In one or more embodiments, a multi-modal bid document intention anchoring and rule pluggable audit system comprises:

[0031] An elementization splitting module is configured to parse and elementize an original bid document file to obtain a plurality of elements; each element retains its position information and unique path ID in the original bid document file to ensure its context attribution relationship;

[0032] A hierarchical structure analysis module is configured to classify all elements according to whether they are title classes, construct a tree-shaped logical structure from top to bottom according to the levels of the title class elements and their order in the original bid document file, and then mount non-title class elements to the nearest parent title node to which they logically belong according to the nearest principle to generate a document structure tree;

[0033] The cross-modal cross-validation module is used to perform cross-modal information alignment and consistency verification on the document structure tree, and determine whether to correct the document structure tree based on the verification result until the verification meets the preset requirements.

[0034] The audit intent anchoring module is used to parse the audit intent into a structured instruction package containing context and guidance for subsequent operations. It traverses the validated document structure tree to generate a hierarchical outline with type labels and injects it together with the structured instruction package as context into the prompt words. Then, based on the prompt words and closed-loop verification, the audit intent is anchored.

[0035] The rule engine invocation module is used to invoke and start the rule engine to perform the review operation based on the anchored review intent and obtain the review result; the rule engine is associated with pluggable rule files in various directories in the original tender document file.

[0036] A third aspect of the present invention provides an electronic device.

[0037] An electronic device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, implements the steps of the intent anchoring and rule pluggable auditing method for multimodal tenders as described above.

[0038] Compared with the prior art, the beneficial effects of the present invention are:

[0039] (1) This invention generates a document structure tree by parsing and element-based decomposition of the original tender document and classifying all elements according to whether they are title types. By performing cross-modal information alignment and consistency verification on the document structure tree, it realizes the verification-style review of the tender content. It can systematically and configurably establish logical verification chains between evidence of different modalities, fundamentally solving the review blind spots caused by information silos in the existing technology. It can discover deep-seated contradictions that are easily overlooked by humans, thereby ensuring the high reliability and accuracy of the review results.

[0040] (2) This invention parses the review intent into a structured instruction package containing context and guidance for subsequent operations. It traverses the document structure tree after verification to generate a hierarchical outline with type labels and injects it together with the structured instruction package as context into the prompt words, forming an engineering framework of context injection and structured output constraints. Based on prompt word guidance and closed-loop verification, the uncertain output of the general large model is constrained into a controllable, verifiable and accurate positioning result. This solves the core pain point of the large model being inaccurate in positioning and easy to produce illusions in document processing, and solves the problems of ambiguous positioning and inexplicable review results in the prior art.

[0041] (3) According to the anchoring of the review intention, the rule engine of the plug-in rule file in each directory in the associated original bidding file is called and started to perform the review operation, so that the rule is 'plug-in', high flexibility, and can efficiently and low-cost adapt to the changing business scenarios. BRIEF DESCRIPTION OF DRAWINGS

[0042] The accompanying drawings, which form a part of this specification, are included to provide a further understanding of the application, and are incorporated in and constitute a part of this specification. The embodiments of these drawings are set to explain the application, and do not constitute an improper limitation on the application.

[0043] Figure 1 is a flowchart of the intention anchoring and rule plug-in review method of the multi-modal bidding document of the embodiment of the application;

[0044] Figure 2 is a structural schematic diagram of the intention anchoring and rule plug-in review system of the multi-modal bidding document of the embodiment of the application;

[0045] Figure 3 is a schematic diagram of an electronic device of the embodiment of the application. DETAILED DESCRIPTION

[0046] The application will be further described below in conjunction with the drawings and embodiments.

[0047] It should be noted that the following detailed description is exemplary and is intended to provide further explanation of the application. Unless otherwise indicated, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which the application belongs.

[0048] It should be noted that the terms used herein are only for the purpose of describing specific embodiments, and are not intended to limit the exemplary embodiments according to the application. As used herein, unless the context clearly indicates otherwise, the singular form is intended to include the plural form, and in addition, it should be understood that when the terms "comprise" and / or "include" are used in the specification, there is a feature, step, operation, device, component and / or combination thereof.

[0049] According to the background art, the existing bidding review has weak multi-modal information processing capability: table data needs to be converted into pure text input, resulting in loss of structural information, license images rely on independent OCR engine output text, text, table and image are in a fragmented state, and lack of cross-modal joint reasoning capability. Therefore, the different modal information such as text description, table data and license image in the bidding document are often processed independently, and lack of cross-checking mechanism. For example, when the company name identified by the business license image is inconsistent with the description of "bidder qualification" in the text chapter, the existing system cannot automatically identify the contradiction, and manual intervention is required to solve it.

[0050] Insufficient structural analysis and intent anchoring accuracy: Existing systems have limited depth of analysis for complex hierarchical structures, and the association between intent recognition and structural nodes is weak. Even if large models are introduced, due to the lack of prompt word optimization mechanism for the characteristics of bid document structure, it is difficult to accurately anchor the review intent such as "financial statement effectiveness" to specific structural nodes such as "Chapter 5.3 Near Three Years Financial Statement", leading to ambiguous review results and poor interpretability.

[0051] Poor rule extensibility and adaptability: Audit rules are often fixed in code form in the system. When facing different industry (such as construction, medical, IT) differences in audit standards, or individualized requirements of the same industry, secondary development is required to modify the rules, which not only has a long cycle, but also has high cost. Some systems that introduce rule engines cannot achieve "plug and play" dynamic updates due to high coupling between rule modules and core systems.

[0052] In summary, there is currently no industrial-level solution that can simultaneously solve the problems of multi-modal information deep fusion verification, accurate analysis of bid document hierarchical structure, precise anchoring of review intent, and flexible configuration of review rules. Therefore, how to build a system and method that can deeply understand multi-modal bid documents, achieve structured anchoring of intent, and conduct intelligent and high-confidence review combined with pluggable rules is a core challenge in the current bidding and compliance intelligent review field.

[0053] To solve the above problems, the present application provides a multi-modal bid document intent anchoring and rule pluggable review method and system. Figure 1 is a flowchart of a multi-modal bid document intent anchoring and rule pluggable review method in an embodiment of the present application, as Figure 1 shown, the multi-modal bid document intent anchoring and rule pluggable review method in the present embodiment can include the following steps S101-S105.

[0054] The specific implementation process of steps S101-S105 is as follows:

[0055] Step S101: Analyze and elementize the original bid document file to obtain a plurality of elements; each element retains its location information and unique path ID (for example, root / chapter[5] / section[1] / image[1]) in the original bid document file to ensure its context attribution relationship.

[0056] In the present embodiment, the format of the original bid document file is PDF, Word, etc.; document analysis techniques such as optical character recognition (OCR) method can be used to analyze the original bid document file.

[0057] The elements here include text blocks carrying layout information such as font, position coordinates, structured tables extracted completely, and image objects separated from the document.

[0058] In some embodiments, on-demand invocation and context-aware mechanism are adopted for image processing. The mechanism is implemented through a set of asynchronous triggers and structured post-processing procedures based on context relevance evaluation. Specifically, a general-purpose optical character recognition (OCR) engine is maintained, which has strong content extraction and layout information preservation capabilities, but is not blindly invoked in the pre-processing stage.

[0059] The specific implementation process is as follows:

[0060] Step a: initial encapsulation and state marking of image objects;

[0061] In the initial parsing stage, all images are encapsulated into "image objects" containing path ID, binary data, and other meta-information. Each image object contains an ocr_status field with an initial value of "PENDING" and an ocr_result field with an initial value of empty.

[0062] Step b: "on-demand invocation" request trigger;

[0063] When the text information of a certain image node is needed, an "on-demand invocation" is triggered. "On-demand invocation" is a "context processing request" passed to the multi-modal data acquisition and preprocessing module. The request is a data structure that contains the path ID of the target image and the context text T_context (for example, the title text immediately adjacent to the image). For example, when the review intent "verify business license" is anchored to the image node with path ID... / image[1], the intent anchoring module will construct and pass a request that not only contains target_id: '... / image[1]', but also contains the context text T_context (for example, its direct parent title "5.1 Business License Scan") extracted from the document structure tree and immediately adjacent to the image.

[0064] Step c: OCR execution decision based on context relevance evaluation;

[0065] Check the ocr_status of the target image object;

[0066] If it is "COMPLETED", the cached result is returned directly from the ocr_result field; if it is "PENDING", "context relevance evaluation" is performed to determine the possible context type D_type_best of the image.

[0067] The relevance score Score(T_context, D_type) between the context text T_context and a predefined "document type knowledge base K" is calculated. The knowledge base K stores multiple key document types (e.g. D_type = 'business license', 'bank credit certificate', etc.) and their associated keyword vectors. The relevance score can be formalized as:

[0068] Score(T_context, D_type) = α * Sim_cos(V(T_context), V(D_type.keywords)) + β * P_match(T_context, D_type.patterns);

[0069] Where: V() is a text vectorization function (e.g. TF-IDF or BERT embedding) that converts text into mathematical vectors; Sim_cos() calculates the cosine similarity between the context text vector and the document type keyword vector, measuring the semantic closeness; P_match() is a pattern matching function that checks whether the context contains strong feature patterns of the document type (e.g. regular expression matching "business license" characters), returning 1 if matched, otherwise 0. α and β are weight coefficients, and β has a greater weight than α to ensure the priority of strong pattern matching. D_type.keywords represents the keywords of the document type; D_type.patterns represents the feature patterns of the document type.

[0070] Calculate the scores of all document types in the knowledge K, and select the highest scoring document type D_type_best as the most likely context type of the image.

[0071] Step d: General OCR invocation and context-guided structured post-processing;

[0072] Invoke the general OCR engine to process the target image, and the general OCR engine treats the image area as a two-dimensional canvas, outputting a raw text block list L_raw containing all text and its coordinates. Ensuring that the most original and complete page information is captured completely;

[0073] According to the determined context type D_type_best (e.g. 'business license'), retrieve the corresponding structured template S_template from the "document type knowledge base K". The template defines the key fields of this type of document and their extraction rules (e.g. the keyword of the field "registered capital" is "registered capital", and its value is usually located in the same line to the right of the keyword);

[0074] An extraction algorithm of template guidance is performed to traverse the original text block list L_raw, and fill the unstructured L_raw into a structured key-value pair (JSON) object according to the rules in S_template.

[0075] Step e: result cache and state update;

[0076] The finally generated structured JSON object (for example, for a business license, in the form of {"legal representative":"...", "unified social credit code": "...",...}) is stored in the ocr_result field of the target image object, and the ocr_status is updated to "completed" (COMPLETED).

[0077] Through the above process, "on-demand calling" is materialized into a complete mechanism including a state machine (not executed / completed), asynchronous request, and result cache. At the same time, through the introduction of formula-based context relevance evaluation and template-guided post-processing, "context awareness" is transformed from an abstract concept into a computable and executable specific technical solution, so that a general OCR engine can intelligently output highly structured and directly usable for review accurate data according to different contexts.

[0078] Step S102: classify all elements according to whether they are title classes, construct a tree-like logical structure from top to bottom according to the level of the title class elements and their order in the original bidding document, and then mount the non-title class elements to the nearest parent title node in the logical structure according to the nearest principle, to generate a document structure tree.

[0079] In the implementation process of step S102, the classifier is used to classify all elements according to whether they are title classes, and the process is as follows:

[0080] The basic layout features, content mode features, relative layout relationship features and content complexity features of each element are extracted using the classifier, and an original feature vector is formed;

[0081] The original feature vector is normalized, and the mapping relationship between the normalized feature vector and the element type is used to obtain the probability that the element belongs to the title class.

[0082] The basic layout features here include:

[0083] Font features: extract font_size (normalized font size), is_bold (whether bold), is_italic (whether italic), font_color (font color), etc. of the text block;

[0084] Position and alignment features: Extract the x_indentation (left indentation distance), alignment_mode (alignment mode: left, center, right) of the text block.

[0085] Content pattern features here include:

[0086] Numbering pattern score: An enhanced regular expression engine is used to match a variety of complex, cross-lingual chapter numbering patterns. The engine not only recognizes "1.1", but also covers "Chapter One", "Section (Two)", "Part A", etc. According to the level and clarity of the matching pattern, a score between 0 and 1 is output, rather than a simple binary match.

[0087] Content density features: Calculate numeric_density (the proportion of numbers to the total number of characters) and capital_ratio (the proportion of capital letters to the total number of letters). Headings and key provisions usually have higher numeric or capital letter density.

[0088] Relative layout features here include:

[0089] Relative vertical spacing ratio (vertical_spacing_ratio_prev): Calculate the vertical spacing between the top of T_i and the bottom of T_{i-1}, and divide it by the line height of T_i itself. This ratio effectively amplifies the large blank space before the heading, while eliminating the interference caused by font size changes.

[0090] Relative indentation delta (indentation_delta_prev): Calculate the difference between the left indentation distance of T_i and T_{i-1}. This feature can accurately capture strong structural patterns such as "heading reset, body indentation" or "multi-level headings with incremental indentation".

[0091] Relative font size ratio (font_size_ratio_prev): Calculate the font size ratio of T_i and T_{i-1}. The font size of the heading is usually significantly larger than that of the previous text or the same level heading.

[0092] Content complexity features here include: character_entropy: Calculate the information entropy of the character distribution within the text block T_i. This feature is based on the following insight: headings are highly condensed, so their word choice is usually more diverse and concise than that of templated, language-patterned text (such as legal provisions, statements, etc.), so their information entropy is usually higher.

[0093] All extracted raw feature values are processed by Min-Max Scaling to scale their value range to the interval [0, 1]. This can eliminate the model training bias caused by different dimensions between different features. All processed features are combined into a fixed-length feature vector V_i as the final input of the classifier.

[0094] In the embodiments of the present application, the classifier adopts a Gradient Boosting Decision Trees (GBDT) model. This model is selected because it can effectively process heterogeneous features (numeric and categorical) and can learn the complex and nonlinear combination relationship between features.

[0095] During the operation of the classifier, for each text block T_i extracted from the tender document, the system first generates its feature vector V_i by performing steps one and two. Then, V_i is input into the trained GBDT model. The model outputs the probability distribution of the text block belonging to each predefined role category. The system selects the role with the highest probability as the final recognition result of T_i.

[0096] After all the title class nodes are recognized, a Document Object Model (DOM) tree is constructed from top to bottom according to their levels and order in the document. Subsequently, non-title class elements (text paragraphs, tables, images) are attached to the nearest parent title node to which they logically belong according to the "nearest principle". In this way, a complex tender document with dozens or even hundreds of pages is converted into a hierarchical tree data structure that can be traversed and queried by algorithms. Each node of the structure tree has a unique path ID (e.g. root / chapter[3] / section[2] / paragraph[1]) and contains the original text, table data or image information corresponding to the node. This deep structured parsing based on multi-dimensional context features is a prerequisite for subsequent implementation of precise anchoring rather than fuzzy matching of intent.

[0097] Step S103: Cross-modal information alignment and consistency verification are performed on the document structure tree, and whether to modify the document structure tree is determined according to the verification result until the verification meets the preset requirements.

[0098] In the specific implementation process of step S103, cross-modal information alignment and consistency verification are performed on the document structure tree, and the process is as follows:

[0099] Step S1031: Traverse the entire document structure tree, extract all entity nodes, and construct a preliminary knowledge graph within the scope of the document.

[0100] For all text nodes, key entities (e.g. “registered capital”, “company name”, “key technical indicators”, “financial data”, “date”, etc.) are extracted using Named Entity Recognition (NER) techniques, and each extracted entity is stored together with its source path ID in the document tree. For image nodes that have been processed by the first module (on-demand) and all table nodes, the algorithm directly reads their already structured key-value pair data. All extracted entities and their metadata (source, path ID, modality) are used to construct a preliminary knowledge graph within the document scope.

[0101] Step S1032: According to the preliminary knowledge graph, match the evidence source and verification logic of each entity node from the Cross-Modal Verification Schema. The Cross-Modal Verification Schema pre-stores a series of verification rules, and each verification rule represents an entity node that needs to be verified and its evidence source and verification logic. Each verification rule is a structured object.

[0102] Step S1033: For the target entity node that matches the Cross-Modal Verification Schema, generate a corresponding verification task, search the nodes in the document structure tree and locate the target evidence node as the evidence source, and perform cross-modal alignment on the target entity node and the target evidence node.

[0103] In the process of locating the target evidence, the correlation score of the context text of the nodes in the document structure tree and the target entity is calculated to find the node with the highest confidence as the target evidence node.

[0104] Specifically, for each text entity, the algorithm queries whether its type (e.g. “registered capital”) matches the source_entity_type of any pattern in the Cross-Modal Verification Schema, establishing a proof relationship between data in different modalities. If a match is found (for example, the VERIFY_REG_CAPITAL pattern is matched), a specific verification task is generated. The goal of this task is to find a node in the document with target_modality as image and context most consistent with target_context_hint (“business license”), and verify its content.

[0105] Using the context correlation evaluation algorithm described in the first module, search all image nodes in the document structure tree, calculate the correlation scores between their context texts and target_context_hint, and thus find the evidence image node with the highest confidence. After locating the target image node, extract the corresponding image-side entity value from the ocr_result (a structured JSON) of this node according to the target_key ("registered capital") defined in the pattern.

[0106] Step S1034: Normalize the target entity and target evidence of cross-modal alignment, then perform similarity / consistency calculation, and judge whether the verification passes according to the comparison between the calculated score and the preset threshold.

[0107] For example, according to the normalization_rule (such as currency_to_number) specified in the verification mode, call the corresponding normalization function Norm() to process the values of the two entities. This function is responsible for converting entities with different expressions into a unified and directly comparable canonical format. For example, Norm("Fifty million yuan") and Norm("50,000,000") will both output the number 50000000.

[0108] The process of performing similarity / consistency calculation is as follows:

[0109] According to the similarity_function (such as numeric_equality or cosine_similarity) specified in the pattern, call the Sim() function to calculate the consistency score of the two normalized entities. Its judgment logic can be expressed as:

[0110] Result = IF( Sim(Norm(E_text), Norm(E_img))>= θ, 'PASS', 'FAIL' );

[0111] Where: The Sim() function is selected according to the rule.

[0112] For numerical values, equality judgment can be used (x, y) => x === y? 1 : 0;

[0113] For text (such as company name), string similarity algorithms (such as Jaro-Winkler distance) or cosine similarity based on word vectors can be used.

[0114] θ is the similarity threshold for this specific verification task, which is preset by the threshold field in the verification schema. This is more flexible and accurate than a global empirical value. For example, registered capital requires θ = 1.0 (exactly equal), while the company name may allow θ = 0.95 to tolerate minor OCR errors.

[0115] The verification result ('PASS' or 'FAIL') is written back to the preliminary knowledge graph, marked on the E_text entity. If the result is 'FAIL', a detailed conflict log is generated, recording the path ID of source_entity, the path ID of target_entity, the original values of both, the normalized values, and the calculated similarity score, for use by the final report generation module.

[0116] Through the above detailed algorithm process driven by the "verification schema library", the originally ambiguous "cross-verification" concept is transformed into an intelligent, clear process, logical and flexible configuration scheme, so as to systematically find the deep and cross-modal logical errors that are easily overlooked in manual review, and improve the depth and reliability of the review.

[0117] Step S104: Analyze the review intention into a structured instruction package containing context and guiding subsequent operations, traverse the checked document structure tree to generate a hierarchical outline with type annotation, and inject it into the prompt word as context together with the structured instruction package, then guide and close-loop verify based on the prompt word, and anchor the review intention.

[0118] In this embodiment, a set of "context injection and structured output constraints" engineering framework is constructed using a large language model (LLM), which is used as a "zero-shot reasoning engine" that does not need to be trained and can be plugged in and used immediately, so as to intelligently and reliably "anchor" high-level and fuzzy review intentions (such as "check the qualifications of core team members") to specific nodes of the document, solving the core pain points of poor stability, easy hallucination, and inability to guarantee the reliability of industrial applications when using general LLM for professional document positioning.

[0119] In the specific implementation process, the process of parsing the review intention into a structured instruction package containing context and guiding subsequent operations is as follows:

[0120] According to the review intention, evidence clues related to the review intention are queried from an associated knowledge base; wherein the associated knowledge base pre-stores a mapping table which maps each structured review to a set of related evidence clues; the evidence clues are artificially predefined knowledge;

[0121] Note that the "intent recognition" in this invention is not about training a model to classify the user's natural language input. Instead, it defines the "audit intent" as a structured input object. When a user (or external system) initiates an audit task, for example, selects an audit item named "Check Core Team Member Qualifications", the following operations are performed:

[0122] Intent object initialization: First, create an intent object, with the initial description "Check Core Team Member Qualifications".

[0123] Associated knowledge base query: Maintain an "Intent-Evidence Knowledge Base". This knowledge base is a mapping table that maps each structured audit item Intent to a set of related evidence clues. These clues are pre-defined, high-quality knowledge. For example: "Check Core Team Member Qualifications" -> {"synonyms": ["Project Manager Qualification", "Technical Backbone Ability"], "keywords": ["Project Manager Certificate", "Senior Engineer Title", "Educational Background", "Related Experience"], "preferred_node_types": ["Table", "Image"]};

[0124] Use the queried evidence clues to enhance the audit intent description and form a structured instruction package containing context and guiding subsequent operations. For example, use the queried evidence clues to "enhance" the initial Intent object. At this time, this object changes from a simple text description to a structured instruction package containing rich context and guiding subsequent operations.

[0125] In order to enable the general LLM to accurately understand the structure of the current specific bid without training, a highly condensed and structured document context will be dynamically constructed for this query.

[0126] Hierarchical outline generation: Traverse the document structure tree (DOM) generated by the hierarchical structure parsing module and generate a "typed hierarchical outline". This outline not only contains chapter titles and their hierarchy, but also specially marks whether each title node contains non-text nodes such as tables ([has_table]) or images ([has_image]).

[0127] For example:

[0128] - 1. Company Overview;

[0129] - 2. Project team introduction [has_table];

[0130] - 2.1 Project Manager Introduction [has_image];

[0131] - 2.2 Resume of the Technical Lead;

[0132] - 3. Qualification certificates;

[0133] - 3.1 Business license [has_image].

[0134] The outline and the enhanced Intent object from the previous step will be injected together as "context" into the final prompt.

[0135] In this embodiment, a structured, multi-stage prompt template is designed to guide the LLM in logical reasoning, rather than a simple question.

[0136] Role-Playing: At the beginning of the prompt, explicitly instruct the LLM to play a specific, professional role. For example: "You are an experienced and extremely meticulous tender document reviewer. Your task is to locate key evidence in the document, not to summarize the content."

[0137] Chain-of-Thought (CoT) guidance: Clues guide LLMs through step-by-step logical thinking, rather than providing direct answers. This significantly improves accuracy in complex tasks.

[0138] Structured input and output: The format of the prompt words is strictly defined, the input is structured information, and the LLM is required to return results in a specific, machine-parseable format (such as JSON).

[0139] During the closed-loop verification process, the validity of the verification format and the existence of the verification path ID are verified.

[0140] Specifically, upon receiving the JSON returned by the LLM, a secure closed-loop verification process of "question-answer-verification" is executed:

[0141] Format validation: Checks whether the returned data is valid JSON and contains the anchored_node_ids field.

[0142] Path ID existence verification: Iterate through each ID in the anchored_node_ids list and query the document structure tree (DOM) in system memory to ensure that the path actually exists. Any non-existent path ID is discarded.

[0143] Through the complete framework of "intention structured enhancement -> context dynamic injection -> CoT prompt word guidance -> closed-loop verification", the application transforms a general LLM which may produce "hallucinations" or unstable output into a reliable, accurate and precise document intention anchoring tool which can be used in serious industrial scenarios without any model training.

[0144] Step S105: According to the anchored review intention, a rule engine is called and the rule engine is started to perform a review operation, and a review result is obtained;The rule engine is associated with the plug-in rule file under each directory in the original bid file.

[0145] In order to solve the pain points of rule solidification and difficulty in adapting to changing business needs of traditional review system, the application designs a flexible plug-in rule engine based on declarative rules and interpreter mode.

[0146] The rules of the application are not hard coded in the program, but are externally stored in a human-readable, structured declarative language (such as JSON or YAML) as a rule file. A typical rule file not only defines the review logic, but also contains all the metadata required to execute the logic.

[0147] When the system starts, or when a specific instruction is received during operation, the rule engine will perform the following initialization operations:

[0148] Scan the rule directory: the engine will scan a pre-configured file directory (for example, / etc / rules.d / ).

[0149] Load and verify: read all rule files (such as.json files) under the directory. For each file, the engine will verify its syntax structure according to a pre-defined Schema (pattern) to ensure that all required fields (such as rule_id, target_intent_id, execution_logic, etc.) exist and are in the correct format.

[0150] Build the in-memory rule base: the verified rules are parsed and loaded into memory to build a hash table or dictionary indexed by target_intent_id. This allows subsequent millisecond-level fast lookup based on intention ID.

[0151] The "pluggable" feature is that the administrator only needs to add, delete or modify rule files under this directory, and then trigger a reload signal (for example, through an API call), and the engine will repeat the above process to dynamically update its audit logic without interrupting system services. For example, when a new requirement for a specific ISO quality certification is added to a certain type of bidding, the administrator only needs to add a rule file, define the intent that needs to be anchored (such as "check ISO certification"), and set the conditions for checking the certification number or validity period.

[0152] When successfully anchoring an intent (for example, INTENT_VERIFY_CAPITAL) to one or more document nodes (called anchor_nodes), the audit execution module is started.

[0153] Rule retrieval: The audit execution module uses the anchored intent_id as a query key to retrieve all relevant rule lists (there may be multiple rules associated with the same intent) from the memory rule base of the rule engine.

[0154] Specifically, in the process of starting the rule engine to execute the audit operation, the rule engine binds the rule itself with the specific data of the current audit, and then uses the rule interpreter inside the rule engine to perform the audit operation on the specific data of the current audit. For example, for each retrieved rule, the engine creates an "execution context". This is a temporary, isolated runtime environment that binds the rule itself with the specific data of this audit (i.e. the content of anchor_nodes). For example, the $anchor_node.content variable in the context will be replaced by the structured OCR result of the anchor node (such as the business license image).

[0155] The step-by-step execution process of the rule interpreter is as follows:

[0156] For each execution context, the rule interpreter inside the engine is started. Its innovation is that it supports two types of execution actions: deterministic operations (Deterministic Actions) and cognitive judgment operations (Cognitive Judgment Actions), which are implemented by calling large language models (LLM). The interpreter strictly follows the order defined in the execution_logic.steps array in the rule file to execute the operations step by step:

[0157] Scenario 1: Perform deterministic operations;

[0158] When the action type is extract_value, normalize_currency, evaluate_condition, etc. deterministic operations, the interpreter behaves as described earlier. It calls internal, algorithm-based function libraries to accomplish these tasks. This guarantees that for audit items with explicit calculation logic (such as numerical comparison, date check), the system's execution is 100% reliable and repeatable.

[0159] Scenario Two: Performing Cognitive Judgment Operations;

[0160] When the action type in the rule file is defined as cognitive_judgment, the rule interpreter will start a LLM call process based on dynamic instruction generation. This process ensures that the general LLM can be accurately and reliably used for complex business judgments.

[0161] Take a rule that checks "whether the project experience is truly relevant" as an example, its internal execution details are as follows:

[0162] 1. Identify the cognitive judgment task: The interpreter identifies that the action is cognitive_judgment.

[0163] 2. Construction of dynamic instruction prompt (Prompt): Instead of simply throwing the question to the LLM, the interpreter dynamically constructs a structured, multi-part instruction prompt.

[0164] (1) Context injection: The interpreter extracts the specific content of the anchor_node from the current "execution context". If the anchor is a text node, it provides the full text of the paragraph; if it is an image node, it provides its structured OCR result. This part of the content corresponds to the "context information" in the Prompt.

[0165] (2) Rule injection: The interpreter extracts the human-readable description field (for example, "check whether the project experience description is highly related to the core requirement 'Pass platform, SasS platform, and MaaS platform intelligent construction' of this bidding") from the current rule file being executed, corresponding to the "audit rule" in the Prompt.

[0166] (3) Instruction and role-playing injection: The interpreter generates explicit "instructions" according to the prompt_template defined in the rule file (or a global template). This includes asking the LLM to play the role of a "senior bidding evaluation expert" and strictly follow the provided "context" and "rules" to make judgments.

[0167] (4) Output Format constraint injection: the instruction contains strict requirements for the output format, forcing the LLM to return a machine-parsable JSON object containing keys such as conclusion and reason.

[0168] 3. LLM service invocation: the interpreter sends this carefully constructed complete prompt word containing the context, rules, instructions, and output format to the general large language model through an API request.

[0169] 4. Parsing and variableization: the structured JSON returned by the LLM is parsed by the interpreter, and the content is assigned to the output_variable defined in the rule step.

[0170] 5. Continue execution: this structured judgment result generated by the LLM has now become a deterministic variable in the execution context, which can be used for accurate conditional judgment by subsequent evaluate_condition and other deterministic steps, thus obtaining the final PASS / FAIL conclusion.

[0171] The result of the conditional evaluation (true or false) determines the final audit status: if the result is true, the interpreter will select the template string in output_format.pass; if the result is false, it will select output_format.fail.

[0172] The interpreter performs a string interpolation, replacing variables in the template (such as {$normalized_capital}) with the final calculated value in the context, generating a human-readable, detailed audit conclusion (for example: "Audit passed: registered capital is 10000000 yuan, meeting the requirement of not less than 1000 million yuan.").

[0173] This final structured result (containing PASS / FAIL status and detailed description) is returned to the audit execution module, completing a complete rule execution cycle.

[0174] Through the above detailed implementation process, the pluggable rule engine of the present application completely separates the "definition" (through JSON files) and "execution" (through the interpreter) of business logic, providing a highly flexible, transparent, and non-intrusive mechanism to manage and extend the audit capabilities of the system, and creatively improving the traditional hard-coded audit system.

[0175] The following is an example of intelligent auditing of an electronic bid (PDF format), which details the specific implementation process of the intent anchoring and rule pluggable auditing method of the multi-modal bid:

[0176] The bid is for a Pass platform, SasS platform, and MaaS platform integration project.

[0177] Scenario A: Execute deterministic, cross-modal auditing rules;

[0178] Scenario setting:

[0179] Audit task: "Verify that the registered capital of the bidding company is not less than 1000 million yuan, and ensure that the license is within the valid period."

[0180] Associated intent ID: INTENT_VERIFY_CORPORATE_QUALIFICATION.

[0181] Bid content related segment:

[0182] Text evidence: On page 15 of the PDF, in the "2.1 Company Profile" paragraph, there is a text description: "... registered capital of 1 million yuan."

[0183] Image evidence: On page 40 of the PDF, under the "5.1 Business License" title, there is a scanned image of a business license.

[0184] Step 1: Initial analysis and objectification of multi-modal data;

[0185] Receive the PDF file for global analysis, extract all text blocks, and create an "image object" for the image on page 40 with an ocr_status of "Pending" (PENDING), and assign it a path ID... / image[1].

[0186] Step 2: Hierarchical structure analysis;

[0187] Based on its multi-dimensional feature engineering and machine learning model, it successfully constructed the logical structure tree (DOM) of the document, accurately locating the path ID of the above-mentioned text and image evidence.

[0188] Step 3: Intent anchoring and on-demand processing;

[0189] 1. Intent anchoring: Using its "context injection and structured output constraint" framework, it calls the LLM for reasoning, successfully anchoring the intent to two nodes: the text node... / paragraph[x] and the image node... / image[1].

[0190] 2. Trigger on-demand OCR: Since the content of the image node is required for review, the intent anchoring module sends a "context processing request" to the first module, including the image ID and the context "5.1 Business License".

[0191] 3. Context-aware processing: According to the predefined context relevance evaluation formula, the image type is determined to be "Business License", then the general OCR is called and template-guided post-processing is performed to generate a structured JSON result {"Registered Capital": "￥10,000,000", "Business Period": "March 10, 2015 to permanent",...}, and it is cached in the image object.

[0192] Step Four: Hybrid intelligent execution of the rule engine;

[0193] 1. Rule retrieval: According to intent_id, two relevant rules are retrieved from its in-memory rule library: rule_capital_check.json and rule_expiry_check.json.

[0194] 2. Execute rule_capital_check: The interpreter of the engine starts to execute this rule step by step:

[0195] step: "extract": Extract "Ten million yuan" from the text node content and "￥10,000,000" from the JSON result of the image node.

[0196] step: "normalize": Call the normalize_currency function to convert both to the number 10000000.

[0197] step: "compare": Execute the condition $normalized_capital >= 10000000, and the result is true.

[0198] 3. Execute rule_expiry_check: (Similarly) The interpreter extracts the "Business Period" from the JSON result of the image node and compares it with the current system date, and the result is true.

[0199] Step Five: Report generation;

[0200] Two PASS results are received. Then a report is generated, in which there are two passed sub-items under the item "Enterprise Qualification Review", and each one is accompanied by an "evidence anchor" pointing to the text on page 15 and the image on page 40, as well as a "rule anchor" pointing to files such as rule_capital_check.json.

[0201] Scenario B: Enforcing review rules that require cognitive judgment;

[0202] 1. Scene setting:

[0203] Review task: "Review the project experience in the bidding proposal to see if it is highly relevant to the theme of this tender, 'Smart City Brain PaaS Platform'."

[0204] Associated intent ID: INTENT_VALIDATE_PROJECT_EXPERIENCE

[0205] Excerpt from the tender document:

[0206] Textual evidence: On page 25 of the PDF, in the section “3.2 Similar Project Experience”, it is described that: “...Our company once led the ‘XX City Traffic Management Data Platform’ project, which integrated traffic checkpoint and traffic light data throughout the city and built a data governance and analysis platform…”;

[0207] Steps one through three (similar to scenario A, the intention is ultimately anchored to the project experience description paragraph on page 25... / paragraph[y]).

[0208] Step 4: Hybrid intelligent execution of the rule engine;

[0209] 1. Rule retrieval: The rule rule_experience_relevance.json was retrieved.

[0210] 2. Execute cognitive judgment rules: The engine's interpreter begins execution:

[0211] step: "extract_project_desc": Extracts the complete project experience description text from the anchor node.

[0212] Step: "llm_judge_relevance": This is a crucial step. The interpreter recognizes the action as cognitive_judgment. It then dynamically constructs a complete cue word containing context, rules, role-playing, and output format, injects the extracted item description into the template, and then invokes the generic LLM.

[0213] LLM returns a structured JSON response: {"conclusion": "Highly relevant", "reason": "The core of this project is the data platform and data governance, which are the fundamental core capabilities of the Smart City Brain PaaS platform."}

[0214] Step: "final_decision": The interpreter makes conditional judgment on the conclusion returned by the LLM $llm_judgment_result.conclusion == = = 'highly relevant', the result is true.

[0215] Step five: report generation;

[0216] After receiving the PASS result, the corresponding entry is generated in the report. The user clicks on the details to not only see the original description as evidence, but also see the specific judgment reason given by the LLM, realizing the complete transparency of the review process.

[0217] Through the implementation of the two scenarios, the present application demonstrates how it handles deterministic cross-modal verification and ambiguity verification that requires cognitive reasoning, and the complete chain from structural parsing, intent anchoring, cross-modal verification, to rule-driven LLM execution, presenting how the modules work together to form an intelligent, traceable, and highly flexible bid review system.

[0218] The present application completely changes the inefficient mode of "first all processing, then use" of the traditional document processing system through the "on-demand calling" and "context-aware" mechanism. Through the asynchronous triggering process based on context correlation evaluation, the computationally intensive OCR operation is only applied to the most relevant image when necessary, greatly reducing the system idle and resource consumption when processing irrelevant information, and significantly improving the response speed and operating efficiency of the overall review process. Moreover, the present application innovatively uses the powerful logical reasoning ability of the large language model to execute the rules loaded by the rule engine, intelligently shortens the bid review process that previously required a lot of manual participation and time-consuming effort, significantly shortens the review period, reduces labor costs, shortens the review time from several hours or even several days to minutes, and effectively avoids the operational risks caused by human negligence.

[0219] The present application provides a complete, end-to-end, and highly reliable, flexible, and deeply cognitive bid intelligent review solution through the deep coupling of a series of technologies such as context-aware on-demand processing, multi-dimensional feature-based deep structure parsing, controllable LLM intent anchoring framework, and pluggable hybrid intelligent rule engine. The present application fundamentally solves the core pain points of the traditional method and the existing AI application in the bid review field, such as single review dimension, uncontrollable AI behavior, ambiguous intent positioning, rule solidification, and low system efficiency, and is a progress in promoting the field to a higher level of intelligence. It has strong advantages in industrial landing.

[0220] As Figure 2As shown, the multi-modal bid intention anchoring and rule pluggable auditing system provided by the embodiment of the present application can be implemented in a software manner, and the multi-modal bid intention anchoring and rule pluggable auditing system comprises the following software modules: an elementized splitting module 201, a hierarchical structure analysis module 202, a cross-modal cross-verification module 203, an auditing intention anchoring module 204, and a rule engine calling module 205.

[0221] The functions of each software module in the multi-modal bid intention anchoring and rule pluggable auditing system will be introduced as follows:

[0222] The elementized splitting module 201 is used for parsing and elementizing the original bid file to obtain a plurality of elements; each element retains its position information and unique path ID in the original bid file to ensure its context attribution relationship;

[0223] The hierarchical structure analysis module 202 is used for classifying all elements according to whether they are title classes, constructing a tree-shaped logical structure from top to bottom according to the levels of the title class elements and their order in the original bid file, and mounting the non-title class elements to the nearest parent title node in the logical structure according to the nearest principle to generate a document structure tree;

[0224] The cross-modal cross-verification module 203 is used for cross-modal information alignment and consistency verification of the document structure tree, and whether to modify the document structure tree is determined according to the verification result until the verification meets the preset requirement;

[0225] The auditing intention anchoring module 204 is used for parsing the auditing intention into a structured instruction package containing context and guiding subsequent operation, generating a hierarchical outline with type annotation by traversing the verified document structure tree, and injecting the hierarchical outline and the structured instruction package into the prompt word as context, and then anchoring the auditing intention based on the prompt word guidance and closed-loop verification;

[0226] The rule engine calling module 205 is used for calling the rule engine and starting the rule engine to perform auditing operation according to the anchored auditing intention to obtain an auditing result; wherein the rule engine is associated with the pluggable rule file in each directory of the original bid file.

[0227] It should be noted that the elementized splitting module 201, the hierarchical structure analysis module 202, the cross-modal cross-verification module 203, the auditing intention anchoring module 204, and the rule engine calling module 205 in the embodiment of the present application correspond to each step in the multi-modal bid intention anchoring and rule pluggable auditing method one by one, and the specific implementation process is the same, which will not be repeated here.

[0228] The structure of the electronic device of the embodiment of the present application will be described in detail as follows,Figure 3 The schematic diagram of the composition structure of the electronic device provided by the embodiment of the present application can be understood as follows, Figure 3 Only exemplary structures of the electronic device are shown, not all structures, and part or all of the shown structures can be implemented as needed.

[0229] The electronic device provided by the embodiment of the present application comprises at least one processor 301, a memory 302, a user interface 303 and at least one network interface 304. The various components in the multi-modal bid document intention anchoring and rule pluggable auditing system are coupled together through a bus system 305. It can be understood that the bus system 305 is used to realize the connection communication between the components. In addition to the data bus, the bus system 305 also includes a power bus, a control bus and a status signal bus. However, for the purpose of clear illustration, all the buses are marked as the bus system 305 in Figure 3 .

[0230] The user interface 303 can include a display, a keyboard, a mouse, a trackball, a click wheel, a key, a button, a touchpad or a touch screen, etc.

[0231] It can be understood that the memory 302 can be a volatile memory or a non-volatile memory, and can also include both volatile and non-volatile memories. The memory 302 in the embodiment of the present application can store data to support the operation of the terminal. Examples of the data include any computer programs for operating on the terminal, such as an operating system and an application program. The operating system contains various system programs, such as a framework layer, a core library layer, a driver layer, etc., for realizing various basic services and processing hardware-based tasks. The application program can include various application programs.

[0232] In some embodiments, the multi-modal bid document intention anchoring and rule pluggable auditing system provided by the embodiment of the present application can be realized in a combination of software and hardware. As an example, the multi-modal bid document intention anchoring and rule pluggable auditing system provided by the embodiment of the present application can be a processor in the form of a hardware decoding processor, which is programmed to execute the multi-modal bid document intention anchoring and rule pluggable auditing method provided by the embodiment of the present application. For example, the processor in the form of a hardware decoding processor can adopt one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs) or other electronic elements.

[0233] As an example, the processor 301 can be an integrated circuit chip with signal processing capability, e.g., a general purpose processor, a Digital Signal Processor (DSP), or other programmable logic device, discrete gate or transistor logic, discrete hardware components, etc. which have the signal processing capability.

[0234] As an example, the processor 301 can be an integrated circuit chip with signal processing capability, e.g., a general purpose processor, a Digital Signal Processor (DSP), or other programmable logic device, discrete gate or transistor logic, discrete hardware components, etc. which have the signal processing capability.

[0235] The memory 302 in the embodiment of the present application is used to store various types of data to support the operation of the multi-modal bid document intention anchoring and rule pluggable auditing system, or store programs for executing the methods shown in the embodiments of the present application. Figure 1 The examples of these data include any executable instructions for operating on the multi-modal bid document intention anchoring and rule pluggable auditing system, such as executable instructions, and the programs implementing the multi-modal bid document intention anchoring and rule pluggable auditing methods of the embodiments of the present application can be included in the executable instructions.

[0236] In particular, according to the embodiments of the present application, the processes described above with reference to the flowcharts can be implemented as a computer software program. For example, the embodiments of the present application include a computer program product comprising a computer program carrying on a computer readable medium, and the computer program contains program codes for executing the methods shown in the embodiments of the present application. Figure 1 In such embodiments, the computer program can be downloaded and installed from a network by a communication part, and / or installed from a detachable medium. When the computer program is executed by the central processing unit, various functions defined in the apparatus of the present application are executed.

[0237] The computer program instructions can also be loaded onto a computer, other programmable data processing apparatus, or other processing device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other processing device to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions specified in the flowchart block or blocks. Figure 1 The flowchart and / or block diagram in the Figures illustrate the architecture, functionality, and operation of possible implementations of apparatuses and computer program products according to various embodiments of the present application. In this regard, each flowchart block and / or block in the Figures can represent a module, segment, or portion of code, which comprises one or more executable Figure 1 Figure 1 The flowchart and / or block diagram in the Figures illustrate the architecture, functionality, and operation of possible implementations of apparatuses and computer program products according to various embodiments of the present application. In this regard, each flowchart block and / or block in the Figures can represent a module, segment, or portion of code, which comprises one or more executable

[0238] The above descriptions are only the preferred embodiment of the application, not intended to limit the application. Any modification, equivalent replacement and improvement made within the spirit and principle of the application shall be included in the protection scope of the application.

Claims

1. A method for intent anchoring and rule pluggable review of multimodal tender documents, characterized in that, The application relates to a method for realizing automatic auditing of a document, and belongs to the technical field of document automatic auditing. The method comprises the following steps: parsing and elementizing a raw bidding document to obtain a plurality of elements; each element retains position information and a unique path ID in the raw bidding document to ensure a context attribution relationship; classifying all the elements according to whether the elements are title elements, constructing a tree-shaped logical structure from top to bottom according to the levels of the title elements and the sequence of the title elements in the raw bidding document, and mounting non-title elements to the nearest parent title node in a logical sense according to a nearest principle to generate a document structure tree; performing cross-modal information alignment and consistency verification on the document structure tree, judging whether to modify the document structure tree according to a verification result, and stopping until the verification meets a preset requirement; analyzing an auditing intention into a structured instruction package containing a context and guiding subsequent operations, generating a hierarchical outline with type annotation by traversing the verified document structure tree, and injecting the hierarchical outline and the structured instruction package into a prompt word as a context, and then guiding and verifying the prompt word based on the prompt word to anchor the auditing intention; calling a rule engine and starting the rule engine to perform an auditing operation according to the anchored auditing intention to obtain an auditing result; wherein the rule engine is associated with pluggable rule files in each directory of the raw bidding document; classifying all the elements according to whether the elements are title elements by using a classifier, and the process is as follows: extracting basic layout features, content mode features, relative layout relationship features and content complexity features of each element by using the classifier, and forming an original feature vector; normalizing the original feature vector, and obtaining a probability that an element belongs to a title element by using a mapping relationship between the normalized feature vector and an element type; performing cross-modal information alignment and consistency verification on the document structure tree, and the process is as follows: traversing the entire document structure tree, extracting all entity nodes and constructing a preliminary knowledge graph in a document range; matching evidence sources and verification logics of each entity node from a cross-modal verification mode library according to the preliminary knowledge graph; wherein the cross-modal verification mode library pre-stores a series of verification rules, and each verification rule represents an entity node to be verified and its evidence source and verification logic; generating a corresponding verification task for a target entity node matched with the cross-modal verification mode library, searching for a node in the document structure tree and locating a target evidence node as an evidence source, and performing cross-modal alignment on the target entity node and the target evidence node; normalizing the target entity and the target evidence in the cross-modal alignment, and then performing similarity / consistency calculation, and judging whether the verification passes according to a comparison between a calculation score and a preset threshold; the process of analyzing the auditing intention into a structured instruction package containing a context and guiding subsequent operations is as follows: querying evidence clues related to the auditing intention from an associated knowledge base according to the auditing intention; 2. A multi-modal proposal intent anchoring and rules pluggable review method as claimed in claim 1, wherein, enhancing auditing intention description by using the queried evidence clues, and forming a structured instruction package containing a context and guiding subsequent operations. In the process of locating a target evidence, a node with the highest confidence is found as a target evidence node by calculating a relevance score of context text of the node in the document structure tree and the target entity.

3. A multi-modal proposal intent anchoring and rules pluggable review method as claimed in claim 1, wherein, The association knowledge base pre-stores a mapping table that maps each structured audit to a set of relevant evidence clues; the evidence clues are artificially pre-defined knowledge.

4. A multi-modal proposal intent anchoring and rules pluggable review method as claimed in claim 1, wherein, In the process of closed-loop verification, the legality of the check format and the existence of the verification path ID are verified.

5. A multi-modal proposal intent anchoring and rules pluggable review method as claimed in claim 1, wherein, In the process of starting the rule engine to perform the audit operation, the rule engine binds the rule itself with the specific data of the current audit, and then uses the rule interpreter in the rule engine to perform the audit operation on the specific data of the current audit.

6. A multi-modal proposal intent anchoring and rules pluggable review system, characterized in that, The intention anchoring and rule pluggable audit method of the modal tender is implemented by using the modal tender of any one of claims 1-5; comprising: An element splitting module is configured to parse and elementize the original tender file to obtain a plurality of elements; each element retains its position information and unique path ID in the original tender file to ensure its context attribution relationship; A hierarchical structure analysis module is configured to classify all elements according to whether they are title classes, construct a tree-shaped logical structure from top to bottom according to the level of the title class elements and their order in the original tender file, and mount the non-title class elements to the nearest parent title node in the logical structure according to the nearest principle to generate a document structure tree; A cross-modal cross-verification module is configured to perform cross-modal information alignment and consistency verification on the document structure tree, and determine whether to modify the document structure tree according to the verification result until the verification meets the preset requirements; An audit intention anchoring module is configured to parse the audit intention into a structured instruction package containing context and guiding subsequent operations, traverse the verified document structure tree to generate a hierarchical outline with type annotation, and inject the hierarchical outline and the structured instruction package into the prompt word as context, and then guide and anchor the audit intention based on the prompt word; A rule engine calling module is configured to call the rule engine according to the anchored audit intention, and start the rule engine to perform the audit operation to obtain the audit result; wherein the rule engine is associated with the pluggable rule file in each directory of the original tender file.

7. An electronic device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, The processor implements the steps of the intention anchoring and rule pluggable audit method of the multi-modal tender according to the program.

Images