Method, device, storage medium and program product for managing multi-round conversations

Abstract

This application provides a method, device, storage medium, and program product for managing multi-turn dialogues, relating to the field of artificial intelligence technology. The method utilizes a drift detection model to detect drift in the current dialogue content and effectively stores and tracks historical intents through an intent management mechanism. When intent drift is detected, a drift type recognition model can be used to identify the drift type, and differentiated dialogue processing can be performed based on the drift type. This endows the customer service robot with long-term memory and multi-tasking capabilities, allowing it to continue or connect previously unfinished dialogue tasks in any turn without requiring the user to repeat already mentioned questions. Even after multiple turns of intent switching, the customer service robot can still accurately generate responses that meet the user's true needs, achieving a more coherent, intelligent, and humanized multi-turn interactive experience, significantly improving dialogue efficiency and user satisfaction.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence technology, and in particular to a method, device, storage medium, and program product for managing multi-turn dialogues. Background Technology

[0002] Against the backdrop of accelerated digital transformation and increasingly sophisticated consumer service demands, intelligent customer service robots have been widely applied in various industries such as e-commerce, finance, telecommunications, and home appliances, becoming an important tool for improving service efficiency and reducing labor costs. Users may ask multiple questions in a single conversation. Traditional intelligent customer service robots employ a dialogue management mechanism based on FSM (Finite State Machine), driving the dialogue process through predefined states and transition conditions between states. This dialogue management mechanism is unidirectional, lacks backtracking capabilities, and struggles to handle complex interactions with intertwined intentions.

[0003] To improve the understanding capabilities of customer service chatbots, the industry is gradually shifting towards an end-to-end dialogue architecture based on LLM (Large Language Model). However, LLM employs a current intent coverage strategy, which means that as the number of dialogue rounds increases, unanswered questions are covered up, leading to missed user requests. When users return to previous topics, they need to repeatedly restate the questions already mentioned, resulting in low interaction efficiency and inaccurate model responses due to the increasing number of dialogue rounds, severely impacting the user experience. Summary of the Invention

[0004] This application provides a method, device, storage medium, and program product for managing multi-turn dialogues, enabling customer service robots to have long-term memory and multi-tasking capabilities, making the dialogue experience more coherent and natural, and improving user experience and customer service satisfaction.

[0005] This application provides a method for managing multi-turn dialogues, including: obtaining the target dialogue content of the current turn in a dialogue window, and performing intent recognition on the target dialogue content to obtain the target intent; using a drift detection model to analyze whether the target intent has drifted relative to the current active intent based on the semantic relevance and dialogue coherence of the target intent and the current active intent, wherein the current active intent is the intent that was most recently successfully parsed and entered the processing flow before the current turn; if the target intent has drifted relative to the current active intent, suspending the current active intent in the historical intent queue; using a drift type recognition model to identify the drift type of the target intent relative to the historical intents that are in a suspended state in the historical intent queue based on the type of the target intent and the dialogue main line; and performing dialogue processing on the historical intents and the target intent according to the drift type, wherein different drift types correspond to different dialogue processing strategies.

[0006] This application also provides a computing device, including: a memory and a processor; wherein, the memory stores executable code, and when the executable code is executed by the processor, the processor performs the above-described method for managing multi-turn dialogues.

[0007] This application also provides a computer-readable storage medium storing executable code, which, when executed by a processor of a computing device, causes the processor to perform the aforementioned method for managing multi-turn dialogues.

[0008] This application also provides a computer program product, including: a computer program / instructions, which, when executed by a processor, enable the processor to implement the steps in the above-described method for managing multi-turn dialogues.

[0009] The method provided in this application, after obtaining the target dialogue content of the current round in the dialogue window, performs intent recognition on the target dialogue content to obtain the target intent. Using a drift detection model, it analyzes whether the target intent has drifted relative to the current active intent from two dimensions: semantic relevance and dialogue coherence. This effectively distinguishes whether the user has made a natural extension of intent or a sudden jump in intent. If the target intent drifts relative to the current active intent, it does not directly overwrite or discard the current dialogue thread. Instead, it suspends the current active intent in the historical intent queue to retain the dialogue context of the current active intent. This allows the customer service robot to have long-term memory, providing a data foundation for differentiated dialogue processing strategies. Even if the user switches intent midway, previously unresolved issues are still available, eliminating the need for the user to repeatedly repeat the issues already mentioned. Furthermore, using a drift type recognition model based on the type of the target intent and the dialogue thread, it identifies the drift type of the target intent relative to historical intents in the historical intent queue that are in a suspended state. This fine-grained classification capability enables the intelligent customer service robot to understand the deep logic behind the user's switching intents, and thus execute differentiated dialogue processing strategies according to the drift type. This approach not only avoids logical confusion caused by loss of context and ensures the accuracy of the intelligent customer service robot's responses in long-round conversations, but also enables the intelligent customer service robot to flexibly respond to frequent topic jumps by users, freely switch or back between multiple dialogue lines, significantly enhancing the fluency and coherence of human-computer interaction, achieving a more human-like and intelligent multi-round dialogue experience, and significantly improving user experience and customer service satisfaction. Attached Figure Description

[0010] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 A flowchart illustrating a method for managing multi-turn dialogues provided as an exemplary embodiment of this application; Figure 2 A schematic diagram of the structure of a drift detection model provided in an exemplary embodiment of this application; Figure 3 A schematic diagram of the structure of a drift type identification model provided in an exemplary embodiment of this application; Figure 4 A schematic diagram of the structure of an apparatus for managing multi-turn dialogues provided as an exemplary embodiment of this application; Figure 5 This is a schematic diagram of the structure of a computing device provided for an exemplary embodiment of this application. Detailed Implementation

[0011] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0012] It should be noted that, in the cases involving user information in the embodiments of this application, 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 relevant laws, regulations, and standards, and corresponding operation entry points are provided for users to choose to authorize or refuse. In addition, the various models involved in this application (including but not limited to language models or large models) comply with relevant laws and standards.

[0013] Against the backdrop of accelerated digital transformation and increasingly sophisticated consumer service demands, intelligent customer service robots have been widely applied in various industries such as e-commerce, finance, telecommunications, and home appliances, becoming an important tool for improving service efficiency and reducing labor costs. In a single conversation, users may ask multiple questions and switch between topics. During this process, the user's current conversational intent often undergoes unexpected shifts, forks, or jumps relative to previous intents; this phenomenon is known as intent drift. For example, in an e-commerce scenario, the following dialogue might occur: "User: When will my phone case be shipped (Intent A: Logistics tracking)? Customer Service: Your order is expected to ship tomorrow. User: Okay, by the way, do you have a red one? (Intent B: Product inquiry - color)? Customer Service: Yes, we have a red one. Do you need to exchange it? User: I'll exchange it for red. Also, why hasn't my refund application arrived yet? (Intent C: Refund inquiry)? Customer Service: Let me check the refund progress for you. The refund is expected to arrive within 3 business days. User: Okay, how do I exchange it for red? (Back to Intent B)? Customer Service: How can I help you?" In this process, the user's intent has shifted from Intent A to Intent B to Intent C and back to Intent B.

[0014] Traditional customer service chatbots employ a dialogue management mechanism based on a Finite State Machine (FSM). This mechanism drives the dialogue flow through predefined states and transition conditions between them. When user input triggers a state transition, the FSM executes the corresponding standard operating procedure. For example, in an e-commerce scenario, if a user mentions color in the logistics query state, the FSM will transition to the product inquiry state. This dialogue management mechanism is unidirectional, lacking the ability to manage and trace historical intents. It struggles to handle complex interactions with intertwined intents, particularly failing to identify and respond to intent drift behaviors, and also struggles to exhaustively enumerate all possible state transition paths.

[0015] To improve the understanding capabilities of customer service chatbots, the industry is gradually shifting towards end-to-end dialogue architectures based on LLM (Large Language Model). However, LLM employs a current intent overriding strategy. As the number of dialogue rounds increases, early intents are diluted in the attention mechanism, and unanswered questions are easily overridden by subsequent intents, leading to missed user requests. When users return to previous topics, the model struggles to quickly recover the relevant context due to the loss of historical intent information, requiring users to repeatedly repeat the questions already asked. This not only results in low interaction efficiency but also inaccurate model responses due to the increasing number of dialogue rounds, severely impacting the user experience.

[0016] To address this, this application proposes a method for managing multi-turn dialogues. It utilizes a drift detection model to detect drift in the displayed content of the current dialogue and employs an intent management mechanism to effectively store and track historical intents, preventing their loss. When an intent drift is detected between the current dialogue intent and the preceding intent, a drift type identification model can be used to identify the drift type. Based on the drift type, differentiated dialogue processing, such as recovery or association of historical intents, is performed. This endows the customer service robot with long-term memory and multi-tasking capabilities, allowing it to naturally continue or associate previously unfinished dialogue tasks in any turn without requiring the user to repeat previously mentioned questions. Even after multiple turns of intent switching, the customer service robot can still accurately generate responses that meet the user's actual needs, effectively avoiding intent omissions and context breaks, achieving a more coherent, intelligent, and human-centered multi-turn interactive experience, and significantly improving dialogue efficiency and user satisfaction.

