114 lines
6.8 KiB
Markdown
114 lines
6.8 KiB
Markdown
# 用 AI 把零散资料变成可复用的知识库 —— llm-wiki-sync 的实现与示例解析
|
||
|
||
**副标题**：如何把 raw/ 里的每一份素材，通过 llm-wiki-sync 自动分析与提炼成结构化的 source 页面、实体与概念，以便长期检索与复用。
|
||
|
||
---
|
||
|
||
## 前言与来源说明
|
||
|
||
本方案借鉴并整合了几条重要线索：
|
||
- Andrej Karpathy 对“LLM Wiki”理念的阐述（将知识以可被大模型直接消费的结构化方式保存）：https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
|
||
- 我们的实现基于开源项目 SamurAI 的 llm-wiki-agent（https://github.com/SamurAIGPT/llm-wiki-agent），在其基础上扩展了企业化的 ingest 流程、Cron 调度与 Hermes skill（llm-wiki-sync）。
|
||
- 最终静态化展示使用 Quartz（https://github.com/jackyzha0/quartz），把生成的 wiki 内容导出为可浏览、可分享的静态站点。
|
||
|
||
下面重点介绍 llm-wiki-sync 如何把一篇笔记做结构化分析与提炼，并用仓库中的实例（wiki/sources/RTO-vs-RPO-Key-Differences-for-Modern-Disaster-Recovery）作为逐项说明。
|
||
|
||
---
|
||
|
||
## llm-wiki-sync 的目标与核心能力
|
||
|
||
核心目标：把原始文档（raw/）自动转成结构化的 wiki source 页面，抽取关键要素（Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections），并记录 ingest 日志、差异与审计信息，供后续检索、合成与内容再生产使用。
|
||
|
||
关键能力：
|
||
- 文本解析与语义压缩：把长文本压缩为 2–4 句高密度 summary。
|
||
- 声明抽取（claim extraction）：识别文中明确的结论与可验证断言。
|
||
- 实体与概念抽取（NER + linking）：识别人名/公司/工具/概念，并把它们标准化为 wiki 实体页（[[Name]]）。
|
||
- 关系发现（connections）：把句子级别的语义关系转成图边（A → depends_on → B）。
|
||
- 模板化输出：固定页面头（frontmatter）+ 标准段落（Summary / Key Claims / Quotes / Concepts / Entities / Connections / Contradictions）。
|
||
- 审计与可回滚：每次 ingest 都写入 wiki/log.md，并可通过 git/checkpoint 回滚变更。
|
||
|
||
实现技术栈要点：Hermes（skill 调用）、Claude Code / agent（可选）、llm-wiki-agent 基础脚本、以及最终的静态化工具 Quartz。
|
||
|
||
---
|
||
|
||
## 从笔记到 Source Page：以 RTO vs RPO 为例
|
||
|
||
仓库中的源页面：wiki/sources/RTO-vs-RPO-Key-Differences-for-Modern-Disaster-Recovery.md
|
||
|
||
下面逐项展示 llm-wiki-sync 针对该文档所做的提取结果（摘自生成的 source 页面）：
|
||
|
||
1) Summary（Summary）
|
||
- 核心主题：RTO（恢复时间目标）与 RPO（恢复点目标）的定义、区别及在现代持续交付中的应用
|
||
- 问题域：灾难恢复规划、发布风险管控
|
||
- 方法/机制：通过 Feature Flag 实现秒级 RTO 和低 RPO
|
||
- 结论/价值：预防优于恢复，Feature Flag 将部署事故从灾难转为非事件
|
||
|
||
说明：Summary 由模型将整篇文章的主旨、问题背景、关键方法与结论压缩为 2–4 条，便于快速检索与索引。
|
||
|
||
2) Key Claims（断言提取）
|
||
- RTO 衡量系统恢复速度：允许的最大停机时间
|
||
- RPO 衡量数据保护：可接受的最大数据丢失量
|
||
- 传统灾备聚焦硬件故障，现代风险更多来自代码变更（部署 bug、数据库迁移、AI 模型更新等）
|
||
- Feature Flag 将 RTO 从小时级降至秒级，同时保护 RPO
|
||
- 应用分层策略（Critical / Important / Nice-to-have）对应不同的 RTO/RPO 指标
|
||
|
||
说明：断言提取用于建立事实层（fact layer），后续可自动化做一致性检查与冲突检测（Contradictions 段）。
|
||
|
||
3) Key Quotes（关键引用）
|
||
- “RTO is about speed: how fast you get back online. RPO is about data: how much you can afford to lose.”
|
||
- “Deploy != Release. Feature flags change this. You can deploy code to production without releasing it to users.”
|
||
|
||
说明：保留可引用原句，便于在后续合成（如写作、演讲稿）中引用来源。
|
||
|
||
4) Key Concepts（概念抽取）
|
||
- RTO（Recovery Time Objective）
|
||
- RPO（Recovery Point Objective）
|
||
- Feature Flag（特性开关）
|
||
- Kill Switch（紧急关闭机制）
|
||
- 渐进式发布（Gradual Rollout）
|
||
|
||
说明：概念会被标准化为 wiki 的 concept 页面（wiki/concepts/），用于聚合所有提到该概念的 source 页面。
|
||
|
||
5) Key Entities（实体抽取）
|
||
- LaunchDarkly（Feature Flag 管理平台）
|
||
- HP（示例企业）
|
||
- Christian Dior（示例企业 — 文档中作为案例提及）
|
||
|
||
说明：实体会被规范化为 wiki/entities/ 下的页面，并且 source 页面会在 sources 列表保留原始链接与引用。
|
||
|
||
6) Connections（关系构建）
|
||
- RTO ← depends_on ← Feature Flag
|
||
- RPO ← depends_on ← Feature Flag
|
||
- LaunchDarkly → provides → Feature Flag
|
||
- Feature Flag ← enables ← 渐进式发布
|
||
|
||
说明：Connections 用于图谱构建（graph/graph.json），后续能在可视化页面（graph.html）展示节点与边。
|
||
|
||
7) Contradictions（冲突检测）
|
||
- 当前文档无明显与现有 wiki 冲突的声明；若检测到冲突，llm-wiki-sync 会把冲突条目列出并标注来源，供人工审查。
|
||
|
||
---
|
||
|
||
## llm-wiki-sync 的典型运行步骤（工程视角）
|
||
|
||
1. 读取 raw/<path>，解析 frontmatter/元数据（若缺失则询回填）。
|
||
2. 检索 wiki/index.md 与 overview.md，获取上下文（避免重复 ingest）。
|
||
3. 用 LLM 生成 Source Page（Summary / Key Claims / Quotes / Concepts / Entities / Connections / Contradictions）。
|
||
4. 将结果写入 wiki/sources/<slug>.md，并更新 wiki/index.md、wiki/overview.md；如有新实体/概念也生成对应页面草稿。
|
||
5. 记录日志：在 wiki/log.md 追加 ingest 记录（时间、文件、摘要、状态）。
|
||
6. 可选：触发 graph 重建（增量或全量），并把 graph/graph.json、graph.html 更新到站点。
|
||
7. 通知：完成后通过 Hermes 的通知机制（deliver=origin 或 Telegram 指定 chat）告知负责人。
|
||
|
||
并发与配额注意：单文件 ingest 优先，批量操作分批（每批 3–10 篇）；对接外部 agent/Claude Code 时避免并发超配额。
|
||
|
||
审计与回滚：每次 ingest 前执行 git branch 或 checkpoint；如需回滚，可用 git revert 或恢复 checkpoint。
|
||
|
||
---
|
||
|
||
## 总结与扩展
|
||
|
||
- llm-wiki-sync 把 Karpathy 关于 LLM Wiki 的理念落地为可执行的工程流程：把知识以结构化表征保存，使得大模型既是“读者”也是“执行者”。
|
||
- 我们的实现基于 SamurAI 的 llm-wiki-agent，并在其上加入了企业级的同步、审计与 Hermes skill 封装，最终通过 Quartz 静态站把生成的 wiki 内容对外展示与分享。
|
||
|
||
如果你想，我可以把上面 RTO vs RPO 的 source 页面再跑一遍演示：展示原始 raw 文件、模型的中间输出（提取断言、实体的置信度、连接候选），以及最终写入 wiki 的 diff。要我现在生成演示输出吗？
|