RAG与LLM Wiki：知识库该动态进化还是静态沉淀？_服务软件

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

2. //@程序员金俊:虽然 PageIndex 在“深度理解单篇/少量复杂文档”上超越了传统 RAG，但它也有非常明显的局限性：极高的 Token 消耗与延迟：传统的向量检索是毫秒级的计算。而 PageIndex 每回答一个问题，都需要 LLM 介入进行多次思考和树节点遍历。这会导致巨大的 Token 吞吐量和长达数秒（甚至十几秒）的 Latency。在关注运行成本和产出比的工程实践中，这是一笔必须精确计算的开销。不适合海量文档的“广度搜索”：如果你有个包含一万份短小碎文档的 PostgreSQL 知识库，要在其中“大海捞针”，传统的 Embedding + 向量检索引擎依然是无可替代的最佳选择。依赖原始数据的结构化质量：树状索引的质量决定了检索的上限。如果输入的 PDF 是一份排版混乱、毫无标题层级的纯扫描件，PageIndex 赖以生存的导航地图就会失效。总结： PageIndex 并没有淘汰向量 RAG，而是开辟了另一个赛道。向量 RAG 擅长处理“海量、碎片、无结构”的广度召回，而 PageIndex 是一个用来对付“单点、长篇、高结构化”硬核文档的精读智能体。未来更合理的架构，很可能是两者的融合（Hybrid）：用向量做初步过滤，用 PageIndex 的树检索做精准的深度穿透。

3. github.com/Tencent/WeKnora 腾讯开源的RAG框架：WeKnora（维娜拉）这是一款基于大语言模型的文档理解与语义检索框架，专为结构复杂、内容异构的文档场景而打造。框架采用模块化架构，融合多模态预处理、语义向量索引、智能召回与大模型生成推理，构建起高效、可控的文档问答流程。核心检索流程基于 RAG（Retrieval-Augmented Generation）机制，将上下文相关片段与语言模型结合，实现更高质量的语义回答。核心特性 🤖 Agent模式：支持ReACT Agent模式，可调用内置工具检索知识库、MCP工具和网络搜索，通过多次迭代和反思给出全面总结报告 🔍 精准理解：支持 PDF、Word、图片等文档的结构化内容提取，统一构建语义视图 🧠 智能推理：借助大语言模型理解文档上下文与用户意图，支持精准问答与多轮对话 📚 多类型知识库：支持FAQ和文档两种类型知识库，支持文件夹导入、URL导入、标签管理和在线录入 🔧 灵活扩展：从解析、嵌入、召回到生成全流程解耦，便于灵活集成与定制扩展 ⚡ 高效检索：混合多种检索策略：关键词、向量、知识图谱，支持跨知识库检索 🌐 网络搜索：支持可扩展的网络搜索引擎，内置DuckDuckGo搜索引擎 🔌 MCP工具集成：支持通过MCP扩展Agent能力，内置uvx、npx启动工具，支持多种传输方式 ⚙️ 对话策略：支持配置Agent模型、普通模式模型、检索阈值和Prompt，精确控制多轮对话行为 🎯 简单易用：直观的Web界面与标准API，零技术门槛快速上手 🔒 安全可控：支持本地化与私有云部署，数据完全自主可控 #科技先锋官#

4. 整个 RAG 行业即将被颠覆。研究人员开发了一种新的 RAG 方法，它： - 不需要向量数据库。 - 不嵌入数据。 - 不涉及分块。 - 不进行相似性搜索。它被称为 PageIndex。与其将文档分块并塞入 Pinecone，不如构建一个树索引，让 LLM 像人类阅读书籍一样推理。在 financebench 上达到了 98.7%。在排行榜上击败了所有向量 RAG。无嵌入。无分块。无向量数据库。 100% 开源。

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技能】传疯了！AI 大神 Karpathy ：真正的知识库不是存资料，而是把知识变成一套会自己生长的系统

7. 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#