[0017] Furthermore, in this embodiment, the customer service robot is also given the ability to proactively guide users back to unresolved intentions, enabling it to proactively prompt or connect previously pending requests when the current task is completed or the conversation is at an appropriate pace, thus preventing users from missing questions due to forgetfulness or process interruption, and further enhancing the integrity of the conversation and the initiative of the service.

[0018] The technical solutions provided by the various embodiments of this application are described in detail below with reference to the accompanying drawings.

[0019] Figure 1 A flowchart illustrating a method for managing multi-turn dialogues provided as an exemplary embodiment of this application is shown below. Figure 1 As shown, the method includes: Step 11: Obtain the target dialogue content for the current round in the dialogue window, and perform intent recognition on the target dialogue content to obtain the target intent.

[0020] Step 12: Using the drift detection model, analyze whether the target intent has drifted relative to the current active intent based on the semantic relevance and dialogue coherence between the target intent and the current active intent. The current active intent is the intent that was most recently confirmed to have been successfully parsed and entered the processing flow before the current round.

[0021] Step 13: If the target intent drifts relative to the current active intent, the current active intent is added to the historical intent queue.

[0022] Step 14: Using the drift type identification model, identify the drift type of the target intent relative to the historical intents that are in a suspended state in the historical intent queue, based on the type of the target intent and the dialogue thread.

[0023] Step 15: Based on the drift type, perform dialogue processing on the historical intent and the target intent, where different drift types correspond to different dialogue processing strategies.

[0024] The above-described method for managing multi-turn dialogues can be applied to various scenarios that require interaction with intelligent customer service robots, such as product consultation and after-sales service scenarios in the e-commerce industry, wealth management customer service scenarios in the financial industry, and health consultant scenarios in the healthcare industry. This embodiment does not impose any limitations, and the following explanation will take the product consultation and after-sales service scenario in the e-commerce industry as an example.

[0025] A dialog window serves as the conversation context boundary for a continuous dialogue between a user and an intelligent customer service chatbot. Users can enter a dialog window through a client application (such as a webpage, mobile app, or mini-program) to establish a conversation with the chatbot. For example, the chat interface that opens after clicking "Contact Customer Service" on a webpage is a dialog window. Within the dialog window, each user input is numbered chronologically as a dialogue round, where the current round corresponds to the most recent message entered by the user in that dialog window. The original message entered by the user in the current round is called the target dialogue content; for example, the target dialogue content could be "change it to red." The target dialogue content is the starting point for subsequent intent recognition and drift analysis.

[0026] The currently active intent is the intent that was most recently successfully parsed and entered the processing flow before the current round. The currently active intent serves as the access anchor for the current dialogue context, used to evaluate whether the target dialogue content of new input continues the original dialogue task. The currently active intent is not the same as the intent of the previous round. If an intent (such as a replacement request) is established as the currently active intent by the system, and the user inserts irrelevant content (such as "okay") in subsequent dialogues, the currently active intent will remain as long as there is no explicit intent drift or task termination.

[0027] After obtaining the target dialogue content for the current round, the intent recognition model can be invoked. On one hand, the intent recognition model is used for basic NLU parsing. Based on the current target dialogue content and the aforementioned dialogue context, operations such as named entity recognition, referential resolution, and omission completion are performed. For example, if the target dialogue content is "change to red", the intent recognition model can infer the complete semantics as "replace the phone case in order O123 with the red one" by combining the product information in the context. On the other hand, the intent recognition model is used to perform intent recognition and slot filling on the target dialogue content to obtain the target intent and the slot information associated with the target intent.

[0028] After obtaining the target intent, a drift detection model is used to analyze whether the target intent has drifted relative to the current active intent. If no intent drift has occurred, the target dialogue content is considered a continuation or slot supplement of the current active intent, and the target dialogue content continues to be processed within the context of the current active intent to generate a response for the current active intent. If intent drift has occurred, it means that the target intent has deviated from the current active intent and shifted to a new dialogue target. In this case, the state of the current active intent is changed from active to suspended, and the current active intent is added to the historical intent queue for later backtracking. Then, a drift type identification model is used to identify the drift type of the target intent relative to the suspended historical intents in the historical intent queue based on the type of the target intent and the dialogue main line, and differentiated dialogue management is performed based on the drift type.

[0029] A drift type is a structured representation of the relationship between a target intent and one or more suspended historical intents in dimensions such as task continuity, semantic relevance, or topic independence. In this embodiment, based on the relationship attributes between the target intent and historical intents reflected by the drift type, it is possible to dynamically determine how to integrate or isolate the contextual information of the historical intent and the target intent, and adjust the response generation logic and the state of the historical intent accordingly. This allows for the application of different dialogue management strategies to different drift types, achieving fine-grained control over the state of multi-turn dialogues. For example, a system or device responsible for managing multi-turn dialogues can determine, based on the drift type, whether the target intent is a retrospective of an unfinished task, a new request related to an existing task, or a completely unrelated new topic; then, it decides whether to restore a suspended intent from the historical intent queue, whether to process the target intent jointly with a historical intent, or whether to respond to the current intent as an independent task.

[0030] The aforementioned method for managing multi-turn dialogues ensures that historical intents are not interrupted or lost when users intersperse their questions, and avoids chaotic responses caused by the incorrect merging of irrelevant intents. This enables intelligent customer service robots to adaptively respond to users' intent drifting behavior in complex task scenarios. No matter how users jump around in their questions, the dialogue experience remains coherent, natural, and accurate, greatly improving user experience and customer service satisfaction.

[0031] The drift detection model described above can comprehensively evaluate whether the target intent has drifted relative to the historical intent that is in a suspended state from two dimensions: the semantic relevance between the target intent and the currently active intent and the dialogue coherence.

[0032] Semantic relevance measures whether the target dialogue content is semantically consistent with the description of the current active intent. For example, if the current active intent is "logistics inquiry," and the target dialogue content is "Where is my package?", then the target dialogue content and the current active intent are highly semantically related. If the target dialogue content is "How do I get an invoice?", then the target dialogue content and the current active intent are less semantically related. Higher semantic relevance indicates that the target dialogue content and the current active intent are more likely to belong to the same intent, and the probability of the target intent drifting relative to historical intents that are currently suspended is lower. Lower semantic relevance indicates that the target dialogue content is more likely to be a new topic, and the probability of the target intent drifting relative to historical intents that are currently suspended is higher.

[0033] In task-oriented dialogue scenarios, some user inputs, while not semantically similar to the current active intent, may be a reasonable and natural next step in the current task flow. A more accurate judgment can be made by combining semantic relevance with dialogue coherence. Dialogue coherence indicates whether the target dialogue content is consistent with the historical interaction segments corresponding to the current active intent, predicting whether the target dialogue content is a natural continuation of the task corresponding to the current active intent. For example, in a product exchange application process, if the previous content was "Please select a reason," and the target dialogue content is "The color was selected incorrectly," then the target dialogue content is consistent with the previous dialogue. If the target dialogue content is "Do you have a membership?", then the target dialogue content is not consistent with the previous dialogue. Higher dialogue coherence indicates that the target dialogue content is consistent with the previous dialogue, the target intent continues to advance the current active intent, and the probability of drift is lower; lower dialogue coherence indicates that the dialogue is not consistent, and the probability of drift is higher.

[0034] For example, using a drift detection model to analyze whether the target intent has drifted relative to the current active intent based on the semantic relevance and dialogue coherence between the target intent and the current active intent can be achieved as follows: Obtain historical dialogue content from multiple rounds prior to the current round, as well as slot filling information for the current active intent; input the historical dialogue content, target dialogue content, and slot filling information into the drift detection model, and perform the following steps in the drift detection model: encode the target dialogue content using a first encoder to obtain a target semantic vector, encode the historical dialogue content using a second encoder to obtain a historical context vector, and generate a slot completion vector based on the slot filling information; calculate the semantic relevance vector between the historical context vector and the target semantic vector based on a cross-attention mechanism; obtain the drift probability based on the target semantic vector, historical context vector, semantic relevance vector, and slot completion vector; when the drift probability is greater than a preset threshold, determine that the current intent has drifted relative to the current active intent.

[0035] In this embodiment, the drift detection model has three inputs: First, the target dialogue content, which serves as the semantic focus to be judged. Second, the historical dialogue content from multiple rounds prior to the current round, used to construct a global context. This historical dialogue content is a continuous text composed of user input and intelligent customer service robot responses, which can be obtained from the dialogue window, memory, or cache. Real user dialogues are filled with many context-dependent ellipsis expressions, such as "yes," "no," "the second," and "that order." If these isolated statements are removed from their historical context, their true intent cannot be accurately interpreted. Third, the slot filling information for the currently active intent. This slot filling information describes in a structured form whether the key elements of the currently active intent are complete, reflecting the execution stage of the task; the slot filling information for the currently active intent can be obtained from the dialogue manager.

