数据库作为 LLM 记忆体：语义缓存、RAG 与一致性

原文发布于 quant67.com，转载请保留出处。

大语言模型（Large Language Model, LLM）本身是无状态的。它只记得 prompt 里出现的内容，超出 context window 就遗忘。"记忆"是外挂进去的，而最常见的外挂形态就是数据库------向量库、关系库、KV 库，或者三者组合。

当我们把数据库当 LLM 的记忆体，很快就会遇到一组熟悉的老问题：读到旧值、写丢失更新、会话之间互相污染、多轮对话里的"事实"前后矛盾。这些问题在数据库教科书里已经被讨论了四十年------linearizability、causal consistency、read-your-writes------只是在 LLM agent 场景里换了名字叫 "semantic drift"、"hallucinated memory"、"context leak"。

本文上半梳理 LLM 记忆体的系统视角：GPTCache 的语义缓存、MemGPT 的分层记忆、向量记忆与事实记忆的分工；下半给出一个用 pgvector + 触发器实现的会话一致性语义缓存工程样例。

一、为什么需要 "数据库式" 记忆

直接把对话历史拼进 prompt 是最朴素的记忆方案。它的极限是 context window------今天最大的开源模型也才 1M token 级，而且长 context 下注意力质量显著衰减（lost-in-the-middle 现象）。更重要的是：

成本线性增长：每轮对话把所有历史拼回 prompt，token 数随轮次累积。
无法共享：用户 A 对话里产生的有用知识，对用户 B 不可见。
无法持久化：进程重启、模型换代，历史就丢。

把历史挪到数据库就同时解决这三点。但挪进去的瞬间也继承了数据库的一切麻烦------事务、一致性、并发、GC。

1.1 两类记忆，不要混为一谈

一个常见的工程误区是把 "LLM 记忆" 当成单一概念。实际上至少要分两类：

向量记忆（Vector Memory）：把对话 / 文档切片，encode 成 embedding 存进向量库，查询时按 cosine 距离召回 top-k。适合"语义相似"检索。
事实记忆（Factual Memory）：结构化的 key-value 或行记录，比如"用户 Alice 的偏好语言是英文"。适合"精确 read/write"。

这两类记忆的一致性要求完全不同。向量记忆容忍"有点过时"（毕竟 top-k 本身就是近似），事实记忆通常要求"至少读到自己写的"。把两者放在一个库一个一致性模型里是常见踩坑源。

二、GPTCache：语义缓存的第一性原理

GPTCache（Bang et al., NLP-OSS @ EMNLP 2023）是第一个被广泛讨论的 LLM 语义缓存开源项目。它的核心问题很小：同样的问题被反复问，没必要每次都让 LLM 重算。

2.1 语义键匹配

传统 HTTP / DB 缓存的键是"字符串完全匹配"。LLM prompt 字符串每次都略有不同（用户会换个说法），所以需要语义键：

text 复制代码

原始 query:   "how many orders last week?"
同语义 query: "tell me the count of orders in the past 7 days"

GPTCache 的做法：

把 query encode 成 embedding。
在向量库里找 top-k 最近的历史 query。
如果最近的距离 ≤ 阈值，就返回历史 query 对应的 LLM 答案。
否则调用 LLM，并把 (query, embedding, answer) 写回缓存。

2.2 语义缓存的一致性陷阱

语义缓存看起来很美，但在真实系统里会出几类问题：

阈值边界抖动：同一个 query 第一次存进去，第二次因为 embedding 模型的随机性召回距离刚好超阈值，miss，重新调 LLM，写进去第二份。缓存里同义项目越来越多。
命中但语义漂移：问的是"上周订单"，召回一周前另一个用户问的"上周订单"------时间语义不同但文本相似，缓存命中导致答案错误。
写污染：LLM 答案本身是错的，被缓存下来后每次命中都给错答案，几周都发现不了。

解决这些的方法依然是传统数据库方法：加 key、加租户隔离、加 TTL、加回归测试，没有银弹。GPTCache 的价值在于把问题暴露出来，让工程师意识到 "语义缓存不是缓存，是一种近似数据库"。

