站点里关于知识图谱的实现思路

一、多类型节点 + 多语义边的设计

传统博客图谱只有"文章-文章"一种边，无法表达丰富的知识结构。本系统扩展为4 种节点类型 + 6 种语义边：

节点类型：

• 文章（article）
• 标签（tag）
• 概念（concept）— 抽象方法论，如 RAG、MCP、Prompt Engineering
• 实体（entity）— 具体产品/工具/组织，如 OpenAI、LangChain

边类型：

• links — 显式双链 [[]]
• belongs_to — 文章归属标签
• similar — 基于共同标签的相似关系
• references / builds_on / contradicts — LLM 发现的语义关系（引用、构建于、矛盾）

二、来源追踪机制（核心设计）

每个节点和边都带 source 字段：auto（自动生成）/ manual（人工补充）/ both。

为什么重要？ 增量更新时，删除一篇文章只会清理它拥有的 auto 边和孤立 auto 节点，保留 manual 节点——因为人工补充的概念节点可能跨文章共享，不能因为某一篇删除而丢失。

三、增量更新而非全量重建

文章增删改时，不需要重新扫描全部文章：

• 新增：追加该文章的节点 + belongs_to 边 + links 边，重算受影响节点的 degree
• 删除：移除该文章所有边，清理孤立 auto 节点（manual 保留）
• 修改：先删后加

只有数据结构升级或批量导入时才走全量重建。

四、LLM 实体提取增强

基础图（wikilink + tag）是确定性的，LLM 在此之上补充语义层：

• 通过结构化 prompt 让 LLM 返回 JSON（实体列表 + 关系列表）
• 区分 concept（抽象）vs entity（具体）
• 过滤置信度 < 0.5 的低质量结果
• 传入已有节点列表避免重复提取
• 结果带 llmMeta（置信度、提取来源、时间戳）便于追溯

五、D3.js 渲染（弃用 ReactFlow）

为什么放弃 ReactFlow？

• ReactFlow 的批量 tick 让力导向失去连续模拟的丝滑感
• React 状态更新有延迟，拖拽反馈不如 D3 直接操作 DOM
• ReactFlow 用 DOM 渲染节点，限制渐变、光晕等 SVG 表现力
• ReactFlow 有边界限制，D3 可无界缩放/平移

节点尺寸公式：size = baseSize + degree × scaleFactor，连接度高的节点视觉上更大，自然突出关键文章。

三种布局：力导向（整体关联）、分层（知识层次）、聚类（主题分组）。

六、图谱反哺搜索（Graph Retrieval）

图谱不只是展示，还作为搜索的结构化扩展召回通道：

• 命中文章节点 → 直接高分（1.0）
• 命中标签/概念/实体 → 沿边扩展到相邻文章（0.75~0.8）
• 文章的邻居文章 → 中等分（0.6，"相关阅读"逻辑）

与 embedding 语义召回、rerank 精排共同构成完整检索管线，图谱提供的是结构化关联，弥补语义相似度的盲区。

核心设计哲学

1. 来源追踪 — 区分人工/自动，让增量更新可安全清理
2. 渐进增强 — 先有确定性基础图，再叠 LLM 语义层，每层独立可关
3. 图谱即检索 — 不只是可视化，更是搜索的扩展通道
4. 交互优先 — 为力导向手感牺牲框架便利，选 D3 而非 ReactFlow