知识库系统从“开卷现抄”到“融会贯通”的进化之路,下一代RAG将如何真正学会“沉淀”与“思考”?
核心内容:
剖析当前主流RAG系统“只查不学”的四大核心症状
揭示问题根源在于系统结构而非参数调优
下一代RAG实现知识沉淀、连接与可信的演进方向

你的 RAG 还在「现翻现抄」吗?从开卷现抄到融会贯通:你那套存量 RAG,该往哪走。聊聊知识沉淀这件事
如果你维护过一套上了线的 RAG 系统,大概率对这个画面不陌生。
用户问一句话,系统把切好的几十个 chunk 现场捞一批出来,按相似度排个序,拼成一段上下文,塞给大模型,让它"看着这堆碎片现编一个答案"。答完,碎片散去,什么都没留下。下一个人问几乎一样的问题,整个过程从头再来一遍。
这很像一个开卷考试的学生——题目来了才翻书,翻到哪页抄哪页,考完什么也没记住。
它能用,甚至大部分时候还挺好用。但你心里清楚:这套东西"会查",却从来不"会学"。
一、先对个症状:这几条你中了几条
把主流做法摆出来,免得我们在抽象里打转。
绝大多数存量系统长一个样:文档切成 chunk,过 embedding 进向量库;查询来了,用朴素向量、或者 BM25+向量的混合、或者 HyDE(先让模型生成一个"假想答案"再拿去检索)召回;召回完 rerank 一下,拼成上下文喂给 LLM。这套范式没有错,它召回快、上手快、覆盖广,是过去两年最务实的工程选择。
但它有一个底层的"人格":它是一个只会开卷现抄、从不做笔记的学生。

症状自检:chunk失上下文 / 知识不沉淀 / 连不起来 / 工程欠账
下面这几条,你中了几条:
•
chunk 丢了上下文。一个孤立的 chunk 写着"当该值低于 -110摄氏度 时上报告警"——可它指的是 恒温机 还是 高速离子对冲机?出自哪一章?切下来那一刻,这些都丢了。就像你把课本撕成纸条,每张纸条本身都对,但谁也不知道它原来在讲什么。
•
知识从不沉淀。同一个事实散落在几十个匿名 chunk 里,每次查询都是现捞、现拼、现生成。不积累、不去重、不演进——这个学生考了一百次试,笔记本永远是空白的。
•
连不起来。凡是需要把信息串成一条线的问题——多跳关系、某一类故障的共性根因——它基本答不上来。因为它脑子里压根没有"实体"和"关系",只有一堆互不相识的句子。
•
工程上还欠着账。很多系统的混合融合用的是非标准的"排名倒数×权重",过度偏袒第一名;上下文超长就硬截断,可能恰好砍掉最相关那段证据;更要命的是,几乎都没有评测和回归框架——改完一个参数,是涨是跌,全靠拍脑袋。
中了三条以上?恭喜你,拥有一套非常典型、非常主流的存量 RAG。这不丢人,这就是行业现状。
接下来要说的,不是让你把这个学生开除,而是教他做笔记。
二、病因不在参数,在结构
在聊怎么改之前,先把病因说清楚,否则容易又掉进"是不是我哪个参数没调好"的自责里。
不是你没调好,是结构本身只到地基。
过去两年,所有人的力气都花在"怎么把碎片捞得更准"上——更好的 embedding、更狠的 rerank、更花的混合策略。这些都没白费,但它们优化的是召回这一个动作。而你线上那些真正难缠的问题,根子不在召回准不准,在于:你的系统里压根没有"知识"这一层,只有一堆碎片。
chunk + embedding 是地基,负责"找得到"。地基没错,也不会消失。但你现在是在拿地基去干楼房的活——你要求一堆撕碎的、匿名的、互不相识的纸条,去回答需要结构、需要关系、需要出处的问题。它当然答不好。
这不是调参能解决的。这是表示层(representation)太薄。
三、三个出圈项目,其实在喊同一句话
最近有三个项目在技术圈里都有些声量。它们形态差得很远,凑到一起看,却在指向同一件事。

三个信号殊途同归:llm_wiki / gbrain / okf
信号一: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、worksat、investedin 之类)的知识图谱;检索时才上"向量 + 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)要做厚。

retrieval 做薄、representation 做厚
过去我们把心思全花在"怎么把碎片捞得更准",那是在优化"现抄"这个动作本身。而这三个项目不约而同地把重心挪到了上游:先把知识好好整理、沉淀成一层,再在这层之上去查。
那个开卷现抄的学生,要变成一个有自己知识体系的人。区别不在于他书架上的书多了,而在于他脑子里那张图——概念之间连着线,重要的口径单独记成了卡片,新学的东西是往旧笔记上"增补"而不是每次重写。
五、务实的演进路线:先建尺子,再动检索
讲了半天"该往哪走",关键是"怎么走得不翻车"。态度先摆明:
存量系统是资产,不是包袱。绝大多数升级,都能用"配置开关 + 旁路"灰度接进去,没必要推倒重来。

