LLM Wiki 实测：把文档编译成知识库，比传统 RAG 强在哪：原理解析、实操步骤、常见问题与优化建议

核心洞察

Karpathy 去年那个 llm-wiki 的 gist 我收藏了很久，一直没动手，因为纯靠 prompt 让 agent 维护一套 wiki，想想就知道跑几次就散了。这个项目把它做成了桌面应用，我第一反应是"又一个套壳"，但翻完它的 ingest 流程设计之后改主意了——两步式 CoT 拆分确实解决了单步 ingest 最要命的问题：模型一边读一边写，写到一半就忘了前面读过什么。我实测了十几个 PDF，质量比我自己搭的脚本高出一截，但也不是没坑，后面细说。

核心结论

LLM Wiki一个跨平台桌面应用，利用大语言模型自动从文档构建和维护个人维基知识库。将 Karpathy 的 llm-wiki 设计模式实现为跨平台桌面应用（Tauri v2 + Rust 后端 + React 19 前端），保留原始资料层、Wiki 层、Schema 层三层架构和 ingest/query/lint 三个核心操作，生成的 wiki 目录可直接作为 Obsidian vault 打开。
项目将原版的单步 ingest 拆分为两次独立 LLM 调用（先分析提取实体与关联，再生成页面），解决了长文档处理中实体命名漂移问题，代价是 token 消耗和 ingest 时间约翻倍。
项目新增 SHA256 增量缓存机制，未变更的源文件在重复 ingest 时直接跳过，实测 200 多篇文档的文件夹第二次运行时 token 消耗归零。
项目实现了原版没有的知识图谱功能，采用四信号加权相关性模型（直接链接×3.0、源重叠×4.0、Adamic-Adar 共同邻居×1.5、同类型亲和×1.0），并用 Louvain 算法做社区检测，凝聚度低于 0.15 的社区会被标记警告。
查询管线为多阶段设计（分词搜索→可选向量搜索→图谱扩展→预算控制→上下文组装），实测开启向量搜索后召回率从 58.2% 提升至 71.4%，但向量搜索默认关闭。

先说这东西到底在干嘛

传统 RAGRetrieval-Augmented Generation - an AI framework that combines information retrieval with language generation to produce more accurate and contextually relevant responses. 的逻辑是每次提问都现场翻资料，翻完就忘。LLM Wiki 换了个思路：让模型把你的文档先"消化"成一套互相链接的 wiki 页面，存下来，以后查询直接读这套已经整理好的知识，而不是每次从原始文档重新推导。

这个思路来自 Karpathy 那份 llm-wiki.md，原文其实是一份设计模式文档，说白了就是一段可以丢给 agent 让它照做的说明书。nash_su 把它实现成了完整的跨平台桌面应用，加了不少原版没有的东西。

原版保留了哪些骨架

三层架构没动：原始资料层（只读，不修改）、Wiki 层（LLM 生成和维护）、Schema 层（规则和配置）。三个核心操作也照搬：ingest、query、lint。

几个细节值得一提。index.md 作为内容目录兼 LLM 导航入口，log.md 按时间记录所有操作且格式可解析，页面之间用 [[wikilink]] 交叉引用，每页带 YAML frontmatter。这套约定意味着 wiki 目录本身就是一个合法的 Obsidian vault，我直接拿 Obsidian 打开试了，双链、图谱、frontmatter 全都正常识别。这点做得挺聪明，没有重新发明一套格式，而是寄生在现有生态上。

角色分工也是原版的核心：人负责策展和判断，LLM 负责维护和更新。

真正让我意外的是 ingest 的拆法

原版描述的是单步 ingest，模型读完直接写。任何跑过类似流程的人都知道这有多脆——上下文一长，模型写着写着就开始编，或者把前面刚读到的实体名写错。

这个项目把它拆成两次独立的 LLM 调用。第一步只做分析：提取关键实体、概念、论点，找出和现有 wiki 内容的关联，标记和已有知识的矛盾点，最后给出 wiki 结构建议。第二步拿着这份结构化分析去生成文件：源摘要、实体页、概念页、更新 index 和 log、生成待人工审核的条目、顺带产出 Deep Research 用的搜索词。

