LLM Memory and Personalization: How Far Are We from General Intelligence?

In recent years, the competitive focus for large language models has been shifting. Early technical progress centered on parameter scale, training data volume, context length, and reasoning capability. The next stage that deserves more attention is whether models can form stable memory across long-term interactions and deliver personalized services based on the user, the organization, and the business environment.

This means large models are no longer just stateless components that answer a question the moment it arrives. They may gradually evolve into intelligent systems that retain history, understand preferences, track tasks, and continuously correct their behavior.

However, does stronger memory and personalization mean artificial general intelligence is imminent? To answer this question, we first need to distinguish between model capability, system capability, and general intelligence.

1. Why Memory Is Becoming the Next Key Direction for Large Models

Traditional large model interfaces are typically stateless: each request must resubmit the necessary background, and the model itself does not naturally remember previous interactions. Even if a system supports a long context window, that does not mean it has true long-term memory.

A context window is closer to a “current workspace.” Once the conversation exceeds the window, or the session is rebuilt, earlier information may no longer participate in reasoning. Long-term memory requires the system to complete a more complex set of operations:

1. Determine which information is worth saving;
2. Convert information into a searchable, manageable form;
3. Recall relevant memories at the appropriate time;
4. Distinguish facts, preferences, inferences, and temporary states;
5. Identify whether a memory has expired or has been corrected by the user;
6. Avoid permanently entrenching incorrect content;
7. Allow users to view, modify, and delete relevant data.

Memory, therefore, is not simply writing all chat logs into a database. It is a complete engineering system involving information extraction, storage, retrieval, ranking, conflict resolution, security controls, and lifecycle management.

From a user experience perspective, memory reduces repeated input. For example, developers do not need to restate their tech stack, coding standards, and project background every time, and enterprise users do not need to repeatedly explain organizational terminology, approval workflows, and document formats.

From a business perspective, memory enables intelligent systems to continuously understand task state. They can do more than answer a single question: they can track goals, record the basis for decisions, identify unfinished items, and carry work forward in subsequent interactions.

2. Long-Term Memory Is Not the Same as a Larger Context Window

A longer context length can alleviate insufficient information, but it cannot fully replace long-term memory, for several reasons.

1. Cost Grows with Input Volume

If every request carries the full history, the input size keeps growing, and inference latency and resource consumption increase accordingly. A large amount of irrelevant information can also dilute what is truly important and affect the model’s attention to key instructions.

2. History Lacks Structure

Raw conversations often contain repetitive statements, temporary ideas, incorrect assumptions, and irrelevant content. If everything is fed to the model without organization, the system struggles to distinguish stable facts from one-off discussion.

3. Information Has a Shelf Life

A user’s role, project status, preferences, and permissions can all change. Simply retaining the full history does not resolve conflicts between old and new information. The system needs to record the source, creation time, update time, and credibility of information, and apply an explicit override or confirmation policy when conflicts occur.

4. Memory Recall Must Be Relevant to the Current Task

The core of long-term memory is not “how much is stored” but “retrieving the right content at the right time.” A mature memory system should filter based on the current question, task stage, user permissions, and memory type, rather than indiscriminately loading all data.

A context window is therefore a model input capability, while long-term memory is a state management capability surrounding the model. The two can work together, but they are not the same technology.

3. What Layers a Memory System Typically Contains

A production-oriented memory architecture can be divided into short-term memory, episodic memory, semantic memory, procedural memory, and organizational memory.

1. Short-Term Memory

Short-term memory holds temporary state within the current session and current task, such as a code snippet being edited, a requirement not yet confirmed, or the failure node currently being investigated.

This type of information is highly time-sensitive and usually does not need to be stored permanently. After the task ends, the system can delete it or compress it into a small set of valuable conclusions.

2. Episodic Memory

Episodic memory records “what happened,” typically with time, participants, task context, and outcome. For example:

• A user once asked to adjust the structure of a certain type of report;
• A particular outage was ultimately caused by a configuration error;
• A requirement was rejected during review;
• A task was once interrupted due to insufficient permissions.

