一、为什么要知识库领域知识决定了 AI 在业务中能发挥多大的价值和作用。任何 AI 系统都由模型、知识、架构三部分组成。模型由供应商提供只能被动接受架构常因模型能力升级而失效重做。相比之下领域知识只能从内部积累——不可替代且随业务演进而持续变化是最值得长期投入的部分。然而领域知识的沉淀面临诸多挑战在数据团队中尤为严重。知识散落在代码和注释、配置、钉钉文档、沟通记录等各处没有统一载体这带来两层后果知识质量退化传播靠口口相传人走知识就断口径不一致同一指标在不同文档里定义矛盾没人能仲裁即便有人写了文档也无人持续维护三个月后就和线上对不上。工程熵增缺乏全局视图团队无法判断一张表是否已经存在、一条链路是否已有人建过重复建设不断累积数据负债。数据团队中如口径答疑、问题排查、代码生成这些本可以被 AI 极大提效的场景都卡在了知识喂不进去这一步。直接套 RAG 解决不了这件事。RAG 的模式是每次查询都到原始文档碎片里现找现拼——chunk 召回、上下文拼接、模型生成——但它并不改变原始材料本身的状态。散落的还是散落的矛盾的还是矛盾的过期的还是过期的只是多了一层向量索引。知识本身的问题一个没解决只是把人找不到变成了AI找到了但答不准。问题出在知识本身不在检索。需要的是在检索之前加一道编译过程——把散落、矛盾、易腐化的源材料预先加工为可被AI直接消费的知识。这是 LLM Wiki 的起点。二、实际效果先来看看实际效果下面从指标维度召回、SQL代码生成以及数据模型迭代4个例子来介绍LLM Wiki的检索生成效果。2.1 指标和维度召回2.1.1 主播xxx分维度召回以主播xxx分用哪张表为例系统首先通过 index.md 定位到 basic/审核打标域然后全域搜索召回候选表再逐张读取详情页判断覆盖度和相关性。最终精准推荐xxx分维表作为首选同时区分出 DWD 增量明细表适合追溯变更历史和主播画像宽表适合同时需要xxx分和其他属性时并主动排除了名称相似但实际是讲解xxx分的干扰项。2.1.2 xxx交易指标召回用户问xxx交易指标怎么取系统经域推断 → 多路搜索 → 详情验证三步精准推荐 DIM 层标签表直接有xxx字段和 DWD 层明细表xxx标记字段可自行聚合并附带判定逻辑、SQL 示例和血缘链路一次查询给出从选表到取数的完整答案。2.2 SQL代码生成用户问不同主播等级的开播场次数怎么算系统自动跨维表域和供给开播域定位到主播基础信息宽表主播等级 主播标签预聚合表预聚合多窗口场次数或主播开播日汇总表按天累加自定义范围输出 JOIN 关联的 SQL 骨架同时标注废弃字段、xx开播口径和多套分级体系的差异——从自然语言到可执行 SQL一步到位。2.3 数据模型迭代2.3.1 背景数据模型迭代是数仓日常工作中高频且高风险的场景。一次迭代往往涉及上下游传播变更沿血缘链路传导影响可达数十张下游表阈值/规则联动字段参与 WHERE 条件、CASE WHEN 分档改错会导致业务判定失效口径一致性新旧口径差异可能引入数据偏差需双跑验证需求理解 → 查表结构 → 查血缘 → 判影响 → 估风险 → 写SQL → 验数据 ↓ ↓ ↓ ↓ ↓ ↓ ↓ 人工耗时 grep搜索 手动递归 看代码 凭经验 逐表改写 手写SQL传统做法依赖人工逐表排查 SQL 代码耗时易出错迫切需要一种新范式让 AI 承担查血缘、判风险、写代码的机械工作将人力聚焦在决策确认环节。2.3.2 基于LLM wiki的数据模型迭代基于LLM wiki知识库把迭代需求拆解成6个步骤按顺序调用对应的子Skill执行关键节点用户确认。步骤做什么输入→输出需求拆解理解需求识别需求类型需求描述 → 需求类型 指标口径知识库召回从Wiki查目标表拉取DDL和口径定义表名 → 表结构 口径说明血缘查询用graph.json查全链路下游强制完整性校验目标表 → 下游表完整列表风险评级看下游SQL判断业务影响高/中/低 风险类型下游表 → 二维风险矩阵SQL生成批量生成DDLETL验证SQL回滚SQL影响分析 → 全套SQL文件报告输出整合分析结果生成影响分析报告全流程结果 → 可交付报告2.3.3 具体实践场景场景一数据源切换data_source_switch需求xxx数据从加权计算切换到大盘数据源流程Step 1确认切换含义直接引用 vs 重新计算Step 3查全链路下游血缘发现 12 张间接下游表Step 4 路径A看下游 SQL发现阈值判定→ 业务影响高Step 5生成目标表改造 SQL 12 张下游表适配 SQL 口径对比 SQL关键发现间接下游表中有 3 张参与准入判定切换后阈值需调整场景二新增字段addition需求xxx数据链路新增xxx分等字段流程Step 1确认指标一一映射Step 4 路径B列出 ** 张候选下游表用户确认传播范围选中 * 张Step 5逐表判断血缘 JOIN 状态 → 生成 * 张下游表适配 SQL关键机制路径B 强制用户确认避免遗漏或过度传播2.3.4 最终效果事项传统人工AI 编排提效血缘查询时间30min手动递归2min–impact15×下游表遗漏率20%间接下游易遗漏0%强制完整性校验100%SQL 生成时间0.5天逐表改写10min批量生成72×风险判定一致性低凭经验高二维矩阵标准化质变2.3.5 总结通过 model-iteration-analysis 编排架构全流程自动化从需求输入到 SQL 输出人工只做三道确认血缘完整性保障下游详情补全杜绝遗漏风险量化评级二维矩阵替代模糊描述判定标准一致状态可追溯单一状态文件记录完整分析链路最终效果模型迭代影响分析从半天缩短到小时级下游表遗漏率从 20%降到 0%数据研发工程师从查代码、写 SQL的机械工作中解放聚焦在决策确认的高价值环节。三、LLM 编译器怎么建3.1 核心思想LLM Wiki 不是一份用 LLM 写出来的文档而是一份结构化、有约束、可验证的知识资产。它和传统文档的区别在四个层面结构可解析——单页内部结构。每个页面是 frontmatter 正文的双层结构frontmatter 是脚本可解析的 YAML承载关系字段type、domain、upstream、computed_by 等正文承载语义描述。脚本可直接读取关系信息不必依赖 LLM 反复解析正文。层级可下钻——跨页层级结构。域按业务主题嵌套组织形成可逐层下钻的树。Agent 检索时可从根域渐进披露避免一次性灌入全部上下文。关系可遍历——跨页关系结构。页面之间的血缘、归属、消费、引用关系以边的形式显式记录构成有向图。脚本可遍历、可计算影响范围、可做多跳召回。正确性可度量——分结构、语义、人工三层校验。结构层用机械规则做自动化约束语义层用 LLM 评审页面内容描述准确性、口径一致性、域归属合理性关键节点由人工确认兜底。三层叠加知识库正确性从主观判断转为可度量的工程指标。让 LLM 来建不是让人来建。人工维护 Wiki 的核心问题是成本高、腐化快、难持续。LLM 作为编译器把散落的源材料DDL、任务代码、文档、接口配置编译成结构化页面人只在关键节点做确认。整体构建过程可以抽象为六个步骤提取 → 生成 → 归类 → 聚合 → 链接 → 验证——对应编译器的词法分析、代码生成、作用域解析、IR 构建、链接、静态分析本质是一条将散落源材料编译为结构化知识的流水线。3.2 LLM Wiki 与 RAG互补而非冲突一个常见的疑问是有了 LLM Wiki 是否还需要 RAG需要但两者定位完全不同。可以用编译时 vs 运行时来理解。LLM Wiki 是编译时产物把原始材料预处理成高质量的知识页面RAG 是运行时手段在查询时刻做精准召回。Wiki 在构建阶段把散落材料固化为完整语义单元——血缘关系显式记录、口径以代码为准做仲裁、层级结构支持渐进式披露、每个页面自带 frontmatter 元数据。RAG 在查询时刻基于这些页面做精准召回frontmatter 用于硬过滤按层级、域、血缘正文用于语义匹配Wiki 尚未覆盖的长尾知识仍可回退到原始材料检索。一句话Wiki 提供高质量语料RAG 提供精准召回组合起来才是完整的检索栈。3.3 知识来源要全Wiki 编译的目标是让 AI 能回答业务问题而一个业务问题往往跨越多种知识载体表定义结构、接口定义契约、看板定义消费场景、文档承载业务背景。材料缺一类编译出的 Wiki 就有相应的盲区——只有 DDL 没有任务代码AI 知道字段叫什么但不知道怎么算有表没有看板AI 知道数据存在哪但不知道谁在用。材料的完整度直接决定了 Wiki 能回答的问题边界。因此知识来源需要从广度和深度两个维度保障广度分为编译时知识和运行时知识两类知识各司其职编译时知识提供是什么、怎么算、怎么连运行时知识提供现在长什么样。编译时知识将相对稳定的知识在构建阶段固化为 Wiki 页面覆盖 5 类载体——表DDL、接口Config Version、文档钉钉文档、任务独立任务代码、看板看板元数据。运行时知识对查询那一刻才能确定的信息物理表数据、任务日志、监控指标等通过 Agent 工具调用现取不进 Wiki。深度每张表不止抓 DDL还要抓产出任务代码。DDL 提供结构信息字段、类型、注释任务代码提供逻辑信息计算方式、过滤条件、聚合维度、上游依赖。只有 DDL 的 Wiki 仅是骨架加上任务代码才构成完整的知识。3.4 知识构建要准准是 Wiki 编译的核心挑战。源材料本身就带噪音——注释长期未更新、文档写错口径、不同来源对同一对象的描述相互矛盾LLM 生成时存在幻觉容易把不确定的推断写成确定的事实像域归属、指标聚类这类判断本身就有一定主观性。仅凭我们要保证准确这句口号无法解决需要一整套覆盖事前、事中、事后的工程纪律噪音过滤分入口和生成两道。入口阶段做粗筛从源头剔除明显过期、低质量的材料降低后续编译需要处理的冲突量。生成阶段做细筛由 LLM 在写 Wiki 时识别并跳过任务代码里的调试残留、文档里的过期片段不让噪音进入页面正文。代码即真相剩下的冲突需要明确的裁决规则。不同来源对同一对象描述不一致时以任务代码为权威——注释和文档可能长期失修但任务代码每天实际跑在生产上代表系统当下的真实行为。这条规则把所有以谁为准的争议收敛到唯一答案。生成与判断分离LLM 在生成基础 Wiki 时需要推断的字段强制留空只写有源材料直接支撑的内容不允许在生成阶段做主观推断。等所有基础页面生成完再独立跑一轮判断阶段基于已写入的内容综合输出候选。判断结果同时经过两道门禁机械门禁覆盖结构、链接、格式等可机械检查的维度未通过则阻断发布人工门禁覆盖域归属、聚类归并这类有主观性的判断由用户确认。代价是多一轮处理收益是把生成和判断两类容易出错的动作彻底解耦。证据链可追溯每个页面在 frontmatter 中保留sources字段逐项指向具体的源材料原始 DDL、任务代码、文档片段。一旦某条信息被怀疑有误可以立即定位到原材料用户校验 AI 答案时也可沿证据链反查依据。可溯源是事后兜底也是 Wiki 与凭印象写文档最根本的区别。3.5 知识的骨架是关系单页内容解决一张表是什么但业务问题往往不是关于一张表——“改了这张表影响哪些下游”“这个指标是从哪些表算出来的”“这个域下有多少资产”——都是关系层面的问题。如果关系只隐含在正文段落里每次回答都需要 LLM 重新从文本中抽取既不稳定也不高效。因此我们需要把关系从正文中抽出来显式存储为图血缘、归属、消费、引用等语义落到 frontmatter 字段再由构建流水线统一扫描提取沉淀为全局关系图。每条边都是结构化的、可遍历的、可计算的。显式建图带来三个能力维度影响范围可计算修改一张表后沿图向下游遍历即可得到完整影响面不依赖人工记忆。归属关系可聚合任何一个域包含哪些表、接口、看板一次查询完成支撑全景感知。枢纽节点可识别按引用频次入度排序可以快速发现数仓中的公共依赖和关键路径。关系图同时也是多路召回的基础——检索命中图上任何一个节点后可以沿边扩展关联节点召回关键词未命中但血缘强相关的知识。3.6 为检索而组织知识的构建和组织不是独立环节而是为检索服务的。怎么生成页面、怎么划分层级、怎么记录关系最终都要回答一个问题AI 在有限的上下文里能否快速找到最相关的知识。围绕这个目标层级结构和关系图分别承担不同的职责知识聚合把大量Wiki页面按主题进行聚合——字段聚合为指标和维度表、接口、看板聚合为域域按业务主题嵌套组织。聚合后检索面从数百个分散页面收敛到少数几个域入口AI 和人都能快速定位到目标区域。渐进式披露Agent 上下文有限不可能一次加载全部知识。层级结构天然支持逐层下钻从全景概览定位相关域从域定位关键页面从页面获取字段和逻辑细节。每一层按需加载在上下文预算内尽可能传递最相关的信息。多路召回聚合和渐进式披露解决的是纵向定位——从全局逐层收敛到目标页面。但业务问题往往涉及横向关联一张表的上游、一个指标的计算依赖、一个域下的全部资产。关系图在这里提供了第二条检索路径——命中一个节点后沿边扩展到血缘相关但关键词未命中的知识覆盖单靠文本相似度无法触达的关联页面。三者配合聚合解决信息爆炸渐进式披露解决上下文有限多路召回解决召回不全——这是知识库能服务 AI 检索的三个工程支点。四、架构设计Wiki 系统以文件为底座但在功能上构成了一个完整的知识管理系统。其中存储层多级文件系统、知识模型层Schema、计算层Agent 编排是三层主干后续章节描述的构建、检索、增量、Lint 等流程都基于这三层运行。其架构可以与数据库系统做如下类比数据库系统Wiki 系统对应关系存储引擎多级文件系统知识的物理组织和生命周期管理索引图索引 树索引加速检索的辅助结构DDL建表Schema 定义定义知识结构和约束写表INSERT/UPDATEWiki 生成按 Schema 写入结构化页面查询SELECTWiki 检索按索引和条件读取知识约束检查健康检查 验证机制保证数据一致性和正确性事务可恢复性断点续传 增量构建中断后幂等重跑已有正确产物跳过只补未完成部分执行引擎Agent 编排调度计算任务管理并行与串行4.1 多级文件系统知识库的生命周期跨越多个阶段清单维护、材料抓取、Wiki 生成、关系图构建、健康检查。每个阶段产出的物料形态不同——清单是输入、原始材料是中间态、Wiki 是最终产出需要分目录隔离避免互相污染。多级文件系统的本质是把不同生命周期的物料放进不同目录由目录承担状态语义。知识库根目录由环境变量KB_ROOT指定目录结构如下${KB_ROOT}/ ├── pre/ # 待处理清单 临时下载产物验证后移入 raw/ ├── raw/ │ ├── ready/ # 完整可用直接进入 Wiki 生成 │ ├── pending/ # 存在缺失或问题需治理后晋升 ready │ └── archive/ # 已下线或弃用不治理也不参与生成 ├── wiki/ │ ├── tables/{db_type}/ # 表页面按存储类型分目录 │ ├── domains/{parent}/ # 域页面按父域分目录 │ ├── concepts/ # 概念页面 │ ├── metrics/ # 指标页面 │ ├── dimensions/ # 维度页面 │ ├── dashboards/ # 看板页面 │ ├── apis/ # 接口页面 │ ├── datasets/ # 数据集页面 │ ├── graph.json # 全局关系图 │ ├── index.md # 全局索引 │ └── overview.md # 全景概览 ├── log/ # 构建日志、域候选、健康检查报告 ├── tmp/ # 跨 skill 协作的中间状态 └── schema/ # 页面模板5 个定义 frontmatter 与正文契约按职能可以分两类主流程目录承载知识从源到产物的状态流pre/维护待处理清单并临时承接抓取下来的原始材料验证通过后移入raw/raw/按状态分流存放原始材料供下游编译使用wiki/存放编译完成的结构化页面——清单 → 原始材料 → 结构化页面三态接力构成完整的主路径。支撑目录服务于编译过程本身log/提供可观测性构建日志、健康检查报告tmp/承载跨 skill 协作的中间状态schema/定义页面契约frontmatter 与正文模板。两类目录互不干扰主流程跑通即可对外发布。主流程中raw/又进一步细分为三态承担材料质量的入口保障ready/完整可用直接进入 Wiki 生成。pending/存在缺失或问题需经过治理后晋升ready/。archive/已下线或弃用不治理也不参与生成仅作为历史归档保留。Wiki 生成阶段只读ready/从源头杜绝低质量材料进入编译流水线把材料是否可用从隐藏字段变成目录归属的物理事实。4.2 Schema 即契约Wiki 系统中有多个环节需要读写页面生成器写入、图构建器提取关系、健康检查校验结构、query 检索内容。如果每个环节对页面长什么样各有理解就会出现生成器写了但检查器读不出的状况。Schema 的作用是对所有环节提供唯一的结构约定类似微服务间的接口协议——生产者按它写消费者按它读任何工具用同一个 parser 就能拿到一致视图。每个页面是 frontmatter 正文的双层结构两者通过 Schema 绑定形成统一契约。frontmatter 是 YAML 格式的结构化头部包含共性字段title、type、description、sources、created、updated 等所有页面都有的字段和页面特有字段如 table 的 upstream/downstream/domain/layermetric 的 computed_bydashboard 的 uses_datasets 等。这些字段承载关系和元数据脚本可直接按字段提取不需要解析自然语言。正文是 Markdown 格式的语义内容每种页面类型定义了固定的章节模板如 table 页面包含业务背景 / 加工逻辑 / 字段说明 / 下游 / 使用建议五个章节。正文承载业务背景、加工口径、字段说明这些需要 LLM 理解的内容供检索和问答使用。正文中的[[表名]]Wikilink 引用是 frontmatter 关系之外的兜底机制。frontmatter 记录的是显式声明的强关系血缘、归属、消费Wikilink 覆盖的是行文中提到但未落到字段里的弱关联图构建器会扫描这些链接生成wikilink边确保关系图不遗漏正文中隐含的引用。4.3 Agent 编排编排层与干活层分离Wiki 编译是一个多阶段、多类型的任务材料预处理、基础页面生成、高阶聚合、图构建、健康检查每个阶段的输入输出差异大且 LLM 调用是主要时间瓶颈。如果用一个大 skill 串行处理所有事情既无法并行加速也难以独立调试某个阶段的问题。因此系统采用编排层与干活层分离的架构——编排器负责调度和协调干活的 skill 各自只关心自己那一段的逻辑。整个 Wiki 系统由 7 个 skill 组成编排架构如下wiki-orchestrator (编排层) │ ┌─────────┬───────┼───────┬─────────┬──────────┐ ▼ ▼ ▼ ▼ ▼ ▼ material base advanced graph health query -prep -gen -gen -builder -check (4 子模块) (32 阶段)编排层wiki-orchestrator只做四件事意图路由识别用户在做哪个 Phase、用户确认域归属、看板归属、生成范围等关键决策点、子 Agent 调度spawn 并行或串行、结果汇报聚合各 skill 输出。它不读原始材料、不写 Wiki 文件、不做 LLM 内容生成——职责严格收敛在调度这一层。干活层的拆分遵循高内聚、低耦合原则高内聚——每个 skill 内部覆盖的所有子任务输入输出来源相同、执行模式相近整体流程对所有对象类型一致只在具体实现上按类型差异化类似代码开发中的抽象接口和具体实现。例如 wiki-material-prep 内部 5 类对象共用读清单 → 调元数据接口 → 验证 → 三态分流流程wiki-base-generator 内部 4 种页面共用扫描现状 → 批间串行批内并行生成 → 校验 → 落盘流程新增一类对象或页面只需补一个实现模块流程框架不变。低耦合——skill 之间不直接调用仅通过文件系统约定的目录交互前一个 skill 把产出落到约定目录后一个 skill 读这个目录任何 skill 都可以独立运行。拆分粒度也由这条原则决定拆得太细破坏内聚如把基础生成的 4 种页面拆成 4 个独立 skill相同的调度框架要重复实现 4 遍拆得太粗也破坏内聚如把基础生成和高阶生成合并但两者输入、依赖、生成方式都不同合并后内部逻辑异质化、调试困难。基础 Wiki 和高阶 Wiki 的拆分正是后一类粒度的边界是干活层切分中最关键的一刀维度基础 Wiki高阶 Wiki性质原子知识单元聚合知识单元类型表、接口、数据集、概念域、看板、指标、维度、index、overview输入来源raw/ready/中的源材料已落盘的基础 Wiki生成方式一对一映射每个对象生成一页多对一聚合多对象按主题归并成一页依赖关系不依赖其他 Wiki必须等基础 Wiki 全部落盘两者属于天然的两个阶段分开建模才能让原子生成和聚合归并各自独立优化、独立调试。综合上述拆分原则干活层的 6 个 skill 各自覆盖编译检索流水线的一个阶段Skill覆盖阶段职责wiki-material-prepPhase 0 材料预处理维护清单、抓取 DDL 和任务代码、验证分流wiki-base-generatorPhase 1 基础生成生成表、接口、数据集、概念四种基础页面wiki-advanced-generatorPhase 1 高阶生成生成域、看板、指标、维度、index、overviewwiki-graph-builderPhase 1 图构建扫描 frontmatter 和 Wikilink沉淀关系图wiki-health-checkPhase 2 健康检查执行结构、链接、格式等多项校验wiki-query运行时检索检索页面、查询血缘、关键词搜索每个 skill 只关心自己的输入输出契约不感知其他 skill 的内部实现。以上拆分编排/干活两层 干活层 6 个 skill共同带来三个收益可并行LLM 调用是主要时间瓶颈分离后凡是数据不依赖的步骤都可以 spawn 子 Agent 并行执行如基础生成的批内并行、高阶生成的域 看板 指标维度三路并发编译耗时显著下降。可独立调试某个阶段出错时只需重跑对应的 skill不必从头走完整流水线。每个 skill 内聚度高输入输出边界清晰问题定位成本低。可单独复用任何 skill 都可以脱离编排器独立调用——比如只跑健康检查验证现有 Wiki、只跑 query 做检索不必触发完整构建。五、知识编译流水线编译流水线分为三阶段——Phase 0 材料预处理、Phase 1 Wiki 生成基础生成 高阶生成 图构建、Phase 2 健康检查。每个阶段都有明确的输入、输出和处理逻辑下面依次展开。5.1 Phase 0材料预处理Phase 0 负责把源材料从外部系统抓取下来经过验证和分流作为 Phase 1 编译的输入。流程分为五步用户提供 5 类对象清单表、任务、看板、接口、文档。LLM 解析清单内容并写入对应的 CSV 文件。脚本根据清单批量调用元数据接口抓取 DDL、任务代码、看板配置、接口配置、文档原文。脚本验证每个对象的材料完整性。按结果三态分流到raw/ready/、raw/pending/、raw/archive/。其中 LLM 仅在第二步介入把自然语言输入转为结构化清单其余环节都是确定性脚本。Phase 0 在设计上有三个关键考量全脚本化执行抓取、验证、分流是确定性逻辑不依赖 LLM——避免了幻觉风险结果可重放可复现且不消耗 token。Phase 0 处理的是机械性高、判断性低的任务抓 DDL、对账、移文件脚本化是更合理的选择。脚本验证前置材料抓取后并不直接进入 ready必须先经过完整性校验如表必须同时有 DDL 和任务代码、命名规范、内容非空未通过的进入 pending 等待治理。质量门禁前置在入口避免噪音材料污染后续编译。支持断点续传抓取大批材料时网络异常或接口限流难以避免断点续传可以从上次中断位置继续不必重头抓所有对象——这是整体架构事务可恢复性在 Phase 0 的具体落点。完成后等待用户确认材料的分流决策确认通过后进入 Phase 1 基础生成。5.2 Phase 1 基础基础 Wiki 生成Phase 1 基础阶段负责把raw/ready/中的源材料编译为 4 种基础 Wiki 页面——表、接口、数据集、概念。流程分为三步扫描现状对比已有 Wiki、新增材料、sources 一致性确定本次需要生成、修复、跳过的对象集合按批间串行、批内并行的策略生成基础 Wiki 页面含 frontmatter 正文所有页面生成完毕后跑一轮统一校验未通过的标记重生成。基础 Wiki 落盘后再独立执行域候选判断输出候选列表供用户确认回填domain字段。基础 Wiki 生成阶段有四个关键设计批间串行、批内并行每批 5 个对象批内 spawn 5 个独立子 Agent每个子 Agent 只读自己那张表的源材料、独立生成。这种切分有两层价值——一是并发提速5 路并行明显快于串行二是上下文隔离每个子 Agent 的 LLM 上下文只承载一个对象的信息避免多对象拼接时 LLM 张冠李戴的幻觉。批的大小5是平衡 LLM 配额、错误恢复成本、并发收益的工程折中。生成完后统一校验所有基础 Wiki 生成完毕后由验证脚本统一校验产出页面——frontmatter 字段是否符合 Schema 约束必填项齐全、枚举值合法、类型正确正文表结构列出的字段是否真实存在于 DDL防止 LLM 幻觉出不存在的列。校验未通过的页面会被标记重生成。这是页面级的字段一致性校验与 Phase 2 全局健康检查互为前后两道关卡。生成与判断分离基础生成阶段domain等需要推断的字段一律留空避免 LLM 在尚未掌握全局信息时做主观判断所有基础页面落盘后再独立跑判断阶段基于已写入的内容综合输出候选由用户确认后回填——具体见 3.4。增量感知扫描现状后只对真正发生变化的对象新增材料、sources 不一致触发生成已有且一致的页面跳过。这是 Wiki 长期维护成本可控的前提。基础 Wiki 落盘后进入高阶聚合阶段。5.3 Phase 1 高阶高阶 Wiki 生成Phase 1 高阶阶段把已落盘的基础 Wiki 按业务主题聚合产出 6 种聚合页面域、看板、指标、维度、index、overview。整个过程由一条 DAG 驱动——一阶段三路并行二阶段串行汇聚一阶段三路并行域页面从基础 Wiki 的domain字段反查抽出域列表按层级生成domains/{parent}/{leaf}.md。看板页面基于数据集 Wiki 生成对每个看板的域归属生成候选由用户确认。指标与维度脚本字段聚类 → 子 Agent DWD 分析 → 用户确认归并 → Wiki 生成 → 脚本一致性校验五个步骤。二阶段串行汇聚必须等一阶段就绪才能跑。index.md每个一级域并行写章节再合并为全局索引。overview.md基于域页面 表 frontmatter 产出全景概览。这条 DAG 的蕴含两层设计意图并发最大化阶段三路无依赖的步骤齐头并进二阶段有依赖的步骤等齐再跑在依赖约束下尽量挖出并发收益。关键节点嵌入审核看板的域归属、指标维度的聚类归并以及一致性校验都嵌在 DAG 节点中由用户确认或脚本兜底而不是事后补丁把机器无法独自判断和机器可机械验证两类工作显式纳入流程。高阶页面之所以能这样组织关键在于聚合靠 frontmatter 字段反查。域页面、指标页面的内容来自基础 Wiki 的 frontmatter 字段聚合如域页面列出我下面有哪些表是反查所有domain字段指向自己的表不需要重新解析正文。这正是 4.2 frontmatter 设计的直接收益——单页关系字段化让跨页聚合可以低成本完成。至此基础和高阶 Wiki 全部落盘关系字段已就位下一步进入图构建。5.4 Phase 1 链接图构建Phase 1 链接阶段产出全局关系图graph.json由节点和边两部分组成。节点对应每个 Wiki 页面不存储冗余信息节点详情按需从对应页面 frontmatter 读取共 8 种类型节点类型路径前缀tabletables/{db_type}/domaindomains/{parent}/conceptconcepts/{businessmetricmetrics/{business_process}/dimensiondimensions/dashboarddashboards/datasetdatasets/apiapis/边是页面之间的关系共 8 种正向边按语义分四类边类型含义方向来源字段has_upstreamODPS 离线血缘当前表 → 上游表upstreamtask_typeodpssyncs_from同步任务血缘当前表 → 来源表upstreamtask_typesyncwrites_fromFlink 实时血缘当前表 → 来源表upstreamtask_typeflinkbelongs_to归属关系表/接口/看板/子域 → 父域domain/parentcomputed_by指标/维度来源指标/维度 → 表computed_byuses看板使用看板 → 数据集uses_datasetsqueries接口/数据集查询接口/数据集 → 表queries_tableswikilink兜底引用引用页 → 被引页正文[[...]]图的构建过程扫描所有 Wiki 页面目录提取每个页面的 frontmatter按字段映射到 8 种边类型——例如表的upstream字段产生血缘类边具体类型由task_type决定看板的uses_datasets字段产生uses边。整个过程由脚本完成不依赖 LLM。图构建完成后会反哺 Wiki基于血缘类正向边反向计算每张表的下游列表回填到 frontmatter 的downstream字段。只读 Wiki 不读图的工具也能直接拿到下游信息避免轻量消费场景强制依赖graph.json。只存正向边 反向按需 回填关键反向字段 文件存储带来了三个收益存储与一致性——反向边信息完全冗余于正向边存两份必然带来双向同步的一致性负担。只存正向边将存储减半一致性问题随之消失运行时需要反向访问时按需构建索引开销可控O(E)。消费灵活性——图供需要全局遍历的场景使用多跳血缘、影响范围分析反哺到 frontmatter 的downstream供只看单页的轻量场景使用两类消费方各取所需。轻量化——关系图以单个 JSON 文件graph.json存储无需部署和维护图数据库任何工具直接读取可随代码仓库版本管理适合当前规模的知识库。编译产出已完整最后一步是健康检查兜底。5.5 Phase 2健康检查Phase 2 健康检查是编译流水线的最后一道质量门禁对编译产物做全局对账决定本次构建是否对外发布。健康检查覆盖结构和格式两类维度共 6 项检查项检查内容数量一致性DDL、Wiki 页面、graph.json节点三方对账确保对象数量对齐结构完整性按页面类型校验 frontmatter 字段集必填项齐全、类型正确、枚举值合法链接有效性Wikilink 断链检测、孤岛页面检测无入边的页面Domain 格式域字段是否符合层级正则一级域/二级域/…YAML 语法graph.json和所有页面 frontmatter 的 YAML 语法合法性Graph 完整性节点路径合法、边类型在白名单、边两端节点存在任意一项检查未通过都视为本次编译失败输出诊断报告到log/wiki-health-check-{timestamp}.md标记具体不通过的对象和原因未通过的编译产物不对外发布。健康检查与流水线前序阶段构成两道校验关卡5.2 的生成完后统一校验是页面级、生成时的字段一致性检查如表结构列出的字段是否真实存在于 DDL5.5 是全局、构建后的对账与契约检查如 Wiki 总数与 DDL 数量、graph.json的边是否都连接到合法节点。两者互补——前者保证单页正确后者保证整体一致共同实现 3.4 提出的正确性可度量和 4.2 提出的Schema 即契约在流水线层面的兜底。健康检查通过后本次编译产出对外发布一次完整的 Wiki 编译流水线结束。六、知识检索检索是 Wiki 的最终消费场景前面的构建和组织最终都要服务于它。前面已经从构建侧给出了为检索而组织的设计原则——聚合、渐进式披露、多路召回。从查询侧看完整的检索栈分为三步意图识别、多路召回、重排序输出。6.1 意图识别任何一次查询请求进入检索前先做意图识别按查询特征分为三类精确查询用户给出明确实体名表名、域名、指标名。直接读取目标页面的详情和血缘即可无需召回环节。关系查询实体名 方向词上游、下游、影响、归属。直接走关系图遍历沿对应方向边扩展。模糊搜索关键词、业务概念、筛选条件。需要走多路召回 重排序的完整链路。模糊搜索之前强制做域推断先读index.md根据用户关键词的语义匹配相关域同时考虑生产方域和消费方域将搜索范围从全库收敛到 2~3 个相关域。这一步不可跳过——它在召回阶段就把搜索空间大幅缩小是后续召回质量的前提也是 3.6 渐进式披露原则在检索侧的直接落地。6.2 多路召回模糊搜索的核心是基于域、关键词、图的多路召回分两阶段执行。阶段一缩小范围并生成候选——两路并行。域召回基于index.md推断出的相关域读取对应的域页面召回域下挂载的相关表用业务主题做硬过滤。关键词召回在 frontmatter 字段和正文上做加权关键词匹配按字段重要性分配权重标题、描述、域、上下游等结构化字段权重高于正文输出按 score 排序的候选集当用户提到具体字段名时退化为精确匹配。两路并行执行一个走层级一个走文本从不同维度切入相同的搜索空间。阶段二图扩展——基于阶段一命中的候选表沿关系图的血缘边向上下游扩展把用户搜了 ADS 表但答案在它的 DWS 上游这类跨节点场景兜进来。阶段一和阶段二的产出合并去重输出 4~6 张候选表交给精排。这种两阶段的设计——先用层级和关键词从全库收敛到候选集再用图扩展补全血缘相关知识——同时利用了 3.6 中树聚合和图多路召回的两类组织能力。6.3 重排序输出重排序分粗排和精排两步。粗排由脚本完成基于关键词命中权重和通用性指标计算 score按分排名输出 4~6 张候选表脚本不做语义判断只用确定性规则做初筛。精排由 LLM 完成对粗排输出的每张候选表逐一读取详情frontmatter 正文判断它是否真正满足查询需求。精排有一条硬约束LLM 必须对每张候选表都读详情不允许在前几张匹配度高时提前停止。靠后的候选可能因为通用性、覆盖度更高而成为最终推荐跳过详情读取就无法识别这种情况。精排基于三个维度覆盖度表的实际字段和数据是否覆盖用户需求。LLM 读取页面详情后判断不依赖关键词命中位置。相关性表的主题与用户搜索意图的语义贴合度。通用性被大量下游消费的表作为数仓中汇聚消费方的枢纽表。通用性单独成维的设计是为了对抗数仓中的重复建设——一张被广泛使用的表如果用户不知道往往会另建一张高度相似的表长期累积形成数据负债。把通用性显式纳入排序维度让用户在检索时能感知到现有的公共依赖资产复用率自然提升。排序逻辑分两层覆盖度是硬门槛——不满足用户需求的表直接淘汰无论其他维度多突出。在覆盖度合格的候选中LLM 根据查询意图综合权衡相关性和通用性——查询意图明确具体时如我要查某个特定指标相关性优先查询意图偏探索时如这个域有哪些常用表通用性优先。最终输出最推荐表 候选列表 血缘链路。整条检索链——意图识别按查询类型路由多路召回利用树和图同时从层级和关系两个维度收敛候选重排序由 LLM 在结构化候选上做最终判断——是前面为检索而组织在查询侧的具体落地也是构建阶段所有结构化投入Schema、关系图、域树的最终消费场景。七、增量编译与持续 Lint知识库不是一次性建完就锁起来的——它每天都在变。新表上线、口径调整、任务代码迭代都会让源材料变化如果每次变更都全量重建LLM 成本和构建时间都不可接受。增量编译的目标是让构建成本只和变化量相关而不是和总规模相关未变化的部分跳过变化的部分按依赖关系局部重跑。增量识别的关键是扫描现状对账。每次构建前先比对三方状态源材料目录新增、删除、内容变化。已有 Wiki 页面已落盘的结构化页面集合。Wiki 中记录的sources字段页面引用的源材料路径。差异决定本次需要触发哪些阶段的子集执行——这部分逻辑已在 5.2 基础生成的扫描现状环节落实增量编译沿用同一套对账机制。增量编译可以覆盖三类典型场景新材料入库新表或新接口加入清单。材料预处理拉取新增对象的源材料基础生成只为新增对象产出 Wiki已有页面不动域判断只对新增对象做归属候选最后图构建做一次全量重建开销 O(E)相对生成阶段可忽略。知识腐化更新上游 DDL 或任务代码变更对应 Wiki 已与源材料不一致。重新跑材料预处理和基础生成覆盖更新对应页面再触发图构建重建并自动回填downstream最后跑健康检查确认整体一致性。结构性修复某次构建留下少量校验失败的页面或某条规则升级后存量页面不合规。直接调用对应阶段基础生成 / 高阶生成 / 图构建局部重跑相关页面不必从材料预处理开始重走全程。Lint 是把健康检查从构建后一次性兜底扩展为持续性质量巡检。健康检查的 6 项规则数量一致性、结构完整性、链接有效性、Domain 格式、YAML 语法、Graph 完整性作为知识库的 Lint 规则集每周或在重大变更后定期跑一次发现断链、孤岛、格式退化、节点冗余等问题不通过的项进入治理待办由对应阶段触发增量重生成。Lint 让知识库的健康度从构建时合格变成持续合格与第三章 3.4 提出的正确性可度量形成构建期 运维期的双重保障。八、总结一句话用 LLM 编译思维替代人工写 Wiki把散落的源材料编译成结构化、有约束、可验证的知识资产。这套实践由几条相互支撑的设计决策构成源材料用代码即真相做仲裁解决多源冲突生成阶段坚持生成与判断分离让 LLM 不做主观推断产出经过结构、语义、人工三层校验使正确性可度量所有页面遵循 Schema 即契约跨工具消费时按字段直接读取页面之间的关系显式存储为图业务主题聚合为树并支持渐进式披露Agent 在有限上下文里也能高效消费编排和干活分层协作高内聚、低耦合让流水线可并行、可调试、可单独复用。回到开篇——领域知识决定了 AI 在业务中能发挥多大价值而它只能从内部积累无法从外部获取。LLM Wiki 提供的是一套系统化的沉淀方法把散落、矛盾、易腐化的领域知识编译为结构化、可验证的知识资产。这是 AI 时代最值得长期投入的基础设施。九、未来规划扩展知识来源把任务清单、看板清单从预留转为正式落地接入实时表和外部数据源。准确性保障保障 Wiki 准确性、检索准确性、生码准确性强化验证机制。一致性保障知识库内部跨Wiki的一致性。检索性能优化在关键词召回基础上引入向量检索作为补充改进混合检索机制实现检索效率提升。知识保鲜建自动化的源材料变更检测和重新编译机制上游 DDL、任务代码、文档发生变化时主动触发对应 Wiki 的增量更新避免知识库滞后于真实业务系统。建立评测体系建自动化评测 benchmark查询准确率、召回率、答案满意度每次构建后自动跑回归让准不准有可量化的指标形成持续改进闭环。学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%免费】