Business approval method and device, electronic equipment, storage medium and program product

Abstract

The application provides a business approval method and device, electronic equipment, a storage medium and a program product, and belongs to the technical field of data processing. Through subscribing to a database underlying log file and capturing change events, real-time synchronization of an approval process and business data generation is realized. While guaranteeing the timeliness of an approval response, the original business system does not need to be code-level modified, and the access cost and coupling degree of the system are reduced. Through constructing a dual calling request pointing to different model services, and continuously updating the first model service by using the historical data of the second model service, the system can make collaborative decisions by combining the advantages of multiple algorithms, and through multidimensional verification at the data processing level and complementary learning between models, the accuracy and reliability of the automatic approval conclusion are effectively improved.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a business approval method, apparatus, electronic device, storage medium, and program product. Background Technology

[0002] In the process of enterprise information management and digital transformation, approval processes are a core part of business operations, such as purchase requests, expense reimbursements, and contract reviews. Traditional approval methods mainly rely on manual review, where approvers need to verify each document according to business rules and company policies. With the surge in business volume, manual approval has gradually shown problems such as inefficiency, response delays, and inconsistent standards.

[0003] To address the aforementioned issues, existing technologies have begun to incorporate artificial intelligence to assist in approval processes, such as direct integration approval systems. These systems embed interface call logic into the business system code. However, the main drawback of this approach is its strong invasiveness. It requires code-level modifications to existing mature business systems, resulting in high integration costs and potential impacts on the stability of the original system. Summary of the Invention

[0004] This invention provides a business approval method, apparatus, electronic device, storage medium, and program product to address the shortcomings of existing technologies that use direct integration approval systems, which require code-level modifications to existing mature business systems, resulting in high integration costs and potential instability issues. It achieves zero-intrusion access for intelligent approval by constructing dual call requests pointing to different model services and continuously updating the first model service using historical data from the second model service. This enables the system to combine the advantages of multiple algorithms for collaborative decision-making. Through multi-dimensional verification at the data processing level and complementary learning between models, the accuracy and reliability of automated approval conclusions are effectively improved.

[0005] This invention provides a business approval method, comprising the following steps.

[0006] Subscribe to log files in the business database; Based on the log file, the change event corresponding to the first business application is determined, and the first business application is a business application that requires approval; Construct a first call request and a second call request based on the business approval process corresponding to the change event; Based on the first approval result and the second approval result, the application approval conclusion is determined; The first approval result is obtained in response to the first call request by approving the first business application based on the first model service; the second approval result is obtained in response to the second call request by approving the first business application based on the second model service; the first model service is updated according to the approval data corresponding to the historical business applications of the second model service.

[0007] According to a business approval method provided by the present invention, the step of capturing change events corresponding to the first business application based on the log file includes: The log parsing module is invoked to parse the format of the log file and obtain the parsing result, which includes the business type corresponding to the first business application. If the business type corresponding to the first business application is a preset business type, the first business application is matched with business rules in the event service database; If the business rule corresponding to the first business application is matched in the event service database, the parsing result is encapsulated to obtain the change event.

[0008] According to a business approval method provided by the present invention, the step of constructing a first call request and a second call request based on the business approval process corresponding to the change event includes: Match the business approval process corresponding to the change event in the event service database; Obtain a first request template and a second request template, wherein the first request template is the request template corresponding to the first model service, and the second request template is the request template corresponding to the second model service; Based on the first request template and the business approval process corresponding to the change event, a first call request is determined, and based on the second request template and the business approval process corresponding to the change event, a second call request is determined.

[0009] According to a business approval method provided by the present invention, the step of determining the application approval conclusion based on the first approval result and the second approval result includes: Receive the user's first input, which is used to select one of the weighted fusion strategy, the voting fusion strategy, and the priority fusion strategy; In response to the first input, the first approval result and the second approval result are processed according to the fusion strategy selected by the first input to obtain the application approval conclusion.

[0010] According to a business approval method provided by the present invention, when the fusion strategy selected by the first input is a weighted fusion strategy, the step of processing the first approval result and the second approval result to obtain an application approval conclusion includes: Based on the first approval result, a first confidence level is determined to be the approval conclusion, and based on the second approval result, a second confidence level is determined to be the approval conclusion. Obtain the first weight value corresponding to the first model service and the second weight value corresponding to the second model service; Determine the first product of the first weight value and the first confidence level, and determine the second product of the second weight value and the second confidence level; If the sum of the first product value and the second product value is greater than or equal to a preset score threshold, the application approval conclusion is determined to be approved; If the sum of the first product value and the second product value is less than a preset score threshold, the application approval conclusion is determined to be that the approval has not been passed.

[0011] According to a business approval method provided by the present invention, when the fusion strategy selected by the first input is a voting fusion strategy, the step of processing the first approval result and the second approval result to obtain an application approval conclusion includes: Compare the approval conclusion in the first approval result with the approval conclusion in the second approval result; Since the approval conclusion in the first approval result is inconsistent with the approval conclusion in the second approval result, the approval conclusion with higher confidence level shall be taken as the application approval conclusion; Based on the consistency between the approval conclusion in the first approval result and the approval conclusion in the second approval result, the application approval conclusion is determined according to the voting mode of the voting fusion strategy; The voting mode includes either a strict mode or a lenient mode.

[0012] According to a business approval method provided by the present invention, determining the application approval conclusion based on the voting pattern of the voting fusion strategy includes: When the voting mode of the voting fusion strategy is the strict mode, the application approval conclusion is determined to be approved based on the fact that the approval conclusion in the first approval result and the approval conclusion in the second approval result are both approved. When the voting mode of the voting fusion strategy is the lenient mode, and the approval conclusion in the first approval result and / or the approval conclusion in the second approval result is "approved", the application approval conclusion is determined to be "approved".

[0013] According to a business approval method provided by the present invention, when the fusion strategy selected by the first input is a priority fusion strategy, the step of processing the first approval result and the second approval result to obtain an application approval conclusion includes: Determine the confidence level corresponding to the approval conclusion in the first approval result; Based on the confidence level being greater than or equal to the confidence threshold, the approval conclusion in the first approval result is selected as the application approval conclusion; Based on the fact that the confidence level is less than the confidence threshold, the approval conclusion in the second approval result is selected as the application approval conclusion.

[0014] According to a business approval method provided by the present invention, the first approval result is obtained in the following manner: Based on the first call request and the prompt words corresponding to the first call request, determine the approval requirements corresponding to the first business application; If business data is required based on the approval requirements, the business data is invoked using a business data invocation tool from the business data invocation tool list. The first invocation request, the prompt word corresponding to the first invocation request, and the business data are sent to the target large language model to obtain the first approval result output by the target large language model. If it is determined that no business data is needed based on the approval requirements, the first call request and the prompt word corresponding to the first call request are sent to the target large language model to obtain the first approval result output by the target large language model; The target large language model is the inference model used by the first model service.

[0015] According to a business approval method provided by the present invention, the list of business data retrieval tools includes one or more of the following business data retrieval tools: Budget query tool, historical record query tool, and attachment recognition tool.

[0016] The present invention also provides a business approval device, comprising the following modules: The subscription module is used to subscribe to log files in the business database; The capture module is used to determine the change event corresponding to the first business application based on the log file, wherein the first business application is a business application that requires approval; The construction module is used to construct a first call request and a second call request based on the business approval process corresponding to the change event; The processing module is used to determine the application approval conclusion based on the first approval result and the second approval result; The first approval result is obtained in response to the first call request by approving the first business application based on the first model service; the second approval result is obtained in response to the second call request by approving the first business application based on the second model service; the first model service is updated according to the approval data corresponding to the historical business applications of the second model service.

[0017] The present invention also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the business approval method as described above.

[0018] The present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the business approval method as described above.

[0019] The present invention also provides a computer program product, including a computer program that, when executed by a processor, implements the business approval method as described above.

[0020] This invention provides a business approval method, apparatus, electronic device, storage medium, and program product. By subscribing to underlying database log files and capturing change events, it achieves real-time synchronization between the approval process and the generation of business data. While ensuring the timeliness of approval response, it eliminates the need for code-level modifications to the original business system, reducing system access costs and coupling. By constructing dual call requests pointing to different model services and continuously updating the first model service using historical data from the second model service, the system can combine the advantages of multiple algorithms for collaborative decision-making. Through multi-dimensional verification at the data processing level and complementary learning between models, it effectively improves the accuracy and reliability of automated approval conclusions. Attached Figure Description

[0021] To more clearly illustrate the technical solutions in this invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0022] Figure 1 This is one of the flowcharts illustrating the business approval method provided by this invention.

[0023] Figure 2 This is a flowchart illustrating the process of capturing change events corresponding to the first business application based on log files, as provided by the present invention.

[0024] Figure 3This is a flowchart illustrating the process of constructing a first call request and a second call request based on the business approval process corresponding to the change event, as provided by the present invention.

[0025] Figure 4 This is a flowchart illustrating the process of determining the application approval conclusion based on the first approval result and the second approval result, provided by the present invention.

[0026] Figure 5 This is a schematic diagram of business approval based on the business system layer, event processing layer, intent recognition layer, AI approval layer, decision-making layer and result processing layer provided by the present invention.

[0027] Figure 6 The data flow sequence diagram of the business approval method in this invention is shown.

[0028] Figure 7 A schematic diagram showing the deployment topology and dependencies of different modules is provided.

[0029] Figure 8 A flowchart illustrating the approval process in this invention is shown.

[0030] Figure 9 This diagram illustrates how the application approval conclusion is determined based on the first and second approval results in this invention.