Episodic memory helps the system understand behavioral history, but it cannot be treated directly as long-term valid fact. What happened in the past does not mean it still applies now.

3. Semantic Memory

Semantic memory stores relatively stable facts and concepts, such as a user’s preferred output language, the API conventions adopted by a team, domain terminology within a project, and confirmed business rules.

Compared with raw conversation, semantic memory usually needs to be extracted and summarized. For example, the system should not store the entire exchange “please answer in a concise format this time,” but can consolidate it as “the user prefers concise structure in technical Q&A,” while noting the scope and confidence of that preference.

4. Procedural Memory

Procedural memory focuses on “how to complete a task,” such as code review steps, troubleshooting order, documentation publishing workflows, and data verification rules.

It differs from ordinary knowledge and is closer to a repeatable working method. If a system can distill processes from successful cases and reuse them in later tasks, it will significantly improve consistency on complex tasks.

However, procedural memory cannot directly promote a single successful experience into a universal rule. The system needs to confirm through validation, approval, or repeated observation that the process truly has reuse value.

5. Organizational Memory

Enterprise scenarios also require organization-level memory, including internal policies, knowledge documents, business definitions, project decisions, and permission rules. Organizational memory cannot be stored mixed with personal memory, and one user’s private information must never be retrievable by another user.

Therefore, an enterprise system must at minimum establish different scopes such as user, team, project, department, and organization, and complete permission filtering before retrieval.

4. A Practical Memory Processing Pipeline

A complete memory chain can typically be divided into five stages: writing, governance, retrieval, assembly, and feedback.

1. Memory Writing

Not every turn of conversation is worth saving. The system must first determine whether information has long-term value. Common criteria include:

• Will it affect future answers?
• Is it a stable preference or a confirmed fact?
• Does it contain explicit task state?
• Can it be re-obtained from another authoritative data source?
• Does it involve sensitive information?
• Does the user permit storage?
• How long should it be retained?

The writing logic can be described with the following neutral pseudocode:

function process_candidate_memory(message, user_consent, current_task):
    if user_consent is false:
        return "do not write"
    candidates = extract_facts_preferences_and_task_state(message)
    for candidate in candidates:
        if candidate is sensitive and required_authorization is missing:
            skip
        if candidate is valid only for the current task:
            write_to_short_term_memory(candidate, expiration_time)
        else:
            normalize(candidate)
            annotate_source_time_scope_and_confidence(candidate)
            run_conflict_check(candidate)
            write_to_long_term_memory(candidate)

The key to this pipeline is “judge first, then save,” rather than recording all interactions permanently by default.

2. Memory Governance

Once memory enters the storage layer, it needs deduplication, merging, version management, and expiration handling. For example, if a user first expresses a preference for detailed answers and later explicitly requests concise answers by default, the system cannot treat both preferences as currently active rules.

A common approach is to retain historical versions but mark only the latest confirmed version as valid. For high-risk information, the system should require the user to confirm again rather than overwrite automatically.

Each memory entry can contain at least the following generic fields:

memory_record:
    subject_id
    memory_type
    normalized_content
    source
    created_at
    last_confirmed_at
    expiration
    scope
    permission_tags
    confidence
    current_status

These fields are a generic design illustration, not a fixed interface of any specific product.

3. Memory Retrieval

When a user initiates a new request, the system can first generate a retrieval intent and then obtain candidates from memories the user is allowed to access. Candidate ranking should not rely only on semantic similarity; it should also consider time, credibility, scope, and task relevance.

The ranking logic can be abstracted as:

overall_relevance =
    semantic_relevance
    + task_match
    + confidence_weight
    + temporal_validity
    + user_confirmation_weight
    - conflict_penalty
    - expiration_penalty

This expression is only an architectural idea, not a fixed algorithm. Different businesses should adjust the importance of each factor based on risk and data characteristics.

4. Context Assembly

After retrieving memories, the system cannot treat them directly as absolutely correct instructions. A safer approach is to assemble context by priority:

1. Security and compliance rules;
2. The current user’s explicit request;
3. Authoritative data for the current task;
4. Confirmed and still-valid long-term memory;
5. Low-confidence preferences inferred from historical behavior.

In particular, historical content must be prevented from overriding current instructions. For example, if a user previously preferred a certain code style but this time explicitly requests another style, the current request should take higher priority.

5. Feedback and Correction

A memory system must provide a correction channel. When a user points out “this is not my preference” or “this project has ended,” the system should be able to revoke, update, or deactivate the corresponding memory.

If a system only accumulates information and never forgets, errors and expired content will keep increasing over time, ultimately degrading answer quality. Controllable forgetting is just as important as accurate memory.

5. Personalization Should Not Become an Unexplainable User Profile

Memory provides the foundation for personalization, but personalization must remain transparent and restrained. Reasonable personalization can include:

• Adjusting the technical depth of answers;
• Adapting to terminology the user is familiar with;
• Maintaining project context;
• Following confirmed format preferences;
• Providing different scopes of information based on role permissions;
• Reducing repetitive operations by leveraging historical tasks.

Unreasonable personalization includes:

• Inferring sensitive attributes from limited behavior;
• Building long-term profiles without the user’s knowledge;
• Mistaking a one-time request for a permanent preference;
• Using historical information to influence decisions unrelated to the current task;
• Being unable to explain why something was stored or recalled.

Therefore, the system should, as much as possible, let users know “what was remembered, why it was remembered, how long it is kept, and where it is used,” and provide the ability to disable personalization, clear memory, and export records.

6. Major Technical Risks in Enterprise Deployment

1. Erroneous Memories Get Continuously Amplified

A model may extract incorrect conclusions from ambiguous statements. Once incorrect content enters long-term memory, subsequent answers may repeatedly reference it, making the problem more serious than a single generation error.

Solutions include assigning confidence levels, distinguishing explicit user statements from system inferences, requiring confirmation for key facts, and periodically re-validating high-impact memories.

2. Instruction Contamination in Historical Content

External documents, historical messages, or knowledge records may contain text that looks like instructions. When the system recalls such content, it should treat it as data rather than automatically executed high-priority commands.

In engineering terms, the “instruction zone” and the “reference zone” need to be separated, and content sources marked, so that historical text cannot alter the system’s security boundaries.

3. Permission Leakage

Enterprise memory may span multiple projects and departments. If retrieval is based only on semantic similarity without performing permission filtering first, information the user is not authorized to view may be returned.

The correct order is to complete identity verification and permission constraints first, then retrieve and rank within the authorized scope. Permission checks cannot rely solely on model judgment; they must be enforced by deterministic access control mechanisms.

4. Privacy and Data Lifecycle Issues

Long-term memory means data is retained longer and governance responsibility is greater. Enterprises should define data minimization principles, retention periods, deletion processes, audit records, and synchronized deletion policies for backups.

For sensitive content, generic measures such as encrypted storage, field masking, tiered access, and operation auditing can be applied. For content that does not need long-term retention, automatic expiration rules should be set.

5. Personalization Leads to Capability Lock-In

If a system answers based on existing preferences over the long term, it may confine users to past behavioral patterns. For example, if the system always provides beginner-level explanations, it may overlook that the user’s capabilities have grown.

Personalization should therefore allow dynamic adjustment and periodically verify whether preferences are still valid. The system must both leverage history and respect the user’s current explicit choices.

7. How to Evaluate Memory and Personalization Capabilities

Traditional Q&A accuracy alone cannot fully measure a memory system. Enterprises can build an evaluation framework around the following dimensions.

1. Writing Accuracy

Examine whether the system saves genuinely valuable information, and whether it incorrectly stores temporary content, unconfirmed inferences, or sensitive data.

2. Recall Accuracy

Assess whether the system can find the correct memory when needed, while avoiding recall of irrelevant or expired information.

3. Conflict Handling

Construct scenarios such as preference changes, fact updates, and contradictions across sources, and observe whether the system can identify conflicts and apply reasonable confirmation, override, or deactivation strategies.

