前言

最近在用AI辅助写代码，本来以为能起飞，结果差点没把我搞疯。

事情是这样的：我最近在做个项目，代码量不小，文档也一堆。我用AI助手帮我理解代码、改bug、加功能。刚开始还挺爽，问啥答啥。但用着用着，我发现了一个特别要命的问题——

哪怕用了RAG、向量数据库、多层文档检索这些看起来很牛的技术，AI的记忆好像还是“死”的。

---

场景还原：数据库重构了一段时间，AI还抱着老文档不放

之前，我做了个数据库重构。

原来那个用户交互信息表，说实话设计得挺乱的——用户行为数据分散在七八张表里，每次查个东西都得join来join去。后来实在受不了，花了两周时间，把散在各处的交互记录全整合到一张大表里，字段重新设计，索引重新建，跑起来顺多了。

重构完测试没问题，我就继续往下走了。那几张老表，后来也没怎么动过。

这半年我主要在做别的模块，最近才回过头来搞推荐算法。我想用用户的交互数据（点击、收藏、停留时长这些）做协同过滤，给用户推点东西。

然后问题就来了。

我问AI：“帮我查一下用户对商品的交互数据，有哪些字段可以用？”

AI很快回了：“根据文档，用户交互数据分布在以下几个表里：user_clicks、user_favorites、user_view_time、user_purchase_history...需要做联表查询。”

我一看就懵了。

这些表三四天前就没了啊，全合并到user_interactions这一张表里了。

我说：“这些表不是早就合并了吗？现在都统一在user_interactions表里。”

AI说：“抱歉，我再看一下...确实找到了user_interactions表，字段包含user_id、item_id、action_type、timestamp、duration、rating...”

然后它重新分析了一遍，这次对了。

但我脑子里冒出来一个疑问：下次呢？下次我问别的跟用户相关的问题，它会不会又把那些老表翻出来？

果然，过了两天我问“统计一下用户活跃度分布”，它又开始提那些已经不存在的表了。

这不是偶然。类似的事情发生过好几次：

• 我问接口参数，它翻出来一篇两个月前的文档，上面的格式早就废弃了

• 我问功能进度，它把“计划要做的”和“已经做完的”混在一起说

• 我问某个bug修了没，它告诉我一个还没修的版本的分析

这让我开始琢磨一个更深的问题：RAG系统的记忆更新，到底怎么搞？

---

问题的本质：静态快照 vs 动态现实

我把这个问题拆解了一下，发现核心出在哪儿了：

你把记忆存进数据库的那一刻，它就变成了一张“静态快照”。

这张快照记录的是“在某个时间点，事情是这样的”。但现实世界是一直在变的啊：

• 数据库重构了，老的表没了

• 字段改名了，老的字段废弃了

• 需求变更了，有的功能做到一半停了

• bug修完了，问题不复存在了

这就产生了一个根本性的冲突：静态的存储系统，碰上了动态的开发过程。

你想更新这些快照，没那么容易：

1. 找不准位置

新改的表结构可能只涉及几个字段，怎么精确找到数据库里对应的那几段文档，只更新它们？

2. 关联断了

老表可能关联着好几篇文档、好几个讨论记录。你改了表结构，那些关联的ER图、查询语句如果不跟着变，以后搜出来就全是矛盾。

3. 索引跟不上

就算你改了原始文档，向量数据库里的索引也得重新算。这个过程不是实时的，中间的空档期，新旧版本就共存着。

结果就是：新老版本的记忆在库里共存，像幽灵一样飘着，等着哪天被人翻出来。

---

那些“漏网之鱼”到底从哪来的？

我仔细复盘了几次AI翻车的情况，发现“漏网之鱼”主要有这几个来源：

1. 语义太像，系统分不清新旧

比如：

• 版本1（重构前）：“用户点击数据在 user_clicks 表”

• 版本2（重构后）：“用户点击数据在 user_interactions 表，action_type='click' 区分”

这两段话在向量空间里离得特别近——都是说“用户点击数据在哪儿”。用户问“用户点击数据怎么查”，系统很可能两个都搜出来。

问题是：系统分不清哪个是现在的，除非你专门做了标记。

2. 隐式知识的坑

有些知识不是写在一个地方，而是拼出来的。比如：

• 文档A说“用户交互数据已经全部合并到 user_interactions 表”

• 文档B是老文档，还在说“用户收藏记录在 user_favorites 表”

系统把文档A和文档B的信息拼在一起，就乱了。它不知道文档B已经过期了。

3. 细粒度更新的技术难度

