Construction method and related system of large language model memory operation system, operation method and hardware equipment

Abstract

The invention discloses a large language model memory operating system (MemOS), a construction method and an operation method thereof, and hardware equipment for realizing the system, and belongs to the technical field of large language model memory ability management. The MemOS provided by the invention adopts a three-layer architecture and comprises a memory interface layer, a memory operation layer and a memory infrastructure layer. The three layers cooperate to form a closed loop, and full-life-cycle management of memory from generation to archiving is achieved. According to the method, memory is converted into dominant resources, controllability, plasticity and evolutionary performance are achieved, a unified and structured memory management mechanism is provided for a large language model, the method is suitable for multiple industry scenes, transition of the large model to memorability and evolutionary is promoted, and a cognitive foundation is laid for universal artificial intelligence.

Description

Technical Field

[0001] This invention relates to the field of memory management technology for Large Language Models (LLMs). Specifically, it relates to a Memory Operating System (MemOS) for large language models, its construction method, operation method, and related hardware devices. This invention aims to transform "memory" from a byproduct of implicit model dependencies into an explicit resource by constructing a standardized, interface-based, and evolvable memory management system. This enables refined management of memory units throughout their entire lifecycle and is applicable to applications in finance, healthcare, education, social media, and other industries with high demands for large model memory capabilities. It represents an innovative technology at the intersection of artificial intelligence and operating systems. Background Technology

[0002] The introduction of the Transformer architecture and the maturity of the self-supervised pre-training paradigm have made Large Language Models (LLMs) a core pillar of natural language processing technology. Relying on pre-training with large-scale corpora, they have successfully constructed language representation spaces with generalization capabilities, demonstrating near-human language understanding and generation abilities in tasks such as open question answering, text generation, summary extraction, structured code generation, cross-modal information processing, multi-turn dialogue, and planning and decision-making. They are becoming an important candidate paradigm for achieving Artificial General Intelligence (AGI).

[0003] Currently, the exploration of LLM memory capabilities has roughly gone through four stages: (1) The stage of defining and exploring memory: classifying and analyzing the memory system of LLM from multiple dimensions, and exploring effective and usable optimization mechanisms in practical applications. (2) The stage of developing human-like memory: addressing the problem of poor performance in complex tasks caused by the differences between LLM and human memory, various forms of human-like memory are introduced to bridge the gap. (3) The stage of tool-based memory management: modular interfaces for memory management have begun to appear, but the overall approach is still limited to simple addition, deletion, modification, and querying of existing memories. (4) The stage of systematic governance of memory: recognizing the need for more comprehensive memory management, but a complete and unified system architecture has not yet been formed.

[0004] To address the issue of knowledge updates lagging behind training costs due to the increased parameter size of LLM models, methods such as Retrieval-Augmented Generation have been widely adopted. This approach introduces an external knowledge retrieval module (such as a vector database or knowledge base) to allow the model to dynamically retrieve relevant text during inference, thereby achieving knowledge updates without modifying the parameters.

[0005] While the aforementioned methods improve the timeliness and openness of knowledge, they do not address the lack of systematic support for the core capability of "memory" in language models. Traditional LLM architectures still primarily rely on implicit parametric memory for knowledge storage. This method encapsulates knowledge within billions, tens of billions, or even hundreds of billions of parameters, making it neither interpretable nor easily customizable. While RAG-style memory introduces explicit information, it primarily achieves immediate responses by "inserting text patches," lacking a structured, unified, and traceable memory management mechanism. Furthermore, as the complexity of application scenarios increases, this structural deficiency becomes increasingly pronounced in the following four scenarios:

[0006] (1) Long-range dependency modeling: Due to the fixed context window of the Transformer (usually between 4K and 32K tokens), it is unable to handle language states across rounds of conversation and cross-task stages. At the same time, the rapid increase in the context window to be processed also poses great challenges to processing efficiency and energy consumption.

[0007] (2) Knowledge Change Adaptation: When information in the real world is constantly changing (such as legal provisions, scientific research progress, and social events), LLM, due to the fixed nature of its parameters, cannot quickly update knowledge. Fine-tuning the model not only incurs huge training costs but also suffers from the problem of catastrophic forgetting. Traditional RAG cannot uniformly manage the multiple knowledge evolution stages of "addition-abandonment-integration".

[0008] (3) Personalization and Multi-role Services: Current LLM models cannot build long-term "memory trajectories" for specific users, roles, or tasks, nor can they model the lifecycle of user interaction styles, preference patterns, and historical intentions. This results in the model being in an almost "initialized state" in each round of inference, failing to form a consistent understanding of the user's personality or task. In other words, the model cannot truly "grow" with the user's interactions and become the model that best understands the user's preferences.

[0009] (4) Cross-platform interaction memory migration: As large-scale model applications move from single interfaces to multi-platform collaboration (such as web pages, mobile apps, and enterprise private deployments), the interaction memory accumulated between users and models is becoming increasingly valuable. However, current systems often confine user profiles, historical interactions, task preferences, and other information to a specific model instance or platform environment, making it impossible to migrate knowledge and interaction records across systems.

[0010] These issues collectively reveal a fact: current large-scale model architectures lack a unified, structured memory system design. The models can "understand" and "answer" the questions, but they "cannot remember," "cannot be modified," and "cannot learn quickly." Summary of the Invention

