Model dialogue method, device, equipment and storage medium

Abstract

This application relates to the field of natural language processing technology and discloses a model dialogue method, apparatus, device, and storage medium, including: acquiring first memory information and a target question input by the user; determining whether the target question has a memory recall requirement; if the target question has a memory recall requirement, acquiring second memory information and determining third memory information based on a summary file; generating a first input sequence based on the target question, first memory information, second memory information, and third memory information; and inputting the first input sequence into the target model to obtain a first response result for the target question. When a memory recall requirement exists, generating a first input sequence based on the three types of memory information and the target question and inputting it into the model decouples the memory retention window from the recall loading window, thereby ensuring the breadth of historical memory coverage while also considering the operational efficiency of model inference.

Description

Technical Field

[0001] This application relates to the field of natural language processing technology, and in particular to a model dialogue method, apparatus, device and storage medium. Background Technology

[0002] Dialogue models need to maintain a memory of user history across multiple rounds of interaction. However, in existing solutions, the retention window and recall window of the memory are intertwined. Often, the content of the corresponding rounds of historical dialogue needs to be loaded all at once to retain a certain number of rounds of historical dialogue. If the scope of accessible historical memory is to be expanded, the historical content input into the model must be increased simultaneously, resulting in a sharp increase in lexical overhead. If the lexical overhead is controlled to limit the number of historical rounds loaded, earlier dialogue history will be lost, making it difficult to balance the breadth of historical memory coverage with the operational efficiency of model inference. Summary of the Invention

[0003] The main purpose of this application is to provide a model dialogue method, apparatus, device and storage medium, which aims to solve the technical problem that existing dialogue model memory retrieval methods are unable to balance the breadth of historical memory coverage and the operational efficiency of model reasoning.

[0004] Firstly, this application proposes a model dialogue method, the method comprising: Acquire first memory information and the target question input by the user. The first memory information is the historical dialogue record between the user and the target model. Determine whether the target problem requires memory recall; When there is a memory recall requirement for the target problem, second memory information is obtained, and third memory information is determined according to the summary file. The second memory information is the dialogue record in the historical dialogue record that is located before the first memory information. The summary file is generated by compressing the historical dialogue record before the second memory information. Generate a first input sequence based on the target problem, the first memory information, the second memory information, and the third memory information; and The first input sequence is input into the target model to obtain the first response result to the target question.

[0005] In the above implementation process, by acquiring the first memory information of the most recent round, the second memory information of earlier history, and the third memory information retrieved from the summary file, when there is a memory recall requirement, the three types of memory information and the target question are simultaneously input into the model, thereby decoupling the memory retention window and the recall loading window. This not only expands the coverage of accessible historical memory, but also avoids loading all historical dialogues indiscriminately in every interaction, thus ensuring the breadth of historical memory coverage while taking into account the running efficiency of model inference.

[0006] In some possible implementations of the first aspect, the step of determining the third memory information based on the digest file includes: The keywords of the summary file are matched with the target question, and the files in the summary file with a matching degree greater than a first preset threshold are used as the first summary file according to the matching results; The target question and the summary field of the first summary file are combined to form a filter suggestion; Input the filtering prompts into the preset first model and output the judgment result; and Based on the judgment result, a second summary file is determined from the first summary file as the third memory information of the target problem.

[0007] In the above implementation process, by adopting a two-level retrieval strategy of first coarse keyword screening and then fine model screening for the summary files, a large number of irrelevant summary files can be quickly filtered out in the first stage through lightweight keyword matching. Only a few candidate summary files with matching degree reaching the threshold are sent to the second stage of fine model screening, which reduces the amount of data to be processed in the fine screening stage, reduces the number of model calls and computational resource consumption, and meets the real-time response requirements in the vehicle scenario.

[0008] In some possible implementations of the first aspect, the step of matching the keywords of the abstract file with the target question further includes: If there is no file with a matching degree greater than the first preset threshold in the summary file, then obtain the entity fields of each summary file; Match the entity fields with the target question; and Files with a matching degree greater than a second preset threshold in the summary file are used as the first summary file.

[0009] In the above implementation process, when keyword matching fails to match any candidate summary file, it automatically switches to the backup search path based on entity fields, uses the pre-extracted structured entity information in the dialogue history to perform entity-level matching with the target question, and reselects candidate summary files based on the entity matching score to improve the recall rate in the target delivery scenario.

[0010] In some possible implementations of the first aspect, the step of generating the first input sequence based on the target problem, the first memory information, the second memory information, and the third memory information includes: The system role message segment is determined based on the third memory information and preset data; The first memory information and the second memory information are split into message pairs according to rounds, and the dialogue role message segments are determined based on the message pairs; and The system role message segment, the dialogue role message segment, and the target question are concatenated to generate the first input sequence.

[0011] In the above implementation process, memory information from different levels is injected in a differentiated manner according to message roles. The content in the system role is background reference material provided by the system, while the content in the dialogue role is the actual interactions that occurred in historical dialogues. This enables the target model to distinguish the information source based on the message role, reducing the risk that the model may mistakenly identify the reference material as its own historical output and generate hallucinatory content.

[0012] In some possible implementations of the first aspect, after the step of determining whether the target problem has a memory recall requirement, the method further includes: If there is no memory recall requirement for the target problem, a second input sequence is generated based on the target problem and the first memory information; and The second input sequence is input into the target model to obtain the second response result to the target question.

[0013] In the above implementation process, when it is determined that the target question does not require memory recall, the process of obtaining second and third memory information is skipped directly. A simplified second input sequence is generated based solely on the target question and the first memory information and input into the target model to obtain a response. This allows the system to avoid unnecessary full recall and retrieval overhead in dialogue scenarios that do not require historical memory, completing the response with minimal token consumption and the lowest decision latency.

[0014] In some possible implementations of the first aspect, after the step of inputting the first input sequence into the target model to obtain a first response result to the target question, the method further includes: Input the target question and the first response result into a preset second model, and output a round summary and entity index of the current round of dialogue; and The current round of dialogue is written into the historical dialogue record based on the round summary and the entity index.

