TEMPR 四路混合检索语义、BM25、图、时间Hindsight 找回旧记忆的秘密武器【免费下载链接】hindsightHindsight: Agent Memory That Learns项目地址: https://gitcode.com/GitHub_Trending/hindsight2/hindsight长期记忆一直是 AI Agent 工程里最难啃的骨头。会话一结束Agent 就失忆上下文窗口越塞越长成本越来越高反而把真正有用的信息稀释掉。开源记忆系统 Hindsight 给出的答案不是更长的窗口、更贵的向量库而是一套名为TEMPR的四路混合检索架构——语义Semantic、关键词 BM25、实体图谱Graph、时间Temporal四条检索臂并行出击再用 RRF 融合与 Cross-Encoder 重排把旧记忆从海量存储中精准捞回来。这套方案并非自说自话。Hindsight 在 LongMemEval 基准上报告准确率达 94.6%社区评测中 Lifebench 71.5%、Locomo 92.0%、BEAM 64.1% 的成绩也显著领先主流记忆系统。本文结合仓库源码拆解 TEMPR 的每一路检索如何工作、四路结果如何融合排序以及记忆如何借助证据追踪实现自我修正。为什么单一向量检索撑不起长期记忆把对话历史直接塞进向量库、每次召回按余弦相似度取 top-k是多数记忆系统的默认做法。它的问题在于语义相似 ≠ 相关。Hindsight 官方文档用一组查询点破了这个矛盾见 recall 检索说明Alice works at Google —— 需要精确的名词匹配向量可能把 work 泛化成各种职业描述Where does Alice work? —— 需要语义理解What did Alice do last spring? —— 需要时间推理纯向量对 last spring 无能为力Why did Alice leave? —— 需要沿因果链追踪关系向量检索根本不知道实体之间的边。没有任何一种单一检索方法能同时处理好这四类查询。而 Agent 的长期记忆恰恰是这四种问题的混合体人名地名需要精确匹配意图需要语义理解事件需要时间过滤关系需要图谱推理。这正是 TEMPR 存在的理由——在 四路并行检索实现 中retrieve_all_fact_types_parallel把语义、BM25、图谱、时间四路一次性交给存储层并行执行互不干扰、各司其职。语义 / BM25 / 图 / 时间四路如何协作召回在recall()被调用时TEMPR 的四个检索臂同时开跑每一路面向自己的索引向量索引语义、全文索引BM25、实体图索引图谱、日期索引时间。仓库中的架构图直观展示了这条路查询进入四条并行臂各自产出排名列表汇聚到 RRF 融合。语义臂理解意思不止词面语义检索负责概念级匹配与改写理解Alices job 能命中 Alice works as a software engineermeeting 能匹配 conference、discussion。它解决的是用户换一种说法提问时记忆系统依然认得出来的问题。在 Postgres 检索实现 中语义臂依赖按 fact_type 分区的部分 HNSW 索引idx_mu_emb_world、idx_mu_emb_observation、idx_mu_emb_experience每个臂请求limit行并带有semantic_min_similarity相似度下限把弱匹配在 SQL 层就先剪掉而不是等融合后再浪费重排预算。BM25 臂专治专有名词与精确术语语义再强也有盲区PostgreSQL、HNSW、Alice Chen 这类专有名词在向量空间里往往没有好邻居但关键词检索一抓一个准。BM25 臂兜住了这个底。Hindsight 的文本搜索后端是可插拔的通过HINDSIGHT_API_TEXT_SEARCH_EXTENSION选择PostgreSQL 原生tsvectorTF-IDF非严格 BM25、vchord_bm25、Timescalepg_textsearch、PGroonga、以及 ParadeDBpg_search。值得注意的是如果要在横向扩展的 Citus 集群上跑真正的 BM25pg_search是唯一选项——这对大规模生产部署是个关键选型约束。在代码层面BM25 臂还会做查询词选择build_bm25_query_text负责从查询里挑出真正有区分度的词项而tokenize_query做归一化分词。如果查询不含任何词字符BM25 臂会被整体跳过纯向量模式不付出任何全文检索成本。图谱臂顺着边找八竿子打不着的事实图谱臂是最有侦探感的一路。它解决的是语义和词面都不沾边、但结构上相连的事实Alice 和她的经理从未在同一句话里出现但通过共享项目、团队关系图谱遍历仍能找到经理。实现上Link Expansion 图谱检索 先用语义检索挑选有界种子semantic seeds然后沿memory_links中预存的三种一等信号做扩展实体链接查询与候选之间的共享实体数用COUNT(DISTINCT entity_id)计算通过 LATERAL 每实体上限graph_per_entity_limit默认 200防止高扇出实体把自连接中间行撑爆语义链接写入时预计算的 kNN 图每条新事实链接到最相似的已有事实双向检查得分即权重因果链接causes/caused_by/enables/prevents构成的显式因果链权重 1.0作为最高质量信号加权。三路信号做加法而非乘法得分区间 [0, 3]。为什么加法因为候选可能只通过因果链连接无共享实体、无语义相似乘法会把这种单通道证据直接清零——加法让每条证据通道独立贡献收敛性证据多通道命中自然排名更高。实体信号用tanh(count × 0.5)做饱和化也值得注意共享 1 个实体得分约 0.462 个约 0.763 个以上趋近 0.91。原始实体计数是无界的高扇出实体比如user这种万能标签能产生 50 的计数不饱和化会把另外两路信号淹没。时间臂把去年春天翻译成日期窗口时间臂让历史查询从碰运气变成精确制导。当查询含时间引用in 2023、last spring时Hindsight 先做时间约束抽取——retrieval.py 中这一步是纯 CPU 工作被放到事件循环之外执行避免拖垮同进程的其他请求。窗口内的候选选择有两个设计细节值得玩味相关性优先于新鲜度窗口内按语义相关性选候选而不是按时间新近度所以2023 年发生了什么不会因为 2023 年后面还有更新的事实而丢掉最相关的记忆跨窗口扩散选择窗口被划分成时间桶每个有内容的桶先取最强匹配保证2023 全年的查询覆盖全年各段而不是聚在最密集的时间簇上。时间同时是打分信号记忆越靠近窗口中心获得越小的 temporal proximity 加成。这套相关性优先 桶扩散的组合让大批量同日写入的银行时间戳高度聚集依然能返回代表性结果而非任意切片。四路结果如何融合RRF → Cross-Encoder → 三乘性加成四条检索臂各自产出的分数体系完全不同余弦相似度、BM25 tf-idf、图激活分数数值不可比。直接加权求和是错的Hindsight 用三层流水线解决见 融合实现第一层RRF 倒数排名融合。reciprocal_rank_fusion用score(d) Σ 1/(k rank_i(d))k60按排名位置而非原始分数合并四个列表。一条在语义臂排第 1、BM25 臂排第 5 的记忆得分 0.0318高于只在语义臂排第 1 的记忆0.0164——跨策略共识胜出。四臂在 RRF 内权重相等想偏袒某一路需另设HINDSIGHT_API_RECALL_STRATEGY_BOOSTS且在融合之外单独施加。第二层Cross-Encoder 重排。RRF 只看位置从不真正把查询候选配对阅读。Cross-Encoder 对每个query, memory配对打分捕捉位置融合抓不到的细节——比如某记忆因命中常用词在 BM25 排第 1却与查询意图毫不相关。重排前候选先裁剪到 top 300HINDSIGHT_API_RERANKER_MAX_CANDIDATES可调控制成本本地重排器按 32 对一批、TEI 按 128 对一批处理外部 API 重排器的校准分数[0,1] 内原样通过本地原始 logits 用 sigmoid 归一化。没有 Cross-Encoder 时如 slim 镜像系统退回按 RRF 排名铺开的合成分数保证下游加成依旧有意义。第三层三乘性加成。归一化后的 Cross-Encoder 分数乘上三个信号加成final_score CE_normalized × recency_boost × temporal_boost × proof_count_boost加成α最大调节奖励什么Recency0.2±10%新近记忆优于旧记忆365 天线性衰减Temporal proximity0.2±10%贴近查询时间窗口中心的记忆Proof count0.1±5%证据数更多的观察对数曲线用乘法而非加法是刻意为之加法给所有候选同样的绝对加成一条低相关记忆可能仅因比较新就跃过高度相关记忆乘法让加成与基础相关度成正比次级信号永远压不过主相关判断。全部加成合起来最好的情况 ×1.27最坏 ×0.77——保守而克制。流水线最后是token 预算截断结果按final_score排序逐个装入直到max_tokens耗尽。只有记忆文本计入预算元数据免费放不下的长记忆被跳过、让位于后面更短的记忆避免一条长事实挤掉多条短事实。这就是 Agent 视角的top-k——不是返回固定条数而是用 token 填满上下文窗口。证据追踪与信念更新记忆如何自我修正TEMPR 解决了找得到但长期记忆的真正难题是**记得对旧信念会被新事实推翻错误信息会被新证据冲刷。Hindsight 的答案是观察observations与心智模型mental models**的分层以及围绕证据的显式趋势计算与撤回机制。每条观察都必须有证据引用在 observations.py 中Observation模型强制要求每条观察携带evidence列表每条证据必须包含源记忆 ID 精确引文 quote 时间戳——信念不是凭空生成的而是逐条可追溯到原始事实的。更关键的是trend计算字段系统不靠 LLM 猜测信念的新旧而是纯算法地从证据时间戳分布推导五种趋势趋势判定逻辑NEW全部证据在近期窗口30 天内STABLE证据跨时间分布且延续至今STRENGTHENING近期证据密度 1.5× 历史密度WEAKENING近期证据密度 0.5× 历史密度STALE近期窗口内无任何证据Alice 可能离职了不再是一句随意的推测——它对应 WEAKENING/STALE 趋势证据密度随时间衰减系统能在刷新时识别出这条信念已经站不住脚。这直接呼应了 Hindsight 官方反复强调的设计哲学bring facts, not beliefs带来事实而非信念。撤回把不存在变成可操作信号记忆系统最隐蔽的坑是证据消失一条事实被作废、删除或作为过期观察被清扫后检索永远不会再返回它——但引用过它的文档还在陈述它、还在引用它。因为系统的每个信号都建立在存在的行之上而撤回恰恰是行的缺席它不产生水位线、进不了 prompt。retractions.py 把这个缺席变成显式值比对文档记录在based_on中的事实 ID 与当前仍存活的 ID 集合找出已被引用但已不存在的 grounding让刷新流程能要求 LLM 明确撤回相关表述。值得注意的是它的防御性设计based_on中的mental-models、directives指向完全不同的表绝不能被误当成缺失的 memory 行而全部引用同时消失被识别为 broken link比如整库迁移导致 ID 重建而非撤回——后者会触发不可逆的删除误判代价极高。心智模型事实之上的可更新信念层在心智模型刷新链路mental_model_refresh.py中观察被组织成面向 Agent 的信念摘要每次刷新基于reflect_response.based_on重新 grounding。这套事实world/experience→ 观察证据支撑的信念→ 心智模型面向决策的摘要的层次与社区总结的「文档→分块→记忆与实体→观察→心智模型」四层仿生记忆架构一一对应。反映在检索上recall的types参数可以按 world / experience / observation 过滤证据越充足的观察在打分时获得 proof_count 加成——记忆系统不只是存取它在自我演化。落地从基准到工程实践TEMPR 不是纸面架构。从工程视角看它的每一路都有独立的开关与配置enable_text_search、enable_temporal_retrieval、enable_graph_retrieval可以按场景单独关闭纯向量模式连 BM25 的 token 化开销都省掉budgetlow/mid/high映射到 100/300/1000 的召回预算贯穿语义、BM25、图谱遍历与时间扩散的每一环节max_tokens与budget两个维度正交——深度搜索 少返回用于研究型查询浅搜索 多返回用于快速闲聊。这也解释了社区实测中 Hindsight 能在 Lifebench、Locomo、BEAM 上领先的原因它的优势来自混合记忆架构与结构化事实抽取而非单一模型的魔法。当别人的 Agent 还在把整段对话历史塞进上下文时Hindsight 已经把对话提炼成带时间、带实体、带因果、带证据的事实网络——TEMPR 的四条臂正是在这层结构化记忆上并行铺开的探针。如果你的 Agent 也在聊完就忘不妨从recall的源码读起四路并行、RRF 融合、乘性加成、证据追踪每一步都是可以被工程化复用的设计决策而不只是某个项目的内部实现。【免费下载链接】hindsightHindsight: Agent Memory That Learns项目地址: https://gitcode.com/GitHub_Trending/hindsight2/hindsight创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考