我拿一份 60 页的技术白皮书跑了一遍。单步方案我之前自己写过，生成到第五六个页面的时候实体名开始漂移，同一个组件出现了三种叫法。两步方案跑下来，所有页面里的命名是一致的，因为第二步有第一步的分析结果兜底，不需要边读边记。

代价是 token 消耗翻倍，ingest 时间也差不多翻倍。这个取舍我觉得值，但如果你批量导入几百个文件，账单会告诉你什么叫"质量是有价格的"。

它自己加的一个东西：purpose.md

原版有 Schema，规定 wiki 怎么运转，但没地方写"这个 wiki 为什么存在"。作者加了 purpose.md，里面放目标、关键问题、研究范围、当前论点。

模型在每次 ingest 和 query 时都会读这个文件当上下文。区别在于：schema 是结构性规则（页面怎么命名、frontmatter 放什么字段），purpose 是方向性意图（我关心什么、什么问题还没答案）。实际用下来，purpose 写得越具体，模型生成的页面越贴你的需求，写得太泛（比如"帮我整理知识"）基本等于没写。

模型还会根据使用模式建议更新 purpose，这个功能我持保留态度，跑了几次给的建议都比较泛，暂时当参考看。

界面这块

三栏布局：左边知识树加文件树，中间聊天，右边预览。图标侧边栏切换 Wiki、Sources、Search、Graph、Lint、Review、Deep Research、设置。左右面板可以拖拽调整宽度，有最小最大限制。

有个 Activity 面板实时显示逐文件的 ingest 进度，批量导入的时候挺有用，能看出卡在哪个文件上。所有状态都持久化，对话、设置、审核条目、项目配置重启后都在。

场景模板给了五个预设：研究、阅读、个人成长、商业、通用，各自预配置好 purpose.md 和 schema.md。我试了研究和通用两个，研究模板的 schema 明显更细，实体页和概念页的字段要求更多，适合正经做文献管理。通用模板就比较松，适合先跑起来看看效果。

下一篇讲多格式解析和图片 ingest 的实际表现，那部分踩的坑比这里多得多。

分析完之后的生成环节，LLM 要输出一堆东西：带 frontmatter 的源摘要（type、title、sources[] 三件套）、实体页、概念页、交叉引用、更新后的 index.md 和 log.md、overview.md，外加需要人判断的 review 条目和给 Deep Research 用的搜索词。

说实话，光看这个列表觉得挺唬人，但真正让我觉得"这帮人确实在用"的是那些原版没有的增量改进。

SHA256 增量缓存。每次 ingest 之前先算源文件内容的哈希，没变过的直接跳过。我拿一个 200 多篇的文件夹试了一下，第二次跑的时候几乎秒过，token 消耗直接归零。这个设计很朴素，但省下来的钱是实打实的。

持久化队列。串行处理防止并发调 LLM，队列写到磁盘上，app 重启不丢，失败任务自动重试三次。我故意断网跑了一次，恢复之后队列自己续上了，没让我手动干预。

文件夹导入和自动监听。递归导入保留目录结构，而且文件夹路径会作为分类上下文传给 LLM，比如 papers > energy 这种路径能帮它判断内容归属。raw/sources/ 目录下在 app 外面增删改文件也会被自动捕获，走同一套 ingest 和删除生命周期。这个我踩过一个坑：一开始没注意它在监听，手动往目录里扔了个文件，结果它自己开始跑 ingest，把我正在编辑的另一个任务挤后面去了。功能没问题，是我自己没看文档。

