我平时的工作多跟大模型相关的AI应用开发但真正让我头疼的并不是算法本身而是知识管理。两年前我开始系统接触LLM书签越存越多公众号文章、论文PDF、GitHub仓库、群聊里的讨论截图散落得到处都是。有一次做方案需要讲清楚“RLHF”的流程我翻了两个小时资料结果发现之前收藏过但当时没做任何整理。后来我换了一种方式用Wiki而不是文件夹来管理这些内容建了一个叫“llm_wiki”的个人知识库。所谓Wiki就是让知识点之间产生链接、能互相跳转、能像地铁图一样看到全貌。这套方法用下来查资料效率提升非常明显。如果你也在学大模型或者想系统整理自己的技术积累这篇文章应该能帮到你。1. 为什么要把LLM知识装进Wiki先搞清楚痛点很多人一听到“知识库”就想到写博客、写文档觉得是个大工程。其实LLM Wiki的核心不是“写长篇大论”而是用一种更符合大脑认知习惯的方式把零散的信息重新组织成知识网络。先看痛点再看方案后面才有动力做下去。1.1 资料不是太少而是太杂学大模型的人会遇到一个特别矛盾的现象网上资源极其丰富但真正要查某个知识点时又觉得特别难。我最早也经历过这个阶段收藏夹里躺着几十篇“Transformer入门”“Prompt工程指南”“RAG实战”群聊里还转了一堆论文和GitHub链接。真到用的时候我发现收藏跟理解完全是两回事。收藏只是相当于把资料搬了个位置大脑里仍然没有建立概念之间的联系。别人问一句“预训练的损失函数为什么用交叉熵”我虽然看过相关文章却没法立刻组织出清楚的回答因为这属于多个知识点的交叉我根本没记录过。有一次我为了搞清楚“垂域LLM的数据准备到底要做什么”从早上查到下午好几个方案在脑子里打架。后来才发现这个问题本身没有一个标准答案不同业务场景的数据准备流程差异很大。最有效的做法不是收藏更多文章而是把已经看过的内容拆成概念卡片整理成自己的判断框架。后来我建立LLM Wiki第一个原则就是“不存原文只写自己的理解”哪怕只是三句话也要用自己的话讲清楚。这个转变让知识库从“资料搬运工”变成了“思考容器”。1.2 Wiki和普通笔记的本质区别传统笔记是文件夹思维新建一个“LLM学习”目录下面分“论文”“视频”“代码”等子文件夹每个文件安安静静躺在那里彼此之间没有联系。这种结构整理起来很方便但用起来非常痛苦因为真实的知识是有依赖关系的。比如“LoRA”这个知识点涉及Transformer结构、参数更新、训练显存、推理速度它不该被锁在“微调”文件夹里而是应该可以被“大模型部署”“低资源训练”“PEFT”这些主题共同引用。Wiki的思维方式是网状链接每个概念单独一张卡片卡片之间用双链互相引用最终形成一个可以无限生长的知识网络。类比一下文件夹就像仓库货物堆得再整齐进出库还是靠人工跑Wiki更像是地铁图每个站都是一个概念换乘关系就是链接。LLM Wiki把“Word Embedding”“Self-Attention”“Transformer”“GPT”“RLHF”“Agent”这些概念全部串起来我在写任何一个新笔记时只要用双链把旧知识挂进去知识之间就会自动建立连接。这种方式的优势是不需要提前规划“完备的分类体系”知识会随着卡片增加自动长出结构。1.3 这套方法适合什么样的人先说适合的人。第一种是想系统学习大模型的初学者。这类人最容易被“资料太多”压垮如果有Wiki作为导航不会学着学着就迷路。第二种是已经入行的工程师或研究者日常工作会积累大量碎片信息比如某个推理框架的参数设置、某篇论文的改进点、某个线上问题的排查记录这些信息如果不及时整理等于白白浪费。第三种是需要经常做技术方案、写文档、做汇报的人Wiki里的双向链接可以让你在写方案时快速找到论据而不是重新去搜索引擎捞一圈。不太适合的也有纯为了“收藏成就”而建立知识库建完不再维护的人明明没有消化内容只想把所有资料堆到一个工具里然后假装自己学会了的人。LLM Wiki不是魔法它只是把“学习-整理-回顾”这个循环变得更加高效如果连整理这一步都不愿意做效果自然等于零。2. 整体设计思路从LLM学习路线到Wiki架构在动手建库之前我建议先画一张LLM学习路线图。很多人一上来就建文件夹今天加一个“注意力机制”明天加一个“Agent实战”没有主线过两周自己都找不到北。Wiki虽然很自由但也需要骨架来承载自由生长。2.1 先画学习路线图再设计目录我用的学习路线大概分为五层基础层、原理层、模型层、工程层、应用层。基础层包括Python、深度学习、概率统计理解到“知道每个符号是什么意思”就够了原理层重点是Transformer及其变体、预训练目标、损失函数、优化方法模型层要熟悉主流模型架构比如GPT系列、Llama、Qwen等以及它们之间的差异工程层聚焦推理加速、模型部署、量化、评测应用层再看RAG、Agent、微调、垂域落地。这五层不是严格的先后关系但可以作为知识库的顶层目录。我不会为了追求工整把分类做到十几层因为层次越深维护成本越高。实际使用的目录结构一般是llm_wiki/ ├── 00_Inbox/ # 临时收集 ├── 10_Basics/ # 基础概念 ├── 20_Model_Architecture/ # 模型结构 ├── 30_Training/ # 预训练与微调 ├── 40_Inference_Deployment/ # 推理与部署 ├── 50_Applications/ # RAG、Agent、垂域 ├── 60_Papers/ # 论文阅读 ├── 90_MOC/ # 导航台 └── templates/ # 模板数字前缀是为了排序稳定。新人刚起步不需要这么多文件夹可以从“00_Inbox、10_基础、20_模型、30_应用、90_MOC”五个文件夹开始。文件夹数量控制在十个以内如果超过说明分类过细反而会让笔记不知道该放哪。最重要的一点是所有临时收藏先丢进Inbox每周再决定它到底该归到哪个主题下这样不会因为“不知道怎么归类”而放弃记录。2.2 MOC给知识库加一个“导航台”MOC全称Map of Content可以理解成“内容地图”。Wiki里的笔记如果只是一堆双链时间长了还是会乱因为没人引导你从哪看起。MOC的作用就是给知识库建导航。我会在页面里放一个“LLM Wiki首页”里面列出所有MOC链接每个MOC页面再列出具体主题卡片形成“首页-主题-卡片”三层结构。以“30_Training”为例我会建一个“MOC: 训练与微调”页面里面用列表整理所有相关卡片比如“预训练损失函数”“RLHF”“LoRA”“全参微调 vs 参数高效微调”“数据准备”。这样即使我忘了某张卡片叫什么名字只要打开MOC就能顺着目录找。MOC不追求一次建完而是在学习过程中不断补充。每当我写完一张新卡片就问自己“这张卡片的上一级导航应该放在哪里”如果找不到就会顺手创建一个新的MOC或调整目录结构。2.3 命名规范、标签与双向链接命名规范越来越重要。我踩过的坑是早期笔记名随意比如“llm”“大模型应用”“关于attention的一些想法”后来根本分不清谁是谁。现在统一规则概念卡片直接用术语命名比如“Transformer”“LoRA”“RLHF”项目或实操笔记用“日期主题”格式比如“20241210-vLLM部署记录”。这样在双链里看到名字就知道大概内容不用点进去猜。标签体系用命名空间而不是无限发散。我会用三种标签领域标签#llm/training、状态标签#status/seed表示萌芽、#status/developing表示成长、#status/mature表示成熟还有一种资料来源标签#source/paper、#source/doc。刚开始不必搞得很复杂只要保证“某个主题下面能筛出相关笔记”即可。双向链接是Wiki的灵魂每张卡片至少链接到3个其他概念才算合格。链接不一定要等到“完全理解”才建立看到一个陌生概念就立刻创建空白卡片并建立链接后续慢慢补充这叫“先建骨架后填血肉”。2.4 工具选型Obsidian、Wiki.js还是飞书知识库工具只是手段。我对比过几类主流方案Obsidian适合个人知识管理本地Markdown存储、双链原生支持、插件生态丰富缺点是协同弱需要靠Git或同步盘分享Wiki.js适合有运维能力的小团队自托管、权限控制好、支持跨设备在线编辑但部署和备份需要花时间飞书知识库、语雀这类在线文档适合团队内部知识沉淀协同体验好但对个人来说内容所有权和灵活性比较差。我的最终方案是个人库用Obsidian团队协作另开一个在线知识库。个人库要求的是长期稳定、可控、免费Obsidian的.md纯文本格式让我不用担心平台跑路。团队库则更重视权限、评论、在线编辑飞书知识库确实方便但我不建议把个人学习笔记和公司机密混在一个库里。实操上我会用Git做版本管理仓库推送到私有仓库手机端和电脑端都能同步。用Obsidian踩过最值得记住的一个点是图片、附件要设置统一存放路径否则会很乱我放在assets/目录下配合主题插件使用效果不错。3. 核心知识点怎么拆LLM Wiki的内容模块有了骨架之后要往里面填内容。很多人的问题是“知道要建立知识库但不知道每个条目该写什么”。这一章我直接举例把LLM相关的高频知识模块拆开告诉大家每一类概念卡片应该记录什么顺便把一些容易混淆的问题讲清楚。3.1 基础设施预训练、损失函数与TransformerLLM Wiki里最基础的一批卡片是解释“大模型是怎么来的”。这里一定不要跳过“预训练损失函数”。我看过太多人只会调用API但一被问“训练时的优化目标是什么”就卡壳。语言模型预训练最常用的目标函数是最大化下一个 token 的预测概率也就是最小化交叉熵损失。为什么是交叉熵因为交叉熵等价于负对数似然。对于一个batch里的每个位置模型会输出一个词表维度的概率分布真实标签是某一个token交叉熵衡量的是预测分布和真实分布之间的差距。这个损失函数计算出来的困惑度Perplexity其实就是对交叉熵取指数直觉上可以理解为“模型对下一个词的不确定程度”。Transformer相关知识就更核心了。自注意力机制、多头注意力、位置编码、残差连接与层归一化这些概念不能只背名字最好每张一个卡片。我的做法是给“Self-Attention”建一张卡里面写下它的直觉解释——每个词都要和句子里的其他词做相似度计算然后加权聚合再补一个具体例子比如“银行”这个词在不同上下文里的表示差异。接着用双链挂到“Transformer”“BERT”“GPT”等相关卡片上。这样每次看注意力相关文章发现新的细节就直接补充到旧卡片里而不是新开一篇笔记知识库才能越用越厚。3.2 模型与框架从训练端到推理端模型模块不只是罗列模型名字而是要区分“模型结构差异”“训练方式差异”“推理生态差异”。热词搜索里经常看到“textcnn bert 和 llm 大模型做意图识别的区别”这就是一个很好的Wiki主题。我的卡片里会画一张比较表记录三者的不同。TextCNN是轻量级模型利用卷积提取局部n-gram特征适合短文本分类、低延迟场景但语义理解能力有限对同义句、复杂意图几乎无能为力。BERT基于Transformer Encoder通过预训练获得上下文语义表示做意图识别时需要微调一个分类头效果比TextCNN好很多但训练和推理成本也高。到了GPT这类LLM意图识别变成了“对话式理解”甚至不需要专门微调给一个包含候选意图的prompt就能输出结果泛化能力强但代价是推理速度慢、成本高、输出不稳定。这个表建议用表格形式放在卡片里。工程侧的知识点也需要记录比如推理端常用的vLLM、TensorRT-LLM、llama.cpp、Ollama它们各自适合什么场景。我用“vLLM”卡片记录“PagedAttention如何减少显存浪费”“适合高并发服务”用“Ollama”卡片记录“本地快速跑模型、CPU/GPU自动切换、适合个人实验”。LLM框架方面LangChain、LlamaIndex、Dify这些工具也可以作为独立卡片重点记录它们解决的问题、核心模块和踩坑记录。不要把工具当成知识本身工具是用来承载落地场景的。3.3 应用研究Agent、RAG与意图识别应用模块是很多人真正关心的地方。LLM Agent是我认为最值得梳理的主题之一。对Agent比较经典的理解是一个由LLM驱动的系统可以自己规划步骤、调用外部工具、读取记忆、根据环境反馈进行推理。它不是“调用一次模型给你一个答案”而是一个循环过程。Wiki里的“Agent”卡片要写清楚四个子模块规划拆解任务、记忆保存上下文、工具调用比如搜索和代码执行、反思评估结果。再往下挂“ReAct”“Function Calling”“AutoGPT”这些具体实现方案。RAG是另一个高频卡片。RAG全称检索增强生成核心思路是先从外部知识库检索相关信息再把信息拼进Prompt交给LLM生成答案可以降低幻觉、支持私有知识问答。卡片里要区分“什么时候用RAG什么时候用Agent”RAG更适合知识密集型问答Agent更适合多步骤任务实际产品里两者通常结合用Agent做任务规划、用RAG提供答案素材。意图识别这块如果团队需要在线系统准确率要求高且数据量有限BERT微调往往是稳妥选择如果意图类别特别多、不断变化LLMFunction Calling会更省事。这些结论不会永远是标准答案所以每张卡片我都会带上“记录时间”和“适用场景”避免以后看到旧笔记产生误导。3.4 垂域实践数据准备与模型落地垂域LLM是现在的热门方向也是Wiki里最容易沉淀经验的地方。做垂域模型的第一步永远不是选模型而是准备数据。我在“垂域数据准备”卡片里会记录完整流程领域知识抽取、数据清洗、敏感信息脱敏、去重、格式标准化、人工抽检。比如做法律问答原始裁判文书有大量格式噪声需要抽取“案件背景-判决依据-判决结果”这样的结构化字段做医疗问答数据涉及隐私必须做严格的脱敏和权限控制。这些细节在通用课程里很难学到只能在实践中积累。更重要的是Wiki要记录“为什么这么做”。比如数据清洗时为什么先做去重因为大量重复样本会让模型训练不稳定甚至让模型过度记忆某几条数据。为什么需要质量打分因为低质量数据会拉低生成效果质量比数量重要。每一条经验都可以从现象、原因、解决方案三个角度写成卡片比如“语料里小语种占比过高导致中文效果变差”“用困惑度过滤低质量文本后垂域效果提升XX%”。这些内容就是普通资料里找不到的也是个人Wiki最有价值的部分。4. 从零搭建LLM Wiki完整实操过程前面把思路理清了这章给大家一套可以直接照搬的落地步骤。我会假定你用的是Obsidian因为它在个人知识库场景下最顺手功能也足够。4.1 第一步初始化仓库与文件夹先在电脑上创建一个空文件夹比如llm_wiki然后用Obsidian“打开文件夹作为仓库”。进入后先做两件小事设置里把“新建笔记的存放位置”改成“指定文件夹”选到00_Inbox把“附件默认存放路径”改到assets避免截图丢得到处都是。接着按前面设计的目录创建文件夹暂时不用建太多00_Inbox、10_Basics、20_Model_Architecture、30_Training、40_Inference_Deployment、50_Applications、90_MOC、templates就够了。文件夹只是辅助不要为了让文件夹好看而强制分类。插件方面最核心的几个Templater用来快速插入模板Dataview用来做笔记列表和统计Graph Analysis用来查看双链图谱Banners可以给页面加头图但不是必需。所有插件都在“社区插件”里搜索安装注意开启“第三方插件”选项。推荐再装一个“Recent Files”插件方便快速回到最近编辑的笔记。不要一次装太多插件知识库的核心价值在内容组织不在插件数量。4.2 第二步搭建首页和MOC导航在90_MOC文件夹里新建一个“LLM Wiki 首页.md”作为整个知识库的入口。这个页面不需要花哨只需要三层信息一句话介绍这个知识库是干什么的、常用入口链接、当前正在推进的学习任务。我用Dataview做了几个自动列表比如“最近创建的20条笔记”“标签为#status/seed的待补充卡片”这样每次打开首页就知道该从哪里继续。然后创建五个MOC页面MOC-基础.md、MOC-模型结构.md、MOC-训练与微调.md、MOC-推理与部署.md、MOC-应用与Agent.md。每个MOC先用列表把手头已知的核心概念列出来比如“MOC-模型结构”里面先写Transformer、Attention、Positional Encoding、MoE这些词条。刚开始不需要把所有笔记都规划好只要有一份可点击的导航后续新增卡片就往对应MOC里挂链接维护成本很低。4.3 第三步设计笔记模板模板是我最看重的一步。没有模板记录的时候会纠结“这条该写什么”最后干脆放弃。我用Templater做了四类模板概念卡模板、论文笔记模板、实操记录模板、MOC模板。概念卡模板只要几段固定的结构就能保证信息密度。--- type: concept aliases: [] tags: [llm/basic] source: [] created: {{date}} --- # {{title}} ## 一句话直觉 用一句大白话解释这个概念不看任何资料都能想起来。 ## 核心定义 准确定义、公式或逻辑关系。 ## 关键细节 列出最重要的3-5个点每个点配一句解释。 ## 与其他概念的关系 - 上游[[ ]] - 下游[[ ]] - 相关[[ ]] ## 实践场景 这个知识点在什么场景下会被用到 ## 参考资料 链接或书目信息。论文笔记模板会加入“研究问题、方法、数据集、结论、启发”几段实操记录模板会加入“背景、操作步骤、遇到的问题、结果、复盘”。每次新建笔记时Templater会按模板自动生成结构我只需要往里面填内容。4.4 第四步写第一张LLM卡片我们实操写一张基础卡片“预训练损失函数”。在30_Training下新建笔记选择概念卡模板然后填充内容。一句话直觉可以写模型每猜一个词我们给它打个分猜得越不准分越高训练就是不断降低这个分数。核心定义写“交叉熵损失 负对数似然”再用两三行解释为什么用交叉熵而不是均方误差因为语言模型的输出是词表上的概率分布交叉熵能更好地衡量分布差异。关键细节写三点按token计算损失、通常忽略padding部分、Perplexity由交叉熵指数得到。最后把关系区的[[Word Embedding]]、[[Transformer]]、[[RLHF]]都挂上这张卡片就算初步完成。写完后直接在首页里的“MOC-训练与微调”页面加上[[预训练损失函数]]链接。这样后续每次学习相关内容都可以补充到这张卡片里。不要追求一次把卡片写完满知识是迭代出来的。4.5 第五步用图谱、反链和搜索把内容串起来Obsidian的Graph View打开时一开始可能很乱但有了MOC导航和标签过滤就能慢慢理清。我会在图谱里按#llm/training标签过滤只看训练相关的卡片及其链接。如果看到某张卡片孤零零没有任何链接说明它还缺少上下文的连接需要补双链。反向链接面板也很有用在任意卡片底部打开“反向链接”就能看到哪些笔记提到了它。这样一来哪怕某张卡片本身没写完整也能通过其他卡片里的上下文补全信息。最后要解决同步和备份。个人知识库最怕硬盘损坏或误删我的做法是仓库根目录初始化为Git每次做完一批笔记就提交并推送到私有仓库同时在本地做一个压缩备份。如果不想用Git可以用坚果云、OneDrive之类的同步盘直接同步整个文件夹。唯一要提醒的是不要直接同步Obsidian的.obsidian配置文件夹到多台不同系统的设备容易冲突可以让同步工具忽略它或按需覆盖。5. 常见问题与排查技巧实录这部分整理了我自己的踩坑记录也是LLM Wiki能不能长期用下去的关键。很多问题不是工具不会用而是使用习惯不对导致知识库越来越膨胀、越来越乱。5.1 笔记写得很散没有主题怎么办这是一个高频问题。我一开始也遇到今天写“Self-Attention”明天写“Agent”各写各的过两周发现没有一条是完整的。后来我养成了一个习惯每张卡片只把一个概念讲透但允许不同卡片之间有交叉。如果发现一张卡片内容越来越多长到上千字就说明该拆分了。把“QLoRA”从“LoRA”卡片里拆出去时原卡片保留一句话介绍然后链接过去。这个拆分动作本身就是在梳理知识结构。另一个处理方法是每周做一次“回填”。把本周所有新笔记过一遍看哪些是从Inbox里收集来的链接哪些是零散想法统一补上类型、标签和双链。不需要花很长时间每次十五分钟就能让整个库保持整洁。5.2 资料太多不知道存什么知识库不是网盘不要什么都往里塞。我给自己定了一个硬规则只有能用自己的话转述的内容才值得记录。如果一篇文章看完后脑子里只能留下一句话那就只记那一个点然后链接到对应卡片。如果某篇资料是经典必读的比如Transformer原文就放“60_Papers”里做论文笔记。真正的干货标准是能回答某个“为什么”或者能指导某个“怎么做”。比如“为什么RLHF需要三阶段训练”“vLLM的PagedAttention为什么省显存”这类内容放在Wiki里才有价值。剩下的一些参考链接如果暂时用不上只放到Inbox里最多保留一个月过期就删。5.3 链接改名后断链了Obsidian对Wiki链接的反向链接和自动重命名支持很好正常情况下改了文件名所有引用会自动更新。但如果你是从老版本笔记里复制粘贴过来的链接或者在文件名里手动修改了大小写偶尔会出现断链。排查方法很简单打开“关系图谱”看有没有孤立节点或者用“未解析文件的链接”搜索所有失效双链。还有一个细节命名时尽量避开特殊字符尤其是中文空格、冒号、括号这些字符在文件名和链接匹配时可能导致问题。我现在的习惯是概念名不加空格文章名用“日期-短横线-主题”格式基本没再断过链。5.4 坚持记录的小习惯建立知识库最难的不是技术而是坚持。我的经验是降低每次记录的启动成本每张卡片不追求完美先写一个“种子版本”哪怕只有一句话“这个知识点我还不懂需要看XXX”也算收录。等到真正有时间研究时再从种子卡片开始补充。另一个小习惯学习新东西时先想“这个新知识应该挂在哪张旧卡片下面”如果没有合适的卡片再新建卡片。这个方法能倒逼自己建立知识之间的联系而不是单纯地“看完就完”。最后分享一个我坚持了很久的小技巧每周单独留出30分钟专门做“知识库浇灌”。这30分钟不做新知识的学习只做整理、补链接、拆分卡片、更新MOC。有人说知识库是有生命的我觉得说得挺对你定期去打理它它才会在你需要的时候回报你。跑过几次之后你会慢慢感觉到LLM Wiki不只帮你减少了找资料的时间更重要的是它逼着你把模模糊糊的想法变成了能说得清楚的判断这才是个人知识库真正的意义。