Express customer service voice robot multi-round task dialogue system based on large model

Abstract

The invention discloses an express customer service voice robot multi-round task dialogue system based on a large model, which relates to the technical field of artificial intelligence and natural language processing and comprises a dialogue domain classifier, a long and short term memory module, a sub-agent module, an information source module, a dialogue management module and a large model fine tuning and data support module. The dialogue domain classifier is used for routing user query to the corresponding sub-agent module; and the long-short-term memory module is used for constructing a layered persistent memory mechanism. According to the express customer service voice robot multi-round task dialogue system based on the large model, by introducing the large language model, accurate understanding of fuzzy and spoken expression of a user is achieved, the generalization ability of intention recognition is enhanced, a multi-level memory mechanism is adopted, continuity and stability of a dialogue state are ensured, and the dialogue efficiency is improved. Even if the user jumps or asks a question, the smoothness of the conversation can be kept, and the maintenance cost is greatly reduced.

Description

Technical Field

[0001] This invention relates to the fields of artificial intelligence and natural language processing technology, specifically to a multi-turn task dialogue system for a courier customer service voice robot based on a large model. Background Technology

[0002] As the express delivery industry continues to expand, users' demands for the immediacy and convenience of services such as express delivery tracking, order placement, address modification, and complaint handling are constantly increasing. Intelligent customer service systems are gradually becoming a crucial support for express delivery companies to improve service efficiency and reduce labor costs. Currently, the application of natural language processing technology in the field of intelligent customer service is deepening, especially the powerful semantic understanding and generation capabilities demonstrated by Large Language Models (LLM). This provides a new technical direction for solving complex multi-turn task-oriented dialogue scenarios, driving express delivery customer service to evolve from traditional single-interaction to more natural and coherent multi-turn task processing, helping companies better cope with massive user inquiries and diverse business needs.

[0003] In current technological practices, intelligent customer service systems in the express delivery industry still have several aspects that need optimization: Intent recognition schemes based on traditional models have limited adaptability to users' ambiguous and colloquial expressions, making it difficult to fully cover the diverse user expressions in real-world scenarios; dialogue management mechanisms often rely on fixed logical architectures, resulting in insufficient flexibility and continuity when handling situations such as skipping steps or asking rhetorical questions in natural user interactions; when adding new business scenarios, the system needs to adjust relevant logic and tagging systems, making the maintenance process relatively complex and time-consuming. Furthermore, although large language models possess excellent semantic understanding capabilities, they still need further improvement in adapting to specific business logic, ensuring the controllability of response generation processes, and optimizing response timeliness to better meet the needs of actual business scenarios. To address these issues, we propose a multi-turn task dialogue system for express delivery customer service voice robots based on a large model. Summary of the Invention

[0004] To address the aforementioned technical challenges, a multi-turn task dialogue system for express customer service voice robots based on a large model is provided. This technical solution resolves the issues raised above, such as the difficulty of adapting traditional intent recognition to users' ambiguous and colloquial expressions; the reliance on fixed architectures in dialogue management leading to insufficient flexibility and continuity when handling user skipping steps or asking questions; the need to adjust logic and tagging systems for new business applications, resulting in complex and time-consuming maintenance; and the need for improvement in adapting the large model to enterprise business logic, ensuring controllable response, and optimizing timeliness.

[0005] To achieve the above objectives, the technical solution adopted by the present invention is as follows: The express delivery customer service voice robot multi-turn task dialogue system based on a large model includes: dialogue domain classifier, long short-term memory module, sub-agent module, information source module, dialogue management module, and large model fine-tuning and data support module; The dialogue domain classifier is used to route user queries to the corresponding sub-agent modules; The long short-term memory module is used to construct a hierarchical persistent memory mechanism, store and dynamically update dialogue state information, and inject the dialogue state information into the prompt words of the large model. The sub-agent module is used to combine the external resources of the information source module with the status management function of the dialogue management module to process express delivery business; The information source module is used to provide external resources required for express delivery services, and the dialogue management module is used to manage dialogue status and dialogue flow. The large model fine-tuning and data support module includes a dataset construction pipeline and a large model supervised fine-tuning strategy, providing high-quality data support for the semantic understanding and response generation of large models; and achieves inference optimization through hierarchical structured Prompt design, context compression, and Prompt caching mechanisms. The system uses a predefined dialogue flow as the core to drive the express delivery business logic. The dialogue flow includes a sequence of steps to complete a preset express delivery task and the corresponding dialogue state. The dialogue state includes the slot information required for the task and the dialogue flow jump conditions. It is also configured with a dialogue rewriting model to rewrite the user's current input and historical dialogue context into a semantically complete query.

[0006] Preferably, the dialogue domain classifier is a composite routing module that includes preprocessing, retrieval filtering, and fine-ranking determination, and the specific process is as follows: Construct a vector index covering all express delivery business dialogue domains. This vector index stores typical query texts and domain function description texts for each dialogue domain. All texts are converted into high-dimensional vectors through the Embedding model. After receiving a user query, the dialogue domain classifier encodes the user query text into a query vector using the same embedding model. It then performs Top-K similarity retrieval in the vector index to filter out a preset number of candidate domains that have the highest semantic relevance to the query vector, forming a candidate domain list. The dialogue domain classifier integrates the user query text, the functional description text of each candidate domain in the candidate domain list, and the context text of the current dialogue into fine-ranking input data, and feeds the fine-ranking input data into the fine-ranking model; the fine-ranking model scores each candidate domain based on two dimensions: semantic matching degree and relevance to the express delivery business scenario, and generates a comprehensive score for each candidate domain; The dialogue domain classifier selects the candidate domain with the highest comprehensive score as the final classification result and routes the user query to the sub-agent module corresponding to that candidate domain.