[0011] In view of the aforementioned shortcomings of existing technologies, this invention proposes MemOS (Memory Operating System), a memory operating system built for large language models. The core concept of MemOS is to transform "memory" from a byproduct of implicit model dependencies into an explicit resource unit in model operation, providing a standardized, interface-based, and evolvable management mechanism. Similar to the unified management and scheduling of hardware resources in traditional operating systems, MemOS uses "memory units" as the core resource object, building a modular support system around their lifecycle (generation, organization, use, fusion, and disposal), encompassing key components such as memory representation (MemEncode), memory organization (MemLink), memory retrieval (MemSearch), and memory migration (MemTrans). Through a unified Memory API layer, the system provides cross-session, cross-task, and cross-user memory access capabilities for model inference, and supports enhanced mechanisms such as structured storage, traceability, version control, and permission management.

[0012] To achieve the above objectives, this invention provides a method for constructing a large language model memory operating system, comprising the following steps:

[0013] S10. Construct the memory interface layer, which is responsible for interacting with users or upper-level systems. This layer provides a standardized Memory API, covering memory query, writing, updating, transfer and combination operations. It uses the built-in MemReader module to convert natural language requests into structured memory operation instructions.

[0014] S20. Construct the memory operation layer, which is the control center of the system and is responsible for memory scheduling, state evolution and retrieval organization logic. It includes the MemScheduler module, the MemLifecycle module and the MemOperator module. The MemScheduler module schedules memory units according to context, system load and visitor strategy. The MemLifecycle module manages the life cycle of memory units and divides them into five stages: generation, activation, fusion, archiving and expiration. The MemOperator module constructs the tag system, graph structure and hierarchical organization method.

[0015] S30. Construct the memory infrastructure layer, which includes MemGovernance, MemVault, MemLoader, MemDumper and MemStore. MemGovernance is responsible for permission management and data retention policies. MemVault manages multiple types of memory banks. MemLoader and MemDumper realize the import, export and cross-platform synchronization of memories. MemStore supports the open publication and subscription of memories.

[0016] S40. Enables collaborative work among the memory interface layer, memory operation layer, and memory infrastructure layer to form a closed loop of memory operation path, completing the entire process from task input to execution scheduling and then to governance and archiving.

[0017] Preferably, in step S10, the standardized Memory API includes Provenance API, Update API, LogQuery API, and Transfer API; Provenance API is used to mark the source when generating or modifying memory, Update API is used to append, merge, or replace memory content, LogQuery API is used to query historical access trajectories, and Transfer API is used for memory migration or sharing.

[0018] Preferably, in step S20, the scheduling granularity of the MemScheduler module includes user-level, task-level, organization-level, or industry-specific scheduling granularity.

[0019] Preferably, in step S20, the state transition of the memory cell is automatically triggered by access frequency, time strategy, task tag factors, or triggered by explicit control.

[0020] This invention also provides a large language model memory operating system, comprising:

[0021] The memory interface layer is used to interact with users or upper-layer systems, providing a standardized Memory API, including the MemReader module, which is used to convert natural language requests into structured memory operation instructions;

[0022] The memory operation layer, connected to the memory interface layer, includes the MemScheduler module, the MemLifecycle module, and the MemOperator module. The MemScheduler module is used to schedule memory units, the MemLifecycle module is used to manage the lifecycle of memory units, and the MemOperator module is used to construct the tag system, graph structure, and hierarchical organization method.

[0023] The memory infrastructure layer, connected to the memory operation layer, includes MemGovernance, MemVault, MemLoader, MemDumper, and MemStore. MemGovernance is used for permission management, data retention policies, etc. MemVault is used to manage multiple types of memory repositories. MemLoader and MemDumper are used to implement memory import, export, and cross-platform synchronization. MemStore is used to support the open publishing and subscription of memories.

[0024] Preferably, the standardized Memory API covers memory query, write, update, transfer, and combination operations.

[0025] Preferably, the MemLifecycle module divides the lifecycle of the memory unit into five stages: generation, activation, fusion, archiving, and expiration.

[0026] Preferably, the memory managed by MemVault includes a user private library, an industry knowledge base, and a shared pipeline library.

[0027] This invention also provides a method for running a large language model memory operating system, which includes the following steps:

[0028] S1. Receive a natural language request or an automatically triggered task prompt from the user, and perform semantic parsing on the request or prompt through the MemReader module of the memory interface layer to identify the task intent, time window, topic entity and context anchor point, and convert the natural language request into a structured memory operation instruction.

[0029] S2. When it is determined that the task involves memory operations, a standardized Memory API request is constructed through the memory interface layer. The Memory API includes Provenance API, Update API, LogQuery API and Transfer API. All API requests are encapsulated into a parameter structure containing context ID, caller identity, required memory type and access window, and submitted to the memory operation layer.

[0030] S3. The MemScheduler module of the memory operation layer schedules the API requests based on context, system load and visitor strategy, and selects relevant memory units according to predefined strategies, including context matching, access frequency and time decay, and the scheduling granularity covers user level, task level, organization level or industry scenario level.

[0031] S4. The lifecycle of the scheduled and activated memory units is managed through the MemLifecycle module of the memory operation layer. The lifecycle includes five stages: generation, activation, fusion, archiving and expiration. Stage transitions are automatically triggered by access frequency, time strategy and task tags or triggered by explicit control.

[0032] S5. Memory units that have completed their lifecycle evolution are archived from the memory infrastructure layer to MemVault, where storage is organized by user, task, or scenario. At the same time, access control, compliance verification, and access auditing are performed through the MemGovernance module, and access control policies are allocated.

[0033] Preferably, in step S1, the structured memory operation instructions include memory query, write, update, transfer, and combination operation instructions.

[0034] Preferably, in step S3, the memory unit includes parameterized memory, activation memory and plaintext memory, and the MemScheduler module performs unified scheduling, sorting and compression of the three types of memory units.