[0015] In the above implementation process, the lightweight model is called to generate two metadata items, round summary and entity index, during each round of dialogue writing. This distributes the computational overhead of entity extraction and summary generation to the writing stage of each round of dialogue. When online compression is triggered subsequently, the round summaries of each round of dialogue can be read directly to aggregate the target prompt words, and the entity indexes of each round of dialogue can be read to aggregate the target entity fields, without having to call the model again to extract entities or generate summaries during the compression stage. This reduces the latency and resource consumption during the compression stage.

[0016] In some possible implementations of the first aspect, after the step of writing the current round of dialogue record into the historical dialogue record based on the round summary and the entity index, the method further includes: If the number of dialogue rounds in the historical dialogue record is greater than a preset compression threshold, or if the number of lexical units in the historical dialogue record exceeds a preset quantity threshold, obtain the dialogue record to be compressed from the historical dialogue record. The dialogue records to be compressed are compressed to generate a target summary field; Target prompt words are determined based on the turn summaries of each of the dialogue records to be compressed, and target entity fields are determined based on the entity indexes of each of the dialogue records to be compressed; and A target summary file is generated based on the target summary field, the target prompt word, and the target entity field.

[0017] In the above implementation process, when the number of dialogue rounds or terms in the historical dialogue records reaches a preset threshold, online compression is triggered to complete the conversion of recent historical dialogues into long-term archive summaries, reduce the amount of historical dialogue data cached online, and at the same time fully retain the two types of retrieval metadata, namely topic and entity, to ensure that the subsequent long-term memory retrieval function can be executed normally.

[0018] Secondly, this application also proposes a model dialogue device, the model dialogue device comprising: The acquisition module is used to acquire first memory information and the target question input by the user. The first memory information is the historical dialogue record between the user and the target model. The judgment module is used to determine whether the target problem has a memory recall requirement; The determination module is used to obtain second memory information when there is a memory recall requirement for the target problem, and determine third memory information according to the summary file. The second memory information is the dialogue record in the historical dialogue record that is located before the first memory information. The summary file is generated by compressing the historical dialogue record before the second memory information. The generation module is configured to generate a first input sequence based on the target problem, the first memory information, the second memory information, and the third memory information; and The input module is used to input the first input sequence into the target model to obtain the first response result of the target question.

[0019] Thirdly, this application also proposes a model dialogue device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the model dialogue method as described above.

[0020] Fourthly, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and which, when executed by a processor, implements the steps of the model dialogue method described above.

[0021] Regarding the beneficial effects of any of the technical solutions in the second, third, and fourth aspects mentioned above, refer to the beneficial effects of the corresponding technical solutions in the first aspect; repeated examples will not be listed here. Attached Figure Description

[0022] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0023] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0024] Figure 1 This is a flowchart illustrating a feasible embodiment of the dialogue method of this application. Figure 2 A schematic diagram of the process for determining third memory information in one feasible embodiment of the dialogue method of this application; Figure 3 This is a schematic diagram of the process of writing the current round of dialogue records in one feasible embodiment of the crosswind identification method of this application; Figure 4 This is a schematic diagram of the user dialogue writing process in the dialogue method of this application model; Figure 5 This is a simplified flowchart of the dialogue method in this application. Figure 6 This is a schematic diagram of the module structure of the model dialogue device according to an embodiment of this application; Figure 7 This is a schematic diagram of the device structure of the hardware operating environment involved in the model dialogue method in this application embodiment.

[0025] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0026] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0027] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0028] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a computer, a dialogue agent, or an electronic device capable of performing the above functions. The following description uses an in-vehicle dialogue agent as an example to illustrate this embodiment and the subsequent embodiments.

[0029] This application provides a model dialogue method, referring to... Figure 1 , Figure 1 This is a flowchart illustrating a feasible embodiment of the dialogue method of this application.

[0030] In this embodiment, the model dialogue method includes steps S10 to S50: Step S10: Obtain first memory information and the target question input by the user. The first memory information is the historical dialogue record between the user and the target model.

[0031] It should be noted that the target question can be the natural language expression of the current round input by the user via voice or touch in an in-vehicle dialogue scenario. The target question includes the user's intent and specific content for this interaction. The target model can be a large language model deployed in the in-vehicle intelligent cockpit system, which is used to understand user input and generate corresponding natural language responses.

[0032] In this embodiment, the target model is deployed with a three-layer hierarchical memory architecture, which can decouple how much history is retained from how much history is loaded in a single response, and inject context according to the role of the memory source.

[0033] Understandably, the first memory information can be the memory data loaded at Layer 1 of the three-layer hierarchical memory architecture, used to provide the most basic context for the current dialogue. In the in-vehicle dialogue scenario, the first memory information is the historical dialogue record of the most recent round between the user and the target model. The historical dialogue record can be the dialogue record between the user and the target model before the current dialogue round. The historical dialogue record is stored in the buffer `recent_rounds`, and each round of dialogue record contains a complete user input and the corresponding target model response.

[0034] It should be understood that the first memory layer, as the most basic memory guarantee layer, can include a fixed number (e.g., N1) of historical dialogue records from before the current dialogue round. When a user asks questions such as "Can I back out?", "What about the second one?", "How far is it?", without retaining the original text of the most recent dialogue rounds, the target model will not be able to correctly understand the referent. Therefore, the first memory information is designed as a fixed window that is always loaded and requires no judgment logic, used to provide the most basic dialogue coherence guarantee for each round of response in a zero-decision-overhead manner. In this embodiment, the fixed number N1 is preferably 3 rounds to ensure contextual coherence in most continuous questioning scenarios, and the corresponding token consumption is extremely low.

[0035] It should be understood that in other implementations, N1 can also be set to any appropriate value such as 2 wheels, 4 wheels, or 5 wheels, depending on the vehicle configuration, the size of the context window of the target model, and user interaction habits.

[0036] Step S20: Determine whether there is a memory recall requirement for the target problem.

