「SAG+LLM WIKI」：我将称之为最强知识库！

我最近越来越觉得，很多公司建知识库，一不小心就建成了一座特别漂亮的网盘。

界面很 AI，入口很现代，搜索框也很聪明。可一到真实业务问题，气氛就开始变得尴尬：资料能找回来，关系接不上；答案能生成出来，知识留不下来。

你问“这个指标为什么下降”，系统找回来三段文字；你问“这张表的字段来自哪里”，系统找回来四段说明；你问“这个异常和哪个供应商有关”，系统又找回来一堆看起来相关的会议纪要。每一段都像有用，但你盯着屏幕看一会儿，会发现一个很麻烦的事实：它们只是并排躺在那里。

真正要命的东西没有回来。

这东西叫组织记忆。

所以这篇文章的判断很直接，边界也很清楚：

如果你做的是企业知识库，尤其是数据产品、指标口径、字段血缘、异常复盘、会议记忆这类场景，我会优先把票投给 SAG + LLM Wiki。

SAG 负责把证据找深，LLM Wiki 负责把知识养久。一个像侦察兵，一个像修史官；侦察兵把前线的线索带回来，修史官把线索写进可复用的档案。

接下来，我们顺着企业知识库最真实的麻烦往下拆：为什么 RAG 只解决了第一步，GraphRAG 为什么会变重，SAG 和 LLM Wiki 又为什么刚好能接上后半场。

企业知识库要走到这一步，才算真的过了新手村。

为什么建知识库

很多团队以为，知识库缺的是文档。真正的缺口不在文档数量：公司网盘里常年堆着 PRD、会议纪要、日报、SQL、表结构、指标口径、故障复盘，数量多到能把新人压成薄片。

真正缺的是组织记忆。

比如你问一个老同事：“这个指标为什么不能直接 sum？”

老同事通常不会打开向量库。他会说：“这事要从去年那次口径调整讲起。你看的那张表是汇总层，粒度已经变了；真正的上游在另一个任务里，供应链那边还补过一次口径。”

你看，这句话里不止有答案：事实是这张表已经到了汇总层；路径要从报表追到任务，再追到上游表；历史是去年做过一次口径调整；最后还有判断，这个指标不能直接 sum。

拆到这里，知识库的问题才真正露出来：第一层是找事实，第二层是连关系，第三层是维护可信度。

RAG 主要解决“资料在哪”；GraphRAG 和 SAG 解决“关系怎么走”；LLM Wiki 解决“理解怎么留下”。

所以，一个好的知识库，应该尽量接近那个老同事：它知道资料在哪，也知道资料之间怎么互相牵连；它保留原始证据，也沉淀被反复验证过的理解。

我自己做数据产品时，最怕的场景通常长这样：文档数量不少，一个口径却在三个地方各写了一版；一个字段血缘要从报表追到任务、再追到上游表，还要翻会议纪要确认当时为什么这么改。

有一次排一个预测类指标，我从看板钻到指标口径，又去翻 SQL 和调度任务。最难受的地方在于：资料其实找得到，但每一份资料都只说了自己那一段；指标说明写的是业务口径，SQL 写的是字段加工，会议纪要写的是当时为什么临时调整。三份材料单独看都没错，合起来才知道真正的问题出在哪。

普通检索能把材料找回来，但真正耗人的，是把这些材料重新拼成一条可信链路。

所以，知识库建设的第一性问题应该这样问：

怎么让一个组织的经验，可以被找到、被连接、被更新、被质疑。

RAG 解决了第一步。它让资料开始能被找回。但很快，第二步和第三步就会找上门。

RAG 建立了旧秩序

RAG 是知识库建设史上很重要的一次开门。

它的逻辑很直接：

一条典型 RAG 链路大概是这样：原始资料先被切成 chunk，再转成向量；用户提问以后，系统找回相似片段，最后交给大模型组织成回答。

RAG 的核心动作是相似召回：先找到相关片段，再交给大模型回答。

这里面最关键的动作是“相似”。用户的问题会被转成 embedding，文档片段也会被转成 embedding；系统在向量空间里找距离最近的片段，把它们塞进上下文，让大模型基于这些材料回答。

