Service request processing method and device, equipment and medium

Abstract

The invention belongs to the field of artificial intelligence, and relates to a service request processing method, which comprises the following steps of: after receiving a service request of a business application layer, determining a model identifier and inputting required data by utilizing a dynamic routing engine according to a routing rule table; in combination with the model identifier and the process rule table, operation process data corresponding to a target language model is obtained through a task composer, and the target language model is a language model corresponding to the model identifier. And based on the operation process data and the input requirement data, decomposing the service request to generate a task execution sequence. And meanwhile, determining a corresponding target micro-service module from the universal component layer based on the model identifier. And executing the task in the task execution sequence through the target language model and the target micro-service module, and generating a response result of the service request. The invention further provides a device, equipment and a medium. The method can be applied to the business fields of financial insurance, medical treatment and the like, and can improve the processing efficiency of the service request.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of artificial intelligence, and is applied to online processing business scenarios such as finance and insurance, medical treatment, and the like, and in particular relates to a service request processing method and device, equipment and a medium. BACKGROUND

[0002] At present, with the rapid development of natural language processing (NLP) technology and its deep integration into various industry business scenarios, enterprises are accelerating the process of intelligent transformation, hoping to greatly improve the efficiency of business processing and the accuracy of decision-making with the help of NLP technology. Different industries have different needs for NLP technology, among which the financial insurance and medical fields are particularly typical. However, when the NLP application system gradually moves from the design stage to the actual deployment and stable operation stage, a series of key technical problems gradually emerge, which seriously restricts the flexibility and scalability of the system and also has a negative impact on the efficiency of part of the operation and maintenance work.

[0003] In the financial insurance scenario, the business involves a large amount of text data processing, such as insurance contract clause interpretation, customer consultation reply, risk assessment report generation, etc. Different insurance products and different customer groups have very different requirements for services, and require accurate and efficient language processing capabilities. When processing these service requests, traditional NLP systems often rely on static configuration or manual intervention to switch language models. For example, when processing complex insurance clause analysis, if the appropriate model cannot be automatically selected according to the specific domain knowledge and semantic complexity of the clause, the system response will be slow, and it will be difficult to quickly meet the needs of customer real-time consultation and business processing. At the same time, this inefficient model switching method also causes a great waste of computing resources, which is contrary to the goal of enterprises pursuing efficient and intelligent service processing.

[0004] In the medical scenario, NLP technology can be used for medical record analysis, medical literature retrieval, and auxiliary diagnosis, etc. Medical data is highly professional and sensitive, and different departments and different diseases have different requirements for text processing. However, when dealing with medical scenarios, traditional NLP systems also face the problem of model switching. Moreover, as the business needs become increasingly diverse, NLP application systems urgently need to have the ability to support highly customized processing flows to adapt to the special requirements of different business scenarios. However, there is an irreconcilable contradiction between customization and standardized processes. Excessive pursuit of customization will dramatically increase the complexity of system development, and in the financial insurance and medical fields, each project needs to invest a large amount of human and material resources. While overemphasizing standardized processes, it is also difficult to fully meet the diverse needs of the business in these two fields. How to realize the standardization and efficient reuse of processes while ensuring the flexibility of processing flows has become a technical problem that needs to be solved in the current NLP system development process. SUMMARY

[0005] Embodiments of the present application aim to provide a service request processing method and device, computer equipment and a storage medium, to solve the problem that the existing NLP system cannot dynamically select a model and flexibly process a process customization.

[0006] In a first aspect, a service request processing method is provided, which adopts the following technical solution:

[0007] receiving a service request initiated by a business application layer; determining a model identifier and input requirement data based on the service request and a preset routing rule table through a preset dynamic routing engine; obtaining operation process data corresponding to a target language model based on the model identifier and a preset process rule table through a preset task orchestrator, the target language model being a language model corresponding to the model identifier; decomposing the service request based on the operation process data and the input requirement data to generate a task execution sequence of the service request; determining a target microservice module corresponding to the model identifier from a preset general component layer; and executing tasks in the task execution sequence through the target language model and the target microservice module to generate a response result of the service request.

[0008] In a second aspect, a service request processing device is provided, which adopts the following technical solution:

[0009] a receiving module configured to receive a service request initiated by a business application layer;

[0010] a first determining module configured to determine a model identifier and input requirement data based on the service request and a preset routing rule table through a preset dynamic routing engine;

[0011] an obtaining module configured to obtain operation process data corresponding to a target language model based on the model identifier and a preset process rule table through a preset task orchestrator, the target language model being a language model corresponding to the model identifier;

[0012] a decomposing module configured to decompose the service request based on the operation process data and the input requirement data to generate a task execution sequence of the service request;

[0013] a second determining module configured to determine a target microservice module corresponding to the model identifier from a preset general component layer based on the model identifier;

[0014] an executing module configured to execute tasks in the task execution sequence through the target language model and the target microservice module to generate a response result of the service request.

[0015] In a third aspect, computer equipment is provided, which adopts the following technical solution:

[0016] receive a service request initiated by a service application layer; determine a model identifier and input requirement data based on the service request and a preset routing rule table through a preset dynamic routing engine; obtain operation process data of a target language model corresponding to the model identifier based on the model identifier and a preset process rule table through a preset task orchestrator, the target language model being a language model corresponding to the model identifier; decompose the service request based on the operation process data and the input requirement data to generate a task execution sequence of the service request; determine a target microservice module corresponding to the model identifier from a preset general component layer; and execute tasks in the task execution sequence through the target language model and the target microservice module to generate a response result of the service request.

[0017] In a fourth aspect, a computer-readable storage medium is provided, and the following technical solutions are adopted:

[0018] receive a service request initiated by a service application layer; determine a model identifier and input requirement data based on the service request and a preset routing rule table through a preset dynamic routing engine; obtain operation process data of a target language model corresponding to the model identifier based on the model identifier and a preset process rule table through a preset task orchestrator, the target language model being a language model corresponding to the model identifier; decompose the service request based on the operation process data and the input requirement data to generate a task execution sequence of the service request; determine a target microservice module corresponding to the model identifier from a preset general component layer; and execute tasks in the task execution sequence through the target language model and the target microservice module to generate a response result of the service request.

[0019] Compared with the prior art, the embodiments of the present application have the following beneficial effects: after receiving a service request, the model identifier and the input requirement data can be intelligently determined with the aid of the preset dynamic routing engine and the routing rule table, thereby breaking away from the limitations of traditional static configuration or manual intervention, quickly and accurately matching the optimal language model, and significantly improving the system response speed. At the same time, according to the model identifier and the process rule table, the operation process data of the target language model is obtained by the task orchestrator to decompose the service request to generate a task execution sequence, thereby ensuring the flexibility of the processing process while realizing process standardization and efficient reuse, and resolving the contradiction between the standardized process and the standardized process. Finally, the target language model and the target microservice module are used to execute tasks to generate a high-quality response result, thereby improving the processing efficiency and quality of the service request. BRIEF DESCRIPTION OF DRAWINGS

[0020] In order to more clearly illustrate the schemes in the present application, the drawings needed in the description of the embodiments of the present application will be briefly introduced. Obviously, the drawings in the following description are some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creating any creative labor.

