Information query method based on large model and electronic device

Abstract

The application provides a large model-based information query method and electronic equipment, and relates to the technical field of data processing. The method comprises the following steps: determining a target intention of a user according to a target query request initiated by the user; when the target intention is a pre-guidance type, taking target business parameters determined based on the target query request as first query information, and obtaining target decision-making rules matched with the first query information from a preset decision-making rule library; when the target intention is a post-tracing type, obtaining upstream and downstream information associated with the target query request from a preset knowledge base as second query information, and obtaining target decision-making rules matched with the second query information from the decision-making rule library; inputting the first / second query information and the corresponding target decision-making rules into a preset large model, and pushing a generated target reply result to the user; and testing and updating the decision-making rules by using test cases generated by the large model. The method improves the efficiency of data query.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, specifically to the field of large model and intelligent agent technology, and particularly to an information query method and electronic device based on a large model. Background Technology

[0002] As enterprises advance their digital transformation, core business operations such as expense reimbursement, purchase requests, contract approvals, and project initiation have all become online and streamlined. These processes are typically handled and executed by workflow engines or BPM (Business Process Management) systems to ensure that business flows according to pre-defined rules. In enterprise operations, these approval processes strictly rely on internal approval rules. These rules, based on multiple dimensions such as business type, amount, department, and importance of the matter, define the decision-making authority and approval path for each transaction. When employees or managers have questions about the approval process, they need to manually query process records across systems, search for rule documents, and perform analysis and comparison to understand the compliance of the process. Summary of the Invention

[0003] This invention proposes an information query method and electronic device based on a large model, which improves the efficiency of data query.

[0004] In a first aspect, embodiments of the present invention propose an information query method based on a large model, comprising: Step 1: determining the user's target intent based on the target query request initiated by the user; Step 2-1: when the target intent is pre-guidance type, using the target business parameters determined based on the target query request as the first query information, and obtaining the target decision rule matching the first query information from a preset decision rule base; Step 2-2: when the target intent is post-retrospection type, obtaining the upstream and downstream information associated with the target query request as the second query information from a preset knowledge base, and obtaining the target decision rule matching the second query information from the decision rule base; Step 3: inputting the first query information / second query information and the corresponding target decision rule into a preset large model. The model is used to push the target response result to the user. The target response result is the result of the big model's rationality analysis of the input data. Each core decision rule in the core decision rule base can be updated through the following steps: the target query request, target intent, first query information / second query information, target core decision rule, and user feedback on the target response result are encapsulated into question-answer pairs and stored in the historical query database; based on the question-answer pairs in the historical query database and the preset test rules, the big model is used to generate test cases covering all core decision rules in the core decision rule base. The preset test rules include test case construction rules and conflict resolution guidance rules. The test case construction rules are used to guide the construction of test cases including boundary value test cases, semantic variant test cases, and conflict test cases. The test cases include various types such as verification test cases. Boundary value test cases are used to test the critical values ​​of various numerical adjustments in the decision rules. Semantic variant test cases utilize the large model to test whether the decision rule base can correctly match and output the same decision conclusion at the semantic level by pre-constructing or automatically generating diverse questions under the same decision rule meaning. Conflict verification test cases are used to test at least two logically overlapping decision rules. When a conflict verification test case detects a rule conflict between at least two decision rules, it drives the large model to generate a conflict resolution solution based on the conflict resolution guidelines. The conflict resolution solution includes at least one of the following: adjusting the priority between conflicting rules, merging conflicting rules, and adding mutual exclusion constraints to conflicting rules. Adjusting the priority between conflicting rules includes: tracing each conflict. The rules are applied in the historical query database. Feature factors corresponding to each conflicting rule are extracted. These features include at least one of the following: the scale of the historical application event, the original and current job titles of the rule-maker, the representativeness of the applicable event, and its randomness. A large model is used to weight and score these feature factors to determine the theoretical priority of each conflicting rule, and the order of application of these rules is determined according to their theoretical priority. The ranking results and reasoning basis of the theoretical priorities are pushed to the administrator of the decision-making rule base. After receiving confirmation, the confirmed priorities are fixed in the attribute fields of the corresponding decision-making rules in the decision-making rule base. Test cases are used to test the decision-making rules in the decision-making rule base, generating a self-inspection report for each decision-making rule.Based on the self-inspection report, rule update suggestions are generated, and the decision rules in the decision rule base are updated according to these suggestions.

[0005] Secondly, embodiments of the present invention propose an information query device based on a large model, comprising: an intent determination unit configured to: determine the user's target intent based on a target query request initiated by the user, wherein the target intent includes pre-guidance type and post-retrospection type; a first rule determination unit configured to: when the target intent is pre-guidance type, use the target business parameters determined based on the target query request as the first query information, and obtain the target decision rule matching the first query information from the decision rule base; and a second rule determination unit configured to: when the target intent is post-retrospection type, obtain the upstream and downstream information associated with the target query request from a preset knowledge base as the second query information. The system retrieves the first / second query information and the corresponding target decision rule from the decision rule base, and obtains the target decision rule that matches the second query information from the decision rule base. The result generation unit is configured to: input the first / second query information and the corresponding target decision rule into a preset large model, and send the output target response result to the user, wherein the target response result is the large model's rationality analysis result of the input data; the rule update unit is configured to update each decision rule contained in the decision rule base through the following steps: encapsulate the target query request, target intent, first / second query information, target decision rule, and user feedback on the target response result into a question-and-answer pair, and store it in the historical query database; based on the question-and-answer pair in the historical query database and the preset test... The rules utilize a large model to generate test cases covering all core decision rules in the core decision rule base. Preset test rules include test case construction rules and conflict resolution guidance rules. Test case construction rules guide the construction of various types of test cases, including boundary value test cases, semantic variant test cases, and conflict verification test cases. Boundary value test cases test the critical values ​​of various numerical adjustments in the core decision rules. Semantic variant test cases utilize the large model to pre-construct or automatically generate diverse questions under the same core decision rule meaning to test whether the core decision rule base can correctly match and output the same core decision conclusion at the semantic level. Conflict verification test cases test at least two logically overlapping core decision rules. When a conflict verification test case detects at least two core decision rules... When rule conflicts exist, the conflict resolution guideline drives the large model to generate conflict resolution solutions. These solutions include at least one of the following: adjusting the priority of conflicting rules, merging conflicting rules, or adding mutual exclusion constraints to conflicting rules. Adjusting the priority of conflicting rules includes: tracing the historical application events of each conflicting rule in the historical query database, extracting the characteristic factors corresponding to each conflicting rule, and the characteristic factors include at least one of the following: the scale of the historical application event, the original and current job level of the rule maker, whether the applicable event is representative, and its randomness. The large model then performs a weighted scoring on the characteristic factors to determine the theoretical priority of each conflicting rule and determines the order of application of each conflicting rule according to its theoretical priority.The theoretical priority ranking results and reasoning basis are pushed to the administrator of the decision rule base. After receiving confirmation feedback, the confirmed priorities are fixed in the attribute fields of the corresponding decision rules in the decision rule base. Test cases are used to test the decision rules in the decision rule base, and a self-inspection report is generated for each decision rule. Rule update suggestions are generated based on the self-inspection reports, and the decision rules in the decision rule base are updated based on the rule update suggestions.

[0006] Thirdly, embodiments of the present invention provide an electronic device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to implement the large-model-based information query method as described in the first aspect.

[0007] Fourthly, embodiments of the present invention provide a non-transitory computer-readable storage medium storing computer instructions that enable a computer to implement the large-model-based information query method as described in the first aspect when executed.

[0008] Fifthly, embodiments of the present invention provide a computer program product including a computer program, which, when executed by a processor, can implement the steps of the information query method based on a large model as described in the first aspect.

[0009] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0010] Other features, objects, and advantages of the invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 This is an exemplary system architecture in which the present invention can be applied; Figure 2 A flowchart illustrating an information query method based on a large model provided in an embodiment of the present invention; Figure 3 A flowchart illustrating a method for obtaining target decision rules that match first query information, provided by an embodiment of the present invention; Figure 4 A flowchart illustrating a method for obtaining target decision rules that match second query information, provided in an embodiment of the present invention; Figure 5 A flowchart illustrating a method for generating target response results based on a large model, provided in an embodiment of the present invention; Figure 6 A flowchart illustrating an information query method based on a large model in an application scenario provided by an embodiment of the present invention; Figure 7 A structural block diagram of an information query device based on a large model provided in an embodiment of the present invention; Figure 8 This is a schematic diagram of the structure of an electronic device suitable for executing a large model-based information query method, provided as an embodiment of the present invention. Detailed Implementation

[0011] The following description, in conjunction with the accompanying drawings, illustrates exemplary embodiments of the present invention, including various details to aid understanding. These details should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the invention. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description. It should be noted that, unless otherwise specified, the embodiments and features described in the present invention can be combined with each other.

[0012] The collection, storage, use, processing, transmission, provision, and disclosure of user personal information involved in the technical solution of this invention all comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0013] Figure 1 An exemplary system architecture 100 is shown, in which embodiments of the large-model-based information retrieval method, apparatus, electronic device, and computer-readable storage medium of the present invention can be applied.

[0014] like Figure 1 As shown, system architecture 100 may include terminal devices 101, 102, and 103, a network 104, and a server 105. Network 104 serves as the medium for providing communication links between terminal devices 101, 102, and 103 and server 105. Network 104 may include various connection types, such as wired or wireless communication links, or fiber optic cables, etc.

[0015] Users can use terminal devices 101, 102, and 103 to interact with server 105 via network 104 to receive or send messages, etc. Various applications for enabling information communication between the terminal devices 101, 102, and 103 and server 105 can be installed. These applications include information query applications, web browser applications, and instant messaging applications.

[0016] Terminal devices 101, 102, and 103 and server 105 can be either hardware or software. When terminal devices 101, 102, and 103 are hardware, they can be various electronic devices with displays, including but not limited to smartphones, tablets, laptops, and desktop computers. When terminal devices 101, 102, and 103 are software, they can be installed in the aforementioned electronic devices, and can be implemented as multiple software programs or software modules, or as a single software program or software module; no specific limitation is made here. When server 105 is hardware, it can be implemented as a distributed server cluster composed of multiple servers, or as a single server. When server 105 is software, it can be implemented as multiple software programs or software modules, or as a single software program or software module; no specific limitation is made here.

[0017] Server 105 can provide various services through its built-in applications. Taking an information query application that generates target response results based on a target query request as an example, when running this application, Server 105 can achieve the following: First, it determines the user's target intent based on the user's target query request. Target intent includes pre-emptive guidance and post-event tracking. When the target intent is pre-emptive guidance, the target business parameters determined based on the target query request are used as the first query information, and target decision rules matching the first query information are obtained from the decision rule base. When the target intent is post-event tracking, upstream and downstream information associated with the target query request is obtained from a preset knowledge base as the second... The system queries the first / second query information and retrieves the target decision rules matching the second query information from the decision rule base. Finally, it inputs the first / second query information and the corresponding target decision rules into a pre-defined large model to generate a target response result, which is then pushed to the user. The target response result represents the large model's analysis of the input data's rationality. Each decision rule in the decision rule base can be updated through the following steps: encapsulate the target query request, target intent, first / second query information, target decision rules, and user feedback on the target response result into a question-and-answer pair and store it in the historical query database; based on the question-and-answer pairs in the historical query database and the pre-defined test rules, it uses the large model to generate... This system generates test cases covering all core decision rules in the core decision rule base. The pre-defined test rules include test case construction rules and conflict resolution guidance rules. Test case construction rules guide the construction of various types of test cases, including boundary value test cases, semantic variant test cases, and conflict verification test cases. Boundary value test cases test the critical values ​​of various numerical adjustments in the core decision rules. Semantic variant test cases utilize a large model to test whether the core decision rule base can correctly match and output the same core decision conclusion at the semantic level by pre-constructing or automatically generating diverse questions under the same meaning of the core decision rule. Conflict verification test cases test at least two logically overlapping core decision rules. When a conflict verification test case detects at least two core decision rules, the system will resolve the conflict. When rules conflict, the large model generates conflict resolution solutions based on the conflict resolution guidelines. These solutions include at least one of the following: adjusting the priority of conflicting rules, merging conflicting rules, or adding mutual exclusion constraints to conflicting rules. Adjusting the priority of conflicting rules involves: tracing the historical application events of each conflicting rule in the historical query database, extracting the characteristic factors corresponding to each conflicting rule, and including at least one of the following: the scale of the historical application event, the original and current job level of the rule maker, whether the applicable event is representative, and its randomness. The large model then assigns a weighted score to the characteristic factors to determine the theoretical priority of each conflicting rule and determines the order of application of each conflicting rule according to its theoretical priority.The theoretical priority ranking results and reasoning basis are pushed to the administrator of the decision rule base. After receiving confirmation feedback, the confirmed priorities are fixed in the attribute fields of the corresponding decision rules in the decision rule base. Test cases are used to test the decision rules in the decision rule base, and a self-inspection report is generated for each decision rule. Rule update suggestions are generated based on the self-inspection reports, and the decision rules in the decision rule base are updated based on the rule update suggestions.