8. 【大语言模型在个人知识管理中的应用演进：LLM WIKI模式】大语言模型在个人知识管理中的应用正在经历从 RAG（检索增强生成）向持久化 Wiki 模式的演进。在传统的 RAG 架构下，模型在每次查询时都需要重新检索原始文档片段并尝试合成答案，这种方式缺乏知识的积累，导致模型在处理需要跨多个文档进行深度综合的问题时效率较低。Andrej Karpathy 提出的 LLM Wiki 模式提供了一种不同的思路：让模型增量式地构建并维护一个结构化、互联的 Markdown 文件集合。以下是该模式的详细技术架构与操作流程：1、三层架构设计原始素材层（Raw Sources）：存放不可变的原始文档，包括文章、论文、图像和数据文件。模型仅读取这些文件，不进行修改，确保信息的真实性。Wiki 表现层（The Wiki）：由模型生成的 Markdown 文件目录。包含实体页面、概念总结、对比分析和综合论述。模型拥有该层的完全写权限，负责创建页面、更新内容并维护交叉引用。模式规范层（The Schema）：通过 CLAUDE.md 或 AGENTS.md 等配置文件，向模型定义 Wiki 的组织结构、命名规范以及处理新信息的工作流。这是确保模型能够像专业管理员一样工作的核心指令集。2、核心操作流程增量摄取（Ingest）：当用户向原始素材层添加新文件时，模型会阅读该文件并提取关键点，随后更新 Wiki 目录中的相关页面。一个新素材的加入可能会触发对 10 到 15 个相关页面的修改，包括更新实体描述、修正旧有的矛盾观点以及补充新的论据。闭环查询（Query）：模型基于 Wiki 页面而非原始素材回答问题。关键的操作细节是，模型生成的深度分析或对比结论会被重新存入 Wiki 成为新的页面。这种方式确保了探索过程中的智力成果能够转化为持久的知识资产。定期巡检（Lint）：模型会定期对 Wiki 进行健康检查。检查内容包括页面间的逻辑矛盾、被新数据覆盖的陈旧主张、没有任何入站链接的孤岛页面，以及提到但尚未建立专门页面的重要概念。3、索引与日志系统index.md：按类别组织的目录文件，包含每个页面的链接和单行摘要。模型在回答问题前会先阅读索引以确定相关页面，这在数百个页面的规模下比向量检索更具确定性。log.md：按时间顺序记录的所有操作日志，包括摄取记录、查询记录和巡检结果。通过统一的日期前缀格式，用户可以使用简单的命令行工具对知识库的演进过程进行追溯。4、辅助工具与集成建议本地搜索：当 Wiki 规模扩大时，可以使用 qmd 等本地搜索引擎。它支持 BM25 关键词搜索与向量语义搜索的混合模式，并提供 MCP 服务器接口，方便模型直接调用。图像管理：建议将网页剪藏中的图像下载至本地目录（如 raw/assets/）。由于模型无法一次性读取包含大量内联图像的 Markdown，目前的实践是先让模型读取文本，再根据需要单独查看引用的图像文件。元数据管理：利用 Obsidian 的 Dataview 插件，配合模型在文件头部生成的 YAML Frontmatter（包含标签、日期、来源计数等），可以实现动态的列表展示和数据统计。5、协作模式与维护逻辑在这种模式下，人类用户的职责在于筛选高质量素材、引导分析方向以及审阅模型生成的更新。模型则负责处理繁琐的簿记工作，如维护交叉引用的准确性、保持各页面间的一致性以及更新索引。这种分工解决了传统 Wiki 因维护成本随规模增长而最终被放弃的问题。LLM Wiki 的本质是将知识管理从一种检索行为转变为一种编译行为，通过持续的增量更新，使知识库在结构上趋于严密。gist.github.com/karpathy/442a6bf555914893e9891c11519de94f

9. 用Obsidian+Karpathy方法搭建"不断生长"的知识库系统

10. 如何评价DeepSeek发布梁文锋署名论文，提出「条件记忆」及Engram记忆检索架构？有哪些亮点？

11. 「Github一周热点95期」META 3D 模型、智能体记忆引擎、向量数据库、 Web 3D 引擎、AirPods 跨平台、数据库管理工具

12. 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# #程序员#

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

14. 深度解析RAG、LangChain、Agent三者间的关系（附应用案例+大厂内部资源合集）

15. 从RAG到记忆工程：AI长期记忆系统的架构范式与落地瓶颈

16. 大神Karpathy的AI 知识库系统搭建，5分钟搞定

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

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

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

20. 《扣子开发 AI Agent 智能体应用》016-基于大模型的企业知识库（知识库实战：打造汽车行业智能客服）

21. SLS 智能问答助手：秒解游戏运营客服难题

