从 RAG 到 LLM Wiki：知识库如何从问答长成体系

关注

原创最新推荐文章于 2026-10-09 11:57:36 发布 297 阅读 AI 写同款· GEO 优化 ›

LLM Wiki：让RAG问答沉淀为企业知识库闭环在构建企业级知识库与智能问答系统时，检索增强生成（RAG）技术虽能有效提升回答准确性，却常面临知识无法沉淀、问答结果“用完即走”的困境。理解RAG的基本原理后不难发现，其本质是临时召回与生成，缺乏持久化的知识管理能力。此时，结合向量检索与知识库技术，可以构建从问答到知识页面的闭环系统。通过FastAPI、LangChain、LangGraph与PGVector等主流技术栈，实现检索、生成、沉淀、复用的一体化流程，让每一次问答都成为知识资产积累的契机。这种模式适用于企业客服、内部文档问答、个人知识管理等场景，阅读详情

假设现在要系统学习一门新的技术，比如 Rust。手头有官方 Book、标准库文档、Cargo 文档、几篇写得不错的博客、一些示例项目、编译器报错记录，还有自己做练习时留下的笔记。

这时可以问 AI：

我已经会一点 Python，现在想学 Rust。所有权、生命周期、trait、async 这些东西到底该怎么串起来学？

如果直接问一个通用大模型，它可能会给出一份看起来像样的学习路线：先看语法，再看所有权，再看生命周期，最后做几个项目。问题在于，它未必读过这套资料，也不知道前面做过哪些练习，更不知道学习过程卡在哪些编译错误上。

更稳的做法是先让 AI 去自己保存的资料里查一遍，再根据查到的内容回答。可以先把 RAG 理解成一句话：让大模型回答前先翻资料。

今天先从 RAG 是什么开始，再讲一个可用的 RAG 系统怎么一步步搭起来。最后再聊 LLM Wiki：当学习资料越来越多、问题反复出现时，怎么让知识库除了回答问题，还能把一门技术越学越清楚。

为什么大模型需要“翻资料”

大模型懂很多通用知识，能解释概念，能写总结，能推理，也能把话说得很顺。但它有几个天然短板。

第一，它的知识有时间边界。模型训练之后出现的新版本、新 API、框架变更，它未必知道。
第二，它不知道个人资料。读过哪些章节，收藏了哪些博客，写过哪些练习代码，踩过哪些坑，都不在它的训练材料里。
第三，它给出的答案不一定能追溯来源。有时候一段答案看起来很完整，却分不清哪一句来自材料，哪一句是模型自己补出来的。

RAG，全称 Retrieval-Augmented Generation，通常翻译为“检索增强生成”。它很像让大模型参加开卷考试：模型依然负责理解和表达，但在回答之前，会先从外部资料中找相关内容。

这里可以把知识分成两类：

• 参数化知识，即模型权重里已经学到的内容。它覆盖面广、回答快、使用方便，但更新困难，也无法覆盖私人资料。
• 非参数化知识，即模型外部的资料。比如官方文档、网页、Markdown、书籍笔记、示例代码、GitHub issue、release notes、学习记录。它可以更新，也更容易查来源。

RAG 要做的，就是把这两类知识接起来。

RAG 的最小流程：先存资料，再查资料

一个最小 RAG 系统可以拆成两个阶段。

第一阶段是提前准备资料。


原始资料

  -> 读取和解析

  -> 清洗

  -> 切成小块

  -> 转成向量

  -> 存进索引或向量数据库

第二阶段是用户提问时现场检索。


用户问题

  -> 转成向量

  -> 找相似资料块

  -> 拼成上下文

  -> 交给大模型回答

  -> 返回答案和来源

继续用学习 Rust 举例。把 Rust Book、标准库文档、Cargo 手册、几篇 async 教程、自己的练习笔记都放进知识库后，系统会先把这些材料解析出来，切成一段段小文本，再把每段文本转成向量。

当问题是“我为什么总是在生命周期这里卡住”时，系统不会直接让模型凭经验回答。它会先找出和这个问题最相关的几段资料，例如“借用规则”“生命周期标注”“函数返回引用”“此前的编译错误记录”，再让模型基于这些资料组织答案。

这套流程就是基础 RAG 的工作方式。它并不复杂，很多知识库问答、文档助手、学习助手、代码问答系统，采用的都是这个流程。

二、RAG 系统的大致流程

