AI知识库RAG演进：上一代解决「找得到」，下一代解决「记得住、连得起、信得过」

你的 RAG 还在「现翻现抄」吗？从开卷现抄到融会贯通：你那套存量 RAG，该往哪走。聊聊知识沉淀这件事

如果你维护过一套上了线的 RAG 系统，大概率对这个画面不陌生。

用户问一句话，系统把切好的几十个 chunk 现场捞一批出来，按相似度排个序，拼成一段上下文，塞给大模型，让它"看着这堆碎片现编一个答案"。答完，碎片散去，什么都没留下。下一个人问几乎一样的问题，整个过程从头再来一遍。

这很像一个开卷考试的学生——题目来了才翻书，翻到哪页抄哪页，考完什么也没记住。

它能用，甚至大部分时候还挺好用。但你心里清楚：这套东西"会查"，却从来不"会学"。

一、先对个症状：这几条你中了几条

把主流做法摆出来，免得我们在抽象里打转。

绝大多数存量系统长一个样：文档切成 chunk，过 embedding 进向量库；查询来了，用朴素向量、或者 BM25+向量的混合、或者 HyDE（先让模型生成一个"假想答案"再拿去检索）召回；召回完 rerank 一下，拼成上下文喂给 LLM。这套范式没有错，它召回快、上手快、覆盖广，是过去两年最务实的工程选择。

但它有一个底层的"人格"：它是一个只会开卷现抄、从不做笔记的学生。

下面这几条，你中了几条：

中了三条以上？恭喜你，拥有一套非常典型、非常主流的存量 RAG。这不丢人，这就是行业现状。

接下来要说的，不是让你把这个学生开除，而是教他做笔记。

二、病因不在参数，在结构

在聊怎么改之前，先把病因说清楚，否则容易又掉进"是不是我哪个参数没调好"的自责里。

不是你没调好，是结构本身只到地基。

过去两年，所有人的力气都花在"怎么把碎片捞得更准"上——更好的 embedding、更狠的 rerank、更花的混合策略。这些都没白费，但它们优化的是召回这一个动作。而你线上那些真正难缠的问题，根子不在召回准不准，在于：你的系统里压根没有"知识"这一层，只有一堆碎片。

chunk + embedding 是地基，负责"找得到"。地基没错，也不会消失。但你现在是在拿地基去干楼房的活——你要求一堆撕碎的、匿名的、互不相识的纸条，去回答需要结构、需要关系、需要出处的问题。它当然答不好。

这不是调参能解决的。这是表示层（representation）太薄。

三、三个出圈项目，其实在喊同一句话

最近有三个项目在技术圈里都有些声量。它们形态差得很远，凑到一起看，却在指向同一件事。

信号一：nashsu/llm_wiki（约 13k★）。 灵感来自 Andrej Karpathy 提的"LLM Wiki"模式。它用 LLM 把源文档一次性"编译"成一座可演进的 Markdown 知识库——实体页、概念页、综合页，彼此用 [[wikilink]] 互链，配上知识图谱和社区检测。关键在于：查询主要在这座沉淀好的 wiki 上跑，而不是每次回到原始 chunk 里重新刨。 工程上也体面：每页 frontmatter 里记 sources[]，来源可追溯；删源时做"共享实体保留"——只移除被多源引用实体的那一条来源关联，而不是一刀切删整页；检索时以命中页为种子做 2-hop 图扩展。

这就是那个学生终于开始整理笔记本、给知识点之间画箭头了。

信号二：garrytan/gbrain（YC 的 Garry Tan 开源）。 面向 AI agent 的"记忆层"。最有意思的是：写入时"零 LLM"——用 regex + schema 规则织出一张带类型边（attended、works_at、invested_in 之类）的知识图谱；检索时才上"向量 + BM25 + 标准 RRF + rerank + 图信号"的混合。在它自建的基准上（240 页语料），把图信号关掉，P@5 明显下降约 31 个点。

这里给个诚实的注脚：这是合成基准上的单点结果，只能当方向参考，别当普适数字。 它想说的方向是——结构化关系能补纯语义的不足。另外，它真实管理的规模约 14.6 万页（早期网传的"1.7 万页"是错的，差了一个量级）。它还会跟踪时间线，并在 think 的时候显式标出"我这儿有个知识缺口"。

