A method, system, and medium for a rule native trusted retrieval augmentation generation

Abstract

The application discloses a rule native trusted retrieval enhancement generation method, system and medium, and relates to the field of retrieval enhancement generation.The method comprises the following steps: replacing vector semantic retrieval with classifier output rule identification; an independent version synchronization mechanism detects substantial changes in rules through structural hashing; a lightweight generative model is used to extract entities and instantiate rules, and business data is obtained on demand; rule trigger conditions can mark multi-modal sensing conditions and schedule multi-modal models by a rule engine, and sensing results are used as structured numerical backfilling; when applicability verification fails, associated rule recall and conflict resolution are triggered, and a traceable "cannot be determined" is output beyond the threshold, and a complete integrity hash and timestamp are output along with the cause and effect traceability and evidence chain.The application takes a rule knowledge base as a native management object, and the rule has an independent version identifier and a dependency graph, and the determination output of the classifier makes the rule identification anchoring become an endogenous ability of the system.The application is suitable for strong rule scenes such as customs, law and finance.

Description

Technical Field

[0001] This invention relates to the fields of retrieval enhancement generation technology and artificial intelligence, specifically to a native reliable retrieval enhancement generation method, system, and medium based on rule-based knowledge, applicable to strongly rule-driven scenarios such as customs, finance, healthcare, and industrial quality inspection. Background Technology

[0002] Retrieval augmentation, by connecting to external knowledge bases, alleviates the knowledge illusion problem of large language models to some extent. In this field, existing rule-based retrieval augmentation schemes, such as RuleRAG and RuAG, all adopt a "rule-guided retrieval augmentation" paradigm. A common feature of these methods is that they treat rules as external auxiliary tools for large language models, injecting them into the model in the form of prompts, embedding vectors, or logical expressions to assist in reasoning. Under this paradigm, rules are still retrieved as ordinary text, and the core matching mechanism remains vector semantic similarity calculation. Rules themselves lack independent lifecycles, version identification, and dependency management capabilities, making deterministic anchoring and associated recall of rule identifiers impossible.

[0003] Existing search enhancement generation architectures cannot meet the needs of rule-driven fields such as customs, finance, healthcare, and industrial quality inspection. Both the aforementioned technical solutions and standard search enhancement generation processes reveal the following significant shortcomings:

[0004] First, ambiguity in retrieval. Traditional vector retrieval relies on semantic similarity, but in rule-based scenarios, "semantic similarity" and "logical consistency" are not the same. For example, "whether the country of departure is a high-risk area" and "the list of high-risk areas includes the country of departure" are semantically similar, but they correspond to different rule identifiers. Vector retrieval is prone to hitting rules that appear related but are logically flawed.

[0005] Second, there's the issue of version consistency. With frequent rule updates, if the retrieval process caches an older version while the knowledge base has been upgraded, the system may not be aware of this difference, and inference might be based on outdated rules. Current RAG knowledge base version management is document-level, lacking fine-grained differentiation and management capabilities.

[0006] Third, there is a lack of logical certainty. Traditional retrieval augmentation generation treats rules as fragments of natural language, relying on large model reasoning, which is prone to logical illusions and cannot restore the rule basis in the reasoning process. In addition, the knowledge recall of traditional retrieval augmentation generation cannot achieve top-1 precision recall. In multi-fragment recall, these fragments contain noise or logical conflicts and errors, which further amplifies the bias and illusions in the reasoning of LLM.

[0007] Fourth, the chain of evidence is missing. Traditional methods can only identify which document fragments the answer may come from, but cannot provide a complete traceability chain from query to rule matching, data extraction, reasoning execution to the final conclusion, let alone trace the causal influence path between rules.

[0008] Fifth, the reasoning path is rigid and lacks error correction. Traditional retrieval enhancement generation uses a fixed link, and once a rule match is incorrect, the entire reasoning link will produce cascading deviations. The system lacks a mechanism to detect and correct errors in subsequent stages.

[0009] To address the aforementioned issues, this invention proposes a "rule-based native retrieval enhancement generation" paradigm, fundamentally redefining the role of rules in the retrieval enhancement generation system. Rules are no longer simply retrieved text or external prompts, but rather natively managed objects with independent version identifiers, dependency graphs, and dynamic evolution capabilities in retrieval enhancement generation. This paradigm shift reconstructs the entire technological framework from knowledge representation to trusted generation.

[0010] Therefore, there is an urgent need for a deterministic retrieval enhancement generation method that uses rules as the native management object, replaces semantic retrieval with classification retrieval, incorporates conflict resolution, applicability verification and error correction mechanisms, and outputs a structured evidence chain that includes causal tracing. Summary of the Invention

[0011] This invention aims to solve the following problems in the generation of enhanced domain retrieval based on strong rules:

[0012] 1. The ambiguity problem of "semantic similarity ≠ logical equivalence" in vector semantic retrieval under rule-based scenarios.

[0013] 2. Traditional retrieval enhancement generation lacks post-retrieval error correction capabilities, leading to reasoning failure due to a single matching error.

[0014] 3. The problem of indeterminate rulings when rules conflict.

[0015] 4. The reasoning process lacks a traceable, structured chain of evidence.

[0016] 5. The problem of being unable to trace the causal influence path between rules based on the decision-making results.

[0017] Technical solution

[0018] This invention provides a rule-based native trusted retrieval enhancement generation method, which relies on a structured QIR-KG (Query-Intent & Instruction-Rule-Knowledge Graph) information model to organize the rule knowledge base. This model includes: a natural language request unit (Q unit) for storing standard question text, serving as a generalization seed for classifier training samples; an intent and instruction unit (I unit) for defining data acquisition parameters and processing instructions; a rule unit (R unit) for storing structured rule logic, dependencies, and version information; and a knowledge graph unit (KG unit) for storing domain entity attributes and embedding vectors, supporting multimodal entity storage. The rule knowledge base is a closed, enumerable set of rule identifiers, with each rule possessing an independent version identifier and structure hash. Additionally, there is an extended metadata unit for storing structure hashes, version numbers, and other data. The method includes the following steps:

[0019] S1. First Search Stage: Rule Identification and Classification

[0020] The system receives natural language queries from users and directly outputs target rule identifiers and confidence scores through a classifier, replacing semantic similarity-based vector retrieval with a deterministic classification retrieval mode. This classifier is based on a pre-trained language model and is fine-tuned on a sample set consisting of query text (generalized by synonym replacement, reversal, addition of typos, colloquialization, etc.) paired with rule identifiers. The output is a probability distribution over a pre-defined set of rule identifiers, and the rule identifier with the highest probability is selected as the target rule identifier.

[0021] When the classifier correctly matches a rule identifier, the system uses that rule identifier as an anchor point to enter the subsequent processing flow. Throughout the process, the rules are supported by the structured version management, dependency graph, and causal tracing capabilities of the knowledge base, which is fundamentally different from directly retrieving unstructured text in traditional retrieval enhancement generation.