第一步：把资料切成合适的小块

很多人第一次做 RAG，会以为只要把文档上传，后面交给大模型就行。实际效果往往卡在第一步：资料怎么切。

一份技术文档可能有几十页，甚至几百页。里面有概念解释、API 说明、示例代码、版本差异、常见错误、最佳实践。不能把整篇文档都当成一个检索单元。

原因很简单：
第一，Embedding 模型有长度限制，文本太长会被截断，后面的内容进不了向量。
第二，一个块里主题太多，向量会变得含糊。用户问“生命周期为什么要显式标注”，结果检索回来一大段同时包含所有权、借用、trait bound 和 async 的内容，模型还要二次筛选重点。
第三，上下文越长，噪声越多。现在模型上下文窗口越来越大，但把所有内容塞进去，依然会让答案变得不稳。

所以 RAG 要做文本分块。常见有三种切法。

固定大小分块

• 比如每 500 字切一段。速度快，适合日志、流水记录、短文本集合。缺点是容易把一句话、一张表、一个步骤切断。

递归字符分块

• 先按段落切，段落太长再按句子切，句子还太长再继续拆。LangChain 里的 RecursiveCharacterTextSplitter 就是这个思路。

语义分块

• 判断相邻句子之间的语义变化，在话题明显切换的地方断开。效果可能更好，但计算成本和调参成本也更高。

中文材料还要注意标点。默认英文分隔符对中文文档不够友好，通常要加入 。、，、、、全角句号、全角逗号这些分隔符。

分块没有万能参数。官方文档、API 手册、博客教程、示例代码、学习笔记，适合的切法都不同。比较可靠的办法，是拿真实问题测试：用户这样问时，系统能不能召回刚好有用的那段。

第二步：把资料块和问题都变成向量

分块之后，每个资料块仍然是普通文字。检索系统不能直接拿“一段文字”和“一个问题”做距离计算，所以中间要加一层转换：把文字送进 Embedding 模型，得到一串固定长度的数字，这串数字就是向量。

入库时，每个资料块都会做一次 Embedding：


chunk_id: rust-install-01

text: "安装 Rust 可以使用 rustup。打开终端后运行 rustup-init..."

vector: [0.018, -0.042, 0.103, ...]

metadata: source=Rust Book, section=Getting started

实际系统里不会手写这些数字，通常会调用 Embedding API，或者在本地跑一个 Embedding 模型。资料入库时，把每个 chunk 的 text 转成 vector，再连同 chunk_id、来源、标题、章节等元数据一起存进向量数据库。

提问时，也做同样的事。比如问题是：

Rust 怎么安装？

系统会先得到这个问题的向量：

"Rust 怎么安装？"

接下来，系统会拿 query_vector 和库里每个 chunk_vector 做相似度计算。最常见的是余弦相似度，也会直接用点积。余弦相似度关注两个向量的方向是否接近，向量长度的影响会被归一化处理。


score = cosine_similarity(query_vector, chunk_vector)

结果会按相似度进行排序

相似度分数	资料块
0.91	安装 Rust 可以使用 rustup。
0.83	Windows 上如何运行 rustup-init。
0.62	更新 Rust 可以运行 rustup update。
0.35	Cargo 是 Rust 的包管理工具。
0.12	生命周期用于说明引用能活多久。

分数越高，说明问题和资料块在语义空间里越接近。系统会按分数排序，取前几个资料块，也就是常说的 Top-K。这个例子里，前两条就很适合拿去拼上下文；后面的 Cargo、生命周期，虽然也属于 Rust 学习资料，但和“怎么安装”关系不大，可以先放到后面。

拿到 Top-K 之后，RAG 会把这些资料块和原始问题一起交给大模型。模型看到的就不再只有一句“Rust 怎么安装？”，还会看到“使用 rustup”“运行 rustup-init”“Windows 安装步骤”这些上下文。这样生成出来的回答会更具体，也更容易标出依据。

这里也能看出检索质量的重要性。如果 Top-K 里排在前面的都是无关内容，后面的生成阶段很难补救。很多 RAG 系统看起来是模型答错了，实际问题出在前面这一步：相关资料没有被召回，或者无关资料排得太靠前。

第三步：用混合检索补上关键词匹配

向量检索能理解语义，但它也有短板。比如用户问：

std::borrow::Cow 这个类型在标准库文档里怎么说？

