Big language model driven dialogue generation method and device, equipment and medium

Abstract

The invention provides a dialogue generation method and device driven by a large language model, equipment and a medium, and the method comprises the steps: receiving natural language input of a user; based on the natural language input and the context information, performing semantic analysis through a large language model to obtain intention and slot position information; managing and updating a current dialogue state based on the intention and the slot position information, the dialogue state being migrated according to a predefined state conversion logic; checking the filling condition of a necessary slot position corresponding to the current dialogue state; deciding the next action of the system based on the filling condition and the updated current dialogue state; and based on the next action, calling the large language model to generate a user-oriented natural language reply. By adopting the method, the controllability of the dialogue process, the natural fluency of interaction, the business goal achievement efficiency and the user interaction experience can be improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more specifically, to a method, apparatus, device, and medium for dialogue generation driven by a large language model. Background Technology

[0002] With the deepening application of artificial intelligence in the field of human-computer interaction, task-oriented dialogue systems have been widely deployed in real-world scenarios such as welcoming guests, customer service, and intelligent navigation. Their core objective is to efficiently achieve specific business goals (such as route guidance, information inquiry, and demand response) through human-computer collaboration, while also taking into account the convenience and naturalness of the interaction process, thus becoming a key technological support for improving service efficiency and user experience.

[0003] In existing task-oriented dialogue systems, one of the mainstream technical approaches is based on finite state machine architecture. This approach predefines fixed dialogue flows, state nodes, and transition rules, clarifying the core objectives and triggering conditions of each dialogue stage. For example, in a welcoming scenario, a fixed flow of "welcome greeting - confirm assistance needs - provide corresponding services - end dialogue" is preset. The system guides the dialogue along the predetermined path by matching user input with preset rules, ensuring the orderly completion of core business tasks.

[0004] This technical approach has significant drawbacks: the dialogue logic relies entirely on pre-configured fixed rules and process templates, lacking the ability to adapt to non-standardized user expressions and contextual changes, resulting in a rigid and template-driven interaction process. When users do not express their needs according to the preset script (e.g., instead of directly responding "Do you need guidance?", they state "I want to find a place to hold a meeting"), the system struggles to identify the user's core intent, easily leading to responses deviating from the user's needs or interaction stuttering, failing to meet the diverse and flexible interaction needs of users in real-world scenarios. Summary of the Invention

[0005] In view of this, the purpose of this application is to provide a large language model-driven dialogue generation method, apparatus, device and medium that can improve the controllability of the dialogue process, the naturalness and fluency of the interaction, the efficiency of achieving business goals and the user interaction experience.

[0006] In a first aspect, embodiments of this application provide a large language model-driven dialogue generation method, the method comprising: Receive natural language input from users; Based on the natural language input and context information, semantic parsing is performed using a large language model to obtain intent and slot information; Based on the intent and the slot information, the current dialogue state is managed and updated, and the dialogue state is transitioned according to a predefined state transition logic. Check the filling status of the required slots corresponding to the current dialogue state; Based on the filling situation and the updated current dialogue state, the decision system will proceed to the next step. Based on the next step, the large language model is invoked to generate a natural language response for the user.

[0007] Optionally, the step of performing semantic parsing based on the natural language input and context information using a large language model to obtain intent and slot information includes: The natural language input is fused with contextual information, including dialogue history, current dialogue state, and business context, to form prompt words; The prompt words are analyzed using the large language model to perform open-domain intent recognition and entity slot extraction. The output contains a structured semantic parsing result that includes the intent and the slot information.

[0008] Optionally, managing and updating the current dialogue state based on the intent and the slot information includes: The structured semantic parsing results are input into the state manager; The state manager updates the current dialogue state by driving the transition of the current dialogue state based on the intent and slot information in the structured semantic parsing result and according to a predefined finite state machine. Each state of the finite state machine corresponds to a dialogue service stage.

[0009] Optionally, checking the filling status of the required slots corresponding to the current dialogue state includes: The slot manager extracts relevant slot values ​​from the structured semantic parsing results and updates the slot repository. Check that all required slots associated with the current dialog state are fully filled.

[0010] Optionally, based on the filling situation and the updated current dialogue state, the next action of the decision-making system includes: If the filling status indicates that there are unfilled necessary slots, the slot manager determines which slots need to be queried first and generates a query command; If the filling status indicates that all required slots have been fully filled, the state manager triggers a state transition instruction to advance the conversation to the next state.

[0011] Optionally, the step of invoking the large language model to generate a user-oriented natural language response based on the next action includes: The response target is determined based on the next action; Using the current dialogue state and the already filled slot information as generation conditions, the large language model is invoked to perform restricted generation, so as to produce natural and goal-oriented human-computer interaction content.

[0012] Optionally, the method further includes a system initialization step: Predefine the state transition logic and establish a state transition table; Load business context information, which includes location information and user information; Set the initial dialogue state.

