Conversation parsing method, and system

Abstract

Provided in the present application are a conversation parsing method and apparatus. Information of a plug-in interface is stored by means of a conditional knowledge graph, so as to achieve the flexible configurability and extensibility of the plug-in interface, such that interface invocation and interface adjustment can be implemented more accurately, and conversation content that better meets the needs of a user can be output. The method comprises: acquiring first input text; on the basis of the first input text, determining a plurality of keywords and a first user intent corresponding to the first input text; on the basis of a conditional knowledge graph, determining at least one first interface corresponding to the first user intent, wherein the conditional knowledge graph comprises information of a plurality of interfaces, or the information of the plurality of interfaces forms the conditional knowledge graph, the plurality of interfaces being interfaces of plug-ins used for implementing at least one function; and acquiring output text on the basis of the plurality of keywords and a field corresponding to the at least one first interface, wherein the output text is a reply to the first input text.

Description

A conversation analysis method and system

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office on March 29, 2024, with application number 202410382443.5 and application name “A Dialogue Parsing Method and System”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of artificial intelligence, and in particular to a conversation parsing method and system. Background Art

[0003] Conversational artificial intelligence (AI) is mainly applied in a variety of scenarios, such as small talk, question-and-answer, or task-based. The model architecture of conversational AI usually includes multiple parts, such as an input module, a parsing module, a dialogue management module, an execution center, a decoding module, or an output module. The parsing module and the dialogue management module have a significant impact on the output results. However, commonly used parsing modules usually use slot matching to parse user intent. Slot matching usually selects a pre-set slot template for matching, which has very poor flexibility in parsing user intent. The parsed user intent may not be adapted to a plug-in with a higher degree of matching, resulting in the output result of calling the plug-in not matching the content required by the user, and thus resulting in inaccurate responses to user input.

[0004] Therefore, how to provide more appropriate responses in user conversations has become an urgent problem to be solved. Summary of the Invention

[0005] The present application provides a conversation parsing method and system, which saves plug-in interface information through conditional knowledge graphs, thereby achieving flexible configuration and scalability of the plug-in interface, and can more accurately implement interface calls to obtain conversations that users need more.

[0006] In view of this, on the first aspect, the present application provides a conversation parsing method, comprising: first, obtaining a first input text, which is obtained based on data input by a user; then determining multiple keywords based on the first input text and the first user intent corresponding to the first input text; then, determining at least one first interface corresponding to the first user intent based on a conditional knowledge graph, the conditional knowledge graph includes information on multiple interfaces, or the information on the multiple interfaces forms a conditional knowledge graph, and the multiple interfaces are interfaces of a plug-in for implementing at least one function; then obtaining an output text based on multiple keywords and fields corresponding to at least one first interface, the output text being a reply to the first input text.

[0007] In the implementation of this application, a conditional knowledge graph is constructed using the interface information of the plug-in. When searching for the required plug-in, the matching interface can be determined from the conditional knowledge graph based on the fields of each interface. The plug-in corresponding to the selected interface is then called to obtain output text that matches the user's intent, allowing for a conversation with the user that meets the user's intent. Therefore, using the conditional knowledge graph to store the information of each interface has very strong flexibility and extensibility, allowing for more flexible interface expansion.

[0008] In one possible implementation, the information of each interface in the conditional knowledge graph includes multiple fields, and each field forms a node in the conditional knowledge graph. The aforementioned acquisition of output text based on multiple keywords and at least one first interface may include: verifying the fields included in at least one first interface based on multiple keywords, and determining at least one second interface from at least one first interface based on the verification result, such as filtering out the first interface that passes the verification as the second interface; and obtaining the output text by calling the plug-in corresponding to at least one second interface. Therefore, in the implementation of the present application, the keywords extracted from the user input data can be used to verify the fields of the first interface, thereby filtering out the first interface that passes the verification as the second interface, so as to obtain the second interface that matches the user's intention, and then obtain the output text required by the user.

[0009] In one possible implementation, the multiple fields of each interface include a function description field, which is used to describe the function implemented when each interface is called; the aforementioned determination of at least one first interface corresponding to the first user intention based on the conditional knowledge graph includes: matching the first user intention with the function description field corresponding to each interface to determine at least one first interface.

[0010] In the implementation mode of the present application, a function description field is set for each interface in the conditional knowledge graph. By matching the user intent with the function description fields of each interface, the interface that is adapted to the user intent can be screened out to determine the plug-in that can be used to output information that meets the user intent.

[0011] In one possible implementation, the information of each interface in the conditional knowledge graph includes an interface constraint, which can be used to represent the range of functions supported by each interface; the aforementioned matching of the first user intention with the function description field corresponding to each interface to determine at least one first interface includes: matching the first user intention with the function description field corresponding to each interface to obtain at least one alternative interface; verifying at least one alternative interface according to the interface constraint corresponding to each interface to obtain at least one first interface.

[0012] In the implementation mode of the present application, each interface in the conditional knowledge graph can also set interface constraints to constrain the scope of functions implemented by the plug-in corresponding to the interface. Therefore, after determining the interface that matches the user's intention, the corresponding interface constraints are further used to further screen the matching interface to obtain an interface that is more suitable for the user's intention.

[0013] In one possible implementation, the aforementioned verification of the fields included in at least one first interface based on multiple keywords, and determining at least one second interface from the at least one first interface based on the verification results, includes: matching multiple keywords with the fields of each first interface, filling the keywords into the matching fields, and obtaining the filling results of each first interface; then verifying the filling results of each first interface, and at least one second interface is the interface that passed the verification in at least one first interface. Therefore, in the implementation of the present application, the filling results of each first interface can be verified, and the first interface that passed the verification can be used as the second interface to obtain an interface that is more compatible with the user's intention, so that the interface that passed the verification can be called later, that is, the interface that better matches the user's intention can be called to obtain conversation content that meets the user's needs.

[0014] In a possible implementation, the aforementioned matching of multiple keywords with the fields of each first interface, filling the keywords into the corresponding fields, and obtaining a filling result includes: matching multiple keywords with the fields of each first interface, filling the keywords into the corresponding fields, and obtaining a filling result when multiple keywords of each first interface are filled; generating a follow-up text when the fields in each first interface include unfilled fields; obtaining a second input text corresponding to the follow-up text; and filling the unfilled fields according to the keywords in the second input text to obtain a filling result when the second input text includes keywords corresponding to the unfilled fields.

[0015] In an embodiment of the present application, when the required fields of the interface are not completely filled, follow-up text can continue to be generated to ask questions about the unfilled fields, so that the unfilled fields can be filled in based on the data entered again by the user, and a more suitable interface can be further screened out in combination with the text that the user continues to enter.

[0016] In a possible embodiment, the method provided by the present application also includes: if the second user intention corresponding to the second input text does not match the first user intention, then redetermining the interface corresponding to the second user intention. Therefore, in the case of generating a follow-up text, if the user intention corresponding to the text input again by the user changes from the user intention in the previous round of dialogue, the next round of dialogue can be entered to rematch the interface of the required plug-in call. In a possible embodiment, the aforementioned filling result of each first interface is verified according to the corresponding constraint conditions to obtain the verification result corresponding to each first interface, including: judging whether the filling result corresponding to each first interface meets the constraint conditions corresponding to each first interface; if so, it means that the filling result corresponding to the first interface passes the verification; if not, it means that the filling result corresponding to the first interface fails the verification.

[0017] In the implementation mode of the present application, when filling the interface fields in combination with the input text, it can be further verified in combination with the constraint conditions corresponding to the field, so that the interfaces that pass the verification can be screened out as callable interfaces, so that the filled fields are more adapted to the semantics of the input text, thereby obtaining an interface that is more adapted to user needs.

[0018] In one possible implementation, a large model can be used to generate text corresponding to the unpopulated field to obtain follow-up text. In the embodiments of the present application, when generating conversation text, a large model can be used. Large models are typically trained using a large amount of conversation data. Therefore, the large model is used to generate follow-up text based on the learned conversational language, thereby outputting text that is more adapted to the user's language habits and improving the user experience.

[0019] In one possible implementation, the constraints may include intra-field constraints and inter-field constraints. The intra-field constraints include the conditions satisfied by the input parameters when calling each interface, and the inter-field constraints include the conditions satisfied between the input parameters when calling each interface.

[0020] In the implementation manner of the present application, constraints can be set between fields in the conditional knowledge graph, and constraints can also be set on the parameter value range of the field, so as to constrain the keywords filled into each field in combination with the actual range supported by each interface, so that the keywords filled into each field match the parameter range supported by the interface.

[0021] In one possible implementation, the aforementioned obtaining of the first input text includes: obtaining user input data, where the type of the user input data may include, but is not limited to, text, image, or voice; and then obtaining text corresponding to the user input data based on the large model to obtain the first input text. In this implementation, the user can input multiple types of input data, which can adapt to more scenarios and has stronger generalization.

[0022] In one possible implementation, the large model can be used to generate output data corresponding to the output text, where the type of the output data is the same as the type of the user input data. In the implementation of the present application, the large model can be used to output output data that is compatible with the user's input data type, thereby adapting the output data to the user's input type, enabling a conversation with the user on the same dimension, and improving the user experience.

[0023] In a second aspect, the present application provides a conversation backend system, including:

[0024] An input module, configured to obtain a first input document;

[0025] a parsing module, configured to determine a plurality of keywords included in a first input text and whether the first input text corresponds to a first user intention;

[0026] The parsing module is further configured to determine at least one first interface corresponding to the first user intent based on the conditional knowledge graph, where the conditional knowledge graph includes information about multiple interfaces, where the multiple interfaces are interfaces of a plug-in for implementing at least one function;

[0027] The execution center is used to call the plug-in corresponding to the interface output by the parsing module to obtain the output result;

[0028] The dialogue management module is used to obtain an output text according to the output result, where the output text is a reply to the first input text.

[0029] Among them, the effects achieved by the second aspect and any optional implementation of the second aspect can be found in the introduction of the aforementioned first aspect or any optional implementation of the first aspect, and will not be repeated here.

[0030] In a possible implementation, the parsing module is further configured to verify fields included in the at least one first interface according to a plurality of keywords, and determine at least one second interface from the at least one first interface according to the verification result;

[0031] The execution center is specifically used to obtain the output result by calling the plug-in corresponding to at least one second interface.

[0032] In a possible implementation, the multiple fields include a function description field, which is used to describe the function implemented when each interface is called;

[0033] The parsing module is specifically used to match the first user intention with the function description field corresponding to each interface to determine at least one first interface.

[0034] In a possible implementation, the information of each interface in the conditional knowledge graph includes an interface constraint, and the interface constraint is used to indicate the scope of functions supported by each interface;

[0035] The parsing module is specifically used to: match the first user intention with the function description field corresponding to each interface to obtain at least one alternative interface; verify at least one alternative interface according to the interface constraints corresponding to each interface to obtain at least one first interface.

[0036] In one possible embodiment, the parsing module is specifically used to: fill multiple keywords into the fields included in at least one first interface to obtain the filling results of each first interface; verify the filling results of each first interface, and at least one second interface is an interface that has passed the verification in at least one first interface.