三、MemGPT：把 OS 的分级存储搬进 LLM

MemGPT（Packer et al., arXiv 2310.08560, 2023, "MemGPT: Towards LLMs as Operating Systems"）把 LLM 当成 CPU，上下文窗口当成 RAM，外部数据库当成磁盘，构建了一个分级存储。它的几个核心抽象：

Main Context：模型当前看见的内容（system prompt + working memory + last messages）。
Recall Memory：最近历史的结构化存档。模型可以通过函数调用翻回。
Archival Memory：更远的历史或知识，一般向量化存储。

模型自己决定什么时候把 main context 里的内容 "write-back" 到 archival，什么时候把 archival 的内容 "page-in" 到 main。这套抽象解决了单会话里的长期记忆问题。

3.1 MemGPT 的工程启发

MemGPT 本身论文关注的是"让 LLM 自己管理记忆"。对工程师而言可迁移的抽象是：

显式定义每层记忆的 TTL 与作用域：main 是 per-turn，recall 是 per-session，archival 是 per-user 或 per-tenant。
读写接口要少、要清晰 ：只暴露 remember(key, value)、recall(query)、forget(key)，不要让 LLM 直接写 SQL（参见上一篇 Text-to-SQL 讨论的权限问题）。
跨层同步要延迟做：main → recall 的写回不要每轮同步落库，按 batch + idle flush，否则 OLTP 压力不可控。

四、一致性模型：把经典结论映射到 agent memory

这是本文最关键的一节。很多 LLM agent 项目的 bug 本质是用了一个连 DBA 都不会接受的一致性模型。

4.1 线性化（Linearizability）

线性化要求所有操作看起来是按某个全局顺序一次发生，而且顺序与实时时间一致。它是强一致的金标准。

在 agent memory 场景：如果用户刚说"我讨厌番茄"，紧接着问"你记得我讨厌什么吗"，应该回答"番茄"。这是一个典型的 read-your-writes 要求。没有任何理由放弃这个保证，否则用户体验直接塌方。

工程实现：同一会话的读写必须走同一个数据库连接 / 同一个主副本。这是所有以"多副本 + 最终一致性"为默认的系统（ES、DynamoDB、大多数向量库）需要注意的地方。

4.2 因果一致性（Causal Consistency）

用户 A 的会话里告诉 agent"把我搬到伦敦"，用户 A 后续的会话应该看到这条记录；但用户 B 是否同步看到，不需要。只要会话内、用户内因果一致即可。

这是一个比线性化弱、但对分布式向量库更可行的保证。实现要点：

session_id / user_id 作为 partition key：保证同一 session 的写不会跨 partition。
写返回 token（vector clock）：后续读带上 token，副本没收到就阻塞。

4.3 会话隔离（Session Isolation）

跨用户 / 跨 session 的污染是生产事故的常见源：

用户 A 问"我的银行卡号是什么"，命中了另一个会话的缓存 embedding，返回用户 B 的信息------直接 GDPR 级事故。
同一用户跨 session，一个过期订单信息被当前 session 召回，误导用户。

隔离姿态：每一条记忆记录都带 session_id + user_id + tenant_id，查询必须带这三把筛子。这一点在下半的 pgvector demo 里会具体演示。

4.4 MVCC 的启发

数据库的多版本并发控制（Multi-Version Concurrency Control, MVCC）给 agent memory 一个非常有用的设计思路：记忆不原地改，写入新版本。这样：

旧对话可以被审计和回放。
当前会话读最新版本，历史会话读自己看见过的版本。
"忘记"变成把版本标记为 tombstone，而不是物理删除。

关于 MVCC 的细节可参考 MVCC 原理与实践与 MVCC 变体。把这些经典机制复用到 agent memory 上，比重新发明一套规则划算得多。

五、RAG 与记忆的边界

Retrieval-Augmented Generation（RAG）常被和 "LLM 记忆" 混为一谈。它们有共通之处也有差异：