[0013] Secondly, embodiments of this application provide a large language model-driven dialogue generation apparatus, the apparatus comprising: The natural language input receiving module is used to receive natural language input from users. The semantic parsing module is used to perform semantic parsing based on the natural language input and context information, using a large language model, to obtain intent and slot information; The dialogue state update module is used to manage and update the current dialogue state based on the intent and slot information. The dialogue state is transitioned according to a predefined state transition logic. The fill status check module is used to check the fill status of the required slots corresponding to the current dialog state; The action determination module is used to decide the next action of the system based on the filling situation and the updated current dialogue state. The natural language response generation module is used to generate a user-oriented natural language response by calling the large language model based on the next action.

[0014] Optionally, the step of performing semantic parsing based on the natural language input and context information using a large language model to obtain intent and slot information includes: The natural language input is fused with contextual information, including dialogue history, current dialogue state, and business context, to form prompt words; The prompt words are analyzed using the large language model to perform open-domain intent recognition and entity slot extraction. The output contains a structured semantic parsing result that includes the intent and the slot information.

[0015] Optionally, managing and updating the current dialogue state based on the intent and the slot information includes: The structured semantic parsing results are input into the state manager; The state manager updates the current dialogue state by driving the transition of the current dialogue state based on the intent and slot information in the structured semantic parsing result and according to a predefined finite state machine. Each state of the finite state machine corresponds to a dialogue service stage.

[0016] Optionally, checking the filling status of the required slots corresponding to the current dialogue state includes: The slot manager extracts relevant slot values ​​from the structured semantic parsing results and updates the slot repository. Check that all required slots associated with the current dialog state are fully filled.

[0017] Optionally, based on the filling situation and the updated current dialogue state, the next action of the decision-making system includes: If the filling status indicates that there are unfilled necessary slots, the slot manager determines which slots need to be queried first and generates a query command; If the filling status indicates that all required slots have been fully filled, the state manager triggers a state transition instruction to advance the conversation to the next state.

[0018] Optionally, the step of invoking the large language model to generate a user-oriented natural language response based on the next action includes: The response target is determined based on the next action; Using the current dialogue state and the already filled slot information as generation conditions, the large language model is invoked to perform restricted generation, so as to produce natural and goal-oriented human-computer interaction content.

[0019] Optionally, the system further includes a system initialization module for performing system initialization steps, including: Predefine the state transition logic and establish a state transition table; Load business context information, which includes location information and user information; Set the initial dialogue state.

[0020] Thirdly, embodiments of this application provide a computer device, including: a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the computer device is running, the processor communicates with the memory via the bus. When the machine-readable instructions are executed by the processor, they perform the steps of the large language model-driven dialogue generation method described in any of the optional embodiments of the first aspect above.

[0021] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, performs the steps of the large language model-driven dialogue generation method described in any of the optional embodiments of the first aspect.

[0022] The technical solution provided in this application includes, but is not limited to, the following beneficial effects: The system receives natural language input from users. This step supports user input without fixed format restrictions, accommodating colloquial expressions, concise instructions, and vague statements. It also adapts to direct text input and speech-to-text output, eliminating the need for users to express their needs according to preset scripts. This design significantly lowers the barrier to user interaction, allowing users to freely convey their core needs and avoiding communication barriers caused by input format restrictions, thus improving the convenience of human-computer interaction.

[0023] Based on natural language input and contextual information, semantic parsing using a large language model yields intent and slot information. By integrating dialogue history, current dialogue state, and business scenario information to build the parsing foundation, and leveraging the open-domain parsing capabilities of the large language model, the core intent behind diverse user expressions can be accurately identified, while efficiently extracting slot information relevant to business objectives. This step addresses the reliance of traditional parsing methods on standardized expressions, ensuring accurate capture of core user needs even in the face of non-preset expressions, providing reliable foundational data support for subsequent dialogue progression.

[0024] Managing and updating the current dialogue state based on intent and slot information, and relying on predefined state transition logic, uses user intent and slot information as the core basis for state updates, achieving accurate and orderly transitions in dialogue state. This step ensures that the dialogue always revolves around business objectives, avoiding process chaos or deviation from core tasks, guaranteeing the controllability of the dialogue, and enabling business processes to proceed efficiently according to preset logic.

[0025] By checking the fill status of the necessary slots corresponding to the current dialogue state, and clarifying the necessary slots for achieving the business objective in the current state, and verifying their fill validity (non-empty, non-ambiguous, and conflict-free), key missing information can be accurately located. This step avoids business processing failures or response deviations due to incomplete core information, provides a clear basis for subsequent action decisions, and ensures the accuracy of business processing.

[0026] Based on the fill status and the updated current dialogue state, the system determines the next action, following the "slot priority - state matching" decision principle. Differentiated actions are taken based on slot fill status: either proactively guiding the user to fill in missing information or executing core business processing, with each action strictly bound to the current state. This process ensures that each system action is clearly targeted, avoids invalid interactions, improves dialogue progress efficiency, and reduces user communication costs.

[0027] Based on the next action, the large language model is invoked to generate a natural language response for the user. By combining the action goal, current state, slot information, and scenario constraints, the large language model is invoked to generate the response. This ensures that the response content highly aligns with user needs and business logic, while avoiding the stiffness of traditional template-based responses through natural language generation capabilities. This step achieves a balance between accuracy and naturalness in the response, improving the user's interactive experience and enhancing the smoothness of human-computer communication.