[0007] Preferably, the hierarchical persistent memory mechanism of the long short-term memory module includes three memory types: working memory, semantic memory, and workflow memory. The working memory stores recent dialogue data within the current dialogue session. The recent dialogue data includes the user's input text for each round, the system's output text for each round, and the dialogue round identifier. The storage range of the recent dialogue data is limited to covering the context associated with the current task. Semantic memory exists in the form of a combination of a knowledge base and a vector database. The knowledge base stores general knowledge, business rules and service standards of the express delivery industry, while the vector database stores structured business fact data. The workflow memory stores the standardized operating procedures corresponding to each express delivery business. The standardized operating procedures clearly define the order of business processing steps, the slot information required for each step, and the step jump conditions. The Long Short-Term Memory (LSTM) module also features state extraction, state maintenance and update, and state retrieval application functions: the state extraction function uses natural language understanding technology to identify and extract key entities and user intents from user input text and system output text, converting them into structured state fragments; the state maintenance and update function manages state fragments, including adding non-existent state fragments, modifying user-corrected state fragments, and marking expired state fragments that have exceeded their business time limit; the state retrieval application function retrieves relevant state information from the three memory types based on the task type of the current dialogue and the semantics of user input, integrates it according to a preset format, and injects it into the prompt words of the large model.

[0008] Preferably, the long short-term memory module's long-term memory injection process is as follows: The long short-term memory module connects to the persistent storage system through a data interface. The storage system stores the user's historical business data and dialogue status, including the user's past express delivery business records, user preference information, and slot information for unfinished tasks. When a user initiates a new conversation or enters a preset business process, the long short-term memory module queries the storage system for historical data related to the current user and the current task based on the user identifier. The query conditions include the user identifier and the business type. The Long Short-Term Memory module performs structured processing on the retrieved historical data, organizing entity data into key-value pairs of entity type: entity value, and process data into the format of process status: description text; The Long Short-Term Memory (LSTM) module injects structured long-term memory information into the Prompt of the large model, and the injection position is located before the user's current input text.

[0009] Preferably, the sub-agent module includes a FAQ Agent, a Workflow Agent, and a Common Agent; FAQ Agent is used to handle frequently asked questions in the express delivery industry that have fixed answers. The specific implementation is as follows: A pre-built FAQ vector database stores the text of all frequently asked questions and their corresponding standard answers. The text of each frequently asked question is converted into a vector using an embedding model. Upon receiving a user query routed to the Agent, the FAQ Agent converts the user's query text into a query vector and performs a nearest neighbor search in the FAQ vector database, calculating the similarity between the query vector and each question vector in the database. If the highest similarity value exceeds a preset confidence threshold, the standard answer text corresponding to that highest similarity value is directly retrieved and returned to the user. If the highest similarity value does not exceed the confidence threshold, the user query is redirected to another adapted sub-agent module. Workflow Agents are used to handle express delivery tasks that require multiple steps. Each Workflow Agent corresponds to a specific express delivery task and has a built-in dialog flow for that task. When a Workflow Agent runs, it first obtains the current dialog state information through the Long Short-Term Memory module and determines whether the collected slot information meets the requirements of the current step. If the slot information is missing, a slot query response is generated to guide the user to supplement the information. If the slot information is complete, the next business step is entered according to the dialog flow jump conditions, or when external resources need to be called, the corresponding external API interface is called through the information source module to obtain business data and generate a response. The Common Agent serves as a fallback module, handling queries that cannot be covered by the FAQ Agent or Workflow Agent. The Common Agent connects to a general-purpose model fine-tuned for express delivery customer service scenarios. This model generates responses based on pre-trained natural language understanding capabilities and fine-tuned business adaptability.

[0010] Preferably, the large model supervised fine-tuning strategy in the large model fine-tuning and data support module includes: prioritizing data quality, iterative data construction, and balancing Prompt and Response. The data quality priority strategy requires that when screening and supervising fine-tuning data, priority should be given to retaining real and valid dialogue data in the express delivery customer service scenario, and removing noisy data containing erroneous business information, semantic ambiguity, and repetitive redundancy. The iterative data construction strategy includes: initially using a small amount of high-quality seed data to fine-tune the large model; after fine-tuning, building a test set and evaluating the model performance using three metrics: intent recognition accuracy, entity extraction accuracy, and response relevance; if the evaluation results are satisfactory, expanding the dataset based on the seed data and using semi-automated annotation tools; if the evaluation results are unsatisfactory, backtracking to analyze issues with data quality, prompt design, or parameter fine-tuning, adjusting and re-fine-tuning and evaluating until the model performance meets the requirements. The Prompt and Response balancing strategy requires that training data cover different ways users express themselves in actual conversations; and ensure that responses to similar Prompts and contexts remain convergent, with core business information consistent.

[0011] Preferably, the dataset construction pipeline in the large model fine-tuning and data support module includes the following steps: Raw data is collected from historical dialogue logs of express customer service, business operation manuals, and FAQ documents; the raw data is cleaned, duplicate dialogue records are removed by hash deduplication algorithm, text containing sensitive information is filtered by regular expression, and idle chat text that is not related to business is removed by manual screening, and unstructured text is converted into a structured format of user input-system response. Develop guidelines covering Prompt annotation, Response annotation, and entity annotation, clarifying the intent to be annotated in Prompt, the business basis to be annotated in Response, and the type to be annotated in Entity, while also specifying the operating procedures and quality inspection standards for annotation personnel; The unlabeled data is preprocessed using a large model that has undergone preliminary fine-tuning. The large model annotates the user input text with intent and entities, and generates an initial response to the system response text. The annotators review the preprocessing results, correcting issues such as mislabeled intents, missing entities, and inappropriate response expressions, and supplementing implicit needs that the model has not recognized. Samples from complex scenarios in the express delivery business were manually annotated. Annotators analyzed the semantics of the samples sentence by sentence to ensure the accuracy of the annotation of intent, entities and responses, thus forming a high-quality seed dataset. The number of prompts is increased by employing back-translation, synonym substitution, and syntactic conversion techniques while maintaining semantic integrity. The quality of the dataset is evaluated by calculating the label consistency coefficient and statistical error rate. The evaluation results are fed back to the previous steps. If the error rate of a certain type of sample is high, the labeling specifications are adjusted. If the data for a certain business scenario is insufficient, supplementary data collection is carried out.