[0021] Figure 1 is an exemplary system architecture diagram in which the present application can be applied;

[0022] Figure 2 a flow chart of one embodiment of a service request processing method according to the present application;

[0023] Figure 3 is a structural schematic diagram of one embodiment of a service request processing apparatus according to the present application;

[0024] Figure 4 is a structural schematic diagram of one embodiment of a computer device according to the present application. DETAILED DESCRIPTION

[0025] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs; the terminology used in the description herein is for describing particular embodiments only and is not intended to be limiting of the application; the description and the drawings are to be regarded as illustrative in nature and are not intended to limit the application; the terminology used in the description of the application herein including the appended claims as well as in the above abstract is intended to be interpreted in only an illustrative way and not in a limiting sense. The terms "comprising", "having", "including", and "containing" used herein are meant to be interpreted in an inclusive sense, i.e., to mean that the described feature is present, but that other features can also be present.

[0026] Reference herein to "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the application. The appearances of the phrase "in an embodiment" in various places in the specification are not necessarily all referring to the same embodiment, nor are they necessarily all directed to the same embodiment, or to a single alternative embodiment. It is explicitly contemplated that embodiments described herein can be combined with each other.

[0027] In order to make the technical personnel in the art better understand the present application scheme, the technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings.

[0028] As shown in Figure 1 , the system architecture 100 can include a terminal device 101, a network 102 and a server 103, the terminal device 101 can be a notebook computer 1011, a tablet computer 1012 or a mobile phone 1013. The network 102 is a medium for providing a communication link between the terminal device 101 and the server 103. The network 102 can include various connection types, such as wired, wireless communication links or optical fiber cables, etc.

[0029] The user can use the terminal device 101 to interact with the server 103 through the network 102 to receive or send messages, etc. Various communication client applications can be installed on the terminal device 101, such as web browser applications, shopping applications, search applications, instant messaging tools, email clients, social platform software, etc.

[0030] The terminal device 101 can be various electronic devices with display screens and supporting web browsing, in addition to the notebook computer 1011, the tablet computer 1012 or the mobile phone 1013, the terminal device 101 can also be an electronic book reader, an MP3 player (Moving Picture Experts Group Audio Layer III), an MP4 player (Moving Picture Experts Group Audio Layer IV), a laptop computer and a desktop computer, etc.

[0031] The server 103 can be a server providing various services, such as a background server supporting the page displayed on the terminal device 101.

[0032] It should be noted that the service request processing method provided by the embodiments of the present application is generally executed by the server / terminal device, and correspondingly, the service request processing apparatus is generally arranged in the server / terminal device.

[0033] It should be understood that Figure 1 The number of terminal devices, networks and servers in

[0034] With reference to Figure 2 , a flow chart of one embodiment of the service request processing method according to the present application is shown. The service request processing method can be applied to an NLP system including a business application layer, a core function layer and a general component layer, and the service request processing method includes the following steps:

[0035] Step S201, receiving a service request initiated by the business application layer.

[0036] The business application layer is at the top of the entire NLP system architecture, and it mainly carries specific business needs in vertical scenarios. It encapsulates and presents various business functions from a business perspective. For example, in the financial insurance scenario, the customer service chat robot is used to answer customers' inquiries about insurance products in real time; in the medical scenario, the marketing copy generator is used to generate promotional copy for specific diseases or departments. Focusing on the implementation of business logic and interaction with users, business requirements can be converted into call requests for internal system services.

[0037] The service request is a demand signal for system processing capacity initiated by the business application layer. It comes from specific business scenarios. For example, in the financial insurance business, a customer initiates a request for interpretation of insurance contract terms; in the medical business, a doctor initiates a medical record analysis request, etc. It is used to trigger a series of internal processing procedures to obtain the desired response result.

[0038] In step S202, based on the service request and the preset routing rule table, the model identifier and input requirement data are determined through the preset dynamic routing engine.

[0039] The routing rule table is a pre-set rule set that comes from the analysis and summary of the characteristics of service requests in different business scenarios. It is used to guide the dynamic routing engine to quickly and accurately determine the appropriate language model based on the characteristics of the service request, ensuring that the service request can be processed most effectively.

[0040] The dynamic routing engine is a core component of the NLP system, which intelligently selects the optimal language model based on the service request and the preset routing rule table. It analyzes the characteristics of the service request, such as text type, semantic complexity, etc., and combines the routing rule table to quickly determine the corresponding model identifier and input requirement data.

[0041] The model identifier is an identifier that uniquely identifies a language model. It comes from the system's management needs for multiple language models, representing a specific language model. It is used to accurately locate and call the required language model in the system. For example, after determining the language model required by the service request, the model identifier can quickly find the corresponding model from the model library.

[0042] The input requirement data is a collection of data required for the target language model to process the service request, such as input format, parameters, etc. It is used to ensure that the data of the service request can be passed to the target language model in the correct format and parameters. For example, specify the encoding method, length limit of the input text, etc. to ensure that the model can normally process the input data and generate accurate output results.

[0043] Step S203, based on the model identification and the preset process rule table, the target language model corresponding operation process data is obtained through the preset task orchestrator, and the target language model is the language model corresponding to the model identification.

[0044] The process rule table is a pre-defined rule set, which is derived from the summary and abstraction of the processing flow in different business scenarios. It is used to guide the task orchestrator to obtain the operation process data corresponding to the target language model, and to ensure the standardization and normalization of the processing flow.

[0045] The task orchestrator is a key component in the NLP system, which obtains the operation process data corresponding to the target language model based on the model identification and the preset process rule table. It is derived from the demand for flexibility and high reuse of processing flow, and aims to decompose complex processing flow into executable task sequence. It uses directed acyclic graph and other methods to define composite operation flow. For example, define the operation flow of "query knowledge base → generate reply → grammar polishing", arrange each task according to certain logical order, and ensure that the service request can be processed according to the predetermined process.

[0046] The target language model is a language model used to process service requests according to the model identification. It is used to process text data in service requests. For example, text classification, sentiment analysis, entity recognition and other operations are performed to generate corresponding processing results.

[0047] The operation process data is the data about the specific operation steps and sequence of the target language model processing service request obtained according to the process rule table. It is used to guide the system to decompose the service request and generate task execution sequence, ensuring that each task can be executed according to the predetermined process and sequence.

[0048] Step S204, based on the operation process data and the input requirement data, the service request is decomposed to generate the task execution sequence of the service request.

[0049] Decomposition is the process of splitting the service request into a series of executable tasks according to the operation process data and the input requirement data. For example, a service request for interpreting an insurance contract clause is decomposed into text preprocessing task, feature extraction task, semantic analysis task, etc., each task has clear input and output requirements.

[0050] The task execution sequence is a sequence arranged by each task according to certain logical order after decomposition. It is used to guide the system to execute each task in a predetermined order, ensuring that the service request can be processed correctly. For example, first execute the text preprocessing task, then execute the feature extraction task, and finally execute the semantic analysis task, etc., to generate the final service request response result.

[0051] Step S205, based on the model identifier, determine the corresponding target microservice module from the pre-set general component layer.

[0052] Wherein, the general component layer is a basic layer in the NLP system architecture, which contains a series of reusable microservice modules. It aims to provide general functional components and avoid repeated development.