[0037] In one possible embodiment, the parsing module is specifically used to: match multiple keywords with the required fields of each first interface, and fill the keywords into the corresponding required fields; when multiple fields of each first interface are filled, output the filling result of each first interface; when the multiple fields in each first interface include unfilled fields, generate a follow-up text; obtain a second input text corresponding to the follow-up text; when the second input text includes keywords corresponding to the unfilled fields, fill the unfilled fields according to the keywords in the second input text, and output the filling result of each first interface.

[0038] In a possible implementation, the parsing module is further configured to: if the second user intent corresponding to the second input text does not match the first user intent, redetermine an interface corresponding to the second user intent.

[0039] In a possible implementation, the dialogue management module is further configured to generate text corresponding to the unfilled fields using the large model to obtain a follow-up question text.

[0040] In one possible implementation, the parsing module is specifically used to: determine whether the filling result corresponding to each first interface meets at least one constraint condition corresponding to each first interface; if so, it means that the filling result corresponding to the first interface has passed the verification; if not, it means that the filling result corresponding to the first interface has not passed the verification.

[0041] In one possible implementation, the constraints are divided into intra-field constraints and inter-field constraints. The intra-field constraints include the conditions that the input parameters must satisfy when calling each interface, and the inter-field constraints include the conditions that the input parameters must satisfy when calling each interface.

[0042] In a possible implementation, the input module is specifically used to: obtain user input data, where the type of the user input data includes text, image, or voice; obtain text corresponding to the user input data according to the large model to obtain a first input text.

[0043] In one possible implementation, the device further includes:

[0044] The output module is used to generate output data corresponding to the output text using the large model. The type of the output data is the same as the type of the user input data.

[0045] In a third aspect, an embodiment of the present application provides a computing device comprising a processor and a memory; the processor of at least one computing device is used to execute instructions stored in the memory of at least one computing device, so that the computing device performs the method steps in the first aspect and any implementation thereof.

[0046] In a fourth aspect, an embodiment of the present application provides a computing device cluster, comprising at least one computing device, each computing device comprising a processor and a memory; the processor of at least one computing device is used to execute instructions stored in the memory of at least one computing device, so that the computing device cluster performs the method steps in the first aspect and any implementation thereof.

[0047] In a fifth aspect, an embodiment of the present application provides a computer program product comprising instructions, which, when executed by a computing device cluster, enables the computing device cluster to execute the method in the first aspect or any implementation of the first aspect.

[0048] In a sixth aspect, an embodiment of the present application provides a computer-readable storage medium comprising computer program instructions. When the computer program instructions are executed by a computing device cluster, the computing device cluster executes a method as in any one of the implementations of the first, second, third or fourth aspects.

[0049] In the seventh aspect, an embodiment of the present application provides a chip comprising at least one processor and an interface; at least one processor obtains program instructions or data through the interface; and at least one processor is used to execute program line instructions to implement the method in the first aspect or any implementation of the first aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0050] FIG1 is a schematic diagram of a system architecture provided in an embodiment of the present application;

[0051] FIG2 is a flow chart of a conversation analysis method provided in an embodiment of the present application;

[0052] FIG3 is an architecture of a conversation backend system provided in an embodiment of the present application;

[0053] FIG4 is a schematic diagram of the structure of a conditional knowledge graph provided in an embodiment of the present application;

[0054] FIG5 is a schematic diagram of the structure of another conditional knowledge graph provided in an embodiment of the present application;

[0055] FIG6 is a flow chart of another method for analyzing a conversation provided in an embodiment of the present application;

[0056] FIG7 is a schematic diagram of the structure of a dialogue background system provided in an embodiment of the present application;

[0057] FIG8 is a schematic diagram of the structure of a computing device provided in an embodiment of the present application;

[0058] FIG9 is a schematic diagram of the structure of a computing device cluster provided in an embodiment of the present application;

[0059] FIG10 is a schematic diagram of the structure of another computing device cluster provided in an embodiment of the present application. DETAILED DESCRIPTION

[0060] The following will describe the technical solutions in the embodiments of this application in conjunction with the drawings in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0061] The recommendation method provided in this application can be applied to artificial intelligence (AI) scenarios. AI is a theory, method, technology and application system that uses digital computers or machines controlled by digital computers to simulate, extend and expand human intelligence, perceive the environment, acquire knowledge and use knowledge to obtain the best results. In other words, artificial intelligence is a branch of computer science that attempts to understand the essence of intelligence and produce a new type of intelligent machine that can respond in a similar way to human intelligence. Artificial intelligence is to study the design principles and implementation methods of various intelligent machines so that machines have the functions of perception, reasoning and decision-making. Research in the field of artificial intelligence includes robotics, natural language processing, computer vision, decision-making and reasoning, human-computer interaction, recommendation and search, basic AI theory, etc.

[0062] The embodiments of the present application involve related applications of neural networks and natural language processing (NLP). In order to better understand the solutions of the embodiments of the present application, the relevant terms and concepts of neural networks that may be involved in the embodiments of the present application are first introduced below.

[0063] (1) Neural Network

[0064] A neural network can be composed of neural units, which can be represented by x s (i.e. input data) and intercept 1 as input operation unit, the output of the operation unit can be:

[0065] Where, s = 1, 2, ... n, n is a natural number greater than 1, W s is x s The weight parameter of the neural unit, b is the bias of the neural unit. f is the activation function of the neural unit, which is used to introduce nonlinear characteristics into the neural network to convert the input signal in the neural unit into the output signal. The output signal of the activation function can be used as the input of the next convolutional layer, and the activation function can be a sigmoid function. A neural network is a network formed by connecting multiple single neural units mentioned above, that is, the output of one neural unit can be the input of another neural unit. The input of each neural unit can be connected to the local receptive field of the previous layer to extract the features of the local receptive field. The local receptive field can be an area composed of several neural units.

[0066] (2) Large model

[0067] A large model is a large-scale model. The size of a large model can be reflected in many aspects, such as large data scale, large-scale parallel computing capabilities, and larger model structure.

[0068] (3) Language model (LM)

[0069] This is used in Natural Language Processing (NLP) and plays a crucial role in the field. Its task is to predict the probability of a sentence occurring in a language. For example, a language model is typically constructed as a probability distribution p(s) for a string s, where p(s) attempts to reflect the frequency with which string s appears as a sentence. This can be applied to scenarios such as text recognition and machine translation.

[0070] (4) Neural machine translation: Neural machine translation is a typical task in natural language processing. Given a sentence in a source language, it outputs the corresponding sentence in the target language. In commonly used neural machine translation models, the words in the source and target language sentences are encoded into vector representations, and the associations between words and sentences are calculated in the vector space to perform the translation task.

[0071] (5) Self-attention model: It refers to the effective encoding of a sequence data (such as the natural language “Your phone is very good.”) into several multi-dimensional vectors to facilitate numerical operations. The multi-dimensional vector integrates the similarity information between each element in the sequence, and this similarity is called self-attention.

[0072] (6) Transformers library: provides models for natural language understanding (NLU) or natural language generation (NLG), such as BERT (bidirectional encoder representations from transformers), GPT-2, RoBERTa, XLM, DistilBert, XLNet, CTRL, etc. It has multiple pre-trained models and supports multiple language processing.

[0073] (7) Transformer structure: Generally, a pre-trained language model (PLM) can be constructed based on the Transformer structure. For example, a PLM can be obtained by stacking multiple Transformer structures. A Transformer structure can also be called a Transformer layer. Compared with other neural networks, such as RNN or CNN, the Transformer layer relies on its attention mechanism to capture the long-term dependency between words. For example, the structure of the Transformer layer can be shown in Figure 2. The Transformer layer includes a multi-head attention network and a forward network module. The multi-head attention network obtains the corresponding weight value by calculating the correlation between words and obtains the context-related word representation, which is the core part of the Transformer structure; the forward network further transforms the obtained representation to obtain the final output of the Transformer layer. In addition to the two important components, the residual layer (ADD) and linear normalization (Norm) are also stacked on these two components to optimize the output of the Transformer layer.

[0074] (8) Large language model (LLM)

[0075] It refers to a language model containing hundreds of billions (or more) of parameters, which are trained on large amounts of text data. It is a natural language processing model based on deep learning. These models can process large amounts of text data and learn the grammatical and semantic rules of natural language. LLM can be specifically applied to text generation, machine translation, question-answering systems, text summarization, or sentiment analysis. It has the advantages of strong generation capabilities, strong adaptability, accurate prediction, and strong scalability. For example, in a movie recommendation scenario, a large language model can generate descriptions of movie scenes, including the movie genre, starring actors, storyline, etc., so that the system can better recommend similar movies. Large language models can also generate reasons for recommendations. For example, e-commerce websites can use large language models to generate reasons for recommending products, such as product quality, price, functions, etc., so that users can better understand the value of the products.

[0076] (9) Knowledge Graph

[0077] A knowledge graph is a technology that graphically represents entities, relationships, and attributes. Essentially, a knowledge graph is a structured semantic knowledge base used to quickly describe concepts and their relationships in the physical world. Generally speaking, a knowledge graph is a graph-based data structure composed of nodes and edges. Each node in a knowledge graph represents an entity, and each edge represents a relationship between entities. Essentially, a knowledge graph is a semantic network.

[0078] (10) Plug-ins

[0079] It is a program written in accordance with a certain specification of the application program interface, and the application programming interface (API) is open to the outside world. For ease of understanding, this application will refer to the application programming interface as the interface or the plug-in interface, through which data interaction with other programs or functional modules is achieved. Usually, by dividing the software requirements and functions during the software design and development process, the program is divided into the main program and plug-ins. Usually, the basic functional requirements are designed in the main program, and the components that implement some functions are deployed in the form of plug-ins. Plug-ins are usually components independent of the main program. Plug-ins can be edited independently, and the functions of the software can be adjusted by adding or removing plug-ins or modifying the internal functions of the plug-ins. Therefore, plug-ins are a very flexible way to implement functions, which can flexibly implement the addition, deletion or modification of functions.

[0080] (11) Conditional Knowledge Graph

[0081] The conditional knowledge graph is a graphical display of the reasoning structure and knowledge relationship based on conditional statements. The knowledge graph focuses on showing the relationship and influence between different entities under specific conditions. In the embodiment of the present application, the information of the plug-in interface can be used to construct the conditional knowledge graph. The information of each interface can include multiple fields, each field forms a node in the conditional knowledge graph, and the nodes are connected by edges. When calling the plug-in, the parameters corresponding to the fields in each interface can be obtained, and the parameters are used as input parameters when calling the interface to obtain the execution result of the plug-in. Optionally, constraints can be set in the conditional knowledge graph, that is, the constraints that need to be met when filling the data in the fields of each plug-in interface when calling the plug-in. For example, constraints between fields can be set, or constraints that need to be met within a field, etc., so as to verify the parameters filled in each field. Only when the verification passes can the plug-in be requested to be called to ensure the correctness of the input parameters when calling each plug-in.

[0082] The following is an introduction to the system architecture and method steps provided by this application.

[0083] FIG1 is a schematic diagram of the structure of a conversation backend system provided by the present application. As shown in FIG1 , the conversation backend system 10 may include a computing device 11 and a client 12 .