[0022] In one implementation, the system input may include multimodal data, such as image reference URLs, sensor data stream identifiers, and video keyframe indexes. This multimodal data is received along with the query text in stage S1 as part of the association context, and is used by the multimodal perception model in subsequent stage S3. The multimodal data itself does not participate in the text classification decision of the classifier; it is only used as input data references for the perception model.

[0023] In one implementation, when deployed offline at the edge or in a weak network environment, S1 uses a locally deployed classifier model and cached rules for inference. This local classifier is maintained by an independent version synchronization mechanism: when the synchronization mechanism detects a change in the central rule identifier set (such as the addition or deletion of rules), it will synchronously update the local rule identifier set and download the updated classifier model to replace the local classifier, so as to ensure that the classifier output space and the rule knowledge base are always consistent.

[0024] S2, Target Rule Acquisition

[0025] The target rule is retrieved from the rule knowledge base based on the rule identifier output by S1, and the rule's version identifier and structure hash are recorded as metadata for subsequent tracing. After retrieving the rule, it proceeds to S3 for rule instantiation and S4 for applicability verification. If S4 verification passes, the subsequent conflict resolution stage is skipped; conflict resolution is only initiated when S4 verification fails and error correction and recall are triggered.

[0026] This step is divided into two working modes based on the system deployment mode:

[0027] (1) Cloud-based centralized deployment mode: The system directly accesses the central rule knowledge base and central classifier service in real time, and obtains the target rules and their version identifiers, structure hashes, version change history and other metadata online without local caching.

[0028] (2) Offline deployment at the edge or weak network environment mode: The system retrieves the target rule from the local cache and uses the locally deployed classifier model. The local cache and local classifier are maintained by an independent version synchronization mechanism. This mechanism is decoupled from the core retrieval process. When the device is online (such as when the system starts up, the network recovers, or a scheduled task is triggered), it actively performs the following synchronization operations: ① Compare the structure hash corresponding to the same rule identifier in the local cache with that in the central rule knowledge base. If an inconsistency is found, it is determined that the rule has undergone substantial changes. The rule and its associated rules in the dependency graph are pulled for incremental synchronization, and the local cache is updated; ② Detect whether the set of rule identifiers in the central end has changed (addition or deletion of rules). If a change has occurred, the local rule identifier set is updated synchronously, and the updated classifier model is downloaded to replace the local classifier, so that the classifier output space is consistent with the rule knowledge base. After synchronization is completed, a version change history containing rule change records and classifier model update records is generated. In offline or weak network conditions, the synchronization mechanism is automatically paused, and the system completes the entire process directly based on the existing local cache and local classifier to ensure that core business functions are not affected by the network. After the network is restored, the synchronization mechanism continues to execute and incorporates the version change history when generating subsequent evidence chains.

[0029] S3. Second Retrieval Stage: Entity Extraction, Rule Instantiation, and Data Acquisition

[0030] A lightweight generative model extracts business entities from user queries, and the extracted entity values ​​are filled into the trigger condition template of the current processing rule, completing rule instantiation. Based on the data fields referenced in the instantiated rule, the source type of the required data is automatically identified. Supplementary data is retrieved from the business database or external system through the data retrieval instructions preset in the rule, and the retrieved data is filled into the corresponding fields of the rule template, giving the rule complete data support. The lightweight generative model used in this step is independent of the large language model that can be optionally configured in the subsequent trusted generation steps, and can be selected separately according to the scenario.

[0031] In one implementation, the trigger condition template of the rule supports explicit labeling of one or more multimodal perception conditions. Multimodal perception conditions include modality type (visual, auditory, sensor, video, etc.), perception task type (object detection, optical character recognition, time-series signal reading, etc.), calling model identifier, expected output field, and timeout parameters. When a trigger condition containing a multimodal perception condition is detected during instantiation, the rule engine directly schedules the corresponding multimodal model to execute the perception task according to the pre-set calling instructions in the I-unit. The scheduling method is decoupled calling through standardized instructions—the standardized instructions include the task type, input data reference (such as image URL, sensor device ID), expected output format, and time constraints. The multimodal model and the S3 entity extraction model are independent of each other and can be selected separately according to the scenario without affecting each other.

[0032] After the multimodal model is executed, its output consists only of structured numerical values ​​(e.g., diameter = 0.52mm, temperature = 195℃, coordinates = [x,y,w,h], etc.), without any judgment conclusions (e.g., "qualified / unqualified" or "high risk / low risk"). These structured numerical values ​​are then backfilled into the corresponding fields of the rule's trigger condition template and, along with the entity values ​​extracted from the text, are entered into the subsequent S4 applicability verification step. The confidence score within the multimodal model can be recorded as execution quality metadata in the S5 evidence chain, but it does not participate in the rule engine's decision logic—the rule engine only uses the backfilled structured numerical values ​​for deterministic condition judgment. When multiple independent multimodal perception conditions exist, the system can schedule each modality model in parallel, and a single modality failure does not contaminate other modality evidence. This design incorporates multimodal perception into the rule's native deterministic framework, which is fundamentally different from the probabilistic weighting method in existing multimodal fusion methods.

[0033] S4. Applicability Verification and Error Correction / Recall

[0034] Applicability verification is performed on the instantiated rules. The data required for each conditional expression in the triggering conditions comes from all data acquired in the S3 phase—including text entity values ​​extracted by the lightweight generative model, supplementary data obtained from business data sources, and structured numerical values ​​returned by the multimodal model. The structured numerical values ​​returned by the multimodal model directly participate in the Boolean determination of the triggering conditions (e.g., determining whether "bubble diameter ≥ 0.5mm" is true).

[0035] Simultaneously, it detects whether there is a semantic contradiction between the user's query intent and the rule's conclusion. Semantic contradiction detection only compares the similarity between the user's input natural language query text and the fused semantics of the rule's standard question text in the Q unit and the conclusion text in the R unit. Multimodal structured numerical values ​​are not involved in semantic contradiction detection.

[0036] The confidence level mentioned in this step, which is below the preset threshold, refers to the classification confidence level output by S1. In strong rule scenarios, the classifier aims for high accuracy on a closed rule set. When the confidence level is insufficient, it indicates that the classifier is not very certain about the match and should be handled by downstream verification and error correction mechanisms as a fallback.

[0037] If the applicability verification passes, proceed to step S5. If the applicability verification fails, trigger the association rule recall. The association rule recall performs a directed search along the dependency graph between rules. The recalled candidate rules constitute a candidate rule set, and the winning rule is selected based on the applicability score. The applicability score is calculated based on at least two of the following dimensions: regulatory rank weight, rule recentity, rule applicability accuracy, historical adoption rate, and rule granularity matching degree; each dimension and its weight can be customized according to the application scenario. The winning rule returns to S3 for re-instantiation. If the candidate rule set contains only one rule, it wins directly. When the number of association rule recalls exceeds the configured limit, proceed to step S5. The above error correction closed-loop process can be found in [link to relevant documentation]. Figure 2 .