[0031] Figure 10 A schematic diagram of the MCP tool invocation process in this invention is shown.

[0032] Figure 11 The diagram illustrates the deployment methods and network connections of the various service components in this invention.

[0033] Figure 12 This is a schematic diagram of the business approval device provided by the present invention.

[0034] Figure 13 This is a schematic diagram of the structure of the electronic device provided by the present invention.

[0035] Figure label: 10: Business System Database; 11: Approval Process Table; 20: Event Subscription Service; 21: Binlog Parsing Module; 30: Rule Engine; 31: Condition Matching Submodule; 32: Data Transformation Submodule; 40: Message Queue; 50: Intent Recognition Service; 51: Route Matching Submodule; 52: Request Construction Submodule; 60: Dify Workflow Platform; 61: Prompt Configuration Module; 62: MCP Tool Configuration Module; 63: LLM Processing Node; 70: MCP Tool Service; 71: Budget Query Tools; 72: Supplier query tool; 73: Historical record query tool; 74: Attachment identification tool; 80: Business system API; 90: Small model approval service; 91: Feature extraction submodule; 92: Model prediction submodule; 100: Approval decision service; 110: Final approval result; 1201: Subscription module; 1202: Capture module; 1203: Construction module; 1204: Processing module; 1310: Processor; 1320: Communication interface; 1330: Memory; 1340: Communication bus. Detailed Implementation

[0036] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0037] The following is an explanation of the terms used in this application.

[0038] 1. Artificial Intelligence (AI).

[0039] 2. Large Language Model (LLM) refers to a deep learning model with a huge number of parameters that has been trained on a large number of texts.

[0040] 3. Binary Log (binlog): A log file in MySQL / MariaDB databases that records all data change operations.

[0041] 4. Model Context Protocol (MCP): A protocol that allows large language models to dynamically call external tools during execution.

[0042] 5. Dify, an open-source platform for developing large language model applications, provides visual workflow orchestration capabilities.

[0043] 6. RocketMQ, an open-source distributed message queue middleware from the Apache Software Foundation.

[0044] 7. Application Programming Interface (API).

[0045] 8. Robotic Process Automation (RPA) uses software robots to simulate human operations.

[0046] 9. Prompt: A textual description used to guide the large language model in generating the expected output.

[0047] 10. Topic: The message topic in the message queue, the first-level classification of messages.

[0048] 11. Tag: A message tag in a message queue, representing the second-level classification of a message.

[0049] 12. INSERT: The insert operation in SQL, which adds a new record to a database table.

[0050] 13. UPDATE: The update operation in SQL, which modifies existing records in a database table.

[0051] 14. DELETE: The delete operation in SQL, which removes records from a database table.

[0052] 15. JSON (JavaScript Object Notation): JavaScript object notation, a lightweight data interchange format.

[0053] 16. JWT (JSON Web Token): JSON Web Token, an open standard for authentication.

[0054] 17. RBAC (Role-Based Access Control): Role-based access control.

[0055] 18. FastAPI: A modern, high-performance Python web framework.

[0056] 19. Vue, a progressive JavaScript framework for building user interfaces.

[0057] 20. Object-Relational Mapping (ORM) is a technique that maps database tables to program objects.

[0058] 21. Docker: An open-source containerization platform for packaging, distributing, and running applications.

[0059] 22. Kafka (Apache Kafka): An open-source distributed stream processing platform from the Apache Software Foundation.

[0060] 23. RabbitMQ: An open-source message broker software that supports multiple message protocols.

[0061] 24. Extreme Gradient Boosting (XGBoost) is an efficient gradient boosting tree algorithm.

[0062] 25. Lightweight Gradient Boosting Machine (LightGBM) is an open-source gradient boosting framework from Microsoft.

[0063] 26. Random Forest is an ensemble learning algorithm that makes predictions by voting among multiple decision trees.

[0064] 27. Feature Engineering: The process of extracting, transforming, and selecting features from raw data.

[0065] 28. Confidence: The degree of confidence the model has in the predicted results, with a value range of [0,1].

[0066] 29. AUC (Area Under Curve): The area under the ROC curve, a metric for measuring the performance of a binary classification model.

[0067] 30. F1-Score: The harmonic mean of precision and recall, a metric for comprehensively evaluating model performance.

[0068] 31. Semantic Understanding: The ability of AI models to understand and interpret the meaning of natural language.

[0069] 32. Zero-invasion: This refers to the ability to extend functionality without modifying existing system code.

[0070] The business approval method provided in this invention can be executed by an electronic device with computing, storage, and network communication capabilities. This electronic device can be an independent business approval server, a distributed server cluster, or an AI-powered approval platform deployed in the cloud. In real-world enterprise applications, this execution entity is typically deployed as an independent middleware system, establishing communication connections with existing business system databases and various model services via the network, thereby providing automated approval capabilities without interfering with the normal operation of the original business system.

[0071] The following is combined Figures 1 to 13 This invention describes the business approval method, apparatus, electronic device, storage medium, and program product.

[0072] Figure 1 This is one of the flowcharts illustrating the business approval method provided by this invention, such as... Figure 1 As shown, the method includes the following: Step 101: Subscribe to the log files in the business database.

[0073] In this context, subscription refers to the executor establishing a long-lived connection with the business database through a specific communication protocol, receiving data change records generated by the database in real time, rather than passively waiting for proactive pushes from the business system. Log files are binary log files used at the database's underlying layer to record all data definition and data operation changes; for example, in MySQL or MariaDB databases, this is represented as a binlog file, while in other types of databases it may be represented as a redo log or logical decoding log. Specifically, the executor can simulate a slave node of the business database, using the database replication protocol to initiate log retrieval requests to the master database. Through this underlying log subscription method, the executor can perceive subtle changes at the database level in real time without modifying the application layer code of the business system, thus achieving zero-intrusion access to the business system.

[0074] Step 102: Determine the change event corresponding to the first business application based on the log file. The first business application is a business application that requires approval.

[0075] In some embodiments, a first business application refers to various business requests submitted by a user at the business front end that require approval processing, such as purchase requisition forms, expense reports, or contract review forms. A change event refers to an insert or update operation that occurs in the database on the corresponding data row due to the submission or status update of a business application.

[0076] Specifically, after receiving streaming log data, the executing entity scans and identifies the log stream in real time, filtering out changes to specific tables or fields related to the approval process. For example, when the business system writes a new record to the approval process table, the executing entity captures the insertion operation and encapsulates it into an event object containing the application number, application type, and original data. This step ensures that the approval process can be driven by data changes in real time, eliminating the delay caused by manual triggering.

[0077] In some embodiments, the business applications requiring approval are not limited to procurement approval, but may also include expense reimbursement approval, leave approval, contract approval, recruitment approval, or project initiation approval.

[0078] Specifically, in expense reimbursement approval, the reimbursement amount, reimbursement category, and authenticity of invoices are determined; in leave approval, the number of leave days, remaining leave days, and work arrangements are determined; in contract approval, the contract amount, contract terms, and partner qualifications are determined; in recruitment approval, recruitment needs, salary budget, and job positions are determined; and in project initiation approval, the project budget, resource requirements, and risk assessment are determined.

[0079] Step 103: Construct the first call request and the second call request based on the business approval process corresponding to the change event.

[0080] In this step, the executing entity first identifies the specific business approval process to which the application belongs based on the characteristic information in the captured change event, such as the process type identifier. Then, two independent request objects are constructed in parallel or sequentially for this process. The first request is a request instruction generated for the first model service, containing semantic features or structured data required for approval; the second request is a request instruction generated for the second model service.

[0081] It is worth noting that the first model service and the second model service differ in their approval logic or judgment dimensions. Specifically, the first model service updates itself based on the approval data corresponding to historical business applications from the second model service. This means that the first model service is evolving and learning-oriented; it can absorb the judgment experience or patterns accumulated by the second model service in past approval cases, thereby continuously optimizing its own approval strategy. By constructing dual-invocation requests, the system can simultaneously evaluate the same business application from different dimensions (such as semantic reasoning and feature statistics), providing diversified references for subsequent comprehensive decision-making.

[0082] Step 104: Determine the application approval conclusion based on the first approval result and the second approval result; the first approval result is obtained after responding to the first call request and approving the first business application based on the first model service; the second approval result is obtained after responding to the second call request and approving the first business application based on the second model service; the first model service is updated according to the approval data corresponding to the historical business applications of the second model service.

[0083] In this embodiment, by subscribing to the underlying log files of the database and capturing change events, real-time synchronization between the approval process and the generation of business data is achieved. While ensuring the timeliness of the approval response, no code-level modification of the original business system is required, reducing the system's access cost and coupling. By constructing dual call requests pointing to different model services and using historical data from the second model service to continuously update the first model service, the system can combine the advantages of multiple algorithms to make collaborative decisions. Through multi-dimensional verification at the data processing level and complementary learning between models, the accuracy and reliability of automated approval conclusions are effectively improved.

[0084] In some embodiments, such as Figure 2 As shown, the change events corresponding to the first service application are captured based on the log file, including: Step 201: Call the log parsing module to parse the log file format and obtain the parsing result, which includes the business type corresponding to the first business application.