RAG 的数据源通常是相对静态的知识库（文档、代码、手册），一致性要求低（today 和 yesterday 的 chunk 差一点无伤大雅）。
Agent memory 的数据源是用户本人的交互历史，一致性要求高（丢了就是产品事故）。

好的架构是把两者分库：RAG 走向量库（Milvus / pgvector / Qdrant），按 chunk 索引；Agent memory 走关系库 + 向量扩展（pgvector、Timescale），以会话 / 用户为主键，向量只是一个辅助召回通道。

六、工程样例：pgvector + 触发器实现语义缓存

下半给一个能直接跑的最小实现。目标：在 PostgreSQL 里做一个带会话隔离的语义缓存，满足：

同会话里严格 read-your-writes；
跨会话按 tenant 隔离；
命中阈值可调；
写入自动维护 embedding 和 TTL。

6.1 表设计

sql 复制代码

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE sem_cache (
    id            BIGSERIAL PRIMARY KEY,
    tenant_id     TEXT NOT NULL,
    session_id    TEXT NOT NULL,
    query_text    TEXT NOT NULL,
    query_vec     vector(768) NOT NULL,
    answer_text   TEXT NOT NULL,
    created_at    TIMESTAMPTZ NOT NULL DEFAULT now(),
    expires_at    TIMESTAMPTZ NOT NULL DEFAULT now() + interval '7 days',
    version       BIGINT NOT NULL DEFAULT 1,
    tombstoned    BOOLEAN NOT NULL DEFAULT false
);

-- ANN index on vector; filter预过滤必须用 WHERE + b-tree 复合
CREATE INDEX ON sem_cache USING hnsw (query_vec vector_cosine_ops);
CREATE INDEX ON sem_cache (tenant_id, session_id, expires_at)
    WHERE tombstoned = false;

要点：

tenant_id + session_id 是强制筛子，每个查询都必须带；
expires_at 兜底 TTL；
version + tombstoned 给 MVCC 风格的"修正记忆"留口子。

6.2 查询：带隔离的语义命中

sql 复制代码

WITH q AS (
    SELECT $1::vector(768) AS qv
)
SELECT id, answer_text, 1 - (query_vec <=> q.qv) AS similarity
FROM sem_cache, q
WHERE tenant_id  = $2
  AND session_id = $3
  AND tombstoned = false
  AND expires_at > now()
ORDER BY query_vec <=> q.qv
LIMIT 1;

应用层拿到后判断 similarity >= threshold（典型 0.92--0.95）才算命中，否则调 LLM 并写回。注意 WHERE 里的 tenant_id 和 session_id 条件必须放在索引里，否则 HNSW 先召回 top-k 再过滤可能因为被 tenant 过滤后为空而漏掉结果。pgvector 0.7+ 的 iterative scan 对这个场景友好。

6.3 写入：保证 read-your-writes

sql 复制代码

-- 在同一个会话同一个连接里立刻可见，无需额外同步。
INSERT INTO sem_cache (tenant_id, session_id, query_text, query_vec, answer_text)
VALUES ($1, $2, $3, $4, $5);

关键约束：同一个 session_id 的所有请求必须路由到同一主库连接 。在 PgBouncer 前面做 session affinity，用 session_id 的 hash 做一致性哈希，避免跨副本 lag 导致 "刚写完读不到" 的现象。

6.4 触发器：自动维护 TTL 与 tombstone 逻辑

sql 复制代码

CREATE OR REPLACE FUNCTION sem_cache_update_version()
RETURNS trigger AS $$
BEGIN
    NEW.version := OLD.version + 1;
    NEW.expires_at := now() + interval '7 days';
    RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER sem_cache_version
BEFORE UPDATE ON sem_cache
FOR EACH ROW
EXECUTE FUNCTION sem_cache_update_version();

当 agent 产生"更正"信号（比如用户说"我之前说错了"），应用层走 UPDATE sem_cache SET answer_text = $new WHERE id = $old，触发器自动 bump version、刷新 TTL。如果是遗忘指令，则 UPDATE ... SET tombstoned = true。不物理删除，保留给审计和回放。

6.5 后台清理

sql 复制代码