[0036] The three target dialogue contents, historical dialogue contents, and slot filling information are input into the drift detection model. The drift detection model can use the current active intent as a semantic anchor point, and collaboratively integrate the global dialogue background, local task progress status, and fine-grained semantic coherence signals to dynamically quantify the degree of deviation of the current user input from the intent of the current main task, and output a thresholdable drift probability.

[0037] In practical applications, the drift detection model uses a first encoder to encode the target dialogue content, obtaining a target semantic vector. This target semantic vector represents the local semantics of the target dialogue content, capturing the inherent semantic connotation of the current statement through vectorization. A second encoder encodes the historical dialogue content, obtaining a historical context vector. This historical context vector represents the overall semantic background of recent dialogues, capturing the complete semantics of the target dialogue content within the dialogue context. Slot filling information is converted into a numerical vector of length equal to the number of required slots through normalization or embedding mapping, called the slot completion vector. Each element in the slot completion vector is a 0-1 number, representing the completion degree of that slot. The slot completion vector reflects the filling status of key slots in the currently active intent, providing task progress information and representing the progress of intent-related tasks, which can help determine whether the current task should continue. Specifically, if the slot completion degree is high, the appearance of a new intent may not be a true drift, but rather a natural extension of the current task; conversely, if the slot completion degree is low, the current task is not yet completed, and the appearance of a new intent may be a true drift.

[0038] After obtaining the target semantic vector and the current active vector based on the encoding, the semantic relevance and dialogue coherence of the two are further jointly calculated. There are various implementation methods for the specific calculation, which are not limited here.

[0039] In some implementations, semantic relevance and dialogue coherence can be calculated separately. First, based on the position of the historical dialogue segment corresponding to the current active intent within the historical dialogue content, the current active vector related to the current active intent is located from the historical context vector. The semantic relevance between the target semantic vector and the current active vector is then calculated. For example, semantic relevance can be obtained through cosine similarity, specifically by normalizing the magnitude of both the target semantic vector and the current active vector, multiplying the two normalized vectors element-wise to obtain a semantic relevance vector, and then calculating a semantic relevance score for each element of this vector, ranging from -1 to 1. Alternatively, semantic relevance can be obtained through a cross-attention mechanism, specifically by performing cross-attention calculation between the current active vector and the target semantic vector. Cross-attention dynamically focuses on the most relevant context position by having each semantic unit of the target semantic vector query relevant information about the current active intent, thus obtaining a semantic relevance vector. This semantic relevance vector is then aggregated to obtain a semantic relevance score. This semantic relevance vector represents the degree of semantic matching between the target dialogue content and the current active intent.

[0040] Furthermore, using the target semantic vector as the query, and the joint representation of the historical context vector, the current active vector, the current task step identifier, and the slot completion vector as the key and value, a context vector is obtained through multi-layer cross-attention calculation; discriminative features related to dialogue coherence judgment are extracted from the context vector, and the discriminative features are mapped to dialogue coherence scores.

[0041] In this implementation, the association weights between the target dialogue content and each word in the current active intent description are calculated based on the cross-attention mechanism, and the semantic alignment, conflict and complementarity between the two are accurately identified to obtain the dialogue coherence. The specific implementation is as follows: The target semantic vector, historical context vector, current active vector, current task step identifier, and slot completion vector are concatenated into a sequence and input into a cross-attention network. Using the target semantic vector as the query and the joint representation of the historical context vector, current active vector, current task step identifier, and slot completion vector as the key and value, multi-layer cross-attention calculation dynamically focuses the query on the most relevant information position in the historical task context, resulting in a context vector (i.e., a dialogue coherence vector). This context vector integrates the interaction information between the target dialogue content and the historical context, comprehensively representing the semantic alignment degree and dialogue continuity rationality of the target dialogue content in the task flow of the current active intent. Then, the context vector is input into a binary classification multilayer perceptron, which maps the high-dimensional context vector to the feature space required for the binary classification task, extracting the discriminant features most relevant to the dialogue coherence judgment. Finally, the scalar output of the perceptron is mapped to a score between 0 and 1 through a sigmoid activation function. This score is the dialogue coherence score, used to represent whether the current user input is a natural continuation of the task corresponding to the current active intent.

[0042] The current task step identifier indicates the specific stage of the current dialogue within the overall task flow. For example, the task flow can be divided into the intent recognition stage, slot filling stage, information confirmation stage, execution operation stage, and resolution stage. The purpose of the current task step identifier is to provide prior information about the task flow position for the cross-attention mechanism, enabling the drift detection model to distinguish whether the current input is at the beginning, middle, or end of the task. This allows the model to assign differentiated attention weights to information at different positions in the historical context at different stages, preventing the drift detection model from misaligning the dialogue content of earlier stages with the current task requirements, thereby improving the accuracy of dialogue coherence judgment.

[0043] The drift probability is obtained based on the target semantic vector, historical context vector, semantic relevance vector, and slot completion vector. This includes: obtaining the drift probability based on the target semantic vector, historical context vector, semantic relevance score obtained from the semantic relevance vector, dialogue coherence score, and slot completion vector. The principle for calculating the drift probability P can be expressed as: P = σ(W·[Ecurr⊕Ectx⊕(1-Sim)⊕(1-Coh{task})⊕Vslot] + b). Here, Ecurr represents the target semantic vector, Ectx represents the historical context vector, Sim represents the semantic relevance score, Coh{task} represents the dialogue coherence score, Vslot represents the slot completion vector, W is the learnable weight matrix, b is the bias term, σ represents the Sigmoid function, and ⊕ represents the vector concatenation operation.

[0044] In other implementations, the drift detection model can first calculate features representing dialogue coherence and then inject these features into the semantic relevance calculation process. For example, based on a cross-attention mechanism, calculating the semantic relevance vector between the historical context vector and the target semantic vector can be implemented as follows: Based on the position of the historical dialogue segment corresponding to the current active intent within the historical dialogue content, the current active vector related to the current active intent is located from the historical context vector. Using the target semantic vector as the query and the current active vector as the key and value, an attention weight distribution is calculated through cross-attention; based on the focus position of the attention weight distribution in the historical dialogue segments related to the current active intent, a dialogue coherence gain factor is generated, which represents the degree of continuity between the target dialogue content and the current active intent; the attention weight distribution is element-wise multiplied by the dialogue coherence gain factor to obtain the semantic relevance vector; and this semantic relevance vector is aggregated to obtain the semantic relevance score.

[0045] The attention distribution can be represented as an attention weight matrix, where each element reflects the correlation between each word in the target dialogue content and each word in the historical dialogue segment corresponding to the current active intent (referred to as historical words). Furthermore, a dialogue coherence gain factor is introduced into the cross-attention calculation. By analyzing the focal position of the attention weight distribution in the historical dialogue segments related to the current active intent segment—such as the position of maximum weight, the position of the weighted average, or the center point of a high-weight region—the dependence of the target dialogue content on task progress is quantified, and the semantic matching strength is modulated accordingly.

[0046] For example, for each word in the target dialogue content, the position of the historical word corresponding to the maximum attention weight is found in the attention weight matrix. Next, the sequence number of the dialogue turn to which the historical word belongs is determined within the historical dialogue segment corresponding to the current active intent. For instance, if the historical dialogue segment of the current active intent contains three dialogue turns (turn 1, turn 2, and turn 3), and the historical word belongs to turn 2, its turn sequence number is 2. The ratio of the turn sequence number to the total number of turns in the historical dialogue segment corresponding to the current active intent is further calculated, resulting in a value between 0 and 1. This value is the dialogue coherence gain factor. The dialogue coherence gain factor indicates which stage of the task progress of the current active intent the focus of the target dialogue content falls on; that is, whether the attention is mainly concentrated in the early or recent stages of the historical task. The closer the dialogue coherence gain factor is to 1, the closer the focus is to the end of the segment, indicating that the user is more likely to continue the latest context of the task, and the stronger the dialogue coherence; the closer the dialogue coherence gain factor is to 0, the closer the focus is to the beginning of the segment, and the weaker the dialogue coherence.

[0047] The maximum attention weight of each word in the target dialogue content is then multiplied by its corresponding dialogue coherence gain factor to obtain a weighted semantic relevance vector. The average of the semantic relevance vectors of each word in the target dialogue content is then calculated to obtain the task-enhanced semantic relevance score. This semantic relevance vector comprehensively reflects the consistency of the target dialogue content with the current active intent in terms of semantic content and the coherence in terms of task progression sequence. After obtaining the semantic relevance score, the target semantic vector, historical context vector, semantic relevance score, and slot completion vector are calculated to obtain the drift probability. The principle for calculating the drift probability P can be expressed as: P = σ(W·[Ecurr⊕Ectx⊕(1-Sim)⊕V) slot ]+b).

[0048] In this way, the drift detection model can integrate multi-dimensional evidence in a unified decision space to generate more discriminative drift probabilities. Specifically, the target semantic vector ensures an accurate representation of the current dialogue content; the historical context vector retains global contextual information across rounds, effectively mitigating false triggers caused by local semantic jumps; the semantic relevance vector, through a fine-grained alignment mechanism, accurately captures whether the current dialogue content continues the latest interaction context of the current active intent, which is the core basis for distinguishing whether intent drift has occurred; the slot completion vector introduces prior knowledge of the task execution state, enabling the drift detection model to dynamically adjust the tolerance threshold for semantic changes according to the stage of the task; through the complementary synergy of the above four types of features, the drift detection model can output drift probabilities based on a comprehensive judgment of the consistency of semantic content, contextual coherence, and task progress status, achieving high-precision perception of intent drift dynamics.

