Dialogue processing method and device, electronic equipment, storage medium and program product

Abstract

Embodiments of the present application provide a method and device for dialogue processing, electronic equipment, storage medium and program product. The method responds to obtaining to-be-processed dialogue information, determines at least one target intent from the to-be-processed dialogue information, and determines at least one target scene corresponding to the at least one target intent. In a preset execution component set, a target execution component subset corresponding to the at least one target scene is screened. The target execution component subset corresponding to the target scene can be flexibly determined, and then the target execution component in the target execution component subset can be called according to the calling rule of each target execution component to generate a solution to the to-be-processed dialogue information. The fixed execution component is avoided for all to-be-processed dialogues, which solves the problem of low processing flexibility and low dialogue processing efficiency to a certain extent.

Description

Technical Field

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

[0002] E-commerce platforms allow consumers to handle pre-sales and after-sales matters through online dialogue. To efficiently address consumer needs, intelligent dialogue service systems are typically set up to automatically generate corresponding solutions based on the consumer's intent.

[0003] In related technologies, intelligent dialogue service systems rely solely on pre-defined, fixed correspondences to determine specific solutions for specific intent scenarios. When new or additional intent scenarios arise, the lack of matching scenarios leads to solutions that result in low consumer satisfaction and a poor user experience. Summary of the Invention

[0004] To overcome the problems existing in related technologies, embodiments of this application provide a dialogue processing method, apparatus, electronic device, storage medium, and program product.

[0005] According to a first aspect of the embodiments of this application, a dialogue processing method is provided, the method comprising: In response to obtaining dialogue information to be processed, at least one target intent is determined from the dialogue information to be processed; Determine at least one target scenario corresponding to the at least one target intent; Filter the subset of target execution components that correspond to the at least one target scenario from the preset set of execution components; The target execution components in the subset of target execution components are invoked according to the invocation rules of each target execution component to generate a solution for the dialogue information to be processed.

[0006] According to a second aspect of the embodiments of this application, a dialogue processing apparatus is provided, the apparatus comprising: An intent determination module is used to determine at least one target intent from the pending dialogue information in response to obtaining pending dialogue information. The scenario determination module is used to determine at least one target scenario corresponding to the at least one target intent; The filtering module is used to filter a subset of target execution components that correspond to the at least one target scenario from a preset set of execution components; The generation module is used to call the target execution components in the subset of target execution components according to the calling rules of each target execution component, so as to generate a solution for the dialogue information to be processed.

[0007] According to a third aspect of the present application, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory, the computer program being executed by the processor to cause the electronic device to perform the method as described in the first aspect.

[0008] According to a fourth aspect of the embodiments of this application, a computer-readable storage medium is provided having a computer program stored thereon, the program being executed by a processor to implement the method as described in the first aspect.

[0009] According to a fifth aspect of the embodiments of this application, a computer program product is provided, including instructions that, when executed on a computer, cause the computer to perform the method as described in the first aspect.

[0010] The technical solutions provided in this application embodiment may include the following beneficial effects: The dialogue processing method in this embodiment, in response to obtaining dialogue information to be processed, determines at least one target intent from the dialogue information to be processed, and determines at least one target scenario corresponding to the at least one target intent; it filters a subset of target execution components corresponding to each of the at least one target scenario from a preset set of execution components. This allows for flexible determination of the subset of target execution components corresponding to the target scenario, and then calls the target execution components in the subset of target execution components according to the calling rules of each target execution component to generate a solution for the dialogue information to be processed. This avoids using fixed execution components for all dialogues to be processed, and to a certain extent solves the problems of low processing flexibility and low dialogue processing efficiency.

[0011] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0012] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly described below. It should be understood that those skilled in the art can obtain other drawings based on these drawings without any creative effort.

[0013] Figure 1 This is a schematic diagram of a scenario corresponding to the dialogue processing method provided in the embodiments of this application; Figure 2 A schematic diagram of the server in the scenario corresponding to the dialogue processing method provided in the embodiments of this application. Figure 3 An exemplary flowchart corresponding to the dialogue processing method provided in the embodiments of this application; Figure 4An exemplary schematic diagram of the dialogue processing apparatus provided in the embodiments of this application; Figure 5 An exemplary schematic diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0014] The technical solutions of the embodiments of this application will now be described with reference to the accompanying drawings.

[0015] The terminology used in the following embodiments of this application is for the purpose of describing particular embodiments and is not intended to limit the technical solutions of this application. As used in the specification and appended claims of this application, the singular expressions “a,” “an,” “the,” “the,” and “this” are intended to include the plural expressions as well, unless the context clearly indicates otherwise.

[0016] It should also be understood that although the terms "first," "second," etc., may be used in the following embodiments to describe a certain type of object, the objects should not be limited to these terms. These terms are used to distinguish the specific implementation objects of that type of object.

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

[0018] The technical scenarios of the embodiments of this application are described below.

[0019] E-commerce platforms allow consumers to handle pre-sales and after-sales matters through online dialogue. To efficiently address consumer needs, intelligent dialogue service systems are typically set up to automatically generate corresponding solutions based on consumer intent. However, in related technologies, intelligent dialogue service systems usually rely on preset, fixed correspondences; that is, they determine the specific solution based on known intent scenarios through rule matching or simple classification models. This fixed model is efficient in handling common, standardized problems, but it lacks flexibility and results in a poor user experience when dealing with dynamically changing needs scenarios.

