Yin 的小站

知识图谱：从 3 条边到 15955 条边

2026-10-21T02:00:00.000Z

起点：一个装饰性图谱

我的知识库门户里一直有个”图谱”页面：力导向布局、节点按来源着色、能拖拽缩放。
看起来很像回事。

直到我看了一眼数据：

nodes=1104  links=3

1104 个节点，3 条边。 边全部来自正文里的 [[双链]]，而我几乎不写双链。
这个页面唯一的用途是截图好看。

为什么不直接用 LLM 抽

2026 年这个方向最热的是 GraphRAG（微软）和 LightRAG（港大），
它们的做法都是：用 LLM 从文本里抽实体和关系。

我想过，但算了三笔账：

额度：免费 10,000 neurons/天。用 LLM 抽 1187 篇文档，一次就可能吃掉大半，
而且抽取质量不稳定，重跑一次结果就变；
可复现：规范判定要求”同输入同输出”。LLM 抽出来的图，今天和明天不一样，
基于它做的判定就没法解释；
可维护：词表写错了，我能定位到具体词条；模型抽错了，我只能”再抽一次看看”。

所以我选了确定性路线：结构化事实优先，LLM 留到以后按需补充。

三层抽取

层	来源	产出	覆盖率
L0 结构事实	路径、front-matter	文档→目录/来源/设备/标签	100%
L1 显式链接	`[[双链]]`、Markdown 相对链接	文档→文档	约 1250 条
L2 词典实体	内置词表 + 正则	文档→实体	约 540 条

L0 是覆盖率的关键：每篇文档都”属于”某个目录、来自某个工具、在某台设备上。
这些关系不需要”理解”，只需要解析。先把确定的东西全拿到，再谈语义。

最终：

nodes=1649  edges=15955
belongs_to 9875  tagged 1907  mdlink 1248
from_source 1187  on_device 1187  mentions 539

三个必须处理的坑

坑 1：枢纽节点会毁掉可视化

device 和 source 这两个节点几乎连到所有文档。从任意文档出发走两跳：

文档 → 设备 → 另外 295 篇文档

图上一秒变毛线球。解法是展示但不穿透：枢纽类节点画出来，但不再从它继续扩展；
再加单层 60 个节点的上限。

坑 2：伪双链

正文里的 Markdown 示例会被误当成真链接：

比如可以写 [[{ "tag": "md", "text": "..." }]]

原来的 31 条”断链”里，有 24 条是这种噪声。加了一条过滤规则
（长度、非法字符、协议前缀）后剩 7 条真实断链。

坑 3：中文分词

FTS5 用 unicode61，会把一整串中文当成一个 token。
所以「索引管线怎么分批嵌入」这种整句查询，MATCH 命中是 0，LIKE 兜底也难。
短期靠”查两个关键词”，中期要接 jieba 预分词。

规范判定：让规则可写、可复现

