个人知识库如果只做全文搜索或向量检索，很容易回答“这段内容和问题像不像”，但不一定能回答“这些概念之间是什么关系”。KnowledgeBase 这个方向给我的启发是：向量检索适合找语义相近的片段，知识图谱适合表达实体、关系和路径，两者结合后，知识库才更接近可解释的个人记忆系统。
向量检索解决相似，不能单独承担结构理解
向量检索很适合处理自然语言问题。用户不需要精确说出文档里的关键词，只要语义接近，系统就有机会召回相关片段。这对个人笔记、项目文档和技术文章都很有价值，因为人的提问往往比文档标题更口语化。
但向量检索也有边界。它擅长判断文本相似度，却不天然知道一个项目依赖哪些模块、一个概念和另一个概念是什么关系、一次决策影响了哪些后续实现。如果知识库只保存片段向量，问答结果很可能停留在“找到了几段相似内容”。
- • 语义召回适合回答“哪里提到过类似内容”。
- • 片段相似不等于关系清楚，尤其在项目、架构和决策类知识中更明显。
- • 缺少结构信息时，来源引用和推理路径都不够直观。
图谱补的是实体、关系和路径
知识图谱把知识条目拆成实体和关系，例如项目、技术栈、模块、接口、问题、决策和文章之间的连接。它的价值不是替代向量库，而是把“这个东西和哪些东西有关”显式记录下来。
在个人站和求职叙事里，这种结构尤其有用。面试官可能会问：AI Note 和 KnowledgeBase 有什么区别？SocialSavvy 的 RAG 和本站后续 RAG 是什么关系？Java 交付经验如何迁移到 AI 工程？这些问题都需要跨项目、跨文章、跨能力标签地组织答案。
- • 项目到技术栈的关系能支撑能力画像。
- • 文章到项目的关系能支撑复盘引用。
- • 决策到实现的关系能解释为什么采用某种架构。
组合检索：先找候选，再补上下文
更稳妥的做法是把向量检索和图谱查询组合起来。向量检索先根据问题召回语义相关片段；图谱再根据片段所属实体扩展一圈上下文，例如关联项目、技术栈、决策记录和相关复盘文章。
这样生成答案时，模型拿到的不只是孤立片段，而是带有结构线索的材料。它可以知道某段话来自哪个项目，这个项目关联哪些技术栈，哪些文章已经解释过类似设计，以及哪些材料仍处于发布前确认状态。
- • 向量召回负责开放式自然语言入口。
- • 图谱扩展负责补充实体关系和上下文边界。
- • 最终答案应保留来源和不确定性说明，避免把推断写成事实。
KnowledgeBase 给本站 RAG 的参考
KnowledgeBase 项目探索的是 Markdown 知识条目、自动知识抽取、Neo4j 图谱、前端可视化和 RAG 问答。它适合作为本站后续智能知识库的参考，但不意味着 M1 阶段要直接接入真实服务。
当前个人站仍保持静态前端。更适合先把内容模型整理清楚：哪些项目可公开，哪些材料需要脱敏，哪些文章可以作为知识来源，哪些截图、演示地址和代码仓库仍然需要发布前确认。等这些边界稳定后，再把结构化内容导入后续 RAG 服务。
工程取舍：不要让图谱变成负担
图谱有表达力，但也有维护成本。首版不应该试图把所有文本都抽成复杂关系，而是优先抽取高价值实体：项目、技术栈、文章、决策、问题和能力标签。关系也要控制在能被页面和问答真实使用的范围内。
如果一条关系不能帮助检索、解释、导航或复盘，它就不应该在首版占据太多维护成本。对个人知识库来说，图谱不是为了看起来复杂，而是为了让知识之间的连接更容易被使用。
- • 先定义稳定实体，再逐步增加关系类型。
- • 优先服务问答引用、项目导航和能力画像。
- • 保留人工校正入口，避免自动抽取关系污染知识库。
公开边界
这篇文章只讨论图谱和向量检索的公开设计思路，不展示私人知识条目、Neo4j 连接配置、模型 Provider 配置、部署凭据或真实来源样例。
后续如果展示 KnowledgeBase 截图，图谱节点和问答引用都应使用虚构或可公开知识条目；如果公开代码仓库，也需要先检查配置、样例数据和部署脚本是否已经脱敏。