[0020] Furthermore, the limitations of intelligent dialogue systems have increased the pressure on human customer service intervention, leading to reduced response efficiency and increased operating costs. Because intelligent dialogue systems have failed to effectively filter and resolve some new issues, a large number of inquiries still need to be transferred to human agents, resulting in longer waiting times for consumers and further degrading the user experience.

[0021] In summary, traditional intelligent dialogue service systems based on fixed presets are gradually showing their inadequacy in dealing with increasingly complex and ever-changing e-commerce consumer demands. To improve consumer satisfaction and user experience, it is necessary to introduce more flexible and scalable intent recognition and solution generation mechanisms, such as combining technologies like continuous learning, scenario generalization, and contextual understanding, so that the system can dynamically adapt to new demand scenarios and thus provide more accurate and personalized service support.

[0022] In view of this, embodiments of this application propose a dialogue processing method that can be applied to a dialogue processing system. For example... Figure 1 The image shows a dialogue processing system that implements a dialogue processing method. For example... Figure 1 As shown, the dialogue processing system includes a client 101 and a server 102, which are connected via a network. The client 101 can be hardware, such as a mobile phone, personal computer, tablet computer, wearable device, or other electronic device, or it can be an application (APP) or software module deployed on an electronic device. The client 101 serves as an online service portal for users. Users can log in to this portal via electronic devices or applications and send questions to the server 102 through it. The server 102 can be an application, service, instance, software module, virtual machine, container, or cloud server, or a hardware device or chip with data processing capabilities. After receiving the question, the server 102 processes it to generate a corresponding response.

[0023] In some embodiments, such as Figure 2 As shown, server 102 may include an upstream dependent application layer, an execution layer, and a downstream dependent engine layer. The application layer and the execution layer, as well as the execution layer and the engine layer, can interact with each other through an application programming interface (API).

[0024] The application layer is configured as the interaction medium between the dialogue platform and the user. The application layer can run on a terminal device. For example, a dialogue interaction client and a dialogue quality inspection client can be deployed in the application layer. The dialogue interaction client can receive dialogue information input by the user in the form of a dialog box on the user interface (UI). The dialogue quality inspection client is used to process the dialogue in the dialogue interaction client to trigger dialogues within the client. In some embodiments, the dialogue interaction client can be used to display the conversation between users and consumers. In some embodiments, the dialogue quality inspection client is used to acquire the dialogue records of each user and consumer in the dialogue interaction client in real time and determine whether a dialogue processing method needs to be triggered to generate a corresponding solution based on the real-time dialogue records.

[0025] The execution layer is configured as the coordination, processing, and decision-making layer of the dialogue interaction platform. This layer can host dialogue processing agents, which handle dialogues between consumers and merchants that cannot be negotiated. The dialogue processing agents process the dialogues according to dialogue processing methods, generating relevant solutions. These solutions can be corresponding operation execution information, enabling users or consumers to implement the solutions based on the operation guidance information.

[0026] The execution layer can maintain the calling interfaces, calling strategies, component determination methods, solution determination methods, and solution knowledge bases for relevant execution components during the dialogue processing method execution process. Execution components can be components corresponding to various stages such as "order filtering," "dialogue understanding," and "scene routing," with each stage encapsulated as one or more execution components. The calling interface of the execution component defines the interaction protocol between components, such as the input / output data format, enabling the execution layer to call each execution component in a unified and pluggable manner. The calling strategy guides the execution layer on how to call execution components in specific scenarios. The strategy determines whether the execution order is sequential, parallel, or conditional. For example, order filtering is executed first, followed by dialogue understanding based on the result; or dialogue understanding is performed first, followed by order filtering. It also handles the scheduling of calls to execution components with dependencies, such as when one component needs to wait for the output of another component before running. The component determination method is used to decide at runtime "which execution components to call" and "with what parameters to configure the call," typically based on the identified target scenario, selecting a subset of target execution components from a pre-defined set of execution components. The solution knowledge base is used to store, manage, and retrieve solutions corresponding to historical scenarios.

[0027] The downstream engine layer is a capability center providing basic, general-purpose computing power and data services. It may also include model engines, algorithm capabilities, and data storage. The model engine encapsulates and deploys various machine learning models, such as a natural language understanding engine: including intent recognition models, entity extraction models, sentiment analysis models, and text classification models. The execution layer calls this engine when performing intent recognition and trigger condition judgment. The large language model service engine provides inference APIs for large language models. The execution layer calls this engine to generate a subset of the target execution components when invoking the execution component matching model. The retrieval engine is used to retrieve historical scenes with similarity to the target scene from the historical scene library.

[0028] It should be understood that the above description of the functional layers of the dialogue information processing system is merely illustrative and does not constitute a limitation on the functional layers of the dialogue information processing system in the embodiments of this application. In actual implementation scenarios, the dialogue information processing system may include more or fewer functional layers, and each layer may contain more or fewer functional modules. The embodiments of this application do not limit this.

[0029] It should be understood that Figure 1 and Figure 2 The illustrated application scenario diagram is merely a schematic representation of the dialogue processing system involved in the embodiments of this application and does not constitute a limitation on the technical solutions of the embodiments of this application.

[0030] In the above operating environment, the embodiments of this application provide as follows: Figure 3 The dialogue processing method shown is applied to, for example, dialogue processing methods. Figure 1 or Figure 2 The corresponding server is 102. The dialogue processing method includes the following steps: In step S301, in response to obtaining the dialogue information to be processed, at least one target intent is determined from the dialogue information to be processed.