对大量文档问答来说，这已经够好。

比如用户问：“报销流程需要哪些材料？”相关 chunk 里很可能直接写着“发票、审批单、付款凭证”。RAG 找回来，大模型整理一下，回答就能用。

所以 RAG 的功劳要认。它把大模型从“凭记忆猜”拉回到“看材料回答”，没有这一步，企业知识库基本只能停留在玩具阶段。

裂缝也藏在这里。

相似片段擅长回答“哪里写过这个问题”，处理“这几件事之间怎么连起来”就不够稳。比如你问：“华东门店预测达成率下降，和哪个供应商异常有关？”

普通 RAG 可能会把三类材料一起找回来：一份预测达成率指标说明，一份华东门店销售日报，再加一份供应商延迟交付会议纪要。三段都相关，但只是并排躺在那里。真正要回答这个问题，需要穿过一条链：

供应商 A 延迟交付，影响 SKU X；SKU X 覆盖华东门店，门店履约受影响；实际达成低于预测，最后才表现为指标下降。

业务问题通常不是一个片段，而是一条穿过实体、事件和指标的链路。

这条链路靠“像不像”很难稳定走完。RAG 找到了碎片，业务要的是链路。

于是 GraphRAG 登场。

GraphRAG 的野心和代价

GraphRAG 的思路很自然：既然知识之间有关系，那就把关系建出来。

人、组织、商品、指标、系统、任务、文档，这些都可以成为节点；属于、影响、依赖、计算自、导致、引用，这些都可以成为边。查询时，系统沿着图走。你问“指标为什么下降”，它可以从指标节点出发，找到相关任务、数据表、异常事件、业务对象，再回到原始证据。

这条路线很有吸引力。

普通 RAG 像在仓库里找箱子，GraphRAG 开始给箱子之间拉线。线拉得好，知识库就不再只是资料检索工具，而会变成一张业务地图。

代价也很清楚。

图谱需要抽实体、抽关系、处理别名、做实体归一，还要定义哪些关系合法。供应商 A、A 供应商、供应商集团 A，到底是否指向同一个对象？预测达成率、预测命中率、预测准确率，三者是否指向同一个指标？“影响”“导致”“关联”“归因”，这些关系能不能混用？

这就是本体论和图谱治理的活。

GraphRAG 的强度来自全局关系，成本也来自全局关系的持续治理。

如果治理得好，GraphRAG 会很强；如果治理得差，它会变成一张漂亮但不敢信的图。企业系统又最会制造麻烦：今天一个口径改了，明天一张表下线，后天一个系统迁移。图谱如果跟不上，图里的边就会慢慢变成旧朝档案，格式还在，权力没了。

所以 GraphRAG 的问题很尖锐：

为了让知识库具备关系检索能力，我们一定要先维护一张重型全局图吗？

SAG 就是在这个问题上出手的。

SAG 不修大城，它先追线索

SAG 的名字听起来很论文，叫 SQL-Retrieval Augmented Generation。它来自 2026 年 6 月 14 日提交的 arXiv 论文《SAG: SQL-Retrieval Augmented Generation with Query-Time Dynamic Hyperedges》。

这篇论文给出的是一条深召回路线：用 event/entity 和 SQL join，在查询时动态构造局部关系结构，减少对全局静态图的预构建依赖。

把它拆成人话：SAG 不急着建一张完整大图。它先把每个文本片段整理成“事件 + 实体”，再用 SQL 在查询时动态把关系链拼出来。

普通 RAG 看到 chunk。SAG 会继续问一句：这个 chunk 里发生了什么事？涉及哪些实体？

比如一段材料写着：“6 月 18 日，供应商 A 延迟交付 SKU X，影响华东门店补货，预测达成率下降。”

SAG 会把它整理成：

一边是 event：供应商 A 延迟交付 SKU X，影响华东门店补货，并导致预测达成率下降。另一边是 entities：6 月 18 日、供应商 A、SKU X、华东门店、补货、预测达成率、延迟交付。

