图谱增强的另一种思路：把"图"从展示变成检索信号（一个有趣的提案）

[heptaspirit]

今天聊兴趣漂移（ #21 ）的时候，顺着 mneme 的实体三表和 ego graph 前端，想了一些关于"图谱还能怎么用"的事情，整理成了一份完整思路文档。今天发出来供大家讨论。

这只是一个"有趣的提案"，不是功能需求，更不是建议清单。 充分尊重本项目的设计哲学和路线图（0.6.x 笔记化记忆库、v0.7 兴趣漂移 + 跨 workspace），如果本文里面有一两条思路对后续设计有点启发，那就足够了。

核心想法：图谱的问题从来不是"没画出来"，而是"没有激活"。 Obsidian 的双链不主动点就没有下文，因为它是静态的；Transformer 的权重矩阵"活"但不可见。mneme 的实体三表结构是显式的，但缺的是"激活"——把图从"展示"变成"检索信号"，让 LLM 的每次推理都受益于它，而不需要 LLM"主动去看"。

特别注意到 0.6.x 的 Wiki-Link / Tag / Tag 加权召回已经在"关系维度"上铺了路，所以这份思路更像是顺着设计方向的自然延伸（把连接从"存储"升级为"运行时信号"），而不是另起炉灶。

以下附上完整文档。
dsh-mneme-discussion-draft-graph-enhancement.md

[Anans-Ivresse]

认真读完这份完整文档，有几个地方想聊聊我的看法。

最认同的：三个接入点 + 运行时零 LLM 的设计哲学

把图谱的价值前置到检索阶段、让 LLM 被动受益——这个判断很准。mneme 目前的 injectCandidates 流程里，LLM 只看到 render() 输出的自然语言条目，任何结构化的东西塞进去都是浪费。三接入点（注入锚定、检索叠加、边 touch）全部走纯 SQL + 算术，毫秒级开销，这个克制程度是合理的。

一个疑问：建图级联深度默认 1 是否太保守？

文档说"默认 1 防无限遍历→完整建库"，但个人记忆库规模（79 条）下，级联到 2 跳的边际成本很低。而且"慢速生长"的一个副作用是：用户感知不到效果，可能还没等到图"长出来"就关掉了。如果默认 2 跳 + Tag 冷启动，几周内就能看到可感知的召回提升，用户才有耐心等它继续长。

Tag 共现噪声问题

Tag 冷启动确实是最省成本的路径，但宽泛标签（"#考研""#公共管理""#技术"）的共现噪声可能不小——同 tag 的记忆不一定真有实体级关联。文档里的停用词表 + 词长阈值 + 实体类型约束能挡住一部分，但 Tag 本身是 LLM 打的，延续了 LLM 的偏差。一个想法：Tag 共现边初始权重取低一点（比如 0.3 而不是 0.5），等 touch 反馈自然抬升——让"用出来的权重"来决定，而不是"建出来的权重"。

人工确认闭环：交互成本 vs 被动确认

白盒原则（可解释、可干预、可审计）没问题，但"认可/删除/忽略"三选一需要用户主动打开 ego graph 去操作——这个门槛不低。能不能做一层"被动确认"：用户正常使用时的 touch 行为本身就是隐式认可（被用过的路径加粗），只有算法发现自己错了（比如某条边一直被 touch 但从不被引用）才需要主动提醒用户。这样大部分边靠使用自然演化，用户只在"算法自知不确定"的时候才介入。

最欣赏的：诚实评估 + 最小验证实验

文档明确说"embedding 大概率已经够用，图谱增量是边际的"，然后把真正值钱的场景限定在长尾关系、可解释性、权重演化——这个定位很准确。验证实验的设计也很务实：5-10 个探针问题、top-5 命中率、多跳 vs 1-hop 对照。建议 @heptaspirit 如果要跑这个实验，探针问题可以复用 issue #21 里兴趣漂移的那些长尾场景，同一个数据集出两个方向的结论。

[heptaspirit]

@Anans-Ivresse 谢谢认真读完文档还给了具体的反馈

关于级联深度默认 1 太保守——你说得对，已采纳。