[0028] The aforementioned steps are progressive and coordinated, comprehensively optimizing the entire dialogue generation process from the ease of receiving user input, the accuracy of demand analysis, the controllability of the dialogue flow, the effectiveness of information verification, the relevance of action decisions, to the naturalness of response generation. Ultimately, this achieves the core goal of enhancing user interaction convenience and experience while ensuring the efficient advancement of business processes and the smooth completion of core tasks, thus constructing an efficient, controllable, and natural human-computer dialogue model.

[0029] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0030] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0031] Figure 1 A flowchart of a large language model-driven dialogue generation method provided in Embodiment 1 of this application is shown; Figure 2 A flowchart of a dialogue state transition method provided in Embodiment 1 of this application is shown; Figure 3 A flowchart of a method for determining intent and slot information provided in Embodiment 1 of this application is shown; Figure 4 A flowchart of a dialogue processing flow provided in Embodiment 1 of this application is shown; Figure 5 A flowchart of a current dialogue state update method provided in Embodiment 1 of this application is shown; Figure 6 This paper illustrates a system architecture diagram for a large language model-driven dialogue generation provided in Embodiment 1 of this application. Figure 7 This paper shows a schematic diagram of the structure of a large language model-driven dialogue generation device provided in Embodiment 2 of this application; Figure 8 A schematic diagram of the structure of a computer device provided in Embodiment 3 of this application is shown. Detailed Implementation

[0032] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely represents selected embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0033] Example 1 To facilitate understanding of this application, the following is combined with... Figure 1 The flowchart illustrating a large language model-driven dialogue generation method provided in Embodiment 1 of this application will be described in detail for Embodiment 1 of this application.

[0034] See Figure 1 As shown, Figure 1 The flowchart illustrates a large language model-driven dialogue generation method provided in Embodiment 1 of this application, wherein the method includes steps S101 to S106: S101: Receives natural language input from the user.

[0035] Specifically, the user input received here has no fixed format restrictions and can include conversational expressions (such as "no guidance needed" or "how to get to the coffee shop"), concise request instructions (such as "find a rest area"), or vague expressions (such as "want a cup of coffee"). The input format supports direct text input or speech-to-text output.

[0036] The receiving module must ensure that the user's input information is completely transmitted to the subsequent semantic parsing stage without information loss or format distortion. For example, if the user says "Please show me the way to the meeting room", the module must completely receive the core requirement statement "show me the way to the meeting room".

[0037] S102: Based on the natural language input and context information, semantic parsing is performed using a large language model to obtain intent and slot information.

[0038] Specifically, the "contextual information" includes dialogue history (such as the system's welcome message in the previous round, "Hello, do you need assistance?", and the user's "No, thank you" in the previous round), the current dialogue status (such as "assistance provided" and "problem handled"), and business scenario information (such as the location of facilities in the scenario and service rules, such as "the meeting room is on the 3rd floor, room 301" and "the coffee shop is only open from 9 am to 6 pm on weekdays").

[0039] The semantic parsing performed by the large language model is open-domain parsing, which can handle non-preset expressions. For example, if a user says "I want to find a place to hold a meeting", it can identify the core intent of "requesting the location of the meeting room" and extract the slot information of "destination = meeting room". Moreover, the parsing result must be strongly related to the current business scenario to avoid generating intents or slots that are irrelevant to the scenario.

[0040] S103: Based on the intent and the slot information, manage and update the current dialogue state, which is transitioned according to a predefined state transition logic.

[0041] Specifically, the "predefined state transition logic" includes multiple explicit dialogue states, each corresponding to a specific business stage and goal. For example, the goal of the "welcome state" is to output a greeting message, the goal of the "assistance state" is to confirm whether the user needs guidance, and the goal of the "problem-handling state" is to answer user inquiries or meet their needs.

[0042] State transitions must simultaneously satisfy both "intent matching" and "slot conditions". For example, if the current state is "providing assistance", the user's intent is "refusing assistance" and the "user intent" slot is filled with "not needed", then the transition will proceed to the "problem handling state". If the user's intent is "accepting assistance", the transition will proceed to the "guided state" to ensure that the transition logic conforms to the business process flow.

[0043] See Figure 2 As shown, Figure 2The flowchart of a dialogue state transition method provided in Embodiment 1 of this application is shown. The dialogue starts from the "WELCOME" state, enters the "OFFER_ASSISTANCE" state after "generating a welcome message", and then flows to the "PROVIDE_GUIDANCE" state or the "HANDLE_QUESTIONS" state according to the user's behavior ("user accepts guidance", "user asks questions / rejects guidance"). In the "HANDLE_QUESTIONS" state, it can further flow to "PROVIDE_DIRECTIONS" or "PROVIDE_INFO" or maintain its own state due to scenarios such as "user continues to ask questions", "returns to question mode", "user requests directions", "user requests information". Finally, it flows to the "END_CONVERSATION" state to end the dialogue through paths such as "complete guidance" or "user ends dialogue". This fully presents the dialogue state transition path in multiple scenarios.

[0044] S104: Check the filling status of the required slots corresponding to the current dialogue state.