22. AI 化知识管理怎么做？Obsidian x GAP 管理法｜AI 做搬运、我做判断

23. 在线文档智能检索新利器——OpenRAG（GitHub: github.com/langflow-ai/openrag）是一款集成Langflow、Docling和OpenSearch的Retrieval-Augmented Generation平台，专为实现智能问答和文档搜索设计。OpenRAG核心优势：- 一键安装即用，所有核心组件无缝对接，开箱即用体验。- 支持多文档快速索引，能处理复杂的真实世界数据，实现精准语义检索。- 集成Langflow的可视化拖拽流程编辑器，方便快速搭建和调试RAG工作流。- 以OpenSearch为底层引擎，保证企业级海量数据检索的高性能和稳定性。- 多agent智能协调和重排序机制，提升问答质量和响应智能度。- 提供Python和TypeScript官方SDK，方便开发者灵活集成入自有应用系统。快速上手：1️⃣ 部署OpenRAG（支持Docker、一键安装）2️⃣ 导入文档进行智能语义索引3️⃣ 即刻开始基于大模型的智能聊天问答体验OpenRAG将文档检索和生成式AI完美结合，助力企业和开发者打造强大的智能知识库和客服机器人，体验未来智能搜索的无限可能。#AI创造营##人工智能#

24. 知识表示是什么：为什么人工智能离不开知识表示

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

26. 基于ima知识库在教、学、评中的应用（二）

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

28. 9000+篇AI教程，现在能“一键问答”了！WaytoAGI知识库大升级

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

30. RAG（检索增强生成）会不会消亡呢？

31. 对于码字爱好者来说，最好用的知识库工具竟然是WPS

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

33. 《扣子开发 AI Agent 智能体应用》015-基于大模型的企业知识库（扣子知识库介绍）

34. 基于AI知识库的教学评应用研究

35. 我这几天也照着Karpathy的思路在claude code建了个人知识库，我觉得非常有帮助，尤其在跨领域的知识关联上，太方便了。//@卧猫岗的猫:有了AI以后，启动类似的知识库真是方便容易许多。最近首页博主在转卡帕西的这条，其实之前我已经看到不少各领域的up在搞类似的obsidian知识库，我也搞起了自己的，边工作边扩充，原则是不在工具本身上花过多时间，依照第一性原理，只加有用的。obsidian的界面对初学者不那么友好，有了AI代理，你甚至可以不去界面交互，而是让代理做你需要做的一切，我们自己只需要在头脑里有一个关于知识、链接、big picture的空间概念即可。就像的“思维宫殿”，入口是AI命令行。 #职场# #人工智能#

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

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

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

39. 知识加工：从事实表达到可用知识体系

40. 《扣子开发 AI Agent 智能体应用》013-基于大模型的企业知识库（企业知识库必要性）

41. 销售与客服：把流量自动转化为订单（知识库驱动：让AI 成为你的专业销售助手）

42. AI发达的今天你是如何建立自己的知识库的？如何让它不只是一个知识仓库？

43. 如何看待企业自建AI知识库?

44. 写作与整理：让OpenClaw 接管你的周报与公文（文件读取与知识库搭建）

45. 《REFRAG: Rethinking RAG based Decoding》Meta最新发布的REFRAG技术，彻底解决了检索增强生成模型（RAG）最大的瓶颈：解码效率低下。相比传统RAG，REFRAG实现了30倍更快的首词生成速度，同时保持零准确率损失。问题核心在于：RAG在输入大量检索段落时，实际只有5-10段内容对生成有用，剩余多数成为计算负担，但模型仍对所有段落进行全面注意力计算，导致时间和内存资源巨大浪费。传统RAG用16K上下文时，首次输出延迟超过100秒，吞吐量下降10倍，内存消耗爆表。REFRAG通过将上下文块压缩成单一嵌入向量，避免了对全部16,384个token的逐一处理，仅需处理约1,024个压缩块嵌入，极大减少计算量。成果显著：- 首词生成速度提升30.85倍- 语义困惑度（perplexity）无损失- 上下文容量扩展16倍（4K token → 64K token）- 性能超越前沿技术3.75倍为何行得通？因为RAG的注意力模式稀疏，大多数检索段落间无交互。REFRAG通过以下三点巧妙利用这一点：1. 预计算并缓存嵌入，推理时重复使用2. 基于强化学习的压缩策略，智能决定哪些块需展开3. 不受位置限制，任意位置均可压缩实际应用优势：- 仅8段文本的延迟即可达到单段处理速度- 在检索器性能较弱时，依然提升准确率- 可支持无限长会话历史- 无需修改基础模型架构这项技术改变了RAG的计算经济学：更多上下文、更低延迟，且成本更优。REFRAG不仅是性能优化，更是RAG从“功能”向“基础设施”转型的关键一步。它告诉我们，提升AI系统效率的关键不在于盲目增加计算资源，而是精准减少无效计算，压缩信息冗余，从根本上优化流程。更多细节和论文链接见：arxiv.org/abs/2509.01092这背后，技术创新带来的不仅是速度，更是未来大规模长文本理解与生成的基石。希望更多开发者和研究者能从中得到启发，推动RAG技术应用迈入新阶段。