假设就改了一个字段名，从 view_time 改成 duration。理想情况是只更新提到这个字段的那几段文档和代码片段。

但现在RAG系统很难做到这种“手术刀式”的更新。大多数时候是整个文档重新处理一遍，效率低，中间还有空档期。

4. 出错了不好查

系统给错答案的时候，可能用了好几个来源。如果是因为混进了老记忆，想追到具体是哪一块出问题，非常难。这种“黑箱”特性让调试变得很痛苦。

---

怎么解决？我试下来比较管用的两个方法

这问题没有完美解法。但我最近实践下来，有两个方法确实能改善不少。

方法一：给每段记忆打上“时间戳”和“版本号”

这听起来简单，但效果最直接。

核心思路：存数据的时候，不光存内容，还存一堆元数据——创建时间、更新时间、版本号、状态（是否有效）。

然后在查数据的时候，只查“当前有效”的。

举个我现在的做法：

python

# 存数据的时候
doc_chunk = {
    "text": "用户交互数据统一存储在 user_interactions 表，字段包括 user_id, item_id, action_type, timestamp, duration",
    "metadata": {
        "version": "2.0",
        "last_updated": "2025-09-15",
        "status": "active",  # active表示当前在用
        "deprecates": "version_1.0"  # 取代了哪个老版本
    }
}

# 存老版本的时候
old_chunk = {
    "text": "用户点击数据在 user_clicks 表，收藏数据在 user_favorites 表...",
    "metadata": {
        "version": "1.0",
        "last_updated": "2025-03-10",
        "status": "deprecated",  # 已废弃
        "deprecated_by": "version_2.0"  # 被哪个新版本取代
    }
}

# 查数据的时候
query = "用户点击数据在哪个表"
filter_condition = {
    "status": "active"  # 只查当前有效的
}
results = vector_db.search(query, filter=filter_condition)

这样，老版本虽然还在库里，但根本搜不出来。

好处：简单粗暴，见效快。
坏处：得有人（或者自动化的脚本）维护这些元数据，得知道什么时候该把老版本标成“无效”。

方法二：两阶段检索，让最新的排前面

有时候光靠过滤不够——有些场景需要同时参考新旧版本（比如要对比重构前后的差异，或者老数据还有历史参考价值）。这时候可以用“两阶段检索”。

第一阶段（海选）：用向量相似度搜出一批相关的，新旧都行，先都捞出来。

第二阶段（精选）：结合时间信息，给这些结果重新排序，让最新的、最相关的排最前面。

代码大概是这个意思：

python

# 第一阶段：宽检索，先捞20个相关的
candidates = vector_db.similarity_search(query, k=20)

# 第二阶段：重排序，把最新的排前面
reranked = []
for doc in candidates:
    # 相关性得分 + 时间权重
    relevance_score = compute_relevance(query, doc.text)
    # 时间越近，freshness_score越高
    days_old = (current_date - doc.last_updated).days
    freshness_score = 1.0 / (days_old + 1)
    # 综合得分：相关性占70%，新鲜度占30%
    final_score = relevance_score * 0.7 + freshness_score * 0.3
    reranked.append((doc, final_score))

# 按最终得分排序
reranked.sort(key=lambda x: x[1], reverse=True)

# 取前5个
final_results = [doc for doc, score in reranked[:5]]

好处：不会完全丢掉老版本（有时候需要看历史），又能保证最新的信息优先。
坏处：多了一个步骤，响应时间会变长一点。

---

说在最后

这问题我想了一段时间，后来想明白了：AI看到的都是“点”，不是“线”。

它能看到某个时间点的表结构，某个时间点的ER图，某个时间点的查询语句，但它看不到这些点之间的“顺序”——哪个在前哪个在后，哪个被哪个取代了，哪些东西已经作废了，哪些还在用。

我脑子里是有一条时间线的：一开始表设计得很散 -> 发现查询太慢 -> 决定重构 -> 花两周合并表 -> 更新了文档但没删老的 -> 现在开始做推荐算法。

但在AI那儿，这些事都是平的、同时存在的。它不知道user_clicks表是在重构前写的还是重构后写的，不知道这个需求是已经做完了还是刚立项。

结果就是：每次问问题，都像在跟一个刚进组、看了两天文档但对项目进度一无所知的实习生聊天。他知道很多东西，但他不知道哪些是“现在”的。

元数据标记和两阶段检索这两个方法，至少能让AI知道“时间”这个概念。不然那些躺在数据库里的老记忆，就像埋着的雷，不知道哪天就炸一下。