[0038] S5. Causal Tracing and Evidence Chain Generation

[0039] Based on the rule-generated judgment conclusion, the rule is either a rule that passed the applicability verification in S4 or an original rule that failed verification due to exceeding the configured recall limit in S4. Starting with a rule, the dependencies and influence strengths between rules are obtained from the rule knowledge base, and causal tracing is performed: a forward weighted breadth-first search is performed along the dependency direction, multiplying the cumulative influence strength of the current node by the edge weight and propagating it to downstream nodes. When multiple paths reach the same node, the maximum cumulative strength is taken; propagation stops when the cumulative strength is lower than the preset propagation threshold, the propagation depth exceeds the preset maximum depth, or the total number of traced nodes exceeds the preset limit; the set of rules in the influence domain, the cumulative influence strength of each rule, and the propagation path are output. Among them, the influence strength can be preset with a default value according to the dependency type: for example, "direct reference" is assigned 0.9, "superordinate" is assigned 0.7, and "reference" is assigned 0.5; when the specific dependency type cannot be distinguished, a comprehensive default value of 0.8 is used. The above values ​​are examples, and can be configured according to the application scenario in actual implementation.

[0040] The judgment conclusion, rule tracing information (including rule source, version number, and structure hash), data access summary, causal tracing results (impact domain, cumulative strength, propagation path), candidate rule list, and applicability score are assembled into a structured evidence chain. Each link in the evidence chain is appended with an integrity hash and a timestamp, and stored in a secure storage medium to ensure immutability. The version change history of the rules involved in this judgment is also included in the evidence chain. If applicability verification fails in S4 and the recall limit is exceeded, this step outputs "Unable to determine," along with the aforementioned evidence chain.

[0041] S6, Trusted Generation

[0042] This step is optional. The winning rule content that has passed applicability verification, its associated rules, the original query text, and supplementary data obtained from the business data source are injected into the large language model, and reliably generated using a predefined prompt word template. The prompt word template must include at least the following constraints: role constraints (clearly stating that the LLM only acts as the organizer of rule data and the executor of formatted output), input data boundaries (clearly listing the scope of rule content, business data, and query text that can be used this time), output format specifications (specifying the JSON Schema or Markdown template for the output results), and a list of prohibited behaviors (prohibiting the introduction of external knowledge, prohibiting unauthorized expansion of conclusions, and prohibiting modification of rule judgment results). The prompt word template restricts the large language model to only organize, summarize, and format output based on the provided rule content and structured data, and prohibits the introduction of judgment criteria outside the rules or unauthorized expansion of conclusions. The large language model used in this step is independent of the lightweight generative model used in S3 entity extraction, and the two can be selected separately according to the task complexity. This step is suitable for scenarios that require generating detailed analysis reports, comprehensive judgment opinions, or formatted output results. If this step is not enabled, the evidence chain generated by S5 is directly used as the system output result.

[0043] The method uses a rule knowledge base as the native management object. Rules are no longer ordinary text being retrieved, but rather native entities with independent version identifiers and dependency graphs. The classifier uses deterministic classification instead of vector semantic retrieval as the first hop for rule matching, making entry point determination an intrinsic capability of the system. The method's rule trigger condition templates further support explicit labeling of multimodal perception conditions. The rule engine schedules the multimodal model and uses the perception results as structured evidence for backfilling. The output of the multimodal model is only structured numerical values ​​and does not contain judgment conclusions.

[0044] Beneficial effects

[0045] 1. Paradigm-level Innovation: For the first time in the field of retrieval augmentation generation, a paradigm shift from "semantic matching" to "deterministic classification" has been achieved. Rules are no longer external tools assisting large language models, but rather natively managed objects with independent version identifiers and dependency graphs. Traditional retrieval augmentation generation is based on vector semantic retrieval, with rules being retrieved as ordinary text.

[0046] 2. Substantial Change Detection for Rule Versions: Through a structure hashing mechanism, the system can accurately determine whether the logical content of a rule has undergone substantial changes, rather than relying solely on version number comparison. Structure hashing is generated based on the standardized serialization of the rule abstract syntax tree, avoiding redundant versions caused by format adjustments or modifications to non-critical fields, ensuring accurate and efficient version management.

[0047] 3. Closed-loop error correction and fault tolerance: An error correction closed loop is formed through applicability verification and association rule recall to automatically correct classification bias. The number of recalls is limited to balance low latency and fault tolerance.

[0048] 4. Automatic conflict resolution: A multi-dimensional applicability scoring mechanism ensures that a unique and optimal rule is selected when conclusions conflict. The dimensions and weights can be customized according to strong rule scenarios such as law and customs, and the resolution process is traceable.

[0049] 5. Causal Tracing and Full-Link Evidence Chain: Deeply integrating causal impact tracing between rules with the decision-making evidence chain, it propagates forward from the ultimately applicable rule, quantifies the impact intensity, and outputs the impact domain and propagation path, elevating the audit traceability of decision conclusions from "evidence of results" to "causal traceability." Each link in the evidence chain is recorded with an additional integrity hash and timestamp to ensure immutability and meet functional safety audit requirements.

[0050] 6. Decoupling rule instantiation from data retrieval: Instantiate rules first and then retrieve data on demand to avoid unnecessary data calls and improve efficiency.

[0051] 7. The entire rule execution process is explainable: from rule identification and matching, entity extraction, data acquisition to causal tracing, every step is recorded, meeting the requirements of strict regulatory audits.

[0052] 8. Flexible deployment of hierarchical models: S3 entity extraction uses a lightweight generative model to ensure low latency, while S6 trusted generation can be equipped with a large language model with larger parameter scale to meet the needs of complex report generation. The two-stage models can be selected according to the scenario, taking into account both efficiency and effectiveness.

[0053] 9. Multimodal Deterministic Anchoring: Triggering conditions support explicit labeling of multimodal perception conditions. The rule engine directly schedules the multimodal model through standardized instructions and uses the perception results as structured evidence for backfilling. The output of the multimodal model is only structured numerical data and does not contain decision conclusions. Its internal confidence level is only recorded as metadata and does not participate in the rule engine's decision logic. The multimodal model and the entity extraction model are completely decoupled and independently invoked through standardized instructions. Unlike the probabilistic weighting method in existing multimodal fusion methods, this scheme incorporates multimodal perception into the rule's native deterministic framework. Even if the confidence level of a single modality's perception model is low, as long as the backfilled value meets the rule threshold, the decision result is unaffected, achieving error isolation between modalities. Attached Figure Description

[0054] Figure 1 This is an overall flowchart of the method of the present invention.