[0084] The computing device 11 may specifically include a server cluster or a cloud platform, or may be another device with computing capabilities. Optionally, the computing device 11 may cooperate with other computing devices, such as data storage, routers, load balancers, and the like. The computing device 11 may use data in a data storage system or invoke program code in the data storage system to implement the method steps provided in the embodiments of the present application.

[0085] Computing device 11 can provide services to users in the form of a client. Users can operate on client 12 to interact with computing device 11 or request services from computing device 11. This client can be deployed on personal computers, computer workstations, smartphones, tablet computers, laptops, and smart cars, etc.

[0086] In one implementation, the computing device 11 is used to implement the method provided in the embodiment of the present application to generate dialog data for user input.

[0087] In general, the method provided in the embodiments of the present application can be applied to electronic devices, that is, the aforementioned computing device 11 can be various electronic devices, such as a server cluster, a cloud platform, a personal computer, a smart phone or a smart car.

[0088] In conjunction with the architecture shown in FIG. 1 , the method provided in this application can be executed by a computing device 11. The computing device 11 can specifically include a server cluster or a cloud platform, which can provide services to users via a client, or the computing device 11 can be another device with computing capabilities. For example, the method provided in this application can be applied to a user conversation scenario, where the computing device 11 can be a server, providing services to users via a client. The user can enter conversation text in the client, and the computing device 11 provides the user with the required information in a conversational manner using the method provided in this application.

[0089] Common conversations can be divided into small talk, question-and-answer, or task-based types.

[0090] in:

[0091] Small talk: mostly used for emotional companionship or daily life inquiries;

[0092] Question-answering type: often seen in customer service systems, and can be used to solve some factual or knowledge retrieval questions;

[0093] Task-based AI is primarily used in business process applications and typically focuses on solving problems within closed domains. Its primary purpose is to assist with analysis or knowledge acquisition during business process operations. It is a key technology for applying AI solutions to enterprise digital workflows.

[0094] Typically, task-based multi-turn dialogue is defined as a continuous conversation based on contextual content, aimed at solving a specific task. Task-based multi-turn dialogue has three key elements: multiple turns, continuity, and closed domain.

[0095] Multi-round: Unlike single-round question-answering, multi-round dialogue solves question-answering under complex conditions. It needs to combine multiple constraints such as context understanding and task requirements. Each response has a strong correlation with the context and task requirements.

[0096] Continuity: The conversation needs to be coherent. Once the user intent is captured, the conversation will continue with the goal of completing this task.

[0097] Closed-domain: A specific type of question indicates that the conversation is limited, meaning it is a closed-domain problem. The dialogue system is only responsible for a set of known tasks in a certain domain, such as booking a flight, ordering food, or querying an internal database.

[0098] In some existing conversation parsing solutions, for backend user conversation scenarios, taking the conversation parsing process of multi-round conversations as an example, multiple steps can be included, such as receiving user input, parsing user intent, conversation management, executing tasks, and decoding plugin output or output. The user intent parsing process typically requires understanding user intent, filling slots, and verifying slots. A slot is a definition of key information identified in user input data, i.e., the information required to convert user intent into a clear user command. Slot filling typically uses a preset slot template, which is equivalent to setting slots for different types of user intent. However, the slots filled according to the preset template may not match the plugin to be called. This results in a low accuracy of the plugin interface found to match the user intent, and thus a low match between the plugin called and the user intent. Therefore, the slot filling method based on preset templates suffers from mechanical, inflexible, and poor scalability. Secondly, slot verification primarily verifies whether the slot value falls within the specified range. Usually, rule verification logic is used, which is preset in a separate verification code. However, its verification logic may not completely match the input data range supported by the actual plug-in. If input data matching the plug-in is required, the code corresponding to the verification logic needs to be adjusted. Therefore, it has the disadvantages of poor scalability, poor reusability, high verification rule development and maintenance costs, and low degree of configuration.

[0099] Furthermore, during the dialogue management step, the system's actions and corresponding AI dialogue data are determined based on the current dialogue state. For example, current multi-turn dialogue management strategies typically employ multiple pre-set response templates or utilize large models to generate a controlled number of responses based on the output of the current user intent analysis step and the results of task execution. Pre-set response templates, however, suffer from mechanical and unnatural responses, often irrelevant to the question, and are gradually being replaced by large models. Currently, large models are increasingly being used to generate personalized responses that better align with human preferences. However, using large models to output responses still lacks strong interactivity with the analysis module, resulting in a lack of interaction between the responses generated by the dialogue strategy learning module and the user's input. Furthermore, guiding the progress of multi-turn dialogues typically involves following a pre-set list one by one. When plugin API parameters change, system modifications are scattered across multiple locations, resulting in significant fragmentation and a low level of configurability. Therefore, this application provides a conversation parsing method that uses a conditional knowledge graph to store information about callable plug-in interfaces. During the parsing process, the information about each plug-in interface in the conditional knowledge graph can be combined to directly filter out plug-in interfaces that match the user's intent, thereby obtaining output data that is more compatible with the user's intent and providing a more targeted response to the user's input text. In other words, the method provided in this application can be applied to a variety of conversation scenarios, such as the aforementioned chat, question-and-answer, or task-based conversations. For more complex, task-based, multi-round conversations, it can achieve more flexible and scalable parsing of user input data and provide more accurate and targeted responses.

[0100] The following is an introduction to the method flow provided by this application.

[0101] Referring to FIG2 , a flow chart of a conversation analysis method provided by the present application is as follows.

[0102] 201. Get the first input text.

[0103] The first input text may be text obtained based on data input by a user.

[0104] Specifically, user input data may be received, and the first input text may be obtained based on the user input data. The user input data may include text, voice, or image data. When the user input data includes text, the text in the user input data may be used as the first input text; when the user input data includes voice, the voice may be detected and recognized, thereby converting the voice into text to obtain the first input text; when the user input data includes an image, the image may be detected and recognized, thereby extracting the text corresponding to the image to obtain the first input text.

[0105] 202. Determine whether a plurality of keywords included in a first input text and the first input text correspond to a first user intention.

[0106] First, for keywords, multiple keywords corresponding to the first input text can be specifically determined. The multiple keywords can include text in the first input text or text extracted from the first input text. For example, a pre-trained keyword detection model can be used to identify the semantics of the first input text to extract keywords from the first input text. Alternatively, a large model can be used to extract keywords from the first input text, for example, by using the first input text as input to the large model and outputting keywords.

[0107] Generally, a keyword can be composed of one or more keywords. In other words, multiple keywords can also be composed of one or more keywords. Therefore, in some scenarios, the multiple keywords mentioned in this application can also be composed of one or more keywords, or the multiple keywords can also form a combination of keywords and keywords, etc. The specific term "keywords" for the extracted data can be adjusted according to the actual application scenario.

[0108] Secondly, with respect to the first user intent, the first user intent can be identified based on the first input text or based on multiple keywords. Specifically, a pre-trained language model or a large model, such as a model that can be used for NLP, NLU, or NLG, can be used to perform semantic understanding based on the first input text or the multiple keywords to identify the first user intent.

[0109] The first user intent can be represented by text or an embedded representation corresponding to the text. The specific user intent representation structure can be deployed according to the actual application scenario. For example, the first user intent can be represented directly by text. For example, if the user input data is "What are the recommended restaurants nearby", the corresponding user intent can be represented as "Search for restaurants". The user intent can also be represented by an embedded representation. For example, after identifying the user intent as "Search for restaurants", the embedding table can be queried to convert it into a corresponding vector representation.

[0110] 203. Determine at least one first interface corresponding to the first user intention based on the conditional knowledge graph.

[0111] The conditional knowledge graph may include a graph formed by information of multiple interfaces. The conditional knowledge graph may include information of multiple interfaces, and the multiple interfaces may be interfaces of plug-ins used to implement one or more functions. The information of each interface may include multiple fields, and each field forms a node in the conditional knowledge graph.

[0112] After obtaining the first input text, one or more interfaces corresponding to the first user intention can be determined from the conditional knowledge graph, which are referred to as the first interface for easy distinction. Specifically, the field of each interface in the conditional knowledge graph may include a function description field, which can be used to describe the function implemented when each API is called or the type of data output, etc. After determining the first user intention, the first user intention can be matched with the function description field corresponding to each interface, and the interface whose function description field matches the first user intention is used as the first interface.

[0113] The first user intention may specifically include text, or may include embedded representations, etc. In the case where the first user intention includes text, the text may be matched with the function description field of each interface, such as by calculating the semantic similarity between the text and the function description field of each interface, so that the interface corresponding to the function description field with a semantic similarity higher than a preset semantic similarity is taken as the first interface; in the case where the first user intention includes embedded representations, the function description field of each interface may also be converted into an embedded representation, and the similarity between the embedded representation included in the first user intention and the embedded representation corresponding to the function description field of each interface may be calculated, and the interface corresponding to the function description field with the similarity higher than the preset similarity is taken as the first interface.

[0114] Furthermore, if the function description field of each interface in the conditional knowledge graph has corresponding constraints, when the first interface is screened out from the conditional knowledge graph, the interface that matches the first user is first used as an alternative interface to obtain one or more alternative interfaces. The at least one alternative interface is verified based on the interface constraints corresponding to each alternative interface, and the alternative interface that passes the verification is used as the first interface. For example, the interface constraints corresponding to each function description can be combined to determine whether the first user's intention is within the constraint range corresponding to the interface constraint, and the interface whose first user intention is within the constraint range of the interface constraint can be used as the first interface, thereby determining the first interface that is more suitable for the first user's intention. For example, taking the "Calculate Personal Tax" API as an example, the interface constraint of the personal tax API is that the calculation range is users working in China. Then, the keyword can be combined to determine whether the user's intention meets the interface constraint. If the interface constraint is met, the API is used as the API that matches the user's intention.

[0115] 204. Obtain output text according to the multiple keywords and at least one first interface, where the output text is a response to the first input text.

[0116] Specifically, the multiple keywords and the at least one first interface may be used to call a plug-in, thereby receiving an output result of the plug-in operation, and further obtaining an output text replying to the user.

[0117] In the implementation manner of the present application, the interface information of the plug-in is stored through the conditional knowledge graph, so that after the user intent is parsed, the user intent can be matched with the interface information stored in the conditional knowledge graph, so that the plug-in query that matches the user intent can be implemented more flexibly, and the plug-in that matches the user intent more highly can be determined, thereby obtaining an output text that better matches the user intent. It can be understood that, compared to filling in slots according to pre-set slot targets when filling in slots, the method provided by the present application can be combined with the fields actually included in each interface in the conditional knowledge graph to fill in slots, so that the slot filling result matches the fields required for the call of the interface, so that when matching between user intent and the interface, a matching result with closer semantics can be obtained, thereby improving the matching accuracy between user intent and the interface.

[0118] Some possible implementations of step 204 are introduced below.

[0119] Optionally, each interface in the aforementioned conditional knowledge graph may include multiple fields, such as a function description field, a required field, an optional field, or other fields. The specific fields included in each interface can be determined based on the actual application scenario. This application only introduces some of the possible fields by way of example and is not intended to be limiting.

