Transaction processing method, system, electronic device, computer storage medium and computer program product

Abstract

Embodiments of the present application provide a transaction processing method, system, electronic device, computer storage medium and computer program product, wherein a transaction processing method comprises: receiving user input for interacting with a generative base model, wherein the user input carries information of a to-be-processed transaction; calling a corresponding transaction processing process instance according to the information of the to-be-processed transaction, wherein the transaction processing process instance is generated according to a unified protocol template for transaction processing, the unified protocol template is used to obtain a plurality of configuration information for transaction processing based on input information, and a template of a transaction processing process instance that can interact with the generative base model is generated based on the plurality of configuration information; and using the generative base model to perform transaction processing on the to-be-processed transaction through the transaction processing process instance. Through the embodiments of the present application, the normativity, consistency and interpretability of the implementation code are ensured, and reuse is facilitated.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence technology, and in particular to a transaction processing method, system, electronic device, computer storage medium, and computer program product. Background Technology

[0002] With the rapid development of AI (Artificial Intelligence) technology, more and more applications, services, and transaction processing are leveraging AI to enhance their intelligence. LLM (Large Language Model) models, due to their superior natural language processing capabilities, have demonstrated broad application potential and value in practical applications, such as deep dialogue systems based on natural language, in areas like customer service automation and intelligent transaction processing.

[0003] Currently, when using the LLM model to implement intelligent applications, services, or transaction processing in different fields, technical personnel need to write different codes based on the basic LLM model according to the specific use case. This results in a lack of standardized code across different scenarios, poor interpretability, and difficulty in subsequent reuse, thus increasing the cost of using the LLM model to achieve intelligence in different scenarios. Furthermore, other models similar to the LLM model also suffer from similar problems. Summary of the Invention

[0004] In view of this, embodiments of this application provide a transaction processing scheme to at least partially solve the above-mentioned problems.

[0005] According to a first aspect of the embodiments of this application, a transaction processing method is provided, comprising: receiving user input for interacting with a generative base model, wherein the user input carries information about a transaction to be processed; invoking a corresponding transaction processing flow instance based on the information about the transaction to be processed, wherein the transaction processing flow instance is generated according to a unified protocol template for transaction processing, the unified protocol template being a template for generating a transaction processing flow instance that can interact with the generative base model based on the input information to obtain various configuration information for transaction processing; and performing transaction processing on the transaction to be processed using the generative base model through the transaction processing flow instance.

[0006] According to a second aspect of the embodiments of this application, another transaction processing method is provided, comprising: obtaining information about a transaction processing flow instance to be generated, and obtaining a unified protocol template for transaction processing, wherein the unified protocol template is a template for generating a transaction processing flow instance that can interact with a generative basic model based on a variety of configuration information obtained based on input information; and generating a corresponding transaction processing flow instance according to the information about the transaction processing flow instance to be generated and the unified protocol template.

[0007] According to a third aspect of the embodiments of this application, a transaction processing system is provided, including: a unified protocol module, a session management module, and an AI thinking module; wherein: the unified protocol module is used to provide a unified protocol template, and generate a corresponding transaction processing process instance according to the unified protocol template based on the information of the transaction processing process instance to be generated; wherein the unified protocol template is a template for generating a transaction processing process instance that can interact with a generative basic model based on the multiple configuration information obtained from input information for transaction processing; the AI ​​thinking module is used to receive user input for interacting with the generative basic model, wherein the user input carries information about the transaction to be processed; and, according to the information about the transaction to be processed, calls the corresponding transaction processing process instance to obtain transaction status information associated with the transaction to be processed through the session management module, and generates prompt information based on the user input and the transaction status information, so that the generative basic model performs transaction processing on the transaction to be processed according to the prompt information.

[0008] According to a fourth aspect of the present application, an electronic device is provided, comprising: a processor, a memory, a communication interface, and a communication bus, wherein the processor, the memory, and the communication interface communicate with each other via the communication bus; the memory is used to store at least one executable instruction, wherein the executable instruction causes the processor to perform an operation corresponding to the method described in the first or second aspect.

[0009] According to a fifth aspect of the embodiments of this application, a computer storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the method as described in the first or second aspect.

[0010] According to a sixth aspect of the embodiments of this application, a computer program product is provided, including computer instructions that instruct a computing device to perform an operation corresponding to the method described in the first or second aspect.

[0011] According to the solution provided in the embodiments of this application, when processing transactions, a transaction processing flow instance generated based on a unified protocol template is used in conjunction with a generative basic model. The unified protocol template can be considered a standard or specification for generating transaction processing flow instances; regardless of the type of transaction, the processing flow is written according to this template. Therefore, on the one hand, because different transaction processing flow instances are generated based on the same unified protocol template, the instances are more universal and standardized, improving their reusability. On the other hand, the unified protocol template includes settings for obtaining various configuration information for transaction processing based on input information, and for generating transaction processing flow instances that can interact with the generative basic model based on these configuration information. These settings are applicable to all transaction processing, unifying both the instance generation standard and the interpretation standard. Furthermore, the interaction between the transaction processing flow instances generated based on the unified protocol template and the generative basic model is more consistent and standardized.

[0012] As can be seen, the solution of this application embodiment can be implemented by combining a generative basic model with a good standardization and interpretability of transaction processing flow instances, even in different fields and scenarios, when it is necessary to perform transaction processing based on generative basic models such as LLM. This not only improves the efficiency of using generative basic models to achieve intelligence in different fields and scenarios and reduces the implementation cost, but also ensures the standardization, consistency and interpretability of the implementation code, and facilitates subsequent code reuse. Attached Figure Description

[0013] To more clearly illustrate the technical solutions in the embodiments of this application 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 only some embodiments recorded in the embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings.

[0014] Figure 1 A schematic diagram of an exemplary system to which the embodiments of this application are applicable;

[0015] Figure 2 This is a flowchart illustrating the steps of a transaction processing method for generating a transaction processing flow instance according to an embodiment of this application;

[0016] Figure 3 This is a flowchart illustrating the steps of a transaction processing method for performing transaction processing according to an embodiment of this application;

[0017] Figure 4A This is a structural block diagram of a transaction processing system according to an embodiment of this application;

[0018] Figure 4B This is a schematic diagram of the structure of an exemplary transaction processing system according to an embodiment of this application;

[0019] Figure 4C for Figure 4B The flowchart of the unified protocol module in the transaction processing system is shown.

[0020] Figure 4D for Figure 4B The flowchart of the session management module in the transaction processing system is shown below;

[0021] Figure 4E for Figure 4B The flowchart of the AI ​​thinking module in the transaction processing system is shown.

[0022] Figure 5 This is a schematic diagram of the structure of an electronic device according to an embodiment of this application. Detailed Implementation

[0023] To enable those skilled in the art to better understand the technical solutions in the embodiments of this application, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art should fall within the protection scope of the embodiments of this application.

[0024] The specific implementation of the embodiments of this application will be further described below with reference to the accompanying drawings.

[0025] Figure 1 An exemplary system applicable to embodiments of this application is shown. For example... Figure 1 As shown, the system 100 may include a cloud server 102, a communication network 104, and / or one or more user devices 106. Figure 1 The example in the text shows multiple user devices.

[0026] The cloud server 102 can be any suitable device for storing information, data, programs, and / or any other suitable type of content, including but not limited to distributed storage system devices, server clusters, computing cloud server clusters, etc. In some embodiments, the cloud server 102 can perform any suitable function. For example, in some embodiments, the cloud server 102 can store a unified protocol template for transaction processing. This unified protocol template is a template for obtaining various configuration information for transaction processing based on input information, and generating a transaction processing flow instance that can interact with a generative base model based on the various configuration information. As an optional example, in some embodiments, after obtaining information about the transaction processing flow instance to be generated, the cloud server 102 can also generate a corresponding transaction processing flow instance based on the unified protocol template, so that the user device 106 can call the flow instance when needed. It should be noted that the generated transaction processing flow instance can be deployed on the cloud server 102, but it can also be sent by the cloud server 102 to the user device 106 for deployment on the user device 106. As another example, in some embodiments, the cloud server 102 also includes a generative base model, such as an LLM (Local Language Model), which completes transaction processing through interaction between the transaction processing instance and the generative base model. The generative base model can be a machine learning model with basic natural language processing and generation capabilities, capable of generating corresponding responses based on user-input natural language. In this application's embodiments, several examples use an LLM model as the generative base model; however, those skilled in the art should understand that other machine learning models with the aforementioned functions are also applicable to the solutions in this application's embodiments.

[0027] In some embodiments, the communication network 104 can be any suitable combination of one or more wired and / or wireless networks. For example, the communication network 104 can include any one or more of the following: the Internet, an intranet, a wide area network (WAN), a local area network (LAN), a wireless network, a digital subscriber line (DSL) network, a frame relay network, an asynchronous transfer mode (ATM) network, a virtual private network (VPN), and / or any other suitable communication network. The user equipment 106 can be connected to the communication network 104 via one or more communication links (e.g., communication link 112), and the communication network 104 can be linked to the cloud server 102 via one or more communication links (e.g., communication link 114). The communication link can be any communication link suitable for transmitting data between the user equipment 106 and the cloud server 102, such as a network link, a dial-up link, a wireless link, a hardwired link, any other suitable communication link, or any suitable combination of such links.