[0085] In some embodiments, the log parsing module is a core component built into the execution entity, specifically responsible for converting the binary data streams generated at the database level (such as row-based format data of binlog) that are difficult to read directly into structured, machine-readable data. Specifically, the parsing module identifies operation identifiers in the log files and extracts the database names, table names, and specific column change information involved in the changes. The resulting parsing result is a set of structured data containing business dimensions, including at least the business type corresponding to the first business application. The business type characterizes the business scope to which the application belongs, such as Purchase, Expense, or Contract. Furthermore, the parsing result typically also includes the business application number (used to uniquely identify the application document) and the submission status of the first business application (such as submitted, pending approval, or status code 1). Through parsing, the originally discrete database logs are restored to data with clear business meaning.

[0086] Step 202: If the business type corresponding to the first business application is a preset business type, perform business rule matching on the first business application in the event service database.

[0087] Among them, the preset business types refer to specific business categories that need to be introduced into the intelligent approval system and are pre-configured by administrators. After obtaining the parsed business types, the executing entity first performs an initial screening, and only businesses that fall within the preset scope will trigger subsequent logic.

[0088] The event service database is a metadata database specifically designed to store approval rules, routing logic, and configuration information. In this step, business rule matching refers to the execution entity comparing the parsed business data with the refined trigger rules stored in the database. Business rules can include field-level filtering conditions, such as matching whether the approval status field has changed from draft to submitted, or matching whether the application amount field meets a specific trigger threshold. This matching method can accurately eliminate irrelevant and interfering information from massive database changes, such as updates that only modify remarks but do not change the approval status, ensuring that only events that truly require initiating the approval process proceed to subsequent stages.

[0089] Step 203: If the business rule corresponding to the first business application is matched in the event service database, the parsing result is encapsulated to obtain the change event.

[0090] When the data characteristics of the first business application fully conform to the preset business rules, the executing entity will structurally reorganize the parsed original field information, the relevant metadata (such as occurrence time and operation type), and the matched rule identifiers. Encapsulation refers to packaging these scattered data into a standard change event object according to a predetermined message format (such as JSON format).

[0091] In this embodiment, by introducing a dedicated log parsing module and a rule matching mechanism in the event service database, progressive filtering and refined identification are achieved from massive underlying database change logs to precise business approval events. This feature, in conjunction with the log subscription function, effectively filters irrelevant non-approval data at the data source through business type filtering and fine-grained rule matching. Events are encapsulated only for specific change behaviors that conform to preset approval logic. This significantly reduces the invalid load on downstream model processing while ensuring real-time approval triggering, thereby improving the accuracy and processing efficiency of the entire approval chain.

[0092] In some embodiments, such as Figure 3 As shown, the first and second call requests are constructed based on the business approval process corresponding to the change event, including: Step 301: Match the business approval process corresponding to the change event in the event service database.

[0093] In some embodiments, the event service database is pre-configured with a configuration database that stores the mapping relationship between business table information and logical processes. Matching refers to the execution entity extracting key feature identifiers (such as database name, table name, or the process type field "flowType" in the data row) from the captured change events, and using these as index keys to retrieve them in the routing configuration table of the event service database.

[0094] In some embodiments, the matching methods may include: direct key-value matching (i.e., tables with identical names), regular expression fuzzy matching (i.e., tables conforming to specific naming rules all correspond to the same process), and priority-based multi-condition composite matching. For example, if a change event originates from the "proc_purchase_t" table, the executing entity determines that the event belongs to the procurement approval process by searching the event service database. This step achieves accurate positioning from physical layer data changes to business layer logical processes, ensuring the targeted nature of subsequent processing.

[0095] Step 302: Obtain the first request template and the second request template. The first request template is the request template corresponding to the first model service, and the second request template is the request template corresponding to the second model service.

[0096] The first request template and the second request template are predefined data format specifications in the system, used to specify the request packet structure sent to different model services.

[0097] The first request template typically includes a configuration protocol, input variable placeholders, and output format definitions for the first model service; the second request template includes a feature vector structure or a list of specific fields for the second model service. The executing entity dynamically retrieves the two corresponding templates from the configuration library based on the specific business approval process matched in the previous step. This template-based management approach allows the system to update only the template configuration in the database when adding new approval processes or changing backend models, without modifying the underlying logic code.

[0098] Step 303: Based on the first request template and the business approval process corresponding to the change event, determine the first call request, and based on the second request template and the business approval process corresponding to the change event, determine the second call request.

[0099] Specifically, the executing entity extracts business characteristic values ​​(such as applicant ID, application amount, business reason, supplier information, etc.) from the original data of the change event, and injects these characteristic values ​​into the placeholders corresponding to the first request template and the second request template according to the mapping rules specified in the matched business approval process, thereby forming the first call request and the second call request.

[0100] For example, in the procurement process, the executing entity fills in the amount of 50,000 into the amount variable of the first request template to generate a first call request in JSON format for the first model service; at the same time, it fills in the same amount and the applicant's historical credit score and other characteristics into the second request template to generate a second call request for the second model service.

[0101] In this embodiment, by introducing an event service database for process matching and dynamically constructing call requests using preset request templates, decoupling and automatic transformation between changes in underlying raw data and inputs to high-level business models are achieved. During data processing, a template mapping mechanism ensures that data sent to different model services maintains consistency in business logic while meeting the personalized input format requirements of different algorithm models. This template-based construction method not only greatly improves the system's flexibility in adapting to different business processes but also effectively reduces the parameter error rate during model calls through standardized data extraction and encapsulation processes, providing a high-quality data foundation for subsequent multi-model collaborative approval.

[0102] In some embodiments, such as Figure 4 As shown, based on the first and second approval results, the application approval conclusion is determined, including: Step 401: Receive the user's first input, which is used to select one of the weighted fusion strategy, voting fusion strategy, and priority fusion strategy.

[0103] In some embodiments, the first input refers to configuration instructions or selection signals entered by administrators or business configuration personnel of the approval system through a front-end interactive interface. This input aims to pre-define a set of decision-making criteria within the system based on the risk level, compliance requirements, and level of trust in the model's capabilities for the current approval process. Specifically, the first input is used to switch between multiple preset decision logics, including but not limited to weighted fusion strategies, voting fusion strategies, and priority fusion strategies. In terms of acquisition method, the executing entity can provide a visual configuration backend. After the user clicks the corresponding strategy option and confirms submission, the executing entity parses the interaction request and converts it into a policy control signal recognizable within the system. This method of determining the fusion strategy through user intervention enables the approval system to flexibly adapt to the management needs of different enterprises, departments, and even different periods.

[0104] Step 402: In response to the first input, process the first approval result and the second approval result according to the fusion strategy selected by the first input to obtain the application approval conclusion.

[0105] In this embodiment, by introducing user input to actively select the fusion strategy, the system establishes a configurable and operable decision-making central logic. This data processing mechanism, through establishing dynamic switching paths between multiple fusion strategy branches, enables the approval system to adjust the interaction logic of the output data of the first and second model services in real time according to the risk preferences of the business scenario (such as a greater emphasis on rigor or flexibility). During processing, this multi-strategy selection mechanism transforms the originally static model prediction results into dynamic, business-logical comprehensive judgments, thereby enhancing the system's adaptability and decision redundancy in the face of complex approval environments, ultimately achieving a balance between approval accuracy and business flexibility under different management needs.

[0106] In some embodiments, when the fusion strategy selected for the first input is a weighted fusion strategy, the first approval result and the second approval result are processed to obtain the application approval conclusion, including: determining a first confidence level for approval based on the first approval result, and determining a second confidence level for approval based on the second approval result; obtaining a first weight value corresponding to the first model service and a second weight value corresponding to the second model service; determining a first product value of the first weight value and the first confidence level, and determining a second product value of the second weight value and the second confidence level; determining the application approval conclusion as approved if the sum of the first product value and the second product value is greater than or equal to a preset score threshold; and determining the application approval conclusion as unapproved if the sum of the first product value and the second product value is less than the preset score threshold.

[0107] Here, confidence level refers to the degree of certainty the model service has about the approval tendency of its output, typically represented by a real number between 0 and 1. In this step, the executing entity extracts probability scores from the first approval result (output by the large language model) and the second approval result (output by the small model service). It should be noted that if the original conclusion output by the model service is disapproval, the executing entity will convert it into a probability corresponding to the approval dimension. For example, if the first model service considers the application disapproval with a confidence level of 0.8, then its corresponding first confidence level (probability of approval) is recorded as 0.2. By unifying the outputs of different models into probability values ​​pointing to the single dimension of approval, a unified data foundation is laid for subsequent cross-model mathematical calculations.

[0108] The weight values ​​represent the system's preference for different model service decision-making authority. The executing entity can extract these values ​​from a pre-defined configuration file or database. In practice, the sum of the first and second weight values ​​is typically 1. For example, if a company believes that the large language model is more reliable in semantic understanding and comprehensive judgment, it can set the first weight value to 0.6 and the second weight value to 0.4. This weighting allows companies to flexibly adjust the focus of approvals based on the actual nature of their business (such as whether they prioritize rule compliance or consistency with historical experience).

[0109] In some embodiments, the preset score threshold is 0.5, or other values, the specific values ​​of which will not be elaborated here.

[0110] For example, suppose a procurement application has a first confidence level (probability of approval in the large model) of 0.9 and a corresponding first weight value of 0.6; a second confidence level (probability of approval in the small model) of 0.3 (i.e., the small model tends to reject), and a corresponding second weight value of 0.4. The executing entity calculates the first product value as 0.9 × 0.6 = 0.54 and the second product value as 0.3 × 0.4 = 0.12. The sum of the two is 0.66. If the preset score threshold is 0.5, since 0.66 > 0.5, the executing entity ultimately determines the application approval conclusion as approved.

