114 lines
6.4 KiB
Markdown
114 lines
6.4 KiB
Markdown
---
|
|
title: "LLM Wiki 的实现模式"
|
|
type: concept
|
|
confidence: medium
|
|
source: "nashsu/llm_wiki README"
|
|
raw_sources:
|
|
- path: raw/LLM Wiki - Persistent Personal Knowledge Bases.md
|
|
hash: "sha256:cd64125fcf5070abff12dd8f25f0371658833d08e0138bd8ee71fc7cb9bfc89d"
|
|
tags:
|
|
- "个人知识库"
|
|
- "LLM Wiki"
|
|
- "检索系统"
|
|
- "知识图谱"
|
|
last_updated: 2026-08-02
|
|
---
|
|
|
|
# LLM Wiki 的实现模式
|
|
|
|
这篇文章把 [[LLM-Wiki-Persistent-Personal-Knowledge-Bases|LLM Wiki 方法论]]映射到可实现的系统组件。重点是哪些机制能让“持续编译知识”在文件系统和桌面应用中稳定运行；项目下载、订阅、星标和其他推广信息不属于知识库内容。
|
|
|
|
## 页面定位
|
|
|
|
本页是与平台无关的实现抽象，重点是摄取队列、增量状态、混合检索、图谱分析和 Review 闭环。当前仓库的桌面 API、MCP 和 Obsidian 操作细节分别保留在 [[LLM-Wiki-Desktop-Implementation|LLM Wiki 桌面实现与外部接入]]和 [[Obsidian-CLI-Wiki-Maintenance|Obsidian CLI 作为本地 Wiki 维护工具]]。
|
|
|
|
## 摄取：先分析，再生成
|
|
|
|
比起让一次 LLM 调用同时阅读来源和修改多份 Wiki 页面，更稳妥的做法是拆成两个顺序阶段：
|
|
|
|
```text
|
|
来源文档
|
|
|
|
|
v
|
|
分析阶段：实体、概念、主张、矛盾、关联页面、结构建议
|
|
|
|
|
v
|
|
生成阶段：来源摘要、实体页、概念页、索引、日志、审阅项
|
|
```
|
|
|
|
分析阶段提供一个结构化中间结果，生成阶段只负责将分析转成文件。这样可以把“理解来源”和“修改知识库”分开审查，也便于重试、缓存和比较生成结果。每个页面应在 YAML frontmatter 中记录 `sources` 或 `raw_sources`，使结论能够追溯到原始文件。
|
|
|
|
### 增量与队列
|
|
|
|
对原始文件计算 SHA-256，未变化的文件可以跳过摄取。摄取队列应串行处理写入，避免多个 LLM 调用同时修改相同索引；队列状态持久化后，应用崩溃或重启时可以恢复。失败任务应区分可重试错误和需要人工处理的错误，并保留失败原因。
|
|
|
|
## 检索：关键词、语义和图谱互补
|
|
|
|
个人 Wiki 的规模较小时，`INDEX.md` 加文件搜索就足够；规模扩大后，可以使用分阶段检索：
|
|
|
|
1. **词法检索**：对中文使用 CJK 二元词，对英文分词并去除停用词；标题命中应获得额外权重。
|
|
2. **可选向量检索**：用兼容 OpenAI API 的 embedding 服务建立本地向量索引，发现没有共享关键词但语义相近的页面。
|
|
3. **图谱扩展**：从高分页面出发，沿 Wikilink 和来源重叠关系进行一到两跳扩展。
|
|
4. **预算控制**：按相关性分配上下文，把索引、Wiki 页面、对话历史和系统规则分别纳入预算。
|
|
5. **证据组装**：为页面编号并要求答案引用页面编号，同时保留原始来源作为核查路径。
|
|
|
|
知识图谱的相关性可以综合四类信号：直接链接、共同来源、共同邻居带来的 Adamic-Adar 分数，以及页面类型亲和度。图谱不仅用于展示，还可以发现孤立页面、稀疏社区、桥接节点和潜在研究空白。
|
|
|
|
## 文件和图谱的一致性
|
|
|
|
当来源被删除或替换时，维护流程不能只删除一个摘要页。应当：
|
|
|
|
- 根据 `sources[]`、来源摘要名称和 frontmatter 引用寻找受影响页面。
|
|
- 对共享多个来源的实体页，只移除被删除的来源，不删除页面本身。
|
|
- 从索引移除失效页面，并清理指向不存在页面的 Wikilink。
|
|
- 对新旧来源冲突保留证据和时间关系，不静默覆盖旧结论。
|
|
|
|
这类级联清理是 Wiki 与普通文件夹的关键区别：知识页面之间存在可计算的依赖关系。
|
|
|
|
## 图谱洞察与异步审阅
|
|
|
|
图谱可以主动暴露维护任务，而不是等用户偶然发现问题：
|
|
|
|
- **孤立页面**：入度或总度很低，可能是未挂载的新知识。
|
|
- **稀疏社区**：页面之间缺乏有效交叉链接，可能需要概念整理。
|
|
- **桥接节点**：连接多个主题，适合作为导航或综合页面。
|
|
- **知识空白**：已有页面提出问题但缺少来源或证据。
|
|
|
|
摄取阶段可以把需要判断的事项放入 Review 队列，例如“创建页面”“发起研究”“跳过”。将审阅异步化可以避免整个摄取任务被一个不确定判断阻塞，同时把高风险选择留给用户。
|
|
|
|
## 外部接入
|
|
|
|
一个本地 HTTP API 可以把 Wiki 暴露给外部 Agent，但应保持本机绑定、令牌保护和明确的读写边界。适合提供的接口包括：
|
|
|
|
- 健康检查和项目列表。
|
|
- 文件列表与文件内容读取。
|
|
- 关键词或混合搜索。
|
|
- Wikilink 图谱读取。
|
|
- 未解决 Review 项导出和状态更新。
|
|
- 原始来源重扫描。
|
|
|
|
MCP 可以把同一组能力包装为标准工具；Agent Skill 则负责向编码 Agent 描述何时调用这些接口、如何引用页面路径以及默认采用只读操作。接口、Skill 和 Wiki 页面应保持职责分离：协议定义调用契约，Skill 定义操作流程，Wiki 保存知识内容。
|
|
|
|
## 适合加入个人知识库的设计原则
|
|
|
|
1. 原始来源可追溯，Wiki 页面可重建，索引和日志可检查。
|
|
2. 摄取先分析后生成，避免理解和批量写入互相污染。
|
|
3. 所有增量处理都使用哈希和状态记录，避免重复消耗上下文与模型调用。
|
|
4. 关键词检索是基础，向量检索和图谱扩展按规模渐进加入。
|
|
5. 删除、替换和冲突处理必须是显式工作流，而不是手动清理。
|
|
6. Review、Lint 和来源引用共同构成质量控制闭环。
|
|
7. 外部 API 默认只读，任何写入都应有明确的权限和审计边界。
|
|
|
|
## 与 Harness 工程的关系
|
|
|
|
LLM Wiki 的三层文件结构对应 Harness 工程中的上下文与可观测性基础：`raw/` 提供事实来源，`wiki/` 提供可检索的工作上下文，Schema 和技能文件提供前馈指南，索引、日志、Lint 和 Review 提供反馈传感器。更大的知识库还需要[[Context-Budget-Management|上下文预算管理]]，以避免页面数量增长反过来淹没 Agent。
|
|
|
|
## 相关研究
|
|
|
|
- [[LLM-Wiki-Persistent-Personal-Knowledge-Bases|LLM Wiki：构建持久累积型个人知识库]]
|
|
- [[Harness-Engineering|Harness 工程]]
|
|
- [[Externalization-in-LLM-Agents|LLM Agent 中的外部化]]
|
|
- [[Memory-Systems|记忆系统]]
|
|
- [[Agent-Protocols|智能体协议]]
|
|
- [[Meta-Harness|Meta-Harness：模型 Harness 的端到端优化]]
|