[0120] In a specific embodiment, the fields included in at least one first interface can be verified based on multiple keywords, and at least one second interface can be determined from the at least one first interface based on the verification results, which is equivalent to screening out an interface that is more compatible with the user's intention from the at least one first interface as the second interface; then, the output text is obtained by calling the plug-in corresponding to the at least one second interface. In the embodiment of the present application, at least one first interface can be verified based on keywords obtained from the data input by the user, thereby screening out an interface that has passed the verification and is more compatible with the user's intention, and then the output text of the reply to the user is obtained by calling the second interface.

[0121] In one possible implementation, multiple keywords can be matched with the fields of each first interface, and the keywords can be filled into the matching fields to obtain the filling results of each first interface; the filling results of each first interface can be verified, and at least one second interface is an interface that has passed the verification among at least one first interface. For example, if the first input text includes "Guangdong, Shenzhen", and a field of a first interface includes "province, city", it can be recognized that "Guangdong" matches "province" and "Shenzhen" matches "city", then "Guangdong" is filled into "province" and "Shenzhen" is filled into "city", resulting in "province: Guangdong, city: Shenzhen".

[0122] Specifically, the process of verifying the filling result of each first interface may include determining whether the filling result of the first interface satisfies the constraint conditions of the interface. If the filling result satisfies the constraint conditions, the verification passes; if the filling result does not satisfy the constraint conditions, the verification fails. Therefore, the constraint conditions set in the conditional knowledge graph can be used to condition the field filling results of each interface, thereby constraining the interface filling result of the callable plug-in to be within the range of the constraint.

[0123] Furthermore, the fields corresponding to each interface can be divided into mandatory fields, optional fields or other fields. Mandatory fields are fields in the interface that must be filled when calling the plug-in. Optional fields are fields in the interface that can be filled or not when calling the plug-in. Other fields can be fields that are added or adjusted according to the specific circumstances of different APIs. When filling in fields, mandatory fields must be filled before calling the plug-in, while optional fields can be filled when the first input text includes the keyword of the optional field. If the first input text does not include the keyword of the optional field, the user can be guided to enter the field through a dialogue, or the field can be directly set to empty when calling the plug-in. The specific field can be determined according to the actual application scenario.

[0124] Priorities can also be distinguished for fields. For example, mandatory fields take precedence over optional fields, and optional fields take precedence over other fields. When matching keywords with interface fields, fields with higher priorities can also be matched first, that is, mandatory fields are filled first, thereby ensuring that mandatory fields are filled and that plug-ins can be called first.

[0125] For example, the fields of each interface may include mandatory fields, i.e., fields that must be filled in when calling the plug-in corresponding to the interface. Keywords in the first input text may be matched with the mandatory fields of each first interface, and the keywords may be filled into the corresponding mandatory fields to obtain a filled result. The filled result of each first interface may then be verified according to the constraints corresponding to the mandatory fields to obtain a verification result corresponding to each first interface. At least one second interface may be determined from at least one first interface based on the verification result corresponding to each first interface. That is, the at least one second interface is obtained by screening from the at least one first interface.

[0126] In addition, during the field filling process, some fields may not be filled. In this case, the user can be guided to enter the input data of the unfilled fields through the next round of dialogue to improve the completeness of the interface input data of each plug-in.

[0127] Specifically, when filling in fields, multiple keywords can be matched with the fields of each first interface, and the keywords can be filled into the corresponding fields. When multiple fields of each first interface are filled, a filling result is obtained; when the fields in the first interface include unfilled fields, a follow-up text can be generated, and the follow-up text is used to ask the user about the unfilled fields to guide the user to input the unfilled fields; then a second input text corresponding to the follow-up text is obtained; when the second input text includes keywords corresponding to the unfilled fields, the unfilled fields are filled according to the keywords in the second input text to obtain a filling result. Therefore, in an embodiment of the present application, when one round of dialogue does not obtain the information required to call the interface, a follow-up text can be generated to ask about the missing information, guiding the user to enter the missing information in the next round of dialogue, thereby enriching the information input into the plug-in interface when calling the plug-in.

[0128] In one possible implementation, if the second user intent corresponding to the second input text does not match the first user intent, a new interface corresponding to the second user intent may be determined based on the second user intent. This mismatch may occur because the first user intent and the second user intent are different, or because the similarity between the first user intent and the second user intent is lower than a threshold.

[0129] When verifying the keywords filled in the fields of each interface, it can be determined whether the filling result corresponding to each first interface meets the constraints corresponding to each first interface; if so, it means that the filling result corresponding to the first interface has passed the verification; if not, it means that the filling result corresponding to the first interface has not passed the verification. Therefore, in the embodiment of the present application, the constraints set in the conditional knowledge graph can be used to verify the filling keywords of the fields of each first interface, so as to obtain a filling result that meets the constraint range of each field, so that the first interface that can adapt to the keywords in the first input text can be screened out from the first interface, so that the second interface that is more in line with the first user's intention can be determined.

[0130] Optionally, the aforementioned constraints may specifically include intra-field constraints and inter-field constraints. The intra-field constraints include the conditions that the input parameters must satisfy when calling each interface, and the inter-field constraints include the conditions that the input parameters must satisfy when calling each interface. Therefore, when verifying the fill results of each field, verification can be performed based on the constraints between the fields, or the constraints within the field, so that the interfaces ultimately selected are those whose fill results meet the constraints.

[0131] In the implementation mode of the present application, for the user dialogue scenario, a conditional knowledge graph is used to represent the information of multiple interfaces. When a certain interface needs to be added or adjusted, the node corresponding to the interface or the corresponding constraint condition in the conditional knowledge graph can be adjusted, thereby achieving more flexible interface adjustment and realizing the configurability of the interface or plug-in. Because the constraint conditions of the fields of each interface are set in the conditional knowledge graph, when selecting an interface, the adapted interface can be selected based on the constraints corresponding to the fields in the interface, which is equivalent to using the constraints corresponding to the fields to verify the available interfaces, thereby realizing the configurability of the interface parameter verification. It can also facilitate the expansion of the interface and has very high scalability.

[0132] In one possible implementation, to generate conversation content, the output of at least one second interface can be used as input to the macro model to generate output text. This allows the macro model to generate content that is more tailored to the user's needs. Typically, the output from calling the second interface can be a data index stored in a database or other storage device after the plugin runs, or a direct representation vector. Therefore, the macro model can be used to convert the output from calling the plugin into natural language, allowing the user to obtain the information they need.

[0133] In addition, in a possible scenario, when the user input data is text, image, voice or other types of data, after obtaining the output text, the output text can be output directly, or the output text can be converted into output data such as image or voice that is the same as the input data type, so as to communicate with the user in the dimension of the same data type, thereby realizing a more intelligent dialogue function.

[0134] The above describes the method flow provided by this application. The following describes the method flow provided by this application in more detail in combination with specific application scenarios.

[0135] Refer to Figure 3, which shows the architecture of a conversation backend system provided by this application. The conversation backend system 30 may include:

[0136] Input module 31 , parsing module 32 , dialogue management module 33 , execution center 34 , decoding module 35 and output module 36 .

[0137] The functions of each module include:

[0138] Input module 31: Receives user input data. This may include user-entered data such as voice, images, and text. For example, for voice data, automatic speech recognition (ASR) is typically used to convert the speech into text. For image data, pre-trained neural networks can be used to extract text from the image. Generally, if the input data is text, no conversion is required.

[0139] Parsing module 32: used to parse the input text information and convert it into a machine-understandable semantic representation. This module relies on natural language understanding (NLU) to identify the user's intent and the semantic slot under the intent from the text information. For example, "What are the popular Cantonese restaurants in Futian District, Shenzhen?" The user's intent is to "search for restaurants", and the semantic slot is "location" is "Futian District, Shenzhen", "popularity" is "high", and "cuisine" is "Cantonese cuisine". Specifically, parsing module 32 may include modules such as intent understanding 321, slot filling 322, and slot value verification 323. The intent understanding module 321 is used to understand the user's intent based on the input text. The slot filling module 322 is used to fill the slot based on the conditional knowledge graph. For example, the field in the interface in the conditional knowledge graph that matches the user's intent is used as the slot to fill. The slot value verification 323 module is used to verify the filled slot using the constraints set in the conditional knowledge graph to obtain a more accurate slot value.

[0140] Dialogue Management Module 33: Based on the semantic representation output by the Parsing Module, it updates the dialogue state and selects a response action based on the policy. This module primarily includes the Dialogue State Tracker (DST) 331 and the Dialogue Policy Learning (DPL) 332. The Dialogue State Tracker 331 is responsible for maintaining the state of multiple rounds of dialogue, generating a new dialogue state based on historical dialogue states, the current input from the Parsing Module 32, and the background knowledge base. The primary function of the Dialogue State Tracker 331 is to memorize and predict. Through continuous interaction with the user, it gradually refines its understanding of the user's state. A common implementation involves determining whether the current dialogue is a continuation of the previous round or the beginning of a new round. The Dialogue Policy Learning Module 332 uses the current dialogue state output by the DST Module 331 to determine the system's action. For example, it selects which plugin to invoke based on the plugin function description information in the conditional knowledge graph. For example, in the example from the Parsing Module 32, this module would select the "search" action, invoking the search plugin to search for highly viewed Cantonese restaurants in Shenzhen's Futian District.

[0141] Execution Platform 34: This is the execution platform that specifically performs a specific action. For example, if a user enters "What are some popular Cantonese restaurants in Shenzhen's Futian District?" and needs to perform a "search" action, the execution platform will perform a specific web search action and return the search results. This platform may specifically include a task execution module 341, which can be used to execute the called plug-in.

[0142] Decoding module 35: This module decodes the results of the execution process into a user-friendly format, typically by converting them into natural language. For example, if the restaurant ID in the database table is "R07" and the restaurant information with the ID "R07" is stored in the backend database, the natural language translation might be "Hello, the most popular Cantonese restaurant nearby is XX Xuan, located at xxx Road, xxx."

[0143] Output module 36: This module is used to return the results generated by the decoding module to the user using the same output data type as the input data type of the input module. This can be achieved by using a chat box, speaker, or other means to provide the user with feedback on the conversation content. For example, input in a web chat box typically returns the results in the form of a web page. Input in the form of speech typically converts natural language into speech using a text-to-speech (TTS) solution, and returns the results in the form of speech.

[0144] Compared with existing solutions, the dialogue backend system provided by this application specifically improves the slot filling, slot value verification, and other modules for the parsing module. In the slot filling module, the shortcomings of the preset slot template, such as mechanization, inflexibility, and poor scalability, are improved by adopting a configurable approach to achieve dynamic scalability. Secondly, the shortcomings of the slot value verification module, which uses preset rules to verify the logic code, such as poor scalability and reusability, and high verification rule development and maintenance costs, are improved. The architecture provided by this application allows for configurable verification logic.

[0145] For the dialogue management module, targeted improvements are made to the dialogue strategy learning module. The use of preset response templates, or the use of large models to generate AI dialogues one by one based on a preset parameter list, can lead to mechanical and irrelevant answers, as well as fragmented parameter modifications. A centralized configuration approach is adopted to achieve unified configuration of verification rules and parameter parsing, thus achieving configurability. At the same time, the information interaction between slot filling and slot value verification in the dialogue strategy learning module and the parsing module is strengthened to improve the weak interactivity between the responses generated by the existing dialogue strategy learning module and the user's input. At the same time, the slot filling and slot value verification results in the parsing module are used to guide the dialogue strategy learning module to generate a new round of dialogue, achieving a more purposeful and interactive multi-round dialogue design.