SAG 把文本拆成事件和实体，再用 SQL 在查询时动态追线索。

然后放进几张关系表：event 表、entity 表、event_entity 关联表。

查询时，系统先找到相关事件，再通过共享实体继续扩展。从“预测达成率”找到事件 A，从事件 A 找到“SKU X”，再通过“SKU X”找到事件 B，又从事件 B 找到“供应商 A”。这条路靠实体和事件一步步连出来，已经越过了一次向量相似度的能力边界。

这就是 SAG 的关键能力：查询时动态组装局部关系链。

它很像一个轻装部队。GraphRAG 修城、铺路、建全局地图；SAG 平时维护驿站、名单和账册，等问题来了，再根据战场临时集结。

论文摘要里给了两个信号：SAG 避免了全局图重建和持续维护，天然支持增量写入；论文报告称，在 HotpotQA、2WikiMultiHop、MuSiQue 三个多跳 benchmark 上，SAG 在 9 个 Recall@K 指标里拿到 8 个最好结果，MuSiQue Recall@5 为 80.0%。这组数字来自单篇论文摘要，我没有复现实验，所以这里只按论文报告结果处理，不写成实测结论。

它解决的问题很明确：普通 RAG 找相似片段不够深，GraphRAG 建全局图太重，SAG 则用 event/entity + SQL，在查询时把局部关系链拉出来。

如果你的知识库里大量问题都在追指标、追字段、追异常、追供应商，SAG 会比普通 RAG 更像一个真正会追线索的人。

但 SAG 也有边界。它解决的是一次问题里怎么把证据追深，解决不了这次追出来的理解怎么留下。

这两个动作看起来很近，其实差别很大：追证据像办案，办完这个案子，你知道线索在哪里；沉淀知识像立档，下一次遇到类似问题，组织不用从头查起。

如果没有后面的立档动作，SAG 找出来的证据很可能只是一次性消费品。问完一次，答案散掉，下次还要重新找。

所以还需要另一个角色：LLM Wiki。

LLM Wiki 是在Agent视角下对RawData的整合

先抛出一个问题：知识库文档的目标受众是谁？

不着急给出答案，带着这个问题我们先往下走。

很多知识库最尴尬的地方在这里：今天终于把一个问题查清楚了，答案也写得不错；过两个月换个人再问，系统又从一堆材料里重新捞一遍。上一次查出来的判断、路径、坑点，没有真正留在组织里。

这就是遗忘。

Karpathy 在 2026 年 4 月 4 日发布的 LLM Wiki gist，第一眼看很朴素。它的核心想法是：不要只让大模型在用户提问时临时检索资料；让大模型在资料进入时，就把资料整理成一套可读、可链接、可维护的 Wiki。

这个变化很关键。知识库的重心从“问的时候找”，向“平时就整理”移动。

所以 LLM Wiki 和 RAG/SAG 的位置不同。RAG 和 SAG 主要处理“这次提问怎么召回材料”；LLM Wiki 处理“资料进来以后，哪些理解应该被保存下来，哪些旧页面应该被更新”。

一个 LLM Wiki 通常会有三层：raw sources 保存原始资料，作为证据源；wiki pages 承载 LLM 生成和维护的知识页面；schema / rules 约束 LLM 怎么组织、引用和更新。

资料进来以后，大模型不只是做摘要。它要判断这份资料会影响哪些页面：指标页、数据表页、系统页、人物页、概念页、异常事件页、专题综述页。新资料和旧页面冲突，要标出来；某个概念反复出现，要独立成页；一次问答很有价值，可以保存成新的 synthesis 或 query page。

这套东西的精髓，在于知识会长大。

普通 RAG 像一个勤快的资料员，你问什么，它去库房找什么。LLM Wiki 像一个长期在岗的编辑：新资料来了，它会看哪些旧页面需要更新，哪些结论需要修正，哪些缺口需要继续研究。

Karpathy 的 gist 给的是方法论原型，nashsu/llm_wiki 这个项目把它做成了桌面应用实践：把本地资料、聊天记录和生成页面组织成一套可维护的个人知识库。