-- 每天一次，物理删除过期且已 tombstone 的行。
DELETE FROM sem_cache
WHERE tombstoned = true
  AND expires_at < now() - interval '30 days';

过期行即使没 tombstone 也可以保留一段时间，只靠 expires_at 过滤不回给用户。物理删除放到冷窗口，避免 HNSW 索引重建引起抖动。

6.6 一致性等级总结

上述设计给出的保证（从强到弱）：

场景	保证	实现手段
同会话读自己写的	read-your-writes	session affinity 到主库
跨会话同用户	因果一致（读主）	tenant_id + user_id 作为 partition key
跨租户	严格隔离	WHERE tenant_id = $ 强制谓词 + RLS 兜底
跨副本只读查询	最终一致	容忍 lag，必要时带 max_staleness 参数

这四档映射直接对应分布式系统教科书里的 linearizability / causal / session / eventual。2026 年没有什么新东西，只是换了场景。

6.7 真实生产里还要注意什么

RLS（Row-Level Security）做最后一道墙：即使应用层忘了带 tenant_id，RLS policy 也能挡住跨租户读。
向量维度随 embedding 模型变化：换模型必须全量重写入或用不同表，不要偷懒把两个维度的向量混进同一张表。
阈值要 A/B：0.92 和 0.95 的命中率差非常大，必须结合实际业务做 A/B，而不是拍脑袋。
observability ：为每次命中 / miss 打点 (session_id, similarity, hit_ttl_remaining)，方便事后分析 drift。

6.8 真实生产里还要注意什么

RLS（Row-Level Security）做最后一道墙：即使应用层忘了带 tenant_id，RLS policy 也能挡住跨租户读。
向量维度随 embedding 模型变化：换模型必须全量重写入或用不同表，不要偷懒把两个维度的向量混进同一张表。
阈值要 A/B：0.92 和 0.95 的命中率差非常大，必须结合实际业务做 A/B，而不是拍脑袋。
observability ：为每次命中 / miss 打点 (session_id, similarity, hit_ttl_remaining)，方便事后分析 drift。

6.9 运行时剖析

在一个千万级记忆条目的 pgvector 生产环境里，一条查询的典型时间构成：

text 复制代码

 0 ─ 2 ms   客户端 -> PgBouncer -> Postgres 建连 / 复用
 2 ─ 5 ms   WHERE tenant_id / session_id / expires_at 过滤走 b-tree
 5 ─ 12 ms  HNSW ANN top-k 召回
12 ─ 15 ms  应用层阈值判断 / 返回

LLM 调用通常 300--2000 ms。如果语义缓存命中率 30%，整体延迟节省 25% 以上，这是语义缓存在生产里真正的卖点。但这个结果完全取决于前面的隔离和阈值是否做对，否则命中率再高也没意义。

6.10 一个常被忽视的场景：跨会话 "学习"

有时产品希望"agent 从所有用户的交互里学习"------比如发现大家都在问"发票怎么开"，把这条沉淀成公司级 FAQ。这个需求和隔离要求是直接冲突的，必须分两层处理：

租户内共享层：同一租户内的"共识记忆"走一张 shared_memory 表，写入前过人工 / 规则审核。
跨租户统计层：对跨租户统计出来的热问题，只以"匿名 + 聚合"形式展示给产品人员，不回流任何 LLM。

这种设计直接映射到差分隐私（下一篇 20 号会单独展开）。对本篇而言要记住的是：跨会话学习 ≠ 跨会话共享记忆。

6.11 与仓库其他文章的互链

存储侧的 MVCC 基础，参考 MVCC 原理与实践。
MVCC 的多种实现变体以及 GC 策略，参考 MVCC 变体。
上一篇 Text-to-SQL 讨论的只读白名单与权限分层，正是本文 agent memory 写入接口设计的前置条件。
下一篇将进入向量索引本身的深度解读（HNSW / DiskANN / SPANN），参考向量索引深度解读。

七、把记忆架构当成一个小型数据库系统来设计

最后一节拉远一点视角：不要把"LLM 记忆"当成一个独立新问题，它其实是把传统数据库里 session、cache、audit 三件事组合起来的新形态。

