Files
llm_wiki/wiki/LLM-Wiki-v2.md
T
giteahh e8c22a4794 feat(wiki): 摄入历史性新机遇分析框架 + 静能量章节扩展 + frontmatter 验证工具增强
- 新增 wiki/历史性新机遇分析框架.md — 大镇乡谈政策分析框架(一目标一核心两支柱三周期)
- 更新 
aw/呸未然_静能量/ — 摄入 6 个章节内容(盘坐、正身、正言、正行、止念、业力)
- 新增/更新 wiki/静能量.md、wiki/佛家修行.md — 概念页扩展
- 优化 	ools/scripts/validate-frontmatter.py:
  * 支持根目录 .md 文件(如 AGENTS.md)的 wiki 专用检查
  * relations 目标存在性检查扩展到整个 vault(不限于 wiki/)
  * 添加 is_wiki_file() 判断,避免对非 wiki 文件误报
- 更新 wiki/LLM-Wiki-v2.md — 删除冗余 relation,修正 SCHEMA→AGENTS
- 更新 wiki/index.md — 页面数统计(505→506)
- 追加 wiki/log.md — ingest 记录
2026-07-03 09:39:55 +08:00

354 lines
11 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
---
categories:
- '[[LLM Wiki]]'
tags:
- wiki
- concept
- concept/technology
- LLM
- Wiki
- 知识管理
- 记忆系统
- 知识图谱
- 开源
- agentmemory
created: '2026-04-14'
source: https://gist.github.com/rohitg00/2067ab416f7bbe447c1977edaaa681e2
type: concept
aliases:
- LLM Wiki v2
confidence: 3
status: active
last_reviewed: '2026-07-01'
review_interval_days: 180
relations:
- type: extends
target: '[[涌现]]'
confidence: 2
- type: extends
target: '[[以终为始]]'
confidence: 2
- type: extends
target: '[[新范式]]'
confidence: 2
---
# LLM Wiki v2
## 概述
Rohit Ghumare 基于 **Karpathy** 原始理念开发的升级版本,新增记忆生命周期和知识图谱等功能。
基于 [agentmemory](https://github.com/rohitg00/agentmemory) 项目实践经验总结。
## 核心理念
> **停止重新推导,开始积累编译**
>
> RAG 是检索和遗忘。Wiki 是积累和复合。
>
> The Memex is finally buildable. — *最终,Memex 可以建造了*
## 缺失的层级:记忆生命周期
### 置信度评分 (Confidence Scoring)
每个事实应携带置信度评分:
- 有多少来源支持
- 最近何时被确认
- 是否有矛盾
```
"项目X使用Redis缓存"
→ 来自2个来源
→ 上次确认3周前
→ 置信度 0.85
```
置信度随时间衰减,随确认强化。
### 超替 (Supersession)
新信息与旧信息矛盾时:
- 旧信息不删除,标记为过时
- 新信息显式替代旧信息
- 保留时间戳和关联
### 遗忘 (Forgetting)
非永久保留机制:
- 基于艾宾浩斯遗忘曲线
- 重要但长期未访问的内容逐渐淡化
- 不删除,降级优先权
- 架构决策衰减慢,临时Bug衰减快
### 整合层级 (Consolidation Tiers)
```
原始观察 → 工作记忆 → 情景记忆 → 语义记忆 → 程序记忆
↓ ↓ ↓ ↓ ↓
最新/未处理 单会话摘要 跨会话压缩 跨会话事实 工作流/模式
```
## 超越平面页面:知识图谱
### 实体提取
-ingest 时提取结构化实体:
- 人 (People)
- 项目 (Projects)
- 库 (Libraries)
- 概念 (Concepts)
- 文件 (Files)
- 决策 (Decisions)
### 类型化关系
| 关系类型 | 说明 |
|----------|------|
| uses | 使用 |
| depends on | 依赖 |
| contradicts | 矛盾 |
| caused | 导致 |
| fixed | 修复 |
| supersedes | 替代 |
### 图遍历查询
不同于关键词搜索,从节点向外遍历:
```
Redis → depends on → 下游依赖
→ uses → 使用它的项目
```
## 搜索扩展
### 混合搜索
| 搜索类型 | 能力 |
|----------|------|
| **BM25** | 关键词匹配、词干、同义词扩展 |
| **向量搜索** | 语义相似度 (Embeddings) |
| **图遍历** | 实体感知关系行走 |
融合方式:Reciprocal Rank Fusion (RRF)
## 自动化:事件驱动
| 事件 | 自动执行 |
|------|----------|
| 新来源 | auto-ingest, 提取实体, 更新图谱 |
| 会话开始 | 加载相关上下文 |
| 会话结束 | 压缩为观察, 归档洞察 |
| 查询时 | 检查是否值得归档 (质量分数>阈值) |
| 记忆写入 | 检查矛盾, 触发超替 |
| 定时 | lint, 整合, 遗忘衰减 |
## 质量与自愈
### 评分系统
每个LLM生成的内容都应有质量分数:
- 结构是否良好
- 是否引用来源
- 是否与Wiki其他部分一致
### 自愈 (Self-healing)
Lint操作应自动修复:
- 孤立页面链接或标记
- 陈旧声明标记
- 修复断裂的交叉引用
### 矛盾解决
1. 标记矛盾
2. LLM提议哪个更可能正确(基于来源时效性、权威性、观察数量)
3. 人类可覆盖
## 多智能体与协作
### 网格同步
多智能体并行观察合并:
- Last-write-wins (大多数情况)
- 时间戳解决冲突
- 支持手动覆盖
### 共享 vs 私有
| 类型 | 说明 |
|------|------|
| 私有 | 我的偏好、工作流 |
| 共享 | 项目架构、团队决策 |
### 工作协调
- 谁在做什么
- 什么被阻塞
- 什么完成了
## 隐私与治理
###-ingest 时过滤
自动剥离敏感信息:
- API密钥
- Token
- 密码
- 标记为私有的内容
### 审计追踪
每次操作记录:
- 时间戳
- 变更内容
- 变更原因
## 结晶化 (Crystallization)
将完成的工作链自动提炼为结构化摘要:
```
探索结果 → 问题 → 发现 → 涉及实体 → 教训
```
探索是来源,与文章/论文同等对待。
## 实现光谱
| 层级 | 组件 | 适用规模 |
|------|------|----------|
| **最小可用** | 原始来源 + Wiki页面 + index.md + Schema | ~50页 |
| **+生命周期** | 置信度、超替、基本遗忘 | ~100页 |
| **+结构** | 实体提取、类型关系、知识图谱 | ~200页 |
| **+自动化** | Hooks、自动-ingest、自动lint | ~500页 |
| **+扩展** | 混合搜索、整合层级、质量评分 | 500+页 |
| **+协作** | 网格同步、共享/私有、工作协调 | 多用户 |
## Schema 是真正的产品
**CLAUDE.md / AGENTS.md** 是系统最重要的文件:
- 定义存在的实体和关系类型
- 如何-ingest 不同来源
- 何时创建新页面 vs 更新现有页面
- 应用什么质量标准
- 如何处理矛盾
- 整合计划是什么
- 什么是私有 vs 共享
## 相关链接
| 项目 | 地址 |
| --------------- | ------------------------------------------------------------------------------------------------------------------------------ |
| **LLM Wiki v2** | [gist.github.com/rohitg00](https://gist.github.com/rohitg00/2067ab416f7bbe447c1977edaaa681e2) |
| **Karpathy原始版** | [gist.github.com/karpathy/442a6bf555914893e9891c11519de94f](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f) |
| **agentmemory** | [github.com/rohitg00/agentmemory](https://github.com/rohitg00/agentmemory) |
## 本地研究
学习资料:`~/.openclaw/workspace/llm-wiki-v2-study/README.md`
---
## 家族新成员:Google Open Knowledge Format (OKF)
> **验证日期**2026-06-16
> **结论**:**不投入**。作为导出格式保留,作为生产格式放弃。
### 它是什么
Google 2026-06 发布的开放规范,把 Karpathy LLM Wiki + Rohit v2 的"Markdown + YAML frontmatter + 互相链接"模式抽成正式标准。v0.1 核心:
- 唯一硬性要求:`type` 字段
- 约定字段 6 个:`type` / `title` / `description` / `resource` / `tags` / `timestamp`
- 概念之间用普通 Markdown 链接(不是 `[[wikilink]]`
- 可选 `index.md`(导航)+ `log.md`(变更历史)
- 完整规范一页纸写完
GitHub: `GoogleCloudPlatform/knowledge-catalog/tree/main/okf`
### 真实验证(教育AI研究 corpus)
`/root/.openclaw/workspace/教育AI研究/`121 个 .md)按 OKF 规范导出,10 秒脚本化完成,121/121 满足硬性要求。但暴露 7 个 friction
1. **type 命名空间碎片化** — 49 个无 frontmatter 文件需要重写,OKF 不约束
2. **wikilink 不会自动变 Markdown link** — 61 个内部链接需手工翻译
3. **自定义字段(你用 20+ 字段)超出 OKF 6 字段** — 跨厂商只 `tags` 真互操作
4. **`resource` 字段对研究型语料语义模糊** — OKF 假设指向 DB/API 链接
5. **tag 表述不统一**`LLM` / `大语言模型` / `生成式AI教育` 三个 tag 指同一概念
6. **`log.md` 完全可选** — 你的 `outputs/` 时间序列报告对 consumer 是黑盒
7. **40% 文件无 frontmatter** — OKF 之外的 tool 拿不到元数据
### 与现有体系的关系
| 维度 | 你的 LLM Wiki v2 | OKF |
|------|------------------|-----|
| frontmatter 字段 | 20+ 自定义 | 6 个约定(可扩展) |
| 链接语法 | `[[wikilink]]` Obsidian 风格 | 普通 Markdown |
| 互操作 | 自给自足 | 跨厂商设计 |
| 演化速度 | 个人决定 | 慢(一旦标准化) |
| type 系统 | 无强制 | 强制但自定义空间大 |
### 不投入的理由
- **生产层没有迁移收益**。你现有 Obsidian 风格 + 自定义 frontmatter 体系已经能跑
- **导出层有保留价值**。需要给外部 consumer 时,OKF 是个体面的交付物形态
- **Google 立场可疑**。"中立"是策略不是信仰,参考实现全部跑在 GCP 上
- **type 命名空间是规范层隐患**。OKF 文章刻意回避,落到具体语料立刻显形
### 何时重评
以下任一信号出现,重启这条线:
- Google/Cloud 之外出现独立的 OKF type 字典
- 有外部组织真正要求你交付 OKF 格式
- OKF v0.2 / v1.0 解决 type 命名空间问题
- 你开始"对外交付"知识(不是给 agent 内用,而是给合作机构/公众)
验证产物保留:
- Bundle`/root/教育AI研究_okf/`30MB
- 脚本:`/tmp/build_okf.py`(可重跑)
---
*最后更新:2026-06-30(追加"4 级记忆在老何 wiki 落地"章节 + frontmatter 修正)*
## 4 级记忆架构在老何 wiki 的落地(2026-06-30
> **背景**2026-06-30 老何在 [[AGENTS]] 重构时,把 LLM Wiki v2 文档里的"整合层级 (Consolidation Tiers)" — 原始观察 → 工作记忆 → 情景记忆 → 语义记忆 → 程序记忆 — **正式落地为 vault 目录结构**。
### AGENTS 里的 5 层映射
| LLM Wiki v2 概念 | 老何 wiki 目录 | 关键特征 |
|----------------|--------------|---------|
| **Working Memory**(原始观察) | `raw/` | 不可变输入(HTML/PDF/转录) |
| **Working Memory**AI 可读提炼) | `sources/` | AI 摘要版本 |
| **Episodic Memory** | `Daily/` | 每日笔记 + Dataview 视图 |
| **Semantic Memory** | `concepts/` `entities/` `syntheses/` | 概念、实体、综合报告 |
| **Procedural Memory** | `AGENTS.md` `log.md` `scripts/` | 规则、流程、工具 |
| **自动生成** | `reports/` `_openclaw/` | 系统诊断 + agent 缓存 |
### 与原 LLM Wiki v2 设计的差异
| 维度 | LLM Wiki v2 原始设计 | 老何 wiki 实际落地 |
|------|-------------------|------------------|
| 记忆层级数 | 5 层 | 5 层 + 1 个自动生成层 |
| 工作记忆命名 | Working Memory | 拆成 `raw/`(不可变)+ `sources/`(可编辑提炼) |
| 程序记忆 | 不强调 | 4 个固定文件(AGENTS/SCHEMA/log/scripts)显式建模 |
| 写入分区 | 单端 | 双端(PC + 腾讯云),按目录分区 |
| 同步机制 | 不强调 | Gitea 双端同步(详见 wiki-gitea-sync skill |
### 实际跑过的验证
2026-06-30 修复 wiki ↔ Gitea 同步时,本文档被作为"4 级记忆架构"的活样本使用:
- **Working Memory 层**`raw/articles/` 接收老何下载的讲座转录、HTML 原文
- **Episodic Memory 层**`Daily/2026-06-30.md` 记录当天会话事件流
- **Semantic Memory 层**:本文档(`concepts/LLM-Wiki-v2.md`)作为概念层锚点
- **Procedural Memory 层**`AGENTS.md` 第 §五节编码了本文档里的 Consolidation Tiers 思想
- **自动生成层**`_openclaw/sync-events.jsonl` 记录 14 条维护事件,机器可读
### 与 [[以终为始]] 的关系
[[以终为始]] 是习惯七律的第一条——先定终态再行动。本文是"终态是什么"的元描述:当习惯 → 流程 → 工具 → 目录都按 4 级记忆架构搭建,[[以终为始]] 才有了具体的承载结构。