Karpathy的LLMWiki:让LLM帮你维护一套个人Wiki最近Karpathy发了一份gist,标题就叫LLMWiki。 Karpathy还给了一个很形象的比喻:Obsidian像IDELLM像程序员wiki像代码库这个比喻很容易把它的工作方式讲清楚。 Karpathy列出来的检查项包括:页面之间有没有冲突有没有旧结论被新资料推翻有没有孤立页有没有该有但还没建的概念页有没有缺交叉引用哪些地方可能需要补新资料wiki不是建完就结束,它也需要持续lint。 Karpathy提到,这套方式在大约100个source、几百个页面的规模下,已经能跑得比较顺,甚至不一定非得上embedding检索系统。log.md这是时间导向的记录。 这份gist后面那层意思如果只用一句话概括,我会这么说:Karpathy在试图把“知识检索”改成“知识编译”。
v=zjkBMFhNj_g一、Andrej Karpathy是谁正式开始介绍视频内容前先来介绍一下视频作者Andrej Karpathy。 Andrej Karpathy最初任职于OpenAI公司,担任研究科学家的职位,主要关注深度学习、强化学习和生成模型等领域的研究。在他的领导下,OpenAI团队取得了一系列重要的研究成果。 而后,在2017年,Karpathy加入特斯拉,担任 Autopilot 人工智能的主管,负责领导自动驾驶汽车的深度学习和计算机视觉方面的研究。 2022 年 7 月,Karpathy 从特斯拉离职,并在接下来的几个月里,发表了一个详解反向传播的课程 、一份重写的 minGPT 库、一份从零开始构建 GPT 模型的完整教程等众多学习材料。 总之,Andrej Karpathy 是一位在深度学习和计算机视觉领域具有广泛影响力和贡献的研工程师,他对于LLM的理解一定是处于业界巅峰水平,这也就很好的解释了本文章要介绍的视频为何在一日之内就有20w
今天继续聊下LLM Wiki个人AI智能知识库。 这个元模型在Karpathy的核心观点里面是概念,实体和关系。如果参考本体建模思路,我细化的元模型核心思路是场景-》方法论-》对象-》行为-》规则。 好了,言归正传,首先还是验证下参考Karpathy LLM Wiki的思路来对原始资料进行加工和知识萃取。 /wiki (存放加工后的结构化知识) Goal 你将作为一个具备 Karpathy 第一性原理思维的架构专家,学习 llm-wiki-skill 的构建模式,将 . Karpathy Style: 参考 https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f 的代码美学,要求 Wiki 内容
❝Andrej Karpathy 提出了 LLM Wiki 架构——一种完全不同于 RAG 的知识管理范式。本文将深入解读其核心思想,并分享我从零实现一个 LLM Wiki 系统的完整实践。 而 Karpathy 提出了一个反直觉的思路:「为什么不在入库时就让 LLM 理解好?」 二、Karpathy 的核心思想:知识编译 Karpathy 的 LLM Wiki 架构,核心就一句话: ❝「"不要让 LLM 在查询时去理解原始文档,而是提前让 LLM 把文档'编译'成结构化的知识。 在 Karpathy 的设计中,「Schema 是整个系统最核心的概念」。 Karpathy 自己也说: ❝"RAG 是用技术复杂度换取内容量。LLM Wiki 是用前期精炼换取查询时的简单与准确。"
Karpathy的LLM Wiki深度拆解:从理念到落地,如何构建可进化的知识底座 最近圈子里都在聊Karpathy的LLM Wiki,不少人把它和RAG搞混,甚至觉得这只是个“花里胡哨的笔记技巧”—— (拒绝玄学,只讲本质) Karpathy在gist里给的定义很简洁,但还是很抽象,我重新拆解一下: LLM Wiki是一套「以Markdown为载体、LLM为维护者、人类为监督者」的知识管理模式,核心是 核心三层架构(Karpathy原版架构+我补充的实操细节) Karpathy在gist里提到了三层结构,但没说清楚每层的具体规范和实操边界,这边稍微做点补全后,直接照着搭就行: LLM编译/转换 约束/ 团队协作:从个人到团队的适配(Karpathy提到的产品机会) Karpathy在推文中说,LLM Wiki不只是个人工作流,更是一个“潜在的产品机会”——核心是解决团队知识碎片化的问题。 Andrej Karpathy, LLM Wiki gist: https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f 2.
今天继续结合Karpathy的LLM Wiki来聊下AI大模型知识库方面的话题。 好了,言归正传,还是聊下对Karpathy的LLM Wiki落地实践的一些关键优化和改进。供大家参考。 文章的分层萃取-主条目和子条目 如果把整个LLM Wiki投给Claude大模型,再给出需要Ingest的思维文章资料。实际AI在处理的时候分为了主条目和子条目两层的Wiki。 我原来一直强调很难区分清楚Karpathy谈到的概念和实体两个概念,我在这里也不去强行区分这两个概念。 但是当前能做的就是历史资料要分层抽取。第一层就是完全和历史文章1对1映射的知识卡片。 Query回写和自我进化 注意LLM Wiki不仅仅是一个知识编译系统,更加重要的是一个动态自我进化的知识库,是真正理解了你核心知识框架和知识元模型的知识库。
的架构故事至少迭代了四轮:从最早的 Notion + ChatGPT(摘要生成),到烂大街的 RAG + 向量数据库(切片检索),再到以 OpenClaw 为代表的自动化 Agent(自主读写记忆),直到最近 AI 大牛 Karpathy 提出了用 LLM 持续编译 Wiki 的方案。 派系 C:Karpathy 的 LLM Wiki —— 有损压缩带来的“软证据”Karpathy 提出的思路是:新资料进来时,直接让 LLM 综合并更新到对应的 Wiki 页面,以后 Agent 直接读 缺陷:LLM 的每一次综合都是一次有损压缩(Lossy Compression)。它会丢失边界条件、过度脑补逻辑关联。 破局之道:设计真正的“知识状态运行时”在拆解了 Hermes 的记忆代码、OpenClaw 的 memory-core 并在本地复现了 Karpathy 的 Wiki 方案后,我得出了一个核心结论:模型只能负责
https://medium.com/@karpathy/software-2-0-a64152b37c35 Andrej Karpathy 人工智能主任特斯拉。 26K 92 以下 Andrej Karpathy 人工智能主任特斯拉。以前在OpenAI的研究科学家和在斯坦福大学的博士生。我喜欢在大型数据集上训练深度神经网络。
这不,AI 领域的大牛 Andrej Karpathy 也感觉到不对劲,发了长文推来指出这个令人无语的现象。 Karpathy 说,「LLM 在默认状态下正变得比我日常使用需求更具『自主代理(Agentic)』倾向,甚至有些超出了我的平均使用场景」。 因此 Karpathy 不得不经常打断 LLM,并用类似这样的指令限制它:「停,你想得太多了。只看这一份文件。不要用任何工具。不要过度设计。」 这带来了很多麻烦,不仅是在编码任务,我们发现日常使用 LLM 工具时候的类似打断情况也越来越多了。 对于这件事,Karpathy觉得罪魁祸首似乎是大模型「在长周期任务上进行了大量基准测试优化」,为了在基准测试上得到更好的成绩,LLM的思考就更倾向于长周期的复杂任务的实现,因此影响了普通任务的响应。
新智元报道 编辑:润 【新智元导读】Karpathy力推代码生成任务增强流程,让GPT-4在CodeContests从19%提升到44%,不用微调不用新数据集训练,让大模型代码能力大幅提升。 这个数据集包含约一万个可用于训练LLM的问题,以及用于评估LLM解决具有挑战性的代码生成问题的能力的验证和测试集。 作者没有训练专用模型,而是开发了一个面向代码的流程,这个流程可以应用于任何能够用于编码任务的预训练的LLM,例如GPT或DeepSeek。 下图展示了一个 CodeContests 数据集中的典型问题示例: 为什么CodeContests是一个评估代码生成任务的LLM的优秀数据集? LLM在生成模块化代码时做得更好 当要求 LLM生成单个冗长函数时,结果往往很差 - 代码通常包含错误或逻辑错误。
这个项目叫 LLM Wiki,基于 Andrej Karpathy 提出的 LLM Wiki 方法论,把传统的 RAG 思路完全颠覆了。 而且它是基于 Karpathy 的原始思想实现的,但做了大量的工程化增强,做成了一个真正能用的桌面应用。 核心亮点 1、两步思维链 Ingest LLM Wiki 没有让 LLM 一边读一边写,而是把这个过程拆成了两个步骤: 第一步:分析 - LLM 先读取源文档,提取关键实体、概念、论点,分析和现有 Wiki 功能特性 • 完整的 Wiki 系统:LLM Wiki 严格遵循 Karpathy 的三层架构-原始素材、知识库、规则配置 • 多格式文档支持:PDF、DOCX、PPTX、XLSX/XLS/ODS、图片 人负责「看什么」,LLM 负责「怎么记」——这才是正儿八经的人机分工。 如果你也在为知识管理头疼,如果你也有一堆收藏了但没整理的资料,不妨试试 LLM Wiki。它可能会彻底改变你管理知识的方式。
年初回归 OpenAI 的 Andrej Karpathy 最近做了一场关于大型语言模型(LLM)的 30 分钟入门讲座,但该讲座当时没录制。 我们接下来整体了解一下 Karpathy 都讲到了哪些内容。视频主要分为三大部分展开,分别是 LLMs、LLMs 的未来和 LLM 安全。 在第一部分,Karpathy 首先介绍了 LLM 的一些入门知识,并以 Meta 推出的开源大模型 Llama 2-70b 为例讲解。 LLM 训练比推理复杂得多。Karpathy 表示,模型推理可以在一台 MacBook 上运行,但模型训练过程耗费的计算量就非常大了。因此,我们需要对互联网内容进行压缩。 在谈到 LLM 的未来发展时,Karpathy 提到了 System 1 和 System 2 的思维模式。
他搭了一套 LLM 驱动的个人知识库系统,用 Obsidian 做前端,Markdown 做底层格式,LLM 负责一切脏活累活。 输出呈现(Output) Karpathy 不喜欢在终端里看答案 他更倾向于让 LLM 生成 Markdown 文件、Marp 格式的幻灯片、matplotlib 图表,然后在 Obsidian 里直接查看 最有远见的一句话 Karpathy 整个推文我认为最有远见的一句话: "随着仓库的增长,自然地也想考虑合成数据生成 + 微调,让你的 LLM '知道'数据在其权重中,而不仅仅是上下文窗口。" 参考资料: Andrej Karpathy — X/Twitter 长推文,2026 年 4 月,关于 LLM 驱动的个人知识库系统 Lex Fridman — 对 Karpathy 推文的回复,关于混合前端和语音模式知识消费 个人页面 — karpathy.ai — 个人经历与项目列表 #知识管理 #Obsidian #Karpathy #LLM #AI写作
Karpathy 的第二大脑秘密 3月底,前OpenAI 联合创始人 Andrej Karpathy 在 X 上发了两条长推,讲他如何用 LLM 构建个人知识库。 Karpathy 的比喻是"像编译代码一样编译知识"[1][3]。 第三步是直接问答。当知识库积累到一定规模,他不再使用关键词搜索,而是直接用自然语言向 LLM 提问。 LLM 读取它自己维护的索引和摘要文件,直接回答。 第四步是定期维护(Linting)[4]。Karpathy 让 LLM 定期对知识库做"体检":找出不一致的地方,补充缺失的信息,建议新的研究方向。 参考 [1] Karpathy (X). LLM Knowledge Bases. [2] Karpathy (X). Farzapedia. [3] Karpathy. Karpathy's LLM Knowledge Bases: Full Breakdown. [6] Eric J. Ma.
前 OpenAI 联合创始人、特斯拉 AI 总监 Andrej Karpathy 也一样。他在前几天发推,说自己「开始养成用 LLM 阅读一切的习惯」。 于是,Karpathy 在周六用氛围编程做了个新的项目,让四个最新的大模型组成一个 LLM 议会,给他做智囊团。 比如,Karpathy 和「LLM 议会」一起读书时,它们一致称赞 GPT 5.1 是表现最好、洞见最丰富的模型,而始终把 Claude 排在最后,中间则是其他模型浮动。 项目地址:https://github.com/karpathy/llm-council 但提醒一下:Karpathy 不会对这个项目提供任何支持,它是原样提供的、为其他人提供灵感的小工具,他也不打算继续改进它 参考链接: https://x.com/karpathy/status/1992381094667411768 https://github.com/karpathy/llm-council © THE
Andrej Karpathy在GitHub上发布了一份名为LLM Wiki的文档引起了巨大的关注,一派认为"这不就是多绕了几步的RAG",另一派已经打开编辑器着手搭建测试。 Karpathy引用了一个计算机科学的类比,RAG表现得像解释器——运行时重新求值一切;LLM Wiki更像编译器,预先将源材料处理成结构化中间表示(即wiki),后续工作针对编译产物展开,而非反复阅读原始材料 Karpathy称之为关键配置文件。主要是通过这个文件把LLM从一个通用聊天机器人转变为有纪律的wiki维护者。 分层的意义在于每层可以独立替换。 Karpathy提到了qmd——一个用于Markdown文件的本地混合BM25/向量搜索引擎,带有MCP服务器接口。缺少类似工具的话,LLM花在读索引上的开销增加,查询延迟随之上升。 总结 Karpathy没有发明新技术,他在清晰阐述一个工作流模式,让LLM天生擅长的事——快速阅读、综合、交叉引用、一致地遵循约定——去接替人类一直需要但从未能持续做好的工作。
机器之心报道 编辑:张倩、陈萍 Andrej Karpathy 又离职了! 看来,这一切对于Karpathy还不够有吸引力。 在Karpathy帖子的评论区,确实出现了一些比较有意思的「阴谋论」,比如有人说他是被马斯克派到OpenAI当间谍的,现在是时候回去了。 Andrej Karpathy个人经历 个人主页:https://karpathy.ai/ 2005-2009 年,Andrej Karpathy 本科就读于加拿大多伦多大学,主修计算机科学与物理,辅修数学 Karpathy 是 OpenAI 的创始成员和研究科学家。 Karpathy表示,新的视频已经在制作了。 这次的离开,相信 Karpathy 重新找回了自己的热情所在,我们也期待 Karpathy做出更多惊艳的研究成果。
OpenAI 创始成员、前研究科学家 Andrej Karpathy 最近尝试在 llm.c 中重现了 GPT-2。 一年后,Karpathy 离开了 OpenAI,并出于教育意义开发了 llm.c。 Karpathy 建议道。 代码 “虽然我可能有点倾向性,但 llm.c 真的非常优雅”Karpathy 介绍道: 它只需要基本 CUDA 依赖即可运行。 llm.c 总计约有 5000 行 C/CUDA 代码。Karpathy 主要尝试使用 C,而非 C++,以保持代码简洁。 多节点训练 如果您是位手握大量 GPU 的“土豪”,llm.c 也支持多节点训练。Karpathy 表示,其见过的 llm.c 训练最多支持约 500 张 GPU。
几个小时前,Andrej Karpathy 推出了一个名为 llm.c 的项目,旨在用纯 C 语言训练 LLM,这种方法的主要优势在于它显著减少了依赖库的体积——不再需要 245MB 的 PyTorch Karpathy 在视频中首先介绍了一些 LLM 入门知识,然后以 Meta 推出的开源大模型 Llama 2-70b 为例进行了讲解。 用 C 语言实现 LLM 这次,Andrej Karpathy 单纯通过 C/CUDA 实现大语言模型训练,且无需 245 MB PyTorch 或 107 MB cPython。 从某种意义上说,Karpathy 确实在尝试重新设计 LLM 的架构。他通过 llm.c 项目探索一种更简单、更高效的训练 LLM 方法。 Karpathy 以更简单、更原始的 C/CUDA 架构来做 LLM 的训练,其中还涉及算法优化、计算资源管理等多个方面。
为了避免偏离初衷,这里必须强调——氛围编程绝不等同于借助LLM编写代码,而是在不审查LLM产出代码的情况下构建软件。 「氛围编程」可以你完全沉浸在氛围中,拥抱指数级进步,甚至忘记代码本身的存在。 遇到报错,就直接复制到对话框中让LLM去修复。代码的复杂程度已超出我的日常认知,真要理解必须逐行细读。有时LLM无法修复bug,我就直接绕过或随机调整直到问题消失。 使用LLM写代码≠氛围编程 与专业软件工程师使用LLM的方式相比,这种「忘记代码存在」的开发方式有着本质差异。 不难看出,当LLM生成代码后,软件工程师会完整地执行审查、测试,以及确保可解释性这一系列流程。也就是说,这本质上仍是传统软件开发范式。工具链中是否包含LLM,并不改变工程实践的属性。 氛围编程的价值 虽然氛围编程≠用LLM进行编程,但这并不意味着它是一种不负责任的开发方式。