[0018] It should be noted that, in addition to being obtained from terminal devices 101, 102, and 103 via network 104, target query requests can also be pre-stored locally on server 105 through various means. Therefore, when server 105 detects that this data is already stored locally (e.g., when starting to process a previously retained target response result generation task), it can choose to retrieve this data directly from locally. In this case, the exemplary system architecture 100 may also exclude terminal devices 101, 102, and 103 and network 104.

[0019] Since generating a target response result based on a target query request requires significant computing resources and strong computing power, the information query method based on a large model provided in the subsequent embodiments of this invention is generally executed by a server 105 with strong computing power and abundant computing resources. Correspondingly, the information query device based on the large model is also generally located in the server 105. However, it should also be noted that when terminal devices 101, 102, and 103 also possess sufficient computing power and resources, they can also complete the aforementioned calculations performed by the server 105 through their installed information query applications, thereby outputting the same results as the server 105. Especially when multiple terminal devices with different computing capabilities exist simultaneously, but the information query application determines that its terminal device has strong computing power and abundant remaining computing resources, it can allow the terminal device to perform the aforementioned calculations, thereby appropriately reducing the computing pressure on the server 105. Accordingly, the information query device based on the large model can also be located in terminal devices 101, 102, and 103. In this case, the exemplary system architecture 100 may also exclude the server 105 and the network 104.

[0020] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0021] Please refer to Figure 2 , Figure 2 A flowchart of an information query method based on a large model provided in an embodiment of the present invention, wherein process 200 includes the following steps: Step 201: Determine the user's target intent based on the target query request initiated by the user; This step is intended to be performed by the implementing entity (e.g.) Figure 1 The server 105 shown receives the target query request initiated by the user and determines the user's target intent based on the target query request. The target query request is the original question text entered by the user in natural language, which may be initiated through various front-end channels, such as internal instant messaging tools, web portals, mobile office applications, or dedicated approval system clients. Examples include "I want to apply for a marketing conference with a budget of approximately 20,000 yuan, what approvals are required?" or "Please explain why document number xxxx was returned by finance." Target query requests are typically characterized by colloquial language, fragmented information, and implicit business context. Target intent includes pre-emptive guidance and post-event traceability. Determining the target intent essentially involves semantically abstracting and categorizing the user's query needs so that the executing entity can invoke the corresponding processing logic and data source for different categories of needs. The core of intent recognition lies in establishing a mapping relationship between user input text and predefined intent categories. This can be achieved through pre-trained language models based on the Transformer architecture (such as BERT, RoBERTa, or domain-fine-tuned large language models). By utilizing the model's full-sentence semantic understanding capabilities, user input is encoded into a high-dimensional semantic vector. Then, a classification layer is used to calculate the probability distribution of the vector belonging to each intent category. Finally, the category with the highest probability is output as the recognition result.

[0022] In this embodiment, the executing entity determines the user's target intent based on the target query request initiated by the user. Specifically, firstly, the executing entity can obtain the target query request initiated by the user and preprocess it, including text cleaning, word segmentation, and stop word removal. Then, the preprocessed target query request is input into the large model, and the probability values ​​of the target query request belonging to the pre-guidance category and the post-tracing category are calculated respectively. Finally, the intent category with the higher probability value is determined as the user's target intent, and when the intent category with the higher probability value is lower than the preset confidence threshold, an intent clarification request is sent to the user, thereby ensuring the accuracy and efficiency of subsequent model processing.

[0023] In this embodiment, the purpose of preprocessing the target query request is to remove noise information irrelevant to semantic expression in the text, such as special symbols that may be carried by the user during input, extra blank characters, Emoji expressions, or format tags brought in when copying text from other applications. The cleaned text is then subjected to word segmentation. Word segmentation is the process of cutting a continuous character sequence into words, which are the minimal units with independent semantics. Since there are no natural separators between words, word segmentation is a key pre-step for understanding text semantics, and its segmentation granularity directly affects the quality of the subsequent model's understanding of semantics. For example, "why is the reimbursement form returned" may be segmented into "reimbursement form / why / be / returned", and each word carries specific semantic information. After word segmentation, it is usually necessary to perform a stop word removal operation. Stop words refer to those words that appear frequently in the text but contribute little to expressing the core semantics, such as auxiliary words, prepositions and conjunctions like "de", "le", "zai", "shi" in Chinese. Removing these words can effectively reduce the dimension of the input text, reduce noise interference, and enable the model to focus more on the core words that carry key information.

[0024] In this embodiment, after the preprocessed target query request is converted into an input format acceptable by the model, it will be input into a large language model for intent recognition. Large language models act as classifiers in the intent recognition task, these large models are usually based on the Transformer architecture. After pre-training on massive general corpora, they already have powerful semantic understanding and representation capabilities. When processing input text, the model maps each word or subword in the text to a semantic vector in a high-dimensional space, captures the contextual dependencies between words through a multi-layer attention mechanism, and finally encodes the entire text sequence into a vector representation that can represent its overall semantics. This semantic vector is then fed into the output layer of the model, which is usually composed of a fully connected neural network and a Softmax activation function. Its function is to map the high-dimensional semantic vector to the same dimension as the number of predefined intent categories, and convert the values on these dimensions into a probability distribution through the Softmax function. For example, the model will separately calculate the probability values that the current input belongs to the pre-event guidance category and the post-event traceability category, and the sum of these two probability values is 1. For the user input "I want to apply for a 50,000-yuan marketing event, what process do I need to go through", the model may output that the probability of the pre-event guidance category is 0.95, and the probability of the post-event traceability category is 0.05, indicating that the model is highly confident that what the user needs is pre-event guidance service. This probability-based output method not only gives the result of intent determination, but also quantifies the model's confidence in this determination result.

[0025] In this embodiment, after obtaining the probability values, the executing entity determines the intent category with the highest probability value as the user's target intent. However, relying solely on the highest probability for a hard judgment may be risky in some situations. For example, when the user input is too vague or ambiguous, the highest probability output by the model may not be significantly higher than other categories. Therefore, a confidence threshold mechanism can be introduced. Before determining the target intent, it is first determined whether the probability corresponding to the intent category with the high probability value is lower than a preset confidence threshold. The confidence threshold is a pre-set value, such as 0.7 or 0.8, used to measure the model's confidence in its judgment result. When the highest probability is lower than this threshold, it means that the model is not confident enough in the current intent recognition result. If this result is forcibly adopted, it may cause the subsequent processing flow to deviate from the user's actual needs, thereby affecting the user experience and the accuracy of the query results. In this case, the executing entity will proactively send an intent clarification request to the user, for example, prompting in a dialogue format, "Do you want to understand the approval standards of a certain business or do you want to query the approval status of a specific document?", guiding the user to further clarify their query intent. Through this interactive clarification mechanism, the implementing entity can obtain a clearer intent from the user's secondary feedback, thereby effectively avoiding subsequent processing deviations caused by misjudgment of intent. This design reflects the system's robustness in handling uncertainty, compensating for the limitations of a single model's judgment through human-machine collaboration, and significantly improving the accuracy of intent recognition and the user-friendliness of the experience. In actual deployment, the specific presentation form and interaction logic of the intent clarification request can be flexibly designed according to the application scenario. For example, it can be displayed as a pop-up window, voice prompt, or clickable option buttons in rich text format in the chat interface, allowing users to quickly select and confirm.

[0026] In this embodiment, pre-initiative guidance intent refers to a user's query scenario where, before initiating a business activity, they wish to understand the approval rules and procedures required for that activity. Essentially, this involves future rule simulation and prediction, such as querying approval standards or business processes. Post-initiative traceability intent, on the other hand, refers to a user's scenario where they query and verify the approval process and compliance reasons for business documents that have already occurred and are recorded in the system. Essentially, this involves tracing past facts and interpreting compliance, such as querying approval progress, verifying the compliance of countersigning records, and auditing process compliance. This division of intents forms the basis for the flow of the entire query processing workflow. Only by accurately identifying user intents can the subsequent data acquisition and rule matching steps be targeted and effective. To further improve the accuracy of intent identification, a confidence threshold mechanism can be introduced in actual deployment. When the highest probability intent output by the model is lower than a preset threshold, the executing entity can proactively send an intent clarification request to the user, such as, "Do you want to understand the approval standards for a certain business activity, or do you want to query the approval status of a specific document?" This allows for secondary confirmation through user feedback, thereby avoiding response deviations caused by misjudgment of intent. This interactive clarification mechanism not only improves the system's robustness but also enhances the user experience. Furthermore, the definition of intent categories is not static; the intent system can be expanded based on business characteristics and management needs. For example, subcategories can be added for specific business types (such as procurement, expense reimbursement, and contracts), or the post-event traceability category can be further differentiated into subcategories such as approval progress queries and compliance reason queries, making the query service more accurate and tailored to actual application scenarios.

[0027] Step 202: When the target intent is a pre-guidance type, the target business parameters determined based on the target query request are used as the first query information, and the target decision rules that match the first query information are obtained from the preset decision rule base; In this embodiment, when the target intent is pre-guidance type, the executing entity uses the target business parameters determined based on the target query request as the first query information, and obtains the target approval rules matching the first query information from the approval rule base. The target business parameters typically include business type, estimated amount, initiating department, matter level, and involved region. For example, if a user inputs "I want to apply for an academic conference for grassroots doctors, with a budget of approximately 30,000 yuan, which leaders need to approve it," the system can extract target business parameters such as the business type "academic conference," the estimated amount "30,000 yuan," and possible initiating department information. This extraction process can be achieved using a large model combined with named entity recognition technology. The large model, while understanding the natural language semantics of the user input, can identify and extract preset entity categories. To improve the accuracy of extraction, the model can be fine-tuned during the model training phase using historical query corpora labeled with business parameters, enabling the model to accurately understand the numerical meanings behind different expressions such as "30,000 yuan," "around 50,000 yuan," and "budget approximately 20,000 yuan," as well as the business types corresponding to words such as "conference," "procurement," and "reimbursement." The extracted target business parameters will be organized into structured first query information, which will serve as input conditions for subsequent rule-based retrieval.

[0028] After obtaining the initial query information, the executing entity needs to retrieve the target approval rule matching the initial query information from the approval rule base. The approval rule base is a pre-built structured knowledge base that stores all effective approval rule entries. Each approval rule typically contains multiple dimensions, such as applicable business type, applicable department, amount threshold range, approval node sequence, and countersigning requirements. Each rule is associated with a specific business scenario and also includes a result dimension, describing the approval path or compliance requirements that should be executed in that scenario. The approval rule base can be constructed by parsing and structuring raw, unstructured rule documents. For example, approval standards originally maintained by an enterprise in Excel spreadsheets or PDF documents can be parsed by automated scripts, extracting each rule into a structured data record and importing it into a database or vector database for efficient subsequent retrieval.

[0029] Step 203: When the target intent is a retrospective type, retrieve the upstream and downstream information associated with the target query request from the preset knowledge base as the second query information, and retrieve the target decision rule that matches the second query information from the decision rule base; In this embodiment, when the target intent is post-event traceability, the executing entity retrieves upstream and downstream information associated with the target query request from a preset knowledge base as the second query information, and retrieves the target decision rule matching the second query information from the decision rule base. The preset knowledge base is a pre-built and continuously synchronized data set that integrates core information from multiple heterogeneous data sources related to the business process. Examples include approval form data and approval flow records stored in the process center, basic personnel information, organizational structure, and reporting relationships stored in the user center, and relevant data from other business systems that may be involved. These data were originally scattered across different independent systems, lacking automated connection channels. The preset knowledge base, through periodic data synchronization or real-time interface calls, aggregates and associates this data according to the core dimension of business documents, forming a unified data view oriented towards the business process.

[0030] In this embodiment, upstream and downstream information refers to the collective term for various types of data that have a sequential or subordinate relationship with key information (such as document number, project number, etc.) contained in the target query request within the business process. For example, tracing upstream, one can obtain form data such as the initiator information, initiating department, form filling time, business type, application amount, and expense details of the document; tracing downstream, one can obtain the complete approval flow record of the document, including the approver, approval time, approval opinion, node status (approved, rejected, transferred, etc.) of each approval node, as well as relevant attachment information involved in the approval process; horizontally expanding, one can also obtain organizational structure information related to the initiator of the document, such as its reporting superior and the head of its department. This information together constitutes a complete factual description of the document, which will be integrated into structured second query information as the factual basis for subsequent rule matching and compliance judgment. To ensure the timeliness and accuracy of the information obtained, the preset knowledge base and the source system can adopt an incremental synchronization or real-time query mechanism. For example, for documents that are in circulation, the approval records may be updated at any time, and the system needs to be able to obtain the latest approval status to ensure the timeliness of the query results.

[0031] In this embodiment, when the executing entity uses the second query information as input for rule matching, the matching process typically uses the core features of the business documents contained in the second query information as retrieval conditions. Specifically, the system extracts key business parameters such as business type, initiating department, actual amount, and event attributes from the second query information, and uses these parameters as conditions to recall rules applicable to the second query information from the decision rule base.