[0037] It should be noted that memory recall needs can refer to whether the current round needs to load additional information from earlier historical memories beyond the first memory information to help the target model accurately understand the user's intent and generate a response.

[0038] In this embodiment, the core of the three-layer hierarchical memory architecture lies in achieving on-demand recall. Additional recall processes for other memory information are only initiated when there is demand; otherwise, only Layer 1 is relied upon to complete the response with minimal overhead. This avoids the token waste and computational latency caused by performing a full recall in every round of dialogue.

[0039] Specifically, the user's target question can be input into the intent recognition node, and the three tasks of intent classification, domain determination, and memory injection determination can be completed simultaneously in a single large language model structured output call.

[0040] In some feasible implementations, after obtaining the target question input by the user, the target question can be classified to identify the type of user intent (such as query, operation, chat, etc.), or the target question can be judged to determine the functional domain to which the current dialogue belongs (such as navigation, music, vehicle control, etc.), or the target question can be judged to determine whether additional memory needs to be loaded from earlier history.

[0041] In other feasible implementations, while simultaneously completing the three tasks of intent classification, domain determination, and memory injection determination in a single large language model structured output call, a keyword fallback mechanism independent of the large language model's determination result can be introduced. This mechanism uses keyword matching to determine whether pronouns exist in the target question, thus determining whether the target question requires memory retrieval. For example, when user input contains preset pronouns such as "last time," "that," "before," "continue," "my wife," or "I said," regardless of the large language model's determination, the memory injection flag is forcibly set to "requires injection." This design considers the uncertainty in intent determination inherent in the large language model, while the presence of pronouns is itself a strong signal requiring historical memory; it's better to inject more than to miss. If the final determination is that memory injection is not required, only Layer 1 fixed loading (e.g., loading only the most recent 3 rounds of original text) is executed; Layer 2 full retrieval and Layer 3 retrieval are not initiated, completing the response with minimal overhead.

[0042] Step S30: If there is a memory recall requirement for the target problem, obtain the second memory information and determine the third memory information according to the summary file. The second memory information is the dialogue record in the historical dialogue record that is located before the first memory information. The summary file is generated by compressing the historical dialogue record before the second memory information.

[0043] It should be noted that the second memory information corresponds to Layer 2 in the three-layer hierarchical memory architecture. This second memory information can be historical dialogue records preceding the first memory information. The dialogue turn corresponding to the second memory information is located before the dialogue turn of the first memory information. The third memory information corresponds to Layer 3, and this third memory information can be long-term historical memory stored in the form of a compressed summary file. When there is a need for memory retrieval, the original text memory of earlier dialogue turns can be retrieved simultaneously from Layer 2, and the relevant summary memory can be retrieved from Layer 3, enabling the target model to obtain complete historical information coverage from recent to distant periods when generating responses.

[0044] Understandably, the three-tiered hierarchical memory architecture can clean up the historical dialogue records in the buffer `recent_rounds` at fixed intervals and compress the historical dialogue records into a summary file for long-term storage.

[0045] It should be understood that there is no data dependency between the full recall in Layer 2 and the two-stage retrieval in Layer 3. In this embodiment, the second and third memory information can be executed concurrently using asyncio.gather. The total latency depends on the slower of the two paths, rather than being sequentially superimposed, thus allowing for the determination of the real-time response in automotive scenarios.

[0046] In some feasible implementations, when it is determined that there is a need for memory retrieval for the target problem, the historical dialogue records of earlier rounds (excluding the most recent N1 rounds) can be retrieved from `recent_rounds`, and the complete dialogue texts of each round are loaded in chronological order. The rounds for the second memory information can be N2-N1 rounds, where N2 is a preset second positive integer and N2>N1. The retrieved texts are split into message pairs of actual user messages and assistant messages, and injected into the dialogue message sequence before the Layer 1 round.

[0047] In other feasible implementations, when it is determined that there is a memory recall requirement for the target problem, the target problem can be matched with the stored summary file, and a candidate summary file with a high degree of matching can be selected from the summary file as the third memory information.

[0048] The summary file may include an abstract field, keywords, and an entity_index field. The abstract field can be a compressed summary of the original multi-turn dialogue text, used as a source of third-party information after a search result is found. The keywords can be a list of keywords extracted and deduplicated from the round summaries of each round of historical dialogue records, used for keyword matching with the target question during the search phase for rapid initial screening. The entity field can be a structured object composed of structured entity indexes of each round of historical dialogue records, merged and deduplicated according to preset entity categories, used as a fallback search path when the initial keyword screening fails, matching entity information in the target question.

[0049] The round range N2 corresponding to the second memory information and the number of days the summary file corresponding to the third memory information is retained can be configured according to the storage capacity and computing resources of the vehicle device. For example, in vehicles with ample storage resources, N2 can be extended to 30 rounds to retain more original text, and the summary retention days can be extended to 30 days to obtain longer historical coverage; in low-end vehicles with limited resources, N2 can be reduced to 10 rounds, and the summary retention days can be shortened to 7 days to control storage overhead. The specific values ​​of each parameter can be adjusted according to the actual deployment environment, and this embodiment does not impose any restrictions on this.

[0050] In the specific implementation process, when it is determined that the target question does not require memory recall, the process of obtaining the second and third memory information can be skipped directly. Only a simplified second input sequence is generated based on the target question and the first memory information and input into the target model to obtain the response result. This avoids unnecessary full recall and retrieval overhead in dialogue scenarios that do not require historical memory, completing the response with minimal token consumption and the lowest decision latency. At this point, after step S20, the following is also included: If there is no memory recall requirement for the target problem, a second input sequence is generated based on the target problem and the first memory information; and The second input sequence is input into the target model to obtain the second response result to the target question.

[0051] Understandably, if the target problem does not require memory retrieval, the current target problem does not need to load additional information from earlier historical memories outside Layer 1. The acquisition of second memory information, the determination of third memory information, and related concurrent retrieval processes can be automatically skipped. A simplified input sequence can be generated based solely on the target problem and the first memory information, and submitted to the target model to generate a response, thus completing the response with minimal token overhead and lowest decision latency.