[0053] Wherein, the target microservice module is the microservice module corresponding to the target language model determined from the general component layer according to the model identifier. It is used to work with the target language model to execute the tasks in the task execution sequence. For example, it provides data preprocessing services, model inference services, etc., to ensure that the service request can be processed completely.

[0054] Step S206, execute the tasks in the task execution sequence through the target language model and the target microservice module, and generate the response result of the service request.

[0055] Wherein, the task is a specific execution unit after the service request is decomposed, which is defined to complete a specific operation in the service request processing process. For example, in the insurance contract clause interpretation task, text preprocessing task, feature extraction task, semantic analysis task, etc. are specific tasks, each task has clear input, output and execution logic, and the processing of the service request is completed step by step by executing these tasks.

[0056] Wherein, the response result is the final processing result of the service request generated by the system after executing all the tasks in the task execution sequence. For example, in the service request of insurance contract clause interpretation, the response result can be the detailed interpretation content of the clause, risk prompt, etc.

[0057] After receiving the service request, the embodiments of the present application can intelligently determine the model identifier and the input requirement data with the help of the pre-set dynamic routing engine and the routing rule table, get rid of the limitations of traditional static configuration or manual intervention, quickly and accurately match the optimal language model, and significantly improve the system response speed. At the same time, according to the model identifier and the process rule table, the operation process data of the target language model is obtained by using the task arranger to generate the task execution sequence by decomposing the service request, which ensures the flexibility of the processing process while realizing the standardization and efficient reuse of the process, and solves the contradiction between the customization and the standardized process. Finally, through the target language model and the target microservice module, the high-quality response result is generated, and the processing efficiency and quality of the service request are improved.

[0058] In some optional implementation manners of the present embodiment, step 202, based on the service request and the pre-set routing rule table, determine the model identifier and the input requirement data through the pre-set dynamic routing engine, which specifically includes the following steps:

[0059] The service request is parsed to obtain request characteristics of the service request; through a preset dynamic routing engine, a routing rule matching the request characteristics is searched from a preset routing rule table; and based on the routing rule, the model identifier and input requirement data are determined by the dynamic routing engine.

[0060] The request characteristics are a set of key attribute information extracted from the service request initiated by the business application layer. For example, in the financial insurance scenario, a service request for interpreting complex insurance clauses includes the text length of the clauses, the types of insurance products involved (such as life insurance and property insurance), the client group (such as individual clients and enterprise clients), and the like.

[0061] The routing rule is a series of rules set in the routing rule table in advance, which is based on the analysis and summary of the relationship between the service request characteristics and the language model in different business scenarios. It is used to guide the dynamic routing engine to determine the model identifier and input requirement data, so as to ensure that the service request can be routed to the most suitable language model for processing.

[0062] In an example, in the financial insurance scenario, a complex life insurance contract clause interpretation service request is taken as an example. The business application layer initiates the service request, which covers the insurance contract clause text, client basic information, and specific questions consulted by the client (such as questions about the scope and conditions of claims). After the system receives the request, a text analysis algorithm in natural language processing technology is used for parsing. On the one hand, the insurance contract clause text is subjected to semantic understanding, keyword extraction, and the like, and on the other hand, the client information is combined to obtain the request characteristics of the service request. For example, the professional terms such as “major illness” and “accidental injury” in the clauses are extracted, it is judged that the clause semantic complexity is high, and the client is a middle-aged and old-aged group with detailed clause interpretation requirements. Subsequently, the dynamic routing engine is used to search for a routing rule matching the above request characteristics from the routing rule table. The routing rule table predefines the correspondence between different request characteristics and model identifiers and input requirement data. The dynamic routing engine finds the matching rule. The rule specifies that such a request should be routed to a language model with professional knowledge in the financial insurance field and deep semantic understanding ability, and clearly specifies the input requirement data, such as that the input text needs to be clearly paragraphed, the key clauses need to be highlighted, and the encoding mode is UTF-8, and the like. Finally, based on the matched routing rule, the dynamic routing engine determines the model identifier and the input requirement data. The model identifier is used to uniquely identify the language model suitable for processing the service request, and the input requirement data ensures that the service request can be passed to the target language model in the correct format and parameters in subsequent processing. In this way, the system can automatically and efficiently select a suitable language model to process a complex life insurance contract clause interpretation service request, effectively avoiding the response delay and resource waste caused by traditional static configuration or manual intervention, and improving the business processing efficiency and customer satisfaction.

[0063] In one example, in a healthcare scenario, consider processing a request for medical record analysis regarding a heart disease patient. The business application layer initiates the service request, which includes the patient's medical record text, including basic information, symptom description, medical history, and test results. After receiving the service request, the system parses it. Using natural language processing techniques, it performs operations such as word segmentation, part-of-speech tagging, and named entity recognition on the medical record text, extracting key information from the medical record, such as the name of the condition ("heart disease"), related symptoms ("chest pain," "palpitations"), and test results ("abnormal electrocardiogram"). Combined with the patient's basic information, the request features are derived. The dynamic routing engine then searches the routing rule table based on the request features. The routing rule table pre-defines matching rules based on the text processing requirements of different medical departments and conditions. The dynamic routing engine finds a matching routing rule, which stipulates that such requests should be routed to a language model with expertise and clinical experience in cardiology, and specifies the input requirement data, such as the input text must be organized according to the standard format of the medical record (such as the chief complaint, current medical history, past medical history, etc., with clear sections), and the text length must not exceed a certain limit. Finally, based on the matched routing rules, the dynamic routing engine determines the model identifier and input requirement data. The model identifier is used to accurately call the language model suitable for processing this medical record analysis service request, and the input requirement data ensures that the medical record text can be entered in a manner that meets the model requirements. In this way, the system can automatically select the appropriate language model based on the specific characteristics of the medical record, improve the accuracy and efficiency of medical record analysis, while avoiding the development complexity problems caused by excessive customization, and achieving a balance between flexibility and standardization of the processing flow.

[0064] The embodiment of the present application can parse the service request to obtain the request characteristics, accurately mine the key information in the request, and provide an accurate basis for subsequent processing. By searching the matching rules in the routing rule table through the dynamic routing engine, an automated model selection process is realized, breaking away from the limitations of traditional static configuration or manual intervention. Based on the matched routing rules, the model identification and input requirement data are determined. On the one hand, it can quickly locate the language model that is most suitable for processing the request, ensuring that the system responds quickly and meets the customer's real-time consultation and business processing needs; on the other hand, the clear input requirement data ensures that the service request can be passed to the target language model in the correct format and parameters, thereby improving the accuracy of processing.

[0065] In some optional implementations, step S203, based on the model identifier and the preset process rule table, obtains the operation process data corresponding to the target language model through a preset task scheduler, specifically including the following steps:

[0066] Determine the operation flow entry corresponding to the model identifier from the preset flow rule table through the preset task orchestrator; extract the directed acyclic graph of the operation flow entry through the task orchestrator, the node of the directed acyclic graph representing a task execution step, and the edge of the directed acyclic graph representing the dependency relationship between the task execution steps; based on the node and the edge, perform integrity verification on the directed acyclic graph, and if the verification is passed, convert the directed acyclic graph into operation flow data.