[0028] User device 106 may include any one or more user devices suitable for interacting with a user. In some embodiments, user device 106 may receive user input in natural language form, which carries information about a transaction to be processed. If a transaction processing flow instance capable of handling the transaction is deployed locally on user device 106, user device 106 may directly invoke the local transaction processing flow instance to process the transaction in conjunction with the generative basic model of cloud server 102; if the transaction processing flow instance capable of handling the transaction is deployed on cloud server 102, user device 106 may send the user input to cloud server 102 through an interface call to invoke the transaction processing flow instance deployed on cloud server 102, and cloud server 102 will process the transaction in conjunction with the generative basic model. In some embodiments, user device 106 also receives and displays interactive information during the transaction processing to the user, and receives and displays the transaction processing results to the user. In some embodiments, user device 106 may include any suitable type of device. For example, in some embodiments, user equipment 106 may include a mobile device, tablet computer, laptop computer, desktop computer, wearable computer, media player and / or any other suitable type of user equipment.

[0029] It should be noted that in this application embodiment, the term "transaction" is used to refer to the reasons that need to be processed, including the aforementioned applications, services, specific transaction processing, etc. Based on this, and based on the above system, the transaction processing scheme provided by the embodiments of this application will be described below through multiple embodiments.

[0030] To facilitate understanding of the solutions in the embodiments of this application, the unified protocol template used in the embodiments of this application will be described first.

[0031] The unified protocol template in this application specifies the unified protocol standard for the information and interactions required in a transaction processing flow instance. When a new transaction processing flow needs to be added, only one instance (i.e., a transaction processing flow instance) needs to be created according to the unified protocol template, and the flow can be automatically generated based on the unified protocol standard. After that, the transaction processing flow instance can interact with the user and the generative basic model and play a role in the processing of transactions.

[0032] Specifically, this unified protocol template specifies how to obtain various configuration information for transaction processing based on input information (which can be user input or other forms of input), and then generate transaction processing flow instances that can interact with the generative base model based on this configuration information. This is applicable to a variety of different transaction processes, thus making the transaction processing flow instances generated based on the unified protocol template more standardized and uniform for different transaction processes. Furthermore, because this unified protocol specification adopts a unified interpretation standard, the generated transaction processing flow instances are also more interpretable.

[0033] In one alternative approach, the various configuration information in the unified protocol template includes at least: basic transaction information, transaction runtime configuration information, configuration information for obtaining transaction status information, information for indicating the necessary information of the transaction to be obtained, and a preset prompt information template.

[0034] The basic information of a transaction can also be considered as its attribute information. This basic information identifies what kind of transaction it is and what kind of processing is required. For example, the basic information of a transaction may include: the transaction name, a brief description of the transaction, and the transaction execution logic Prompt (used to indicate the execution logic required for subsequent processing of the generative base model, where Prompt represents a prompt message).

[0035] In one alternative approach, the unified protocol template can be saved as JSON format. JSON format has many advantages, including ease of reading and parsing, lightweight nature, standardization, and wide support. This embodiment of the application saves the unified protocol template as JSON format, fully utilizing these characteristics to make the transaction processing flow instances generated based on the unified protocol template easy to read and parse, thus improving interpretability. However, this is not a limitation; other formats of unified protocol templates can also be applied to the solutions of this embodiment. For example, open standard file formats and data exchange formats such as XML and YAML can be applied to the solutions of this embodiment.

[0036] In one example, the basic information about a transaction stored in JSON format could be:

[0037] "label": "Transaction name information";

[0038] "description": "A brief description of the transaction";

[0039] "logics":["Transaction execution logic Prompt"].

[0040] Taking a leave request as an example, its basic information can be represented as follows:

[0041] "label":"Request for leave";

[0042] "description":"Helps users submit leave requests";

[0043] "logics": [

[0044] "-If a user inquires about remaining vacation time or work schedule, you must include that information in your reply."

[0045] "-If the leave time is not during the scheduled work hours, we must confirm with the user."

[0046] ].

[0047] The transaction runtime configuration information is used to indicate the runtime configuration when processing a transaction. Optionally, it may include: information indicating whether the transaction processing is switchable, information on the maximum number of dialogue rounds that the transaction processing can accept, and information on the transaction processing commit interface.

[0048] Taking the unified protocol template in JSON format as an example, the transaction execution configuration information can optionally be represented as follows:

[0049] "exchangeable": Whether the transaction processing is switchable;

[0050] "maxDialogRound": "Maximum number of dialogue rounds";

[0051] "submitAPI": "Transaction commit interface".

[0052] Taking leave requests as an example, its runtime configuration information can be represented as follows:

[0053] "exchangeable":"true"; / *"true" means allow switching, "false" means disallow switching* /

[0054] "maxDialogRound":"8";

[0055] "submitAPI":"com.company.leaveSumbit".

[0056] Configuration information for obtaining transaction status information indicates how to acquire this information. Transaction status information refers to the state information saved during transaction processing, including historical dialogue records, extracted transaction processing information, and queried transaction memories. This status information is maintained and updated across multiple rounds of dialogue and is committed upon completion of the transaction. The aforementioned transaction processing information refers to the predetermined types of information that must be submitted during transaction processing. This information can be extracted during the dialogue between the generative model (LLM) and the user; that is, it can be extracted based on user input and used to assist in transaction processing, such as the reason for the complaint and the target of the complaint in a complaint scenario. The aforementioned transaction memories refer to memory information related to the transaction processing flow, including rules that transaction processing information must meet and user information that may be needed in this transaction scenario, such as the user's remaining vacation time and work hours in a leave request scenario. This information needs to be dynamically queried in the database and can assist the generative model (LLM) in considering user input, improving the quality of the LLM's responses and the efficiency of retrieving transaction processing information.

[0057] In one example of this application's embodiment, the configuration information used to obtain transaction status information is mainly interface configuration information. Taking the JSON-formatted unified protocol template as an example, the configuration information used to obtain transaction status information can optionally be represented as:

[0058] "memoryTable":

[0059] [{

[0060] "name":"Query item name"; / * Which transaction status information is being queried? * /

[0061] "description":"Query item description";

[0062] "type":"Interface type"; / *Query the interface type of the interface* /

[0063] "interface":"Query interface"; / *Detailed information about the query interface* /

[0064] "args":"Input parameters"; / * Input parameters for the query interface * /

[0065] "booster": "Return value to Prompt converter"; / * Information about the converter that converts query results to Prompts * /

[0066] }]

[0067] Taking leave requests as an example, and using the user's shift schedule and remaining vacation time as examples to obtain transaction status information, the corresponding configuration information can be represented as follows:

[0068] "memoryTable":[{

[0069] "name":"schedule";

[0070] "description":"User scheduling information obtained from the query";

[0071] "type":"SpringBoot";

[0072] "interface":"service.getWorkDates";

[0073] "args":["submitForms.startTime","context.userId"];

[0074] "booster":"workDateListToPromptBooster"

[0075] };

[0076] {

[0077] "name":"balance";

[0078] "description":"The user's vacation balance obtained from the query";

[0079] "type":"HSF";

[0080] "interface":"service.getBalance";

[0081] "args":["context.userId"];

[0082] "booster":"balanceToPromptBooster"

[0083] }]

[0084] The information used to indicate the necessary information for a transaction to be retrieved refers to information indispensable for processing the transaction, such as the reason for leave and the leave time in a leave application, or the reason for the complaint and the target of the complaint in a complaint. To facilitate efficient processing of this information, in one optional method, this information is recorded as form fields and then carried in a form for submission.

[0085] Taking the JSON-formatted unified protocol template as an example, the information used to indicate the necessary details of the transaction to be retrieved can optionally be represented as follows:

[0086] "submitForms":

[0087] [{

[0088] "name":"Form field name"; / *Name of the required information* /

[0089] "description": "Form item description";

[0090] "type":"Form item type";

[0091] "required": "Whether it is required";

[0092] "format":"Form field format";

[0093] "validators": "Form field validators"

[0094] };

[0095] ... / *Other form items* /

[0096] "globalValidators":[] ]

[0098] A transaction may require multiple pieces of information, and correspondingly, the aforementioned form items may also have multiple elements. Although the above only provides a complete example of one form item's content, those skilled in the art should understand that other form items can be generated by referring to the example. Each form item has a form item validator to check the correctness of its content. For example, it might be incorrect to enter the applicant's name in the leave reason section, or the leave date might be incorrect, such as entering the previous year or the following year. In addition to each form item's validator, a global validator is also provided to perform overall validation of the entire form, including but not limited to data correctness checks and validation of the logical relationships between form items.

[0099] Optionally, restrictions can be set for necessary information in a transaction to standardize its format, word count, etc., to facilitate subsequent processing. These restrictions can be used as one of the validation criteria in a form field validator.

[0100] Taking the form fields of leave type, leave start time, leave end time, and leave reason as an example, the corresponding information is as follows:

[0101] "submitForms":[

[0102] {

[0103] "name":"type";

[0104] "description": "The leave type selected by the user";

[0105] "type":"java.lang.String";

[0106] "required":"true";

[0107] };

[0108] {

[0109] "name":"startTime";

[0110] "description":"Leave start time";

[0111] "type":"java.util.Date";

[0112] "required":"true";

[0113] "format":"yyyy-MM-ddHH:mm";

[0114] "validators":["format"];

[0115] };

[0116] {

[0117] "name":"endTime";

[0118] "description":"Leave end time";

[0119] "type":"java.util.Date";

[0120] "required":"true";

[0121] "format":"yyyy-MM-ddHH:mm";

[0122] "validators":["format"];

[0123] };

[0124] {

[0125] "name":"leaveReason";

[0126] "description": "Reason for leave";

[0127] "required":"true";

[0128] "type":"java.lang.String";

[0129] };

[0130] "globalValidators":["allCollected"] ]

[0132] The prompt template is used to indicate how to generate a prompt message, which is used for subsequent interaction with generative base models such as LLM. The prompt template can be appropriately set by those skilled in the art according to actual needs. It may typically include a standard switch and end, basic transaction information, transaction runtime configuration information, configuration information for obtaining transaction status information, information indicating the necessary information of the transaction to be obtained, and the obtained multi-turn dialogue records, etc.

[0133] Taking the JSON-formatted unified protocol template as an example, the prompt message template can optionally be:

[0134] "promptTemplate": "Standard prompt message template"

[0135] The "standard prompt message template" can contain the information and dialogue records as described above. For example, these information and dialogue records can be represented by variables in the "standard prompt message template". Then, for each transaction processing instance, the variables can be replaced or assigned values ​​using the corresponding information and dialogue records to generate the prompt message in the actual transaction processing instance.

[0136] It is evident that by using a unified protocol template, the transaction processing flow, interaction content, and required data have been standardized. As a result, the transaction processing flow instances generated based on it are more standardized and more interpretable, thereby improving their reusability.

[0137] Based on this, refer to Figure 2 From the perspective of generating transaction processing process instances, this application describes a transaction processing method for generating transaction processing process instances according to an embodiment of the present application.

[0138] The transaction processing method in this embodiment includes the following steps:

[0139] Step S202: Obtain information about the transaction processing flow instance to be generated, and obtain the unified protocol template for transaction processing.

[0140] The unified protocol template is a template that generates a transaction processing flow instance that can interact with a generative base model such as LLM, based on various configuration information obtained from input information and these configuration information. For example, this unified protocol template can be the unified protocol template described above.

[0141] Information about the transaction processing instance to be generated can be obtained in several ways. One alternative approach is to provide a user interface with multiple input controls, allowing users to input information about the transaction processing instance through text input and / or list options.

[0142] For example, this human-computer interaction interface can include text input boxes for users to input basic instance information, text boxes for inputting instance runtime configuration information, numeric input boxes, list options for displaying multiple data tables involved in the instance, list options for displaying multiple API interfaces involved in the instance, and so on. Users can input information about the transaction processing flow instance by typing or selecting.

[0143] In another alternative approach, because the generative base model possesses basic semantic understanding and response generation capabilities, information about the transaction processing instance to be generated can be obtained through the generative base model. In this approach, the user needs to input a request to instruct the generation of the transaction processing instance, which at least includes the name of the transaction processing instance to be generated. Then, based on this request, auxiliary information for generating this information is obtained, such as the data tables and API interfaces used by the instance, as well as various configuration information specified in the unified protocol template. A prompt is then generated based on the information carried in the user's input request and the obtained auxiliary information. The generative base model, such as an LLM, uses this prompt and, according to the specifications of the various configuration information, performs information generation processing to generate the required transaction processing instance information. Further optionally, this generated information can be further edited and modified to meet the user's actual needs.

[0144] For example, suppose the transaction processing instance to be generated targets a shift change transaction. First, the information for this instance needs to be generated, and then the transaction processing instance is further generated based on this information and the unified protocol template. In this step, regarding the information for generating the shift change transaction processing instance, the user can enter a request query, such as "I need a shift change transaction processing instance; please generate the instance information required for this instance first." After this request query is sent to the service backend, such as the cloud server, the cloud server will, based on this request query, query the unified protocol template from the database or knowledge base to obtain the various configuration information it specifies; on the other hand, it will query and obtain the information of the data tables and / or API interfaces used by the shift change transaction. Then, based on the information carried in the request query, such as the transaction name and the information of the data tables and / or API interfaces used by the shift change transaction obtained from the query, and according to the requirements and specifications of various configuration information in the unified protocol template, it generates a prompt to instruct the LLM to generate the shift change transaction processing instance. Upon receiving this prompt, the LLM processes it to generate various instance information that conforms to the various configuration information requirements and specifications in the unified protocol template. It is evident that, in this process, the various configuration information in the unified protocol template also serves as a template, and the generated instance information must meet the specifications and standards of its corresponding configuration information in the unified protocol template.

[0145] In one optional approach, the information of the transaction processing instance to be generated includes at least: basic information of the instance corresponding to the transaction processing instance to be generated, the runtime configuration information of the instance, the information of the data table and / or API interface corresponding to the instance, and the necessary information of the instance. The various configuration information in the unified protocol template, as described above, includes at least: basic transaction information, transaction runtime configuration information, configuration information for obtaining transaction status information, information for indicating the necessary information of the transaction to be obtained, and a preset prompt information template. This information ensures, on the one hand, the smooth generation of subsequent transaction processing instances; on the other hand, it also ensures a good correspondence between the information of the transaction processing instance to be generated and the configuration information in the unified protocol template, thereby improving the efficiency of subsequent transaction processing instance generation.

[0146] The basic information of an instance includes at least the name of the transaction process corresponding to the instance, such as "leave" or "shift change". This basic information of the instance can serve as the basis for generating the basic information of transactions in subsequent transaction processing process instances.

[0147] The instance's runtime configuration information corresponds to the transaction's runtime configuration information, which may include, but is not limited to: information indicating whether the transaction processing corresponding to the instance is switchable, information on the maximum number of dialogue rounds acceptable to the transaction processing, and information on the transaction processing's commit interface. The instance's runtime configuration information can be manually entered by the user, but is not limited to this; it can also be intelligently generated through a generative base model, or obtained through other methods (such as obtaining it based on information from historical instances of the same type).

[0148] For a specific transaction processing instance, it is typically associated with corresponding databases, knowledge bases, and API interfaces for data access and processing. These databases and knowledge bases store various data used for transaction processing, while the API interfaces provide both access to this data and options for processing it. Based on this, these databases, knowledge bases, and API interfaces can effectively provide data support for the generation of subsequent instances and the processing of specific transactions. For example, they can serve as the basis for generating configuration information used to obtain transaction status information within an instance.

[0149] The necessary information for an instance corresponds to the necessary information for a transaction in the unified protocol template, ensuring the efficient and accurate generation of the necessary information for a transaction.

[0150] Having obtained the information about the transaction processing flow instance to be generated and the unified protocol template for transaction processing, the transaction processing flow instance for a specific transaction can then be generated.

[0151] Step S204: Based on the information of the transaction processing flow instance to be generated, generate the corresponding transaction processing flow instance according to the unified protocol template.

[0152] When generating a transaction processing flow instance according to the unified protocol template, the various configuration information for transaction processing can be generated item by item according to the specifications and requirements of each part of the unified protocol template, based on the information of the transaction processing flow instance to be generated, and finally the transaction processing flow instance is generated.

[0153] In one alternative approach, basic transaction information as specified in the unified protocol template can be generated based on the instance's basic information; transaction runtime configuration information as specified in the unified protocol template can be generated based on the instance's runtime configuration information; configuration information for obtaining transaction status information as specified in the unified protocol template can be generated based on the data table and API interface information corresponding to the instance; necessary information for indicating the transaction to be obtained, as specified in the unified protocol template, can be generated based on the instance's necessary information; and a transaction processing flow instance can be generated based on the generated basic transaction information, transaction runtime configuration information, configuration information for obtaining transaction status information, necessary information for indicating the transaction to be obtained, and a preset prompt information template. In this way, the instance information has a good correspondence with the various configuration information in the unified protocol template, allowing for more efficient generation of transaction processing flow instances.

[0154] As mentioned above, the basic information of an instance includes at least the name information of the transaction process corresponding to the instance. Based on this, generating the basic information of a transaction as specified in the unified protocol template based on the basic information of the instance can be achieved as follows: generating transaction processing logic hint information for the transaction process according to the transaction processing logic hint rules in the unified protocol template based on the name information of the transaction process; generating the basic information of the transaction based on the name information of the transaction process and the transaction processing logic hint information.

[0155] Optionally, transaction description information can also be generated for the transaction based on the transaction name information and the transaction description rules in the unified protocol template. Therefore, generating basic transaction information based on the transaction name information and transaction logic hints can be achieved by generating the basic transaction information based on the transaction name information, transaction description information, and transaction logic hints.

[0156] The transaction name information can be directly obtained from the instance's basic information, as this name information effectively characterizes which transaction the generated transaction processing instance is processing. The transaction description rules in the unified protocol template can be used to specify how to generate the corresponding transaction description information based on the transaction name information. Therefore, transaction description information can be automatically generated based on the transaction processing name information. For example, in one optional approach, the transaction processing name information can be sent to an LLM or other machine learning model capable of information generation, instructing it to generate transaction description information based on the transaction processing name information. In another optional approach, the unified protocol template can also specify the format of the transaction description information, such as "Help users submit ${label} tasks," where "${label}" is a variable that can be replaced by the transaction name information in practical applications. Since the transaction name information originates from the transaction processing name information in the instance's basic information, it can also be considered that it can be replaced by the transaction processing name information. Taking the transaction processing name information or the transaction name information as "leave request" as an example, the transaction description information could be "Help users submit leave request tasks." However, this is not limited to this; other methods of generating transaction description information are also applicable to the embodiments of this application. It should also be noted that in some cases, the transaction description information may be empty, that is, it was not generated or was not successfully generated. This situation will not affect the generation of the transaction processing flow instance.