46. 知识的基本特性：相对正确性、不确定性与可表示性

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

48. 飞书 AI 知识库「知识付费模式」上线：让知识沉淀获得正向回馈

49. 思源笔记+Ollama！在极空间本地搭建强大AI写作系统

50. 【实用】Obsidian + AI ：从零搭建智能知识库（附 Claudian 插件配置）

51. AI开发常常需要切换多个资源库，查文档学Oracle AI Database、找Notebook实验代理系统、看教程建RAG应用，来回折腾效率低下。Oracle AI Developer Hub 把AI开发所需资源全整合，提供完整的Oracle AI Database + OCI服务开发解决方案。包含完整应用demo、Jupyter Notebook、动手workshop、代理记忆包，甚至企业级AI代理架构指南。GitHub：github.com/oracle-devrel/oracle-ai-developer-hub主要功能：- 完整AI应用demo（/apps），展示端到端RAG代理、金融AI助手、健身追踪器等实战案例；- 丰富Jupyter Notebook（/notebooks），覆盖RAG、多代理CoT、混合搜索、11种认知架构实验；- 动手workshop（/workshops），从信息检索到记忆增强代理的全栈学习路径；- Oracle AI Agent Memory包，支持统一内存核心（对话历史、持久事实、实体状态）；- 详细指南（/guides），企业AI代理大脑/骨架构建、记忆工程学科深度解析；- 多云支持，AWS/Azure/Google Cloud + Oracle AI Database集成样例。支持Jupyter、Python、FastAPI、LangChain等多框架，Codespaces一键环境，适合AI工程师和开发者使用。#OracleAI##AI开发##RAG代理#

52. #黄仁勋#未来两三年9成新知识由AI合成# 🤖 AI重塑知识生产英伟达CEO黄仁勋近期提出观点，预计在未来两到三年内，约九成的新知识（例如文档、代码、设计方案等）将直接由人工智能生成或辅助合成。这预示着AI将从信息处理工具，演变为人类知识创造的核心参与者和加速器。评论：这一判断指向了AI发展的深层变革：其角色正从“效率工具” 升维为 “知识合作伙伴” 。如果预言成真，将彻底改变教育、科研、内容创作等所有依赖知识生产的行业。它带来的核心挑战将是：人类角色的重新定位：人的核心价值将更聚焦于提出关键问题、设定伦理框架、进行最终判断和创造性连接，而非重复性知识产出。信息可信度与来源的严峻考验：当大部分新知识由AI生成，如何验证其真实性、避免“幻觉”和偏见污染知识库，将成为社会性难题。新一轮生产力与不平等的悖论：率先善用AI合成知识的组织和个人将获得巨大优势，但如何确保技术普惠、避免知识鸿沟加剧，是需要同步思考的命题。这不仅是技术预测，更是对我们如何学习、创造与建立信任的一次根本性提问。

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

54. 阿里云 Serverless 计算 12 月产品动态

55. 在整理复杂思路、长期笔记和知识链接时，普通笔记工具往往结构不够清晰、检索也不灵活。Trilium Notes是一个开源知识管理应用，把层级结构笔记、本地搜索和关系链接整合在一个系统里，适合构建长期积累的个人知识库。项目地址：github.com/zadam/trilium主要功能1.支持多层级树状笔记结构，适合构建复杂知识体系；2.拥有强大的全文搜索和标签过滤功能；3.支持双向链接和笔记间关系，可视化知识网络；4.提供丰富的编辑器功能，包括代码块、附件和富文本；5.支持本地存储和可选同步方式，数据掌控在自己手里；Trilium Notes不是简单的笔记本，而是一个更强调结构与关联的知识平台，适合长期梳理学习笔记、项目资料或思维导图式内容。