[0067] The operation flow entry is derived from the preset flow rule table, which is an entry information pre-set for a specific model identifier to describe a series of operation flows required to be executed when processing a service request.

[0068] The directed acyclic graph is a data structure extracted from the operation flow entry by the task orchestrator. It is used to visually display the operation flow, where the node represents the task execution step, and the edge represents the dependency relationship between the task execution steps. Through the directed acyclic graph, the system can clearly understand the execution order and mutual influence of each task execution step, thereby reasonably arranging the execution of the tasks.

[0069] The task execution step is a specific operation unit represented by the node in the directed acyclic graph. It is used to clearly define the specific tasks that need to be executed at each stage, so that the system can execute these tasks in a predetermined order and logic.

[0070] The dependency relationship is the logical connection between the task execution steps represented by the edge in the directed acyclic graph. It represents that a certain task execution step must be executed after another task execution step is completed.

[0071] The integrity verification is a checking operation on the directed acyclic graph. It is used to ensure that the directed acyclic graph can accurately describe the operation flow and there is no missing task execution step or unreasonable dependency relationship.

[0072] In an example, in the field of financial insurance, taking processing a car insurance claim service request as an example. The business application layer initiates the car insurance claim service request, and the request contains accident description text (such as accident time, location, process, etc.), vehicle information (vehicle type, license plate number, etc.), and customer basic information (name, contact information, etc.). First, through the dynamic routing engine, based on the service request and the preset routing rule table, the model identifier for processing the car insurance claim request is determined. For example, it is a language model with knowledge in the field of car insurance claim and can perform semantic analysis and risk assessment, and the input requirement data is determined at the same time, such as the text format is pure text, the encoding method is UTF-8, etc. Then, the task arranger determines the operation process item corresponding to the model identifier from the process rule table. The process rule table pre-sets the operation process corresponding to different model identifiers. For the car insurance claim model identifier, the operation process item includes accident information integrity check, preliminary responsibility determination, claim amount estimation, etc. Then, the task arranger extracts the directed acyclic graph of the operation process item. In the directed acyclic graph, the node represents the task execution step, such as "accident information integrity check" as a node and "preliminary responsibility determination" as another node. The edge represents the dependency relationship between the task execution steps, such as the "preliminary responsibility determination" node must be executed after the "accident information integrity check" node is completed, because the complete accident information is the basis for determining the responsibility. Then, the directed acyclic graph is verified based on the nodes and edges. The system checks whether all necessary task execution steps are included and whether the dependency relationship is reasonable. If the key step of "accident information integrity check" is missing, the integrity verification will not pass, prompting the developer to correct the process rule table. If the verification passes, the directed acyclic graph is converted into operation process data.

[0073] The embodiments of the present application can determine the operation process item corresponding to the model identifier from the process rule table through the task arranger, which realizes accurate matching of the process. Different model identifiers correspond to different business demands, and this step can quickly locate the operation process suitable for processing the current service request. The directed acyclic graph of the operation process item is extracted, with the node representing the task execution step and the edge representing the dependency relationship, which intuitively presents the logical structure of the operation process. This helps the system to clearly understand the task execution order and mutual relationship. The directed acyclic graph is verified based on the nodes and edges, which ensures the accuracy and integrity of the operation process. If the verification passes, the directed acyclic graph is converted into operation process data, which provides a reliable basis for the decomposition and task execution of subsequent service requests. This process avoids system failures caused by missing processes or incorrect dependency relationships, and improves the stability and reliability of the system.

[0074] In some optional implementation manners, in step S204, the service request is decomposed based on the operation process data and the input requirement data to generate a task execution sequence of the service request, specifically including the following steps:

[0075] The node information and edge information of the directed acyclic graph are extracted from the operation flow data; the original content carried in the service request is preprocessed according to the input requirement data to obtain the preprocessed service request content; and the task execution sequence of the service request is generated based on the node information and the edge information in combination with the preprocessed service request content.

[0076] The node information is a key element extracted from the operation flow data. The node information represents the related attributes of the specific task execution steps represented by each node in the directed acyclic graph, such as task name, task type, and resources required for task execution. It is used to clearly define the specific content and requirements of each task execution step, so that the system can execute these tasks in the correct order and manner.

[0077] The edge information is also an important part of the operation flow data. The edge information represents the dependency relationship between the task execution steps represented by the edges in the directed acyclic graph, i.e., one task execution step must be executed after another task execution step is completed. It is used to determine the sequence of task execution, ensuring that the system can process service requests in a reasonable logical flow.

[0078] The original content is the initial data carried in the service request initiated by the business application layer without processing. It can include text, images, audio, and other forms.

[0079] The preprocessing is a process of format conversion, data cleaning, feature extraction, and other operations on the original content carried in the service request. The purpose is to make the original content meet the requirements of subsequent task execution.

[0080] In an example, in the field of finance and insurance, taking processing a health insurance application service request as an example. The business application layer initiates the health insurance application service request, and the original content carried in the request includes text data such as basic information of the applicant (such as name, age, gender, occupation, etc.), health status description (such as whether there is a history of disease, family history, etc.), and insurance amount. First, the system obtains the operation process data corresponding to the target language model based on the determined model identifier (the model identifier corresponds to the target language model for processing health insurance application related business) and the preset process rule table through the preset task scheduler. The node information and edge information of the directed acyclic graph are extracted from the operation process data. The node information includes "applicant information verification task", "health risk assessment task", "premium calculation task", etc., and each node corresponds to a specific task execution step. The edge information indicates the dependency relationship between these tasks, for example, "health risk assessment task" must be executed after "applicant information verification task" is completed, because only after the authenticity of the applicant's information is verified, the health risk of the applicant can be accurately assessed. Then, according to the input requirement data (such as the data format requirement is JSON, the character encoding is UTF-8, etc.), the original content carried in the service request is preprocessed. The original text data is converted into the required JSON format, and some ambiguous health status descriptions are standardized, such as "occasional headache" is unified as "headache frequency: occasional", to obtain the preprocessed service request content. Finally, based on the extracted node information and edge information, combined with the preprocessed service request content, the task execution sequence of the service request is generated. According to the dependency relationship between the nodes in the directed acyclic graph, the "applicant information verification task", "health risk assessment task", "premium calculation task" and other tasks are arranged in sequence, and the preprocessed service request content is provided as the input data for each task. In this way, the system can execute each task in sequence according to the generated task execution sequence, and finally complete the processing of the health insurance application service request, and generate the corresponding response result.

[0081] The embodiment of the application can accurately locate each task execution step and its dependency relationship by extracting node information and edge information of the directed acyclic graph from the operation flow data, build a clear logical framework for subsequent process processing, avoid processing errors caused by chaotic task order or unclear dependency relationship, and ensure orderly process advancement. According to the input requirement data, the original content of the service request is preprocessed, the original data can be converted into a format that meets the subsequent processing requirements, noise and redundant information are removed, the data quality is improved, the target language model and the microservice module can more efficiently and accurately process data, and the waste of computing resources and processing delay caused by inconsistent data formats or information errors is reduced. Based on the node information, edge information and preprocessed content, the task execution sequence is generated, which can combine business logic and actual data to dynamically generate the most reasonable task execution order, ensure that each task is executed at the right time, fully utilize system resources, improve overall processing efficiency, quickly respond to service requests and enhance customer experience.

