我前阵子整理旧笔记时发现一个扎心的事实：七八年前存下的几百个Markdown文件，标题起得还算规矩，可真正要找某个知识点时，只能靠关键词硬搜，很多内容明明记过，但早就忘了当初放在哪个文件夹里。更别提跨主题的关联——比如翻到“transformer学习率设置”时，我根本想不起来自己还写过一篇“BERT微调踩坑记录”。这些知识躺在硬盘里，既没有结构，也没有连接，它们不是知识库，只能算一堆“知识死货”。后来我把整个体系重构了一遍，借助LLM（大语言模型）做维护，搭了一个会自己生长的Wiki，效果比预想中好很多。这篇就把完整的思路、技术选型、实操步骤和踩过的坑都拆开讲。

对想搭个人知识库、正在折腾RAG问答、或者觉得知识管理不该只是“文件归档”的人，这篇文章会比较有用。它不会教你装个笔记软件然后继续手动整理，而是讲清楚怎么让大模型替你完成“知识入库、关系发现、内容更新、冲突消解”这套最耗时的工作。你不需要会写复杂的算法，但最好对Python脚本和基本的API调用不陌生。

2. 传统Wiki为什么容易“死掉”

先聊一个根本问题：大家平时说的“Wiki知识库”，到底和普通文件夹有什么本质区别？文件夹是树状结构，一个文件只能属于一个目录；而Wiki的核心是双向链接——每一页都能通过链接指向其他相关页面，反过来也会被其他页面引用。这种网络结构天然适合知识组织，因为它不强迫你做“唯一正确的分类”，知识之间可以有多条路径被再次发现。

但传统Wiki有一个致命伤：结构维护的成本完全落在人身上。你读了一篇论文，得手动创建页面，手动打标签，手动找相关旧笔记并加上反向链接。三个月后你想更新某个旧条目，发现它已经过时了两代技术版本，可你根本不知道哪里需要改。就算你意志力特别强，坚持用Obsidian或Notion维护了半年，大概率也会出现内容不一致、链接断掉、分类体系前后冲突的情况。这不是工具不好，而是“人肉维护网络结构”这件事的边际成本实在太高。

RAG问答库解决了另一部分问题。它不要求你预先整理结构，把文档切片后扔进向量库，用户问一句，系统检索相关片段再让大模型生成回答。但它的缺陷也很明显：知识没有沉淀成体系。你把一百篇PDF灌进Dify或者LangChain，能问“某某章节讲了什么”，但问不了“这套知识体系里有哪些核心概念、它们之间什么关系”，因为向量库里根本没有显式的实体关系结构。每个问题都是临时检索，答完就散，知识库本身不会因为被使用而变得更完善。

LLM Wiki想解决的就是这个矛盾：既保留Wiki的网状知识结构，又把维护结构的重复劳动交给大模型。你负责提供原材料——网页、PDF、会议纪要、代码片段，大模型负责抽取实体、提炼摘要、建立双链、标记过时内容。知识库不再是“死文件集”，而是一个持续被加工、被关联、被更新的活系统。

2.1 传统知识库的维护周期陷阱

做过内容运营的人都知道，任何知识库都逃不过“衰减定律”：入库成本低的知识库更新快，但结构乱；结构规整的知识库更新成本高，最后必然停滞。传统Wiki把希望寄托在“使用者的自律”上，这在个人场景偶尔能维持，放到团队或企业场景基本必死——文档写了没人更新，接口变了没人同步，等项目结束回头看，Wiki里一半内容已经不能用。LLM Wiki的真正价值，在于把“更新维护”从人的例行公事变成了一条自动化流水线，知识库的质量不再随人的精力波动而波动。

2.2 LLM Wiki的定位：不是“让AI写Wiki”，而是“让AI养Wiki”

这里要区分一个概念。有人理解的LLM Wiki是“AI自动生成百科式文档”，比如丢一个主题给模型，让它输出几十页介绍。这不是我要讲的东西，那只是单次内容生成，没有持续生长的能力。我讲的“让大模型替你维护一座会生长的知识库”，指的是持续循环：新资料进来，AI抽结构、建链接；旧内容变化，AI检测冲突、发起修订；知识之间的关系逐渐丰富，检索和发现能力指数级上升。Wiki是主，LLM是维护工，不是内容生成器。

3. 让知识库“生长”的核心机制：从输入到链接的闭环

如果把LLM Wiki看成一棵植物，它有四层机制缺一不可：摄入层负责把原始资料变成干净的“知识原料”，结构层负责抽出实体和关系，关联层负责形成页面间的双向链接，维护层负责让旧知识跟上新变化。下面一层一层拆。