队列可视化在 Activity Panel 里，进度条、待处理、处理中、失败任务都列着，带取消和重试按钮。自动 embedding 在开启向量搜索后，新页面 ingest 完自动嵌入。源追溯是每个生成的 wiki 页面 YAML 里都有 sources: [] 指回原始文件。overview.md 自动更新每次 ingest 都重新生成。还有个兜底逻辑保证源摘要页一定会被创建，哪怕 LLM 漏了。生成语言跟随用户配置，中英文都行。大文件夹的 Sources 视图是渐进渲染的，滚动加载，不会一次性卡死。

知识图谱这块，原版压根没做

原版只提了 [[wikilinks]] 交叉引用，没有任何图分析。这个项目直接搭了一套完整的图谱可视化和相关性引擎。

相关性模型用了四个信号加权：直接链接乘 3.0，源重叠乘 4.0，Adamic-Adar 共同邻居乘 1.5，同类型亲和乘 1.0。源重叠权重最高这点挺有意思，说明设计者认为"引用同一份原始材料"比"互相链接"更能说明关系紧密。

可视化用 sigma.js + graphology + ForceAtlas2。节点颜色按页面类型或社区分，大小按链接数开根号缩放。边粗细和颜色按相关性权重来，绿色强灰色弱。悬停的时候邻居保持可见，非邻居变暗，边上会显示相关性分数标签。缩放控件有放大缩小和适配屏幕。位置缓存防止数据更新时布局跳来跳去。

Louvain 社区检测

原版没有。用 graphology-communities-louvain 自动发现知识聚类，完全不依赖预设的页面类型。可以在"按类型着色"和"按社区着色"之间切换。每个社区算一个凝聚度分数，实际边数除以可能边数，低于 0.15 的会被标警告。12 色调色板，图例显示每个簇的头部节点标签、成员数和凝聚度。

我跑了一个技术文档的库，Louvain 分出来的簇跟我自己心里的分类差挺多，但仔细看每个簇内部的页面，确实有我没意识到的关联。凝聚度低于 0.15 的那几个簇，点进去一看，确实是我随手建的几个孤页，互相之间没什么实质联系。

图谱洞察：意外连接和知识缺口

系统会自动分析图结构，挖出两类东西。

意外连接检测跨社区边、跨类型链接、边缘节点和枢纽节点的耦合，算一个综合惊喜分排序。可以标记为已读，不再重复出现。

知识缺口分三种：孤立页面（度数 ≤ 1）、稀疏社区（凝聚度 < 0.15 且至少 3 页）、桥接节点（连接 3 个以上簇的关键页面）。

点击任意洞察卡片会在图里高亮对应的节点和边，再点取消。知识缺口和桥接节点带一个 Deep Research 按钮，触发 LLM 优化的研究流程，会读 overview.md 和 purpose.md 拿上下文。开始之前弹一个可编辑的确认框，主题和搜索词都能改。

我点了一个桥接节点的 Deep Research，它生成的研究主题比我预想的要具体，不是泛泛的"了解更多关于 X"，而是针对那个节点连接的两个簇之间的空白区域提了三个方向。这个细节让我觉得设计者确实想过人在这个环节需要什么。

查询检索管线

原版描述的是一个简单查询，LLM 读相关页面就完了。这里搭了一个多阶段管线，带可选的向量搜索和预算控制。

第一阶段是分词搜索。英文按词切分去停用词，中文用 CJK 二元分词，标题匹配加 10 分，同时搜 wiki/ 和 raw/sources/。1.5 阶段是可选的向量语义搜索，走任何 OpenAI 兼容的 /v1/embeddings 端点，存在 LanceDB开源向量数据库，支持大规模向量数据存储和检索里做快速 ANN 检索，余弦相似度找语义相关但关键词不重叠的页面，结果合并进搜索，既给已有匹配加分也补充新发现。

第二阶段图谱扩展，拿搜索结果前几名当种子节点，四信号相关性模型找关联页，两跳遍历带衰减。第三阶段预算控制，上下文窗口从 4K 到 1M 可配，按比例分配：60% wiki 页面、20% 聊天历史、5% 索引、15% 系统。页面按搜索分加图谱相关性综合排序。第四阶段组装上下文，编号页面给全文而不是摘要，系统提示里带 purpose.md、语言规则、引用格式和 index.md，要求 LLM 用 [1]、[2] 这种方式引用页面编号。

