了解人工智能记忆：上下文、嵌入向量、RAG与模型权重详解
本文详细阐述了人工智能系统究竟是如何存储信息的，涵盖了上下文窗口、嵌入向量、向量数据库、RAG以及模型参数等内容。
今天与人工智能的对话场景：
“我正在开发一个机器学习项目。”
第二天，你再次联系对方：
“我的项目有哪些需要改进的地方？”
你会认为人工智能能记住你之前告诉它的内容吗？
有时它能记住。
有时则记不住。
还有时它只会记住部分对话内容，而完全忽略另一部分。
这引出了一个有趣的问题：
究竟是什么让人工智能系统能够记住某些事物？
真正的答案比简单地说：
要复杂得多。“人工智能有记忆功能。”
现代人工智能系统依靠多种不同的机制来存储信息，例如上下文窗口、对话状态、外部内存、检索系统、数据库以及模型自身的参数。
了解这些机制有助于明确当今人工智能的能力所在及其实际局限。
1. 第一个惊喜：大语言模型并不会自动记住一切
与语言模型交流时，会给人一种仿佛在和某个能够持续记住你的人对话的印象。
例如：
You:
My project is about crop disease detection.
AI:
That's interesting. You can use computer vision...
稍后：
You:
What model should I use?
AI:
For crop disease images, a vision model could be appropriate.
看起来人工智能记住了你所说的话。
但背后究竟发生了什么？
答案取决于这些信息实际上来自何处。
它可能来自：
- 仍处于活跃对话上下文中
- 由专用内存系统存储
- 从外部来源获取
- 间接嵌入模型的训练参数中
- 在用户不知情的情况下重新输入
尽管最终结果可能看起来相同，但这些其实是截然不同的机制。
2. 内存与知识并非同一概念
这一区别非常重要。
模型可能知道以下问题的答案：
“什么是CNN？”
但这并不能保证它能回忆起：
“你上周在项目中使用了CNN。”
可以这样区分：
KNOWLEDGE
"What is a CNN?"
↓
Learned during training
MEMORY
"The user is working on a CNN project."
↓
Stored/retrieved from context or memory system
知识反映了模型在训练过程中吸收的内容。
内存反映了当前可获取的关于特定用户、任务、环境或正在进行的交互的信息。
3. AI内存的最简单形式：上下文
在单次对话中最为基础的“内存”形式就是上下文。
看看这段对话：
User:
My dataset has 10,000 images.
AI:
Okay.User:
Should I use CNN?AI:
For 10,000 images, CNN could be...
AI是如何知道“10,000张图片”指的是什么的？
因为之前的消息可以与新消息一起反馈给模型。
从概念上来看，它是这样的：
Previous messages
+
Current message
↓
Context
↓
LLM
↓
Response
模型在生成回复时会依据所给定的上下文来工作。
4. 但上下文也有局限
问题就在这里变得复杂了。
模型无法在单次请求中处理无限长的文本。
这一限制有一个上限，被称为：
上下文窗口
可以将其视为模型一次能够处理的总信息量。
从概念上讲：
┌───────────────────────────────┐
│ CONTEXT WINDOW │
│ │
│ Previous messages │
│ Documents │
│ Instructions │
│ Current question │
│ Tool results │
│ │
└───────────────────────────────┘
当对话持续时间过长时，根据系统处理溢出的方式，早期的内容可能会被丢弃、简化或变得难以获取。
这就暴露了人工智能内存的第一个重大局限：
上下文确实很有用，但它并非无限。
5. 上下文算真正的记忆吗？
不完全是。
想象有人在提问之前把一堆文件交给你。你可以利用这些文件来回答问题，但这并不意味着它们已经永久存储在你的大脑中。
这里的逻辑也是如此：
Context
=
Information currently available to the model
相比之下，持久性内存的工作方式更像是这样：
Memory
=
Information stored for possible future retrieval
一旦开始构建人工智能智能体，这种差异就显得非常重要。
6. 短期记忆
人工智能智能体能够保存与其当前正在处理的任务相关的信息。
以以下指令为例：
“下载数据集，对其进行清洗、分析，并生成报告。”
在处理该任务时，智能体可能会这样记录自己的进展：
Task:
Create dataset report
Completed:
✓ Downloaded dataset
✓ Removed duplicates
✓ Calculated statisticsRemaining:
□ Create graphs
□ Write report
这类似于人类的短期工作记忆。智能体并非试图永远保留所有信息——它只需要完成当前任务所必需的细节。
7. 长期记忆
现在考虑一种智能体需要保存那些超越当前任务期限的信息的情况。
例如：
“我更喜欢用Python进行数据分析。”
内存系统能够保存这类细节，以便日后使用。大致如下：
Conversation
↓
Important Information
↓
Memory Store
↓
Future Conversation
↓
Retrieve Relevant Memory
↓
AI
这里的关键词是：
相关性。
一个设计良好的内存系统不应调出所有存储的内容，而应仅呈现当前任务所需的信息。
8. 系统如何选择合适的内存？
这才是真正有趣的部分。
假设某个内存存储中包含如下条目：
Memory 1:
User likes Python.
Memory 2:
User is working on computer vision.Memory 3:
User built a website.Memory 4:
User is learning distributed systems.Memory 5:
User prefers dark UI designs.
这时用户会问：
“我的图像项目应该使用哪种模型？”
调出所有存储的内存既浪费又没有必要，系统必须判断哪些内容真正适用。
这正是嵌入向量和向量搜索旨在解决的类型的问题。
9. 什么是嵌入向量？
嵌入向量将某条信息转换为数值向量。
从概念上讲：
"My project uses image classification"
↓
Embedding Model
↓
[0.12, -0.73, 0.44, ...]
另一段文本也可以经过相同的处理流程：
"Which model should I use for images?"
↓
Embedding Model
↓
[0.15, -0.69, 0.41, ...]
如果使用任何相似度计算方法后得到的向量足够接近，系统就可以将它们视为相关的概念。
这样一来，就可以基于语义相似性来检索信息，而无需依赖精确的关键词匹配。
10. 向量数据库
当拥有大量嵌入向量时，需要一个地方来存储它们——通常是专为向量搜索设计的数据库。
从概念上讲：
MEMORY
│
↓
Embeddings
│
↓
Vector Database
│
↑
User Query
│
↓
Query Embedding
│
↓
Similar Memories
检索系统可以查找在那个向量空间中嵌入值彼此靠近的记忆。
这一机制是当今RAG系统与记忆架构构建方式的基础。
11. RAG也是一种外部记忆
想象一家拥有50,000份内部文档的公司。
将所有这些文档直接嵌入模型参数中是不合理的，尤其是由于内容会随时间不断变化。
相反，这些文档需要经过预处理步骤：
Documents
↓
Chunking
↓
Embeddings
↓
Vector Database
每当有问题出现时，系统会在生成答案之前先进行检索步骤：
Question
↓
Embedding
↓
Search
↓
Relevant Documents
↓
LLM
↓
Answer
这种模式被称为检索增强生成，即RAG。
模型不会记住整个文档集，而是在需要时获取相关信息。
12. 模型参数是另一种形式的记忆
思考人工智能系统中的“记忆”还有另一种方式：
模型的权重。
在神经网络训练过程中，它会不断调整数百万甚至数十亿个数值参数。
简而言之：
Training Data
↓
Neural Network
↓
Parameter Updates
↓
Learned Weights
这些权重最终会编码训练过程中吸收的模式。
不过，这与拥有可检索的独立事实档案并非同一概念。
通常无法向模型提出如下请求：
"请告诉我你学到的关于主题X的完整句子。"
模型所掌握的知识分散在训练后的参数中，而非以可检索的记录形式存储。
13. 我们常称之为“记忆”的三种不同事物
此时有必要区分三个不同的概念：
1. 模型知识
以间接方式存储在模型的参数中。
Training
↓
Weights
↓
Learned capabilities
2. 上下文
当前输入到模型中的所有信息。
Conversation
↓
Context Window
↓
LLM
3. 外部记忆
完全存储在模型之外的信息。
Database
Vector Store
Files
Documents
User Memory
↓
Retrieval
↓
LLM
将这三者区分开来，就能弄清楚许多原本令人困惑的AI行为。
14. 为什么AI会“忘记”？
假设你告诉一个AI系统：
“我最喜欢的编程语言是Python。”
然而在对话进行很久之后，它却再也没有提及过这个偏好。
发生了什么？
有几种可能的解释：
Information no longer in active context
OR
Memory wasn't persisted
OR
Memory wasn't retrieved
OR
System chose not to use it
OR
The model misunderstood the reference
因此，当人工智能出现“遗忘”现象时，它并不一定是在表现得像一个容易遗忘的人类。
真正的原因可能是以下方面的故障：
数据存储、信息检索、上下文可用性或模型行为。
15. 人工智能智能体更需记忆功能
回想一下之前关于人工智能智能体的讨论。
一个智能体通常会循环执行以下步骤：
Plan
↓
Action
↓
Observation
↓
Action
↓
Observation
如果没有某种形式的持久化状态，涉及多个步骤的任务将极难管理。
以一个正在处理编程项目的智能体为例。
它需要记录诸如以下内容：
Which files changed?
What tests failed?
What has been completed?
What remains?
What errors occurred?
What decisions were made?
正因如此，智能体的内存结构通常会呈现为这样的形式：
AI AGENT
│
┌──────────┼──────────┐
↓ ↓ ↓
Context State Long-Term
Memory Memory
│ │ │
└──────────┼────────────┘
↓
Actions
16. 记忆无需保持非结构化状态
并非所有值得记住的内容都必须以自由格式的文本形式存在。
代理可以选择保存结构化记录，类似如下形式：
Project:
AirStore
Language:
PythonFramework:
FastAPIDatabase:
SQLiteCurrent Phase:
Storage NodeKnown Issue:
Heartbeat timeout
以这种方式组织的数据比在大量原始对话中查找和更新要容易得多。
这正是现实世界中的AI系统很少依赖单一存储机制的原因。相反，它们通常会同时结合多种方法：
- 数据库
- 结构化状态对象
- 向量存储
- 原始对话历史
- 生成的摘要
17. 将总结作为记忆技术
想象一下一段长达10万字的对话。
系统不必将每一行都视为同等重要，而可以将这些交流内容压缩成摘要。
Long Conversation
↓
Summarization
↓
Compact Memory
↓
Future Context
举个例子：系统不必保存关于某个项目的20条独立消息，而只需保留类似这样的内容：
“该用户正在开发一个基于Python和FastAPI的系统，用于在离线状态下跨不同节点存储数据，目前重点研究的是节点之间如何相互注册以及数据的复制方式。”
这样做可以减少每一步需要传递的数据量。
但压缩也有其风险：
如果重要信息在传输过程中丢失了怎么办？
正因如此，如何负责任地压缩内存本身就是一个复杂的工程问题。
18. 从本质上讲，内存关乎检索
这里一个较为微妙的见解是：AI内存其实并非关乎：
保存所有内容。
其核心在于：
保留有用的信息，并在恰当时刻调取所需内容。
一种简化的表达方式是：
M* = argmax over m in M of S(m, q)
其中：
- M 是所有存储的记忆集合
- q 是当前查询
- S(m, q) 表示某记忆与查询的相关性得分
- M* 是被判定为最相关的那条（些）记忆
用通俗的话来说：
Millions of memories
↓
Current question
↓
Relevance calculation
↓
Top useful memories
↓
AI
19. 存储更多记忆并不等同于更聪明
这一点非常重要。
假设某个人工智能系统存储了：
10,000 irrelevant facts
而另一个系统仅存储：
3 relevant facts
在实际应用中，哪一个表现更好？通常来说是后者。
大量无关的存储信息实际上会妨碍检索过程，并不必要的占用上下文空间。
因此，正确的关系应该是：
有用记忆 > 最大存储量
目标并非最大化存储容量，而是最大化存储内容的相关性。
20. 记忆事物会引发隐私问题
一旦系统能够记住用户的详细信息，就会出现一个新的问题：
这些信息究竟存储在何处？
可能敏感的数据可能会分散存储在：
Conversation history
Databases
Vector stores
Application logs
Files
Caches
这一现实带来了一系列工程上的要求：
- 限制访问权限
- 对存储数据进行加密
- 设定数据保留期限
- 提供删除机制
- 保留审计日志
如果没有这些保护措施，一个记录用户所有信息的系统可能会变成真正的隐私隐患。
21. 利用记忆来个性化响应
正是记忆让人工智能系统显得更加实用。
假设某个人工智能已经了解到你通常更喜欢：
Python
Simple explanations
Practical examples
Technical diagrams
后续的回答就可以根据这些偏好来生成。
这并不意味着底层模型本身在所有方面都变得更聪明。实际上：
General AI
+
Relevant User Context
↓
Personalized Interaction
正是这种区别使得记忆成为当今人工智能产品设计中极为重要的部分。
22. 未来展望：基于多层记忆的人工智能
先进的人工智能代理最终可能会利用这样的组合结构：
AI AGENT
│
┌─────────────┼─────────────┐
↓ ↓ ↓
Working Memory Long-Term External
Memory Knowledge
↓ ↓ ↓
Current Task Preferences Documents
History Databases
Projects APIs
└─────────────┼─────────────┘
↓
Retrieval
↓
LLM
↓
Action
这并非一个统一的“记忆容器”，而更像是多个独立内存层协同工作的组合。
23. 为何人工智能记忆与人类记忆不同
人类记忆是生物性的，具有动态性、关联性，并受感知、情绪、重复以及无数其他因素的影响，这些因素以我们尚未完全理解的方式相互作用。
相比之下，人工智能记忆则是通过设计构建的。
它通常依赖于以下组件：
Tokens
Vectors
Databases
Indexes
Parameters
Summaries
Retrieval algorithms
这两种记忆虽然可能产生看似相似的结果，但其运作基础却截然不同。
因此，每当有人声称：
“人工智能会记忆。”
就值得停下来思考：
究竟是哪种机制在提供这些信息？
24. 整合所有要素
现代人工智能系统可以这样理解：
USER
│
↓
QUESTION
│
↓
┌──────────────────┐
│ AI / LLM │
└────────┬─────────┘
│
┌───────────────┼────────────────┐
↓ ↓ ↓
Context Memory RAG/Search
│ │ │
Conversation Vector DB Documents
Current Task Database Web/Data
│ │ │
└───────────────┼────────────────┘
↓
Relevant Context
↓
LLM
↓
Response
当有智能体参与时，其结构会更加复杂：
Goal
↓
Retrieve Memory
↓
Plan
↓
Choose Tool
↓
Execute
↓
Observe
↓
Store Important Result
↓
Plan Again
↓
Finish
此时，内存不再只是被动的存储工具，而是成为智能体决策循环中的主动组成部分。
总结
每当有人说道：
“人工智能会记住。”
通常并不存在某个单一的、神奇的记忆系统来负责这一点。
实际上，通常是多个层次共同发挥作用：
模型知识 + 上下文 + 外部内存 + 检索机制
模型的参数存储了训练过程中学到的模式。上下文窗口为模型提供即时可用的信息，而外部内存则用于存储模型本身之外的信息。检索机制负责决定在实际需要时从这些存储的信息中调出哪部分。
这引出了一个有趣的结论：
人工智能内存的未来或许并不在于让模型记住一切。
更重要的是教会它们保留重要信息、舍弃无关内容、在恰当时机获取信息，并负责任地处理这些信息。
即便拥有无限存储空间但检索能力较差的人工智能，使用起来依然会令人沮丧；而具备精心设计的内存系统——即便规模较小——的人工智能反而可能更加实用。
所以真正的问题并非：
“人工智能能记住多少信息？”
而是：
“人工智能能否在恰当的时间回忆起正确的信息？”