[0082] In some optional implementations, step S205, based on the model identifier, determines the corresponding target microservice module from the preset general component layer, and specifically further includes the following steps:

[0083] Traverse each microservice module in the preset general component layer to obtain the model list of each microservice module; detect whether the model list contains the model identifier, if it contains, determine the microservice module corresponding to the model list containing the model identifier as the target microservice module.

[0084] Among them, the microservice module is an independent functional unit in the general component layer. It is used to realize the distributed processing of business logic, improve the flexibility, maintainability and scalability of the system.

[0085] Among them, the model list is a set of information obtained when traversing each microservice module in the general component layer. It is used to detect whether the microservice module supports a specific model identifier, so as to determine the target microservice module.

[0086] In an example, in the field of financial insurance, taking processing a car insurance claim service request as an example. The system first receives the car insurance claim service request initiated by the business application layer. Based on the service request and the preset routing rule table, the model identifier is determined as "vehicle damage assessment model V2.0" and the corresponding input requirement data through the dynamic routing engine. Then, the system starts to traverse each microservice module in the preset general component layer. The general component layer includes a plurality of microservice modules. For example, "customer information management microservice module", "vehicle information query microservice module", "vehicle damage assessment microservice module", etc. For each microservice module, the system obtains its model list. For example, the model list of "customer information management microservice module" may include "customer information verification model V1.0" and "customer credit evaluation model V1.5"; the model list of "vehicle information query microservice module" may include "vehicle basic information query model V1.2" and "vehicle repair record query model V1.8"; and the model list of "vehicle damage assessment microservice module" includes "vehicle damage assessment model V2.0". The system detects whether the model list of each microservice module contains the previously determined "vehicle damage assessment model V2.0" model identifier. In the detection process, it is found that the model list of "vehicle damage assessment microservice module" contains the model identifier. Therefore, the "vehicle damage assessment microservice module" corresponding to the model list containing the "vehicle damage assessment model V2.0" model identifier is determined as the target microservice module. Through the target microservice module and the previously determined target language model (i.e., "vehicle damage assessment model V2.0"), the system can execute vehicle damage assessment related tasks according to the generated task execution sequence, and finally generate the response result of the car insurance claim service request.

[0087] By traversing each microservice module in the general component layer and obtaining the model list, the embodiments of the present application can comprehensively grasp the model capabilities of each microservice module in the system, provide a complete information basis for subsequent model matching, and avoid the inability to accurately find a suitable module due to information loss. The operation of detecting whether the model list contains the model identifier can accurately locate the microservice module supporting the target language model. Different business requirements correspond to different models, and through this detection, the required module can be quickly screened from a plurality of microservice modules, ensuring that the system can call the correct model to process the service request. The microservice module corresponding to the model list containing the model identifier is determined as the target microservice module, realizing efficient docking of the service request and the appropriate microservice module. This can make full use of system resources and improve the service request processing efficiency.

[0088] In some optional implementation manners, in step S206, the tasks in the task execution sequence are executed through the target language model and the target microservice module, and the response result of the service request is generated, specifically including the following steps:

[0089] According to the task execution sequence, the target language model and the target microservice module are associated to generate a microservice module instance set; the microservice module instance set is called to execute the tasks in the task execution sequence to generate a response result of the service request.

[0090] The association refers to the logical connection between the target language model and the target microservice module established according to the task execution sequence. It is used to realize the seamless connection between the model and the module, and to ensure that the tasks can be efficiently executed according to the predetermined process and rules.

[0091] The microservice module instance set is generated by the system after associating the target language model and the target microservice module according to the task execution sequence. It is used to centrally manage and call each microservice module instance to execute the tasks in the task execution sequence.

[0092] In an example, in the field of financial insurance, taking processing a health insurance claim service request as an example. The system first receives the health insurance claim service request initiated by the business application layer. Based on the service request and the preset routing rule table, the model identifier is determined as "health insurance claim evaluation model V3.0" and the input required data, such as the medical record of the insured person, the medical expense list, etc. Then, based on the model identifier, the corresponding target microservice module is determined from the preset general component layer, including "medical information query microservice module", "claim rule verification microservice module", "expense accounting microservice module", etc. Then, according to the generated task execution sequence, the target language model and these target microservice modules are associated. For example, in the task execution sequence, the medical information of the insured person needs to be queried first, at this time, the "health insurance claim evaluation model V3.0" is associated with the "medical information query microservice module" to generate an instance of the module, which is used to obtain the medical record, diagnosis result, etc. of the insured person from the medical database according to the input required data. Then, in the claim rule verification link, the model is associated with the "claim rule verification microservice module" to generate an instance, which judges whether the claim meets the conditions according to the obtained medical information and the preset claim rule. Finally, in the expense accounting stage, the model is associated with the "expense accounting microservice module" to generate an instance, which calculates the claim amount according to the medical expense list and the accounting rules. These associated instances together constitute a microservice module instance set. The system calls the microservice module instance set to execute the tasks in the task execution sequence. First, the "medical information query microservice module" instance obtains the information, then the "claim rule verification microservice module" instance verifies the rules, and finally the "expense accounting microservice module" instance accounts the amount, and finally generates the response result of the health insurance claim service request, completing the entire claim process.

[0093] The embodiments of the present application associate the target language model and the target microservice module according to the task execution sequence and generate a microservice module instance set, which can realize accurate matching and efficient integration of the model and the module. The models and module functions required in different task stages are different, and this association mode ensures that appropriate resources are called at the correct time, avoiding resource waste and incorrect calls. Calling the microservice module instance set to execute the tasks in the task execution sequence can ensure the coherence and accuracy of the business process. Each instance works in a predetermined order, closely linking from data acquisition, rule verification to result calculation, reducing errors and delays in intermediate links. The finally generated service request response result not only improves the business processing efficiency, but also enhances the reliability and consistency of the result.

[0094] In some optional implementations, after the target language model and the target microservice module are used to execute the tasks in the task execution sequence and generate the response result of the service request, the method further includes the following steps at step S206:

[0095] Comparing the perplexity of the response result with a preset threshold value; if the perplexity is greater than the preset threshold value, activating a backup module routing mechanism to generate a backup response result of the service request by a backup language model.

[0096] The perplexity is used to evaluate the quality of the response result generated by the target language model after processing the service request. Specifically, it reflects the ability of the model in generating the response in terms of semantic understanding and grammar rule following.

[0097] The preset threshold value is a standard value preset by the system to measure the size of the perplexity. It is used for comparison with the perplexity to determine whether the response result is qualified.

[0098] The backup module routing mechanism refers to a mechanism that automatically switches to a backup processing flow when the perplexity of the response result generated by the target language model is greater than the preset threshold value. It is used to enable backup resources in time when the main processing flow has problems, to ensure that the service request can continue to be processed.

[0099] The backup language model is a model prepared in advance in the system to replace the target language model for processing when the response result generated by the target language model does not meet the requirements.

[0100] The backup response result is the result generated by the backup language model after taking over the processing of the service request. It is used as an alternative solution to provide to the user when the response result generated by the target language model is unqualified.