[0052] Specifically, the step of generating the second input sequence based on the target question and the first memory information may include: splitting the first memory information into message pairs of user messages (questions previously entered by the user) and assistant messages (information provided by the model in response to the questions) according to rounds; adding each of the split message pairs to the dialogue role message position in chronological order; adding the target question as the last user role message after the dialogue role message position; adding the system persona description of the target model to the system role message position, and concatenating it with the dialogue role message position and the target question to generate the second input sequence. The second input sequence does not contain any memory content from Layer 2 or Layer 3, and the system role message position does not need to add Layer 3 summary text.

[0053] In some feasible implementations, after the second input sequence is input into the target model, the target model understands the current target question based on the system persona description and the context of the most recent N1 rounds of dialogue, and generates a second response result. Since the second input sequence does not contain historical memories from Layer 2 or Layer 3, the target model completes reasoning in the most concise way in scenarios where there is no need for memory recall. This avoids unnecessary waste of computational resources and also avoids interference that may be caused by mistakenly introducing irrelevant historical information into the context.

[0054] Step S40: Generate a first input sequence based on the target problem, the first memory information, the second memory information, and the third memory information.

[0055] It should be noted that the first input sequence is the information submitted to the target model for inference. The first input sequence assembles the memory information of the three levels according to the message role, enabling the target model to distinguish the source of information based on the message role. The first input sequence contains a combination of the three levels of first memory information, second memory information, and third memory information, while the second input sequence contains only the first memory information.

[0056] For example, generating the first input sequence can be achieved by assigning the target question, the first memory information, the second memory information, and the third memory information to corresponding positions according to a preset classification rule, and then concatenating them into the first input sequence. For instance, the first input sequence can include system roles and dialogue roles. The content in the system role is background reference material provided to the model in advance, while the content in the dialogue role is actual interactions that occurred in historical dialogues. Classification helps avoid role confusion and illusions caused by mistaking reference material for one's own historical output.

[0057] In the specific implementation process, to reduce the risk of the model mistaking reference materials for its own historical output and generating hallucinatory content, memory information from different levels of sources can be injected differentially according to message roles. At this time, step S40 may include: The system role message segment is determined based on the third memory information and preset data; the first memory information and the second memory information are split into message pairs according to the round, and the dialogue role message segment is determined based on the message pair; the system role message segment, the dialogue role message segment and the target question are concatenated to generate the first input sequence.

[0058] The system role message segment is a message location in the input sequence of the target model used to carry system-level instructions and background information. The content of the system role message segment is understood by the target model as fixed personas, rule descriptions, or reference background provided by the system. In this embodiment, the system role message segment is composed of the third memory information and the preset data, which may include system persona descriptions, knowledge base references, etc.

[0059] The target model interprets the content in the system role message segment as background reference information rather than what it has said in the historical dialogue, so that it will not mistake the summary information for its own historical output during inference.

[0060] The user / assistant message segment is the message location in the target model's input sequence used to carry historical dialogue interaction records. The content of the user / assistant message segment is interpreted by the target model as the actual dialogue that once occurred between the user and the assistant.

[0061] Specifically, for each round of dialogue in the second memory information, it can be split into a user message and an assistant message, forming at least one message pair; similarly, for each round of dialogue in the first memory information, it can be split into a user message and an assistant message, forming at least one message pair. Then, all the resulting message pairs are added to the dialogue role message segment in chronological order. The message pair corresponding to the second memory information precedes the message pair corresponding to the first memory information.

[0062] It is understandable that after obtaining the system role message segment and the dialogue role message segment, the system role message segment can be placed at the beginning of the input sequence, the dialogue role message segment can be placed after the system role message segment, and the target question can be placed as the last user role message (user message) after the dialogue role message segment to form a complete first input sequence.

[0063] Step S50: Input the first input sequence into the target model to obtain the first response result of the target question.

[0064] Specifically, after the first input sequence is input into the target model, the target model can perform reasoning based on its pre-trained knowledge and the multi-layer memory information provided in the input sequence to generate a natural language response corresponding to the target question, which serves as the first response result.

[0065] In this embodiment, by acquiring the first memory information of the most recent round, the second memory information of an earlier history, and the third memory information retrieved from the summary file, when there is a need for memory retrieval, the three types of memory information and the target question are simultaneously input into the model. This decouples the memory retention window from the retrieval loading window, which can both expand the coverage of accessible historical memory and avoid loading all historical dialogues indiscriminately in every interaction. Thus, it ensures the breadth of historical memory coverage while taking into account the running efficiency of model inference.

[0066] In one feasible embodiment of this application, content that is the same as or similar to the above embodiments can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 2 , Figure 2 This is a schematic diagram of the process for determining third memory information in one feasible embodiment of the dialogue method of this application.

[0067] In this embodiment, determining the third memory information based on the stored digest file includes steps S301-S304: Step S301: Match the keywords of the summary file with the target question, and based on the matching results, use the files in the summary file with a matching degree greater than a first preset threshold as the first summary file.

[0068] It should be noted that the keywords "topics" are pre-defined search tags in the summary file, used to quickly characterize the core topics of the conversations covered by the summary file. During the summary file generation process, keywords can be extracted from the round summaries of each round of historical dialogue records during the compression stage, and then merged and deduplicated.

[0069] During the retrieval phase, the keywords of the abstract files can be matched with the target question. Only abstract files with a matching degree reaching the first preset threshold will enter the subsequent fine screening process, while abstract files with a matching degree below the first preset threshold will be directly filtered without loading the abstract text. This significantly reduces the amount of data that needs to be processed during the retrieval phase and enables rapid filtering of a large number of abstract files.

[0070] Specifically, matching the keywords in the abstract files with the target question can be achieved by calculating the matching degree between the keywords in the target question and the keyword sets of each abstract file. The keywords in the target question can be extracted by segmenting the target question using a word segmentation tool and filtering out stop words, or by identifying entity words in the target question as keywords using a lightweight named entity recognition model. The matching degree can be the similarity between the keywords in the target question and the keyword sets in the abstract files, or it can be the proportion of the keywords in the target question that match the keyword sets in the abstract files.