[0049] This application does not limit the number of model parameters supported by the drift detection model, aiming to meet actual needs. Optionally, the drift detection model can be a traditional artificial intelligence model with relatively small model parameters, or a large model with relatively large model parameters, such as an LLM (Large Language Model), but it is not limited to these. The following describes... Figure 2 The architecture and processing flow of the drift detection model are illustrated by example.

[0050] like Figure 2 As shown, the drift detection model mainly includes a dual-tower encoding submodule, a lightweight preprocessing module, and a fusion computation layer. The dual-tower encoding submodule contains a first encoder and a second encoder that encode the target dialogue content and historical dialogue content into a target semantic vector and a historical context vector, respectively. The second encoder is also used to extract the currently active intent vector from the historical context vector, which can be implemented through attention pooling or an intent classification head. The first and second encoders have the same structure but do not share parameters; for example, a context-aware sequence encoding structure based on a multi-layer self-attention mechanism can be used. The first and second encoders operate independently and are completely isolated during computation. The lightweight preprocessing module is used to generate a slot completion vector based on slot filling information and to generate a current task step identifier. The fusion computation layer includes a cross-attention layer and a multi-layer perceptron, where the multi-layer perceptron is composed of multiple fully connected layers stacked together. The specific implementation of the fusion computation layer varies in different implementations.

[0051] For example, in the method of calculating semantic relevance using cosine similarity, the target semantic vector, historical context vector, current active vector, current task step identifier, and slot completion vector are input into the fusion computing layer. The fusion computing layer also includes a similarity calculation module, which receives the target semantic vector and the current active vector and obtains a semantic relevance vector through cosine similarity calculation. At the same time, the cross-attention layer of the fusion computing layer obtains the context vector of dialogue coherence through multi-layer cross-attention calculation. The target semantic vector, historical context vector, semantic relevance vector, context vector of dialogue coherence, and slot completion vector are concatenated into a joint feature to form a joint feature representation, which is then input into the multilayer perceptron.

[0052] For example, the target semantic vector, historical context vector, and slot completion vector are input into the fusion computation layer. A semantic relevance vector is calculated using a cross-attention mechanism in the cross-attention layer. The target semantic vector, historical context vector, semantic relevance vector, and slot completion vector are concatenated to form a joint feature representation, which is then input into the multilayer perceptron.

[0053] In a multilayer perceptron, multiple pairs of joint feature representations undergo layer-by-layer nonlinear transformations, and the Sigmoid activation function outputs a value between 0 and 1, representing the drift probability. The drift probability quantifies the likelihood of intent drift occurring in the current round and serves as a decision threshold for whether to trigger drift type determination. When the drift probability exceeds a preset threshold, it is determined that the target intent has drifted relative to the currently active intent, thus triggering the subsequent drift type determination process.

[0054] In an exemplary embodiment, a drift type recognition model is used to identify the drift type of a target intent relative to historical intents in a suspended state in the historical intent queue, based on the type of the target intent and the dialogue mainline. This includes: generating a first prompt based on the details of the target intent and the details of the historical intents in a suspended state, wherein the details include at least: intent type, intent identifier, parent intent category, and slot filling information; inputting the first prompt into the drift type recognition model, and under the guidance of the first prompt, the drift type recognition model uses a position-aware attention mechanism to verify the consistency of the intent type and intent identifier of the target intent and the historical intents in a suspended state, so as to obtain a consistency verification result; based on the parent intent category and slot filling information, using a semantic association attention mechanism to verify whether the target intent and the historical intents in a suspended state belong to the same dialogue mainline, so as to obtain a mainline verification result; and identifying the drift type of the target intent relative to the historical intents in a suspended state based on the consistency verification result and the mainline verification result.

[0055] In this embodiment, a dialogue manager is used to manage the historical intent queue. During drift type identification, details of the target intent and details of historical intents in a suspended state can be obtained from the dialogue manager. Then, based on the details of the target intent and the details of the historical intents in a suspended state, a first prompt is constructed. The first prompt not only contains the complete structured fields of the target intent and each suspended historical intent, but also contains explicit instructions to guide the drift type identification model to perform consistency verification and dialogue mainline verification. For example, the first prompt can take the form of "You are an e-commerce dialogue understanding engine. Please determine the drift type of the target intent based on the following information: [Current target intent: intent identifier; intent type; parent intent category; slot filling information]; [historical intents ... Figure 1 [Intent identifier; Intent type; Parent intent category; Slot filling information]; [Historical intents] Figure 1 : Intent identifier; Intent type; Parent intent category; Slot filling information]; Please perform the following operations; (1) For each historical intent, verify whether its intent identifier and intent type match the target intent. Figure 1(2) If inconsistent, determine whether it constitutes the same dialogue thread as the target intention; (3) Based on the above verification results, output the drift type: return drift / related drift / independent drift. This application does not limit the number of model parameters supported by the drift type recognition model, aiming to meet actual needs. Optionally, the drift type recognition model can be a traditional artificial intelligence model with relatively few model parameters, or a large model with relatively large model parameters, such as LLM, MLLM (Multimodal Large Language Model), etc. For example, as shown... Figure 3 As shown, the drift type recognition model can include a word segmenter, an embedding layer, a multi-head attention mechanism, and a feedforward neural network. When the first prompt word is input into the drift type recognition model, the model can use the word segmenter to divide the first prompt word into a sequence of word units. The embedding layer maps each word unit to a fixed-dimensional vector representation, and overlays positional encoding to preserve the original order of each word unit in the sequence.

[0056] After obtaining the complete vector sequence, the drift type recognition model utilizes a multi-head attention mechanism to focus on different semantic regions within the first prompt word, extracting key vector representations for subsequent verification. For example, the drift type recognition model identifies the lexical interval corresponding to the intent identifier of the target intent and uses the vector sequence of this lexical interval as the target intent identifier vector. Similarly, it extracts vectors corresponding to the intent type, its parent intent category, and service entities such as order number and product number in the slot filling information, forming the target intent type vector, target parent intent category vector, and target slot entity vector, respectively. For any historical intent in a suspended state, the drift type recognition model also extracts the corresponding historical intent identifier vector, historical intent type vector, historical parent intent category vector, and historical slot entity vector in the same way.

[0057] Based on the above vector representation, the drift type recognition model first performs consistency verification: for the target intent and any historical intent in a suspended state, its intent identifier vector and intent type vector are compared position by position. For the intent identifier, if the number of tokens corresponding to the target intent identifier vector and the historical intent identifier vector are not equal, it is directly determined as a mismatch; if the number of tokens is equal, it is further determined in a dedicated intent... Figure 1In the consistency detection attention head, the word sequence of the target intent identifier vector is used as the query, and the word sequence of the historical intent identifier vector is used as the key and value. Cross-attention calculation is performed to obtain a cross-attention weight matrix of size m×m (where m is the number of words). Based on the cross-attention weight matrix, a diagonal mask is constructed, retaining only the attention weights of the first word to the first word, the second word to the second word, ..., the mth word to the mth word, and setting the remaining positions to zero. The attention weights at these diagonal positions are accumulated to obtain the alignment attention score. If the alignment attention score is greater than or equal to m-ϵ (where ϵ is a very small tolerance, such as 0.1), that is, the attention weights are concentrated on the diagonal, it indicates that the historical intent identifier word is highly valued at each target intent identifier word position, which is equivalent to the word sequence being consistent, and thus the target intent identifier and the historical intent identifier are determined to be consistent; if the alignment attention score is less than m-ϵ, the target intent identifier and the historical intent identifier are determined to be inconsistent. The drift type recognition model performs position-by-position comparisons of the target intent type vector and the historical intent type vector in the same manner to determine whether the target intent identifier and the historical intent identifier are consistent. When both the intent identifier and intent type are determined to be consistent, the consistency verification result between the target intent and any historical intent in a suspended state is considered a match. Figure 1 Consistency detection attention head outputs a high activation signal, triggering a return-type drift decision gate; otherwise, the consistency verification result is a mismatch. Figure 1 The consistency detection attention head outputs a low activation signal, triggering the main dialogue verification.

[0058] In this context, the dialogue thread refers to the task context that unfolds around a high-level service goal in multi-turn dialogues, and is composed of one or more intents. The dialogue thread is a high-level task aggregation unit dynamically identified internally by the model based on the co-occurrence relationships of multiple intents across key service entities, parent intent categories, and task semantic goals. This unit is flexible, allowing for the dynamic inclusion of semantically related sub-tasks while maintaining the core goal, and enabling cross-intent inheritance and reuse of key slot information. For example, if a user asks "Do you have red phone cases?" and "Can I change to red?", although the intent types are different, they share the same order and product and have the same goal, so they can be grouped under the same dialogue thread.

