跳到正文
← 全部笔记
流量与内容BOOTNOTE

我把Karpathy的LLMWiki改成了六层架构,更适合内容创作者

尹睦5 分钟阅读

原载公众号 BookNote · 保留原文观点与写作日期

#流量与内容

阅读公众号原文 ↗

今年4月,Andrej Karpathy(OpenAI联合创始人)提出一个知识库结构,叫LLM Wiki。做法很简单:把所有资料存成Markdown文件,分成raw(原始素材)和wiki(结构化知识)两层,让AI直接读文件夹,相当于自己做一个小型的百度百科,想学习或者查什么东西非常方便。这条推文的浏览量超过千万,整个AI圈子都在学习。我第一时间就用上了。把过去写的300篇原创文章全部导入Obsidian,按他的架构整理成raw+wiki两层,加了一个index导航层。但我用了一段时间以后,发现理论很美,实际有坑。 1.Karpathy的架构有什么问题?不只是我一个人,很多人用了以后都有类似反馈:第一,规模一大就崩。 超过100个来源以后,wiki层的矛盾开始累积。AI在不同时间整理的内容会互相冲突,而且没有自动纠错机制。你今天让它总结的观点,可能和上周总结的完全矛盾,它自己不知道。第二,token成本扛不住。 我上周写一篇获客文章,让Claude根据我的知识库完善,结果它直接消耗了我$17的token。而且我的知识库还在持续扩大,每次想用它写文章就是在烧钱。第三,只管写不管读。 原始架构的重心全在怎么把素材整理进wiki,但对怎么高效地从 wiki里取出来用设计不足。说白了,存进去容易,用的时候并不好找。这些问题,对于建一个个人知识库学习用来说,可以忍。但我的需求不是学习,我是要用这个知识库写文章、做内容、跑业务的。 2.我的需求和Karpathy不一样 Karpathy是研究者,他的知识库是用来整理论文和技术笔记的。但我是内容创作者,我的知识库要同时承担三个角色:

1.素材库:存放我过去写的所有文章,AI写新文章时从这里调案例和数据 2.方法论库:提炼出来的写作模型、获客框架、平台策略,每次创作时对照检查 3.生产工具:要能生成封面图片、预览排版、多平台分发 Karpathy的两层架构解决了素材存储的问题,方法论勉强能塞进wiki里,但生产环节完全没覆盖。而且最大的问题是:所有东西混在一起,AI每次扫库的消耗太大。有时候我就写一篇关于小红书起号的文章,AI把Karpathy的人物档案、GPT-Image2的提示词库全读了一遍,跟这篇文章一点关系都没有,纯粹烧钱。无奈之下,我只能在这个架构下进行魔改 3.我的解决方案:六层架构改了三四版以后,我现在的架构基本定型: raw/      → 原始素材层(几百篇历史文章,按11个主题分类) wiki/     → 结构化知识层(方法论、框架、案例提炼) index/    → 导航层(主题索引、仪表盘、知识图谱) memory/   → Agent记忆层(原则、偏好、模板、钩子) people/   → 人物档案层(半隐性,按需调用) caogao/   → 创作草稿区和Karpathy的原始架构比,多了四层。说一下每层为什么要加。 memory层是改动最大的。 这一层存的是高度压缩的记忆卡片,一张卡片就是一条原则或一个偏好,几百字。比如写文章时标题必须有数字和认知冲突,这种东西不需要每次从wiki里重新推导,直接存成一张卡片,AI秒读。写文章时先读memory,只在需要展开的时候才去翻wiki和raw。加了这一层以后,单篇文章的token消耗大概降了一半。 people层是我一个有点得意的设计。 我研究了不少人,Karpathy、Dan Koe、参哥、经纬这些,每个人的档案都有几千字。如果放在wiki里,写任何文章都会被扫到,纯粹浪费。单独拎出来以后,只有我提到某个人名的时候,AI才去找对应档案。平时完全不碰。

index层用来解决找不到的问题。 上千个文件,光靠记忆根本找不到想要的素材。 Dataview动态查询加上Canvas可视化知识图谱,相当于给知识库装了个搜索引擎。 caogao层解决生产流程。 草稿和成品分开,写到一半的东西不会污染知识库。这个最简单,但不做的话wiki会越来越乱。 4.核心思路就四个字:分层加载不是所有内容都需要每次都读。按使用频率和场景分层:层级什么时候读大小 memory 每次都读极小(十几张卡片) wiki 写文章时读相关主题中等 raw 需要原文验证时读大 people 提到人名时读按需 index 找素材时读小 这样每次写文章,AI实际读取的内容大概只有全库的10%-20%,但覆盖了90%的需求。当然这套架构也有代价。初始搭建比Karpathy的原版复杂得多,memory层的卡片需要手动维护,people层的人物档案要一个一个建。说白了就是前期投入大,但跑起来以后效率高很多。最后还是要说,Karpathy的LLM Wiki是一个很好的起点,我的内容生产架构现在还在用他的raw+wiki核心结构为基础。但如果你不只是做知识管理,而是要用知识库做内容生产,光靠两层不够。想要更快、更准、并且省钱地把需要的东西调出来,我认为我现在的架构是更有好用的。如果你也在用LLM Wiki,建议先加一个memory层试试。把你最常用的原则和偏好压缩成几张卡片,让AI每次先读这些,效果立竿见影。我是敦敦,多年获客操盘手,如果你对流量获客有任何想法或者困惑,欢迎和我聊聊。

—

有值得继续追问的问题?写信交流 ↗