[0157] The unified protocol template also specifies transaction processing logic prompt rules for the basic information section of a transaction. This section primarily indicates what form of prompt information should be generated that can subsequently interact with the generative base model. This prompt can guide the generative base model's execution logic for transaction processing, such as indicating the information that should be included in the generated response, or the information that needs to be interacted with by the user during the thought chain reasoning process. Based on these transaction processing logic prompt rules and the information of the actual transaction to be processed, transaction processing logic prompt information can be generated. In this embodiment, the specific implementation of the transaction processing logic prompt rules can be flexibly set by those skilled in the art according to actual needs, and this embodiment does not impose any limitations on this.

[0158] It should be noted that, as mentioned earlier, the basic information of a transaction in the unified protocol template includes: the transaction name, a brief description, and the transaction execution logic (Prompt). Based on this, the basic information of an instance could also include the transaction name, brief description, and execution logic (Prompt), but this approach increases both the information parsing burden and the user's operational burden. Therefore, in this embodiment, the basic information of the instance only includes the transaction name; other information is generated subsequently to reduce the user's operational burden and the system's information parsing burden.

[0159] As can be seen, the above process effectively generates basic transaction information that conforms to the unified protocol template.

[0160] When generating the transaction runtime configuration information in the unified protocol template based on the instance's runtime configuration information, it is necessary to obtain information on whether transaction switching is allowed and the maximum number of dialogue rounds allowed for a single transaction. This information is typically input by the user, carried in the instance's runtime configuration information, and sent to the cloud server. The cloud server then parses the information and assigns it to the corresponding transaction runtime configuration information. In other words, the instance's runtime configuration information must include at least: information on whether transaction switching is allowed and information on the maximum number of dialogue rounds allowed for a single transaction. Based on this, generating the transaction runtime configuration information in the unified protocol template from the instance's runtime configuration information can be achieved by generating the transaction runtime configuration information based on the information on whether transaction switching is allowed and the maximum number of dialogue rounds allowed for a single transaction.

[0161] Furthermore, since basic transaction information, information regarding whether transaction switching is allowed, the maximum number of dialogue rounds allowed for a single transaction, configuration information for obtaining transaction status information, and information indicating necessary information for the transaction to be obtained all need to be submitted, the subsequent generative base model can perform targeted transaction processing based on this information. Therefore, during the generation of transaction runtime configuration information, information about the transaction commit interface can also be obtained. This transaction commit interface is used to submit the prompt information generated by the transaction processing instance during transaction processing to the generative base model. Based on this, the generation of transaction runtime configuration information can be implemented as follows: The transaction runtime configuration information is generated based on the information regarding whether transaction switching is allowed, the maximum number of dialogue rounds allowed for a single transaction, and the transaction commit interface information.

[0162] This enables the effective generation of transaction runtime configuration information. This runtime configuration information can be used to restrict the subsequent processing of transactions by the generative basic model, ensuring that transaction processing can be executed according to actual needs.

[0163] In one optional approach, configuration information for obtaining transaction status information can be generated based on the data table and API interface information corresponding to the instance. For example, query description information for the data table can be generated based on the table name and basic transaction information; the API interface name, interface type, and input parameters can be obtained based on the API interface information, and a transformation configuration can be generated based on the API interface's return parameters; the transformation configuration is used to generate prompts for interaction with the generative model based on the return parameters; and the configuration information for obtaining transaction status information is generated based on the data table name, query description information, interface name, interface type, input parameters, and transformation configuration.

[0164] As mentioned earlier, transaction status information refers to the state information saved during transaction processing, including historical dialogue records, extracted transaction processing information, and queried transaction memories. This information can be stored in data tables or other data storage files or databases. During transaction processing, this information is needed as support to complete the transaction. Examples include user scheduling information and remaining user vacation information. This information can be obtained at least through API interfaces, thus providing information about the API interfaces, including but not limited to the interface name, interface type, input parameters, and return parameters, to inform calls to the API interface. Furthermore, because the transaction processing instance needs to interface with a generative foundation model such as an LLM to send relevant information to the generative foundation model for final execution, the API interface return parameters need to be converted into prompts acceptable to the generative foundation model; that is, configuration conversion.

[0165] Based on this, the configuration information of the transaction status can be used to successfully provide the data required during the transaction processing, thus providing data support for the entire transaction processing.

[0166] For the essential information required for handling transactions, the necessary information for the transaction is provided as specified in the unified protocol template. While the delivery of this information can take any appropriate form, to process, manage, and maintain this information more efficiently, in one optional embodiment of this application, when generating information indicating the necessary information for the transaction to be acquired based on the necessary information of the instance, the form information of the form required for the transaction processing corresponding to the instance is determined based on the basic information of the instance; based on the form information and the validation information used to validate the data in the form, the necessary information indicating the transaction to be acquired is generated. The form information clearly shows the name, type, whether it is required, required format, and other simple and easy-to-explain information of the necessary information. Some of this information can be obtained through user interaction. For example, the user can fill in relevant information through a human-computer interaction interface, and then this information is passed to the cloud server as part of the basic information of the aforementioned instance for use in generating the necessary information for the transaction. Alternatively, when generating a transaction processing flow instance, the cloud server can interact with the user device again, receive user input through the user device, and generate the necessary information for the transaction based on the relevant information input by the user. Furthermore, since there may be errors in the form information, validation information is also set up for this part to verify whether there are any errors or abnormal data in the necessary information of the above transactions, so as to ensure the normal processing of subsequent transactions.

[0167] Optionally, when determining the form information of the form required for the transaction processing of the instance based on the instance's basic information, in order to improve the efficiency of subsequent data processing, in one optional approach, the form item name of at least one form item in the form required for the transaction processing of the instance can be determined based on the instance's basic information; for each form item, a form item description is generated based on the current form item name, and the type, whether it is a required item, and the format of the form item corresponding to the current form item name are determined.

[0168] Furthermore, to ensure the overall correctness of the form data, in one optional approach, generating information indicating the necessary information for the transaction to be acquired, based on the form information and the validation information used to validate the data in the form, can be implemented as follows: for each form item, generating a validation configuration for the current form item based on the type of the form item, whether it is a required item, and the format of the form item; generating a total validation configuration for the form based on the validation configurations of all form items; and generating information indicating the necessary information for the transaction to be acquired based on the validation configurations of each form item and the total validation configuration.

[0169] It should be noted that the specific verification methods corresponding to the verification configurations for each form item and the overall verification configuration described above can be flexibly set by those skilled in the art according to actual needs, and the embodiments of this application do not impose any limitations on this. For example, the use of verification algorithms or machine learning models with verification functions, etc., are all applicable to the solutions of the embodiments of this application.

[0170] Once the basic information of the transaction, the transaction's operation configuration information, the configuration information for obtaining transaction status information, and the information for indicating the necessary information of the transaction to be obtained have all been generated, the transaction processing flow instance required by the user can be generated by combining the preset prompt information template.

[0171] In practical applications, the activation of a transaction processing flow instance is typically achieved through registration. Therefore, various configuration details for a transaction processing flow instance can be registered to add the corresponding transaction processing flow to the system. Subsequently, when the corresponding transaction processing is required, the transaction processing flow instance is invoked to combine with the generative base model and perform the appropriate transaction processing.

[0172] This embodiment enables the generation of transaction processing flow instances based on a unified protocol template. Because the unified protocol template standardizes various configuration information, the generated transaction processing flow instances are more standardized and interpretable. Furthermore, since different transaction processing flow instances are all generated based on the same unified protocol template, the instances are more universal and standardized, improving their reusability.

[0173] Based on the generated transaction processing flow example, the transaction processing method of this application embodiment will be described below from the perspective of transaction processing.

[0174] Reference Figure 3 The diagram illustrates a flowchart of the steps of a transaction processing method for performing transaction processing according to an embodiment of this application.

[0175] The transaction processing method in this embodiment includes the following steps:

[0176] Step S302: Receive user input for interacting with the generative base model.

[0177] The user input contains information about the transactions to be processed.

[0178] User interaction with generative base models such as LLMs is typically achieved through a human-computer interface (HCI). Users input their requests or instructions, such as "I want to request leave" or "I want to change shifts," through input fields on the HCI interface. This input usually carries information about the pending transaction, such as "leave" or "shift change," thus allowing the information to be obtained from the user's input.

[0179] Step S304: Based on the information of the transaction to be processed, call the corresponding transaction processing flow instance.

[0180] The transaction processing flow instance is generated according to a unified protocol template for transaction processing. This unified protocol template is a template that generates a transaction processing flow instance that can interact with the generative base model based on various configuration information obtained from input information and based on this configuration information. For example, the unified protocol template can be the unified protocol template described above, where the various configuration information includes at least: basic transaction information, transaction runtime configuration information, configuration information for obtaining transaction status information, information indicating the necessary information for the transaction to be obtained, and a preset prompt information template.