这个问题里有明确类型名，关键词匹配往往比向量相似度更可靠。再比如用户问：

我之前那个字符串借用的问题，为什么换成 String 就能过？

这里没有明确关键词，语义检索更有用。所以很多 RAG 系统会用混合检索。

稀疏检索

• 负责精确匹配。典型方法是 BM25，适合函数名、类型名、错误码、库名、命令、配置项。

密集检索

• 负责语义匹配。它适合口语化提问、同义表达、概念相近的内容。

两路结果出来后，再用 RRF 或加权融合排个序。这样既能定位 std::borrow::Cow、E0597、tokio::spawn 这种精确词，也能处理“那个字符串借用的问题”这种模糊说法。

稀疏向量强在可解释和精确匹配，密集向量强在语义理解。混合检索把两者放在一起，可以避免系统只会查到语义，却抓不住关键术语。

第四步：先把用户问题“翻译”成检索问题

用户提问时，很少会刚好说成文档里的样子。他们会问：

上次练习里那个生命周期报错，为什么这次又出现了？

或者：

我之前那个报错怎么又出现了？

或者：

这个写法官方文档里有推荐吗？

这些问题对人来说很自然，对检索系统来说却很模糊。所以高级一点的 RAG，会在检索前处理用户问题。

• 查询重写：把口语问题改成更适合检索的表达。
例如把“那个报错怎么又出现了”改写成“Rust 编译错误 E0597 borrowed value does not live long enough 的原因和修复方式”。
• 多查询分解：一个问题里有多个意图时，拆开查。
例如“Rust async 为什么这么难，应该先学什么”，可以拆成“async/await 的基本执行模型”“Future 和 runtime 的关系”“Send、Sync、'static 在 tokio::spawn 中的作用”几个问题。
• HyDE：先让模型写一段假设性答案，再用这段更完整的文本去检索。
短问题信息太少时，这种方法有时能召回更好的材料。
• 查询路由：判断问题该去哪里查。
有的问题查官方文档，有的问题查示例代码，有的问题查 GitHub issue，有的问题需要回到本地项目，或到命令行里验证。

到这一步，RAG就学会先理解问题，再决定怎么查。

第五步：回答阶段

检索到资料后，还要让模型回答。这一步也有要注意的地方：资料找到了，模型如果继续自由发挥，RAG 的检索出的内容就会被弱化。所以提示词里通常要写清楚：

• 只根据给定上下文回答。
• 上下文没有依据时，直接说明资料不足。
• 尽量给出来源或引用片段。
• 区分事实、推断和建议。
• 输出格式保持稳定，比如清单、表格、JSON。

还是学习 Rust 的例子。

一个高质量回答最好说明：

• 哪些结论来自 Rust Book。
• 哪些来自标准库文档或官方博客。
• 哪些是个人练习里的错误记录。
• 哪些说法只是经验建议，不能当成官方规则。

RAG 的可信度，很大一部分来自证据链。回答出内容只是第一步；能回到材料拿到回答的依据才是最重要的。

三、RAG 面临的问题

到这里，一个基础 RAG 系统已经能工作了。它能读取资料、切块、向量化、混合检索、重写问题，基于上下文回答，还能做评估。如果目标是文档问答、学习助手、产品手册助手，这套方法已经很有价值。

但长期使用后，会遇到一个新问题：每次提问，系统都在重新查资料、重新拼答案。比如第一次问“Rust 所有权到底怎么理解？”，系统回答得很好。第二天又问“所有权、借用和生命周期之间是什么关系？”，系统又重新查一遍。过几天学到 async，再问“async 里的生命周期和前面学的是一回事吗？”，系统还是重新从一堆片段里找证据、拼结论。

问题也会跟着出现：上次问出来的好答案没有沉淀下来；各个概念之间的关系，没有形成一页长期维护的说明；资料越积越多，知识结构未必变清楚；用户每次都在问，系统每次都在临时组装。

这时就需要继续深入：把有价值的问答结果保存下来，让知识库自己形成结构。

四、LLM Wiki：把一次次问答沉淀成知识层

很多人都有互联网仓鼠的习惯。看到一篇好文章，先收藏；遇到一个有用命令，先贴进笔记；AI 解释得不错，也先复制下来。短期看，这是一个，至少资料没有丢。

但资料越攒越多，另一个问题会慢慢出现：同一个主题散在很多地方，旧结论没人更新，相关内容没有链接，下一次要用时还得重新找。知识库看起来越来越厚，可复用的结构却没有同步长出来。