[0146] To facilitate understanding, the structure of the conditional knowledge graph is first introduced below.

[0147] This conditional knowledge graph can be used when calling third-party plug-ins for parameter parsing and parameter verification. Through the conditional knowledge graph provided by this application, it is possible to guide multiple rounds of dialogue and complete the parameter parsing of plug-ins one by one, so that the plug-in completes parameter parsing and is smoothly executed in the execution center.

[0148] For example, refer to Figure 4, which is a structural diagram of a conditional knowledge graph provided in this application.

[0149] The structure of the conditional knowledge graph can be divided into multiple parts, such as multiple fields and corresponding constraints. For example, fields can be function descriptions, required fields, optional fields, or other fields. Constraints can be divided into interface constraints (API conditions), intra-field constraints, or inter-field constraints.

[0150] Functional description: This describes the specific purpose of an API (or its corresponding plug-in), including description content and keywords. This description is used by the intent parsing module to match the plug-in to be called based on the identified semantics during intent recognition. For example, the functional description of an API might be: "Query weather information for a certain area on a certain day." When a user enters "Help me find the weather in Shenzhen today," the API is called based on semantic matching, thus achieving intent understanding.

[0151] API condition: This field is used to constrain the scope of an API and can be used to verify matching APIs during intent parsing. For example, if an API is restricted to "only for Chinese citizens," this information is configured in the API condition field to verify the scope of the API.

[0152] Required fields: Fields that must be entered when calling the API, and fields that need to be filled when filling slots in the method provided by this application.

[0153] Optional fields: Fields that can be filled in when calling the API.

[0154] Other fields: Other fields related to the API, which can be set according to specific circumstances.

[0155] Field constraints: Conditions that the parameters input to the API must meet. These can be logical operators, logical checksums, or natural language descriptions of restrictions. Examples include value ranges and enumerations. For example, for gender, the value range is [Male, Female].

[0156] Inter-field constraints: These are constraints that must be met between parameters when calling an API. These constraints can be a logical operator, logical checksum code, or a natural language description. For example, the relationship between the province field and the city field must meet geographic common sense, while the relationship between the disease field and the gender field must meet medical common sense.

[0157] When querying the corresponding API from the conditional knowledge graph, you can set the priority of each type of field during the query. For example, the query priority is from high to low: function description, API condition, required field, optional field, and other fields. Intra-field constraints and inter-field constraints are the constraints that fields must satisfy and the constraints that must be satisfied between fields, respectively. When the parsing module parses a field with a corresponding intra-field constraint or inter-field constraint, the API is called only when the verification passes.

[0158] For example, as shown in Figure 5, the structure of the individual tax query API can be used. The API's functional description can be "Calculate segmented individual income tax," and the corresponding API condition can be set to "Individual tax query for Chinese citizens." Required fields can include one or more, such as "province," "city," "gender," or "monthly salary." The intra-field constraint for "province" can be set to "values ​​within the 34 provincial-level administrative regions," the inter-field constraint between "province" and "city" can be set to "must meet geographical common sense," and the intra-field constraint for "gender" can be set to "value range [male, female]." Optional fields can include "Do you have minor children?" and "Do you support someone over 60?", and the inter-field constraint between the optional fields can be set to "Choose one of the two." When setting priorities, the functional description priority can be set to "Highest," the API condition priority can be set to "High," the required fields can be set to "Medium," and the optional fields can be set to "Low."

[0159] The following is an introduction to the steps performed by the dialogue background provided by this application in combination with the aforementioned background dialogue system and conditional knowledge graph.

[0160] For example, as shown in FIG6 , the flowchart of another conversation parsing method provided by the present application is as follows.

[0161] 601. The input module receives input data.

[0162] The input module can receive user input data. If the user input data is text, the text can be directly used as input to the parsing module. If the user input data is non-text, such as an image or voice, the user input data can be converted into text and used as input to the parsing module. For example, if the user input data is "What are the popular Cantonese dishes in Futian District, Shenzhen", keywords that can be identified from the text may include "Shenzhen", "Futian District", "popular", "restaurant", "Cantonese cuisine", "search", etc.

[0163] 602. The intent understanding module identifies keywords and user intent.

[0164] After receiving the input text from the input module, the intent understanding module can identify the keywords corresponding to the input text and the user intent.

[0165] Specifically, semantic recognition can be performed on the input data to extract keywords that can be used to express semantics. For example, a pre-trained language model or a pre-trained large model can be used to identify keywords in the input data, thereby identifying the semantics of the user's input data and obtaining keywords that can be used to express semantics.

[0166] Specifically, when identifying the user's intention, a language model can be used for identification, or a large model can be used for identification. The input for identifying the user's intention can be a keyword or an input text from an input module.

[0167] For example, if the user input is "What delicious hot pot restaurants are there in Luohu District, Shenzhen", the corresponding user intent may be "search for restaurants".

[0168] For another example, if the user input is "Calculate how much tax I have to pay this month", the corresponding user intent may be "Calculate personal income tax".

[0169] For the conversation between the user, it can be a multi-round conversation, and the subsequent conversation branches can be divided into initial conversation and multi-round conversation branches. The initial conversation is the first round of conversation for the current user intention or the first time the user enters text, etc. The multi-round conversation is one or more rounds of conversation for the current user intention.

[0170] If the current conversation is not the first one, step 603 may be executed, i.e., determining whether the user's intention has changed. If the current conversation is not the first one, step 604 may be executed directly, i.e., matching the API as the initial conversation.

[0171] 603. The dialogue state tracking module determines whether the user intention has changed. If so, step 604 is executed; if not, step 606 is executed.

[0172] In a non-first round of conversation, after identifying the user's intention, it can be determined whether the user's intention has changed. If it has not changed, step 606 can be executed, that is, filling in the fields of the API that has matched the user's intention. If the user's intention has changed, step 604 can be executed, which is equivalent to starting a new round of conversation.

[0173] For example, after multiple rounds of conversations with the user, in one of the rounds of conversations, after identifying the user intent, determine whether the user intent in this round of conversation is the same as the user intent in the previous round of conversation. If they are the same, you can continue to fill in the fields of the API that has matched the user intent to determine the API that is more suitable for the user intent, that is, execute step 606. If they are not the same, you can use the user intent of this round of conversation as the new user intent to start a new round of conversation, that is, trust step 604.

[0174] For example, if the user intent in the previous round of conversation was "search for restaurants", and the user intent in this round of conversation is "calculate personal income tax", a new round of conversation can be started based on the user intent of "calculate personal income tax".

[0175] 604. Combine conditional knowledge graph to create user intent matching API.

[0176] During the initial conversation or the start of a new round of conversation, the conditional knowledge graph can be combined to match the user's intent with an API, that is, the conditional knowledge graph is searched for an API that is compatible with the user's intent. The API that is compatible with the user's intent is the first interface mentioned above.

[0177] Optionally, in multiple rounds of conversation, if the user intent corresponding to the current round of conversation is the same as that of the previous round of conversation, there is no need to re-match the API for the user, that is, the API that matched the user intent in the previous round of conversation is used as the API that matches the user intent in the current round.

[0178] Specifically, when it is necessary to match an API for user intent, the user intent can be matched with the function description field of the API in the conditional knowledge graph, so as to filter out the API whose function field matches the user intent. The API that matches the user intent is the first interface mentioned above.

[0179] For example, if the user intention is "search for restaurants", the user intention can be matched with the functional description of the API in the conditional knowledge graph. For example, the semantic similarity between the user intention and the functional description of each API can be calculated, and the API with a semantic similarity greater than the preset similarity can be regarded as the API that matches the user intention, that is, the API of the plug-in used to execute the "search for restaurants" function can be regarded as the API that matches the user intention.

[0180] In addition, after determining the API that matches the user's intention, it can be further verified in combination with the API condition, and the API that passes the verification can be regarded as the API that matches the user's intention. Specifically, the keywords in the input text can be combined to determine whether they are within the API condition constraint range. If so, the verification passes and the API is regarded as the API that matches the user's intention. If not, the verification fails and no subsequent processing is required for the API. Generally, in actual application scenarios, there are many types of verification failures. For example, if the keywords filled into the field do not meet the constraints corresponding to the field, or the field is filled with empty space, etc., it can be considered that the verification failed, and there is a situation where information is missing.

[0181] This means that after entering the intent understanding module, intent matching is performed based on the functional description fields of all plug-in APIs, and one or more plug-in APIs are filtered from the conditional knowledge graph. For APIs that pass the matching, the API condition is used to verify the intent. If the verification passes, the next step is carried out. If the verification fails, the API matching continues and the APIs that fail the current verification are eliminated.

[0182] In one scenario, if no API matching the user's intent is found, a corresponding dialog can be generated. That is, step 609 is executed, where a response is given to the API that does not match the user's intent, or a large model is used to output a response dialog text to the user's input data.

[0183] 605. Query the corresponding API field from the conditional knowledge graph.

[0184] After determining one or more APIs corresponding to the user's intent, other fields of the API can be queried from the conditional knowledge graph, such as the required fields, optional fields, or other fields of the API.

[0185] For example, the required, optional, or other fields of APIs that match user intent can be queried from the conditional knowledge graph and stored in the cache. For example, it may take multiple rounds of conversation to collect field information for APIs that match user intent. The fields corresponding to APIs that have matched user intent, including required and optional fields, can be stored in the cache.

[0186] For example, in the "Calculate Personal Income Tax" plug-in API, the fields of the API may include required fields such as "province", "city", "gender" or "monthly salary", and optional fields may include "whether there are underage children" or "whether to support elderly people over 60 years old".

[0187] 606. The slot filling module performs field filling based on the API field.

[0188] The slot filling module fills the fields of the API that match the user's intent based on the keywords in the input text. For example, the keywords in the input text are filled into the required fields, optional fields, or other fields of the API.

[0189] For example, as shown in Figure 5 above, in the individual income tax query API, required fields may include "province," "city," "gender," and "monthly salary." If the user's input text includes keywords related to these required fields, the keywords can be filled into the corresponding required fields. For example, if the input text includes the keyword "female," the keyword "female" can be filled into the "gender" field, resulting in "Gender: Female."

[0190] 607. The slot verification module performs verification based on the conditional knowledge graph.

[0191] After filling the keywords in the input text into the API field, the filled field can be verified based on the corresponding constraints in the conditional knowledge graph. For example, it can be determined whether the keywords filled into the field meet the constraints set in the conditional knowledge graph. If the keywords filled in the field meet the constraints, it means that the verification is passed. If the keywords filled in the field do not meet the constraints, it means that the verification has failed. The verified filling results and the fields that failed the verification can be output.

[0192] Typically, multiple rounds of dialogue may be generated to fill in the fields of the API that match the user's intent. Therefore, a target field list can be built to cache fields that have not passed the validation or have not been filled, so as to record the fields that have not passed the validation or have not been filled.

[0193] Specifically, based on the fields in the filled slot information, you can query the conditional knowledge graph for the conditions in the intra-field constraints or inter-field constraints of the field, record the fields that failed verification or were not filled, and add them to the target field list. For fields that have passed verification, remove them from the target field list.