"慢速生长的一个副作用是用户感知不到效果，可能还没等图'长出来'就关掉了"。这个点我确实没考虑到。激活驱动建图本来就有 touch 门控和 heat 衰减做约束，防"无限遍历 → 完整建库"的担忧在激活驱动下本来就弱化了，默认 1 是残留的保守。已经改成默认 2（范围 [1,3] 不变），让图更快长出可感知的效果。

关于 Tag 共现噪声和初始权重——认同，而且你这个思路比我的更彻底。

宽泛标签（"#考研""#技术"）的共现噪声确实是问题，停用词表只能挡一部分，因为 tag 本身就是 LLM 打的、延续了 LLM 的偏差。你把 Tag 共现边初始权重调到 0.3、靠 touch 反馈自然抬升。这个"让用出来的权重决定，而不是建出来的权重决定"正是文档里 5.4 建图哲学（"关系是用出来的，不是建出来的"）的彻底贯彻。已采纳，初步设定 manual 1.0 / manual_confirmed 保持 / tag 0.3 / llm 0.4。

关于人工确认闭环的交互成本——这是最有价值的一条，已采纳为"被动确认"主路径。

"认可/删除/忽略"三选一确实需要用户主动打开 ego graph，门槛不低。你说的"被动确认"：touch 即隐式认可、只有算法自知不确定才提醒用户，其实把两个机制缝起来了：正常使用时的 touch 本来就是边权重抬升（隐式认可），用户无感；只有出现信号冲突（比如一条边被 touch 多次但从不被引用）才触发异常提醒，让用户三选一。这符合"例外管理"：大部分边靠使用自然演化，用户只在算法不确定时介入。文档 5.10 已经改为这个结构。

关于验证实验复用 #21 场景——好主意，已采纳。

同一数据集出两个方向的结论（兴趣漂移 + 图谱桥接），可比性更高，也能互相印证。后续有机会进行的 6.2 验证实验的探针已经将注明复用 #21 的长尾场景。

---

另外补充两个思考时新补的设计，供参考：

① 图谱遍历的起点（锚定）：query 是自然语言、实体名是术语，两者常对不上："处理文档的 CLI 工具"里没有"officecli"。所以锚定分三层：精确名匹配 → Tag 桥接（query 命中 tag → 同 tag 记忆的实体，mneme 特有）→ 向量相似（query 向量 vs 实体）。起点是集合而非单点（多路尝试，激活可累加），起点空则图谱不参与、退回纯向量/keyword。

② 注入的预算分级：图谱增强后候选池变大，但注入预算不变（5 条 / 1500 字符）。不推纯标题（LLM 是单次消费，只有标题的条目会被当噪声），按融合分加权分配预算：top-2 完整内容、中位 2 摘要、末位 1 标题 + 关联提示（"经 officecli 桥接召回"），5 条都有可消费信息。

[Anans-Ivresse]

@heptaspirit 你把反馈采纳得又快又准，尤其把"被动确认"缝进 touch 门控、收敛成"例外管理"——这版设计明显更自洽了。你新补的两点我也顺着聊两句：

① 锚定分层（精确名 → Tag 桥接 → 向量）方向认同，两个落地细节想确认：

• 多路起点的激活要累加没错，但建议加一层归一化：三路命中的边权重尺度本就不同（精确名是 1.0、向量是 cos 相似度、Tag 共现是计数），直接累加容易让 Tag 这种高频命中的通路淹没低频但强相关的实体关系。可以在聚合前按通路做 min-max 或排序权重再决定整体候选，避免 Tag 数量优势扭曲图谱指纹。
• "起点集合"建议给一个规模上界（比如单次检索活动累计激活的种子实体 ≤ N 个）。否则三路全开时被 touch 的边数会逼近"完整建库"，又绕回了当初防无限遍历的顾虑——上限能保证累加出来的仍是活跃子图，而不是冷启动期就把整个库点亮。

② 注入预算分级赞成，补充一个信号质量问题：

• 位置 5 那条"经 officecli 桥接召回"的关联提示，本质是一条低置信元数据，而 LLM 单次消费时容易把它当有依据的实体回头引用扩散。建议要么在提示语上明确标注它是检索线索而非事实（比如前缀 [检索线索]，或并入"经 X 桥接召回"的固定句式让 LLM 识别为链路信息），要么索性只作用于排序、不进最终注入文本。否则图谱桥接越多，越容易诱导 LLM 把"桥接来的"说成"记得的"。

