Memory management method and device for long-time multi-turn dialogue
By constructing causal dependency graphs and conflict relationship graphs to filter memory units, the inconsistency problem of memory management in long-duration, multi-turn dialogues is solved, the causal closure and verifiable source of memory content are realized, and the output quality and reliability of the dialogue system are improved.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- CHANGSHA DUXACT BIOTECH CO LTD
- Filing Date
- 2026-03-10
- Publication Date
- 2026-06-09
AI Technical Summary
Existing large-scale model dialogue systems suffer from problems such as incomplete semantic fragments, difficulty in constraining factual conflicts, difficulty in tracing memory sources, and unstable budget utilization in long-duration, multi-turn dialogues, resulting in poor output consistency and reliability.
By constructing causal dependency graphs and conflict graphs of atomic memory units, a set of demand keys is generated. Based on the causal dependency graphs, conflict graphs, and token budgets, the candidate set is filtered, and memory capsules are constructed to generate target answers, ensuring the causal closure and verifiable source of the memory content.
It improves the availability of memorized content and output consistency in long-duration, multi-turn dialogues, avoids contextual breaks and factual conflicts, and enhances the overall output quality and engineering controllability of the dialogue system.
Smart Images

Figure CN122173608A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of natural language processing technology, and in particular to a memory management method and apparatus for long-duration, multi-turn dialogues. This application also relates to a computing device and a computer-readable storage medium. Background Technology
[0002] Large-scale dialogue systems, in practical deployments, are limited by context length and computational resource costs, making it difficult to carry complete historical dialogues with each generation. Existing dialogue memory management typically employs methods such as truncating recent dialogues, summarizing and compressing, and semantic retrieval to select and append portions of historical content to the model's input prompts within a fixed token budget. These methods suffer from problems such as incomplete semantic fragments, difficulty in constraining factual conflicts, difficulty in tracing the source of memory, and unstable budget utilization in scenarios involving long dialogues, multiple tool calls, and multiple topic switching.
[0003] Specifically, incomplete semantic fragments manifest in the fact that the retrieved content is often discrete, lacking necessary context and consequences, such as missing corresponding user questions, tool call parameters, and tool outputs, leading to insufficient semantic closure and inference bias or factual inconsistency in the output. The difficulty in constraining factual conflicts arises when the same entity / field is updated at different times, such as address, version number, or convention changes; relying solely on similarity for retrieval may simultaneously include conflicting information, resulting in contradictory or inconsistent output. The difficulty in tracing the source of memory manifests in the lack of verifiable source links for memories concatenated into the model's input prompts, making it difficult to audit or verify the basis of the model's output. Unstable budget utilization manifests in the fact that when selecting only from the nearest window and related recalls, the proportion of effective information in the memory segment and output consistency fluctuates significantly under the same budget, influenced by fragment length and redundancy. Summary of the Invention
[0004] In view of this, embodiments of this application provide a memory management method for long-duration, multi-turn dialogues to address the technical deficiencies in the prior art. Embodiments of this application also provide a memory management device for long-duration, multi-turn dialogues, a computing device, and a computer-readable storage medium.
[0005] According to a first aspect of the embodiments of this application, a memory management method for long-duration, multi-turn dialogues is provided, comprising: Based on the received session message stream, memory units are extracted to obtain all atomic memory units; Construct a causal dependency graph of all the atomic memory units and a conflict relationship graph of the atomic memory units; In response to received user questions, generate a set of demand keys and determine the token budget; Based on the user's question, a candidate set is obtained by selecting from all the atomic memory units; The candidate set is filtered using the causal dependency graph, the conflict relationship graph, the demand key set, and the token budget, and a memory capsule is constructed based on the filtering results. Based on the memory capsule, a target answer corresponding to the user's question is generated.
[0006] Optionally, the step of extracting memory units based on the received session message stream to obtain all atomic memory units includes: Receive the session message stream; Extract and save the structured fields from the session message stream, wherein the structured fields include role, tool call, tool output, timestamp and message link identifier; Based on the saved structured fields, memory cell extraction is performed to generate all the atomic memory cells, wherein the atomic memory cells include memory cell identifier, memory cell type, normalization key, structured value, generation time, source message identifier set, confidence level, token cost, and auxiliary fields.
[0007] Optionally, after constructing the causal dependency graph associated with all the atomic memory units and the conflict relationship graph associated with the atomic memory units, the method further includes: Receive new dialogue message streams and construct atomic memory units corresponding to the new dialogue message streams; Based on the atomic memory unit corresponding to the newly added dialogue message stream, the causal dependency graph and the conflict relationship graph are incrementally updated.
[0008] Optionally, the step of filtering the candidate set using the causal dependency graph, the conflict relationship graph, the demand key set, and the token budget, and constructing a memory capsule based on the filtering results, includes: The candidate set is filtered using the causal dependency graph, the conflict relationship graph, the demand key set, and the token budget to obtain the minimum causal closure set; The memory capsule is obtained by performing stability sorting and serialization encoding on the set of minimal causal closures.
[0009] Optionally, the step of filtering the candidate set using the causal dependency graph, the conflict relationship graph, the demand key set, and the token budget to obtain the minimum causal closure set includes: Based on the conflict relationship diagram, mutually exclusive atomic memory units in the candidate set are removed to obtain the first subset; Based on the causal dependency graph, causal closure expansion is performed on the first subset to complete the dependency predecessors, resulting in the second subset; By processing the second subset using the demand key set and the token budget, the minimum causal closure set is obtained.
[0010] Optionally, the step of processing the second subset using the demand key set and the token budget to obtain the minimal causal closure set includes: For the atomic memory units contained in the second subset, under the premise of prioritizing the requirement key set, candidate closure components are selected based on the token budget, and non-essential units not included in the minimum causal closure set are eliminated in descending order of contribution to obtain the minimum causal closure set.
[0011] Optionally, the memory capsule includes a capsule identifier, a capsule issue identifier, a capsule token budget, a list of memory cells, a digest check value, a source index, and capsule auxiliary fields.
[0012] According to a second aspect of the embodiments of this application, a memory management device for long-duration, multi-turn dialogues is provided, comprising: The extraction module is configured to extract memory units based on the received session message stream to obtain all atomic memory units. The building module is configured to build a causal dependency graph associated with all the atomic memory units, and a conflict relationship graph associated with the atomic memory units; The response module is configured to generate a set of demand keys and determine the token budget in response to received user questions; The selection module is configured to select from all the atomic memory units based on the user question to obtain a candidate set; The filtering module is configured to filter the candidate set using the causal dependency graph, the conflict relationship graph, the demand key set, and the token budget, and construct a memory capsule based on the filtering results; The response module is configured to generate a target answer corresponding to the user's question based on the memory capsule.
[0013] According to a third aspect of the embodiments of this application, a computing device is provided, comprising: Memory and processor; The memory is used to store computer-executable instructions, and the processor implements the steps of the memory management method for long-duration multi-turn dialogue when executing the computer-executable instructions.
[0014] According to a fourth aspect of the embodiments of this application, a computer-readable storage medium is provided that stores computer-executable instructions, which, when executed by a processor, implement the steps of the memory management method for long-duration multi-turn dialogues.
[0015] According to a fifth aspect of the embodiments of this application, a chip is provided that stores a computer program, which, when executed by the chip, implements the steps of the memory management method for long-duration multi-turn dialogue.
[0016] The memory management method for long-duration, multi-turn dialogues provided in this application extracts memory units from the received conversation message stream to obtain all atomic memory units; constructs a causal dependency graph and a conflict relationship graph associated with all the atomic memory units; generates a demand key set and determines a token budget in response to a received user question; selects candidates from all the atomic memory units based on the user question to obtain a candidate set; filters the candidate set using the causal dependency graph, the conflict relationship graph, the demand key set, and the token budget, and constructs a memory capsule based on the filtering results; and generates a target answer corresponding to the user question based on the memory capsule. This method enables long-term memories to have causal closures containing necessary antecedents and consequences when recalled, and provides the output memory content with a structured representation that verifies sources and controls conflicts, thereby improving the availability and output consistency of memory segments under a fixed token budget. Attached Figure Description
[0017] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0018] Figure 1 This is a flowchart of a memory management method for long-duration, multi-turn dialogue provided in an embodiment of this application; Figure 2 This is a schematic diagram of the system structure of a memory management method for long-duration, multi-turn dialogue provided in an embodiment of this application; Figure 3 This is a flowchart of memory unit extraction and mapping of a memory management method for long-duration, multi-turn dialogue provided in an embodiment of this application; Figure 4 This is a flowchart illustrating the causal closure selection process of a memory management method for long-duration, multi-turn dialogues, provided in one embodiment of this application. Figure 5This is a schematic diagram of the structure of a memory management device for long-duration, multi-turn dialogue provided in an embodiment of this application; Figure 6 This is a structural block diagram of a computing device provided in one embodiment of this application. Detailed Implementation
[0019] Many specific details are set forth in the following description to provide a full understanding of this application. However, this application can be implemented in many other ways different from those described herein, and those skilled in the art can make similar extensions without departing from the spirit of this application; therefore, this application is not limited to the specific embodiments disclosed below.
[0020] The terminology used in one or more embodiments of this application is for the purpose of describing particular embodiments only and is not intended to limit the scope of one or more embodiments of this application. The singular forms “a,” “the,” and “the” used in one or more embodiments of this application and in the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” used in one or more embodiments of this application refers to and includes any or all possible combinations of one or more associated listed items.
[0021] It should be understood that although the terms first, second, etc., may be used to describe various information in one or more embodiments of this application, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, first may also be referred to as second without departing from the scope of one or more embodiments of this application, and similarly, second may also be referred to as first.
[0022] First, the terminology used in one or more embodiments of the present invention will be explained.
[0023] Atomic memory unit: A basic memory information extracted from a dialogue by a MemUnit to represent a single fact, intention, constraint, or tool-related content.
[0024] Normalized Key: A normalized key is used to uniformly identify key values of the same type of memory content, making it easier to determine whether different memories point to the same semantic object.
[0025] Source ID: The Source ID identifies the dialogue message or tool call from which the memory unit originated, and is used for subsequent tracing.
[0026] Token Cost: Token Cost represents the number of tokens used after a memory unit is placed into the model context, and is used to control the context budget.
[0027] Causal Dependency: This means that one memory is semantically dependent on another memory, and both need to be retained when used.
[0028] Causal dependency graph: Gd is a graph structure used to describe the causal dependencies between memory units.
[0029] Conflict Relation: This refers to a situation where two memories are inconsistent or contradictory in content.
[0030] Conflict graph: Gc is a structure used to record the conflict relationships between memory units.
[0031] Causal closure: The process by which a causal closure fills in the necessary prior memories it depends on when selecting a memory.
[0032] Minimal Causal Closure Set: The smallest semantically complete set of memories selected while satisfying the current requirements.
[0033] This application provides a memory management method for long-duration, multi-turn dialogues. This application also relates to a memory management device for long-duration, multi-turn dialogues, a computing device, and a computer-readable storage medium, which will be described in detail in the following embodiments.
[0034] Figure 1 The flowchart illustrates a memory management method for long-duration, multi-turn dialogues according to an embodiment of this application, specifically including the following steps: Step S102: Based on the received session message stream, extract memory units to obtain all atomic memory units; Step S104: Construct a causal dependency graph of all the atomic memory units and a conflict relationship graph of the atomic memory units; Step S106: In response to the received user question, generate a set of demand keys and determine the token budget; Step S108: Based on the user question, select from all the atomic memory units to obtain a candidate set; Step S110: Filter the candidate set using the causal dependency graph, the conflict relationship graph, the demand key set, and the token budget, and construct a memory capsule based on the filtering results; Step S112: Based on the memory capsule, generate the target answer corresponding to the user's question.
[0035] When implementing dialogue systems, memory management often needs to balance online inference and offline maintenance. On the one hand, it should avoid blocking the inference chain as much as possible, and on the other hand, it should ensure that the recalled content is self-consistent and traceable. To ensure this balance, the dialogue memory management system in this embodiment is geared towards long-duration, multi-turn dialogues, such as... Figure 2 The system architecture diagram of a memory management method for long-duration, multi-turn dialogues is shown. Its core components include message and memory storage, memory unit extraction, graph updating and causal and conflict graph construction (including user question q, key requirement generation Kq), query intent and key requirement generation, causal closure selection, and memory capsule encoding (including capsule encoding / digest and output capsule text). Specifically, message storage is responsible for saving session messages and their order relationships, roles, tool call information, and timestamps; memory unit extraction is responsible for extracting atomic memory units from the message stream and recording source identifiers and confidence levels; causal and conflict graph construction is responsible for constructing causal dependencies and conflict relationships between memory units; query intent and key requirement generation is responsible for generating the set of fact keys / constraint keys to be covered from the user question; causal closure selection mainly addresses the problem of "how to select the most usable one within the budget," selecting the minimum set of causal closures that satisfies the coverage constraints under a token budget; and memory capsule encoding is responsible for encoding the selected memory units into a consistent, verifiable, structured text representation and outputting it.
[0036] Therefore, by extracting memory units from the conversation message stream, historical dialogues are no longer treated as scattered text fragments. Instead, key information formed during the dialogue is abstracted into atomic memory units carrying unified key identifiers, source information, and length metrics. Based on this, causal dependency graphs and conflict relationship graphs are constructed to explicitly depict the cause-and-effect relationships and conflict relationships between memories. Upon receiving a user's question, corresponding memory retrieval is required. During the memory retrieval phase, the causal dependency graph and conflict relationship graph introduce causal closure and mutual exclusion constraints to select a minimal set of memories within a limited context budget. This set must cover the information required for the current question, be semantically complete, and not contain contradictory content. Finally, it is organized and output using a deterministic memory capsule approach. This approach utilizes a structured representation of memory units, a multi-constraint selection mechanism based on causal and conflict relationships, and a memory capsule design that deterministically encodes and verifies output memories. Compared to solutions relying solely on nearest-nearest windows or similarity retrieval, this approach effectively avoids context breaks and factual conflicts, improving the stability, consistency, and traceability of memory use in long-duration dialogue scenarios, thereby enhancing the overall output quality and engineering controllability of the dialogue system.
[0037] Furthermore, in step S102, the process of extracting memory units based on the received session message stream to obtain all atomic memory units is specifically implemented as follows in this embodiment: Receive the session message stream; extract and save the structured fields from the session message stream, wherein the structured fields include role, tool call, tool output, timestamp and message link identifier; based on the saved structured fields, perform memory unit extraction to generate all the atomic memory units, wherein the atomic memory unit includes memory unit identifier, memory unit type, normalization key, structured value, generation time, source message identifier set, confidence level, token cost and auxiliary fields.
[0038] The atomic memory unit MemUnit contains the following fields: unit_id (memory unit identifier); type (memory unit type, commonly including user intent, facts, preferences, constraints / rules, and tool calls and results); key (normalization key, mainly responsible for conflict detection and constraint coverage, such as user.address, project.deadline, tool.search.result); value (structured value or text value); time (generation time); source_ids (source message identifier set); confidence; token_cost (token cost, mainly used as a length measure for budget calculation); and auxiliary fields, the activation of which depends on business and cost constraints, specifically including schema (valued pattern and valid interval), [valid_from, valid_to]; negated; version; salience; evidence summary; and created_by (generation source type, values include extractor, rewrite, tool).
[0039] The normalized key is defined as a hierarchical namespace key, specifically: , Here, ns, entity, and attr are all string fragments, with "." as the field separator; ns represents the domain namespace, entity represents the combined field of entity category and entity identifier, and attr represents the attribute name; in some scenarios, entity consists of entity_type and entity_id, that is: , Here, `entity_type` represents the entity type, indicating the semantic category of the entity, used to distinguish different types of object domains; `entity_id` represents the entity identifier, indicating the specific instance identifier under the corresponding entity category constraint, used to uniquely identify entity objects under that category; `entity` is composed of `entity_type` and `entity_id`, used to stably locate specific entities in both entity category and instance dimensions, thereby supporting the distinction and conflict detection between entities of the same type. When the entity identifier is missing, `entity_id` takes the stable identifier within the session, ensuring key consistency within the same session; and to ensure key stability and resolvability, `ns` / `entity` / `attr` are normalized. The normalization process involves: removing leading and trailing whitespace and converting to lowercase; normalizing synonyms into a unified string through a mapping table; performing percent sign encoding on the separators "." and ":" and control characters to avoid semantic conflicts with the separators; and concatenating the normalized fragments to obtain the final key. Therefore, the key generation process is achieved through entity recognition and referential resolution, entity category and domain namespace mapping, attribute synonym normalization, and stable key encoding. It should be noted that when a stable entity identifier cannot be obtained, the entity uses a local identifier within the session or a stable identifier derived from source_ids to ensure consistency of keys within the same session.
[0040] Furthermore, the token cost is defined as the number of tokens encoded in the atomic memory unit according to the capsule serialization format. The specific process for calculating the token cost is as follows: enc(u) is obtained by encoding according to a fixed field order and a fixed escape rule; TokenCount(enc(u)) is calculated using a word segmenter consistent with the dialogue model, where TokenCount(·) is the token counting function; the result is used as the token cost and updated synchronously with the unit update.
[0041] Based on this, during the memory unit extraction process, issues arise such as irregular upstream text, inconsistent tool output fields, and the possibility of facts and preferences being interspersed within the same sentence. Therefore, it's crucial to ensure the traceability of information splitting and avoid excessive fusion in the early stages. Fusion and rewriting can be performed asynchronously to prevent the loss of source links. The extraction process uses the conversation message stream as input, including roles, text content or chunked content, tool call information, tool output information, timestamps, link identifiers, and message identifiers. For each message generating one or more MemUnits, the process involves extracting Intent from user messages, where the key corresponds to the normalized key of the user's current requirement domain, and the value is a structured representation of the requirement. Then, Commitment and Constraint are extracted from assistant messages, primarily expressing commitments, plans, rules, prohibitions, and constraints. ToolCall is extracted from tool calls, with the value containing the tool name, parameter summary, and call identifier. ToolResult is extracted from tool output, with the value being an output summary and key fields. Finally, Fact statements in user or assistant messages are extracted, and Preference statements are extracted. The extracted results are written to the MemUnit library and bound to source_ids to form a traceable chain of evidence.
[0042] Then, confidence and evidence are generated for each MemUnit. Confidence is determined by the consistency of extraction, the pass rate of structured verification, the reliability of the source, and the strength of repeated verification. Evidence is a verifiable evidence summary, which includes the source message identifier and the necessary original text fragment location information. When the same key has consistent values in multiple sources, confidence is increased and salience is added.
[0043] In step S104, during the process of constructing the causal dependency graph and the conflict relationship graph associated with atomic memory units, the causal dependency graph is denoted as Gd=(Vd,Ed), and the conflict relationship graph is denoted as Gc=(Vc,Ec).
[0044] For a causal dependency graph, node Vd is an atomic memory unit, and a directed edge (u→v)∈Ed indicates that v semantically depends on u, satisfying the closure constraint that if v is chosen, u must also be chosen. The construction of causal edges typically follows this pattern: ToolResult depends on its corresponding ToolCall and its predecessor Intent; Commitment depends on the Intent that triggered the commitment and the key fact unit; units generated by summary rewriting depend on their original source units. Furthermore, additional dependency edges are needed to reduce broken chains. This process includes: for units generated in the same round of dialogue, establishing dependency edges from user-triggered units to assistant-generated units; for tool call rounds, establishing dependency edges from ToolCall units to ToolResult units; for units referencing historical facts, establishing dependency edges from the referenced fact unit to the current unit; and for units generated by rewriting, establishing dependency edges from the original unit to the rewriting unit. Here, ToolResult represents the completeness of the tool execution chain; ToolCall represents the triggering source of the commitment; Intent represents the semantic inheritance chain; and Commitment represents the explicit representation of the reference relationship.
[0045] For the conflict graph, node Vc is an atomic memory unit; an undirected edge {u,v}∈Ec indicates a conflict between u and v, satisfying key(u)=key(v) and value(u)≠value(v); the determination is also based on signals such as time, confidence level, and version identifier. In practical applications, it is unnecessary to cover all theoretical extreme cases. The main design goal is to focus on common scenarios in real dialogue systems. Overly fine constraints often lead to unnecessary complexity. Therefore, a trade-off must be made between the scope of closure and the granularity of conflict. For example, in handling multiple values with the same key / negative facts, priority should be given to ensuring that obviously contradictory content is not sent to the prompt input at the same time.
[0046] Conflict relationships are mainly reflected in the mutual exclusion constraints during the selection phase, meaning that conflicting values with the same key will not be placed into the output capsule simultaneously. In practical applications, conflict edge generation is usually triggered by the following situations: key(u) = key(v), and the valid intervals overlap; key(u) = key(v), and one of them has negated=true; key(u) = key(v), and the versions are different and no substitution chain has been formed; key(u) and key(v) are in the same mutually exclusive key group. Specific conflict edge generation can be enabled according to business needs.
[0047] Therefore, after receiving the session message stream, the structured fields are extracted and saved first. This clarifies the core content included in the structured fields, such as roles, tool calls, tool outputs, timestamps, and message link identifiers. This effectively preserves key auxiliary information in the session data, providing comprehensive contextual support for subsequent extraction of atomic memory units. This allows the extracted atomic memory units to reflect their generation scenario, associated roles, and message links in conjunction with these structured fields, improving the relevance and effectiveness of the atomic memory units. By clarifying the core fields included in the atomic memory units, such as memory unit identifier, memory unit type, normalization key, and structured value, a standardized definition of atomic memory units is achieved. This ensures that the extracted atomic memory units have a unified format and complete content across different scenarios, avoiding problems such as the inability to perform subsequent filtering and graph building steps due to missing fields. For example, the token cost field provides a basis for subsequent token budget control, the generation time field provides support for the temporal filtering of memories, and the memory unit identifier... This approach facilitates the tracing and management of memories. By extracting memory units based on stored structured fields, a standardized extraction process is established, ensuring that the extracted atomic memory units accurately correspond to the core content of the conversation information. This effectively avoids redundancy and fragmentation of memory units, reduces the difficulty and workload of subsequent screening, and improves the overall efficiency of memory management. Through the association between the source message identifier set and message link identifier in the atomic memory unit, precise binding between the atomic memory unit and the original conversation message is achieved. If memory deviations or logical errors occur later, the original message can be quickly traced back, facilitating problem investigation and method optimization, and improving the reliability and maintainability of the memory management method. The standardized atomic memory unit extraction results ensure that the subsequent construction of causal dependency graphs and conflict relationship graphs is more accurate, the selection of candidate sets is more efficient, and the construction of memory capsules is more standardized, thereby improving the overall effectiveness of the long-term multi-turn dialogue memory management method and ensuring that the generated target answer is more accurate and coherent.
[0048] Furthermore, in step S104, after constructing the causal dependency graph and conflict relationship graph associated with all atomic memory units, if there are newly added dialogue message streams, the newly added content needs to be aggregated into the original data. Specifically, in this embodiment, the implementation method is as follows: Receive new dialogue message streams and construct atomic memory units corresponding to the new dialogue message streams; based on the atomic memory units corresponding to the new dialogue message streams, incrementally update the causal dependency graph and the conflict relationship graph.
[0049] Among them, such as Figure 3The provided memory management method for long-duration, multi-turn dialogues includes a flowchart of memory unit extraction and graph construction. MemUnit, Gd, and Gc are maintained incrementally. Specifically, this includes: adding new messages, i.e., adding new dialogue message streams only triggers new unit extraction and local graph updates; Gd uses a reverse adjacency list to calculate closures, and the complexity of closure unpacking is proportional to the number of dependent edges traversed; Gc updates by key-based buckets, with stable internal sorting rules within each bucket (see version and time for details); the online path only performs candidate recall, closure selection, and capsule encoding, while graph updates and rewriting are performed asynchronously.
[0050] In real-world use cases, memory cell extraction, graph updates, and rewriting are typically not completed synchronously along the same path. Instead, they converge gradually through a queue / batch processing approach. This means that the online link relies on the most recent stable snapshot to ensure latency, while the background task is responsible for filling in the dependency edges and substitution relationships. This trade-off ensures more controllable online performance.
[0051] Specifically, for a newly added MemUnit, causal dependency edges of Gd are first generated according to type rules; then conflict edges of Gc are generated or updated according to key bucketing; when a replacement chain is detected, such as a version or time update, the valid range of the replaced unit is updated to an invalid state. In actual implementation, graph structure maintenance often requires fault tolerance, that is, tool output may arrive late, and the extractor may backfill with higher quality MemUnits. Therefore, graph updates usually adopt an idempotent write and incremental correction strategy, allowing online availability to be guaranteed first, and then evidence and dependencies to be completed in the background.
[0052] Therefore, by receiving new dialogue message streams and constructing corresponding atomic memory units, the system can capture newly added memory information in long-duration, multi-turn dialogues in real time, ensuring that no newly generated memory units are missed. This provides a data foundation for incremental updates of the two graphs, enabling memory relationships to be updated in real time as the dialogue progresses, adapting to the dynamic scenario of continuously accumulating memory information in long-duration, multi-turn dialogues. By incrementally updating the causal dependency graph and conflict graph based on newly added atomic memory units, it is not necessary to rebuild the entire graph structure. Only the causal dependencies and conflict relationships between newly added atomic memory units and existing atomic memory units need to be analyzed, and these new relationships are added to the original graph. This significantly reduces system resource consumption and update time, ensuring that the system can respond to dialogue needs in real time and improving the efficiency of memory management. The incrementally updated causal dependency graph and conflict graph can accurately reflect the relationships between all atomic memory units, which is helpful when selecting candidate sets later. This approach fully considers the associations of newly added memories, avoiding the omission of new dependent memories or the neglect of new memory conflicts. It ensures that the selected memory information is more complete and logically consistent, thereby improving the accuracy and coherence of the target answer. The incremental update mechanism avoids the accumulation of biases in the associations. As the dialogue progresses, the two graphs remain up-to-date, ensuring that all subsequent memory management steps are based on accurate and timely associations, thus improving the stability and reliability of the entire memory management method. The implementation of the incremental update scheme enables long-duration, multi-turn dialogue systems to operate continuously and stably. Even with long dialogue durations and a large number of atomic memory units, it can efficiently manage memory associations without frequent system restarts or graph reconstruction, reducing system maintenance costs and expanding the application scenarios of the memory management method. It is particularly suitable for long-duration, multi-turn dialogue scenarios with large message volumes, such as intelligent customer service and long-term companion intelligent assistants.
[0053] In step S106, as Figure 4 The provided flowchart for a causal closure selection method for memory management in long-duration, multi-turn dialogues illustrates this approach. It parses the user question q to generate a set of requirement keys, denoted as Kq, where each key represents a fact / constraint that needs to be covered in answering the question. The generation of Kq includes extracting entity, attribute, and constraint representations from the user question and mapping them to normalized keys; extracting tool categories and necessary input / output keys for tool-type questions; and extracting the most recent commitment / planned node key for multi-turn continuation questions.
[0054] In step S108, as Figure 4 The flowchart of the causal closure selection method for memory management in long-term multi-turn dialogue is shown. The process of recalling the candidate set C from the stored memory unit set is as follows: recall based on key matching and synonym mapping; retrieval and recall based on semantic similarity of value or unit summary vector; and filtering based on topic / conversation scope.
[0055] Furthermore, in step S110, the process of filtering the candidate set using a causal dependency graph, conflict relationship graph, demand key set, and token budget, and constructing a memory capsule based on the filtering results, is specifically implemented as follows in this embodiment: The candidate set is filtered using the causal dependency graph, the conflict relationship graph, the demand key set, and the token budget to obtain the minimum causal closure set; the minimum causal closure set is then subjected to stability sorting and serialization encoding to obtain the memory capsule.
[0056] Furthermore, in the above steps, the process of filtering the candidate set through causal dependency graphs, conflict relationship graphs, demand key sets, and token budgets to obtain the minimum causal closure set is specifically implemented as follows in this embodiment: Based on the conflict relationship graph, mutually exclusive atomic memory units in the candidate set are removed to obtain a first subset; based on the causal dependency graph, causal closure expansion is performed on the first subset to complete the dependency predecessors, resulting in a second subset; the second subset is processed through the demand key set and the token budget to obtain the minimum causal closure set.
[0057] Furthermore, in the above steps, the process of processing the second subset using the demand key set and token budget to obtain the minimum causal closure set is specifically implemented as follows in this embodiment: For the atomic memory units contained in the second subset, under the premise of prioritizing the requirement key set, candidate closure components are selected based on the token budget, and non-essential units not included in the minimum causal closure set are eliminated in descending order of contribution to obtain the minimum causal closure set.
[0058] Here, candidate closure components represent atomic memory units contained in the candidate set, while non-essential units represent atomic memory units that do not overlap with the candidate set and the second sub-feature set. Therefore, by satisfying closure constraints and mutual exclusion constraints through conflict relationship graphs and causal dependency graphs, and further, under this premise, a secondary selection is performed through token budget. When the budget is insufficient, non-essential units not included in the minimum causal closure set are eliminated in descending order of contribution to obtain the minimum causal closure set.
[0059] like Figure 4 The flowchart of a causal closure selection method for memory management in long-duration, multi-turn dialogues is provided. For a candidate set C, a closure operator is defined, denoted as closure(·). Let closure(S) represent the smallest set of dependent predecessors that is repeatedly added to set S until no further additions are made, i.e., the second subset, expressed as: , Specifically, the process of dependency completion for set S is as follows: if there is a memory unit v in the set, and there is an edge (u→v) in the graph, it means that v is semantically dependent on u. Therefore, u needs to be added to the set. This process continues until no new dependency predecessors are added, resulting in a semantically complete minimal dependency closure set. It should be noted that closures may theoretically continue to expand, but for online dialogue systems, the core goal is to complete the minimum causal relationships required for an answer. Therefore, in practical use cases, the scope of closure edges is usually selected based on trade-offs. High-yield dependencies such as toolchains and commitment triggers are prioritized for closure, while low-yield, easily bloated dependencies are controlled through configuration or handled by asynchronous rewriting to avoid closure expansion crowding out the budget.
[0060] The second subset of the selected output, denoted as M, must satisfy the covering constraint, closure constraint, mutual exclusion constraint, and budget constraint. For the covering constraint, it can be expressed as for each k∈Kq, there exists u∈M such that key(u)=k; The closure constraint is represented as M=closure(M); the mutual exclusion constraint is represented as if {u,v}∈Ec, then u and v cannot be selected at the same time; the budget constraint is represented as sum(token_cost(u)) ≤ T_max, where T_max is the upper limit of the token budget.
[0061] As can be seen from the above, this embodiment does not cover all theoretical extreme cases, but rather focuses on common scenarios in actual dialogue systems as its main design goal. Therefore, excessively pursuing global optimization often leads to uncontrollable complexity and latency. Thus, a phased strategy of first satisfying coverage and closure, and then expanding benefits, is adopted. This is easier to explain and easier to handle degradation when abnormal data occurs. Under the premise of satisfying constraints, the selection module will give candidate units a comprehensive score. This comprehensive score is related to the relevance of the question, the confidence of the source, and the freshness of time. At the same time, it will penalize highly repetitive content to avoid piling up synonymous fragments within a limited budget.
[0062] To ensure output stability and reproducibility, the following consistency rules are adopted: when multiple candidates are difficult to prioritize in terms of scoring, the system uses a stable internal sorting rule for disambiguation; when selecting in case of conflict, priority is generally given to retaining those with more recent time and higher confidence; if they still cannot be distinguished, internal identifiers are used to stably break the tie; when the budget is insufficient, under the premise of satisfying the coverage constraint, closure constraint, and mutual exclusion constraint, priority is given to retaining the closure component covering Kq; non-essential units not included in the final set are removed in descending order of contribution.
[0063] While the selected atomic memory units can be directly applied, in real-world dialogue scenarios, answers are often not supported by a single fragment. Tool results require parameters and triggering intents, fact updates leave behind old values, and old and new rules may contradict each other. Therefore, the user question is first transformed into a set of keys that need to be covered. Then, the minimum causal closure is expanded from the candidates, and trade-offs are made under mutual exclusion and budget constraints. It should be noted that the closure and conflict granularity adopt an engineering-based approximation, aiming to make the prompt input usable, stable, and verifiable, rather than formalizing all edge cases to the point of being impractical.
[0064] For the coverage satisfaction stage and the benefit expansion stage included in the solution process, the coverage satisfaction stage forms a candidate unit set Uk for each k∈Kq; for each candidate in Uk, the cost and benefit of the closure({u}) are calculated; under mutual exclusion constraints, the set of closures that makes the coverage valid and minimizes the cost is selected and merged into M. The benefit expansion stage selects additional units under the remaining budget. Marginal benefits and marginal costs are defined for candidate unit u, with the marginal benefits as follows: , The marginal costs are as follows: , In terms of marginal revenue, M represents the set of currently selected memory units; u represents a candidate memory unit; closure({u}) represents the smallest causal closure set containing u and all its dependent predecessors; Gain() represents the revenue function of the set for the current user problem, used to measure the set's comprehensive contribution to demand key coverage, relevance, etc.; Δ(M,u) represents the additional revenue brought by adding candidate unit u along with its dependent closures to the current set M. In terms of marginal cost, token_cost(x) represents the number of tokens occupied by memory unit x after serialization; closure({u})\M represents the additional memory units that need to be added when u is added, which are not yet in M; Δcost(M,u) represents the additional token cost after adding u and its dependent closures.
[0065] Therefore, the above formula indicates how much additional benefit will be brought by adding candidate unit u and its dependent closures to the current selected set M, and how much additional token cost will be required. In actual selection, the cost-effectiveness of marginal benefit relative to the additional cost is used as the priority. Without violating mutual exclusion constraints, priority is given to adding closure components that can bring more new information but will not significantly crowd out the budget, iterating until the budget is exhausted.
[0066] Furthermore, for conflict candidates with the same key, the conflict decision follows these principles: if a version exists, the higher version is selected; if a valid range exists, the one valid at the current time is selected; otherwise, the one with the newer time and higher confidence is selected; if a distinction still cannot be made, a stable internal identifier is used to break the tie. Finally, the conflict decision record is written to `Capsule.conflict_resolutions`, and the excluded units are retained in storage to support audit review.
[0067] Therefore, by comprehensively considering four key factors—causal dependency graph, conflict relationship graph, demand key set, and token budget—to screen the candidate set, a multi-dimensional and comprehensive memory screening can be achieved. This ensures that the screened memory information aligns with the user's core needs (based on the demand key set), is free of logical conflicts (based on the conflict relationship graph), and is complete (based on the causal dependency graph), while remaining within the token budget (based on the token budget). This effectively avoids various defects caused by single-factor screening in existing methods, significantly improving the rationality and accuracy of the screening results. By obtaining the minimum causal closure set through screening, the memory information is simplified and complete. Redundant and low-contribution memory units are eliminated, saving token resources, while all necessary core and dependent memory units are retained, ensuring the integrity of the memory information. This provides accurate and efficient information support for the generation of the target answer, avoiding answers caused by memory redundancy or missing information. By performing stability sorting and serialization on the minimum causal closure set, the system can achieve comprehensive screening. Encoding organizes the logical order and relationships between memory units, making the memory information more structured. When generating the target answer, there's no need to reorganize the memory order; processing can be done directly based on the encoded memory information, significantly improving the efficiency of answer generation while ensuring the logical coherence and completeness of the answer. By constructing standardized memory capsules, the filtered, sorted, and encoded memory information is integrated into a structured carrier, forming a unified format and core content. This facilitates standardized processing by the answer generation module, improving the adaptability between modules. It also facilitates the storage, management, and traceability of memory capsules. If answer deviations occur later, the problem in the memory capsule can be quickly located for optimization. This solution further improves the memory management closed loop, making the filtering and memory capsule construction steps more standardized and implementable, enhancing the practicality and scalability of the entire memory management method. This ensures that the long-duration, multi-turn dialogue system can continuously and stably generate accurate, coherent, and efficient target answers, improving the user's dialogue experience.
[0068] Furthermore, by clearly defining the selection sequence—first removing mutually exclusive memories, then performing dependency closure completion, and finally combining requirements and budget—a standardized and logically clear selection process is formed. This avoids the chaos caused by processing multiple factors simultaneously, significantly improving selection efficiency and ensuring that each step lays the foundation for subsequent steps, reducing repeated adjustments. By first removing mutually exclusive atomic memory units from the candidate set based on the conflict relationship graph to obtain the first subset, logical conflicts between memory units can be eliminated in advance, avoiding the problem of conflict propagation when selecting dependent memory units later. This ensures that the subsequent selection process is based on a conflict-free memory set, improving the accuracy of the selection results and reducing the workload of subsequent selections, as there is no need to handle the dependencies of the removed conflicting memory units again. Performing causal closure expansion on the first subset based on the causal dependency graph to complete the dependency predecessors and obtain the second subset, necessary dependent memory units can be added on the basis of no conflict, ensuring the integrity of memory information and avoiding the problem of dependency propagation. The system addresses issues such as incomplete memory and inaccurate answers caused by missing dependencies. Furthermore, since dependency completion is performed on the first subset, it reduces the risk of conflict propagation and provides a foundation for subsequent screening under mutual exclusion constraints. Fourth, by combining the demand key set and token budget to process the second subset, it prioritizes meeting core user needs while ensuring conflict-free and complete memories. Simultaneously, it controls the token budget, eliminating low-contribution memory units, ultimately obtaining a conflict-free, complete, demand-aligned, and budget-controlled minimum causal closure set, achieving the screening objective. The standardized screening steps make the process more practical and reproducible, facilitating system implementation and optimization. It also improves the stability of the screening results. Regardless of the size or complexity of the candidate set, a high-quality minimum causal closure set can be obtained through fixed steps, providing reliable support for the subsequent construction of memory capsules and the generation of target answers. This further improves the entire memory management process and enhances the method's practicality and reliability.
[0069] Finally, by clearly defining the priority rules for satisfying the demand key set, we ensure that the processing is always guided by the core user needs, prioritizing the retention of atomic memory units highly relevant to user needs. This avoids the problem of eliminating key memory units due to excessive focus on token budget, ensuring that the selected minimum causal closure set accurately matches user needs, providing core support for generating the target answer and improving the accuracy of the response. By combining the selection with token budget under the premise of satisfying coverage, closure, and mutual exclusion constraints, and eliminating non-essential units not included in the final set in descending order of contribution, we clarify the judgment logic for low-contribution memory units. These units are those whose contribution does not match the token cost and that provide little help in answering the user's question. This avoids problems caused by random or subjective elimination, ensuring that truly useless or minimally useful memory units are eliminated, while retaining high-contribution, low-token-cost memory units. This achieves optimal allocation of token resources, controlling the total token cost to not exceed the budget and conserving token resources. By quantitatively evaluating the contribution of each atomic memory unit (based on its correlation with the demand key set), we ensure that the processing is always guided by the core user needs. The ratio of contribution to token cost allows for precise assessment of the value of each memory unit, providing a scientific and accurate basis for elimination operations. This enhances the scientific rigor and accuracy of the processing results, preventing the waste of token resources and the loss of memory information. When eliminating low-contribution memory units, the system prioritizes eliminating those with the lowest ratio based on their contribution to token cost, continuing until the total token cost does not exceed the budget. This clarifies the elimination order, avoids confusion during the elimination process, and ensures efficient and orderly processing. It also ensures that the final minimum causal closure set meets user needs, maintains memory integrity, and does not exceed the token budget. This solution further improves the selection process for the minimum causal closure set, making the processing steps that combine needs and budget more standardized and feasible. This enhances the stability and reliability of the selection results, providing higher-quality input for the subsequent construction of memory capsules. Ultimately, this improves the effectiveness of the entire memory management method, ensuring that long-duration, multi-turn dialogue systems can generate accurate and coherent target answers that meet user needs while controlling the token budget, thus improving user experience and system performance.
[0070] Furthermore, in step S110, the memory capsule includes a capsule identifier, a capsule issue identifier, a capsule token budget, a list of memory cells, a digest check value, a source index, and capsule auxiliary fields.
[0071] The definition of a memory capsule (Capsule) is as follows: a set of selected memory units and their consistent serialization result, including the capsule identifier (capsule_id); the capsule question identifier (query_id); the capsule token budget; units: a list of selected MemUnits ordered in a stable order, i.e., a list of memory units; a digest check value, representing the digest value calculated from the serialization result, used to verify consistency; and a source index (source_index), obtained by aggregating source_ids. Additionally, it includes capsule auxiliary fields, which in practical use scenarios may include one or more of the following: empty fields, the key set (key_coverage), conflict resolutions, closure proofs (closure_proof), and the capsule creation time (created_at).
[0072] Regarding the encoding and verifiability of memory capsules, deterministic serialization is first performed, outputting the list of memory units (units) in a stable order as structured text. A fixed field order and fixed escaping rules are used to form memory segments that can serve as input prompts for the model. Each unit contains type, key, value, time, and source_ids, satisfying the following consistency requirements: the encoding character set is UTF-8; the field order is fixed as type, key, value, time, source_ids; source_ids are deduplicated and output in a stable order; special characters such as newlines and tabs are uniformly escaped; each unit is separated by a newline, and fixed delimiters are used between fields.
[0073] The following step is the digest verification process. Specifically, a digest is calculated from the serialized result and saved along with the capsule. When the capsule is reused or transferred across systems, the digest can be used to verify that the capsule content has not been tampered with and remains consistent. Optionally, the digest is the result of SHA-256 calculation of the serialized text byte sequence. If the digests are the same, it indicates that the capsule content is consistent and can be directly reused; if only the source_index is the same but the content is different, a conflict checking and difference merging process can be triggered.
[0074] The capsule text of the memory capsule consists of three parts: header, cell list, and source index. The header contains capsule_id, budget, digest, and key_coverage; the cell list is output in a stable order, and each cell outputs type, key, value, time, and source_ids; the source index deduplicates source_ids and outputs them in a stable order.
[0075] Finally, the memory capsule, corresponding digest, and source index are saved. In subsequent requests, deduplication and reuse are performed based on the digest, and audit information is recorded.
[0076] Therefore, by clearly defining the seven core fields included in the memory capsule, such as the capsule representation and capsule question representation, a standardized definition of the memory capsule is achieved. This ensures that the memory capsules constructed in different scenarios have a unified format and complete content, facilitating standardized parsing and processing by the subsequent answer generation module, improving the adaptability between modules, and reducing the development and maintenance costs of the system. By setting the capsule question representation field, the user question corresponding to the memory capsule can be clearly identified, facilitating the rapid matching of the corresponding user question in scenarios where multiple memory capsules coexist, avoiding the misuse of memory capsules, and ensuring that the correct memory capsule is called when generating the answer, thus improving the accuracy of the answer. By setting a candidate memory unit list, memory units that have made a certain contribution but were not included in the minimum causal closure set due to token budget or priority reasons can be stored during the screening process. When there are memory gaps or biases in the minimum causal closure set, or when the user raises related extended questions later, they can be quickly retrieved from the candidate list. Retrieving relevant memory units without re-filtering significantly improves the efficiency and flexibility of memory management, enhancing the practicality of memory capsules. By setting summary check values and source indexes, the summary check value can be used to quickly verify whether the content in the memory capsule is complete and tamper-proof, ensuring the reliability of the memory capsule. The source index can be used to quickly trace the original conversation message source of each atomic memory unit in the memory capsule, facilitating rapid troubleshooting and method optimization when memory biases or incorrect answers occur, thus improving the reliability and maintainability of the memory management method. The standardized and complete composition of memory capsules further improves the closed loop of memory management, enabling memory capsules to fully play their core role as memory carriers, providing comprehensive, accurate, and reliable information support for answer generation, improving the efficiency and accuracy of target answer generation, and also enhancing the practicality, scalability, and maintainability of long-duration, multi-turn dialogue memory management methods, adapting to various long-duration, multi-turn dialogue scenarios.
[0077] Corresponding to the above method embodiments, this application also provides an embodiment of a memory management device for long-duration, multi-turn dialogues. Figure 5 This diagram illustrates the structure of a memory management device for long-duration, multi-turn dialogues according to an embodiment of this application. Figure 5 As shown, the device includes: Extraction module 502 is configured to extract memory units based on the received session message stream to obtain all atomic memory units; Module 504 is configured to construct a causal dependency graph associated with all the atomic memory units, and a conflict relationship graph associated with the atomic memory units. Response module 506 is configured to generate a set of demand keys and determine a token budget in response to a received user question; The selection module 508 is configured to select from all the atomic memory units based on the user question to obtain a candidate set; The filtering module 510 is configured to filter the candidate set using the causal dependency graph, the conflict relationship graph, the demand key set, and the token budget, and construct a memory capsule based on the filtering results. The response module 512 is configured to generate a target answer corresponding to the user's question based on the memory capsule.
[0078] In an optional embodiment, the extraction module 502 is further configured to: Receive the session message stream; extract and save the structured fields from the session message stream, wherein the structured fields include role, tool call, tool output, timestamp and message link identifier; based on the saved structured fields, perform memory unit extraction to generate all the atomic memory units, wherein the atomic memory unit includes memory unit identifier, memory unit type, normalization key, structured value, generation time, source message identifier set, confidence level, token cost and auxiliary fields.
[0079] In an optional embodiment, the memory management device for long-duration, multi-turn dialogue further includes: The update module is configured to receive new dialogue message streams and construct atomic memory units corresponding to the new dialogue message streams; based on the atomic memory units corresponding to the new dialogue message streams, it incrementally updates the causal dependency graph and the conflict relationship graph.
[0080] In an optional embodiment, the filtering module 510 is further configured to: The candidate set is filtered using the causal dependency graph, the conflict relationship graph, the demand key set, and the token budget to obtain the minimum causal closure set; the minimum causal closure set is then subjected to stability sorting and serialization encoding to obtain the memory capsule.
[0081] In an optional embodiment, the filtering module 510 is further configured to: Based on the conflict relationship graph, mutually exclusive atomic memory units in the candidate set are removed to obtain a first subset; based on the causal dependency graph, causal closure expansion is performed on the first subset to complete the dependency predecessors, resulting in a second subset; the second subset is processed through the demand key set and the token budget to obtain the minimum causal closure set.
[0082] In an optional embodiment, the filtering module 510 is further configured to: For the atomic memory units contained in the second subset, under the premise of prioritizing the requirement key set, candidate closure components are selected based on the token budget, and non-essential units not included in the minimum causal closure set are eliminated in descending order of contribution to obtain the minimum causal closure set.
[0083] In an optional embodiment, the response module 512 is further configured to: The memory capsule includes a capsule identifier, a capsule issue identifier, a capsule token budget, a list of memory cells, a digest check value, a source index, and capsule auxiliary fields.
[0084] The memory management device for long-duration, multi-turn dialogues provided in this application extracts memory units from the received conversation message stream to obtain all atomic memory units; constructs a causal dependency graph and a conflict relationship graph associated with all the atomic memory units; generates a demand key set and determines a token budget in response to a received user question; selects from all the atomic memory units based on the user question to obtain a candidate set; filters the candidate set using the causal dependency graph, the conflict relationship graph, the demand key set, and the token budget, and constructs a memory capsule based on the filtering results; and generates a target answer corresponding to the user question based on the memory capsule. Key information formed during the dialogue is broken down into independently manageable atomic memory units, and each memory unit is uniformly assigned a stable key identifier, source information, and length measure. Based on this, by explicitly maintaining the causal relationships and potential conflict relationships between memories, a set of memories is selected within a limited context budget that covers the information required for the current question, is semantically complete, and does not contain contradictory content. The selected memories are organized and encoded in a deterministic manner to form verifiable and reusable memory outputs, thereby improving the stability, consistency and traceability of the model when using historical memories in multi-turn, long-duration dialogue scenarios.
[0085] The above is an illustrative scheme of a memory management device for long-duration, multi-turn dialogue according to this embodiment. It should be noted that the technical solution of this memory management device for long-duration, multi-turn dialogue belongs to the same concept as the technical solution of the memory management method for long-duration, multi-turn dialogue described above. Details not described in detail in the technical solution of the memory management device for long-duration, multi-turn dialogue can be found in the description of the technical solution of the memory management method for long-duration, multi-turn dialogue described above. Furthermore, the components in the device embodiment should be understood as functional modules necessary to implement each step of the program flow or each step of the method; these functional modules are not actual functional divisions or separations. A device claim defined by such a set of functional modules should be understood as a functional module architecture that primarily implements the solution through the computer program described in the specification, and not as a physical device that primarily implements the solution through hardware.
[0086] Figure 6 A structural block diagram of a computing device 600 according to an embodiment of this application is shown. The components of the computing device 600 include, but are not limited to, a memory 610 and a processor 620. The processor 620 is connected to the memory 610 via a bus 630, and a database 650 is used to store data.
[0087] The computing device 600 also includes an access device 640, which enables the computing device 600 to communicate via one or more networks 660. Examples of these networks include a Public Switched Telephone Network (PSTN), a Local Area Network (LAN), a Wide Area Network (WAN), a Personal Area Network (PAN), or a combination of communication networks such as the Internet. The access device 640 may include one or more of any type of wired or wireless network interface (e.g., a Network Interface Card (NIC)), such as an IEEE 802.11 Wireless Local Area Network (WLAN) interface, a Wi-MAX interface, an Ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a Bluetooth interface, a Near Field Communication (NFC) interface, and so on.
[0088] In one embodiment of this application, the aforementioned components of the computing device 600 and Figure 6 Other components, not shown, can also be connected to each other, for example, via a bus. It should be understood that... Figure 6 The block diagram of the computing device shown is for illustrative purposes only and is not intended to limit the scope of this application. Those skilled in the art can add or replace other components as needed.
[0089] The computing device 600 can be any type of stationary or mobile computing device, including mobile computers or mobile computing devices (e.g., tablet computers, personal digital assistants, laptop computers, notebook computers, netbooks, etc.), mobile phones (e.g., smartphones), wearable computing devices (e.g., smartwatches, smart glasses, etc.) or other types of mobile devices, or stationary computing devices such as desktop computers or PCs. The computing device 600 can also be a mobile or stationary server.
[0090] The processor 620 is used to execute computer-executable instructions for the memory management method for long-duration multi-turn dialogues.
[0091] The above is an illustrative scheme of a computing device according to this embodiment. It should be noted that the technical solution of this computing device and the technical solution of the memory management method for long-term multi-turn dialogue described above belong to the same concept. For details not described in detail in the technical solution of the computing device, please refer to the description of the technical solution of the memory management method for long-term multi-turn dialogue described above.
[0092] An embodiment of this application also provides a computer-readable storage medium storing computer instructions that, when executed by a processor, are used to implement the steps of the memory management method for long-duration, multi-turn dialogues.
[0093] The above is an illustrative scheme of a computer-readable storage medium according to this embodiment. It should be noted that the technical solution of this storage medium belongs to the same concept as the technical solution of the memory management method for long-term multi-turn dialogue described above. For details not described in detail in the technical solution of the storage medium, please refer to the description of the technical solution of the memory management method for long-term multi-turn dialogue described above.
[0094] An embodiment of this application also provides a chip that stores a computer program, which, when executed by the chip, implements the steps of the memory management method for long-duration, multi-turn dialogue.
[0095] The foregoing has described specific embodiments of this application. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired results. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.
[0096] The computer instructions include computer program code, which may be in the form of source code, object code, executable file, or certain intermediate forms. The computer-readable medium may include any entity or device capable of carrying the computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium may be appropriately added to or subtracted according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media may not include electrical carrier signals and telecommunication signals.
[0097] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.
[0098] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.
[0099] The preferred embodiments disclosed above are merely illustrative of this application. The optional embodiments do not exhaustively describe all details, nor do they limit the invention to the specific implementations described. Clearly, many modifications and variations can be made based on the content of this application. These embodiments are selected and specifically described in this application to better explain the principles and practical applications of this application, thereby enabling those skilled in the art to better understand and utilize this application. This application is limited only by the claims and their full scope and equivalents.
Claims
1. A memory management method for long-duration, multi-turn dialogues, characterized in that, include: Based on the received session message stream, memory units are extracted to obtain all atomic memory units; Construct a causal dependency graph of all the atomic memory units and a conflict relationship graph of the atomic memory units; In response to received user questions, generate a set of demand keys and determine the token budget; Based on the user's question, a candidate set is obtained by selecting from all the atomic memory units; The candidate set is filtered using the causal dependency graph, the conflict relationship graph, the demand key set, and the token budget, and a memory capsule is constructed based on the filtering results. Based on the memory capsule, a target answer corresponding to the user's question is generated.
2. The method according to claim 1, characterized in that, The process of extracting memory units based on the received session message stream yields all atomic memory units, including: Receive the session message stream; Extract and save the structured fields from the session message stream, wherein the structured fields include role, tool call, tool output, timestamp and message link identifier; Based on the saved structured fields, memory cell extraction is performed to generate all the atomic memory cells, wherein the atomic memory cells include memory cell identifier, memory cell type, normalization key, structured value, generation time, source message identifier set, confidence level, token cost, and auxiliary fields.
3. The method according to claim 1, characterized in that, After constructing the causal dependency graph and the conflict relationship graph associated with all the atomic memory units, the method further includes: Receive new dialogue message streams and construct atomic memory units corresponding to the new dialogue message streams; Based on the atomic memory unit corresponding to the newly added dialogue message stream, the causal dependency graph and the conflict relationship graph are incrementally updated.
4. The method according to claim 1, characterized in that, The step of filtering the candidate set using the causal dependency graph, the conflict relationship graph, the demand key set, and the token budget, and constructing a memory capsule based on the filtering results, includes: The candidate set is filtered using the causal dependency graph, the conflict relationship graph, the demand key set, and the token budget to obtain the minimum causal closure set; The memory capsule is obtained by performing stability sorting and serialization encoding on the set of minimal causal closures.
5. The method according to claim 4, characterized in that, The process of filtering the candidate set using the causal dependency graph, the conflict relationship graph, the demand key set, and the token budget to obtain the minimum causal closure set includes: Based on the conflict relationship diagram, mutually exclusive atomic memory units in the candidate set are removed to obtain the first subset; Based on the causal dependency graph, causal closure expansion is performed on the first subset to complete the dependency predecessors, resulting in the second subset; By processing the second subset using the demand key set and the token budget, the minimum causal closure set is obtained.
6. The method according to claim 5, characterized in that, The process of processing the second subset using the demand key set and the token budget to obtain the minimum causal closure set includes: For the atomic memory units contained in the second subset, under the premise of prioritizing the requirement key set, candidate closure components are selected based on the token budget, and non-essential units not included in the minimum causal closure set are eliminated in descending order of contribution to obtain the minimum causal closure set.
7. The method according to claim 1, characterized in that, The memory capsule includes a capsule identifier, a capsule issue identifier, a capsule token budget, a list of memory cells, a digest check value, a source index, and capsule auxiliary fields.
8. A memory management device for long-duration, multi-turn dialogues, characterized in that, include: The extraction module is configured to extract memory units based on the received session message stream to obtain all atomic memory units. The building module is configured to build a causal dependency graph associated with all the atomic memory units, and a conflict relationship graph associated with the atomic memory units; The response module is configured to generate a set of demand keys and determine the token budget in response to received user questions; The selection module is configured to select from all the atomic memory units based on the user question to obtain a candidate set; The filtering module is configured to filter the candidate set using the causal dependency graph, the conflict relationship graph, the demand key set, and the token budget, and construct a memory capsule based on the filtering results; The response module is configured to generate a target answer corresponding to the user's question based on the memory capsule.
9. A computing device, characterized in that, include: Memory and processor; The memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions to implement the steps of the memory management method for long-duration multi-turn dialogue as described in any one of claims 1 to 7.
10. A computer-readable storage medium storing computer instructions, characterized in that, When executed by the processor, this instruction implements the steps of the memory management method for long-duration multi-turn dialogue as described in any one of claims 1 to 7.