LLM Wiki不是RAG的平替，选错架构准确率反降12%_服务软件

1. 如何评价Karpathy提出的个人知识库的架构？

2. RAG退潮，“文件系统+grep”回归，智能体检索的返璞归真

3. Karpathy 的新想法：用 LLM 给自己建一个会自我生长的个人知识库。大多数人用 AI 处理文档的方式都是 RAG——把文件上传，提问时检索相关片段，生成答案。这能用，但有个根本问题：每次提问，AI 都在从零开始重新发现知识。没有积累，没有沉淀。问一个需要综合五篇文章的问题，它每次都要重新拼。NotebookLM、ChatGPT 文件上传、绝大多数 RAG 系统，本质都是这套逻辑。Karpathy 的想法完全不同，他叫它 LLM Wiki。1. 核心思路——知识库是编译过的，不是每次现查的不是把文档丢给 AI 等它检索，而是让 AI 主动维护一个结构化的 wiki——一组互相链接的 markdown 文件。每加入一篇新文章：AI 读它、提取关键信息、更新相关词条页面、标注新内容和旧内容的矛盾、把综合的结论写进去。知识编译一次，持续更新，不是每次查询都重来。本质上是：知识在 wiki 里复利增长，而不是在对话里一次性消耗。2. 三个组成部分1）Raw Sources（原始文档）：你收集的所有原始资料，AI 只读、不改，是知识的源头2）Wiki（AI 维护的知识库）：结构化的 markdown 文件集合，AI 全权负责写和更新3）Schema（规则文件）：告诉 AI 这个 wiki 怎么组织、什么格式、什么工作流——是整个系统的配置文件，放在 CLAUDE.md 或 AGENTS.md 里3. 三个核心操作1）Ingest（摄入）：丢进一篇新文章，AI 读、讨论、写摘要、更新10-15个相关词条2）Query（查询）：问问题，AI 查 wiki、综合答案——好的答案可以直接存回 wiki，让探索的成果沉淀下来3）Lint（维护）：定期让 AI 检查 wiki 健康状态——找矛盾、找孤岛页面、找缺失的交叉引用Karpathy 还提了一个新概念——「Idea File」他说：在 LLM Agent 时代，分享"具体代码/应用"的意义越来越小，因为每个人的 agent 都能自己把想法落地。更有价值的是分享想法本身——一个抽象的 idea file，把核心模式讲清楚，剩下的让你自己的 agent 根据你的需求定制实现。这个 gist 本身就是一个 idea file 的示范：没有具体代码，只有模式描述，然后让你扔给自己的 agent 去落地。访问：gist.github.com/karpathy/442a6bf555914893e9891c11519de94f#HOW I AI# #程序员#

4. Boris（Claude Code 创始人）解释为什么 Claude Code 不用 RAG 向量检索代码：在开发 Claude Code 的早期版本时，我们曾尝试过 RAG 搭配本地向量数据库的方案。但很快我们就发现，Agent 使用关键字搜索在实际应用中的表现通常要出色得多。这种方案不仅实现起来更加简洁，而且还完美避开了 RAG 模式下那些令人头疼的“老毛病”：比如数据安全性、隐私泄露风险、信息滞后以及系统可靠性等问题。

5. 个人知识库相比大模型已有海量知识，是否存在独特价值？如果知识库录入越来越多，假设达到了大模型训练数据的 1/1000, 这时候个人知识库是不是没有意义了？因为它的回答和分析，跟训练后的大模型输出结果也许趋于相同？简单直接的回答是：恰恰相反，你的知识库越大，它的“主权价值”和“差异化价值”反而越高，甚至会成为你相对于通用 LLM 的核心壁垒。以下从几个维度来拆解为什么“趋同”是一个伪命题：1. “1/1000” 的含义：信号密度 vs. 数据总量目前的顶级模型（如 Llama 3 或 GPT-4）训练数据动辄在 15 Trillion (15万亿) tokens 以上。如果你个人的知识库达到了它的 1/1000，那就是 15 Billion (150亿) tokens。- 规模参考：整个英文维基百科大约只有 40 亿 tokens。- 分析：如果你拥有一个 150 亿 tokens 的私有知识库，这里面的信息熵（Information Entropy）远高于通用互联网数据。通用模型是“万金油”，它是对全人类平庸知识的最大公约数（Statistical Average）；而你的知识库是针对特定研究领域的高精度垂直采样。2. “平均值” vs. “特异性”：逻辑趋同，但结论可能相反即便模型通过训练“见过”你知识库里的某些公开发表的内容，它在输出时也会被大量的通用语料“稀释”。- 平庸的答案： LLM 的预训练权重倾向于给出最稳妥、最符合大众认知的回答。- 你的“Edge”：你的知识库里包含你个人的 Vibe、你的非共识论据、以及你私有的实验数据。- 结论：知识库存在的意义不是为了重复 LLM 已有的知识，而是为了校准（Alignment）和对抗（Counter-steering）。当 LLM 的权重倾向于 A 时，你的知识库能通过 RAG 强行将它拉回到更深刻的 B。3. 确定性与“溯源”：解决幻觉的终极手段这是 Karpathy 和 Lex Fridman 都非常看重的一点。- 权重是模糊的：模型训练完后，知识被揉碎成了概率分布。你无法确定它说出某个观点是基于哪篇论文。- 知识库是精确的：无论库多大，它始终提供 Citations（引用）。在专业研究中，一个无法溯源的“正确答案”往往是没用的；而一个能够回溯到原始 .md 文件和图片的论证才是真正的资产。4. 动态更新与“时间差”：权重是死的，知识库是活的LLM 的训练数据有 Knowledge Cutoff（知识截止日期）。- 即便是 1/1000 的量级，如果这部分数据是过去 6 个月内产生的、或是你正在进行的实时研究，通用 LLM 的权重里根本不存在这些信息。- 在 Agent Native 的工作流中，知识库是你的 L2 Cache。只要你还在源源不断地产生新 token，你的库就永远领先于模型的权重更新。5. 合成数据的“炼金术”正如你之前提到的“输出原文不直接包含的论据”，当你的库大到一定程度，你其实是在进行更高阶的合成。- LLM 是 CPU，知识库是 RAM： CPU 再强，没有大内存也跑不动复杂的任务。- 反哺训练：当你的库达到 1/1000 量级，你已经具备了微调（Finetuning）一个专属模型的资格。这时候，知识库不再是“没意义”，而是进化成了“种子语料”，让你从“调教 Agent”上升到“训练专属大脑”。总结：如果把通用 LLM 比作一个博学但健忘的教授，你的知识库就是他手边那叠永不磨灭的、带有他个人批注的、且实时更新的精密笔记。教授越博学，那叠笔记反而越珍贵。因为笔记不再需要记录“1+1=2”这种常识，它会进化到只记录最前沿的、最私密的、最能产生逻辑增量的核心洞察。所以，别担心趋同。当你积累到 1000 个文件甚至更多时，你只会发现通用 LLM 越来越像一个“好用的翻译官或打字员”，而真正的“灵魂和护城河”都在你的 .md 文件里。（附图附带排版，内容相同）