[0194] For example, if the input text contains keywords such as "Guangdong" and "Shenzhen," "Guangdong" is entered into the "Province" field as "Province: Guangdong," and "Shenzhen" is entered into the "City" field as "City: Shenzhen." Verification can be performed on the results of the "Province" and "City" fields. For example, if the field constraint for the "Province" field is "values ​​within the 34 provincial-level administrative regions," the entered "Guangdong" passes verification. The inter-field constraint between "Province" and "City" is "must satisfy geographical common sense." Geographical common sense states that "Guangdong" and "Shenzhen" have an administrative relationship. Therefore, the inter-field constraint between the "Province" and "City" fields satisfies the constraint and passes verification. For example, if the user enters "Wuhan City, Guangdong Province," the "Province" field is filled with "Guangdong," and the "City" field is filled with "Wuhan," verification fails because the inter-field constraint "must satisfy geographical common sense" is not met.

[0195] 608. The dialogue management module determines whether the field is missing based on the verification result. If so, execute step 609; if not, execute step 610.

[0196] After the slot verification module performs verification, it outputs the verified filling results and target field list. The filling results include key information filled in each field of the API that matches the user's intent, such as "Province: Guangdong, City: Shenzhen". The target field list is a list of fields that failed verification and fields with unfilled information. For example, if the user's input data does not include fields such as "Name, Gender, Monthly Income", these unfilled fields will be stored in the target field list to record the unfilled fields.

[0197] Optionally, the interface fields included in the conditional knowledge graph may include required fields, optional fields or other fields, etc. In the target field list, only required fields may be recorded, or all types of fields of each interface may be recorded. The specific method can be determined according to the actual application scenario. Accordingly, when judging whether there is a missing field, if only required fields are recorded in the target field list, it can be directly judged whether the target field list includes the field; in the case of recording all fields of the interface in the target field list, it can be chosen to judge whether there is a required field. If there is a required field in the target field list, it is considered that there is information missing. If there is no required field in the target field list, it can be chosen to continue to judge whether there is an optional field or other field missing. If there is an optional field or other field missing, there is a field missing in the task; if there is no required field in the target field list, it can also be considered that there is no field missing. The specific judgment method can be determined according to the actual application scenario. This application is only an illustrative introduction and is not intended to be limiting.

[0198] Specifically, the dialogue management module can determine whether there are missing fields by whether the target field list includes unverified fields or unfilled fields. If there are unverified fields or unfilled fields in the target field list, it is determined that the field is missing, and information about the missing fields can be collected by dialogue with the user; if the target field list is empty, it means that there are no missing fields or no required fields are missing, and the plug-in corresponding to the API that has matched the user's intention can continue to be called to obtain the required information, that is, execute step 610, such as calling the plug-in corresponding to the restaurant information query API to obtain specific restaurant addresses and user reviews and other information.

[0199] If one or more API fields that match the user's intent all pass verification, indicating that the fields are not missing, the corresponding API plug-in can be called, that is, step 610 is executed; if the API fields that match the user's intent do not pass verification, indicating that the fields are missing, a dialogue can be generated to obtain the missing fields, that is, step 609 is executed. For example, if the keywords in the user's input data only include "province" and "city" is omitted, a dialogue content can be generated to ask the user about "city" to guide the user to enter the "city" field, and the "city" field can be further filled based on the user's response.

[0200] In one possible scenario, the number of APIs that match the user's intent may be one or more. In the scenario where there are multiple APIs that match the user's intent, if all fields of any of the APIs have been filled and verified, the plug-in corresponding to the API can be called by executing the middle platform. Of course, it is also possible to call the plug-ins corresponding to the multiple APIs after all fields of all APIs have been filled and verified, which is not limited here. If there is no API with all fields filled and verified among the multiple APIs that have matched the user's intent, 609 can be executed, that is, information about fields that have not been verified or filled can be obtained through dialogue.

[0201] 609. Generate dialogue.

[0202] Among them, there may be many situations in which a dialogue is generated. For example, when no API that matches the user's intention is found in the conditional knowledge graph, a dialogue may be generated to prompt the user to re-enter or prompt the user that no relevant information has been retrieved; or, when there are unverified fields or unfilled fields in the fields of the API that has matched the user's intention, a dialogue text, or a follow-up text, may be generated and output for the unverified fields or unfilled fields.

[0203] Optionally, when generating conversational text, a large model can be used to generate the text, thereby producing text that is consistent with the user's conversation. The large model can be trained using a large amount of training data and can learn the user's conversational language. Therefore, the large model can output conversational content that is more compatible with the user's language habits, improving user comprehensibility. For example, "Which city do you live in?" can be used to guide the user to enter information in the "city" field.

[0204] For example, if no API matching the user's intent is found in the conditional knowledge graph, a corresponding dialogue can be generated. If no API is found, or if no plug-in API is found after N cycles, the large model can be used to infer the input information from the input module and output the large model. This output is then fed into the decoding module for output. For example, if no API matching the user's intent is found in the conditional knowledge graph, a prompt text can be generated and fed back to the user. For example, the user can be prompted with "I don't understand what you mean" or "Please rephrase your question" to prompt the user to re-enter or start a new round of dialogue; alternatively, the big model can output the corresponding output text based on the user's input data. For example, if the user input is "How to produce a car", then if the API is not matched, if the big model is a model that supports casual conversation, the user's input text can be directly used as the input of the big model, and the big model's response text for "How to produce a car" can be output, such as "The production of a luxury car requires the design stage, engineering development, raw material procurement, production assembly, quality control, fine decoration, quality inspection and test drive..." etc.

[0205] For example, if there are unverified or unpopulated fields among the fields that have been matched with the user's intent, the big model can be used to output follow-up text for the unverified or unpopulated fields. For example, if the "province" field has not passed the verification or is missing, the big model can be used to output follow-up text for "province", such as using the big model to output "Which province do you work in?" to guide the user to enter input data for the "province" field.

[0206] After executing step 609 , step 601 may be executed again, that is, the data input by the user is obtained again, and the next round of dialogue is entered, that is, step 601 is executed in a loop.

[0207] 610. The execution center calls the plug-in to execute the task.

[0208] Among them, there are many situations in which the execution center calls the plug-in to perform tasks. For example, in the process of executing the aforementioned steps 601-step 609 or repeatedly executing steps 601-step 609, once an API that matches the user's intention and passes the verification appears, the API can be called as the second interface.

[0209] Alternatively, after looping through steps 601-609, one or more APIs that match the user's intent and pass verification are screened out, and the one or more APIs can be called as the second interface. Furthermore, when there are multiple APIs that match the user's intent and pass verification, all of the multiple APIs can be called as the second interface; or one of the APIs can be selected as the second interface to be called, specifically, an API can be randomly selected as the second API, or the API with the highest degree of match between the user's intent and the function description field can be selected as the second API, etc.

[0210] That is, after executing the aforementioned steps 601-609 or looping through the aforementioned steps 601-609, one or more APIs that have matched the user's intent and whose filled-in fields have passed verification can be obtained. The execution center can then call the one or more APIs, and the called API is the aforementioned second interface, to execute the plug-in corresponding to the one or more APIs to obtain the output result.

[0211] It is understandable that the conversation backend system provided by this application is the main program, and each plug-in interacts with the main program through the API. After obtaining the filling results of each field to be called and inserted into the API, the filling results of each field can be used as input parameters of the API of the plug-in to be called to run the plug-in to obtain the output data of running the plug-in. Specifically, the plug-in can be started and run in the operating environment provided by the conversation backend system provided by this application. For example, the operating environment of the conversation backend system provided by this application is deployed in the host of the plug-in. When the conversation backend system needs to call the plug-in, the API filling results can be transmitted to the host where the plug-in is deployed to run the plug-in. The host feeds back the output results obtained by running the plug-in to the conversation backend system. It is also possible to add the plug-in to the conversation backend system provided by this application, so that in the conversation backend system, the plug-in is directly run with the filling results of the plug-in API as input to obtain the output results of the plug-in operation.

[0212] For example, if the API that matches the user's intention is a "Search Restaurant" API, that is, a plug-in for searching for restaurants, and the field filling results of the API have passed verification, such as the filling results of fields such as "restaurant star rating", "restaurant area" or "taste" have passed verification, then the dialogue background system can call the plug-in corresponding to the "Search Restaurant" API. Specifically, the "Search Restaurant" plug-in can be deployed in a host that is different from the dialogue background system. The dialogue background system can transfer its operating environment to the host where the "Search Restaurant" plug-in is deployed, and when the plug-in needs to be called, the API filling results are passed as input into the host to run the "Search Restaurant" plug-in in the host. The host feeds back the running results of the plug-in to the dialogue background system, such as feeding back the information of the searched restaurant to the dialogue background system. Alternatively, the "Search Restaurant" plug-in can be added to the dialogue background system. When the dialogue background system determines that the plug-in needs to be called, it can use the field filling results of the API as input to directly start the plug-in locally to obtain the output result of the plug-in operation.

[0213] 611. The decoding module decodes the plug-in output.

[0214] After the execution center calls the plug-in to obtain the output result, it transmits the output result to the decoding module, and uses the decoding module to convert the output result into natural language, that is, output text and output it to the output module.

[0215] Specifically, the decoding module can be implemented by a decoder, which can decode the output of the plug-in using mechanisms such as self-attention or cross-attention. If the output of the plug-in is usually an embedded representation or output feature, the decoder can be used to convert the output of the plug-in into natural language, thereby obtaining the output text of the response to the user.

[0216] 612. The output module outputs data to the user.

[0217] Typically, the output module can output data of the same type as the input module's input data. For example, if the input module receives speech, the output module will output speech. Typically, the output module can output through a chat box, microphone, or other means. For example, if the user inputs in a web chat box, the output module will typically return the output text in the chat box in the form of a web page. If the user inputs in the form of speech, the output module will typically convert natural language into speech, using text to speech (TTS) to convert the output text into speech, and then return the output result in the form of speech.

[0218] Therefore, in the implementation of this application, a conditional knowledge graph is set up to store the interface parameters of each plug-in, and the conditional knowledge graph is introduced into the dialogue background system. This enables multiple rounds of dialogue to obtain the parameters to be parsed from the conditional knowledge graph, thereby guiding the generation of speech for the next round of AI dialogue, enabling AI dialogue to conduct targeted parameter parsing and prompting users to provide target parameter information in natural language. This achieves stronger interaction with user input in the target parameter field and more human-like AI speech generation.

[0219] Furthermore, conditional knowledge graphs can be combined to verify the input parameters required by each plug-in API. If parameter verification fails, it can be assumed that the unverified field is missing information, and multiple rounds of dialogue can be used to guide the generation of the next round of dialogue. Furthermore, large models can be used to generate AI dialogue content, enabling AI dialogues to provide timely feedback on the results and reasons for parameter verification failures, and prompt users to make corrections in natural language. This enables stronger user error correction interaction and more human-like AI dialogue generation.

[0220] The above is an introduction to the method flow provided in this application. The following is a further introduction to the device results provided in this application in combination with the above method steps.

[0221] Referring to FIG7 , a schematic diagram of the structure of a conversation backend system provided by the present application, the conversation backend system includes:

[0222] An input module 31 is configured to obtain a first input document;