[0181] In practical implementation, since the information of the transaction to be processed can indicate what kind of transaction processing should be performed, and the basic information of the transaction in the transaction processing flow instance includes the transaction name information, transaction description information, etc., the two can be matched to determine the corresponding transaction processing flow instance for the transaction to be processed, and the transaction processing flow instance is invoked to process the transaction to be processed. However, this is not limited to this; other methods of determining and invoking the transaction processing flow instance based on the information of the transaction to be processed are also applicable to the scheme of the embodiments of this application.

[0182] In an alternative approach, to more accurately match and invoke transaction processing flow instances, intent recognition can be performed first based on the information of the transaction to be processed; then, based on the intent recognition result, the corresponding transaction processing flow instance can be invoked. The specific implementation of intent recognition can be achieved by those skilled in the art using any appropriate algorithm or machine learning model according to actual needs, and this application embodiment does not impose any limitations on this. Because user input is random and uncertain—for example, if a user inputs "I'm sick and can't go to work," their intent might be to request sick leave. Directly determining the corresponding transaction processing flow instance based solely on "I'm sick and can't go to work" might lead to anomalies or failure to effectively confirm the intent. However, by recognizing the intent as requesting sick leave, an instance for processing sick leave can be matched more accurately, improving the efficiency and fault tolerance of transaction processing.

[0183] Step S306: Using a transaction processing flow instance and a generative basic model, perform transaction processing on the transaction to be processed.

[0184] The transaction processing instance can interact with users and generative base models such as LLM throughout the entire transaction processing process, and also has the function of obtaining relevant information for transaction processing (such as transaction status information, necessary information of the transaction, etc.) for subsequent use by the generative base model.

[0185] In one optional approach, regarding the transaction status information, the transaction status information and necessary information associated with the transaction to be processed can be obtained through a transaction processing flow instance. Based on the transaction status information, necessary information, and user input, a prompt is generated. This prompt is then input into a generative base model (LLM) to process the transaction. Optionally, the transaction status information includes at least one of the following: historical dialogue records between the user and the generative base model (LLM) corresponding to the user input, or auxiliary data obtained from queries based on user input. This auxiliary data includes, but is not limited to, extracted transaction processing information and queried transaction memories. By including both the transaction status information and necessary information in the prompt, the LLM has more processing data to support its reasoning and thus achieves efficient and objective transaction processing.

[0186] While transaction processing can be completed in some cases through a single round of dialogue between the user and the generative base model, in most cases, the dialogue typically involves multiple rounds (two or more). That is, through a transaction processing flow example, using a generative base model such as an LLM, the transaction processing involves multiple rounds, each round including further interaction between the user and the generative base model such as the LLM, and / or, further acquisition of transaction state information. This not only ensures the normal implementation of transaction processing but also enables the acquisition of more targeted and timely transaction state information.

[0187] In this scenario, for each round of processing, prompts are regenerated based on the interaction data from the next round of interaction and / or the transaction status information obtained again. A generative base model, such as LLM, is used to process the transaction to be processed based on the regenerated prompts, obtaining intermediate transaction processing data. Based on the intermediate transaction processing data, as well as the interaction data input for the next round of processing and / or the transaction status information for the next round of processing, new prompts are generated, enabling the generative base model, such as LLM, to process transactions based on the new prompts until the final round.

[0188] For example, if data retrieved through an API interface triggers a new round of queries, new transaction status information will be obtained again, generating a new prompt message for LLM processing. Alternatively, if the user needs to further select or confirm information during transaction processing, the user can be interacted with again through the human-computer interface to obtain interaction data for the second interaction. A new prompt will then be generated based on this data and processed by the LLM. It should be noted that if a further round of dialogue is required based on the second interaction and / or the second data retrieval, the LLM's output corresponding to this second interaction and / or second data retrieval will be used as intermediate data in the transaction processing and carried in the next round's prompt for LLM use. In one example, if the user's leave period is entered as January 1, 2024 - January 5, 2024, and the reason for leave is annual leave. If, based on the obtained transaction status information, it is determined that the user has only 1 day of annual leave remaining, the user will be informed of this information through the human-computer interaction interface, and the user's modification will be accepted. For example, if the leave period is changed to January 1, 2024 - January 2, 2024, this new modification information will be the interaction data for the next interaction, and it will be carried in a new prompt and handed over to the LLM for use.

[0189] Furthermore, a user may need to handle two or more transactions simultaneously, such as needing to take leave and change shifts, or wanting to convert one transaction into another. In this case, the system needs to be able to efficiently switch transaction processing flow instances. Therefore, in one optional approach, it can also receive new user input; based on the new user input, determine to switch the current transaction processing flow instance to the transaction processing flow instance corresponding to the new user input; and use the switched transaction processing flow instance, using a generative basic model, to perform transaction processing on the new user input for the transaction to be processed. The reception of new user input may occur after the previous transaction is completed or during the previous transaction processing; this embodiment does not limit the timing of instance switching.

[0190] New user input also carries information about new pending transactions. Based on this, a corresponding new transaction processing flow instance can be determined. Using this new transaction processing flow instance, combined with the generative basic model, the new pending transactions can be processed.

[0191] It should be noted that in one optional method, when switching instances, all information related to the previous instance is archived and cleared, including transaction status information and necessary transaction information, to ensure that new pending transactions can be processed smoothly. However, this is not the only option. Because the data involved for the same user is highly correlated, in another optional method, it can be determined whether adjacent instances use overlapping data. If so, the data obtained from the previous instance can be used to avoid duplicate operations. For example, if a user wants to take leave from January 1st to January 2nd, 2024, and needs to swap shifts with other colleagues during this period, the date saved in the leave transaction processing instance can be used as the time basis for finding colleagues who can swap shifts in the shift swap processing instance. That is, colleagues who do not have shift duties during that date can be considered as shift swap candidates.

[0192] In addition, exit mechanisms, filtering mechanisms, and delay mechanisms can be set for transaction processing. An exit mechanism means that if an exit command is received after or during transaction processing, the current transaction processing instance will exit, and the generative base model's processing of the current transaction will terminate. A filtering mechanism means that if input unrelated to the current transaction is received during transaction processing (possibly due to user error or other reasons), the input will be filtered and not processed. A delay mechanism means that if a user pauses transaction processing or fails to respond to system-required interactions within a certain timeframe before processing is complete, a delay state will be entered. The transaction processing flow will resume only after the user restarts or performs the required interaction. These mechanisms make transaction processing more complete and comprehensive.

[0193] If a transaction is successfully completed through its corresponding transaction processing flow instance and generative basic model, such as a successful leave request, then optionally, the corresponding transaction status information can be updated based on the transaction processing result after confirming that the transaction processing has been completed normally, so as to ensure the timeliness and accuracy of the transaction status information.

[0194] As can be seen, this embodiment employs a method of using transaction processing flow instances generated based on a unified protocol template, combined with a generative basic model, to process transactions. The unified protocol template can be considered a standard or specification for generating transaction processing flow instances; regardless of the type of transaction, the processing flow is written according to this template. Therefore, on the one hand, because different transaction processing flow instances are generated based on the same unified protocol template, the instances are more universal and standardized, improving their reusability. On the other hand, the unified protocol template includes settings for obtaining various configuration information for transaction processing based on input information, and generating transaction processing flow instances that can interact with the generative basic model based on these configuration information. These settings apply to all transaction processing, unifying both the instance generation standard and the instance interpretation standard. Furthermore, this makes the interaction between transaction processing flow instances generated based on the unified protocol template and the generative basic model more consistent and standardized.

[0195] The solution in this embodiment enables transaction processing based on generative base models, such as LLM, to be implemented even in different fields and scenarios. This can be achieved by combining generative base models with standardized and interpretable transaction processing flow instances. This not only improves the efficiency of using generative base models to achieve intelligence in different fields and scenarios and reduces implementation costs, but also ensures the standardization, consistency and interpretability of the implementation code, and facilitates subsequent code reuse.

[0196] This application also provides a transaction processing system, such as... Figure 4A As shown.

[0197] Figure 4A The transaction processing system shown includes: a unified protocol module 402, a session management module 404, and an AI (Artificial Intelligence) thinking module 406.

[0198] in:

[0199] The unified protocol module 402 is used to provide a unified protocol template and generate a corresponding transaction processing process instance according to the information of the transaction processing process instance to be generated. The unified protocol template is a template that generates a transaction processing process instance that can interact with the generative basic model based on the various configuration information obtained from the input information for transaction processing.

[0200] AI thinking module 406 is used to receive user input for interacting with the generative base model, wherein the user input carries information about the transaction to be processed; based on the information about the transaction to be processed, it calls the corresponding transaction processing flow instance to obtain the transaction status information associated with the transaction to be processed through the session management module 404, and generates prompt information based on the user input and transaction status information, so that the generative base model can perform transaction processing on the transaction to be processed according to the prompt information.

[0201] The specific implementation of each template function can be found in the description of the corresponding function in the foregoing embodiments, and will not be repeated here.

[0202] However, for easier understanding, the transaction processing system of this embodiment will be illustrated below with a specific example, such as... Figure 4B As shown.