[0055] Figure 2 This is a closed-loop flowchart of step S4, applicability verification and error correction recall, in the method of the present invention. Detailed Implementation

[0056] To make the objectives, technical solutions, and advantages of this invention clearer, a detailed description is provided below with reference to embodiments. The described embodiments are only a part of this invention, not all of it. All default values ​​appearing in this specification are illustrative and do not constitute a limitation on the scope of protection of this invention; those skilled in the art can configure them to other values ​​according to actual application scenarios.

[0057] System initialization

[0058] Before executing the method, the following preparations must be completed:

[0059] 1. Definition and Construction of Rule Knowledge Base

[0060] The rule knowledge base of this invention organizes data using the following structured QIR-KG information model. The formal definitions of each core unit are as follows:

[0061] Q-unit (Natural Language Request Unit): Q = (query_text, query_type, multimodal_ref), where query_text is a non-empty string storing the standard question text, serving as a seed for generalization in the classifier training samples; the S1 classifier receives real-time natural language queries from the user, and the classification model trained by generalizing from this standard question outputs the matched rule identifier and confidence score; query_type ∈ {rule validation, data retrieval, compliance judgment, knowledge query}, optional; multimodal_ref is a multimodal data reference, optional. Integrity constraint: Each record must contain a Q-unit and query_text cannot be empty.

[0062] Unit I (Intent and Instruction Unit): I = (intent_type, data_access_params, instruction, multimodal_instruction), where intent_type ∈ {rule validation, data retrieval, visual inspection, process verification}; data_access_params is a JSON object defining data acquisition parameters; instruction is a non-empty string defining the specific instruction for data acquisition or model scheduling; multimodal_instruction is the multimodal scheduling instruction, optional. Integrity constraint: intent_type is a predefined enumeration value.

[0063] R Unit (Rule Unit): R = (rule_id, trigger_condition, execution_logic, output_conclusion, source, rule_version, rule_structure_hash, rule_relations). Where rule_id is the classifier label; trigger_condition supports AND, OR, NOT logical combinations and spatial relation operators such as above, below, and contain; execution_logic supports execution modes such as serial, parallel, loop, branch, and visual inspection; source contains information such as filename, clause number, original description, and priority; rule_version is the incrementing version number; and rule_structure_hash is the rule structure hash.

[0064] `rule_relations` is a list of dependencies, each containing the target rule identifier, dependency type, and impact strength. Integrity constraints: fields referenced in `trigger_condition` must exist in KG unit entity attributes or system predefined fields; `target_rule_id` in `rule_relations` must point to an existing rule identifier.

[0065] KG (Knowledge Graph Unit): KG = {entities}, where each entity is represented as (id, type, embedding_vector, attributes, timestamp). The embedding_vector ∈ ℝᵈ (default d = 128); attributes is a JSON object storing domain entity attribute key-value pairs, providing factual data for applicability verification; the embedding_vector is used for semantic contradiction detection. KG units support multimodal entity storage. Original references to multimodal data such as visual and sensor data are stored in attributes. The embedding vectors are generated by the corresponding encoder and share the same vector space as text entities. Integrity constraint: Each record must contain at least one entity, supporting either text or visual types.

[0066] The basic semantics of a rule unit are: when the trigger_condition is true in the current state of the KG unit, execute the action sequence defined by execution_logic to obtain output_conclusion. The semantics of visual spatial relation operators are defined as: above(A,B) ≡ yA < yB, below(A,B) ≡ yA > yB, contain(A,B) ≡ xB1 < xA < xB2 ∧ yB1 < yA < yB2, with the origin of the coordinate system defaulting to the top left corner. Rule matching can be performed using linear scanning or optimized with a RETE network.

[0067] The QIR-KG information model also includes extended metadata units that store metadata such as version numbers, structure hashes, and change history.

[0068] The following is a compact JSON serialization example of a ship risk rule, showing the key fields of each core unit:

[0069] {"q_layer":{"query":"Check the risk level of the Ocean Ship","query_type":"Rule validation"},

[0070] "i_layer":{"intent_type":"rule validation","data_access_params":{"vessel_name":"Oceanic"},

[0071] "instruction":"SELECT risk_level FROM vessel_risk WHERE name='Ocean'"},

[0072] "r_layer":{"rule_id":"R001","trigger_condition":{"operator":"AND",

[0073] "conditions":[{"field":"origin_region","operator":"in","value":["A","C"]},

[0074] {"field":"violation_count","operator":">=","value":3}]},

[0075] "output_conclusion":"High Risk","source":{"file":"Regulations on Ship Risk Management.pdf","clause":"Article 3"},

[0076] "rule_version":1,"rule_structure_hash":"a1b2c3...","rule_relations":

[0077] [{"target_rule_id":"R005","relation_type":"triggers","strength":0.8}]},

[0078] "kg_layer":{"entities":[{"id":"e1","type":"vessel","attributes":

[0079] {"name":"Oceanic","origin_region":"C","violation_count":4},

[0080] "embedding_vector":[]}]}}.

[0081] In plain text scenarios, setting multimodal-related fields to null allows the system to run in lightweight mode; in multimodal scenarios, visual reasoning capabilities are enabled through field expansion.

[0082] The construction process of the rule knowledge base includes: extracting rules from rule documents and data sources in the target domain, parsing them into a three-layer abstract structure of triggering conditions, execution logic, and output conclusions; generating Q-layer query text and I-layer instructions through natural language processing; calculating the structure hash and assigning an initial version number; and writing the dependencies between rules into a dependency list. The completed rule knowledge base maintains a closed and enumerable set of rule identifiers, with each rule possessing an independent version identifier and structure hash.

[0083] Structure hashes are calculated as follows: the triggering conditions and execution logic of a rule are parsed into an abstract syntax tree, and normalization processes such as variable name unification, removal of redundant parentheses, stable sorting of child nodes, constant folding, and deduplication are performed. After serialization, the structure hash is concatenated with the rule's external dependencies to calculate the SHA256 hash value. Structure hashes are generated based on the normalized serialization of the rule logic and are used to accurately determine whether a rule has undergone substantial changes—if the structure hashes of the old and new versions are consistent, the rule logic remains unchanged, and version synchronization is not triggered.

[0084] 2. Classifier Training

[0085] The system pairs rule identifiers from rule logic expression units with query text from natural language request units, augments samples through synonym replacement and sentence structure transformation, and fine-tunes the pre-trained language model using cross-entropy loss and early stopping strategies. The classifier output is a probability distribution over a pre-defined set of rule identifiers.

[0086] 3. Preparation of Generative Models

[0087] S3 entity extraction uses a lightweight generative large language model, requiring no fine-tuning of the rule knowledge base. It only requires specifying the set of entity fields to be extracted in the prompt words, and the output entity values ​​are strictly constrained within this set. S6 reliable generation can be equipped with a large language model with a larger parameter scale; the two-stage model can be selected separately according to the scenario.