[0032] Step 204: Input the first query information / second query information and the corresponding target decision rules into the preset large model, and push the output target response results to the user; In this embodiment, the executing entity inputs the first / second query information and the corresponding target decision rules into a pre-set large-scale model, generates the target response result, and pushes it to the user. The pre-set large-scale model is a large-scale pre-trained language model based on the Transformer architecture, such as the GPT series, Wenxin Yiyan, Tongyi Qianwen, or DeepSeek. These models, through self-supervised pre-training on massive general-purpose corpora, already possess powerful language understanding, knowledge association, and text generation capabilities. In this embodiment, the model does not directly answer the user's original question but acts as an intelligent information integrator and reasoning generator. Its input is a processed set of structured information, and its output is a natural language representation of this information. Specifically, the input to the large model typically includes two main parts: one part is query information, namely the first query information in the pre-guidance category (such as target business parameters like business type, estimated amount, and initiating department) or the second query information in the post-tracing category (such as upstream and downstream information like approval form data, approval process records, and organizational structure relationships). This part constitutes the factual basis that users are concerned with. The other part is the corresponding target decision-making rules, namely one or more rule clauses matched from the decision-making rule base that are applicable to the current query scenario. This part provides authoritative evidence for judgment and interpretation. These two parts together constitute the contextual material required for the large model to generate a response.

[0033] In this embodiment, inputting the first / second query information and the target decision-making rules into the large model is not a simple data concatenation, but requires careful organization and formatting to guide the model in generating an expected response. This is typically achieved through cue word engineering, which involves designing a structured cue word template and filling the input information into designated locations within the template to form a complete cue text containing instructions and context. For example, the cue word template might include the following elements: first, a role-setting instruction requiring the model to act as a "corporate process compliance consultant" or "intelligent approval assistant"; second, a task description clearly informing the model that it needs to generate a clear and accurate explanation or guidance based on the provided information; third, the information body, presenting the query information and decision-making rules in a structured manner, such as listing key nodes of the approval record in a list or line breaks, or presenting the original rule text using citations; and finally, output format requirements, such as requiring the model to organize its response according to the logical structure of "fact overview - rule basis - conclusion and recommendation," or requiring the model to specify the rule number when citing rules. Through this carefully designed cue word, the model's generation behavior can be effectively constrained, guiding it to focus on key information and follow a logical order, thereby generating a high-quality target response.

[0034] In this embodiment, the executing entity pushes the target response result to the user. Specifically, the push operation needs to have channel adaptation capabilities, that is, it should be able to return the result in the format and protocol supported by the channel used when the user initiated the query. The target response result is the result of the big model's rationality analysis of the input data. For example, if the user initiates a query through WeChat Work, the system needs to push the response result to the user in the form of a text message or rich text card through WeChat Work's robot interface or application message interface; if the user submits a query through a web page, the system needs to return the result to the front end through an HTTP response, and the front-end JavaScript script will render the result on the page; if the user submits a query through email, the system may need to organize the result into an email body and send it through an email gateway. Regardless of the channel, the core of the push is to accurately and completely deliver the text content generated by the big model to the user.

[0035] In this example, pushing the target response result to the user is often not a simple text send. It requires combining the functionality of the result display layer to format and enhance the response content before pushing it. The raw response result generated by the large model is usually a continuous piece of natural language text. However, to improve user experience and readability, the executing entity can perform post-processing on the response text before pushing it. For example, key data fields in the response can be highlighted, such as using bold or different colors to highlight monetary amounts, approver names, and rule numbers, allowing users to quickly locate core information. Approval nodes referenced in the response can be linked to actual approval records via hyperlinks, allowing users to view detailed approval opinions or operation logs by clicking the node name. Rule clauses referenced in the response can be linked to the original rule text, allowing users to view the complete rule details by clicking the rule number. Furthermore, the response text can be segmented and formatted according to a preset logical structure, such as organizing the text in the order of "basic document information - current status of approval process - explanation of rule basis - compliance conclusion," allowing users to understand the entire explanation logic step by step. The responses after these post-processing steps are no longer simple text strings, but structured content containing rich interactive elements, which can significantly improve the efficiency and depth of users' information acquisition and understanding.

[0036] Step 205: Each decision rule in the decision rule base can be updated through the following steps: Encapsulate the target query request, target intent, first query information / second query information, target decision rule, and user feedback on the target response into a question-and-answer pair and save it in the historical query database; Based on the question-and-answer pairs in the historical query database and the preset test rules, use a large model to generate test cases covering all decision rules in the decision rule base; Use the test cases to test the decision rules in the decision rule base and generate a self-inspection report for each decision rule; Generate rule update suggestions based on the self-inspection reports and update the decision rules in the decision rule base based on the rule update suggestions.

[0037] In this embodiment, the executing entity first encapsulates the target query request, target intent, first query information / second query information, target decision rules, and user feedback on the target response into question-and-answer pairs, which are then stored in a historical query database. The encapsulation of question-and-answer pairs can be achieved by defining a unified data structure, such as using JSON format to organize the aforementioned fields and adding metadata such as timestamps and user identifiers to facilitate subsequent retrieval and analysis. Then, based on the question-and-answer pairs in the historical query database and preset test rules, a large model is used to generate test cases covering all decision rules in the decision rule library. The purpose of this step is to verify each decision rule in the decision rule library, ensuring that the decision rules can be correctly matched and interpreted. That is, the preset test rules can include test case construction rules to guide test case generation, such as "each decision rule corresponds to at least one positive test case and one negative test case," "test cases should cover all conditional branches defined in the rule," and "test cases should simulate different user roles and permission scenarios." Finally, the test cases are used to test the decision rule library. The system tests the core decision rules and generates a self-inspection report for each rule. The report includes basic rule information, the total number of test cases, the number of successfully matched cases, details of failed cases, and analysis of the reasons for failure. For example, if a rule fails to match correctly in multiple test cases, the report might indicate that the rule's applicable conditions are too vague or that the rule base index has defects. Finally, the system generates rule update suggestions based on the self-inspection reports and updates the core decision rules in the rule base accordingly. These suggestions address the issues revealed in the reports and propose specific improvement measures. If the report shows that a rule is not recalled in multiple test cases, the suggestion might be to adjust the rule's indexing strategy or optimize its text description. If the report shows that a rule conflicts with or overlaps with another rule, the suggestion might be to merge or adjust the rule's condition definition. If the report shows that a rule frequently causes negative feedback in actual user queries, the suggestion might be to revise the rule content or add exception clauses. Through the above methods, continuous monitoring and optimization of the decision-making rule base are achieved, ensuring that the rules are always accurate, complete, and consistent with business needs, thereby continuously improving the quality and reliability of intelligent query services.

[0038] In this embodiment, the test case construction rules can be used to guide the construction of various test cases, including boundary value test cases, semantic variant test cases, and conflict verification test cases, respectively. Boundary value test cases are used to test the critical values ​​of various numerical adjustments in the decision rules, semantic variant test cases are used to test different colloquial expressions of the same decision rule, and conflict verification test cases are used to test at least two decision rules with logical overlap. Specifically, the approval rules typically include numerical thresholds such as "a single reimbursement amount exceeding 5,000 yuan requires approval from a higher authority." Boundary value test cases are designed to input data near these thresholds (such as 4,999 yuan, 5,000 yuan, and 5,001 yuan) to verify whether the judgment logic of the rule at the critical point is consistent with actual business expectations. The executing entity automatically extracts the data type and value range of the numerical fields (such as amount, number of days, quantity, etc.) defined in the approval rules, and then generates multiple test inputs such as equal to the boundary value, boundary value minus the minimum unit, and boundary value plus the minimum unit. These inputs are then passed to a large model to simulate query requests, and the returned approval conclusion is observed to see if it matches the rule definition. This effectively identifies rule failures caused by incorrect numerical precision or the use of comparison operators (greater than, greater than or equal to). Semantic variant use cases focus on the consistency of the same core decision rule in response to different colloquial or industry-standard expressions. User queries are not always strictly standardized statements. For example, for the rule "business trip requires approval from the supervisor," users might express it as "Who approves my business trip?", "Which supervisor approves my business trip?", "Does my business trip require the supervisor's signature?", etc. Semantic variant use cases leverage the large model's generalized understanding of natural language. By pre-constructing or automatically generating diverse questions with the same rule meaning, they test whether the core decision rule base can correctly match and output the same core decision conclusion at the semantic level. The executing entity can generate several semantically similar but differently expressed questions based on key entities (such as approval nodes and conditional attributes) and verb structures in the rule, using the large model's own generation capabilities. These questions are then used as test inputs to the query process to check whether the target core decision rule is always the expected one. This significantly improves the system's robustness in real-world dialogue environments and avoids rule mismatches or missed matches due to changes in user word choice. The purpose of conflict verification test cases is to detect whether at least two approval rules that logically overlap or intersect will produce contradictory judgment results. Technically, a company's approval system often involves multiple rules acting on the same business scenario. For example, if the rules "the department head's approval authority is capped at 10,000 yuan" and "reimbursements exceeding 8,000 yuan require the CFO's signature" are both true, then for a 9,000 yuan reimbursement request, the correct result should be that both the department head's approval and the CFO's signature are triggered simultaneously.Conflict verification test cases construct query parameters that simultaneously satisfy multiple rules. After inputting these parameters into a large model, the consistency and completeness of the output decision path are observed. This process identifies issues such as missing rule priorities, mutually exclusive conditions, or circular dependencies. The executing entity performs pairwise or combined analysis on the rules in the decision rule base, identifying rule pairs with overlapping condition intervals or intersecting entity scopes. Then, test queries that simultaneously activate these rules are generated and compared to the comprehensive decision results expected in the real business process. If the response returned by the large model contains missing rules, reversed order, or logical contradictions, it indicates a rule conflict, requiring adjustments to rule priorities, rule merging, or the addition of mutual exclusion constraints. These three types of test cases work together to comprehensively cover the quality verification requirements of the decision rule base from three dimensions: numerical accuracy, semantic generalization ability, and logical consistency.

[0039] Furthermore, the conflict resolution operations described above, such as "adjusting rule priority, merging rules, or adding mutual exclusion constraints," can be jointly completed by the executing entity and the larger model based on the conflict resolution guidelines in the preset test rules. That is, in addition to test case construction rules (e.g., "each approval rule corresponds to at least one positive test case and one negative test case," "test cases should cover all conditional branches defined in the rule"), the test rules can further include conflict resolution guidelines, thus constituting a concrete lower-level expansion of the preset test rules in a conflict verification scenario. Specifically, the conflict resolution guidelines can be configured as at least one of the following: 1) Priority Adjustment Guidance Rules: When two or more decision rules have overlapping condition intervals and inconsistent output paths, the large model guides the determination of theoretical priorities for each conflicting rule and outputs a comprehensive decision path according to the principle of "higher priority rules are applied first, and lower priority rules are applied supplementarily or with concessions." The determination of theoretical priorities can be automatically calculated based on the historical application data of the decision rules. Specifically, this includes: tracing the historical application events of each conflicting rule in the historical query database, extracting characteristic factors such as the actual triggering frequency of each rule, the amount of the applicable business documents, the original and current job titles of the personnel involved in formulating the rule, and whether the applicable business events are representative and accidental. The large model automatically assigns theoretical priority values ​​to each conflicting rule after weighted scoring based on these characteristic factors. Rules with higher theoretical priorities are executed first in the decision path, while rules with lower theoretical priorities are supplemented or downgraded to reference prompts, provided they do not directly conflict with higher priority rules. After determining the theoretical priority, the executing entity can push the priority ranking results to the preset rule base administrator in a visual form (such as a priority ranking table or conflict rule comparison view), along with the theoretical priority reasoning basis generated by the large model, and require the administrator to confirm or manually adjust the priority ranking. After receiving confirmation feedback, the theoretical priority will be solidified into the rule attribute field in the decision rule base.

[0040] 2) Rule Merging Guidance: When two or more decision-making rules substantially point to the same business scenario and only differ in threshold ranges or approval nodes, the large model is guided to analyze the trigger condition set and decision-making path set of each conflicting rule, identify the common and differing parts among the rules, and generate a draft merged rule. This draft merged rule uses the common parts as the basic condition and the union or strictest value of the differing parts as the extended condition, ensuring that the merged single rule can cover all the expected applicable scenarios of the original conflicting rules. The draft merged rule is then sent to the rule library administrator for review and confirmation. During the generation of the draft merged rule, the large model can further reference the question-and-answer pairs associated in the historical query database to verify the coverage and accuracy of the draft merged rule in historical query scenarios, ensuring that the merging operation does not introduce new rule blind spots.