[0059] In the dialogue mainline verification, the drift type recognition model utilizes a semantic association attention mechanism to determine whether the target intent and any suspended historical intent belong to the same high-level task context. In a dedicated semantic association attention head, the lexical sequence of the target slot entity vector of a service entity (such as an order number) in the target intent slot filling information is used as the query, and the lexical sequence of the historical slot entity vector is used as the key and value. Cross-attention calculation is performed to obtain the corresponding cross-attention weight matrix, which determines whether the service entity is the same in the target intent and historical intent. If the attention weights are concentrated on the diagonal, it indicates that the service entities are the same, and a high-confidence entity matching score is output. For multiple key service entities, individual entity matching scores are generated.

[0060] Similarly, the target parent intent category vector is compared with the historical parent intent category vector to determine whether the target intent and historical intent belong to the same high-level task category, outputting a parent category consistency score. Furthermore, the target intent type vector, historical intent type vector, and their respective slot entity vectors are concatenated and fed into a feedforward neural network. This feedforward neural network contains one or more fully connected layers and activation functions to perform non-linear fusion of multi-source semantic features, outputting a corresponding task synergy score to measure whether the target intent and historical intent constitute a collaborative sub-task under the same user goal in service logic. The scores from the above multiple dimensions are weighted and summed using learnable weight parameters to obtain a comprehensive association strength value. If this comprehensive association strength value is greater than or equal to a judgment threshold set internally by the model (this threshold can be automatically learned during the instruction fine-tuning stage), it is determined that the historical intent and the target intent belong to the same dialogue mainline; otherwise, the historical intent and the target intent do not belong to the same dialogue mainline, and the mainline verification result of the historical intent is output.

[0061] Optionally, an evaluation dimension of service domain consistency can be introduced into the aforementioned multi-dimensional evaluation of the dialogue mainline. Specifically, based on a predefined service classification system (such as after-sales domain, order domain, complaint domain, etc.), each intent is explicitly labeled with its corresponding service domain. For example, the after-sales domain includes returns, exchanges, refund progress, and shipping insurance; the order domain includes order inquiries, address modifications, and order cancellations. Service domain information is injected by the natural language understanding module or service rule engine when the intent is created and is persistently stored as intent metadata. When constructing the first prompt word, in addition to the original parent intent category and intent type, the target intent and the service domain tags of each pending historical intent are explicitly added.

[0062] During the verification of the main dialogue line, the service domain consistency score between the target intent and each suspended historical intent is determined. Then, the service domain consistency score is weighted and summed with the scores of the other three dimensions using learnable weight parameters to obtain a comprehensive association strength value. Service domain consistency, due to its strong prior nature, can be assigned a high initial weight during model training and further strengthened through fine-tuning. For example, it significantly improves the prediction confidence of associative drift for intent pairs within the same domain, while suppressing the possibility of misclassifying cross-domain intent pairs as associative. Thus, the service domain can not only serve as a structured input feature for prompts but also deeply participate in decision modeling, making the drift type identification results more consistent with the actual service process logic and significantly improving the robustness and interpretability of the model in complex dialogue scenarios.

[0063] The target intent and each suspended historical intent in the historical intent queue undergo consistency verification and mainline verification respectively. Based on the consistency verification results and mainline verification results, the drift type identification model can identify the drift type of the target intent relative to the suspended historical intent. Specifically, if there is a first historical intent with a matching consistency verification result, the drift type of the target intent relative to the suspended historical intent is determined to be a return-type drift; if there is a second historical intent with a non-matching consistency verification result but belonging to the same dialogue mainline in the mainline verification result, the drift type of the target intent relative to the suspended historical intent is determined to be an association-type drift; if the consistency verification result and the mainline verification result indicate that neither the first nor the second historical intent exists, the drift type of the target intent relative to the suspended historical intent is determined to be an independent drift.

[0064] Furthermore, the device or system responsible for managing multi-turn dialogues processes historical and target intentions based on the identified drift type. For example, it invokes a language generation model, instructs it to generate response information based on the corresponding dialogue management strategy according to the identified drift type, and sends the response information to the intelligent customer service robot so that the intelligent customer service robot can reply to the user. Specifically, if the drift type is a return-type drift, the dialogue state of the first historical intention is restored, and response information is generated based on the target intention to continue the task flow of the first historical intention; if the drift type is a relational drift, the second historical intention and the target intention are marked as collaborative sub-tasks, and multi-intention joint reasoning is performed on the collaborative sub-tasks to obtain joint response information for the current intention and the historical intention; if the drift type is an independent drift, response information is generated based on the slot information of the target intention.

[0065] Return-type drift refers to the situation where a user, after interrupting a task, explicitly reverts to that task itself; its essence is the reactivation of the same intent. This manifests as a first historical intent in the historical intent queue that is in a suspended state and has the same intent identifier and intent type as the target intent.

[0066] To address return-type drift, a task state restoration and process continuation strategy is implemented. Specifically, the first historical intent is used as a direct continuation of the current dialogue, restoring the complete dialogue state of the first historical intent. This complete dialogue state includes, but is not limited to, filled slots, the user's original request, and the operational steps already performed by the intelligent customer service robot, avoiding repetitive descriptions by the user. When generating response information, the complete dialogue state of the first historical intent is used as the current task context, aiming to continue the task flow of the first historical intent. This generates corresponding response information to help the user quickly connect to the context and achieve seamless task restoration. For example, if a user suddenly asks "How do I exchange for red?" while processing a refund inquiry, the product inquiry intent corresponding to "exchange for red" has already been created and suspended. When generating a response, the user is proactively prompted that they have returned to the previous task, for example, "We have returned you to the exchange issue. You previously selected a red phone case. Please confirm whether you want to submit an exchange request." This response is not an isolated response to the target dialogue content, but a natural continuation of the incomplete step (submitting an exchange request) in the original exchange task.

[0067] Related drift occurs when there is a structural or semantic connection between the target intent and the second historical intent, rather than a duplication of identifiers. This manifests as different intent types or intent identifiers between the target intent and the second historical intent, but they are closely related in service logic, jointly serving the same high-level goal or entity. The two intents may be derived from the same initial user request (e.g., a problem with my order triggers multiple sub-requests), share a unique service entity (e.g., logistics expediting and exchange requests under the same order number), or be defined by service rules as having the same sub-task origin. This type of drift does not constitute a backtracking of the original task, but requires joint processing to ensure service continuity.

[0068] To address related drift, a multi-intent collaborative processing strategy is implemented. Specifically, the target intent and the second historical intent are marked as collaborative sub-tasks. When generating response information, the slot information and task objectives of the target intent and the second historical intent are jointly parsed to generate a joint response that covers the target request and connects with the historical tasks. The joint response includes both a direct answer to the target intent and answers to the second historical intent, or status synchronization or collaborative operation prompts. For example, if a user first asks "When will my phone case be shipped?" (logistics inquiry intent) and then later asks "Can this phone case be changed to red?" (product inquiry intent), this can be mentioned together in the response, such as "It has been changed to red for you, and the order is expected to be shipped tomorrow," thereby improving dialogue efficiency and avoiding repeated follow-up questions from the user.

[0069] Independent drift refers to a situation where the current user input initiates a completely new topic unrelated to the existing task. This manifests as the current target intent having no service connection to or sharing of the task thread with any suspended historical intent. For independent drift, a context isolation and independent processing strategy is implemented. Specifically, suspended historical intents do not participate in the generation of the current response, ensuring that the response content does not introduce irrelevant historical tasks. Historical intents remain suspended, awaiting subsequent backtracking or timeout cleanup. When generating the response, the response is generated based on the slot filling information and intent type of the target intent itself, ensuring the conciseness and focus of the response. For example, if a user previously inquired about "logistics progress," and the target dialogue content was "Are there any coupons?", this scenario is identified as independent drift. The response only answers the coupon rules, without mentioning refunds, thus ensuring the focus and accuracy of the response.

[0070] In an exemplary embodiment, a dialog manager maintains multiple intent entries in a historical intent queue. Each intent entry records detailed information about a corresponding historical intent, including a processing status, which at least includes an active state and a suspended state. The processing status of the historical intents in the multiple intent entries is updated according to the drift situation and drift type. Specifically, when a drift occurs, the active state of the currently active intent is updated to a suspended state. When the drift type is a return drift, the first historical intent is updated from a suspended state to an active state. When the drift type is an associated drift, a new intent entry is created for the target intent, the processing status of the target intent in the new intent entry is set to an active state, and the target intent is associated with the second historical intent to the same dialog thread. When the drift type is an independent drift, a new intent entry is created for the target intent, and the processing status of the target intent in the new intent entry is set to an active state.

[0071] In this embodiment, a dialogue manager is used to provide fine-grained control over the execution status of intents in multi-turn dialogues. The dialogue manager maintains multiple intent entries in a historical intent queue. Intent entries serve as the carriers for recording and managing historical intents; each intent entry corresponds to a historical intent, and the intent entry records detailed information about the corresponding historical intent. This detailed information includes, but is not limited to: intent type, intent identifier, slot fill information, service priority, creation time, most recent active time, mainline identifier, parent intent category, service domain, and processing status.