[0088] 4. Multimodal model deployment

[0089] Based on the multimodal perception conditions defined in Unit I, a corresponding perception model invocation instruction is configured for each rule containing multimodal conditions. The perception models are deployed independently and decoupled from the rule engine through a standardized instruction interface. The standardized instructions include task type, input data reference, expected output format, and time constraints. The capability tags (such as "object detection" and "optical character recognition"), input / output specifications, and timeout parameters of each perception model are recorded in the policy registry. During scheduling, the rule engine dynamically matches models based on their capability tags and invokes them decoupledly through standardized instructions, supporting independent upgrades and replacements of multimodal models without affecting the normal operation of other modules.

[0090] 5. Business data source configuration

[0091] Based on the intent and instruction unit definition, configure the corresponding database connection, query statement or API call parameters for the data fields referenced by each rule.

[0092] 6. Applicability scoring dimension configuration

[0093] Select and configure applicability scoring dimensions and weights based on the application scenario; customization is supported. Dimensions include, but are not limited to, regulatory hierarchy weight, recentity of effective date, accuracy of rule applicability, historical adoption rate, and rule granularity matching degree.

[0094] Independent version synchronization mechanism

[0095] This invention employs an independent version synchronization mechanism to maintain version consistency between the local cache and the local classifier when deployed offline at the edge or in a weak network environment. This mechanism runs independently as a background service, implemented by the client during system initialization, and is completely decoupled from the core retrieval and generation process of S1 to S6. Its operation is not driven by user query requests.

[0096] 1. Triggering timing

[0097] The version synchronization mechanism is automatically triggered when any of the following conditions are met:

[0098] The system detects that a network connection is available upon first startup or restart.

[0099] Restore network connectivity from offline or weak network status to a stable network connection;

[0100] Execute at preset time intervals (e.g., every 1 hour, every 24 hours, which can be configured according to the scenario);

[0101] Receive version update notifications pushed from external sources (optional, suitable for real-time synchronization scenarios based on message queues).

[0102] 2. Synchronization Process

[0103] Each time a synchronization task is executed, follow these steps:

[0104] Step A: Rule Identifier Set Change Detection. Obtain the current complete set of rule identifiers in the central rule knowledge base and compare it with the rule identifier set stored locally. If any added or deleted rule identifiers are found, record the change details and update the changed rule identifier set to local storage.

[0105] Step B: Rule Structure Hash Comparison and Incremental Synchronization. For each rule in the rule identifier set, compare the current structure hash at the central end with the structure hash of the same rule identifier in the local cache. If they do not match, it is determined that the rule has undergone substantial changes. The latest version of the rule is retrieved from the central end, and the latest versions of related rules along its dependency graph are retrieved and updated in the local cache.

[0106] Step C: Classifier Model Update. If Step A detects a change in the rule identifier set, the latest classifier model file matching the current rule identifier set is downloaded from the central server, replacing the local classifier model, and the successful model loading is verified.

[0107] Step D: Record version change history. Summarize all changes generated during this synchronization (addition / deletion / modification of rules, changes in the hash structure of each rule, version switching of classifier models, etc.), generate a version change history record, persist it locally, and append this change history to the local cache metadata of the relevant rules, so that the rules themselves carry complete version evolution information.

[0108] 3. Offline operation strategy

[0109] When a device is offline or in a weak network state, the version synchronization mechanism automatically pauses and does not make any network requests. The core retrieval and generation process (S1 to S6) operates normally based on the existing local cache and local classifier, unaffected by the pause in the synchronization mechanism. Once the network is restored, the synchronization mechanism immediately triggers a synchronization task to synchronize the rule and classifier changes generated at the central end during the offline period to the local machine in one go, and records the version change history. This historical record will be included in the next S5 evidence chain generation to ensure that even if an older version of the rules was used during the offline period, its version status can still be fully traced.

[0110] For the centralized cloud deployment mode, the system does not rely on local caching and synchronization mechanisms. The version change history of the target rule is directly maintained in the rule model by the central rule knowledge base and is obtained by S2 when it retrieves the rule, ensuring the integrity of version traceability information.

[0111] Core computing and verification mechanisms

[0112] 1. Applicability scoring formula for conflict resolution

[0113] The applicability score is defined as a weighted sum of the selected dimensions. The calculation methods for each dimension are as follows: The weight of the regulatory rank can be customized, for example, laws are 1.0, administrative regulations are 0.8, departmental rules are 0.6, and normative documents are 0.4. The recentity of the effective date is calculated using an exponential decay model. The rule applicability precision is the number of fields in the rule triggering conditions that match the query facts divided by the total number of fields in the conditions. The historical adoption rate is the number of adoptions divided by the total number of triggers. The rule granularity matching degree can be customized, for example, specific clauses are 1.0, general clauses are 0.6, and principle clauses are 0.3. Weights can be configured according to the scenario; the above values ​​are only examples.

[0114] 2. Causal Tracing and Propagation Rules

[0115] The initial cumulative strength of the winning rule is set to 1.0. For directed edges, the cumulative strength propagation rule is to multiply the cumulative influence strength of the current node by the edge weight and propagate it to downstream nodes. The maximum value is taken when multiple paths reach the same node. Propagation termination conditions are configurable: the cumulative strength is lower than a preset propagation threshold, the propagation depth exceeds a preset maximum depth, or the total number of traced nodes exceeds a preset upper limit. The influence strength can be preset with a default value based on the dependency type: for example, 0.9 for "direct reference," 0.7 for "upper / lower reference," and 0.5 for "reference." When the specific dependency type cannot be distinguished, a comprehensive default value of 0.8 is used. The above values ​​are examples; actual implementation can be configured according to the application scenario.

[0116] 3. Association rule recall method

[0117] Dependency-directed graph recall: Directed retrieval is performed along the dependency graph formed by the dependency relationship fields. The recall depth does not exceed the preset depth, which is configurable. The recall rules are sorted according to the applicability score, and the highest score enters the next stage.

[0118] 4. Semantic Contradiction Detection Method

[0119] The user-input natural language query text is encoded into a vector. Simultaneously, the fused semantics of the standard question text (query_text) stored in the Q unit and its conclusion text (output_conclusion) in the R unit are encoded into a vector. The cosine similarity between the two vectors is calculated. When the similarity is higher than a preset semantic consistency upper threshold, it is considered semantically consistent. When the similarity is lower than a preset semantic contradiction threshold, it is considered semantically contradictory, and the applicability verification is considered a failure. When the similarity is between the two thresholds, it is considered semantically uncertain, and the applicability score of the current rule is multiplied by a preset decay factor and recorded. Both the threshold and decay factor are configurable parameters. Semantic contradiction detection only applies to the semantics of the user query and the rule; multimodal structured numerical values ​​are not involved.

[0120] 5. Multimodal evidence backfilling mechanism