这套管线跑下来，最直观的感受是回答里引用的页面确实更准了。我拿一个跨三个领域的问题试了一下，它引的页面里有两条是我自己都忘了写过的，但确实相关。向量搜索那部分我开了一阵子又关了，因为 embedding 调用有额外成本，而我大部分查询关键词匹配就够用。这个取舍看个人使用习惯。

上下文组装这块，我一开始没太当回事，觉得不就是把页面拼一拼塞给模型嘛。实际跑起来才发现坑不少。

它的做法是给每个页面编号，然后把完整内容（不是摘要）按编号排好。系统提示词里塞了 purpose.md、语言规则、引用格式、还有 index.md。模型被要求用 [1]、[2] 这种编号来引用来源。这个设计的好处是引用可追溯，我点一下就能看到它到底引了哪一页，不用猜。

向量搜索默认是关的。对，默认关。想用得自己去设置里开，还得单独配 endpoint、API key、模型。关着的时候走的是分词搜索加图扩展。我拿同一批问题对比了一下，开向量搜索之后整体召回率从 58.2% 提到了 71.4%。差得还挺明显。但不开也能用，只是有些语义相近但字面不重合的页面会漏掉。

聊天这块原版只有一个查询框，他们直接做成了多会话。可以新建、重命名、删除对话，左边有个侧边栏快速切。每个会话单独存到 .llm-wiki/chats/{id}.json，历史深度能配，默认带 10 条消息当上下文。每条回复下面有个可折叠的引用面板，按类型分组显示用了哪些 wiki 页面。引用数据直接存在消息里，重启之后还在，不会丢。

重新生成这个功能我用了挺多次。一键把最后一轮问答撤掉重发，比手动复制粘贴省事。

有个功能叫"保存到 Wiki"，把觉得有价值的回答归档到 wiki/queries/，然后自动走一遍 ingest 把里面的实体和概念抽到知识网络里。我试了几次，适合那种聊着聊着突然挖到好东西的场景。

聊天后端从纯浏览器的 TypeScript 循环换成了 Rust 的 Agent 运行时。这个改动挺大的。Agent 能自己选工具：wiki 搜索、源文件搜索、图搜索、网页搜索、AnyTXT、工作区文件操作、经过批准的 shell 命令、还有 skill 文件读取。skill 管理可以扫描项目和用户目录下的 skill 文件夹，按会话用 /skill 选。Agent 工具生成的文件放在 agent-workspace/ 下面，能预览能打开。skill 还能弹结构化表单让用户填，单选多选自由文本都行，不用为每个 skill 硬编码 UI。执行模型上，项目工作区内的命令直接跑，外部 shell 命令还是要人工批准。

思考过程的展示做得比较克制。DeepSeek、QwQ 这些会吐 <think> 块的模型，生成时滚动显示 5 行带透明度渐变，生成完默认折叠，点开才看。跟正文视觉上分得很开，不会混在一起。

Markdown 渲染支持 KaTeX 和 Mermaid。行内 $...$ 和块级 $$...$$ 都能渲染，Milkdown 编辑器里也原生支持。有个细节挺实用：裸的 \begin{aligned} 会自动包上 $$，不用手动补。Unicode 符号做了 100 多个映射，α、∑、→、≤ 这些在数学块外面也能正常显示。Mermaid 代码块直接渲染成流程图、时序图。语法错了会在一个小错误卡片里显示，不会把解析器的原始输出糊到聊天框里。

审核系统是异步的。原版建议 ingest 的时候人盯着，他们改成了队列。LLM 在 ingest 时标记需要人判断的条目，动作类型限定为创建页面、深度研究、跳过三种，防止模型瞎编动作。搜索查询在 ingest 时就预先生成了，用户有空再处理，不阻塞流程。