[0012] Preferably, the reasoning optimization includes a hierarchical structured Prompt design and a short-term dialogue memory management mechanism, specifically implemented as follows: The hierarchical structured Prompt consists of two parts: system prompts and dynamic context prompts. The system prompts are located at the beginning of the Prompt and clearly define the role, behavior guidelines, output format, and general standardized operating procedures of the large model. The dynamic context prompts are located after the system prompts and contain the user's current input text and processed short-term dialogue memory information. Short-term dialogue memory management is achieved through a sliding window and a summarization mechanism: the sliding window sets a fixed upper limit on the number of dialogue turns, retaining only a preset number of dialogue turns before the current turn as the memory within the window, while old dialogue turns exceeding the window are removed from the immediate memory; for old dialogues exceeding the sliding window, the system calls a small summarization model to summarize them, extract key information, and integrate the key information into summary text; the system uses the dialogue history within the window and the summary text together as short-term dialogue memory information, and incorporates dynamic contextual prompts.

[0013] Preferably, the reasoning optimization optimizes memory management during the reasoning process by maximizing the compression of contextual information entropy and maintaining contextual locality, specifically as follows: Context information entropy maximization compression is achieved through hierarchical summarization and entity structure extraction, specifically: Hierarchical summarization processes historical dialogues hierarchically according to the importance of each dialogue turn. For core turns containing key entities, detailed summaries are extracted from the user input intent and the core content of the system response. For non-core turns, only the dialogue topic is extracted as a brief summary. Entity structure extraction identifies and extracts core entities from all dialogue turns, storing entity types and corresponding values ​​in tabular form to replace entity descriptions in natural language. The compressed summaries, structured entities, and original dialogue history are associated and stored with unique identifiers. When the large model's response generation depends on the details of the original dialogue, the original text can be retrieved by backtracking through the identifiers. Context locality maintenance prioritizes retaining neighboring dialogue content that is directly related to the current task, while filtering out historical information that is irrelevant to the current task, based on the task focus of the current dialogue.

[0014] Preferably, the Prompt caching mechanism in inference optimization has a two-layer structure, including a global system prompt word cache and a session-level user prompt word cache: The global system prompt word cache is used to store the fixed common parts of the Prompt, that is, the content of the system prompt words that is common to all user sessions. When the system is first started or the system prompt words are updated, the fixed common parts are input into the large model inference engine to complete the tokenization process and KV Cache calculation, and the calculation result is stored in the global cache pool. When all subsequent user sessions call the large model, they directly reuse the calculation result from the global cache pool. The session-level user prompt word cache creates an independent cache space for each user session, storing the processing results of the user's historical input within that session, including the user's input text, extracted entity information, dialogue status, and a summary of the system response. When a user enters a similar query or mentions historical information in the same session, the system directly retrieves the corresponding entity information and dialogue status from the session cache without needing to process it repeatedly.

[0015] Compared with the prior art, the beneficial effects of the present invention are as follows: This invention proposes a multi-turn task dialogue system for express delivery customer service voice robots based on a large model. By introducing a large language model, it achieves accurate understanding of users' ambiguous and colloquial expressions, enhancing the generalization ability of intent recognition. Employing a multi-level memory mechanism ensures the continuity and stability of the dialogue state, maintaining fluency even when users skip steps or ask questions. The highly modular design of the system architecture makes adding and modifying new business processes more flexible and convenient, significantly reducing maintenance costs. By combining structured processing of contextual information with a Prompt optimization strategy, it effectively improves the response speed and accuracy of the large model, making the generated responses more tailored to user needs. This system transforms express delivery customer service from single-interaction to natural, coherent multi-turn task processing, improving service efficiency and user satisfaction. Attached Figure Description

[0016] Figure 1 This is a system framework diagram of the present invention; Figure 2 A flowchart for constructing the dataset of this invention is provided. Detailed Implementation

[0017] The following description is intended to disclose the invention and enable those skilled in the art to implement it. The preferred embodiments described below are merely examples, and other obvious variations will occur to those skilled in the art.

[0018] This multi-turn task dialogue system for express delivery customer service voice robots, based on a large model, uses a dialogue flow as the core to drive the express delivery business logic. The dialogue flow is a sequence of steps designed to complete a specific express delivery task. Each step specifies the required dialogue state, which includes the slot information necessary for task execution and the key conditions controlling the dialogue flow transition. Slot information is designed based on specific business scenario requirements. For example, an express delivery query task requires slots such as the order number and the recipient's mobile phone number. These slots are derived from common business processes in the express delivery industry, ensuring that all necessary information for task completion is covered. Transition conditions are determined based on business rules and user interaction logic. For instance, when the user provides a complete order number and recipient's mobile phone number, meaning all required slot information has been collected, the condition for transitioning from the information collection step to the query execution step is met. If slot information is missing, a slot supplementation step is triggered. The execution flow of the dialogue flow in the system is as follows: when a user initiates a business request, the dialogue management module loads the corresponding business dialogue flow based on the results of the dialogue domain classifier. Combining the dialogue status obtained by the long short-term memory module, it determines the current step. If the slot information is complete, the business operation is executed step by step. If it is missing, the user is guided to supplement the information through the sub-agent module. At the same time, the dialogue status is updated in real time to ensure that the dialogue flow proceeds according to the preset logic.

[0019] The system possesses context-aware deep dialogue understanding capabilities. Unlike traditional NLU's isolated understanding of single sentences, this system employs a dialogue rewriting model to achieve this functionality. The dialogue rewriting model uses a Transformer-based sequence generation model, comprising an encoder and a decoder. The encoder processes the user's current input and historical dialogue context, while the decoder generates semantically complete query text. Training data comes from annotated multi-turn dialogue data related to express delivery. Each data point includes the user's current input, historical dialogue context, and the annotated result of the semantically complete query. For example, if the historical dialogue context is "User: Check express delivery; System: Please provide order number; User: 123456789", the user's current input is "123456789", and the annotated result of the semantically complete query is "I want to check the express delivery status of order number 123456789". The model training uses the cross-entropy loss function, the Adam optimizer, a learning rate of 3e-5, and five training epochs. After training, the accuracy of generating semantically complete queries reaches over 90%. The workflow involves receiving the user's current input and the historical dialogue context retrieved from the working memory of the Long Short-Term Memory module. After concatenation, the input is fed into the encoder to obtain a contextual semantic representation. The decoder then generates a semantically complete query containing necessary historical information based on this representation. This query is used for subsequent retrieval by the dialogue domain classifier and semantic understanding of the large model, ensuring that the dialogue is accurately routed to the correct dialogue stream.