[0121] For multimodal perception conditions marked in the trigger conditions, the rule engine schedules the multimodal model to execute the perception task through standardized instructions. The structured numerical values ​​returned by the model are then directly filled into the corresponding fields of the trigger conditions. The standardized instructions include the task type, input data references, expected output fields, and timeout parameters. For example, if the visual model returns a diameter of 0.52mm, this value is directly used to determine whether the trigger condition "bubble diameter ≥ 0.5mm" is true. The confidence score (e.g., 0.85) within the multimodal model is only recorded as execution quality metadata in the S5 evidence chain and does not participate in the logical judgment of the trigger conditions. This mechanism ensures that the output of multimodal perception and the entity values ​​extracted from text are processed uniformly within a deterministic framework—the rule engine only recognizes numerical values, not confidence scores. When there are multiple independent multimodal perception conditions, the system can schedule each modality model in parallel, and a single modality failure will not contaminate the evidence of other modalities. The data required for each condition expression in the trigger conditions comes from three channels: text extraction, business data query, and multimodal perception. The structured numerical values ​​returned by the multimodal model are directly used in the Boolean determination of the triggering conditions, while the internal confidence level is only used as metadata and does not participate in the decision-making process.

[0122] Example 1: Customs Vessel Risk Inquiry. This example uses customs vessel risk screening as a scenario to demonstrate the complete process of rule-based native trusted retrieval enhancement generation, including one-time pass of applicability verification, semantic contradiction detection triggering conflict resolution, and outputting "Unable to determine" when the confidence level is below the threshold and the applicability verification fails.

[0123] The rule base contains the following rules: R001 (High-risk area determination rule, triggered by "originating country ∈ [A,C] and number of violations ≥3", conclusion is "high risk"); R008 (Medium-risk determination rule, triggered by "originating country ∈ [A,C] and number of violations ≥1", conclusion is "medium risk"); ENV_023 (Electronic waste environmental inspection rule, conclusion is "return or destruction required"); CUS_089 (Solid waste determination rule, conclusion is "belongs to prohibited imported solid waste").

[0124] Scenario A: The classifier outputs a confidence score greater than the threshold, and the applicability verification passes on the first attempt.

[0125] The user entered: "Check the risk level of the Yuanyang, the country of departure is C."

[0126] S1: The classifier outputs rule identifier R001 with a confidence score of 0.97, which is greater than the threshold of 0.7. S2: Obtain the target rule R001. S3: Extract "Ship Name = Ocean Ship, Country of Origin = C", query "Number of Violations = 4" from the ship database, and fill it into the trigger condition template. S4: The trigger condition "Country of Origin ∈ [A, C] and Number of Violations ≥ 3" is met, and the semantic contradiction detection similarity is 0.88, thus passing the verification. S5: Perform causal tracing starting from R001. The influence domain includes R005 (0.8), R012 (0.64), and R003 (0.65). Generate an evidence chain, attaching an integrity hash and timestamp. S6 (Optional): Not enabled in this scenario. Output conclusion: "High Risk".

[0127] Scenario B: Semantic contradiction detection triggers conflict resolution

[0128] The user entered: "Is an imported used washing machine considered prohibited solid waste?"

[0129] S1: The classifier outputs rule identifier ENV_023 with a confidence score of 0.92, which is greater than the threshold. S2: Obtain the target rule and proceed directly to S3. S3: Instantiate ENV_023 and retrieve data from the business database; the data is complete. S4: The triggering condition for ENV_023 is met by the data, but the semantic contradiction detection calculation shows that the similarity between the user query semantics and the fused semantics of the rule standard question text and the conclusion text of the R unit is only 0.31, which is lower than the contradiction threshold of 0.5. Therefore, it is judged as a semantic contradiction, and the verification fails. Trigger association rule recall, recalling CUS_089. S2 Conflict resolution: The candidate set contains both ENV_023 and CUS_089; CUS_089 wins. S3: Re-instantiate CUS_089. S4: CUS_089 passes verification. S5: Perform causal tracing starting from CUS_089, generate an evidence chain, record semantic contradiction detection details, and attach an integrity hash and timestamp. Output the conclusion: "This old washing machine belongs to solid waste prohibited from import."

[0130] Scenario C: If the confidence level is below the threshold, the applicability verification fails and the output is "Cannot be determined".

[0131] The user typed: "Is there a problem with that ship?"

[0132] S1: The classifier outputs R001 with a confidence score of 0.32, which is lower than the preset threshold of 0.5. S2: Obtain the target rule. Enter S3 for instantiation, instantiating rule R001. Because the user input "Is there a problem with that ship?" lacks a valid entity, the entity cannot be extracted for data acquisition and backfilling. S4: Applicability verification fails, triggering association rule recall. The winning rule re-enters S3 for instantiation, ultimately exceeding the recall limit, and no rule passes verification. S5: Generate an evidence chain, outputting "Unable to determine," a list of candidate rules, rule applicability scores, and other structured evidence, along with an integrity hash and timestamp.

[0133] Example 2: Multi-rule conflict resolution (legal scenario). This example demonstrates the complete process of resolving conflicts through applicability scoring when multiple rules are competing.

[0134] A user entered: "I am a sole proprietor and want to recruit franchisees to open stores. Is the contract valid?"

[0135] S1: The classifier outputs rule identifier CIVIL_153 (Article 153 of the Civil Code, civil legal acts that violate mandatory provisions are invalid), with a confidence level of 0.92. S2: Obtain the target rule and proceed to S3. S3: Extract entities such as "individual business owner" (subject type) and "entering a franchise contract" (behavior type), and instantiate CIVIL_153. S4: The triggering condition is met by the data, but semantic contradiction detection reveals a potential deviation between the user's query semantics (inquiring about contract validity) and the conclusion of CIVIL_153. The system also discovers that the dependency relationship of CIVIL_153 includes REG_003 (Article 3 of the Regulations on the Administration of Commercial Franchises, mandatory norms concerning the validity of franchisor subject access), triggering association rule recall. REG_003 is recalled and added to the candidate rule set. S2 conflict resolution: The candidate set contains both CIVIL_153 and REG_003. The applicability score is calculated using legal scenario weighting: regulatory hierarchy weight (REG_003 is an administrative regulation = 0.8, CIVIL_153 is a law = 1.0), rule application accuracy (REG_003 directly addresses the qualifications of the franchisee, resulting in higher accuracy), etc. REG_003 scored 0.8925, while CIVIL_153 scored 0.7925, making REG_003 the winner. S3: REG_003 is re-instantiated; the data is now complete. S4: REG_003's applicability verification passes. S5: Causal tracing is performed starting from REG_003, generating an evidence chain that includes conflict resolution score details, rule version information, dependency propagation path, and an appended integrity hash and timestamp. The output conclusion is: "The individual business owner does not possess the qualifications of a franchisee; the contract is invalid."

