LLM Wiki 是一种借助 LLM 持续维护有效知识的方法OKF 则是让这套知识能够在不同工具之间交换的开放格式。现在我们来探讨一些 LLM Wiki 相关的工程实践。一、为 AI Coding 创建可维护的上下文知识地图LLM Wiki OKF 的一个应用场景是 AI Coding特别是对大型企业应用 — 它们通常依赖于大量、多形态、且不断演变的领域知识。LLM 的强大很容易制造一种错觉模型看得懂代码所以它便能理解我的项目。但事实上看懂一段 Java 或 TypeScript和理解“这段逻辑为什么只能放在这一层”、“这个接口为什么不允许跨模块直调”、“这段无用的代码为什么不废弃”是两回事。一个大型的企业软件系统常常涉及多个代码仓库与多个系统层次。真正的业务、技术与数据知识往往散落在需求与设计文档里很多边界藏在工程师的脑海中而各种接口协议又可能分布在代码和配置文件里。可行的方法是构建一个面向 Coding Agent 的 OKF Knowledge Bundle知识包。如何设计这张知识“地图”这个 Wiki 知识库独立于工具和编程语言也不依赖数据库与向量索引。你可以围绕 Agent 在完成编程任务时真正需要经过的路径来组织理解业务、理解架构、选择技术、确认边界、寻找接口和数据完成设计与编程。比如这样一个 LLM Wiki 知识库这套目录并非 OKF 定义而是自己定制的一套本地专有知识体系。还记得吗 — OKF 只提供最小的互操作格式规则真正的知识结构由你自己来决定。根index.md是 Agent 的上下文入口。它告诉 Agent你可以读取 business 目录了解业务流程并从 architecture 学习架构知识编码时则需要从 engineering 等读取编码规范、API、数据模型等。index.md 负责导航知识单元承载知识而源码负责代码事实。如何从 LLM Wiki 加载上下文Wiki 建好后不是把所有页面一次性塞进上下文代价太高。你需要指导 Agent 如何阅读先看全局地图再沿目录和关系逐层下钻获得完成任务所需的最小完整上下文。你可以在 Coding Agent 的全局规则或者 Skills 中给予提示例如- 先读根索引 index.md判断并选择最相关的知识域- 读取对应目录索引 index.md - 加载相关的 Concept并沿必要的 Markdown 链接继续展开补齐必要的知识信息- 区分已核验事实、来源观点和你的推断资料不足时标记知识缺口- 上下文足够后停止导航执行输入任务这是一种典型的“基于知识地图的渐进式上下文加载”。假设你的需求是“为订单失败增加自动补偿机制”那么 Agent 可以这样加载上下文在此过程中Agent 在必要时会回到代码核验方法签名、配置项、字段和真实调用链等因为 LLM Wiki 页面更适合描述相对稳定的知识、约束和规则等代码仍然是当前实现的最终证据。为了方便 Agent “探索”知识库一个实用的 AI Coding 的知识库最好同时记录结论和必要证据信息。你可以在知识单元中维护更多的元数据。比如resource指向对应代码、OpenAPI 规格、数据库 Schemasource_commit固定已经核验的代码版本owner说明由谁负责维护责任人是谁review_status区分草稿、Agent 推断、人工确认和已废弃timestamp最近一次有意义的更新时间正文进一步写清本知识适用条件、反例、何时要核查代码等注意这个 OKF 知识库应由 LLM 负责维护人工负责审核与指导。如何让知识产生“复利”效应这种由 LLM 持续维护的知识体系的另一个好处是可以产生“复利”效应。比如一次开发任务中可能会发现新的跨模块约束并补进架构页验证了某个 API 的副作用可以更新 API 契约页测试过程发现新的失败模式可以加入 Checklist等等。这样下次 Agent 就不必重蹈覆辙知识地图会随着任务逐渐完整。具体到实现方法可以让 Agent 在任务过程中把一些有价值的输出直接沉淀下来。比如把推理结果写入到 outputs / 目录自定义格式随后让 LLM 整理出有长期价值的结果并在审核后通过 PR 提交回流到 Wiki为下一次探索留下可复用制品。你也可以在任务结束后让 LLM 根据生成的代码与制品整理出可能的新知识。以上介绍了 LLM Wiki 在 AI Coding 中的应用实践。这种经过整理的、半结构化、持续维护的企业知识体系还可以在企业内部的知识培训、共享与传递、检索问答、客户服务等多个领域发挥作用。二、在 Obsidian 中构建 LLM Wiki 知识体系Obsidian 已经成为很多人的知识库选择特别是它强大的知识表示、链接能力与丰富的插件。如果把 LLM Wiki 的构建类比成“编译”Obsidian 则可以作为你的 IDE既可以保存你的原始笔记也可以保存“编译”后的 Wiki并提供编辑、链接与图谱展示的 UI。我们先看两种在 Obsidian 中编撰 LLM Wiki 知识体系的方法。路径一借助 Obsidian 的 LLM Wiki 插件Obsidian 中有个第三方的社区插件 Karpathy LLM Wiki。它把 LLM Wiki 的摄入、查询和维护流程直接放进 Obsidian只需要配置一个 LLM 即可。大致的使用方法如下具体请参考插件说明1、搜索并安装在插件设置中设置模型提供商2、从 Obsidian 命令面板执行“摄入单个源文件”或者“从文件夹摄入”、“多选文件摄入”。插件可以读取 Markdown 笔记或 PDF需要 LLM 支持然后由 LLM 总结、提取实体和概念等生成带别名、来源与[[Wiki Link]]的知识页面并维护索引wiki/index.md。原始笔记保持不变新知识则默认写入以下目录3、构建完成后可以打开插件的右侧面板“查询 Wiki”与你的知识对话。注意这里的对话并没有使用传统的 RAG 方法而是从 index.md 导航进入再沿页面中的[[Wiki Link]]图进行扩展最后得出答案所以无需配置嵌入模型。4、后续知识维护。这个插件并不只负责一次生成。它可以定时自动检查重复页、断链、空页、孤立页、缺失别名和矛盾等问题并智能修复也可以“监听文件夹的改动”并自动摄入你还可以定义自己的 Schema 描述来决定最终的知识结构。上面看到的输出结构是在默认的 config.md 中定义的该结构会被注入 LLM 提示词该插件适合个人的小型知识库安装简单使用界面完整几分钟就能看到结果。不过该插件目前生成的 LLM Wiki 还不是一个符合 OKF 标准的 Bundle你可以尝试自定义 config.md 来调整其 LLM 输出格式为 OKF。目前 Obsidian 社区中也有一些 OKF 插件但功能还不够强大。路径二自定义生成 Wiki 的 Agent/Skill如果你更看重 OKF 兼容、Git 审核或需要接入企业数据源、自定义治理规则可以参考上篇中介绍的方法构建自己的 Agent把现有的 Obsidian Vault 当作只读 Raw 来源。你仍然在熟悉的 Obsidian 环境里阅读、思考并用自己的语言记录笔记由 Agent 在旁边维护一个独立的 LLM Wiki。比如你的知识结构可以像这样raw可以是符号链接对应到自己的原始笔记。但要注意人工笔记不能被摄入 Agent 自动覆盖Wiki 可以由 Agent 修改但涉及隐私和重要决策的内容需要人工确认。基于 Agent 的 LLM Wiki 构建流程发现新增或变化的笔记读取相关 Raw 与已有 Concept生成变更计划更新概念页、交叉链接、索引和日志执行格式、断链与必填元数据等质量检查门禁通过 Git Diff 、 Pull Request 等提交给人工审核这种方法的好处是灵活、强大、可以根据自己的需要定制维护逻辑、可以结合 Git 进行团队的共享知识治理缺点是实现较复杂具体而言又可以有不同的路径比如借助 Agent 开发框架与 SDK如 LangChain、Pi、Google ADK 自行实现直接调用现有的 Coding Agent 来完成 — 为它配备必要的 Skill 即可自定义摄入 Agent 可以参考 GitHub 上 Google 官方 OKF 项目中的例子。无论你的 LLM Wiki 是由插件还是自定义 Agent 生成都可以直接用 Obsidian 打开把它作为浏览界面比如查看 Graph 视图根据 Wiki Link 自动生成借助 Obsidian 的双向链接与 Graph可以帮助我们观察到知识页的结构与质量问题某页是否成为异常中心节点、两个主题是否由某页连接、是否出现大量孤立页面、同一个概念是否因为缩写和全称被拆成多个节点等等。三、LLM Wiki 与 RAG定位与融合应用在对 LLM Wiki 的应用有了一定基础后让我们再次来认识它与 RAG 之间的关系。定位一个重在治理一个擅长检索很显然两者的重点并不一样LLM Wiki OKF 的重点是在知识的组织、治理与交换把文档整理、“编译”为标准格式的知识单元并持续维护它们的内容、关系和索引。RAG 向量检索的重点更偏向知识的运行时检索能力根据当前问题从大规模材料中召回候选知识内容重排并组装进模型上下文。用一个表格来总结维度LLM Wiki OKFRAG 向量检索定位知识组织、治理、交换格式运行时知识检索与上下文增强核心任务整理可复用、持续演化的知识针对当前问题召回相关知识工作时间摄入、变更和审查时持续进行预先做向量索引查询时实时检索主要单元目录、概念页、链接、索引、日志、元数据Chunk、Embedding、元数据、索引、Reranker长期产物可读、相互连接、可版本化的知识单元与地图Chunks、向量索引加载方式从入口索引逐层导航按需读取知识单元沿链接扩展将问题向量化召回 Top-K Chunks排序后注入上下文适用场景需要理解定义、关系、规则、操作方法的知识探索目标明确的事实查询、证据查找与大规模语料的问答上下文显式保留知识之间的层级、引用与依赖关系切块割裂了上下文可通过父子块、GraphRAG等缓解优势知识治理、重复利用、可移植、审计、渐进式披露大规模、语义检索、长尾问题、多模态检索、响应速度快主要风险过度整理丢失细节、维护成本、大规模下的性能召回知识的偏差、碎片化的知识丢失上下文、索引更新成本总的来说RAG 擅长快速找到可能相关的知识片段而最常见的方式是借助向量索引而 LLM Wiki 则擅长告诉 Agent 有哪些知识、彼此有什么关系按什么路径读取但具体查询知识的方式则由 Agent 决定。融合让 Wiki 成为知识源RAG 成为查询加速层由于二者在解决的问题领域、原理与方法存在如此大的区别因此两者不仅可以融合还能够形成互补LLM Wiki 作为权威的、持续维护的知识源而 RAG 则用来构建检索加速层。这样的知识系统有两个循环**知识准备与更新。**读取 Raw、定位受影响的知识单元、生成知识变更经过门禁与审核后发布到 LLM Wiki然后对 Wiki 构建 BM25与向量索引。查询与上下文注入。根据问题的特点采用不同策略查询与组装上下文。比如查询具体的 API 规格或规范术语可通过索引精确读取只知道某个知识领域可从index.md渐进式下钻问题表达模糊或 Wiki 很大先用 BM25 或向量定位候选知识单元先用向量检索到具体知识块再沿 Wiki Link 扩展必要的关联知识例如开发者要求 Coding Agent 完成任务“在订单创建完成后调用物流平台 API 创建运单。”那么 Agent 加载上下文的方式就可以是 LLM Wiki 与向量检索的配合这个例子可以简单概括为沿着 LLM Wiki 理解应该怎么做并用 RAG 查清 API 具体怎么调用。LLM Wiki 并非万能不要过度神话在上面的例子中理论上 Agent 也完全可以通过 Wiki 导航找到这个 API 相关的知识页。但这里必须要考虑的一个问题是如果你的知识规模非常庞大知识页的数量、每一页的知识内容、Wiki Link 的数量逐层探索 Wiki 也可能会带来性能下降与成本升高。当然这本身和你对知识组织与治理的能力有关。但整体而言对于相对独立、结构明确的知识如 API 规范、表结构、错误码等通过 RAG 检索可以更高效、简单地定位信息。两者结合可以兼顾理解能力与检索效率。实际应用时可以随着规模扩大按实际问题逐步增加基础设施几十到上百个 Concept优先使用index.md、文件路径和关键词页面达到数千且表达差异增大增加 BM25 与向量混合检索经常询问跨系统影响范围增加链接图Graph与图查询原始材料包含图片、录音和视频增加多模态解析与检索能力知识更新频繁增加增量构建、缓存和索引一致性检查等总之不要因为新方法的出现就轻易下“某某已死”的结论。很多时候技术演进只是能力边界的重新划分而非新旧替代。成熟的技术决策者不应该追逐单一的新技术而是深入理解每种技术的背景与价值选择最合适的方案。以上两篇文章是我们对 LLM Wiki 概念、方法与实践的系统介绍。LLM Wiki 的核心价值不是简单替代 RAG而是让企业知识成为一套可理解、可维护、可持续演进的知识体系而背后的核心能力来自 LLM。这种范式可以让 AI 能够基于一个持续成长的知识体系更可靠地完成诸如 Coding 这样的关键任务。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
LLM Wiki 是一种借助 LLM 持续维护有效知识的方法OKF 则是让这套知识能够在不同工具之间交换的开放格式。现在我们来探讨一些 LLM Wiki 相关的工程实践。一、为 AI Coding 创建可维护的上下文知识地图LLM Wiki OKF 的一个应用场景是 AI Coding特别是对大型企业应用 — 它们通常依赖于大量、多形态、且不断演变的领域知识。LLM 的强大很容易制造一种错觉模型看得懂代码所以它便能理解我的项目。但事实上看懂一段 Java 或 TypeScript和理解“这段逻辑为什么只能放在这一层”、“这个接口为什么不允许跨模块直调”、“这段无用的代码为什么不废弃”是两回事。一个大型的企业软件系统常常涉及多个代码仓库与多个系统层次。真正的业务、技术与数据知识往往散落在需求与设计文档里很多边界藏在工程师的脑海中而各种接口协议又可能分布在代码和配置文件里。可行的方法是构建一个面向 Coding Agent 的 OKF Knowledge Bundle知识包。如何设计这张知识“地图”这个 Wiki 知识库独立于工具和编程语言也不依赖数据库与向量索引。你可以围绕 Agent 在完成编程任务时真正需要经过的路径来组织理解业务、理解架构、选择技术、确认边界、寻找接口和数据完成设计与编程。比如这样一个 LLM Wiki 知识库这套目录并非 OKF 定义而是自己定制的一套本地专有知识体系。还记得吗 — OKF 只提供最小的互操作格式规则真正的知识结构由你自己来决定。根index.md是 Agent 的上下文入口。它告诉 Agent你可以读取 business 目录了解业务流程并从 architecture 学习架构知识编码时则需要从 engineering 等读取编码规范、API、数据模型等。index.md 负责导航知识单元承载知识而源码负责代码事实。如何从 LLM Wiki 加载上下文Wiki 建好后不是把所有页面一次性塞进上下文代价太高。你需要指导 Agent 如何阅读先看全局地图再沿目录和关系逐层下钻获得完成任务所需的最小完整上下文。你可以在 Coding Agent 的全局规则或者 Skills 中给予提示例如- 先读根索引 index.md判断并选择最相关的知识域- 读取对应目录索引 index.md - 加载相关的 Concept并沿必要的 Markdown 链接继续展开补齐必要的知识信息- 区分已核验事实、来源观点和你的推断资料不足时标记知识缺口- 上下文足够后停止导航执行输入任务这是一种典型的“基于知识地图的渐进式上下文加载”。假设你的需求是“为订单失败增加自动补偿机制”那么 Agent 可以这样加载上下文在此过程中Agent 在必要时会回到代码核验方法签名、配置项、字段和真实调用链等因为 LLM Wiki 页面更适合描述相对稳定的知识、约束和规则等代码仍然是当前实现的最终证据。为了方便 Agent “探索”知识库一个实用的 AI Coding 的知识库最好同时记录结论和必要证据信息。你可以在知识单元中维护更多的元数据。比如resource指向对应代码、OpenAPI 规格、数据库 Schemasource_commit固定已经核验的代码版本owner说明由谁负责维护责任人是谁review_status区分草稿、Agent 推断、人工确认和已废弃timestamp最近一次有意义的更新时间正文进一步写清本知识适用条件、反例、何时要核查代码等注意这个 OKF 知识库应由 LLM 负责维护人工负责审核与指导。如何让知识产生“复利”效应这种由 LLM 持续维护的知识体系的另一个好处是可以产生“复利”效应。比如一次开发任务中可能会发现新的跨模块约束并补进架构页验证了某个 API 的副作用可以更新 API 契约页测试过程发现新的失败模式可以加入 Checklist等等。这样下次 Agent 就不必重蹈覆辙知识地图会随着任务逐渐完整。具体到实现方法可以让 Agent 在任务过程中把一些有价值的输出直接沉淀下来。比如把推理结果写入到 outputs / 目录自定义格式随后让 LLM 整理出有长期价值的结果并在审核后通过 PR 提交回流到 Wiki为下一次探索留下可复用制品。你也可以在任务结束后让 LLM 根据生成的代码与制品整理出可能的新知识。以上介绍了 LLM Wiki 在 AI Coding 中的应用实践。这种经过整理的、半结构化、持续维护的企业知识体系还可以在企业内部的知识培训、共享与传递、检索问答、客户服务等多个领域发挥作用。二、在 Obsidian 中构建 LLM Wiki 知识体系Obsidian 已经成为很多人的知识库选择特别是它强大的知识表示、链接能力与丰富的插件。如果把 LLM Wiki 的构建类比成“编译”Obsidian 则可以作为你的 IDE既可以保存你的原始笔记也可以保存“编译”后的 Wiki并提供编辑、链接与图谱展示的 UI。我们先看两种在 Obsidian 中编撰 LLM Wiki 知识体系的方法。路径一借助 Obsidian 的 LLM Wiki 插件Obsidian 中有个第三方的社区插件 Karpathy LLM Wiki。它把 LLM Wiki 的摄入、查询和维护流程直接放进 Obsidian只需要配置一个 LLM 即可。大致的使用方法如下具体请参考插件说明1、搜索并安装在插件设置中设置模型提供商2、从 Obsidian 命令面板执行“摄入单个源文件”或者“从文件夹摄入”、“多选文件摄入”。插件可以读取 Markdown 笔记或 PDF需要 LLM 支持然后由 LLM 总结、提取实体和概念等生成带别名、来源与[[Wiki Link]]的知识页面并维护索引wiki/index.md。原始笔记保持不变新知识则默认写入以下目录3、构建完成后可以打开插件的右侧面板“查询 Wiki”与你的知识对话。注意这里的对话并没有使用传统的 RAG 方法而是从 index.md 导航进入再沿页面中的[[Wiki Link]]图进行扩展最后得出答案所以无需配置嵌入模型。4、后续知识维护。这个插件并不只负责一次生成。它可以定时自动检查重复页、断链、空页、孤立页、缺失别名和矛盾等问题并智能修复也可以“监听文件夹的改动”并自动摄入你还可以定义自己的 Schema 描述来决定最终的知识结构。上面看到的输出结构是在默认的 config.md 中定义的该结构会被注入 LLM 提示词该插件适合个人的小型知识库安装简单使用界面完整几分钟就能看到结果。不过该插件目前生成的 LLM Wiki 还不是一个符合 OKF 标准的 Bundle你可以尝试自定义 config.md 来调整其 LLM 输出格式为 OKF。目前 Obsidian 社区中也有一些 OKF 插件但功能还不够强大。路径二自定义生成 Wiki 的 Agent/Skill如果你更看重 OKF 兼容、Git 审核或需要接入企业数据源、自定义治理规则可以参考上篇中介绍的方法构建自己的 Agent把现有的 Obsidian Vault 当作只读 Raw 来源。你仍然在熟悉的 Obsidian 环境里阅读、思考并用自己的语言记录笔记由 Agent 在旁边维护一个独立的 LLM Wiki。比如你的知识结构可以像这样raw可以是符号链接对应到自己的原始笔记。但要注意人工笔记不能被摄入 Agent 自动覆盖Wiki 可以由 Agent 修改但涉及隐私和重要决策的内容需要人工确认。基于 Agent 的 LLM Wiki 构建流程发现新增或变化的笔记读取相关 Raw 与已有 Concept生成变更计划更新概念页、交叉链接、索引和日志执行格式、断链与必填元数据等质量检查门禁通过 Git Diff 、 Pull Request 等提交给人工审核这种方法的好处是灵活、强大、可以根据自己的需要定制维护逻辑、可以结合 Git 进行团队的共享知识治理缺点是实现较复杂具体而言又可以有不同的路径比如借助 Agent 开发框架与 SDK如 LangChain、Pi、Google ADK 自行实现直接调用现有的 Coding Agent 来完成 — 为它配备必要的 Skill 即可自定义摄入 Agent 可以参考 GitHub 上 Google 官方 OKF 项目中的例子。无论你的 LLM Wiki 是由插件还是自定义 Agent 生成都可以直接用 Obsidian 打开把它作为浏览界面比如查看 Graph 视图根据 Wiki Link 自动生成借助 Obsidian 的双向链接与 Graph可以帮助我们观察到知识页的结构与质量问题某页是否成为异常中心节点、两个主题是否由某页连接、是否出现大量孤立页面、同一个概念是否因为缩写和全称被拆成多个节点等等。三、LLM Wiki 与 RAG定位与融合应用在对 LLM Wiki 的应用有了一定基础后让我们再次来认识它与 RAG 之间的关系。定位一个重在治理一个擅长检索很显然两者的重点并不一样LLM Wiki OKF 的重点是在知识的组织、治理与交换把文档整理、“编译”为标准格式的知识单元并持续维护它们的内容、关系和索引。RAG 向量检索的重点更偏向知识的运行时检索能力根据当前问题从大规模材料中召回候选知识内容重排并组装进模型上下文。用一个表格来总结维度LLM Wiki OKFRAG 向量检索定位知识组织、治理、交换格式运行时知识检索与上下文增强核心任务整理可复用、持续演化的知识针对当前问题召回相关知识工作时间摄入、变更和审查时持续进行预先做向量索引查询时实时检索主要单元目录、概念页、链接、索引、日志、元数据Chunk、Embedding、元数据、索引、Reranker长期产物可读、相互连接、可版本化的知识单元与地图Chunks、向量索引加载方式从入口索引逐层导航按需读取知识单元沿链接扩展将问题向量化召回 Top-K Chunks排序后注入上下文适用场景需要理解定义、关系、规则、操作方法的知识探索目标明确的事实查询、证据查找与大规模语料的问答上下文显式保留知识之间的层级、引用与依赖关系切块割裂了上下文可通过父子块、GraphRAG等缓解优势知识治理、重复利用、可移植、审计、渐进式披露大规模、语义检索、长尾问题、多模态检索、响应速度快主要风险过度整理丢失细节、维护成本、大规模下的性能召回知识的偏差、碎片化的知识丢失上下文、索引更新成本总的来说RAG 擅长快速找到可能相关的知识片段而最常见的方式是借助向量索引而 LLM Wiki 则擅长告诉 Agent 有哪些知识、彼此有什么关系按什么路径读取但具体查询知识的方式则由 Agent 决定。融合让 Wiki 成为知识源RAG 成为查询加速层由于二者在解决的问题领域、原理与方法存在如此大的区别因此两者不仅可以融合还能够形成互补LLM Wiki 作为权威的、持续维护的知识源而 RAG 则用来构建检索加速层。这样的知识系统有两个循环**知识准备与更新。**读取 Raw、定位受影响的知识单元、生成知识变更经过门禁与审核后发布到 LLM Wiki然后对 Wiki 构建 BM25与向量索引。查询与上下文注入。根据问题的特点采用不同策略查询与组装上下文。比如查询具体的 API 规格或规范术语可通过索引精确读取只知道某个知识领域可从index.md渐进式下钻问题表达模糊或 Wiki 很大先用 BM25 或向量定位候选知识单元先用向量检索到具体知识块再沿 Wiki Link 扩展必要的关联知识例如开发者要求 Coding Agent 完成任务“在订单创建完成后调用物流平台 API 创建运单。”那么 Agent 加载上下文的方式就可以是 LLM Wiki 与向量检索的配合这个例子可以简单概括为沿着 LLM Wiki 理解应该怎么做并用 RAG 查清 API 具体怎么调用。LLM Wiki 并非万能不要过度神话在上面的例子中理论上 Agent 也完全可以通过 Wiki 导航找到这个 API 相关的知识页。但这里必须要考虑的一个问题是如果你的知识规模非常庞大知识页的数量、每一页的知识内容、Wiki Link 的数量逐层探索 Wiki 也可能会带来性能下降与成本升高。当然这本身和你对知识组织与治理的能力有关。但整体而言对于相对独立、结构明确的知识如 API 规范、表结构、错误码等通过 RAG 检索可以更高效、简单地定位信息。两者结合可以兼顾理解能力与检索效率。实际应用时可以随着规模扩大按实际问题逐步增加基础设施几十到上百个 Concept优先使用index.md、文件路径和关键词页面达到数千且表达差异增大增加 BM25 与向量混合检索经常询问跨系统影响范围增加链接图Graph与图查询原始材料包含图片、录音和视频增加多模态解析与检索能力知识更新频繁增加增量构建、缓存和索引一致性检查等总之不要因为新方法的出现就轻易下“某某已死”的结论。很多时候技术演进只是能力边界的重新划分而非新旧替代。成熟的技术决策者不应该追逐单一的新技术而是深入理解每种技术的背景与价值选择最合适的方案。以上两篇文章是我们对 LLM Wiki 概念、方法与实践的系统介绍。LLM Wiki 的核心价值不是简单替代 RAG而是让企业知识成为一套可理解、可维护、可持续演进的知识体系而背后的核心能力来自 LLM。这种范式可以让 AI 能够基于一个持续成长的知识体系更可靠地完成诸如 Coding 这样的关键任务。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
