召回问题

记忆明明存在却召回不出来、召回了不相关的记忆，或者召回很慢时，先修记忆本身的结构。确认记忆没问题之后，再去调权重和阈值。

在召回页面测试一条提示词复制锚点链接

1. 打开召回页面。自托管服务器请访问 http://127.0.0.1:18901/recall。Loremem 云服务请在控制台中打开召回页面。
2. 粘贴失败时使用的完整提示词，然后运行。
3. 查看各个流程阶段。对每个候选，检查它的分数、是否通过展示阈值，以及命中了哪些线索词。
4. 将结果与 Agent 收到的 <recall> 块对比。每一行都显示分数、URI 和线索词。

没有召回任何内容复制锚点链接

原因： 以下三种情况之一：

• 嵌入模型的设置为空或有误。召回在搜索前需要先解析嵌入模型，解析失败时请求会报错，Agent 收不到 <recall> 块。
• 没有记忆匹配。图谱为空，或者记忆缺少提示词中使用的触发条件和术语。
• 所有候选的分数都低于 recall.display.min_display_score（默认 0.60）。只有至少一条内容通过时，Lore 才会写入 <recall> 块。

修复：

1. 打开 /setup 或 /settings，确认嵌入模型的基础 URL、API 密钥和模型名称已保存。运行连接测试。
2. 在召回页面运行该提示词。如果记忆不是候选，请把它的触发条件改写为一个具体的场景，并把人们实际会输入的词加入术语。参见写好一条记忆。
3. 如果记忆是候选，但分数低于阈值，先改进记忆的结构。只有当记忆确实相关、结构也已经良好时，才降低 recall.display.min_display_score。

召回了错误的记忆复制锚点链接

原因： 宽泛的节点会匹配很多提示词，通常是因为它涵盖多个主题，或者触发条件过于笼统。优先级过高会让情况更糟。优先级会增加排序加分，因此标为 0 或 1 的记忆可能会排在更具体的记忆前面。优先级不会强行让记忆出现，但会把它往前推。

修复：

1. 把宽泛的节点拆分为挂在真实父节点下的聚焦子节点。每个子节点只使用一个触发条件。
2. 降低非核心记忆的优先级。优先级 0 在整个库中最多 5 个节点，优先级 1 最多 15 个。
3. 在召回页面重新运行该提示词。

中文提示词匹配效果差复制锚点链接

原因： PostgreSQL 会退回到 simple 文本搜索配置，它无法切分中文词语。Lore 依次尝试 pg_jieba、zhparser，最后退回 simple，并且在服务器重启之前会一直沿用这个检测结果。

检查： 在 Lore 数据库中运行以下两条查询。如果某条报错，说明对应的扩展不可用。

SELECT to_tsvector('jiebacfg', '测试');
SELECT to_tsvector('zhparser', '测试');

修复：

1. 使用 Lore 的 PostgreSQL 镜像 fffattiger/pgvector-zhparser:pg16，它同时包含两者。
2. 如果使用自己的 PostgreSQL 服务器，请安装 pg_jieba（推荐）或 zhparser。使用 pg_jieba 时，还要把它加入 shared_preload_libraries，然后重启 PostgreSQL。
3. 重启 Lore 服务器，让它重新检测配置。
4. 在术语中同时加入中英文变体，例如 refund 和 退款。

召回很慢或被跳过复制锚点链接

原因： Lore 在搜索前需要先为查询生成嵌入，因此嵌入端点或数据库变慢，都会拖慢每一次召回。另外还有两个时间限制：

• 召回请求的耗时超过 recall.safety.timeout_ms（默认 2000 毫秒）时会被终止。Lore 随后返回以下提示，而不是候选结果：Recall took longer than 2 seconds and was skipped. Use lore_search for detailed related memories. 这一限制适用于 API 客户端和 Hermes 插件使用的召回接口。
• Agent 的 Hook 会在自身的超时时间后停止等待。Claude Code、Codex、ZCode 和 DeepSeek Harness 的超时时间为 10 秒（dsh 可用 LORE_PROMPT_TIMEOUT_MS 调整）。之后提示词会继续处理，但不会带上 <recall> 块。

修复：

1. 检查嵌入端点能否快速响应，以及数据库是否负载过高。
2. 减少匹配大量提示词的宽泛节点。
3. 只有在提示持续出现，且嵌入端点确实很慢时，才调高 recall.safety.timeout_ms。允许范围为 500 到 30000 毫秒。

Agent 忽略召回结果复制锚点链接

原因： <recall> 中的每一行只是线索，不是事实。Agent 需要打开节点。只有当 Agent 使用标签中的 session_id 和 query_id 调用 lore_get_node 时，Lore 才会把该记忆计为 采用（Used）。

检查： 在召回页面的召回分析中，对比该运行时的 展示（Shown，即注入提示词的次数）与 采用（Used，即 Agent 打开过的次数）。展示次数高而采用次数低，说明 Agent 看到了这些行，却没有打开它们。

修复：

1. 让每个触发条件足够具体，使 Agent 知道什么时候应该打开这个节点。
2. 在设置页面中加强指导：lifecycle.guidance.global 保存使用指导，lifecycle.prompt_recall.preamble 保存每个召回块之前的文字。告诉 Agent 在依赖召回的记忆之前先打开它。
3. 确认 Agent 原样传递标签中的 session_id 和 query_id。缺少它们，Lore 就无法把采用记录到正确的那次召回上。

记忆存在，但从不出现复制锚点链接

原因： 该记忆不是你所测试提示词的候选，或者它是候选，但分数低于阈值。

修复：

1. 在召回页面运行完全相同的提示词，并查看各个阶段。
2. 如果它不是候选，说明触发条件和术语与提示词的表达方式不匹配。请把触发条件改写为一个场景，并加入人们会输入的词。
3. 如果它是候选但低于阈值，先修复结构，再调整阈值。然后重新测试。

大幅修改后结果过时复制锚点链接

原因： Lore 会根据节点内容生成视图（view），即用于语义搜索的摘要（gist 和 question）。修改嵌入模型会使所有现有嵌入失效，因此在重建完成之前，结果可能滞后。

修复：

1. 等待重建完成。修改嵌入模型时会要求确认，然后重建所有嵌入。
2. 在节点页面点击 重建，重建该节点的视图。
3. 在设置页面点击 重建索引，重建整个索引。
4. 在召回页面重新运行该提示词。