[0136] Example 3: Example of causal tracing and chain of evidence. This example demonstrates the calculation process of causal tracing in detail, based on the above examples.

[0137] Starting with the winning rule R001 in Scenario A of Example 1, the initial cumulative strength is 1.0. The dependencies of R001 are obtained from the rule knowledge base: R001→R005 (edge ​​weight 0.8), R001→R012 (edge ​​weight 0.64), R005→R003 (edge ​​weight 0.65). A forward weighted breadth-first search is performed: R005 cumulative strength = 1.0 × 0.8 = 0.8; R012 cumulative strength = 1.0 × 0.64 = 0.64; R003 is reached via two paths—path R001→R005→R003 cumulative strength = 0.8 × 0.65 = 0.52, path R001→R012→R003 cumulative strength = 0.64 × 0.5 = 0.32, taking the maximum value of 0.52. The final impact domain includes R005 (0.8), R012 (0.64), and R003 (0.52). The judgment conclusion, rule tracing information (version number, structure hash), and causal tracing results (impact domain, cumulative strength, propagation path) are assembled into a structured evidence chain, with an additional integrity hash and timestamp.

[0138] Example 4: Lightweight deployment and version synchronization at the edge (offline operation)

[0139] This method system is deployed on an edge quality inspection terminal. When the device is connected to the network, an independent version synchronization mechanism runs automatically: ① It compares the structure hashes of the local and cloud-based rule knowledge bases, finds that rule Q001 and its dependent rule Q005 have new versions, and completes incremental rule synchronization; ② It detects that rule Q010 has been added to the rule identifier set, and downloads the updated classifier model to replace the local classifier. After synchronization is complete, a version change history containing rule changes and classifier update records is generated. The device then enters offline working mode.

[0140] In offline mode, the user inputs: "Detected a scratch on the workpiece surface with a length of 5mm, determine the level," and uploads an image. S1: The local classifier outputs rule identifier Q001 (synchronized to the latest version), with a confidence level of 0.95. S2: The system directly retrieves the latest version of rule Q001 from the local cache and records its version number V2.1 and structure hash. No internet connection is required throughout the process, and there is no response delay. S3: "Scratch length = 5mm" is extracted, and a multimodal model is called for visual detection backfilling. S4: The trigger condition is verified and passed. S5: Causal tracing is performed starting from Q001. When assembling the evidence chain, the system incorporates the version change history previously generated by the synchronization mechanism (update records for rules Q001 and Q005, and classifier model update records). The evidence chain is output after adding an integrity hash and timestamp. Conclusion: "Moderate defect."

[0141] Once the network is restored, the version synchronization mechanism restarts in the background, checks whether there are any changes to the rule structure hash and rule identifier set, and records the new change history for use by subsequent tasks.

[0142] Example 5: Generation of Financial Compliance Analysis Reports

[0143] A financial risk control department needs to regularly generate customer transaction compliance analysis reports. The rule "REPORT_001" is registered in the rule base, triggered by a "customer ID not empty" condition. Its execution logic is to generate compliance analysis reports, and the required data fields include: customer name, number of transactions in the past 30 days, number of large transactions (single transaction ≥ 500,000), whether there are cross-border transactions, and risk level.

[0144] S1: The system receives the query "Generate monthly compliance report for customer C001". The classifier outputs the rule identifier "REPORT_001" with a confidence level of 0.96, which is greater than the threshold. S2: Obtain the target rule and proceed directly to S3. S3: Extract the entity "Customer ID = C001". Based on the data acquisition instructions from Unit I, query the number of transactions in the past 30 days (156 transactions) from the core transaction system, the number of large transactions (12 transactions) and cross-border transaction markers (yes) from the risk control system, and the customer name (XX Trading Company) and risk level (medium risk) from the customer information system. Fill in the trigger condition template. S4: The trigger condition "Customer ID is not empty" is met, and the verification passes. S5: Perform causal tracing starting from REPORT_001, generate an evidence chain, and attach an integrity hash and timestamp. S6: Inject the original query text, the complete content of rule REPORT_001, and all backfilled business data into the large language model. The prompt template restricts LLM to be organized solely based on the input data, outputting a JSON-formatted report containing four parts: basic customer information, transaction overview, risk indicators, and compliance assessment. Introducing external knowledge or extending conclusions independently is prohibited. The LLM generates a structured report, which is then included in the chain of evidence and output.

[0145] Experimental results

[0146] On the STARD public legal consultation dataset, the classifier achieved a Top-1 accuracy of 98.0% with a latency of only 10ms; the accuracy of traditional retrieval enhancement-generated semantic retrieval was only 52.0%. After introducing Reranker for re-ranking, the accuracy dropped to 49.5%. This counterintuitive phenomenon shows that semantic similarity does not equal logical relevance, and this characteristic is further strengthened after re-ranking, proving that the retrieval enhancement semantic matching paradigm fails at the architectural level in strong rule scenarios.

Claims