[0041] 3) Mutually Exclusive Constraint Guidance Rules: When the condition intervals of two or more approval rules overlap but should not be triggered simultaneously in business operations, the large model is guided to generate mutually exclusive condition expressions for the conflicting rules. For example, an exclusionary constraint of "and does not meet the triggering condition of rule X" can be added to the condition field of one rule, or mutually exclusive applicable condition labels (such as regional labels or business subtype labels) can be added to both rules respectively, so that the originally overlapping condition intervals are divided into independent intervals that do not overlap by mutually exclusive conditions. The large model can also verify whether each rule can still correctly cover its historical applicable scenarios after adding mutually exclusive constraints based on the historical approval records in the historical query database, and send the generated mutually exclusive constraint suggestions to the administrator for confirmation.

[0042] By using the aforementioned priority adjustment guidelines, rule merging guidelines, and mutual exclusion constraint guidelines as subordinate test rules in the conflict resolution phase, the executing entity can automatically generate specific conflict resolution solutions based on these guidelines after discovering rule conflicts using the conflict verification test cases. These solutions are then output to the rule base administrator in an auditable and traceable manner. After manual confirmation, the rule base is updated, forming a complete closed loop of "conflict detection → conflict analysis → conflict resolution suggestion → manual confirmation → rule update." This process not only further clarifies the content of the preset test rules but also extends the self-checking and updating mechanism of the rule base from simply "intelligently discovering conflicts" to "intelligently resolving conflicts," significantly improving the automation level and rule quality of rule base maintenance.

[0043] The following example illustrates the working mechanism of the aforementioned priority adjustment guidelines. Assume there are two approval rules in the approval rule base for similar requests: Rule A states, "A single reimbursement exceeding RMB 5,000 requires department head approval," and Rule B states, "A single reimbursement exceeding RMB 3,000 for a marketing promotion activity requires marketing director approval." These two rules may have been formulated at different historical periods by different personnel for specific events. For example, Rule A was formulated three years ago by an administrative staff member (former P5, current P6) for general office expense reimbursement events, with approximately 1,200 historical application cases, making its application scenario widespread and representative. Rule B, on the other hand, was formulated a year ago by a marketing staff member (former P4, current P5) for a specific reimbursement event related to a large-scale marketing promotion activity, with approximately 80 historical application cases, making its application scenario somewhat random. At the current point in time, for a marketing activity reimbursement request of RMB 6,000, the condition intervals of these two rules overlap (both are satisfied). If the large model directly outputs the approval path, it only triggers the department head's approval and misses the marketing director's approval, then the conflict verification test case detects a "rule omission" type conflict. At this point, the executing entity, based on the priority adjustment guidelines in the test rules, drives the large model to perform the following operations: First, the large model traces the historical application events of decision-making rule A and decision-making rule B from the historical query database, extracting characteristic factors such as the scale of their respective historical application events (comparing 1200 events with 80 events), the original rank of the rule-making personnel (comparing P5 with P4) and current rank (comparing P6 with P5), and whether the applicable events are representative and accidental (comparing general representativeness with specific accidentality); then, the large model quantifies and scores the above characteristic factors based on a preset weighted scoring model. For example, decision-making rule A, with its large historical application event scale, high current rank, and general representativeness, receives a higher theoretical priority score (e.g., 0.85), while decision-making rule B, with its small historical application event scale, relatively low rank of the rule-maker, and accidental nature, receives a lower theoretical priority score (e.g., 0.60); accordingly, the large model determines that the theoretical priority of decision-making rule A is higher than that of decision-making rule B. When generating the approval path, the large model uses approval rule A as the basic framework (department head approval is a mandatory node). However, due to the low priority of approval rule B and its non-conflict with approval rule A (the "market director approval" added by approval rule B can be regarded as a supplement to A), the large model still includes market director approval as a supplementary node in the approval path, but clearly marks it as being based on the lower priority approval rule B and explains the reason.Finally, the large model pushes the theoretical priority ranking results, reasoning basis, and comprehensive decision-making path scheme to the rule base administrator in the form of a structured conflict resolution report. The report includes: conflicting rule pairs (A and B), conflict type (overlapping conditions), a summary of historical application data for each rule, detailed theoretical priority scores, suggested comprehensive decision-making paths, and an interactive entry point for administrator confirmation. After reviewing the report, the administrator can confirm the priority ranking or manually adjust it. The implementing entity updates the rule priority attribute fields and / or the reference relationships between rules in the decision-making rule base based on the administrator's final confirmation. Through this method, not only is intelligent resolution of historical rule conflicts achieved, but the final decision-making power of human intervention is also retained, ensuring the traceability and compliance of the decision-making rule base updates.

[0044] The information query method based on a large model provided in this invention first determines the user's target intent based on the user's target query request, and adopts differentiated information acquisition strategies for two different intents: pre-guidance and post-retrospection, achieving accurate responses to user queries. For pre-guidance queries, target business parameters are determined as the first query information based on the target query request, and matching target approval rules are obtained from the approval rule base, which can quickly provide users with pre-approval conditions for reference and effectively assist decision-making. For post-retrospection queries, upstream and downstream information related to the target query request is obtained from a preset knowledge base as the second query information, and combined with rules in the approval rule base, so that the query results not only contain factual data, but also provide reasonable rule-based explanations, meeting users' needs for in-depth traceability of the compliance of business documents. Furthermore, the first or second query information and the corresponding target approval rules are input into a preset large model, and the natural language understanding and generation capabilities of the large model are used to generate target response results that conform to the user's reading habits, avoiding the tedious process of manually integrating information in traditional methods, and significantly improving query efficiency and response quality. Meanwhile, the entire query process requires no manual intervention, achieving an automated closed loop, reducing enterprise labor costs, and ensuring the timeliness and consistency of responses, thereby improving user experience and enhancing the intelligence level of business management. Furthermore, this invention can automatically generate test cases covering boundary values, semantic variations, and conflict verification based on historical question-and-answer data. It also utilizes conflict resolution guidelines included in preset test rules to perform a comprehensive self-check of the core rule base and generate appropriate conflict solutions and update suggestions, thus achieving automated closed-loop optimization of the rule base, reducing manual maintenance costs, and improving the rules' adaptability to new scenarios, colloquial expressions, and logical conflicts.

[0045] Based on any of the above embodiments, when the target intent is pre-guidance, in order to provide users with accurate and compliant pre-guidance services, please refer to... Figure 3 , Figure 3A flowchart of a method for obtaining target decision rules that match first query information is provided in an embodiment of the present invention, wherein process 300 includes the following steps: Step 301: Input the target query request into the large model, obtain the target business parameters output by the large model, and use the target business parameters as the first query information; In this embodiment, when the target intent is pre-guidance, the executing entity inputs the target query request into the large model. Utilizing the large model's natural language understanding and entity recognition capabilities, it extracts target business parameters that conform to preset business parameter categories from the user's colloquial and fragmented target query request, using these target business parameters as the first query information. Specifically, after receiving the target query request, the large model performs semantic encoding on the input text through its multi-layer Transformer network, capturing the contextual dependencies between words to form a deep semantic understanding of the entire query request. Based on this, the model can identify words or phrases belonging to specific entity categories in the text through sequence labeling or machine reading comprehension. For example, for the user input "I want to apply for an academic conference for grassroots doctors, with a budget of approximately 30,000 yuan," the model can identify that "academic conference" belongs to the business type entity, "30,000 yuan" belongs to the estimated amount entity, and may infer the initiating department information based on the dialogue context. To improve the accuracy and coverage of this extraction process, a large amount of historical query data annotated with business parameters can be used to fine-tune the model during the model training phase. This allows the model to accurately understand the common numerical meaning behind different colloquial expressions such as "around 20,000," "budget of 50,000," and "cost approximately 30,000," as well as the mapping relationship between words such as "conference," "event," and "promotion" and specific business types. The extracted target business parameters will be organized into structured first query information, for example, organized in the form of key-value pairs as "Business type: academic conference, estimated amount: 30,000 yuan, unit: yuan," serving as precise input conditions for subsequent rule-based retrieval.

[0046] Step 302: Determine the user's permission information based on the user identifier contained in the target query request; In this embodiment, the executing entity determines the user's permission information based on the user identifier contained in the target query request. The user identifier is a unique identifier for the user, such as an employee ID, account ID, or mobile phone number, and can typically be obtained from the session information, authentication token, or request parameters carried when the user initiates the target query request. Based on this user identifier, the executing entity needs to query the permission management system or user information center to obtain the user's permission information regarding approval rule queries. Different user roles often have different visibility ranges for approval rules. For example, ordinary employees may only be able to view routine approval rules related to their department and position; department heads may be allowed to view cross-departmental collaborative approval rules in addition to their department's rules; while compliance specialists or auditors may have the right to view all rules across the company, including sensitive high-level approval permission settings. Obtaining permission information is typically achieved by calling a unified permission service interface. This interface receives the user identifier as input and returns the scope of rules that the user is authorized to view, such as a list of viewable business types, the range of viewable departments, and the security level of viewable rules. This permission information will serve as a constraint for subsequent rule retrieval, ensuring that users can only access the rules within their authorized scope and preventing the leakage of sensitive information.

[0047] Step 303: Based on the permission information and the first query information, obtain the target decision rule that is within the user's permissions and matches the first query information from the decision rule base; In this embodiment, the executing entity retrieves target decision rules that are within the user's permissions and match the first query information from the decision rule base based on permission information and the first query information. Specifically, the matching process typically employs a multi-condition combined filtering retrieval strategy. First, the executing entity performs preliminary screening based on the business parameters in the first query information, such as recalling all candidate rules matching "academic conference" from the rule base. Subsequently, based on the candidate rules, user permission information is used as a filtering condition to eliminate rules that are beyond the user's visibility range. For example, if a rule is explicitly marked as only visible to directors and above, and the current user is a regular employee, that rule will be filtered out. After permission filtering, the executing entity further uses other business parameters in the first query information for precise matching, such as comparing the estimated amount "30,000 yuan" with the amount threshold range of each candidate rule, retaining only rules whose amount threshold range covers 30,000 yuan; at the same time, filtering is performed in conjunction with information such as the initiating department. Through this progressively refined matching strategy, one or more target decision rules that match the user's query scenario and that the user has the right to view are finally obtained.

[0048] In this implementation, permission information may be expressed in various forms, such as the user's department, job title, and role tags. Rule permissions may also be defined as conditional expressions, such as "only allowed to view by marketing department employees" or "only allowed to view by employees at level P7 and above." During matching, the executing entity needs to be able to parse these conditional expressions and dynamically determine permissions based on the user's attribute information. To improve retrieval efficiency, the permission attributes of rules can be pre-calculated and indexed when the rules are entered into the database, or a strategy of parallel execution of permission filtering and business matching can be adopted. For example, user permission information can be converted into query conditions at the database query level, filtering out rules that the user is authorized to view and that match the business requirements from the rule base in one go. Furthermore, when the rules within a user's permission scope are insufficient to completely match their query, the system can generate partially matching results based on existing rules and prompt the user that part of their query may exceed their permission scope, or guide the user to apply for higher permissions. Through the comprehensive application of the above technical means, the system can provide users with accurate and compliant pre-emptive guidance services while ensuring data security, laying an accurate data foundation for generating the target response results subsequently.

[0049] The method for obtaining target decision rules that match the first query information provided in this embodiment of the invention uses a pre-guidance intent to intelligently extract target business parameters from the user query input big model as the first query information. At the same time, it determines permission information based on the user identifier, and then combines the permissions and business parameters to accurately match the target decision rules within the user's permissions from the decision rule base. This not only utilizes the semantic understanding capability of the big model to achieve efficient conversion from natural language to structured parameters, but also ensures the security and compliance of rule queries through permission verification, avoiding unauthorized access to sensitive rule information. Thus, it provides users with accurate and personalized pre-guidance services while ensuring data security.

[0050] Based on any of the above embodiments, when the target intent is post-event retrospective, in order to provide users with accurate and compliant pre-event guidance services, please refer to... Figure 4 , Figure 4 A flowchart of a method for obtaining target decision rules that match second query information is provided in an embodiment of the present invention, wherein process 400 includes the following steps: Step 401: Input the target query request into the large model to obtain the key entity information output by the large model; In this embodiment, when the target intent is post-event retrospective, the executing entity inputs the target query request into the large model to obtain the key entity information output by the large model. Key entity information refers to core data items that uniquely identify a business document or business process. The most common form is the document number; for example, in the user's input "Please explain why document number EXP20260101 was returned by finance," "EXP20260101" is the document number. In addition, key entity information may also include unique business identifiers such as contract numbers, application numbers, and purchase order numbers. The process of inputting the target query request into the large model to determine key entity information essentially utilizes the large model's natural language understanding and named entity recognition capabilities to extract key information that conforms to a preset entity category from the user's colloquial and fragmented input. From a technical perspective, after receiving the target query request, the large model performs semantic encoding on the input text through its multi-layered Transformer network, capturing the contextual dependencies between words to form a deep semantic understanding of the entire query request. Building upon this foundation, the model can identify words or phrases belonging to predefined entity categories in text through sequence labeling. For example, the model can recognize that the continuous character sequence "EXP20260101" conforms to the format characteristics of a document number, and combined with the contextual clue "document number," confirm that it belongs to the document number entity. To improve the accuracy and coverage of this extraction process, the model can be fine-tuned during the training phase using a large amount of historical query data annotated with key entity information. This allows the model to accurately identify document numbers in different formats and document references in different ways, such as variations like "document number PL03073701," "my expense report 20241008," and "purchase contract PO-2024-001."

