Large model-based multi-turn domain identification method

Abstract

The present application mainly relates to the technical field of natural language processing, in order to solve the problems of low precision of multi-round dialogue domain recognition, poor context continuity and weak fuzzy intention processing ability in the prior art, the present application provides a multi-round domain recognition method based on a large model, in the offline stage, an intention label and description information, a fine-tuning data set containing single-round dialogue data, multi-round dialogue completion data and multi-round refusal recognition data and a self-defined entity dictionary are constructed, and a special large model is obtained through pre-training and instruction fine-tuning; in the online stage, multi-dimensional data such as user's current request text, historical dialogue record and terminal returned resource information are collected in real time, and after word segmentation and entity extraction, the fine-tuning model is input, the model outputs an intention label or a completion text of the intention label, and finally it is mapped to a real business label, which improves the precision of the multi-round dialogue scene and the completion ability of the fuzzy request, and effectively suppresses the problem of non-business request mis-triggering.

Description

Technical Field

[0001] This invention relates to the field of natural language processing technology, and in particular to a multi-round domain recognition method based on a large model. Background Technology

[0002] In human-computer interaction on smart terminals, accurate domain identification is one of the key core technologies. Its function is to accurately match the user's request text to the corresponding business domain and specific business intent (such as video playback, music playback, channel search, volume adjustment, etc.), thereby triggering the corresponding business logic of the terminal and directly determining the smoothness and accuracy of human-computer interaction. Currently, the mainstream domain identification scheme is a combination of "single-turn domain identification model + multi-turn completion by a small model." That is, a single-turn domain identification model is first used to complete the domain and intent identification of an independent single-sentence request, and then a dedicated small model is used to complete the simple referential information in multi-turn dialogues with a fixed specification. However, existing technical solutions have many technical shortcomings in practical applications and can no longer meet the user's continuous dialogue needs, specifically: 1. Limited multi-round completion capability: Small models only support fixed-specification insertion, such as only recognizing simple references like "this" and "that", and cannot handle complex user requests with non-standard references, ambiguous intent, and missing information, resulting in extremely poor context adaptability; 2. Low domain accuracy: Single-round domain model lacks the ability to associate context across rounds. Multiple rounds of dialogue under the same topic are prone to domain deviation. For example, when a user asks questions related to movies and TV shows one after another, the model mistakenly places the request in the music domain. 3. Frequent cross-domain false triggers: In casual conversation scenarios, the existing model cannot distinguish between casual conversation content and business requests, which can easily trigger business functions such as music playback and video-on-demand, seriously disrupting the user's continuous conversation experience; 4. Cumbersome and inefficient process: The phased processing method of "single-round domain placement + multi-round completion" results in information loss in the intermediate links, and the two models need to be deployed and called independently, which leads to low processing efficiency and cannot meet the needs of real-time interaction of smart terminals. Summary of the Invention

[0003] This invention provides a multi-turn context recognition method based on a large model, aiming to solve the problems of low accuracy, poor context coherence, and weak fuzzy intent processing capability in existing multi-turn dialogue context recognition technologies.

[0004] The technical solution adopted by the present invention to solve the above-mentioned technical problems A multi-round domain identification method based on a large model, applied to human-computer interaction scenarios, the method includes: S1: Construct intent labels and corresponding descriptive information; S2: Construct a fine-tuning dataset and a custom entity dictionary; the fine-tuning dataset includes single-turn dialogue data, multi-turn dialogue completion data, and multi-turn rejection recognition data; the multi-turn rejection recognition data is used to distinguish between business requests and non-business requests. S3: Select a large model as the base model, and perform self-supervised pre-training on the base model based on the constructed intent labels and their corresponding descriptive information; S4: Fine-tune the pre-trained model using instructions based on the fine-tuning dataset and a custom entity dictionary; the fine-tuning dataset is used to train the model to learn the mapping rules between user requests and intent labels, and the custom entity dictionary is used to identify entities and entity types in user requests; S5: Real-time collection of user request text, historical dialogue records, and resource information returned during terminal interaction, and word segmentation and entity knowledge extraction; S6: Input the historical dialogue records, the user's current request text, resource information, and extracted entity knowledge information into the fine-tuned large model. Based on the fine-tuned large model, perform intent recognition and fuzzy request completion, and output intent labels or intent label completion text. S7: Map the intent tag or intent tag completion text to the real business tag and output it.

