windy/my-vault
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

feat: 整合 LLM Wiki v2 知识管理框架

Browse Source 
- 新增 knowledge-management/ (3页): memory-lifecycle, knowledge-graph, wiki-operations
- 新增 entities/index.md: 实体索引 + Typed Relationships
- SCHEMA.md: 新增 confidence/superset/decay 字段 + 知识管理标签体系
- index.md: Total pages 35→39
- log.md: 完整变更记录
This commit is contained in:
zhiqiang feng
2026-04-13 11:32:34 +08:00
parent 86c6088819
commit 634d8b3406
7 changed files with 861 additions and 28 deletions
Download Patch File Download Diff File Expand all files Collapse all files
airport-wiki/concepts/knowledge-management/knowledge-graph.md
+200
View File
@@ -0,0 +1,200 @@
---
title: 知识图谱
created: 2026-04-13
updated: 2026-04-13
type: concept
tags: [knowledge-management, knowledge-graph, entity, typed-relationship]
sources: [raw/articles/llm-wiki-v2-rohitg00.md]
---
# 知识图谱
## 概述
传统 wiki 是页面的平面集合，通过 wikilinks 连接。规模化后这种模式的局限显现：链接只说"A 与 B 相关"，不说明**如何**相关。知识图谱在页面之外增加结构化关系层，让查询可以从"A 出发，追踪所有依赖 B 的节点"。
本页阐述知识图谱在本 wiki 中的设计与集成方案。
源自 [LLM Wiki v2](https://gist.github.com/rohitg00/2067ab416f7bbe447c1977edaaa681e2)。
## 核心思想
> 页面（pages）用于阅读，图（graph）用于导航和发现。
当用户问"升级 Redis 版本的影响"时：
- **页面搜索**：关键词匹配，返回包含 Redis 的页面
- **图遍历**：从 Redis 节点出发，沿 `depends_on` / `uses` 边向外走，追踪所有下游实体
---
## 实体提取（Entity Extraction）
摄入来源时，提取结构化实体而非仅存储文本。
### 实体类型
| 实体类型 | 示例 |
|----------|------|
| **机场** | 深圳宝安机场、郑州航空港、福州长乐机场 |
| **供应商** | NVIDIA、Vertiv、华为、ADB SAFEGATE、Amadeus |
| **硬件型号** | GB200 NVL72、H100 SXM5、HGX H100 |
| **系统/平台** | AODB、A-CDM、SMGCS、BHS |
| **标准/协议** | NCCL、RDMA、RoCE、Infiniband |
| **项目** | 郑州万卡集群、福州长乐智算中心 |
| **人/组织** | （可选择是否记录）|
### 实体元数据
```yaml
# entities/shenzhen-airport.md frontmatter 扩展
type: entity
entity_type: airport # airport | vendor | hardware | system | standard | project
confidence: 0.95
sources_count: 3
relationships: # 预定义关系（也在页面正文中用 wikilink）
- target: gpu-cluster-shenzhen
type: deploys
confidence: 0.9
- target: nvidia-h100
type: uses
confidence: 0.95
- target: aodb-core
type: operates
confidence: 0.85
```
---
## 类型化关系（Typed Relationships）
Wikilink 只说"A 连接到 B"，Typed Relationship 说明**关系的语义**。
### 预定义关系类型
| 关系类型 | 含义 | 示例 |
|----------|------|------|
| `deploys` | 部署/安装 | 深圳机场 deploys GPU集群 |
| `uses` | 使用（某技术/产品） | 深圳机场 uses NVIDIA GB200 |
| `depends_on` | 依赖 | GPU集群 depends_on 液冷系统 |
| `contradicts` | 矛盾/否定 | 旧方案 contradicts 新方案 |
| `supersedes` | 替代 | GB200 supersedes H100 |
| `caused` | 导致 | 功耗过高 caused 液冷需求 |
| `integrates_with` | 与…集成 | AODB integrates_with A-CDM |
| `competes_with` | 竞争 | Amadeus AODB competes_with ADB SAFEGEGO AODB |
| `part_of` | 属于/组成 | BHS part_of 行李处理系统 |
| `references` | 参考 | 本文 references NVIDIA白皮书 |
### 关系置信度
每条关系独立持有置信度：
> 深圳机场 uses GB200 NVL72，关系置信度 0.9（来源：深圳机场官方报道 + 华为官宣）
---
## 图遍历查询示例
### 示例 1：寻找 GPU 集群依赖
```
问题：郑州航空港 GPU 集群的电力需求是多少？
图遍历路径：
郑州航空港
→ deploys → gpu-cluster-zhengzhou
→ uses → GB200 NVL72
→ power_draw → 查询 power-and-cooling.md
→ depends_on → 液冷系统
→ 答案：NVL72 单卡 1200W，72卡集群 86.4MW（需液冷）
```
### 示例 2：供应商竞争分析
```
问题：ADB SAFEGATE 和 Amadeus 在 AODB 领域有何差异？
图遍历：
ADB SAFEGATE AODB
→ competes_with → Amadeus AODB
→ 两者都 integrate_with → A-CDM
→ 参考 aodb-vendors.md 对比表
```
### 示例 3：故障链追溯
```
问题：机坪 FODS 传感器故障影响了哪些系统？
图遍历：
FODS 传感器
→ feeds → SMGCS
→ feeds → 场面活动管理
→ 间接影响 → 停机位分配（RMS）
→ 快速找到受影响实体
```
---
## 本 Wiki 的实施路径
### 阶段 1：手动标注（当前可行）
在 `entities/` 页面中逐步添加 `relationships` 字段，手动梳理实体间关系。
目标：覆盖核心机场实体和关键供应商关系。
### 阶段 2：自动化关系提取（中期目标）
在 ingestion 流程中增加实体识别步骤：
- 来源文本 → NER 提取实体
- 实体类型分类（机场/供应商/硬件/系统/标准）
- 关系模式匹配（uses/deploys/integrates_with 等）
### 阶段 3：图数据库（远期目标）
当关系数量超过 ~500 条时，考虑引入图数据库：
- **Neo4j**：成熟，支持 Cypher 查询
- **Age**（PostgreSQL 扩展）：与现有工作流更易集成
- 图遍历替代关键词搜索，提升查询质量
---
## 当前实体关系图（示例）
```
┌─────────────────┐
│ 深圳宝安机场 │◄─── deploys ────┐
└────────┬────────┘ │
│ uses │ uses
┌────────▼────────┐ ┌───────▼────────┐
│ NVIDIA GB200 │─────────►│ 华为自研芯片 │
│ NVL72 │ supersedes │
└────────┬────────┘ └────────────────┘
│ power_draw (1200W/GPU)
┌────────▼────────┐
│ 液冷系统 │
│ (PUE < 1.15) │
└────────┬────────┘
│ supports
┌────────▼────────┐
│ 电力供应系统 │
│ (双路 N+1) │
└─────────────────┘
┌─────────────────┐ integrates_with ┌─────────────────┐
│ AODB │◄───────────────────────────►│ A-CDM │
│ (ADB SAFEGEGO) │ │ │
└────────┬────────┘ └────────┬────────┘
│ competes_with │
│ │ feeds
┌────────▼────────┐ ┌────────▼────────┐
│ Amadeus AODB │ │ SMGCS │
└─────────────────┘ └─────────────────┘
```
---
## 相关页面
- [[memory-lifecycle]] — 置信度、superset、遗忘机制
- [[wiki-operations]] — 实体提取的自动化钩子
- [[aodb-vendors]] — 供应商竞争关系的具体例子
- [[gpu-cluster]] — GPU 与其他硬件的关系
- [[power-and-cooling]] — 电力/冷却是 GPU 集群的依赖关系
airport-wiki/concepts/knowledge-management/memory-lifecycle.md
+197
View File
@@ -0,0 +1,197 @@
---
title: 记忆生命周期
created: 2026-04-13
updated: 2026-04-13
type: concept
tags: [knowledge-management, confidence, supersession, forgetting, consolidation-tier]
sources: [raw/articles/llm-wiki-v2-rohitg00.md]
---
# 记忆生命周期
## 概述
Wiki 内容不是平等有效的。原始 LLM Wiki 模式将所有知识视为永久有效，而实践中知识有生命周期。本页阐述四层生命周期管理机制，让 wiki 从"平等声明的平面集合"变为"可判断置信度的动态模型"。
源自 [LLM Wiki v2](https://gist.github.com/rohitg00/2067ab416f7bbe447c1977edaaa681e2)（agentmemory 项目实战经验）。
## 置信度评分（Confidence Scoring）
每条 wiki 事实应携带置信度分数，声明其可靠性。
### 评分维度
| 维度 | 说明 |
|------|------|
| **来源数量** | 有多少独立来源支持该声明 |
| **时效性** | 最近一次确认的时间 |
| **矛盾检测** | 是否有其他来源否定该声明 |
### 置信度表示法
在 frontmatter 或行内元数据中标注：
```yaml
confidence: 0.85
sources_count: 2
last_confirmed: 2026-04-01
superseded_by: null
```
**示例：**
> "郑州航空港当前算力 10,000P" — confidence: 0.9（官方新闻稿，2026-03）
> "GB200 NVL72 HBM3e 带宽 16 TB/s" — confidence: 0.95（NVIDIA 官方白皮书）
> "某供应商报价 2026 Q4 交付" — confidence: 0.4（单一非官方来源，未经交叉验证）
### 置信度衰减与强化
- **时间衰减**：事实的置信度随时间自然下降（架构决策衰减慢，bug/价格信息衰减快）
- **强化机制**：新来源确认 → 置信度上升；被新来源否定 → 触发 supersession
衰减率可参考 Ebbinghaus 遗忘曲线模型：
- 首次学习后 24 小时：保留约 40%
- 1 周后：保留约 25%
- 每个"访问/确认"事件重置衰减时钟
**实践建议：**
- `confidence > 0.8`：稳定知识，优先检索
- `confidence 0.5–0.8`：参考知识，标注不确定性
- `confidence < 0.5`：草稿或待验证，不用于关键结论
---
## 替代机制（Supersession）
当新信息推翻或更新现有声明时，使用 supersession 而非静默覆盖。
### 规则
1. 旧版本**不删除**，保留完整内容
2. 旧版本 frontmatter 标记 `superseded_by: [new-page-name]`，`superseded_date: YYYY-MM-DD`
3. 新版本 frontmatter 记录 `supersedes: [old-page-name]`，`supersedes_date: YYYY-MM-DD`
4. 旧页面添加 `status: stale` 标签，归档到 `_archive/`
### 示例
**旧版本（归档）：**
```yaml
---
title: 福州长乐机场智算中心
created: 2026-01-22
updated: 2026-01-22
status: stale
superseded_by: fuzhou-changle-airport-bsj
superseded_date: 2026-04-13
confidence: 0.7
---
# 福州长乐机场智算中心（已过时）
原报道：2026 年 Q4 投产，投资 11 亿元。
（此版本已被新版本替代，内容已更新）
```
**新版本：**
```yaml
---
title: 福州长乐机场智算中心
created: 2026-01-22
updated: 2026-04-13
type: entity
supersedes: _archive/fuzhou-changle-airport-old
supersedes_date: 2026-04-13
confidence: 0.9
sources_count: 3
---
```
### 触发条件
- 同一实体的新来源比旧来源更权威或更新
- 供应商方案更新、型号参数变化
- 项目时间节点变化（如投产日期推迟）
---
## 遗忘机制（Forgetting）
Wiki 不应该记住所有事情。没有遗忘机制的 wiki 会变得嘈杂，降低检索效率。
### 保留策略
| 知识类型 | 衰减速度 | 说明 |
|----------|----------|------|
| 架构决策 | 极慢 | 长期有效，少量衰减 |
| 硬件规格 | 慢 | 以年计，需等新一代产品 |
| 供应商方案 | 中 | 以季度计 |
| 项目进度/节点 | 快 | 月度变化，不重要后快速衰减 |
| Bug/问题记录 | 最快 | 解决后快速降权 |
### 实践方式
- **软删除**：不真正删除，frontmatter 标记 `status: dormant`
- **降权**：降低 `confidence`，不用于主要结论
- **归档转移**：移动至 `_archive/`，不纳入主要检索
### Ebbinghaus 遗忘曲线应用
- 每次**访问**或**来源确认**事件重置衰减时钟
- 长期未访问的事实自动降权
- `log.md` 中的历史记录本身也是一种衰减信号
---
## 整合层次（Consolidation Tiers）
原始观察需要经过管道处理才能成为可靠知识。建立以下层次：
| 层次 | 名称 | 内容 | 特征 |
|------|------|------|------|
| Tier 0 | **Working Memory** | 最近一次会话的观察，尚未处理 | 存于 session 上下文，不持久化 |
| Tier 1 | **Episodic Memory** | 会话摘要，从 raw sources 压缩而来 | `log.md` 中的 session 条目 |
| Tier 2 | **Semantic Memory** | 跨会话事实，从 episodes 整合 | `concepts/` 和 `entities/` 中的稳定页面 |
| Tier 3 | **Procedural Memory** | 工作流和模式，从重复的 semantics 提取 | `SCHEMA.md`、操作规程、schema |
### 升级规则
- **Working → Episodic**：session 结束时自动压缩为 `log.md` 条目
- **Episodic → Semantic**：同一实体/概念出现 2+ 次后，创建或更新 `entities/`/`concepts/` 页面
- **Semantic → Procedural**：跨 wiki 的模式被识别后，更新 `SCHEMA.md`
### 本 wiki 中的对应关系
```
Session / Chat
↓ session end
log.md (Episodic Memory — session summaries)
↓ 2+ mentions / important update
concepts/ entities/ (Semantic Memory — cross-session facts)
↓ schema-level pattern recognized
SCHEMA.md (Procedural Memory — workflows and conventions)
```
---
## 与现有 Wiki 的集成
### 当前缺口
1. `entities/` 目前只有 7 个机场实体，**无置信度字段**
2. `concepts/` 页面无 `confidence` / `superseded_by` / `status` 标记
3. `log.md` 是 episodic layer，但**未向上整合到 semantic memory**
4. 无 supersession 机制，旧版本被静默覆盖
### 近期改进
- [ ] 为所有 `entities/` 页面添加 `confidence` 和 `sources_count` 字段
- [ ] 建立 `_archive/` 目录，存放被 supersede 的旧版本
- [ ] 制定 wiki auto-lint 脚本，自动检测矛盾并触发 supersession
- [ ] 评估是否引入 `status: stale` / `status: dormant` 标记
---
## 相关页面
- [[knowledge-graph]] — 超越平面页面的结构化知识表示
- [[wiki-operations]] — ingest/query/lint 操作的自动化钩子
- [[glossary]] — 术语表（其中包含 confidence 相关的量化指标）
airport-wiki/concepts/knowledge-management/wiki-operations.md
+186
View File
@@ -0,0 +1,186 @@
---
title: Wiki 操作与自动化
created: 2026-04-13
updated: 2026-04-13
type: concept
tags: [knowledge-management, automation, ingestion, lint, event-hooks]
sources: [raw/articles/llm-wiki-v2-rohitg00.md]
---
# Wiki 操作与自动化
## 概述
原始 LLM Wiki 定义了三个基础操作：ingest（摄入）、query（查询）、lint（清理）。在规模化运营中，这三个操作需要扩展为事件驱动架构：每个事件类型触发预定义的自动化钩子，人只做 curation，bookkeeping 全自动化。
本页描述扩展后的操作模型及其在本 wiki 中的实践。
源自 [LLM Wiki v2](https://gist.github.com/rohitg00/2067ab416f7bbe447c1977edaaa681e2)。
---
## 三层操作模型
### Layer 1：原始来源层（Raw Sources）
`raw/` 目录，保存未处理的原始文档：
- 新闻报道、白皮书、官方文档
- 每次摄入注明来源、日期、URL
### Layer 2：Wiki 层（Semantic Memory）
`concepts/`、`entities/`、`comparisons/` 中的页面：
- 经过处理的结构化知识
- 从 raw sources 提取、整合、标注关系
### Layer 3：Schema 层（Procedural Memory）
`SCHEMA.md` 和 `log.md`：
- 元知识、工作流、命名规范
- 从 wiki 操作中积累的模式
---
## 事件钩子（Event Hooks）
### 标准钩子矩阵
| 事件 | 自动触发动作 |
|------|-------------|
| **On new source** | 存档至 `raw/` → 运行 entity extraction → 更新 `entities/index.md` → 检查 supersession → 更新 index.md |
| **On session start** | 根据最近 `log.md` 条目加载相关上下文 |
| **On session end** | 将会话压缩为 episodic 条目写入 `log.md` |
| **On query** | 检索时检查答案是否值得写回 wiki（quality score > threshold） |
| **On memory write** | 检查矛盾，触发 supersession，更新 confidence |
| **On schedule**（定时） | 全量 lint、consolidation tier 检查、confidence decay、遗忘处理 |
### On New Source — 完整流程
```
收到新来源（用户提供 URL / Gist / 文件）
↓
1. 下载并保存至 raw/articles/[slug]-[date].md
↓
2. 自动 entity extraction
- 识别：机场名、供应商、硬件型号、系统名
- 提取 Typed Relationships
- 分配 confidence 初值（来源权威性 × 时效性）
↓
3. 矛盾检测
- 与现有 entities 比较
- 若发现矛盾 → 触发 supersession 流程
- 旧版本 → _archive/，标记 status: stale
↓
4. 更新目录
- 新增 entities → entities/index.md
- 新增 concepts → index.md 对应 section
- 更新 log.md
↓
5. 通知（如有重大矛盾）
- 标记待用户审核
```
### On Session End — 压缩流程
```
会话结束信号
↓
1. 提取本次会话的关键结论
- "新了解到 …"
- "已验证 …"
- "仍有疑问 …"
↓
2. 写入 log.md（Episodic Memory）
条目格式：
- 日期 + session id
- 来源：本次对话
- 新知识：<压缩后的结论>
- 开放问题：<下次需验证>
↓
3. 评估是否升级至 Semantic Memory
- 同一实体在 2+ session 中出现？
- 是 → 创建/更新 entities/ 或 concepts/ 页面
```
### On Schedule — 定期维护
```
每日/每周定时任务
↓
1. Confidence decay
- 所有 entities/concepts 按时间衰减
- 衰减率：架构决策 0.1%/月，供应商信息 1%/月，进度信息 5%/月
↓
2. Orphan check
- 没有入站链接的页面 → 标记 review
- 入站链接多但内容少的"薄页" → 合并或扩展
↓
3. Broken link scan
- 检查所有 wikilink 有效性
- 检查所有 raw source 文件是否存在
↓
4. Supersession review
- 标记为 stale > 3 个月且无访问 → 移至 _archive/
```
---
## 自动化实现方案
### 当前状态 vs 目标状态
| 操作 | 当前（手动） | 目标（自动） |
|------|-------------|-------------|
| 来源摄入 | 用户触发 | On new source hook |
| Session 摘要 | 无 | On session end → log.md |
| 矛盾检测 | 无 | On memory write → supersession |
| 定期 lint | 偶尔手动 | On schedule cron |
| 置信度衰减 | 无 | On schedule cron |
### 近期可实现步骤
1. **会话结束自动写 log**
- 在 `hermes-agent` 中增加 post-session hook
- 自动压缩本次对话结论写入 `log.md`
2. **建立 supersession 工作流**
- ingestion 时检测矛盾
- 自动创建旧版本 archive + 链接新版本
3. **Cron 定期 lint**
- 使用 `hermes cron` 每日运行 lint 脚本
- 检测断链、orphaned pages、confidence decay
### 实施优先级
1. **P0（立即）**：建立 `_archive/` 目录 + supersession 流程
2. **P1（本周）**：entity extraction 脚本（基于正则/NER）
3. **P2（本月）**：session end hook → log.md
4. **P3（下月）**：定时 cron lint + confidence decay
---
## 质量评分（Quality Scoring）
每次 LLM 生成内容时，给出质量分数：
| 分数 | 含义 | 行动 |
|------|------|------|
| `quality > 0.9` | 高质量，直接写入 wiki | 自动写入 |
| `quality 0.7–0.9` | 可接受，需人工审核 | 写入草稿，待 review |
| `quality < 0.7` | 低质量，不写入 | 记录但不持久化 |
**质量维度：**
- 结构化程度（是否遵循 frontmatter 规范）
- 来源引用（是否有 `sources` 字段）
- wikilink 密度（是否有足够的交叉引用）
- 长度合理性（不过短/不过长）
- 事实一致性（与已知知识不矛盾）
---
## 相关页面
- [[memory-lifecycle]] — confidence scoring、supersession、forgetting 机制
- [[knowledge-graph]] — entity extraction、typed relationships
- [[SCHEMA]] — wiki 结构规范（Procedural Memory）