6. 在开发AI解决方案时，传统向量数据库或记忆API常面临延迟高、成本昂贵等问题。OpenMemory是一款开源、自托管的AI记忆引擎，通过独特的分层记忆分解架构，实现了长期、语义、情境记忆的高效存储与检索。它不仅支持多种嵌入模型，还能为AI助手、代理和协同工具提供持续、透明的记忆服务。主要特点包括：- 结构化记忆：利用分层设计，实现多领域记忆存储，无数据冗余 - 高效检索：多向融合检索机制提供更低延迟的记忆回溯 - 开放自托：源代码公开，自行部署，100%数据归属用户 - 跨平台支持：兼容OpenAI、Gemini、Ollama等多种嵌入方案 GitHub：github.com/CaviraOSS/OpenMemory通过OpenMemory，开发者能为AI系统赋予更丰富、灵活的记忆能力，实现更智能、高效的交互体验。

7. 250份文档投毒，一举攻陷万亿LLM！Anthropic新作紧急预警

8. 大模型（LLM）和智能体（Agent）有什么区别？

9. 【LLM智能体正在成为新一代高级编程语言】一个大胆的假设：C语言之于汇编，Java之于C，Python之于Java，现在LLM智能体正在对所有编程语言做同样的事。这里说的LLM智能体，指的是一种全新的开发模式：多个智能体并行工作，大部分时间自主运转，只在关键节点需要人类介入。判断这个假设是否成立的标准很简单：如果一个开发者借助多智能体能产出十倍于从前的成果，那它就是真的。2026年初的今天，我还不能完全确定，但已经在认真考虑这种可能性。对于在软件行业摸爬滚打多年的人来说，质疑声不会少。先回应几个常见的：“十倍代码量不等于十倍产出，那只是垃圾代码。”没错，衡量标准应该是实际交付的功能价值，不是代码行数。如果假设成立，真正的“代码”其实是你给LLM的指令。“LLM是给不会写代码的人用的。”LLM确实会带来大量新程序员，但这不意味着老手用不上。事实上，很多资深开发者正在借助LLM实现产出的飞跃。“用LLM就是偷懒不想动脑。”恰恰相反。当你用LLM做更多事情时，你需要思考和工作得更多，而不是更少。管理一支智能体舰队比自己写代码更费心力，因为你要设计的东西是原来的好几倍。“LLM会让我们的编程技能退化。”可能吧。但我们在工作中也不会担心汇编或C语言技能生疏。大多数人只在业余时间练习这些，因为没人能证明用汇编写业务代码会更高效。“LLM写的代码比我差太多。”几乎肯定如此。但你的汇编代码也比不上专家。只要LLM生成的代码足够高效，能跑起来，就已经可以交付了。系统会丑一些，但它能用。“用LLM智能体太贵了。”如果它们能带来50%的生产力提升，对比你的薪资，其实一点都不贵。而且LLM只会越来越便宜。它们只在绝对值上贵，相对值上并不贵。“我试了一下午，纯粹浪费时间。”学习曲线是存在的。想想你当初花了多少时间和编程工具、语法搏斗，才勉强上手。以上这些反对意见在逻辑上都站不住脚，但情感上确实不容易接受。真正触及核心的问题有两个：质量和可理解性。LLM生成的代码会不会很快变成一堆垃圾？我们是不是在沙子上建房子？LLM生成的代码量会不会大到我们永远无法理解？即使系统能跑，我们是否会因为不理解而永远失去控制？我认为质量和可理解性应该成为任何LLM编程框架的核心目标。从经济角度看，只追求质量是不够的。可理解性可能是浪漫主义的幻想，也可能是一个值得押注的长期赌注。我选择后者。有趣的是，LLM比以往任何高级语言都更具非确定性。但它们也能在高层次描述上帮你理清思路，这是以前任何抽象层都做不到的。未来的开发会是什么样子？我看到四个核心要素：文档是一组描述系统规格的页面，包括目的、核心实体、接口、约束、关键流程和编码规范；实现是代码库加上所有数据，代码库应该能从文档重建，数据应该与文档描述一致；对话是多个智能体在执行任务时产生的思考流，人类可以随时查看或介入；任务是一组动态的离散工作单元，可以嵌套，有状态追踪。两个存量，两个流量。文档和实现是系统的积累，对话和任务是构建它们的过程。人类当然可以直接修改文档和实现，但这种情况会越来越少，因为大部分工作流是智能体驱动的，人类主要在与智能体交互。智能体可以扮演多种角色：独立完成任务的执行者、协调下一步的管理者、试图破坏新功能的测试者、脱离上下文审查代码的评审者、解决冲突的合并者。重要的是人类可以灵活配置，指令可以是一次性的，也可以是文档的一部分。MCP协议带来了一个打破应用孤岛的机会。它可以被视为一种通用的数据请求接口，让你的智能体能够从任何现有应用中提取功能和数据，放到你自己设计的动态画布上。你可以说“从某个系统给我拿这些数据”，LLM就会去取，然后在你想要的地方做一个漂亮的即时可视化。这才是真正的孤岛终结者。如果我们用一个好的底层基座而不是臃肿的技术栈，LLM输出的代码量会大幅减少，也更容易理解。系统的前端变成了文档和智能体，后端变成了基座。还有一些开放问题：文档和对话如何与实现一起存储？版本控制系统怎么用？这些都等待探索。federicopereiro.com/llm-high/

10. llm的本质是知识压缩和检索吗？和外挂知识库的检索比到底强在了什么地方？

11. 知识库（Knowledge Base）与知识图谱（Knowledge Graph）到底该怎么选？

12. 【AI技能】传疯了！AI 大神 Karpathy ：真正的知识库不是存资料，而是把知识变成一套会自己生长的系统

13. 能否使用RAG技术来解决大模型的长期记忆问题？

14. 通俗易懂的解释 LLM，RAG 和 AI Agent 的差别，以下内容为原推的翻译：我终于明白了LLM、RAG和AI智能体的区别过去两年里，我一直在搭建真正落地的AI系统。现在，我终于清楚了：LLM（大语言模型）、RAG（检索增强生成）和AI智能体（AI Agents），根本不是互相竞争的技术，而是构成同一个AI智能系统的三个层次。很多人用错了方法，把它们当成互斥的工具。---> 大语言模型是“大脑” <LLM 就像AI的脑子，它会思考，会写作，也懂语言。但问题来了：它是冻结在某个时间点的。比如 GPT-4，它的知识截止到训练结束的那一天。你问它昨天的新闻发生了什么？那可就瞎编了。大语言模型很聪明，但却不了解“现在”正在发生的事。---> RAG是AI的“记忆” <这时候就需要 RAG（Retrieval-Augmented Generation，检索增强生成）了，它相当于给大脑接入了“外置内存”。当你提问时，RAG会先去外部数据库或文档里搜索，把相关资料抓出来，再丢给大语言模型作为上下文。这样一来，原本静态的模型一下子就“活”了：- 有最新的数据- 有真实的事实- 完全不需要重新训练模型最关键的是，准确率立刻就提高了。大语言模型不用再靠记忆乱猜，而是真正地在实时检索到的信息上进行推理。你甚至还能追溯每个答案到底用了哪些文档。---## > AI智能体是AI的“行动力” <尽管LLM能思考，RAG能提供新鲜的数据，但它们都缺乏真正的行动能力。这时，AI智能体（AI Agents）出场了。它在大语言模型的外面套上了一个控制循环：- 设定目标- 规划步骤- 执行行动- 回顾反思AI智能体并不仅仅是回答问题那么简单，它能自主地去研究一个话题、收集数据、撰写报告，甚至帮你发邮件，全程自动化。---> 真正的生产级AI，要同时用好这三者 <很多酷炫的AI展示，其实只是单纯用了LLM再配上花里胡哨的提示词。但真正能落地的AI系统，往往同时结合了这三个要素：- LLM 提供推理和思考能力- RAG 确保知识准确而新鲜- AI智能体则提供行动和决策能力---> 如何选用这三者？ <- 只用LLM 如果你需要纯语言的任务，比如写作、摘要、解释。- LLM + RAG 如果你需要回答涉及特定文档、技术手册、专业领域知识的问题，并确保答案准确无误。- LLM + RAG + AI 智能体如果你需要真正的自主行动，比如系统自己决策、执行任务、管理复杂流程。---> AI的未来，不是选哪一种，而是如何把这三层架构起来 <记住这个公式：- LLM负责思考- RAG负责知识- AI智能体负责行动真正的AI智能系统，就是这三者协同起来，形成一个完整的智能架构。来源：x.com/connordavis_ai/status/1985663551697273216