[0005] In this invention, a two-stage architecture of offline preparation and online inference is adopted to integrate the steps of intent label pre-training, fine-tuning dataset construction, multi-dimensional data collection, intent recognition and fuzzy completion, and result mapping output into a complete multi-turn domain recognition method. This achieves full-process coverage from model training to online inference, significantly improving the accuracy of domain recognition, the smoothness of context connection, the ability to complete fuzzy requests, and the system response efficiency in multi-turn dialogue scenarios, while effectively suppressing the problem of accidental triggering of non-business requests.

[0006] Furthermore, the single-turn dialogue data in step S2 includes the user's current request text and the corresponding intent tag; the multi-turn dialogue completion data includes historical dialogue records, the user's current request text, resource information returned by the terminal, and intent tags; the multi-turn rejection identification data includes historical dialogue records, the user's current request text, intent tags, and entity knowledge information.

[0007] In this invention, single-turn dialogue data, multi-turn dialogue completion data, and multi-turn rejection recognition data are used as fine-tuning datasets. Single-turn dialogue data is used to train the model's basic domain-specific capabilities, multi-turn dialogue completion data is used to train the model's referential resolution and fuzzy completion capabilities, and multi-turn rejection recognition data is used to train the model to distinguish between business requests and non-business requests. The synergistic effect of these three types of data significantly improves the model's overall performance in multi-turn dialogue scenarios.

[0008] Furthermore, in step S4, the LoRA fine-tuning method is used to reduce the number of training parameters for the pre-trained model.

[0009] In this invention, the LoRA fine-tuning method is used to reduce the number of training parameters, which significantly reduces the model training cost and the requirements for hardware resources.

[0010] Furthermore, in step S4, the dialogue data of the input model is limited to a specified round of dialogue within a preset time period under the same device MAC address.

[0011] In this invention, the historical context of the input model is limited to a specified round of dialogue within a preset time period under the same device MAC address. This ensures that the model can make full use of recent historical information for contextual understanding, while avoiding redundant calculations caused by excessively long inputs, thus effectively improving the model's inference speed.

[0012] Furthermore, the word segmentation and entity knowledge information extraction in step S5 includes: performing Jieba word segmentation and part-of-speech tagging on the user's current request text and the user request portion in the historical dialogue record, and extracting entity knowledge information from a custom entity dictionary, wherein the entity knowledge information includes entity name and corresponding attributes.

[0013] In this invention, by combining Jieba word segmentation with a custom entity dictionary for word segmentation and part-of-speech tagging, the core entities and their types in user requests can be accurately identified. Entity knowledge information is input into the model in a structured form, enabling the model to clearly understand the type of entity mentioned by the user, thereby assisting in intent judgment, avoiding domain errors caused by entity recognition bias, and improving the recognition accuracy in entity-intensive scenarios.

[0014] Furthermore, the fuzzy request completion in step S6 specifically refers to the following: when the user's current request text includes referential words or is expressed in a non-standard format, the fine-tuned model completes the current request based on historical dialogue records, resource information, and entity knowledge information, generating a complete text with a clear intent, which is then output along with the intent label.

[0015] In this invention, when a user request includes referential words or non-standardized expressions, the model can complete the current request based on three types of data: historical dialogue records, resource information returned by the terminal, and entity knowledge information, generating complete text with a clear intent. This enables the model to understand the true meaning of the referential words and significantly improves the ability to handle ambiguous requests.