[0035] Preferably, in step S5, the access control policy includes an access control list, a time-to-live (TTL) period, and effective conditions, and the authorization boundary is determined based on the visitor's identity and the task context.

[0036] Preferably, in step S5, the memory infrastructure layer realizes cross-platform synchronization of memory units through the MemLoader and MemDumper modules, and supports open publishing and subscription of memory through the MemStore module.

[0037] Finally, this invention provides a hardware device for implementing a large language model memory operating system, comprising:

[0038] processor;

[0039] Memory, used to store computer programs;

[0040] When the computer program is executed by the processor, it implements the aforementioned method for constructing or running a large language model memory operating system.

[0041] Beneficial technical effects of the present invention:

[0042] (1) MemOS provides full lifecycle management capabilities for memory units, supporting unified scheduling of processes such as memory generation, activation, fusion, and disposal. The system introduces a multi-level permission control mechanism, a context-aware activation strategy, and uses methods such as watermarking and log tracking to ensure the availability, security, and interpretability of model memory in multi-task, multi-user, and multi-model environments.

[0043] (2) MemOS supports cross-task and cross-role memory restructuring and transfer. The system provides memory slicing, tagging, hierarchical mapping, and context binding capabilities, allowing developers or the system to build highly adaptable memory structures according to inference goals. This enables the model to activate different memory views as needed for different tasks, or to automatically update its memory associations when switching roles, thereby achieving rapid cognitive adaptation and behavioral shaping.

[0044] (3) MemOS supports dynamic conversion and unified scheduling mechanisms between different types of memory, including parametric memory (such as knowledge embedded in model weights), activation memory (contextual states during inference), and plaintext memory (structured knowledge fragments). The system can seamlessly switch between different forms of memory based on task requirements and knowledge evolution stages. For example, it can convert plaintext user rules formed in multiple dialogues into activation memory, or compress structured long-term knowledge into parametric memory. By supporting this kind of "cross-memory form" conversion, MemOS provides a reliable infrastructure guarantee for knowledge fusion, autonomous learning, and capability iteration of large models.

[0045] (4) This invention introduces “dynamic memory capability” into the large language model in a system form, marking a key leap from “parameter-driven” to “memory-driven” intelligent systems. It not only makes up for the core defects of existing models in memory structuring, life cycle management and multi-source fusion, but also provides operating system-level support for models to achieve cross-task adaptation, cross-morphological evolution and cross-platform migration, and builds a cognitive foundation with “long-term memory” and “continuous evolution” for the next generation of general intelligent systems (AGI).

[0046] The following will further explain the concept, specific structure, and technical effects of the present invention in conjunction with the accompanying drawings, so as to fully understand the purpose, features, and effects of the present invention. Attached Figure Description

[0047] Figure 1 This is an overview diagram of the MemOS framework of this invention;

[0048] Figure 2 This is a diagram illustrating the three-layer architecture and memory call path of MemOS;

[0049] Figure 3 It is a diagram showing the mutual transformation between the three types of memory. Detailed Implementation

[0050] The following description, with reference to the accompanying drawings, illustrates several preferred embodiments of the present invention to make its technical content clearer and easier to understand. The present invention can be embodied in many different forms, and the scope of protection of the present invention is not limited to the embodiments mentioned herein.

[0051] In the accompanying drawings, components with the same structure are indicated by the same numerical designation, and components with similar structures or functions are indicated by similar numerical designations. The dimensions and thicknesses of each component shown in the drawings are arbitrary, and the present invention does not limit the dimensions and thicknesses of each component. To make the illustrations clearer, the thickness of some components has been appropriately exaggerated in the drawings.

[0052] Example 1: A Method for Constructing a Large Language Model Memory Operating System

[0053] 1. Overall Construction Process

[0054] This embodiment will detail the construction method of the Large Language Model Memory Operating System (MemOS). The method includes constructing a memory interface layer, a memory operation layer, and a memory infrastructure layer, and implementing the collaborative work of the three layers to form a closed loop of memory operation path.

[0055] In pet health interaction scenarios, when a user inputs "My dog ​​needs help," the system needs to quickly access the dog's past health records, common ailment treatment plans, and other memory units, and support subsequent memory updates (such as adding symptom descriptions) and cross-platform synchronization (such as syncing from the mobile app to the pet hospital system). To achieve this, MemOS is built around the end-to-end management of "user-pet-health memory," using a modular three-layer architecture to transform natural language requests into structured operations, completing the generation, scheduling, storage, and management of memories.

[0056] 2. Construct the memory interface layer (S10)

[0057] The memory interface layer is the user's interaction point with the system. It is responsible for converting natural language requests such as "My dog ​​needs help" into executable memory operation instructions. Its core includes the standardized Memory API and the MemReader module.

[0058] 2.1 Design a standardized Memory API

[0059] For pet health scenarios, the interface layer provides four core APIs, covering operations throughout the entire lifecycle of memory:

[0060] Provenance API: Used to annotate the source of records. For example, when a user uploads their dog's vaccination record, they can use this API to annotate the source as "Vaccination certificate from XX Pet Hospital in March 2024" to ensure the record is traceable.

[0061] Update API: Used to update memory content. When a user adds "the dog is vomiting", the new information is appended to the "My Dog Health Record" memory unit through this API, or multiple scattered records (such as "diarrhea last week" and "vomiting today") are combined to form a complete symptom track.

[0062] LogQuery API: Used to query historical access records. For example, veterinarians can use this API to query "the number of times and the times a user accessed a dog's deworming records in the past 3 months" to assist in diagnosis.

[0063] Transfer API: Used for cross-platform memory transfer. When a user switches from the mobile app to the computer, this API is used to synchronize the "dog's eating preferences" memory from the mobile device to the cloud, ensuring information consistency across multiple devices.