规则放在内容仓的 policy/rules/*.yaml，和笔记一起版本化：

- id: fm.required
  name: front-matter 必填字段
  kind: front_matter
  severity: error
  params:
    required: ["title", "source"]

关键设计是 kind 是封闭枚举，YAML 只传参数、不写 SQL。
内容仓是可写的（笔记软件、网页、客户端都能改），如果规则里能塞 SQL，
等于给内容仓开了一个注入面。

结果

1187 篇 × 13 条规则 → 2068 条判定记录
违规 881 条：warn 125 + info 756，error 0
按规则：doc.orphan 756 / title.dup 107 / naming.no_space 11 / 断链 7

error = 0 说明敏感信息扫描（私钥、API Key）在内容仓里零命中——这是我最想看到的结果。

至于那 756 条”孤立文档”：它们全是机器导入的会话记录，本来就没有入链。
规则的意义不是消灭数字，而是让数字可解释。

还没做的

传递闭包目前只到 10 轮，复杂层级还没压测；
图谱的社区聚类（Leiden）没做——要做也打算用纯 TS，不调 LLM；
增量判定：现在每次全量重算，规模再大就得改。

下一步如果做，我会先做增量，而不是做更花哨的图算法。
因为真实使用中，”改一篇笔记后多久能看到判定更新”比”图好看不好看”重要得多。

用 Cloudflare 免费额度搭一套私有知识库

2026-10-20T02:00:00.000Z

架构一览

Markdown 仓库（私有）
   │ git push
   ▼
GitHub Actions  ── 抽取/切分/嵌入/判定 ──▶ Cloudflare
                                            ├─ D1（文档、切片、三元组、判定）
                                            ├─ Workers KV（索引产物）
                                            ├─ Vectorize（语义向量）
                                            └─ Worker（查询 API）
                                                   ▲
                                     Pages + Access（只给自己看）

选这套的原因很朴素：没有一个组件需要常驻服务器。
Neo4j、OpenSPG 这类图数据库确实更强，但要一台机器一直开着，就不符合”零成本”。

四个撞过的硬限制

1. 嵌入请求有 6 万 token 的总上限

第一次跑索引，第一批就 400：

AiError: Max context reached 99392 tokens but model supports only 60000

原因是按固定 64 条一批，而中文分片每片接近 900 token，64 × 900 直接顶破。
改成按估算 token 预算动态分批，并对单条做字符上限保护；仍失败就二分重试。

2. KV 的单键上限是 25 MiB

索引产物里有一份 embeddings.jsonl，88 MB，PUT 直接 413：

content size of 87905171 bytes exceeds maximum allowed size of 27MiB

后来发现这个键运行时根本没人读——向量在 Vectorize 里，Worker 只读
docs.json 和 meta.json。删掉即可。先查清楚谁在读，再决定怎么存。

3. D1 单条语句的绑定参数有上限

想在一条 SQL 里从 300 个节点取边：

WHERE e.src IN (?,?,...) OR e.dst IN (?,?,...)   -- 600 个参数

直接 500。官方文档没写这个数，实测大约 100。改成拆两条 SQL、每批 50 个 id，
再用 id 去重合并。

4. 免费神经元额度是 10,000/天

全量重建一次约 3000 neurons（4290 片 × 约 700 token），
所以一天最多重建三次。这直接决定了：增量索引不是”优化”，是”必需”。

一个反直觉的设计：判定放在离线

一开始我想把规则引擎放进 Worker，请求时现算。算了一下：1187 篇 × 13 条规则 ≈ 1.5 万条判定，
而 Workers 免费档单请求 CPU 只有 10 ms——跑不完，也写不完。

于是把判定挪到管线里离线跑（一次约 3 秒），Worker 只做”读”。
副产品是：判定结果成了可查看的历史快照，而不是每次请求都变的临时值。

代价与收益

项	结果
月成本	0 元
全量索引耗时	约 4 分钟（Actions）
查询延迟	毫秒级（D1 / KV 命中）
规模上限	Vectorize 5M 维度，当前已用 87.8%

最后一行是唯一的隐患：知识库再涨约 14%，语义检索就会超限。
到那天的退路已经想好了——降级成纯关键词检索，功能不崩，只是没那么”聪明”。

小结

免费额度的真正价值不是”省钱”，而是逼你把架构想清楚：
不能堆组件，就得想清楚每一层到底在解决什么问题。
这套系统里，真正不可替代的只有两件事——分片策略和规则。
其余的，都是可以替换的实现细节。

为什么我要做一个自己的知识库

2026-10-18T02:00:00.000Z

起因

我的笔记散在四个地方：Obsidian 里一部分、几个 AI 工具的会话记录里一部分、浏览器书签里一部分、
还有一部分在「等我有空再整理」的文件夹里。

结果是：收藏越多，越找不到。

真正让我下决心的是一个很具体的问题——我想找半年前写过的一段
「Cloudflare Workers 怎么复用连接」的笔记，翻了三个 App 都没找到。
那一刻我意识到，我缺的不是存储，是检索和结构。

我想要的到底是什么

我把需求写成了四条，后来整个系统都是围绕这四条长出来的：

一个地方：所有笔记最终汇到一个仓库，不管原来在哪；
搜得到：关键词能搜，语义也能搜；
看得见关系：这篇笔记和哪些文档有关，为什么有关；
判得准：我的知识库有没有违反自己定的规范（缺元数据、断链、过期、含密钥）。

第 4 条听起来最玄，其实是最后落地时最有用的一条——见下面。

为什么不用现成的

我试过几个方向：

云笔记 + 全平台同步：同步没问题，但检索只有关键词，没有关系；
现成的 RAG 工具：能问答，但索引是黑盒，我改不了它的分片策略；
笔记软件自带的图谱：好看，但只是”双链的可视化”，不是可计算的图。

共同的问题是：它们不让我碰索引。

而知识库的价值恰恰在索引层——分片怎么切、实体怎么抽、规则怎么判。
所以我决定自己写一个，只在索引层花功夫，其他都尽量简单。

最后的形态

存储：Markdown 仓库（GitHub 私有仓），跨设备靠 git 同步；
索引：GitHub Actions 里跑，产出切片、向量、三元组、判定结果；
查询：Cloudflare Worker + D1 + Vectorize，全部落在免费额度内；
入口：一个网页门户 + 一个桌面客户端 + 一套 MCP 工具。

关键取舍是：不绑卡。所以没有用 R2，索引产物直接写 Workers KV，
原文由 Worker 通过 GitHub API 直读。

第 4 条需求意外地有用

我原本以为”规范判定”是个锦上添花的功能，直到它第一次跑出结果：

warn  标题重复    knowledge/memory/dsh/profiles/desktop/cordis.yml
      与 1 篇文档同名，容易混淆
warn  双链断链    31 处 → 过滤掉代码示例里的伪链接后剩 7 处
info  孤立文档    756 篇没有入链

756 这个数字很刺眼，但它是对的：那批文档是机器导入的会话记录，本来就没有入链。
规则的价值不是”发现问题”，而是”让问题可度量”。有了度量，才知道先修什么。

下一步

语义检索和关系图谱已经能用了，但我还想加两件：

中文分词后再进全文索引（现在 unicode61 会把整句中文当成一个 token）；
增量索引（现在每次全量重建都吃一次嵌入额度）。

这两件事都不难，难的是别把系统搞复杂。这个博客大概会记录它们。