[0045] Specifically, "required slots" are the key information units for achieving business objectives in the current state. Different states correspond to different required slots. For example, the required slots for "route guidance state" are "destination" and "user's current location," while the required slots for "information query state" are "query object" (such as "facility name" and "service time"). The checking process first extracts the slot values ​​from the semantic parsing results and updates them to the local or cloud-based slot repository (stored in the form of key-value pairs of "slot name-slot value," such as "destination = coffee shop"). Then, it checks whether each required slot has valid information. Valid information must meet the requirements of being "not empty, not ambiguous, and not conflicting." For example, "destination = a certain place" is considered ambiguous and invalid, and "current location = lobby" and "current location = 2nd floor" are considered conflicting and invalid.

[0046] S105: Based on the filling situation and the updated current dialogue state, decide the next action of the decision system.

[0047] Specifically, the action decision follows the principle of "slot priority + status matching" and is divided into two core scenarios: If there are unfilled necessary slots, the next action is to "actively guide the user to fill in the missing information". For example, when "user's current location" is not filled in the "route guidance status", the decision action is to "ask the user's current location".

[0048] If all necessary slots are filled, the next action is to "execute the core business processing corresponding to the current state". For example, when all slots are full in the "route guidance state", the decision action is to "retrieve the specific route from the user's current location to the destination". The action decision must be bound to the current state and irrelevant actions cannot be executed across states (such as not executing the route retrieval action in the "welcome state").

[0049] S106: Based on the next step, call the large language model to generate a natural language response for the user.

[0050] Specifically, when calling the large language model, four types of parameters need to be passed in: "action target + state information + slot information + scenario constraints". The scenario constraints include "the reply should be conversational", "use polite language (such as 'you' or 'please')", "do not contain content that is irrelevant to the current needs", and "clearly respond to the user's intent or slot".

[0051] For example, when the action goal is "feedback route", the generated response should include "starting point (user's current location), ending point (destination), and key path nodes (such as 'turn left' or 'walk straight for 30 meters')", such as "You are currently in the lobby. To get to the coffee shop, turn left and walk straight along the corridor for 30 meters. It is on your right." Interactive statements can also be added (such as "Do you need me to repeat the route?") to avoid the stiffness of traditional templated responses.

[0052] In an optional implementation, see Figure 3 As shown, Figure 3 The flowchart illustrates a method for determining intent and slot information according to Embodiment 1 of this application. The method involves obtaining intent and slot information through semantic parsing using a large language model based on the natural language input and context information, including steps S301-S303: S301: The natural language input is fused with contextual information including dialogue history, current dialogue state and business context to form prompt words.

[0053] Specifically, prompts should be in a structured format, clearly distinguishing each information dimension to avoid information fragmentation that could lead to model parsing bias.

[0054] For example, if a user inputs "No need", the dialogue history is "System: Hello, do you need to be guided to the receptionist?", the current dialogue status is "Providing assistance status", and the business context is "Scenario: a technology innovation base welcoming guests, facilities include reception room (3rd floor 302), coffee shop (east side of the lobby), and meeting room (3rd floor 301)", then the prompt can be constructed as follows: "[User input] No need; [Dialogue history] System: Hello, do you need to be guided to the receptionist?; [Current status] Providing assistance status; [Business scenario] Technology innovation base welcoming guests, facility locations: reception room 3rd floor 302, coffee shop east side of the lobby, meeting room 3rd floor 301; Please parse the user intent and associated slots."

[0055] S302: Analyze the prompt words using the large language model to perform open-domain intent recognition and entity slot extraction.

[0056] Specifically, "open domain" means that intent recognition is not limited to preset categories and can cover non-standardized expressions of users. For example, if a user says "I want to find a place to talk to a client," the model can recognize the intent of "requesting directions to the meeting room," rather than just matching the preset broad categories such as "give directions" or "consult."

[0057] Slot extraction should focus on entities related to the current business objective. For example, under the "provide assistance" state, only the "user intention (accept / reject)" slot should be extracted, and irrelevant entities such as "user age" and "contact information" should not be extracted. At the same time, the intent should be further divided into "task-based intent" (such as giving directions, information query) and "interactive intent" (such as accepting assistance, rejecting requests, ending the conversation) to facilitate subsequent state transition judgment.

[0058] S303: Output a structured semantic parsing result containing the intent and the slot information.

[0059] Specifically, the structured results must be in a machine-readable format (such as JSON), clearly annotating the intent type, intent description, and slot key-value pairs. For example, the parsing result for a user inputting "How to get to the coffee shop" could be "{'Intent Type': 'Task-based - Requesting route guidance', 'Intent Description': 'User needs to obtain route information to the coffee shop', 'Slot Information': {'Destination': 'Coffee Shop', 'Current Location': 'Unfilled'}}". This result must be compatible with the interfaces of the subsequent "State Manager" and "Slot Manager" to ensure that both types of managers can directly read the intent and slot data without secondary format conversion.

[0060] See Figure 4 As shown, Figure 4The flowchart of a dialogue processing flow provided in Embodiment 1 of this application is shown. Starting from "user input", after "calling LLM to perform NLU analysis to extract intent and slots", the process proceeds through "slot manager to update and store new information", and then through "state machine logic to determine whether the required slots are filled?" branch processing. If the determination is "no", then "decision: actively inquire about missing slots", "call LLM to generate inquiry statement", and then "return the reply and wait for the next round of user input". If the determination is "yes", then "decision: state transition and execute core task", "call LLM to generate final reply", and then "return the task result and enter the next dialogue state", ultimately pointing to "this round of dialogue output", which fully presents the closed-loop processing logic of dialogue from input to output.