3.1 知识摄入：LLM先把“资料”变成“条目”

原始资料形态很杂：网页正文、PDF扫描件、产品文档、聊天记录、会议录音转写。直接把这些塞给知识库基本等于自杀——格式不统一、噪声太多、重复内容互相覆盖。我的做法是先用LLM做一轮“清洗和结构化”，让它按预设模板输出。

模板大概长这样：

• 条目标题：尽量是具体概念，而不是“XXX相关笔记”这种模糊命名
• 一句话摘要：压缩成适合被索引的短文本
• 关键实体：文中出现的人、系统、技术、工具、术语
• 关系对：实体A与实体B的类型化关系，例如“依赖”“替代”“改进自”
• 信息日期：内容对应的时点或版本范围，用于后续判断是否过时
• 原文来源：指向原始文件的路径或链接

这一步非常关键，因为后续所有检索、链接、更新都依赖这些结构化字段。实测下来，让LLM抽取实体的效果相当稳，但前提是你要给它一个明确的提取schema（抽取模板），而不是含糊地说“帮我总结一下”。schema越具体，返回结果越能直接用。

3.2 关系发现：从“分类文件夹”到“知识网络”

传统笔记靠文件夹分类，可现实里一个知识点永远横跨多个主题。比如“LoRA”既属于模型微调，又属于显存优化，还和参数高效训练有关——你把它放在哪个文件夹都不对。Wiki的解法是：不设唯一目录，用链接代替归属。LLM在这件事上的优势是批量发现隐含关联——你人工翻资料一小时未必能想起来旧笔记里有一条和当前内容相关，但让LLM扫描全库的实体和摘要，给出候选链接是很快的。

实际执行时，我会定期跑一个“关联发现任务”：把近期新增条目和已有所有条目的标题、摘要、实体列表喂给模型，让它输出“本条可能关联到哪几个已有条目，以及是什么关系”。得到候选后不需要照单全收，重点看模型给出的“理由”和“关系类型”，人工确认一下合不合逻辑。这一步大概是整个体系里最值钱的功能——知识库开始出现“没人为创建、但确实存在”的连接，这就是我理解的“生长”。

3.3 内容维护：自动摘要、过时检测、冲突消解

生长不只是“变多”，还包括“变新”。LLM Wiki跑一段时间后，同一个主题下可能出现多篇新旧不一的资料，甚至两篇内容互相矛盾。这时候需要维护机制：

• 过时检测：给每个条目一个“最晚有效时间”字段。定期让模型扫描，判断该条目的技术内容是否已被新条目替代或推翻。如果某条目引用的框架版本老于当前主流，模型会在条目顶部加一行“该内容可能过时，参见XXX条目”，而不是直接删掉——历史记录仍然有参考价值，但要明确标注时效。
• 冲突消解：两页面对同一个概念说法不一致，LLM会把差异抽出来并生成一条“知识冲突记录”。它不会自动二选一，因为立场和语境需要人来判断。但过去这种冲突得靠人逐篇阅读才可能发现，现在模型能主动暴露给你。
• 反向链接复核：Wiki里最关键的反链，通常是由“谁引用了这个页面”决定的。LLM在每次新增条目后，会把该条目引用的所有旧条目往下游注册一条反链。这样一来，你从旧条目上也能看到“后来哪些内容讨论了我”，知识网络是双向的。

3.4 生命周期管理：知识库的分级与淘汰

一块长期运转的Wiki如果无限膨胀，最终会退化成另一个大杂烩。所以我给条目定义了生命周期：草稿（刚录入），活跃（被引用多、更新时间近），休眠（不再活跃但仍有历史价值），归档（确认不再适用于当前语境）。LLM不会擅自归类，但它会按规则给出建议：某条目三个月没被任何新条目引用、实体也没有再出现在新资料中，模型标记为“疑似休眠”，我确认后进入休眠。这套生命周期体系的用意是：知识库的检索质量不取决于总量，而取决于活跃子集的密度。让LLM替你定期“剪枝”，比堆几个T的资料然后全部检索要靠谱得多。

4. 技术选型的关键拆解：RAG、GraphRAG、本体和框架

LLM Wiki的核心是“结构+上下文”，这就牵扯到几个绕不开的技术选型问题。这一节我结合自己的实践，把最容易决策出错的几个点讲透。

4.1 为什么不能只靠向量检索