[0016] Furthermore, the output of intent label or intent label completion text in step S6 specifically means: when the user's current request intent is clear and complete, only the intent label is output; when the user's current request has unclear referents or ambiguous intent, the intent label completion text obtained after context completion is output.

[0017] In this invention, the output is selective based on the clarity of the user's request. When the request is clear, only the intent label is output to save computing resources. When the request is ambiguous, the intent label and the completed text are output to ensure execution accuracy. This ensures both response efficiency and execution correctness in ambiguous scenarios, avoiding redundancy or insufficiency caused by outputting a fixed format regardless of whether the request is clear or not, as is the case with traditional solutions.

[0018] Furthermore, S6 also includes: querying preset cached data using the user's current request text as the key; if a matching cached record is found, the domain result stored in the cached record is directly output and the process ends; if no match is found, intent recognition and fuzzy request completion are performed based on the finely tuned large model.

[0019] In this invention, a cache-first, model-backup architecture is adopted. High-frequency requests can directly return results from the cache without calling the large model. Only requests that fail to hit the cache are processed by the large model, which effectively reduces the model's concurrency pressure and computational cost.

[0020] Furthermore, the mapping of intent tags to real business tags in step S7 specifically includes: presetting an intent tag mapping library, storing the correspondence between intent tags and real business tags, and converting the intent tags output by the model into real business tags through the mapping library.

[0021] In this invention, an intent tag mapping library is used to convert the intent tags output by the model into real business tags that the central control system can recognize. The mapping library adopts an extensible configuration method. When a new business domain or a new intent tag is added, the mapping library can be updated directly without modifying the core logic of the model, which reduces system maintenance costs and iteration cycles, and improves the system's scalability and business adaptability.

[0022] Furthermore, the method also includes S8: periodically collecting new business data logs to supplement the fine-tuning dataset, performing secondary fine-tuning on the fine-tuned model, and synchronously updating the custom entity dictionary and intent labels.

[0023] In this invention, a normalized iterative optimization mechanism is established, new business data logs are collected regularly to supplement the fine-tuning dataset and perform secondary fine-tuning, and the custom entity dictionary and intent tags are updated synchronously to ensure that the model can continuously adapt to the dynamic changes of business scenarios.

[0024] Beneficial effects of the present invention This invention integrates multi-turn dialogue completion and domain placement into a single model, and introduces multi-dimensional context such as historical dialogue records, terminal returned resource information, and entity knowledge information. This significantly improves the domain placement accuracy and fuzzy request completion capability in multi-turn dialogue scenarios, effectively solves the problems of intent drift, difficulty in referential resolution, and poor context connection in traditional solutions, greatly optimizes the domain placement recognition response efficiency, and suppresses cross-domain false triggering, thereby improving the accuracy, fluency, and efficiency of human-computer interaction. Attached Figure Description

[0025] Figure 1 This is a flowchart of the multi-round domain identification method based on a large model described in this invention. Detailed Implementation

[0026] Existing technologies only support simple reference for multi-turn dialogue context recognition in human-computer interaction processes, with limited multi-turn completion capabilities and inability to handle non-standardized requests; at the same time, single-turn models lack contextual association, which can easily lead to context bias; and in casual conversation scenarios, business functions can be accidentally triggered.

[0027] Based on the above, this invention proposes a multi-turn domain identification method based on a large model. Its core lies in integrating domain identification and fuzzy request completion in multi-turn dialogues into a unified task of the large model. First, in the offline stage, a fine-tuned dataset is constructed, including intent tags and description information, single-turn dialogue data, multi-turn dialogue completion data, and multi-turn rejection identification data, along with a custom entity dictionary. A dedicated large model is obtained through pre-training and instruction fine-tuning. Then, in the online stage, multi-dimensional data such as the user's current request text, historical dialogue records, and resource information returned by the terminal are collected in real time. After word segmentation and entity extraction, this data is input into the fine-tuned model. The model outputs intent tags or intent tags plus completed text in a unified manner, which are finally mapped to real business tags to trigger corresponding business logic. This significantly improves the accuracy of domain identification in multi-turn dialogue scenarios, the fluency of contextual connection, the ability to complete fuzzy requests, and the system response efficiency, while effectively suppressing the problem of accidental triggering of non-business requests.