[0071] In this embodiment, files with a matching degree greater than a first preset threshold can be used as first summary files based on the matching results. The value of the first preset threshold can be dynamically configured according to the latency requirements of the vehicle scenario and the number of stored summary files.

[0072] In the specific implementation process, when keyword matching fails to find any candidate summary files, the system can automatically switch to an alternative search path based on the entity_index field. This involves using pre-extracted structured entity information from the dialogue history (such as people, car models, products, prices, preferences, etc.) to perform entity-level matching with the target question. Candidate summary files are then reselected based on the entity matching score, improving recall in the target delivery scenario. At this point, the step of matching the keywords of the summary file with the target question further includes: If no file with a matching degree greater than the first preset threshold exists in the summary file, then the entity fields of each summary file are obtained; the entity fields are matched with the target question; and the file with a matching degree greater than the second preset threshold in the summary file is used as the first summary file.

[0073] It's important to note that in in-vehicle dialogue scenarios involving referential expressions, users might use phrases like "Where is that restaurant we talked about last time?" to express their opinions. The keyword "restaurant" in the target question might not appear in the `topics` field of the relevant summary file, causing keyword matching to fail to retrieve relevant summary files. This could result in a situation where no files with a match score greater than the first preset threshold exist in the summary file. In such cases, the system can automatically switch to a fallback search path based on entity indexing to ensure high recall in referential expression scenarios.

[0074] The entity field `entity_index` can be a structured search index from the metadata of the summary file, such as a JSON object, used to record entity information appearing in the dialogue rounds covered by the summary file. This entity field can be generated during the compression stage by merging and deduplicating the structured entity indexes `round_entities` of each round of historical dialogue records according to preset entity categories.

[0075] For example, the preset entity categories include, but are not limited to, seven categories: vehicle_model, product, price, person, preference, time, and other. Each entity category records the specific entity name and associated information that appears in the corresponding dialogue batch. For example, the person category records titles such as "my wife" or "salesperson" appearing in the dialogue, while the product category records product names such as "intelligent driving package" or "air suspension."

[0076] Specifically, the step of matching entity fields with the target question may include extracting target entity information from the target question. The extraction of target entity information may employ a lightweight named entity recognition model or a rule-based pattern matching method to identify entity words in the target question that belong to the preset entity category. For example, from the question "Where is that restaurant we talked about last time?", the entity "restaurant" and its corresponding category "location" may be identified. Then, the extracted target entity information is matched with entity records in the entity fields of each summary file. It is determined whether the entity fields of each summary file contain entity records that are identical or semantically similar to the target entity information.

[0077] After completing the entity matching, an entity matching score is calculated for each digest file based on the matching results. The calculation method for the entity matching score includes, but is not limited to, the number of matched entities, a weighted hit score, or the proportion of matched entities to the total number of target entities. The entity matching score of each digest file is compared with a second preset threshold, and the digest files with a matching degree greater than the second preset threshold are designated as the first digest file. The specific value of the second preset threshold can be set according to the sparsity of entity matching and the actual needs of referential resolution in different scenarios.

[0078] Step S302: Combine the target question and the summary field of the first summary file into a filter suggestion.

[0079] It should be noted that the `abstract` field is the core content field in the summary file, generated by compressing the original text of multiple rounds of dialogue. The `abstract` field is a coherent natural language description that carries the semantic information of the dialogue batches covered by the summary file.

[0080] Specifically, the summary field and the target question can be combined according to a preset prompt template to generate a single filter prompt corresponding to each first summary file. The preset prompt template can be used to instruct the preset first model to perform a relevance judgment task.

[0081] In this embodiment, Layer 3 targets long-term memory and employs a two-stage retrieval strategy to recall summaries on demand. Stage 1 is a coarse keyword screening: the `topics` field from the Summary metadata of each summary file within the last 15 days is read and matched with the current user question, selecting candidate summary files with a matching score reaching a threshold. Stage 2 is a lightweight model fine screening: the `abstract` field of the candidate summary files is combined with the current user question to create a filtering suggestion, which is then submitted to a lightweight model for further relevance assessment. Only the full text of the finally selected summary is loaded. If the keyword matching in Stage 1 fails to find any candidate files, a fallback approach is adopted: the `entity_index` field of each Summary file is read, and entity matching scores are used instead of keyword scores to select candidates, followed by the fine screening step in Stage 2.

[0082] Step S303: Input the filtering prompt into the preset first model and output the judgment result.

[0083] Step S304: Based on the judgment result, determine a second summary file from the first summary file as the third memory information of the target problem.

[0084] The preset first model is a lightweight model used to perform relevance assessment, with fewer parameters than the target model that generates the final response. The preset first model can perform relevance assessment of the first abstract file with relatively low computational cost.

[0085] Specifically, the filtering prompts are input into the preset first model in text form. Based on its understanding of natural language, the preset first model analyzes the semantic relevance between the target question in the filtering prompts and the summary content, and outputs a judgment result corresponding to the filtering prompts. The judgment result is a binary classification decision by the preset first model regarding whether the target question in the filtering prompts and the summary content are related; the output format of the judgment result is "related" or "irrelevant." Based on the judgment result, a second summary file judged as "related" by the preset first model can be filtered from the first summary file, thereby determining the third memory information.

[0086] In this embodiment, by adopting a two-stage retrieval strategy of first coarse keyword screening and then fine model screening for the summary files, a large number of irrelevant summary files can be quickly filtered out in the first stage through lightweight keyword matching. Only a few candidate summary files with matching degree reaching the threshold are sent to the second stage of fine model screening. This greatly reduces the amount of data that needs to be processed in the fine screening stage, reduces the number of model calls and computational resource consumption, and makes the retrieval latency meet the real-time response requirements in the vehicle scenario.