很多人会把LLM Wiki和“向量知识库”画等号，但纯向量检索有两个硬伤。第一，检不出关系——你可以问“哪几篇文章提到了LoRA”，但问不了“哪些方法与LoRA解决的是同一个问题”，因为向量相似度衡量的是文本表面语义，不是概念之间的关系。第二，上下文缺失——检索出来的是片段集合，没有骨架，大模型只能靠猜去组织答案。所以检索层我建议做成混合结构：向量检索负责召回候选，图结构负责沿着关系扩展上下文，最后用LLM组织回答或更新条目。

4.2 图结构：GraphRAG什么时候值得上

GraphRAG这两年很热，核心思路是先从文档中提取实体和关系构成知识图谱，再基于图谱做检索增强。放在LLM Wiki里，它的价值在于：当你要回答“A方案相比B方案有哪些优劣变化”这类跨文档问题，图结构能沿着“替代”“依赖”“改进”等关系路径去收集散落在不同页面里的相关信息。但注意，GraphRAG不是免费午餐，构建图谱需要额外推理开销，对小体量知识库来说收益有限。如果条目不到几百，纯向量+双向链接已经够用；到几千条以上、跨领域问题变多，图谱的价值才明显起来。

4.3 本体设计：LLM Wiki里最容易被忽视的细节

“LLM Ontology”这个热词，说的不是让LLM学习某个现成本体，而是定义一个足够小而明确的schema，让LLM在这个schema框架内抽取知识。很多人失败的项目通病是：本体设计得太大，想让模型把所有哲学关系都抽出来，结果模型大量编造关系，知识库结构越来越脏。

我的经验是，本体控制在6到8种实体类型、8到10种关系类型以内就够了。实体类型例如：技术、工具、论文、人物、项目、概念；关系类型例如：基于、替代、引入、优化、提出、依赖、评估。你不需要设计完美的知识图谱语言，你只需要一个机器能稳定执行的关系约定。schema过大，LLM的稳定输出率直线下降。

4.4 LLM框架的取舍：自己拼还是用现成流水线

如果你只做单机笔记，完全不需要重型LLM框架。我建议先跑一个最朴素的流水线：文件系统当存储，脚本触发任务，OpenAI兼容API（任意服务商均可，可本地私有化部署）调模型。Obsidian作为浏览层，它的双链图谱可视化足以展示知识库的生长效果。等需求复杂到需要团队协作、权限管理、多数据源接入，再考虑Dify这类平台，它自带文档加载、分段清洗、Prompt编排、召回测试等模块，省掉很多重复造轮子的时间。

选型时有个原则：能用一个脚本解决的，绝不上一个框架。框架会约束你的数据格式和流程抽象，在小规模阶段反而是负担。我见过太多人一上来就部署企业级RAG平台，最后整个系统接口比笔记内容还复杂。

5. 实操：从零搭建一套会生长的LLM Wiki

我分两个方案讲：轻量方案适合个人，半个小时能跑起来；平台方案适合团队或生产环境，需要额外部署。

5.1 轻量方案：文件系统 + 脚本 + LLM API

第一步，我先约定目录结构，把笔记库拆成这样：

wiki/ pages/ # Wiki条目，每个概念一个md文件 sources/ # 原始资料存档 scripts/ # 维护脚本 metadata/ # 实体、关系、日志等元数据

pages里的每个条目前面加上简单的frontmatter（元数据头），给LLM提供操作入口。一个条目的头部大概长这样：

--- title: "图注意力网络 GAT" summary: "一种基于自注意力机制的图神经网络架构，适合处理异构图。" entities: [GAT, 图神经网络, 自注意力, Pytorch Geometric] relations: - [图神经网络, GAT, 提出] - [GAT, Pytorch Geometric, 基于] updated: 2025-06-18 status: active ---

第二步，写一个扫描脚本，遍历sources目录，把新出现的PDF和网页转成文本，调用大模型抽取内容，生成条目文件写入pages。脚本里有个关键的“增量标记”：处理完的文件会在文件名后加一个.done标记，下次运行自动跳过。这一步避免了重复调用API烧钱。

第三步，也是最重要的关联发现，写一个批处理任务，定期把新条目的内容摘要和已有条目索引发给模型，让它输出候选链接。得到结果后生成[[双链语法]]写进条目文件，Obsidian会自动渲染。实际测试中，这一步能发现很多我完全没想到的知识交叉点。比如我之前一篇“分布式训练踩坑”的旧笔记，被模型关联到了新录入的“ZeRO优化器”，理由是两者都涉及显存分配策略。这个联想路径我当初整理时根本没意识到。

5.2 一个简单的抽取脚本示例

下面给你一个基于OpenAI兼容接口的示意代码，直接改改就能用。注意API endpoint可以换成任意服务商或本地模型服务，整体逻辑不变。