15. 【用大模型编译你的第二大脑】快速阅读：Karpathy分享了一套用LLM构建个人知识库的工作流，核心是把原始资料“编译”成结构化wiki，让LLM持续维护、查询和增强这个知识库，而不只是回答一次性问题。这套方法正在引发广泛讨论，不少人已独立摸索出了类似路径。---大多数人用LLM的方式，像是每次都重新烧开一壶水，用完就倒掉。Karpathy最近分享的做法，是在烧水之前先挖一口井。具体流程是这样：把论文、文章、代码库、图片等原始资料扔进raw/目录，让LLM把它们“编译”成一个wiki，也就是一堆.md文件，有摘要、有反向链接、有概念条目、有交叉引用。前端用Obsidian查看。重要的是，这个wiki几乎不需要你手动写一个字，全部由LLM维护。当wiki积累到一定体量，比如100篇文章、40万字，你就可以对着它问复杂问题了。LLM会自己去检索、综合、给出答案，然后你可以把答案“归档”回wiki，下次查询的起点又高了一截。每一次探索都在给知识库加砖，而不是消耗完就散。有观点认为，这套方案最有价值的地方，在于知识连接的可能性是指数级增长的。500条笔记，取任意4个主题做交叉推演，组合数达到620亿条路径。stoic哲学、SaaS定价、病毒式传播、育儿，LLM真的可以找到这条路径上某个有用的东西。有意思的地方在于，Karpathy提到自己不需要复杂的RAG架构。LLM自动维护索引文件和摘要，在这个规模下读相关文档不费力气。那些准备好搭复杂向量数据库的人，可能先白忙了。有网友提到，自己把9个月的编程会话全部导出成markdown，建了SQLite全文索引，现在可以直接说“那个音频桥接的问题我们是怎么解的”，几秒钟出来。没有向量数据库，没有embedding，只有markdown加grep。他说这套东西让他在9个月里造了50多个工具，涵盖全栈、OSINT管线、本地CUDA推理，还帮赛车店分析了ECU数据。“每家公司都有一个raw/目录，只是从来没有人编译过它。”Karpathy本人对这句话的反应是：说得对，就是这个。这件事的终点可能是：向frontier LLM提一个问题，自动召唤一组LLM，临时构建一个wiki，lint一遍，循环几轮，生成完整报告。远不是.decode()能描述的事情。至于这个工作流最终会长成一个产品，还是永远是每个人自己的一堆脚本，这个问题目前没有答案。Karpathy说“我觉得这里有空间做出一个了不起的产品”，但他自己还没动手。x.com/karpathy/status/2039805659525644595

