llm-wiki实践学习

llm-wiki实践学习

​ 前言：之前只是学习过Llm-wiki的理念，但是从来没有从0搭建过一个Llm-wiki，这次以一个真实的落地例子来系统性学习如何从零搭建一个Llm-wiki

1 llm-wiki结构

一个完整的llm-wiki项目由这几个部分组成

1.1 事实源:

​ 就是我们原始的，未加工的素材，是整个wiki的事实依据，原则是保留原貌，敏感信息脱敏

1.2知识层

​ 也就是把原始的资料加工未适合人和Llm阅读的内容，为什么我们要对原始资料进行编译，原因是原始材料一般是比较杂乱的，文件的格式各不相同，同一个概念的知识可能放在不同的文档，还可能同一个概念在不同的文档被重复的讲解，我们知识层做的事情就是将这些原始的资料做汇总，整理，合并重复的概念，并建立知识间的链接，将agent运行时的理解迁移到离线编译，agent使用的是材料，而不是原始的文件

1.3 导航层

​ 导航层用于辅助agent 在llm-wiki中检索知识，可以说是agent检索的公路，形式为index.md index.md 包含各个模块的信息以及内容，指导agent 导航到各个的子知识层的index.md，当然导航层并不是只有这种首页和分类索引的形式，还存在页面间链接，用来表示各个知识模块的关系，或者包含来源引用，指向事实源

​ 注意，我们一般还会使用脚本来检测当前所有的正向链接，产生一份回链文件

1.4 维护治理层

​ 负责管理知识，定义知识怎么维护，更新，保证质量，具体落在实现中分为这几种

1.4.1 顶层元数据

​ 每个知识页顶部的元数据就是维护治理层的一种，我们在元数据中维版本号，标题，更新时间戳，唯一标识，或者维护知识页的权限，谁有资格更改，或者提供置信度分数，当出现冲突时，优先比较顶层元数据，比如权威来源，最新验证事件，评分来比较，同时也可以带上tags 标签，元数据一般是yaml front matter格式，目前由agent，ci，人工更新维护，维护发生在新建知识页时，修改知识页时，ci检查时，一般我们也可也在本地写一个检测的脚本，当我们触发修改后，使用脚本来检测格式是否正确，

1.4.2 schema(知识规范)

​ 除了元数据，我们的schema也是维护治理层的一种，schema我们可以单独开一个文件夹，描述当前不同的知识页，提供模板规定知识应该怎么写

1.4.3 lint(知识检查)

​ lint也就是知识检查，在页面创建/编辑/保存后触发，目的是保证知识页顶层元数据符合格式，知识页格式正常，是否符合只是也模板，检查导航层的导航是否可达，命名规范检查，是否存在重复的知识检查等

​ 部分的Lint可以由脚本完成，比如对知识页元数据的检测，对markdown层级的检测，对Index.md应用页面是否存在的检测，是否存在孤立页面的检测，如果我们使用agent进行检测，往往是检测内容你是否完整，知识页是否重复，知识是否过期，知识是否忠于原始材料，注意，正式知识页一般都需要有一个入栈链接，否则会成为孤儿页面

1.4.4 review

如果说lint做的是检查是否符合规范，那review就是审核知识质量，回答的问题是这个知识能进入知识库吗，内容是否正确，是否遗漏了关键概念，是否表达清晰，是否真的需要新增这个知识页，比如有人新增加了一个知识页，lint干的事是保证这个知识页的格式正确，而我们review要做的是检测这个知识页的必要性，这里的review更多的是一个决策者

完整的流程是 有用户提交知识 -> 进行Lint ->进行reivew ->进行决策

review 的结果有 1. 通过 2. 要求修改 3. 拒绝合并 4. 拆分 5. 归档，lint输出的是警告，review输出的是决策

1.4.5 版本管理

版本管理就是把知识库当代码库来管理，回答的问题是一篇知识什么时候改了，谁改的，改了什么，能不能回滚

一般我们直接用git就可以了，

1.4.6 状态和生命周期

随着整体流程是变化，知识页也分为不同的状态，

一开始提价后是Draft态，也就是草稿态，在进入审核后变成了reviewing 也就是审核中的状态，再进一步通过review后进入，verified 状态，如果知识对历史系统有用，但是我们现在已经是新系统了，可以加deprecated状态，如果是彻底退出了知识库，就可以变成归档状态，以后都不会返回

而生命周期就是定义一份知识页在这些状态间流转的流转规则

1.4.7 来源管理

​ 记录当前知识页的来源，除了在元数据侧做标识，还要在内部的数据段落标识来源，建立映射关系，这样做的目的是在底层来源发生变化时，可以自底向上检测，更新整个源

1.4.8 知识质量指标

知识质量指标就是定义了一系列指标，来定义当前知识页或者整体知识库的健康程度

常见的指标有完整性 即知识是否完整 新鲜度即知识多久没更新了，可信度 知识有多可靠 覆盖 一个领域是否能覆盖完全 引用率 使用频率

指标的维护也可以发生在单知识页修改之后，来源变更之后 或者全局更新时进行维护的

1.4.9 定时治理

​ 除了我们单个知识页在新增或者修改时的维护，肯定也需要一种全局的维护方式，用于在全局层面发现问题，也就是进行治理系统周期性扫描，比如在每天凌晨的固定时间，先扫描整个wiki，发现问题后生成治理任务，更改问题后进行review通过后更新状态

1.5 检索方式

也就是我们的agent如何使用llm wiki

首先最常用的就是我们利用构建好的导航，也就是各个Index.md 和知识页内部的link，特点就是有方向，范围小，token消耗低，更符合知识组织结构，但是我们这样按链接的去检索，前提是你知道从哪进，且路上有链，有结构、有上下文、路径可解释漏链、走错门、跨主题够不着，当我们不知道从哪进时，就需要使用全局检索来兜底了，全局检索可以使用grep，也可也使用向量检索rag，混合检索之类的

1.6 整体流程图及补充

事实源(sources)  --编译-->  知识层(wiki pages)
                              ↕ 互链
                         导航层(index / links)
                              ↑
                    维护治理(元数据/schema/lint/review/git/指标)

需要注意的是

必做（MVP）	可后置
元数据 + schema 模板	质量指标度量
脚本 lint（元数据/断链/孤页）	agent 深度内容 lint
Git 版本	复杂权限模型
简单 status	完善定时治理与任务单
来源 id 引用	细粒度段级溯源