[0064] 2.2 Developing the MemReader module

[0065] The MemReader module is responsible for parsing the natural language request "My dog ​​needs help," and the specific process is as follows:

[0066] Semantic analysis: The task intent is identified as "pet health help", the subject entity is "user's dog", and the context anchor is "dog breed (corgi) and age (2 years old) mentioned in the user's history of conversations".

[0067] Structured transformation: Generates an instruction chain that includes operation type, time window, and memory range.

[0068] Operation type: "Query + Activation"

[0069] "Time window": "The past 7 days"

[0070] "Memory Range": ["Recent eating history of the dog", "Common symptoms of Corgi diseases", "Address of nearby veterinary hospitals"],

[0071] "Context Anchor": "User ID: U123, Historical Conversation ID: C456"

[0072] API mapping: Mapping the instruction chain to specific API calls, such as querying the past 7 days' food records through the LogQuery API, or activating the pet hospital address memory through the Transfer API.

[0073] 3. Construct the memory operation layer (S20)

[0074] The memory operation layer is the control center of the system, responsible for the scheduling, lifecycle management and organization of memories in the "My dog ​​needs help" scenario. Its core includes three major modules: MemScheduler, MemLifecycle and MemOperator.

[0075] 3.1 Develop the MemScheduler module (memory scheduling)

[0076] This module selects relevant memory units and determines the scheduling strategy based on user context and system state:

[0077] Scheduling granularity: A hybrid granularity of "user-level + task-level" is adopted. User-level scheduling focuses on the private memories of "U123 user's dog" (such as vaccination records); task-level scheduling prioritizes the activation of frequently used memories such as "Corgi acute illness treatment process" for "pet emergency help" tasks.

[0078] Scheduling strategy: combined with appendix Figure 3 The context matching logic prioritizes the following options when the user inputs "My dog ​​needs help":

[0079] Memory with high contextual relevance (e.g., a user mentioned "the dog's appetite has decreased" 3 days ago);

[0080] Memory accessed frequently (e.g., "address of nearby 24-hour pet hospital", retrieved 12 times in history);

[0081] Memory with a low time decay factor (such as a record of "dog's body temperature 39℃" updated 2 hours ago).

[0082] 3.2 Develop the MemLifecycle module (lifecycle management)

[0083] Based on "My Dog's" healthy memories, its life cycle is divided into five stages, combined with... Figure 3 The state transition logic is implemented for dynamic management:

[0084] Generation phase: When a user first enters "My dog's name is Wangcai, a 2-year-old Corgi", the system generates an initial memory unit, which is marked as "user manual input" through the Provenance API.

[0085] Activation phase: When a user enters "My dog ​​needs help", the scheduler triggers activation, turning memories such as "Wangcai's vaccination record" and "Common Corgi ailments" from archived to active state for real-time retrieval.

[0086] Fusion phase: When the user adds "Wangcai vomited twice today and had diarrhea yesterday", the system automatically merges the two records to generate a merged memory of "Wangcai's digestive system has been abnormal for the past 2 days" and deletes redundant information.

[0087] Archiving phase: If "Wangcai's childhood vaccination record" is not accessed for 30 consecutive days, the system will automatically archive it to cold storage to release active memory, but retain the retrieval entry.

[0088] Expiration Stage: When Wangcai passes away, the user can trigger the expiration by giving an explicit command. The system will mark "Wangcai's Health Record" as expired and will automatically delete it after 3 years according to policy.

[0089] 3.3 Developing the MemOperator module (memory organization)

[0090] This module achieves efficient management of "My Dog's" memories through a tagging system, graph structure, and hierarchical organization:

[0091] Tagging system: Add multi-dimensional tags to memory units, such as "#pet type-corgi", "#health status-abnormal", "#time-20240715", "#user-U123", to support precise retrieval.

[0092] Graph Structure: Constructing a memory association graph (as shown in the appendix) Figure 3 (The logic of "memory organization" in China) For example, "Wangcai vomiting" is associated with "Corgi gastroenteritis symptoms", "nearby pet hospitals", and "the dog food brand purchased by the user", forming a knowledge network.

[0093] Hierarchical organization: Storage based on importance:

[0094] First layer (high-frequency access): Dynamic data such as Wangcai's current symptoms and real-time body temperature;

[0095] Second layer (mid-frequency access): Vaccine records, medical history, etc.;

[0096] The third layer (low-frequency access): childhood growth records, non-critical dietary preferences, etc.

[0097] 4. Construct the memory infrastructure layer (S30)

[0098] This layer provides storage, security, synchronization, and circulation support for the "My dog ​​needs help" scenario, and includes five core components:

[0099] 4.1 MemGovernance (Permissions and Policy Management)

[0100] Access control: Set three levels of permissions for "Wangcai's Health Record": User U123 has read and write permissions, authorized veterinarians have read-only permissions, and other users have no access permissions (implemented through access control lists).

[0101] Data retention strategy: In accordance with pet data protection standards, lifecycle rules are set for "health records to be retained for 3 years after the pet's death" and "real-time symptom records to be retained for 1 year".

[0102] Access audit: Records all operation traces, such as "20240715 10:30 Veterinarian Zhang inquired about Wangcai's vaccine records", supporting subsequent traceability.

[0103] 4.2 MemVault (Memory Management)

[0104] Managing three types of memory banks to meet scenario requirements:

[0105] User private library: Stores private data such as "Wangcai's health record" and "user's interaction record with Wangcai", which can only be accessed with user authorization.

