LLM wiki实战：用20篇文章做一个“管理数字分身”

AI客服卡在业务规则推理上，知识图谱又贵又难做。作者用LLMwiki的思路，把20篇管理文章编译成知识摘要、实体页和概念页，再让Agent按需检索，实测回答质量好过向量切分方案，代价是响应偏慢。

现在企业用AI降本增效，AI客服算是最典型的场景之一。

而AI客服这类项目最核心的东西是背后的业务知识库。只不过业务类型不同，知识库搭建的难度也差很多。

有些业务场景比较简单，整理一些高频FAQ、文档就已经够用了；而复杂的业务场景，背后有大量规则、条件和判断，做起来就有点棘手了。

从我这边的接触的企业咨询情况来看，大多数公司当前把简单知识库应用得挺好了，但是遇到了新的瓶颈，就是回答一些直接问题还行，一旦涉及业务上的逻辑推理、规则判断，就不太行了。于是想尝试走知识图谱这条路径来解决。

但知识图谱这个东西，真做起来真挺难的，前面我也写了几篇知识图谱和本体论的文章，大家可以参考。包括我去做的时候也会感觉很难，难的倒不是技术和工具，而是你得先成为这个领域的业务专家，才能把里面的业务对象、关系、属性、规则、行动梳理清楚，并转化为结构化的知识和规则模型。否则图谱就算画出来，也解决不了实际问题。

所以现实情况是，对AI应用得比较深的公司来说，简单知识库已经不太够用了，知识图谱理论上能行，但实际上又很难做得出来。

那接下来怎么办？是硬着头皮迎难而上，还是换个思路另寻出路？

这里我们探讨一种新的知识库构建方案：LLMwiki，下面我们先大致先了解下LLMwiki是个啥东西。

LLMwiki新范式

2026年4月，前OpenAI联合创始人AndrejKarpathy在Github上公开了一份知识库构想文件，大致描述了一套新的知识库构建理念，但其实并没有说明具体如何实现。

随后，社区对此反响非常火爆，甚至出现唱衰RAG的论调，以及基于LLMwiki+Obsidian去构建个人第二大脑的实践。到目前为止，也有很多的知识库产品以及企业，也在将这套范式用于业务生产环境。

在这份构想中，Karpathy指出了传统RAG检索的一个大的弊端：原始文档被粗暴的分块，然后塞进向量数据库，每次问答都是从海量的知识碎片里面去寻找相似的文档，然后在临时组装这些散落的知识片段来生成答案。当下次询问相同的问题，仍然是从零开始去检索、排序、组合生成，回答完了就忘记了，知识和经验并没有被持续沉淀下来。

我们之前也说过，RAG这套范式，是重检索流程，数据处理环节却做得很弱。而数据处理基本就决定了知识库的能力上限了，即便后续的检索阶段再怎么做工程侧调参、优化，效果提升并不明显。

而LLMwiki的玩法就完全不同了，它的核心理念是：预先编译，持续更新，反复复用。在检索之前，就先用LLM完成阅读、理解、提炼和关联，把零散信息编译成结构化、语义互联、可溯源的Markdown知识文档。之后的每一次查询，都可以直接读取这份已经准备好的知识。

基于以上理念，LLMwiki的整体架构设计如下。

数据、规则与知识的分层架构

整体架构分为三层：

第一层：原始数据层（RawLayer），这些内容是整个知识Wiki的事实来源，核心原则是不可变，LLM只能读取但是绝不能修改它们，这确保了所有的编译出来的知识都能够准确溯源。

第二层：规则约束层（SchemaLayer），定义整个知识系统的维护规范，通常是CLAUDE.md或者AGENTS.md这类规则文件，它告诉大模型Wiki的目录结构、从哪里读取原始知识、怎么编译知识、每个页面的元数据与正文规范、遇到知识冲突如何处理等整套工作流程。