[0028] This embodiment uses a smart TV as an example to describe in detail the multi-round domain identification method based on a large model described in this invention. However, this invention is not limited to smart TVs and can also be applied to human-computer interaction scenarios of other smart terminals such as smart speakers and smartphones. Figure 1 Specifically, it includes the following steps.

[0029] I. Offline Preparation Stage The offline preparation phase includes steps S1 to S4, which only needs to be performed once for training and deploying the model.

[0030] Step S1: Construct intent labels and their corresponding descriptive information This step begins by comprehensively collecting intent tags and corresponding descriptive information for question-and-answer business scenarios. This forms complete intent description data for subsequent model pre-training.

[0031] The question-and-answer services of smart TVs include video playback, music on demand, program search, Q&A, volume adjustment, and channel switching. This embodiment collects 1000 intent tags, each uniquely corresponding to a service area. For example, the intent tag "videoQuery" corresponds to the video playback area, the intent tag "musicPlay" corresponds to the music on demand area, and the intent tag "searchChannel" corresponds to the channel search area.

[0032] Write detailed descriptions for each intent tag, clearly including the intent name, triggering scenario, and associated entity type.

[0033] Taking "videoQuery" as an example, its description is: "Used to search and play specific film and television content such as movies, TV series, variety shows, etc. by dimensions such as title, actors, directors, year, production company, lines, soundtrack, rating, box office, etc., such as playing "xx movie", high-scoring movie in 2023, TV series with "xx" soundtrack; excluding TV channel switching, such as changing the channel to channel A, channel B, etc.

[0034] Step S2: Build the fine-tuning dataset and custom entity dictionary Construct a custom entity dictionary. This embodiment inputs core entity information for smart TVs, such as movies, music, programs, and Q&A topics. The dictionary uniformly adopts the format of "entity name-entity type-word frequency". For example, "xx TV series-video-100" means that "xx TV series" is a movie / TV series entity with a word frequency of 100, and "xx song-song-100" means that "xx song" is a song entity with a word frequency of 100. For entities with the same name, a multi-part-of-speech tagging method is used, such as "YY-video&song-100" meaning that "YY" is both a movie / TV series name and a song name.

[0035] The custom entity dictionary uses the Jieba segmentation tool to build a dynamic dictionary update mechanism. It synchronizes the TV media asset library with newly added entities once a day at a set time, and adds the new entities to the custom entity dictionary. There is no need to retrain the Jieba segmentation model, which ensures the timeliness of entity recognition.

[0036] Then, a fine-tuning dataset is constructed. In this embodiment, the fine-tuning dataset comes from two sources: first, real business data logs from smart TVs over the past year, including user interaction records with the TV; and second, data from commonly used multi-turn dialogue scenarios generated in batches using a large model. All data is manually cleaned and labeled to remove invalid data such as incorrectly labeled or context-irrelevant data, ultimately forming a fine-tuning dataset comprising three types of data: single-turn dialogue data, multi-turn dialogue completion data, and multi-turn rejection recognition data. All data is stored in JSON format.

[0037] Single-turn dialogue data is used to train the model's single-turn context recognition capability. Each data entry includes at least the user's current request text and the corresponding intent tag. The standard format of single-turn dialogue data is: {"query":"user's single-turn request text","output":"corresponding intent tag"}. To improve the accuracy of the descriptive information, single-turn data can also include entity knowledge information, with the corresponding data format: {"query":"user's single-turn request text","output":"corresponding intent tag","knowledge":["entity information 1","entity information 2",...]}. For example, a single-turn dialogue data entry might be: the user's current request text is "Play xx music", and the corresponding intent tag is "musicPlay". Optionally, this single-turn dialogue data entry can also include entity knowledge information, such as "xx music is a song title".