16. Andrej Karpathy 最近发了一条长推，聊了聊他最近在怎么用大语言模型。这条推文在 AI 圈引起了不小的反响，Lex Fridman、Obsidian 创始人 kepano 等人都跑来评论区交流。内容很精彩，值得好好拆解一下。## 从写代码到整理知识Karpathy 开篇就说了一个很有意思的变化：**他最近用 LLM 消耗的 token，越来越少花在写代码上，越来越多花在整理知识上。**具体来说，他在用 LLM 给自己感兴趣的研究方向搭建个人知识库。知识以 Markdown 文件和图片的形式存储，整个过程几乎全部由 LLM 来完成，他本人很少直接动手编辑。这个转变挺值得琢磨的。我们大多数人用 ChatGPT 或者 Claude，基本上是一问一答的模式，问完就走，下次再问可能又要从头来。但 Karpathy 的做法是让 AI 帮他把知识沉淀下来，形成一个可以持续积累、反复查询的体系。**同样是用 AI，一个是消费型的，一个是积累型的，长期下来差距会非常大。**## 整套工作流是怎么运转的Karpathy 把整个流程拆成了几个环节，每个环节都很清晰。### 数据收集他会把各种来源的资料，包括文章、论文、代码仓库、数据集、图片等等，统一放进一个 raw/ 目录。网页文章用 Obsidian Web Clipper 插件转成 Markdown 文件，相关的图片也会下载到本地，方便 LLM 引用。### 知识编译这是最核心的一步。**他让 LLM 把 raw/ 目录里的原始资料增量地“编译”成一个 wiki。**这个 wiki 就是一组按目录结构组织的 .md 文件，里面包含所有原始数据的摘要、反向链接，还会把数据归类到不同的概念下，为每个概念写文章，并把它们互相关联起来。这里有个细节值得注意：他说这个过程目前还不是全自动的。早期阶段他会一篇一篇地手动添加资料，自己参与其中。但随着 wiki 逐渐成型，LLM 会“理解”整个知识库的结构和模式，后面再添加新文档就变得很简单了，只需要说一句“把这篇新文档归档到我们的 wiki 里”就行。这个渐进式的过程很有意思。**就像带一个新助手，刚开始你得手把手教，告诉他文件怎么分类、笔记怎么写。但教了一段时间之后，他就摸清了你的习惯和偏好，后面的工作越来越顺畅。**### 浏览和查看他用 Obsidian 作为前端界面，可以在里面查看原始数据、编译好的 wiki，以及各种衍生的可视化内容。他还试了一些 Obsidian 插件来用不同方式展示数据，比如用 Marp 做幻灯片。有一点他特别强调：**wiki 里的所有内容都是 LLM 写的和维护的，他自己几乎不直接编辑。**### 问答查询当 wiki 积累到一定规模之后，事情就变得有意思了。Karpathy 说他的某个研究方向的 wiki 已经有大约 100 篇文章、40 万字。在这个体量下，你可以向 LLM Agent 提出各种复杂的问题，它会自己去 wiki 里查找、研究，然后给出答案。他原本以为需要搭一套复杂的 RAG（检索增强生成）系统，但实际上 **LLM 自己维护的索引文件和文档摘要就够用了**。在这个规模下，LLM 能很轻松地读取所有相关数据。这一点可能会让很多做 RAG 的开发者感到意外。**当知识库的规模还没有大到离谱的时候，LLM 自己的组织和检索能力其实已经相当够用了。**有时候我们容易过度工程化，在问题还没有出现之前就搭建了一套复杂的基础设施。### 输出形式Karpathy 不喜欢在终端里看纯文本的回答。他会让 LLM 把结果渲染成 Markdown 文件、Marp 格式的幻灯片，或者 matplotlib 生成的图表，然后在 Obsidian 里查看。更妙的是，他经常会把这些输出“归档”回 wiki 里，用来增强后续查询的质量。这样一来，**他自己的每一次探索和提问都会“累积”到知识库中。**这就形成了一个正向循环：你问得越多、探索得越深，知识库就越丰富，下一次查询的质量就越高。### 知识库体检他还会定期让 LLM 对 wiki 做“健康检查”，比如找出数据不一致的地方、用网络搜索补充缺失的信息、发现有意思的关联来作为新文章的候选，等等。通过这种方式逐步清理和完善整个知识库的数据质量。LLM 还很擅长一件事：**建议你接下来可以问什么、可以深入研究什么方向。**这就像有一个研究助手，不仅帮你整理资料，还会主动提出新的研究线索。### 额外工具随着使用的深入，Karpathy 发现自己会开发一些额外的小工具来处理数据。比如他 vibe code（随手写）了一个简单的搜索引擎，有 web 界面可以直接用，但更多时候是通过命令行交给 LLM 作为工具来使用。### 技术架构的极简主义有人问他是不是用了 Obsidian 的命令行工具，他说没有。他刻意保持整个架构极其简单和扁平：就是一个嵌套的目录，里面放着 .md 文件、.png 图片，加上少量的 .csv 和 .py 文件，然后用一个 [AGENTS.md](网页链接) 文件来记录整个知识库的结构说明。LLM 对这种简单的结构理解起来毫无障碍。这个设计选择很有意思。在技术圈，人们总是倾向于用更复杂、更“高级”的方案。但 Karpathy 选择了最朴素的文件系统加 Markdown，因为这是 LLM 最容易理解和操作的格式。**工具越简单，LLM 用起来越顺手，整个系统就越可靠。**## 未来的想象空间Karpathy 还提到了两个很有前瞻性的方向。第一个是合成数据加微调。随着知识库越来越大，一个自然的想法是：**能不能用这些数据来微调模型，让 LLM 把知识“记”在模型参数里，而不只是放在上下文窗口中？**这就像一个人从“查资料才能回答”进化到“张口就来”的过程。第二个更大胆。他在评论区补充说，可以想象这样一个场景：**你向一个顶级 LLM 提出一个问题，它会自动派出一个 LLM 团队，从零开始构建一个临时的 wiki，反复检查和完善，最后输出一份完整的报告。**这已经远远超出了简单的“生成回答”的范畴。## 精彩互动这条推文的评论区也很有料。Obsidian 的创始人 kepano 回复说，他喜欢 Karpathy 这种做法的一个原因是：**它降低了 AI 生成内容对你主知识库的“污染”风险。**他的建议是，把个人的 Obsidian 知识库保持高信噪比，所有内容都要有明确的来源，然后单独给 AI Agent 开一个“游乐场”。Lex Fridman 说他也有类似的工作流，用 Obsidian、Cursor 和自己 vibe code 的 web 终端作为前端。因为他做播客，研究兴趣非常广泛，这种知识库的方式效果很好。有个叫 Krishna Tammireddy 的人留了一句特别精辟的评论：**每家公司都有一个 raw/ 目录，但从来没有人把它“编译”过。这就是产品机会。**Karpathy 回复说：不知道这是不是 LLM 写的回复，但说得没错。还有人说 Karpathy 现在就像 AI 界的 Linus Torvalds，是一个“元级别的 vibe coder”，不知道这条推文会在一夜之间催生多少新项目。Karpathy 自嘲说：哈哈，我用推特来 vibe code 产品。## 一个值得所有人思考的方向Karpathy 在推文最后说了一句话：他觉得这里面蕴藏着一个很棒的新产品的机会，而不应该只是一堆拼凑的脚本。这句话点出了一个很重要的趋势。**我们正在从“用 AI 聊天”走向“用 AI 管理知识”。**聊天是即时的、一次性的，而知识管理是持续的、累积的。当 AI 能够帮你把散落在各处的信息整理成一个结构化的、可查询的、不断生长的知识体系时，它的价值就从一个聊天工具变成了一个真正的智力放大器。而且 Karpathy 的做法有一个特别值得学习的地方：**他让每一次使用 AI 的过程都产生沉淀。**问一个问题，答案归档到 wiki 里；做一次探索，发现的新线索变成新文章的种子。这样一来，你跟 AI 的每一次交互都在让你的知识库变得更好，而更好的知识库又会让下一次交互的质量更高。**这种正向飞轮一旦转起来，长期的复利效应是非常可观的。**说到底，工具都是现成的，Obsidian 免费，LLM 的 API 也不贵。**真正稀缺的是这种思维方式：把 AI 从一个回答问题的工具，变成一个帮你积累和组织知识的系统。**这个转变，可能比学会写更好的 prompt 重要得多。#科技先锋官##How I AI#

17. OpenViking：一个非常实用的开源项目，专为AI Agent设计的上下文数据库，通过创新的“文件系统范式”统一管理Agent所需的记忆、资源和技能，彻底解决了传统向量数据库碎片化、检索效果差、上下文不可见的问题。主要亮点包括：- 文件系统管理范式，实现统一结构化管理，轻松浏览和操作上下文，像管理本地文件一样简单- L0/L1/L2三层上下文分级加载，按需调用，大幅降低Token消耗- 目录递归检索策略，结合目录位置和语义搜索，实现更精准、更全局的上下文获取- 可视化检索轨迹，完整呈现检索过程，方便调试和优化- 会话自动管理，自动提取长期记忆，Agent能“用得越久越聪明”支持Python包安装，也有Rust CLI工具；支持多家主流模型提供商，包含Volcengine、OpenAI、Anthropic、本地vLLM等等；同时提供详尽配置示例，轻松上手。新手快速开始示例脚本也非常简洁，几行代码即可增加资源、浏览文件结构、等待语义处理、抽取摘要、执行语义搜索，非常适合开发者验证和应用。同时官方推荐在云服务器（推荐Volcengine ECS + veLinux）环境中部署，保证稳定性和性能。如果你正打造智能Agent或者想优化上下文管理，强烈建议一试OpenViking，这个项目将让上下文管理和检索变得前所未有的清晰、高效、智能。GitHub地址：github.com/volcengine/OpenViking 官网：www.openviking.ai 文档：www.openviking.ai/docs

18. 如何构建上下文图谱（How do you build a context graph）? Context Graph 本质上就是：把「事情是怎么被做成的」这件事结构化下来，变成 AI 可以学习和推理的对象。上下文图谱通过连接人员、文档及行为轨迹，捕捉企业工作的动态过程。它将孤立的知识转化为动作序列，让AI理解“如何”完成任务。通过集成知识图谱与个人数据，系统能自主学习最佳路径，实现端到端业务自动化并确保持续进化。原文：x.com/jainarvind/status/2019553277571190821 #HOW I AI# #程序员#

19. 如何系统性的学习RAG、Agent、MCP?