LLM Wiki 更像长期编辑：把新资料写进可维护、可回溯的知识页。

你问“预测达成率为什么下降”，它召回的对象可能先是预测达成率指标页、华东履约异常复盘页、供应商 A 页面、SKU X 页面，以及 6 月 18 日会议纪要摘要页。这些页面已经被整理过，带着上下文、关系和历史。

当然，Wiki 页面是生成层，不能当成最终事实源。真正的底线仍然是 raw sources。一个成熟的 LLM Wiki 必须能从页面回到原始资料，知道每个判断从哪里来。

所以，LLM Wiki 解决的是第三层问题：维护。

它让知识库从“有问有答”走向“持续沉淀”。这里需要注意一件事：LLM Wiki 也需要召回，它通常会用 index、关键词、向量、wikilink、页面图扩展来找相关页面。

但它召回的对象变了：RAG 召回原始片段；SAG 召回事件链，再回到原始片段；LLM Wiki 先召回整理过的知识页，再按需要回查原始资料。一个是在仓库里找箱子，一个是在档案馆里找卷宗。

顺便回答段落开头的问题：

知识库的受众不再是人，而是Agent，而LLM Wiki的思路，核心就是让Agent更容易理解召回知识库内容。

为什么是 SAG + LLM Wiki

现在把几条线合起来看，知识库真正要跑通的是一整个生命周期。某一次问答，只是其中一段。

企业知识库最容易死在第二行和第三行：关系追不到，结论留不住。SAG 补前者，LLM Wiki 补后者。

RAG 是入口，GraphRAG 是重型结构路线，SAG 是轻型深召回路线，LLM Wiki 是长期知识维护路线。我会押 SAG + LLM Wiki，因为它们分管了知识库里最容易断的两个动作：一次查询怎么追深，追出来的理解怎么留下。

单独看，二者都有短板。SAG 能把证据链追出来，但它不会自动把结论写进组织记忆；LLM Wiki 能把知识页维护起来，但面对散落在原始资料里的细粒度线索，单靠页面搜索和 wikilink 容易挖得不够深。

组合以后，流程会变成这样：

资料进入时，LLM Wiki 负责生成和更新知识页，SAG 同时抽取 event/entities，建立事件索引和实体索引。用户提问时，系统先查 Wiki 页面获得整理过的上下文，再用 SAG 追原始事件链，最后回到 raw sources 校验证据；如果这个答案很有价值，再写回 Wiki。

SAG 负责深挖证据链，LLM Wiki 负责把高价值理解沉淀下来。

这套方法的关键，在于把知识库的生命周期补完整：资料进入时有整理，用户提问时有深挖，答案生成后有沉淀；旧结论被新资料挑战时，还能更新。

两个新名词只是外壳，真正重要的是这条链能长期跑下去。

用业务语言讲，SAG + LLM Wiki 尤其适合这些场景：指标口径问答、数据表和字段血缘、供应链异常追踪、项目会议记忆、客服工单复盘、投研资料整理、企业内部制度和流程知识库。

它尤其适合数据产品。因为数据产品里的问题很少是“某句话在哪里”，更多时候，真正的问题是：这个指标为什么这么算，这个字段为什么会变，这个异常影响了谁，这个结论来自哪几份资料，这个口径上次是谁改的。

这些问题带着时间、实体、关系、责任和证据。普通 RAG 能帮你找材料，SAG 能帮你追线索，LLM Wiki 能帮你留下组织经验；三者放在一条链上，知识库才开始像一个会学习的系统。

不同场景下如何选择知识库搭建方法

功劳要认，边界也要看。

如果你的知识关系非常稳定，实体和关系定义已经被治理得很好，GraphRAG 可能更适合。比如高度标准化的知识图谱、药品关系、法规条款、设备部件依赖，这类场景值得认真维护全局图。

如果你的资料里事件很少，更多是长篇制度、手册、FAQ，SAG 的 event/entity 抽取可能收益不高。普通 RAG 加上关键词检索、结构化目录和人工维护，已经能解决大部分问题。