前段时间，Andrej Karpathy（OpenAI 联合创始人）开源了一个名为“LLM-Wiki”的想法：用一份类似 llm-wiki.md 的说明，告诉 Agent 如何维护一个 Markdown Wiki。原始资料放在哪里，整理后的页面放在哪里，遇到新资料时怎么更新摘要、概念、实体和索引，回答问题时先看哪些页面，什么时候要回到原文查证，这些都写成清楚的工作规程。

传统 RAG 的主要动作发生在提问时：用户问一个问题，系统临时从原始 chunk 里找材料，再让模型拼答案。
LLM Wiki 则会把一部分工作提前到资料进入系统时：新资料进来后，LLM 先读一遍，提取关键内容，整理成 Markdown 页面，并把它接到已有知识结构上（这部分有点像对知识进行“编译”）。

继续用学习 Rust 举例。加入 Rust Book 之后，系统会把它切成 chunk 和向量索引，同时生成一页来源摘要；看到“所有权”“借用”“生命周期”反复出现，就会建立概念页；看到 Cargo、rustc、Tokio、Serde 这些工具和库，就会建立实体页；如果后面加入一篇新的 async 教程，里面的说法和旧笔记有冲突，也可以在相关页面标出来，提醒后面再确认。

所以我更愿意把 LLM Wiki 看成一层“知识整理层”。人负责挑资料、提问题、判断关键结论是否可靠；LLM 负责那些重复但重要的维护动作，比如摘要、归档、补链接、更新索引、记录变更。配合 Obsidian 这类 Markdown 工具，知识库既能被 Agent 维护，也能被人直接打开、检查和修改。

从“临时回答”到“长期笔记”

想象一下，如果每次问完 AI 后，都让它顺带完成三件事：

• 把这次答案保存成一页笔记。
• 把涉及的概念链接到已有页面。
• 如果发现新旧资料冲突，在相关页面标出来。

几个月后，聊天窗口里的零散回答会逐渐变成可追踪、可更新、可复用的 Markdown 页面。

单次问答只留下结果，LLM Wiki 会留下可维护的页面：原始资料保留不动，中间多出一层由 LLM 整理的知识层。我理解 LLM Wiki 的核心就在这一层。

这样一来，下次再提问时，模型不用只面对一堆原始 chunk。它可以先读已经整理过的概念页、来源摘要、对比页，再回到原始资料里查证。

LLM Wiki 的三层结构

LLM Wiki 通常可以分成三层。


raw sources

  原始资料层

  保存文章、PDF、截图 OCR、代码片段、学习记录

  尽量保持原样，作为事实来源

wiki

  知识整理层

  保存来源摘要、概念页、实体页、对比页、索引、日志

  由 LLM 负责创建和维护

schema

  操作规程层

  告诉 LLM 目录怎么用、页面怎么写、什么时候更新

这三层很好理解。raw sources 像资料柜，原文放在那里，不会再更改。wiki 像读书笔记和索引卡，负责把原文里的重点、概念、关系整理出来。schema 像图书管理员的工作手册，规定新资料进来后怎么处理，查询时先看哪里，哪些目录能写，哪些目录只能读。

如果继续用学习 Rust 的例子，LLM Wiki 可以这样维护：

• 给 Rust Book、标准库文档、官方博客、示例项目分别写来源摘要。
• 给“所有权”“借用”“生命周期”“trait”“async runtime”建立概念页。
• 给“Cargo”“rustc”“Tokio”“Serde”“Axum”建立实体页。
• 新版本文档或新的学习笔记进来时，更新旧页面，并标出变化。
• 用户问出一份很有用的学习路线或错误排查表时，把它保存到 outputs/。
• 每次更新后，在 log.md 里记一条。

Wiki 层为什么有用

保存文件本身不麻烦，上传、归档、命名都有工具可以做。但是我们往往面临以下繁琐的问题：

• 这份资料和旧资料有什么关系？
• 哪个结论被新资料改了？
• 哪些页面应该互相链接？
• 哪个概念反复出现，应该单独成页？
• 哪些来源互相矛盾？
• 哪次问答值得保存下来？

人经常会漏掉这些工作。它们难度不高，但很碎。LLM 很适合承担这类整理工作，它可以一次读多页，自动补链接、补摘要、补索引、补日志。

人的分工也会更清楚：