[0101] In an example, in the field of financial insurance, taking processing a vehicle insurance claim service request as an example. The system first receives the vehicle insurance claim service request initiated by the business application layer. Then, according to the preset routing rule table and the dynamic routing engine determination model, the model identification is determined as “vehicle insurance claim evaluation model”, and the input requirement data such as accident scene photos, vehicle repair list, etc. is obtained. Then, the operation process data corresponding to the model is obtained through the preset task scheduler, and the service request is decomposed based on the operation process data and the input requirement data, and the task execution sequence is generated, including accident information verification, vehicle loss assessment, claim amount calculation, etc. The system determines the target microservice module from the general component layer based on the model identification, such as “accident information query microservice module”, “vehicle valuation microservice module”, etc., and executes the task through the target language model and the target microservice module to generate the response result. Then, the system compares the perplexity of the response result with the preset threshold. For example, the preset threshold is set to 2.5. If the description of the vehicle loss assessment part in the generated response result has semantic ambiguity, logical inconsistency and other problems, resulting in a calculated perplexity of 3.0, which is greater than the preset threshold 2.5. At this time, the system activates the backup module routing mechanism. The mechanism will select a backup language model from the backup model library, such as “vehicle insurance claim backup evaluation model”. The backup language model will reprocess the service request, which will call a more comprehensive vehicle repair data reference library and combine a more accurate algorithm to reevaluate the vehicle loss. Finally, a backup response result is generated, which clearly and accurately describes the vehicle loss and the claim amount calculation is more reasonable. In this way, when the response result generated by the target language model is not ideal, the system can still provide accurate and reliable vehicle insurance claim services for customers, improving the stability and service quality of the system.

[0102] The embodiments of the present application can accurately identify the quality of the response result generated by the target language model by comparing the perplexity with the preset threshold. When the perplexity is greater than the preset threshold, it indicates that the response result may have problems such as unclear semantics and chaotic logic, which cannot meet the business requirements. At this time, the backup module routing mechanism is activated, and the backup language model is used to reprocess the service request, which can effectively avoid service interruption or incorrect result output caused by the main model problem.

[0103] It should be emphasized that in order to further ensure the privacy and security of the above-mentioned service request, routing rule table, model identification, input requirement data, flow rule table, and operation process data, the above-mentioned service request, routing rule table, model identification, input requirement data, flow rule table, and operation process data can also be stored in a node of a block chain.

[0104] The blockchain referred to in the present application is a new application mode of distributed data storage, peer-to-peer transmission, consensus mechanism, encryption algorithm and other computer technologies. The blockchain is essentially a decentralized database, which is a series of data blocks associated using cryptographic methods, each data block containing information of a batch of network transactions, used to verify the validity (anti-fake) of the information and generate the next block. The blockchain can include a blockchain underlying platform, a platform product service layer, and an application service layer.

[0105] The embodiments of the present application can acquire and process related data based on artificial intelligence technology. Artificial intelligence (AI) is the use of digital computers or computer-controlled machines to simulate, extend and expand human intelligence, perceive the environment, acquire knowledge and use knowledge to obtain the best results.

[0106] The basic technology of artificial intelligence generally includes technologies such as sensors, special artificial intelligence chips, cloud computing, distributed storage, big data processing technology, operation / interaction system, mechatronics, etc. The software technology of artificial intelligence mainly includes computer vision technology, robot technology, biometric technology, speech processing technology, natural language processing technology, and machine learning / deep learning, etc.

[0107] A person of ordinary skill in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by computer readable instructions instructing related hardware, and the computer readable instructions can be stored in a computer readable storage medium. The program can include the processes of the above-mentioned embodiments when executed, wherein the storage medium can be a non-volatile storage medium such as a magnetic disc, an optical disc, a read-only memory (ROM), or a random access memory (RAM).

[0108] It should be understood that although each step in the flowchart of the accompanying drawings is shown in sequence according to the direction of the arrow, these steps are not necessarily executed in sequence according to the direction of the arrow. Unless otherwise specified herein, the execution of these steps is not strictly limited in sequence, and they can be executed in other orders. Moreover, at least part of the steps in the flowchart of the accompanying drawings can include multiple sub-steps or multiple stages, which are not necessarily executed at the same time, but can be executed at different times, and the execution sequence is not necessarily sequential, but can be executed in rotation or alternation with at least part of other steps or sub-steps or stages of other steps.

[0109] Further reference is made to Figure 3As an implementation of the method shown in the above Figure 2 The application provides an embodiment of a service request processing device, which corresponds to the method embodiment shown in the above Figure 2 The device can be applied to various electronic devices.

[0110] As shown in the above Figure 3 The service request processing device 400 of the embodiment includes a receiving module 401, a first determining module 402, an obtaining module 403, a decomposing module 404, a second determining module 405, and an executing module 406. Wherein:

[0111] The receiving module 401 is configured to receive a service request initiated by a service application layer.

[0112] The first determining module 402 is configured to determine a model identifier and input requirement data based on the service request and a preset routing rule table through a preset dynamic routing engine.

[0113] The obtaining module 403 is configured to obtain operation process data corresponding to a target language model based on the model identifier and a preset process rule table through a preset task orchestrator, the target language model being a language model corresponding to the model identifier.

[0114] The decomposing module 404 is configured to decompose the service request based on the operation process data and the input requirement data to generate a task execution sequence of the service request.

[0115] The second determining module 405 is configured to determine a corresponding target microservice module from a preset general component layer based on the model identifier.

[0116] The executing module 406 is configured to execute tasks in the task execution sequence through the target language model and the target microservice module to generate a response result of the service request.

[0117] In the embodiment, after receiving the service request, the model identifier and the input requirement data can be intelligently determined by means of the preset dynamic routing engine and the routing rule table, which can break through the limitation of traditional static configuration or manual intervention, quickly and accurately match the optimal language model, and significantly improve the system response speed. Meanwhile, according to the model identifier and the process rule table, the operation process data of the target language model is obtained by the task orchestrator to decompose the service request to generate the task execution sequence, which can ensure the flexibility of the processing process, realize the process standardization and efficient reuse, and solve the contradiction between the customization and the standardized process. Finally, the target language model and the target microservice module are used to execute tasks to generate a high-quality response result, which improves the processing efficiency and quality of the service request.

[0118] In an embodiment, the first determining module 402 includes:

[0119] a parsing sub-module, configured to parse the service request to obtain a request feature of the service request;

[0120] a searching sub-module, configured to search, by a preset dynamic routing engine, a routing rule matching the request feature from a preset routing rule table;

[0121] a first determining sub-module, configured to determine, based on the routing rule, a model identifier and input requirement data by the dynamic routing engine.

[0122] The embodiments of the present application can accurately mine the key information in the request by parsing the service request to obtain the request feature, and provide accurate basis for subsequent processing. The dynamic routing engine is used to search the matching rule in the routing rule table, so that the automatic model selection process is realized, and the limitations of traditional static configuration or manual intervention are eliminated. The model identifier and the input requirement data are determined based on the matched routing rule, which can quickly locate the language model most suitable for processing the request, ensure the system to respond quickly, and meet the real-time consultation and business processing needs of customers; on the other hand, the clear input requirement data ensures that the service request can be delivered to the target language model in the correct format and parameters, and improves the processing accuracy.

[0123] In an embodiment, the obtaining module 403 comprises:

[0124] a second determining sub-module, configured to determine, by a preset task orchestrator, an operation flow item corresponding to the model identifier from a preset flow rule table;

[0125] a first extracting sub-module, configured to extract, by the task orchestrator, a directed acyclic graph of the operation flow item, wherein a node of the directed acyclic graph represents a task execution step, and an edge of the directed acyclic graph represents a dependency relationship between the task execution steps;

[0126] a verifying sub-module, configured to verify the integrity of the directed acyclic graph based on the nodes and the edges, and convert the directed acyclic graph into operation flow data if the verification is passed.

[0127] The embodiment of the application can determine the operation process item corresponding to the model identifier from the process rule table through the task arranger, and realize accurate matching of the process. Different model identifiers correspond to different business requirements, and this step can quickly locate the operation process suitable for processing the current service request. The directed acyclic graph of the extracted operation process item is represented by nodes and edges, which intuitively presents the logical structure of the operation process. This helps the system to clearly understand the task execution order and mutual relationship. The directed acyclic graph is verified based on the nodes and edges to ensure the accuracy and integrity of the operation process. If the verification is passed, the directed acyclic graph is converted into operation process data, which provides a reliable basis for subsequent decomposition and task execution of service requests. This process avoids system failure caused by missing processes or incorrect dependency relationships, and improves the stability and reliability of the system.

[0128] In an embodiment, the decomposition module 404 comprises:

[0129] The second extraction submodule is configured to extract node information and edge information of the directed acyclic graph from the operation process data.

[0130] The preprocessing submodule is configured to preprocess the original content carried in the service request according to the input requirement data to obtain preprocessed service request content.

[0131] The first generation submodule is configured to generate a task execution sequence of the service request based on the node information and the edge information, in combination with the preprocessed service request content.

[0132] The embodiment of the application can accurately locate each task execution step and its dependency relationship by extracting the node information and edge information of the directed acyclic graph from the operation process data, build a clear logical framework for subsequent process processing, avoid processing errors caused by chaotic task order or unclear dependency relationship, and ensure the orderly progress of the process. Preprocessing the original content of the service request according to the input requirement data can convert the original data into a format that meets the requirements of subsequent processing, remove noise and redundant information, improve data quality, and enable the target language model and microservice module to process data more efficiently and accurately, reducing the waste of computing resources and processing delay caused by data format inconsistency or information errors. Generating a task execution sequence based on the node information, edge information and preprocessed content can dynamically generate the most reasonable task execution order by combining business logic and actual data, ensure that each task is executed at the right time, fully utilize system resources, improve overall processing efficiency, quickly respond to service requests, and enhance customer experience.

[0133] In an embodiment, the second determination module 405 comprises:

[0134] The traversal submodule is configured to traverse each microservice module in the preset general component layer to obtain a model list of each microservice module.

[0135] The detection submodule is configured to detect whether the model list contains the model identifier, and if the model list contains the model identifier, determine the microservice module corresponding to the model list containing the model identifier as the target microservice module.

[0136] The embodiments of the present application can comprehensively grasp the model capabilities of each microservice module in the system by traversing each microservice module in the general component layer and obtaining a model list, and provide a complete information basis for subsequent model matching, thereby avoiding the failure to accurately find a suitable module due to missing information. The operation of detecting whether the model list contains the model identifier can accurately locate the microservice module supporting the target language model. Different business requirements correspond to different models, and this detection can quickly filter out the required module from a large number of microservice modules, thereby ensuring that the system can invoke the correct model to process the service request. Determining the microservice module corresponding to the model list containing the model identifier as the target microservice module can realize efficient docking of the service request and the suitable microservice module. This can make full use of system resources and improve the service request processing efficiency.

[0137] In an embodiment, the execution module 406 includes:

[0138] The association submodule is configured to associate the target language model and the target microservice module according to the task execution sequence, and generate a microservice module instance set.

[0139] The second generation submodule is configured to invoke the microservice module instance set to execute the task in the task execution sequence, and generate a response result of the service request.

[0140] The embodiments of the present application can accurately match and efficiently integrate the model and the module by associating the target language model and the target microservice module according to the task execution sequence and generating a microservice module instance set. The functions of the models and modules required in different task stages are different, and this association method ensures that the appropriate resources are invoked at the correct time, thereby avoiding resource waste and incorrect invocation. Invoking the microservice module instance set to execute the task in the task execution sequence can ensure the coherence and accuracy of the business process. Each instance works in a predetermined order, and the links such as data acquisition, rule verification, and result calculation are closely connected, thereby reducing errors and delays in the intermediate links. The finally generated service request response result not only improves the business processing efficiency, but also enhances the reliability and consistency of the result.

[0141] In an embodiment, the service request processing apparatus 400 further includes:

[0142] The comparison module is configured to compare the perplexity of the response result with a preset threshold.

[0143] The activation module is used to activate the backup module routing mechanism if the perplexity is greater than a preset threshold, and generate a backup response result of the backup language model to the service request.

[0144] The present embodiment can accurately identify the quality of the response generated by the target language model by comparing the perplexity with a preset threshold. When the perplexity exceeds the preset threshold, it indicates that the response may have unclear semantics, confusing logic, or other issues, failing to meet business requirements. Activating the backup module routing mechanism at this point and promptly re-enabling the backup language model to reprocess the service request can effectively avoid service interruptions or erroneous output caused by issues with the primary model.

[0145] To solve the above technical problems, the present application also provides a computer device. Figure 4 , Figure 4 This is a basic structural block diagram of the computer device in this embodiment.

[0146] The computer device 6 includes a memory 61, a processor 62, and a network interface 63 that are interconnected through a system bus. It should be noted that the figure only shows a computer device 6 having a memory 61, a processor 62, and a network interface 63, but it should be understood that it is not required to implement all the components shown, and more or fewer components can be implemented instead. Among them, those skilled in the art can understand that the computer device here is a device that can automatically perform numerical calculations and / or information processing according to pre-set or stored instructions, and its hardware includes but is not limited to a microprocessor, an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a digital signal processor (DSP), an embedded device, etc.

[0147] Computer devices can be desktop computers, laptops, PDAs, cloud servers, etc. Computer devices can interact with users through keyboards, mice, remote controls, touchpads, or voice-activated devices.

[0148] The memory 61 includes at least one type of readable storage medium, such as a flash memory, a hard disk, a multimedia card, a card-type memory (e.g., an SD or DX memory, etc.), a random access memory (RAM), a static random access memory (SRAM), a read-only memory (ROM), an electrically erasable programmable read-only memory (EEPROM), a programmable read-only memory (PROM), a magnetic memory, a magnetic disk, an optical disk, etc. In some embodiments, the memory 61 can be an internal storage unit of the computer device 6, such as a hard disk or a memory of the computer device 6. In other embodiments, the memory 61 can also be an external storage device of the computer device 6, such as a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash card, etc. equipped on the computer device 6. Of course, the memory 61 can include both the internal storage unit and the external storage device of the computer device 6. In this embodiment, the memory 61 is generally used to store an operating system and various application software installed on the computer device 6, such as computer readable instructions of the processing method of the service request, etc. In addition, the memory 61 can also be used to temporarily store various data that have been output or will be output.