[0111] In this embodiment, by introducing a weighted fusion mechanism, the approval confidence of different algorithm dimensions can be transformed into quantifiable contribution values, and the dynamic balance of the advantages of different models can be achieved by using weight configuration. Under this data processing flow, the bias or extreme judgment of a single model can be corrected by the robust output and weight allocation of another model, thereby significantly improving the fault tolerance rate and the rationality of the final conclusion in complex business scenarios through multi-dimensional probabilistic coupling.

[0112] In some embodiments, when the fusion strategy selected for the first input is a voting fusion strategy, the first approval result and the second approval result are processed to obtain the application approval conclusion, including: comparing the approval conclusion in the first approval result with the approval conclusion in the second approval result; based on the inconsistency between the approval conclusion in the first approval result and the approval conclusion in the second approval result, taking the approval conclusion with higher confidence as the application approval conclusion; based on the consistency between the approval conclusion in the first approval result and the approval conclusion in the second approval result, determining the application approval conclusion according to the voting mode of the voting fusion strategy; wherein, the voting mode includes a strict mode or a lenient mode.

[0113] The approval conclusion refers to the final judgment opinion given by the first model service or the second model service for the first business application. It is usually in the form of a boolean value (such as True for approval and False for rejection) or an enumeration value (such as Approve or Reject).

[0114] In this embodiment, when the executing entity identifies a conflict between the approval conclusions of two models—for example, the first model concludes approval while the second model concludes disapproval—it does not simply use the average or manual intervention. Instead, it introduces a confidence level competition mechanism. Specifically, the executing entity extracts the first confidence level corresponding to the first approval result and the second confidence level corresponding to the second approval result, and compares their values. The executing entity automatically accepts the conclusion of the model with the higher confidence level. For example, if the first model indicates approval with a confidence level of 0.95, while the second model indicates disapproval with a confidence level of 0.70, the executing entity determines that the first model's judgment is more valuable, thus determining approval as the final application approval conclusion. This approach enables the model's self-evaluation mechanism to select the best option when models disagree, reducing the risk of misjudgment.

[0115] When two models reach identical approval conclusions, it doesn't mean the conclusion will be directly output. The implementing entity needs to further confirm this by introducing a voting mode. The voting mode is a set of pre-set decision-making criteria designed to adjust the strictness of the approval process based on different business risk preferences. The voting mode includes a strict mode and a lenient mode. Specifically, the implementing entity reads system configuration parameters or real-time user instructions to determine the appropriate mode for the current business application. Provided the conclusions are consistent, mode filtering allows for deeper risk control or efficiency optimization of the approval results.

[0116] In this embodiment, by comparing the consistency of approval conclusions from different sources and competitively selecting based on the confidence level of the model output, intelligent optimization based on data certainty is achieved in scenarios of model divergence, effectively reducing decision-making errors caused by occasional biases of a single model. At the same time, by introducing a voting mechanism that includes strict and lenient modes, the system can perform secondary logical filtering on consistent conclusions according to preset business risk levels during data processing, ultimately achieving a flexible balance between approval accuracy and efficiency in different business scenarios.

[0117] In some embodiments, determining the application approval conclusion based on the voting mode of the voting fusion strategy includes: when the voting mode of the voting fusion strategy is a strict mode, determining the application approval conclusion as approved based on the fact that the approval conclusion in the first approval result and the approval conclusion in the second approval result are both approved; when the voting mode of the voting fusion strategy is a lenient mode, determining the application approval conclusion as approved if the approval conclusion in the first approval result and / or the approval conclusion in the second approval result are both approved.

[0118] In this embodiment, the strict mode refers to a data filtering logic based on unanimous approval, designed to minimize approval risks. In this mode, the executing entity performs a logical AND operation on the two received parallel data streams: the first approval result and the second approval result. Specifically, the executing entity will only output an approval decision in the final application approval conclusion if both the first and second approval results are explicitly marked as approved.

[0119] The lenient mode refers to a fault-tolerant triggering logic based on any approval system, designed to improve the efficiency of low-risk business processes. In this mode, the executing entity performs a logical OR operation on the two approval results. As long as at least one of the first and second approval results indicates approval, the executing entity can determine that the business application meets the approval conditions and output a conclusion.

[0120] In this embodiment, differentiated control over the approval data flow is achieved by introducing a binary differentiation processing logic of strict and lenient modes into the voting fusion strategy. The strict mode ensures that high-value, high-risk businesses must undergo cross-validation by dual algorithms at the data processing level through multi-dimensional logical consistency constraints, greatly enhancing the security of automated approval. The lenient mode, on the other hand, utilizes the complementary fault tolerance between algorithms to ensure that routine businesses can be quickly released when either model service gives a positive judgment, improving the system's automation coverage and flow efficiency in handling massive amounts of low-risk businesses. This allows the entire approval method to flexibly adapt to the business governance needs of different risk levels within the enterprise.

[0121] In some embodiments, when the fusion strategy selected for the first input is a priority fusion strategy, the first approval result and the second approval result are processed to obtain the application approval conclusion, including: determining the confidence level corresponding to the approval conclusion in the first approval result; selecting the approval conclusion in the first approval result as the application approval conclusion based on the confidence level being greater than or equal to the confidence level threshold; and selecting the approval conclusion in the second approval result as the application approval conclusion based on the confidence level being less than the confidence level threshold.

[0122] In some embodiments, the confidence threshold is an empirical value preset in the system configuration, such as 0.8 or 0.9, and its specific value will not be elaborated here.

[0123] In this embodiment, a dynamic decision-making routing mechanism is achieved by introducing a priority fusion strategy and combining it with a confidence threshold to select branches from approval results from different sources. This mechanism, through flexible allocation of data processing weights, allows the system to leverage its intelligent understanding capabilities to improve approval quality when the first model service (large model) possesses high determinism, and automatically utilizes the stability of the second model service (small model) to fill the gap when the first model service exhibits uncertainty. This complementary cooperation based on confidence effectively reduces the impact of potential misjudgment risks or performance fluctuations of a single model on the approval conclusions, ensuring that the system can output highly reliable and consistent automated approval conclusions under various complex business scenarios.

[0124] In some embodiments, the first approval result is obtained in the following manner: based on the first call request and the prompt word corresponding to the first call request, the approval requirement corresponding to the first business application is determined; if business data is required based on the approval requirement, the business data call tool in the business data call tool list is called to call the business data, and the first call request, the prompt word corresponding to the first call request, and the business data are sent to the target large language model to obtain the first approval result output by the target large language model; if business data is not required based on the approval requirement, the first call request and the prompt word corresponding to the first call request are sent to the target large language model to obtain the first approval result output by the target large language model; wherein, the target large language model is the inference model used by the first model service.

[0125] In some embodiments, when the target large language model identifies that the current approval requirement (such as budget verification) cannot be determined based solely on the existing data in the first call request, it is determined that business data is required. At this time, the executing entity accesses a pre-defined list of business data call tools, which encapsulates a series of standard interface tools based on the model context protocol. The executing entity automatically selects and calls the corresponding business data call tool according to the type of approval requirement.

[0126] Specifically, the business data retrieval tool initiates queries to external business systems or auxiliary databases based on parameters generated by the model (such as department ID or supplier name), and retrieves relevant real-time business information to obtain business data.

[0127] In this embodiment, by introducing a prompt-driven approval requirements analysis mechanism, the system can simulate the thinking of human experts, automatically identifying and breaking down complex approval logic. Simultaneously, by establishing a list of business data retrieval tools and coordinating with dynamic data requests from the target large language model, real-time, on-demand completion of key external information during the approval process is achieved. This data processing approach not only solves the information gap problem existing in specific business domains within the large language model but also significantly enhances the comprehensiveness, accuracy, and adaptability to complex business scenarios by deeply integrating static data, dynamic data, and semantic reasoning logic within the target large language model.

[0128] In some embodiments, the list of business data retrieval tools includes one or more of the following: budget query tool, historical record query tool, and attachment identification tool.

[0129] like Figure 5 As shown, the business approval method proposed in this invention is described using a business system layer, an event processing layer, an intent recognition layer, an AI approval layer, a decision-making layer, and a result processing layer.

[0130] The following are Figure 5 The function of each module is explained below: Business system database 10 refers to the company's existing business system database, which uses MariaDB or MySQL database to store business data and approval process data.

[0131] In some embodiments, the business system database 10 may also be PostgreSQL, Oracle, SQL Server, or MongoDB.

[0132] Specifically, for PostgreSQL, the Logical Decoding plugin is used to capture change events, and the logical logs are parsed using pgoutput or wal2json; for Oracle, LogMiner or GoldenGate is used to capture database changes and parse the Redo Log; for SQL Server, the Change Data Capture or Change Tracking features are used to capture change events; and for MongoDB, Change Streams is used to monitor collection change events in real time.

[0133] Approval Process Table 11 is an approval process data table in the business system database, containing complete information about the approval documents.

[0134] Event subscription service 20, also known as binlog subscription service component, monitors change events in the business system database in real time.

[0135] binlog parsing module 21, the binlog parsing submodule in the event subscription service, is responsible for parsing binlog binary logs.

[0136] The rules engine 30 is an event filtering and data processing engine responsible for performing condition matching, data transformation, and message encapsulation on captured events.

[0137] Conditional matching submodule 31 is a conditional matching submodule in the rule engine that supports a variety of operators and logical combinations.

[0138] Data transformation submodule 32, the data transformation submodule in the rules engine, is responsible for field mapping, value transformation and formatting.

[0139] Message queue 40, namely the Apache RocketMQ message queue, is responsible for reliable event transmission and asynchronous decoupling.

