你的 RAG 还在「现翻现抄」吗？从开卷现抄到融会贯通：你那套存量 RAG，该往哪走。聊聊知识沉淀这件事
如果你维护过一套上了线的 RAG 系统，大概率对这个画面不陌生。
用户问一句话，系统把切好的几十个 chunk 现场捞一批出来，按相似度排个序，拼成一段上下文，塞给大模型，让它"看着这堆碎片现编一个答案"。答完，碎片散去，什么都没留下。下一个人问几乎一样的问题，整个过程从头再来一遍。
这很像一个开卷考试的学生——题目来了才翻书，翻到哪页抄哪页，考完什么也没记住。
它能用，甚至大部分时候还挺好用。但你心里清楚：这套东西"会查"，却从来不"会学"。
一、先对个症状：这几条你中了几条
把主流做法摆出来，免得我们在抽象里打转。
绝大多数存量系统长一个样：文档切成 chunk，过 embedding 进向量库；查询来了，用朴素向量、或者 BM25+向量的混合、或者 HyDE（先让模型生成一个"假想答案"再拿去检索）召回；召回完 rerank 一下，拼成上下文喂给 LLM。这套范式没有错，它召回快、上手快、覆盖广，是过去两年最务实的工程选择。
但它有一个底层的"人格"：它是一个只会开卷现抄、从不做笔记的学生。
下面这几条，你中了几条：
chunk 丢了上下文。 一个孤立的 chunk 写着"当该值低于 -110摄氏度 时上报告警"——可它指的是 恒温机 还是 高速离子对冲机？出自哪一章？切下来那一刻，这些都丢了。就像你把课本撕成纸条，每张纸条本身都对，但谁也不知道它原来在讲什么。
知识从不沉淀。 同一个事实散落在几十个匿名 chunk 里，每次查询都是现捞、现拼、现生成。不积累、不去重、不演进——这个学生考了一百次试，笔记本永远是空白的。
连不起来。 凡是需要把信息串成一条线的问题——多跳关系、某一类故障的共性根因——它基本答不上来。因为它脑子里压根没有"实体"和"关系"，只有一堆互不相识的句子。
工程上还欠着账。 很多系统的混合融合用的是非标准的"排名倒数×权重"，过度偏袒第一名；上下文超长就硬截断，可能恰好砍掉最相关那段证据；更要命的是，几乎都没有评测和回归框架——改完一个参数，是涨是跌，全靠拍脑袋。
中了三条以上？恭喜你，拥有一套非常典型、非常主流的存量 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 加上你自己按难度分桶的黄金回归集。没有这把尺子，后面所有优化都是拍脑袋，你永远不知道某次改动到底是涨了还是跌了。这一步不性感，但它是地基的地基。
第一阶段：低风险、高回报的"补课"。
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。 注意是"按数据决定"，不是"因为时髦所以上"。
六、哪些"看着酷"，但多半别乱碰
这部分可能比上面更值钱。技术圈不缺新词，缺的是知道哪些新词不该追。
判断标准只有一条：
它是在补你测出来的短板，还是只在补你的 FOMO？没有第 0 步那把尺子，你永远分不清这两者。
ColBERT / 多向量。 听起来先进，但它要你换向量库、存储暴涨，而那点检索增益很大程度上被你现成的 rerank 抵消了。投入产出比不划算。
完整版、全量 GraphRAG 索引。 GraphRAG 是好东西，但要分清定位。ORAN 这一篇基准（arXiv:2507.03608）的结论是：向量在简单、事实型问题上更有优势，图在多跳、复杂关系型问题上更强，二者 hybrid 总体最佳——图是来补短板的，不是来替换向量的。而全量 GraphRAG 索引非常贵。成本敏感的话，看看 LazyGraphRAG（按需、惰性地构图，省掉全量索引那笔大开销）。
一步到位的全 agentic 迭代检索。 它会增加延迟，对大量单跳问题收益很小。更稳的是按意图分流（路由）+ CRAG（检索质量门控：检索质量差就改写查询、或老实兜底"信息不足"）那种做法，抑制低质上下文喂出来的幻觉。
照搬别人的形态。 别人做成桌面单机、别人用了某套领域本体，未必适合你。形态是手段，不是目的。
七、收个尾
回到那个开卷考试的学生。
我们花了两年，把他训练成一个"查得飞快"的考生——embedding 越来越准，rerank 越来越狠，混合策略越来越花。这件事本身是对的，地基必须夯实。
但下一段路要解决的是另一个问题：让他开始做笔记、建体系，让知识不再是每次现捞现拼的一次性碎片，而是一层会沉淀、会演进、能追溯到出处的资产。
而且这件事不需要你推倒重来。它可以从一个配置开关、一条旁路、一把评测尺子开始，渐进地长出来。
上一代 RAG 解决的是"找得到"；下一代要解决的是——知识被沉淀下来、连得起来、信得过。
你那套跑了两年的系统，地基其实打得不错，差的只是地基之上那一层——还没长出来的知识。 别急着革它的命，先教它做笔记。
-----------------------------------------------------------