56. AI“投毒”，风险巨大！国家安全机关，紧急提醒→

57. RAG的碎碎念 RAG的实现思路整理

58. 浅谈 RAG（RAG 已死？）

59. llm wiki

60. 基于 LLM Wiki 构建 AI 友好知识库

61. 别再只会搭RAG了，LLM Wiki才是个人和团队知识库的新做法

62. 用AI维护一个越用越聪明的知识库

63. Karpathy开源LLMWiki

64. 别再用 RAG 了！Karpathy 的 LLMwiki 才是 AI 知识库的终局

65. LLM Wiki 和 GBrain 真正的差别，不是谁检索更强。

66. WriteBack-RAG

67. 不用向量检索了，让AI像翻目录一样找企业

68. 学习笔记｜从静态RAG到智能RAG

69. 超越静态检索

70. 静态 RAG 与动态 RAG 技术全解析

71. RAG 2.0架构解析

72. AI知识库检索（RAG）

73. 让Ai建一个"永远在长"的 Wiki.🔥 Karpathy 的知识库新玩法，让 AI 帮你建一个"永远在长"的 Wiki

74. Karpathy 的 LLMWiki 和 OPPO 的小布记忆，殊途同归

75. KarpathyAI牛人教你搭建个人知识库 LLM Wiki

76. 炸锅了！Obsidian+claude code｜跨文档推理不再断裂，知识一次编译，永久知识复利躺赚,--福利

77. Andrej Karpathy 的 “LLM Wiki” 模式

78. LLM Wiki

79. RAG + Wiki 混合检索

80. 打造像Wiki一样的专属RAG知识库｜让AI真正懂你

81. LLM Wiki与传统知识库对比

82. LLM Wiki vs 传统RAG

83. RAG 之外的另一条路

84. 放弃RAG！Karpathy亲自下场

85. Karpathy的笔记法，RAG该退场了

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

87. 📌 LLM Wiki 比 RAG 更值钱

88. RAG 已死，LLM Wiki 永生

89. 【前沿技术分享】LLM Wiki

90. 这可能是 AI 知识管理的新范式

91. LLM Wiki

92. LLM Wiki

93. Karpathy 的 LLM Wiki

94. 从"检索"到"编译"

95. 别RAG了，直接导航

96. 专题解读 | 可更新的检索增强知识库发展方向及进展

97. 基于 LLM Wiki 的 Agentic PKM 实践

98. 知识图谱如何结合 RAG实现更精确的知识问答

99. RAG技术详解

100. 优质的知识底座，才是企业RAG落地的“底气”

101. RAG、知识库、知识图谱在一个系统里怎

102. 从传统RAG到AgentRAG：Java企业AI应用的范式升

103. 大话AI（3）：一次性讲清楚AI大模型检索增强生成（RAG）技术

104. RAG+生成式检索：AI幻觉的终结者？

105. Karpathy - LLM Wiki 学习报告

106. 当 LLMWiki 拆掉 Web3 的最后一道墙：从 “数字废墟” 到 “主权资产” 的终局路标

107. RAG系统如何检索知识？

108. AI原生知识图谱的统一框架（一）

109. 原生智能革命：内置知识库与多Agent协同，定义大模型AI Native新范式

110. RAG知识库技术解析：企业AI应用的核心基础设施

111. 500强企业都在用的AI知识问答系统！数商云凭何成推荐首选？

112. LLM Wiki不是新工具，而是知识终于开始“活”了

113. 2026年AI工程师必须掌握的8种RAG架构模式

114. RAG 不是搭完就结束

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

116. 面试官：企业级RAG知识库如何构建？构建企业级RAG知识库，先做好企业内文档（PDF、数据库、API 数据等）的清洗、结构化处理（拆分段落、提取关键信息），同时通过加密手段保障数据合规；再选用适配业务的embedding 模型（如通义千问Embedding、Sentence-BERT）将文本转化为向量，存入高可用向量数据库（如Milvus、Chroma）；接着搭混合检索（关键词＋向量检索）+上下文增强逻辑，提升召回精度；最后结合私有化部署落地，配套权限管控和知识库迭代机制（根据用户反馈优化数据与检索策略）。 #RAG #知识库搭建 #知识库 #AI大模型 #面试题

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