[0051] Step 402: Determine the user's permission information based on the user identifier contained in the target query request; In this embodiment, the executing entity determines the user's permission information based on the user identifier contained in the target query request. The user identifier is a unique identifier for the user in the system, such as an employee ID, account ID, or mobile phone number, and can typically be obtained from the session information, authentication token, or request parameters carried by the user when initiating the query. Based on this user identifier, the executing entity needs to query the permission management system or user information center to obtain the user's permission information for post-event traceability queries. In practical applications, viewing permissions for business documents are usually strictly controlled. For example, ordinary employees can generally only view documents initiated by themselves; department heads can view all documents initiated by employees in their department; finance personnel may have the right to view documents related to financial reimbursement; and compliance auditors may have super-permissions to view all documents in the entire company. Obtaining permission information is usually achieved by calling a unified permission service interface. This interface receives parameters such as the user identifier and document type as input and returns the scope of documents the user is authorized to view, such as the list of initiators, the range of departments that can be viewed, and the types of documents that can be viewed. In some sophisticated permission models, the permission service may also return a user's specific operational permissions for particular documents, such as being able to view only basic information, view complete approval records, or view sensitive financial information. This permission information will serve as a constraint on subsequent data retrieval, ensuring that users can only access document information within their authorized scope and preventing the leakage of sensitive data.

[0052] Step 403: Based on permission information and key entity information, retrieve upstream and downstream information that is within the user's permissions and is associated with the target query request from the preset knowledge base, and use the upstream and downstream information as the second query information.

[0053] In this embodiment, based on permission information and key entity information, the executing entity retrieves upstream and downstream information related to the target query request that falls within the user's permissions from a preset knowledge base, and uses this upstream and downstream information as the second query information. Specifically, firstly, the executing entity uses key entity information (e.g., document number) as an index to query all data associated with the document in the preset knowledge base. During the query, user permission information is used as a filtering condition. For example, if the user's permissions only allow them to view documents initiated by themselves, the system will add a filter condition of "initiator equals current user" during the query; if the user's permissions allow them to view all documents in their department, the executing entity will query documents where the initiator's department is equal to the user's department and match them with the key entity information. Only documents that pass the permission verification will have their associated data returned. After permission filtering, the upstream and downstream information obtained by the system typically includes two main parts: Tracing upstream, it retrieves form data such as the initiator's information, initiating department, form completion time, business type, application amount, and expense details, describing the business background and content of the document; tracing downstream, it retrieves the complete approval workflow record, including the approver, approval time, approval comments, node status, and relevant attachments involved in the approval process at each approval node; Horizontally, it can also obtain organizational structure information related to the initiator of the document, such as their reporting superior and department head, which is crucial for understanding the rationality of the approval path. All this information will be integrated into structured second query information, such as organized in JSON or XML format, as factual input for subsequent processing. This information collectively constitutes a complete factual description of the document, which will be integrated into structured second query information as the factual basis for subsequent rule matching and compliance judgment. In actual deployment, in order to ensure the timeliness and accuracy of the information obtained, the knowledge base and the source system can adopt an incremental synchronization or real-time query mechanism. For example, for documents that are in circulation, the approval records may be updated at any time, and the executing entity needs to be able to obtain the latest approval status to ensure the timeliness of the query results.

[0054] In this embodiment, the robustness of key entity information extraction and multi-entity processing capabilities also need to be considered. User input may mention multiple documents simultaneously, such as "Please compare the differences in the approval processes of document A and document B." In this case, the large model needs to be able to identify all mentioned key entity information, and the executing entity needs to obtain the upstream and downstream information of each document separately. Furthermore, when the user input does not explicitly include a document number but describes the document in other ways, such as "the travel application I submitted last week," the large model needs to combine context and user history information for reasoning. This may require retrieving a list of recently submitted documents from the user information and then determining the specific document through semantic matching. In this case, a candidate document list can also be returned and the user requested to confirm to clarify the specific key entity information. Simultaneously, the performance and real-time nature of the preset knowledge base are also important considerations. For documents in progress, approval records may be updated at any time, requiring assurance that the latest data is obtained. This can be achieved by using incremental synchronization or real-time query mechanisms between the preset knowledge base and the source system. For example, for frequently accessed documents or real-time queries, data can be directly retrieved from the source system, while historical documents can be read from a pre-defined knowledge base cache to balance data timeliness and system load. Through the comprehensive application of these technologies, the executing entity can accurately and efficiently obtain complete upstream and downstream information of documents within the user's permissions, providing solid data support for the subsequent generation of compliance explanations and traceability reports.

[0055] The method for obtaining target decision rules that match the second query information provided in this embodiment of the invention, if the target intent is a retrospective intent, uses the user query input to a large model to intelligently extract key entity information, and determines permission information based on the user identifier. Then, it combines the permissions and entity information to accurately obtain complete upstream and downstream information within the user's permissions from a preset knowledge base as the second query information. The large model realizes the efficient conversion from fuzzy query to precise entity, and the permission verification ensures the secure access to sensitive business data, avoids the leakage of unauthorized information, and provides a comprehensive, accurate and secure factual data foundation for subsequent compliance analysis and interpretation.

[0056] Based on the embodiments disclosed in process 300 or process 400 above, in order to achieve efficient and accurate rule matching in the process of determining the target decision rule from the decision rule base, the following technical solution is further disclosed: The process of determining the target decision rule from the decision rule base includes: obtaining matching candidate decision rules from the decision rule base according to the first query information or the second query information. For example, for pre-event guidance queries, the executing entity can perform preliminary screening based on strongly related fields such as business type and initiating department in the first query information, and recall all candidate decision rules that match the business type and applicable department from the decision rule base; for post-event traceability queries, the executing entity can perform preliminary screening based on the second query information. The system performs initial screening using fields such as business type, initiating department, and actual amount. It then retrieves all candidate approval rules from the approval rule library that match the business type, applicable department, and amount range. Next, it uses preset business conditions, including at least one of the following, to filter the candidate approval rules and obtain the target approval rule. These preset business conditions are a flexible and configurable set of filtering rules, whose specific content can be customized according to business characteristics and rule complexity. These conditions include at least one of the following: the threshold value range of the actual or estimated amount; the user's department or organizational unit; the business category or level; the effective time range of the candidate approval rule; and the current effective status flag of the candidate approval rule. Approval rules are often associated with specific organizational structures; for example, some rules only apply to the sales department, and some only apply to the R&D department. Therefore, it is necessary to filter candidate rules based on the user's department, eliminating those rules that are clearly not applicable to that department.

[0057] In this embodiment, to improve the coverage and robustness of the recall, synonym expansion and fuzzy matching mechanisms can be introduced. For example, the business type entered by the user might be "marketing promotion activity," while the rule base might record "academic promotion." Through a pre-built thesaurus or semantic vector-based similarity calculation, the executing entity can identify the relationship between the two, thereby recalling relevant rules and avoiding rule omissions due to differences in wording. Furthermore, for recall involving numerical fields such as amounts, an interval overlap judgment method can be used. For example, all rules whose amount threshold intervals intersect or overlap with the user-input amount can be recalled. This embodiment obtains a relatively broad set of candidate rules through the above methods, providing a foundation for subsequent refined filtering.

[0058] In this embodiment, the preset business conditions can include at least the following types: The first type is monetary conditions, such as the threshold value range of the actual or estimated amount. For pre-emptive guidance queries, the estimated amount entered by the user needs to be compared with the monetary threshold range defined in each candidate rule, and only rules whose monetary threshold range can cover the estimated amount are retained. For post-event retrospective queries, the actual amount of the document needs to be compared with the rule threshold to ensure that the applicability of the rule matches the actual business. The second type is organizational unit-related conditions, such as the department or organizational unit to which the user belongs. Approval rules are often associated with a specific organizational structure. For example, some rules only apply to the sales department, and some rules only apply to the R&D department. Therefore, candidate rules need to be filtered according to the user's department to eliminate those rules that are clearly not applicable to that department. The third type is business classification or hierarchical conditions, such as the business classification (procurement, expense reimbursement, contract) or hierarchy (ordinary matters, important matters, strategic matters). It is necessary to accurately match the business classification in the query information with the applicable business types defined in the rules. The fourth category is the timeliness condition of the rules, including the effective time range of the candidate approval rules and the current effective status flag of the candidate approval rules. Approval rules may be adjusted as enterprise management needs change, such as raising the monetary threshold for approval authority or adding new approval nodes. Therefore, when determining the target rules, it is necessary to ensure that the recalled rules are the valid and effective versions at the current time. This can be achieved by checking the rule's effective start time, effective end time, and status flag. For example, adding a filter condition of "the current system time is within the rule's effective time range and the status flag is effective" can effectively avoid providing users with expired or ineffective rule information, ensuring the authority and accuracy of the query results. These preset business conditions can be used individually or in combination. Through layer-by-layer filtering, the executing entity can accurately locate one or more target approval rules that best match the current user query scenario from a candidate set containing hundreds or thousands of rules.

[0059] In this embodiment, the priority and combination logic of preset business conditions also need to be considered. When multiple preset business conditions are applied simultaneously, the logical relationship between each condition needs to be clarified, such as whether it is an "AND" relationship (all conditions must be met simultaneously) or an "OR" relationship (meeting any one condition is sufficient), which depends on the specific business rule design. Typically, conditions such as amount thresholds, applicable departments, and business categories are combined using an "AND" relationship, meaning the rule must meet all conditions simultaneously to be considered a match; while for some supplementary conditions, such as optional applicable scenarios for rules, an "OR" relationship may be used. Furthermore, to improve filtering efficiency, indexes can be created for various attributes of the rules during the rule base design phase. For example, B-tree or R-tree indexes can be created for amount threshold ranges to support efficient range queries, and inverted indexes can be created for category attributes such as departments and business types to support fast equality matching. During query execution, the database query optimizer can select the optimal execution plan based on the index situation, ensuring the real-time nature of the filtering process and the controllability of system load. By comprehensively utilizing the above-mentioned technical means, the process of determining the target decision rules from the decision rule base can achieve efficient and accurate rule matching, providing accurate and reliable rule basis for the subsequent generation of target response results.

[0060] The decision-making rule filtering method disclosed in this embodiment obtains candidate rules from the rule base based on query information and performs refined filtering based on preset business conditions such as amount threshold, department organization, business classification, and rule timeliness. This achieves a two-stage rule screening process from broad recall to precise matching, ensuring that the final determined target decision-making rule is highly consistent with the user's specific business scenario, while also guaranteeing the current validity of the rule. This provides accurate, reliable, and practical rule basis for generating subsequent query results, significantly improving the accuracy and practicality of rule matching.

[0061] Based on any of the above embodiments, to ensure that the target response results generated by the large model are readable, interpretable, and verifiable, and to provide users with high-quality intelligent query services, please refer to [the relevant documentation / reference]. Figure 5 , Figure 5 A flowchart of a method for generating target response results based on a large model, provided for an embodiment of the present invention, wherein process 500 includes the following steps: Step 501: Mark the source of each data field in the first query information / second query information and determine the confidence level of each data field; In this embodiment, the executing entity annotates the source of each data field in the first / second query information to determine the confidence level of each data field. Data fields originating from a preset knowledge base are marked with high confidence, while data fields originating from the target query request are marked with low confidence. Specifically, the first or second query information may contain various types of data fields. For example, in pre-event guidance queries, this information may include target business parameters such as business type, estimated amount, and initiating department; in post-event traceability queries, this information may include upstream and downstream information such as approval form data, approval flow records, and organizational structure relationships. The sources of these data fields may differ. Some originate from a preset knowledge base, such as approval records synchronized from the process center or organizational structure information obtained from the user center. This data undergoes system synchronization and verification and typically has high accuracy and reliability. However, some data fields may directly originate from the user's target query request itself, such as the amount or business type description directly mentioned by the user in the query. This information has not been verified by other systems and may contain inaccurate descriptions, misunderstandings, or missing information. Therefore, source labeling of data fields can clearly distinguish the credibility of data from different sources, providing an important reference for subsequent large-scale model response generation.

[0062] In this embodiment, source labeling can be achieved by attaching metadata tags to each field at the data structure level. For example, the field attribute "source" can be used to mark that the data originates from "knowledge_base" or "user_query". Data fields originating from a preset knowledge base are labeled as high-confidence, while data fields originating from the target query request are labeled as low-confidence, according to preset rules. This labeling method not only quantifies the credibility of the data but also provides clear guidance on how large models should weigh the weights of different information during inference. In practical applications, confidence can be represented numerically, such as 0.9 for high confidence and 0.5 for low confidence, or it can be represented by text labels, directly adding identifiers such as "(system record)" or "(user provided)" to the field description for intuitive differentiation in subsequent processing.