[0072] The intent type refers to the specific task category to which the user's current request belongs, used to distinguish different semantic goals. The intent identifier is a string used to uniquely identify a specific user task instance, generated by combining key service entities. The intent identifier ensures that even if the intent types are the same, they are considered different intents if different service entities are involved. Service priority determines the order of task processing or response when multiple pending intents exist concurrently; for example, complaint intents have higher priority than ordinary inquiries. The service priority of each historical intent can be preset by service rules and dynamically adjusted by the dialogue strategy module. Creation time records the timestamp of the first identification and creation of the intent entry, used for task lifecycle management and timeout judgment. For example, if an intent entry is not reactivated for more than 24 hours after creation, it can be automatically cleaned up. Last active time (last_active_time) records the timestamp of the last explicit or implicit activation of the intent entry by user interaction, which can be used for timeout judgment and task sorting; the last active time can be updated when tracing or associating historical intents. Slot filling information records the filling status of required and optional slots in key-value pairs, including the specific values ​​of filled slots, the missing status of slots to be filled, and fuzzy values ​​or candidate sets when partially filled. The parent intent category indicates whether the historical intent corresponding to the intent entry is a subtask of another intent; if the parent intent category field is empty, it indicates that it is a top-level intent; if it points to an identifier of another intent entry, it indicates that it belongs to that other intent. The main line identifier identifies the dialogue main line to which the intent belongs. It can be generated when the dialogue main line is first identified, and the determined main line affiliation is subsequently persisted and reused to avoid repeated clustering calculations.

[0073] Processing states are used to identify the current lifecycle stage of a historical intent corresponding to an intent entry. The dialog manager can dynamically manage the lifecycle of historical intents based on processing states. Processing states include: Created, Active, Suspended, Resumed, Finished, and Discarded. The Created state indicates that the intent has been initialized but not yet activated; this state exists briefly after drift type determination. The Active state indicates that the intent is currently being processed and is the focus of the user's dialogue; only one intent can be in the Active state in the dialog manager. The Suspended state indicates that the intent was temporarily interrupted due to the user switching topics, but all context information is retained, and it can be reactivated by subsequent backtracking or associated operations. The Resumed state is an optional intermediate state used to mark the process of reactivating a historical intent in a suspended state; in some implementations, it can directly transition from the Suspended state to the Active state. The Finished state indicates that the intent has been successfully executed, all necessary operations have been completed, the result has been fed back to the user, and it will no longer participate in subsequent interactions. An abnormal completion status indicates that the intent was actively discarded due to timeout (such as exceeding the preset validity period) or explicit abandonment by the user. Its context will no longer be restored and will wait to be cleaned up at a specified time.

[0074] When a drift occurs, the currently active intent is updated from an active state to a suspended state, meaning it is suspended in the historical intent queue. This pauses the current active intent and preserves its context to ensure the integrity and recoverability of the task switch. After identifying the drift type of the current target intent relative to historical intents, the dialogue manager can dynamically update the state of the relevant intents based on the drift type. Specifically, when the drift type is a return drift, the first historical intent is updated from a suspended state to an active state, indicating that the first historical intent has been explicitly recalled and reactivated by the user.

[0075] When the drift type is associated drift, a new intent entry is created for the target intent. The initial state of the target intent is set to the creation state. After the new intent entry is created, the state of the target intent changes from the creation state to the active state to indicate that the target intent is being processed. Furthermore, in the intent entry of the target intent, the main line identifier of the target intent is set to the dialog main line to which it belongs, thereby explicitly associating the target intent and the second historical intent to the same dialog main line. If the target intent has a parent-child relationship with a certain historical intent, the parent intent category of the target intent in the intent entry is updated. This not only enables the correct flow of intent states, but also allows the structured association between multiple intents to be accurately traced and utilized by the subsequent dialog manager.

[0076] When the drift type is independent drift, a new intent entry is created for the target intent. The initial state of the target intent is set to the creation state. After the new intent entry is created, the state of the target intent changes from the creation state to the active state.

[0077] The underlying organizational structure of the dialogue manager in this embodiment is not limited; the specific underlying organizational structure can be flexibly selected based on system resources, performance requirements, and service complexity. This underlying organizational structure enables the dialogue manager to maintain multiple intent entries and express the transition relationships between intents, support the retrieval of suspended intents required for drift detection, and ensure that in a dialogue window with intertwined intents, it can intelligently determine which historical intents should be activated, associated, or isolated based on the drift type, ultimately achieving a multi-turn dialogue experience with coherent context, recoverable tasks, and accurate responses. By using the dialogue manager to maintain a historical task queue, the intelligent customer service robot can temporarily suspend the current task and remember to-do items, avoiding forgetting previous information due to intent switching. It can flexibly respond to frequent intent jumps by users, freely switching or retracing between multiple dialogue threads.

[0078] In one exemplary embodiment, the dialog manager is organized as an indexed list. The dialog manager maintains multiple intent entries in the historical intent queue, including: storing multiple intent entries into the indexed list according to their creation order or priority order; marking the position of the intent entries in the indexed list using a hash index; and updating the processing status of the historical intents in the multiple intent entries according to the drift type, including: locating multiple intent entries from the indexed list based on the hash index and updating the processing status of the historical intents in the multiple intent entries according to the drift type.

[0079] The dialog manager stores multiple intent entries in an indexed dynamic list structure. This structure consists of a dynamically expandable linear sequence (such as an array or linked list) and multiple auxiliary indexes to balance storage compactness with multi-dimensional query efficiency. The dynamic list stores intent entries sequentially according to their creation time, ensuring the time-series traceability of historical intents. Each intent entry is assigned a globally unique intent entry identifier upon creation. The dialog manager also maintains a hash map that records the correspondence between the intent entry identifier and its position index in the dynamic list. This allows the position index to be determined based on the intent entry identifier, enabling quick location of the intent entry in the list. This ensures that any intent entry can be located and accessed in constant time O(1), avoiding the overhead of linear scanning.

[0080] Optionally, the dialog manager can also maintain an additional set of suspended intents, where all intent entries are in a suspended state. Since the state of an intent belongs to the intent itself, and the intent entry serves as its context carrier, when the state of an intent is updated to suspended, its corresponding intent entry identifier is added to the suspended intent set; when the state changes to active, completed, or incomplete, the corresponding intent entry identifier is removed from the suspended intent set. Thus, during the drift type identification stage, this suspended intent set can be traversed to quickly retrieve historical intents in a suspended state.

[0081] Within this indexed dynamic list structure, the dialogue manager implements all operations on intent entries through an efficient data access and state update mechanism. When creating a new intent entry for a target intent, the new intent entry is appended to the end of the dynamic list, and the correspondence between the intent entry identifier and its position index in the list is recorded in the hash map table. When a return-type drift occurs and a suspended historical intent needs to be activated, the specific position of the corresponding intent entry in the dynamic list is quickly located based on the intent entry identifier through the hash map table, and then the processing status in the intent entry is updated to active. When determining the drift type, it is necessary to query the historical intents in the suspended state. At this time, the additionally maintained set of suspended intents can be directly traversed, and the corresponding intent entries can be retrieved one by one through the hash map table to extract the detailed information of the historical intents, and then consistency verification and dialogue mainline verification can be performed. In addition, to prevent invalid tasks from residing in memory for a long time, the dialog manager will periodically perform timeout cleanup: it traverses multiple intent entries in the dynamic list, and determines whether the corresponding intent has exceeded the preset validity period threshold based on the creation time and recent active time recorded for each intent entry. For intents that meet the timeout conditions and are still in the suspended state, their status is updated to abnormal completion state, and their intent entry identifier is removed from the suspended intent set; intent entries in the abnormal completion state are removed from the dialog manager in subsequent garbage collection cycles, thereby releasing resources and maintaining the timeliness and cleanliness of the dialog context.

[0082] In another exemplary embodiment, the dialogue manager organizes multiple intent entries involved in the current session into a doubly linked list structure, rather than a linear list ordered by creation time. The doubly linked list is organized based on processing priority, the priority order of which will be explained later. Its node layout is as follows: the head of the list always points to the currently active intent; middle nodes store one or more historical intents in a suspended state; the tail of the list stores the intent entry that has not been accessed for the longest time and has the lowest overall priority, which is prioritized for elimination when system resources are limited or timeouts occur. When a return-type drift is detected, the following operations are performed: locate the first historical intent node in the list; remove it from its current position and insert it at the head of the list; update the status of the first historical intent to active. The original head intent is repositioned in the list based on its priority score among historical intents and inserted into the determined position.

[0083] When an intent is completed, it is completely removed from the list. The remaining pending intents are traversed, and the one with the highest priority score is promoted to the head of the list and its status is set to active, thus achieving seamless task continuation.

[0084] In an exemplary embodiment, when the target intent enters the completed state, or when the dialog window is detected to be idle, the system actively queries the dialog manager to see if there are any historical intents in a suspended state. If there are any historical intents in a suspended state, guidance information is generated for the historical intents in a suspended state to prompt the user to continue processing the unfinished task.

