LLM Wiki 与编译型知识层

二、为什么需要编译型知识层

直接在原始材料上做检索常遇到：

• 同一事实散落在多份文档或代码位置中。
• 文档过长、上下文依赖强，单个切片缺少意义。
• 术语、实体和关系没有统一表达。
• 新人不知道阅读顺序，Agent 每次都要重复探索。
• 原始材料适合生产和协作，却不适合学习、导航和跨源比较。

编译型知识层把这些重复推理前移，形成主题页、组件说明、关系图、决策记录、FAQ 或索引。它类似“源代码到构建产物”的关系：知识页是派生物，原始来源仍是事实依据。

三、基本模型

原始来源 → 解析与规范化 → 知识单元与关系 → Wiki 页面 / Schema → 校验与审阅 → 检索、阅读与问答 → 反馈与增量更新

层次	保存什么	关键要求
Raw Sources	原始文档、代码、网页、记录、数据	不被派生摘要覆盖；保留版本与权限
Parsed Evidence	可定位文本、结构、符号、字段和位置	可回到原始片段；解析误差可识别
Compiled Wiki	主题、对象、关系、决策、导航与摘要	每个重要结论可追溯；事实与推断分开
Index	关键词、向量、图与结构化字段	与 Wiki 和来源版本一致；支持删除与权限传播
Runtime	搜索、RAG、Agent 读取与工具使用	查询时仍校验证据、权限和时效
Feedback	无结果、冲突、差评、人工修订和变更事件	进入候选队列，经审阅后更新稳定知识

四、LLM Wiki 与 RAG 的关系

维度	LLM Wiki	RAG
主要时点	查询前，持续或批量编译	查询时，按当前问题检索
主要输入	一组原始来源及其变化	用户问题、对话状态、索引
主要输出	稳定的知识页、关系、导航和摘要	当前问题的证据上下文与回答
主要价值	降低重复理解成本，改善可读性与整体结构	提供问题相关证据，降低参数知识过时影响
主要风险	编译错误、来源丢失、知识漂移、错误覆盖	召回失败、上下文污染、引用不忠实、提示注入
最佳组合	Wiki 作为高质量检索语料，同时保留回到 Raw 的路径	对 Wiki 与 Raw 分层召回，并在回答时显示来源层级

因此，“用 LLM Wiki 还是用 RAG”通常是一个错误二选一。更准确的问题是：

1. 哪些知识值得提前编译？
2. 查询时应检索编译结果、原始来源，还是两者一起？
3. 回答中的事实最终追溯到哪一层？

与相邻模式的区别

模式	主要产物	主要价值	不自动等于
编译型知识层	人和机器可读的主题页、对象页、决策与导航	跨来源综合、复用和维护	完整知识图谱或长期记忆
知识图谱 / 社区摘要	实体关系、子图、聚类和全局摘要	关系遍历与整体性问题	可供人维护的 Wiki
Agent 长期记忆	跨会话保留的事实、经验、状态或策略	减少重复探索并支持连续行动	组织的权威知识库

三者可以组合，但事实源、生命周期、权限和评测对象不同。只有当 Wiki 被持续写入、跨会话读取并影响 Agent 后续行为时，它才同时承担一部分长期记忆职责；只有当它显式维护实体和关系时，它才同时具有知识图谱特征。

Wiki 双链与 Neo4j 的职责边界

2026-09-09 补充。Wiki 也表达关系，Neo4j 也能保存说明文本；职责划分取决于数据模型和维护约定，不能简单说一个只供人读、另一个只供机器读。

维度	普通 Wiki 双链	结构化业务关系
连接对象	页面或段落	有稳定身份的行业、工序、要求、条款等实体
默认语义	引用或相关阅读，细节依赖正文	明确区分包含、采用、依据、候选等含义
擅长查询	怎样理解、有哪些解释、谁引用了这篇	沿哪些关系找到要求、条件是什么、影响哪些对象
维护重点	上下文、可读性、解释完整及出处	对象身份、关系含义、条件与版本一致性

例如脱墨页链接“监测点位要求”，单凭这条链接不能推断必须执行，也不能推断适用条件已满足。反向链接仅提供“谁引用了我”的导航，不证明反方向的业务关系成立。Obsidian 链接说明 与 Neo4j 属性图模型 分别说明这两类机制。

给 Markdown 配置稳定 ID、关系字段、条件和校验程序后，它也能作为结构化知识的维护源。技术载体并不决定事实权威；普通链接也不能未经复核直接升级成正式法规适用关系。

正式知识与解释怎样协作

建议每类正式事实只有一个权威维护位置，允许受控派生，不在 Wiki 和 Neo4j 中独立各改一份。

内容	建议维护源	派生与消费
原文、版本与位置	来源档案	Wiki 引用，图谱关联到条款
对象、正式关系、条件与参数	经复核的结构化知识与规则记录	生成关系投影及 Wiki 的事实部分
解释、案例与常见误解	经审核的 Wiki 解释稿	以对象 ID 关联并供阅读检索
企业事实与正式结果	业务系统及规则执行记录	按任务读取，结合通用知识说明

行业演示项目的当前通用 Wiki 和 Neo4j 均由统一结构化知识生成，并通过稳定 ID 关联；这属于程序生成的 Wiki 知识层。独立专家解释编辑层、模型辅助维护候选属于后续建议。详见 行业案例的实际分工 ↗。

如后续允许人工编辑解释，应将生成部分与独立解释稿分开保存或采用受保护的编辑区。重建不得覆盖人工内容。解释稿中的新观点先成为候选，经复核后再改正式关系或规则；发布后检查图谱、Wiki、规则与来源版本，过期内容提示复核。身份、权限和来源撤回的变化也应传播到派生内容。

OpenWiki 的当前代码 Wiki 实现以结构化 Claims 关联版本化仓库证据，并定位证据变化后的复核对象；这一机制可作设计参考。它针对代码仓库证据的能力不能直接等同于环保法规审查，模型维护也不保证所有内容自动正确。

五、适用场景

适合

• 代码库、产品文档或制度材料规模较大，且会被反复理解。
• 新人学习路径、组件关系、术语和决策背景很重要。
• 多个来源需要持续归并，但原始来源仍要保留。
• 人和 Agent 需要共享一层可读、可导航的知识界面。
• 系统有稳定的增量变化信号，例如 Git commit、文档版本或数据库事件。

不宜优先

• 来源极少、结构简单，搜索或 FAQ 已足够。
• 信息变化极快，而系统无法及时检测和重编译。
• 无法保存来源、版本和权限映射。
• 生成内容会被误当成权威事实，且没有审阅或校验机制。
• 目标只是一次性摘要，不存在长期复用和维护需求。

八、主要问题与处理

问题	为什么危险	控制方式
编译幻觉	错误被写入稳定层后会反复传播	来源引用、差异审阅、事实校验、禁止无证据强结论
来源压缩丢失	摘要省略限定条件或反例	保留 Raw 回链，关键结论记录适用范围
双层漂移	Raw 已更新，Wiki 或索引仍旧	版本水位、变更事件、重编译状态和一致性检查
错误合并	同名对象或相似概念被合并	稳定 ID、别名、类型和人工确认门
权限泄漏	低权限用户看到高权限来源的派生结论	权限继承、派生权限计算、检索前过滤
自我污染	模型生成物再次被当成新 Raw，错误循环放大	明确来源类型，派生层不自动升级为原始证据
过度编译	所有材料都生成页面，维护成本超过收益	以复用价值、稳定性和问题密度决定晋升