[0020] To ensure the stability and continuity of task-oriented multi-turn dialogues, this system employs a layered, persistent long short-term memory (LSTM) mechanism to support context management and state tracking for large models. The LTM module's layered persistent memory mechanism includes working memory, semantic memory, and workflow memory. Working memory stores recent dialogue data within the current session, including user input text for each turn, system output text for each turn, and dialogue turn identifiers. The storage range is set to retain the most recent 10 turns. This upper limit is determined based on the common length of multi-turn dialogues in the express delivery business; most express delivery dialogues can be completed within 10 turns. Dialogues exceeding 10 turns have reduced relevance, and retaining 10 turns satisfies context understanding requirements while avoiding excessive memory consumption. Working memory uses a first-in, first-out (FIFO) mechanism; when the dialogue exceeds 10 turns, the earliest turn is automatically removed, and the turn identifier is updated in real time to ensure the data is up-to-date and relevant.

[0021] Semantic memory exists in the form of a combination of a knowledge base and a vector database. The knowledge base stores general knowledge, business rules, and service standards for the express delivery industry, using a structured knowledge graph format. Nodes include express delivery business terminology, service processes, and policy regulations, while edges represent the relationships between nodes. For example, the "Express Delivery Address Change" node is linked to the "Address Change Deadline (Before Recipient Signs)" node through an edge that includes the time limit requirement. The knowledge base is updated monthly, with updated data sourced from the latest rules and industry standards published by the business departments of express delivery companies. Updates are manually reviewed before being updated to ensure accuracy. The vector database stores structured business factual data, such as network information and express delivery fee standards for various express delivery companies. It is built using the FAISS framework, with IVF SQ8 index type to achieve a balance between retrieval speed and storage cost. Queries use approximate nearest neighbor queries, with response time controlled within 100ms to meet real-time dialogue requirements.

[0022] The workflow memory stores standardized operating procedures for each express delivery service. These procedures are derived from the actual business process documents of express delivery companies and have been structured and formatted into JSON format by the technical team. They include fields such as service name, step list, slot requirements, and jump conditions. For example, in the standardized operating procedure for the "express delivery address change" service, the step list includes verifying user identity, obtaining the original delivery address, obtaining the new delivery address, confirming the address change fee, and submitting the address change application. The slot requirements for each step are clearly defined. For example, the "verify user identity" step requires the "order number" and "recipient's mobile phone number" slots. Jump conditions include "proceed to the next step if the slot information is complete" and "terminate the process if the user refuses to provide information," providing clear execution guidance for the large model.

[0023] The Long Short-Term Memory (LSTM) module has functions for state extraction, state maintenance and updating, and state retrieval applications. The state extraction function is implemented using a BERT-based sequence labeling model. This model has been fine-tuned using express delivery customer service corpora and employs the BIO labeling system to identify key entities. It outputs user intent through a classification layer. The training data comes from labeled customer service dialogue text, achieving an entity labeling accuracy of over 95% and an intent recognition accuracy of over 92%. The extracted key entities and intents are converted into structured state fragments in the format "Entity Type: Entity Value, Intent Type: Intent Value," such as "Order Number: 123456789, Intent Type: Express Delivery Inquiry."

[0024] The status maintenance and update function manages status fragments. Adding a new operation applies to entities or intents extracted for the first time; modifying an operation applies to information corrected by the user. For example, if a user initially provides an incorrect order number "987654321" and later corrects it to "123456789", the system will update the order number in the original status fragment with the new value and record the update time; marking expired is based on business timeliness. For example, after a package is signed for, status fragments related to that package, such as address changes and queries, are automatically marked as expired. Expired fragments are not included in subsequent searches, ensuring that the status is accurate and up-to-date.

[0025] The state retrieval application retrieves relevant information from three memory types based on the current dialogue task type and user input semantics. During retrieval, the task type is first determined, then relevant dialogue data is retrieved from working memory based on user-input keywords, business rules are retrieved from semantic memory, and operational procedures are retrieved from workflow memory. The retrieved information is integrated into a large model prompt in the format: "[Working Memory Information]: The user recently entered order number 123456789, and the system previously prompted that the recipient's mobile phone number is required; [Semantic Memory Information]: Express delivery inquiry requires verification of the order number and the recipient's mobile phone number; [Workflow Memory Information]: The current step in express delivery inquiry is to verify user identity, requiring the order number and the recipient's mobile phone number slots." This information supports response generation.

[0026] The long-term memory injection process of the Long Short-Term Memory (LSTM) module connects to the persistent storage system via a RESTful API data interface. The interface uses HTTPS for security, and parameters include user identifiers and business types. The response format is JSON. The persistent storage system employs a combined MySQL and Redis architecture. MySQL stores historical user business data and conversation states, while Redis caches frequently accessed data to improve query speed.

[0027] When a user initiates a new conversation or enters a preset business process, the Long Short-Term Memory (LSTM) module queries relevant historical data from the storage system based on the user's identifier. Query conditions include exact matching of the user identifier and fuzzy matching of the business type. For example, if the current task is a courier address change, the system queries all past address change records for that user, as well as information on unfinished address change task slots. The query first retrieves data from the Redis cache; if a match is found, it is used directly; otherwise, it queries from MySQL and synchronizes the data to Redis. The cache is valid for 24 hours to reduce database pressure.