[0031] For example, the dialogue information to be processed can be one or more pieces of text information input by a user (such as a consumer) through a dialogue interface. This information is raw input data that needs to be understood and processed. The target intent refers to the specific purpose, task, or demand that the user hopes to achieve in the dialogue, identified through semantic analysis of the dialogue information to be processed. This transforms the user's vague natural language expression into a structured task label that the computer can understand and process. For example, in an e-commerce after-sales scenario, the target intent may include "apply for a refund only", "request an exchange", "file a complaint", "check logistics status", "inquire about product functions", etc.

[0032] An intent rule base can be pre-built, storing keywords, phrases, or sentence templates corresponding to the target meaning. When determining the target intent, the dialogue to be processed is matched against this intent rule base. If the dialogue information contains key elements that highly overlap with a certain intent rule, then that intent is determined to be the target intent. Alternatively, a machine learning classification model can be used to extract textual features from the dialogue information to be processed, outputting the probability of each preset intent category, and identifying one or more categories with the highest probability as the target intent. Furthermore, the contextual understanding and instruction-following capabilities of a large language model can be utilized. By constructing specific prompts, the dialogue information is submitted to the large language model, which is then instructed to analyze the text and output structured intent judgment results. This approach does not require dedicated model training for each intent, exhibiting strong zero-shot or few-shot learning capabilities, enabling a more refined understanding of the user's implied meaning and true needs, and providing flexibility for handling complex scenarios. In addition, its intent labeling system can be dynamically adjusted and expanded.

[0033] Those skilled in the art will understand that the methods for determining the target's intent are not limited to those described above. Depending on the actual task requirements, data scale, and technical infrastructure, other natural language understanding technologies or a combination of the above methods may be employed, and this embodiment does not limit this approach.

[0034] In step S302, at least one target scene corresponding to at least one target intent is determined.

[0035] For example, a target scenario refers to a standardized task situation or framework predefined in some fields to handle a class of user demands with similar processing flows, rules, and resource requirements. A "scenario" is associated with a set of processing logic (such as the components invoked, the execution strategy, and the set of available solutions). For example, in the e-commerce after-sales field, a target scenario could be "product quality problem - refund only scenario", "logistics problem - goods not received scenario", "service dispute - merchant insult complaint scenario", etc.

[0036] A large language model can identify at least one task-related entity and problem within a target intent. For example, the target scenario corresponding to "insufficient standby time for product XX" is "inconsistent product description information"; the target scenario corresponding to "loose charging head" is "product has quality issues". Typically, one target intent corresponds to one target scenario. In some embodiments, multiple target scenarios may be simultaneously identified, or multiple target intents may correspond to one target scenario, thus enabling dynamic adjustment of the target scenario based on actual circumstances to a certain extent.

[0037] In step S303, a subset of target execution components corresponding to at least one target scenario is selected from the preset execution component set.

[0038] For example, a preset set of execution components containing various functional modules can be pre-configured. Once at least one target scenario is determined, one or more functional modules suitable for handling that scenario are selected from this preset set to form a subset of target execution components, based on the requirements of each target scenario. By maintaining the preset set of execution components and filtering them according to the characteristics of the target scenario, the ability to dynamically select and configure dynamic processing for different scenarios is achieved.

[0039] A directed acyclic graph (DAG) is constructed to represent the data dependencies between execution components in the pre-defined execution component set. Each target scenario corresponds to a processing objective (e.g., "generate after-sales solution") and initial input data. The filtering process is transformed into a search or matching problem in the graph. For example, finding an optimal path from the input data node to the processing objective node, where the sequence of nodes along the path represents the subset of target execution components. Alternatively, scenario features can be matched with pre-defined process templates, and the most suitable template can be selected.

[0040] In step S304, the target execution components in the target execution component subset are called according to the calling rules of each target execution component to generate a solution for the dialogue information to be processed.

[0041] For example, invocation rules refer to predefined specifications or strategies that manage how "target execution components" are scheduled and executed. These rules not only include simple execution order but may also cover more complex control logic, such as data dependencies between components (which component's output is another component's input), execution modes (serial, parallel, or conditional branching), exception handling strategies (how to handle when a component fails), timeout controls, and resource constraints. A solution refers to the structured result generated after invoking and processing a subset of target execution components, used to directly or indirectly respond to the user's requests in the "pending dialogue information." In after-sales scenarios, a solution can be a specific operational suggestion (e.g., "A refund is agreed upon, amount XXX yuan"), an operational instruction to be executed (e.g., "Create a return logistics order"), or a response to be given to the user (e.g., "Priority processing has been applied for for you; a specialist is expected to reply within 2 hours").

[0042] The invocation rules explicitly define a linear execution order list. For example, each target execution component is invoked sequentially according to the list order. After the previous component finishes execution and outputs its result, its result is passed as input (or partial input) to the next component in the list, until all components have been invoked. The output of the last component is then processed and used as the solution.

[0043] In some embodiments, the invocation rules can be set as a directed acyclic graph (DAG), where nodes represent target execution components and directed edges represent data dependencies between components. The workflow engine parses this DAG and schedules components according to their dependencies. Components without dependencies can execute in parallel to improve efficiency; a component is only scheduled for execution after all its preceding dependent components have executed successfully. The workflow engine is responsible for data transfer, state management, and fault handling.

[0044] As can be seen, by adopting the embodiments of this application, in response to obtaining the dialogue information to be processed, at least one target intent is determined from the dialogue information to be processed, and at least one target scenario corresponding to the at least one target intent is determined; a subset of target execution components corresponding to the at least one target scenario is filtered from a preset set of execution components. This allows for flexible determination of the subset of target execution components corresponding to the target scenario, and then the target execution components in the subset of target execution components can be called according to the calling rules of each target execution component to generate a solution for the dialogue information to be processed. This avoids the use of fixed execution components for all dialogues to be processed, and to a certain extent solves the problems of low processing flexibility and low dialogue processing efficiency.