# -*- coding: utf-8 -*- """ 轻量LLM Wiki维护脚本：新资料抽取与条目生成 """ import os import json import hashlib from pathlib import Path from openai import OpenAI client = OpenAI(base_url="http://localhost:8000/v1", api_key="EMPTY") WIKI_ROOT = Path("./wiki") SOURCES = WIKI_ROOT / "sources" PAGES = WIKI_ROOT / "pages" PROCESSED = WIKI_ROOT / ".processed" # 假设我们有一个从PDF/网页里抽取纯文本的模块 def extract_text(path: Path) -> str: # 实际可接 pymupdf / trafilatura / markdown 解析器 return path.read_text(encoding="utf-8") def generate_page(title_source_text: str) -> dict: schema_instructions = ( "你是知识库管理员。我需要你把给定材料转换成一个Wiki条目。" "严格输出JSON字段：title, summary, entities, relations, source。" "entities只列具体概念、技术、工具、系统。" "relations格式为[[实体A,实体B,关系]]，关系类型限定为：基于、替代、提出、" "引入、优化、依赖、评估。如果材料中没有明确的关系，relations给空列表。" "不要编造材料中不存在的信息。" ) resp = client.chat.completions.create( model="qwen2.5:14b", # 换成你本地用的型号 messages=[ {"role": "system", "content": schema_instructions}, {"role": "user", "content": title_source_text}, ], temperature=0.2, response_format={"type": "json_object"}, ) return json.loads(resp.choices[0].message.content) def main(): PROCESSED.mkdir(exist_ok=True) for src in SOURCES.glob("*.md"): digest = hashlib.sha256(src.read_bytes()).hexdigest() marker = PROCESSED / f"{src.stem}.done" if marker.exists() and marker.read_text() == digest: continue # 已经处理过且内容没变 page_data = generate_page(extract_text(src)) page_path = PAGES / f"{page_data['title']}.md" # 写frontmatter frontmatter = ( "---\n" f"title: {page_data['title']}\n" f"summary: {page_data['summary']}\n" f"entities: {page_data['entities']}\n" f"relations: {page_data['relations']}\n" f"source: {src.name}\n" "updated: 2025-06-18\n" "status: active\n" "---\n\n" ) page_path.write_text(frontmatter + page_data.get("body", "")) marker.write_text(digest) print(f"[处理完成] {src.name} -> {page_path.name}") if __name__ == "__main__": main()

这个脚本没有把“关联发现”阶段放进去，那部分是独立的批处理任务，思路基本一样：读取所有页面的title、summary、entities，交给模型，让它输出候选链接。关键配置是temperature调低一点（0.1到0.2），并要求模型必须输出“关联理由”，否则你不知道它为什么推荐这个链接。

5.3 轻量方案的实测心得

我实际跑这个方案用了大概两个月，发现几个规律。第一，抽取类任务用小模型完全够，我用本地7B到14B的模型跑实体和关系抽取，效果稳定；但关联发现这类任务需要更强的推理能力，用更大的模型或API效果才有保障。第二，增量标记真的是省钱神器，没有它一个批量任务能重复烧掉上千次API调用。第三，Obsidian的Graph View确实能直观看到知识库的生长——第一周图谱稀疏得像几颗孤立的树；一个月后开始出现明显的密集子图，那就是关联发现任务沉淀出来的结果。

5.4 平台方案：用Dify搭一条知识库流水线

如果知识库的规模上去了、需要多人协作，命令行的轻量模式很快会成为瓶颈。这时候我建议把流水线搬到一个平台上。以Dify为例，大致是这么串的：

1. 接入数据源：文档、网页、Notion数据库、甚至数据库表。Dify内置了不少加载器，省去自己写解析的功夫。
2. 清洗与分段：按章节或语义切块，块太大召回不准，块太小上下文丢失。经验值是500到800字符一段，重叠50到100字符。
3. LLM抽取节点：在知识库写入前，加一步“知识抽取”，把分段文本转成实体、关系、标签。这一步可以调用外部模型服务，也可以接本地模型。
4. 图索引环节：把抽取出的三元组写入图谱存储，作为GraphRAG的检索基础。
5. 应用端：对外提供问答接口，用户提问时先向量召回，再沿图关系扩展候选集合，最后让生成模型组织答案。

平台方案的好处是有可视化的工作流编辑器和调试界面。文档切分效果不好、检索召回不到位，都能在界面上直接调参数，不用反复改代码。

5.5 增量更新和执行节奏

LLM Wiki不能是跑一次就完事的项目，它需要持续运行。我在生产环境是这么调度的：