[0038] Multi-turn dialogue completion data is used to train the model's ability to handle ambiguous requests. Each data entry includes at least historical dialogue records, the user's current request text, resource information returned by the terminal, and intent tags. Historical dialogue records include the user's interaction history with the TV, with each record including roles and content; "user" represents the user, and "assistant" represents the TV's response. Resource information is a list of film and television resource names returned during TV interaction, used to assist the model in completing name matching. The standard format of multi-turn dialogue data includes at least the following two, which can be flexibly selected according to the actual dialogue scenario: Format 1 (Multi-round completion - referential completion): {"history":[{"role":"user","content":"user's previous request text"},{"role":"assistant","content":"terminal's previous response text"}],"query":"user's current request text","output":"corresponding intent tag | completion text","knowledge":["entity information 1","entity information 2",...]}; Format 2 (Multi-round requests with resource information - resource reference completion): {"history":[{"role":"user","content":"user's previous request text"},{"role":"assistant","content":"terminal's previous response text"}],"query":"user's current request text","output":"corresponding intent tag | completion text","result":["resource information 1","resource information 2",...],"knowledge":["entity information 1","entity information 2",...]}.

[0039] For example, the completion data for a multi-turn dialogue is as follows: In the previous round of the dialogue history, the user said "I want to watch a movie directed by director xx", the TV replied "Recommended movies directed by him", the user's current round request text is "90s", the intent tag is "videoQuery" with the completion text "I want to watch a 90s movie directed by director xx", and the entity knowledge information is "director xx is a director".

[0040] Multi-turn rejection identification data is used to train the model's ability to distinguish between business scenario queries and non-business scenario queries, avoiding intent drift in multi-turn dialogue scenarios. Each data entry includes at least historical dialogue records, the user's current request text, and entity knowledge information. The standard format for multi-turn rejection identification data is: {"history":[{"role":"user","content":"user's previous request text"},{"role":"assistant","content":"terminal's previous response text"}],"query":"user's current request text","output":"corresponding intent tag","result":["resource information 1","resource information 2",...],"knowledge":["entity information 1","entity information 2",...]}.

[0041] For example, a multi-turn rejection identification data is as follows: In the historical dialogue record, the user said "recommend action movies", the TV replied with a movie list, the user said "is it good?" in the current turn, the intent label is "chat", and the entity knowledge information is "a movie is a movie title".

[0042] Step S3: Perform self-supervised pre-training on the base model based on intent labels and descriptive information. This step selects a large model as the base model. The 1000 intent labels and corresponding descriptions constructed in step S1 are used as input data, and the base model is pre-trained using a self-supervised learning approach. The training batch size is set to 4 rounds, with the learning rate controlled within the range of 1e-5 to 5e-5. After pre-training, the model can accurately identify the core features of each intent label and its corresponding business scenario, initially possessing the ability to identify the domain in a single round.

[0043] Step S4: Fine-tune the pre-trained model using instructions based on the fine-tuning dataset and a custom entity dictionary. This step involves fine-tuning the pre-trained model to further improve its accuracy in identifying the domain and its ability to adapt to multi-turn dialogues.

[0044] The fine-tuning dataset constructed in step S2 is input into the pre-trained large model, and LoRA high-parameter fine-tuning is used. LoRA fine-tuning only updates the parameters of two low-rank matrices, which greatly reduces the number of training parameters and reduces the memory usage.

[0045] The fine-tuning process incorporates the custom entity dictionary built in step S2 to enhance the model's ability to recognize core entities. Specifically, entity knowledge information is added to the model input, allowing the model to learn the relationship between entity type and intent. For example, when a user request includes the entity with the part-of-speech tag "video", the intent is likely "videoQuery"; when a user request includes the entity with the part-of-speech tag "song", the intent is likely "musicPlay".