[0063] Step 502: Embed the first / second query information marked with confidence level, the corresponding target decision rules, and the preset confidence rules into the preset prompt word template to generate target prompt words; In this embodiment, the executing entity embeds the first / second query information labeled with confidence levels, the corresponding target decision rules, and the pre-set confidence rules into a preset prompt word template to generate target prompt words. The prompt word template is a pre-designed, structured text framework whose function is to organize the various input information according to a certain logical order and format, forming a prompt text containing clear instructions and complete context to guide the large model in generating an expected response. A prompt template typically consists of several components: First, a role setting section informs the large model of its intended role, such as "You are a corporate process compliance consultant. Please provide accurate and clear explanations to users based on the following information." Second, a task description section clearly states the task the model needs to complete, such as "Based on the provided factual data and rule clauses, analyze the compliance of the approval process and provide a conclusion." Third, the information body section presents the first or second query information and the target approval rule in a structured manner, such as listing the key nodes of the approval record in a list format, presenting the original text of the rule in a citation format, and incorporating confidence level annotations into the information description appropriately, such as stating "The system record shows that the actual amount is 80,000 yuan" for high-confidence fields and stating "The user mentioned a budget of approximately 30,000 yuan" for low-confidence fields. Finally, the output requirements section specifies the format, logical structure, and language style of the model's generated response, such as "Please organize your response according to the structure of 'Fact Overview - Rule Basis - Conclusion Recommendation,' and the conclusion section must clearly indicate whether it is compliant and the reasons."

[0064] In this embodiment, when embedding the first or second query information labeled with confidence levels and the target decision rule into the prompt word template, it is also necessary to embed pre-defined confidence rules simultaneously. Pre-defined confidence rules are a set of predefined behavioral guidelines used to guide the model when processing information with different confidence levels. Examples include: "When high-confidence information conflicts with low-confidence information, the high-confidence information prevails," "For low-confidence information, when citing it, it must be clearly stated that it originates from user input, and the user must be prompted to verify," and "When generating conclusions, judgments should be based primarily on high-confidence information." These rules can be embedded in the prompt words in the form of natural language instructions. For example, a note could be added to the prompt words: "Please note the confidence levels of the following information: Information from the system knowledge base has high confidence and can be used as definitive facts; information from user input has low confidence and is only for reference; the user must be prompted to verify in the conclusion." In this way, pre-defined confidence rules are combined with specific information to form refined constraints on model behavior.

[0065] Step 503: Input the target prompt words into the large model, obtain the target response results output by the large model, and push the target response results to the user.

[0066] In this embodiment, the executing entity inputs the target prompt words into the large model, obtains the target response result output by the large model, and pushes the target response result to the user. The large model is used to generate response results for the target query request and perform a reasonableness analysis on the response results. The large model first segments and encodes the prompt word text, converting it into a series of semantic vectors. Then, through the attention mechanism of a multi-layer Transformer network, it captures the semantic relationships between different information fragments in the vector space, such as comparing the actual approver in the approval record with the specified approver in the rule, or comparing the document amount with the rule threshold. Based on this, the model uses its autoregressive generation capability to predict and generate the output text word by word. Each step of generation depends on the already generated text and the contextual information of the original input to ensure the coherence and consistency of the generated content.

[0067] During the generation of the target response, the large model also differentiates information with different confidence levels based on the instructions in the prompts and pre-set confidence rules. For example, for high-confidence approval records from a pre-set knowledge base, the large model directly cites them as certain facts and assigns them high weight in the reasoning; while for low-confidence estimated amounts from user queries, the model may add explanations when generating the response, such as "Based on your provided budget of 30,000 yuan," and prompt the user in the conclusion section, "Please refer to the actual document amount for the final result. We suggest you check the accurate information through the document number after submitting your application." In addition, the large model is also required to perform a reasonableness analysis on the response results. This means that while generating the response, the model is actually performing a process of logical reasoning and compliance judgment internally. Its output not only includes a direct answer to the user's question but also implicitly contains a chain of reasoning based on facts and rules. For example, for post-event retrospective queries, the model-generated response might include a statement such as, "According to system records, the actual amount of this document is 80,000 yuan, while approval rule R-2024-001 stipulates that amounts exceeding 50,000 yuan require financial approval; therefore, adding a financial node to the process is reasonable." This statement includes factual citations, rule-based justification, and logical conclusions. In this way, the target response generated by the large model is not only readable but also interpretable and verifiable, providing users with high-quality intelligent query services.

[0068] The method for generating target response results based on a large model disclosed in this embodiment distinguishes high-confidence knowledge base data from low-confidence user input data by annotating the source of query information. The annotated information, target rules, and pre-set confidence rules are jointly embedded into a prompt word template, guiding the large model to reasonably weigh information weights based on confidence differences when generating responses. At the same time, the model is required to perform a rationality analysis on the responses, which effectively improves the accuracy and credibility of the results generated by the large model, reduces the risk of incorrect responses due to user input bias, and enhances the interpretability and logical rigor of the responses.

[0069] Building upon the above embodiments, to provide users with the best reading experience and improve information retrieval efficiency, the executing entity can obtain the target response result output by the large model in the following way: First, input the target prompts into the large model to obtain the initial response text output by the large model; then, perform post-processing operations on the initial response text, including at least one of the following: highlighting key data fields, hyperlinking the approval nodes referenced in the initial response text to the actual approval records, hyperlinking the rule clauses referenced in the initial response text to the original rule text, and formatting the initial response text into segments according to a preset format; finally, encapsulate the response text obtained after post-processing operations into the target response result. With the target response result formed in this way, users can not only obtain the conclusions generated by the large model, but also quickly capture the most relevant information points while scanning the response, and trace back to the original data and rule text for independent verification, thereby improving the transparency and credibility of the query results.

[0070] Building upon the above embodiments, to autonomously assess the completeness of the decision-making rule base, this embodiment further discloses the use of a large model to determine whether there are missing decision-making rules in the rule base. If missing rules exist, the large model generates rule supplement suggestions and sends these suggestions to a pre-defined rule base administrator to generate new decision-making rules. Specifically, when the large model is processing a target query request, first query information, or second query information, and currently matched target decision-making rules, if it finds that the user's actual query scenario or required decision conditions cannot be effectively covered by any existing rule in the decision-making rule base, the large model determines that there are missing decision-making rules. This judgment is typically based on the large model's semantic understanding and logical reasoning capabilities regarding the input information: the large model compares the key elements in the user's query (such as business type, amount range, approval node, condition combination, etc.) with the triggering conditions of each decision-making rule in the rule base. When the similarity is below a set threshold or there is a lack of rules that can fully explain the current scenario, a missing rule is output. The executing entity can pre-design a prompt template for missing detection, requiring the large model to output fields such as "whether there is a missing rule," "description of the missing rule conditions," and "suggested rule content" in a structured form, thereby standardizing the judgment process. Once the large model determines that a decision rule is missing, it will further generate a suggested update rule. This suggested update rule is a structured draft decision rule, which typically includes key elements such as the triggering conditions of the decision rule, the applicable business scenario, the decision path (e.g., which roles need to approve), and constraints (e.g., amount limit, time limit). The large model automatically infers the rule content that should be supplemented in a given missing scenario based on the extensive business knowledge it has learned in the pre-training stage and the domain rule patterns fine-tuned from historical query question-answer pairs. The executing entity can define a set of rule templates (e.g., using JSON format or a specific domain language) to guide the large model to fill in the suggested content according to the template fields, ensuring that the generated suggested update rule has good readability and editability, making it easy for administrators to directly adopt or modify it later.After generating the suggested update rule, the executing entity will invoke the early warning notification function to notify the administrator. This early warning notification function refers to a message push mechanism pre-integrated into the system, capable of delivering the suggested update rule to the administrator responsible for maintaining the decision-making rule base in a timely manner through various channels (such as email, instant messaging tools, system message lists, or enterprise-level collaboration platforms). The early warning notification function is typically designed based on an event-driven architecture. When the judgment result of a missing decision rule and the generated suggested update rule are generated as event payloads, a notification service module is triggered. This module assembles and sends the notification content based on the configured administrator contact information (such as email address and user ID). The notification content not only includes the suggested update rule but can also include information such as the original user query request that caused the missing rule and a summary of the basis for the missing judgment, helping the administrator quickly understand the business context and decide whether to formally include the suggested rule in the decision-making rule base. After receiving the notification, the administrator can review and adjust the suggested update rule according to actual business procedures and ultimately execute the update operation, thus forming a closed loop for the continuous evolution of the decision-making rule base. In addition, the rule missing detection and update notification is a proactive rule base maintenance mechanism. It does not rely on regular manual review, but rather the large model dynamically discovers rule blind spots during routine query processing, which significantly improves the rule base's adaptability to constantly changing business needs.

[0071] Based on the above embodiments, in order to obtain a dedicated large model for generating target response results, this embodiment further discloses the training of the large model through the following steps: First, obtain question-answer pairs from the historical query database and determine the quality labels of the question-answer pairs. The quality labels are markers used to identify the quality of each question-answer pair and can be automatically generated based on user feedback. For example, question-answer pairs marked as "useful" by users are assigned a high-quality label, and question-answer pairs marked as "useless" by users are assigned a low-quality label. Then, based on each question-answer pair and its corresponding quality label in the historical query database, training samples are constructed. Finally, the initial large model is fine-tuned using the training samples to obtain a large model for generating target response results. During the training process, the large model repeatedly reads the training samples and learns how to generate responses that meet business requirements based on the input query information and rules. After multiple rounds of iterative training, once the model's performance on the validation set stabilizes, a fine-tuned large model specifically for generating target responses can be obtained. Compared to the general large model, this fine-tuned model has significant improvements in the accuracy of intent understanding, the standardization of rule citation, and the rationality of response structure. It can better meet the professional needs of business approval query scenarios and provide users with higher quality services.

[0072] In this example, to improve the accuracy and coverage of the labels, a manual review mechanism can be introduced, where business experts or operations personnel sample and evaluate a subset of question-and-answer pairs and assign quality levels. Alternatively, a semi-automated approach can be used, such as leveraging a large model to perform initial quality scoring on the question-and-answer pairs, followed by manual verification for calibration. Quality labels can be binary, such as "high quality" and "low quality," or more granular, such as a five-point scale, to provide finer-grained supervision signals during subsequent training.

[0073] In this example, when constructing training samples, the relevant information in each question-answer pair needs to be reorganized into a form suitable for model learning. Specifically, for each question-answer pair, the target query request can be used as part of the user input, key query information and target decision rules can be used as contextual information, and the original target response result can be used as the expected output. Meanwhile, the role of quality labels at this stage is to filter and weight training samples. For example, only question-answer pairs with high-quality labels can be retained as training samples, or different loss weights can be assigned to samples of different qualities, so that the model pays more attention to the correct behavior represented by high-quality samples during training.

[0074] To enhance understanding, this invention also provides a specific implementation scheme in conjunction with a particular application scenario, as shown in the example below. Figure 6 As shown.

[0075] Company A designed an information query system, which was deployed on the company's internal server.

[0076] Scenario 1: Employee Zhang San plans to hold an academic conference for doctors in city X, with an estimated 50 attendees and a total budget of 90,000 yuan. He needs to know in advance what approval processes are required for this expense, so he opens the company's information query system to check: 1. A user initiates a query. Zhang San enters in the dialog box: "I want to hold an academic conference in Hangzhou with a budget of 90,000 yuan and 50 attendees. Which leaders need to approve it?" 2. Determine the target intent. After receiving the target query request input by Zhang San, the information query system calls the intent recognition module to preprocess the text (cleaning, word segmentation, and removal of stop words) and uses a large model to calculate the intent probability. The results are: the probability of pre-guidance type is 0.93, and the probability of post-tracing type is 0.07. Since the probability of pre-guidance type is higher than the confidence threshold (e.g., 0.7), the information query system determines that the user's target intent is pre-guidance type.

