把 Markdown 笔记变成可问答的知识图谱：本地 Graph RAG 工具 Kwipu 实测
你有没有这种困境：Obsidian 或者本地 Markdown 笔记越积越多，却只能靠关键词搜索，根本无法跨文件追问「这个概念和那个概念有什么关联」？
Kwipu 想解决的正是这个问题——它把你的 Markdown 笔记目录，构建成一张可被本地 LLM 查询的知识图谱（Property Graph），实现真正的自然语言 Q&A。全程本地，不碰云端。
它是怎么工作的
Kwipu 的核心管道非常清晰：
Markdown 文件
→ 预处理（解析 [[wikilinks]] 和 YAML frontmatter）
→ LLM 提取（实体 + 关系三元组）
→ Property Graph Index（持久化到 storage_graph/）
→ 混合检索（Vector + BM25 + 时间维度 + 同义词）
→ LLM 生成回答
区别于普通 RAG 只做向量相似度检索，Kwipu 引入了图结构：每个实体、每条关系都被提取出来，查询时同时走向量、BM25 和图关系，命中质量更高，尤其适合知识密度高的笔记库。
核心特性一览
| 特性 | 说明 |
|---|---|
| 完全本地 | 基于 Ollama 运行，数据不出本机 |
| Graph RAG | 实体-关系三元组 + 混合检索 |
| 增量更新 | 新增一个文件只需 20-60s，无需全量重建 |
| Obsidian 友好 | 自动识别 [[wikilinks]]，.obsidian/ 配置忽略 |
| 多语言支持 | 通过 lang_config.py 配置 |
| 持久化图索引 | 构建一次，后续查询秒级加载 |
快速上手
环境要求：
- Ollama（本地推理引擎）
- 推荐模型：
llama3.1:8b/qwen2.5:7b/mistral:7b - Embedding：
nomic-embed-text
# 克隆项目
git clone https://github.com/benmaster82/Kwipu
cd Kwipu
pip install -r requirements.txt
# 拉取所需模型
ollama pull qwen2.5:7b
ollama pull nomic-embed-text
# 把笔记放到 knowledge_base/ 或修改 geode_graph.py 中的 KNOWLEDGE_DIR
# Obsidian 用户直接指向 vault 路径即可
# 启动
python geode_graph.py
首次运行会构建图索引，时间取决于笔记数量：
| 笔记数量 | GPU（7B） | CPU（7B） |
|---|---|---|
| 5 篇 | ~2 分钟 | ~5 分钟 |
| 20 篇 | ~7 分钟 | ~20 分钟 |
| 100 篇 | ~35 分钟 | ~100 分钟 |
| 500+ 篇 | ~3 小时 | 不建议 |
重要：构建完成后图结构持久化到磁盘，后续启动秒级加载，新增文件增量更新约 20-60 秒。
硬件需求参考
| 组件 | 内存占用 |
|---|---|
| Ollama LLM（7B Q4） | ~5-6 GB |
| Embedding 模型 | ~300 MB |
| 图索引构建 | 0.5-4 GB |
| 查询阶段 | 200-500 MB |
| 7B 方案合计 | 约 8-12 GB |
推荐最低配置：16 GB 内存 + 独立显卡（有 GPU 加速差距明显）。
一个实用技巧：先云后本地
Kwipu 项目文档里有个思路很有意思：
用一次性的强力云模型（通过 Ollama API 接入）构建知识图谱，然后切换成轻量本地模型日常查询。
图结构（实体、关系、三元组）一旦构建完成就和模型解耦了，切换模型不需要重建图，只影响回答生成质量。这意味着你可以用 qwen2.5:72b 做一次高质量的知识提取，然后用 3b 模型来低成本日常查询——相当节省算力。
适合谁用
- Obsidian 重度用户：笔记多、关联密，想要跨文件知识问答
- 个人知识库管理者：不愿意把笔记传云端，追求完全离线
- 研究/阅读笔记积累者：大量摘录、读书笔记，需要跨文件回溯
- 对 RAG 感兴趣的开发者：Graph RAG 的落地参考实现
总结
Kwipu 不是又一个向量数据库套 LLM 的玩具。它真正做到了把非结构化 Markdown 笔记转化为有明确图结构的知识库，查询路径更丰富，回答质量更稳定。全本地、MIT 开源、对 Obsidian 零侵入——如果你在找一个认真对待「知识管理」这件事的本地 RAG 工具，Kwipu 值得一试。
