Files
nexus/wiki/sources/llm-wiki.md
2026-05-03 05:42:12 +08:00

4.0 KiB
Raw Blame History

title, type, tags, date
title type tags date
LLM Wiki source
llm
knowledge-base
agent
personal-wiki
rag
2026-04-09

Source File

Summary用中文描述

  • 核心主题:利用 LLM 构建和持续维护个人知识库Wiki的架构模式
  • 问题域:传统 RAG 每次查询都从零发现知识无法积累Wiki 维护负担随规模增长而超过价值,导致人们放弃维护
  • 方法/机制三层架构Raw Sources → Wiki → SchemaLLM 增量构建持久化维基,代替人类完成"记账式"维护工作(总结、交叉引用、归档、一致性检查)
  • 结论/价值知识只需编译一次即可保持最新LLM 承担维护成本使 Wiki 可持续运行人是编辑LLM 是程序员Wiki 是代码库

Key Claims用中文描述

  • LLM Wiki 通过增量构建和持续维护,使知识在每次查询时无需重新推导
  • 传统 RAG 每次回答都从原始文档中重新发现知识没有积累LLM Wiki 则将知识编译为持久化、相互链接的摘要
  • LLM 不会厌倦、不会忘记更新交叉引用,一次可以处理 15 个文件,维护成本接近零
  • 人的职责是筛选资料、指导分析、提出好问题LLM 的职责是其他一切
  • 好的答案可以归档回 Wiki 作为新页面,探索结果与摄入来源一样复合积累

Key Quotes

"The wiki is a persistent, compounding artifact." — Wiki 的本质特征:持久化、复合增长的成果物 "Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase." — LLM 与人的协作模式比喻 "The tedious part of maintaining a knowledge base is not the reading or the thinking — it's the bookkeeping." — 维护知识库最繁琐的部分不是阅读或思考,而是记录工作 "LLMs don't get bored, don't forget to update a cross-reference, and can touch 15 files in one pass." — LLM 相比人类的维护优势 "This idea is related in spirit to Vannevar Bush's Memex (1945)" — 概念渊源Vannevar Bush 的 Memex

Key Concepts

  • PersistentWiki:持久化维基——结构化、相互链接的 Markdown 文件集合,介于用户与原始数据源之间,知识编译一次后保持最新
  • LLMWikiArchitecture三层架构——Raw Sources原始资源、WikiLLM 生成的知识层、SchemaCLAUDE.md/AGENTS.md 等配置文件)
  • IngestWorkflow导入工作流——LLM 读取源文件、与用户讨论要点、编写摘要、更新索引、更新相关实体和概念页面、追加日志
  • QueryWorkflow查询工作流——LLM 搜索相关页面、综合答案并引用来源;好的答案可归档回 Wiki
  • LintWorkflow:检查工作流——定期检查页面间矛盾、过时说法、孤立页面、数据缺口等
  • MemexVannevar Bush1945构想的个人知识库概念文档之间有关联轨迹——LLM Wiki 承接了这一愿景并解决了"谁来维护"的问题

Key Entities

  • VannevarBush1945 年 Memex 概念的提出者,提出"关联轨迹"思想,其愿景比后来的万维网更接近 LLM Wiki 的理念
  • Obsidian:本地 Markdown 编辑器IDE用户浏览 Wiki 结果的界面,提供图形视图查看 Wiki 结构
  • NotebookLMGoogle 的 AI 笔记工具,采用传统 RAG 模式,与 LLM Wiki 的持久化维基模式形成对比

Connections

Contradictions

  • 与 NotebookLM 等传统 RAG 系统对比:
    • 冲突点:是否需要每次查询时重新发现知识
    • 当前观点LLM Wiki 通过持久化维基积累知识,避免重复推导
    • 对方观点:传统 RAG 每次查询时检索相关片段生成答案,无需维护 Wiki