[0045] In some embodiments, determining the target execution component subset in step S303 above can also be achieved by: determining scene features based on at least one target scene; obtaining execution components that match the scene features from a preset set of execution components; if at least one execution component that matches the scene features is obtained from the preset set of execution components, then at least one execution component is determined as the target execution component subset; if no execution component that matches the scene features is obtained from the preset set of execution components, then the execution component matching model is invoked to match the corresponding target execution component subset in the preset set of execution components.

[0046] For example, in this embodiment, both static and dynamic matching methods are provided to filter the subset of target execution components. First, scene features describing the scene are extracted from the determined target scene. Then, from the pre-configured mapping relationship, it is searched for directly related execution components based on the scene features. If matching components are found, these components are determined as the subset of target execution components. If no matching components are found through the preset static mapping, the execution component matching model is invoked to search for and determine the subset of target execution components suitable for processing the scene from the preset execution component set. This embodiment, by extracting scene features and adopting a two-stage decision-making mechanism of "preset rule matching first, model intelligent matching as a backup," improves the component filtering capability for handling unknown or novel scenes to a certain extent while ensuring processing efficiency and predictability.

[0047] For the matching process of obtaining at least one execution component that matches the scene features from the preset execution component set, matching can be performed through a "scene feature-execution component" mapping table. After obtaining the scene features, the scene features are used as keys to query the "scene feature-execution component" mapping table. If a record is found, one or more execution components associated with the record are determined as the "target execution component subset".

[0048] Regarding the matching process of the execution component matching model, the model receives scene features as input, performs inference calculations, and outputs a list of components suitable for handling the scene. This model can be trained based on historical successful component call logs, learning the complex relationship between scene features and component effects; or it can be a large language model that matches the execution process and results of each execution component with scene features.

[0049] Regarding the method for determining scene features, in some embodiments, metadata can be extracted from the target scene based on the predefined metadata description corresponding to each target scene, and this metadata can be used as scene features. In some embodiments, scene features can also be determined in the following ways: determining dispute type features and claim features based on at least one target intent; determining scene features based on dispute type features, claim features, and order information corresponding to the dialogue information to be processed.

[0050] For example, dispute type features refer to the characteristics that categorize user-raised questions based on their task nature. They describe the type of problem that has occurred. For instance, in the e-commerce after-sales field, dispute type features could include disputes over product quality, logistics fulfillment, service attitude, discrepancies between description and actual product, price, and intellectual property rights. The focus is on the nature of the problem rather than the specific solution. Request features refer to the characteristics that describe the user's expected solution or outcome in both form and content. They describe what the user wants. For example, request features could include the form of the request (e.g., request for a refund, request for an exchange, request for compensation, request for an apology, request for an explanation) and specific parameters of the request (e.g., a full refund, an exchange for the same model but a different color, compensation in the form of a coupon). Order information refers to the structured data contained in the transaction order associated with the currently pending dialogue information. This may include, but is not limited to, order status (e.g., shipped, received, transaction successful), product category and attributes (e.g., fresh food, large appliances, virtual goods), order amount, merchant information, logistics information, payment information, order creation time, etc. Order information provides the specific background and constraints of the problem.

[0051] By parsing the dispute type and the demand from the target intent and integrating them with order information, the original user demand is deeply and structurally decomposed. Combined with the specific task context, this generates multi-dimensional and information-rich scene description features necessary to depict the current situation.

[0052] By invoking a corresponding large model, user request features, dispute type features, and order information can be transformed into numerical vectors through different encoders, and then feature fusion can be performed to obtain the corresponding scenario features. Those skilled in the art will understand that the system division of dispute types and request features, the fields selected in the order information, and the specific representation of the final scenario features (whether it is a discrete tag set, feature string, or numerical vector) can all be flexibly designed and defined based on knowledge of the specific task domain. A weighting mechanism can also be introduced during the fusion process to adjust the degree of emphasis on features from different sources. This embodiment does not limit this.

[0053] In some embodiments, when determining the target execution component subset, if no execution component matching the scene features is obtained from the preset execution component set, the historical scene with the highest similarity to the target scene can be determined from the historical scene library for any target scene; and at least one execution component corresponding to the historical scene can be used as the target execution component subset.

[0054] For example, a historical scenario library refers to a structured database or knowledge base where each record represents a previously processed task scenario case. Each record contains at least two core pieces of information: first, a description of the historical scenario's characteristics (possibly similar to the definition of "scenario features," including values ​​for dimensions such as dispute type, demands, and order information); and second, a list of "execution components" that were actually invoked and verified as valid during the processing of that historical scenario, along with their possible related information (such as execution order and parameters).

[0055] In the implementation process, each historical scene in both the target scene and the historical scene library is transformed into a feature vector in the same dimensional space through feature engineering. Then, a distance metric (such as cosine similarity or Euclidean distance) is used to calculate the distance (or similarity score) between the target scene vector and each historical scene vector. Finally, the historical scene with the smallest distance (or the highest similarity score) to the target scene is selected as the result. Alternatively, a learning ranking model or a deep matching model can be used, taking the pairwise feature representations of the target scene and historical scenes as input and directly outputting a matching score. Candidate scenes in the historical scene library are scored, and the historical scene with the highest score is selected. This can be trained using positive feedback data from the past, such as "Scene A eventually adopted a component from Scene B and succeeded."