[0140] In some embodiments, the message queue is not limited to RocketMQ, but can also be other message middleware such as Apache Kafka, RabbitMQ, Apache Pulsar, or Redis Stream.

[0141] Among them, Apache Kafka is a high-throughput distributed message queue, suitable for large-scale data processing scenarios; RabbitMQ supports multiple message protocols, suitable for complex routing scenarios; Apache Pulsar supports multi-tenancy and persistent storage, suitable for cloud-native scenarios; and Redis Stream is a lightweight message queue, suitable for small-scale rapid deployment scenarios.

[0142] Intent recognition service 50 is used for event intent recognition and routing services, consuming events from the message queue and identifying approval process types.

[0143] The route matching submodule 51, which is the route matching submodule in the intent recognition service, matches the corresponding approval process based on the conditions.

[0144] The request construction submodule 52, which is the request construction submodule in the intent recognition service, applies the request template and generates an API call request.

[0145] Dify Workflow Platform 60 is a platform that provides first-model services, such as the Large Language Model Workflow Platform, which offers visual workflow orchestration and LLM invocation capabilities.

[0146] In some embodiments, the platform providing the first model service may be, in addition to the Dify workflow platform 60, LangChain, a self-developed workflow engine, other LLM platforms, or direct LLM API calls.

[0147] Specifically, LangChain is an open-source LLM application development framework that supports the integration of multiple models and tools; its self-developed workflow engine can be based on the LLM API to develop a workflow orchestration system, which is more flexible; other LLM platforms, such as FlowiseAI, n8n and other low-code LLM workflow platforms; and direct LLM API calls.

[0148] The prompt word configuration module 61, which is the prompt word configuration module in the Dify platform, configures dedicated natural language prompt words for each approval process.

[0149] MCP tool configuration module 62, also known as the MCP tool configuration module in the Dify platform, defines the list of available business data acquisition tools. It includes the business type (product activation), business order number, and submission status. LLM processing node 63, namely the large language model processing node in the Dify workflow, executes the approval judgment logic.

[0150] MCP Tool Service 70, also known as Business Data Acquisition Tool Service, encapsulates business system API calls and provides standardized MCP interfaces.

[0151] In some embodiments, the MCP tool service 70 is not limited to business data querying, but can be extended to one or more of the following: external system integration, knowledge base querying, calculation tools, notification tools, and workflow triggering.

[0152] Specifically, external system integration is used to call third-party APIs, such as credit information inquiries and business registration information inquiries; knowledge base queries are used to call the enterprise knowledge base to obtain policy documents, rules and regulations, etc.; calculation tools are used to perform complex calculations, such as interest calculations and tax calculations; notification tools are used to send notifications via email, SMS, WeChat, etc.; and workflow triggering is used to trigger other business processes or approval processes.

[0153] Budget Query Tool 71, also known as the Budget Query Tool in the MCP tool service, is used to obtain departmental budget information.

[0154] Supplier Query Tool 72, also known as the Supplier Query Tool in the MCP tool service, allows you to obtain supplier qualification information.

[0155] Historical record query tool 73, also known as the historical record query tool in the MCP tool service, retrieves historical approval records.

[0156] Attachment recognition tool 74, also known as the attachment recognition tool in the MCP tool service, uses a visual model to identify the authenticity and content of attachments.

[0157] In some embodiments, the visual model can identify the authenticity and content of attachments by performing document recognition, facial recognition, seal recognition, or form recognition. Specifically, facial recognition is used to verify whether the ID photo matches the applicant; seal recognition is used to verify the authenticity of seals on contracts and certificates; and form recognition is used to identify tabular documents such as invoices and reports.

[0158] In some embodiments, the visual model can use a multimodal large model to understand both images and text simultaneously.

[0159] Business System API 80 is the data query API interface provided by the business system for the MCP tool service to call.

[0160] Small model approval service 90, also known as second model service, such as a dedicated approval model service based on machine learning algorithms, is trained using historical approval data.

[0161] Feature extraction submodule 91, which is the feature extraction submodule in the small model service, extracts features such as amount, applicant, and supplier from the approval data.

[0162] Model prediction submodule 92, which is the model prediction submodule in the small model service, outputs the approval conclusion and confidence level based on the extracted features.

[0163] Approval Decision Service 100, also known as the Decision Fusion Service, integrates the approval results of the large model (i.e., the first model service in this invention) and the small model (i.e., the second model service in this invention) to output the final conclusion. Weighted Fusion Submodule: The weighted fusion submodule in the approval decision service calculates a weighted score based on confidence level. Voting Fusion Submodule: The voting fusion submodule in the approval decision service employs a majority-decision strategy.

[0164] The final approval result 110 is the final approval conclusion output by the approval decision service, including whether it is approved or not, and the reasons for approval.

[0165] Specifically, the event subscription service 20 uses Python's pymysqlreplication library to connect to the MySQL / MariaDB master database as a slave and receive binlog event streams in real time. It supports the following configurations: database instance information: host, port, username, password; monitoring scope: specified database, specified table; event type filtering: INSERT, UPDATE, DELETE; server ID: to avoid conflicts with other slaves; heartbeat interval: to keep the connection active.

[0166] Among them, the binlog parsing module 21 is responsible for parsing the binary log and extracting the following information: (1) Event types: INSERT, UPDATE, DELETE; (2) The databases and table names involved; (3) Data row content before and after the change; (4) Event timestamp.

[0167] Its workflow is as follows: (1) Initialization phase: Read the database instance configuration (host, port, username, password); create a BinLogStreamReader stream object; configure the event types and data range to be monitored.

[0168] (2) Runtime phase: read binlog event stream in a loop; parse event type and data content; construct event data object in standard format; pass event data to rule engine 30.

[0169] (3) Abnormal handling: detect disconnection and reconnect automatically; record the processed binlog position and resume interrupted transmission; record abnormal event logs and alarms.

[0170] The Event Subscription Service 20 features millisecond-level event capture latency without requiring modification to the business system code. It also supports breakpoint resume to avoid event loss and allows for flexible configuration of monitoring scope and event types.

[0171] Specifically, the rules engine 30 contains two core sub-modules: condition matching sub-module 31 and data transformation sub-module 32.

[0172] The condition matching submodule 31 supports the following operators: (1) equal to (eq), that is, the field value is equal to the specified value; (2) Not equal to (ne), that is, the field value is not equal to the specified value; (3) Greater than (gt), that is, the field value is greater than the specified value; (4) Greater than or equal to (gte), that is, the field value is greater than or equal to the specified value; (5) Less than (lt), meaning the field value is less than the specified value; (6) Less than or equal to (lte), meaning the field value is less than or equal to the specified value; (7) Like, meaning the field value contains the specified string; (8) IN condition (in), that is, the field value is in the specified list; (9) Interval judgment (between), that is, the field value is within the specified interval.

[0173] Meanwhile, the logical combinations supported by the condition matching submodule 31 include: (1) AND, meaning all conditions are met; (2) OR, meaning either condition is satisfied; (3) NOT, which means negating the condition.

[0174] Data conversion submodule 32 supports the following functions: (1) Field selection, that is, selecting the required fields from the event data.

[0175] (2) Field renaming, which maps the source field to the target field name.

[0176] (3) Field value conversion, that is, formatting and type conversion of field values.

[0177] (4) Custom functions, i.e., support the registration of custom conversion functions.

[0178] Specifically, the workflow of Rule Engine 30 includes: (1) Rule loading, such as loading all enabled subscription rules from the database and sorting them by priority.

[0179] (2) Event matching, that is, traversing all rules and checking whether the event type matches; calling the condition matching submodule 31 to determine whether the field conditions are met; if the conditions are met, calling the data conversion submodule 32 to process the data.

[0180] (3) Message sending, which involves encapsulating the converted data into a message; sending it to the specified Topic of message queue 40; and recording the sending log.

[0181] In some embodiments, the condition matching submodule 31 may be replaced by the following alternatives: using a rule engine framework such as Drools; using an expression language (such as SpEL, MVEL); and using a DSL (domain-specific language) to define rules.

[0182] In some embodiments, the data transformation submodule 32 may be replaced by the following alternatives: using JSONPath for data extraction; using a template engine (such as Jinja2) for data rendering; and using a scripting language (such as JavaScript or Python) for transformation.

[0183] Specifically, the intent recognition service 50 consumes event data from the message queue 40, identifies the approval process type through the route matching submodule 51, and then constructs an API request through the request construction submodule 52.

[0184] The route matching submodule 51 executes a priority matching strategy, which sorts all enabled route rules by priority; it then checks the condition field and condition value of each route in turn and returns the first matching route rule.

[0185] In this process, the routing rules used by the route matching submodule 51 include: (1) Condition field, i.e., the field path in the event data, such as data.flowType.

[0186] (2) Conditional operators, such as equal to, contain, etc.

[0187] (3) Conditional values, such as target values.

[0188] (4) Priority, such as the smaller the number, the higher the priority.

[0189] The request build submodule 52 executes a template replacement strategy, which involves defining a request template containing variable placeholders; extracting variable values ​​from event data and route configuration; replacing placeholders in the template; and generating the final request.

[0190] The workflow of Intent Recognition Service 50 includes: (1) Message consumption, that is, pulling messages from message queue 40, deserializing the message content into a dictionary object, and generating a unique business ID (businessId).

[0191] (2) Route matching, which means loading all enabled routing rules from the database, calling the route matching submodule 51 to find matching routes, and if no match is found, logging and discarding the event.