[0223] a parsing module 32 for determining a plurality of keywords included in the first input text and whether the first input text corresponds to a first user intention;

[0224] The parsing module 32 is further configured to determine at least one first interface corresponding to the first user intent based on the conditional knowledge graph, where the conditional knowledge graph includes information about multiple interfaces, where the multiple interfaces are interfaces of a plug-in for implementing at least one function;

[0225] The execution center 34 is used to call the plug-in corresponding to the interface output by the analysis module 32 to obtain the output result;

[0226] The dialogue management module 33 is configured to obtain an output text according to the output result, where the output text is a reply to the first input text.

[0227] In a possible implementation, the parsing module 32 is further configured to verify fields included in the at least one first interface according to a plurality of keywords, and determine at least one second interface from the at least one first interface according to the verification result;

[0228] The execution center 34 is specifically used to obtain the output result by calling the plug-in corresponding to at least one second interface.

[0229] In a possible implementation, the multiple fields include a function description field, which is used to describe the function implemented when each interface is called;

[0230] The parsing module 32 is specifically configured to match the first user intention with the function description field corresponding to each interface to determine at least one first interface.

[0231] In a possible implementation, the information of each interface in the conditional knowledge graph includes an interface constraint, and the interface constraint is used to indicate the scope of functions supported by each interface;

[0232] The parsing module 32 is specifically used to: match the first user intention with the function description field corresponding to each interface to obtain at least one alternative interface; and verify at least one alternative interface according to the interface constraint corresponding to each interface to obtain at least one first interface.

[0233] In one possible embodiment, the parsing module 32 is specifically used to: fill multiple keywords into the fields included in at least one first interface to obtain the filling results of each first interface; verify the filling results of each first interface, and at least one second interface is an interface that has passed the verification in at least one first interface.

[0234] In one possible embodiment, the parsing module 32 is specifically used to: match multiple keywords with the required fields of each first interface, and fill the keywords into the corresponding required fields; when multiple fields of each first interface are filled, output the filling result of each first interface; when the multiple fields in each first interface include unfilled fields, generate a follow-up text; obtain a second input text corresponding to the follow-up text; when the second input text includes keywords corresponding to the unfilled fields, fill the unfilled fields according to the keywords in the second input text, and output the filling result of each first interface.

[0235] In a possible implementation, the parsing module 32 is further configured to: if the second user intent corresponding to the second input text does not match the first user intent, then redetermine the interface corresponding to the second user intent

[0236] In a possible implementation, the dialogue management module 33 is further configured to use the large model to generate text corresponding to the unfilled fields to obtain a follow-up question text.

[0237] In one possible implementation, the parsing module 32 is specifically used to determine whether the filling result corresponding to each first interface meets at least one constraint condition corresponding to each first interface; if so, it means that the filling result corresponding to the first interface has passed the verification; if not, it means that the filling result corresponding to the first interface has not passed the verification.

[0238] In one possible implementation, the constraints are divided into intra-field constraints and inter-field constraints. The intra-field constraints include the conditions that the input parameters must satisfy when calling each interface, and the inter-field constraints include the conditions that the input parameters must satisfy when calling each interface.

[0239] In a possible implementation, the input module 31 is specifically configured to: obtain user input data, where the type of the user input data includes text, image, or voice; and obtain text corresponding to the user input data according to the large model to obtain a first input text.

[0240] In one possible implementation, the device further includes:

[0241] The output module 36 is used to generate output data corresponding to the output text using the large model, and the type of the output data is the same as the type of the user input data.

[0242] In addition, the device provided in the present application may also include a decoding module 35 for decoding the data output by the dialogue management module 33 and using the decoding result as input to the output module 36 to output the dialogue content with the user.

[0243] Each module in the aforementioned conversation backend system can be implemented via software or hardware. As an example, the following describes the implementation of the parsing module. Similarly, the implementation of other modules, such as the input module, conversation management module, execution center, decoding module, or output module, can refer to the implementation of the parsing module.

[0244] As an example of a software functional unit, a parsing module may include code running on a computing instance. The computing instance may be at least one of a physical host (computing device), a virtual machine, a container, and other computing devices. Furthermore, the computing device may be one or more. For example, the parsing module may include code running on multiple hosts / virtual machines / containers. It should be noted that the multiple hosts / virtual machines / containers used to run the application may be distributed in the same region or in different regions. The multiple hosts / virtual machines / containers used to run the code may be distributed in the same AZ or in different AZs, and each AZ includes one data center or multiple data centers with close geographical locations. Typically, a region may include multiple AZs.

[0245] Similarly, the multiple hosts / virtual machines / containers running the code can be distributed within the same VPC or across multiple VPCs. Typically, a VPC is located within a region. Cross-region communication between two VPCs within the same region, or between VPCs in different regions, requires a communication gateway within each VPC to interconnect the VPCs.

[0246] As an example of a hardware functional unit, a parsing module may include at least one computing device, such as a server. Alternatively, the parsing module may be implemented using a CPU, ASIC, PLD, CPLD, FPGA, GAL, DPU, NPU, SoC, offload card, accelerator card, etc. The PLD may be implemented using a CPLD, FPGA, GAL, or any combination thereof.

[0247] The multiple computing devices included in the parsing module can be distributed in the same region or in different regions. The multiple computing devices included in the parsing module can be distributed in the same AZ or in different AZs. Similarly, the multiple computing devices included in the parsing module can be distributed in the same VPC or in multiple VPCs. The multiple computing devices can be any combination of servers, ASICs, PLDs, CPLDs, FPGAs, GALs, DPUs, NPUs, SoCs, offload cards, accelerator cards, and other computing devices.

[0248] As an example of a software functional unit, a module can include a code running on a computing instance. The computing instance can be at least one of a physical host (computing device), a virtual machine, a container, and other computing devices. Furthermore, the above-mentioned computing device can be one or more. For example, the dialogue backend system can include code running on multiple hosts / virtual machines / containers. It should be noted that the multiple hosts / virtual machines / containers used to run the application can be distributed in the same region or in different regions. The multiple hosts / virtual machines / containers used to run the code can be distributed in the same AZ or in different AZs, and each AZ includes one data center or multiple data centers with close geographical locations. Generally, a region can include multiple AZs.

[0249] Similarly, the multiple hosts / virtual machines / containers running the code can be distributed within the same VPC or across multiple VPCs. Typically, a VPC is located within a region. Cross-region communication between two VPCs within the same region, or between VPCs in different regions, requires a communication gateway within each VPC to interconnect the VPCs.

[0250] As an example of a hardware functional unit, a module can include at least one computing device, such as a server. Alternatively, the dialog backend system can be implemented using an ASIC or a PLD. The PLD can be implemented using a CPLD, FPGA, GAL, or any combination thereof.

[0251] The multiple computing devices included in the conversation backend system can be distributed in the same region or in different regions. They can also be distributed in the same AZ or in different AZs. Similarly, they can be distributed in the same VPC or across multiple VPCs. These multiple computing devices can be any combination of servers, ASICs, PLDs, CPLDs, FPGAs, GALs, and other computing devices.

[0252] The present application also provides a chip system, which includes a processor and a power supply circuit, the power supply circuit is used to power the processor, and the processor is used to perform the operation steps corresponding to the method provided in the present application. For the sake of brevity, it is not described here. The processor can be implemented by a GPU, or by a computing device such as a DPU, NPU, XPU, SoC, offload card, accelerator card, etc.

[0253] This application also provides a computing device 100. As shown in FIG8 , computing device 100 includes a bus 102, a processor 104, a memory 106, and a communication interface 108. Processor 104, memory 106, and communication interface 108 communicate with each other via bus 102. Computing device 100 may be a server or a terminal device. It should be understood that this application does not limit the number of processors and memories in computing device 100.

[0254] The bus 102 may be a Peripheral Component Interconnect Express (PCIe) bus or an Extended Industry Standard Architecture (EISA) bus, a unified bus (UBus or UB), a Compute Express Link (CXL), a Cache Coherent Interconnect for Accelerators (CCIX), or the like. A unified bus is also referred to as a Lingqu bus. Buses can be classified as address buses, data buses, control buses, and the like. For ease of illustration, FIG8 shows only one line, but this does not imply that there is only one bus or only one type of bus. The bus 104 may include a path for transmitting information between various components of the computing device 100 (e.g., the memory 106, the processor 104, and the communication interface 108). A unified bus may also be referred to as a Lingqu bus.

[0255] The processor 104 may include any one or more computing devices such as a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP) or a digital signal processor (DSP), an ASIC, an FPGA, a CPLD, an NPU, a SoC, an offload card, an accelerator card, etc.

[0256] The memory 106 may include volatile memory, such as random access memory (RAM). The processor 104 may also include non-volatile memory, such as read-only memory (ROM), flash memory, a hard disk drive (HDD), or a solid state drive (SSD). In addition, the memory 106 may also be implemented using storage class memory (SCM), phase change memory (PCM), or other types of storage media.

[0257] It is worth noting that the same type of storage medium can be configured in the same computing device to implement the function of memory 106, or two or more types of storage media can be configured to implement the function of memory 106. This application does not limit this.

[0258] The memory 106 stores executable program code, and the processor 104 executes the executable program code to respectively implement the functions of the various modules mentioned in Figure 7, thereby implementing the method provided by the present application. In other words, the memory 106 stores instructions for executing the method provided by the present application.

[0259] Alternatively, the memory 106 stores executable code, and the processor 104 executes the executable code to respectively implement the functions of the aforementioned input module, parsing module, dialogue management module, execution center, decoding module, or output module, thereby implementing the method provided by the present application. In other words, the memory 106 stores instructions for executing the method provided by the present application.

[0260] The communication interface 103 uses a transceiver module such as, but not limited to, a network interface card or a transceiver to implement communication between the computing device 100 and other devices or a communication network.

[0261] As a possible implementation, the computing device 100 may also include a chip system, which includes a processor and a power supply circuit, the power supply circuit is used to power the processor, and the processor is used to execute the operation steps corresponding to the method provided in this application. For the sake of brevity, it is not described here. Among them, the processor can be implemented by a GPU, or by a computing device or AI chip such as a DPU, NPU, XPU, SoC, offload card, accelerator card, etc.

[0262] As a possible implementation, the computing device 100 may include multiple types of processors 104, that is, the computing device 100 is a heterogeneous device. For example, the computing device 100 includes a CPU and a GPU, and the operating steps corresponding to the method provided in this application can be performed by at least one of the processors 104. For the sake of brevity, they are not further described here.

[0263] Embodiments of the present application also provide a computing device cluster. The computing device cluster includes at least one computing device. The computing device can be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device can also be a terminal device such as a desktop computer, a laptop computer, or a smartphone.

[0264] As shown in Figure 9, the computing device cluster includes at least one computing device 100. The memory 106 in one or more computing devices 100 in the computing device cluster may store the same instructions for executing the method provided in this application.

[0265] In some possible implementations, the memory 106 of one or more computing devices 100 in the computing device cluster may also store some instructions for executing the method provided in the present application. In other words, the combination of one or more computing devices 100 can jointly execute the instructions for executing the method provided in the present application.