[0028] The retrieved historical data is structured. Entity data is organized into key-value pairs of "entity type: entity value", such as "order number: 123456789, recipient's mobile number: xxxxxxx". Process data is organized into "process status: description text" format, such as "process status: the courier address change task has completed identity verification and is awaiting the acquisition of a new delivery address". The structured long-term memory information is injected into the large model's Prompt, and it is placed before the user's current input text. For example, if the user currently enters "help me change my address", the injected long-term memory information is "[Long-term memory information]: The user has previously processed a courier address change, historical order number 123456789, the address change task has not been completed and a new delivery address needs to be added." The complete Prompt is "[System prompt]... [Long-term memory information]: The user has previously processed a courier address change, historical order number 123456789, the address change task has not been completed and a new delivery address needs to be added. [User's current input]: help me change my address", ensuring that the large model prioritizes obtaining historical context and better understands the user's intent.

[0029] refer to Figure 1 As shown, the overall architecture of this system consists of a dialogue domain classifier, a long short-term memory module, a sub-agent module, an information source module, and a dialogue management module.

[0030] The dialogue domain classifier, as the core routing component, is a composite intelligent routing system that includes preprocessing, multi-level classification, and retrieval re-ranking mechanisms. When constructing the vector index, it uses an embedding model fine-tuned from the express delivery customer service corpus, with a word vector dimension of 768 dimensions to balance semantic expression and computational efficiency. The vector index stores typical query texts and domain function description texts for each express delivery business dialogue domain. Typical query texts are derived from high-frequency user queries in historical dialogue logs, such as "How do I check my express delivery?" and "I want to change my delivery address." The domain function description texts define the business scope of each dialogue domain, such as "Express delivery query domain: Handling user queries about express delivery status and estimated delivery time." These texts are first preprocessed to remove special characters and unify the format, then encoded into high-dimensional vectors by the embedding model and stored in a vector database that supports efficient similarity queries. The IVF FLAT index structure improves retrieval speed.

[0031] After receiving a user query, the query text is preprocessed and then encoded into a query vector. Top-K similarity retrieval is performed in the vector index, using cosine similarity calculation. The Top-K value is set to 5, a value determined experimentally to balance retrieval accuracy and efficiency. After selecting five candidate domains to form a list, the user query text, the functional description text of each candidate domain, and the context text from the last three rounds are integrated into the fine-tuning input data. The fine-tuning model adopts a Transformer-based binary classification architecture. The training data comes from labeled customer service dialogue data. Scoring is based on two dimensions: semantic matching degree and business scenario relevance, with weights of 0.6 and 0.4 respectively. The comprehensive score is calculated as a weighted sum of the scores from the two dimensions. The candidate domain with the highest comprehensive score is selected as the result. If the highest score is below the 0.7 threshold, routing is performed to the Common Agent to ensure classification credibility.

[0032] The sub-agent module adopts a modular architecture and follows the single responsibility principle. The main system routes queries to the appropriate sub-agent based on the results of the dialogue domain classifier.

[0033] The FAQ Agent handles frequently asked questions with fixed answers. It pre-builds an FAQ vector database, with common questions originating from those repeated more than 50 times in historical dialogues, such as "What should I do if my package is lost?" and "How long will it take for my package to arrive?". The standard answers are provided by the company's customer service department to ensure authority. In building the FAQ vector database, the question text is preprocessed and converted into vectors using the same embedding model as the dialogue domain classifier. Storage is done using the Milvus vector database, and the HNSW index supports efficient searching. Upon receiving a query, the query text is preprocessed and encoded into a vector. Euclidean distance is used to calculate similarity. If the highest similarity exceeds the 0.85 confidence threshold, the standard answer is retrieved; otherwise, the query is forwarded to another adapted agent. Context synchronization is used during the forwarding process to ensure coherence.

[0034] Workflow Agents handle multi-step express delivery tasks. Each Agent corresponds to a specific business and has a built-in dialogue flow. The dialogue flow is designed based on enterprise business process specifications, including step sequences, slot requirements, and jump conditions. For example, the dialogue flow steps for the "Place an Express Order" business are "Get Sender Information," "Get Recipient Information," "Get Express Item Information," "Confirm Shipping Fee," and "Submit Order Request." The slot requirements for each step are clearly defined. At runtime, the dialogue state is first obtained through the Long Short-Term Memory (LSTM) module to determine whether the slot information meets the requirements of the current step, based on the step slot list. If missing, a templated query response combining natural language is generated to guide the completion. For example, if the "Sender Address" slot is missing, the response would be "To help you complete your express order, please provide your sender address, thank you." If complete, the process proceeds to the next step according to the jump conditions. When external resources need to be called, the API is called through the information source module, with a synchronous call timeout of 3 seconds. If the timeout occurs, a busy message is displayed. After obtaining the data, a response is generated, such as "Based on the sender and recipient addresses you provided, the shipping fee for this express order is 12 yuan. Do you want to confirm the order?"

[0035] The Common Agent serves as a fallback module, handling queries that cannot be covered by other agents. It connects to a general-purpose model fine-tuned for courier customer service scenarios. The base model is a moderately sized pre-trained model, and the fine-tuning data comes from dialogue data that cannot be processed by other agents. The batch size for fine-tuning is 16, the learning rate is 2e-5, and the training epochs are 3. Response generation adheres to the principles of friendliness, professionalism, and staying within the scope of business needs. For questions that cannot be answered, a response such as "I'm sorry, I can only provide you with courier-related services at this time. If you have any questions about courier services, please feel free to contact me" is generated, ensuring consistency with the system's positioning.

[0036] The information source module provides external resources required for express delivery services, including logistics query APIs, freight calculation APIs, branch information query APIs, and order management APIs from express delivery companies. It also includes static resources such as knowledge bases and policy / regulatory documents for the express delivery industry. External API access uses the RESTful API protocol and JSON data format, with API key authentication ensuring security. Static resources are integrated into structured databases or document libraries; for example, policy / regulatory documents are converted to PDF format for storage and indexed for easy retrieval. The module has interface monitoring capabilities, monitoring metrics such as call success rate and response time in real time. When the call success rate falls below 95% or the response time exceeds 3 seconds, an alarm mechanism is triggered to notify technical personnel to investigate the problem and ensure the stable availability of external resources.

