先理解
刚接触这个知识点
补齐先备概念，读原理与反例，再用自己的话解释为什么。
从核心原理开始 →知识目录选择核心方向与细分内容
理解 → 实现 → 排错 → 取舍
长期记忆的准入、来源与事实修正
考察记忆准入、来源、有效期与纠错。
知识内容核对 2026-10-03 · 原题来源核对 2026-10-02
建议先理解：
记忆作用域与可信授权上下文 →RAG 的证据流与故障定位 →这个知识点，你想学到哪一步？
按当前基础选择起点，也可以依次深入。遇到不熟悉的概念，先回到核心原理；完成后用知识练习检查理解。
知识单元目录
LEARN · PRACTICE · REFLECT
知识学习与个人记录
先沿着原理、问答和迁移案例阅读。需要检查理解时，再切换巩固练习或展开个人记录。
核心知识 · 长期记忆的准入、来源与事实修正
先理解核心原理
先备概念：用户陈述与引用、事实和推断、版本化记录
长期记忆把一次输入变成未来反复使用的依据，因此写入门槛应高于临时上下文。保存复用价值与来源性质，不能把模型推断升级为已确认事实。
记住越多不等于更懂用户
用户说“同事喜欢 Rust”，直接写成用户喜欢 Rust，会让以后每个建议都偏离。信息在对话里出现只说明它参与了当前任务，不证明它属于用户、长期有效或值得保存。临时行程、引用文本和假设场景通常应留在任务状态。
把写入拆成候选、准入和提交
候选包含对象、属性、值、作用域、来源轮次、有效时间与确认性质。应用策略检查是否有后续复用价值、是否敏感、是否与当前事实冲突，以及保存是否符合用户意图。模型可抽取候选，可信代码执行策略与版本写入；高风险推断要拒绝或先确认。延迟到后台提取可以减小主请求延迟，但后台任务仍需防止读取过期授权和写回已撤销事实。
记忆也是可纠正的数据
“我以前用 Java，现在这个项目用 Go”包含历史与当前、个人与项目两个维度。不能简单覆盖成“此人只用 Go”，也不能保留两条都当当前偏好。使适用范围相同的旧记录失效，保存更正来源，更新依赖索引和摘要。使用前仍按当前有效期与作用域过滤。
用损失而不是容量评价
统计错误保存、漏保存、后续错误使用和用户修正次数。命中率高可能是所有回答都命中过宽偏好，反而制造重复或冒犯；评估应看记忆是否让目标任务更正确、更省步骤。反例是把模型自己提出的建议再记成用户偏好，下一轮又引用它为依据，形成无外部来源的自我强化。
用一个问题检查理解
用户随口说一句话，要不要写入长期记忆？怎样避免错误记忆污染？
长期记忆应服务后续任务，不是自动保存全部对话。区分用户明确陈述、工具验证事实、模型推断和临时任务状态；只在符合保存策略且确有复用价值时写入。记录来源、作用域、有效期与确认状态，敏感信息采用更严格准入。模型推断不能变成已确认事实，用户修正应使旧记录失效并传播到索引和缓存。
实现与取舍
先定义哪些信息值得保存
稳定语言偏好、明确项目约束可能有复用价值，临时查询结果和一次失败日志通常只属于当前运行。对“下周可能去上海”应保留不确定性与时间条件，不能写成“用户住在上海”。记忆准入应包含用途、作用域和数据类别，避免为了召回率无限收集内容。
写入流程与来源
从对话提取候选记忆后，检查用户是否明确表达、是否与已有记录冲突、是否需要确认和多久失效。存储字段可以包括 subject、predicate、value、source_id、observed_at、valid_until、confidence 和 status。confidence 仅是内部辅助信号，不替代来源证明；未经确认的推断不能被后续系统当作授权或身份信息。
纠错与遗忘
用户说“我现在改用 Go”时，不应简单在 Python 偏好后追加一条互相冲突的记录，而要明确是新增技能、当前偏好变化还是旧信息错误。对旧记录标记 superseded 或 revoked，并更新索引、摘要和缓存。保留纠错所需的最小来源关系，删除时仍按相应保留规则处理。
测试长期污染
测试用户假设句、反讽、引用他人、短期计划和后来否认的事实。检查这些内容是否被错误永久化，跨会话调用时能否正确解释有效期。指标不能只有记忆命中率，还应包含错误写入率、过期召回率、纠错传播延迟和有用性抽查。
工程推演
- 场景
- 面试假设：用户练习英文时说“我住纽约”，系统误保存为真实住址。
- 设计决策
- 识别练习上下文，将其排除在已确认个人事实之外。
- 验证目标
- 后续真实任务不把练习陈述当事实。
- 适用边界
- 保存范围和确认策略取决于产品承诺及数据类别。
连续追问与解答
沿着问题的前提和约束继续向下读。先理解参考解答，再尝试收起答案，用自己的话解释因果和取舍。
第 1 层引用别人的话怎么识别？
从长期准入深入到最容易误归属的信息。
参考解答
识别说话主体和引用边界，候选标记为第三方陈述，不写入用户偏好。若身份或指代不清，留在临时上下文或澄清。引号、转述词只是线索，还要结合语境；可以保存有明确用途的第三方事实，但必须绑定正确对象、合法范围和来源。
第 1 层用户改变偏好是覆盖还是新增？
写入后用户会变化，需要定义修正而非只累加。
参考解答
取决于语义：同对象同属性的明确当前修正使旧值失效，同时保留必要更正记录；不同项目或有效时间则分别建模。不要无条件覆盖所有历史，也不要新增后继续召回两条冲突当前值。通过版本条件写避免后台提取把旧偏好覆盖回来。
沿着这个回答继续深入
第 2 层后台提取的是旧对话，新偏好已生效，它该怎样提交？
父问定义偏好更新后，异步提取引入旧写覆盖竞态。
参考解答
候选带来源轮次和期望事实版本，提交时执行条件写。若当前版本已更新，重新判定候选是否只是历史事实或应被丢弃，不直接覆盖。失败重试也使用同一候选身份，防止重复生成相同记忆；用户明确更正优先于晚到的旧提取。
沿着这个回答继续深入
第 3 层旧对话里的事实今天才导入，能以今天更新时间排成最新偏好吗？
条件写解决并发后，仍需防止用导入时间误判语义新旧。
参考解答
不能。保存观察或导入时间与事实有效时间，并优先依据明确修正关系。今天导入的“去年喜欢 Java”不推翻本月明确的项目偏好；不知有效时间时标为未知，避免自动升级为当前。到达时间只描述系统何时得知。
第 1 层记忆命中率高为何仍可能体验差？
将写入量和使用量与真正任务收益分开。
参考解答
命中不代表适用。过宽作用域、过期事实、误归属和重复召回都可能提高命中率却降低任务成功。用有无记忆对照和用户纠错样本测收益，区分检索命中、实际使用和正确使用；仅为了让每轮都有记忆会制造噪声。
举一反三：条件变了，怎样推导？
先找出改变的条件，再判断原方案中哪些前提仍成立。下面的案例是教学推演，便于将原理迁移到新问题。
工具确认事实
改变的条件：从随口描述变成权威系统结果
延伸问题：查询得到用户当前项目负责人，能永久保存吗？
推导与参考解答
来源更可核对，但事实仍随人员变化，且可能受项目权限约束。保存来源版本、作用域与有效期，使用前按需要重新验证。工具成功只说明这次结果，不代表长期不变或允许跨项目共享。把它作为短时缓存或版本化事实更合适。
保持不变的原理：来源可信不消除生命周期与授权限制。
一次语气偏好
改变的条件：用户说这封邮件语气强硬一点
延伸问题：是否应该把“喜欢强硬语气”存成全局偏好？
推导与参考解答
不应直接全局化，它限定当前邮件。保留任务状态；若用户明确说以后所有催款邮件都这样，可保存限定用途的偏好。记忆候选应保留作用范围，避免一次场景约束污染所有交流。
保持不变的原理：从局部要求推广到长期规则需要额外依据，不能靠概括省略范围。
易错点
- 所有聊天自动入库
- 推断变成确认事实
- 只删除主记录不处理摘要缓存
参考资料
依据公开技术资料设计；参考资料支持技术机制，场景与评分标准为本站设计，不代表某公司面试原题。 新增问答与迁移案例用于原理讲解，来源核查与案例运行验证分别记录。
检查自己理解到哪一步
读完后可以对照这些标准解释原理、边界和取舍。掌握程度由你自评；需要进一步验证时，再完成下方小任务。
- 基础达标
- 能结合来源与用途区分可复用偏好和临时任务内容。
- 中高级信号
- 给出来源、状态、有效期与纠错链。
- 资深信号
- 用反讽、练习和撤销反例验证污染率。
动手验证 按需完成 · 建议 15 分钟
给五条聊天句子标注不保存、候选、已确认和短期有效，并解释原因。
展开验收要求与检查点
- 练习身份不当真实身份
- 假设保留不确定性
- 修正能使旧事实失效
重点检查
- 区分事实、推断与临时状态
- 定义记忆准入和时效
- 能纠错并传播失效