编者按：根据云器科技联合创始人 & CTO 关涛在 2026 DACon 北京的 KeyNote 演讲分享整理，本文围绕知识表达、获取、加工与持续更新展开，结合两个实践案例及知识工程架构进行讨论。图示来自分享资料，如需获取完整版分享材料，请扫描下方二维码领取。
导言：从数据处理走向知识生产
过去，从关系数据库到大数据平台，数据技术主要解决的是将原始数据加工成信息的问题。原始日志被转换为 BI 报表，交易记录被汇总为业务指标；但报表呈现之后，数字背后的业务含义、口径差异及适用条件，仍大量依赖业务人员解释。
AI 的理解、抽取、生成与推理能力，为信息进一步组织为知识提供了新的工具。传统数据处理能够计算、聚合和展示信息，模型则使文档中的描述、交互中的经验，以及报表背后的业务含义，有机会被提取并组织起来。由此，知识不再只是数据处理后的人工解释，也开始成为需要被持续生产、校验和使用的工程对象。
DIKW 框架将数据、信息、知识和智慧区分为四个层次：数据是原始素材，信息是经过加工的数据，知识是组织化的信息，智慧则位于更高层次。沿这一框架观察，数据平台面临的任务正在从数据到信息，进一步延伸到信息到知识。
知识工程需要回答三个相互关联的问题：知识从哪里来，原始材料经过怎样的加工才能成为可用知识，以及知识应以什么形态被表达和使用。只有把获取、加工、表达与持续更新连接起来，才能形成完整的工程体系，而不是停留在一次性的材料整理或模型调用。
第一章 知识是什么 本体又是什么
💡 本章要点
本体只是知识的一种建模形态。 同一份知识可以有多种表达方式，各自具有不同的计算、检索和校验能力。
没有一种形态可以包打天下。 知识的组织方式应服从业务场景，而不是要求所有应用采用同一套模型。
数据是基础素材，知识是组织化的信息
在这一讨论框架下，数据是基础素材，信息是加工后的数据，知识则进一步组织关系、规则、口径和流程。知识可以采用多种表达形态，也可以采用不同的建模方式。本体是其中一种建模形态，而不是知识的唯一载体。
本体在企业知识场景中有两类具体应用。一类是 Semantic View：结构化数据经过加工形成关系表或报表，语义视图进一步为这些数据补充业务含义，使表中的数字能够按明确口径被理解和使用。
另一类面向文档、照片等非结构化材料。材料中的实体、属性及关联经过提取和组织，可以形成知识图谱。语义视图与知识图谱所面向的数据形态不同，但都需要表达概念及其关系。图 1 将数据、信息、知识、本体和语义放在同一概念框架中，也展示了本体作为知识表达方式的作用。
图 1 数据、信息、知识、本体与语义的概念关系
同一个事实 可以有不同的表达形态
以 Meta 历年营收为例，同一组事实可以采用不同表达方式。第一种是文本：分别描述 2021 年、2022 年和 2023 年的营收情况。这一文本示例以约一百个字节的文字表达这组信息。
第二种是关系表。相同信息被整理为年份与营收两列后，示例中的表示体积缩小到约十至二十个字节，计算也更加方便。相比自然语言描述，表格明确了字段及其对应关系，便于进行筛选、聚合和比较。
第三种是将第一种文字表达截成图片。读者看到的内容没有变化，但存储体积明显增大，也无法像关系表那样直接参与计算。同一事实改变表达形态之后，在存储、检索和计算上的能力与代价便发生了变化。
从这一例子可以进一步比较几类知识表达方式。关系表适合结构化计算；标量与倒排索引支持文本及关键词检索；向量表达通过向量索引进行空间相似度搜索；点边图则以节点及其关联组织知识，例如将企业与营收组织为相互关联的实体。
模型参数也是知识的一种表达方式：信息可以通过训练或预训练进入模型，由模型在推理时隐式调用。表格、文本、向量、图与模型参数的差别，不只是存储形式不同，也在于知识能够如何被访问、解释、计算与校验。
图 2 同一知识的不同载体及其能力与代价
模型参数具有较强的表达能力，能够承载多种信息，但逐条解释和校验知识较难，使用时还需要承担模型推理成本。关系表则具备结构清晰、计算准确、可读性较好的特点，但需要预先整理，也不适合直接承载所有形态的非结构化内容。不同载体的优势伴随不同的组织成本与使用边界。
没有一种建模形态可以包打天下
本体的价值在于显式组织概念及其关系，但这一价值并不意味着所有知识都必须转化为同一种本体模型。不同表达形态各有适用条件，不能将本体与知识本身画等号。
知识的表达应与使用方式相匹配。不同应用可能需要不同的建模形态，才能在准确性、可解释性、计算效率与灵活性之间取得合适的平衡。没有一种形态可以覆盖全部需求，多种表达方式通常需要共同存在。
第二章 业界的五类知识建模路线
💡 本章要点
已有表达规范，不等于已有统一的企业本体标准。 企业模型如何构建、运行、裁决冲突与持续维护，仍缺少统一规范。
设计目标不同，知识形态就不同。 五类方案在强保证、开放交换与表达灵活性之间，做出了不同选择。
当前，本体建模尚未形成统一标准。 RDF、OWL、SHACL 等规范已经解决了部分表达、推理与约束问题，但企业应该建模什么、模型如何运行、冲突口径如何裁决，以及知识如何持续维护，仍缺少产业共同接受的统一规范。关涛认为，五类代表性方案并不是同一标准下的不同实现，而是围绕各自的业务目标，选择了不同的知识表达、建模与运行方式。
Palantir 把知识与行动一起建模
Palantir 是全面建模的一类代表。它在前 AI 时代便已开展本体与知识建模实践，其特点不是只建立一层数据说明，而是将业务对象、知识及行动连接到同一体系。
所谓全面建模，是将企业内部的业务要素纳入模型，甚至把行动本身也建模。系统除本体知识层外，还包含行动层，通过运行引擎连接下一步业务操作。这使本体不仅描述业务，也参与业务运行。
这种形态在军工等高价值垂直场景中具有实践基础，但其可行性不意味着所有企业都应采用相同的建模深度。关涛以 Google、Meta 这类大规模用户场景作比较，指出选型问题不只是企业是否了解本体技术，还包括实施与长期维护所需的投入。
全面建模需要较高成本。Palantir 的 FDE 模式要求工程人员深入业务现场，理解流程、建立模型并连接运行系统。知识模型的建设因而不是一次简单的数据导入，而是对具体业务持续投入的过程。
在高价值场景中，这种投入可能具有合理性；面对数十亿量级用户、需要持续维护个体画像的场景时，成本结构则不同。关涛的判断是，尤其在前 AI 时代，为每个用户都构建深度本体模型，可能因成本过高而难以采用。
Palantir 展示了全面建模路线的可行性：通过属性对象式模型，可以将企业内容组织成标准化的模型，并进一步连接行动。但投入越深，对场景价值与实施能力的要求也越高。选型需要同时判断技术能否实现，以及业务是否值得承担相应投入。
图 3 Palantir Ontology 的对象、知识与行动系统
Semantic View 从结构化分析语义切入
Snowflake Semantic View 代表另一类更聚焦分析语义的路径。它将建模范围收敛到结构化数据之上，围绕表、关系、维度和指标定义业务含义，成为数据平台向知识层延伸的一个切入点。
这一方向强调分析口径的准确性与确定性。对于 Chat BI 而言，数据表解决了数据存放在哪里的问题，语义视图则进一步说明这些数据应如何解释、计算，以及以什么业务口径被使用。
Semantic View 本身聚焦结构化分析，不等同于全面的业务行动系统。正因为范围相对明确，它能够为 Data Agent、Chat BI 及企业数据分析 Agent 提供较清晰的边界，也成为相关应用落地的常见起点。
图 4 Semantic View 在结构化分析中的位置
Apache Ossie 开放交换与本体语义分层
在开放交换方向，Apache Ossie 由 OSI 演进而来。该项目由 dbt、Snowflake 等公司共同推动，关注不同工具和平台之间的语义模型交换。
与绑定特定平台的语义对象相比，这一路线首先强调开放性：在不同企业或工具的 Semantic Model 之间建立中间交换契约，使同一套业务定义有机会被不同消费方复用，而不必在每个工具中重新定义。
另一项值得关注的变化，是本体层与语义层的分离。规范包含语义定义、本体定义及两者之间的 Mapping：语义模型可以用 YAML 文件表达，Ontology 使用独立定义，再通过映射连接业务概念与底层数据语义。
分层的原因在于，底层表定义与上层业务概念不一定一一同形。企业可以只有一套底层数据定义，却在不同场景中使用多个业务概念或口径；这些概念也可能映射到同一语义定义。分别组织本体、语义与 Mapping，可以显式表达这种关系。
Palantir、Semantic View 和 Ossie 都包含明确的模型，但建模范式与运行范围不同。在关涛的比较框架中，Ossie 本体层采用事实式模型，Palantir 更侧重属性对象式模型；开放交换契约与完整业务运行系统也不应混为一谈。
图 5 Apache Ossie 的本体层、语义层与 Mapping
Genie Ontology 用混合方式组织企业知识
Databricks Genie Ontology 则代表混合组织企业知识的方向。该概念在 2026 年度 Summit 中发布，将 Ontology 纳入数据平台向知识层延伸的整体设计。
这套设计不只包含分析语义，也并非用一个模型覆盖全部内容。语义部分采用与 Metric View 相近的组织方式，同时结合图谱建模、文本文档搜索等能力，将不同形态的知识纳入混合体系。
混合方式试图扩大知识覆盖范围，并更多依靠自动化生成企业知识内容。关涛提到，这套系统当时仍较新，不少部分尚处于试运行阶段。
Snowflake 与 Databricks 的这些探索，体现了数据平台向知识组织与知识服务延伸的趋势；不同方案在覆盖范围、模型强度和自动化程度上的选择并不相同。
图 6 Genie Ontology 的混合知识组织方式
Agent Memory 自由文本也是一种有效知识形态
Agent Memory 展示了低建模成本的另一种路径。部分个人 Agent 工具使用文件式记忆保存项目约定、偏好与经验。以 Claude 系列工具为例，其记忆系统能够承载个人知识，而不要求先建立严格的概念模型。
关涛分享的个人 Memory 由一组目录与话题文件组成，话题内容根据聊天记录生成。打开某一条目，可以看到标准文本，而不是事先定义好的对象模型。目录帮助组织话题，文本保存具体背景、约定和经验。
这一例子说明，自由文本也是一种有效的知识表达形态。在个人知识复用场景中，文本式记忆能够发挥实际作用；判断知识系统是否合适，不能只看是否具有强 Schema，也需要看它服务的对象与任务。
图 7 个人 Agent Memory 的目录与文本表达
企业需要选择适合场景的组合 而不是绑定一种模型
知识存在不同表达形态，产业系统也据此形成不同设计。五类方案在模型强度、可靠性保证与表达灵活性之间做出不同选择，其差异反映了各自服务的业务范围和运行目标。
企业不必绑定某一种模型。 不同业务形态与场景，对建模深度、确定性和灵活性的要求不同，可以采用不同方式，也可以组合使用多种知识形态。
从严格建模的 Palantir，到以 Markdown 文本组织记忆的 Agent Memory，图 8 给出了不同方向的比较。系统之间的差别不只是是否使用图结构，还包括如何表达知识、如何运行，以及能为使用过程提供什么保证。
图 8 五类路线在强保证、开放性与灵活性之间的取舍
第三章 知识从哪里来
💡 本章要点
最难的知识，往往不在文档里，而在人脑里。 持续采集交互 Trace，可以让知识供给与日常工作连接起来。
已有报表与经确认的 SQL，是语义建模的切入点。 业务问题与查询事实可以共同提供反向蒸馏语义视图的证据。
最难的知识 不在文档里而在人脑里
确定知识的表达方式后，还需要反向追溯知识如何构建、如何抽取。获取原料是知识工程面临的第一个实际挑战：材料是否存在、隐含知识如何显现，都会影响后续建模的质量与成本。
仅收集一批文档，通常不足以覆盖企业知识。云器团队的实践将知识来源区分为几个层次：已经写在文档中的内容相对容易获取；没有形成文档、但沉淀在系统中的内容，可以从 BI 报表、指标定义和其他使用记录中提取。
更难获取的是人的经验与判断。 大量业务知识保存在人员头脑中，要求每个人专门把全部经验写成文档，往往难以持续。问题不仅在于写作投入，也在于部分经验只有在具体工作中才会被意识到。
人在与 Agent 交互时 已经在持续输出知识
Tracing 提供了另一条路径。人在与 Agent 交互、或与其他人协作时，会持续表达背景、规则、判断和纠正意见。这些交互可以成为知识获取的原料，而不必完全依赖额外编写文档。
例如，用户查询本月 GMV，Agent 给出 1200 万的结果。业务人员随后指出，该计算包含了退款订单，而当前口径应剔除退款。这次纠正既改变了结果，也暴露了业务人员原本掌握、却未必写成文档的指标规则。
系统识别到的，不只是把 1200 万这个数字纠正过来，而是识别到一次指标口径的纠偏。这就是一条知识。这条知识原来在人的脑子里，让他专门写文档，很难写出来；但通过日常交互，就可以获得它。
在这一思路下，文档仍是重要来源，但持续采集用户与 Agent 的交互，能够让知识供给与日常使用连接起来。关涛将其视为比单纯要求人员持续补写文档更持久的路径。
图 9 从用户纠正与交互 Trace 中发现业务知识
从已有 BI 报表 反向蒸馏语义视图
云器团队还介绍了从企业现有系统获取知识的案例，其原料不是 Agent 交互，而是已经沉淀的业务报表。企业希望建立 Semantic Layer 或 Ontology 时，首先面临的问题往往是如何启动，而不是选择什么工具。
假设企业有 1000 张表，需要为这些表建立 Semantic View，纯手工建设的难度很高：既涉及表结构，也涉及业务含义、指标口径和关系。团队在实践中发现，即使由企业内部数据开发工程师承担，也不容易兼顾效率和准确性；让模型在缺少业务证据的情况下直接生成，同样困难。
已有 BI 报表提供了反向蒸馏的切入点。 假设企业已积累数百张报表，每张报表既有标题或说明，表达业务问题，也有底层 SQL。把业务描述与 SQL 放在一起交给模型，比只提供表结构更有助于提取语义。
团队使用 TPC-H 等基础 Benchmark 中的 Verified Query，以及 MIT 校园数仓相关数据开展实验。关涛分享的实验结果显示，蒸馏生成的 Semantic View 准确度可达 90%以上；当原料中没有某个指标时，系统倾向于保留空缺，而不是自行补造。上述结果属于特定实验设置下的表现，不能视为对所有企业数据的准确率承诺。
这一实践形成了语义建模的启动方式：企业提出构建 Semantic View 的需求后，可以先提供一批已有 BI 报表及其查询，而不是立即组织人员从头编写说明。报表中同时存在业务意图与查询事实，可以反向提供语义建设的证据。
图 10 从业务问题与验证 SQL 蒸馏语义视图的案例
第四章 原始材料如何变成可用知识
💡 本章要点
Raw Data 不等于 AI-ready Data。 材料可被检索，不代表已完成知识加工；抽取、整理、合并与评估仍不可少。
知识蒸馏的重点是减少歧义与干扰。 案例中的改善来自预先明确口径与分步加工，而不是继续增加模型上下文。
Raw Data 不等于 AI-ready Data
获取材料之后，第二个挑战是知识加工。Raw Data 不等于 AI-ready Data，也不自动等于知识。 材料已经集中存放，甚至已经支持检索，并不意味着模型能够按正确口径稳定使用它们。
如果只是把所有数据放在同一个位置，再建立向量索引，完成的仍主要是原始材料的组织与召回。要形成可以可靠使用的知识，还需要明确的抽取、转换、汇总、评估和服务过程。
首先，从材料中抽取候选信息；其次，对相似内容进行转换与整理，再通过 Aggregate 完成汇总。汇总后还需要评估内容是否准确、是否有证据支持，最后才向应用提供服务。不同步骤解决的问题不同，不能全部交给回答问题时的一次模型调用。
AI-ready 意味着材料已经经过面向使用的加工，而不仅是可以被检索。缺少这些环节，模型仍需在回答时同时承担信息甄别、知识整理和任务执行，效果容易受到干扰。
图 11 从原始文档到抽取、转换、索引、评估与服务
文档已经很完整 为什么检索后的结果仍然不稳定
在与某头部内容平台的合作中，云器团队遇到的并不是资料缺失。该平台已从 BI 系统导出并整理了完整文档：前面有路由说明，告诉使用方不同业务域应阅读哪些材料；具体文档又列出指标定义和对应 Sample Query。
尽管资料已经较完整，把这些文档放入 RAG 库后直接召回，效果仍不理想。关涛提到，由于指标复杂，相关内部评估中的指标准确率只有 30%多，距离实际使用要求仍有差距。
问题并非知识不够，而是相似知识过多。 对某个概念进行检索，可能同时召回多段相近但并不完全相同的描述；如果这些内容未经整理便共同进入上下文，模型需要先判断哪一段才适用于当前问题。
同一个模型还要生成 SQL、验核报表并完成归因。当知识甄别与后续分析都集中在一次调用中，任务目标过多，注意力便容易分散，相似描述之间的差异也更难被稳定处理。
在该案例中，这表现为结果准确度波动：同一个报表、同样的 Prompt，也可能给出不同结果。材料的完整性并没有直接转化为使用的一致性。
不是再加材料 而是先把材料蒸馏成指标体系
团队据此基于现有文档建立蒸馏 Pipeline，将文档信息预先加工为 Semantic 知识。不仅 SQL 片段，文档中的指标说明与文字描述，也被进一步整理成指标体系，再供 Agent 使用。
据云器团队的内部评估，这一调整使相关题集上的准确率提升了接近一倍，同时带来另外两项变化：知识定义更明确，按正确结果衡量的 Token 使用效率改善，Token 消耗下降；执行时间也随之减少。准确率、Token 消耗与执行时间的具体结果均应限定在该次内部评估的题集和设置中理解。
图 12 内容平台业务文档蒸馏案例及本次内部评估结果
知识蒸馏是一个熵减过程
这一结果看似反直觉：加工后保留的信息更少，使用准确度却更高。关涛将知识蒸馏概括为一个“熵减过程”——减少的是重复、歧义及无关干扰，而不是简单地增加模型能够看到的材料数量。
如果将 Raw Data 直接交给 Agent 统一整理，它需要同时进行信息甄别、不同描述的挑选及后续任务处理，目标容易分散。将知识加工设为独立过程，则可以让每一步围绕更明确的目标执行。
该案例中的加工流程分为多步：信息抽取、信息整理、信息合并以及验证。各步骤分别处理具体问题，而不是在一次生成中同时完成，从而提高蒸馏结果的准确性和后续使用的一致性。
围绕知识获取与加工的挑战，云器团队进一步将相关系统实践总结为四个架构共识，分别涉及开发与生产分工、数据处理架构复用、持续评估更新，以及真实使用驱动的闭环。
第五章 知识工程的四个架构共识
💡 本章要点
开发期用 Agent 探索，生产期运行确定性管线。 分层、统一元数据与增量处理等已有数据工程机制，可以继续复用。
知识平台不是一次性交付。 真实使用产生 Trace，持续评估与更新让知识回到应用，形成可运行的闭环。
开发期用 Agent 探索 生产期运行确定性管线
第一个架构问题，是知识蒸馏应由自主 Agent 完成，还是构建预定义 Pipeline。Agent 能够在本地快速探索语料和尝试方案，但生产运行又需要明确的成本、执行路径及错误处理边界。云器团队的选择不是二选一，而是按阶段分工。
参考 Anthropic 关于有效 Agent 的讨论，团队将这一分工概括为“Agents in Dev, Artifacts in Prod ”。开发过程可以采用 Agentic 方式，在本地使用 Agent 探索材料、尝试提示词并快速迭代；生产阶段则运行经过确定的处理流程。
可以由确定性工具完成的任务，应优先使用专用代码。例如，SQL 解析可以交给 sqlglot，而不是让 Agent 反复解释 SQL 文本。模型仍处理需要语义理解的任务，但不必同时承担所有解析与流程决策。
在开发阶段或上线初期，Agent Loop 有利于快速迭代；进入 Production 后，则应将已经确定的步骤组织为标准 Pipeline。这种分工保留模型的理解能力，同时约束生产执行的不确定性。
Pipeline 可包含抽取、编译、合并和校准等过程，再进入生产运行。开发与生产并不互相排斥，而是在不同阶段采用合适的执行方式。
图 13 开发期 Agent Loop 与生产期 Pipeline 的分工
复用奖牌架构 统一处理结构化与非结构化材料
第二个共识是复用数据工程中的管线与分层架构。云器团队采用奖牌架构组织知识生产，参考图同时展示了 Databricks、Snowflake 面向数据与 AI 的相关处理方式。
结构化数据管线通常分为三层：Raw Data 对应铜牌层，可以类比国内常说的 ODS 层；银牌层承担进一步加工，可类比 DWD 层；金牌层则面向消费和应用。结构化 SQL 是这些转换过程中的主要处理工具。
非结构化数据也可以采用相近的分层方式，但输入变成文档、视频和音频，最初保存在 Volume 等存储体系中。处理引擎不再只有 SQL，还需要文档 AI 等能力，逐层完成抽取、转换和整理。
两类管线的输入和处理算子不同，但可以复用同一套知识生产基础架构。这套架构的特点可以归纳为四项。
第一，采用标准的三层结构，兼顾原料保留与面向应用的确定性。
第二，统一元数据；这种统一不仅发生在非结构化内容内部，也连接结构化与非结构化两类处理。知识蒸馏的重要过程之一，是从非结构化材料形成结构化知识，元数据需要贯穿其间。
第三，在 SQL 引擎之外引入 AI 处理引擎，让模型能力成为管线中的处理环节。
第四，持续以增量方式运行，而不是一次全量加工后结束。企业知识随材料和业务变化而更新，管线也需要保持相应的更新能力。
图 14 以 Bronze、Silver、Gold 分层组织知识加工管线
知识平台不是一次性交付 评估与更新更重要
第三个共识是，知识平台不能被视为一次性交付的项目。 关涛提到一种常见建设思路：企业先立项建立知识平台，等平台完成之后，再以此支撑 Agent。问题在于，脱离真实应用，很难判断知识平台应提供什么知识，以及这些知识是否真正有效。
“先完成知识平台，Agent 自然就能做好”的顺序未必成立。知识平台与 Agent 需要共同迭代，实际任务及其反馈才能持续暴露知识缺口、口径错误和使用边界。
知识质量也很难通过一次评估，就被证明为百分之百准确。作为对照，TDD（Test-Driven Development）以测试集约束程序行为，程序通过相应测试后再上线；但涉及业务知识和模型输出时，验证对象还会持续变化。
知识与背后的 AI 能力都是动态的，难以依靠一次构建后就完整不变的 Golden 集覆盖长期使用。关涛认为，这类系统更需要 EDD，即评估驱动开发：持续评估结果，并在材料、模型和业务发生变化后重新检验。
即使知识平台当前表现良好，半年后也可能已有部分知识不再适用。个人知识系统中保存的住址就是一个简单例子：人员搬家后，原先正确的记录便成为过期知识。企业指标、规则和流程也存在类似的变化。
因此，一次性交付不应成为建设完成的判断标准。比追求首版覆盖所有知识更重要的，是持续评估、发现变化、更新内容并检验更新效果的能力。当前有效，并不意味着以后可以不再维护。
图 15 评估驱动与持续更新的知识生产机制
从真实使用出发 让知识闭环转起来
第四个共识关注知识闭环从哪里启动。关涛将 Agent 的实际使用情况视为重要前提：如果应用已经进入真实任务，就能持续提供交互和反馈；如果缺少应用使用，知识平台很难仅靠一次建设形成持续迭代。
这个 Loop 的起点是人使用 Agent， 更高阶的情况是 Agent 自己迭代。一旦有了真实使用，就可以采集 Agent Trace。Trace 是知识很好的养料。
得到 Trace 之后，就可以做知识蒸馏，形成评估验证集，最终经过验证入库。验证可以有人参与，也可以自动化。入库后，知识又可以给 Agent 使用；Agent 使用之后，再产生新的 Trace，闭环就形成了。
人与 Agent 交互越多，可供提取与验证的知识线索也越多。以 Data Agent 辅助建表为例，用户提出创建新表，并说明它的上游依赖；Agent 完成任务时，这段交互 Trace 也可被采集和蒸馏，成为后续知识的一部分。
在这一思路下，知识“保鲜”的关键不是单独追加一项定期整理工作，而是让真实使用、Trace 采集、蒸馏与验证持续运行。云器团队基于上述四个共识构建了相关系统，并以参考架构说明这些环节如何连接。
图 16 使用、Trace、蒸馏、评估、入库与服务组成的 Eco-loop
第六章 从数据平台演进为知识工程平台
💡 本章要点
知识平台是数据平台的演进，而不是另起炉灶。 湖仓、计算引擎与增量处理，继续作为知识工程的数据底座。
加工、观测与知识服务需要连接起来。 AI-ETL、SingSight 和知识模块分别承接加工、Trace 与评估、知识组织与服务。
湖仓与增量计算构成数据底座
云器科技的相关实践以多云、云中立的数据平台为基础。湖仓存储、开放数据格式、计算引擎及增量处理能力，共同构成知识工程平台所复用的数据底座。
第一，以 Lakehouse 湖仓作为底座，好处是可以把非结构化数据和结构化数据存在一起。
第二，以 Apache Iceberg 作为开放核心，使数据不被锁定，能够被不同引擎消费。
第三，计算引擎为数据加工提供性能基础。关涛在分享中介绍过相较开源 Spark 的十倍性能优势，详情请参考以下报告：
第四，通用增量计算将流、批和交互处理纳入同一计算范式。具体客户实践请参考：
最后，云器 AI Lakehouse 是一个多云的数据平台。以上是原有数据平台的部分，也是后续知识工程的基础。
图 17 云器 AI Lakehouse 的数据底座与计算能力
V2 把加工、可观测与知识工程连接起来
在知识工程的架构演进中，原有数据平台被定义为 V1 底座，V2 则在其基础上增加知识生产、观测与服务能力，而不是另行建立一套完全独立的数据体系。
V2 连接三个核心部分：AI-ETL 提供具有 AI 能力的 ETL 管线；SingSight 承担 Agent 日志采集、可观测与评估；知识工程及蒸馏模块则组织加工后的知识。Agent 使用产生的交互信息，由此能够进入后续知识生产流程。
图 18 云器 V2 架构中的 AI-ETL、SingSight 与知识工程
结构化数据与 Agent 日志进入同一套处理体系
参考架构图中，绿色部分是结构化数据处理：有结构化表，通过 Single-Engine 生成动态表，再由 BI 消费。
黄色部分是新增部分。数据源里除了原有数据和非结构化材料，还有 Agent 日志。采集过来之后，先放在 Volume 这样的非结构化存储中心。再通过 AI-ETL Pipeline，把这些数据加工成知识，最终向不同 Agent 提供服务。
图 19 从数据平台到 AI 知识平台的整体处理架构
在原始证据上 同时蒸馏语义与 Skill
云器团队参考 CoALA 架构，将企业知识组织为三类相互关联的内容：原始情景证据（Episodic），以及在原始证据基础上进一步形成的语义知识与程序性知识。语义知识侧重业务概念、关系和含义，可通过 Semantic 或 Ontology 等方式表达。
程序性知识对应 Procedural，强调流程、规则与工具使用方式，可以通过 Skill 等形式被 Agent 复用。相同的原始材料既可以支持语义或本体知识蒸馏，也可以用于提取可复用的 Skill； 两类产物服务于不同的使用需求。
图 20 原始情景证据、语义知识与程序性知识的组织
这样就形成一个闭环：底下有 AI-ETL 基础能力，构建加工管线；通过 SingSight 把日志信息取上来；通过知识蒸馏得到企业知识，再反馈给 Agent，形成 Loop。这组成了云器 V2 的整体架构。
图 21 AI-ETL、SingSight 与知识工程对闭环的支撑
结语 知识需要一个完整的生产体系
从信息到知识，意味着数据平台的处理对象与服务目标继续延伸。关涛将其概括为数据平台的第三次革命，但这一方向并不对应唯一的表达方式：知识可以采用多种形态，不同业务场景也需要不同的建模选择。
Raw Data 不等于 AI-ready Data。知识需要经过生产过程，才能从分散的材料、规则与经验，转化为可供应用可靠使用的资产。知识工程或知识蒸馏所关注的，正是这一过程如何被系统化组织。
要构建完整体系，不能只有一条蒸馏 Pipeline，还需要整体的工程体系：从日志，到管线，再到知识表达。知识来源、加工过程、评估更新和应用使用，必须被连在一起。
获取完整演讲资料
完整演讲 PPT 保留了五类路线的比较、实验图示和知识工程架构。请扫描下方二维码领取本次分享的完整演讲 PPT，结合本文进一步阅读。
观看完整演讲
🎁 新用户专享福利
✅ 1 TB 存储 · 1 CRU时/天计算 · 1 年全托管体验
➤ 即刻访问云器官网领取：https://www.yunqi.tech/product/one-year-package