[0056] It should be noted that the historical scenario library can be compiled based on empirical values. It can be determined that the solutions stored in the historical scenario library are common, high-frequency, and relatively typical solutions for negotiation scenarios. Therefore, if the target scenario extracted from the dialogue information to be processed is a relatively typical scenario, then historical scenarios with high similarity to the scenario features can be obtained from the historical scenario library. If the scenario features of the dialogue information to be processed involve entirely new scenarios (e.g., cross-border logistics), multiple conflicting rules (e.g., multiple complex rules such as "price protection," "quotation service," and "membership benefits"), or are vaguely described (e.g., the dialogue information is "I am not satisfied"), then it may exceed the coverage of typical scenarios. In this case, the historical scenario library cannot obtain historical scenarios corresponding to the scenario features, and it is necessary to further determine the subset of target execution components based on the executable results.

[0057] By retrieving similar scenarios from a historical scenario database and reusing the operations of successfully executed components from these scenarios, a case-based reasoning-based component selection strategy is implemented. This approach bypasses the steps of explicit rule configuration or model training for each new scenario, instead leveraging historical successes to solve new problems.

[0058] In some embodiments, matching a corresponding subset of target execution components in a preset set of execution components can determine at least one executable result corresponding to any target scenario for any target scenario, so as to obtain a set of executable results corresponding to at least one target scenario; identifying at least one target executable result that satisfies at least one target scenario from the set of executable results; and taking the target execution component corresponding to at least one target executable result as a subset of target execution components.

[0059] For example, in this embodiment, the process of determining the target execution component subset is result-oriented, involving reverse matching within a preset execution component set. First, for each target scenario requiring processing, all theoretically possible, structured processing results are enumerated, forming an executable result set. Next, from this result set, the target executable results that best meet the specific needs of the current target scenario are identified. Finally, the specific functional modules responsible for implementing or outputting these "target executable results" are determined as the final subset of target execution components to be invoked.

[0060] For example, in an after-sales scenario, the possible outcomes could be: generating an instruction to "agree to a full refund", generating a negotiation script to "suggest exchanging the product and compensate for shipping costs of 20 yuan", calling the logistics interface to create a return order, or marking the user's request as "requiring urgent human intervention".

[0061] During implementation, a mapping table of "scene type - list of executable results" is maintained in advance. For the input target scene, the mapping table is queried according to its scene type (or characteristics) to directly obtain all possible executable results associated with it, forming an executable result set. Set enablement conditions or filters for each result in the executable result set. These conditions are matched against details of the current target scenario (such as order amount, product status, user history, and merchant policies). Only results where all conditions are met are identified as "target executable results." For example, a "refund only" result might be filtered by conditions such as "product category is not virtual" and "order status is received." A ranking or scoring model can also be used to score all results in the executable result set. Scoring is based on factors such as the semantic relevance of the result to the scenario, historical adoption rate, expected user satisfaction, and execution cost. One or more results with the highest scores are identified as target executable results.

[0062] After determining the target executable result, the target execution component corresponding to the target executable result is taken as a subset of the target execution components.

[0063] The two approaches described above—determining the target execution component subset through a historical scenario library and determining it through executable results—can complement each other and be used in combination. For example, if the target scenario is determined to be routine or frequently occurring based on scenario characteristics, the first approach—determining the target execution component subset based on a historical scenario library—can be prioritized. This allows for the efficient reuse of at least one execution component corresponding to a historical scenario in the library, thereby improving the reliability of the solution to some extent. When the historical scenarios determined using the first approach have low similarity or fail to match, the second approach—determining the target execution component subset based on executable results—can be used for more flexible combination of execution components.

[0064] Those skilled in the art will understand that the granularity of the executable result definition, the strategy for generating the executable result set, the judgment logic for satisfying conditions, and the mapping relationship between the result and the target execution component can all be flexibly adjusted according to specific circumstances. For example, a complex result may correspond to a small workflow composed of multiple components. This embodiment does not limit this.

[0065] After determining the subset of target execution components, the target execution components in the subset of target execution components are called according to the calling rules of each target execution component. This includes: if the calling rule is parallel calling, then each target execution component is called in parallel to generate a solution; if the calling rule includes serial calling, then each target execution component is called sequentially according to the calling rules of each execution component in the serial calling to generate a solution.

[0066] For example, the process of invoking target execution components to generate a solution involves two core execution modes: serial or parallel, depending on different invocation rules. When the invocation rule is specified as "parallel invocation," each component in the subset of target execution components is started and run simultaneously. These components execute independently, and their intermediate results are collected, summarized, or merged to ultimately form a unified solution. When the invocation rule is specified as "serial invocation," each target execution component is invoked sequentially according to a predefined order. The next component only begins execution after the previous component has finished executing and passed its output to the next component. Through this relay-style processing, the output of the last component after execution, or the result of processing all intermediate results, serves as the final solution.

[0067] By determining the type of invocation rule and executing parallel or serial scheduling operations accordingly, fine-grained control over the component execution flow is achieved. This design enables the system to flexibly adopt the most efficient or reliable task orchestration method based on the dependencies between components and the task processing logic.

[0068] In implementation, for parallel calls, independent execution threads or processes can be allocated to each target execution component that needs to be executed in parallel. These threads / processes are started and run simultaneously. A master thread is responsible for waiting for all parallel tasks to complete and collecting the results from other threads. This fully utilizes multi-core computing resources, and when the execution component itself is computationally intensive or involves input / output waiting, it can significantly reduce the "clock time" from the start of the call to the collection of all results, which has a significant effect on reducing overall system latency and improving throughput.