20. 【保姆级】RAG智能体终极方案：n8n+Google File Search，零门槛搭建高精度RAG工作流！

21. LightRAG 是一个简单快速的检索增强生成（RAG）框架，能高效整合大语言模型和知识图谱，实现智能文档查询和多模态检索。LightRAG支持多种存储方案（PostgreSQL、Neo4j、Milvus、OpenSearch等），支持文本、图片、表格、公式等多种数据类型的端到端知识抽取和问答。还提供了丰富的示例代码、Web UI，以及支持OpenAI、Hugging Face、Ollama、Azure OpenAI等多家模型接口。项目亮点：- 灵活配置的多存储架构，适合大规模知识管理；- 深度集成知识图谱构建与编辑，支持实体关系管理、知识图谱可视化；- 支持强大的Reranker提升检索效果；- 新增RAG-Anything，打通多模态文档处理与检索能力；- 丰富文档导入格式、引用功能、缓存管理、Token使用统计；- 还支持Langfuse可观测性监控以及RAGAS自动评价指标。无论是科研研究、企业知识库、还是多模态智能问答应用，LightRAG都提供了极具扩展性且高性能的解决方案。GitHub：github.com/HKUDS/LightRAG#在线智能检索# #知识图谱# #大语言模型# #RAG# #开源项目#

22. 【向量数据库被颠覆？一个无需嵌入的RAG新思路】最近开源社区出现了一个有意思的项目PageIndex，它提出了一种完全不同的RAG实现路径：用文档树结构替代传统的向量嵌入，在FinanceBench基准测试上达到了98.7%的准确率。这个方案的核心理念是让大模型直接在文档结构上进行推理，而不是通过关键词匹配来检索。不需要嵌入，不需要分块，完全开源。听起来很激进，但仔细想想，这其实回归了一个朴素的问题：人类阅读文档时，依赖的是什么？是语义相似度，还是章节、标题、表格这些结构化线索？对于金融报告、法律合同、合规文档这类天然具有清晰层级结构的内容，让模型沿着文档树进行推理，确实比把文档切成碎片再用向量匹配更符合直觉。结构优先的检索方式，也让引用溯源变得更加可靠。但社区的实测反馈也很真实。有人指出它目前只能处理单个文档，跨文档比较和相似性匹配这类场景还是需要向量数据库。也有人反映速度偏慢，对于简单查询来说，逐层遍历节点的开销不小。还有人质疑：面对大规模非结构化数据，这种方案能否扩展？一位开发者的评论很中肯：向量数据库能用廉价的数学运算实现毫秒级检索，而PageIndex依赖的是昂贵且缓慢的大模型推理，在需要扫描海量文档的场景下，可行性存疑。所以这不是一个“谁取代谁”的故事。更准确的理解是：RAG的工具箱里多了一件趁手的武器。结构化文档用文档树，非结构化内容用向量嵌入，复杂场景可能需要混合方案。技术选型从来不是非此即彼。真正的答案永远是：在你自己的数据上跑一遍基准测试。 GitHub：github.com/VectifyAI/PageIndex x.com/dr_cintas/status/2019045152350756869

23. 在构建RAG Agent时，哪些场景应该用确定性逻辑判断取代LLM的概率推理，具体怎么实现？

24. Leonie Monigatti深入剖析了AI代理中的记忆演进，从最初的RAG（检索增强生成）到Agentic RAG，再到具备读写能力的Agent Memory，厘清了这一系列技术的核心逻辑与突破。RAG诞生于2020年，其核心是将离线存储的外部知识检索进LLM上下文，解决模型记忆有限带来的问题。但其“单次检索”与“只读”限制导致复杂场景下仍有误导风险。Agentic RAG引入了“工具调用”机制，允许智能体主动判断是否需要检索、选择检索工具，并评估检索结果相关性，显著提升了灵活性和准确性，但仍无法动态学习和更新信息。Agent Memory则迈出关键一步：支持智能体不仅读取，还能写入和管理外部记忆，实现基于历史交互的持续学习和个性化体验。它将记忆从“静态”转变为“动态”，但也带来了记忆管理和遗忘机制的新挑战。这三者共同体现了信息“存储-检索-编辑-删除”的完整闭环，也反映了AI系统从单点知识调用向复杂记忆体系演进的趋势。未来，如何设计高效的多源、多类型记忆管理策略，将是提升AI智能和人机交互体验的关键。详细内容及代码示例请见原文：leoniemonigatti.com/blog/from-rag-to-agent-memory.html

25. 请教一下各位关于RAG（检索增强生成）的几个问题？

26. RAG、LangChain、Agent 到底有什么关系？

27. 【AI记忆系统突破99%准确率：用Agent完全替代向量数据库】快速阅读： Supermemory团队用多智能体协作系统在长期记忆基准测试LongMemEval上达到99%准确率，核心突破是用3个并行搜索Agent替代传统向量检索，让AI通过“理解”而非“数学相似度”来回忆信息。这套方案不需要向量数据库，甚至可以嵌入机器人。---向量数据库可能不是AI记忆的最优解。Supermemory在LongMemEval基准测试（11.5万token对话历史）上达到99%准确率，用的方法反而更简单：完全抛弃向量检索，改用多个Agent协作。传统RAG的问题出在检索环节。语义相似度匹配根本分不清“旧事实”和“新更正”，当检索结果里混杂太多噪音，大模型就会迷失。他们的解法是ASMR（Agentic Search and Memory Retrieval）：信息摄取阶段，3个并行Observer Agent同时读取对话记录，按照个人信息、偏好、事件、时间数据等六个维度提取知识点，直接存储结构化内容而非生成embedding。检索阶段才是关键。面对提问时不查询数据库，而是派出3个专门的搜索Agent——一个找直接事实，一个挖隐含语境，一个重建时间线。这些Agent是在“主动阅读和推理”，不是在做向量余弦计算。回答阶段用了两种策略测试。第一种是8个高度专业化的prompt变体并行运行（精确计数专家、时间专家、上下文深挖专家等），只要任何一条推理路径答对就算成功，准确率98.6%。第二种是12个Agent独立作答后，由一个聚合器LLM综合投票裁决，准确率97.2%。有观点认为这套系统证明了“认知理解”比“数学相似性”更适合处理记忆任务。数学只能捕捉表层模式，而Agent可以处理时间序列中的矛盾、更新和细微差别。更有意思的是，这个架构完全在内存中运行，不依赖外部向量数据库，理论上可以部署到任何设备，包括机器人。他们11天后会开源全部代码。当数十亿个高度个性化的AI Agent开始学习和记住我们的一切时，记忆系统的天花板在哪里？也许不在算力，而在我们愿意给Agent多少“主动思考”的权限。ref: x.com/DhravyaShah/status/2035517012647272689#AI创造营##人工智能#