信号三：GoogleCloudPlatform/okf（Open Knowledge Format，2026-06 发布 v0.1）。 Google Cloud 的"开放知识格式"。它把 agent 知识库表示成一堆带 YAML frontmatter 的纯 Markdown + 链接构成的弱类型有向图——知识像源代码一样可以 git diff、提 PR、做 review，不被锁进任何专有向量库。它的参考实现里，agent 面对新信息会在三条路里择一：把内容补进已有文档（enrich）、新建一个独立 reference（mint）、或者干脆 skip；另配一个 conformance validator，检查质量问题。

要注意：okf 只是知识表示规范，不是检索引擎。 别拿它当检索方案用。

把三句话并排放：

llm_wiki 把源文档编译成互链 wiki；gbrain 用规则织图谱、检索期叠图信号；okf 用 Markdown 有向图把知识变成可 git 管理的源代码。

桌面 Rust、Bun+Postgres、纯 Markdown 规范——三套技术栈八竿子打不着，路径各不相同，内核却是同一个。

四、点透这层窗户纸：retrieval 做薄，representation 做厚

三个项目拼在一起，共性就一句话：

检索那一层（retrieval）要做薄，表示那一层（representation）要做厚。

过去我们把心思全花在"怎么把碎片捞得更准"，那是在优化"现抄"这个动作本身。而这三个项目不约而同地把重心挪到了上游：先把知识好好整理、沉淀成一层，再在这层之上去查。

那个开卷现抄的学生，要变成一个有自己知识体系的人。区别不在于他书架上的书多了，而在于他脑子里那张图——概念之间连着线，重要的口径单独记成了卡片，新学的东西是往旧笔记上"增补"而不是每次重写。

五、务实的演进路线：先建尺子，再动检索

讲了半天"该往哪走"，关键是"怎么走得不翻车"。态度先摆明：

存量系统是资产，不是包袱。绝大多数升级，都能用"配置开关 + 旁路"灰度接进去，没必要推倒重来。

第 0 步，先建一把尺子。 动手改检索之前，先搭评测地基——RAGAS 加上你自己按难度分桶的黄金回归集。没有这把尺子，后面所有优化都是拍脑袋，你永远不知道某次改动到底是涨了还是跌了。这一步不性感，但它是地基的地基。

第一阶段：低风险、高回报的"补课"。

这一阶段的共同点：都是配置级改动，旁路灰度，风险低、见效快。

第二阶段：开始真正做"知识沉淀"。 在召回地基之上，长出那层显式知识——实体、关系、源追溯、防灌水门控。前面三个项目的设计可以直接借鉴：来源 frontmatter、共享实体保留、enrich/mint/skip 的择一决策。这一步让系统从"会查"迈向"会记"。

第三阶段：按数据决定要不要上 GraphRAG / agentic。 注意是"按数据决定"，不是"因为时髦所以上"。

六、哪些"看着酷"，但多半别乱碰

这部分可能比上面更值钱。技术圈不缺新词，缺的是知道哪些新词不该追。

判断标准只有一条：

它是在补你测出来的短板，还是只在补你的 FOMO？没有第 0 步那把尺子，你永远分不清这两者。

七、收个尾

回到那个开卷考试的学生。

我们花了两年，把他训练成一个"查得飞快"的考生——embedding 越来越准，rerank 越来越狠，混合策略越来越花。这件事本身是对的，地基必须夯实。

但下一段路要解决的是另一个问题：让他开始做笔记、建体系，让知识不再是每次现捞现拼的一次性碎片，而是一层会沉淀、会演进、能追溯到出处的资产。

而且这件事不需要你推倒重来。它可以从一个配置开关、一条旁路、一把评测尺子开始，渐进地长出来。

上一代 RAG 解决的是"找得到"；下一代要解决的是——知识被沉淀下来、连得起来、信得过。

你那套跑了两年的系统，地基其实打得不错，差的只是地基之上那一层——还没长出来的知识。 别急着革它的命，先教它做笔记。