[0106] Industry knowledge base: Integrates publicly available knowledge such as "Corgi breed characteristics" and "Pet digestive system disease diagnosis and treatment guidelines", from authoritative pet medical institutions, and supports sharing across the entire system.

[0107] Shared workflow library: Stores "pet emergency help handling process" (such as "symptom description → nearby hospital recommendation → appointment registration") for reuse by multiple platforms.

[0108] 4.3 MemLoader and MemDumper (Cross-platform synchronization)

[0109] Import (MemLoader): Users download "Wangcai's physical examination report" from the pet hospital's official website, import it into the private library through MemLoader, automatically parse the PDF content and associate it with "Wangcai's health record".

[0110] Export (MemDumper): After user authorization, MemDumper can be used to export "Wangcai's Symptom Records" as an encrypted file and send it to the veterinarian's diagnosis and treatment system to achieve cross-platform collaboration.

[0111] Synchronization mechanism: After the user updates the "Wangcai vomiting count" in the mobile APP, MemLoader and MemDumper synchronize to the computer and cloud in real time to ensure data consistency across multiple terminals.

[0112] 4.4 MemStore (Memory Publishing and Subscription)

[0113] Published: A pet hospital has released a professional guide on "Prevention of Common Corgi Diseases in Summer," with pricing and access restrictions, available for users to subscribe to.

[0114] Subscription: Users subscribe to the above memories through MemStore, and the system automatically associates them with "Wangcai's Health Record". When the publisher updates the content, the subscribing users will receive push notifications in real time.

[0115] 5. Achieve three-tier collaborative work (S40)

[0116] The three layers work together through standardized interfaces to form a complete closed loop for processing "My dog ​​needs help" (see attached diagram). Figure 3 (Information flow direction):

[0117] Interface Layer → Operation Layer: After the user inputs "My dog ​​needs help", the MemReader module generates a structured instruction, queries "Wangcai's recent health records" through the LogQuery API, encapsulates it into parameters containing "Context ID: C456" and "Caller: U123", and submits it to the operation layer.

[0118] Operational Layer → Infrastructure Layer: MemScheduler schedules memories such as "Wangcai's Symptom Records" and "Corgi Disease Database," which are then activated by MemLifecycle; MemOperator extracts relevant data from MemVault's user-owned private database and industry knowledge base through tag matching.

[0119] Infrastructure layer → Operation layer: MemGovernance verifies U123's access permissions and returns the stored data after confirming its validity; MemLoader synchronizes the latest records from the mobile client to the operation layer to ensure data integrity.

[0120] Operation Layer → Interface Layer: The operation layer integrates the memory data and generates a response such as "It is recommended to seek medical attention immediately and recommend a nearby 24-hour pet hospital XXX", which is then fed back to the user through the interface layer.

[0121] End-to-end closed loop: After a user confirms their medical visit, the system automatically updates "Wangcai's Health Record" (Update API), recording "Appointment made at XXX Hospital at 11:00 on July 15, 2024", and archives it to MemVault, completing the entire process from input to governance.

[0122] Example 2: Large Language Model Memory Operating System

[0123] 1. System Overall Architecture

[0124] The large language model memory operating system in this embodiment includes a memory interface layer, a memory operation layer, and a memory infrastructure layer. These layers work together to achieve effective management of the large language model memory.

[0125] 2. Memory Interface Layer

[0126] The memory interface layer is used to interact with users or upper-level systems, providing a standardized Memory API, which includes the MemReader module.

[0127] The standardized Memory API covers memory query, write, update, transfer, and composition operations. (See attached...) Figure 3When a user inputs "My dog ​​needs help," the request is processed through the memory interface layer. The MemReader module performs semantic parsing, identifies the task intent as seeking help about a dog, and then generates corresponding memory operation instructions to call the relevant APIs.

[0128] For example, if you need to query memories about a dog's disease treatment, call the query API; if the user provides new health information about the dog, call the write API to store it; if an error is found in an existing memory, call the update API to correct it; if you need to share a dog's health memories with a veterinarian, call the transfer API; and if you need to combine multiple memory units about the dog for analysis, call the combination API.