演进路线图:第0步建尺子 → 补课 → 知识沉淀 → 按数据决定
第 0 步,先建一把尺子。动手改检索之前,先搭评测地基——RAGAS 加上你自己按难度分桶的黄金回归集。没有这把尺子,后面所有优化都是拍脑袋,你永远不知道某次改动到底是涨了还是跌了。这一步不性感,但它是地基的地基。
第一阶段:低风险、高回报的"补课"。
•
Contextual Retrieval(性价比最高的单项)。据 Anthropic 官方博客,做法是入库期给每个 chunk 用 LLM 补 1-2 句"它属于哪个文档、哪个章节"的上下文,再同时喂给 embedding 和 BM25。官方数据:top-20 检索失败率(即 1 − recall@20)单用 contextual embeddings 降约 35%,叠加 contextual BM25 降约 49%。注意那个流传最广的"最高降约 67%",是再叠加 rerank 之后的上限值,不是常态增益,别当普适数字截图转发。成本可以用 prompt caching 压下来。这一步,就是给每张笔记纸条重新标上它从哪本书、哪一页来的。
•
把"排名倒数×权重"换成标准 RRF。RRF(按多路排名倒数求和的标准融合法)公式是score = Σ 1/(k+rank)。很多系统那种"排名倒数×权重"约等于 k=0,会过度偏袒第一名;小语料把 k 取 10-20 就稳得多(业界默认常用 k=60)。几乎零调参,融合立刻更稳。
•
挂一个领域术语/缩写词典做查询增强。把缩写补全、挂上标准术语再去检索。telecom 这种缩写满天飞的领域,收益尤其明显。
•
盘活已经切好的分层结构。很多系统切了父子层级,检索期却没回溯父块——补上 small-to-big / auto-merging(命中精确小块时,把它所属的整段父上下文一起带上),精度和可读性都涨。
这一阶段的共同点:都是配置级改动,旁路灰度,风险低、见效快。
第二阶段:开始真正做"知识沉淀"。在召回地基之上,长出那层显式知识——实体、关系、源追溯、防灌水门控。前面三个项目的设计可以直接借鉴:来源 frontmatter、共享实体保留、enrich/mint/skip 的择一决策。这一步让系统从"会查"迈向"会记"。
第三阶段:按数据决定要不要上 GraphRAG / agentic。注意是"按数据决定",不是"因为时髦所以上"。
六、哪些"看着酷",但多半别乱碰
这部分可能比上面更值钱。技术圈不缺新词,缺的是知道哪些新词不该追。

看着酷但多半别乱碰:ColBERT/全量GraphRAG/全agentic/照搬形态
判断标准只有一条:
它是在补你测出来的短板,还是只在补你的 FOMO?没有第 0 步那把尺子,你永远分不清这两者。
•
ColBERT / 多向量。听起来先进,但它要你换向量库、存储暴涨,而那点检索增益很大程度上被你现成的 rerank 抵消了。投入产出比不划算。
•
完整版、全量 GraphRAG 索引。GraphRAG 是好东西,但要分清定位。ORAN 这一篇基准(arXiv:2507.03608)的结论是:向量在简单、事实型问题上更有优势,图在多跳、复杂关系型问题上更强,二者 hybrid 总体最佳——图是来补短板的,不是来替换向量的。而全量 GraphRAG 索引非常贵。成本敏感的话,看看 LazyGraphRAG(按需、惰性地构图,省掉全量索引那笔大开销)。
•
一步到位的全 agentic 迭代检索。它会增加延迟,对大量单跳问题收益很小。更稳的是按意图分流(路由)+ CRAG(检索质量门控:检索质量差就改写查询、或老实兜底"信息不足")那种做法,抑制低质上下文喂出来的幻觉。
•
照搬别人的形态。别人做成桌面单机、别人用了某套领域本体,未必适合你。形态是手段,不是目的。
七、收个尾
回到那个开卷考试的学生。
我们花了两年,把他训练成一个"查得飞快"的考生——embedding 越来越准,rerank 越来越狠,混合策略越来越花。这件事本身是对的,地基必须夯实。
但下一段路要解决的是另一个问题:让他开始做笔记、建体系,让知识不再是每次现捞现拼的一次性碎片,而是一层会沉淀、会演进、能追溯到出处的资产。
而且这件事不需要你推倒重来。它可以从一个配置开关、一条旁路、一把评测尺子开始,渐进地长出来。
上一代 RAG 解决的是"找得到";下一代要解决的是——知识被沉淀下来、连得起来、信得过。
你那套跑了两年的系统,地基其实打得不错,差的只是地基之上那一层——还没长出来的知识。别急着革它的命,先教它做笔记。
———————————————————–