[0069] For serial calls, each component is called synchronously in the order they occur. The output of the previous component is passed as the input parameter for the next component. The entire process is completed within a linear and predictable control flow.

[0070] In the implementation process, if the calling rules in some embodiments include both serial and parallel calls, the corresponding serial target execution component is called according to the calling rules of each execution component in the serial call; and the corresponding parallel target execution component is called according to the calling results of each serial target execution component to obtain the solution.

[0071] For example, when both serial and parallel calls are included, the calling rules are no longer limited to "serial" or "parallel." Specifically, the target execution components that need to be called serially are first identified, and these components are called sequentially, strictly following the serial calling rules. After all the serial components have completed their execution, the results produced by the serial execution components are used as input or trigger conditions to call another set of target execution components in parallel. Finally, the outputs of these parallel execution components are collected and processed to generate the final solution. This is a two-stage combined execution model of "serial first, then parallel."

[0072] During the invocation process, there is no need to wait for all serial execution components to complete before invoking the parallel execution component. The execution result can be passed to the corresponding waiting execution component after the component awaiting the result has finished executing, allowing the corresponding waiting execution component to execute. For example, if the target execution component subset includes multi-level serial-parallel relationships, when the output of a certain serial component is the sole or primary input to a specific downstream parallel component, the corresponding parallel execution component can be triggered immediately upon generation of that result, without waiting for other serial components, further reducing overall latency.

[0073] Those skilled in the art will understand that "serial first, then parallel" is merely a common form of hybrid mode. Depending on task requirements, there may also be "parallel first, then serial," or more complex nested structures. The number of components within the serial stage, the number of components within the parallel stage, and the data mapping and transformation logic between the two stages can all be flexibly designed according to the specific task scenario. Components in the parallel stage can share all the results of the serial stage, or they can each subscribe to the partial results they need. This embodiment does not limit this.

[0074] In some embodiments, if multiple solutions are generated, the method further includes: determining a preset number of solutions as target solutions based on the popularity values ​​corresponding to the multiple solutions.

[0075] For example, the popularity score can be obtained based on the success rate of solution negotiations. Each popularity score represents the frequency with which the corresponding solution is adopted; the higher the popularity score, the higher the success rate of the solution being accepted by both consumers and merchants. In this way, identifying the solution corresponding to the highest popularity score as the target negotiation solution helps to improve the success rate of negotiations, thereby improving the user experience for both consumers and merchants.

[0076] Popularity scores can be determined in the following ways. One method is to record each adopted solution and the characteristics of the scenario it belongs to. When calculating the popularity score of a newly generated solution, the system retrieves historical scenarios similar to that solution from the historical database and counts the number of times the solution (or highly similar solutions) was ultimately adopted by users or customer service in history. The number of adoptions (or the normalized adoption rate) serves as its popularity score. This method allows the popularity score to directly reflect the "practical effectiveness" and "popular choice" of the solution, possessing high objectivity and persuasiveness. It enables recommended solutions to more closely align with real user preferences and is an experience-based, data-driven optimization strategy.

[0077] Another approach is to calculate the popularity score by weighting multiple metrics. For example, it can comprehensively consider historical adoption rates, solution implementation costs, estimated resolution time, user historical preferences, and the method of solution determination, assigning weights to each metric and calculating a weighted total score as the final popularity score. This approach balances multiple factors, enabling a more comprehensive and refined evaluation. It allows for meeting user needs while also considering other objectives such as platform operational efficiency and cost control, leading to more optimal, holistic decisions.

[0078] If the target intent is determined solely based on the dialogue information to be processed, it may be inaccurate or unable to extract the relevant intent. To improve the accuracy of the target intent, at least one target intent can be determined in the following ways: determine the order information contained in the dialogue information to be processed; read the historical dialogue information related to the order information, which refers to the dialogue information before the dialogue information to be processed; if the order information triggers the solution generation condition, then call the intent recognition model to determine at least one target intent based on the historical dialogue information.

[0079] For example, the specific transaction order involved can be parsed or associated from the pending dialogue information to obtain the detailed information of that order. Next, using the order information as an index, all past communication records related to the same order before the current pending dialogue information was generated are searched and retrieved from the storage system; these past records are collectively referred to as historical dialogue information. Then, it is determined whether the obtained "order information" meets the preset conditions for initiating the automatic solution generation process. If these "solution generation conditions" are met, the subsequent intelligent processing flow will be initiated.

[0080] Historical dialogue information can be dialogue information within the same order over a preset time period, or dialogue information from a preset number of dialogue rounds. By limiting time and dialogue rounds, the accuracy of target intent is improved while reducing the consumption of computing resources, thereby improving the efficiency and accuracy of determining target intent to a certain extent.

[0081] The conditions for generating a solution include at least one of the following: the merchant has no solution, the merchant's response times out, or the consumer disagrees with the solution offered by the merchant. By limiting the judgment to three specific dimensions—"the merchant has no solution," "the merchant's response times out," and "the consumer disagrees with the merchant's solution"—the scenarios in which proactive intervention to provide a solution is determined in the "merchant-consumer" negotiation context are clarified. For example, a series of merchant response templates or keywords representing each generation condition can be predefined, such as "cannot be processed," "cannot be resolved," or "sorry, there's nothing I can do." When the merchant's latest response matches these templates, it is determined that "the merchant has no solution." An intent or solution recognition model can also be invoked to analyze the merchant's response. If the model's output is a negative category such as "no clear solution" or "passing the buck," or if no structured solution entity (such as refund, exchange, or compensation amount) can be extracted from the response, then it is determined that the solution generation condition is met.