[0087] In one feasible embodiment of this application, content that is the same as or similar to the above embodiments can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 3 , Figure 3 This is a schematic diagram of the process of writing the current round of dialogue records in one embodiment of the crosswind identification method of this application.

[0088] In this embodiment, after step S50, steps S601-S602 are also included: Step S601: Input the target question and the first response result into the preset second model, and output the round summary and entity index of the current round of dialogue record.

[0089] Step S602: Write the current round of dialogue record into the historical dialogue record according to the round summary and the entity index.

[0090] It should be noted that after a user and model complete a dialogue, the dialogue record for that round can be written into a buffer as recording information for subsequent rounds.

[0091] The pre-defined second model can be a lightweight model for performing text summarization and entity information extraction. During each round of dialogue writing, the pre-defined second model can be invoked to simultaneously generate two metadata items: a round summary (round_summary) for topic extraction during online compression, and a structured entity index (round_entities) covering seven types of entity information: vehicle type, product, price, person, preference, time, and others. These two metadata items are written to disk along with the dialogue and can be directly read during subsequent retrievals without real-time computation.

[0092] Understandably, a round summary is a brief natural language description generated after text compression of the current round's dialogue record. When compressing the current round's dialogue record in subsequent rounds, keywords can be directly extracted from each round summary and aggregated to generate the topic keyword field in the summary file, thus significantly reducing the real-time computational overhead of the compression stage.

[0093] The entity index `round_entities` is index data generated after structured entity extraction from the current round of dialogue. The entity index records information about various entities that appeared in the current round of dialogue. When compressing the current round of dialogue later, the entity indexes of dialogue records from different rounds can be merged and deduplicated by category to generate the entity field `entity_index` in the summary file, which serves as the fallback path data source for Layer 3 retrieval. The entity index is stored in a structured format, such as a JSON object.

[0094] After obtaining the round summary and entity index of the current dialogue record, the original dialogue text, round summary, and entity index of the current dialogue are associated, establishing a correspondence using the same index identifier (such as round number). The associated current dialogue record is written to the end of the historical dialogue record; the current round number and total token count of the historical dialogue record are updated. After the writing operation is completed, the total round number of the historical dialogue record is increased by 1. The newly written round is located at the very end of the time sequence, serving as the latest dialogue record and becoming part of the first memory information in the next round of dialogue response.

[0095] In the specific implementation process, online compression can be triggered when the number of dialogue turns or lexical units in the historical dialogue records reaches a preset threshold, completing the conversion of recent historical dialogues into long-term archive summaries, reducing the amount of historical dialogue data cached online, while fully preserving the topic and entity retrieval metadata, ensuring that the subsequent long-term memory retrieval function can be executed normally. At this time, after step S602, the following is also included: If the number of dialogue rounds in the historical dialogue record is greater than a preset compression threshold, or if the number of lexical units in the historical dialogue record exceeds a preset quantity threshold, obtain the dialogue record to be compressed from the historical dialogue record. The dialogue records to be compressed are compressed to generate a target summary field; The target prompt words are determined based on the round summary of each of the dialogue records to be compressed, and the target entity fields are determined based on the entity index of each of the dialogue records to be compressed. A target summary file is generated based on the target summary field, the target prompt word, and the target entity field.

[0096] It should be noted that when the number of dialogue turns in the historical dialogue records exceeds a preset compression threshold, the dialogue records to be compressed can be compressed to avoid excessive original dialogue turns being retained in the short-term storage area, which could lead to uncontrolled consumption of storage space and tokens. Alternatively, compression can be triggered when the number of lexical units in the historical dialogue records exceeds a preset threshold to ensure that the total number of lexical units in the historical dialogue records is always within the capacity of the target model's context window, avoiding the inability to submit to the target model due to excessively long input sequences. Alternatively, the end of the day can be triggered to compress all historical dialogue records of the day and generate a cross-day summary file.

[0097] The preset compression threshold can be set higher than the target number of historical dialogue records to be retained, i.e., the number of rounds to be retained after compression, to avoid accidental compression triggering when the target number of rounds is reached. For example, when the target number of rounds to be retained is 20, the preset compression threshold can be set to 25 rounds. Compression is only triggered when the actual number of rounds reaches 25, and the number of rounds after compression drops back to 20. The difference between the compression trigger threshold and the target number of rounds to be retained (i.e., a buffer margin of 5 rounds) effectively avoids frequent jitter caused by repeatedly triggering compression at the critical value.

[0098] The preset quantity threshold is a trigger condition based on the number of tokens. The value of the preset quantity threshold can be configured according to the context window size of the target model. For example, compression is triggered when the total number of tokens in the historical dialogue records exceeds 80% of the context window of the target model, so as to ensure that the input sequence will not exceed the context window limit of the target model due to the excessive length of the historical records.

[0099] For example, online compression is triggered when the number of dialogue rounds in the buffer `recent_rounds` reaches the compression trigger threshold (25 rounds, higher than the target retention amount of 20 rounds) or the total number of tokens exceeds the preset limit. It is understood that the extracted dialogue data is not stored merely as an independent batch summary, but rather as part of the overall dialogue information for the day and is included in the daily summary. To ensure the integrity and continuity of cross-day dialogue memory, a daily summary process can be executed at a preset fixed time each day (e.g., during off-peak hours in the early morning), uniformly compressing and summarizing all dialogue rounds corresponding to the first and second memory information generated that day. Specifically, the oldest batch of rounds is extracted, the dialogue text sequence is input into a preset second model, and the preset second model is instructed to compress this dialogue segment into a coherent summary text. The summary text output by the preset second model is used as the target summary field.

[0100] Read the round summaries (round_entities) corresponding to each dialogue record to be compressed, merge the keyword lists of all round summaries, and use the merged and deduplicated keyword set as the target prompt words.

[0101] Read the entity index `round_entities` corresponding to each dialogue record to be compressed from the historical dialogue records, merge the entity indexes of each round according to the preset entity categories, and perform deduplication on the merged entity categories; use the merged and deduplicated structured entity index as the target entity field.