1. A rule-based native trusted retrieval enhancement generation method, characterized in that, The method includes the following steps: S1. First Retrieval Stage: Receive user natural language queries, output target rule identifiers and confidence scores through a classifier, and replace vector retrieval based on semantic similarity with a deterministic classification retrieval mode; the classifier is based on a pre-trained language model, fine-tuned on a sample set consisting of query text and rule identifier pairings, and outputs a probability distribution on a preset set of rule identifiers, taking the rule identifier corresponding to the highest probability as the target rule identifier; wherein, in offline deployment at the edge or in a weak network environment, a locally deployed classifier model and cached rules are used, and the local classifier is updated synchronously by an independent version synchronization mechanism when the set of rule identifiers changes; S2. Target Rule Acquisition: The system retrieves the target rule from the rule knowledge base based on the rule identifier and records the rule's version identifier and structure hash. In a centralized cloud deployment, the system accesses the central rule knowledge base in real time to directly acquire the target rule, its version identifier, structure hash, and version change history. In an offline edge deployment or weak network environment, the system retrieves the target rule from the local cache. The local cache and local classifier are maintained by an independent version synchronization mechanism. This mechanism compares the rule structure hashes of the local and central ends when the device is online to trigger incremental rule synchronization and detects changes in the rule identifier set to trigger classifier model updates. After synchronization, the version change history is updated to the rule metadata in the local cache. S3, Second Retrieval Stage: Extract business entities from user queries using a lightweight generative model, fill the extracted entity values ​​into the trigger condition template of the current processing rule to complete rule instantiation, and retrieve supplementary data from the business data source according to the data retrieval instructions preset in the rule; S4. Applicability Verification and Error Correction Recall: Verify whether the triggering conditions of the instantiated rule are satisfied by the acquired data and whether there are semantic contradictions. The data required for each condition expression in the triggering condition comes from text extraction, business data query, or multimodal perception channels. The structured numerical values ​​returned by the multimodal model directly participate in the Boolean judgment of the triggering condition, and its internal confidence is only used as metadata records and does not participate in the decision. The semantic contradiction is determined by comparing the similarity of the fused semantics between the user query and the rule's standard question text in the Q unit and the conclusion text in the R unit. The multimodal structured numerical values ​​do not participate in semantic contradiction detection. If the verification fails, the association rule recall is triggered. The recalled candidate rules form a candidate rule set, and the winning rule is selected through applicability scoring. The winning rule is returned to S3 for re-instantiation. The maximum number of recalls is configurable. S5. Causal Tracing and Evidence Chain Generation: Combine rules to generate a judgment conclusion. The rules are either the rules that passed the applicability verification in S4 or the original rules that failed verification due to exceeding the configuration limit in S4 recall count. Starting from the rules, perform a forward weighted breadth-first search along the dependency directed graph between rules, and output the set of rules in the influence domain, the cumulative influence strength, and the propagation path. Assemble the judgment conclusion, rule source information, and causal tracing results into a structured evidence chain and output it. Add an integrity hash and a timestamp to the records of each link in the evidence chain, and include the version change history of the rules involved in this judgment in the evidence chain. S6. Inject the winning rule content and its associated rules, the original query text, and supplementary data into the large language model, and generate a reliable result by combining the prompt word template. The prompt word template limits the large language model to output only based on the provided rule content and structured data. The method uses a rule knowledge base as the native management object, and each rule has an independent version identifier, structural hash, and dependency graph. The classifier uses deterministic classification to replace vector semantic retrieval as the first hop for rule matching, making entry point determination an intrinsic capability of the system. When the classifier hits a rule identifier, the system uses that rule identifier as an anchor point to enter the subsequent process. Its operation is supported by the structured version management, dependency graph, and causal tracing capabilities of the rule knowledge base throughout. The rule trigger condition template further supports explicit labeling of multimodal perception conditions. The rule engine schedules the multimodal model and uses the perception results as structured evidence for backfilling. The output of the multimodal model is only structured numerical values ​​and does not contain judgment conclusions.

2. The method according to claim 1, characterized in that, The applicability score described in S4 is calculated based on a weighted sum of at least two of the following dimensions: regulatory rank weight, rule recentity, rule applicability accuracy, historical adoption rate, and rule granularity matching degree; the weights of each dimension are customized according to the application scenario or obtained through dynamic optimization.

3. The method according to claim 1, characterized in that, The entity extraction scope of the lightweight generative model described in S3 is strictly constrained within the preset entity field set by the trigger condition template of the current processing rule; the large language model described in S6 is independent of the lightweight generative model described in S3 and can be selected separately according to the scenario.

4. The method according to claim 1, characterized in that, Semantic contradiction detection in S4 is determined by comparing the similarity between the user-input natural language query text and the fused semantics of the rule's standard question text in Q unit and the conclusion text in R unit. The fused semantics of the user-input natural language query text and the rule's standard question text in Q unit and the conclusion text in R unit are encoded into vectors respectively, and the cosine similarity is calculated. When the similarity is lower than the preset contradiction threshold, it is judged as a semantic contradiction and is considered as a verification failure.

5. The method according to claim 1, characterized in that, The association rule recall in S4 is performed by traversing the directed graph of dependencies between rules. When the number of recalls exceeds the configured limit and the applicability verification still fails, S5 outputs "Unable to determine" and a structured chain of evidence.

6. The method according to claim 1, characterized in that, The forward weighted breadth-first search in S5 specifically involves multiplying the cumulative influence strength of the current node by the edge weight and propagating it to downstream nodes. When multiple paths reach the same node, the maximum cumulative strength is taken. The propagation termination conditions include the cumulative strength being lower than a preset propagation threshold, the propagation depth exceeding a preset maximum depth, or the total number of traceable nodes exceeding a preset upper limit. The influence strength mentioned in S5 is based on a preset default value according to the dependency type, or obtained from statistical analysis of historical inference logs.

7. The method according to claim 1, characterized in that, The structure hash is calculated by parsing the triggering conditions and execution logic of the rule into an abstract syntax tree, and then normalizing it. The independent version synchronization mechanism determines whether the rule has undergone substantial changes by comparing the current structure hash corresponding to the same rule identifier in the local cache and the rule knowledge base. If so, incremental synchronization of the rule and its dependency graph is triggered, and the version change history is recorded.

8. The method according to claim 1, characterized in that, The trigger condition template of the rule described in S3 supports explicit labeling of one or more multimodal perception conditions. The multimodal perception conditions include modality type, perception task type, calling model identifier, expected output field, and timeout parameter. When the trigger condition includes a multimodal perception condition, the rule engine directly schedules the corresponding multimodal model to execute the perception task through standardized instructions according to the pre-set calling instructions in the rule. The standardized instructions include task type, input data reference, expected output field, and timeout parameter. The output of the multimodal model is only a structured numerical value and does not contain any form of judgment conclusion. This structured numerical value is backfilled into the corresponding field of the trigger condition template of the rule. The multimodal model and the entity extraction model of S3 are independent of each other and are decoupled through standardized instructions.

9. A rule-based native trusted retrieval enhancement generation system, characterized in that, include: Classification module: Configured to receive user natural language queries and output rule identifiers and confidence scores; Conflict resolution module: Configured to select the winning rule from the candidate rule set based on the applicability score when the applicability verification fails and an error correction recall is triggered. Instantiation module: configured to extract business entities from user queries to instantiate the current processing rule, and obtain supplementary data from the business data source according to the data acquisition instruction; the instantiation module is further configured to schedule the multimodal model and backfill the perception result through standardized instructions when the trigger condition template of the rule contains multimodal perception conditions, and the standardized instructions include task type, input data reference, expected output field and timeout parameter; Verification and Recall Module: Configured to verify whether the triggering conditions of the instantiated rules are met and whether semantic contradictions exist; the data required for each conditional expression in the triggering conditions comes from three channels: text extraction, business data query, and multimodal perception. The structured numerical values ​​returned by the multimodal model directly participate in the Boolean judgment of the triggering conditions, and their internal confidence is only used as metadata records and does not participate in the decision; semantic contradiction detection only compares the similarity of the user query text with the fused semantics of the standard question text of the rule in the Q unit and the conclusion text in the R unit. The multimodal structured numerical values ​​do not participate in semantic contradiction detection; when verification fails or the confidence is lower than the preset threshold, the associated rules are recalled and the conflict resolution module is triggered for processing; Causal tracing module: Configured to perform a forward weighted breadth-first search along the directed graph of dependencies between rules, starting from the winning rule, outputting the set of rules in the influence domain, the cumulative influence strength and the propagation path, and assembling the judgment conclusion, causal tracing results and rule source information into a structured evidence chain output; add integrity hashes and timestamps to the records of each link in the evidence chain.

10. A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method according to any one of claims 1 to 8.

Images