[0082] In the automated process of intervening in merchant-consumer disputes, intervening too early may disrupt normal negotiations between the two parties; intervening too late may lead to escalation of the problem and a deterioration of the experience. By setting solution generation conditions, the system can identify key moments when "merchant-consumer negotiations have reached a stalemate or failed, requiring the intervention of the platform's intelligent agent," thereby ensuring that automated intervention is reasonable, necessary, and timely.

[0083] The above implementation steps can also be implemented through software modules to achieve the corresponding functions. Corresponding to the above dialogue processing method, the embodiments of this application can also provide a dialogue processing device.

[0084] like Figure 4 As shown, a dialogue processing apparatus is provided for use with a target device. The apparatus may include: an intent determination module 41, a scene determination module 42, a filtering module 43, and a generation module 44.

[0085] For example: the intent determination module 41 is used to determine at least one target intent from the dialogue information to be processed in response to obtaining the dialogue information to be processed; Scene determination module 42 is used to determine at least one target scene corresponding to the at least one target intent; The filtering module 43 is used to filter a subset of target execution components that correspond to the at least one target scenario from a preset set of execution components; The generation module 44 is used to call the target execution components in the subset of target execution components according to the calling rules of each target execution component, so as to generate a solution for the dialogue information to be processed.

[0086] In some optional embodiments, the filtering module is further configured to: determine scene features based on the at least one target scene; Obtain execution components that match the scene features from the preset set of execution components; If at least one execution component matching the scene features is obtained from the preset execution component set, then the at least one execution component is determined as a subset of the target execution components; If no execution component matching the scene features is obtained from the preset execution component set, the execution component matching model is invoked to match the corresponding target execution component subset in the preset execution component set.

[0087] In some optional embodiments, the filtering module is further configured to: determine dispute type characteristics and claim characteristics based on the at least one target intent; The scenario features are determined based on the dispute type features, the claim features, and the order information corresponding to the pending dialogue information.

[0088] In some optional embodiments, the filtering module is further configured to: for any target scene, determine the historical scene with the highest similarity to the target scene from the historical scene library; At least one execution component corresponding to the historical scenario is taken as a subset of the target execution components.

[0089] In some optional embodiments, the filtering module is further configured to: for any target scenario, determine at least one executable result corresponding to the target scenario, so as to obtain a set of executable results corresponding to the at least one target scenario; Identify at least one target executable result that satisfies the at least one target scenario from the set of executable results; The target execution component corresponding to the at least one target executable result is taken as the target execution component subset.

[0090] In some optional embodiments, the generation module is further configured to: if the invocation rule is a parallel invocation, invoke each target execution component in parallel to generate the solution; If the invocation rules include serial invocation, then each target execution component is invoked sequentially according to the invocation rules of each execution component in the serial invocation to generate the solution.

[0091] In some optional embodiments, if the calling rules are serial calling and parallel calling, the generation module is further configured to: call the corresponding serial target execution component according to the calling rules of each execution component in the serial calling; Based on the invocation results of each serial target execution component, the corresponding parallel target execution components are invoked in parallel to obtain the solution.

[0092] In some optional embodiments, if multiple solutions are generated, the generation module is further configured to: Based on the popularity values ​​corresponding to the multiple solutions, a preset number of solutions are determined as target solutions.

[0093] In some optional embodiments, the intent determination module is further configured to: determine order information contained in the dialogue information to be processed; Read historical dialogue information related to the order information, where the historical dialogue information refers to the dialogue information preceding the dialogue information to be processed. If the order information triggers the solution generation condition, the intent recognition model is invoked to determine the at least one target intent based on the historical dialogue information.

[0094] In some optional embodiments, the solution generation conditions include at least one of the following: the merchant has no solution, the merchant's response times out, or the consumer disagrees with the solution provided by the merchant.

[0095] As can be seen, by adopting the embodiments of this application, in response to obtaining the dialogue information to be processed, at least one target intent is determined from the dialogue information to be processed, and at least one target scenario corresponding to the at least one target intent is determined; a subset of target execution components corresponding to the at least one target scenario is filtered from a preset set of execution components. This allows for flexible determination of the subset of target execution components corresponding to the target scenario, and then the target execution components in the subset of target execution components can be called according to the calling rules of each target execution component to generate a solution for the dialogue information to be processed. This avoids the use of fixed execution components for all dialogues to be processed, and to a certain extent solves the problems of low processing flexibility and low dialogue processing efficiency.

[0096] Understandable Figure 4 The division of the various modules is merely a logical functional division. In actual implementation, the functions of these modules can be integrated into the hardware entity of the electronic device.

[0097] Please refer to Figure 5 , Figure 5 An electronic device is provided, and this disclosure also provides an electronic device for performing some or all of the steps of the above-described dialogue processing method. Please refer to... Figure 5 The electronic device includes a processor 500, a memory 501, a bus 502, and a communication interface 503, wherein the processor 500, the communication interface 503, and the memory 501 are connected via the bus 502; the memory 501 stores a computer program that can run on the processor 500, and the processor 500 can be equivalent to a CPU, executing the aforementioned provisions of this disclosure when running the computer program. Figure 3The dialogue processing method provided in any of the embodiments, during the execution of the aforementioned method, interacts with the corresponding client through the communication interface 503 to exchange data and instructions.

[0098] The memory 501 may include high-speed random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device. Communication between this system network element and at least one other network element is achieved through at least one communication interface 503 (which can be wired or wireless), such as the Internet, wide area network, local area network, metropolitan area network, etc.