7.1 记忆即 session

传统 OLTP 的 session 是"一个 TCP 连接绑一批事务"。LLM agent 的 session 是"一个用户 × 一个 agent × 一段时间"。两者共享相同的关键需求：

绑定 identity：session 必须绑用户。
有起止边界：login / logout、会话开始 / 结束。
可审计：每个写操作可追溯。

这决定了 agent memory 的 session 管理应该复用数据库的 session 管理 ，而不是另起一套。例如在 PostgreSQL 里可以用 SET LOCAL app.current_session_id = '...'，把 session id 绑到 transaction 内，后续 trigger、RLS policy 都能读到。

7.2 记忆即缓存

GPTCache 一节讨论过"语义缓存"。更一般的说法是：LLM 的每一次输出都可以被看成一个带语义键的缓存项。这层抽象让我们能直接搬缓存系统的成熟做法：

多级：内存里 LRU（最近几百条），数据库里 ANN（全量）。
失效策略：TTL + LRU + 显式失效。
风暴保护：热 key 的重算要加 single-flight，避免同一 query 并发未命中时同时打 LLM。

Single-flight 在 Go、Rust 里都有成熟库，跟 LLM 记忆的结合几乎是粘合代码。跳过这一步会在流量尖峰时被 LLM 账单教育。

7.3 记忆即审计

合规视角下，LLM 的每一次生成都是一条审计事件。这与数据库的 WAL 非常像：

WAL 记录"谁在什么时间改了哪些数据"。
LLM audit 记录"谁在什么时间用什么 prompt 生成了什么答案"。

把 audit 存在独立的 append-only 表（inserts only、no updates、no deletes），再给它开单独的只读访问权，和数据库的 WAL 管理如出一辙。这样在事后追查、合规审查时，能用熟悉的数据库工具（pgBadger、pg_wal 分析工具）直接工作。

7.4 开放问题：跨模型的记忆兼容

到 2026 年仍没解决的一个开放问题是：embedding 空间不兼容。换一个 embedding 模型（比如从 OpenAI text-embedding-3 换到 BGE-M3），所有历史向量失效，必须重写入。这对已经存了几 TB 语义缓存的团队极其痛苦。

当前的折中方案：

只存原文，不存 embedding，需要时现场算。牺牲延迟换可迁移。
存多套 embedding，每个模型一列向量。牺牲空间换灵活。
把 embedding 版本化 ，同表多版本向量共存，查询时带 embedding_version = $current。折中方案。

这个问题短期内没有通解。把 embedding 模型换代看作一次全量重写，是比较务实的心态。

7.5 小结

"数据库作为 LLM 记忆体"表面上是一个新命题，往里看会发现所有经典问题都回来了：一致性、隔离、审计、版本、GC。过去四十年数据库社区攒下的工程智慧并没有被 LLM 冲走，反而换了一副外壳继续发挥作用。

这也是为什么这个系列从第 3 篇开始花五篇篇幅讨论 AI 原生数据库------AI 原生的 "新" 实际上是 "旧问题在新场景下的重组"。看透这一点，工程决策就会稳很多。

八、RAG × Agent Memory 的产品形态

本文前半把 RAG 和 agent memory 分开讲。产品落地时两者必须协作，这里补充一个完整的产品形态参考。

8.1 三层知识栈

一个成熟的 LLM 应用的知识栈往往长这样：

text 复制代码

┌─────────────────────────────────────────────┐
│ Long-term Knowledge (RAG)                    │ 静态 / 准静态文档、代码
│  - 文件入库：chunk + embed + index           │
│  - 查询：topk ANN + rerank                   │
│  - 更新：按源文件版本差异                     │
└─────────────────────────────────────────────┘
┌─────────────────────────────────────────────┐
│ User / Session Memory                        │ 本文焦点
│  - 写：会话过程中自动 write-back              │
│  - 读：会话开头 load, 每轮按需 recall          │
│  - 隔离：tenant / user / session 三把筛子     │
└─────────────────────────────────────────────┘
┌─────────────────────────────────────────────┐
│ Short-term Context (prompt)                  │ 本轮 prompt
│  - system prompt + few-shot + current turn   │
│  - rotating window，by-token budget          │
└─────────────────────────────────────────────┘