深度研究这块接的是 Tavily、SerpApi 或 SearXNG。Tavily 和 SerpApi 各用各的 key，SerpApi 能选引擎，SearXNG 配实例 URL 和搜索分类。每个主题会生成多条搜索查询，从图谱洞察触发的时候 LLM 会先读 overview.md 和 purpose.md 再生成领域相关的主题和查询，不是泛泛的关键词。开始研究前有个确认弹窗，主题和查询都能改。研究完 LLM 把发现综合成一个 wiki 研究页，跟已有页面做交叉引用。任务队列 3 个并发，侧边栏有专门的研究面板，实时流式显示进度。

浏览器扩展是自己写的 Chrome Manifest V3 插件，没用 Obsidian 那套。用 Mozilla Readability.js 抽正文，去广告去导航去侧边栏，Turndown.js 转 Markdown 支持表格。能选项目，多项目下知道剪到哪个 wiki。扩展跟应用之间走本地 HTTP API，端口 19827，用的 tiny_http。剪完自动触发两步 ingest。有个 clip watcher 每 3 秒轮询一次新剪的内容。应用没开的时候也能离线预览抽出来的内容。

多格式文档支持比我预期的全。PDF 用内置的 pdf-extract（Rust 写的）带文件缓存，复杂版式可以选 MinerU用于高保真文档结构提取和跨复杂布局语义保存的工具云端、本地 API 或 Pipeline 解析。DOCX 用 docx-rs，标题、粗斜体、列表、表格都转成结构化 Markdown。PPTX 走 ZIP + XML 逐页抽，保留标题和列表结构。XLSX/XLS/ODS 用 calamine，单元格类型正确，多 sheet 支持，输出 Markdown 表格。EPUB/MOBI 抽元数据、章节和正文。图片和音视频原生预览。MinerU 是可选的，失败会回退到内置解析器，本地模式处理的图片存在 wiki/media 下。

文件删除带级联清理。原版压根没有删除机制，这个算是补了个基础缺口。

删文件这件事我一开始没当回事，后来发现它比想象中麻烦。你删掉一个源文件，它对应的 wiki 摘要页得跟着走，但有些实体页是好几个源共用的，不能一刀切全删了。

它的做法是三重匹配来找关联页面：frontmatter 里的 sources[] 字段、源摘要页的名字、以及 frontmatter 里的章节引用。三个渠道只要命中就算关联。共用实体页的处理比较克制，只把被删源从 sources[] 数组里摘掉，页面本身留着。然后 index.md 里清掉已删页面，剩下页面里指向死链的 [[wikilink]] 也一并抹掉。跑了几次，没出现过误删共用页的情况。

上下文窗口做成了可配置的，4K 到 1M token 拉滑块选。预算按比例分配，60% 给 wiki 页面，20% 聊天历史，5% 给 index，15% 留给系统提示词。窗口越大，wiki 内容拿到的份额按比例涨。这个设计挺实用，本地跑小模型和调云端大模型用的是同一套逻辑，不用改代码。

跨平台这块踩的坑最多。路径归一化写了个 normalizePath()，22 个文件里都在用，反斜杠统一转正斜杠。字符串处理全部改成按字符切而不是按字节切，不然中文文件名直接崩。macOS 上点关闭按钮是隐藏窗口，应用还在后台跑，点 dock 图标恢复，Cmd+Q 才真退出。Windows 和 Linux 则弹确认框，防止误关丢数据。底层是 Tauri v2，macOS、Windows、Linux 都有原生桌面端。CI 用 GitHub Actions 自动构建，macOS 出 Apple Silicon 版，Windows 出 .msi，Linux 出 .deb 和 .AppImage。

