> ## Content Index
> Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt
> Use this file to discover other available public pages before exploring further.

# AI 记忆是一个数据库问题
- URL: https://www.hubwiz.com/blog/ai-memory-is-a-database-problem/
- Published: 2026-06-02T12:14:54.000Z
- Updated: 2026-10-13T15:49:22.000Z
- Description: 大多数AI用户的本能是归咎于模型。如果答案错了，我们假设模型误解了任务。实际上，模型几乎总是在用给定的数据做我们告诉它做的事情。失败实际上发生在上游。
- Author: admin
- Tags: AGENT, #Import 2026-10-14 14:41

我在AI系统中反复遇到一个模式。我们一直把数据存储和检索当作一个新问题来对待。我们构建上下文窗口、向量存储、图和markdown维基，然后在它们上面叠加人工智能。结果是可预测的。系统变慢，答案变得不一致，可靠性永远无法达到我们对生产软件的期望。

因此，与其继续在抽象层面讨论架构，我运行了一个实验。我想要隔离一个变量：上下文是如何存储和检索的。不是它如何被建模或如何被解释，而是系统实际上如何获取回答问题所需的数据。

> *独特思维研讨会*

我认为这个框架比大多数关于"记忆"或"推理"的现代讨论更接近我们在AI系统中实际构建的东西。实用AI系统中的主导问题实际上是检索而非智能。在聊天中，我们希望它查找某样东西；在智能体中，我们希望它基于提供的资源完成任务。模型只知道它们被训练过的内容，智能体只能拉入系统赋予其访问权限的内容。该上下文的质量、结构和可访问性决定了系统是感觉快速、可靠、有用；还是缓慢、不一致、无法信任。

## 1、这不是模型问题，这是检索问题

大多数AI用户的本能是归咎于模型。如果答案错了，我们假设模型误解了任务。实际上，模型几乎总是在用给定的数据做我们告诉它做的事情。失败实际上发生在上游。

如果我们提供了太多上下文，延迟增加，信号被稀释。如果我们提供了错误的上下文，模型会产生幻觉。如果上下文在不同来源之间不一致，模型产生的答案看起来连贯但根本上是错误的。这些不是模型失败，而是检索失败。

一旦你接受了这一点，问题就发生了转移。你设计的系统主要不是一个AI系统，而是一个碰巧在末端使用AI模型的数据检索系统。

## 2、并非所有记忆系统都在解决同一个问题

我评估了三种从代码库存储和检索上下文的方法。这些系统是最近发布的，旨在帮助解决上下文图谱万亿级问题[1](#footnote-1)

1. [Mempalace](https://github.com/MemPalace/mempalace?ref=hubwiz.com)
2. [Graphify](https://github.com/safishamsi/graphify?ref=hubwiz.com)
3. [Llmwiki](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f?ref=hubwiz.com)

一个以维基风格的markdown存储上下文，一个具体化了代码库的完整图，另一个使用数据库风格的索引方法并支持增量更新。每个系统被赋予相同的语料库、相同的查询和相同的接口。

重要的约束是，虽然数据的表示形式允许不同，但评估集中在每个系统在查询时如何检索信息。这是我发现"AI记忆"变得最令人困惑的地方。我们把数据的结构方式与其访问方式混为一谈，而这并不是同一个问题。

```
Query: "Where is authentication handled?"

Markdown (LLMWiki):
- search across documents using grep/index

Graph (Graphify):
- load entire graph
- construct traversal structure
- traverse nodes

Wiki (MemPalace):
- lookup indexed entities
- follow relationships
- return scoped results

```

每个系统回答相同的问题，但它采用的路径根本不同。这个路径决定了性能。

## 3、加载一切才是真正的瓶颈

最初的假设是基于图的系统会表现良好。当图已经在内存中时，图遍历在计算上是高效的。问题在于真实系统不是在那个假设下运行的。图必须在任何遍历发生之前被加载、解析和构建。

这个成本主导了查询生命周期。它不是实现细节。它就是系统本身。

Graphify查询路径：

1. 从磁盘加载3.7 GB图
2. 构建内存中的图
3. 执行遍历

相比之下，依赖索引检索的系统完全避免了这一步。

MemPalace查询路径：

1. 查询索引存储
2. 检索匹配行
3. 返回限定范围的上下文

这些系统之间的差异不是理论上的。它是全局状态和选择性访问之间的差异。一个系统假设回答问题需要一切。另一个假设只需要一个子集。

## 4、数据库行为胜过表示形式

一旦在系统级条件下评估，结果毫不含糊。数据库风格的系统在延迟和存储占用上都以数量级的优势超越了markdown和基于图的方法。

延迟（系统级）：

- MemPalace: \~34 ms
- LLMWiki: \~2.2 s
- Graphify: \~35 s

存储：

- MemPalace: 8.8 MB
- LLMWiki: 33.9 MB
- Graphify: 3.7 GB

这不是渐进式改进。这是系统行为上的结构性差异。数据库风格的系统更快，不是因为更简单或更优化，而是因为它避免了不必要的工作。它不尝试加载或推理整个数据集。

## 5、获胜的系统都遵循数据库原则

表现最好的系统不是表示最丰富的那个，而是对数据访问方式施加约束的那个。它索引实体，在检索前缩小搜索空间，避免对数据集的全扫描。

这些不是新想法。它们是数十年以来已被充分理解的基础数据库原则。值得注意的是AI系统暴露忽视这些原则后果的速度有多快。

*示例查找模式：*

```
SELECT entity_id
FROM entities
WHERE name LIKE '%auth%';

SELECT *
FROM relationships
WHERE subject_id IN (...)
AND predicate IN ('implements', 'depends_on');

```

系统不尝试在查询时推断一切。它检索一个有界的、相关的数据子集，并将其传递给模型。这个约束是性能和可靠性的共同基础。

## 6、上下文存储是工程原语，不是AI特性

这项工作出于实际需要。我正在跨多个代码仓库监视整个代码目录，捕获发生的变化。从这些变化中，我提取模式、跟踪依赖关系并存储可重用的上下文。

目标不是构建一个抽象的记忆系统。而是回答在真实工程工作流中出现的问题，比如识别先前的实现或理解服务如何交互。

捕获的上下文：

`auth_middleware implements user_authorization`

`source: /internal/auth/middleware.go`

`payment_service depends_on auth_service`

`source: /services/payment/main.go`

这是从系统本身派生的结构化数据。AI模型不负责生成此上下文。它负责使用它。这个区别很重要。

## 7、如果检索很慢，构建在其上的一切都会崩溃

优化提示、调优模型或改进智能体逻辑很诱人。如果检索层效率低下，这些改变都不能解决核心问题。慢的检索增加整个系统的延迟。不一致的检索导致不可靠的输出。不正确的检索产生幻觉。

系统失败是因为它在数据访问方面缺乏纪律性。模型成为了更深层架构问题的可见表面。

我们正在实时重新发现数据库。

---

原文链接：[AI Memory Is a Database Problem](https://soypetetech.substack.com/p/ai-memory-is-a-database-problem)

汇智网翻译整理，转载请标明出处

> **这是「Agent / MCP」专题的一部分。**完整地图见：[Agent / MCP / 自动化完全指南](https://www.hubwiz.com/blog/agent-stack/)