[0037] The dialogue management module manages dialogue states and flow using a state machine design. Each state corresponds to a step in the dialogue flow, and transitions are controlled by jump conditions. Dialogue states include the current step identifier, collected slot information, user identifier, and dialogue start time, stored in a long short-term memory (LSTM) module and a persistent system. The module retrieves updated states by calling the LSM module interface. Dialogue flow management includes loading, execution, and termination. Upon user request, the corresponding dialogue flow is loaded, progress is updated in real-time during the dialogue, and recording stops upon completion. State storage is paused when the user ends or a timeout (set to 5 minutes) occurs. The module also has exception handling capabilities; when slot information is invalid, a prompt is generated to guide re-entry, ensuring dialogue flow stability.

[0038] refer to Figure 2 As shown, the large-scale model fine-tuning and data support module includes a dataset construction pipeline and a large-scale model supervised fine-tuning strategy. The first step in the dataset construction pipeline is the collection and cleaning of raw data. The data comes from historical dialogue logs of express customer service, business operation manuals, and FAQ documents. The historical dialogue logs cover customer service dialogue data from the past year, the business operation manuals are provided by the express company, and the FAQ documents contain compiled common questions and standard answers. Cleaning is performed by deduplicating data using the MD5 hash algorithm. The MD5 value is calculated for the concatenated text of user input and system output for each dialogue record, and duplicates are deleted. Sensitive information is filtered using regular expressions, matching patterns such as mobile phone numbers and ID card numbers and replacing them with "*". Irrelevant chatter is manually removed, based on whether it involves express business. Finally, the data is converted into a structured format of "User Input: XXX, System Response: XXX".

[0039] The second step is to develop annotation guidelines, covering detailed annotation rules for Prompt, Response, and entity annotations. Prompt annotations must indicate the intent type, such as express delivery inquiry or order placement; Response annotations must indicate the business basis; entity annotations must indicate the entity type, including order number and recipient name. Annotators participate after receiving training and passing the qualification test. The quality inspection standard is a Kappa coefficient greater than 0.85 to ensure consistent and high-quality annotations.

[0040] The third step involves semi-automated annotation based on a large model. This model, which is pre-tuned using a pre-trained model and fine-tuned with a small amount of labeled seed data, achieves an accuracy rate of over 85% for intent annotation and over 88% for entity annotation. Annotators then review and correct the data, adding any implicit requirements to ensure data quality.

[0041] The fourth step involves manual fine-labeling of a small amount of seed data. Complex scenario samples are selected, such as mixed intentions and ambiguous expressions. The labelers analyze and label each sentence to form 1,000 high-quality seed data, balancing training needs and labeling costs.

[0042] The fifth step is data augmentation, which uses Chinese-English-Chinese back-translation, industry terminology synonym replacement, and syntactic conversion techniques to expand the number of Prompts to three times the original amount, thereby improving the robustness of the model.

[0043] The sixth step is iterative quality assessment and feedback. The Kappa coefficient and error rate are calculated to assess quality. A Kappa coefficient greater than 0.85 indicates consistent labeling. The error rate is calculated as (number of erroneous samples / total number of samples) × 100%, and each error rate must be below 5%. Results are fed back to the preceding steps. If the error rate is high, the labeling specifications are adjusted; if data is insufficient, additional data is collected, forming a closed loop.

[0044] The data quality-first strategy of the large model supervised fine-tuning strategy retains real and valid dialogue data, removes erroneous business information, semantic ambiguity, and duplicate and redundant data, and avoids low-quality data from affecting training.

[0045] The iterative data construction strategy initially uses 1000 seed data points for fine-tuning, with a batch size of 8, a learning rate of 1e-5, two training epochs, and the AdamW optimizer. After fine-tuning, a test set of 500 data points is built, and the results are evaluated based on intent recognition accuracy, entity extraction accuracy, and response relevance. The target for intent recognition accuracy is 90%, the target for entity extraction accuracy is 92%, and the target for response relevance in manual evaluation is an average score of 4 or higher. If the targets are met, the data is expanded using tools, adding 2000 data points each time; if the targets are not met, adjustments are made backtracking until the requirements are met.

[0046] The Prompt and Response balancing strategy requires covering various user expression styles, including formal, colloquial, concise, and vague expressions; ensuring convergence of similar Prompts and contextual Responses, consistency of core business information, accelerating model convergence, and improving stability.