[0192] (3) Request construction, that is, to obtain the request template associated with the route, call the request construction submodule 52, apply the template replacement, and generate a complete API request object.

[0193] (3) API call, that is, calling the API interface of Dify workflow platform 60 and calling the small model approval service 90 in parallel, and waiting for the response of the two services.

[0194] (4) Result processing, that is, calling the approval decision service 100 to integrate the results and output the final approval conclusion 110.

[0195] In some embodiments, the routing configuration for procurement approval is as follows: the condition field is data.flowType, the condition operator is eq (equal to), the condition value is purchase, and the API URL is https: / / dify.example.com / v1 / workflows / run; the request template includes fields such as appSceneCode, businessId, and data.

[0196] In some embodiments, the routing configuration for expense reimbursement is as follows: the condition field is data.flowType, the condition operator is eq (equal to), the condition value is expense, the API URL is https: / / dify.example.com / v1 / workflows / run, and the request template includes fields such as appSceneCode, businessId, and data.

[0197] In some embodiments, route matching may be replaced by the following alternatives: using decision trees for multi-condition matching, using regular expressions for pattern matching, or using machine learning models for intent classification.

[0198] In some embodiments, request construction can be replaced by using a JSON template engine, using the GraphQL query language, or using the Protobuf serialization format.

[0199] Specifically, Dify Workflow Platform 60 is a large language model workflow orchestration platform that provides a visual interface for configuring workflows. Each approval process corresponds to a pre-configured workflow, which includes: (1) Prompt word configuration module 61: Define approval requirements, judgment criteria and output format; (2) MCP tool configuration module 62: Defines the list of available business data acquisition tools; (3) LLM processing node 63: Executes approval judgment logic and calls MCP tool.

[0200] In some embodiments, the MCP tool service 70 encapsulates multiple business data acquisition tools. For example, the MCP tool service 70 encapsulates the following tools: (1) Budget query tool 71, used to obtain departmental budget information; (2) Supplier query tool 72, used to obtain supplier qualification information; (3) Historical record query tool 73, used to obtain historical approval records; (4) Attachment recognition tool 74, used to call the visual model to identify the authenticity and content of attachments.

[0201] The workflow of Dify Workflow Platform 60 includes: (1) Workflow startup, that is, the intent recognition service 50 calls the Dify API, passes in the approval data, and the Dify workflow platform 60 starts the corresponding workflow instance, loads the prompt word configuration and MCP tool configuration.

[0202] (2) LLM processing, namely, LLM processing node 63 receives approval data and prompt words, analyzes the approval requirements based on the prompt words, and determines which business data is needed to support the approval decision.

[0203] (3) MCP tool call, that is, the LLM selects the appropriate MCP tool as needed, calls the MCP tool service 70, passes in the parameters, the MCP tool service 70 calls the business system API 80 to obtain the data, and returns the data to the LLM processing node 63.

[0204] (4) Attachment processing, i.e., the approval includes attachments. The LLM calls the attachment recognition tool 74, which identifies the attachment type (e.g., ID card, marriage certificate), calls the visual model to identify the authenticity and content of the attachment, and returns the recognition results to the LLM.

[0205] (5) Approval decision, that is, the LLM integrates the approval data and the acquired business data, and makes inferences based on the judgment criteria defined by the prompt words, outputs the approval conclusion (result: 1-pass, 0-fail) and outputs the approval reasons and analysis process.

[0206] In some embodiments, taking procurement approval as an example, the prompt message generated by the prompt message configuration module 61 is: "You are a professional procurement approval expert. Please determine whether this procurement request is approved based on the following business data and procurement policies, and output the approval conclusion in the following format:" { “analysis”: “Analysis and explanation”; "result": 1; "reason": "Reason for approval"; "confidence": 0.95 } Note: If you need more business data, please use the MCP tool to obtain it.

[0207] The business data includes: purchase application ID (e.g., {{flowId}}), applicant (e.g., {{applicantId}}), purchase amount (e.g., {{amount}} yuan), and supplier ID (e.g., {{supplierId}}). The procurement policy is as follows: 1. Whether the purchase amount is within the departmental budget; 2. Whether the supplier's qualifications are compliant (supplier information needs to be checked); 3. Whether the procurement process is standardized (historical procurement records need to be checked); 4. Verification of the authenticity of attachments (if there are attachments such as ID cards or marriage certificates, their authenticity needs to be verified).

[0208] Based on this, the list of available MCP tools includes: 1. `get_budget_info` is used to retrieve department budget information; the parameter is `department_id`. 2. `get_supplier_info` is used to retrieve supplier qualification information; the parameter is `supplier_id`. 3. `get_purchase_history` is used to retrieve historical purchase records. The parameters are `applicant_id` and `limit`. 4. `get_attachment_info` is used to retrieve attachment information and identify its authenticity and content. The parameters are `attachment_path` and `attachment_type`.

[0209] In some embodiments, the Dify workflow platform 60 can be replaced by the following options: using the LangChain framework to orchestrate LLM workflows, using a self-developed workflow engine, or directly calling the LLM API without using the workflow platform.