[0061] In an optional implementation, see Figure 5 As shown, Figure 5 The flowchart illustrates a current dialogue state update method provided in Embodiment 1 of this application, wherein the step of managing and updating the current dialogue state based on the intent and the slot information includes steps S501-S502: S501: Input the structured semantic parsing result into the state manager.

[0062] Specifically, the state manager is the core module responsible for managing the lifecycle of the dialogue state. The structured semantic parsing result of the input must contain complete "intent information + slot information" (such as "intent = refuse to assist" and "slot = user intention: not needed"). The input process must be implemented through a preset interface to ensure the real-time (input is completed within 1 second after the parsing result is generated) and completeness (no missing fields) of the data transmission.

[0063] Meanwhile, the state manager needs to validate the received parsing results. For example, it needs to determine whether the intent belongs to the intent list supported by the current scene (e.g., the "complaint" intent is not supported in the welcoming scene) and whether the slot is the slot associated with the current state. If the validation fails, it should return an "invalid parsing result" message to avoid abnormal data causing state chaos.

[0064] S502: The state manager updates the current dialogue state by driving the transition of the current dialogue state based on the intent and slot information in the structured semantic parsing result and according to a predefined finite state machine, wherein each state of the finite state machine corresponds to a dialogue service stage.

[0065] Specifically, the "finite state machine" contains multiple explicit dialogue states, each corresponding to a specific business stage. For example, "WELCOME" corresponds to the "initial welcoming stage", "OFFER_ASSISTANCE" corresponds to the "assistance confirmation stage", "HANDLE_QUESTIONS" corresponds to the "request response stage", and "END_CONVERSATION" corresponds to the "dialogue closing stage". State transitions must meet "two-condition triggering": first, the intent in the parsed result matches the business goal of the current state (e.g., "providing assistance" requires matching the intent of "accepting assistance" or "refusing assistance"), and second, the required slots of the current state are filled (e.g., "providing assistance" requires the "user intention" slot to be filled with a valid value).

[0066] For example, if the current state is "Provide Assistance" and the parsing result is "Intent = Refuse Assistance" and "Slot = User Intent: Not Needed", then the state manager drives the dialogue state to migrate to "Problem Handling State" to complete the state update.

[0067] In an optional implementation, checking the filling status of the required slots corresponding to the current dialogue state includes: extracting relevant slot values ​​from the structured semantic parsing results through the slot manager and updating the slot repository.

[0068] Specifically, the slot manager follows the "relevance principle" when retrieving slot values, extracting only slots relevant to the business objectives of the current dialogue state. For example, in the "problem handling state," if the user's request is "query meeting room opening hours," only the slots with "query object = meeting room" and "query content = opening time" are extracted, ignoring slots such as "receptionist's name" and "visitor's title" that are irrelevant to the current request. The slot repository is a structured data storage unit, storing data in key-value pairs of "slot name - slot value." If a slot with the same name exists (e.g., the user first requests "go to the restaurant" and then changes it to "go to the coffee shop"), the latest extracted slot value overwrites the old value, ensuring that the stored slot information always reflects the user's latest request.

[0069] Check that all required slots associated with the current dialog state are fully filled.

[0070] Specifically, the criteria for determining "fully filled" include three aspects: First, the slot value is not empty (e.g., the "Destination" slot cannot be "None" or "Don't know"); second, the slot value has no ambiguous description (e.g., "Destination = a certain place" or "Current location = over there" are considered ambiguous and invalid); and third, the slot value has no conflict (e.g., "Current location = Lobby" and "Current location = 3rd floor" cannot exist at the same time). For example, the required slots for "Route guidance status" are "Destination" and "Current location". If the slot repository contains "Destination = Coffee Shop" and "Current location = Lobby", it is determined to be "fully filled"; if "Current location = Not specified", it is determined to be "not fully filled". The check result must be output in the form of "fill status + list of unfilled slots" (e.g., "fill status: not fully filled; unfilled slots: current location") to provide a clear basis for subsequent action decisions.

[0071] In an optional implementation, the decision-making process based on the fill status and the updated current dialogue state includes: if the fill status indicates the existence of unfilled required slots, the slot manager determines the slots that need to be queried first and generates a query instruction.

[0072] Specifically, when the slot manager decides to "prioritize querying slots," it follows the "business priority sorting rule." That is, the slot with the greater impact on the current business goal has a higher query priority. For example, in the "route guidance status," the "destination" slot has a higher priority than the "current location" slot (because without a destination, the route direction cannot be determined), and the "current location" slot has a higher priority than "whether accompaniment and guidance are needed" (because the current location can be supplemented by the scenario default value, while the destination has no default value). The generated query command must include the "target slot name" and the "guidance script template." For example, when the target slot is "current location," the query command is "Where are you currently located? Can you tell me the specific area (such as the lobby, the elevator entrance on the 3rd floor, or the reception desk on the 1st floor)?" By using specific examples, the user's understanding cost is reduced and ambiguity is avoided.