三层的 一致性预算 完全不同：顶层是最终一致（文档两天后更新也没事），中层是会话级一致（当前对话不能互相矛盾），底层是线性化（本次请求内的顺序严格保证）。

8.2 跨层通信的陷阱

跨层通信时常见 bug：

RAG 覆盖了 memory：用户说"我叫 Alice"被写进 memory；RAG 恰好命中一篇说 "Alice is a dog trainer" 的旧文档；LLM 把两条当成同一件事，告诉用户"好的 Alice，我记得你是驯狗师"。对策：不同层的检索结果在 prompt 里用不同 role 标记，模型被教导优先 memory > RAG > system。
memory 污染 RAG：用户某次玩笑把 "Pluto is a planet" 写进 memory，下次检索 "planet" 主题时 memory 命中把玩笑当事实。对策：memory 的权威级别低于 RAG，只有"用户事实"类记忆才允许覆盖。
检索命中顺序依赖：LLM 对 prompt 中 context 的顺序敏感；memory 与 RAG 的拼接顺序要固定，并且随机翻转做回归测试。

8.3 产品化清单

把一个 "能用" 的 LLM 记忆产品化需要的东西（按优先级）：

tenant / user / session 三元组的严格隔离与 RLS。
每条记忆 append-only + 版本化 tombstone。
embedding 模型的版本字段，所有检索都带过滤。
TTL + 后台回收 job。
管理后台：搜索、导出、删除（GDPR 合规）。
观测：命中率、命中相似度分布、跨 session 污染告警。
A/B 框架：阈值与 prompt 的 A/B。

缺了其中任何一条，你都可能在线上吃到教训。这个清单本质上就是把数据库运维那一套 "ACID + audit + capacity + backup" 搬到 LLM 记忆层。认识到这一点，就不会再把 LLM 记忆当成一个"新问题"。

九、关于"遗忘"的设计

一个容易被忽视但在合规语境下极重要的问题：agent memory 的遗忘机制。

不同法域的表述不同，核心要求一致：数据主体有权要求删除自己的数据。在 LLM agent 场景这意味着：

用户点"删除我的记忆" → 所有该用户的记忆条目必须在合理时间内被删除。
训练用数据中包含该用户痕迹的 embedding、调试日志、缓存，都要清掉。
删除必须可审计（什么时候删的、谁操作、删了多少条）。

9.2 软删 vs 硬删

"tombstone + 30 天后物理删" 是个常见折中。软删保留审计能力，硬删满足合规。实现上要注意：

软删后所有读路径都要过滤 tombstoned = true，一处漏了就合规事故。用 RLS policy 兜底。
硬删清理 embedding 时要同步清 ANN 索引，否则 HNSW 里还能召回到已删节点。
备份里的副本也要删。很多团队忘了这条------合规删了主表但备份里还在，审计时直接踩雷。

9.3 选择性遗忘

比整体删除更麻烦的是"记住 A 不记得 B"。比如用户希望 agent 记得自己的偏好但不记得某次失败对话。这在产品上需要：

记忆分类：每条记忆带 category（preference / event / instruction / hallucination）。
按 category 遗忘：删除 category = hallucination 的所有条目。
用户可见的管理界面：让用户自己分类记忆。

2026 年这方面还没有业内标准，属于产品和合规共同发展的领域。但提前留好 category 字段几乎零成本，后面需要时能省下重构工作量。

十、读者扩展阅读建议

如果你想深入本文涉及的每条线，这里给一个阅读建议：