28. 构建智能问答系统通常面临查询模糊、上下文理解不足和检索效率低等挑战。Agentic RAG for Dummies 是一个基于 LangGraph 的极简 Agentic RAG（检索增强生成）框架，帮助你用最少代码快速搭建具备会话记忆和人机交互查询澄清能力的生产级系统。项目集成了多功能模块： - 会话记忆，保持对话上下文连贯； - 智能查询澄清，自动重写或请求补充信息； - 分层索引，实现精准且上下文丰富的检索； - 多Agent并行处理复杂多问； - 灵活切换多种大语言模型（Ollama、OpenAI、Google Gemini 等）； - 开箱即用的 Gradio Web UI，方便体验和部署。无论是学习 RAG 基础，还是构建定制化应用，这个项目都提供了交互式笔记本和模块化代码两条路径，助力开发者快速上手并轻松扩展。 GitHub 地址：github.com/GiovanniPasq/agentic-rag-for-dummies/ 主要功能： - 支持多轮对话记忆，提升问答自然度； - 自动拆分复杂查询，精准定位信息点； - 结合关键词稀疏向量和语义稠密向量的混合检索； - 内置人机交互机制，避免误解或无效查询； - 多Agent协同，提升复杂问题的处理效率； - 完整文档处理流水线，支持 PDF 转 Markdown 及分块索引。适合 AI 研究者、开发者及数据工程师，轻松构建满足生产需求的智能问答系统。

29. DeepLearning AI 吴恩达和 Qdrant新出的这个课程看起来不错。Multi-Vector Image Retrieval，大多数检索系统都会用单个向量来表示一张图像。本课程展示了多向量方法如何将图像表示为由多个嵌入组成的集合，从而在文本查询与视觉内容之间实现更加精确的匹配，尤其适用于包含图片、图表和文字混合的文档场景。1 实现 ColBERT，用于理解多向量文本检索与延迟交互式搜索。2 应用 ColPali，从图像中提取更细粒度的局部补丁级特征，用于精细视觉检索。3 通过量化与池化技术优化内存占用。4 将多向量输出转换为 MUVERA 向量，以加速基于 HNSW 的快速检索。5 构建一个多模态 RAG 流水线，用于检索并推理复杂的视觉类文档。访问：learn.deeplearning.ai/courses/multi-vector-image-retrieval/#ai创造营# #程序员#

30. 管理复杂项目和任务，知识沉淀分散且难以高效协作？ATLAS MCP Server 提供了一套基于 Neo4j 图数据库的任务与知识管理解决方案，专为支持大语言模型（LLM）智能代理设计。ATLAS 采用三节点架构（项目、任务、知识），实现项目内任务细粒度跟踪与知识结构化管理，支持任务依赖关系和跨实体统一搜索。2.x 版本全面切换至 Neo4j，增强了数据一致性与查询性能，支持自托管（Docker）和云端 AuraDB。主要功能包括：- 项目全生命周期管理，支持状态、优先级、依赖等丰富属性；- 任务创建、更新、删除与批量操作，支持分配、标签和多维筛选；- 知识库支持领域分类、标签和引用，方便信息沉淀与复用；- 基于 Model Context Protocol (MCP) 的多种通信方式，方便 LLM 代理和各种客户端集成；- 深度研究工具，支持结构化调研计划生成与管理；- 数据库备份与恢复，保障数据安全可靠。GitHub 地址：github.com/cyanheads/atlas-mcp-server npm 包：www.npmjs.com/package/atlas-mcp-server适合需要结合 AI 助理进行复杂任务和知识管理的团队与开发者，支持灵活定制和扩展。

31. 基于 RAG 的 AI 搜索技术实践

32. 如何评价Karpathy提出的个人知识库的架构？

33. AI Agent开发常常需要管理海量对话历史，传统RAG或知识图谱难以实现真正学习，记忆准确率低、长期遗忘严重。Hindsight™ 提供革命性的Agent记忆系统，让AI Agent真正"学会"而非仅"记住"。不仅在LongMemEval基准测试中创下最优性能，还支持世界事实、个人经历、心理模型构建，已被Fortune 500企业投入生产。GitHub：github.com/vectorize-io/hindsight主要功能：- 记忆保留（Retain）：自动提取实体、关系、时序数据构建知识库；- 智能回忆（Recall）：语义+关键词+图谱+时序四路并行检索；- 深度反思（Reflect）：基于记忆生成洞察和决策建议；- 多用户记忆隔离：支持按用户/会话隔离记忆管理；- 生物仿生架构：模拟人类记忆机制（世界事实+经历+心理模型）；- 一行代码集成：LLM Wrapper自动为现有Agent添加记忆能力。支持Docker一键部署、Python/Node.js客户端、嵌入式模式，兼容OpenAI/Anthropic等多种LLM提供商。#AIAgent##AgenticAI##人工智能#

34. 教程：All-in-RAG | 大模型应用开发实战一：RAG技术全栈指南网页链接本项目是一个面向大模型应用开发者的RAG（检索增强生成）技术全栈教程，旨在通过体系化的学习路径和动手实践项目，帮助开发者掌握基于大语言模型的RAG应用开发技能，构建生产级的智能问答和知识检索系统。主要内容包括： RAG技术基础：深入浅出地介绍RAG的核心概念、技术原理和应用场景数据处理全流程：从数据加载、清洗到文本分块的完整数据准备流程索引构建与优化：向量嵌入、多模态嵌入、向量数据库构建及索引优化技术检索技术进阶：混合检索、查询构建、Text2SQL等高级检索技术生成集成与评估：格式化生成、系统评估与优化方法项目实战：从基础到进阶的完整RAG应用开发实践#微博兴趣创作计划#

35. 怎么让大模型的RAG迅速落地，看这一篇就够了（附AI项目落地实操经验+技巧+资料）

36. 《扣子开发 AI Agent 智能体应用》014-基于大模型的企业知识库（知识库的理论基础 RAG）

37. LLM，RAG和Agent不是割裂的，而是一个整体。如果把 AI 系统比作一个生命体，那么 LLM = 大脑，RAG = 记忆，Agent = 执行系统。LLM 像是大脑的皮层，擅长理解、联想和表达。它能在复杂的语言世界中“即兴发挥”，像人类一样推理、总结、编故事。也会在需要时做出“认知上的决策”——比如分析问题的思路、选择回答的方向。然而，大脑并不擅长记住具体事实。它能推断“苹果会掉下来”，却未必记得“牛顿是什么时候发现的万有引力”。这时，就需要「RAG」登场。RAG 相当于一个“外接记忆系统”。当大脑想不起细节时，它能立刻翻查资料库，把相关的事实、文档、图像调出来，再交还给大脑整合成一段有根据的回答。于是，大脑不再是“瞎编”，而是“有据可依”。从技术上讲，这就像给模型装上一个搜索引擎——但比搜索更聪明，因为它能理解上下文、筛选关键信息、甚至融合多个来源的内容。Agent 则像是神经系统中的“执行层”。大脑想出了计划，记忆提供了依据，而真正“去行动”的，是 Agent。它决定什么时候要产生计划，要不要调用工具、查阅资料、生成报告，甚至与外部世界互动。可以说，LLM 负责“想”，RAG 负责“记”，Agent 负责“做”。当这三者协同工作时，AI 便不再是一个“聊天机器人”，而是一个有意识、有记忆、有行动能力的“数字生命”。#ai创造营##科技#

38. AI 搜索的技术效能：从“检索”到 “洞察”