118. 基于RAG架构的DeepSeek大模型本地知识库构建教程分享 - 哔哩哔哩

119. 大模型入门第十一课：RAG初探：给大模型装上“知识检索引擎”

120. LLM Wiki是一套AI主导的动态知识管理

121. RAG、智能RAG与AI记忆

122. 使用开源项目 llm-wiki-compiler 搭建 Claude Code 知识库

123. RAG知识库应用及安全边界

124. 面向客户沟通场景的知识库搭建方案（高效查阅 + 提升服务质量）

125. 从Datasheet到LLMWiki的工程化方法

126. 2025年企业知识库推荐：产品经理必看！RAG、安全合规与国产化全栈适配的选型指南

127. Hermes Agent支持微信！打造Wiki知识库 🚀Hermes Agent高级玩法！微信扫码即用+LLM Wiki知识库+Obsidian图谱，AI知识管理终极方案！人人都可以打造自己的数据飞轮！复刻Andrej Karpathy工作流！保姆级教程 🚀🚀🚀视频简介： ✅【保姆级教程】告别传统RAG！Hermes Agent内置LLM Wiki实现知识复利增长，从论文到结构化知识库只需一条命令！ 🔥 本期视频详细演示了Hermes Agent的两大高级功能：个人微信原生集成和LLM Wiki知识库构建。 📱 首先演示了Hermes Agent连接个人微信的完整流程——扫码登录、配对连接、私聊交互，轻松在微信中调用AI能力。 📚 重点讲解了基于Andrej Karpathy分享的LLM Wiki知识库工作流。通过深入对比传统RAG（无状态碎片检索）与LLM Wiki（有状态知识编辑），揭示了知识复利增长的核心优势。实战演示了：从ArXiv批量摄入论文 → 自动提取结构化知识 → 生成交叉引用的Wiki页面 → 在Obsidian中可视化Graph图谱 → 多Wiki无缝切换与合并。 🏗️ 详细解析了LLM Wiki的三层架构：不可变的原始来源层、Agent驱动的Wiki页面层、人机协同的进化层，真正实现"编译一次，持续更新"的数据飞轮。 #HermesAgent #Hermes #AI #LLMWiki #AI智能体

128. RAG检索增强生成实战：构建智能知识库系统

129. 基于知识图谱的智能问答系统 | 项目介绍基于知识图谱的智能问答系统 | 项目介绍项目简介这是一个大语言模型(LLM)+知识图谱(KG)深度融合的智能问答平台。通过Neo4j图数据库存储结构化知识，结合DeepSeek大模型生成自然语言答案，实现精准、可追溯的问答服务。技术架构技术栈： - 后端：Flask + SQLite + Neo4j - 前端：Vue.js + Element UI + ECharts - AI：DeepSeek API + jieba中文分词 - 知识处理：PDF解析 + OCR识别 + 三元组抽取数据流：用户提问 → 语义理解 → 知识图谱检索 → 上下文构建 → LLM生成答案核心功能 1. 智能问答 - 6种问题类型自动识别（定义/方法/原因/列举/对比/功能） - 多维度知识检索：完整问题+关键词+实体 - 流式输出，实时响应 2. 文档智能处理 - PDF自动解析（文本提取/OCR识别） - LLM驱动的知识三元组抽取 - 11种实体类型自动标注 - 全自动：PDF → 文本 → 三元组 → 知识图谱 3. 知识图谱管理 - ECharts交互式可视化 - 1-3度关系深度扩展 - 节点/关系增删改查 - 支持10万+节点的高性能查询 4. 用户管理 - 登录/注册/角色权限 - 个人中心/头像上传 - 科技感可视化大屏三大创新点创新一：LLM+KG深度融合架构解决痛点：纯LLM有"幻觉"问题，纯KG缺乏自然交互方案： - 知识图谱 = 可靠知识源（避免幻觉、支持溯源） - 大模型 = 自然语言引擎（理解意图、流畅表达） - 两者协同：图谱提供事实，LLM生成答案效果：既保证知识准确性，又实现自然对话体验创新二：智能语义理解系统亮点： - 自研中文语义搜索引擎 - TF-IDF + TextRank双算法关键词提取 - 自定义领域词典，可快速适配医学/法律/金融等领域 - 智能降级机制，保证不同环境稳定运行创新三：文档自动知识化全自动流水线： 1. 智能PDF解析（自动判断是否需要OCR） 2. LLM驱动知识抽取（先纠错再提取） 3. 批量写入Neo4j（自动去重同步）效果：上传PDF即可自动构建知识图谱，零人工干预#neo4j #知识图谱构建 #知识图谱可视化 #智能问答 #计算机毕业设计