4. Permission Isolation

Test with different identities and scopes to confirm that personal, project, and organizational memories do not suffer unauthorized access.

5. Forgetting Effectiveness

Verify that after a user deletes a memory, online retrieval, caches, indexes, and subsequent answers all stop using the relevant data in sync.

6. Personalization Benefit

The value of personalization should not be judged only by whether users feel it “seems more like me.” It should also measure whether task completion time, repeated input volume, revision counts, and result consistency improve.

7. Degradation and Stability

As the volume of memory continues to grow, observe whether retrieval latency, context noise, and answer quality degrade. The system should also have reasonable degradation capability when the memory service is unavailable, so that core business is not completely interrupted.

8. How Enterprises Should Build in Phases

Enterprises do not need to build a complex,全域 memory platform from the start. A more prudent approach is phased implementation based on risk and benefit.

In the first phase, focus on current session state to solve multi-turn task interruption and repeated input. At this stage, prioritize short-term memory and set explicit expiration times.

In the second phase, introduce preference memory that users explicitly confirm, such as language, format, and common working methods. All memories should be viewable, modifiable, and deletable.

In the third phase, connect governed enterprise knowledge and establish permission boundaries at the role, project, and department levels. This phase should focus on building auditing, versioning, and data lifecycle mechanisms.

Only in the fourth phase should you consider distilling procedural experience from historical tasks so the system can reuse successful processes. Because such capabilities may affect actual operations, approval, validation, and rollback mechanisms must be added.

If an enterprise uses cloud infrastructure such as Baidu AI Cloud, the relevant chain can be built on generic object storage, databases, container platforms, logging services, monitoring and alerting, and access control capabilities. However, the specific architecture should still be designed according to data sensitivity, business scale, and compliance requirements. The availability of cloud resources should not be equated directly with the reliability of a memory system.

9. Do Memory and Personalization Mean General Intelligence Is Imminent?

Memory is indeed an important component of more general intelligent systems. Models lacking long-term memory struggle to continuously learn user needs and to maintain goal consistency across tasks over time. Personalization allows systems to adapt to different environments rather than providing exactly the same behavior to every user.

But memory and personalization alone are not enough to conclude that artificial general intelligence is close to realization. Broader general intelligence typically also requires capabilities in multiple areas:

• Forming reliable plans for unfamiliar tasks;
• Transferring knowledge across domains;
• Recognizing the boundaries of one’s own knowledge and uncertainty;
• Building stable causal models of complex environments;
• Maintaining goal consistency across long-term tasks;
• Learning from feedback without breaking existing capabilities;
• Taking action under resource, permission, and safety constraints;
• Providing verifiable grounds for key decisions.

Much of what is currently called “memory” is essentially data storage and retrieval external to the model. It can improve interaction continuity, but it does not mean the model has formed autobiographical memory similar to a human’s, nor does it mean the system can autonomously understand all experience.

Likewise, personalization usually means adjusting output based on known preferences. It does not mean the system truly understands a person’s values, intentions, and long-term goals.

10. Conclusion

The shift of next-generation large models from “bigger” to “remembering more accurately and adapting better” is an important signal that the technology is becoming more practical. Long-term memory can reduce the cost of repeated communication, and personalization can improve task fit. Combined, intelligent systems will feel more like continuously collaborating assistants rather than one-off Q&A interfaces.

But the stronger the memory capability, the higher the risks of error entrenchment, privacy leakage, permission overreach, and behavioral manipulation. A truly mature solution should not pursue unlimited storage, but should achieve selective writing, controlled retrieval, transparent use, timely correction, and verifiable deletion.

Memory and personalization are therefore better viewed as a set of infrastructure on the path toward general intelligence, not as sufficient evidence that general intelligence has arrived. For developers and enterprises, the most valuable work at this stage is not predicting a specific date, but building a memory architecture that is governable, evaluable, and auditable, so that intelligent systems gain continuity while remaining safe, accurate, and controllable.