落地建议：这些已经明显超出"有趣提案"、接近具体设计了。建议把"图谱桥接"拆成一个正式 feature issue（锚定层 + 权重演化 + 预算分级 + 被动确认四块），并入 v0.7.0 排期，这样讨论能闭环、后续也能被 issue/PR 直接追踪。要不要我来起这个 issue？🙌

[heptaspirit]

@Anans-Ivresse 这轮的两个落地细节和信号质量提醒都很到位
① 多路激活归一化——同意，这是我们的疏漏。

三路尺度确实完全不同（精确名是布尔 1.0、Tag 是计数、向量是 cos 相似度），直接累加的话，一次命中 5-15 个种子的高频 Tag 通路会主导激活分布，把低频但强相关的实体关系淹没。已按你的建议改成" 按通路先做 min-max（或 rank）归一化，再跨通路累加 "，写进了文档 5.3 锚定部分。

② 种子规模上界——同意，加上了。

"三路全开 → 被 touch 的边数逼近完整建库"这个担忧很实在，确实绕回了当初防无限遍历的顾虑。已加参数 graphSeedCap（建议默认 12，范围 [1,30]），单次检索的激活种子数封顶，保证扩散出来的是活跃子图，而不是冷启动期就把整个库点亮。

③ 关联提示的诱导风险——这条最有价值。

"LLM 单次消费时会把'经 X 桥接召回'当成有依据的事实引用"——这正是幻觉诱导的机制，而且图谱桥接越多越严重。已采纳双轨：默认用固定句式前缀 [检索线索] 明确标注"链路信息非事实断言"；另留 graphInjectHint=false 的保守选项（关联提示只作用于排序、不进最终注入文本）。也把一条原则写进了文档：注入文本里的任何信息默认都会被 LLM 当事实,元信息必须显式标注其非事实属性。

④ 关于起 issue 和排期——非常期待，但排期想对齐一下。

能通过 issue/PR 追踪这套设计太好了，四块拆法（锚定层 + 权重演化 + 预算分级 + 被动确认）我完全认同，很乐意你来起这个 issue。

不过排期上我有个想法，想跟你们对齐：图谱桥接本质是 增强型功能 ——它在已有记忆体系之上叠加关系维度，前置依赖是 heat（v0.7 的兴趣漂移）先落地、Wiki-Link/Tag（0.6.x）先稳定。而目前 v0.7 的预期的计划是 workspace 和兴趣漂移，这两个是更基础的能力，值得先打磨扎实。

所以我的建议是：issue 可以先开（方便追踪讨论），但排期放在 v0.8+ 或之后，让 v0.7 专注把目前路线图上预期的基础打牢，图谱桥接等 heat 稳定后再接。那时候三个接入点的地基（TYPE_DECAY、touch、sleep）才真正齐了。当然这只是我作为使用者的节奏建议，最终以项目的路线图判断为准 🙌

以下是我此番修改后的文档
dsh-mneme-graph-philosophy.md

[Anans-Ivresse]

一圈看下来，这版设计已经打磨得很扎实了。几个关键补丁——归一化、种子上界、[检索线索] 标注——都到位了，尤其"被动确认"缝进 touch 门控之后，整个建图哲学从"建出来的"到"用出来的"这条线彻底闭环了 👍

关于排期，完全同意 v0.8+。

v0.7 先把 workspace 和兴趣漂移（heat）这两个地基打牢是对的。图谱桥接的三个接入点（TYPE_DECAY、touch、sleep）本身就依赖 heat 成熟后的信号质量，先跑稳 v0.7 再往上叠关系维度，比现在硬上更自洽。

issue 我来起，按你提的四块拆（锚定层 + 权重演化 + 预算分级 + 被动确认），挂 v0.8 milestone，这样讨论有地方追踪，排期也不挤占 v0.7 的节奏。写好了 @ 你。

[Anans-Ivresse]

issue 已按汇总建立，挂 v0.8 milestone，把合议的四块（锚定层 / 权重演化 / 注入预算分级与 [检索线索] 防幻觉 / 被动确认）都收进去了，另建了专用验收清单可逐块勾选。感谢这次完整的提案和一周末的推敲 🙏

追踪: #24

@heptaspirit 后续在这条 issue 上继续推。