[0046] Simultaneously, the model input logic is optimized, limiting the historical context of the model input to the most recent specified round of dialogue within 10 minutes under the same device MAC address. For example, if the user device MAC address is "xxxx" and there are 3 rounds of historical dialogue within 10 minutes, then these 3 rounds of historical dialogue plus the current round request will be input; if there are no historical dialogues, only the current round request will be input. The core purpose of this design is to reduce model input redundancy, reduce model computation, improve model response speed, and at the same time ensure that the model can fully utilize recent historical dialogue information, avoiding intent drift caused by missing context.

[0047] II. Online Reasoning Stage The online inference phase includes steps S5 to S7, which are executed each time a user requests it.

[0048] Step S5: Collect the user's current request text, historical dialogue records, and resource information returned during terminal interaction in real time, and perform word segmentation and entity extraction. When a user interacts with a smart TV, multi-dimensional interaction information is collected in real time and preprocessed in a standardized manner. This includes: device information, such as the user's device MAC address and the TV's chassis model and version number; dialogue information, including the user's current request text and historical dialogue records within a set time period under the same MAC address; and media asset information, i.e., the film and television resource information returned by the TV during the interaction with the user. All collected data undergoes integrity verification to ensure that there are no missing or error-free records.

[0049] After data collection, data preprocessing is performed. Jieba word segmentation and part-of-speech tagging are performed on the user's current request text and the user request portion of historical dialogue records. Core entity knowledge information is extracted using the custom entity dictionary constructed in step S2. Entity knowledge information explicitly includes the entity name and corresponding attributes, used to assist the model in achieving accurate domain identification and avoiding domain identification errors caused by entity recognition bias.

[0050] For example, if a user's current request text is "I want to watch xx actor's xx movie", the result after word segmentation and part-of-speech tagging is: "I want to watch" is tagged as "actionXK", "xx actor" is tagged as "figure, actor, singer", "of" is tagged as "uj", "xx movie" is tagged as "video, song", and "movie" is tagged as "n". By matching a custom entity dictionary, entity knowledge information is extracted: "xx actor is an actor, xx movie is a movie title".

[0051] Step S6: Input the historical dialogue records, the user's current request text, resource information, and entity knowledge information into the fine-tuned large model to perform intent recognition and fuzzy request completion. This step is the core reasoning process. It encapsulates the historical dialogue records, user request text for the current round, resource information returned by the terminal, and extracted entity knowledge information obtained in step S5 into a unified JSON format corresponding to the fine-tuning dataset in step S2, ensuring that the model can read and reason normally.

[0052] The encapsulated data is input into the large model that has been fine-tuned in step S4, and the model performs the following operations in sequence: First, intent recognition. The model combines four types of data: historical dialogue records, entity knowledge information, resource information, and the text of the user's current request, to accurately determine the intent tag corresponding to the user's current request, ensuring accuracy in domain identification and avoiding intent drift.

[0053] Second, ambiguous request completion. If a user's current request is unclear or has vague intent, the model uses historical dialogue records, resource information, and entity knowledge to accurately complete the request, generating a complete text with a clear intent, which is output along with the intent tag. If the request intent is clear and complete, only the intent tag is output.

[0054] For example, suppose a user says "Recommend movies by director xx" in the first round, and the TV returns a list of movies: "Movie A, Movie B, Movie C, Movie D". In the second round, the user says "Play the first one". In this step, the model receives the following information: the user's previous dialogue record ("Recommend movies by director xx"), the TV's movie list response, the resource information ("Movie A, Movie B, Movie C, Movie D"), the entity knowledge information ("director xx is a director"), and the user's current request text ("Play the first one"). The model recognizes "play" as a video playback intent, understands "first one" as referring to "Movie A" based on the resource information, and finally outputs the intent label "videoQuery" with the completed text "Play Movie A".