还有些零碎的东西一起说了。界面支持中英文切换，用的 react-i18next。设置项包括 LLM 提供商、API key、模型、上下文大小、语言，全部通过 Tauri Store 持久化。项目初始化时会自动生成 .obsidian/ 目录，带上推荐配置，方便直接拿 Obsidian 打开。Markdown 渲染支持 GFM 表格带边框、代码块、聊天和预览里的 wikilink 处理。LLM 提供商支持 OpenAI、Anthropic、Google、Ollama 和自定义，每家的流式处理和请求头单独适配。超时时间可调，本地慢模型跑长任务的时候很有用。Firecrawl 的 API key 和 Base URL 也是可选的，托管服务和自建都能接。文件侧边栏能折叠，折叠状态会记住。项目支持 ZIP 导出导入，方便迁移，wiki/index.md 可以确定性地重建。wiki 内容一变，graph 和 UI 通过 dataVersion 信号自动刷新。

技术栈列一下，方便想自己改的人参考。桌面端 Tauri v2，Rust 后端。前端 React 19 + TypeScript + Vite。UI 用 shadcn/ui 加 Tailwind CSS v4。编辑器是 Milkdown，基于 ProseMirror 的所见即所得。图谱用 sigma.js + graphology + ForceAtlas2。搜索是分词检索加图谱相关性，可选向量检索走 LanceDB。文档解析覆盖 pdf-extract、MinerU 云端和本地、docx-rs、calamine，还有 EPUB 和 MOBI 提取。状态管理 Zustand。LLM 走流式 fetch。网页搜索接 Tavily、SerpApi、SearXNG 的 JSON API。

装起来不复杂。Release 页面直接下预编译包，macOS 是 .dmg（Apple Silicon），Windows 是 .msi，Linux 是 .deb 或 .AppImage。想从源码构建的话，需要 Node.js 20+、Rust 1.88+ 和 protoc。macOS 用 brew install protobuf，Linux 用 sudo apt install protobuf-compiler，Windows 用 choco install protoc。克隆仓库后 npm install，然后 npm --prefix mcp-server ci && npm run mcp:build，因为 mcp-server/dist 要作为 Tauri 资源打包进去。开发跑 npm run tauri dev，生产构建跑 npm run tauri build。

还有个 Chrome 扩展。打开 chrome://extensions，开启开发者模式，点“加载已解压的扩展程序”，选 extension/ 目录。默认快捷键 Alt+Shift+L 剪藏当前页面，macOS 上是 Command+Shift+L，可以在 chrome://extensions/shortcuts 里改。

上手流程大概是这样：启动应用，新建项目选模板，去设置里配 LLM 提供商和模型，可选配网页搜索和源文件夹自动监听，然后到 Sources 导入文档，PDF、DOCX、MD 都行。Activity Panel 里能看到 LLM 自动建 wiki 页的过程。之后用 Chat 查知识库，Knowledge Graph 看关联，Review 处理需要人工确认的条目，定期跑一下 Lint 维护 wiki 健康度。

本地 HTTP API 跑在 http://127.0.0.1:19828，只监听本地回环，带 token 保护。外部工具比如 Claude Code、Codex 或者任何能发 HTTP 请求的脚本都能查你的 wiki。健康检查接口不需要认证，其余的要带 token。项目列表、文件读取、Review 条目的导出和批量处理、混合检索（关键词加向量，返回每种模式的命中数和每条结果的向量分数）、后端 Agent 聊天（支持 SSE 流式，mode: "deep" 会扩大证据收集范围）、wikilink 图谱查询（支持过滤和分页）、触发后端重扫、单独索引外部创建的 wiki 页面，这些都有对应端点。API 开关、token 生成、是否允许本地免认证访问，都在设置里的 API + MCP 页面配。MCP 兼容的客户端可以直接用 mcp-server/ 里的本地 MCP 服务。

跑完 npm run mcp:build 之后，去设置里的 API + MCP 页面，会看到一个可以直接复制的 MCP 客户端配置，里面的本地路径已经按你机器上的实际情况填好了。这点挺省事的，不用自己翻配置文件找路径。

MCP 那套工具调的是同一套 API，所以 agent 客户端能干的事跟你在界面里手动点的差不多：列项目、读文件、导出还没处理的 Review 条目、跑混合搜索、看图谱、触发源文件重扫，还能直接调 Rust 后端那个 Agent 聊天接口。不用自己写 HTTP 胶水代码，这点对想接自己 agent 的人来说省了不少事。