[0203] Figure 4B In the unified protocol module 402, a unified protocol template defines a standardized protocol. To add a new transaction processing flow, simply create a transaction processing flow instance according to this protocol, and the corresponding transaction processing flow will be automatically generated based on the protocol. After the developer generates the transaction processing flow instance according to the specifications in the unified protocol template and adds it to the overall system framework, the transaction processing flow instance will play a role in the AI ​​thinking module 406 and the session management module 404.

[0204] The session management module 404, as defined by the protocol, obtains multi-turn dialogues between the generative base model and the user within a single transaction processing flow, assisting in transaction processing. It includes functions such as acquiring transaction state information, filtering irrelevant information, intent recognition, and switching between transaction processing. At the start of the interaction between the user and the generative base model, the transaction processing flow instance initializes the dialogue state, including user identification, dialogue context, and scene information; the transaction processing flow instance receives user input and hands it over to the AI ​​thinking module 406 for semantic understanding and information extraction (the above process is...). Figure 4B (Simply illustrated as "process configuration"). The conversation management template updates the dialogue status in real time with a 404 error, including filtering irrelevant information, retaining key dialogue nodes, and performing intent recognition and switching in multi-intent scenarios. Figure 4B This is simply illustrated as "intent recognition" to ensure the coherence and purposefulness of the conversation. Furthermore, when a user... Figure 4BAfter the human-computer interaction module inputs relevant transaction processing information, the routing module routes the information to the session management module 404. The session management module 404 then performs matching processing according to a matching strategy (if related to the current transaction, it processes the information based on the current transaction processing flow instance; if unrelated to the current transaction, it matches a new, suitable transaction processing flow instance, etc.). Figure 4B (This is simply illustrated as a "matching strategy"). Furthermore, it records transaction status information based on the current transaction processing progress. Figure 4B This is simply illustrated as a "status record" and can be used to update transaction status information later. When the transaction processing flow termination condition is detected (transaction completed or an instruction to exit the current transaction processing is received), the system will organize the dialogue record, perform archiving and clearing operations, and prepare to end the dialogue (determined according to the "process configuration").