[0099] Bus 502 can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. Memory 501 is used to store programs, and the processor 500 executes the programs after receiving execution instructions. Figure 2 The illustrated embodiments reveal that the dialogue processing method can be applied to, or implemented by, the processor 500.

[0100] The processor 500 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of the processor 500 or by instructions in software form. The processor 500 may be a general-purpose processor, including a CPU, a network processor (NP), etc.; it may also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this disclosure. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this disclosure can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules may reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory 501. The processor 500 reads the information in memory 501 and, in conjunction with its hardware, completes the steps of the above method.

[0101] The electronic device provided in this disclosure and the dialogue processing method provided in this disclosure are based on the same inventive concept and have the same beneficial effects as the methods they adopt, operate or implement.

[0102] This application also provides a computer-readable storage medium storing instructions for dialogue processing, which, when executed on a computer, cause the computer to perform some or all of the steps in the methods described in the foregoing embodiments.

[0103] This application also provides a computer program product including instructions for dialogue processing, which, when run on a computer, causes the computer to perform some or all of the steps in the method described in the foregoing embodiments.

[0104] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0105] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection between apparatuses or units through some interfaces, and may be electrical, mechanical, or other forms.

[0106] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0107] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

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

[0109] Although alternative embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make further changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.

[0110] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of this application. It should be understood that the above description is only a specific embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made on the basis of the technical solution of this application should be included within the scope of protection of this invention.

Claims

1. A dialogue processing method, characterized in that, The method includes: In response to obtaining dialogue information to be processed, at least one target intent is determined from the dialogue information to be processed; Determine at least one target scenario corresponding to the at least one target intent; Filter the subset of target execution components that correspond to the at least one target scenario from the preset set of execution components; The target execution components in the subset of target execution components are invoked according to the invocation rules of each target execution component to generate a solution for the dialogue information to be processed.

2. The method according to claim 1, characterized in that, The step of filtering a subset of target execution components corresponding to each of the at least one target scenario from a preset set of execution components includes: Determine scene features based on the at least one target scene; Obtain execution components that match the scene features from the preset set of execution components; If at least one execution component matching the scene features is obtained from the preset execution component set, then the at least one execution component is determined as a subset of the target execution components; If no execution component matching the scene features is obtained from the preset execution component set, the execution component matching model is invoked to match the corresponding target execution component subset in the preset execution component set.

3. The method according to claim 2, characterized in that, Determining scene features based on the at least one target scene includes: Determine the dispute type characteristics and claim characteristics based on at least one target intent; The scenario features are determined based on the dispute type features, the claim features, and the order information corresponding to the pending dialogue information.

4. The method according to claim 2 or 3, characterized in that, The invocation execution component matching model, for matching the corresponding target execution component subset in the preset execution component set, includes: For any target scene, determine the historical scene with the highest similarity to the target scene from the historical scene database; At least one execution component corresponding to the historical scenario is taken as a subset of the target execution components.

5. The method according to claim 2 or 3, characterized in that, The invocation execution component matching model, for matching the corresponding target execution component subset in the preset execution component set, includes: For any target scenario, determine at least one executable result corresponding to the target scenario to obtain a set of executable results corresponding to the at least one target scenario; Identify at least one target executable result that satisfies the at least one target scenario from the set of executable results; The target execution component corresponding to the at least one target executable result is taken as the target execution component subset.

6. The method according to claim 1, characterized in that, The step of invoking the target execution components in the subset of target execution components according to the invocation rules of each target execution component includes: If the invocation rule is a parallel invocation, then each target execution component is invoked in parallel to generate the solution; If the invocation rules include serial invocation, then each target execution component is invoked sequentially according to the invocation rules of each execution component in the serial invocation to generate the solution.

7. The method according to claim 6, characterized in that, If the calling rules are serial and parallel calls, the method further includes: According to the calling rules of each execution component in the serial call, the corresponding serial target execution component is called; Based on the invocation results of each serial target execution component, the corresponding parallel target execution components are invoked in parallel to obtain the solution.

8. The method according to claim 6, characterized in that, If multiple solutions are generated, the method further includes: Based on the popularity values ​​corresponding to the multiple solutions, a preset number of solutions are determined as target solutions.

9. The method according to claim 1, characterized in that, Determining at least one target intent from the dialogue information to be processed includes: Determine the order information contained in the dialogue information to be processed; Read historical dialogue information related to the order information, where the historical dialogue information refers to the dialogue information preceding the dialogue information to be processed. If the order information triggers the solution generation condition, the intent recognition model is invoked to determine the at least one target intent based on the historical dialogue information.

10. The method according to claim 9, characterized in that, The solution generation conditions include at least one of the following: the merchant has no solution, the merchant's response times out, or the consumer does not agree with the solution provided by the merchant.

11. A dialogue processing apparatus, characterized in that, The device includes: An intent determination module is used to determine at least one target intent from the pending dialogue information in response to obtaining pending dialogue information. The scenario determination module is used to determine at least one target scenario corresponding to the at least one target intent; The filtering module is used to filter a subset of target execution components that correspond to the at least one target scenario from a preset set of execution components; The generation module is used to call the target execution components in the subset of target execution components according to the calling rules of each target execution component, so as to generate a solution for the dialogue information to be processed.

12. An electronic device comprising a memory, a processor, and a computer program stored in the memory, wherein the processor, when executing the computer program, implements the method of any one of claims 1-10.

13. A computer-readable storage medium having a computer program stored thereon, characterized in that, The program is executed by a processor to implement the method as described in any one of claims 1-10.

14. A computer program product, characterized in that, Includes instructions that, when executed on a computer, cause the computer to perform the method as described in any one of claims 1-10.

Images