外观
怎么找回真正相关的记忆？
项目版本说明
这些问答整合历史设计与实现资料；当前 main 分支 README 以工作包描述建设状态。具体能力、实验数据与设计目标的边界见项目状态与证据。
标准回答
召回先限制可访问和仍有效的数据，再结合关键词与语义检索找候选，排序后按预算返回相关内容与依据。
关键词检索：看你用了什么词
查询“pgvector 索引”时，包含这个专有名词的记忆通常很有价值。全文检索会把文本处理成适合搜索的形式，再匹配查询和评估相关性。不同语言的切词与配置会影响结果，中文不能默认与英文效果相同。
语义检索：看表达的意思是否接近
你问“以前决定把数据存在哪里”，记忆写的是“项目使用 PostgreSQL”。两句话用词不完全一样，但含义相关。Embedding 模型把文本转换成一组数字，即向量，让系统能够比较表达之间的接近程度。
一个足够准确的理解
向量像用于比较语义的坐标。坐标接近只说明模型认为内容相似，不表示事实正确，也不表示你有权限使用。每一维通常不能被简单命名为“数据库”“偏好”等人工标签。
混合检索怎么理解
关键词通道擅长处理明确词语；向量通道补充语义相近的候选。系统把两路结果合并、排序，再检查适用性。两路结合是可用策略，效果仍需要在实际数据上验证，不能自动推出一定比单路好。
一次读取，按这六步讲
- **识别调用者：**确定其身份与有效授权。
- **限定范围：**只允许目标 Space 中可访问的内容进入受控查询。
- **取得候选：**关键词搜索，并在语义通道可用时结合查询向量搜索。
- **检查有效性：**排除被撤销、过时、不再有有效推导依据等不适用内容。
- **组织上下文：**排序，控制条数和 token 预算，附带来源信息。
- **交给使用者：**Agent 或回答服务收到上下文，再用于当前任务。
这是便于讲解的逻辑顺序。实际代码可能在数据库查询、服务层、答案提交和缓存读取等多处重复校验，不能把安全约束只放在最后一步。
为什么要有 token 预算
Token 是模型处理文本的计量单位，与汉字或单词没有固定一一对应关系。找回 100 条记忆，并不代表都应塞进输入；上下文需要留给问题、指令和回答。预算限制让返回内容有明确上限。
Recall 和 Ask 有什么不同
**Recall：**找回相关记忆。**Ask：**结合可用记忆形成答案，需要处理引用、答案提交和可能的缓存。找回一条正确资料，并不等于最终答案一定正确。
自查：为什么“能搜到”还不够？
还要相关、授权范围正确、事实仍有效、来源未撤销，并且在上下文预算内。最终 Agent 是否使用、使用是否正确，还需要另外验证。
内容来源
- EachOf Wiki · 记忆与上下文 · 原条目
retrieve