[0047] Inference optimization is achieved through a hierarchical structured Prompt design, a short-term dialogue memory management mechanism, maximizing contextual information entropy compression, maintaining contextual locality, and a Prompt caching mechanism. The hierarchical structured Prompt consists of two parts: system prompts and dynamic context prompts. The system prompts are located at the beginning, clearly identifying the user as a courier customer service voice robot, with behavioral guidelines including accurate and professional responses, and output format requirements such as clear bullet points or inclusion of key information, and general operating procedures including identity verification first. The dynamic context prompts are located afterward, containing the user's current input and processed short-term dialogue memory information, such as "[Short-term dialogue memory]: The user previously provided order number 123456789, but did not provide the recipient's mobile phone number; [User's current input]: I forgot to mention the recipient's mobile phone number is xxxxxxxx."

[0048] The short-term dialogue memory management sliding window is set to an upper limit of 8 rounds. This number of rounds was determined through experiments. The old dialogue in the super window calls the T5-small model summary to extract and integrate key information. Dynamic prompt words are incorporated into the dialogue and summary in the window to ensure that the large model obtains the complete context.

[0049] Contextual information entropy is maximized to compress hierarchical summaries based on importance. Core rounds extract intent and core response content, while non-core rounds extract topics. Entity structure extraction extracts core entities and stores them in a table format: "|Entity Type|Entity Value|". Compressed information is associated with the original text via round IDs, allowing for backtracking when details are needed to ensure completeness.

[0050] Context locality maintenance prioritizes retaining relevant neighbor dialogues and filters out irrelevant historical information based on the current task focus, ensuring that the large model focuses on the current task.

[0051] The Prompt caching mechanism has a two-layer structure. The global system prompt cache stores the system prompts common to all sessions. When the system is first started or updated, the input inference engine completes tokenization and KV cache calculation and stores them in the Redis database for subsequent reuse to reduce computation. The session-level user prompt cache establishes an independent space for each session, identified by a session ID, and stores the user's historical input processing results. When the user mentions historical information in the session, it is directly retrieved to reduce redundant processing and improve speed.

[0052] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely principles of the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the claimed invention. The scope of protection claimed by the appended claims and their equivalents is defined.

Claims

1. A large model-based express customer service voice robot multi-turn task dialogue system, characterized in that, Comprise: A dialogue domain classifier, a long short-term memory module, a sub-agent module, an information source module, a dialogue management module, and a large model fine-tuning and data support module; The dialogue domain classifier is used to route user queries to corresponding sub-agent modules; The long short-term memory module is used to build a hierarchical persistent memory mechanism, store and dynamically update dialogue state information, and inject dialogue state information into the prompt words of the large model; The sub-agent module is used to combine the external resources of the information source module and the state management function of the dialogue management module to handle express business; The information source module is used to provide external resources required for express business, and the dialogue management module is used to manage dialogue state and dialogue flow; The large model fine-tuning and data support module includes a data set construction Pipeline and a large model supervised fine-tuning strategy to provide high-quality data support for semantic understanding and response generation of the large model; and reasoning optimization is realized through hierarchical structured Prompt design, context compression and Prompt caching mechanism; The system drives the express business logic with a predefined dialogue flow as the core, the dialogue flow includes a step sequence for completing a preset express task and corresponding dialogue states, and the dialogue states include slot information required for the task and dialogue flow jump conditions; It is also configured with a dialogue rewriting model for rewriting the current user input and historical dialogue context into a semantically complete query.

2. The large model-based express customer service voice robot multi-turn task dialogue system according to claim 1, wherein, The dialogue domain classifier is a composite routing module including preprocessing, retrieval screening and precision ranking determination, and the specific process is as follows: A vector index covering all express business dialogue domains is constructed, which stores typical query texts and domain function description texts of each dialogue domain, and all texts are converted into high-dimensional vectors through an Embedding model; After receiving the user query, the dialogue domain classifier encodes the user query text into a query vector through the same Embedding model, performs Top-K similarity retrieval in the vector index, filters out a preset number of candidate domains with the highest semantic correlation degree from the query vector, and forms a candidate domain list; The dialogue domain classifier integrates the user query text, the function description text of each candidate domain in the candidate domain list, and the context text of the current dialogue into precision ranking input data, and transmits the precision ranking input data into a precision ranking model; The precision ranking model scores each candidate domain based on semantic matching degree and express business scenario relevance to generate a comprehensive score for each candidate domain; The dialogue domain classifier selects the candidate domain with the highest comprehensive score as the final classification result and routes the user query to the sub-agent module corresponding to the candidate domain.

3. The large model-based express customer service voice robot multi-turn task dialogue system according to claim 1, wherein, The hierarchical persistent memory mechanism of the long short-term memory module includes three memory types: working memory, semantic memory, and workflow memory: The working memory stores recent dialogue data within the current dialogue session, including user input text, system output text, and dialogue turn identification, and the storage range of the recent dialogue data is limited to the context associated with the current task; The semantic memory exists in the form of a combination of a knowledge base and a vector database, the knowledge base stores general knowledge, business rules and service standards of the express industry, and the vector database stores structured business fact data; The workflow memory stores the standardized operation procedures corresponding to each express service, which clearly define the step sequence of service processing, the required slot information of each step, and the step jump conditions; The long short-term memory module also has state extraction, state maintenance update, and state retrieval application functions: the state extraction function identifies and extracts key entities and user intentions from user input text and system output text through natural language understanding technology, and converts them into structured state fragments; the state maintenance update function manages state fragments, including adding non-existing state fragments, modifying user-corrected state fragments, and marking expired state fragments that exceed the business time limit; the state retrieval application function retrieves relevant state information from the three memory types according to the task type and user input semantics of the current dialogue, and integrates them into the prompt words of the large model according to the preset format.

4. The large model-based express customer service voice robot multi-turn task dialogue system according to claim 1, wherein, The long-term memory injection process of the long short-term memory module is as follows: The long short-term memory module is connected to the persistent storage system through a data interface, and the storage system stores the user's historical business data and dialogue state, including the user's past express service handling records, user preference information, and slot information of unfinished tasks; When the user initiates a new dialogue or enters a preset business process, the long short-term memory module queries the historical data related to the current user and the current task from the storage system according to the user identifier, and the query conditions include the user identifier and the business type; The long short-term memory module performs structured processing on the queried historical data, arranges entity type data into key-value pairs of entity values, and arranges process type data into process state descriptions; The long short-term memory module injects the structured long-term memory information into the Prompt of the large model, and the injection position is before the user's current input text. 5.The large model-based express customer service voice robot multi-turn task dialogue system according to claim 1, characterized in that, The sub-agent module includes FAQ Agent, Workflow Agent, and Common Agent; FAQ Agent is used to handle common questions in the express industry with high frequency and fixed answers, and the specific implementation is as follows: An FAQ vector database is pre-constructed, which stores the text of all common questions and the corresponding standard answer text, and the common question text is converted into a vector through an Embedding model; after receiving the user query routed to this Agent, the FAQ Agent converts the user query text into a query vector, performs a nearest neighbor search in the FAQ vector database, and calculates the similarity between the query vector and each question vector in the database; if the highest similarity value exceeds the preset confidence threshold, the standard answer text corresponding to the highest similarity is directly retrieved and fed back to the user; If the highest similarity value does not exceed the confidence threshold, the user query is transferred to other suitable sub-agent modules. The Workflow Agent is used to process express business tasks that need to be completed in multiple steps. Each Workflow Agent corresponds to a preset express business and has a built-in dialogue flow for the business. When the Workflow Agent runs, it first obtains the state information of the current dialogue through the long short-term memory module, and determines whether the collected slot information meets the requirements of the current step. If the slot information is missing, a slot inquiry response is generated to guide the user to supplement the information. If the slot information is complete, the next business step is entered according to the jump conditions of the dialogue flow, or when external resources need to be called, the corresponding external API interface is called through the information source module to obtain the business data and generate a response. The Common Agent is used to handle queries that cannot be covered by the FAQ Agent or the Workflow Agent. The Common Agent connects a general large model fine-tuned for the express customer service scenario. The large model has pre-trained natural language understanding capabilities and fine-tuned business adaptation capabilities to generate responses. 6.The large model-based express customer service voice robot multi-turn task dialogue system according to claim 1, characterized in that, The large model fine-tuning and data support module includes the following strategies: data quality priority, iterative data construction, and Prompt and Response balance. The data quality priority strategy requires that when filtering supervised fine-tuning data, real and valid dialogue data under the express customer service scenario should be prioritized, and noise data containing incorrect business information, ambiguous semantics, and redundant data should be removed. The iterative data construction strategy includes the following steps: a small amount of high-quality seed data is used to fine-tune the large model initially; a test set is constructed after fine-tuning, and the model performance is evaluated through intent recognition accuracy, entity extraction accuracy, and response relevance; if the evaluation results meet the requirements, the data set is expanded based on the seed data and combined with semi-automatic labeling tools; if the evaluation results do not meet the requirements, the data quality, Prompt design, or fine-tuning parameters are analyzed, and the model is fine-tuned and evaluated again until the model performance meets the requirements. The Prompt and Response balance strategy requires that different expressions of users in actual dialogues should be covered when constructing training data; and the responses to similar prompts and contexts should be kept convergent, with consistent core business information.

7. The large model based express customer service voice robot multi-turn task dialogue system according to claim 1, characterized in that, The data set construction Pipeline in the large model fine-tuning and data support module includes the following steps: Collecting raw data from express customer service historical dialogue logs, business operation manuals, and FAQ documents; cleaning the raw data by removing duplicate dialogue records through a hash de-duplication algorithm, filtering text containing sensitive information through regular expressions, removing non-business-related casual text through manual screening, and converting unstructured text into a structured format of user input-system response; Developing guidelines covering Prompt annotation, Response annotation, and entity annotation, specifying the annotation of Prompt, the business basis of Response annotation, and the type of entity annotation, while specifying the operation process and quality inspection standards of the annotators; The unlabelled data is preprocessed by the large model which is preliminarily fine-tuned, the large model labels the graph and entity of the user input text, and generates a preliminary reply to the system response text; the annotation personnel audits the preprocessing result, corrects the problems of incorrect intent labeling, entity missing labeling and improper reply expression, and supplements the implicit demand not recognized by the model; Select samples of complex scenarios in express business for manual fine labeling, and the annotation personnel analyzes the sample semantics sentence by sentence to ensure the accuracy of intent, entity and reply labeling, and forms a high-quality seed dataset; The back-translation, synonym replacement and syntax conversion techniques are used to expand the number of prompts while keeping the semantics unchanged; The dataset quality is evaluated by calculating the labeling consistency coefficient and statistical error rate, and the evaluation results are fed back to the previous steps. If the error rate of a certain type of sample is high, the labeling specification is adjusted, and if the data of a certain business scenario is insufficient, the data collection is supplemented. 8.The large model-based express customer service voice robot multi-turn task dialogue system according to claim 1, characterized in that, The reasoning optimization includes hierarchical structured prompt design and short-term dialogue memory management mechanism, which are implemented as follows: The hierarchical structured prompt includes system prompt words and dynamic context prompt words. The system prompt words are located at the head of the prompt, which clearly defines the role, behavior standard, output format and general standardized operation procedure of the large model. The dynamic context prompt words are located after the system prompt words, which include the current input text of the user and the processed short-term dialogue memory information; Short-term dialogue memory management is achieved through sliding window and summary mechanism: the sliding window sets a fixed upper limit of dialogue turns, only the pre-set number of dialogue turns before the current turn are retained as the memory within the window, and the old dialogue turns beyond the window are removed from the immediate memory; for the old dialogues beyond the sliding window, the system calls a small summary model to summarize them, extracts the key information, and integrates the key information into a summary text; the system integrates the dialogue history within the window and the summary text as short-term dialogue memory information, and integrates it into the dynamic context prompt words. 9.The large model based express customer service voice robot multi-turn task dialogue system according to claim 1, characterized in that, The reasoning optimization optimizes memory management through context information entropy maximization compression and context locality maintenance during reasoning: Context information entropy maximization compression is achieved through hierarchical summary and entity structured extraction, which is implemented as follows: The hierarchical summary processes the historical dialogues according to the importance of dialogue turns. For core turns containing key entities, the user input intent and system response core content are extracted as detailed summaries. For non-core turns, only the dialogue topic is extracted as a brief summary. Entity structured extraction identifies and extracts core entities from all dialogue turns, stores entity types and corresponding values in the form of a table, and replaces entity descriptions in natural language. The compressed summary, structured entity and original dialogue history are stored in association through a unique identifier, and when the large model generates a response that depends on the original dialogue details, the original text is queried through the identifier; Context locality maintenance prioritizes the preservation of neighboring dialogue content directly related to the current task and filters historical information unrelated to the current task according to the task focus of the current dialogue. 10.The large model based express customer service voice robot multi-turn task dialogue system according to claim 1, characterized in that, The prompt cache mechanism in reasoning optimization is a double-layer structure, including global system prompt word cache and session dimension user prompt word cache: The global system prompt cache is used to store the fixed public part in the prompt, that is, the content common to all user sessions in the system prompt. When the system is started for the first time or the system prompt is updated, the fixed public part is input into the large model inference engine, the Tokenization processing and KV Cache calculation are completed, and the calculation results are stored in the global cache pool. Subsequent calls to the large model for all user sessions directly reuse the calculation results from the global cache pool. The session dimension user prompt cache creates an independent cache space for each user session and stores the processing results of the user's historical input in the session, including the user input text, extracted entity information, dialogue state, and summary of the system response. When the user inputs similar queries or mentions historical information in the same session, the system directly retrieves the corresponding entity information and dialogue state from the session cache without repeating the processing.

Images