• 日任务：扫描新落地的资料文件，执行抽取入库。
• 周任务：对全库做一次关联关系重扫描，发现新链接，标记疑似更新。
• 月任务：过时检测，休眠周期重算，输出知识库健康报告。

调度工具没有特殊要求，cron脚本站里就能跑。Dify平台自带的定时触发也可以。关键是“增量”两个字，每次都全量重跑一遍，资源消耗会把你逼疯。

6. 实际运行中的问题与排查技巧实录

任何知识库系统跑久了都会出问题。下面是我实际踩过的坑，每条都带排查思路和解决办法。

6.1 检索匹配度低：为什么模型回答总像“答非所问”？

这是被问得最多的问题。匹配度低的源头，通常不在模型，而在数据切片和检索方式。我遇到过一种典型情况：一篇一万字的架构设计文档，被切成若干五百字的语段，向量化后每段的语义都被稀释了。用户问“这套系统的容灾方案是什么”，检索出来的片段可能是“以MySQL为主库”这种上下文片段，没有前后文对照，模型只能靠猜。

解决办法有几个。先检查切片策略：按层级标题做结构化切分，保留段落标题信息，让向量携带更多上下文。再做混合检索：关键词BM25与向量召回并行，各自给出候选再取并集。最后是query改写，让LLM把用户口语问题转成几个可能的检索表示，再从库里分别召回。实测混合检索对匹配度的提升，比换更大的embedding模型要明显得多。

6.2 条目内容里出现幻觉，怎么防止知识库被污染？

LLM抽取时确实会编造一些看起来合理的实体和关系。我最开始用的是一股脑全量重写模式，模型返回什么就写什么，结果二维码图例里多出一个不存在的“知识建模五步法”——这个名词模型完全是自己造出来的。污染一旦写入，后续所有基于该条目的关联和问答都会被带偏，而且很难被发现。

解决思路是“抽取与生成分离”：抽取阶段只用小模型、低温度，严格按schema输出，不要求它自由发挥；生成阶段才用大模型做摘要和关联建议。还有一条规则：关系对里每个实体都应该在文本中出现过，如果实体在原文里找不到依据，整条关系直接扔掉。再加一个“人工抽查机制”，每周随机看20条新写入的条目，发现问题就回溯那批数据的来源和prompt。

6.3 链接碎片化：图谱越来越密，但用户感觉不到用处

有一种情况是系统跑得很欢、图谱看起来很华丽，但问答测试时用户觉得“还是没有帮我串联起知识”。原因往往是：关系抽取粒度太碎，模型把“A说了X、B说了Y”都抽成实体，导致图谱里的边很密但质量很差。解决方法是给关系类型加权重约束，只有“替代”“基于”“改进自”这类强关系才写入主图谱，其他弱关系只作为文本标签存在而不进入关系检索。

6.4 大模型接入和数据安全问题

个人场景用API无所谓，但企业内部知识库牵涉数据隐私，别直接把文档全量灌给第三方接口。两个方向：一是本地部署开源模型，现在14B级别的模型跑抽取任务已经足够，只要配置显卡不差；二是私有化网关做统一出口，敏感内容走本地模型，低敏感内容走云端大模型。深度求索这类国产开源模型在抽取类任务上表现稳定，成本也低。

6.5 常见问题速查表

7. 让知识库持续生长的几个小技巧

除了主线流程，再分享几个我后期才悟出来的经验。

第一个是别让AI单方面维护全部内容。LLM Wiki最合理的使用姿势是：你负责判断什么值得入库、什么标准算“过时”，AI负责执行重复劳动。定期给它上“新资料”、纠正几处错误的关联判断，比设计再精妙的自动规则都管用。毕竟LLM没有价值观，如果没有人在关键节点把关，它会把“吐槽实验失败”的随笔和维护里的“生产最佳实践”混为一谈。我的经验是让LLM维护结构，而维护者本人只做高价值决策。

第二个是把“未知”也纳入知识库。我会让LLM在找不到关联时生成一条“未连接节点”的记录，而不是硬编一段关系。这些孤立条目往往代表你知识体系里的盲区，定期扫一下，能反向指导你下一步该补充了解什么方向。这招对个人学习规划尤其好使——知识库不只是储存已知的东西，还能暴露你不知道自己不知道的地方，这个价值被很多人忽略了。

第三个是版本管理一定要做。用Git管理整个wiki目录，每次批量维护跑完后看一眼diff——如果LLM大幅改写了某个条目，diff会帮你发现它是不是跑偏了。几个月实践下来，这个习惯让我至少避免过三次灾难性的批量误改。