Files
my_wiki/wiki/concepts/LLM-Wiki-Implementation-Patterns.md
T

6.3 KiB

title, source, raw_sources, tags, last_updated
title source raw_sources tags last_updated
LLM Wiki 的实现模式 nashsu/llm_wiki README
path hash
raw/LLM Wiki - Persistent Personal Knowledge Bases.md sha256:cd64125fcf5070abff12dd8f25f0371658833d08e0138bd8ee71fc7cb9bfc89d
个人知识库
LLM Wiki
检索系统
知识图谱
2026-08-02

LLM Wiki 的实现模式

这篇文章把 LLM-Wiki-Persistent-Personal-Knowledge-Bases映射到可实现的系统组件。重点是哪些机制能让“持续编译知识”在文件系统和桌面应用中稳定运行;项目下载、订阅、星标和其他推广信息不属于知识库内容。

页面定位

本页是与平台无关的实现抽象,重点是摄取队列、增量状态、混合检索、图谱分析和 Review 闭环。当前仓库的桌面 API、MCP 和 Obsidian 操作细节分别保留在 LLM-Wiki-Desktop-ImplementationObsidian-CLI-Wiki-Maintenance

摄取:先分析,再生成

比起让一次 LLM 调用同时阅读来源和修改多份 Wiki 页面,更稳妥的做法是拆成两个顺序阶段:

来源文档
   |
   v
分析阶段:实体、概念、主张、矛盾、关联页面、结构建议
   |
   v
生成阶段:来源摘要、实体页、概念页、索引、日志、审阅项

分析阶段提供一个结构化中间结果,生成阶段只负责将分析转成文件。这样可以把“理解来源”和“修改知识库”分开审查,也便于重试、缓存和比较生成结果。每个页面应在 YAML frontmatter 中记录 sourcesraw_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。

相关研究