如果你的团队没有证据回溯习惯，LLM Wiki 反而会制造新的风险。页面写得越漂亮，越容易让人忘记它是生成层；一旦来源、版本、更新时间和冲突标记缺失，Wiki 就会从知识库变成另一种幻觉放大器。

所以这套组合的前提很明确：你愿意把 raw sources 当底座，把 Wiki 当维护层，把 SAG 当深召回层，并且持续做校验。

MVP落地方案

如果我是一个数据产品负责人，我不会一上来做“全公司知识库”。这个目标太大，通常也太虚。更稳的做法，是先选一个高价值窄域。

比如预测达成率知识库、供应商异常知识库、指标口径知识库、数据表血缘知识库、项目会议记忆库，都比“全公司知识库”更适合作为第一站。

然后按三层搭：

重点看第一层。Wiki 页面写得再漂亮，SAG 链路追得再深，都要回到原始证据；没有证据层，后面两层只是更会说话的包装。

每份资料进来，都做两件事：一份给人看，更新 Wiki 页面；一份给系统查，抽 event/entities。比如一份会议纪要进来，LLM Wiki 要更新“预测达成率”页面、“华东异常复盘”页面、“供应商 A”页面；SAG 则抽出会议里的事件、时间、供应商、SKU、门店、指标，放进 SQL 索引。

用户以后再问，系统可以先读整理过的页面，再沿事件索引追到原始证据。

这里有一个底线：

Wiki 页面不能脱离证据。

每个重要判断都要能回到 raw source。LLM 写出来的页面再漂亮，也只是生成层；真正的可信度来自来源、版本、更新记录和可复查路径。

所以还要定期 lint。检查断链页面、无来源结论、重复概念、过期指标口径、页面和原始 DDL 不一致、答案写回后没有证据、旧页面和新资料冲突。

很多知识库死在这一步：大家都建过，也都演示过，后面没人敢信。而知识库一旦没人敢信，就会退化成另一座网盘。界面再 AI，骨子里还是灰。

这是一场范式的变革

当下语言模型ScalingLaw接近瓶颈，但世界模型却迟迟没有找到触及范式，甚至没有共识路径的当下，基于业务知识的智慧沉淀、复用、嵌入一定是最低门槛、最易理解的提效场景。而无论落地场景的输入输出经历了怎么的非线性变换，必然都绕不开知识库的嵌入。

因此当6月14日SAG的论文发布后，我立即意识到，这是一场范式的变革。

SAG + LLM Wiki 改变的核心，是组织处理经验的方式。

过去，知识系统像一个临时问答台。你问一次，它答一次；答得好不好，看检索和模型。答完之后，系统本身并没有变得更懂你。

SAG + LLM Wiki 让这件事发生变化：每一次资料进入，Wiki 变厚一点；每一次问题发生，SAG 把线索挖深一点；每一次高价值回答被写回，组织记忆就多一道刻痕。

这就是我愿意把它称为“当下最强知识库方法论”的原因。

RAG 让资料能被找回，SAG 让关系能被追踪，LLM Wiki 让知识能被维护。这三步连起来，一个组织第一次拥有了接近机器速度的记忆：资料会被整理，关系会被追踪，旧页面会被新证据推着更新。

可如果经验可以被自动压缩，线索可以被自动追踪，连组织记忆都能被机器维护，人到底还需要亲自记住什么？

也许是那一秒：系统已经给出答案，屏幕也很安静，但你的鼠标还停在来源链接上，手指没有立刻点确认。你多看了一眼来源，多问了一句凭什么，然后把责任留在自己手里。

就是那一下停顿。

参考引用：

• SAG 论文：Yuchao Wu 等，《SAG: SQL-Retrieval Augmented Generation with Query-Time Dynamic Hyperedges》，arXiv:2606.15971，2026-06-14。https://arxiv.org/abs/2606.15971

• Karpathy LLM Wiki gist：Andrej Karpathy, llm-wiki.md，created 2026-04-04。https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f

• nashsu/llm_wiki 项目：https://github.com/nashsu/llm_wiki