第三层：知识编译层（WikiLayer），用于存放由LLM编译后的结构化知识，主要是把原始知识按照这几类别进行抽取：摘要、实体、概念、比较、概述、综合理解等。然后以markdown文件保存，每个知识文件都有标准的YAML元数据头（类别、标签、知识来源、状态、创建及更新时间）以及与其它知识页面的关系链接。

在这套架构里面，人机分工的规则是：人负责定义规则、提供原始数据、负责价值审核和关键裁决，LLM则负责知识编译层的维护更新。

根据上面的架构分层逻辑，目录文件结构大致设计如下：

knowledge/

├──schema.md

├──raw/

│└──papers/

├──templates/

│├──comparison.md

│├──concept.md

│├──entity.md

│├──overview.md

│├──source.md

│└──topic.md

└──wiki/

├──comparisons/

├──concepts/

├──entities/

├──overviews/

├──sources/

├──topics/

├──index.md

└──log.md

目录文件按职能可以分两类：

第一类是主流程目录，承载知识从源头到产物的状态流

raw存放原始资料，供下游编译使用。

wiki就是经过AI编译完成后的结构化页面，按照摘要、实体、概念、比较、概述、综合理解进行组织。

其中raw和wiki内部的目录结构没有固定标准，可以结合实际的业务场景进行调整，不一定要遵循这一套分类。

第二类是支撑目录文件，服务于编译及查询过程本身

schema.md，是指导LLM维护整个知识库的工作原则，在企业级项目中，schema中内容通常作为系统提示词。

templates用于给AI生成wiki时参照的模板文件，与wiki下面的目录结构一一对应，确保生成的同一种类型文件结构都是一样的，便于维护管理。

index.md是整个wiki知识的索引文件，它相当于一本书的目录结构，便于后续能检索时快速找到目标内容。

log记录操作日志，比如每次知识编译更新了哪些知识文件、主题内容是什么。核心原则是：内容只增加，不替换。

而整体的核心工作流程是：先知识编译，再知识检索，最后知识治理。

下面我看一个基于这套范式的案例。

看一个案例

我现在要基于我的20篇管理文章，做一个我的管理分身，来回答用户的各种团队管理问题。

还是开头说到的问题，如果使用RAG向量知识库这种方案，回答效果肯定是不会太好的，用知识图谱的方式建模的成本又太高了。

因此，我们这里尝试用LLMwiki这条路径来实现，这里用腾讯开源的知识库产品Weknora进行说明，因为它也支持了LLMwiki这种知识库的范式。

不过Weknora需要基于源码在本地先进行部署，部署方式也很简单，把官方部署文档丢给Agent干就完事了，然后配置一系列的模型就能使用。

首先新建一个知识库，选择Wiki知识库类型，提取粒度选择标准，这里Weknora内部集成了几套知识抽取的规则，对应前面我们说的Schema层，然后下面我们也可以自定义一些规则，比如Wiki内容生成要求、提取重点。

上面这步配置完成后，我们再把20篇管理文章导入进去，然后需要等待一段处理时间。

知识编译完成后，就可以看到wiki内容了，总共生成了20份知识摘要，13个实体页，128个概念页。

同时也可以看到整个知识页面的图谱的关系网。

但这里需要给大家澄清的是，这并不是所谓的知识图谱，而是知识页面之间的链接关系，每个点表示的是一个实体或概念页面，它的知识粒度是很粗的，而链接线仅仅表示的两个页面的引用关系，并没有所谓的层级、属于、包含之类的图谱关系。比如A页面关联了B页面，B页面关联了C页面，然后用知识网展示了出来而已，并不存在逻辑链。

接下来，我们看知识检索的流程，在对话中我们问了这个问题：“刚晋升为团队Leader，事情分配不出去，感觉很疲惫，我该怎么办？”。

这是一个需要理解情境、综合观点的问题，而不是一个事实性问题，知识库中没有一条可以直接复制出来的标准答案。