[0266] It should be noted that the memory 106 in different computing devices 100 in the computing device cluster can store different instructions, each used to perform part of the functions of the joint testing apparatus. In other words, the instructions stored in the memory 106 in different computing devices 100 can implement the functions of one or more of the aforementioned input module, parsing module, dialogue management module, execution center, decoding module, or output module.

[0267] In some possible implementations, one or more computing devices in a computing device cluster may be connected via a network. The network may be a wide area network or a local area network, etc. FIG10 shows a possible implementation. As shown in FIG10 , two computing devices 100A and 100B are connected via a network. Specifically, the connection to the network is made through a communication interface in each computing device. In this type of possible implementation, the memory 106 in the computing device 100A stores instructions for executing the functions of an input module, a parsing module, a dialogue management module, an execution center, a decoding module, or an output module. At the same time, the memory 106 in the computing device 100B stores instructions for executing the functions of an input module, a parsing module, a dialogue management module, an execution center, a decoding module, or an output module.

[0268] It should be understood that the functions of the computing device 100A shown in FIG10 may also be completed by multiple computing devices 100. Similarly, the functions of the computing device 100B may also be completed by multiple computing devices 100.

[0269] The connection method between the computing device clusters shown in Figure 10 can be based on the consideration that the method provided in this application requires a large amount of computing power, load balancing or a large amount of data storage, etc., so it is considered to deploy different modules in different computing devices, such as handing over the functions implemented by the analysis module to the computing device 100A for execution, and handing over the functions implemented by the dialogue module to the computing device 100B for execution.

[0270] The present application also provides another computing device cluster. The connection relationship between the computing devices in this computing device cluster can be similar to the connection method of the computing device cluster described in Figures 9 and 10. However, the memory 106 of one or more computing devices 100 in this computing device cluster can store the same instructions for executing the method provided in this application.

[0271] In some possible implementations, the memory 106 of one or more computing devices 100 in the computing device cluster may also store some instructions for executing the method provided in the present application. In other words, the combination of one or more computing devices 100 can jointly execute the instructions for executing the method provided in the present application.

[0272] It should be noted that the memory 106 in different computing devices 100 in the computing device cluster can store different instructions for executing some of the functions of the dialogue backend system provided in this application. In other words, the instructions stored in the memory 106 in different computing devices 100 can implement the functions of one or more modules such as the input module, the parsing module, the dialogue management module, the execution center, the decoding module, or the output module.

[0273] The present application also provides a computer program product comprising instructions. The computer program product may be software or a program product comprising instructions that can be run on a computing device or stored in any available medium. When the computer program product is run on at least one computing device, the at least one computing device executes the method provided in the present application.

[0274] The present application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium that can be stored by a computing device or a data storage device such as a data center that contains one or more available media. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a magnetic tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state drive). The computer-readable storage medium includes instructions that instruct the computing device to execute the method provided in the present application.

[0275] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the protection scope of the technical solutions of the various embodiments of the present invention.

Claims

1. A conversation analysis method, characterized in that: include: Get the first input text; determining a plurality of keywords included in the first input text and whether the first input text corresponds to a first user intention; Determining at least one first interface corresponding to the first user intent based on a conditional knowledge graph, wherein the conditional knowledge graph includes information of multiple interfaces, and the multiple interfaces are interfaces of plug-ins for implementing at least one function; An output text is acquired according to the multiple keywords and the at least one first interface, where the output text is a reply to the first input text.

2. The method according to claim 1, characterized in that The information of each interface in the conditional knowledge graph includes multiple fields, each field forming a node in the conditional knowledge graph, and obtaining output text according to the multiple keywords and the at least one first interface includes: Verifying fields included in the at least one first interface according to the multiple keywords, and determining at least one second interface from the at least one first interface according to the verification result; The output text is obtained by calling a plug-in corresponding to the at least one second interface.

3. The method according to claim 1 or 2, characterized in that The multiple fields of each interface in the conditional knowledge graph include a function description field, and the function description field is used to describe the function implemented when each interface is called; The determining, based on the conditional knowledge graph, at least one first interface corresponding to the first user intention includes: The first user intention is matched with the function description field corresponding to each interface to determine the at least one first interface.

4. The method according to claim 3, characterized in that The information of each interface in the conditional knowledge graph includes an interface constraint, where the interface constraint is used to indicate the scope of functions supported by each interface; The matching the first user intention with the function description field corresponding to each interface to determine the at least one first interface includes: Matching the first user intention with a function description field corresponding to each interface to obtain at least one alternative interface; The at least one candidate interface is verified according to the interface constraint corresponding to each interface to obtain the at least one first interface.

5. The method according to any one of claims 2 to 4, characterized in that Verifying the fields included in the at least one first interface according to the multiple keywords, and determining at least one second interface from the at least one first interface according to the verification result, includes: Matching the multiple keywords with the fields of each first interface, filling the keywords into corresponding fields, and obtaining a filling result for each first interface; The filling result of each of the first interfaces is verified, and the at least one second interface is an interface that has passed the verification among the at least one first interface.

6. The method according to claim 5, characterized in that Filling the multiple keywords into the fields included in the at least one first interface to obtain a filling result for each first interface includes: Matching the multiple keywords with the fields of each first interface, and filling the keywords into corresponding fields; When multiple fields of each first interface are filled, output the filling result of each first interface; generating a follow-up text when the plurality of fields in each first interface include an unfilled field; Acquire a second input text corresponding to the question text; In a case where the second input text includes keywords corresponding to the unfilled fields, the unfilled fields are filled according to the keywords in the second input text, and the filling results of each first interface are output.

7. The method according to claim 6, characterized in that The method further comprises: If the second user intent corresponding to the second input text does not match the first user intent, the interface corresponding to the second user intent is re-determined.

8. The method according to claim 6 or 7, characterized in that The generating of the follow-up text includes: The large model is used to generate text corresponding to the unfilled field to obtain the follow-up text.

9. The method according to any one of claims 6 to 8, characterized in that The information of each interface further includes at least one constraint condition, and the verifying of the filling result of each first interface includes: Determining whether the filling result corresponding to each first interface meets at least one constraint condition corresponding to each first interface; If yes, it means that the filling result corresponding to the first interface passes the verification; If not, it means that the filling result corresponding to the first interface fails to pass the verification.

10. The method according to claim 9, characterized in that The constraint conditions include intra-field constraints and inter-field constraints. The intra-field constraints include conditions satisfied by the input parameters when calling each interface. The inter-field constraints include conditions satisfied between the input parameters when calling each interface.

11. The method according to any one of claims 1 to 10, characterized in that The obtaining of the first input text includes: Acquire user input data, where the type of the user input data includes text, image or voice; The text corresponding to the user input data is obtained according to the large model to obtain the first input text.

12. The method according to claim 11, characterized in that The method further comprises: The large model is used to generate output data corresponding to the output text, where the type of the output data is the same as the type of the user input data.

13. A dialogue background system, characterized in that: include: An input module, configured to obtain a first input document; a parsing module, configured to determine a plurality of keywords included in the first input text and whether the first input text corresponds to a first user intention; The parsing module is further configured to determine at least one first interface corresponding to the first user intent based on a conditional knowledge graph, wherein the conditional knowledge graph includes information of multiple interfaces, and the multiple interfaces are interfaces of a plug-in for implementing at least one function; The execution center is used to call the plug-in corresponding to the interface output by the analysis module to obtain the output result; A dialogue management module is used to obtain an output text according to the output result, where the output text is a reply to the first input text.

14. The dialogue background system according to claim 13, characterized in that: The parsing module is further configured to verify fields included in the at least one first interface according to the multiple keywords, and determine at least one second interface from the at least one first interface according to the verification result; The execution middle platform is specifically used to obtain the output result by calling the plug-in corresponding to the at least one second interface.

15. The dialogue background system according to claim 14, characterized in that: The multiple fields include a function description field, and the function description field is used to describe the function implemented when each interface is called; The parsing module is specifically used to match the first user intention with the function description field corresponding to each interface to determine the at least one first interface.

16. The dialogue background system according to claim 15, characterized in that: The information of each interface in the conditional knowledge graph includes an interface constraint, where the interface constraint is used to indicate the scope of functions supported by each interface; The parsing module is specifically used to: Matching the first user intention with a function description field corresponding to each interface to obtain at least one alternative interface; The at least one candidate interface is verified according to the interface constraint corresponding to each interface to obtain the at least one first interface.

17. The dialogue background system according to claims 14-16, characterized in that: The parsing module is specifically used to: Filling the multiple keywords into the fields included in the at least one first interface to obtain a filling result for each first interface; The filling result of each of the first interfaces is verified, and the at least one second interface is an interface that has passed the verification among the at least one first interface.

18. The dialogue background system according to claim 17, characterized in that: The parsing module is specifically used to: Matching the multiple keywords with the required fields of each first interface, and filling the keywords into the corresponding required fields; When multiple fields of each first interface are filled, output the filling result of each first interface; generating a follow-up text when the plurality of fields in each first interface include an unfilled field; Acquire a second input text corresponding to the question text; In a case where the second input text includes keywords corresponding to the unfilled fields, the unfilled fields are filled according to the keywords in the second input text, and the filling results of each first interface are output.

19. The dialogue background system according to claim 18, characterized in that: The parsing module is further used to: If the second user intent corresponding to the second input text does not match the first user intent, the interface corresponding to the second user intent is re-determined.

20. The dialogue background system according to claim 18 or 19, characterized in that: The dialogue management module is further used to generate text corresponding to the unfilled field using the large model to obtain the follow-up question text.

21. The dialogue background system according to any one of claims 18 to 20, characterized in that: The parsing module is specifically used to: Determining whether the filling result corresponding to each first interface meets at least one constraint condition corresponding to each first interface; If yes, it means that the filling result corresponding to the first interface passes the verification; If not, it means that the filling result corresponding to the first interface fails to pass the verification.

22. The dialogue background system according to claim 21, characterized in that: The constraints are divided into intra-field constraints and inter-field constraints. The intra-field constraints include the conditions satisfied by the input parameters when calling each interface, and the inter-field constraints include the conditions satisfied between the input parameters when calling each interface.

23. The dialogue background system according to any one of claims 13 to 22, characterized in that: The input module is specifically used for: Acquire user input data, where the type of the user input data includes text, image or voice; The text corresponding to the user input data is obtained according to the large model to obtain the first input text.

24. The dialogue background system according to claim 23, characterized in that: The dialogue background system also includes: An output module is used to generate output data corresponding to the output text using the large model, and the type of the output data is the same as the type of the user input data.

25. A computing device, characterized in that The computing device includes a processor and a memory; The processor is configured to execute instructions stored in the memory, so that the computing device performs the operating steps of the method according to any one of claims 1 to 12.

26. A computing device cluster, characterized in that: comprising at least one computing device, each computing device including a processor and a memory; The processor of the at least one computing device is configured to execute instructions stored in a memory of the at least one computing device, so that the computing device cluster performs the operating steps of the method according to any one of claims 1 to 12.

27. A computer program product comprising instructions, characterized in that When the instructions are executed by a computing device cluster, the computing device cluster is caused to perform the operation steps of the method according to any one of claims 1 to 12.

28. A computer-readable storage medium, characterized in that The method comprises computer program instructions. When the computer program instructions are executed by a computing device cluster, the computing device cluster performs the operation steps of the method according to any one of claims 1 to 12.

Images