[0149] The processor 62 can be a central processing unit (CPU), a controller, a microcontroller, a microprocessor, or other data processing chip in some embodiments. The processor 62 is generally used to control the overall operation of the computer device 6. In this embodiment, the processor 62 is used to run computer readable instructions or process data stored in the memory 61, such as computer readable instructions of the processing method of the service request.

[0150] The network interface 63 can include a wireless network interface or a wired network interface, and the network interface 63 is generally used to establish a communication connection between the computer device 6 and other electronic devices.

[0151] After receiving the service request, the embodiments of the present application can intelligently determine the model identifier and the input requirement data by means of the preset dynamic routing engine and the routing rule table, get rid of the limitations of traditional static configuration or manual intervention, quickly and accurately match the optimal language model, and significantly improve the system response speed. At the same time, according to the model identifier and the process rule table, the operation process data of the target language model is obtained by using the task arranger, the service request is decomposed to generate a task execution sequence, the flexibility of the processing process is ensured, the process standardization and efficient reuse are realized, and the contradiction between the standardized process and the standardized process is solved. Finally, the target language model and the target micro-service module execute the task to generate a high-quality response result, and the processing efficiency and quality of the service request are improved.

[0152] The application also provides another implementation, that is, providing a computer readable storage medium, the computer readable storage medium stores computer readable instructions, the computer readable instructions can be executed by at least one processor to make the at least one processor execute the steps of the service request processing method as described above.

[0153] The application embodiment can intelligently determine the model identifier and the input requirement data by means of the preset dynamic routing engine and the routing rule table after receiving the service request, break away from the limitations of traditional static configuration or manual intervention, quickly and accurately match the optimal language model, and significantly improve the system response speed. At the same time, according to the model identifier and the process rule table, the operation process data of the target language model is obtained by using the task arranger, the service request is decomposed to generate a task execution sequence, the process standardization and efficient reuse are realized while ensuring the flexibility of the processing process, and the contradiction between the standardization and the standardized process is solved. Finally, the target language model and the target micro-service module execute the task to generate a high-quality response result, and the processing efficiency and quality of the service request are improved.

[0154] Through the description of the above embodiments, those skilled in the art can clearly understand that the above-mentioned embodiment method can be realized by means of software and a general hardware platform, of course, it can also be realized by hardware, but in many cases, the former is a better implementation. Based on such understanding, the technical solutions of the application can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), and includes a plurality of instructions for making a terminal device (which can be a mobile phone, computer, server, air conditioner, or network device) execute the method of each embodiment of the application.

[0155] Obviously, the above-described embodiments are only some of the embodiments of the application, not all the embodiments, and the preferred embodiments of the application are given in the drawings, but do not limit the patent scope of the application. The application can be implemented in many different forms, and conversely, the purpose of providing these embodiments is to make the disclosure of the application more thorough and comprehensive. Although the application has been described in detail with reference to the foregoing embodiments, those skilled in the art can modify the technical solutions recorded in the foregoing specific embodiments, or make equivalent replacements to some technical features. Any equivalent structure made by using the contents of the specification and drawings, directly or indirectly applied to other related technical fields, is also within the patent protection scope of the application.

[0156] The non-company software tools or components appearing in the embodiments of the application are only examples for introduction, and do not represent actual use.

Claims

1. A method of processing a service request, characterized by, The method comprises the following steps: receiving a service request initiated by a service application layer; determining a model identifier and input requirement data based on the service request and a preset routing rule table through a preset dynamic routing engine; obtaining operation process data corresponding to a target language model based on the model identifier and a preset process rule table through a preset task orchestrator, the target language model being a language model corresponding to the model identifier; decomposing the service request based on the operation process data and the input requirement data to generate a task execution sequence of the service request; determining a target microservice module corresponding to the model identifier from a preset general component layer; executing tasks in the task execution sequence through the target language model and the target microservice module to generate a response result of the service request.

2. The method of claim 1, wherein, The step of determining the model identifier and the input requirement data based on the service request and the preset routing rule table through the preset dynamic routing engine specifically comprises: parsing the service request to obtain request features of the service request; finding a routing rule matching the request features from the preset routing rule table through the preset dynamic routing engine; determining the model identifier and the input requirement data through the dynamic routing engine based on the routing rule.

3. The method of claim 1, wherein, The step of obtaining the operation process data corresponding to the target language model based on the model identifier and the preset process rule table through the preset task orchestrator specifically comprises: determining an operation process entry corresponding to the model identifier from the preset process rule table through the preset task orchestrator; extracting a directed acyclic graph of the operation process entry through the task orchestrator, a node of the directed acyclic graph representing a task execution step, and an edge of the directed acyclic graph representing a dependency relationship between the task execution steps; performing integrity verification on the directed acyclic graph based on the nodes and the edges, and converting the directed acyclic graph into operation process data if the verification is passed.

4. The method of claim 3, wherein, The step of decomposing the service request based on the operation process data and the input requirement data to generate the task execution sequence of the service request specifically comprises: extracting node information and edge information of the directed acyclic graph from the operation process data; preprocessing original content carried in the service request according to the input requirement data to obtain preprocessed service request content; generating the task execution sequence of the service request based on the node information and the edge information in combination with the preprocessed service request content.

5. The method of claim 1, wherein, The step of determining the target microservice module corresponding to the model identifier from the preset general component layer specifically comprises: traversing each microservice module in the preset general component layer to obtain a model list of each microservice module; detecting whether the model list contains the model identifier, and determining a microservice module corresponding to the model list containing the model identifier as the target microservice module if the model list contains the model identifier.

6. The method of claim 1, wherein, The step of executing the tasks in the task execution sequence by the target language model and the target microservice module to generate the response result of the service request specifically comprises: According to the task execution sequence, the target language model and the target microservice module are associated to generate a microservice module instance set; The microservice module instance set is called to execute the tasks in the task execution sequence to generate the response result of the service request.

7. The method of claim 1, wherein, After the step of executing the tasks in the task execution sequence by the target language model and the target microservice module to generate the response result of the service request, the method further comprises: Comparing the perplexity of the response result with a preset threshold value; If the perplexity is greater than the preset threshold value, activating a backup module routing mechanism to generate a backup response result of the service request by a backup language model.

8. A service request processing apparatus characterized by comprising: Comprise: A receiving module configured to receive a service request initiated by a business application layer; A first determining module configured to determine a model identifier and input requirement data based on the service request and a preset routing rule table through a preset dynamic routing engine; An obtaining module configured to obtain operation process data corresponding to a target language model based on the model identifier and a preset process rule table through a preset task orchestrator, the target language model being a language model corresponding to the model identifier; A decomposing module configured to decompose the service request based on the operation process data and the input requirement data to generate a task execution sequence of the service request; A second determining module configured to determine a corresponding target microservice module from a preset general component layer based on the model identifier; An executing module configured to execute the tasks in the task execution sequence by the target language model and the target microservice module to generate the response result of the service request.

9. A computer device, comprising: A memory and a processor, the memory storing computer readable instructions, and the processor implementing the steps of the service request processing method of any one of claims 1 to 7 when executing the computer readable instructions.

10. A computer-readable storage medium, characterized in that, The computer readable storage medium stores computer readable instructions, and the computer readable instructions are executed by the processor to implement the steps of the service request processing method of any one of claims 1 to 7.

Images