整体的回答质量还是挺不错的，比之前尝试的向量分割的方案好太多了，只不过响应时间有点太长，不过也能理解，因为这里是Agent运行时。

这里我们重点看下检索的提示词逻辑，下面这段内容是把WeKnora的系统提示词翻译过来的：

这里其实定义了一套渐进式加载的检索流程：

1）拿到用户问题后，先去Wiki里搜相关摘要或索引，定位可能有用的知识页面。

2）如果搜到的摘要信息不够，就打开对应页面，读更完整的内容。

如果还缺信息，就顺着页面中提到的其他相关页面继续查。

如果涉及精确引用、代码细节或存疑内容，就根据页面里标注的来源，去查原始文档。

3）如果不同来源说法不一致，就比较时间、范围和出处，说明差异；

核心思想是：先用Wiki索引和摘要快速定位，再根据信息缺口逐层深入，确保结论有证据、可追溯。

有了LLMwiki，是不是不需要RAG了？

这里先说结论：LLMwiki跟RAG的关系并不冲突，他们各自解决的场景问题仍然不同，甚至可以组合使用。

其实知识体量大起来以后，LLMwiki也会出现性能瓶颈，每次的编译成本和查询成本都会变大，且增量更新的质量也会下降。

比如前面讲的检索流程，大模型先得完整加载索引文件index.md，找到与问题可能相关的知识页面，然后再渐进式下钻到相关页面。这种检索方式对于几十到几百个Wiki页面的知识库没啥问题的，但wiki持续变大之后，index.md这个索引文件的体积也会持续膨胀，检索效率就会随之下降，检索及编译的Token消耗也会变大。

要解决检索的性能瓶颈，仍然需要结合RAG检索方案。大致的思路是：

1）先把索引文件拆分为小的知识chunk；

基于这些chunk构建BM25关键词索引；

查询时先用BM25召回候选片段，再用向量相似度做语义重排；

2）LLM读取命中的原始页面，再生成最终答案。

所以LLMwiki也并不是知识库构建方案的银弹，即使有了LLMWiki仍然是需要RAG的，他们两者的思路其实完全不同，各有千秋。

这里可以用编译时和运行时来理解。LLMWiki是编译时产物，把原始材料预先处理成知识页面；而RAG是运行时手段，在查询时刻做精准召回。

Wiki在构建阶段就把散落的材料固化为完整的语义单元，每个页面自带元数据、关系使用双链符号记录、层级结构支持渐进式披露。

RAG的重心是检索链路，它不会帮忙理解并整理这些内容，原来分散的资料依然分散，矛盾的还是矛盾的，过期的还是过期的。

下面我们看一张几个关键维度对比图：

人的判断权不能交出去

上面的这套流程执行下来，刚开始的时候体验非常好，感觉一切都很美妙，我们只需要往里面投喂信息，LLM自动就把知识编译到wiki中去了，省去了我们整理数据的麻烦。

我们其实是偷了整理数据的懒，把这个本该人做的事情让AI去做了。LLM也确实降低了维护成本，但如果全凭LLM自动化编译，也别指望编译出来的知识质量有多高。因为LLM并不知道哪些信息真的重要，哪些结论值得保留，哪些内容应该被丢弃，甚至会丢掉一些关键细节或生效条件。

这也正是人需要持续参与的原因。

我认为两个环节人一定要把好关：

第一是信息筛选环节，人要判断什么样的知识能流入知识库中；

第二是知识编译阶段，需要增加人机交互的环节，指导大模型关注重点，并review生成的结果。

其实karpathy自己也有提到，他倾向于单篇知识摄入，并且会全程参与进去，去阅读LLM生成的摘要，并检查更新的内容，指导LLM关注重点知识。

想要构建一个长期可控、有价值的知识库，是不太可能完全让他自动化跑的，还是需要依靠人和LLM协作，LLM负责降低知识整理和结构化的时间成本，但是人仍然要参与筛选、审核。