图谱工程实战指南：十一步改造Obsidian知识库

如何将Obsidian知识库改造成适合大模型使用的结构？

通过图工程改造，包括设计精简路由器、维护索引文件、拆分小节点、使用精准维基链接、用逻辑检索替代模型调用、记录状态文件等十一步骤，使大模型只需读取两三个文件即可精准回答。

路由器文件应该包含什么内容？为什么需要控制在500 token以内？

路由器文件只包含事实性指向，如计费规则指向billing-rules，客户资料指向client-acme，写作规范指向voice，不包含解释性文字。控制在500 token以内是为了避免大模型每次提问先消化长文，浪费预算，影响回答效率。

索引文件在知识库中起什么作用？如何维护？

索引文件记录每个节点的名称、链接和一句话摘要，使大模型提问时先扫索引就能判断答案所在节点，无需打开笔记。维护方法是每新增一个笔记节点就顺手在索引里加一行，格式为文件名加简短描述，保持更新。

为什么节点要小而专？如何命名节点？

节点小而专可以避免大模型为使用其中一行而读取整个大文件，节省token和算力。节点命名要直白，文件名直接说明内容，如计费规则就叫billing-rules，避免抽象缩写。

Obsidian的图谱视图对检索有帮助吗？真正的边是什么？

图谱视图对检索速度没有贡献，只是视觉展示。真正的边是节点内部的维基链接，用于在节点间跳转，且必须精准，只连接确实存在依赖关系的节点，避免噪音。

如何用逻辑检索替代模型调用？具体步骤是什么？

逻辑检索通过关键词匹配和打分来定位答案，不调用模型。步骤包括：提取关键词、在索引中给节点打分、打开得分最高的节点、读取相关段落、如有链接则跳转。前五步零成本，最后才让大模型整理输出。

状态文件有什么作用？如何记录？

状态文件记录上次运行的成功和失败路径，使新会话能避开错误，复用成功路径，让知识库越用越聪明。记录内容包括成功路径（如退款问题→router→index→billing-rules→client-acme）和失败尝试（如单搜“费用”命中率低）。

改造后如何验证效果？为什么需要验证？

通过对比测试验证：用同一批问题分别问原始知识库和图结构知识库，记录token消耗、响应时间和答案质量。验证是必要的，因为直觉可能不准确，实际数据能证明节省了多少token和秒数。

为什么应该先写笔记再建图？

因为空图结构没有价值，先写笔记能积累真实内容，连接关系自然浮现，基于真实笔记建的图结构才有实际用处。

在十一步骤中，哪一步最值得优先实施？为什么？

索引是最值得优先实施的步骤，因为投入最小、提升最明显。只需开一个文件，每写一个笔记加一行描述，就能放大路由器和边的效果，为后续步骤打好基础。