[0073] If the filling status indicates that all required slots have been fully filled, the state manager triggers a state transition instruction to advance the conversation to the next state.

[0074] Specifically, before triggering a transition command, the state manager needs to perform a "secondary verification" to reconfirm the validity of filling the required slots (to avoid misjudgment during the initial check) and verify whether the current intent matches the business objective of the next state (e.g., when transitioning from "problem handling state" to "route guidance state", it needs to be confirmed that the user intent is "request route"). The transition command needs to include three types of information: "current state", "next state", and "trigger condition" (e.g., "current state: problem handling state; next state: route guidance state; trigger condition: user intent = request route, all required slots (destination, current location) are filled"). At the same time, it is sent synchronously to the slot manager (clearing the "filled" mark of the required slots in the current state) and the interaction layer (notifying them to prepare to generate the response content for the next state) to ensure that all modules work together to complete the state transition.

[0075] In an optional implementation, the step of generating a user-oriented natural language response by invoking the large language model based on the next action includes: determining the response target based on the next action; using the current dialogue state and filled slot information as generation conditions, invoking the large language model to perform restricted generation, so as to produce natural and targeted human-computer interaction content.

[0076] Specifically, the response objective is strictly bound to the next action, possessing uniqueness and specificity: if the next action is "inquiring about unfilled slots," then the response objective is "guiding users to provide valid information corresponding to that slot" (e.g., when the target slot is "destination," the response objective is "getting users to clearly state the specific location they want to go"); if the next action is "performing core business processing," then the response objective is "clearly providing users with feedback on the business processing results" (e.g., when the business processing is "searching for meeting room opening hours," the response objective is "informing users of the specific opening hours of the meeting room and whether it is available for booking"); the response objective must be defined in the form of "keywords + constraints" (e.g., "route feedback response objective: including the starting point, destination, and key turning points, concise language, no more than 2 sentences"), to avoid the large language model generating content that deviates from the requirements.

[0077] "Restricted generation" is the core means to ensure that responses conform to business logic and interactive experience. When calling the large language model, three types of constraints need to be passed in: First, the current dialogue state (such as "route guidance state"), to avoid generating content unrelated to the state (such as not mentioning "receptionist appointment"); second, the already filled slot information (such as "destination = coffee shop" "current location = lobby"), to ensure that the response is related to the information already provided by the user (such as not repeatedly asking "where do you want to go"); and third, scenario-based interaction rules (such as the welcoming scenario should be "polite and conversational, using honorifics such as 'you' and 'please', and avoiding technical terms").

[0078] For example, when generating a route response, the model needs to output "You are currently in the lobby. To get to the coffee shop, turn left and walk straight along the corridor for 30 meters. It is on your right. Do you need me to repeat the route?" under constraints. This not only contains key business information but also has a natural human-computer interaction feel, which is different from the rigid response generated by traditional fixed templates.

[0079] In an optional implementation, the method further includes a system initialization step: predefining the state transition logic and establishing a state transition table.

[0080] Specifically, the predefined process needs to combine the business objectives of the specific application scenario and clarify the core information of each state, including the state name (such as "WELCOME", "OFFER_ASSISTANCE", "HANDLE_QUESTIONS"), business objectives (such as "WELCOME state objective = output a welcome message and introduce the service scope" and "OFFER_ASSISTANCE state objective = confirm whether the user needs guidance or consultation"), required slots (such as "OFFER_ASSISTANCE state has no required slots, HANDLE_QUESTIONS state requires the 'user request type' slot"), triggering conditions (such as "the condition for WELCOME state to trigger the next state = system startup completed" and "the condition for OFFER_ASSISTANCE state to trigger the next state = the user explicitly expresses 'accept' or 'refuse' assistance"), and the next state (such as "the next state of WELCOME state = OFFER_ASSISTANCE state").

[0081] The state transition table is presented in the form of a visual flowchart, marking the relationships and transition paths of each state, which facilitates development and maintenance. At the same time, the state transition logic is stored in the configuration file of the state manager, which supports subsequent on-demand expansion (such as adding a "Temporary Rest Area Guide" state) without modifying the core system code.

[0082] For example, as shown in the table below:

[0083] Load business context information, which includes location information and user information.

[0084] Specifically, "venue information" needs to cover detailed data on all key facilities within the scene. For example, in the welcoming scene of the science and technology innovation base, it includes facility names (coffee shop, reception room, meeting room, elevator, front desk), precise locations (such as "the coffee shop is located on the east side of the lobby, 10 meters from the lobby entrance, next to the front desk" and "meeting room 301 is located on the east side of the 3rd floor, near elevator No. 3"), attribute information (such as "the reception room is only open from 9:00 to 17:00 on weekdays" and "the coffee shop provides free drinking water"), and related services (such as "the elevator can directly reach the meeting room area on the 3rd floor" and "the front desk can provide visitor registration services").

[0085] "User information" is divided into two categories: pre-registered users (stores name, title, and historical interaction records, such as "Visitor Zhang San, title: engineer, last inquired about the meeting room reservation process") and temporary visitors (loads default user information, such as "Visitor type: temporary visitor, service permission: infrastructure guidance").