[0102] Write the target summary field, target prompt words, and target entity field into the Summary file for that day.

[0103] Understandably, if any anomalies occur during compression (such as lightweight model call timeouts or summary generation failures), all original rounds in `recent_rounds` must be retained without any truncation. In in-vehicle dialogue scenarios, it's preferable to incur some extra token overhead rather than risk losing crucial dialogue history due to system anomalies.

[0104] In one example, reference Figure 4 , Figure 4This is a schematic diagram of the user dialogue writing process in the dialogue method of this application. During each round of user dialogue writing, the metadata of the pre-generated round summary (round_summary) and entity index (round_entities) are synchronously called using a preset second model and written to disk along with the original dialogue text. When the number of rounds in the historical dialogue records reaches a preset compression threshold (e.g., 25 rounds) or the number of tokens exceeds a preset threshold, online compression is performed. The oldest batch of dialogue records to be compressed is extracted, and the preset second model is called to generate the target summary field `abstract`. Simultaneously, the round summaries (round_summary) of each round to be compressed are directly aggregated to generate the target prompt words `topics`, and the entity indexes (round_entities) of each round to be compressed are aggregated to generate the target entity field `entity_index`. These three data items together constitute the target summary file and are stored in persistent storage. If the compression conditions are not met, compression is skipped, the original text is retained, and accumulation continues.

[0105] Furthermore, after the day's conversations are completed, a daily summary can be performed to periodically clear the buffer. This requires generating a cross-day summary file. The diagram illustrates three complementary triggering methods: scheduled tasks, idle triggers, and lazy execution fallback. Scheduled tasks execute automatically at a preset time each day; idle triggers execute when the system has been idle for a preset duration; and lazy execution fallback checks upon receiving the first request the following day, and executes if the previous day's summary is not yet complete. Successful execution of any of these three methods completes the generation of the cross-day summary. Subsequent triggers that detect completion skip this step, ensuring the continuity of cross-day conversation memory and data security.

[0106] Understandably, when the duration of a summary file in storage exceeds a preset long-term retention threshold (e.g., 15 days), the summary files exceeding the preset long-term retention threshold can be further aggregated into long-term summaries, such as higher-level summaries organized monthly, to free up storage space and generate ultra-long-term conversational memories, thereby freeing the memory window from the limitation of a fixed number of days.

[0107] In this embodiment, a lightweight model is invoked to generate two metadata items, a round summary and an entity index, during each round of dialogue writing. This distributes the computational overhead of entity extraction and summary generation across the writing stage of each round of dialogue. When online compression is triggered subsequently, the round summaries of each round of dialogue can be read directly to aggregate the target prompt words, and the entity indexes of each round of dialogue can be read to aggregate the target entity fields, without having to re-invoke the model to extract entities or generate summaries during the compression stage. This reduces latency and resource consumption during the compression stage.

[0108] For example, to help understand the implementation flow of the model dialogue method obtained by combining this embodiment with the above embodiment one, please refer to... Figure 5 , Figure 5This is a simplified flowchart of the model dialogue method in this application. Specifically, the model dialogue method consists of three parts: intent recognition, memory recall, and role-based injection. User input undergoes memory injection judgment at the intent recognition node. If memory injection is not required, only the original text from the most recent N1 rounds (e.g., the most recent 3 rounds) of Layer 1 is loaded to complete the response with minimal overhead. If memory injection is required, Layer 2 performs full recall and Layer 3 performs two-stage retrieval concurrently. Layer 2 directly loads all original dialogue texts from the short-term storage area, excluding the most recent 3 rounds. Layer 3 first performs a coarse keyword screening using topics in the summary file; if there is zero match, it switches to entity_index for fallback matching, and then performs LLM fine screening to determine relevant summaries. After determining memory recall, each memory information is injected according to role-based partitioning. The Layer 3 summary is placed in the System message position, forming a system-level background together with the system persona and knowledge base. Layer 2 recall rounds and the most recent round of Layer 1 are split into user / assistant message pairs in ascending chronological order and inserted into the dialogue role message segment. The current user's question is used as the last user message, and together they form a complete input sequence to be submitted to the target model to generate an answer.

[0109] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the dialogue method of this application. Any simple transformations based on this technical concept are within the protection scope of this application.

[0110] This application also provides a model dialogue device, please refer to... Figure 6 The model dialogue device includes: The acquisition module 10 is used to acquire first memory information and the target question input by the user. The first memory information is the historical dialogue record between the user and the target model. The judgment module 20 is used to determine whether the target problem has a memory recall requirement. The determination module 30 is used to obtain second memory information and determine third memory information according to the summary file when there is a memory recall requirement for the target problem. The second memory information is the dialogue record in the historical dialogue record that is located before the first memory information. The summary file is generated by compressing the historical dialogue record before the second memory information. Generation module 40 is configured to generate a first input sequence based on the target problem, the first memory information, the second memory information, and the third memory information; and The input module 50 is used to input the first input sequence into the target model to obtain the first response result of the target question.

[0111] The model dialogue device provided in this application, employing the model dialogue method in the above embodiments, can solve the technical problem that existing dialogue model memory retrieval methods struggle to balance the breadth of historical memory coverage with the operational efficiency of model reasoning. Compared with the prior art, the beneficial effects of the model dialogue device provided in this application are the same as those of the model dialogue method provided in the above embodiments, and other technical features in the model dialogue device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0112] This application provides a model dialogue device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, which are executed by the at least one processor to enable the at least one processor to perform the model dialogue method in Embodiment 1 above.