[0210] In some embodiments, the MCP protocol can be replaced by the following alternatives: using a Function Calling mechanism (such as OpenAI's function calls), using a Tool Use protocol, or a custom tool call interface.

[0211] Among them, the small model approval service 90 includes two core sub-modules: feature extraction sub-module 91 and model prediction sub-module 92.

[0212] Specifically, the feature extraction submodule 91 extracts the following features from the approval data: (1) Amount-related characteristics, such as application amount and normalized amount; (2) Applicant characteristics, such as the applicant's department, the number of approved applications in the past, and the number of rejected applications in the past; (3) Supplier characteristics, such as supplier rating and length of cooperation; (4) Process characteristics, such as approval type and number of attachments.

[0213] The model prediction submodule 92 is implemented using the following algorithms: Random Forest, Gradient Boosting, and Multilayer Perceptron (MLP).

[0214] Specifically, when using random forests, integrating multiple decision trees provides strong robustness; when using gradient boosting trees, accuracy is high; and when using multilayer perceptrons, complex nonlinear relationships can be handled.

[0215] In some embodiments, the gradient boosting tree can be XGBoost or LightGBM.

[0216] The workflow of the small model approval service (90%) includes: (1) Model training stage, namely, extracting features and labels (pass / fail) from historical approval data; splitting the training set and test set; training the model and adjusting hyperparameters; evaluating the model accuracy, precision and recall; and saving the trained model file.

[0217] (2) Model prediction stage, i.e., receiving approval data; calling feature extraction submodule 91 to extract feature vectors; calling model prediction submodule 92 to output prediction results; calculating prediction confidence (probability value); and returning approval conclusion and confidence.

[0218] The feature design of the feature extraction submodule is shown in Table 1.

[0219] Table 1

[0220] The evaluation metrics for the small model approval service include at least one of the following: accuracy, precision, recall, F1-score, and AUC.

[0221] Among them, accuracy is the proportion of correct predictions; precision is the proportion of predictions that pass actually pass; recall is the proportion of actual passes that are predicted to pass; F1-Score is the harmonic mean of precision and recall; and AUC is the area under the ROC curve, which measures the model's ranking ability.

[0222] In some embodiments, the feature extraction involved in the small model approval service 90 can be replaced by the following schemes: using deep learning to automatically extract features, using embedded representations, or using feature hashing.

[0223] In some embodiments, the model algorithm used by the small model approval service 90 can be replaced by the following schemes: Logistic Regression, Support Vector Machine (SVM), Deep Neural Network, Gradient Boosting Tree (XGBoost, LightGBM, CatBoost).

[0224] The approval decision service 100 includes two core sub-modules: the weighted fusion sub-module and the voting fusion sub-module.

[0225] Specifically, the weighted fusion submodule executes a weighted fusion strategy, which calculates a weighted score based on the output confidence scores of the large model and the small model; the weight of the large model is 0.6, and the weight of the small model is 0.4 (which can be adjusted according to business needs); a weighted score ≥ 0.5 is considered a pass, otherwise it is considered a fail.

[0226] The formula for calculating the weighted score is: total_score=llm_score×llm_weight+small_score×small_weight; Where: llm_score = llm_confidence (if LLM passes) or (1 - llm_confidence) (if LLM fails); small_score = small_confidence (if small model passes) or (1 - small_confidence) (if small model fails).

[0227] The voting fusion submodule executes the voting fusion strategy. Specifically, in the case of majority rule, both models must pass to pass (strict mode); in the case of either model passing, either model must pass to pass (relaxed mode).

[0228] The approval decision service 100 can also select a priority fusion strategy for execution. The priority fusion strategy is suitable for use scenarios where the large model has strong capabilities. That is, if the confidence of the large model is greater than or equal to the threshold (such as 0.8), the result of the large model is directly adopted; otherwise, the result of the small model is referenced.

[0229] The workflow of Approval Decision Service 100 includes: (1) Receive results, that is, receive the approval results and confidence level output by the large model workflow, and receive the approval results and confidence level output by the small model service.

[0230] (2) Result analysis, i.e., analyzing the results of the large model: result (1 or 0), confidence (0-1), and analyzing the results of the small model: result (approve or reject), confidence (0-1).

[0231] (3) Fusion decision, that is, according to the configured fusion strategy, the corresponding fusion sub-module is selected. When weighted fusion is selected, the weighted fusion sub-module is called; when voting fusion is selected, the voting fusion sub-module is called; and the final result and confidence level are calculated.

[0232] (4) Output of results, namely the approval conclusion after encapsulation and fusion, which includes the large model result, the small model result, the fusion strategy, and the final confidence level, and outputs to the final approval result 110.

[0233] The performance of the evaluation indicators under different schemes is shown in Table 2.

[0234] Table 2

[0235] As shown in Table 2, the voting fusion (strict mode) has the highest accuracy and is suitable for scenarios with high requirements for approval accuracy; the weighted fusion has good balance and is suitable for general scenarios.

[0236] In some embodiments, the fusion strategy can be replaced by the following schemes: Bayesian fusion, Stacking integration, dynamic weights, and cascading fusion.

[0237] Among them, Bayesian fusion is a fusion method based on probability theory; Stacking fusion uses a meta-model to learn how to fuse; dynamic weights dynamically adjust model weights based on input data; and cascaded fusion uses one model for filtering and another model for confirmation.

[0238] For exception handling scenarios, the following methods can be used: For large model calls that fail, i.e., when the Dify workflow platform detects a 60 response timeout or error, a degradation strategy is adopted, such as using only the results of small models, logging the exception, and sending an alarm.

[0239] If the MCP tool fails to be invoked, i.e., the LLM detects that the MCP tool returns an error, it can try to use other available tools or make decisions based on existing data, and mark the data acquisition anomaly in the approval results.

[0240] If the results of the two models conflict, such as the larger model passing while the smaller model fails (or vice versa), a weighted fusion can be used, with the decision based on the confidence level, and manual review if necessary.

[0241] To facilitate understanding of the business approval scheme proposed in this invention, let's take a corporate procurement approval scenario as an example. A procurement officer submits a procurement request in the business system, with a requested amount of 50,000 yuan and the supplier being ABC Company. The system automatically captures database changes and invokes AI for approval.

[0242] The complete timeline of the company's procurement approval process is as follows: T0: The purchasing agent submits a purchase request; T1: Database write, generating binlog event (delay: <100ms); T2: Event subscription service captures events (delay: <1s); T3: Rule engine matching rules (delay: <100ms); T4: Message sent to RocketMQ (delay: <100ms); T5: Intent to identify service consumption message (delay: <100ms); T6: Parallel call to large and small models (delay: 2-4s). T7: Decision Fusion (Latency: <10ms); T8: Result write-back (delay: <100ms); Total delay: approximately 3-5 seconds.

[0243] Based on this, the complete process for enterprise procurement approval is as follows: (1) Database changes: Specifically, the purchaser fills in the purchase application form in the business system and clicks submit; the business system writes the purchase application data into the approval process table 11 of the business system database 10; the approval process table 11 adds a record: ID=12345, status='submitted', amount=50000, supplier_id='supplier_abc'; the business system database 10 generates a binlog event.

[0244] (2) Event capture: Specifically, the event subscription service 20 monitors the binlog of the business system database 10 in real time; the binlog parsing module 21 captures the INSERT event; parses the event content: schema='business_db', table='approval_flow', event_type='INSERT'; extracts the data rows: flowId=12345, flowType='purchase', status='submitted', amount=50000, applicantId='user001', supplierId='supplier_abc'; constructs the event data object and passes it to the rule engine 30.

[0245] (3) Rule matching: Specifically, rule engine 30 loads the subscribed rules from the database; the matched rule is: table='approval_flow', event_type='INSERT', status='submitted'; the condition matching submodule 31 checks: the status field value is 'submitted', which meets the condition; the data transformation submodule 32 extracts the fields: flowId, flowType, status, amount, applicantId, supplierId; the message is encapsulated and sent to the Topic of message queue 40: 'approval_events'.

[0246] (4) Intent recognition: Specifically, intent recognition service 50 consumes messages from message queue 40; route matching submodule 51 finds a matching route, i.e., checks the condition field: data.flowType='purchase'; a route is matched: purchase approval process, priority=1. Request construction submodule 52 applies the request template, i.e., replaces the variables: appSceneCode='purchase_approval', businessId='PA_20260123_001'; and constructs a complete API request.

[0247] (5) Parallel invocation. Specifically, the intent recognition service 50 invokes two services in parallel: the procurement approval workflow of the Dify workflow platform 60 and the procurement approval model of the small model approval service 90.

[0248] (6) Large model approval: Specifically, the Dify workflow platform 60 receives the request and starts the workflow instance; loads the prompt word configuration module 61 and the MCP tool configuration module 62; the LLM processing node 63 executes the approval, that is, parses the prompt words: needs to judge the amount, supplier qualifications, and history; decision: needs to call the MCP tool to obtain business data; calls the MCP tool service 70, such as calling the budget query tool 71: to obtain the department budget information and confirm that 50,000 yuan is within the budget range; calls the supplier query tool 72: to obtain the qualification information of supplier ABC and confirm that it is a qualified supplier; calls the history query tool 73: to obtain the purchaser's historical purchase records and confirm that there are no abnormalities; integrates the data and makes inferences and judgments; outputs the approval conclusion: result=1 (passed), confidence=0.9, reason= complies with the procurement management regulations, the budget is sufficient, and the supplier qualifications are compliant.

[0249] (7) Small model approval: Specifically, the small model approval service 90 receives approval data; the feature extraction submodule 91 extracts features, namely amount=50000, normalized_amount=0.5, applicant_department_id=101, applicant_history_approved_count=15, applicant_history_rejected_count=2, supplier_rating=4, supplier_cooperation_years=3, flow_category_id=1, attachment_count=0; the model prediction submodule 92 predicts, that is, inputs the feature vector to the trained random forest model, and outputs: result='approve', confidence=0.85, probability distribution: approve=0.85, reject=0.15.

[0250] (8) Decision fusion. Specifically, the approval decision service 100 receives two results: large model: result=1, confidence=0.9; small model: result='approve', confidence=0.85; a weighted fusion strategy is adopted, that is, the score of the large model: 0.9×0.6=0.54; the score of the small model: 0.85×0.4=0.34; the total score: 0.54+0.34=0.88≥0.5; and the final approval result 110 is output: final_result='approve', final_confidence=0.88.

[0251] (9) Result processing: Specifically, the final approval conclusion is written back to the business system database 10; the status of the approval process table 11 is updated: status='approved'; and a notification is sent to the applicant and relevant approvers.

[0252] Figure 6 The data flow sequence diagram of the business approval method in this invention is shown. Figure 7 A schematic diagram illustrating the deployment topology and dependencies of different modules is shown, such as... Figure 6 and Figure 7 As shown, the business approval process involves the following steps: 1. binlog change events; 2. Parse the event type and data; 3. Transmit event data; 4. Condition matching; 5. Data conversion; 6. Send message queue; 7. Consumer news; 8. Route matching; 9. Construct the API request; 10a. Invoke the large model workflow; 11a. Use the MCP tool to obtain data; 12a. Return business data; 13. LLM reasoning and judgment; 14a. Return the approval result; 10b. Call the small model service; 11b. Feature extraction; 12b. Model prediction; 14b. Return the approval result; 15. Integrated decision-making; 16. Output the final approval conclusion.

[0253] Figure 8 A flowchart illustrating the approval process in this invention is shown, as follows: Figure 8 As shown, the approval process includes: Step 801: The business system writes the approval data; Step 802: The database generates binlog events; Step 803: The event subscription service captures events. If the event is changed to INSERT or UPDATE, proceed to step 804; if the event is changed to any other event, the process ends. Step 804: Parse the event data; Step 805: Rule engine condition matching. If the match is successful, proceed to step 806; otherwise, the process ends. Step 806: Data conversion and encapsulation; Step 807: Send message to the message queue; Step 808: Identify the service consumption message; Step 809: Route matching. If a route is matched, proceed to step 810. If no route is matched, log the information and end the process. Step 810: Construct the API request; Step 811, Parallel Invocation; Step 812: Invoke the Dify workflow; Step 813: Is business data needed? If the result is yes, proceed to step 814; if the result is no, proceed to step 815. Step 814: Call the MCP tool; Step 815, LLM reasoning and judgment; Step 816: Obtain business data; Step 817: Output the large model results; Step 818: Call the small model service; Step 819: Feature extraction; Step 820: Model prediction; Step 821: Output the small model results; Step 822: Integration of approval decision-making and service decision-making; Step 823: Calculate the fusion result; Step 824: Output the final approval conclusion; Step 825: Write back to the business system.

[0254] Figure 9 This diagram illustrates how the application approval conclusion is determined based on the first and second approval results in this invention. The approval result of the large model is also the first approval result, and the approval result of the small model is also the second approval result. Figure 9 As shown, different fusion strategies are executed according to the selected weighted fusion strategy, voting fusion strategy, and priority fusion strategy to obtain the application approval conclusion, which is the final approval conclusion.

[0255] Figure 10 A schematic diagram of the MCP tool invocation process in this invention is shown, as follows: Figure 10 As shown, the MCP tool invocation process includes: 1. Receive approval data and prompts; 2. Analyze prompts and identify approval requirements; 3. Analyze the required business data; 4. Check the list of available MCP tools; 5a. Call get_budget_info; 6a. Execution budget query tool; 7a. GET / budget / department / {id}; 8a. Return budget data; 9a. Return the results; 10a. Return budget information; 5b. Call get_supplier_info; 6b. Execute the supplier query tool; 7b. GET / supplier / {id}; 8b. Return supplier data; 9b. Return the results; 10b. Return supplier information; 5c. Call get_attachment_info; 6c. Execute the attachment recognition tool; 7c, POST / vision / analyze; 8c. Return the recognition result; 9c. Return the result; 10c. Return additional identification information; 11. Integrate all business data; 12. Make inferences and judgments based on the clues; 13. Output the approval conclusion.

[0256] Figure 11 The diagram illustrates the deployment methods and network connections of each service component in this invention, such as... Figure 11 As shown, the data storage layer deploys an event service database and a business database; the event service cluster deploys event subscription service 1 and event subscription service 2; the approval service cluster deploys intent recognition service 1 and intent recognition service 2; the AI ​​service deploys a small model service, the Dify workflow platform, and the MCP tool service. Among them, the MCP tool service communicates with the business system API and visual model API in the external system. The application service layer connects with the user access layer through a message middleware layer and a load balancing layer.

[0257] The business approval device provided by the present invention is described below. The business approval device described below and the business approval method described above can be referred to in correspondence.

[0258] In some embodiments, a business approval device is provided, such as Figure 12 As shown, it includes the following modules: Subscription module 1201 is used to subscribe to log files in the business database; Capture module 1202 is used to determine the change event corresponding to the first business application based on the log file. The first business application is a business application that requires approval. Module 1203 is used to construct the first call request and the second call request based on the business approval process corresponding to the change event; The processing module 1204 is used to determine the application approval conclusion based on the first approval result and the second approval result; the first approval result is obtained after responding to the first call request and approving the first business application based on the first model service; the second approval result is obtained after responding to the second call request and approving the first business application based on the second model service; the first model service is updated according to the approval data corresponding to the historical business applications of the second model service.

[0259] Figure 13 An example is a schematic diagram of the physical structure of an electronic device, such as... Figure 13As shown, the electronic device may include: a processor 1310, a communication interface 1320, a memory 1330, and a communication bus 1340, wherein the processor 1310, the communication interface 1320, and the memory 1330 communicate with each other through the communication bus 1340. The processor 1310 can call logical instructions in the memory 1330 to execute a business approval method, which includes: subscribing to log files in a business database; determining a change event corresponding to a first business application based on the log files, wherein the first business application is a business application requiring approval; constructing a first call request and a second call request according to the business approval process corresponding to the change event; determining an application approval conclusion based on the first approval result and the second approval result; the first approval result is obtained after approving the first business application based on a first model service in response to the first call request; the second approval result is obtained after approving the first business application based on a second model service in response to the second call request; and the first model service is updated according to the approval data corresponding to historical business applications of the second model service.

[0260] Furthermore, the logical instructions in the aforementioned memory 1330 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0261] On the other hand, the present invention also provides a computer program product, which includes a computer program that can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer can execute the business approval method provided by the above methods. The method includes: subscribing to log files in a business database; determining a change event corresponding to a first business application based on the log files, wherein the first business application is a business application that requires approval; constructing a first call request and a second call request according to the business approval process corresponding to the change event; determining an application approval conclusion based on the first approval result and the second approval result; wherein the first approval result is obtained after approving the first business application based on a first model service in response to the first call request; wherein the second approval result is obtained after approving the first business application based on a second model service in response to the second call request; and wherein the first model service is updated according to the approval data corresponding to historical business applications of the second model service.

