LLM Knowledge Bases

把 LLM 从回答器，升级为个人研究知识库的编译器与运营者

[[Obsidian]] 作为前台，文件系统作为数据库，Agent 负责 ingest / compile / query / lint / evolve。

方法论拆解

这套范式是什么

不是把文档喂给聊天框。

而是先把原始资料收进 raw/，再让 LLM 持续把它们编译成一个可链接、可检索、可回写的 wiki。

核心对象不是单次回答，而是一个会持续演化的 [[数字花园]] / 研究知识库。

核心判断

  • LLM 的主要工作从操作代码，转向操作知识与文件。
  • 真正有价值的是累计可复用资产，而不是一次性问答。
  • 输出应默认落成文件，如 Markdown、Canvas、Marp、图表。
  • 个人探索产生的新结果，应尽量再回收入库。
  • 当 wiki 规模还在中小体量时，依靠摘要、索引、双链和 agent 搜索，往往就足够好。

为什么它在小规模上有效

  • 不是全靠长上下文硬吃，而是让 LLM 自己维护摘要页、索引页、主题页。
  • 关键上下文被压缩成更短的结构化入口，读取成本下降。
  • 文件系统天然支持渐进读取、局部改写、版本管理和可追溯。
  • [[Obsidian]] 让人类和 agent 看到的是同一套材料与产物。

它和经典 [[RAG]] 的关系

这不是先检索再回答的窄链路。

更接近：

  • 文件化 memory
  • agent 自主搜集上下文
  • 持续编译知识结构
  • 回写产物并再利用

也就是一种偏 [[上下文工程]] 与知识编译的系统。

产品机会

原文最后那句很关键：

现在像是一堆脚本的拼接，但它其实已经隐含一个新产品雏形：

AI Native Research OS

一个把 ingest、wiki compile、问答、可视化、健康检查、再沉淀统一起来的个人研究操作系统。

系统闭环

1. Ingest

raw/

文章、论文、repo、dataset、图片先入库。

目标是保留原始材料，而不是立刻过度加工。

2. Compile

wiki/

LLM 生成摘要页、概念页、关系页、主题页、索引页，并补 [[wikilink]]。

3. Query

Agent 不只回答问题。

它会自己搜索 wiki、读取原文、整合证据、再生成结论。

4. Output

默认产出文件：

Markdown Canvas Marp Matplotlib 图 报告与草稿

5. File Back

把有价值的问答产物重新归档进 wiki。

这样每次研究都会增加未来可复用上下文。

6. Lint

健康检查、缺失字段、事实冲突、候选新主题、待补证据、脏数据清理。

7. Tools

小型搜索引擎 repo CLI 批处理脚本 图表生成器 外部搜索器

8. Repo As OS

raw/
wiki/
outputs/
prompts/
tools/
reports/

文件系统就是数据库，也是 agent 的工作面。

闭环本质：原始资料 -> 编译知识 -> 围绕知识提问 -> 生成新产物 -> 回收入库 -> 持续增强。

如何全面实践

阶段 1

选题与边界

  • 先选一个研究主题，不要一上来全库总动员。
  • 明确原始资料类型、更新频率、核心问题。
  • 先做 30 到 100 份高质量材料的试验库。

先证明闭环能跑，再扩大。

阶段 2

目录与规范

至少分层：

  • raw/
  • wiki/
  • outputs/
  • prompts/
  • tools/
  • reports/

原文、编译产物、查询产物不要混写。文件命名、frontmatter、链接规则要尽早固定。

阶段 3

编译流水线

为 agent 设计几类稳定任务：

  • 单文档摘要
  • 多文档综述
  • 主题页更新
  • 索引页维护
  • 链接补全
  • 证据追溯

重点不是大而全，而是可增量重跑。

阶段 4

查询与输出

把常见问题都文件化输出：

  • 问题回答
  • 研究备忘录
  • 决策对比
  • 幻灯片
  • 图表
  • 新候选主题页

目标是让每次提问都留下结构化资产。

阶段 5

健康检查

周期性让 agent 做：

  • 死链与孤儿页检查
  • frontmatter 缺项
  • 事实冲突与口径不一致
  • 高价值缺页候选
  • 需要 web 校验的陈旧信息

知识库质量要靠巡检，而不是靠记忆。

阶段 6

评估与扩容

最后才考虑：

  • 搜索引擎增强
  • 向量索引
  • 合成数据
  • 微调

判断标准是：当前文件化闭环是否已稳定，瓶颈是否真来自检索或模型记忆，而不是流程设计。

建议拆成 5 类 agent 角色

  • Ingestor：把外部资料整理进 raw/
  • Compiler：把 raw 编译成 wiki 结构
  • Researcher：回答复杂问题并追证据
  • Librarian：维护索引、双链、目录与主题页
  • Linter：跑质量检查，产出修复建议

这样比一个全能 agent 到处乱写更稳。

建议节奏

  • 每次 ingest 后，只增量编译受影响主题。
  • 每天允许生成问答产物，但要有归档路径。
  • 每周至少跑一次 health check。
  • 每月回顾：哪些主题越来越强，哪些只是制造噪音。

知识库不是一次性建成，而是持续运营。

实践原则

先把“本地文件 + 可回写产物 + 增量编译 + 周期巡检”四件事做稳，再追求 fancy 的 RAG、知识图谱或微调。

风险、边界与决策

常见失败模式

  • raw/ 和 wiki/ 混在一起，原文与推断无法区分。
  • Agent 可无边界改写全库，越跑越脏。
  • 问答只停留在聊天里，没有回写。
  • 索引页和摘要页不维护，导致规模一大就失控。
  • 过早上复杂 RAG，掩盖了真正的问题。

硬边界

  • 原文区只追加，不覆盖。
  • 编译区允许改写，但要区分事实、判断、待确认。
  • 最新事实默认要求可追溯来源。
  • 高风险批量操作先 dry-run。
  • 输出优先生成新文件，不直接重写核心常青页。

先盯这些指标

  • 可回答问题的覆盖度
  • 主题页完整度
  • 死链/孤儿页数量
  • 关键概念是否有摘要与索引
  • 问答产物回收入库比例

先衡量知识库是否越来越好用。

何时考虑合成数据与微调

当且仅当：

  • 高频问题稳定
  • 输出格式稳定
  • 文件化闭环已成熟
  • 检索和上下文成本成为真实瓶颈

否则，多半是在把流程问题伪装成模型问题。

最终结论

这套方法论最强的地方，不是替代搜索，而是把研究过程本身沉淀成一个越来越聪明、越来越可操作的个人知识系统。