[0077] 3. Since the target intent is pre-event guidance, the information query system extracts the target business parameters from the target query request, specifically [Business Type: Academic Conference; Event Location: Hangzhou; Estimated Amount: 90,000 RMB; Number of Participants: 50]. Combined with the user identifier (Zhang San's employee ID), the system retrieves his department (Marketing Department) from the user center. These business parameters are then organized into structured first query information.

[0078] 4. Obtain the target approval rule from the approval rule library. The information query system uses the first query information as a condition to match in the approval rule library, searching for all business types containing "academic conference" or "marketing activity", resulting in 8 candidate approval rules. Next, filter by conditions such as amount threshold, department, number of participants, etc., retaining rules with an amount range covering 90,000 yuan → 3 rules remaining, retaining rules applicable to the marketing department → 2 rules remaining, retaining rules related to the number of participants (e.g., ≥30 people require compliance filing) → 2 rules remaining, checking the effective time and status of the rules → both rules are in effect, finally matching two target approval rules: Rule R-01: Standard approval for academic conferences (amount 50,000~150,000 yuan), approval path: Marketing Director → Finance Review, Rule R-02: Compliance requirements for large-scale events (≥30 participants), requires adding a compliance department filing node.

[0079] 5. The information query system inputs the initial query information (including confidence level labels) and target decision rules into a pre-set large model to construct prompt words, requiring the model to generate clear and structured target response results. For example: [Pre-event guidance] Based on the information you provided (marketing department, academic conference, budget of 90,000, 50 attendees), the system has outlined the approval process for you as follows: 1. Rule R-01: Approval of Academic Conference Standards - Applicable amount: 50,000 to 150,000 yuan - Approval path: Marketing Director Approval → Financial Review 2. Rule R-02: Compliance Requirements for Large Events - Applicable conditions: ≥30 participants - Approval path: Add a compliance department filing node In summary, your meeting application requires the following: Marketing Director Approval → Compliance Department Filing → Financial Audit Note: The above is generated based on your input budget and number of people. The final version is subject to the actual submitted document.

[0080] 6. Push the results to the user. The information query system will push the above target reply results to Zhang San's chat window in rich text format and display them in a formatted way on the front end (highlighting key nodes and attaching hyperlinks with rule numbers). Zhang San can then clearly understand the approval process and prepare for submitting the application later.

[0081] Application Scenario 2: Employee Li Si finds that the business process he initiated is stuck at the "financial review" node and has been showing "processing" for more than 2 hours. He is worried that there is a problem with the process, so he initiates a query in the information query system.

[0082] 1. A user initiates a query. Li Si enters the target query request in the dialog box: "Why does order number-20260101-001 require financial approval? My budget is only 90,000, and similar meetings have never required it before."

[0083] 2. Determine the target intent. After receiving the target query request input by Li Si, the information query system calls the intent recognition module to preprocess the text (cleaning, word segmentation, and removal of stop words) and uses a large model to calculate the intent probability. The results are: the probability of pre-guidance type is 0.13, and the probability of post-tracing type is 0.87. Since the probability of post-tracing type is higher than the confidence threshold (e.g., 0.7), the information query system determines that the user's target intent is post-tracing type.

[0084] 3. Since the target intent is pre-emptive guidance, the information query system uses a large model to extract key entity information from the target query request, specifically [Document Number: 20260101-001]. Combined with the user identifier (Li Si's employee ID), it confirms from the user center that Li Si is the document initiator and has the right to view complete information. Using the document number as an index, the information query system retrieves related upstream and downstream information from a pre-set knowledge base, specifically [Initiator: Liu Wei (Marketing Department), Business Type: Academic Conference, Budget: 85,000 RMB, Number of Attendees: 50, Submission Time: 2026-03-18 10:30, Approval Records, Organizational Structure Information], as the second query information, and marks the source and confidence level of each field.

[0085] 4. Based on the second query information, the information query system matches the target approval rule from the approval rule base, recalling all rules containing "academic conference" or "marketing activity" in the business type, resulting in 8 candidate approval rules. These are then filtered sequentially using conditions such as amount threshold, department, and number of participants. Rules covering an amount range of 90,000 yuan are retained (3 rules remaining); rules applicable to the marketing department are retained (2 rules remaining); and rules with participant requirements are retained (1 rule remaining). The rule's effective date is checked, and one rule is found to be effective. Rule R-03 is matched, which stipulates that for academic conference-related businesses, when the application amount reaches 80,000 yuan or more, a financial co-signing node must be added.

[0086] 5. The information query system inputs the second query information (including factual data) and the target decision-making rules into a pre-set large model, constructs prompt words, and requires the model to generate an explanatory report containing factual references, rule basis, and compliance conclusions. For example: [Post-event Retrospective Analysis Report] Document Number: 20260101-001 Analysis time: 2026-03-19 10:00 [Fact Citation] According to system records, the basic information of the document 20260101-001 you queried is as follows: - Initiator: Zhang San (Marketing Department) - Business Type: Academic Conference - Application amount: 90,000 yuan - Number of attendees: 50 Submission time: 2026-03-18 10:30 The approval record for this document shows: 1. Approved by Marketing Director Wang Qiang on March 18, 2026 at 11:20 AM. 2. March 18, 2026, 14:00: Compliance Department, Chen Min, approved the filing. 3. March 19, 2026, 09:30: Finance Department's Li Fang completed the financial countersigning (currently completed). [Basis of the rules] You asked "Why is financial countersignature required?" After checking the currently effective approval rules, the system found the following rules: Rule R-03 (Financial Co-signing Rule) - Applicable business: academic conferences, marketing activities - Applicable departments: Marketing Department, Medical Department - Triggering condition: Application amount ≥ 80,000 yuan - Countersigning requirement: Add a financial countersigning step (reviewed by a designated person from the finance department). [Compliance Conclusion] Based on the above facts and rules, the analysis is as follows: Why is financial approval required? Rule R-03 stipulates that academic conferences with amounts of 80,000 RMB or more require an additional financial countersignature step. Your invoice amount is 90,000 RMB, which has reached the countersignature trigger threshold. You mentioned that "previous similar meetings did not require this." Upon verification, Rule R-03 came into effect on January 1, 2026. If your previous meeting took place in 2025, before this rule came into effect, then financial countersignature was not required. After the new rule takes effect, all eligible documents will require financial countersignature.

[0087] Conclusion: Your document 20260101-001 has an amount of 90,000 yuan, which has reached the financial countersigning trigger threshold (80,000 yuan). The financial countersigning node in the process is fully compliant with the current effective rules, and the process design is correct. Please rest assured.

[0088] [Supplementary Notes] - To view the full text of the rule, please click the hyperlink above for the rule number. - To view the rule change history, click "View rule version history".

[0089] 6. The information query system performs post-processing on the responses, highlighting key fields such as "90,000 yuan", "80,000 yuan", "financial countersignature", "R-03", and "effective January 1, 2026" in bold red. "R-03" is linked to the original rule page, and "view rule version history" is linked to the rule change history. The system is also divided into sections and formatted according to a four-section structure of "factual reference - rule basis - compliance conclusion - supplementary explanation".

[0090] After processing, the message was sent to Zhang San via WeChat. Upon seeing the reply, Zhang San suddenly understood the necessity of the financial countersignature and gained a clear understanding of the rule change.

[0091] This implementation provides a large-scale model-based information query method. First, it determines the user's target intent based on the user's query request. Then, it employs differentiated information retrieval strategies for two different intents: pre-emptive guidance and post-event retrospective, achieving precise responses to user queries. For pre-emptive guidance queries, the target business parameters are determined as the first query information based on the query request, and matching target approval rules are retrieved from the approval rule base. This quickly provides users with pre-approval conditions for reference, effectively assisting decision-making. For post-event retrospective queries, upstream and downstream information related to the target query request is retrieved from a pre-set knowledge base as the second query information. Combined with rules from the approval rule base, the query results not only contain factual data but also provide reasonable rule-based explanations, meeting users' needs for in-depth traceability of business document compliance. Furthermore, the first or second query information, along with the corresponding target approval rules, is input into a pre-set large-scale model. Utilizing the model's natural language understanding and generation capabilities, a target response result conforming to the user's reading habits is generated, avoiding the tedious process of manually integrating information in traditional methods and significantly improving query efficiency and response quality. Meanwhile, the entire query process requires no manual intervention, achieving an automated closed loop, reducing the company's labor costs, and ensuring the timeliness and consistency of responses, thereby improving the user experience and enhancing the level of intelligence in business management.

[0092] Further reference Figure 7 As an implementation of the methods shown in the above figures, the present invention provides an embodiment of an information query device based on a large model, which is similar to... Figure 2 Corresponding to the method embodiments shown, this device can be specifically applied to various electronic devices.

[0093] like Figure 7As shown, the information query device 700 based on a large model in this embodiment may include: an intent determination unit 701, a first rule determination unit 702, a second rule determination unit 703, a result generation unit 704, and a rule update unit 705. The intent determination unit 701 is configured to: Step 1: Determine the user's target intent based on the target query request initiated by the user, wherein the target intent includes pre-guidance type and post-retrospective type; The first rule determination unit 702 is configured to: Step 2-1: When the target intent is pre-guidance type, use the target business parameters determined based on the target query request as the first query information, and obtain the target decision rule matching the first query information from the decision rule base; The second rule determination unit 703 is configured to: Step 2-2: When the target intent is post-retrospective type, obtain the upstream and downstream information associated with the target query request from a preset knowledge base as the second query information, and obtain the result generation unit 704, and update the result generation unit 705. The system retrieves the target decision rule that matches the second query information from the decision rule base; the result generation unit 704 is configured to step 3: input the first query information / second query information and the corresponding target decision rule into a preset large model, and send the output target response result to the user, wherein the target response result is the result of the large model's rationality analysis of the input data; the rule update unit 705 is configured to update each decision rule contained in the decision rule base through the following steps: encapsulate the target query request, target intent, first query information / second query information, target decision rule and user feedback on the target response result into a question-answer pair and save it in the historical query database; Based on question-answer pairs in the historical query database and pre-defined test rules, a large model is used to generate test cases covering all core decision rules in the core decision rule base. The pre-defined test rules include test case construction rules and conflict resolution guidelines. Test case construction rules guide the construction of multiple types of test cases, including boundary value test cases, semantic variant test cases, and conflict verification test cases. Boundary value test cases test the critical values ​​of various numerical adjustments in the core decision rules. Semantic variant test cases utilize the large model to test whether the core decision rule base can correctly match and output the same core decision conclusion at the semantic level by pre-constructing or automatically generating diverse question formats under the same core decision rule meaning. Conflict verification... The test case is used to test at least two core decision rules with overlapping logic. When the conflict verification test case detects that at least two core decision rules have rule conflicts, the conflict resolution guideline drives the large model to generate a conflict resolution solution. The conflict resolution solution includes at least one of the following: adjusting the priority between conflicting rules, merging conflicting rules, and adding mutual exclusion constraints to conflicting rules. Adjusting the priority between conflicting rules includes: tracing the historical application events of each conflicting rule in the historical query database, and extracting the characteristic factors corresponding to each conflicting rule. The characteristic factors include at least one of the following: the scale of the historical application event, the original and current job level of the rule maker, whether the applicable event is representative, and the randomness.The large model performs weighted scoring on feature factors to determine the theoretical priority of each conflict rule, and then determines the applicable order of the conflict rules according to their theoretical priority. The ranking results of the theoretical priorities and the reasoning basis are pushed to the administrator of the decision rule base. After receiving confirmation feedback, the confirmed priorities are fixed in the attribute fields of the corresponding decision rules in the decision rule base. Test cases are used to test the decision rules in the decision rule base, generating a self-inspection report for each decision rule. Rule update suggestions are generated based on the self-inspection reports, and the decision rules in the decision rule base are updated based on these suggestions.

[0094] In this embodiment, the specific processing and technical effects of the intent determination unit 701, the first rule determination unit 702, the second rule determination unit 703, the result generation unit 704, and the rule update unit 705 in the large model-based information query device 700 can be found in the following references. Figure 2 The relevant descriptions of steps 201-205 in the corresponding embodiments will not be repeated here.

[0095] In some optional implementations of this embodiment, the intent determination unit 701 is further configured as follows: a preprocessing module, configured to preprocess the target query request initiated by the user, wherein the preprocessing includes text cleaning, word segmentation, and removal of stop words; a probability calculation module, configured to input the preprocessed target query request into a large model to obtain the probability values ​​calculated by the large model for the target query request to belong to the pre-guidance category and the post-tracing category respectively; and an intent clarification module, configured to determine the intent category with the high probability value as the user's target intent, and send an intent clarification request to the user when the intent category with the high probability value is lower than a preset confidence threshold.

[0096] In some optional implementations of this embodiment, the first rule determination unit 702 is further configured as follows: a parameter determination module, configured to input the target query request into the large model, obtain the target business parameters output by the large model, and use the target business parameters as the first query information; a first permission determination module, configured to determine the user's permission information based on the user identifier contained in the target query request; and a first rule determination module, configured to obtain the target decision rule that is within the user's permission and matches the first query information from the decision rule base based on the permission information and the first query information.

[0097] In some optional implementations of this embodiment, the second rule determination unit 703 is further configured as follows: an entity determination module, configured to input the target query request into the large model and obtain the key entity information output by the large model; a second permission determination module, configured to determine the user's permission information based on the user identifier contained in the target query request; and an upstream and downstream information determination module, configured to obtain upstream and downstream information related to the target query request that is within the user's permissions from a preset knowledge base based on the permission information and the key entity information, and use the upstream and downstream information as the second query information.

[0098] In some optional implementations of this embodiment, the process of determining the target decision rule from the decision rule base in the first rule determination unit 702 or the second rule determination unit 703 includes: obtaining matching candidate decision rules from the decision rule base according to the first query information or the second query information; filtering the candidate decision rules using preset business conditions including at least one of the following to obtain the target decision rule: a threshold value of the numerical range where the actual amount or estimated amount is located, the department or organizational unit to which the user belongs, the business classification or level, the effective time range of the candidate decision rule, and the current effective status flag of the candidate decision rule.

[0099] In some optional implementations of this embodiment, the result generation unit 704 is further configured as follows: a confidence level labeling module, configured to label the source of each data field in the first query information / second query information and determine the confidence level of each data field; wherein, data fields from a preset knowledge base are labeled as high confidence, and data fields from the target query request are labeled as low confidence; a prompt word generation module, configured to embed the first query information / second query information labeled with confidence level, the corresponding target decision rules, and the preset confidence rules into a preset prompt word template to generate target prompt words; and a response result generation module, configured to input the target prompt words into a large model, obtain the target response result output by the large model, and push the target response result to the user.

[0100] In some optional implementations of this embodiment, the response result generation module in the result generation unit 704 includes: inputting the target prompt words into the large model to obtain the initial response text output by the large model; performing at least one of the following post-processing operations on the initial response text: highlighting key data fields, hyperlinking the approval nodes referenced in the initial response text to the actual approval records, hyperlinking the rule clauses referenced in the initial response text to the original rule text, and formatting the initial response text into segments according to a preset format; and encapsulating the response text obtained after the post-processing operations into the target response result.

[0101] In some optional implementations of this embodiment, the information query device 700 based on the large model further includes: a rule early warning unit, configured to use the large model to determine whether there are missing core decision rules in the core decision rule base; if there are missing core decision rules, generate rule supplement suggestions using the large model, and send the generated rule supplement suggestions to a preset rule base administrator to generate new core decision rules.

[0102] In some optional implementations of this embodiment, the large model in the large model-based information query device 700 is trained through the following steps: obtaining question-answer pairs from the historical query database and determining the quality labels of the question-answer pairs; constructing training samples based on each question-answer pair and its corresponding quality label in the historical query database; and fine-tuning the initial large model using the training samples to obtain a large model for generating the target response result.

[0103] This embodiment exists as a device embodiment corresponding to the above method embodiment. The information query device based on a large model provided in this embodiment first determines the user's target intent based on the target query request initiated by the user, and adopts differentiated information acquisition strategies for two different intents: pre-guidance and post-retrospection, to achieve accurate response to user queries. For pre-guidance queries, the target business parameters are determined as the first query information based on the target query request, and matching target approval rules are obtained from the approval rule base, which can quickly provide users with pre-approval conditions for reference and effectively assist decision-making. For post-retrospection queries, upstream and downstream information related to the target query request is obtained from a preset knowledge base as the second query information, and combined with the rules in the approval rule base, so that the query results not only contain factual data, but also provide reasonable explanations based on rules, meeting users' needs for in-depth traceability of the compliance of business documents. Furthermore, the first or second query information and the corresponding target approval rules are input into a preset large model, and the natural language understanding and generation capabilities of the large model are used to generate target response results that conform to the user's reading habits, avoiding the tedious process of manually integrating information in traditional methods, and significantly improving query efficiency and response quality. Meanwhile, the entire query process requires no manual intervention, achieving an automated closed loop, reducing the company's labor costs, and ensuring the timeliness and consistency of responses, thereby improving the user experience and enhancing the level of intelligence in business management.

[0104] According to embodiments of the present invention, the present invention also provides an electronic device, the electronic device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to implement the large model-based information query method described in any of the above embodiments.

[0105] According to embodiments of the present invention, the present invention also provides a readable storage medium storing computer instructions that enable a computer to implement the large-model-based information query method described in any of the above embodiments when executed.

[0106] According to embodiments of the present invention, the present invention also provides a computer program product, which, when executed by a processor, can implement the information query method based on a large model described in any of the above embodiments.

[0107] Figure 8 A schematic block diagram of an exemplary electronic device 800 that can be used to implement embodiments of the present invention is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0108] like Figure 8 As shown, the electronic device 800 includes a computing unit 801, which can perform various appropriate actions and processes based on a computer program stored in a read-only memory (ROM) 802 or a computer program loaded from a storage unit 808 into a random access memory (RAM) 803. The RAM 803 may also store various programs and data required for the operation of the electronic device 800. The computing unit 801, ROM 802, and RAM 803 are interconnected via a bus 804. An input / output (I / O) interface 805 is also connected to the bus 804.

[0109] Multiple components in electronic device 800 are connected to I / O interface 805, including: input unit 806, such as keyboard, mouse, etc.; output unit 807, such as various types of displays, speakers, etc.; storage unit 808, such as disk, optical disk, etc.; and communication unit 809, such as network card, modem, wireless transceiver, etc. Communication unit 809 allows device 800 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0110] The computing unit 801 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 801 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 801 performs the various methods and processes described above, such as the large-model-based information query method. For example, in some embodiments, the large-model-based information query method can be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 808. In some embodiments, part or all of the computer program can be loaded and / or installed on the electronic device 800 via ROM 802 and / or communication unit 809. When the computer program is loaded into RAM 803 and executed by the computing unit 801, one or more steps of the large-model-based information query method described above can be performed. Alternatively, in other embodiments, the computing unit 801 can be configured to perform the large-model-based information query method by any other suitable means (e.g., by means of firmware).