[0085] When frequently switching intents, users may forget the questions they asked previously. In practical applications, it is possible to proactively detect whether there are any unfinished historical intents in a suspended state at specific times, and proactively restore and guide the intent in the dialog window, actively waking up the shelved historical intents. This proactive guidance mechanism is activated under the following two triggering conditions: the target intent enters the completed state or the dialog window is detected to be idle. Among them, the target intent entering the completed state means that the intent currently being processed has successfully executed its application logic and reached the expected endpoint, and the state of its corresponding intent is updated to normal completion. For example, if a user initiates a refund application intent, the system completes the refund review and returns the funds, and at this time the state of the intent is considered to have entered the completed state. The dialog window being idle includes any of the following situations: (1) no user input is detected within a continuous preset time period, that is, the user has not sent a new message for a long time; or (2) the user input in the current round does not identify a clear intent after natural language understanding, indicating that there is no effective task progress at present.

[0086] When any of the above triggering conditions are met, the system or device responsible for managing multi-turn dialogues proactively queries the dialogue manager to check if there are any pending historical intent entries in the historical task queue. If there are pending historical intent entries, context-aware guidance information is generated based on the detailed information of the pending historical intents to prompt the user to continue processing the unfinished task. When generating guidance information, appropriate transitional verbs can be automatically concatenated according to the context. For example, in a recap scenario after a task is completed, a transitional phrase can be used, such as "[New task] is completed. Returning to the [old task] that we didn't finish discussing earlier, the [filled slot] you mentioned..."; for a recall scenario triggered by dialogue idleness, a confirmation question can be used, such as "Regarding the [old task] we just discussed, do you still need to process it?" Placeholders such as "[New task]", "[Old task]", and "[filled slot]" are dynamically filled according to the actual content of the completed intent and the pending historical intent, ensuring that the language is natural, coherent, and the information is accurate.

[0087] The intelligent customer service robot outputs guidance information to the dialogue window. If the user responds to the guidance information, the status of the previously suspended historical intent is updated to active. If the user ignores or explicitly refuses, the intent remains suspended, waiting for the next trigger or timeout. Through this mechanism, the intelligent customer service robot has the ability to proactively guide users back to unresolved intents, rather than passively waiting for the user to remember them. This effectively improves the recall rate of unfinished tasks and the overall service loop rate in complex multi-turn dialogues. Because of its intent management and guidance capabilities, the intelligent customer service robot can handle more complex long-chain logic without getting stuck in a dead loop or logical confusion due to a user's interruption. This significantly enhances the fluency and coherence of human-computer interaction and user trust in the intelligent customer service robot, achieving a more human-like and intelligent multi-turn dialogue experience.

[0088] In an exemplary embodiment, if there are historical intents in a suspended state, guidance information is generated for the historical intent entries in the suspended state, including: if there are multiple historical intents in a suspended state, guidance information is generated sequentially for the historical intents in the suspended state according to priority order, wherein the priority order is sorted from most recent active time to oldest and / or sorted from highest to lowest service priority.

[0089] If multiple historical intents are in a suspended state, they can be processed using a priority-based sequential guidance strategy. The priority order can be dynamic, reflecting the real-time processing value of the intent in the current session. Dynamic priority can be calculated by weighting factors such as recent access time decay factor, user explicit mention intensity (e.g., using "just now," "the one before"), and slot filling progress. Alternatively, the priority order can be static, predefined according to service rules, reflecting the inherent importance of the intent type; for example, complaint and refund intents have higher priority than ordinary inquiries. The priority order can also be a combination of dynamic and static priorities. For instance, a weighted fusion of dynamic and static priorities can be used to obtain a score for each suspended historical intent, which can then be sorted in descending order of score. In this way, guidance messages can be generated first for the intent with the highest priority; if the user explicitly refuses or fails to respond within the timeout period, the next priority intent is automatically moved to the next trigger, and so on.

[0090] In other implementations, after prioritizing, the top-priority historical intents (e.g., the first 2 to 3 items) that are currently pending are organized into a structured list of options and output to the dialog window all at once for the user to choose from. For example, "You have the following unfinished items: ① Exchange request; ② Member points redemption. Please reply with the number to continue."

[0091] In summary, the method for managing multi-turn dialogues provided in this application introduces an explicit intent drift detection step, which not only focuses on the target intent of the current turn, but also determines whether the current target intent has drifted relative to the historical intents that are in a suspended state in the historical intent queue. When intent drift occurs, the specific type of intent drift is determined, providing a precise decision-making basis for subsequent differentiated dialogue management strategies. This significantly improves the sensitivity and accuracy of intent recognition and avoids semantic lag and context breakage problems when faced with sudden user interruptions, topic jumps, or task interruptions.

[0092] The system implements full lifecycle state management for each intent through a dialogue manager, defining a complete state transition path. Each intent is a stateful entity carrying a complete context, and its associated intent entries persistently store detailed information about the corresponding intent. This gives the system long-term memory and multi-tasking capabilities, breaking away from the flat, question-and-answer, one-and-go interaction model. Users can freely switch between multiple tasks, and the system can always accurately trace unfinished task nodes suspended several or even dozens of rounds ago, ensuring zero loss of contextual information. Furthermore, the system possesses proactive correction and guidance capabilities, transforming passive response into proactive service, effectively retrieving tasks forgotten by the user and achieving automatic stitching and proactive recovery of dialogue breakpoints.

[0093] The combined effect of these mechanisms enables intelligent customer service robots to exhibit intelligent behavior that more closely resembles that of human customer service representatives. They are able to robustly handle complex, long-chain logic, significantly reducing the rate of switching to human agents in practical applications, greatly improving the self-service resolution rate and user task completion rate, while enhancing the naturalness, coherence, and user satisfaction of the dialogue.

[0094] It should be noted that the execution subject of each step of the method provided in the above embodiments can be the same device, or the method can be executed by different devices. For example, the execution subject of steps 11 to 15 can be device E; or, for example, the execution subject of step 11 can be device E, and the execution subject of steps 12 to 15 can be device F, etc.

[0095] In some of the processes described in the above embodiments and accompanying drawings, multiple operations are included that appear in a specific order. However, it should be clearly understood that these operations may not be executed in the order they appear herein, or they may be executed in parallel. The sequence numbers of the operations are merely used to distinguish different operations and do not represent any execution order. Furthermore, these processes may include more or fewer operations, and these operations may be executed sequentially or in parallel. It should be noted that the descriptions such as "first," "second," etc., in this document are used to distinguish different messages, devices, modules, etc., and do not represent a sequential order, nor do they limit "first" and "second" to different types.

[0096] Figure 4 This is a schematic diagram of a device for managing multi-turn dialogues, provided as an embodiment of this application. Figure 4 As shown, the device includes: an acquisition module 41, a drift detection module 42, an intent management module 43, a drift type recognition module 44, and a dialogue processing module 45.

[0097] The acquisition module 41 is used to acquire the target dialogue content of the current round in the dialogue window and perform intent recognition on the target dialogue content to obtain the target intent; the drift detection module 42 is used to analyze whether the target intent has drifted relative to the current active intent based on the semantic relevance and dialogue coherence of the target intent and the current active intent using a drift detection model. The current active intent is the intent that was most recently confirmed to have been successfully parsed and entered the processing flow before the current round; the intent management module 43 is used to suspend the current active intent to the historical intent queue if the target intent has drifted relative to the current active intent; the drift type identification module 44 is used to identify the drift type of the target intent relative to the historical intent that is in a suspended state in the historical intent queue based on the type of the target intent and the dialogue main line using a drift type identification model; the dialogue processing module 45 is used to perform dialogue processing on the historical intent and the target intent according to the drift type, wherein different drift types correspond to different dialogue processing strategies.

[0098] The detailed implementation methods and beneficial effects of each step in this embodiment have been described in detail in the foregoing embodiments, and will not be elaborated here.

[0099] Figure 5 This is a schematic diagram of the structure of a computing device provided in an embodiment of this application. Figure 5 As shown, the computing device includes a memory 51 and a processor 52.

[0100] Memory 51 is used to store computer programs and can be configured to store various other data to support operation on the computing platform. Examples of this data include instructions for any application or method operating on the computing platform, data structures, contact data, phone book data, messages, pictures, videos, etc.

[0101] The processor 52, coupled to the memory 51, executes the computer program in the memory 51 for: acquiring the target dialogue content of the current round in the dialogue window and performing intent recognition on the target dialogue content to obtain the target intent; using a drift detection model to analyze whether the target intent has drifted relative to the current active intent based on the semantic relevance and dialogue coherence of the target intent and the current active intent, where the current active intent is the intent that was most recently successfully parsed and entered the processing flow before the current round; if the target intent has drifted relative to the current active intent, suspending the current active intent in the historical intent queue; using a drift type recognition model based on the type of the target intent and the dialogue main line to identify the drift type of the target intent relative to the historical intents that are in a suspended state in the historical intent queue; and performing dialogue processing on the historical intents and the target intent according to the drift type, wherein different drift types correspond to different dialogue processing strategies.