[0113] The following is for reference. Figure 7 The diagram illustrates a structural schematic suitable for implementing the model dialogue device in the embodiments of this application. The model dialogue device in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 7 The illustrated model dialogue device is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0114] like Figure 7As shown, the model dialogue device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory 1002 or a program loaded from a storage device 1003 into a random access memory 1004. The random access memory 1004 also stores various programs and data required for the operation of the model dialogue device. The processing unit 1001, the read-only memory 1002, and the random access memory 1004 are interconnected via a bus 1005. An input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to the input / output interface 1006: input devices 1007 including, for example, a touch screen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. Communication device 1009 allows the model dialogue device to communicate wirelessly or wiredly with other devices to exchange data. Although model dialogue devices with various systems are shown in the figures, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0115] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0116] The model dialogue device provided in this application, employing the model dialogue method in the above embodiments, can solve the technical problem that existing dialogue model memory retrieval methods struggle to balance the breadth of historical memory coverage with the operational efficiency of model reasoning. Compared with the prior art, the beneficial effects of the model dialogue device provided in this application are the same as those of the model dialogue method provided in the above embodiments, and other technical features in this model dialogue device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0117] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0118] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0119] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the model dialogue method in the above embodiments.

[0120] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections with one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0121] The aforementioned computer-readable storage medium may be included in the model dialogue device; or it may exist independently and not be assembled into the model dialogue device.

[0122] The aforementioned computer-readable storage medium carries one or more programs, which, when executed by the model dialogue device, cause the model dialogue device to perform the model dialogue method described above.

[0123] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0124] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0125] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0126] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., computer programs) for executing the above-described model dialogue method. This solves the technical problem that existing dialogue model memory retrieval methods struggle to balance the breadth of historical memory coverage with the operational efficiency of model inference. Compared to the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the model dialogue method provided in the above embodiments, and will not be elaborated upon here.

[0127] The above description is only a part of the embodiments of this application and does not limit the scope of this application. All equivalent structural transformations made under the technical concept of this application and using the content of this application specification and drawings, or direct / indirect applications in other related technical fields, are included within the protection scope of this application.

[0128] It should be noted that the data collection, tag management, rule setting, and push decision-making processes involved in this application are designed to work with other technical features to solve technical problems. They do not involve or support any illegal activities. Any data processing that may violate laws and regulations (such as unauthorized collection of privacy data, generation of discriminatory tags, setting unfair rules, or pushing illegal information) is not within the scope of protection of this application's technical solution. Of course, the user data in this application will be encrypted, anonymized, or de-identified before storage to ensure user data security.

Claims

1. A model dialogue method, characterized by, The model dialogue method includes: Acquire first memory information and the target question input by the user. The first memory information is the historical dialogue record between the user and the target model. Determine whether the target problem requires memory recall; When there is a memory recall requirement for the target problem, second memory information is obtained, and third memory information is determined according to the summary file. The second memory information is the dialogue record in the historical dialogue record that is located before the first memory information. The summary file is generated by compressing the historical dialogue record before the second memory information. Generate a first input sequence based on the target problem, the first memory information, the second memory information, and the third memory information; and The first input sequence is input into the target model to obtain the first response result to the target question.

2. The model conversation method of claim 1, wherein, The step of determining the third memory information based on the digest file includes: The keywords of the summary file are matched with the target question, and the files in the summary file with a matching degree greater than a first preset threshold are used as the first summary file according to the matching results; The target question and the summary field of the first summary file are combined to form a filter suggestion; Input the filtering prompts into the preset first model and output the judgment result; and Based on the judgment result, a second summary file is determined from the first summary file as the third memory information of the target problem.

3. The model dialogue method of claim 2, wherein, The step of matching the keywords of the summary file with the target question further includes: If there is no file with a matching degree greater than the first preset threshold in the summary file, then obtain the entity fields of each summary file; Match the entity fields with the target question; and Files with a matching degree greater than a second preset threshold in the summary file are used as the first summary file.

4. The model dialogue method of claim 1, wherein, The step of generating the first input sequence based on the target problem, the first memory information, the second memory information, and the third memory information includes: The system role message segment is determined based on the third memory information and preset data; The first memory information and the second memory information are split into message pairs according to rounds, and the dialogue role message segments are determined based on the message pairs; and The system role message segment, the dialogue role message segment, and the target question are concatenated to generate the first input sequence.

5. The model conversation method of any one of claims 1 to 4, wherein, After the step of determining whether the target problem has a memory recall requirement, the method further includes: If there is no memory recall requirement for the target problem, a second input sequence is generated based on the target problem and the first memory information; and The second input sequence is input into the target model to obtain the second response result to the target question.

6. The model dialogue method as described in any one of claims 1 to 4, characterized in that, After the step of inputting the first input sequence into the target model to obtain the first response result of the target question, the method further includes: Input the target question and the first response result into a preset second model, and output a round summary and entity index of the current round of dialogue; and The current round of dialogue is written into the historical dialogue record based on the round summary and the entity index.

7. The model dialogue method as described in claim 6, characterized in that, After the step of writing the current round of dialogue record into the historical dialogue record based on the round summary and the entity index, the method further includes: If the number of dialogue rounds in the historical dialogue record is greater than a preset compression threshold, or if the number of lexical units in the historical dialogue record exceeds a preset quantity threshold, obtain the dialogue record to be compressed from the historical dialogue record. The dialogue records to be compressed are compressed to generate a target summary field; Target prompt words are determined based on the turn summaries of each of the dialogue records to be compressed, and target entity fields are determined based on the entity indexes of each of the dialogue records to be compressed; and A target summary file is generated based on the target summary field, the target prompt word, and the target entity field.

8. A model dialogue device, characterized in that, The device includes: The acquisition module is used to acquire first memory information and the target question input by the user. The first memory information is the historical dialogue record between the user and the target model. The judgment module is used to determine whether the target problem has a memory recall requirement; The determination module is used to obtain second memory information when there is a memory recall requirement for the target problem, and determine third memory information according to the summary file. The second memory information is the dialogue record in the historical dialogue record that is located before the first memory information. The summary file is generated by compressing the historical dialogue record before the second memory information. The generation module is configured to generate a first input sequence based on the target problem, the first memory information, the second memory information, and the third memory information; and The input module is used to input the first input sequence into the target model to obtain the first response result of the target question.

9. A model dialogue device, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the model dialogue method as described in any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the model dialogue method as described in any one of claims 1 to 7.

Images