[0111] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0112] The program code used to implement the methods of the present invention can be written in any combination of one or more programming languages. This program code can be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing device, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code can be executed entirely on the machine, partially on the machine, as a standalone software package partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0113] In the context of this invention, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. Machine-readable media can include, but are not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0114] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0115] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0116] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and Virtual Private Server (VPS) services, such as high management difficulty and weak business scalability.

[0117] According to the technical solution of this invention, the user's target intent is first determined based on the user's target query request. Differentiated information acquisition strategies are adopted for two different intents: pre-guidance and post-retrospection, achieving accurate responses to user queries. For pre-guidance queries, target business parameters are determined as the first query information based on the target query request, and matching target approval rules are obtained from the approval rule base. This quickly provides users with pre-approval condition references, effectively assisting decision-making. For post-retrospection queries, upstream and downstream information related to the target query request is obtained from a preset knowledge base as the second query information. Combined with rules in the approval rule base, the query results not only contain factual data but also provide reasonable rule-based explanations, meeting users' needs for in-depth traceability of business document compliance. Furthermore, the first or second query information, along with the corresponding target approval rules, is input into a preset large model. Utilizing the large model's natural language understanding and generation capabilities, a target response result conforming to the user's reading habits is generated, avoiding the tedious process of manually integrating information in traditional methods and significantly improving query efficiency and response quality. Meanwhile, the entire query process requires no manual intervention, achieving an automated closed loop, reducing the company's labor costs, and ensuring the timeliness and consistency of responses, thereby improving the user experience and enhancing the level of intelligence in business management.

[0118] It should be understood that the various forms of processes shown above can be used to reorder, add, or delete steps. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this invention can be achieved, and this is not limited herein.

[0119] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. An information retrieval method based on a large model, characterized in that, include: Step 1: Determine the user's target intent based on the target query request initiated by the user; Step 2-1: When the target intent is a pre-guidance type, the target business parameters determined based on the target query request are used as the first query information, and the target decision rules that match the first query information are obtained from the preset decision rule library; Step 2-2: When the target intent is a retrospective type, obtain the upstream and downstream information associated with the target query request from the preset knowledge base as the second query information, and obtain the target decision rule that matches the second query information from the decision rule base; Step 3: Input the first query information / second query information and the corresponding target decision rules into a preset large model, and push the output target response result to the user; wherein, the target response result is the reasonableness analysis result of the large model on the input data; The core decision rules in the core decision rule base can be updated through the following steps: The target query request, the target intent, the first query information / second query information, the target core decision rule, and the user's feedback on the target response are encapsulated into question-and-answer pairs and stored in a historical query database. Based on the question-and-answer pairs in the historical query database and preset test rules, test cases covering all core decision rules in the core decision rule base are generated using the large model. The preset test rules include test case construction rules and conflict resolution guidance rules. The test case construction rules guide the construction of multiple types of test cases, including boundary value test cases, semantic variant test cases, and conflict verification test cases. The boundary value test cases test the critical values ​​of various numerical adjustments in the core decision rules. The semantic variant test cases use the large model to test whether the core decision rule base can correctly match and output the same core decision conclusion at the semantic level by pre-constructing or automatically generating diverse questions under the same core decision rule meaning. The conflict verification test cases test at least two logically overlapping core decision rules. When the conflict verification test case detects a rule conflict between at least two core decision rules, it determines whether the conflict resolution rules are correct. The conflict resolution guidelines drive the large model to generate conflict resolution solutions. These solutions include adjusting the priority of conflicting rules, merging conflicting rules, and adding mutual exclusion constraints. Adjusting the priority of conflicting rules involves: tracing the historical application events of each conflicting rule in the historical query database; extracting characteristic factors corresponding to each conflicting rule; these characteristic factors include at least one of the following: the scale of the historical application event, the original and current job levels of the rule-maker, the representativeness of the applicable event, and its randomness; the large model performs a weighted scoring of these characteristic factors to determine the theoretical priority of each conflicting rule, and determines the applicable order of each conflicting rule according to its theoretical priority; the ranking results and reasoning basis of the theoretical priority are pushed to the administrator of the core decision rule library, and upon receiving confirmation feedback, the confirmed priority is fixed in the attribute fields of the corresponding core decision rule in the core decision rule library; the test cases are used to test the core decision rules in the core decision rule library, generating a self-inspection report for each core decision rule; rule update suggestions are generated based on the self-inspection reports, and the core decision rules in the core decision rule library are updated based on these suggestions.

2. The method according to claim 1, characterized in that, Determining the user's target intent based on the user's initiated target query request includes: The user-initiated target query request is preprocessed; wherein, the preprocessing includes text cleaning, word segmentation, and stop word removal; The preprocessed target query request is input into the large model to obtain the probability values ​​calculated by the large model for the target query request to belong to the pre-guidance class and the post-tracing class, respectively. The intent category with a high probability value is identified as the user's target intent, and when the intent category with a high probability value is lower than a preset confidence threshold, an intent clarification request is sent to the user.

3. The method according to claim 1, characterized in that, The step of using the target business parameters determined based on the target query request as the first query information, and obtaining the target decision rules matching the first query information from a preset decision rule base, includes: The target query request is input into the large model to obtain the target business parameters output by the large model, and the target business parameters are used as the first query information; The user's permission information is determined based on the user identifier contained in the target query request; Based on the permission information and the first query information, the target decision rule that is within the user's permissions and matches the first query information is obtained from the decision rule base.

4. The method according to claim 1, characterized in that, The step of retrieving upstream and downstream information associated with the target query request from a preset knowledge base as the second query information includes: Input the target query request into the large model to obtain the key entity information output by the large model; The user's permission information is determined based on the user identifier contained in the target query request; Based on the permission information and the key entity information, upstream and downstream information that is within the user's permissions and associated with the target query request is obtained from the preset knowledge base, and the upstream and downstream information is used as the second query information.

5. The method according to claim 3 or 4, characterized in that, The process of determining the target decision rule from the decision rule base includes: Based on the first query information or the second query information, obtain matching candidate decision rules from the decision rule base; The candidate approval rules are filtered using preset business conditions including at least one of the following to obtain the target approval rule: the threshold value of the actual amount or estimated amount, the department or organizational unit to which the user belongs, the business category or level, the effective time range of the candidate approval rule, and the current effective status flag of the candidate approval rule.

6. The method according to claim 1, characterized in that, The step of inputting the first query information / second query information and the corresponding target decision rules into a preset large model, and pushing the output target response result to the user, includes: Each data field in the first query information / second query information is labeled with its source to determine the confidence level of each data field; wherein, data fields originating from the preset knowledge base are labeled with high confidence, and data fields originating from the target query request are labeled with low confidence. The first / second query information marked with confidence level, the corresponding target decision rules, and the preset confidence rules are embedded into a preset prompt word template to generate target prompt words; The target prompt is input into the large model to obtain the target response result output by the large model, and the target response result is pushed to the user.

7. The method according to claim 6, characterized in that, The process of obtaining the target response result output by the large model includes: Input the target prompt words into the large model to obtain the initial response text output by the large model; The initial response text is subjected to post-processing operations including at least one of the following: highlighting key data fields, hyperlinking the approval nodes referenced in the initial response text to the actual approval records, hyperlinking the rule clauses referenced in the initial response text to the original rule text, and formatting the initial response text into segments according to a preset format. The response text obtained through the post-processing operation is encapsulated into the target response result.

8. The method according to claim 1, characterized in that, The method further includes: The large model is used to determine whether there are missing core decision rules in the core decision rule base; If any of the aforementioned core decision rules are missing, the large model is used to generate rule supplement suggestions, and the generated rule supplement suggestions are sent to the preset rule base administrator to generate new core decision rules.

9. The method according to claim 1, characterized in that, The large model is trained through the following steps: Obtain question-answer pairs from the historical query database and determine the quality labels of the question-answer pairs; Based on each question-answer pair and its corresponding quality label in the historical query database, training samples are constructed; The initial large model is fine-tuned using the training samples to obtain the large model used to generate the target response result.

10. An electronic device, comprising: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the information query method based on a large model as described in any one of claims 1-9.

Images