[0055] If the user directly says "Play video A" in the second round of dialogue, the model judges that the request intent is clear and complete, and only outputs the intent label "videoQuery".

[0056] The criteria for determining fuzzy requests are: the user's current request text contains pronouns, indicator words, or other referential terms, or the request is expressed in a non-standard format that fails to directly clarify the user's core intent. The generated completed text must meet the requirements of consistency with historical context logic and clear intent, ensuring that the completed data accurately triggers the corresponding business logic.

[0057] Step S7: Map the intent tag or intent tag completion text to the actual business tag and output it. This step pre-sets an intent label mapping library, which explicitly stores the one-to-one correspondence between the intent labels in the dataset of step S2 and the actual business intent labels. For example, "musicPlay" is mapped to "MUSIC.PLAY", "videoQuery" is mapped to "VIDEO.QUERY", "searchChannel" is mapped to "SearchChannel", and "weather" is mapped to "WEATHER".

[0058] The intent tags output in step S6 are converted into real business intent tags that can be recognized by the central control unit through the intent tag mapping library. Then, the converted real business domain intents and the completed text are uniformly encapsulated into a format that can be recognized by the central control business module and output to the TV business module to trigger the corresponding business logic.

[0059] For example, step S6 outputs the intent label "videoQuery" and the completed text "Play video A". After mapping, the actual business label "VIDEO.QUERY" is obtained. After being encapsulated in JSON format, it is output to the central control service module, triggering the video playback business logic, and the TV starts playing video A.

[0060] For example, step S6 outputs the intent label "chat", which is mapped to obtain the real business label "CHAT", and the control center connects with different intelligent agents for processing according to business needs.

[0061] The intent tag mapping library adopts an extensible configuration method. When a smart TV adds a new business area or a new intent tag, the intent tag mapping library can be updated directly without modifying the core logic of the model, thus improving the scalability and maintainability of the system.

[0062] As a preferred implementation, a cache query is also performed before the large model query in this step: Specifically, a Redis caching module is configured, using a hash structure to store data. The stored content consists of "instruction template + domain intent," forming frequently cached user data. The cache key is uniformly set to the core text of the user request, and the cache value is the intent tag.

[0063] Redis caching is divided into two categories. The first category is general-purpose caching, which is configured based on the part-of-speech tagging results from Jieba (a Chinese dictionary platform) and is specifically adapted to simple command templates that users frequently use. These include at least the movie / TV search template "I want to watch a certain movie / TV show" and other high-frequency command templates such as "adjust the volume to a certain value" and "query the playback channel of a certain program". The second category is ordinary caching, which is used to store the "command + domain result" of user historical requests. When a user makes the same or similar request again, the cache can be quickly hit, reducing redundant calculations.

[0064] The specific process of the cache query step is as follows: use the text of the user's current request as the key to query the preset cache data. If a matching cache record is found, the domain result stored in the cache record is directly output and the process ends; if no match is found, intent recognition and fuzzy request completion are performed based on the fine-tuned large model.

[0065] For example, if a user says "I want to watch a movie", the core text after word segmentation and redundancy removal is "I want to watch a movie". If a matching record is found in the Redis cache with the cached value "VIDEO", then "VIDEO" can be output directly without calling the large model, thus improving response speed.

[0066] Another embodiment of the present invention further includes step S8: establishing a normalized iterative optimization mechanism, specifically including: New business data logs from smart TVs are collected at a set frequency and added to the fine-tuning dataset constructed in step S2. The large model, fine-tuned in step S4, is then further fine-tuned to continuously improve the model's domain recognition accuracy. New entities in the TV media asset library are synchronized daily, and the custom entity dictionary is updated to ensure timely entity recognition. A "Model-Completion Strategy" configuration table is also established to dynamically determine whether to generate completion text based on the performance differences of different devices, optimizing response speed and user experience. The intent tag mapping library and the "Model-Completion Strategy" configuration table are added or maintained periodically as needed to adapt to new business domains and models, ensuring that the model and various resources are always adapted to user interaction needs and changes in terminal services.