[0086] Business context information is stored in a dedicated database and is loaded via a batch import interface during initialization. It also supports a real-time update mechanism (such as synchronizing to the system database within 10 minutes after changes in facility location or opening hours) to ensure information timeliness.

[0087] Set the initial dialogue state.

[0088] Specifically, the initial dialogue state needs to be set according to the core startup goal of the application scenario. For example, the initial state of the welcoming scenario is set to "WELCOME (welcome state)", and the initial state of the customer service scenario is set to "QUESTION_ACCEPT (question receiving state)". When setting the initial state, two initialization operations need to be completed simultaneously: first, clear the slot storage library (reset all slot values ​​to "unfilled"), and second, initialize the dialogue history (set to an empty list) to avoid historical dialogue data interfering with the new dialogue process.

[0089] At the same time, the initial state needs to be bound to a preset "initial interaction action". For example, the initial action of "WELCOME state" is "automatically generate and output a welcome message". The welcome message should include scene identification, self-introduction and service scope, such as "Hello! Welcome to the Science and Technology Innovation Base. I am the intelligent welcoming assistant. I can provide you with facility route guidance, opening time inquiry or receptionist guidance services. Do you need my assistance?" The human-computer interaction process can be quickly started through the initial action.

[0090] The stateful dialogue system architecture corresponding to the large language model-driven dialogue generation method disclosed in this application is described in [reference needed]. Figure 6 As shown, Figure 6The diagram illustrates a system architecture diagram for dialogue generation driven by a large language model, as provided in Embodiment 1 of this application. The system is divided into a “cognitive layer - large language model engine”, a “processing layer - dialogue management engine”, and an “interaction layer”. The cognitive layer includes "prompt word engineering integration status, history, and instructions" and "large language model understanding and generation core," used to "request analysis of user intent" and "return structured parsing results." The structured parsing results include user intent tags (including task-oriented and interactive intents) and slot information in the form of "slot name-slot value." The processing layer includes "NLU: semantic parsing," "slot manager update and storage," and "state manager," responsible for semantic processing, slot management, and state control of the parsing results. It also involves "slot confirmation" logic—the slot manager stores slot information in key-value pairs and verifies the necessary slot filling status, while the state manager drives dialogue state transitions based on a predefined finite state machine. The interaction layer includes "user input" and "NLG: generate response" modules, realizing the interactive function of receiving user input and generating system responses. The NLG module calls the large language model for restricted generation based on the action instructions of the processing layer (such as querying missing slots or providing feedback on business results), clearly demonstrating the information flow and functional division between the modules in each layer.

[0091] Example 2 See Figure 7 As shown, Figure 7 The diagram illustrates the structure of a large language model-driven dialogue generation device according to Embodiment 2 of this application, wherein the device includes: Natural language input receiving module 701 is used to receive natural language input from users; Semantic parsing module 702 is used to perform semantic parsing based on the natural language input and context information, through a large language model, to obtain intent and slot information; The dialogue state update module 703 is used to manage and update the current dialogue state based on the intent and slot information, wherein the dialogue state is transitioned according to a predefined state transition logic; The fill status check module 704 is used to check the fill status of the required slots corresponding to the current dialog state; Action determination module 705 is used to determine the next action of the system based on the filling situation and the updated current dialogue state; The natural language response generation module 706 is used to generate a user-oriented natural language response by calling the large language model based on the next step.

[0092] In an optional implementation, the step of performing semantic parsing based on the natural language input and context information using a large language model to obtain intent and slot information includes: The natural language input is fused with contextual information, including dialogue history, current dialogue state, and business context, to form prompt words; The prompt words are analyzed using the large language model to perform open-domain intent recognition and entity slot extraction. The output contains a structured semantic parsing result that includes the intent and the slot information.

[0093] In an optional implementation, managing and updating the current conversation state based on the intent and the slot information includes: The structured semantic parsing results are input into the state manager; The state manager updates the current dialogue state by driving the transition of the current dialogue state based on the intent and slot information in the structured semantic parsing result and according to a predefined finite state machine. Each state of the finite state machine corresponds to a dialogue service stage.

[0094] In an optional implementation, checking the fill status of the required slots corresponding to the current dialogue state includes: The slot manager extracts relevant slot values ​​from the structured semantic parsing results and updates the slot repository. Check that all required slots associated with the current dialog state are fully filled.

[0095] In an optional implementation, the decision on the next action of the system based on the fill status and the updated current dialogue state includes: If the filling status indicates that there are unfilled necessary slots, the slot manager determines which slots need to be queried first and generates a query command; If the filling status indicates that all required slots have been fully filled, the state manager triggers a state transition instruction to advance the conversation to the next state.

[0096] In an optional implementation, the step of invoking the large language model to generate a user-oriented natural language response based on the next action includes: The response target is determined based on the next action; Using the current dialogue state and the already filled slot information as generation conditions, the large language model is invoked to perform restricted generation, so as to produce natural and goal-oriented human-computer interaction content.

[0097] In an optional implementation, the system further includes a system initialization module for performing system initialization steps, including: Predefine the state transition logic and establish a state transition table; Load business context information, which includes location information and user information; Set the initial dialogue state.

