Hindsight Recall 检索机制解析TEMPR 四路并行搜索、RRF 融合与 Cross-Encoder 重排【免费下载链接】hindsightHindsight: Agent Memory That Learns项目地址: https://gitcode.com/GitHub_Trending/hindsight2/hindsightHindsight 的recall()通过四路并行检索策略语义、关键词、图遍历、时间感知配合 RRF 融合与 Cross-Encoder 重排从记忆库中为 Agent 按 token 预算返回最相关的记忆。本文基于官方文档 retrieval 并结合 API 服务端源码hindsight-api-slim/hindsight_api/engine/search/目录完整还原了从查询进入到最终排序的整条流水线每条策略如何取数、融合公式为何采用排名而非原始分、三个乘性 boost 如何设计、budget参数如何映射为各阶段的候选池规模。读完后你可以依据自己的延迟与召回质量需求精确调整 recall 的每个可调参数。记忆召回的核心难题不同类型的查询需要不同的搜索方式Alice works at Google→ 需要精确的专名匹配Where does Alice work?→ 需要语义理解What did Alice do last spring?→ 需要时间推理Why did Alice leave?→ 需要因果关系追溯没有任何单一检索方法能同时覆盖这些场景。Hindsight 的解法是TEMPR四种互补策略并行运行再统一融合。从源码结构看这个流程图与 retrieval.py 中的实现一一对应模块 docstring 明确写着 Implements: 1. Semantic retrieval, 2. BM25 retrieval, 3. Graph retrieval, 4. Temporal retrieval四路结果装入ParallelRetrievalResult数据类semantic/bm25/graph/temporal四个字段其中temporal可为None当查询不含时间引用时该路整体跳过。四种搜索策略1. 语义搜索Semantic Search作用理解词语背后的含义而不只是词本身。最适合概念匹配Alices job → Alice works as a software engineer同义改写Bobs expertise → Bob specializes in machine learning近义词meeting 匹配 conference、discussion、gathering为什么重要你可以用自然语言提问而不必精确匹配关键词。在实现层面语义臂由一条组合 SQL 承担retrieve_semantic_bm25_combined_sqlretrieval.py用UNION ALL把每个 fact_typeworld / observation / experience拆成独立的 SQL 臂每臂自带ORDER BY embedding $1 LIMIT ...从而命中 Alembic 迁移自动创建的按 fact_type 划分的部分 HNSW 索引idx_mu_emb_world、idx_mu_emb_observation、idx_mu_emb_experience。源码注释特别解释了为什么每臂只取恰好limit行而不是多取 5 倍再裁剪返回的行在臂内已按距离排序前 limit×5 行里取前 limit 行与LIMIT limit完全等价真正影响 ANN 质量的是连接级的候选列表大小而不是这里多取的行数。语义臂还有一个分数下限min_semantic可按请求用recall的min_scores.semantic覆盖弱匹配在进入融合前就在 SQL 层被剪掉。2. 关键词搜索Keyword Search作用找到精确的术语与名称即使它们拼写非常规。最适合专有名词Google、Alice Chen、MIT技术术语PostgreSQL、HNSW、TensorFlow唯一标识URL、产品名、特定短语为什么重要确保你不会漏掉那些提及了特定名称或术语的结果即使它们在语义上离你的查询很远。可插拔后端Hindsight 内置五种 BM25 后端通过HINDSIGHT_API_TEXT_SEARCH_EXTENSION环境变量选择五个变量名均可在 config.py 中确认后端使用技术Citus 兼容nativePostgreSQLtsvectorts_rank_cdTF-IDF非真正的 BM25是vchordvchord_bm25扩展否pg_textsearchTimescalepg_textsearch扩展否pgroongaPGroongaGroonga全文扩展TokenBigram多语言分词器否pg_searchParadeDBpg_search扩展可配置分词器如jieba、chinese_compatible、ngram通过HINDSIGHT_API_TEXT_SEARCH_EXTENSION_PG_SEARCH_TOKENIZER指定是如果你的 Postgres 集群做了水平扩展Citus且需要真正的 BM25 排序pg_search是唯一选择。仓库内提供了配套的pg_searchdocker-compose 示例。实现上BM25 臂是条件性的查询被tokenize_query清洗去标点、小写、按空白切分后若没有任何词元或enable_text_searchFalse纯向量模式时该臂直接从 SQL 中剔除——不是执行后丢弃而是连分词、pg_stats选词查询和/rank 扫描的成本都省掉。查询文本在 bm25_term_selection.py 中构建并与知识库搜索共用同一条构建路径防止两条 BM25 路径的查询形态再次漂移。此外每臂有bm25_min_score下限可通过请求级min_scores.keyword覆盖。3. 图遍历Graph Traversal作用沿实体之间的连接找到间接相关的信息。最适合间接关系What does Alice do? → Alice → Google → Google 的产品实体探索Bobs colleagues → Bob → 同事 → 共同项目多跳推理Alices teams achievements为什么重要能取回那些在语义或词汇上不相似、但通过知识图结构化连接的事实。示例即使 Alice 和她的经理从未在同一条记忆里出现图遍历也能通过共同项目或团队关系找到她的经理。当前默认实现是LinkExpansionRetrieverlink_expansion_retrieval.py它先选出有界的语义种子GRAPH_SEED_LIMIT 20相似度阈值来自graph_seed_min_similarity配置再沿memory_links表中三类一等信号并行扩展实体链接——查询时通过unit_entities自连接分数为种子集与候选之间共享实体的去重数量每个实体用 LATERAL 上限graph_per_entity_limit默认 200防止高扇出实体如 user爆炸中间行数语义链接——预计算的 kNN 图retain 时每个新事实连向最相似的既有事实受阈值约束双向检查图非对称分数即权重因果链接——显式因果链causes/caused_by/enables/prevents分数即权重作为最高质量信号。三类扩展被融合进单条 CTE 查询一次往返、一个连接槽位用source判别列区分Python 合并阶段再套用各自的分数变换。若整条查询超过link_expansion_timeout则自动降级为仅语义因果两路。observations 型记忆因不在memory_links中直接持有实体链接走专门路径source_memory_ids → world facts → entities → other world facts → their observations。4. 时间感知搜索Temporal Search作用理解时间表达按事件发生时间过滤。最适合历史查询What did Alice do in 2023?时间区间What happened last spring?相对时间What did Bob work on last year?前后关系What happened before Alice joined Google?工作原理当查询含时间引用时Hindsight 先把它解析为日期窗口temporal_extraction模块纯 CPU 工作通过线程池移出事件循环执行然后取时间与该窗口重叠的记忆。窗口内候选按与查询的语义相关性选取——而不是按新旧排序因此窗口内最相关的记忆不会因为别的记忆更新而被丢弃。随后选取沿窗口范围铺展窗口被划分成时间桶源码常量_TEMPORAL_COVERAGE_BUCKETS 8retrieval.py每个非空桶先取各自的最强匹配保证what happened in 2023?能取到整年分布的记忆而不是聚集在最密集的时段。时间同时作为评分信号——越靠近窗口中心的记忆获得小幅加成见下文 Temporal proximity 信号。源码中这一相关性优先 覆盖铺展的设计有明确的动机注释retrieval.py早期实现按COALESCE(occurred_start, mentioned_at, occurred_end)取窗口内最新的 50 条在时间戳密集趋同的记忆库上例如大批量数据用同一日期入库最新键退化后等于近似随机采样可能丢掉窗口内唯一最相关的那条记忆并且在 66 万行的 bank 上退化为全扫描落盘排序30 秒以上。现在每条 fact_type 先取一个按相似度排序的池子_TEMPORAL_POOL_SIZE 60再由_select_with_temporal_coverage轮转式收窄为 10 个铺展的入口点_TEMPORAL_ENTRY_POINTS 10。入口点确定后还通过 temporal/causal 类型的memory_links做最多 5 轮 BFS 扩散每批 20 个节点、每源邻居上限 10邻居的时间分数由自身时间邻近度与父节点分数 × 链接权重 × 因果加成 × 0.7取最大因果类链接causes/caused_by加成 2.0、使能/阻止类enables/prevents1.5。为什么重要使精确的历史查询既能保持相关性又能代表整个时段。即使在时间戳高度聚集的记忆库上例如大批量数据用同一日期入库也能快速返回最优匹配而非任意切片。结果融合Result Fusion四路策略执行完毕后结果被融合出现在多路策略中的记忆排名更高共识排名比分数更重要对不同评分体系更稳健最终结果由一个考虑查询-记忆交互的神经模型重排融合为何重要既语义相似又提及了正确实体的事实会排在仅仅语义相似的事实之前。为什么需要多路策略考虑查询What did Alice say about Python last spring?语义找到 Alice 对编程看法的事实关键词确保 Python 真的被提及图连接 Alice → 编程语言 → 相关实体时间过滤到 last spring 时段四者的融合给你恰好想要的结果——尽管任何单一路径都不够。Token 预算管理Hindsight 面向 AI Agent 而非人类设计。传统搜索系统返回 top-k 条结果但 Agent 不按条数思考——它们按 token 思考。Agent 的上下文窗口以 token 计量Hindsight 也用同样的方式计量结果。工作机制优先选取排名靠前的记忆直到 token 预算耗尽为止你指定上下文预算Hindsight 用最相关的记忆填满它你可控制的参数max_tokens返回多少记忆内容默认4096 tokensbudget搜索深度档位low、mid、hightypes按 world、experience、observation 或 all 过滤tags按可见性标签过滤记忆tags_match标签匹配方式全部选项见 Recall API扩展上下文Chunks记忆是蒸馏后的事实——简洁但有时缺少细微语境。当 Agent 需要更深的上下文时可以可选地取回原始材料Chunks返回生成每条记忆的原始文本——当蒸馏后的事实丢失了重要细节时很有用Memory: Alice prefers Python over JavaScript Chunk: Alice mentioned she prefers Python over JavaScript, mainly because of its data science ecosystem, though she admits JS is better for frontend work and shes been learning TypeScript lately.使用include_chunksTrue配合max_chunk_tokens来控制 chunks 的 token 预算。这在需要逐字引用、或语境很重要的场景非常有用例如 What exactly did Alice say about the project?。调优 Recall质量 vs 延迟不同用例需要在召回质量与响应速度之间做不同取舍两个参数控制这个权衡Budget搜索深度控制 Hindsight 探索记忆库的彻底程度——影响图遍历深度、候选池大小、Cross-Encoder 重排Budget最适合取舍low快速查询、简单问题快可能漏掉间接连接mid大多数查询均衡覆盖好速度合理high需要深度探索的复杂查询彻底较慢示例What did Alices managers team work on? 受益于 high budget因为它要遍历多跳Alice → manager → team → projects并评估更多候选。Max Tokens上下文窗口大小控制返回多少记忆内容Max Tokens约等于文本页数最适合取舍2048约 2 页聚焦回答快 LLM记忆更少更快4096默认约 4 页均衡上下文覆盖好标准8192约 8 页全面上下文记忆更多LLM 更慢示例Summarize everything about Alice 受益于更高的 max_tokens 来纳入更多事实。两个独立维度Budget 和 max_tokens 控制 recall 的不同侧面参数控制什么延迟影响示例Budget探索记忆的彻底程度搜索耗时High budget 找到 Alice → manager → team → projectsMax Tokens返回多少上下文LLM 处理耗时High tokens 向 Agent 返回更多记忆二者相互独立。常见组合BudgetMax Tokens用例highlow深度搜索只返回最佳结果lowhigh快速搜索返回找到的所有东西highhigh综合研究型查询lowlow快速聊天机器人回复推荐配置用例BudgetMax Tokens原因聊天机器人回复low2048快速响应聚焦上下文文档问答mid4096覆盖与速度的平衡研究型查询high8192全面、多跳推理实时搜索low2048最小化延迟评分与排序深度解析本节解释 Hindsight 如何把原始检索结果变成最终的有序列表。流水线共三个阶段RRF 融合、Cross-Encoder 重排、组合评分最后加一步 token 截断。阶段 1Reciprocal Rank FusionRRF所有策略并行运行后结果用 Reciprocal Rank Fusion 合并。RRF 按排名位置合并多个有序列表奖励在多路策略中排名都高的条目不依赖原始分数不同检索方法的分数不可比。公式score(d) Σ 1 / (k rank_i(d)) i其中k 60平滑常数——防止榜首条目独大rank_i(d) 文档d在策略i中的位置从 1 开始求和遍历d出现的所有策略这与 fusion.py 中reciprocal_rank_fusion(result_lists, k60)的实现一致按[semantic, bm25, graph, temporal]的顺序遍历各臂对每个候选累加1.0 / (k rank)同时记录每条臂各自的原始分数arm_scores与各臂排名source_ranks供下游追踪使用。该函数还内置类型守卫——如果某臂返回了 tuple 而非RetrievalResult会立即抛出带臂名和排名的TypeError。RRF 内部四种策略权重完全相等——融合只用排名位置、不看来源没有任何策略获得隐含乘数。但你可以通过HINDSIGHT_API_RECALL_STRATEGY_BOOSTS刻意偏置某个来源。注意这个 boost 应用在另外的两个阶段——重排前过滤上限之前、以及重排之后——而不是 RRF 融合内部。源码层面这个设计选择有明确理由recall_boost.py 模块注释最初的实现是在分数空间里把该臂的1/(krank)乘以权重w标准加权 RRF但 k60 时 300 名窗口内的 RRF 分数只跨越1/61 → 1/360约 5.9 倍任何超过该动态范围的w都会让排序退化为被 boost 臂永远排前、排名只做平局裁决在高召回 bank 上被 boost 臂占满全部 300 个重排名额语义臂候选完全进不了 Cross-Encoder实测 recall20 从 0.97 掉到 0.40。改为在排名空间操作——该臂的贡献按1/(k rank/w)计算——常数项 k 被抵消boost 臂排名第 r 的候选当且仅当r w × s时胜过未 boost 臂的第 s 名位移严格成比例不会翻转榜首。优先级档位为 low2.0、medium4.0、high8.0重排之后还有第二个阶段用BoostWeights.additive给被 boost 臂候选的最终权重加一个固定增量。为什么用 RRF 而不是原始分数合并每种检索策略产生的分数尺度不同余弦相似度、BM25 tf-idf、图激活值。这些分数不可比——BM25 分数 12.5 与余弦相似度 0.85 含义完全不同。RRF 只用排名位置因而对任何评分体系都稳健无需校准。示例一条记忆在语义中排第 1、在 BM25 中排第 5RRF score 1/(601) 1/(605) 0.0164 0.0154 0.0318一条只在语义中排第 1 的记忆RRF score 1/(601) 0.0164前者排名更高因为它具有跨策略的共识。阶段 2Cross-Encoder 重排RRF 给出不错的初始排序但它基于位置而非对查询-文档的深度理解。Cross-Encoder 把每个候选与查询作为一对来评估产出相关性分数。预过滤重排前候选被裁剪到 RRF 分数最高的前300个以限制计算成本可通过HINDSIGHT_API_RERANKER_MAX_CANDIDATES配置config.py 中还有按 low/mid/high budget 分别覆盖的_LOW/_MID/_HIGH变体。若设置了HINDSIGHT_API_RECALL_STRATEGY_BOOSTSboost 会在这一截断之前施加到 RRF 分数上使被偏置来源的候选更容易存活。为什么在 RRF 之后重排RRF 基于位置——它知道某条记忆在多路中排名都不错但从未真正读过查询与记忆的组合。Cross-Encoder 会读它把查询和每个候选作为一对输入基于二者的完整交互产出相关性分数。这能抓住基于位置的融合会漏掉的细微差别比如一条仅因匹配了常用词而在关键词搜索中排第 1、实际却与查询意图无关的记忆。在 reranking.py 中可以看到送进 Cross-Encoder 的文档文本做了两层增强若记忆带context字段则前缀化{context}: {text}若带occurred_start日期则加上双格式日期前缀[Date: June 5, 2022 (2022-06-05)]让模型具备时间感知。分数归一化Cross-Encoder 输出原始 logit可为负。已经落在 [0, 1] 区间内的分数——由校准过的外部 API 重排器如 Cohere、SiliconFlow、ZeroEntropy、Alibaba、Jina返回——原样通过以保留其绝对置信度。落在 [0, 1] 之外的原始 logit 用 sigmoid 归一化CE_normalized 1 / (1 e^(-raw_logit))此外实现中还有 NaN 消毒Cross-Encoder 对某些输入可能返回 NaN会被替换为 0.0避免 NaN 传播到下游评分、再经 JSON 序列化变成null破坏客户端。批处理候选分批打分——本地重排器每批32 对TEI 每批128 对。没有 Cross-Encoder 怎么办在不部署 Cross-Encoder 的场景如 slim 镜像且无外部重排器下系统回退到 RRF 派生分数候选按 RRF 排名被分配铺在 [0.1, 1.0] 区间的合成分数reranking.py 中is_passthrough_reranker分支使下文组合评分的 boost 仍能有意义地工作。若不加此处理pass-through 重排器的所有分数相同乘性 boost 会成为唯一排序信号最终排序退化为纯按新旧排序。阶段 3组合评分Boosts归一化后的 Cross-Encoder 分数会被三个乘性 boost调整纳入 Cross-Encoder 看不到的信号新近性recency、时间邻近度temporal proximity、证据强度proof count。为什么是乘性而不是加性加性 boost如CE 0.1 × recency会给每个候选同样的绝对加分与相关性无关。一条 barely-relevant 的记忆可能仅因更新就超越一条 highly-relevant 的记忆。乘性 boost 让调整与基础相关性成正比——高相关记忆上的 10% 绝对变化大于低相关记忆上的 10%。这保证次要信号永远不会压倒主要的相关性判断。公式与 reranking.py 中apply_combined_scoring的实现逐字对应final_score CE_normalized × recency_boost × temporal_boost × proof_count_boost每个 boost 以 1.0 为中心中性由一个 alpha 限制其最大摆动幅度boost 1 α × (signal - 0.5)Boostα最大调整奖励什么Recency0.2±10%新记忆优于旧记忆Temporal proximity0.2±10%靠近所查询时间窗口的记忆Proof count0.1±5%有更多证据支撑的 observations3.1 Recency 信号默认按记忆发生日期起 365 天线性衰减reranking.py 的compute_recency_decayrecency clamp(1.0 - days_ago / 365, 0.1, 1.0)查询时间戳当天的记忆 recency 为 1.010% boost查询时间戳 6 个月前的记忆 recency 约 0.5中性查询时间戳一年以上的记忆 recency 0.1-8% 惩罚。未提供query_timestamp时以服务器当前时间为准。无日期的记忆得 0.5中性——不加不减。实现细节衰减曲线是可配置的linear/exponential/none三种exponential以 90 天为半衰期且对粗粒度日期有特殊处理——文本只说到年或月的记忆会被提取成整个日历周期如 in 2015 → 2015-01-01 至 2015-12-31这类记忆按周期末尾计算新近性事件最晚可能发生的时刻并把信号封顶在中性值从周期起点算会凭空捏造一个不存在的陈旧而周期若仍在进行则末尾在未来、又会被错误地加成最新。真正的区间多日出差、任职期则不受此特殊处理影响。3.2 时间邻近信号Temporal proximity signal仅在查询含时间引用如 last spring、in 2023时激活度量记忆日期距离所查询时间窗口中心有多近temporal_proximity 1.0 - min(days_from_center / (window_days / 2), 1.0)窗口中心的记忆得 1.010% boost窗口边缘的记忆得 0.0-10% 惩罚。非时间查询中所有记忆得 0.5中性。3.3 Proof count 信号针对 observation 型记忆用对数曲线奖励证据更多的记忆proof_norm clamp(0.5 ln(proof_count) / 10, 0.0, 1.0)Proof countproof_normBoost10.5中性30.611.1%100.732.3%1501.05%上限非 observation 事实world/experience/opinion没有 proof count恒得 0.5 中性基线。组合波动上限所有 boost 同时处于极端时最佳情况×1.10 × 1.10 × 1.05 ≈27%最差情况×0.90 × 0.90 × 0.95 ≈-23%boost 被刻意设计得保守——它们只是微调排序不会覆盖 Cross-Encoder 的相关性判断。阶段 4Token 截断评分完成后结果按final_score排序自顶向下选取直到max_tokens预算耗尽。只有记忆文本计入预算——元数据免费。Budget 如何映射到流水线参数budget参数low/mid/high控制搜索深度——每条策略考虑多少候选。每个档位映射为一个recall budget数值贯穿所有流水线阶段BudgetRecall budgetfixed 模式环境变量覆盖low100HINDSIGHT_API_RECALL_BUDGET_FIXED_LOWmid300默认HINDSIGHT_API_RECALL_BUDGET_FIXED_MIDhigh1000HINDSIGHT_API_RECALL_BUDGET_FIXED_HIGH该 recall budget 在流水线中的流向九个环境变量名均可在 config.py 中确认流水线阶段Recall budget 的用法语义搜索从 HNSW 取 max(recall_budget × 5, 100)裁剪到 recall_budgetBM25 搜索SQL 中LIMIT recall_budget图遍历最多探索 recall_budget 个节点时间铺展通过链接最多激活 recall_budget 个节点结果考量前 recall_budget × 2 条结果进入 token 过滤重排预过滤300 候选与 budget独立——它是单独的旋钮HINDSIGHT_API_RERANKER_MAX_CANDIDATES。自适应预算Adaptive budgeting另一种预算模式让 recall budget 随max_tokens缩放而非使用固定值recall_budget clamp(max_tokens × ratio, min, max)BudgetRatio环境变量覆盖lowmax_tokens 的 2.5%HINDSIGHT_API_RECALL_BUDGET_ADAPTIVE_LOWmidmax_tokens 的 7.5%HINDSIGHT_API_RECALL_BUDGET_ADAPTIVE_MIDhighmax_tokens 的 25%HINDSIGHT_API_RECALL_BUDGET_ADAPTIVE_HIGH结果被夹在地板20HINDSIGHT_API_RECALL_BUDGET_MIN与天花板2000HINDSIGHT_API_RECALL_BUDGET_MAX之间。用HINDSIGHT_API_RECALL_BUDGET_FUNCTIONadaptive启用。图评分细节图遍历link expansion对每个候选组合三个独立信号相加计分信号分数公式值域实体重叠tanh(shared_entity_count × 0.5)[0, 约 1.0]语义链接预计算的 kNN 链接权重[0.7, 1.0]因果链接因果链接权重[0, 1.0]graph_score entity_score semantic_score causal_score ∈ [0, 3]这与 link_expansion_retrieval.py 的合并逻辑一致entity_scores[fact_id] math.tanh(row[score] * 0.5)语义与因果各取最大权重最后三者求和、按总分排序取前 budget 条。相加组合奖励收敛证据——通过多种信号类型连接到查询的记忆排在仅通过单一强信号连接的记忆之前。为什么实体分数用 tanh原始共享实体数量无上界——user 这类高扇出实体可能产生 50 的计数淹没另外两个信号。tanh(count × 0.5)自然饱和前几个共享实体贡献很大1→0.462→0.763→0.91但更多的实体收益递减使实体信号保持在 [0, 1]与语义、因果分数同尺度。为什么这里是加性而不是乘性与组合评分的 boost 不同图信号是独立的证据通道而非对基础分的调整。一条记忆可能仅通过因果链接连接无共享实体、无语义相似——乘性组合会把它清零。加性评分让每个信号独立贡献策略间的最终排序交给外层 RRF 融合。实体信号示例与查询共享 1 个实体的记忆得 tanh(0.5) ≈ 0.46共享 2 个实体得 tanh(1.0) ≈ 0.763 个及以上饱和在 0.91。关键源码索引模块文件说明四路并行检索入口retrieval.py语义BM25 组合 SQL、时间入口点选取与铺展、retrieve_all_fact_types_parallelRRF / 交错融合fusion.pyreciprocal_rank_fusionk60与去重场景的interleave_fusionCross-Encoder 重排reranking.py分数归一化、乘性组合评分、pass-through 回退图遍历link_expansion_retrieval.py实体/语义/因果三路扩展、tanh 实体评分、超时降级策略 boostrecall_boost.py排名空间与加性两阶段 boost 的设计论证环境配置config.py上述所有HINDSIGHT_API_*变量定义对应的测试覆盖位于hindsight-api-slim/tests/例如test_combined_scoring.py组合评分、test_rrf相关的test_fusion_cap.py、test_interleave_fusion.py、test_link_expansion_retrieval.py、test_recall_scoring_time.py、test_recall_temporal_window.py、test_reranker_score_normalization.py等。下一步Retain—— 记忆如何连同丰富上下文一起存储Reflect—— disposition 如何影响推理Recall API—— 代码示例、参数与标签过滤【免费下载链接】hindsightHindsight: Agent Memory That Learns项目地址: https://gitcode.com/GitHub_Trending/hindsight2/hindsight创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Hindsight Recall 检索机制解析：TEMPR 四路并行搜索、RRF 融合与 Cross-Encoder 重排
Hindsight Recall 检索机制解析TEMPR 四路并行搜索、RRF 融合与 Cross-Encoder 重排【免费下载链接】hindsightHindsight: Agent Memory That Learns项目地址: https://gitcode.com/GitHub_Trending/hindsight2/hindsightHindsight 的recall()通过四路并行检索策略语义、关键词、图遍历、时间感知配合 RRF 融合与 Cross-Encoder 重排从记忆库中为 Agent 按 token 预算返回最相关的记忆。本文基于官方文档 retrieval 并结合 API 服务端源码hindsight-api-slim/hindsight_api/engine/search/目录完整还原了从查询进入到最终排序的整条流水线每条策略如何取数、融合公式为何采用排名而非原始分、三个乘性 boost 如何设计、budget参数如何映射为各阶段的候选池规模。读完后你可以依据自己的延迟与召回质量需求精确调整 recall 的每个可调参数。记忆召回的核心难题不同类型的查询需要不同的搜索方式Alice works at Google→ 需要精确的专名匹配Where does Alice work?→ 需要语义理解What did Alice do last spring?→ 需要时间推理Why did Alice leave?→ 需要因果关系追溯没有任何单一检索方法能同时覆盖这些场景。Hindsight 的解法是TEMPR四种互补策略并行运行再统一融合。从源码结构看这个流程图与 retrieval.py 中的实现一一对应模块 docstring 明确写着 Implements: 1. Semantic retrieval, 2. BM25 retrieval, 3. Graph retrieval, 4. Temporal retrieval四路结果装入ParallelRetrievalResult数据类semantic/bm25/graph/temporal四个字段其中temporal可为None当查询不含时间引用时该路整体跳过。四种搜索策略1. 语义搜索Semantic Search作用理解词语背后的含义而不只是词本身。最适合概念匹配Alices job → Alice works as a software engineer同义改写Bobs expertise → Bob specializes in machine learning近义词meeting 匹配 conference、discussion、gathering为什么重要你可以用自然语言提问而不必精确匹配关键词。在实现层面语义臂由一条组合 SQL 承担retrieve_semantic_bm25_combined_sqlretrieval.py用UNION ALL把每个 fact_typeworld / observation / experience拆成独立的 SQL 臂每臂自带ORDER BY embedding $1 LIMIT ...从而命中 Alembic 迁移自动创建的按 fact_type 划分的部分 HNSW 索引idx_mu_emb_world、idx_mu_emb_observation、idx_mu_emb_experience。源码注释特别解释了为什么每臂只取恰好limit行而不是多取 5 倍再裁剪返回的行在臂内已按距离排序前 limit×5 行里取前 limit 行与LIMIT limit完全等价真正影响 ANN 质量的是连接级的候选列表大小而不是这里多取的行数。语义臂还有一个分数下限min_semantic可按请求用recall的min_scores.semantic覆盖弱匹配在进入融合前就在 SQL 层被剪掉。2. 关键词搜索Keyword Search作用找到精确的术语与名称即使它们拼写非常规。最适合专有名词Google、Alice Chen、MIT技术术语PostgreSQL、HNSW、TensorFlow唯一标识URL、产品名、特定短语为什么重要确保你不会漏掉那些提及了特定名称或术语的结果即使它们在语义上离你的查询很远。可插拔后端Hindsight 内置五种 BM25 后端通过HINDSIGHT_API_TEXT_SEARCH_EXTENSION环境变量选择五个变量名均可在 config.py 中确认后端使用技术Citus 兼容nativePostgreSQLtsvectorts_rank_cdTF-IDF非真正的 BM25是vchordvchord_bm25扩展否pg_textsearchTimescalepg_textsearch扩展否pgroongaPGroongaGroonga全文扩展TokenBigram多语言分词器否pg_searchParadeDBpg_search扩展可配置分词器如jieba、chinese_compatible、ngram通过HINDSIGHT_API_TEXT_SEARCH_EXTENSION_PG_SEARCH_TOKENIZER指定是如果你的 Postgres 集群做了水平扩展Citus且需要真正的 BM25 排序pg_search是唯一选择。仓库内提供了配套的pg_searchdocker-compose 示例。实现上BM25 臂是条件性的查询被tokenize_query清洗去标点、小写、按空白切分后若没有任何词元或enable_text_searchFalse纯向量模式时该臂直接从 SQL 中剔除——不是执行后丢弃而是连分词、pg_stats选词查询和/rank 扫描的成本都省掉。查询文本在 bm25_term_selection.py 中构建并与知识库搜索共用同一条构建路径防止两条 BM25 路径的查询形态再次漂移。此外每臂有bm25_min_score下限可通过请求级min_scores.keyword覆盖。3. 图遍历Graph Traversal作用沿实体之间的连接找到间接相关的信息。最适合间接关系What does Alice do? → Alice → Google → Google 的产品实体探索Bobs colleagues → Bob → 同事 → 共同项目多跳推理Alices teams achievements为什么重要能取回那些在语义或词汇上不相似、但通过知识图结构化连接的事实。示例即使 Alice 和她的经理从未在同一条记忆里出现图遍历也能通过共同项目或团队关系找到她的经理。当前默认实现是LinkExpansionRetrieverlink_expansion_retrieval.py它先选出有界的语义种子GRAPH_SEED_LIMIT 20相似度阈值来自graph_seed_min_similarity配置再沿memory_links表中三类一等信号并行扩展实体链接——查询时通过unit_entities自连接分数为种子集与候选之间共享实体的去重数量每个实体用 LATERAL 上限graph_per_entity_limit默认 200防止高扇出实体如 user爆炸中间行数语义链接——预计算的 kNN 图retain 时每个新事实连向最相似的既有事实受阈值约束双向检查图非对称分数即权重因果链接——显式因果链causes/caused_by/enables/prevents分数即权重作为最高质量信号。三类扩展被融合进单条 CTE 查询一次往返、一个连接槽位用source判别列区分Python 合并阶段再套用各自的分数变换。若整条查询超过link_expansion_timeout则自动降级为仅语义因果两路。observations 型记忆因不在memory_links中直接持有实体链接走专门路径source_memory_ids → world facts → entities → other world facts → their observations。4. 时间感知搜索Temporal Search作用理解时间表达按事件发生时间过滤。最适合历史查询What did Alice do in 2023?时间区间What happened last spring?相对时间What did Bob work on last year?前后关系What happened before Alice joined Google?工作原理当查询含时间引用时Hindsight 先把它解析为日期窗口temporal_extraction模块纯 CPU 工作通过线程池移出事件循环执行然后取时间与该窗口重叠的记忆。窗口内候选按与查询的语义相关性选取——而不是按新旧排序因此窗口内最相关的记忆不会因为别的记忆更新而被丢弃。随后选取沿窗口范围铺展窗口被划分成时间桶源码常量_TEMPORAL_COVERAGE_BUCKETS 8retrieval.py每个非空桶先取各自的最强匹配保证what happened in 2023?能取到整年分布的记忆而不是聚集在最密集的时段。时间同时作为评分信号——越靠近窗口中心的记忆获得小幅加成见下文 Temporal proximity 信号。源码中这一相关性优先 覆盖铺展的设计有明确的动机注释retrieval.py早期实现按COALESCE(occurred_start, mentioned_at, occurred_end)取窗口内最新的 50 条在时间戳密集趋同的记忆库上例如大批量数据用同一日期入库最新键退化后等于近似随机采样可能丢掉窗口内唯一最相关的那条记忆并且在 66 万行的 bank 上退化为全扫描落盘排序30 秒以上。现在每条 fact_type 先取一个按相似度排序的池子_TEMPORAL_POOL_SIZE 60再由_select_with_temporal_coverage轮转式收窄为 10 个铺展的入口点_TEMPORAL_ENTRY_POINTS 10。入口点确定后还通过 temporal/causal 类型的memory_links做最多 5 轮 BFS 扩散每批 20 个节点、每源邻居上限 10邻居的时间分数由自身时间邻近度与父节点分数 × 链接权重 × 因果加成 × 0.7取最大因果类链接causes/caused_by加成 2.0、使能/阻止类enables/prevents1.5。为什么重要使精确的历史查询既能保持相关性又能代表整个时段。即使在时间戳高度聚集的记忆库上例如大批量数据用同一日期入库也能快速返回最优匹配而非任意切片。结果融合Result Fusion四路策略执行完毕后结果被融合出现在多路策略中的记忆排名更高共识排名比分数更重要对不同评分体系更稳健最终结果由一个考虑查询-记忆交互的神经模型重排融合为何重要既语义相似又提及了正确实体的事实会排在仅仅语义相似的事实之前。为什么需要多路策略考虑查询What did Alice say about Python last spring?语义找到 Alice 对编程看法的事实关键词确保 Python 真的被提及图连接 Alice → 编程语言 → 相关实体时间过滤到 last spring 时段四者的融合给你恰好想要的结果——尽管任何单一路径都不够。Token 预算管理Hindsight 面向 AI Agent 而非人类设计。传统搜索系统返回 top-k 条结果但 Agent 不按条数思考——它们按 token 思考。Agent 的上下文窗口以 token 计量Hindsight 也用同样的方式计量结果。工作机制优先选取排名靠前的记忆直到 token 预算耗尽为止你指定上下文预算Hindsight 用最相关的记忆填满它你可控制的参数max_tokens返回多少记忆内容默认4096 tokensbudget搜索深度档位low、mid、hightypes按 world、experience、observation 或 all 过滤tags按可见性标签过滤记忆tags_match标签匹配方式全部选项见 Recall API扩展上下文Chunks记忆是蒸馏后的事实——简洁但有时缺少细微语境。当 Agent 需要更深的上下文时可以可选地取回原始材料Chunks返回生成每条记忆的原始文本——当蒸馏后的事实丢失了重要细节时很有用Memory: Alice prefers Python over JavaScript Chunk: Alice mentioned she prefers Python over JavaScript, mainly because of its data science ecosystem, though she admits JS is better for frontend work and shes been learning TypeScript lately.使用include_chunksTrue配合max_chunk_tokens来控制 chunks 的 token 预算。这在需要逐字引用、或语境很重要的场景非常有用例如 What exactly did Alice say about the project?。调优 Recall质量 vs 延迟不同用例需要在召回质量与响应速度之间做不同取舍两个参数控制这个权衡Budget搜索深度控制 Hindsight 探索记忆库的彻底程度——影响图遍历深度、候选池大小、Cross-Encoder 重排Budget最适合取舍low快速查询、简单问题快可能漏掉间接连接mid大多数查询均衡覆盖好速度合理high需要深度探索的复杂查询彻底较慢示例What did Alices managers team work on? 受益于 high budget因为它要遍历多跳Alice → manager → team → projects并评估更多候选。Max Tokens上下文窗口大小控制返回多少记忆内容Max Tokens约等于文本页数最适合取舍2048约 2 页聚焦回答快 LLM记忆更少更快4096默认约 4 页均衡上下文覆盖好标准8192约 8 页全面上下文记忆更多LLM 更慢示例Summarize everything about Alice 受益于更高的 max_tokens 来纳入更多事实。两个独立维度Budget 和 max_tokens 控制 recall 的不同侧面参数控制什么延迟影响示例Budget探索记忆的彻底程度搜索耗时High budget 找到 Alice → manager → team → projectsMax Tokens返回多少上下文LLM 处理耗时High tokens 向 Agent 返回更多记忆二者相互独立。常见组合BudgetMax Tokens用例highlow深度搜索只返回最佳结果lowhigh快速搜索返回找到的所有东西highhigh综合研究型查询lowlow快速聊天机器人回复推荐配置用例BudgetMax Tokens原因聊天机器人回复low2048快速响应聚焦上下文文档问答mid4096覆盖与速度的平衡研究型查询high8192全面、多跳推理实时搜索low2048最小化延迟评分与排序深度解析本节解释 Hindsight 如何把原始检索结果变成最终的有序列表。流水线共三个阶段RRF 融合、Cross-Encoder 重排、组合评分最后加一步 token 截断。阶段 1Reciprocal Rank FusionRRF所有策略并行运行后结果用 Reciprocal Rank Fusion 合并。RRF 按排名位置合并多个有序列表奖励在多路策略中排名都高的条目不依赖原始分数不同检索方法的分数不可比。公式score(d) Σ 1 / (k rank_i(d)) i其中k 60平滑常数——防止榜首条目独大rank_i(d) 文档d在策略i中的位置从 1 开始求和遍历d出现的所有策略这与 fusion.py 中reciprocal_rank_fusion(result_lists, k60)的实现一致按[semantic, bm25, graph, temporal]的顺序遍历各臂对每个候选累加1.0 / (k rank)同时记录每条臂各自的原始分数arm_scores与各臂排名source_ranks供下游追踪使用。该函数还内置类型守卫——如果某臂返回了 tuple 而非RetrievalResult会立即抛出带臂名和排名的TypeError。RRF 内部四种策略权重完全相等——融合只用排名位置、不看来源没有任何策略获得隐含乘数。但你可以通过HINDSIGHT_API_RECALL_STRATEGY_BOOSTS刻意偏置某个来源。注意这个 boost 应用在另外的两个阶段——重排前过滤上限之前、以及重排之后——而不是 RRF 融合内部。源码层面这个设计选择有明确理由recall_boost.py 模块注释最初的实现是在分数空间里把该臂的1/(krank)乘以权重w标准加权 RRF但 k60 时 300 名窗口内的 RRF 分数只跨越1/61 → 1/360约 5.9 倍任何超过该动态范围的w都会让排序退化为被 boost 臂永远排前、排名只做平局裁决在高召回 bank 上被 boost 臂占满全部 300 个重排名额语义臂候选完全进不了 Cross-Encoder实测 recall20 从 0.97 掉到 0.40。改为在排名空间操作——该臂的贡献按1/(k rank/w)计算——常数项 k 被抵消boost 臂排名第 r 的候选当且仅当r w × s时胜过未 boost 臂的第 s 名位移严格成比例不会翻转榜首。优先级档位为 low2.0、medium4.0、high8.0重排之后还有第二个阶段用BoostWeights.additive给被 boost 臂候选的最终权重加一个固定增量。为什么用 RRF 而不是原始分数合并每种检索策略产生的分数尺度不同余弦相似度、BM25 tf-idf、图激活值。这些分数不可比——BM25 分数 12.5 与余弦相似度 0.85 含义完全不同。RRF 只用排名位置因而对任何评分体系都稳健无需校准。示例一条记忆在语义中排第 1、在 BM25 中排第 5RRF score 1/(601) 1/(605) 0.0164 0.0154 0.0318一条只在语义中排第 1 的记忆RRF score 1/(601) 0.0164前者排名更高因为它具有跨策略的共识。阶段 2Cross-Encoder 重排RRF 给出不错的初始排序但它基于位置而非对查询-文档的深度理解。Cross-Encoder 把每个候选与查询作为一对来评估产出相关性分数。预过滤重排前候选被裁剪到 RRF 分数最高的前300个以限制计算成本可通过HINDSIGHT_API_RERANKER_MAX_CANDIDATES配置config.py 中还有按 low/mid/high budget 分别覆盖的_LOW/_MID/_HIGH变体。若设置了HINDSIGHT_API_RECALL_STRATEGY_BOOSTSboost 会在这一截断之前施加到 RRF 分数上使被偏置来源的候选更容易存活。为什么在 RRF 之后重排RRF 基于位置——它知道某条记忆在多路中排名都不错但从未真正读过查询与记忆的组合。Cross-Encoder 会读它把查询和每个候选作为一对输入基于二者的完整交互产出相关性分数。这能抓住基于位置的融合会漏掉的细微差别比如一条仅因匹配了常用词而在关键词搜索中排第 1、实际却与查询意图无关的记忆。在 reranking.py 中可以看到送进 Cross-Encoder 的文档文本做了两层增强若记忆带context字段则前缀化{context}: {text}若带occurred_start日期则加上双格式日期前缀[Date: June 5, 2022 (2022-06-05)]让模型具备时间感知。分数归一化Cross-Encoder 输出原始 logit可为负。已经落在 [0, 1] 区间内的分数——由校准过的外部 API 重排器如 Cohere、SiliconFlow、ZeroEntropy、Alibaba、Jina返回——原样通过以保留其绝对置信度。落在 [0, 1] 之外的原始 logit 用 sigmoid 归一化CE_normalized 1 / (1 e^(-raw_logit))此外实现中还有 NaN 消毒Cross-Encoder 对某些输入可能返回 NaN会被替换为 0.0避免 NaN 传播到下游评分、再经 JSON 序列化变成null破坏客户端。批处理候选分批打分——本地重排器每批32 对TEI 每批128 对。没有 Cross-Encoder 怎么办在不部署 Cross-Encoder 的场景如 slim 镜像且无外部重排器下系统回退到 RRF 派生分数候选按 RRF 排名被分配铺在 [0.1, 1.0] 区间的合成分数reranking.py 中is_passthrough_reranker分支使下文组合评分的 boost 仍能有意义地工作。若不加此处理pass-through 重排器的所有分数相同乘性 boost 会成为唯一排序信号最终排序退化为纯按新旧排序。阶段 3组合评分Boosts归一化后的 Cross-Encoder 分数会被三个乘性 boost调整纳入 Cross-Encoder 看不到的信号新近性recency、时间邻近度temporal proximity、证据强度proof count。为什么是乘性而不是加性加性 boost如CE 0.1 × recency会给每个候选同样的绝对加分与相关性无关。一条 barely-relevant 的记忆可能仅因更新就超越一条 highly-relevant 的记忆。乘性 boost 让调整与基础相关性成正比——高相关记忆上的 10% 绝对变化大于低相关记忆上的 10%。这保证次要信号永远不会压倒主要的相关性判断。公式与 reranking.py 中apply_combined_scoring的实现逐字对应final_score CE_normalized × recency_boost × temporal_boost × proof_count_boost每个 boost 以 1.0 为中心中性由一个 alpha 限制其最大摆动幅度boost 1 α × (signal - 0.5)Boostα最大调整奖励什么Recency0.2±10%新记忆优于旧记忆Temporal proximity0.2±10%靠近所查询时间窗口的记忆Proof count0.1±5%有更多证据支撑的 observations3.1 Recency 信号默认按记忆发生日期起 365 天线性衰减reranking.py 的compute_recency_decayrecency clamp(1.0 - days_ago / 365, 0.1, 1.0)查询时间戳当天的记忆 recency 为 1.010% boost查询时间戳 6 个月前的记忆 recency 约 0.5中性查询时间戳一年以上的记忆 recency 0.1-8% 惩罚。未提供query_timestamp时以服务器当前时间为准。无日期的记忆得 0.5中性——不加不减。实现细节衰减曲线是可配置的linear/exponential/none三种exponential以 90 天为半衰期且对粗粒度日期有特殊处理——文本只说到年或月的记忆会被提取成整个日历周期如 in 2015 → 2015-01-01 至 2015-12-31这类记忆按周期末尾计算新近性事件最晚可能发生的时刻并把信号封顶在中性值从周期起点算会凭空捏造一个不存在的陈旧而周期若仍在进行则末尾在未来、又会被错误地加成最新。真正的区间多日出差、任职期则不受此特殊处理影响。3.2 时间邻近信号Temporal proximity signal仅在查询含时间引用如 last spring、in 2023时激活度量记忆日期距离所查询时间窗口中心有多近temporal_proximity 1.0 - min(days_from_center / (window_days / 2), 1.0)窗口中心的记忆得 1.010% boost窗口边缘的记忆得 0.0-10% 惩罚。非时间查询中所有记忆得 0.5中性。3.3 Proof count 信号针对 observation 型记忆用对数曲线奖励证据更多的记忆proof_norm clamp(0.5 ln(proof_count) / 10, 0.0, 1.0)Proof countproof_normBoost10.5中性30.611.1%100.732.3%1501.05%上限非 observation 事实world/experience/opinion没有 proof count恒得 0.5 中性基线。组合波动上限所有 boost 同时处于极端时最佳情况×1.10 × 1.10 × 1.05 ≈27%最差情况×0.90 × 0.90 × 0.95 ≈-23%boost 被刻意设计得保守——它们只是微调排序不会覆盖 Cross-Encoder 的相关性判断。阶段 4Token 截断评分完成后结果按final_score排序自顶向下选取直到max_tokens预算耗尽。只有记忆文本计入预算——元数据免费。Budget 如何映射到流水线参数budget参数low/mid/high控制搜索深度——每条策略考虑多少候选。每个档位映射为一个recall budget数值贯穿所有流水线阶段BudgetRecall budgetfixed 模式环境变量覆盖low100HINDSIGHT_API_RECALL_BUDGET_FIXED_LOWmid300默认HINDSIGHT_API_RECALL_BUDGET_FIXED_MIDhigh1000HINDSIGHT_API_RECALL_BUDGET_FIXED_HIGH该 recall budget 在流水线中的流向九个环境变量名均可在 config.py 中确认流水线阶段Recall budget 的用法语义搜索从 HNSW 取 max(recall_budget × 5, 100)裁剪到 recall_budgetBM25 搜索SQL 中LIMIT recall_budget图遍历最多探索 recall_budget 个节点时间铺展通过链接最多激活 recall_budget 个节点结果考量前 recall_budget × 2 条结果进入 token 过滤重排预过滤300 候选与 budget独立——它是单独的旋钮HINDSIGHT_API_RERANKER_MAX_CANDIDATES。自适应预算Adaptive budgeting另一种预算模式让 recall budget 随max_tokens缩放而非使用固定值recall_budget clamp(max_tokens × ratio, min, max)BudgetRatio环境变量覆盖lowmax_tokens 的 2.5%HINDSIGHT_API_RECALL_BUDGET_ADAPTIVE_LOWmidmax_tokens 的 7.5%HINDSIGHT_API_RECALL_BUDGET_ADAPTIVE_MIDhighmax_tokens 的 25%HINDSIGHT_API_RECALL_BUDGET_ADAPTIVE_HIGH结果被夹在地板20HINDSIGHT_API_RECALL_BUDGET_MIN与天花板2000HINDSIGHT_API_RECALL_BUDGET_MAX之间。用HINDSIGHT_API_RECALL_BUDGET_FUNCTIONadaptive启用。图评分细节图遍历link expansion对每个候选组合三个独立信号相加计分信号分数公式值域实体重叠tanh(shared_entity_count × 0.5)[0, 约 1.0]语义链接预计算的 kNN 链接权重[0.7, 1.0]因果链接因果链接权重[0, 1.0]graph_score entity_score semantic_score causal_score ∈ [0, 3]这与 link_expansion_retrieval.py 的合并逻辑一致entity_scores[fact_id] math.tanh(row[score] * 0.5)语义与因果各取最大权重最后三者求和、按总分排序取前 budget 条。相加组合奖励收敛证据——通过多种信号类型连接到查询的记忆排在仅通过单一强信号连接的记忆之前。为什么实体分数用 tanh原始共享实体数量无上界——user 这类高扇出实体可能产生 50 的计数淹没另外两个信号。tanh(count × 0.5)自然饱和前几个共享实体贡献很大1→0.462→0.763→0.91但更多的实体收益递减使实体信号保持在 [0, 1]与语义、因果分数同尺度。为什么这里是加性而不是乘性与组合评分的 boost 不同图信号是独立的证据通道而非对基础分的调整。一条记忆可能仅通过因果链接连接无共享实体、无语义相似——乘性组合会把它清零。加性评分让每个信号独立贡献策略间的最终排序交给外层 RRF 融合。实体信号示例与查询共享 1 个实体的记忆得 tanh(0.5) ≈ 0.46共享 2 个实体得 tanh(1.0) ≈ 0.763 个及以上饱和在 0.91。关键源码索引模块文件说明四路并行检索入口retrieval.py语义BM25 组合 SQL、时间入口点选取与铺展、retrieve_all_fact_types_parallelRRF / 交错融合fusion.pyreciprocal_rank_fusionk60与去重场景的interleave_fusionCross-Encoder 重排reranking.py分数归一化、乘性组合评分、pass-through 回退图遍历link_expansion_retrieval.py实体/语义/因果三路扩展、tanh 实体评分、超时降级策略 boostrecall_boost.py排名空间与加性两阶段 boost 的设计论证环境配置config.py上述所有HINDSIGHT_API_*变量定义对应的测试覆盖位于hindsight-api-slim/tests/例如test_combined_scoring.py组合评分、test_rrf相关的test_fusion_cap.py、test_interleave_fusion.py、test_link_expansion_retrieval.py、test_recall_scoring_time.py、test_recall_temporal_window.py、test_reranker_score_normalization.py等。下一步Retain—— 记忆如何连同丰富上下文一起存储Reflect—— disposition 如何影响推理Recall API—— 代码示例、参数与标签过滤【免费下载链接】hindsightHindsight: Agent Memory That Learns项目地址: https://gitcode.com/GitHub_Trending/hindsight2/hindsight创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考