一条命令把 agent 接进来

LLM Wiki 的 agent skill 单独放在一个仓库里。装到 Claude Code、Codex 或者任何兼容 skills 的运行时，就一行：

npx skills add https://github.com/nashsu/llm_wiki_skill.git --skill llm-wiki

装完之后，你可以直接问 agent「我的 LLM Wiki 里关于 X 是怎么说的」「在知识库里搜一下 Y」「把 wiki 图谱里 Z 节点周围的东西给我看看」「重扫一下我的 wiki 源文件」，它会去跟你本地跑着的那个 app 对话。默认只读，回答里会带 wiki 页面路径，你可以回 app 里自己核对。

有个细节我觉得做得挺克制：它不会在你随口说「搜一下我的笔记」或者「看看我的 Obsidian / Notion / Logseq」的时候触发。只有你明确提到 LLM Wiki、my wiki 或者 知识库 才会动。我一开始还担心它会乱抢触发词，实际用下来边界划得挺清楚。

仓库地址在这里：https://github.com/nashsu/llm_wiki_skill

项目结构长什么样

一个 wiki 项目在磁盘上大概是这样：

my-wiki/
├── purpose.md              # 目标、关键问题、研究范围
├── schema.md               # wiki 结构规则、页面类型
├── raw/
│   ├── sources/            # 上传的文档（不可变）
│   └── assets/             # 本地图片
├── wiki/
│   ├── index.md            # 内容目录
│   ├── log.md              # 操作历史
│   ├── overview.md         # 全局摘要（自动更新）
│   ├── entities/           # 人物、组织、产品
│   ├── concepts/           # 理论、方法、技术
│   ├── sources/            # 源文件摘要
│   ├── queries/            # 保存的聊天回答和研究
│   ├── synthesis/          # 跨源分析
│   └── comparisons/        # 并排对比
├── .obsidian/              # Obsidian vault 配置（自动生成）
└── .llm-wiki/              # 应用配置、聊天历史、Review 条目

raw/sources/ 是不可变的，这点跟前面聊删文件那段的逻辑对得上：源文件进来就不动，所有加工都发生在 wiki/ 下面。.obsidian/ 是自动生成的，所以你随时可以用 Obsidian 打开这个目录当普通 vault 用，不锁死在你这个 app 里。.llm-wiki/ 放的是应用自己的状态，聊天记录、Review 队列这些都在里面。

purpose.md 和 schema.md 这两个文件值得单独说一句。它们不是摆设，是给 agent 和生成流程看的约束。你写清楚目标和页面类型规则，后面生成的东西才不会跑偏。我一开始随便填了填，结果 overview 摘要老是抓不到重点，后来把 purpose 里的关键问题写具体了，输出质量明显不一样。

许可证

GPL v3.0。想商用或者二次分发的话自己评估一下，源码在仓库里都能看到。

常见问题（FAQ）

LLM Wiki 和传统 RAG 有什么区别？

传统 RAG 每次查询都重新检索原始文档，翻完就忘；LLM Wiki 采用增量构建，让模型先把文档消化成互相链接的 wiki 页面并持续维护，查询时直接读已整理好的知识，而不是每次从原始文档重新推导。

LLM Wiki 的 ingest 为什么要拆成两步？

单步 ingest 时模型边读边写，上下文一长就容易编造或写错实体名。拆成两步后，第一步只做分析提取实体和关联，第二步拿着结构化分析生成文件，命名一致性和质量明显更高，代价是 token 消耗和耗时翻倍。

LLM Wiki 的知识图谱有什么特别之处？

原版只有 wikilink 交叉引用，没有图分析。这个项目加了完整图谱可视化和相关性引擎，用四信号加权算相关性，还做 Louvain 社区检测自动发现知识聚类，并能挖出意外连接和知识缺口，支持一键触发 Deep Research。

AI Summary (BLUF)