[0262] In another aspect, the present invention also provides a non-transitory computer-readable storage medium storing a computer program thereon, which, when executed by a processor, is implemented to perform the business approval method provided by the above methods. The method includes: subscribing to log files in a business database; determining a change event corresponding to a first business application based on the log files, wherein the first business application is a business application requiring approval; constructing a first call request and a second call request according to the business approval process corresponding to the change event; determining an application approval conclusion based on the first approval result and the second approval result; the first approval result is obtained in response to the first call request after approving the first business application based on a first model service; the second approval result is obtained in response to the second call request after approving the first business application based on a second model service; and the first model service is updated according to the approval data corresponding to historical business applications of the second model service.

[0263] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0264] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., including several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods of various embodiments or some parts of embodiments.

[0265] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A business approval method, characterized in that, include: Subscribe to log files in the business database; Based on the log file, the change event corresponding to the first business application is determined, and the first business application is a business application that requires approval; Construct a first call request and a second call request based on the business approval process corresponding to the change event; Based on the first approval result and the second approval result, the application approval conclusion is determined; The first approval result is obtained in response to the first call request after approving the first business application based on the first model service; The second approval result is obtained in response to the second call request after approving the first business application based on the second model service; The first model service is updated based on the approval data corresponding to the historical business applications of the second model service.

2. The business approval method according to claim 1, characterized in that, The step of capturing change events corresponding to the first service application based on the log file includes: The log parsing module is invoked to parse the format of the log file and obtain the parsing result, which includes the business type corresponding to the first business application. If the business type corresponding to the first business application is a preset business type, the first business application is matched with business rules in the event service database; If the business rule corresponding to the first business application is matched in the event service database, the parsing result is encapsulated to obtain the change event.

3. The business approval method according to claim 1, characterized in that, The step of constructing the first and second call requests based on the business approval process corresponding to the change event includes: Match the business approval process corresponding to the change event in the event service database; Obtain a first request template and a second request template, wherein the first request template is the request template corresponding to the first model service, and the second request template is the request template corresponding to the second model service; Based on the first request template and the business approval process corresponding to the change event, a first call request is determined, and based on the second request template and the business approval process corresponding to the change event, a second call request is determined.

4. The business approval method according to claim 1, characterized in that, The process of determining the application approval conclusion based on the first approval result and the second approval result includes: Receive the user's first input, which is used to select one of the weighted fusion strategy, the voting fusion strategy, and the priority fusion strategy; In response to the first input, the first approval result and the second approval result are processed according to the fusion strategy selected by the first input to obtain the application approval conclusion.

5. The business approval method according to claim 4, characterized in that, When the fusion strategy selected by the first input is a weighted fusion strategy, the process of processing the first approval result and the second approval result to obtain the application approval conclusion includes: Based on the first approval result, a first confidence level is determined to be the approval conclusion, and based on the second approval result, a second confidence level is determined to be the approval conclusion. Obtain the first weight value corresponding to the first model service and the second weight value corresponding to the second model service; Determine the first product of the first weight value and the first confidence level, and determine the second product of the second weight value and the second confidence level; If the sum of the first product value and the second product value is greater than or equal to a preset score threshold, the application approval conclusion is determined to be approved; If the sum of the first product value and the second product value is less than a preset score threshold, the application approval conclusion is determined to be that the approval has not been passed.

6. The business approval method according to claim 4, characterized in that, When the fusion strategy selected by the first input is a voting fusion strategy, the process of processing the first approval result and the second approval result to obtain the application approval conclusion includes: Compare the approval conclusion in the first approval result with the approval conclusion in the second approval result; Since the approval conclusion in the first approval result is inconsistent with the approval conclusion in the second approval result, the approval conclusion with higher confidence level shall be taken as the application approval conclusion; Based on the consistency between the approval conclusion in the first approval result and the approval conclusion in the second approval result, the application approval conclusion is determined according to the voting mode of the voting fusion strategy; The voting mode includes either a strict mode or a lenient mode.

7. The business approval method according to claim 6, characterized in that, The process of determining the application approval conclusion based on the voting pattern of the voting fusion strategy includes: When the voting mode of the voting fusion strategy is the strict mode, the application approval conclusion is determined to be approved based on the fact that the approval conclusion in the first approval result and the approval conclusion in the second approval result are both approved. When the voting mode of the voting fusion strategy is the lenient mode, and the approval conclusion in the first approval result and / or the approval conclusion in the second approval result is "approved", the application approval conclusion is determined to be "approved".

8. The business approval method according to claim 4, characterized in that, When the fusion strategy selected by the first input is a priority fusion strategy, the process of processing the first approval result and the second approval result to obtain the application approval conclusion includes: Determine the confidence level corresponding to the approval conclusion in the first approval result; Based on the confidence level being greater than or equal to the confidence threshold, the approval conclusion in the first approval result is selected as the application approval conclusion; Based on the fact that the confidence level is less than the confidence threshold, the approval conclusion in the second approval result is selected as the application approval conclusion.

9. The business approval method according to claim 4, characterized in that, The first approval result was obtained in the following way: Based on the first call request and the prompt words corresponding to the first call request, determine the approval requirements corresponding to the first business application; If business data is required based on the approval requirements, the business data is invoked using a business data invocation tool from the business data invocation tool list. The first invocation request, the prompt word corresponding to the first invocation request, and the business data are sent to the target large language model to obtain the first approval result output by the target large language model. If it is determined that no business data is needed based on the approval requirements, the first call request and the prompt word corresponding to the first call request are sent to the target large language model to obtain the first approval result output by the target large language model; The target large language model is the inference model used by the first model service.

10. The business approval method according to claim 9, characterized in that, The list of business data retrieval tools includes one or more of the following business data retrieval tools: Budget query tool, historical record query tool, and attachment recognition tool.

11. A business approval device, characterized in that, include: The subscription module is used to subscribe to log files in the business database; The capture module is used to determine the change event corresponding to the first business application based on the log file, wherein the first business application is a business application that requires approval; The construction module is used to construct a first call request and a second call request based on the business approval process corresponding to the change event; The processing module is used to determine the application approval conclusion based on the first approval result and the second approval result; The first approval result is obtained in response to the first call request after approving the first business application based on the first model service; The second approval result is obtained in response to the second call request after approving the first business application based on the second model service; The first model service is updated based on the approval data corresponding to the historical business applications of the second model service.

12. An electronic device comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that, When the processor executes the computer program, it implements the business approval method as described in any one of claims 1 to 10.

13. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the business approval method as described in any one of claims 1 to 10.

14. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the business approval method as described in any one of claims 1 to 10.

Images