[0129] During the parsing process, the MemReader module also identifies time windows (such as the dog's recent health status), subject entities (the dog), and context anchors (previous health records) to ensure that the generated structured memory operation instructions accurately reflect the user's needs.

[0130] 3. Memory Operation Layer

[0131] The memory operation layer is connected to the memory interface layer and includes the MemScheduler module, the MemLifecycle module, and the MemOperator module.

[0132] The MemScheduler module is used for scheduling memory units. (Combined with the appendix...) Figure 3 The process involves the user inputting "My dog ​​needs help" and then processing it through the interface layer. MemScheduler then selects memory units related to the dog's health, such as the dog's past medical history and treatment records for common diseases, based on the context (the user's previous health consultation records for the dog), system load (the number of tasks currently being processed by the system), and visitor policy (the user's permissions and priority of needs).

[0133] The MemLifecycle module manages the lifecycle of memory units, dividing it into five stages: generation, activation, fusion, archiving, and expiration. Taking a user's memories about a dog's health as an example: when a user records the dog's health information for the first time, a new memory unit is generated; when the user inquires about the dog's health again, the memory unit is activated; when multiple health records exist, they are merged to form a complete health profile; when the dog's health has not been mentioned for a long time, it is archived; if the dog's information is outdated (e.g., the dog has passed away and the record is no longer needed), it is marked as expired.

[0134] The MemOperator module is used to build a tagging system, graph structure, and hierarchical organization. For a dog's health memories, tags such as "pet," "dog," and "health" can be added; the graph structure connects the dog's health memories with related veterinary information, pet hospital information, etc.; and the memories are hierarchically arranged according to their importance and access frequency, such as placing records of serious illnesses at higher levels and daily diet records at lower levels.

[0135] 4. Memory Infrastructure Layer

[0136] The memory infrastructure layer is connected to the memory operation layer and includes MemGovernance, MemVault, MemLoader, MemDumper, and MemStore.

[0137] MemGovernance is used for access control and data retention policies. For users' private health memories about their dogs, it allows access only to the user and authorized veterinarians; it also allows setting the retention period for these memories based on user needs.

[0138] MemVault manages various types of memory repositories, including user-owned private repositories, industry knowledge repositories, and shared pipeline repositories. User-owned private repositories store users' personal memories about their dogs, industry knowledge repositories store professional knowledge about the pet healthcare industry, and shared pipeline repositories store process memories for pet healthcare services, such as pet visit procedures and vaccination procedures.

[0139] MemLoader and MemDumper are used to import, export, and synchronize memories across platforms. Users can use MemLoader to import their dog's medical records from other veterinary clinics into their own private database, and use MemDumper to export the dog's health records to the veterinarian; at the same time, it ensures that the user's memory data can be synchronized and updated across different devices.

[0140] MemStore supports the open publishing and subscription of memories. Pet medical research institutions can publish new pet disease treatment memories through MemStore, and pet hospitals or veterinarians can subscribe to these memories to obtain the latest treatment methods in a timely manner.

[0141] Example 3: Operation method of large language model memory operating system

[0142] 1. Overall Operation Process

[0143] The operating method of this embodiment is used to run the above-mentioned large language model memory operating system, including steps such as receiving and parsing requests, constructing API requests, scheduling execution, lifecycle management and storage archiving and governance.

[0144] 2. Receiving and parsing requests (S1)

[0145] It receives natural language requests from users or automatically triggered tasks (Prompts) and performs semantic parsing on them through the MemReader module of the memory interface layer.

[0146] With attachment Figure 3 Taking the example of a user inputting "My dog ​​needs help," the MemReader module first identifies the task intent as seeking help about a dog, which may involve aspects such as the dog's health and behavior. Next, it determines the time window, such as whether the user is referring to a current problem the dog is experiencing or a situation within a recent period. The subject entity is "dog," and the context anchors may be information about the dog that the user has mentioned in previous interactions with the system, such as the dog's breed and age.

[0147] Through parsing, natural language requests are transformed into structured memory operation instructions, including memory query (such as querying common dog problems and solutions), writing (such as recording a dog's current symptoms), and updating (such as supplementing a dog's past medical history).

[0148] 3. Construct the API request (S2)

[0149] When it is determined that the task involves memory operations, a standardized Memory API request is constructed through the memory interface layer, including the Provenance API, Update API, LogQuery API, and Transfer API. All API requests are encapsulated into a parameter structure containing the context ID, caller identity, required memory type, and access window, and submitted to the memory operation layer.

[0150] For a user's request "My dog ​​needs help", if it is necessary to retrieve relevant memories, call the LogQuery API; if it is necessary to record the dog's current symptoms, call the Provenance API to mark the source (the user) and write it; if it is necessary to supplement previous information, call the Update API.

[0151] In the encapsulated parameter structure, the context ID is used to associate the request with previous interaction records, the caller identity is the user, the required memory type is memories about the dog's health, behavior, etc., and the access window is the most recent related memory.

[0152] 4. Scheduling Execution (S3)

[0153] The MemScheduler module in the memory operation layer schedules API requests based on context, system load, and visitor strategy.

[0154] Combined with appendix Figure 3The context includes the user's previous interactions with dogs, system load such as the number of other requests the system is currently processing, and visitor policies such as the user's membership level and the urgency of the request.

[0155] Predefined strategies include context matching (selecting dog-related memories), access frequency (selecting dog-related memory types that users frequently access), and time decay (prioritizing recent memories). Scheduling granularity is user-level, meaning scheduling is performed on dog-related memories specific to that user.

[0156] Memory units include parametric memory (such as general knowledge about dogs in the model), activation memory (such as information about dogs mentioned in the user's current session), and plaintext memory (such as specific information about dogs recorded by the user). The MemScheduler module performs unified scheduling, sorting, and compression of these three types of memory units to ensure that the most relevant and important memories are processed first.

[0157] 5. Lifecycle Management (S4)

[0158] The MemLifecycle module in the memory operation layer manages the lifecycle of scheduled and activated memory units, including five stages: generation, activation, fusion, archiving, and expiration.

[0159] Activated memory units may be previously recorded memories of the dog's health and are in an active state. If the user provides new information about the dog, a new memory unit is generated and merged with the existing memory to form a more complete memory. When a memory unit is not accessed for a period of time, it is automatically archived; if the memory is outdated, such as when some information about the dog has changed and there is no need to retain the old information, it is marked as expired.

[0160] Phase transitions can be triggered automatically by access frequency (e.g., keeping a frequently accessed memory active), time strategies (e.g., archiving a memory if it hasn't been accessed for a certain period), and task tags (e.g., archiving memories marked as "resolved"). They can also be triggered by explicit user control (e.g., manually deleting a memory to make it expire).

[0161] 6. Storage Archiving and Governance (S5)

[0162] Memory units that have completed their lifecycle evolution are archived from the memory infrastructure layer to MemVault and organized for storage by user, task, or scenario.

[0163] For users' memories of their dogs, these memories are stored in a user-private database. Meanwhile, the MemGovernance module performs access control, compliance checks, and access auditing, assigning access control policies such as access control lists (access is limited to the user and authorized personnel), lifetime (setting the retention period for memories), and activation conditions (e.g., memories that are valid only for a specific age range of the dog).

[0164] The memory infrastructure layer enables cross-platform synchronization of memory units through the MemLoader and MemDumper modules, such as synchronizing dog memories recorded by users on their mobile phones to the computer. The MemStore module supports the open publishing and subscription of memories, such as allowing users to choose to publish certain non-private dog-related experience memories for other dog owners to subscribe and refer to.

[0165] Example 4: Hardware device for implementing a large language model memory operating system

[0166] 1. Hardware components

[0167] The hardware device includes a processor and a memory. The memory is used to store computer programs. When the computer programs are executed by the processor, the above-mentioned method for constructing or running a large language model memory operating system is implemented.

[0168] The processor can be a high-performance CPU, such as the Intel Core i9 series or AMD Ryzen 9 series, which has powerful computing and multi-threaded processing capabilities and can quickly handle various tasks in memory operations, such as memory scheduling, parsing, and lifecycle management.

[0169] The storage system includes main memory and secondary storage. The main memory can be DDR5 memory modules with a capacity of at least 32GB to ensure fast reading and storage of temporary data during operation, such as structured memory operation instructions and activated memory units. The secondary storage can be a large-capacity solid-state drive (SSD) with a capacity of at least 1TB for long-term storage of various memory banks, computer programs, etc.

[0170] 2. The process of implementing the construction method

[0171] When a computer program is executed by a processor to implement a build method, the processor first controls the memory to allocate appropriate space for storing data and program modules during the build process.

[0172] When constructing the memory interface layer, the processor runs relevant program modules, designs a standardized Memory API, and implements the functionality of the MemReader module to ensure that natural language requests are accurately converted into structured instructions. Simultaneously, relevant data structures and mapping relationships for API calls are established in memory.

[0173] When constructing the memory operation layer, the processor loads the program code of the MemScheduler, MemLifecycle, and MemOperator modules, sets the scheduling strategy, lifecycle stage division rules, and memory organization method, and allocates space in memory for the data processing and storage of these modules, such as storing scheduling records and lifecycle status information of memory units.

[0174] When building the memory infrastructure layer, the processor runs programs such as MemGovernance, MemVault, MemLoader, MemDumper, and MemStore to configure permission management rules, memory storage structure, import / export and synchronization mechanisms, and publish / subscribe rules. It also divides the memory into corresponding areas to store various types of memory data, permission information, etc.

[0175] Finally, the processor coordinates communication and collaboration between the layers, establishes data exchange channels and protocols, and ensures that the three layers can work in a closed loop.

[0176] 3. The process of implementing the running method

[0177] When a computer program is executed by a processor to implement its operating method, the processor receives natural language input requests from the user, parses them using the MemReader module program in memory, and stores the parsing results in memory.

[0178] Next, the processor constructs a standardized Memory API request based on the parsing results, encapsulates the parameters, and passes it to the program module of the memory operation layer through memory.

[0179] During the scheduling execution phase, the processor runs the program of the MemScheduler module, schedules memory units based on the context information stored in memory, system load data, and visitor policies, and stores the scheduling results in memory for subsequent processing.

[0180] For lifecycle management, the processor executes the program of the MemLifecycle module, updates the lifecycle state of the memory cells based on the access frequency and time information of the memory cells, and records the relevant information of the state transition.

[0181] During the storage archiving and governance phase, the processor controls the storage of memory units that have completed their lifecycle evolution into the MemVault in the external storage, and performs operations such as access control through the MemGovernance module. The relevant access information, storage path, etc. are recorded in the memory.

[0182] Through the coordinated work of the processor and memory, the large language model memory operating system can be ensured to run efficiently and stably, enabling effective management and utilization of memory.

[0183] The above embodiments describe in detail the construction method, system, operation method and hardware device of the present invention, covering the memory management process in different scenarios.

[0184] In practical applications, modules and parameters can be adjusted and optimized according to specific industry needs and user scenarios to better meet the memory management requirements of large language models. For example, in the financial field, specific scheduling strategies and access control rules can be designed for financial transaction memories and risk control memories; in the education field, the focus can be on the management and evolution of students' learning memories and knowledge mastery memories.

[0185] This invention addresses many shortcomings of existing large language models in terms of memory by systematically managing memory as an explicit resource. It provides strong support for the further development and application of large language models and has broad application prospects and significant technical value.

[0186] By continuously improving and optimizing the functions and collaboration mechanisms of each layer, MemOS can be made more controllable, adaptable and evolvable, better adapt to different application scenarios and technological development needs, and promote the development of large language models towards a more intelligent and efficient direction.

[0187] In subsequent technological iterations, more advanced technologies can be introduced, such as artificial intelligence algorithms to optimize the scheduling and fusion process of memory, and blockchain technology to enhance the security and traceability of memory, thereby further improving the performance and reliability of MemOS.

[0188] In summary, the method for constructing a large language model memory operating system and related systems, operating methods, and hardware devices of the present invention provide a complete, efficient, and reliable solution for the memory management of large language models, and have significant theoretical and practical application value.

[0189] The preferred embodiments of the present invention have been described in detail above. It should be understood that those skilled in the art can make numerous modifications and variations based on the concept of the present invention without creative effort. Therefore, all technical solutions that can be obtained by those skilled in the art based on the concept of the present invention through logical analysis, reasoning, or limited experimentation on the basis of existing technology should be within the scope of protection defined by the claims.

Claims

1. A method for constructing a large language model memory operating system, characterized in that, Includes the following steps: S10. Construct the memory interface layer, which is responsible for interacting with users or upper-level systems. This layer provides a standardized MemoryAPI, covering memory query, writing, updating, transfer and combination operations. It uses the built-in MemReader module to convert natural language requests into structured memory operation instructions. S20. Construct the memory operation layer, which is the control center of the system and is responsible for memory scheduling, state evolution and retrieval organization logic. It includes the MemScheduler module, the MemLifecycle module and the MemOperator module. The MemScheduler module schedules memory units according to context, system load and visitor strategy. The MemLifecycle module manages the life cycle of memory units and divides them into five stages: generation, activation, fusion, archiving and expiration. The MemOperator module constructs the tag system, graph structure and hierarchical organization method. S30. Construct the memory infrastructure layer, which includes MemGovernance, MemVault, MemLoader, MemDumper and MemStore. MemGovernance is responsible for permission management and data retention policies. MemVault manages multiple types of memory banks. MemLoader and MemDumper realize the import, export and cross-platform synchronization of memories. MemStore supports the open publication and subscription of memories. S40. Enables collaborative work among the memory interface layer, memory operation layer, and memory infrastructure layer to form a closed loop of memory operation path, completing the entire process from task input to execution scheduling and then to governance and archiving.

2. The method according to claim 1, characterized in that, In step S10, the standardized MemoryAPI includes Provenance API, Update API, LogQuery API, and Transfer API; Provenance API is used to mark the source when generating or modifying memory, Update API is used to append, merge, or replace memory content, LogQuery API is used to query historical access trajectories, and Transfer API is used for memory migration or sharing.

3. The method according to claim 1, characterized in that, In step S20, the scheduling granularity of the MemScheduler module includes user-level, task-level, organization-level, or industry-specific scheduling granularity.

4. The method according to claim 1, characterized in that, In step S20, the state transition of the memory cell is automatically triggered by access frequency, time strategy, task tag factors, or triggered by explicit control.

5. A large language model memory operating system, characterized in that, include: The memory interface layer is used to interact with users or upper-layer systems, providing a standardized MemoryAPI, including the MemReader module, which is used to convert natural language requests into structured memory operation instructions. The memory operation layer, connected to the memory interface layer, includes the MemScheduler module, the MemLifecycle module, and the MemOperator module. The MemScheduler module is used to schedule memory units, the MemLifecycle module is used to manage the lifecycle of memory units, and the MemOperator module is used to construct the tag system, graph structure, and hierarchical organization method. The memory infrastructure layer, connected to the memory operation layer, includes MemGovernance, MemVault, MemLoader, MemDumper, and MemStore. MemGovernance is used for permission management, data retention policies, etc. MemVault is used to manage multiple types of memory repositories. MemLoader and MemDumper are used to implement memory import, export, and cross-platform synchronization. MemStore is used to support the open publishing and subscription of memories.

6. The system according to claim 5, characterized in that, The standardized MemoryAPI covers memory query, write, update, transfer, and combination operations.

7. The system according to claim 5, characterized in that, The MemLifecycle module divides the lifecycle of memory units into five stages: generation, activation, fusion, archiving, and expiration.

8. The system according to claim 5, characterized in that, The memory managed by MemVault includes user private libraries, industry knowledge bases, and shared pipeline libraries.

9. A method for operating a large language model memory operating system, used to run the large language model memory operating system according to any one of claims 5-8, characterized in that, Includes the following steps: S1. Receive a natural language request or an automatically triggered task prompt from the user, and perform semantic parsing on the request or prompt through the MemReader module of the memory interface layer to identify the task intent, time window, topic entity and context anchor point, and convert the natural language request into a structured memory operation instruction. S2. When it is determined that the task involves memory operations, a standardized Memory API request is constructed through the memory interface layer. The Memory API includes Provenance API, Update API, LogQuery API and Transfer API. All API requests are encapsulated into a parameter structure containing context ID, caller identity, required memory type and access window, and submitted to the memory operation layer. S3. The MemScheduler module of the memory operation layer schedules the API requests based on context, system load and visitor strategy, and selects relevant memory units according to predefined strategies, including context matching, access frequency and time decay, and the scheduling granularity covers user level, task level, organization level or industry scenario level. S4. The lifecycle of the scheduled and activated memory units is managed through the MemLifecycle module of the memory operation layer. The lifecycle includes five stages: generation, activation, fusion, archiving and expiration. Stage transitions are automatically triggered by access frequency, time strategy and task tags or triggered by explicit control. S5. Memory units that have completed their lifecycle evolution are archived from the memory infrastructure layer to MemVault, where storage is organized by user, task, or scenario. At the same time, access control, compliance verification, and access auditing are performed through the MemGovernance module, and access control policies are allocated.

10. The method according to claim 9, characterized in that, In step S1, the structured memory operation instructions include memory query, write, update, transfer and combination operation instructions.

11. The method according to claim 9, characterized in that, In step S3, the memory unit includes parameterized memory, activation memory and plaintext memory, and the MemScheduler module performs unified scheduling, sorting and compression of the three types of memory units.

12. The method according to claim 9, characterized in that, In step S5, the access control policy includes an access control list, a time-to-live (TTL) period, and effective conditions, and the authorization boundary is determined based on the visitor's identity and the task context.

13. The method according to claim 9, characterized in that, In step S5, the memory infrastructure layer realizes cross-platform synchronization of memory units through the MemLoader and MemDumper modules, and supports open publishing and subscription of memory through the MemStore module.

14. A hardware device for implementing a large language model memory operating system, characterized in that, include: processor; Memory, used to store computer programs; When the computer program is executed by the processor, it implements the method for constructing a large language model memory operating system as described in any one of claims 1-4, or the method for running a large language model memory operating system as described in any one of claims 9-13.

Images