00:00:00让我们来解决 Claude Code 和内存的问题，让 AI 系统能够可靠、准确地
00:00:06回答关于过去对话或海量文档的问题，是我们多年来一直
00:00:13试图解决的问题，而典型的应对方案一直是 RAG（检索增强生成），
00:00:20虽然这个视频的标题是“Claude Code 和 RAG 的七个层级”，但这个视频真正讨论的
00:00:26是解构 Claude Code、以及更普遍的 AI 系统在内存方面的问题，
00:00:33更重要的是，这个视频旨在为你提供一份路线图，向你展示你在
00:00:37这场 AI 系统与内存的博弈中所处的位置，以及为了提升到下一个层级你需要做什么。所以当我们
00:00:43探索 Claude Code 和 RAG 的这七个层级时，我们会涉及许多话题，但我们
00:00:48不会从 GraphRAG 或任何复杂的东西开始；我们要从头开始，
00:00:53也就是 Claude Code 原生的基础内存系统，因为遗憾的是，
00:00:59这不仅是大多数人开始的地方，也是他们停留的地方。从自动内存（Auto Memory）和
00:01:04claud.md 等事物开始，我们将转向像 Obsidian 这样的外部工具，最后
00:01:10与真正的 RAG 系统这些“大玩家”会合。在这些层级中，我们将讨论 RAG 究竟是什么、
00:01:16它是如何工作的、不同类型的 RAG（例如：原生 RAG、GraphRAG、代理式 RAG），以及
00:01:21重排序器（Re-rankers）等一切相关内容。在每个层级，我们都将以相同的方式进行拆解：
00:01:25我们将讨论在该层级可以期待什么、你需要掌握的技能、
00:01:29需要避免的陷阱，以及进入后续层级所需的操作。这个视频
00:01:34不会是对如何具体设置这些系统的超深入技术解释，
00:01:40因为在很多情况下我已经做过相关视频了，比如当我们讨论 GraphRAG 和
00:01:45LightRAG，甚至是更高级的话题，如这些不同嵌入系统中的 RAG Anything 时，
00:01:50我已经制作过从头到尾分解如何自行设置这些系统的视频了。
00:01:55所以在讲到这些部分时，我会链接那些视频。这对我们双方都有好处，
00:02:00这样这个视频就不会长达五个小时，但对于这些层级，我们仍会讨论
00:02:04其实际意义、每个系统能为你带来什么以及何时应该使用它。但在
00:02:09我们开始第一层级之前，先听听今天赞助商——也就是我——的一段话。就在上个月，我发布了
00:02:15Claude Code 大师班，这是从零开始成为 AI 开发者的头号途径，特别是如果你没有
00:02:21技术背景。这个大师班有点不同，因为我们专注于
00:02:25通过多个不同的用例来学习如何使用 Claude Code。其中之一就是
00:02:31生产级 RAG，即如何在现实场景中构建你在本视频中看到的 RAG 系统，并
00:02:37将其作为团队成员使用或出售给客户。这就是我们关注的内容，所以
00:02:42如果你想获取权限，可以在 Chase AI Plus 中找到，置顶评论中有链接，
00:02:47我们非常欢迎你的加入。现在让我们从第一层级开始：自动内存（Auto Memory）。
00:02:51这些是 Claude Code 自动用来创建某种内存机制的系统，以
00:02:58实际记住你谈论过的事情。如果你从未
00:03:02刻意进行任何设置来帮助 Claude Code 记住以往对话或代码库中的上下文，
00:03:09那么你就在这一层。当我们谈论自动内存时，
00:03:13它的字面意思就是“自动内存系统”，当你使用 Claude Code 时，它是自动开启的。
00:03:18基本上，它允许 Claude Code 自行创建 Markdown 文件，
00:03:26列出它认为在该特定项目中关于你的重要信息。这纯粹是
00:03:32基于它根据你的对话得出的直觉。我可以查看它创建的这些内存文件，
00:03:37它是自动完成的。如果你进入 .claud 文件夹，进入 projects，你会看到
00:03:42一个名为 memory 的文件夹，里面有一系列 Markdown 文件。
00:03:47这里有四个文件，它们就像 Claude Code 版的便签，上面写着“噢，他有一次
00:03:51提到了他的 YouTube 项目增长目标，我们把它记下来”。在每个人的
00:03:59memory 文件夹里都会有一个 memory.md 文件。你看，在这个内存文件里有一条关于
00:04:04我的技能的小笔记，然后它还有一个所有这些子内存文件的索引，
00:04:09显示这里有一个 YouTube 增长文件、一个收入文件或参考文献文件，以及里面的内容。
00:04:13所以如果我只是在 Vault 文件中与 Claude Code 聊天，并提到关于 YouTube 的事情
00:04:19或者我的增长目标之类的，它会引用这个并说“噢，是的，Chase 正在努力
00:04:23在 2026 年底前获得某某数量的订阅者”。这很贴心，但归根结底并不是那么有用。
00:04:30这有点像你在使用 ChatGPT 时，它会随机带出
00:04:35之前对话的内容，而且几乎像是强行塞进去的。这感觉就像是“行吧，我知道你记住了这个，
00:04:40但我真的不在乎，老实说，一直提这个有点奇怪，我宁愿你别提”。
00:04:44不幸的是，大多数人的内存之旅都停留在这里，而这建立在
00:04:49我们在使用这些聊天机器人时所共有的一种近乎“受虐”的过去。
00:04:54因为这些聊天机器人在对话之间没有任何真正的记忆，所以
00:05:00我们总是非常害怕关闭聊天窗口或退出终端会话，
00:05:06因为你会想“天哪，它不会记得我的对话了”。这确实是一个
00:05:10现实问题，因为面对聊天窗口无法记住任何内容，
00:05:17大家的答案是什么？答案就是你让那次对话永远持续下去，
00:05:22因为你不想遇到必须退出而导致它忘掉一切的情况。这种恐惧始于
00:05:26这些聊天窗口，从 ChatGPT 开始，Claude 的 Web 应用也是如此。
00:05:31老实说，以前 Claude 的 Web 应用情况要糟得多，我想我们都记得
00:05:35在拥有 100 万上下文窗口之前的日子，你只能和 Claude 聊 30 分钟，然后它会说“四小时后见”。
00:05:39问题是，人们把这种近乎疯狂、偏执的行为带到了终端，
00:05:45很大程度上是因为现在有了 100 万的上下文窗口，你可以这样做，
00:05:50所以他们从不清除会话，只是不停地与 Claude Code 对话，
00:05:55因为他们不想让它忘记正在谈论的内容。由于这些内存问题，
00:06:00问题在于，随着时间的推移，你在同一个会话中与 Claude Code 交流得越多，
00:06:05你的效率就会大幅下降。这就是“上下文腐烂（Context Rot）”的基本概念。
00:06:10如果你不知道什么是上下文腐烂，它是指我在同一个会话、同一个聊天中
00:06:16使用 AI 系统的次数越多，并填满了它的上下文窗口，它的表现就越差。你可以在这里看到，
00:06:23Claude Code 的 100 万上下文窗口，在 256k Token 时（即我只填满了大约四分之一的窗口），
00:06:30准确率在 92%，而到最后降到了 78%。所以你在同一个聊天中用得越多，效果就越差。
00:06:36这是人们在使用 AI 系统和内存时面临的主要问题之一。我有 Claude Code，它现在有百万级上下文，
00:06:42但我不想让它忘记对话，所以我从不关闭窗口，只是不断地填满它。
00:06:47这会导致两件事：第一，有效性会下降，正如你刚才看到的；
00:06:51第二，你的资源消耗会剧增，因为在 100 万或 80 万上下文下使用的 Token 数量，
00:06:59要比在 8 万上下文下多得多。所以这不仅是唯一的问题，
00:07:08顺便提一下，目前大家都在抱怨 Claude Code 被削弱了，
00:07:12或者我的额度自动被耗尽了。这有很多原因，但其中一个
00:07:18无疑是，自从引入 100 万上下文以来，人们根本不知道如何
00:07:24管理自己的上下文窗口，他们在清除和重置对话方面远没有
00:07:29那么积极主动。不过这有点跑题了。
00:07:34讨论这些的重点在于，当谈到内存以及关于 RAG 和 Claude Code 的讨论时，
00:07:39我们必须时刻牢记上下文腐烂，因为我们一直在处理这种紧张关系：
00:07:44一方面，我希望摄取上下文，让 Claude Code 能回答关于很多事情的问题；
00:07:50但与此同时，我不希望上下文变得太大，因为那样效果会变差。
00:07:55所以在关于内存的讨论中，这始终是我们必须思考的问题。
00:08:02回到视频本身和第一层级，人们在第一层级在做什么？
00:08:06答案是，他们其实什么也没做。正因为他们什么也没做，
00:08:10他们只能依靠臃肿的上下文窗口来记忆。如果你从未编辑过
00:08:15claud.md 文件，也从未创建过任何形式的工件（Artifact）或文件来让 Claude Code
00:08:23意识到到底发生了什么、它过去做了什么以及未来需要做什么，那么你就处于这个层级。
00:08:27那么在这个层级我们需要掌握什么呢？其实，撇开我在这里写的一切不谈，
00:08:31你只需要明白自动内存是不够的，我们需要在 Claude Code 和内存方面扮演积极的角色。
00:08:35因为这一层的一个陷阱是，如果你不扮演积极角色，你就无法掌控。
00:08:40我们需要控制 Claude Code 在回答我们的问题时所考虑的内容。
00:08:44因此，为了解锁第一层级并进入第二层级，
00:08:50我们需要显式的内存，我们需要弄清楚该如何实际操作。
00:08:57你需要编辑哪些文件，并理解它们的存在，以便在这种关系中扮演积极角色？
00:09:01现在，第二层级完全是关于一个特定的文件，那就是 claud.md。当你了解
00:09:06这个文件时，感觉它就像救星一样。终于有一个单一的地方，
00:09:12我可以告诉 Claude Code 一些我希望它始终遵循的规则和约定，而它会照做。
00:09:16事实上，我可以把希望它记住的事情放进去，它就永远会记得。起初这确实感觉像是一种进步。
00:09:20这是一个个人助手项目的标准 claud.md 文件模板。Claude Code
00:09:29会自动创建一个 claud.md 文件，但你有能力
00:09:33编辑它，甚至可以通过使用诸如 /init 之类的命令按需更新它。
00:09:38这个文件的理念是，它再次成为了那个特定项目中 Claude Code 指令的“圣经”。
00:09:43实际上，Claude Code 在执行任何任务之前都会查看这个文件。
00:09:50所以如果你想让它记住特定的事情，你会怎么做？你会
00:09:54把它放进 claud.md。理论上，它的规模比 RAG 小一些，
00:10:00我们不会把完整的文档放进去，但会放入你想让 Claude Code
00:10:05始终记住的事情以及你希望它遵循的约定。对于这一个文件，我们有一个“关于我”部分，
00:10:09有一个文件系统结构的分解，以及当我们给它指令时我们希望它如何实际操作的说明。
00:10:14就像我说的，因为它基本上会在每一次 Prompt 中被引用，所以 Claude Code
00:10:18非常擅长遵循这些。所以“我希望它记住特定事情”这种想法，
00:10:22这里似乎是个绝佳的放置地点。但我们必须小心，因为我们可能会做过头。当我们参考
00:10:28像这样的研究——《评估 agents.md》（你可以把 agents.md 换成 claud.md）时，
00:10:33研究发现，这类文件实际上可能会降低大型语言模型整体的有效性。
00:10:40为什么会这样？这是因为让它如此优秀的特质（即它被注入到基本上每一个 Prompt 中），
00:10:45也正是让它变糟的原因。我们是否真的
00:10:51注入了正确的上下文？我们是否穿透了噪音并给出了正确的信号？
00:10:57还是我们只是塞进了一些我们认为好的东西？因为如果它不是
00:11:02与你项目中几乎每一个 Prompt 都相关，那它应该出现在 claud.md 中吗？
00:11:08这是让 Claude Code 记住事情的好方法吗？我会辩称：并非如此。
00:11:15这与很多人关于 claud.md 以及你应该如何根据研究来构建它的说法截然相反。
00:11:20根据个人经验，“少即是多”。上下文污染是真实的，上下文腐烂也是真实的。
00:11:26所以，如果有些内容在 claud.md 里，但对于你给它的
00:11:32几乎每一个 Prompt 都没有意义，那它就不该在里面。但大多数人没意识到这一点，
00:11:37反而掉入了“臃肿规则手册”的陷阱。相反，我们应该掌握的技能
00:11:42是如何创建具有高信号的项目上下文。我如何确保我实际放入
00:11:48这个文件中的内容是有意义的？随之而来的就是我们在上一层级讨论过的
00:11:53对上下文腐烂的警惕。综合这些因素，第二层级感觉你一直在
00:11:57前进，比如“我在内存管理中扮演了积极角色，我有了这个 claud.md 文件”。但你会意识到
00:12:02这还不够。当我们讨论第三层级以及我们能做些什么来向前推进时，
00:12:08我们想要考虑的不是一份静态的规则手册，而是某种可以进化的东西，
00:12:14它可以包含 claud.md。与其依赖 claud.md 来完成所有事情，
00:12:18如果我们把 claud.md 用作一种指向 Claude Code 正确方向的索引文件呢？
00:12:24那么，我说的“把 claud.md 作为索引并指向其他文件”是什么意思？
00:12:30我指的是在你的代码库中采用一种架构，它不再只靠一个 Markdown 文件
00:12:37（即 claud.md）来处理所有的内存问题。我说的是针对特定任务拥有
00:12:41多个文件。我认为这方面的一个极佳示例就是 GSD（Get Shit Done）
00:12:47编排工具所做的。它不仅是创建一个文件说“嘿，这是我们要构建的东西，
00:12:53这是需求，这是我们已经做的以及我们要去的地方”，
00:12:56相反，它创建了多个文件。你可以在左边看到，我们有一个 project.md、一个 requirements.md、
00:13:02一个 roadmap 和一个 state。需求文件存在，是为了让 Claude Code 始终知道并记住
00:13:08它应该构建什么。路线图（Roadmap）分解了我们不仅是现在、
00:13:12还有过去和未来具体要创建的内容。而项目文件则给它
00:13:16关于我们正在做的事情的高层级概述内存，即我们的北极星指标是什么。通过
00:13:22在这种系统中拆分内存、上下文和约定，我们正在对抗上下文腐烂的想法，
00:13:29以及那项研究中提到的观点，即像我们在 claud.md 中所做的那样，一直将这些文件
00:13:34注入到每一个 Prompt 中，其实是适得其反的，它并不能帮我们获得更好的输出。
00:13:39此外，将其分解成这些块（Chunks），并为 Claude Code 提供一条清晰的路径，
00:13:44让它说“嘿，我想弄清楚这个信息在哪里，哦，我去查 claud.md，
00:13:49claud.md 说我有这五个选项，好的，就是这一个，让我去找它”。
00:13:54这种结构正是你在后续层级（当我们讨论 Obsidian 时）会 100% 看到的，
00:13:58而且它实际上是对我们在真实 RAG 系统中看到的块（Chunking）系统和
00:14:04向量相似度搜索的一种粗略重新构想。但显然，这一层级是小规模的。
00:14:10在这里我们讨论的是四个 Markdown 文件，而不是一个可以处理成千上万个
00:14:14文档的系统。但是，就像你会经常听我提到的那样，这
00:14:20对你意味着什么？你是否需要一个在第四、五、六、七层级讨论的、
00:14:26可以处理这么多文档的系统？答案可能是：不需要。所以 RAG 旅程的
00:14:32一部分不仅是了解你所处的位置，还包括“你究竟需要去哪里”。
00:14:36你是否总是需要处于第七层级，并知道如何在 Claude Code 中实现代理式 RAG 系统？
00:14:41知道如何做大概是件好事，但同样重要的是知道什么时候不需要
00:14:46去实现它。有时我们在这种系统中看到的这种做法，对很多人来说已经足够了。
00:14:52所以，知道如何做以及知道“你需要吗、你应该做吗”同样重要。
00:14:58当我们谈论第三层级和状态文件（State Files）时，我们如何知道自己处于这一层？
00:15:00当我们仍严格处于 Claude Code 生态系统中，尚未集成外部工具或应用，
00:15:04并且我们正处于创建多个 Markdown 文件来打造我们自己“土法制作”的
00:15:09内存分块系统的阶段，我们就知道自己在这里了。
00:15:14但这仍然非常重要，我们仍在这里掌握一些真正的技能：比如
00:15:18实际构建文档结构、建立某种在每次会话中更新状态的系统。
00:15:23因为在 RAG 中这也会是个问题：你如何确保一切都是最新的？
00:15:28而且你可能在这个阶段开始倾向于使用编排层（Orchestration Layers），
00:15:33比如 GSD 和 Superpowers，它们可以自动完成这种多 Markdown 文件架构。
00:15:40但这里有一个真实的陷阱：我们在项目中创建的内容很大程度上只是为了那个项目。
00:15:46将这些 Markdown 文件转移到另一个项目会显得有点笨拙。于是就有了
00:15:51第四层级，也就是我们引入 Obsidian 的地方。这是一个一直备受推崇的工具，
00:15:56而且理由充分。当你有像 Andrej Karpathy 这样的人在讨论
00:16:00他们创建的 LLM 知识库（其核心基本上就是建立在 Obsidian 的基础之上），
00:16:06且获得了将近 2000 万的浏览量时，我们应该听听看这究竟是如何运作的。
00:16:11为了提供背景，我之前对这个“Karpathy 式 LLM 知识库”做过完整的深度剖析，
00:16:18我会在上方链接那个视频。所以如果你想专注于如何构建它，请务必查看上方的链接。
00:16:22我还要向大多数人提到的是，我们在这里第四层级讨论的这个 Obsidian 方案，
00:16:27坦白说，这是大多数人应该追求的层级，
00:16:32因为在大多数用例中，这对大多数人来说已经足够了。当我们谈论第五、六、
00:16:37七层级时，我们会讨论真正的 RAG 结构。说实话，对大多数人来说那是大材小用。
00:16:43对大多数人来说，那确实过度了。我们喜欢谈论 RAG，这没问题，我理解，但
00:16:50Obsidian 是那个“80% 的解决方案”，实际上对大多数人来说它就是个“99% 的解决方案”，因为它免费、
00:16:56基本上没有维护开销，而且它能为独立运营者解决问题。当我说明它能为
00:17:02独立运营者解决问题时，我的意思是它解决了让 Claude Code 连接到一堆
00:17:07不同文档、一堆不同 Markdown 文件的问题，并能从中获得准确、及时的信息，
00:17:13同时作为人类，你也能对这些文档拥有洞察力。因为当我点击
00:17:19这些文档时，里面发生了什么一目了然，也很清楚哪些文档
00:17:24与之相关。当我点击这些链接时，我被带到更多的文档；当我点击这些链接时，
00:17:30我又被带到更多的文档。所以对我这个人类来说，拥有这种洞察力很重要。
00:17:36因为坦白说，我倾向于认为基于 Obsidian 的文档洞察力要优于
00:17:42很多 RAG 系统提供的洞察力。当我们讨论成千上万个文档被嵌入到
00:17:47例如像这样的 Graph RAG 系统，视觉上看起来非常棒
00:17:52看起来非常震撼。但你真的知道里面发生了什么吗？说实话，也许你知道
00:17:58但你可能只是依赖它显示的答案、链接之类的，但这很难
00:18:03确实很难逐一分析这些嵌入。总之，你应当
00:18:08特别关注 Obsidian 和 Claude Code，因为当我们讨论从 RAG 开始的这段旅程时
00:18:13我总是向所有人（包括客户）建议：让我们先从 Obsidian 开始，看看能扩展到什么程度
00:18:20最终，如果我们真的遇到了瓶颈，你随时可以过渡到更强大的 RAG 系统
00:18:26那么为什么不先尝试简单的方案呢？如果行得通，那就太棒了，而且它是免费的，不用花钱
00:18:31相比之下，去攻克 RAG 系统可能非常困难，这取决于你想实现什么
00:18:35总之，永远从简单的开始，之后过渡到更复杂的系统并不难
00:18:40那么我们在第四阶段到底在讨论什么呢？我们讨论的是
00:18:45采用我们在第三阶段开始构建的那种结构，即通过索引文件指向
00:18:50不同的 Markdown 文件，并将其规模化，然后引入 Obsidian 这个外部工具
00:18:56让你作为人类能更轻松地看清这些连接。这个版本的理想范式
00:19:00基本上就是 Andrej Karpathy 所展示的，即在 Obsidian 之上构建 LLM 知识库
00:19:05并由 Claude Code 提供支持。具体的结构大概是这样的
00:19:11当你下载并使用 Obsidian 时（再次强调它是完全免费的，参考我之前的视频）
00:19:16你需要将某个文件夹设为“库”（Vault）。把这个“库”想象成某种 RAG 系统
00:19:23一个你创建的准 RAG 系统。在“库”内部，我们进行架构设计
00:19:30仅通过文件来构建结构：有一个名为 Vault 的总文件夹，其内部
00:19:36我们创建多个子文件夹。在 Andrej Karpathy 的案例中，他谈到了三个不同的子文件夹
00:19:41实际上它们可以是任何子文件夹，只要符合我们将要讨论的主题即可
00:19:47其中一个文件夹存放原始数据（Raw Data），这是我们要摄取并最终进行结构化处理的所有内容
00:19:52以便 Claude Code 稍后引用。想象一下，你让 Claude Code 对 50 家竞争对手
00:19:58进行竞争分析，它为每家抓取了 50 个站点，对吧？我们说的是海量信息
00:20:03大约有 2500 个不同的项，所有这些都会被丢进某个原始数据文件夹
00:20:08这是数据的暂存区。然后我们有 Wiki 文件夹。Wiki 文件夹
00:20:14是存放结构化数据的地方。我们会让 Claude Code 提取原始数据，并将其结构化
00:20:20实质上是在 Wiki 文件夹中生成类似维基百科的文章，每篇文章都有自己的文件夹
00:20:28这样当你询问 Claude Code 信息时，例如
00:20:33我们让它搜索有关 AI 智能体的内容，我说：“嘿，Claude Code，跟我聊聊 AI 智能体”
00:20:38就像你查询 RAG 系统一样，Claude Code 会进入 Vault 文件夹
00:20:45从 Vault 进入 Wiki。Wiki 中有一个 Markdown 格式的主索引文件
00:20:50想想我们之前讨论过的关于 claude.md 的操作，对吧？你会看到这些主题
00:20:56是如何在不同阶段中过渡的。它会查看主索引，主索引会告诉它
00:21:00这个 Obsidian RAG 系统中存在什么。哦，有 AI 智能体，太酷了。你猜接下来会发生什么？
00:21:08它还有一个索引文件，列出了现有的具体文章。我想表达的是
00:21:14当 Claude Code 想要查找文件信息时，它有一套清晰的层级结构可以参考
00:21:21从 Vault 到 Wiki，到索引，再到文章等等。正因为查找信息的路径如此清晰
00:21:31而且将信息转化为 Wiki 的过程也非常明确，我们可以创建一个包含海量文档的系统
00:21:37即便没有 RAG，如果你操作得当，处理成百上千篇文档也没问题。因为如果系统逻辑清晰
00:21:44即：“检查 Vault，检查索引”，且每处都有明确的界定。那么
00:21:50Claude Code 弄清楚去哪儿找东西并不难。因此，你可以用非 RAG 结构
00:21:54来处理数千个文档，这在过去是很困难的。这主要是因为
00:21:58大多数人根本不建立任何结构，只是把海量文档堆在一个文件夹里
00:22:02这就像是把 1000 万个文件散落在工厂地板上，然后问：“Claude Code 能找到它吗？”
00:22:08不，你其实只需要一个档案柜。Claude Code 实际上非常聪明
00:22:13你可以从这里看到这种架构。现在我们看到的是一个 claude.md 文件
00:22:17它位于一个 Obsidian 库中。它说了什么呢？它拆解了
00:22:24Vault 结构、Wiki 系统，以及子文件夹的总体结构
00:22:30以及具体的运作方式，对吧？同样，我们在这里把 claude.md 用作约定类文件
00:22:36在左侧，你可以看到 Wiki 文件夹。Wiki 文件夹内有一个主索引
00:22:43列出了其中的内容。在本例中，只有一篇文章，是关于 Claude 托管智能体的
00:22:49在这个文件夹里，我们看到 Claude 托管智能体，它有自己的 Wiki 文件夹
00:22:55用于拆解文章内容。所以它需要采取的步骤非常清晰。当我告诉 Claude Code
00:23:01跟我聊聊托管智能体时，我们已有相关 Wiki。它很容易通过
00:23:06内置的 grep 工具进行搜索。它会链接到具体的 Markdown 文件，然后拆解所有内容
00:23:12那么第四阶段的问题就变成了规模化的问题。这种系统
00:23:16能支持多少文档而不崩溃？是否有一个临界点
00:23:22会导致 Karpathy 的系统开始瓦解？即便路径很清晰
00:23:26Claude Code 需要遵循索引等等。但当文档达到 2000、2500 或 3000 份时
00:23:31它还能维持吗？是否有明确的数量限制？答案是：我们并不知道
00:23:37而且这个临界点可能会更早出现，因为文档各不相同。所谓的遇到瓶颈
00:23:43并不只是 Claude Code 给出错误答案，或者系统里文件太多
00:23:47还包括：现在加了这么多文件，消耗了多少 Token？以及它的响应速度有多快？
00:23:52因为在某些情况下，RAG 实际上可能快得多，也省钱得多
00:23:59我们现在看的是纯文本 LLM（图中长条所示）与纯文本 RAG 之间的比较
00:24:06比较的维度是获取正确答案所需的 Token 数量以及
00:24:11消耗的时间。我们看到了什么？纯文本 RAG 与纯文本 LLM 之间
00:24:18存在巨大差异，量级在 1200 倍左右。我的意思是
00:24:25在这些研究中，RAG 比纯文本 LLM 便宜 1200 倍，快 1200 倍。当然
00:24:33背景是这些研究是在 2025 年完成的，并未使用 Claude Code。模型自那时起已发生了巨大变化
00:24:37这些只是普通的 LLM，不是针对编码的。然而，我们讨论的是 1200 倍的差异
00:24:48所以，在评估该用 Obsidian 还是用 RAG 系统时，情况并不简单
00:24:54不仅仅是能不能给对答案的问题。因为可能存在一种情况
00:24:59你在 Obsidian 中能得到正确答案，但如果改用 RAG，成本会便宜一千倍
00:25:04速度也会快一千倍。因此，在“Obsidain 什么时候够用”与
00:25:10“这种 Markdown 架构什么时候该转向 RAG”之间，界限非常模糊
00:25:15我没有一个标准的答案。答案是你必须亲自实验
00:25:18你需要尝试两种方案，看哪种有效。毕竟之前的研究已有些过时，那是 2025 年的老模型了
00:25:25现在的 RAG 与纯文本 LLM 的差距可能不是 1200 倍，但这个差距缩小了多少呢？
00:25:32因为 1200 倍是一个疯狂的差距。这不是 10 倍，而是 1200 倍。所以你需要了解很多细节
00:25:39同样，你无法预先知道答案。真的不知道。即使你看遍了所有视频
00:25:45也没人能告诉你那条界线在哪。你只能亲自实验
00:25:49随着你让 Claude Code 回答问题的文档量增加，去观察什么最适合你
00:25:54基于这一点，让我们进入第五阶段，我们将终于开始
00:25:59讨论真正的 RAG 系统，并讨论 RAG 的一些基础概念，如嵌入（Embeddings）
00:26:04向量数据库，以及当数据成为 RAG 知识库的一部分时，它是如何流动的
00:26:10让我们先从朴素 RAG（Naive RAG）谈起，它是最基础的 RAG 类型
00:26:16但它为我们后续的一切奠定了基础。你可以认为
00:26:21RAG 系统被分为三个部分：左侧是嵌入阶段
00:26:27中间是向量数据库，右侧则是通过大语言模型进行的实际检索
00:26:33也就是步骤 1、2、3。为了更好地说明这个模型
00:26:40让我们以一个即将成为知识库一部分的文档的“旅程”开始。记住
00:26:45在一个大型 RAG 系统中，我们可能讨论的是数千个文档，每个文档可能有数千页
00:26:50但在本例中，我们讨论的是一个只有一页的文档
00:26:56如果我们想把这个文档添加到数据库中，它的运作方式并不是将其作为一个整体摄取
00:27:03相反，我们会把这个文档切分成若干片段（Chunks）。所以这一页纸
00:27:08基本上变成了三个不同的片段。这三个片段随后被发送到嵌入模型
00:27:15嵌入模型的工作是将这三个片段转化为向量数据库中的一个向量
00:27:21向量数据库只是标准数据库的一种变体
00:27:27说到标准数据库，想想 Excel 文档，对吧？你有列和行
00:27:32但在向量数据库中，它不是二维的列和行，它实际上是
00:27:37成百上千个维度。不过为了方便今天理解，就把它想象成
00:27:43这里看到的这种三维图表。向量就是图表中的点
00:27:50每个点由一系列数字表示。你可以看到这里有香蕉（bananas）
00:27:57它的坐标是 0.52、5.12 和 9.31，你可以在上面看到。这种数字序列会持续数百个
00:28:06每个向量在巨大的多维图表中的位置取决于它的语义
00:28:13也就是说，这些词到底是什么意思。你可以看到，这边就像是水果区域
00:28:19有香蕉、苹果、梨。而这边是船只区域，有大船和小船
00:28:24回到我们的文档，假设这个文档是关于二战舰船的
00:28:31那么每个片段都会被转化成一系列数字，而这些数字
00:28:37将作为图表中的一个点。你觉得它会落在哪里？
00:28:42它们大概会落在这一区域，对吧？这就是片段 1、2、3。这就是文档被放置的方式
00:28:49每个文档都会被切分，每个片段经过嵌入模型，然后由嵌入模型
00:28:54插入到向量数据库中。对每个文档重复此操作。最终
00:28:58在重复几千次后，我们就得到了一个代表我们知识图谱或知识库的
00:29:04向量数据库。这把我们带到了第三步，即检索部分
00:29:09那么在这个过程中你处于什么位置？通常，让我们来描绘一下你
00:29:16给你换个颜色，你是粉色的。这就是你。通常你只是
00:29:23与 Claude Code 交谈，问它关于二战战舰的问题。那么
00:29:29在标准的非 RAG 设置中，会发生什么？大语言模型（假设是 Opus 4.6）会查看
00:29:34它的训练数据，然后根据其训练数据中关于二战战舰的信息
00:29:39给你一个答案。但在 RAG 系统中，它会做得更多。它会
00:29:44检索相关的向量。它会利用这些向量来增强它为你生成的答案
00:29:51这就是“检索增强生成”（RAG）的含义。这就是 RAG 的力量，它允许大语言模型
00:29:56调取不属于其训练数据的信息，来增强其回答。在本例中
00:30:02是二战战舰，虽然模型已经知道了，但请把这替换成
00:30:06任何企业私有数据，那些在互联网上无法获取的信息，并进行规模化处理
00:30:15这就是 RAG 的卖点。现在在我们的例子中，当我们向 Claude Code 询问
00:30:21关于二战战舰的信息，并且是在 RAG 设置下，它会做的是
00:30:25提取我们的问题，并将其转化为一串数字，类似于这边的向量
00:30:32然后它会查看我们问题的数字以及这些向量的数字
00:30:39看哪些向量与问题的向量最匹配。对吧？
00:30:46基本上就是看向量与问题的相似度。然后它会提取一定数量的向量
00:30:51可能是 1 个、3 个、5 个、10 个或 20 个，并将这些向量及其包含的信息
00:30:56导入大语言模型。所以现在大语言模型拥有了
00:31:02它的训练数据答案，外加（假设）10 个向量的信息。这就是检索部分
00:31:09然后它利用这些额外信息进行增强并生成答案。这就是 RAG 的原理
00:31:13也是朴素 RAG 的运作方式。但由于多种原因，这并不是特别有效
00:31:19这种非常基础的结构在开始阶段就会出问题，当我们开始思考：
00:31:25我们该如何切分这些文档？是随机的吗？是纯按 Token 数量吗？
00:31:31是否有一定的重叠度？文档本身的设置方式是否
00:31:36适合切分？因为万一片段 3 引用了片段 1 中的内容
00:31:42而在我们的向量检索中，如果它没有拿到正确的那一部分，会怎样？如果它没拿到
00:31:47作为上下文所需的另一个片段，那片段 3 的内容还说得通吗？
00:31:53我的意思是，通常需要整个文档才能回答关于该文档的问题
00:31:59所以这种零碎的回答在实践中并不奏效
00:32:05然而这就是 RAG 长期以来的设置方式。其他可能出现的问题还包括
00:32:10如果我想询问不同向量之间的关系怎么办？因为
00:32:17目前我只是孤立地提取向量。但如果我想知道小船与
00:32:22香蕉的关系呢？听起来很随机，但如果我真的想知道呢？在
00:32:31标准向量数据库朴素 RAG 方法中，一切都是孤立的，很难连接信息
00:32:36很大程度上取决于原始文档的结构是否良好，结构是否适合
00:32:41进行 RAG。这些年来，我们想出了一些办法来缓解这些问题
00:32:46比如重排序器（Re-rankers），或者说排序系统，它们会查看我们抓取的所有向量
00:32:51然后用大语言模型再处理一遍，按相关性对它们进行排序。但是
00:32:56总的来说，这种朴素 RAG 系统已经逐渐过时了。尽管如此，理解其基础原理
00:33:03仍然非常重要，这能为你选择更强大的 RAG 方案提供参考
00:33:07因为如果你不理解切分（Chunking）或嵌入（Embeddings）是如何工作的
00:33:13你怎么能就文档结构做出决策？尤其是当我们要谈论
00:33:17Graph RAG 或更复杂的嵌入系统时。比如 Google 最新的系统
00:33:22它不仅可以处理文本，还可以处理视频。如果你不理解这种基础
00:33:27你就很难看清这个陷阱。陷阱在于，我们可能只是
00:33:31创建了一个蹩脚的搜索引擎。在这些只能提取片段且无法理解
00:33:36片段间关系的朴素 RAG 系统中，这和单纯的、过于复杂的
00:33:42Ctrl+F 系统有什么区别？答案是：没多大区别
00:33:48这就是为什么在这些简单且过时的 RAG 结构中（虽然它们现在依然到处都是）
00:33:54如果你看到有人说：“这是我的 Pinecone RAG 系统”或“这是我的 Supabase RAG”
00:33:58而他们完全没提到 Graph RAG，也没提到诸如
00:34:03“我们拥有复杂的重排序系统”之类的内容，那么这个系统会很烂
00:34:07烂到什么程度？大概只有 25% 的时间能给对。这几乎跟靠猜没区别
00:34:12所以如果你事先不知道这一点，你很容易被忽悠或困惑，某些情况下
00:34:18甚至会被骗去购买那些根本不合理的 RAG 系统。所以第五阶段并不是
00:34:23关于实现这些朴素 RAG 系统，而是关于理解它们的工作原理
00:34:28这样当你需要实现更复杂的系统时，你才能真正明白发生了什么
00:34:34因为这种对 RAG 的五分钟解释，遗憾的是，并不是大多数喊着“我需要 RAG 系统”的人能理解的
00:34:38那么，你真的需要 RAG 吗？你还必须问问自己，你到底在向系统
00:34:43提什么样的问题。如果你只是把知识库当作一个巨大的规则手册
00:34:48你只需要调取其中特定的内容，那么 Obsidian 可能就足够了
00:34:54或者你甚至可以用朴素 RAG 系统糊弄过去。但如果我们想知道
00:34:59事物间的关系，想知道 X 是如何与 Y 交互的，而它们又是两个独立的文档
00:35:02文档里甚至从未提到过彼此。而且因为有成千上万个文档
00:35:09我也没法直接把它们全塞进上下文。那么，在那时，你就需要 RAG
00:35:13而且你需要比基础向量 RAG 更复杂的东西。那就是我们要开始讨论
00:35:19Graph RAG 的时候了。所以当我们谈论 Claude Code 与 RAG 的第六阶段时
00:35:23我们讨论的是 Graph RAG。在我看来，如果你打算使用 RAG
00:35:29这是你应该构建的最底层的架构水平。这里使用的是 Light RAG
00:35:34这是一个完全开源的工具。我会在上面放一个链接，详细拆解如何使用
00:35:39和构建它。但 Graph RAG 的核心理念非常直观：即万物皆有联系
00:35:44这不再是一个装满孤立向量的向量数据库，而是一堆相互连接的事物
00:35:50对吧？我点击这个文档，可以在右侧看到（我把它移过来）
00:35:55向量的描述、名称、类型、文件、片段，以及更重要的：各种不同的关系
00:36:00这种基于关系的方法会产生更有效的成果。这是一张来自 Light RAG GitHub 的图表
00:36:05大约是 6 到 8 个月前的。另外值得注意的是，Light RAG 是目前我所知的
00:36:10最轻量级的 Graph RAG 系统。当然也有一些非常强大的版本，包括来自 Microsoft 的 GraphRAG
00:36:15它真的就叫 GraphRAG。但当我们将朴素 RAG 与 Light RAG 全面对比时
00:36:23我们经常能看到超过 100% 的性能提升，对吧？比如 31.6 对比 68.4
00:36:3024 对比 76，24 对比 75 等等。也就是说，根据 Light RAG 的数据
00:36:35它甚至能稳住阵脚并击败 GraphRAG 本身。不过这是它们自己的数据，仅供参考
00:36:4324 对 75 等等，而且根据 LightRAG 的说法，
00:36:49它实际上能够保持优势并击败 GraphRAG 本身，但这些是 LightRAG 的数据，所以
00:36:54仅供参考。现在当我们看这个知识图谱系统时，你脑子里
00:36:58可能会立刻想到 Obsidian，因为它们看起来非常相似。然而，我们在这里看到的
00:37:04Obsidian 图像比 LightRAG 或任何 GraphRAG 系统中进行的处理要原始得多，
00:37:10因为我们在这里看到的这一系列连接全都是手动的且有些随意，它之所以连接
00:37:16只是因为我们在生成此特定文档时，手动或通过 Claude Code 设置了相关文档，
00:37:22例如，只需添加几个括号，砰的一声，文档就连接上了。
00:37:27所以理论上我可以连接一堆随机的、实际上毫无关系的文档。
00:37:30虽然 Claude Code 并不笨，它不会那样做，但这与这里发生的事情大不相同，
00:37:35比如这经过了一个实际的嵌入系统，它查看了实际内容，
00:37:41设置了关系，发送了实体，在 LightRAG 内部为了定义这些关系，
00:37:46做了比 Obsidian 多得多的工作。那么这种差异是否真的
00:37:52等同于在低水平性能上的巨大差距呢？在巨大的规模下，也许吧，再次强调，
00:38:02我们处于某种灰色地带，这取决于你的规模和我们具体讨论的内容，
00:38:07除了你和一些个人经验外，没人能回答这个问题。但要理解这两者
00:38:13并不相同。兄弟，我们是不一样的，这是两个完全不同的系统，
00:38:20一个是相当复杂的，一个是相当原始的。明白这一点，所以总结一下第六级 GraphRAG，
00:38:26当我们决定像 Obsidian 这种东西行不通时，我们就在这个级别了，我们不能使用
00:38:31像 Naive RAG 这样的东西，因为它就是没用，我们需要能够提取实体
00:38:36和关系的东西，并真正利用这种混合向量加图查询的系统设计。
00:38:43但这里也存在一些陷阱和严重的障碍，即便是在第六级，当我们谈论
00:38:48LightRAG 时，这只是文本。如果我有可扫描的 PDF 怎么办？如果我有视频、
00:38:55图像怎么办？我们并非生活在一个所有文档都只是 Google 文档的世界里，
00:39:01那么在这些情况下我们该怎么办？所以多模态检索是一件大事，除此之外，
00:39:06给这些系统增加一些 Agent 特性，赋予它更多的 AI 能力，或者说在那个领域提升一下如何？
00:39:11如果我们谈论的是多模态的事物，那么我们终于可以进入
00:39:17当今时代 RAG 的最前沿了，截至 2026 年 4 月，这就是第七级的内容。
00:39:24现在当我们谈论第七级 Agentic RAG 时，我们真正想要重点关注的是
00:39:31与多模态摄取有关的事物。我们已经做过关于这些内容的视频了，比如
00:39:36Rag-Anything，它允许我们将图像和非文本文件（再次想到可扫描的 PDF）
00:39:44导入到你在这里看到的 LightRAG 知识图谱结构中。我们还有像 Gemini
00:39:49Embedding 2 这样的新发布，它刚刚在三月份推出，允许我们将视频直接
00:39:56嵌入到我们的向量数据库中，就是视频本身，坦白说，这就是空间发展的方向。仅处理文本
00:40:01文档是不够的。有多少信息、多少知识被困在互联网上，特别是在像 YouTube
00:40:06这样的地方，那里纯粹是视频，而且我们也想要比单纯的文稿更多的东西。
00:40:10文稿做得还不够，所以这种多模态问题是现实存在的，再次强调，这些东西
00:40:16几周前才出来。第七级也是我们需要开始关注
00:40:20当涉及到 RAG 系统进出的数据时的架构和管道的地方。仅仅把数据放进去是不够的，
00:40:25这很好，你知道，好吧，我们有了所有的这些连接什么的。但数据是怎么到那里的？
00:40:30在团队协作的背景下，数据是如何到达那里的？数据又是如何出来的？
00:40:35如果某个特定文档中的某些信息发生了变化怎么办？如果有人编辑了它，
00:40:40它该如何更新？如果我们添加了重复项怎么办？在生产级别的事物上，究竟谁能
00:40:46把这些东西放进去？这些都是你需要开始问自己的问题。
00:40:50所以当我们看一个像 n8n 的这种 Agentic RAG 系统时，你可以看到绝大多数的架构，
00:40:54这里列出的所有内容全都是关于数据摄取和数据同步的。
00:41:01只有很小一部分是关于 RAG 的，就在那里。因为我们需要能够清理数据的系统，
00:41:06能够检查：好吧，我们刚刚摄取了这个文档，事实上这是第一版的第二版，
00:41:11我们现在能回去清理那些数据吗？这是一个数据摄取管道，文档不会被
00:41:17直接放入系统或 LightRAG 中，相反，我们会把它放在像 Google Drive 之类的地方，
00:41:21然后从那里被摄取到 GraphRAG 系统中并记录下来。这些就是当你
00:41:27真正实际使用 RAG 系统时，会决定其成败的事情。当我们谈论 Agentic RAG 时，
00:41:31你可以看到这里，我知道这相当模糊，但如果我们有一个 AI Agent 在运行整个程序，
00:41:37想象一下你为你的团队设置了某种聊天机器人。它是否总是需要访问这个数据库？
00:41:42答案可能是不需要。在团队环境、商业环境中，你很可能
00:41:49会有存在于这种数据库中的信息（如文本等），但你可能还有
00:41:54另一套数据库，比如标准的 Postgres 数据库，里面有一堆你想要
00:41:58用 SQL 查询的信息。所以当我们谈论 Agentic RAG 系统时，我们需要一个具备所有这些能力的系统，
00:42:03能够智能地决定：哦，我是要去访问这里代表的 GraphRAG 数据库，
00:42:08还是仅仅在 Postgres 中进行一些 SQL 查询。这些事情会变得很复杂，对吧？
00:42:15而且这一切都取决于用例，这就是为什么有时很难制作这些视频并尝试
00:42:20涵盖每一个边缘案例。第七级的重点并不在于必然存在某种你从未听说过的
00:42:23超级 RAG 系统，而在于细节决定成败，而这主要在于
00:42:30数据摄取部分以及保持数据更新，还有就是你实际上如何访问这东西。在演示中很容易做到，
00:42:34就在这里，哦，我们直接去 LightRAG 界面，去检索，然后提问。但当我们在
00:42:39讨论团队使用，且每个人都从不同角度接入时，情况就不同了，而且你
00:42:46可能不希望每个人都能通过 Web 应用直接上传到 LightRAG 本身。
00:42:50话虽如此，对于想要创建能够处理多模态事务的复杂 RAG 系统的
00:42:55独立运营者，我建议采用 Rag-Anything 加 LightRAG 的组合。
00:43:01我做过关于这个的视频，如果我还没放链接，我会把它链接在上面。我推荐这个有几个原因，
00:43:07第一，它是开源的且轻量级的，所以你不需要花费大量的金钱或时间
00:43:14来运行这样的系统，以确保它确实符合你的用例。
00:43:19再次强调，我们想要的是不要被困在没有出路的系统中，
00:43:26而且我们花了大量的钱才走到那一步，这就是为什么我非常喜欢 Obsidian，而且我总是推荐
00:43:31像 LightRAG 和 Rag-Anything 这样的东西，因为嘿，如果你尝试了发现它对你没用，
00:43:37或者不合理，那也没关系，你只是浪费了几个小时，你知道，这不像你
00:43:42在微软的 GraphRAG 上花了一大笔钱，那可一点都不便宜。
00:43:45那么你怎么知道自己处于第七级呢？真正的多模态需求：你需要索引图像、表格和视频，
00:43:50并且你正在集成某种 Agent 系统，让它能智能地决定走哪条路径
00:43:56来回答信息。因为在第七级，你可能正在整合所有这些东西，你可能
00:44:02有一个包含一些永久信息的 Claude MD 文件，可能在一个代码库中包含一些
00:44:06为了方便检索而设计的 Markdown 文件，也许你还包含了 Obsidian，
00:44:12它在某个库中，加上你可能还有一部分文档在 GraphRAG 数据库中，
00:44:16并且你有一个处于漏斗顶端的 AI 系统，它可以决定：他们问了这个问题，我走
00:44:20这条路线。这是我会建议的一种成熟的记忆架构。但这里的陷阱是什么？
00:44:25陷阱坦白说就是当不需要这种复杂程度时，还强迫自己进入这个级别。
00:44:33老实说，在看完这些之后，你们中的大多数人用 Obsidian 就行了。这已经绰绰有余，
00:44:40你不需要 GraphRAG，你真的不需要普遍意义上的 RAG。如果你觉得不明显
00:44:47需要第七级，而且当然如果你还没试过 Obsidian 的路线，你不需要待在这里，
00:44:52这很可能是浪费你的时间。但这个视频的全部目的，是尽我最大的努力
00:44:57让你接触到我所看到的 RAG、记忆和 Claude Code 的不同级别，以及
00:45:01这个问题是什么，存在哪些张力，权衡是什么，以及根据你的用例
00:45:07你应该处于什么位置。再次强调，最重要的事情就是实验。你不需要在进入之前
00:45:12就知道答案，只需去尝试。如果可以的话，我会建议按升序尝试。如果你能
00:45:18仅靠 Claude 系统中的 Markdown 文件解决，且它基本上就是加强版的 Claude.md，太棒了，去用吧。
00:45:24然后尝试 Obsidian，如果 Obsidian 还不够，尝试 LightRAG 等等。所以
00:45:28这就是我今天要留给你们的内容。如果你想了解更多，特别是关于 RAG 的生产端，
00:45:34比如如何为团队运行这个，或者为客户打包，我们在 Chase AI Plus 内部
00:45:39有一个完整的模块。所以去看看那个。除此之外，让我知道你的想法，
00:45:43我知道这视频挺长的，我们回头见。
00:45:47我知道这是一个很长的过程，我会在附近见到你
00:45:52我会再见面的