39. #IT那些事儿# OpenViking + OpenClaw 将会是王炸组合。OpenViking（火山引擎开源：github.com/volcengine/OpenViking） + OpenClaw（开源地址：github.com/openclaw/openclaw）的组合 = 文件系统协议 (OpenViking) + 向量与关键词混合检索 (OpenClaw) + 自动多层加载 (OpenViking) 的组合一、各自的优势OpenViking（中文介绍：github.com/volcengine/OpenViking/blob/main/README_CN.md）- 核心定位：云原生数据湖存储加速器。- 目标：在大数据和AI场景下，优化对海量数据（特别是对象存储中的数据）的访问性能。而OpenClaw采用向量检索 + 关键词匹配的双重方案：- 向量检索：实现语义匹配，能理解同义表达（如搜索"认证漏洞"也能匹配到"认证问题"）- 关键词匹配：实现精确短语查找，锁定核心内容与需要独立部署向量数据库的方案不同，OpenClaw的实现非常轻量：- 向量检索：直接基于SQLite实现，无需额外部署复杂的向量数据库- 关键词检索：依托SQLite的FTS5（全文搜索）扩展插件实现但是要注意，SQLite 向量检索不是“无限扩展”，它的真实情况是：- 10 万级向量：舒服- 100 万级：开始抖- 1000 万级：不适合所以：OpenClaw 的“工作区间”是：- Agent 私有知识- 企业部门级资料- 单用户或小团队的多模态数据- ❌ 而不是公司级别的多模态数据对 OpenClaw 来说，世界就是文件、附件、日志、快照、索引、任务产物。那么 OpenViking 提供的是：- 一个看起来像本地- 但实际上背后是数据湖- 并且自动做冷热管理这对一个 7×24、要跑多年、不断积累历史的 Agent OS 是刚需级能力。而 OpenViking+OpenClaw 的组合可以理解为 “OpenViking 修了一条智能高速公路，OpenClaw 在上面跑最先进的物流车队”，两者结合可以让个人或团队级 AI Agent 不再受限于本地存储与 IO，能长期运行、持续积累、而不牺牲隐私与控制权。二、组合架构设想1.数据湖作为唯一信源：你的所有原始的图片、视频、PDF、音频等非结构化数据，统一存放在对象存储（如S3/TOS）中，构成数据湖。2.OpenViking 作为“智能数据接入层”：对下，它接管了对数据湖的访问，通过其缓存和预取能力，让后续的数据读取速度提升数个量级。对上，它以一个标准POSIX文件系统或FUSE挂载点的形式提供服务。这对于OpenClaw 的索引构建过程至关重要。3.OpenClaw 作为“智能检索大脑”。“文件系统协议 (OpenViking) + 向量与关键词混合检索 (OpenClaw) + 自动多层加载 (OpenViking)” 这个组合，精准地命中了当前AI和大数据基础设施的几个关键痛点：数据墙、IO瓶颈、非结构化数据价值挖掘。它们组合后，能够为 “多模态AI应用”（如海量图片/视频搜索、企业知识库问答、音视频内容理解）提供一个从底层存储、高速接入到顶层智能体检索与召回的一站式后端解决方案。三、场景场景 1：多模态搜索引擎（最典型、最强）场景描述- 数据：图片 / 视频 / 音频 / PDF- 存储：对象存储（S3 / TOS）- 用户通过聊天工具给 OpenClaw 个人智能体助理下达需求：- “找和这张图相似的视频”- “搜索提到某事件的会议录音”- “从几百万文档中定位相关段落”OpenViking 此时在干什么：- 把对象存储 → 本地文件系统语义- 对热数据、索引扫描、回查文件做缓存和预取- 避免每一次检索结果都打到远端对象存储OpenClaw 此时在干什么：- 建立：- 向量索引（语义）- 关键词索引（精确）- 输出候选结果集合组合的价值：检索是秒级，回看原始文件不再是灾难级 IO。场景 2：媒体 / 视频资产管理场景描述- 电视台 / 短视频平台 / 自媒体集团有：- 海量历史素材- 多种格式- 高分辨率视频实际需求- “找和这个镜头相似的素材”- “搜索某人物出现过的所有片段”- “快速预览”组合的工程优势- 索引只存 embedding + metadata- 原视频仍在对象存储- 热素材被 OpenViking 缓存在本地结论：OpenClaw 是一个本地优先、能长期运行并持续积累的 Agent OS；OpenViking 为它提供了可扩展的多模态数据与 IO 底座。两者结合，使个人或团队级 AI Agent 不再受限于本地存储与访问性能，能在保护隐私与控制权的前提下，稳定运行多年。四、具体的组合方式：①部署形态：┌──────────────────────┐│ Agent App ││ (Orchestrator / LLM) ││ ││ ┌──────────────────┐ ││ │ OpenClaw SDK │◄┼───── semantic / keyword query│ └──────────────────┘ ││ ▲ ││ │ Context ││ ▼ ││ ┌──────────────────┐ ││ │ OpenViking API │◄┼───── file-like context API│ └──────────────────┘ ││ │ │└──────────┼───────────┘ ▼ Object Store / FS / KV / Vector注意：OpenClaw 和 OpenViking 是两个独立服务，不是库级耦合。②上下文目录规范：/context├── agents/│ └── {agent_id}/│ ├── L0/│ │ └── sessions/{session_id}/│ │ ├── messages/│ │ ├── tool_calls/│ │ └── scratchpad.md│ ├── L1/│ │ ├── summaries/│ │ └── recent_refs/│ ├── L2/│ │ ├── long_term_memory/│ │ ├── knowledge/│ │ └── compressed_sessions/│ └── skills/│ ├── web_search.md│ ├── calendar.md│ └── db_query.md└── resources/├── documents/├── images/└── tools/- L0 = 强时效、强相关、强 IO- L1 = 最近总结、弱原始数据- L2 = 冷数据、不可频繁扫描

40. 函数计算 AgentRun 重磅上线知识库功能，赋能智能体更“懂”你

41. 使用LLM进行文本聚类：LLM-MemCluster框架

42. 花了半天时间实测 Andrej Karpathy 提到的 LLM 知识库玩法，分享一些实操细节：【架构设计】我采用了简单的 2 层 Markdown 结构，完全没用 Embedding 工具。我觉得在文件数量 < 1,000 的规模下，这种“纯文本编译”的思路完全够用。1. 索引层 (wiki/index.md)：核心索引文件。每一行对应一个文件，包含：Path | Summary | Tags。2. 摘要层 (wiki/document.summary.md)：由 LLM 根据原文增量构建的摘要文件。3. （舍弃项）： Claude Code 曾建议增加一个 Tag/Topic 索引，但考虑到 Tag 过于稀疏且文件方式维护复杂，被我 Pass 掉了。【工作流】- 数据入库：索引项目文档 →→ 写入 index.md →→ 构建 Summary。- 检索逻辑： 1. 搜索某 Topic 时，LLM 先加载 index.md 获取相关文件列表。 2. LLM 读取相关文件的 Summary，判断是否需要进一步加载“原文”。【实测效果】我导入了某个研究领域的数篇文章，让 LLM 针对其中一个观点输出论证。在关键词文件命中不多（< 10）的情况下，输出非常有条理。它不是简单的 grep 组合，而是完全按照逻辑重新组织过的观点，通常能给出 3 到 4 个核心要点，不知道这个试验是否属于 Andrej 说的合成数据的玩法【一个意外发现】输出结果中居然包含了一个还没被 index.md 索引的文件内容，并用它辅助了观点。推测是因为该文件之前被加载过，信息存在于 Claude Code 的 memory 文件中【后续】接下来会继续增加库的容量，等关注领域积累到上百个文件后再观察效果。目前的原理非常简单，有兴趣的朋友也自己去尝试下，低成本跑通自己的 agent 知识库。