Claims

1. A multi-round location identification method based on a large model, characterized in that, The method includes: S1: Construct intent labels and corresponding descriptive information; S2: Construct a fine-tuning dataset and a custom entity dictionary; the fine-tuning dataset includes single-turn dialogue data, multi-turn dialogue completion data, and multi-turn rejection recognition data; the multi-turn rejection recognition data is used to distinguish between business requests and non-business requests. S3: Select a large model as the base model, and perform self-supervised pre-training on the base model based on the constructed intent labels and their corresponding descriptive information; S4: Fine-tune the pre-trained model using instructions based on the fine-tuning dataset and a custom entity dictionary; the fine-tuning dataset is used to train the model to learn the mapping rules between user requests and intent labels, and the custom entity dictionary is used to identify entities and entity types in user requests; S5: Real-time collection of user request text, historical dialogue records, and resource information returned during terminal interaction, and word segmentation and entity knowledge extraction; S6: Input the historical dialogue records, the user's current request text, resource information, and extracted entity knowledge information into the fine-tuned large model. Based on the fine-tuned large model, perform intent recognition and fuzzy request completion, and output intent labels or intent label completion text. S7: Map the intent tag or intent tag completion text to the real business tag and output it.

2. The multi-round location identification method based on a large model according to claim 1, characterized in that, The single-turn dialogue data in step S2 includes the user's current request text and the corresponding intent tag; the multi-turn dialogue completion data includes historical dialogue records, the user's current request text, resource information returned by the terminal, and intent tags; the multi-turn rejection identification data includes historical dialogue records, the user's current request text, intent tags, and entity knowledge information.

3. The multi-round location identification method based on a large model according to claim 1, characterized in that, In step S4, the LoRA fine-tuning method is used to reduce the number of training parameters for the pre-trained model.

4. The multi-round location identification method based on a large model according to claim 1, characterized in that, In step S4, the dialogue data of the input model is limited to a specified round of dialogue within a preset time period under the same device MAC address.

5. The multi-round location identification method based on a large model according to claim 1, characterized in that, Step S5, which involves word segmentation and entity knowledge information extraction, includes: performing Jieba word segmentation and part-of-speech tagging on the user's current request text and the user request portion in the historical dialogue record; and extracting entity knowledge information from a custom entity dictionary, wherein the entity knowledge information includes entity name and corresponding attributes.

6. The multi-round location identification method based on a large model according to claim 1, characterized in that, The fuzzy request completion in step S6 specifically includes: when the user's current request text includes referential words or is expressed in a non-standard format, the fine-tuned model completes the current request based on historical dialogue records, resource information, and entity knowledge information, generating a complete text with a clear intent, which is then output together with the intent label.

7. The multi-round location identification method based on a large model according to claim 1, characterized in that, The output of intent label or intent label completion text in step S6 specifically includes: when the user's current request intent is clear and complete, only the intent label is output; when the user's current request has unclear referents or ambiguous intent, the intent label completion text obtained after context completion is output.

8. The multi-round location identification method based on a large model according to claim 1, characterized in that, S6 also includes: querying preset cached data using the user's current request text as the key; if a matching cached record is found, the domain result stored in the cached record is directly output and the process ends; if no match is found, intent recognition and fuzzy request completion are performed based on the finely tuned large model.

9. The multi-round location identification method based on a large model according to claim 1, characterized in that, The step S7, which maps intent tags to real business tags, specifically includes: pre-setting an intent tag mapping library to store the correspondence between intent tags and real business tags, and converting the intent tags output by the model into real business tags through intent tag mapping.

10. The multi-round location identification method based on a large model according to claim 9, characterized in that, The method also includes S8: periodically collecting new business data logs to supplement the fine-tuning dataset, performing secondary fine-tuning on the fine-tuned model, and synchronously updating the custom entity dictionary and intent label mapping library.

Images