[0098] Example 3 Based on the same application concept, see [link / reference] Figure 8 As shown, Figure 8 This illustration shows a structural schematic diagram of a computer device provided in Embodiment 3 of this application, wherein, as shown... Figure 8 As shown, the computer device 800 provided in Embodiment 3 of this application includes: The computer device 800 includes a processor 801, a memory 802, and a bus 803. The memory 802 stores machine-readable instructions that can be executed by the processor 801. When the computer device 800 is running, the processor 801 communicates with the memory 802 through the bus 803. When the machine-readable instructions are executed by the processor 801, they perform the steps of the large language model-driven dialogue generation method shown in Embodiment 1 above.

[0099] Example 4 Based on the same concept, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the steps of the dialogue generation method driven by the large language model described in any of the above embodiments.

[0100] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the system and apparatus described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0101] The computer program product for large language model-driven dialogue generation provided in this application includes a computer-readable storage medium storing program code. The instructions included in the program code can be used to execute the methods described in the preceding method embodiments. For specific implementation details, please refer to the method embodiments, which will not be repeated here.

[0102] The large language model-driven dialogue generation device provided in this application embodiment can be specific hardware on a device or software or firmware installed on the device. The implementation principle and technical effects of the device provided in this application embodiment are the same as those in the foregoing method embodiments. For the sake of brevity, any parts not mentioned in the device embodiment can be referred to the corresponding content in the foregoing method embodiments. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can all be referred to the corresponding processes in the above method embodiments, and will not be repeated here.

[0103] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some communication interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

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

[0105] In addition, the functional units in the embodiments provided in this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

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

[0107] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. In addition, the terms "first", "second", "third", etc. are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0108] Finally, it should be noted that the above-described embodiments are merely specific implementations of this application, used to illustrate the technical solutions of this application, and not to limit them. The protection scope of this application is not limited thereto. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this application; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application. All should be covered within the protection scope of this application. Therefore, the protection scope of this application should be determined by the protection scope of the claims.

Claims

1. A dialogue generation method driven by a large language model, characterized in that, The method includes: Receive natural language input from users; Based on the natural language input and context information, semantic parsing is performed using a large language model to obtain intent and slot information; Based on the intent and the slot information, the current dialogue state is managed and updated, and the dialogue state is transitioned according to a predefined state transition logic. Check the filling status of the required slots corresponding to the current dialogue state; Based on the filling situation and the updated current dialogue state, the decision system will proceed to the next step. Based on the next step, the large language model is invoked to generate a natural language response for the user.

2. The method according to claim 1, characterized in that, The process of semantic parsing based on the natural language input and context information, using a large language model, to obtain intent and slot information includes: The natural language input is fused with contextual information, including dialogue history, current dialogue state, and business context, to form prompt words; The prompt words are analyzed using the large language model to perform open-domain intent recognition and entity slot extraction. The output contains a structured semantic parsing result that includes the intent and the slot information.

3. The method according to claim 2, characterized in that, The management and updating of the current dialogue state based on the intent and the slot information includes: The structured semantic parsing results are input into the state manager; The state manager updates the current dialogue state by driving the transition of the current dialogue state based on the intent and slot information in the structured semantic parsing result and according to a predefined finite state machine. Each state of the finite state machine corresponds to a dialogue service stage.

4. The method according to claim 3, characterized in that, The step of checking the fill status of the required slots corresponding to the current dialogue state includes: The slot manager extracts relevant slot values ​​from the structured semantic parsing results and updates the slot repository. Check that all required slots associated with the current dialogue state are fully filled.

5. The method according to claim 4, characterized in that, Based on the filling situation and the updated current dialogue state, the next action of the decision-making system includes: If the filling status indicates that there are unfilled necessary slots, the slot manager determines which slots need to be queried first and generates a query command; If the filling status indicates that all required slots have been fully filled, the state manager triggers a state transition instruction to advance the conversation to the next state.

6. The method according to claim 1, characterized in that, The step of generating a user-oriented natural language response by invoking the large language model based on the next action includes: The response target is determined based on the next action; Using the current dialogue state and the already filled slot information as generation conditions, the large language model is invoked to perform restricted generation, so as to produce natural and goal-oriented human-computer interaction content.

7. The method according to claim 1, characterized in that, The method also includes a system initialization step: Predefine the state transition logic and establish a state transition table; Load business context information, which includes location information and user information; Set the initial dialogue state.

8. A dialogue generation device driven by a large language model, characterized in that, The device includes: The natural language input receiving module is used to receive natural language input from users. The semantic parsing module is used to perform semantic parsing based on the natural language input and context information, using a large language model, to obtain intent and slot information; The dialogue state update module is used to manage and update the current dialogue state based on the intent and slot information. The dialogue state is transitioned according to a predefined state transition logic. The fill status check module is used to check the fill status of the required slots corresponding to the current dialog state; The action determination module is used to decide the next action of the system based on the filling situation and the updated current dialogue state. The natural language response generation module is used to generate a user-oriented natural language response by calling the large language model based on the next action.

9. A computer device, characterized in that, include: The computer device includes a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the computer device is running, the processor communicates with the memory via the bus. When the machine-readable instructions are executed by the processor, they perform the steps of the large language model-driven dialogue management method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, performs the steps of the large language model-driven dialogue management method as described in any one of claims 1 to 7.

Images