[0205] The AI ​​thinking module 406, as specified in the protocol, performs transaction memory retrieval based on user input and transaction status information during single-turn dialogue processing. Figure 4B In simple terms, this is represented as "transaction memory query". The generative basic model is based on the transaction memory query results and the obtained transaction state information ( Figure 4B In a simplified diagram, this is referred to as "transaction status information extraction." The system extracts necessary information about the transaction from user input and assists in transaction processing. In each round of dialogue, the transaction processing flow instance constructs a prompt message based on the prompt message template in the unified protocol template. This prompt message includes user input, basic transaction information, transaction runtime configuration information, configuration information for obtaining transaction status information, and necessary information indicating the transaction to be obtained. The AI ​​thinking module 406 utilizes transaction memory (i.e., relevant information and constraint rules contained in the database / table) and a generative basic model to analyze user input, identify and extract keywords, entities, and attribute values ​​directly related to transaction processing, supplement or confirm transaction processing details, request missing information from the user through dialogue, confirm the correctness of extracted information, and prompt the user for input that does not conform to the transaction memory, ensuring the accuracy of transaction processing. Figure 4B (Simply illustrated as "status verification"). The generative basic model, based on the transaction logic processing results and historical dialogue records in the transaction status information, generates appropriate response content to guide the user into the next round of dialogue or complete the current transaction. After all information is collected, the AI ​​thinking module 406 transmits this information to the cloud server to execute specific transaction processing operations, such as submitting for approval or making an appointment. Furthermore, the AI ​​thinking module 406 also updates the transaction status information it has obtained based on the transaction status information records sent by the session management module 404. Figure 4B (This is simply illustrated as "transaction status update").

[0206] For the unified protocol module 402, an exemplary process for creating a transaction processing flow instance is as follows: Figure 4C As shown, it includes process 402-1: Based on the unified protocol template, write a transaction processing flow example, including: writing the basic information of the transaction and the transaction's runtime configuration information; writing the information of the data tables and / or API interfaces required for transaction processing, including various types of information and their attributes that need to be submitted during transaction processing (providing a basis for generating configuration information for obtaining transaction status information); writing the transaction memory query table, including the transaction memory name, description, interface, input parameters, etc. that the transaction processing may query (providing a basis for generating configuration information for obtaining transaction status information); and writing the necessary information of the transaction (providing a basis for generating information indicating the necessary information of the transaction to be obtained). Process 402-2: Register corresponding values ​​according to each part of the written transaction processing flow instance, including: registering basic transaction information and transaction operation configuration information, such as registering to the session management module 404; registering information on the data tables and / or API interfaces required for transaction processing so as to extract the corresponding transaction processing information according to the data tables and / or API interfaces, such as registering to the AI ​​thinking module 406; registering a transaction memory lookup table so that a query can be performed according to the table when the query conditions are met, and the query results are processed and handed over to the generative basic model such as LLM, for example, it can be registered to the AI ​​thinking module 406.

[0207] For session management module 404, an exemplary runtime session management process is as follows: Figure 4D As shown, it includes process 404-1: User requests entry and inputs information; process 404-2: Determine if a transaction is currently being processed; when a user enters for the first time, intent recognition is performed based on the user input to determine the existence and validity of the intent. Only if the intent matches a registered transaction processing instance will the user input be routed to the corresponding transaction processing instance; subsequently, the user enters the corresponding transaction processing process; process 404-3: Relevant transaction status information is obtained and processed by the AI ​​thinking module 406; if it is determined that a transaction processing process needs to be switched, the transaction status is switched, including archiving and clearing the dialogue history, converting the common transaction memory of the two transactions, and converting the collected relevant transaction processing information; process 404-4: If the user requests to exit the transaction processing process or the transaction processing process times out, the transaction status information is cleared and the user exits; otherwise, the transaction status information is saved normally; a response is returned to the user.

[0208] For AI thinking module 406, an exemplary runtime AI thinking process is as follows: Figure 4EAs shown, it includes process 406-1: In a single-turn dialogue, the user requests entry and provides new user input; process 406-2: Obtain the transaction status information of the currently processed transaction through the current transaction processing flow instance; process 406-3: Based on the transaction status information, determine whether the new user input is related to the currently processed transaction. If related, proceed to process 406-4; otherwise, proceed to process 406-12; process 406-4: Through the current transaction processing flow instance, query and obtain the transaction memory, and combine it with the new user input to generate a prompt; process 406-5: Based on the prompt, LLM extracts information related to the currently processed transaction from the new user input and extracts the transaction memory for inference generation; process 406-6: Based on the inference generation result, update the transaction status information of the current transaction; process 406-7: Based on the inference generation result, determine whether it is necessary to query the new transaction memory. If yes, proceed to process 406-8; otherwise, proceed to process 406-9; process 406-8: Determine whether the current query meets the query termination condition. If yes, proceed to the next step. Procedure 406-9: If not, return to procedure 406-4; Procedure 406-9: Process the obtained transaction processing information and query values, and update the transaction status information; Procedure 406-10: Determine whether the transaction can be committed based on the current transaction processing flow instance; if yes (i.e., commit), commit the transaction processing result and mark the transaction as completed; if not, proceed to procedure 406-11; Procedure 406-11: Determine whether the number of dialogue rounds has exceeded the maximum acceptable number of dialogue rounds based on the current transaction processing flow instance. If the timeout period is exceeded, the transaction is marked as timeout; if the timeout period is not exceeded, the transaction is marked as continue. Process 406-12: Determine whether a transaction processing flow instance switch is needed; if yes, perform an instance switch; if no, determine whether to exit the current transaction processing flow. Process 406-13: If the result is to exit the current transaction processing flow, the transaction is marked as exit. Process 406-14: If the result is not to exit the current transaction processing flow, filter out new user input. Process 406-15: Leave the AI ​​thinking dialogue.

[0209] As seen in the above process of AI Thinking Module 406, it can determine whether the current user input is for exiting the process, irrelevant input, switching processes, or continuing processing based on the information in the transaction processing flow instance. For the first three, if the determination result is yes, the operations of exiting transaction processing, filtering irrelevant input, and switching transaction processing are executed respectively, and the user leaves the AI ​​Thinking dialogue. For continuing processing, if the determination result is yes, the user can normally enter the next stage. If it is necessary to switch transaction processing, i.e., switch transaction processing flow instances, the transaction status information is switched, including clearing the dialogue record, converting the common transaction memory of the two flow instances, and converting the collected relevant transaction processing information, etc.

[0210] If the query is determined to be based on user input and retrieved relevant information, a prompt can be generated based on this information to assist the LLM in extracting new transaction-related information. Furthermore, if, based on the query table defined within the transaction processing instance, it is determined that newly extracted information requires a new round of querying, a new query is performed, the transaction status information is updated, and a new prompt is generated to assist the LLM in extracting information, proceeding in a cyclical manner. After the transaction processing is completed, the extracted information and responses can be processed, and the response value is returned.

[0211] In the above process, an example of the preset prompt message template in the unified protocol template is shown below:

[0212]

[0213]

[0214] The "Content" section in the table above specifies the information that should be included in the prompt, while the "Example" section uses a leave request as an example to illustrate the "Content" section.

[0215] Based on this, a prompt template and a sample prompt generated from the template are shown below:

[0216] #Role

[0217] You are the "${schema.label} assistant" and "${schema.description}" of the XX application.

[0218] #Current Date

[0219] ${context.currentTime}

[0220] #foreach($result in${memories})

[0221] #${result.name}

[0222] ${result.result}

[0223] #end

[0224] #Historical Dialogue Records

[0225] #foreach($msg in${historyMessages})

[0226] ${msg}

[0227] #end

[0228] #Your Task

[0229] You need to extract the user's ${schema.label} information based on historical conversation records.

[0230] - You must output in JSON format.

[0231] - You need to extract the following ${schema.submitFormsSize} pieces of information:

[0232] #foreach($form in${schema.submitForms})

[0233] --${form.line}

[0234] #end

[0235] - When the user's input is insufficient, you need to guide the user.

[0236] #foreach($logic in${schema.logics})

[0237] -${logic}

[0238] #end

[0239] - Set fields that cannot be extracted to blank strings.

[0240] #Format

[0241] json

[0242] {

[0243] #foreach($form in${schema.submitForms})

[0244] ${form.shortLine}

[0245] #end

[0246] "allCollected":" / *true if ${schema.submitFormsSize} information has been collected and the leave application conditions are met, otherwise false* / ",

[0247] "reply":" / *Information that needs to be replied to the user* / "

[0248] }

[0249] ```

[0250] #start

[0251] Please extract the leave request information from the above historical chat log. Your output should be:

[0252] Based on the above prompt template, taking "Leave Request" as an example, the generated prompt is as follows:

[0253] #Role

[0254] You are the "Leave Request Assistant" for XX app, helping users submit leave requests.

[0255] #Current Date

[0256] 2024-07-31 09:00:00

[0257] #User scheduling information obtained from the query

[0258] 2024-07-31 09:30 to 12:00

[0259] 2024-07-31 13:30 to 18:00

[0260] # User's holiday balance obtained from the query

[0261] Sick leave: No restrictions

[0262] Annual leave: 5 days

[0263] Personal leave: 200 hours

[0264] #Historical Dialogue Records

[0265] [User](2024-07-31 09:13:56) I need to request leave.

[0266] [AI](2024-07-31 09:14:00) Hello! It seems you want to apply for leave. What type of leave do you plan to take (e.g., annual leave, sick leave, etc.)? Also, please provide the duration of your leave and the reason for your leave.

[0267] [User](2024-07-31 09:14:15) What is my work schedule for today?

[0268] [AI](2024-07-31 09:14:19) Your work schedule today consists of two shifts: the first is from 09:30 to 12:00, and the second is from 13:30 to 18:00. Which of these two shifts do you plan to take leave during, and what is the type of leave and reason for it?

[0269] [User](2024-07-31 09:14:23) Just the first paragraph. I'm sick.

[0270] #Your Task

[0271] - You need to extract the user's leave request information from historical conversation records.

[0272] - You must output in JSON format.

[0273] - You need to extract the following 4 pieces of information:

[0274] --Holiday type, required

[0275] --Start time, required, output format: yyyy-MM-dd HH:mm

[0276] --End time, required. Output format: yyyy-MM-dd HH:mm

[0277] --Reason for leave (required)

[0278] - When the user's input is insufficient, you need to guide the user.

[0279] - If a user inquires about remaining vacation time or work schedule, the corresponding information must be included in the reply.

[0280] - If the leave time is not within the scheduled work hours, you must confirm with the user.

[0281] - Set fields that cannot be extracted to blank strings.

[0282] #Format

[0283] json

[0284] {

[0285] "leaveType":" / *Vacation type* / ",

[0286] "startTime":" / *Start Time* / ",

[0287] "endTime":" / *End Time* / ",

[0288] "reason":" / *Reason for leave* / ",

[0289] "allCollected":" / *True if all four pieces of information have been collected and the leave application conditions are met; otherwise, false* / ",

[0290] "reply":" / *Information that needs to be replied to the user* / "

[0291] }

[0292] ```

[0293] #start

[0294] Please extract the leave request information from the above historical chat log. Your output should be:

[0295] As shown above, through transaction processing flow examples, the interaction between the generative basic model and the user, as well as the generation of prompts for the generative basic model (through prompt templates), can be effectively realized, achieving intelligent, efficient, fast and accurate transaction processing.

[0296] The transaction processing system in this embodiment achieves efficient multi-turn dialogue transaction processing with integrated transaction memory. It optimizes the human-computer interaction experience through a unified protocol module, a session management module, and an AI thinking module, improves the efficiency of using generative basic models to achieve intelligence in different fields and scenarios, reduces implementation costs, ensures the standardization, consistency, and interpretability of the implementation code, and facilitates subsequent code reuse.

[0297] First, in the development phase, the unified protocol template in the unified protocol module abstracts various transaction processing processes, allowing for rapid standardized access and expansion, improving the flexibility and response speed of AI services, and enhancing the reusability of transaction processing.

[0298] Secondly, in the runtime state, the unified protocol template specifies how each module functions, including: through the AI ​​thinking module, actively querying and utilizing "transaction memory" based on user input, that is, accessing the database / table to obtain relevant information based on the user's dynamic needs, ensuring that the AI ​​response matches the user's actual transaction processing scenario, solving the inefficiency and error problems caused by the lack of real-time knowledge in traditional methods; through the conversation management module, intelligently filtering irrelevant information in multiple rounds of dialogue, switching transaction processing process instances and saving dialogue states, ensuring clear dialogue focus, improving anti-interference ability, information extraction accuracy and transaction processing efficiency.

[0299] Reference Figure 5 This document illustrates a schematic diagram of an electronic device according to an embodiment of this application. The specific embodiments of this application do not limit the specific implementation of the electronic device.

[0300] like Figure 5 As shown, the electronic device may include: a processor 502, a communications interface 504, a memory 506, and a communications bus 508.

[0301] in:

[0302] The processor 502, communication interface 504, and memory 506 communicate with each other via communication bus 508.

[0303] Communication interface 504 is used to communicate with other electronic devices or servers.

[0304] The processor 502 is used to execute program 510, which can specifically execute the relevant steps of any of the above-described method embodiments.

[0305] Specifically, program 510 may include program code that includes computer operation instructions.

[0306] The processor 502 may be a CPU, a GPU (Graphics Processing Unit), an Application Specific Integrated Circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application. The electronic device includes one or more processors, which may be processors of the same type, such as one or more CPUs; or they may be processors of different types, such as one or more CPUs and one or more ASICs.

[0307] Memory 506 is used to store program 510. Memory 506 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage device.

[0308] Program 510 may include multiple computer instructions. Specifically, program 510 may use multiple computer instructions to cause processor 502 to perform the operation corresponding to the method described in any of the foregoing multiple method embodiments.

[0309] The specific implementation of each step in program 510 can be found in the corresponding steps and units described in the above method embodiments, and has corresponding beneficial effects, which will not be repeated here. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the devices and modules described above can be referred to the corresponding process descriptions in the foregoing method embodiments, and will not be repeated here.

[0310] This application also provides a computer storage medium storing a computer program thereon, which, when executed by a processor, implements the method described in any of the foregoing method embodiments. The computer storage medium includes, but is not limited to, compact disc read-only memory (CD-ROM), random access memory (RAM), floppy disk, hard disk, or magneto-optical disk.

[0311] This application also provides a computer program product, including computer instructions that instruct a computing device to perform an operation corresponding to any of the methods in the above-described multiple method embodiments.

[0312] Furthermore, it should be noted that the user-related information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data on user interaction with transaction processing instance, data on user interaction with generative base model, sample data used for model training, data used for analysis, stored data, displayed data, etc.) involved in the embodiments of this application are all information and data authorized by the user or fully authorized by all parties. Moreover, the collection, use and processing of related data must comply with the relevant laws, regulations and standards of relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0313] It should be noted that, depending on the implementation needs, the various components / steps described in the embodiments of this application can be broken down into more components / steps, or two or more components / steps or parts of the operation of components / steps can be combined into new components / steps to achieve the purpose of the embodiments of this application.

[0314] The methods described in the embodiments of this application can be implemented in hardware, firmware, or as software or computer code that can be stored in a recording medium (such as a CD-ROM, RAM, floppy disk, hard disk, or magneto-optical disk), or as computer code originally stored on a remote recording medium or a non-transitory machine-readable medium and subsequently stored on a local recording medium, downloaded over a network. Thus, the methods described herein can be stored on a recording medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware (such as an Application Specific Integrated Circuit (ASIC) or a Field Programmable Gate Array (FPGA)). It is understood that the computer, processor, microprocessor controller, or programmable hardware includes storage components (e.g., Random Access Memory (RAM), Read-Only Memory (ROM), Flash Memory, etc.) capable of storing or receiving software or computer code, which, when accessed and executed by the computer, processor, or hardware, implements the methods described herein. Furthermore, when a general-purpose computer accesses code used to implement the methods shown herein, the execution of the code transforms the general-purpose computer into a dedicated computer for executing the methods shown herein.

[0315] Those skilled in the art will recognize that the units and method steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the embodiments of this application.

[0316] The above embodiments are only used to illustrate the embodiments of this application, and are not intended to limit the embodiments of this application. Those skilled in the art can make various changes and modifications without departing from the spirit and scope of the embodiments of this application. Therefore, all equivalent technical solutions also fall within the scope of the embodiments of this application, and the patent protection scope of the embodiments of this application should be defined by the claims.