一致性模型：Bailis 2014 "Highly Available Transactions"、Jepsen 博客的 consistency hierarchy、Kleppmann 《Designing Data-Intensive Applications》第 5、9 章。
向量检索：先读 HNSW 原论文 (Malkov & Yashunin, 2016)，再读 DiskANN (NeurIPS 2019)，然后看 pgvector 源码中 hnsw.c 就能贯通。
agent memory：MemGPT、GPTCache 源码值得读；LangChain / LlamaIndex 的 memory 模块也值得读，主要看他们怎么不做。
合规：GDPR 第 17 条（Right to Erasure）、中国个人信息保护法第 47 条，直接读条文比看二手解读更准确。

这几条路径有些偏工程、有些偏合规，拼在一起覆盖了本篇的全部侧面。读完之后如果你只记得一句话，希望是："LLM 记忆是一个被重新命名的数据库问题，不是一个新问题。" 带着这句话再去看后续所有 agent memory / LLM 记忆的新工作，你会更快辨别哪些是真创新、哪些是把 1990 年代的 session management 换了个名字重新卖一遍。

参考文献

F. Bang, "GPTCache: An Open-Source Semantic Cache for LLM Applications", NLP-OSS @ EMNLP 2023, aclanthology.org/2023.nlposs....
C. Packer et al., "MemGPT: Towards LLMs as Operating Systems", arXiv:2310.08560, 2023, arxiv.org/abs/2310.08....
P. Lewis et al., "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks", NeurIPS 2020, arxiv.org/abs/2005.11.... RAG 的原始论文。
N. F. Liu et al., "Lost in the Middle: How Language Models Use Long Contexts", TACL 2024, arxiv.org/abs/2307.03.... 长 context 注意力衰减实证。
M. Herlihy and J. M. Wing, "Linearizability: A Correctness Condition for Concurrent Objects", TOPLAS 1990, dl.acm.org/doi/10.1145.... 一致性模型经典论文。
P. Bailis et al., "Highly Available Transactions: Virtues and Limitations", VLDB 2014, www.vldb.org/pvldb/vol7/.... 会话级 / 因果一致性的系统讨论。
zilliztech/GPTCache, GitHub, github.com/zilliztech/....
cpacker/MemGPT, GitHub, github.com/cpacker/Mem....
pgvector/pgvector, GitHub, github.com/pgvector/pg.... PostgreSQL 向量扩展。
PostgreSQL Row-Level Security 官方文档, www.postgresql.org/docs/curren....

上一篇 : Text-to-SQL 与 Agentic Query：DIN-SQL、C3、DAIL-SQL 工程复盘 下一篇 : 向量索引深度解读：HNSW、DiskANN、SPANN 对比

数据库作为 LLM 记忆体：语义缓存、RAG 与一致性

一、为什么需要 "数据库式" 记忆

1.1 两类记忆，不要混为一谈

二、GPTCache：语义缓存的第一性原理

2.1 语义键匹配

2.2 语义缓存的一致性陷阱

三、MemGPT：把 OS 的分级存储搬进 LLM

3.1 MemGPT 的工程启发

四、一致性模型：把经典结论映射到 agent memory

4.1 线性化（Linearizability）

4.2 因果一致性（Causal Consistency）

4.3 会话隔离（Session Isolation）

4.4 MVCC 的启发

五、RAG 与记忆的边界

六、工程样例：pgvector + 触发器实现语义缓存

6.1 表设计

6.2 查询：带隔离的语义命中

6.3 写入：保证 read-your-writes

6.4 触发器：自动维护 TTL 与 tombstone 逻辑

6.5 后台清理

6.6 一致性等级总结

6.7 真实生产里还要注意什么

6.8 真实生产里还要注意什么

6.9 运行时剖析

6.10 一个常被忽视的场景：跨会话 "学习"

6.11 与仓库其他文章的互链

七、把记忆架构当成一个小型数据库系统来设计

7.1 记忆即 session

7.2 记忆即缓存

7.3 记忆即审计

7.4 开放问题：跨模型的记忆兼容

7.5 小结

八、RAG × Agent Memory 的产品形态

8.1 三层知识栈

8.2 跨层通信的陷阱

8.3 产品化清单

九、关于"遗忘"的设计

9.1 GDPR / 个人信息保护法的要求

9.2 软删 vs 硬删

9.3 选择性遗忘

十、读者扩展阅读建议

参考文献