[0102] Furthermore, such as Figure 5 As shown, the computing device also includes other components such as a communication component 53 and a power supply component 54.

[0103] The aforementioned memory can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random-Access Memory (SRAM), Electrically Erasable Programmable Read Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0104] The aforementioned communication component is configured to facilitate wired or wireless communication between the device containing the communication component and other devices. The device containing the communication component can access wireless networks based on communication standards, such as 2G, 3G, 4G / LTE, 5G, or combinations thereof. In one exemplary embodiment, the communication component receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel.

[0105] The aforementioned power supply components provide power to various components within the device in which they reside. These power supply components may include a power management system, one or more power sources, and other components associated with generating, managing, and distributing power to the device in which they reside.

[0106] Accordingly, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, enables the processor to implement the steps in the above-described method embodiments. The computer-readable storage medium includes volatile or non-volatile components, or a combination thereof, and can be removable or non-removable. Examples of computer-readable storage media include, but are not limited to, phase-change random access memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random-access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), flash memory or other memory technologies, CD-ROM, Digital Video Disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium.

[0107] Accordingly, this application also provides a computer program product, which includes a computer program or instructions that, when executed by a processor, cause the processor to implement the steps in the above method embodiments. It should be understood that each step or combination of steps in the above method flow can be implemented by the computer program or instructions. Furthermore, these computer programs or instructions can be applied to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device, enabling the processor of the general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing device to function as an apparatus for implementing the corresponding functions in the above method embodiments.

[0108] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary hardware. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product, or it can be embodied in the process of data migration. The computer software product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, mobile terminal, server, or network device, etc.) to execute the methods described in various embodiments or some parts of the embodiments of this application.

[0109] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0110] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A method for managing multi-turn dialogues, characterized in that, include: Obtain the target dialogue content for the current round in the dialogue window, and perform intent recognition on the target dialogue content to obtain the target intent; The drift detection model is used to analyze whether the target intent has drifted relative to the current active intent based on the semantic relevance and dialogue coherence between the target intent and the current active intent. The current active intent is the intent that was most recently confirmed to have been successfully parsed and entered the processing flow before the current round. If the target intent shifts relative to the currently active intent, the currently active intent is added to the historical intent queue. The drift type identification model is used to identify the drift type of the target intent relative to the historical intents that are in a suspended state in the historical intent queue, based on the type of the target intent and the dialogue thread. Based on the drift type, dialogue processing is performed on the historical intent and the target intent, wherein different drift types correspond to different dialogue processing strategies.

2. The method according to claim 1, characterized in that, Using a drift detection model, based on the semantic relevance and dialogue coherence between the target intent and the current active intent, the analysis determines whether intent drift has occurred relative to the current active intent, including: Obtain the historical dialogue content of multiple rounds prior to the current round, as well as the slot filling information of the current active intent; The historical dialogue content, the target dialogue content, and the slot filling information are input into the drift detection model, and the following steps are performed in the drift detection model: The target dialogue content is encoded using a first encoder to obtain a target semantic vector, the historical dialogue content is encoded using a second encoder to obtain a historical context vector, and a slot completion vector is generated based on slot filling information. Based on the cross-attention mechanism, the semantic relevance vector between the historical context vector and the target semantic vector is calculated; The drift probability is obtained based on the target semantic vector, the historical context vector, the semantic relevance vector, and the slot completion vector. When the drift probability is greater than a preset threshold, it is determined that the current intent has drifted relative to the current active intent.

3. The method according to claim 2, characterized in that, Based on the cross-attention mechanism, the semantic relevance vector between the historical context vector and the target semantic vector is calculated, including: The current active vector related to the current active intent is located from the historical context vector. The target semantic vector is used as the query, and the current active vector is used as the key and value. The attention weight distribution is obtained by cross-attention calculation. Based on the focus position of the attention weight distribution in the historical dialogue segments related to the current active intent, a dialogue coherence gain factor is generated, wherein the dialogue coherence gain factor characterizes the degree of continuity of the target dialogue content with the current active intent. The semantic relevance vector is obtained by multiplying the attention weight distribution element by the dialogue coherence gain factor.

4. The method according to claim 2, characterized in that, Also includes: Using the target semantic vector as the query, and the joint representation of the historical context vector, the current active vector, the current task step identifier, and the slot completion vector as the key and value, a context vector is obtained through multi-layer cross-attention calculation; Extract discriminant features related to dialogue coherence judgment from the context vector, and map the discriminant features to a dialogue coherence vector; The process of obtaining the drift probability based on the target semantic vector, the historical context vector, the semantic relevance vector, and the slot completion vector includes: The drift probability is obtained based on the target semantic vector, the historical context vector, the semantic relevance vector, the dialogue coherence vector, and the slot completion vector.

5. The method according to any one of claims 1-4, characterized in that, The drift type identification model, based on the type of the target intent and the dialogue thread, identifies the drift type of the target intent relative to historical intents that are in a suspended state in the historical intent queue, including: A first prompt word is generated based on the details of the target intent and the details of historical intents that are in a suspended state. The details include at least: intent type, intent identifier, parent intent category, and slot filling information. The first prompt word is input into the drift type recognition model. Under the guidance of the first prompt word, the drift type recognition model uses a position-aware attention mechanism to verify the consistency of the target intent and the intent type and intent identifier of the historical intent in the suspended state, so as to obtain the consistency verification result. Based on the parent intent category and the slot filling information, the semantic association attention mechanism is used to verify whether the target intent and the historical intent in the suspended state belong to the same dialogue mainline, so as to obtain the mainline verification result. Based on the consistency verification results and the mainline verification results, the drift type of the target intent relative to the historical intent that is in a suspended state is identified.

6. The method according to claim 5, characterized in that, Based on the consistency verification results and the mainline verification results, the drift type of the target intent relative to the historical intent in the suspended state is identified, including: If there is a first historical intent with a matching consistency verification result, the drift type of the target intent relative to the historical intent in the suspended state is determined to be a return drift; If there is a second historical intent whose consistency verification result is mismatched but whose main line verification result belongs to the same dialogue main line, the drift type of the target intent relative to the historical intent in the suspended state is determined to be an associated drift. If the consistency verification result and the mainline verification result indicate that the first historical intent and the second historical intent do not exist, the drift type of the target intent relative to the historical intent in the suspended state is determined to be an independent drift.

7. The method according to claim 6, characterized in that, Based on the drift type, dialogue processing is performed on the historical intent and the target intent, including: If the drift type is a return drift, then restore the dialogue state of the first historical intent, and generate response information to continue the task flow of the first historical intent based on the target intent; If the drift type is an associated drift, then the second historical intent and the target intent are marked as collaborative subtasks, and multi-intent joint reasoning is performed on the collaborative subtasks to obtain joint response information for the current intent and for the historical intent; If the drift type is independent drift, the response information is generated based on the slot information of the target intent.

8. The method according to claim 6, characterized in that, The method further includes: The dialog manager maintains multiple intent entries in the historical intent queue. Each intent entry records detailed information about a historical intent, including its processing status, which includes at least an active state and a suspended state. The processing status of historical intents in multiple intent entries is updated according to the drift situation and the drift type. When a drift occurs, the currently active intent is updated from an active state to a suspended state. When the drift type is a return drift, the first historical intent is updated from a suspended state to an active state. When the drift type is an associated drift, a new intent entry is created for the target intent, the processing status of the target intent in the new intent entry is set to active, and the target intent is associated with the second historical intent to the same dialogue thread. When the drift type is independent drift, a new intent entry is created for the target intent, and the processing status of the target intent in the new intent entry is set to active.

9. The method according to claim 8, characterized in that, The dialogue manager is organized as an indexed list, and maintains multiple intent entries in the historical intent queue, including: Multiple intent entries are stored in the indexed list according to their creation order or priority order; The position of the intent entry in the indexed list is marked by a hash index; Update the processing status of historical intents in multiple intent entries according to the drift type, including: Based on the hash index, multiple intent entries are located from the indexed list, and the processing status of historical intents in the multiple intent entries is updated according to the drift type.

10. The method according to claim 8, characterized in that, The method further includes: When the target intent enters the completed state, or when the dialog window is detected to be idle, actively query the dialog manager to see if there are any historical intents in a suspended state. If there are pending historical intents, generate guidance information for those pending historical intents to prompt the user to continue processing the unfinished task.

11. The method according to claim 10, characterized in that, If there are any historical intents in a suspended state, guidance information is generated for those suspended historical intents, including: If there are multiple historical intents in a suspended state, guidance information is generated sequentially for the suspended historical intents according to priority order, where the priority order is sorted from the most recent active time to the oldest and / or sorted from the highest to the lowest service priority.

12. A computing device, characterized in that, include: A memory and a processor; wherein the memory stores executable code, which, when executed by the processor, causes the processor to perform the method as described in any one of claims 1 to 11.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores executable code that, when executed by a processor of a computing device, causes the processor to perform the method as described in any one of claims 1 to 11.

14. A computer program product, characterized in that, include: A computer program / instruction that, when executed by a processor, causes the processor to perform the steps of the method according to any one of claims 1 to 11.

Images