Claims

1. A transaction processing method, comprising: Receive user input for interacting with the generative base model, wherein the user input carries information about the transaction to be processed; Based on the information of the transaction to be processed, the corresponding transaction processing process instance is invoked. The transaction processing process instance is generated according to a unified protocol template for transaction processing. The unified protocol template is a template for generating a transaction processing process instance that can interact with the generative basic model based on the multiple configuration information obtained from the input information. Using the aforementioned transaction processing flow instance and the generative basic model, the pending transaction is processed.

2. The method according to claim 1, wherein, The step of processing the pending transaction using the generative basic model through the transaction processing flow instance includes: Through the transaction processing flow instance, obtain the transaction status information and necessary information of the transaction associated with the transaction to be processed; Based on the transaction status information, the necessary information of the transaction, and the user input, a prompt message is generated; The prompt information is input into the generative base model to process the pending transaction through the generative base model.

3. The method according to claim 2, wherein, The transaction status information includes at least one of the following: the historical dialogue records between the user corresponding to the user input and the generative base model, and auxiliary data obtained based on the query of the user input.

4. The method according to any one of claims 1-3, wherein, The transaction processing through the transaction processing flow instance, using the generative basic model to process the transaction to be processed, includes multiple rounds of processing. Each round of processing includes further interaction between the user and the generative basic model, and / or, further acquisition of the transaction status information. For each round of processing, the prompt message is regenerated based on the interaction data from the next interaction and / or the transaction status information obtained again; Using the generative base model, the pending transaction is processed based on the regenerated prompt information to obtain intermediate transaction processing data; based on the intermediate transaction processing data, the interaction data input for the next round of processing, and / or the transaction status information for the next round of processing, new prompt information is generated so that the generative base model processes the transaction based on the new prompt information until the final round.

5. The method according to any one of claims 1-3, wherein, The method further includes: Receive new user input; Based on the new user input, determine to switch the current transaction processing instance to the transaction processing instance corresponding to the new user input; Using the switched transaction processing instance, and the generative base model, perform transaction processing on the new user input for the transaction to be processed.

6. The method according to any one of claims 1-3, wherein, The method further includes: If it is determined that the transaction processing has been completed normally, the corresponding transaction status information is updated according to the processing result of the transaction processing.

7. The method according to any one of claims 1-3, wherein, The unified protocol template includes at least the following configuration information: basic transaction information, transaction operation configuration information, configuration information for obtaining transaction status information, information for indicating the necessary information of the transaction to be obtained, and a preset prompt information template.

8. The method according to any one of claims 1-3, wherein, The step of invoking the corresponding transaction processing flow instance based on the information of the transaction to be processed includes: Intent identification is performed based on the information of the transaction to be processed; Based on the intent recognition result, the corresponding transaction processing flow instance is invoked.

9. A transaction processing method, comprising: Obtain information about the transaction processing flow instance to be generated, and obtain a unified protocol template for transaction processing. The unified protocol template is a template for generating a transaction processing flow instance that can interact with the generative basic model based on the multiple configuration information obtained from the input information. Based on the information of the transaction processing flow instance to be generated, a corresponding transaction processing flow instance is generated according to the unified protocol template.

10. The method according to claim 9, wherein, The information of the transaction processing process instance to be generated includes: basic information of the instance corresponding to the transaction processing process instance to be generated, runtime configuration information of the instance, information of the data table and / or application programming interface (API) corresponding to the instance, and necessary information of the instance. The unified protocol template includes at least the following configuration information: basic transaction information, transaction operation configuration information, configuration information for obtaining transaction status information, information for indicating the necessary information of the transaction to be obtained, and a preset prompt information template.

11. The method according to claim 10, wherein, The step of generating a corresponding transaction processing flow instance according to the unified protocol template based on the information of the transaction processing flow instance to be generated includes: Generate the basic information of the transaction based on the basic information of the instance; The runtime configuration information of the transaction is generated based on the runtime configuration information of the instance; Based on the data table and application programming interface (API) information corresponding to the instance, generate the configuration information used to obtain transaction status information; Based on the necessary information of the instance, generate the information used to indicate the necessary information for the transaction to be acquired; A transaction processing flow instance is generated based on the basic information of the transaction, the operation configuration information of the transaction, the configuration information for obtaining transaction status information, the information for indicating the necessary information of the transaction to be obtained, and the preset prompt information template.

12. The method according to claim 11, wherein, The basic information of the instance includes the name information of the transaction processing corresponding to the instance; The step of generating the basic information of the transaction based on the basic information of the instance includes: Based on the name information of the transaction, and in accordance with the transaction logic prompt rules in the unified protocol template, transaction logic prompt information is generated for the transaction; Based on the transaction name information and the transaction logic prompt information, the basic information of the transaction is generated.

13. The method according to claim 12, wherein, The method further includes: generating transaction description information for the transaction process according to the transaction description rules in the unified protocol template, based on the name information of the transaction process; The step of generating basic information of the transaction based on the name information of the transaction and the logic prompt information of the transaction includes: generating basic information of the transaction based on the name information of the transaction, the description information of the transaction, and the logic prompt information of the transaction.

14. The method according to claim 11, wherein, The instance's runtime configuration information includes: whether transaction switching is allowed, and the maximum number of dialogue rounds allowed for a single transaction. The step of generating the transaction's runtime configuration information based on the instance's runtime configuration information includes: generating the transaction's runtime configuration information based on information regarding whether transaction switching is allowed and information regarding the maximum number of dialogue rounds allowed for a single transaction.

15. The method according to claim 14, wherein, The method further includes: obtaining information about the transaction commit interface of the transaction, wherein the transaction commit interface is used to submit the prompt information generated by the transaction processing instance during the transaction processing to the generative basic model; The step of generating the transaction's runtime configuration information based on the information regarding whether transaction switching is allowed and the information regarding the maximum number of dialogue rounds allowed for a single transaction includes: generating the transaction's runtime configuration information based on the information regarding whether transaction switching is allowed, the information regarding the maximum number of dialogue rounds allowed for a single transaction, and the information regarding the transaction commit interface.

16. The method according to claim 11, wherein, The step of generating the configuration information for obtaining transaction status information based on the data table and application programming interface (API) information corresponding to the instance includes: Based on the table name information of the data table and the basic information of the transaction, generate query description information for the data table; Based on the information from the API, the interface name, interface category, and input parameters of the API are obtained, and a transformation configuration is generated based on the return parameters of the API; wherein, the transformation configuration is used to generate prompt information for interacting with the generative model based on the return parameters; Based on the data table name, the query description information, the interface name, the interface category, the input parameters, and the conversion configuration, the configuration information for obtaining transaction status information is generated.

17. The method according to claim 11, wherein, The step of generating the necessary information for indicating the transaction to be acquired based on the necessary information of the instance includes: Based on the basic information of the instance, determine the form information of the form required for the transaction processing corresponding to the instance; Based on the form information and the verification information used to validate the data in the form, the necessary information for indicating the transaction to be acquired is generated.

18. The method according to claim 17, wherein, The step of determining the form information of the form required for the transaction processing corresponding to the instance based on the basic information of the instance includes: Based on the basic information of the instance, determine the name of at least one form item from the form required for the transaction processing corresponding to the instance; For each form item, generate a form item description based on the current form item name, and determine the type, whether it is required, and the format of the form item corresponding to the current form item name.

19. The method according to claim 18, wherein, The step of generating the necessary information for indicating the transaction to be acquired based on the form information and the verification information used to verify the data in the form includes: For each form item, generate a validation configuration based on the item's type, whether it is required, and its format. Generate a master validation configuration for the form based on the validation configurations of all form items; Based on the validation configuration of each form item and the overall validation configuration, the necessary information for indicating the transaction to be acquired is generated.

20. A transaction processing system, comprising: Unified protocol module, session management module, and AI thinking module; in: The unified protocol module is used to provide a unified protocol template and generate a corresponding transaction processing process instance according to the information of the transaction processing process instance to be generated, based on the unified protocol template. The unified protocol template is a template for generating a transaction processing process instance that can interact with the generative basic model based on the various configuration information obtained from the input information for transaction processing. The AI ​​thinking module is used to receive user input for interacting with the generative base model, wherein the user input carries information about the pending transaction; based on the information about the pending transaction, it calls the corresponding transaction processing flow instance to obtain transaction status information associated with the pending transaction through the session management module, and generates prompt information based on the user input and the transaction status information, so that the generative base model can perform transaction processing on the pending transaction according to the prompt information.

21. An electronic device, comprising: The processor, memory, communication interface, and communication bus are provided, wherein the processor, memory, and communication interface communicate with each other via the communication bus. The memory is used to store at least one executable instruction that causes the processor to perform an operation corresponding to the method as described in any one of claims 1-8; or, the executable instruction causes the processor to perform an operation corresponding to the method as described in any one of claims 9-19.

22. A computer storage medium having a computer program stored thereon, which, when executed by a processor, implements the method as described in any one of claims 1-8; or implements the method as described in any one of claims 9-19.

23. A computer program product comprising computer instructions that instruct a computing device to perform an operation corresponding to any one of the methods described in claims 1-8; or, to perform an operation corresponding to any one of the methods described in claims 9-19.

Images