43. LlamaIndex 深度实战：用《长安的荔枝》学会构建智能问答系统网页链接“这篇文章兼顾了 RAG 的科普与 LlamaIndex 的实战。无论你处在哪个阶段，都能找到适合自己的阅读路径：1. 如果你是 RAG 或 AI 新手（👋 欢迎！）建议从第一部分：原理篇开始。这部分会用一个生动的比喻，帮你建立 RAG 的核心概念，理解 AI 是如何"读书"的。然后，你可以直接跳到第二部分：实战篇，快速体验用 30 行代码构建一个问答系统的乐趣。第三部分：优化篇和第四部分：架构篇可以先收藏，等有概念后再来深入。2. 如果你熟悉 RAG，想深入 LlamaIndex（🚀 进阶！）你可以快速浏览第一部分：原理篇，回顾一下核心概念。第二部分：实战篇值得一看，LlamaIndex 的 API 非常简洁高效。第三部分：优化篇是本文的精华。我们通过真实实验，展示了 chunk_size 和 top_k 等参数对结果的具体影响，这对于生产环境调优至关重要。第四部分：架构篇将帮你理解 LlamaIndex 的内部机制，为你的二次开发或深入定制打好基础。”

44. 关于 NotebookLM 植入 Gemini 这件事，我详细写了一篇自己的使用体验：网页链接NotebookLM 里的笔记本可以作为 Gemini 的外挂 RAG，Gemini 的答案会更加精准，幻觉会收敛，输出更加聚焦和有价值。而对于 NotebookLM 来说，Gemini 帮它搞定了多笔记本互通的事情，另外，NotebookLM 干不了的事儿，Gemini 可以代劳，比如 Deep Research，出图，做视频，写程序等等。这就有点像 Agentic RAG，当然，因为 Gemini 是面向所有互联网数据的，泛化的更厉害一些。目前墨问时间的知识库，还是经典 RAG，要升级成 Agentic RAG，本质是让模型从“只在生成参与”扩展到“全链路参与”，把检索变成一个可决策、可路由、可自我评估的系统，并引入可持久记忆与多源工具。这样不仅提升准确性与覆盖率，也能在复杂查询下保持稳健。还有很长的路要走……

45. 为什么 RAG 落地难？解析数据处理 “三重困境”，事件驱动架构如何破局？

46. Milvus 向量数据库实战：从零构建高性能 RAG 系统

47. LLM 语境下，「持续学习」是否是「记忆」问题的最优解？

48. 🚨突发新闻：Qwen 团队刚刚发布了他们的官方代理框架，它包含了所有功能。无需拼接第三方库。无需对抗抽象概念。Qwen-Agent 为您提供：→框架内直接内置的原生函数调用→开箱即用的安全代码解释器沙箱→ RAG 和 MCP 支持包括→用于浏览器原生代理工作流程的 Chrome 扩展程序由构建模型的团队开发，所以它运行稳定可靠。100% 开源且完全免费。

49. 腾讯基于 RAG 和 Agent 技术的混元大模型业务落地实践

50. Andrej Karpathy 现在成了一个超级 AI 明星。他最近主推的一个 LLM+ MD + Wiki 的个人知识库特别火，很多人根据他的理论做了自己的知识库。Andrej Karpathy 的这招我早就用过了。写了一下我的实践，3 月的事儿网页链接

51. Karpathy:用 LLM + Obsidian 编译知识库

52. Karpathy最新的干货输出:能够进化的知识库

53. Karpathy 用 LLM 搭了一套自动维护的知识库

54. 新“LLM知识库”架构绕过了RAG

55. 别再用 RAG 当知识库了！让 LLM 帮你养一个会自己长大的 Wiki

56. LLM Wiki

57. 学习下Karpathy大佬对于 LLM 知识库的最新研究

58. 跟着前OpenAI 大佬Karpathy学！用 LLM+Obsidian 搭建个人知识库，效率翻倍

59. Karpathy新提出LLM Wiki，可能将彻底颠覆RAG知识库

60. Karpathy推出LLM Wiki 重构AI知识库格局

61. 从代码到知识

62. 体验 Karpathy 用 LLM 构建的个人知识库，赞！

63. Karpathy 知识库构建

64. Andrej Karpathy 用 Obsidian 替代 RAG，这才是平民玩家的知识管理方案

65. Karpathy的LLM Wiki

66. 打造个人 AI 第二大脑

67. 从检索到编译

68. LLM 知识库 (LLM Knowledge Bases)

69. Karpathy不写代码了

70. Andrej Karpathy 如何打造LLM 知识库

71. 告别向量搜索，这个GitHub项目让AI像人类专家一样“推理”检索文档，金融问答准确率达98.7%

72. 让 AI 帮你写知识库

73. 「随便说说」卡帕西又整活了

74. Karpathy 的LLM Wiki引发全网讨论：让大模型从“会查资料”，进化到“会积累知识”

75. 用 LLM 编译你的知识库

76. #模型时代# Andrej Kaparthy：如何用LLM构建个人知识库（维基）

77. 放弃RAG吧！LLM知识库新范式 | Karpathy的新思路

78. 大语言模型在个人知识管理中的应用演进:LLM WIKI模式

79. PageIndex 能替代传统RAG吗？

80. Karpathy知识库「LLM Wiki」火爆了,全网围观讨论

81. AI RAG系列: 第8篇:【常用RAG开源框架对比与选择】

82. 介绍下9种RAG的架构

83. RAG讣告：死于智能体之手，葬于上下文窗口

84. RAG喊死了三年，Glean和DoorDash为什么还在用？

85. RAG进阶方案：打造更优质LLM回答的高阶优化指南

86. Karpathy大神的个人知识编译理论和我的一些理解实践

87. RAG技术从入门到精通：四种架构解析，建议收藏反复学习！

88. PageIndex深度解析：推理式检索，无向量数据库的新范式

89. RAG 与 Agentic RAG 的区别详解

90. 告别“傻叉“被动式RAG！主动式RAG让AI像人类一样思考，效率提升10倍！

91. 🦜🌊 Agentic RAG 实战 3️⃣ 自带评分和托底的 Corrective RAG

92. 易术观察｜动态知识图谱提升准确率30%，结构化知识成行业AI新基座

93. 如何用LangChain实现动态路由的RAG系统？

94. WriteBack-RAG：让 RAG 系统的知识库"学会进化"

95. 如何选择AI知识库架构？深度解析RAG、GraphRAG与微调方案

96. 低成本跑通自己的 LLM 知识库：用 Markdown + LLM 代替传统 RAG

97. 2025 封神级大模型技术手册：LLM、RAG、Agent、MCP 核心逻辑全拆解

98. 如何一键搭建Karpathy知识库「LLM Wiki」

LLM Wiki不是RAG的平替，选错架构准确率反降12%

精选参考来源