构建AI时代的知识底座：LLM Wiki实践

在企业智能化转型过程中，数据团队的领域知识管理面临着严峻挑战。代码注释、配置文档、沟通记录散落在各个角落，缺乏统一的承载载体。这直接导致两个核心问题：知识质量持续退化——口口相传导致人走知识断、口径不一致引发数据矛盾、文档无人维护而逐渐过时；工程熵增失控——团队无法全局审视现有资产，重复建设不断累积数据负债。原本可以被AI极大提效的答疑、排查、代码生成等场景，都卡在了"知识喂不进去"这一关键环节。

LLM Wiki的核心设计思想

传统的RAG（检索增强生成）方案虽然应用广泛，但其本质是每次查询时从原始文档碎片中现找现拼，并未改变原始材料本身的状态。散落的依然散落，矛盾的依然矛盾，过期的依然过期。问题出在知识本身，而不在检索技术。我们需要的是在检索之前增加一道"编译过程"——将散落、矛盾、易腐化的源材料预先加工为可被AI直接消费的高质量知识单元。这正是LLM Wiki的核心理念。

构建方法论

LLM Wiki并非"用LLM写出来的文档"，而是一份结构化、有约束、可验证的知识资产。它在四个层面区别于传统文档：结构可解析——每个页面采用frontmatter与正文的双层结构，frontmatter作为脚本可解析的YAML，承载关系字段（类型、领域、上游、计算方式等），正文承载语义描述，脚本可直接读取关系信息而无需依赖LLM反复解析。层级可下钻——领域按业务主题嵌套组织形成可逐层下钻的树结构，Agent检索时可从根域渐进披露，避免一次性灌入全部上下文。关系可遍历——页面间的血缘、归属、消费、引用关系以边的形式显式记录，构成有向图，脚本可遍历、可计算影响范围、可做多跳召回。正确性可度量——分为结构、语义、人工三层校验，结构层用机械规则自动化约束，语义层用LLM评审内容准确性，关键节点由人工确认兜底。

让机器建，而非让人建

人工维护Wiki的核心痛点是成本高、腐化快、难持续。采用LLM作为编译器，把散落的源材料（DDL、任务代码、文档、接口配置）编译成结构化页面，人只在关键节点做确认。整个构建过程可抽象为六个步骤：提取→生成→归类→聚合→链接→验证——对应编译器的词法分析、代码生成、作用域解析、IR构建、链接、静态分析，本质是一条将散落源材料编译为结构化知识的流水线。 在准确性保障方面，我们建立了一整套覆盖事前、事中、事后的工程纪律。噪音过滤分入口和生成两道关口：入口阶段粗筛剔除明显过期低质量的材料，生成阶段细筛由LLM识别并跳过调试残留和过期片段。冲突裁决规则采用"代码即真相"原则——不同来源对同一对象描述不一致时，以任务代码为权威，因为注释和文档可能长期失修，但任务代码每天实际运行在生产上，代表系统当下的真实行为。生成与判断分离机制要求LLM在生成时强制留空需要推断的字段，只写有源材料直接支撑的内容，待所有基础页面生成完毕后再独立运行判断阶段。所有页面在frontmatter中保留sources字段逐项指向具体源材料，确保证据链可追溯。

知识组织架构

知识的骨架是关系。业务问题往往不是关于单张表，而是关系层面的问题——"改了这张表影响哪些下游""这个指标从哪些表算出来"。我们将关系从正文中抽出显式存储：血缘、归属、消费、引用等语义落到frontmatter字段，再由构建流水线统一扫描提取，沉淀为全局关系图。每条边都是结构化的、可遍历的、可计算的。 知识组织为检索服务，通过三个工程支点实现：知识聚合——把大量Wiki页面按主题聚合，字段聚合为指标和维度，表、接口、看板聚合为域，检索面从数百个分散页面收敛到少数几个域入口。渐进式披露——层级结构天然支持逐层下钻，从全景概览定位相关域，从域定位关键页面，从页面获取字段细节，每一层按需加载在上下文预算内传递最相关信息。多路召回——聚合和渐进式披露解决纵向定位，关系图提供第二条检索路径，命中一个节点后沿边扩展到血缘相关但关键词未命中的知识，覆盖单靠文本相似度无法触达的关联页面。

如有侵权，请联系删除。