• 人负责决定哪些资料重要。
• 人负责提出自己关心的问题。
• 人负责审核关键结论。
• LLM 负责整理和维护。

这样跑一段时间后，知识库会逐渐出现结构。除了原始资料，里面还会有主题页、来源页、对比页、时间线和查询沉淀。

五、RAG 和 LLM Wiki 怎么配合

组合架构：RAG 查证据，Wiki 留结构

RAG 和 LLM Wiki 可以放在一起。RAG 负责查证据，LLM Wiki 负责留下结构。

一个更完整的知识系统，可以长这样：


原始资料层

  保存 PDF、网页、Markdown、代码片段、学习记录

  用搜索或 RAG 做大范围召回

Wiki 知识层

  保存来源摘要、概念页、实体页、专题输出

  用 Markdown 和 wikilinks 维护结构

生成层

  回答问题、写报告、做对比、生成方案

  必要时回到原文查证

小规模知识库里，index.md 就很有用。LLM 先读索引，再打开相关页面，很多问题不用向量数据库也能处理。资料多起来以后，RAG 仍然重要。它可以检索原始资料，也可以检索整理后的 Wiki 页面。两者配合后，系统既能找原文，也能沿着已有结构继续往下写。

放在 Obsidian 里怎么落地

如果用 Obsidian，一个 LLM Wiki 可以从简单目录开始。


_llm-wiki/

  raw/

    原始资料，只读

  wiki/

    index.md

    log.md

    sources/

    concepts/

    entities/

    outputs/

  README.md

raw/ 放原始资料。网页剪藏、PDF、截图 OCR、代码片段、练习记录都可以放这里。

wiki/sources/ 放来源摘要。每份资料一页，记录它讲了什么、哪些结论值得引用。

wiki/concepts/ 放概念页。比如所有权、借用、生命周期、trait、async runtime。

wiki/entities/ 放实体页。比如 Cargo、rustc、Tokio、Serde、Axum。

wiki/outputs/ 放值得保留的查询结果。比如学习路线、错误排查清单、项目实践总结。

index.md 是地图。LLM 查询时先读它，再决定打开哪些页面。

log.md 是时间线。每次 ingest、query-save、lint、maintenance 都记录一条。

还需要一个 schema 文件。对 Codex 来说可以是 AGENTS.md，对 Claude Code 来说可以是 CLAUDE.md。它要写清楚：

• 哪些目录只能读。
• 哪些目录可以更新。
• 新资料进入后更新哪些页面。
• 查询时先看索引，再看具体页面。
• 什么样的输出值得保存。
• 页面怎么命名。
• wikilinks 怎么写。
• 日志怎么追加。

什么时候只用 RAG，什么时候加 LLM Wiki

如果目标是快速问答，先做 RAG。

比如：

• 文档问答系统。
• 产品手册问答。
• API 文档助手。
• 内部知识库查询。
• 技术资料检索。

这些场景最看重：找得准、答得稳、有出处。

如果目标是长期积累，就加 LLM Wiki。

比如：

• 持续研究一个技术主题。
• 维护项目决策记录。
• 整理学习笔记和项目实践。
• 建个人知识库。
• 把多轮 AI 对话变成可复用资料。
• 定期写专题汇报或公众号文章。

如果同一个主题后面还会反复问、反复改、反复引用，就应该让它进入 Wiki。

RAG 适合让模型查资料，LLM Wiki 适合让资料长出结构。两者结合起来，才更像一个长期可用的知识系统。

六、最后

回到开头学习 Rust 的例子。RAG 解决的是“回答前先查资料”。问题来了，系统去 Rust Book、标准库文档、练习笔记里找证据，再让模型基于证据回答。它适合快速问答，也适合在大量资料里定位线索。

但长期学习一门技术，只靠一次次检索还不够。今天问这个，明天哪个，如果答案只留在聊天窗口里，知识仍然是散的。

LLM Wiki 则把有价值的回答保存下来，把概念之间的关系连起来，把新资料带来的变化更新到旧页面里。下一次再问时，AI 面对的除了原始片段，还有已经整理过的学习脉络，形成自己的一套知识体系。

RAG 让模型会翻资料，LLM Wiki 让资料能沉淀下来，二者结合后，知识库就会逐渐形成自己的知识体系。

学AI大模型的正确顺序，千万不要搞错了

🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！

有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！

就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋

在这里插入图片描述

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！

我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～