导语：AI 找到了旧信息，真的能直接用吗？
你问 AI：
“上次我们定的产品发布时间是哪天？”
它从历史对话里翻出一句：
“暂定 6 月 18 日上线。”
回答看起来没问题。可你马上补充：
“那是旧计划，后来改到 7 月了。”
这一下，问题就暴露了。
AI 记住了内容，却没判断这条内容已经失效。
找得回来，是检索。知道哪条还成立，才接近理解。
这也是 @AlloomiAI 提到的 Holistic Context 值得关注的地方：把时间关系、版本关系和信息之间的变化一起放进上下文里，而不是只做“关键词搜索”。
普通检索：能找到，不代表能判断
很多 AI 应用的记忆机制，大致是这样的：
- 把聊天记录切成一段段文本。
- 为每段文本生成向量。
- 用户提问时，找出相似内容。
- 把结果塞回提示词，让模型回答。
这种方式适合找资料。
比如：
- 找出某个项目的技术方案。
- 找出用户之前提过的偏好。
- 找出一段产品需求。
- 找出某次会议的结论。
麻烦出在“变化”上。
同一个问题可能有多条答案：
| 时间 | 信息 | 当前状态 | |---|---|---| | 3 月 1 日 | 发布日期是 6 月 18 日 | 已过期 | | 3 月 12 日 | 发布日期调整到 7 月 2 日 | 被替代 | | 3 月 20 日 | 发布日期暂定 7 月 15 日 | 当前版本 |
如果系统只看语义相似度，三条内容都可能被召回。
它需要继续回答几个问题：
- 哪条信息更新？
- 新信息是否明确替代旧信息？
- 旧信息是作废，还是仍然适用于某个场景？
- 当前回答应该引用哪一个版本？
这一步，已经超出普通搜索的范围了。
AI 记忆的核心：给信息加上“生命状态”
一条信息不该只有文本内容。
更实用的记忆单元，至少要带上这些字段：
{
"content": "产品发布日期调整到 7 月 15 日",
"created_at": "2025-03-20",
"valid_from": "2025-03-20",
"valid_until": null,
"version": 3,
"status": "active",
"replaces": "memory_102",
"source": "产品评审会议",
"confidence": 0.92
}
这里有几个字段特别关键：
created_at：这条话是什么时候产生的
它记录的是信息被写入系统的时间。
注意，创建时间不一定等于生效时间。
例如，团队在 3 月 10 日宣布：“4 月 1 日开始执行新报销规则。”
这条信息的创建时间是 3 月 10 日，生效时间却是 4 月 1 日。
valid_from 和 valid_until：这条信息在哪段时间有效
时间范围能帮 AI 处理很多现实问题：
- 促销活动何时生效。
- 合同价格何时开始执行。
- 员工权限何时失效。
- 某个政策适用于哪个周期。
没有有效期，AI 很容易把历史规则当成当前规则。
version：这是第几版
同一份需求可能改过五次。
如果所有版本都平铺在数据库里，AI 很难知道该引用哪一个。版本号能让信息之间建立清晰关系。
status：当前是否还可用
可以设计成几种简单状态：
active：当前有效superseded：已被新版本替代expired：超过有效期retracted：被撤回draft：尚未正式生效unknown：状态不明确，需要人工确认
状态越清楚，回答越稳。
一个实用例子：客户偏好也会过期
假设客户曾经说过：
“我不喜欢收到营销邮件。”
半年后，客户又主动订阅了新品通知。
如果 AI 只记住第一句话，它会拒绝发送所有相关邮件。
更合理的处理方式是拆开看：
- 原始偏好：不接收普通营销邮件。
- 新行为：主动订阅新品通知。
- 当前判断：新品通知属于客户明确订阅的类型，不能和普通营销邮件混为一谈。
这就是上下文关系。
信息不是简单相加，而是会被新事件修改、限制或重新解释。
Holistic Context 值得借鉴的设计思路
把一段文本丢进向量数据库，只解决了“相关内容在哪里”。
更完整的上下文系统，还要把这些关系放进去：
时间关系
记录事件发生的时间、信息生效的时间、信息失效的时间。
版本关系
标记谁替代了谁，哪一个版本是当前版本。
来源关系
知道信息来自哪里。
会议纪要、用户口述、正式文档、系统日志，它们的可信度和权威性可能不同。
适用范围
同一句话可能只适用于某个项目、某个客户，或者某个地区。
例如：
“退款周期是 7 天。”
它可能只适用于国内订单，不适用于海外订单。
冲突关系
两条信息互相矛盾时，系统不能安静地随机选一条。
它应该标记冲突，并在必要时追问：
“我找到两个版本：旧记录写的是 6 月 18 日，新记录写的是 7 月 15 日。你要确认当前发布计划吗？”
这类回答看起来慢半拍，实际能少闯很多祸。
落地做法：给 AI 记忆加一层“状态判断”
如果你正在做 AI Agent、企业知识库或客服机器人，可以按这个流程设计。
第一步：召回相关信息
先用关键词、向量搜索或混合检索找出候选内容。
别急着直接喂给模型。
第二步：按时间过滤
判断用户问的是：
- 当前状态。
- 某个历史时点的状态。
- 未来计划。
“现在的价格是多少”和“去年 6 月的价格是多少”，检索条件完全不同。
第三步：处理版本链
检查候选内容有没有被替代：
版本 1 → 版本 2 → 版本 3
如果版本 1 已经被版本 3 替代，默认回答应优先引用版本 3。
第四步：检查适用范围
确认这条信息是不是针对当前用户、项目、地区或业务线。
范围不匹配时，即使文本很相似，也不能直接使用。
第五步：处理冲突和不确定性
遇到冲突时，给出来源和时间，不要装得很确定。
例如：
“根据 3 月 20 日的评审记录，当前计划是 7 月 15 日。3 月 1 日的记录仍写着 6 月 18 日，但已经被后续计划替代。”
这比一句“发布日期是 7 月 15 日”可靠得多。
提示词也要写出这套规则
你可以给 Agent 加一段简单的记忆判断规则：
处理历史信息时，请遵循以下规则：
1. 优先使用当前有效版本。
2. 检查信息的创建时间和生效时间。
3. 如果新记录明确替代旧记录，不要引用旧记录作为当前结论。
4. 如果不同记录存在冲突，说明冲突来源和时间。
5. 信息状态不明确时，不要自行补全，向用户确认。
6. 回答涉及历史状态的问题时，按用户指定的时间点进行判断。
这段规则不复杂，却能明显减少“把旧答案当新答案”的问题。
避坑清单：这些记忆设计看着聪明，实际很危险
只保存文本，不保存时间
AI 会把三年前的规则和今天的规则放在同一个层级上。
只看相似度，不看版本
越相似的旧内容，越可能抢走新内容的位置。
看到新信息就覆盖旧信息
历史记录有时很重要。审计、复盘、合同争议，都需要知道过去发生过什么。
正确做法是保留旧版本，同时标记它已经失效或被替代。
冲突时强行选一条
模型很擅长把矛盾说得像真的一样。
碰到日期、金额、权限、政策这类高风险信息，宁可明确提示冲突，也别靠猜。
把“用户说过”当成“用户永远如此”
偏好会变，计划会变，身份会变，需求也会变。
记忆系统需要支持更新，而不是给用户贴永久标签。
一套够用的数据结构
中小型项目不需要一开始就搭复杂知识图谱。可以先用下面这套结构：
{
"id": "memory_103",
"topic": "发布日期",
"content": "产品发布日期调整到 7 月 15 日",
"entity": "项目 A",
"source": "产品评审会议",
"created_at": "2025-03-20",
"valid_from": "2025-03-20",
"valid_until": null,
"status": "active",
"version": 3,
"replaces": ["memory_101", "memory_102"],
"scope": {
"project": "项目 A",
"region": "中国大陆"
}
}
配合向量检索，再加一层规则过滤，已经能覆盖不少实际场景。
你不需要一开始就追求“完美记忆”。
先让系统分清三件事：
- 这是什么信息？
- 它什么时候有效？
- 它有没有被更新？
光是做到这一步，回答质量就会出现明显变化。
写在结尾：记忆的价值，不是保存更多，而是判断得更准
AI 记忆不是聊天记录的仓库。
它更像一个持续变化的档案系统：每条信息都有来源、时间、版本和适用边界。
真正难的地方，不是把旧内容找回来。
难的是在用户问“现在怎么办”时，AI 能识别出哪些内容已经过期，哪些仍然有效，哪些地方存在冲突。
这也是 Holistic Context 给出的重要启发：上下文不能只看内容，还要看内容如何变化。
当 AI 开始理解时间和版本，它才算从“会搜索”往“会判断”迈了一步。