130. RAG vs GraphRAG vs LLM Wiki 一次讲透：Karpathy引爆的LLM Wiki，是知识工程的下一次革命，还是又一个被高估的"自我进化"

131. 如何看待Karpathy倡导的LLM Wiki？它是RAG技术的终结者吗？

132. 基于RAG架构的DeepSeek大模型本地知识库构建实战--itxt.top

133. 知识图谱+大模型智能问答系统

134. 企业知识库 RAG 落地：从架构选型到组件决策的完整思路

135. RAG落地实践：知识库三层架构和关键组件

136. 【neo4j知识图谱实战项目】基于知识图谱的智能问答系统

137. 企业级知识库问答系统开源

138. 用了就回不去了！LLMwiki+Obsidian搭建个人知识库

139. RAG我懂你：从架构到知识库构建

140. 怎么用 LLM 和 Obsidian 搭一个会持续进化的知识库？

141. 知识图谱知识库智能问答

142. 如何用 LLM 搭建个人知识库？Karpathy 给出了一套清晰框架

143. 企业知识库-多模态RAG 多模态RAG通过理解和处理文字、图纸、照片、视频等多种信息，将制造业分散的知识资产转化为随时可查、精准可用的智能系统，是推动企业数字化转型的关键技术。基于Python + FastAPI + ES + MySQL + Angular开发的多模态企业知识库，支持云端和本地化私有化部署，LLM可以使用云端API和本地部署的大模型，支持图文搜索和联网搜索，知识库查询返回结果支持图文显示和用户反馈，支持文档权限管理（公开、私有、部门和分享）。#企业数字化转型 #介绍自己开发 #AI #llm

144. 图解 RAG（十三）快速入门｜实战应用：企业知识库问答系统选型与搭建

145. 【2026】大模型RAG实战！企业级知识库与问答系统设计！增加检索/文本向量/知识库搭建

146. 腾讯版小龙虾「WorkBuddy Claw」体验25：我的知识库+Karpathy知识库「LLM Wiki」

147. 别再用RAG做知识库了，赶紧试试LLM Wiki吧现在业界主流的知识库检索管理方案都是RAG，但RAG被吐槽不是一天两天了。Karpathy直接提出了LLM Wiki的新思路：让大模型自己管理知识，不再依赖传统检索。我觉得这个方向太对了，于是干脆自己动手写了一个LLM Wiki Agent，能把研报PDF自动拆解归档，按概念、实体、来源分层索引，随时精准调取机构观点。项目近期开源，评论区欢迎讨论。 #LLMWiki #RAG #AI知识库 #Agent #vibecoding

148. 生成式AI(GenAI)的定义、原理和局限性

149. #抖音科技风向标你有没有这样的经历？读了一堆文章，收藏夹里塞满"稍后阅读"，结果再也没有读过。做了大量笔记，但想找某个观点时，翻了三小时也找不到。学了新知识，却不知道怎么和旧知识联系起来。问题不在你，在你的工具。今天，我要告诉你一个秘密：Andrej Karpathy——就是那个从特斯拉AI总监做到 OpenAI 创始成员的顶级工程师——刚刚开源了他的私人知识库搭建方法。他把这个系统叫做 "LLM Wiki"。简单说，LLM Wiki 是让 AI 当你的图书管理员。传统做法是：你读一篇文章，手动整理、分类、贴标签、写摘要。耗时耗力。 Karpathy 的做法是：你把文章扔进去，AI 自动帮你整理成维基百科。不是简单的总结，而是—— 自动识别文章里提到的人、公司、产品（实体）自动提炼概念、理论、方法（概念）自动建立它们之间的关系所有内容双向链接，像维基百科一样互相跳转这套知识库核心需要两套工具，一个是ai agent （claude code or codex or openclaw等）、一个是obsidian。#claudecode #codex #obsidian #llmwiki

RAG与LLM Wiki：知识库该动态进化还是静态沉淀？

精选参考来源