数字化转型浪潮下，企业IT运维正在经历一场深刻变革。传统的"救火式"运维模式已难以应对日益复杂的IT环境，AI驱动的智能运维（AIOps）正成为企业IT管理的新范式。 一、传统运维的困境 过去十年，企业IT环境发生了翻天覆地的变化： 系统复杂度激增：微服务架构、容器化部署、混合云环境让系统拓扑变得极其复杂 数据量爆炸：监控指标、日志数据、告警信息每天以TB级增长 响应压力剧增：用户对系统可用性的期望从"99%"提升至"99.99%" 传统运维团队面临的核心挑战是：如何在海量数据中快速定位问题根源，并实现主动预防而非被动响应？ 二、AIOps的核心能力 AIOps（Artificial Intelligence for IT Operations）通过机器学习、大数据分析和自动化技术，为运维带来三大核心能力： 1. 智能异常检测 传统阈值告警存在两大问题：阈值设置依赖经验，且难以适应动态变化的业务场景。AI驱动的异常检测能够： 自动学习系统正常行为模式 实时识别偏离基准的异常信号 降低误报率，提升告警精准度 某大型电商平台实施AIOps后，告警数量减少70%，有效告警比例从15%提升至85%。 2. 根因定位自动化 当系统出现故障时，运维人员往往需要在数十个甚至上百个组件中排查。AI能够： 自动关联分析日志、指标、变更记录 构建因果推理模型，快速定位故障源头 生成修复建议，加速问题解决 实际案例显示，AIOps将平均故障定位时间（MTTD）从30分钟缩短至5分钟。 3. 预测与预防 这是AIOps最具价值的场景——从"事后补救"转向"事前预防"： 预测资源容量瓶颈，提前扩容 识别性能下降趋势，主动干预 分析历史故障模式，推荐预防措施 一家金融服务公司通过AI预测模型，在CPU负载达到阈值前24小时发出预警，避免了数次潜在的系统崩溃。 三、实施路径与实践建议 第一步：数据整合 AIOps的基础是高质量的数据。企业需要： 统一监控平台，整合日志、指标、追踪数据 建立数据治理规范，确保数据质量 构建事件关联图谱，打通数据孤岛 第二步：场景切入 不要试图一步到位。建议从以下场景切入： 场景 预期收益 实施难度 告警降噪 告警减少50-70% 低 异常检测 误报降低60% 中 根因分析 定位时间缩短80% 中高 预测预防 故障减少30% 高 第三步：团队转型 技术变革需要组织变革配合： 运维人员技能升级：从脚本编写到数据分析 跨团队协作机制：DevOps与AIOps团队深度融合 决策流程优化：建立AI辅助决策的信任机制 四、挑战与应对 AIOps实施并非一帆风顺，常见挑战包括： 数据质量问题 问题：数据缺失、格式不一致、噪声干扰影响AI模型效果。 应对：投入数据清洗和标准化工作，建立数据质量监控机制。 人才缺口 问题：同时懂运维和数据科学的复合型人才稀缺。 应对：内部培养与外部引进结合，建立学习型组织文化。 组织阻力 问题：运维团队对AI决策的信任度不足，担心自动化带来的风险。 应对：从小场景开始验证效果，逐步建立信任；保留人工干预机制作为安全网。 五、展望：智能运维的未来 2026年，AIOps正在从"辅助工具"演进为"核心能力"。未来趋势包括： 自愈系统：AI不仅发现问题，还能自动执行修复 运维大模型：基于LLM的运维助手，提供自然语言交互 边缘智能运维：将AI能力下沉到边缘节点，实现分布式运维 对于CIO和IT管理者而言，AIOps已不再是选择题，而是必答题。那些能够率先实现智能运维转型的企业，将在数字化竞争中占据先机。 结语 从被动响应到主动预防，AI正在重塑IT运维的本质。这不仅是技术的升级，更是运维思维的根本转变。 当AI能够提前预警潜在故障，当系统具备自愈能力，当运维团队从"救火队员"转型为"预防专家"——这才是数字化运维应有的样子。 行动起来吧，让AI成为你运维转型的加速器。 来源（公众号）：IT管理知识库
编者按：今年政府工作报告首次提出“打造智能经济新形态”，并指出要深化数据资源开发利用，健全数据要素基础制度，建设高质量数据集。为探索工业数据“采”“集”“用”有效路径，工业和信息化部近日印发通知，启动工业数据筑基行动，开展面向人工智能赋能的高质量行业数据集建设先行先试，业界反应热烈。安徽省工业和信息化厅二级巡视员、安徽省新经济联合会会长潘峰特为本报撰写文章，就高质量数据集建设路径展开讨论。 在“人工智能+”行动深入推进的时代背景下，高质量数据集已成为驱动产业智能化转型、培育新质生产力的核心要素。其价值不仅在于数据本身的精准性与标准化，更在于通过集群化效应实现从单点突破到面状发展的跨越式赋能。如何构建可持续、可推广、可落地的高质量数据集发展体系，推动高质量数据集建设收获“规模红利”，并向“质量红利”“生态红利”跃递？笔者在此提出“三二一”思路，希望能为这项创新性工作做些抛砖引玉的尝试。 坚持三个导向 所谓“三”，是指坚持问题导向、价值导向、市场导向这三个导向，以期锚定高质量数据集解决实际问题、创造核心价值、实现持续运转的生命根基。 问题导向是高质量数据集的立身之本。数据集的成功，关键就在于精准切入全产业链发展中的痛点，有针对性地解决生产决策、供需对接、研发制造过程中的难点问题。合肥的杰士杰公司是一家生产改性工程塑料和高分子复合材料的公司，在企业发展过程中，一个难题就是，客户越来越多，需求品种已经超过了5000种，每一个品种的配方都要千百次地研发尝试，科研成本效率亟待提升。后来公司找到芜湖智唐科技公司，该公司直面这个棘手问题，从相关数据搜集、清洗、统一标准、标注等开始，建立起高质量数据集，然后用高质量数据集“喂”出相应的工业模型，最终打造出工业智能体，一举解决了这个问题。现在，相应的产品配方都是AI自动生成的了，研发效率提升80%以上，大大节约了科研成本。杰士杰公司对此成就感到惊喜，立刻又着手和智唐公司合作解决其他棘手问题，目前已打造出三个智能体，全面提升了企业效率。这个案例让我们充分认识到，只有聚焦企业的难点、痛点问题，所构建的高质量数据集才能体现出价值，使之真正成为企业降本增效的“利器”，这也是人工智能赋能新型工业化的核心逻辑。问题导向下的数据集建设，拒绝“为建而建”的形式主义，坚持“有用才建”的务实原则，让数据真正成为破解产业发展瓶颈的“金钥匙”。 价值导向是高质量数据集的推广之要。我们今天有声有色地开展高质量数据集建设，是为了让更多的企业从中受益，最大程度地摊开价值之饼。如何做到呢？就是要从成功的个性案例中萃取出共性的东西来，然后用这个共性的东西，为更多的企业送去福音。第一步，基于个性化的共性萃取。笔者在此提出“因式分解+取最大公约数+共性模型化处理”的方法。“因式分解”，就是把解决企业问题的数据集细分成若干单元因子。“取最大公约数”，就是把解决同一类问题（不同案例）的相同单元因子取出来。“共性模型化处理”，就是把同一类问题带有共性的单元因子处理成模型单元。第二步，借助共性化模型单元，结合企业具体情况，加以微调处理，形成众多不同企业的个性化解决方案。这样，就可以实现从单点应用到批量赋能的辐射效应，实现高质量数据集建设的价值更大化，实现解决一类问题，带动一片产业。合肥的零壹数智公司正在这方面进行积极探索，并取得一定的成效，在为阳光电源、雅迪这样的大公司建设高质量数据集的过程中，已经形成若干共性的模型单元，这让它们有条件为更多的企业高效地送去AI赋能服务。 市场导向是高质量数据集的续航之基，旨在通过市场化运作逻辑实现可持续发展。数据采集、治理、标注、更新等数据全生命周期环节均需持续投入，单纯依靠政策扶持或公益投入难以长久。市场导向下的高质量数据集建设，不仅要考虑技术可行性，更要设计清晰的价值变现路径，通过数据产品、技术服务、授权使用等多元模式，让数据要素在流通中实现价值增值，为数据集的持续迭代提供不竭动力。杰士杰公司和智唐公司就有意把他们基于高质量数据集建设起来的三个智能体剥离出来，成立新的AI赋能公司，以一种新的业态开展普适性的服务。在这项崭新的数字技术实践过程中，我们希望能有更多的新模式、新业态与之匹配。 尝试两条路径 所谓“二”，是指“可解耦”和“不可解耦”两条路径，以期破解高质量数据集的推广难题。 当前高质量数据集建设面临的最大难题就是共享与隐私之间形成的矛盾。龙头企业走出了高质量数据集建设之路，但是出于对企业隐私的顾虑，多数企业不愿意把自己的数据集拿出来共享。怎么解决？笔者提出可解耦与不可解耦两条路径并行发展之策，以期既兼顾中小企业的共享需求，又尊重龙头企业的隐私诉求，实现“普惠性”与“特殊性”的有机统一。 可解耦路径，主要是针对产业集群的共性需求，通过数据共享构建“普惠型”高质量数据集。在中小企业密集的产业集群中，单一企业的数据规模小、覆盖面窄，难以形成高质量数据集，但众多企业的共性问题为数据共享提供了基础。通过行业联盟或第三方平台组织，引导企业贡献非涉密的共性数据，经过标准化治理，形成可剥离、可共享的数据集，能够有效降低中小企业的智能化转型成本。中国农业科学院构建的企业典型作业场景多模态数据集，正是通过“申请-授权”的共享机制，整合多家生产单位的作业数据，支撑AI算法研发与智能装备创制，帮助相关企业节省劳动力10%以上。这种路径的核心价值在于“聚沙成塔”，让中小企业无须单独投入高昂成本，即可享受高质量数据集的赋能，同时通过数据共享进一步丰富数据集的多样性与完整性，形成“共享-赋能-共赢”的良性生态。我们今天已经建成许多产业集群，完全可以针对不同细分行业的共性生产问题，构建起跨企业的可解耦数据集，推动整个产业集群的智能化水平提升。 不可解耦路径，立足龙头企业的隐私保护与生态引领，通过“数据集+大模型+生态”模式实现“辐射型”赋能。龙头企业往往拥有海量高价值数据，但这些数据涉及商业秘密或核心技术，难以直接共享。对此，可以鼓励龙头企业依托自身数据资源构建私有高质量数据集，训练行业专用大模型与智能体，通过生态合作的方式，带动上下游企业发展。西门子与微软联合推出的工业元宇宙计划，正是依托西门子的工业全生命周期数据构建专有数据集，通过大模型赋能生态合作伙伴的生产优化与创新研发。国内医疗领域的龙头医院联合科研机构构建的专病病例库，虽未直接开放原始数据，但通过模型输出诊断辅助方案、科研分析结果等方式，赋能基层医疗机构与相关企业，实现了“数据不流出、价值流出去”的效果。这种路径既保障了龙头企业的数据安全，又发挥了其技术与资源优势，通过带动100家、200家生态企业共同发展，形成产业生态的“领头雁”效应，同样是高质量数据集集群化赋能的重要实现方式。 打造一个联合体 所谓“一”，是指打造一个联合体，以期凝聚起高质量数据集的建设合力。 高质量数据集建设涉及数据采集、治理、标注、应用等多个环节，跨越政府、企业、科研机构等多个主体，单靠任何一方都难以完成系统性建设，构建“政产学研金服用”联合体是破解协同难题的关键。联合体的核心价值在于整合各方优势，形成“数据资源+技术研发+场景应用+政策保障”的闭环体系。政府部门发挥政策引导与资源协调作用，通过出台扶持政策、制定行业标准、搭建公共平台等方式营造良好环境。研究机构则聚焦核心技术攻关，突破智能标注、数据安全流通、质量评估等关键技术，为数据集建设提供方法论与工具支撑。制造企业、数字化企业、软件企业，包括金融单位、相关服务单位等作为关联主体，既是数据集的使用者，也是数据资源的提供者与应用场景的贡献者，从各自角度为数据集建设提供支撑保障。在联合体机制下，各方通过联合攻关、成果共享、风险共担，能够有效破解“数据孤岛”、技术壁垒、标准不一等突出问题。例如，针对工业高质量数据集建设中存在的标准缺失问题，可由政府主导、科研机构牵头、企业参与，共同制定数据采集、标注、质量评估等系列标准；针对数据安全流通难题，可通过联合体共同研发隐私计算、区块链等技术方案，在保障安全的前提下，促进数据要素流动。最终，依托联合体构建的高质量数据集，能够形成“数据集-大模型-工业智能体”的技术链条，针对具体产业问题实现精准赋能，让数据要素的价值在协同创新中充分释放。 高质量数据集的建设不是孤立的技术工程，而是关乎产业升级、生态协同、可持续发展的系统工程。“三个导向”明确建设的价值逻辑，确保数据集“有用、能用、好用”；“两条路径”破解共享与隐私的矛盾，实现不同主体的差异化赋能；“一个联合体”凝聚了多方合力，为建设工作提供了组织保障。三者相互支撑、有机统一，可以共同构成高质量数据集从建设到应用、从单点到集群、从短期突破到长期发展的完整路径。 来源（公众号）：CDO之家
我最近有两个特别反感的地方。第一，人们把语义学中一些众所周知的技术，改名为“语境”，然后宣称整个话题是全新的，好像人工智能刚刚创造出来似的。第二，专家们讲解元数据、语义学、分类学、本体论、知识图谱和语境时，一个例子都不举，结果反而让听众更加困惑。 在我的职业生涯中，我目睹了所谓的“护城河”在整个技术栈中不断摇摆。早期，存储数据的供应商（关系型数据库供应商）掌握着主导权。后来，护城河转移到了应用层（ERP系统），再到API网关，最终到达了BI工具。最近，基础架构模型公司也开始声称拥有同样的地位。 现在，整个技术栈的供应商都围绕着“上下文层”重新定位，声称上下文是重心，将解决概率模型和代理对企业数据缺乏真正了解的缺陷。 在这篇文章中，我将用具体的例子来阐释上下文概念背后的原理，这也是我希望更多人能做到的。最后，我会分享自己关于如何构建上下文层的看法。 为什么是现在？ 过去两年发生的四件事使得一个由来已久的争论突然变得迫在眉睫。 首先，自主代理出现了。它们代表我们读取文档、编写代码、提交工单和调用API，取代了以往软件仅提供信息的功能。 其次，出错的代价也随之增加。如果仪表盘上“收入”的定义模糊不清，首席财务官就会感到恼火。同样定义模糊的代理人可能会基于错误的数字发放退款、发送电子邮件或提交合规报告。 第三，技术终于成熟了。LLM（大型语言模型）能够从非结构化文本中提取实体和关系，图数据库已经成熟，OSI、MCP、Delta Share和Iceberg REST 目录等标准正在快速融合。非结构化数据现在可以像结构化数据一样发挥作用了。 第四，数据消费者发生了变化。过去，人类每天只进行少量查询，可以通过判断和对话来接受缓慢或不一致的答案。而智能代理发出的查询数量级要多得多，它们既不具备判断力，也不具备沟通能力。 当人们从三份不同的报告中得到三个不同的收入数据时，我们会通过对话来调和这些不一致之处，从而容忍这种混乱。但一旦消费者成为代理人，同样的混乱就会演变成运营风险。如果我们现在不解决语义问题，人工智能不仅无法解决我们的一致性问题，反而会加剧这个问题。 常见问题解答 供应商经常把元数据、语义、分类、本体、知识图谱和上下文等术语混用。买家不知道该问什么，而中间的架构师则不得不负责翻译。但这六个术语并非相互竞争的概念，它们构成了一个技术栈。每一层都负责特定的任务，缺一不可。正是这个技术栈区分了会产生幻觉的人工智能代理和不会产生幻觉的人工智能代理。 这篇文章是我在任何关于架构的讨论深入之前都需要向别人提供的常见问题解答。为了使内容更具体，我举了两个例子：我最近购买的MacBook Air，以及一位客服人员正在处理的一个零件缺陷投诉。这两个例子几乎出现在每个答案中。 1.元数据、语义、分类、本体、知识图谱和上下文的定义是什么？ 2. 它们之间有什么关系？ 3. 语义层物理上位于哪里？ 4. OSI（开放语义交换）等标准的作用是什么？ 5. 上下文层是如何构建和持久化的？ 1. 这些定义是什么？ 随着这些话题从学术会议上的趣味话题转变为首席数据官（CDO）的优先事项，定义是第一步。抽象的定义容易被遗忘，但举例子能让它们变得具体。 (1)元数据 元数据是关于数据的数据。例如，MacBook Air 出厂时带有序列号、型号标识符、生产日期、原产国、保修起始日期、订单号和发货时间戳。这些信息都不是笔记本电脑本身，而是对笔记本电脑的描述。 在笔记本电脑内部，每个文件都会被赋予元数据：创建日期、修改日期、所有者、权限和 MIME 类型。元数据使资产可查找、可管理且值得信赖。它是其他所有层级赖以生存的基础。 元数据进一步分为技术元数据、操作元数据、社交元数据和业务元数据： 技术元数据就是我们过去所说的数据字典：表格的结构，包括列名、数据类型和长度等。 操作元数据描述动态数据：新鲜度、上次刷新时间、管道运行持续时间、错误计数、查询延迟。 社交元数据是用户贡献的隐性知识：管理者的认可、评分、评论以及诸如有多少仪表板使用该表格之类的信号。 业务元数据描述了资产对组织的意义。名为 cust_addr_st 的列本身没有任何意义，直到它被定义为“这是客户所在的州，美国两位字母邮政编码，取自 ISO 3166-2:US 列表”。 这就是我们从元数据过渡到语义的地方。 (2)语义 语义是指赋予数据的意义。例如，列中的字符串“M5 MacBook Air”只有在经过编码后才能被理解为一台笔记本电脑，它指的是苹果公司的某个特定产品线。语义的作用在于将符号转化为事物：它告诉我们一行代表一个客户，一列代表一个价格，一个值代表一种货币，一个代码代表一个国家。 语义涵盖了围绕资产建立意义的一切要素，包括： 定义：商业术语的精确且共同的含义。“活跃客户”是指在过去 90 天内至少进行过一次交易的客户。“流失客户”不包括已暂停的账户，但包括降级到免费套餐的客户。 指标和关键绩效指标：数字的计算方式。“月度经常性收入”是指月末有效订阅价值的总和，不包括一次性费用和按比例计算的金额。每个指标要么只有一个标准定义，要么没有标准定义。 业务规则：政策和计算方法的适用范围。佣金仅适用于超过 10,000 美元的交易。30 天内的退款不计入销售配额。新客户价格仅适用于前 90 天。 层级结构和分类：概念如何层层递进。产品归类，客户细分，交易分阶段。这就是分类体系的运作方式。 语义是商业智能工具、分析师以及日益普及的人工智能代理在利用数据之前必须掌握的关键信息。没有语义，所有用户都只能靠猜测，从而导致结果不一致。 (3)分类 分类法是一种层级式分类，它将概念组织成父子关系。我的 MacBook Air 就位于任何电商网站都会使用的分类体系中：电子产品 → 电脑 → 笔记本电脑 → 苹果 → MacBook → MacBook Air → 13 英寸 → M5。每一层级都缩小了范围。正是有了分类法，你才能在不列举所有型号的情况下，简单地查询“显示所有笔记本电脑”。 企业在各个方面都依赖分类体系。产品归类，客户细分，交易流程分阶段，员工组织架构，行业分类（例如北美行业分类系统 (NAICS) 或全球行业分类系统 (GICS)）等标准，采购支出分类（例如联合国系统分类标准 (UNSPSC)），医疗诊断分类（例如国际疾病分类第十版 (ICD-10)）。每一种分类体系都构成一个父子树，并且都能帮助我们解答汇总问题。 同一资产通常同时属于多个分类体系。例如，我的 MacBook Air 就同时属于产品目录分类体系（笔记本电脑类）、支持分类体系（苹果硬件类）、监管分类体系（锂离子电池设备类）和会计分类体系（资本设备类）。大多数企业都有多个分类体系，每个体系都由不同的团队负责管理。 分类法无法描述 MacBook Air 运行 macOS 系统、与 iPhone 共享 iCloud 账户，或者与 AirPods 是同一订单购买的。这些都是关联关系，而非分类。一旦你需要描述关联关系，你就已经从分类法跨入了本体论的范畴。 (4)本体论 本体论是对实体、实体属性以及实体间关系的正式模型。分类法告诉你 MacBook Air是一种笔记本电脑，而本体论则告诉你 MacBook Air配备M5 芯片、预装macOS 系统、由客户拥有、通过订单销售，并且享有保修服务。名词是实体；连接实体的动词是关系。该模型同时编码了实体和关系。 本体由三个部分构成： 实体（正式名称为类）。领域中存在的事物。例如：客户、产品、订单、地址、保修、账户。 属性。每个实体所具有的特性。客户有姓名和电子邮件地址。产品有 SKU、价格和芯片代数。订单有日期和总金额。 关系。实体之间的法律联系。客户下订单。订单包含一件或多件产品。产品享有特定期限的保修服务。 分类法只提供层级结构。本体论则添加了属性和关系，并使这三者都可被机器读取。 本体是用RDFS和OWL等形式化语言编写的，这样软件不仅可以显示本体，还能对其进行推理。大多数领域已经存在行业标准本体：Schema.org为开放网络提供共享词汇表；FIBO为金融领域提供共享词汇表；SNOMED CT为临床医学领域提供共享词汇表；GS1则为全球供应链中的产品标识符提供标准化。 本体让机器能够推理意义，但它本身仍然只是一个模型。它定义了可能存在的事物、事物之间的关联以及可以推断出的信息。要回答一个实际的问题，你需要用真实的客户、真实的订单和真实的MacBook Air数据来填充它。填充后的版本就是知识图谱。 (5)知识图谱 知识图谱是本体与真实数据结合的产物。本体描述“每个客户都有订单，并且居住在某个地址”。知识图谱则描述“Sanjeev Mohan，账号 12345，于 2026 年 5 月 17 日下了订单号为 99887 的订单，购买了一台 MacBook Air（序列号 C02XYZ123），发货地址为 Main Street 123 号，并搭配了一部 iPhone（序列号 F2L456789），符合 AppleCare 服务计划 AP-2026-0517 的资格”。本体是模式，知识图谱则是填充了数据且可查询的该模式实例。 关于术语的说明：这种基于本体的视图描述的是一个RDF知识图谱。另一种常见的风格是带标签的属性图，它存储相同的节点、边和属性，但不需要正式的本体。我描述的是基于本体的这种类型，其中图是模型的填充实例。 知识图谱由三个结构要素构成： 节点。实际的实体。我的MacBook Air。我的Apple ID。我下的订单。 边。它们之间的实际关系。这台 MacBook Air 由这位顾客购买。此订单已发货至此地址。此 AppleCare 服务计划涵盖此序列号。 属性。节点和边所附加的属性。MacBook Air 节点包含序列号和芯片代数。“购买者”边包含购买日期和购买渠道。 其杀手锏功能在于多跳推理。SQL 几乎无法表达“查找所有与 30 天内退回同一型号商品的客户地址相同的客户”这样的需求，而知识图谱则能轻松实现。 具体到人工智能领域，GraphRAG 通过知识图谱构建检索流程，使智能体不仅能看到相关文档，还能看到围绕该文档的关联实体网络。这正是背诵型智能体和推理型智能体之间的区别。 在上面的例子中，知识图谱捕捉到了交易的所有信息：谁、什么、何时、何地以及如何进行。但它没有捕捉到我为什么选择这台 MacBook Air。这些决定存在于完全不同的信息库中。例如我的网络搜索记录、我之前提交的关于旧笔记本电脑的支持工单，以及我和家人的对话。将所有这些信息整合起来，针对特定时刻和特定用户，这就是我们所说的“上下文”。 (6)语境 上下文是凌驾于一切之上的情境感知。它连接各种记录系统，使客服人员不仅能够推断发生了什么，还能推断为什么会发生。关于客户交易的上下文可能存在于 Confluence 页面、查询日志、Slack 消息、电子邮件、Web 日志和产品文档中。 请注意，其中一些信号是实时信号，而非历史信号。上下文信息并非仅仅由存储的数据构成，它需要实时数据流。IBM于 2026 年斥资110 亿美元收购Confluent，其明确目标是“将实时数据打造为企业人工智能和智能体的引擎”，这正体现了这一点。如果没有上下文层下方的流式基础设施，你始终只能使用昨天的数据。 以客户支持为例。一位客户来电咨询MacBook Air键盘故障。客服人员掌握着结构化的记录：购买历史、保修状态、之前的工单。这部分比较容易处理，占比仅为10%。真正决定结果的上下文信息存在于数据库之外： 零件文档PDF文件，描述了特定生产批次中已知的缺陷模式。 网络服务器日志显示，该客户本周访问故障排除页面七次。 顾客在推特上公开批评了该品牌。 支持搜索栏的查询日志显示，他们在两天内输入了三次“退货政策”。 上周，一位现场工程师诊断出另一位客户的机器存在同样的缺陷，以下是与该工程师的电子邮件往来记录。 这些信息并非集中存在于某个地方，而且只有经过整合才能发挥作用。上下文正是将这些信号整合在一起的运行时行为。如果没有上下文层，智能体拥有数据，却无法做出判断。有了上下文层，智能体每次都能将意义、历史、意图和策略整合在一起进行推理。如果语义层提供词汇，知识图谱提供事实，那么上下文层则提供当下情境。 如果你听信硅谷风投的说法，上下文或许会成为下一个万亿美元的商机。但批评者认为，它不过是一个由来已久的知识工程难题，本体论专家们一直在努力解决。就目前而言，它看起来像是一个理论概念，之前的尝试屡屡失败。不过是旧瓶装新酒罢了。 2. 它们之间有什么关系？ 它们是堆叠结构中的层级，而非竞争关系。定义部分按照含义递增的顺序逐一讲解；而堆叠结构则按照相互依赖关系排列。 图 1：人工智能与自信满满的错误答案之间的屏障。 从下往上： 底层是物理数据：数据仓库、湖屋、操作数据库、文档库、消息队列、日志文件。元数据位于这一层之上，用于描述每一项资产。 上一层是本体，即意义的形式化模型。它定义了什么是顾客，产品有哪些属性，以及它们之间有哪些合法关系。分类体系存在于本体内部，是分类方案的层级骨架。 知识图谱使用真实的实体和关系来实例化本体。它是模型的填充版本，可以进行查询：是企业的持久上下文。 语义层位于所有这些之上，作为受监管的业务契约。它是语义的部署：指标、KPI、业务规则和计算逻辑。它提供的API会显示“本季度活跃客户数 = 12,847，以下是具体的统计方法”。它基于相同的定义为BI工具、分析师和AI代理提供服务。 最上面一层是上下文层：运行时程序集从下面的每一层提取正确的切片，加上用户身份、会话状态、最近的操作和适用的策略，并在做出决定时将其交给人类用户或自主代理。 将我的 MacBook Air 逐层分析，就能明白每一层的重要性。元数据层提供序列号和保修到期日。本体层定义了什么是笔记本电脑，以及它包含电池、芯片和保修。知识图谱层记录了我的笔记本电脑序列号为 C02XYZ123 并已关联到我的 Apple ID 等信息。语义层解释了“符合免费更换电池条件”的计算方式：保修有效且电池循环次数超过 1000 次且之前未更换过电池。上下文层在我发起支持聊天时，会将所有这些信息，包括我最近的搜索记录和技术人员的角色信息整合起来，并打包发送给回复我的客服人员。 跳过任何一层，系统都会不出所料地崩溃。没有元数据，就找不到任何信息。没有本体，每个人对“客户”的定义都不一样。没有知识图谱，你可以回答“卖了什么”，但回答不了“哪些东西和哪些东西关联”。没有语义层，每个仪表盘都会互相干扰。没有上下文层，代理拥有数据，却没有判断力。 下图显示了嵌入了我的 MacBook 示例的堆栈。 图 2：一台笔记本电脑从序列号到实际提供帮助的代理的整个流程。 3. 语义层物理上位于哪里？ 理论就到此为止。实践者面临的最大问题是如何以经济高效的方式实现这些概念。这些层应该具有持久性，以便人类和智能体可以互换使用。元数据已经持久化到数据目录中，通常被称为业务术语表。然而，随着我们向上层架构的构建，持久化问题变得更加复杂，这主要受可用性、可移植性和一致治理的需求驱动。例如，无论数据以何种方式和原因被使用，随着使用规模的扩大，性能损失都应该降到最低。 这要求很高。我们既想鱼与熊掌兼得。其中一些要求需要权衡取舍。错误的决策会导致这些理念与数据脱节，最终导致投资失败。 本节我们将探讨语义层持久化。我们看到每个供应商都声称自己是最佳存储位置。然而，实际上，存储这些概念的位置各有利弊。答案不出所料，取决于具体情况。这取决于最终用户群的规模、数据变化的频率和数量，以及谁最了解数据，从而最有能力保持这些概念的更新。 在我们探讨上下文层将位于何处之前，首先需要承认我们尚未解决一个更简单的问题：语义层目前位于何处？答案是，无处不在，又无处可寻： 商业智能 (BI) 工具：语义的概念最早由Business Objects公司在 20 世纪 90 年代初提出。自那时起，几乎所有 BI 工具都声称自己是存储语义的最佳平台。Looker在这方面做出了巨大努力，但微软的Power BI才是真正的标杆，它声称拥有超过 2000 万个语义模型。BI 工具市场依然活跃：一款相对较新的 BI 工具Omni最近以 15 亿美元的估值融资 1.2 亿美元。优点：对于真正了解数据及其使用模式的用户来说，操作最为直观。缺点：BI 工具可能存在用户锁定问题，并且可能与不支持 BI 的 AI 代理不兼容。 独立层：无论语义层存在于何处，它始终会造成某种程度的锁定。因此，像AtScale和Cube.dev这样的独立语义层供应商提供了一种独立的服务，供所有用户调用。优点：提供了一个独立的语义层，确保所有 BI 和 AI 用户的数据一致性。缺点：增加了数据工具的数量，并带来了一些运维开销。 数据治理工具： Collibra、Informatica、Atlan、Alation以及ServiceNow（收购data.world后）等数据目录一直是存储元数据、展示数据沿袭和应用访问策略的核心。它们声称能够存储语义，如今又能够存储上下文，这是一种自然而然的发展，正如Databricks的 Unity Catalog Metrics 等新产品所展现的那样。数据治理工具还包括Profisee和Reltio（已被SAP收购）等主数据管理 (MDM) 供应商，因为 MDM 的设计初衷就是通过黄金记录的概念来提供语义一致性。优点：语义与数据沿袭、策略和黄金记录并列，而数据管理员已经在这些方面开展工作。缺点：目录通常侧重于描述而非执行，因此定义可能与查询的实际运行方式存在偏差。 数据集成供应商：组织内部的大部分业务逻辑都位于数据集成层，因此像dbt （已被Fivetran收购）这样的供应商 声称自己是存储语义数据的理想场所。事实上，dbt 已根据 Apache 2.0 开源了 MetricFlow，并使用 Git 来存储指标。优点：非常适合数据沿袭分析。缺点：对业务用户来说不够直观。 数据存储供应商：Snowflake和BigQuery都引入了语义层，该语义层最接近数据表，并且无论使用者类型如何，都会强制执行。例如，AI 代理可以使用 MCP 等协议来访问语义层。优点：强大的集中式治理。缺点：本质上是特定于某个供应商的。 人工智能代理：代理通过提示上下文和工具描述来学习语义理解。这是目前人工智能厂商竞相研发的领域。优点：持续学习。缺点：应用范围有限，且该领域尚不成熟。 企业平台供应商： Palantir 的 Foundry 方案提供了最全面的集成，其本体嵌入平台内部，并由其前线部署工程师维护。优点：AI 代理可以原生运行在受管控的、可操作的本体之上。缺点：本体实际上是租用的，而非拥有的。治理工作由供应商负责，而非您。 这些层级分别由不同的角色使用，例如数据工程师、数据分析师、数据管理员和业务用户。仅由一个角色创建语义是有限的，因为他们的优先级和业务知识各不相同，这可能导致语义过时。语义需要经过测试和版本控制，以避免与底层数据发生偏差。幸运的是，由于开放标准的出现，语义层与底层数据的这种泾渭分明的界限正逐渐模糊。 4. OSI 等标准的作用是什么？ 企业数据领域一个不为人知的秘密是：每种工具都对“真相”有着各自不同的解读。商业智能工具有自己的指标库，数据目录有自己的术语表。转换工具中的语义层对“月度经常性收入”的定义可能与人工智能代理提示模板中的语义层定义不同。六种工具，六种MRR定义，一致性荡然无存。 标准打破了这种恶性循环。 开放语义交换 (OSI) 是此技术栈最相关的标准。OSI 的目标是以标准且可移植的格式定义指标一次，使其在任何地方都能被识别，无需手动重新映射。如果您的“活跃客户”定义符合 OSI 标准，那么您的Tableau仪表板、Snowflake语义视图、LangChain代理和 GraphRAG 查询都将读取相同的定义。该定义具有可移植性。截至 2026 年 5 月，已有超过 30 家公司注册支持 OSI，其中包括Salesforce和Databricks。 OSI 引入了更高层次的可移植性。例如，Snowflake 语义视图中定义的语义与Hex、ThoughtSpot和Omni等 BI 工具具有双向读写功能。这使得不同的用户可以选择由谁来创建和维护语义，并确保语义在技术栈的不同层级之间保持同步。 OSI 是更广泛模式的一部分。增量共享 (Delta Sharing) 正在成为跨组织数据共享的开放标准。Iceberg REST 目录正在逐渐成为表元数据的标准。模型上下文协议 (MCP) 最初由 Anthropic 公司提出，并于 2025 年底捐赠给 Linux 基金会旗下的 Agentic AI 基金会，如今已成为将 AI 代理连接到工具、数据和应用程序的事实标准。 本体论由一系列 W3C 标准构建而成。RDFS 提供基本的类和属性模型。OWL 提供推理结构，使软件能够推断新的事实。SKOS 负责分类法和术语表的词汇控制。PROV-O 对事实的来源（即其沿袭）进行建模。在此基础上，构建了之前介绍的领域本体论，例如 Schema.org、FIBO、SNOMED CT 和 GS1，它们都是符合 W3C 标准的词汇表，可供整个行业共享。 正是因为有了标准，美国邮政编码中的“加利福尼亚州”才用“CA”表示，而不是“加拿大”。令人遗憾的是，ISO 3166 标准中“CA”指的却是加拿大，而这正是标准存在的意义所在——为了规范这种歧义。 对于智能体人工智能而言，标准至关重要，不容商榷。一个需要调用五种工具并遍历三个数据源的智能体，不可能学习五种专有语义方案。OSI、MCP 和开放表格格式是智能体的通用语言。 5. 上下文层是如何构建和持久化的？ 我们已经花了相当多的时间来解释语义的各个方面。现在，是时候了解当今的上下文层是如何构建和存储的了。语义和上下文术语这两个术语经常被混用。希望这篇文章已经阐明，上下文层比语义层要大得多。也许这正是问题所在。当范围过于庞大时，实现起来就变得困难了。 前沿模型将上下文视为短暂的，仅在运行时为单个代理回合构建并丢弃。然而，跨会话持久化上下文可以让系统直接回答常见查询，从而减少昂贵的 LLM 往返次数和令牌成本。 在《设计人工智能驱动的数据基础》一书中，引入了“提取、上下文、链接”（ECL）模式来构建上下文层： 提取：上下文信息分散在各个地方，存在于结构化数据库、PDF、电子邮件、聊天记录、支持工单、产品评论和网页日志中。因此，首要需求是能够访问所有这些数据源。现有的集成模式（ETL、ELT、联合）是为人工通过 SQL 查询结构化表格数据而设计的，并非为这种混乱的多格式环境而设计。ECL 可以连接到所有数据源，无需您先将数据复制到一个数据仓库，即可从每个数据源中提取实体及其元数据。 上下文：找到数据源并不等同于理解它。一旦识别出实体，大型语言模型（LLM）就会推断它们的语义：每个实体是什么，它在您的业务中意味着什么，以及它与其他实体之间的关系。正是在这里，90% 的企业非结构化数据最终变得可用。零件文档 PDF 不再是一堆文本，而是变成了“产品 Z 上的缺陷模式 X，影响批次 Y”。这些上下文理解以本体的形式存储在目录中。 链接：最后一步通过知识图谱将提取出的上下文信息整合到企业内存中。它在遵守安全策略和业务流程的前提下，将数据库、文档和通信系统中的实体和上下文信息连接起来。其优势在于，代理可以通过 API 或 MCP 查询单一端点，而无需手动集成十几个系统。 这就是向上下文架构转变背后的微妙变化。传统的 RAG 架构在模型运行前将数据推送给代理，预先猜测其所需内容。上下文层则完全颠覆了这一模式：代理在运行时通过一个受控的端点获取其所需的确切数据。数据检索过程并未消失，而是得到了有效管理。 让我们回到之前提到的MacBook Air故障电话。提取功能会访问订单数据库、零件PDF、网络日志、客户的推文以及支持搜索日志。上下文功能会从每条信息中提取出具体含义：客户、序列号、故障模式、情绪和意图。链接功能会将这些信息整合到一个图中，这样客服人员看到的就是一个完整的故事，而不是几个互不关联的片段。这个可查询的链接视图就是上下文层。 一个值得注意的细微差别。当数据集在组织内部生成时，您可以通过数据契约预先定义其上下文，该契约声明了模式、字段语义和质量阈值。但当数据来自组织外部时，例如第三方数据源、合作伙伴数据或缺乏所有者的、管理不善的内部数据源，则无法预先定义上下文，而必须进行推断。ECL 正是自动化这一推断过程。 结束 在缺乏治理的元数据和不一致的语义之上构建上下文层，只会加速出错。在本文中，我们探讨了元数据、语义、分类法、本体、知识图谱和上下文的概念，但尚未涉及企业最关心的议题，例如安全性、治理、规模和成本。正如语义层几乎可以存在于技术栈的任何位置一样，上下文层最终也可能分布在多个层级，而不是集中在一个地方。 来源（公众号）；数据驱动智能
每隔几个月，同样的架构争论就会再次出现：企业 AI 系统是否需要 RDF 和 OWL，还是属性图就足够了？ 问题在于，这个问题本身就是错误的。 两者都以可预见的方式犯了错。 真正的问题不在于RDF/OWL是否比属性图更好，而在于：你要解决的是哪种语义问题？ 如果你正在构建一个具有明确关系且需要快速遍历的单系统代理，那么属性图可能正是合适的选择。但如果你正在构建跨平台、受监管、可审计的代理工作流，并且系统之间需要就含义达成一致，那么形式化本体论就显得尤为重要。 本指南为架构师提供了一个结构化的决策框架——以生产部署为基础——并明确规定了正式本体何时能够证明其成本合理，以及何时会增加复杂性而没有相应的收益。 我们究竟在选择什么？ 这场争论常常将不同层面的实施选择混为一谈。 RDF（资源描述框架）是一种数据模型：它由具有全局唯一URI的主语-谓语-宾语三元组组成，是W3C制定的链接数据标准表示方法。 OWL（Web本体语言）是一种用于RDF的模式语言。它允许您定义类、属性、关系，以及至关重要的推理规则。OWL推理器（例如Pellet或HermiT）可以推导出未显式存储的事实：如果AFxSpotContract是B的子类FinancialInstrument，推理器会自动推断出这种成员关系，而无需为每个实例显式存储。 SPARQL是 RDF 图的查询语言，相当于三元组存储的 SQL 语言。 SHACL（形状约束语言）是一种 RDF 词汇表，用于表达随数据一起传递的数据验证约束，而不是锁定在应用程序代码内部。 属性图（Neo4j、TigerGraph、Amazon Neptune）存储带有键值属性的节点和边。它们针对显式关系和操作遍历进行了优化。但它们并不提供 RDF/OWL 所设计的基于标准的语义模型、可移植的推理语义或全局共享的标识符规范。 问题不在于哪个“更好”，而在于它们是为了解决不同的问题而设计的。 影响决策的五个维度 1. 知识范围：单一系统与跨界 当您的知识仅限于单个应用程序、数据库或团队时，属性图就足够了。如果您拥有整个数据模型，属性图可以以极低的设置成本为您提供所需的一切。 当需要在组织或系统边界之间共享、比较或验证知识时，RDF/OWL 就变得至关重要了。 设想一个典型的企业采购环境。同一供应商同时出现vendor_id在ERP系统、party_ref合同管理系统、supplier_code发票平台和counterparty_id风险管理系统中。对于人工分析师而言，这只是日常的摩擦；而对于自主智能体来说，这却是一道难以逾越的障碍。 当你部署一个采购代理，需要验证供应商是否已获得合同批准才能发出采购订单时，你就是在要求它实时协调四个标识符、三个状态分类和两个“已批准供应商”的定义——而且没有人会注意到它何时连接错误。 “首选供应商”、“可寻址支出”、“合同价格”和“批准类别”等概念缺乏跨系统通用的定义。而RDF/OWL + SHACL则弥补了这一空白：本体只需定义Supplier一次，即可包含所有有效状态和约束。SHACL将这些约束表达为任何系统都能独立验证的形式。新加入工作流的代理导入本体，运行验证器，即可获知供应商是否符合共享定义。语义契约得以共享，集成工作量也随之减少。 2. 推理要求：存储的事实与推导的知识 这是大多数建筑师容易低估的一个方面。 属性图存储的是你输入的内容。添加一个新的子类后，你必须更新所有依赖于该层次结构的查询和应用程序。OWL 推理器会自动推断——你只需定义一次类层次结构，其含义就会自动在整个图中传播。 RDF/OWL 在以下情况下值得使用： 你需要发现其中存在的隐含矛盾（两个不可能同时为真的事实）。 您的域具有复杂的继承层次结构，并且会随着时间的推移而增长。 为了符合合规性或审计要求，您需要可证明的完整性。 属性图在以下情况下是正常的： 你需要快速遍历明确的、稳定的关系。 查询性能比推理完备性更重要 State Street GFRO 部署中使用了 Pellet（一个 OWL DL 推理器）进行工具层面的监管报告——因为这类报告需要完整性。基金层面的报告则使用参数化的 SPARQL，而没有使用完整的推理器，因为这类报告不需要推理的完整性。在需要完整性的地方使用推理器；在不需要完整性的地方则不使用。 3. 治理模型：应用所有制 vs. 数据可移植制 大多数属性图和专有平台部署都用作封闭式操作系统：平台决定哪些数据存在、哪些数据有效以及允许哪些操作。治理规则存在于平台逻辑、API、工作流定义或应用程序代码中。它们功能强大，但无法随数据一起流动。 RDF/OWL 提供开放的、基于标准的语义。SHACL 则通过可移植的验证机制对其进行补充。OWL适用于需要共享语义和推理的情况。SHACL 适用于需要可导出、版本化并由其他系统（包括发布机器可读要求的外部审计机构或监管机构）执行的数据质量约束的情况。 对于拥有复杂专有模型的平台而言，合适的框架在于：平台边界内的运维能力与跨平台边界的语义互操作性。两者都是合理的架构选择——问题在于你的多智能体设计实际需要的是哪一种。 4. 代理架构：单系统与跨平台协调 当一个平台上的AI代理将任务移交给另一个平台上的代理，而该代理又调用第三个平台上的工具时，认知协调机制并未建立。代理要么拥有共享的语义契约，要么做出一些会向下游传播的假设。 微软的 GraphRAG 研究（Edge 等人，2024/2025）展示了一种截然不同的方法：基于 LLM 的图结构。GraphRAG 并非预先定义模式，而是从非结构化文本中提取实体和关系，构建属性图，并利用莱顿社区检测将其划分为主题聚类。对于语料库级别的非结构化文本意义构建，GraphRAG 的性能显著优于传统的向量 RAG，其全面性胜率高达 72%–83%。 GraphRAG 和 RDF/OWL 并非对同一问题的相互竞争的答案。GraphRAG回答的是“该文档语料库的主题是什么？”，而 RDF/OWL 回答的是“该金融工具在我们五个源系统中是否符合巴塞尔协议 III 对一级资本的定义？”。第一个问题没有预先存在的模式；第二个问题则需要一个权威的模式。 5. 投资期限：短期速度与长期杠杆 RDF/OWL 确实存在前期成本：本体工程需要专门的技能，三元组存储的操作特性与关系数据库不同，而且 SPARQL 不如 SQL 常见。 属性图能让你更快地构建出可用的原型。Neo4j 的开发者体验远胜于任何三元组存储。 微积分发生变化的地方： 语义协调工作需要在多个源系统和团队之间重复进行——尤其是在添加新系统时。 数据质量溯源的外部监管要求 已建立的行业标准本体（金融领域采用 FIBO，医疗保健领域采用 SNOMED CT / HL7 FHIR，建筑领域采用 IFC） 跨组织或供应商边界运行的人工智能代理 在这些关键节点，RDF/OWL 的前期成本会分摊到所有使用该本体的系统中。道富银行团队向开放标准贡献了 62 个 FIBO 扩展——这项工作惠及所有符合 FIBO 标准的机构，而不仅仅是道富银行。 决策框架 首先，何时开始使用 RDF/OWL？ 何时使用属性图谱 + API： 实践中效果最佳的混合模式 在设计良好的企业系统中，这两种方法都不会被全盘采用。生产部署倾向于采用三层架构，其中每种图类型都承担其擅长的任务： 智能体记忆图/情景知识图谱——捕捉智能体的行为、决策及其原因；具有双时态溯源性；决策轨迹作为一种不断累积的制度资产。图式在交互过程中涌现，而非预先设定。（类似Zep的框架在此发挥作用。） 属性图谱 + GraphRAG在操作知识层——显式参考知识、语料库意义构建、快速遍历以进行推荐和检索。在此，领域知识变得可查询。 OWL 本体 + SHACL在语义契约层——跨组织边界共享含义、类层次结构、在需要时进行形式推理、外部各方无需导入您的平台即可执行的可移植验证。 三种需要避免的模式 模式 1：过早的形式本体论 一个团队构建单租户内部知识库，却花了六个月时间进行 OWL 建模、SPARQL 端点设计和推理器调优——而属性图只需两周就能解决这个问题。当既不需要跨边界交换，也不需要推理时，形式化本体就毫无价值。 模式二：大规模的图谱蔓延 一个团队为一个用例构建了一个属性图，并将其扩展到另外五个用例，然后与三个外部合作伙伴共享——结果发现他们之间没有统一的URI方案，没有可移植的约束，也无法验证合作伙伴对节点的解释是否一致。每个新的集成点都需要定制的协调方案。成本不断累积。 模式 3：将平台级语义层误认为可移植语义标准 许多企业平台都自带所谓的“本体”——一种跨平台共享的语义模型，能够在其生态系统内良好运行。其实，它本质上就是一个平台级的语义层。它解决了同一厂商内部的集成问题，但无法解决跨厂商的互操作性问题。 如果没有 OWL 导出、SPARQL 访问或可移植的 SHACL 约束，平台级语义层就无法作为跨平台代理协调的语义标准。从外部加入的新代理必须调用源平台的 API 并信任其解释，才能对其进行验证。 关于为何这种差距持续存在，需要说明一点：对于拥有成熟语义模型的平台而言，实现可移植语义契约在技术上并不困难。但在平台经济中，谁拥有协调层，谁就能获得不成比例的价值——而可移植标准打破了这种依赖关系。历史模式一脉相承：可移植性只有在监管机构强制要求（例如医疗保健领域的 FHIR，金融领域的 FIBO）或企业买家将其作为采购条件时才会出现。在此之前，应将可移植性视为一项需要明确定义的架构需求，而不是供应商会主动趋同的特性。 总结 对于受监管的行业而言，跨组织边界运营，拥有长期存在的数据资产，需要由您无法控制的系统和代理进行一致的解释，因此 RDF/OWL 并非过度设计。 对于语义含义稳定、易于理解且永远不需要外部方验证的单团队、单平台部署来说，这样做是过度的。 属性图并非“精简版的RDF”。它们是一种不同的工具：操作速度快、开发人员操作方便、并且具有LLM友好的归纳结构。 企业人工智能的未来不在于选择哪个图论阵营，而在于了解何时需要推断含义，何时需要验证含义，何时需要传递含义，以及何时只需要快速查询。 来源（公众号）：数据驱动智能
10%存储拖垮90% GPU投资？ 去年公司花1000万买了60台A100，老板把我叫到办公室问我AI项目的ROI怎么样。 我当时支支吾吾说不上来，后来才发现GPU利用率只有30%，大部分时间都在等数据。 这让我想起2023年我犯的一个错，以为买了顶级的GPU就能出效果，结果被存储系统拖垮了整个项目。 那个教训花了公司快100万，差点让我离职。 今天把这段经历分享出来，是想告诉各位IT管理者：存储不是配角，是GPU价值的放大器。 你GPU利用率低、AI推理速度慢、算不过来，问题可能不在GPU本身，而在被你忽略的存储系统。 一个反认知的观点 先说个反认知的观点：很多IT管理者认为存储就是存数据的，够用就行。 这种想法在AI时代特别危险。 IBM最新的研究发现，不到10%的存储投入，可能拖垮90%的GPU投资。 什么概念呢？ 你花1000万买GPU，只花100万配存储，结果GPU利用率只有30%，相当于700万的GPU投资被浪费了。 我给你一个参考数据，2023年那个项目，我们就是因为存储系统跟不上，导致GPU空转率高达70%，每个月的电费就要多交20万，这种隐形成本很容易被忽略。 为什么存储会成为GPU的瓶颈？ 为什么存储会成为GPU的瓶颈？我给你一个实用的判断方法。 AI训练的典型流程是这样的：GPU先从存储读取训练数据，然后进行计算，计算完成后再把结果写回存储。 这个过程中，如果存储的读写速度跟不上GPU的计算速度，GPU就会一直等待，就像法拉利装了个拖拉机引擎。 IBM的研究显示，AI训练过程中70%的时间GPU在等待数据，只有30%的时间在真正计算。 而存储系统的性能，直接决定了这70%等待时间的长短。 一个真实案例：50万撬动450万价值 我给你一个真实案例，去年我帮一个客户做AI平台优化，他们的GPU利用率一直维持在30%左右，老板以为GPU买少了，准备再投500万扩容。 我让他们先做一次存储诊断，发现存储系统的随机读写性能只有GPU需求的1/3。 后来他们只花了50万升级存储系统，GPU利用率直接从30%提升到65%，节省了450万的不必要GPU投资。 这个案例特别典型，很多IT管理者看到GPU利用率低，第一反应是买更多GPU，而不是先查存储瓶颈。 三个已验证的方法 具体怎么做？我给你三个已经验证过的方法，都是我踩过坑总结出来的。 方法一：全链路诊断 第一个方法是做一次全链路诊断，从数据采集、数据传输、到GPU加载，每个环节都要测速。 这个诊断不用花很多钱，找存储供应商做个免费的PoC测试就行，重点看三个指标：存储的随机读写IOPS、顺序读写带宽、数据传输延迟。 这三个指标如果任何一个低于GPU需求的50%，你就知道瓶颈在哪里了。 我去年用这个方法帮5个客户做过诊断，其中有4个发现了存储瓶颈，而不是GPU不够用。 方法二：AI智能调度 第二个方法是用AI智能调度存储数据。 这个方法是IBM最新的研究成果，他们把AI Agent直接塞进了存储系统，让存储系统自己学会优先调度热点数据。 具体做法是这样的，你在存储系统中部署AI Agent，它会自动分析哪些数据集被GPU频繁访问，然后把这些热点数据放到高速存储层，冷数据放到低速存储层。 这种智能调度可以让GPU的等待时间减少60%以上。 IBM自己的测试数据显示，使用AI智能调度后，GPU利用率可以从30%提升到70%，而存储投入只需要增加不到10%。 这个方法特别适合那种GPU投资已经很大、但利用率一直上不来的场景。 方法三：分层存储架构 第三个方法是做分层存储架构。 这个方法特别实用，你把数据分为热数据、温数据、冷数据三层。 热数据是GPU正在频繁访问的训练数据，放到NVMe SSD层；温数据是偶尔访问的验证数据，放到SATA SSD层；冷数据是历史归档数据，放到大容量HDD层。 这种三层架构可以让存储成本下降40%，同时GPU利用率提升20%以上。 我去年在一家AI公司落地过这个方案，他们原来全部用NVMe SSD，存储成本很高，后来做了分层架构，存储成本从800万降到500万，GPU利用率反而从45%提升到55%。 存储是GPU价值的放大器 如果你正在筹备AI项目，或者GPU利用率一直上不来，建议你先把存储系统查一遍。 存储投入可能只占IT预算的10%不到，但直接决定了90%的GPU投资能不能发挥价值。 就像那个客户，本来准备花500万买GPU，后来只花了50万升级存储，就搞定了问题。 这种投资决策，需要IT管理者跳出传统思维，不是GPU越多越好，而是要看整体ROI。 存储不是配角，是GPU价值的放大器。 你花1000万买GPU，如果存储跟不上，GPU利用率只能到30%，相当于700万被浪费了。 反过来，你只需要多投入10%在存储上，GPU利用率就能从30%提升到70%，相当于用100万撬动了700万的价值。 这个账，IT管理者一定要会算。 2026年AI推理会迎来大爆发，到时候GPU的需求会是现在的3-5倍。 如果你的存储系统现在就有瓶颈，到时候问题会被放大3-5倍。 不如现在就开始布局，把存储系统从配角变成价值放大器，让每一分GPU投资都发挥最大价值。 来源（公众号）：IT管理知识库
2025年年底，推荐性国家标准《数据管理能力成熟度评估模型》（GB/T 36073-2025，简称DCMM2.0）正式修订发布。DCMM 2.0在标准一级能力域由8个增加至9个，新增数据资产域。 国家市场监督管理总局和国家标准化管理委员会正式发布推荐性国家标准《数据管理能力成熟度评估模型》（GB/T 36073-2025），即DCMM 2.0，这一新版标准将于2026年7月1日正式实施，目前已进入“即将实施”阶段。新标准由全国信息技术标准化技术委员会（TC28）提出并归口，由中国电子信息行业联合会会同50多家行业协会、央国企、高校及科研机构共同起草。 新版标准着力构建一个以数据价值实现为核心的资产化、业务化、智能化、可信化新框架。 “资产化”旨在确立数据作为可交易要素的经济属性，为数据资源的市场化定价与流通奠定基础，呼应数据要素市场化配置的改革方向； “业务化”与“智能化”相结合，确保数据供给能精准、高效地支撑具体业务创新与人工智能应用； “可信化”则为数据跨组织、跨域的安全有序流通构建制度与技术并重的信任环境，从而系统推动数据从“管理对象”向“经营要素”转变。 DCMM 2.0在标准架构上实现显著拓展与前瞻布局。一级能力域由8个增加至9个，新增数据资产域。二级能力项由28个增至33个。 DCMM 2.0的核心价值在于为培育和建设全国统一的数据要素市场提供统一的能力标尺。通过评估模型，帮助广大企事业单位建立系统化的运营体系与方法论，成为组织构建数据治理新范式的核心操作指南与支撑体系。 DCMM 2.0 的发布不仅是标准版本的迭代升级，也承载着在数据要素市场化配置背景下，为企业构建统一数据管理能力参照体系的现实意义，体现出数据治理模式由内部管控向要素化、价值化方向演进的趋势。推动数据治理从传统管理向现代化要素运营演进，为“十五五”时期做强做优做大数字经济提供坚实支撑，标志着我国数据治理体系建设进入以激活要素价值为导向的全新阶段。 DCMM1.0 和DCMM2.0系统对比 DCMM2.0（GB/T 36073-2025）于2025年12月31日发布、2026年7月1日实施，核心是新增数据资产域、升级能力项与成熟度规则，适配数据要素市场化与合规要求，相比DCMM1.0更聚焦价值释放与安全可控。 以下是系统对比与核心内容梳理： 一、修订背景 二、能力域对比 1. 能力域架构升级 DCMM1.0：8个能力域、28个能力项、445条评估指标，覆盖数据战略、治理、架构、应用、安全、质量、标准、生命周期。 DCMM2.0：9个能力域、33个能力项，核心调整如下： 新增数据资产域含权属管理、价值评估、资产运营，支撑数据资产入表与价值释放。原“数据应用”调整为数据应用流通：新增外部数据管理，规范数据合作与引入合规。数据安全衔接《数据安全法》《个人信息保护法》，细化个人信息保护、跨境数据治理；数据质量新增非结构化数据标注与检索规则等。 2. 能力项关键变化 三、成熟度等级与评估规则调整 1. 等级划分优化 DCMM1.0：5级（初始级1→受管理级2→稳健级3→量化管理级4→优化级5），无甲乙双方差异化设定。 DCMM2.0：合并初始级（1级）至受管理级（2级），首次申报最低从2级起评。按甲方（需求/应用方）、乙方（服务/提供方）业务属性，差异化设定评估指标与要求。优化级（5级）门槛提升：新增持续创新、数据驱动业务变革等硬性要求，强调数据价值最大化与生态协同。 2. 评估指标与术语更新 指标体系适配新能力域，补充数据资产、流通合规等相关指标，强化可操作性。 更新“数据文化”“数据流水线”等18个关键术语，贴合当前数据管理实践。 四、核心价值与适用场景 DCMM1.0：以基础数据管理体系建设为核心，帮助企业搭建标准化制度与组织架构，规范全流程管理，适用于数字化转型初期的企业。 DCMM2.0： 突出数据资产价值。助力企业实现数据从成本中心到价值中心的转变，支撑数据资产入表与市场化交易。 强化合规与安全。全面满足数据安全与个人信息保护合规要求，降低合规风险。 适配新技术场景。支撑AI训练数据治理、隐私计算等新技术应用，推动数据驱动创新。 适用场景：数字化转型进阶期企业、数据要素流通活跃的行业（金融、互联网、制造等）、涉及跨境数据处理的企业。 五、企业应对建议 对照新能力域梳理现状。重点排查数据资产权属、价值评估、外部数据管理等短板。 升级数据管理制度。完善数据资产相关制度，修订数据安全、质量、流通等流程，适配新合规要求。 分阶段推进能力建设。优先夯实数据资产基础能力，再拓展数据应用流通与创新能力，结合自身业务属性（甲方/乙方）制定差异化提升路径。 提前准备评估。熟悉DCMM2.0评估规则，针对优化级新增要求，提前布局数据驱动业务变革与持续创新机制。 来源（公众号）：数据要素社
在数字化转型浪潮中，数据已成为组织最核心的资产。然而，传统数据治理模式往往陷入“大而全、长周期”的困境——耗时数月甚至数年梳理数据，最终却因业务需求变化或价值不明确而半途而废。如何打破这一困局？敏捷数据治理正成为破局的关键。 一、敏捷治理：以价值驱动的“小步快跑” 传统数据治理常以“建标准、理资产、治质量”为线性路径，导致治理与业务需求脱节。而敏捷治理的核心在于“价值优先、场景切入”，通过快速解决业务痛点证明价值，逐步积累治理资产。 核心策略： 聚焦高价值场景：直接对接业务需求（如组织机构数据不准、分析需求无法满足），以此为治理起点。 最小可行治理（MVG）：将庞大体系拆解为可独立交付的小模块，优先解决核心问题。 自动化工具赋能：利用元数据发现、数据血缘解析等工具替代手工盘点，提升效率。 轻量化协作：成立虚拟敏捷小组，以2-4周为周期冲刺，简化审批流程。 持续迭代优化：设定可衡量指标，定期回顾并调整优先级。 二、高校数据治理：从“痛点”到“速赢”的闭环 高校数据治理面临三大痛点：标准不一致、原始数据质量低、数据价值呈现不足。传统线性路径难以快速见效，而“以用促治、单点突破”的敏捷闭环则能在2-3个月内初见成效。 行动框架： 选定“速赢”场景：选择业务部门痛点深、领导关注度高的场景（如“人员身份治理”“教师一站式办事”）。 反向定义主数据与规则：围绕场景需求，锁定核心主数据（如“学生”“课程”），制定最小化标准和质量规则。 轻量级技术整合：建立临时数据视图，实施质量稽核与整改，快速开发场景应用。 沉淀资产并复制推广：将治理成果固化为资产，向全校展示并征集下一个痛点场景，形成治理飞轮。 三、学生关爱系统：敏捷治理的“小切口”实践 以学生关爱系统为例，敏捷治理可在4-6周内交付可见价值。核心思路是“反向驱动、精准治理”，通过解决“主动发现重点关注学生”的场景需求，快速打通数据。 敏捷步骤： 精准定义场景：与学工部、保卫部等部门确定痛点（如“识别多重风险学生”），转化为数据产品需求。 梳理最小数据需求：围绕“学业、经济、心理、社交”四类风险，列出必要数据清单，确认唯一主数据（学号）。 治理与整合并行：成立虚拟小组，轻量级对齐主数据，自动化探查并修复数据问题，构建“关爱数据专区”。 快速应用与反馈：开发预警看板，试点后收集反馈，形成持续优化闭环。 四、敏捷治理的关键要点 范围最小化：只治理场景必需的数据，不求全。 决策扁平化：虚拟小组拥有现场决策权，避免层层审批。 工具轻量化：优先利用现有工具和脚本，避免等待大型平台。 价值即时化：以“周”为单位交付成果，持续获得业务支持。 结语：让治理“于无形”中创造价值 敏捷数据治理的精髓在于“治理于无形”——通过快速解决业务痛点证明价值，逐步培养组织习惯，自然演化出完善的治理体系。高校数据治理应摒弃“四面出击”的传统思维，集中火力打造“治理飞轮”，让数据在业务场景中真正释放价值。 敏捷治理，让数据从“资产”变为“价值”，数据治理不再是一项“工程”，而是一种“能力”。通过敏捷方法，组织能快速响应业务需求，让数据治理真正服务于业务创新，实现从“被动治理”到“主动赋能”的转变。 来源（公众号）：数智转型洞察
有一个关于盲人摸象的古老故事。每个人都摸到了大象的不同部位，然后都确信自己了解了大象的全部。有人摸到了象鼻，说它像蛇；有人摸到了象腿，坚持说它像树；还有人摸到了象身，说它像墙。 企业级人工智能看起来很像那样。 问工程师公司应该如何使用人工智能，你可能会听到代理、编排、API、评估和应用架构等术语。问顾问，你可能会得到一份转型路线图。问领域专家，你可能会听到某个应该立即自动化的高价值工作流程。 这些观点本身并没有错，但它们都不全面。而且大多数观点都忽略了一点：真正每天从事实际工作的人，往往才是最先发现人工智能在哪些领域能发挥作用的人。 这一点很重要，因为企业在人工智能领域早期犯的最大错误是认为实现价值的途径是从训练或构建开始的。 通常的模式是这样的：首先，公司培训员工如何撰写简洁明了的内容以及如何安全使用人工智能。然后，公司筛选出一些有前景的工作流程，并委托开发定制应用程序来实现自动化。这两个步骤听起来都很合理，也都有帮助。但单独来看，它们都无法解决根本问题：有效的AI实践仍然分散、地域性强，难以复用。 结果不出所料。一个团队开发出一个巧妙的客户支持分诊提示。另一个团队创建了一个内部代理，帮助分析师准备周报。一位开发人员找到了一个强大的 MCP 集成方案，使代理能够访问内部文档、问题跟踪器和分析系统。还有人构建了一个 Claude Code 工作流，可以将缺陷单转化为实施计划草案。所有这些都很有价值。然而，在大多数企业中，它们仍然局限于个人笔记本电脑、Slack 讨论、笔记本或一次性演示中。 这就是企业人工智能的重大秘诀：企业并非仅仅通过培训员工使用人工智能或构建孤立的人工智能应用就能获得最快的回报。相反，当企业创建一个共享平台，让有用的提示、代理、技能、工具和支持多级协作平台（MCP）的功能能够被发现、改进、管理和复用时，才能获得更快的回报。 为什么独自训练效果不佳 想象一下，给每位员工的办公桌上都放上一款功能强大的AI工具，比如OpenClaw，然后说：“它几乎可以自动化所有事情。去用吧。” 这听起来很有启发性。但实际上，这往往会导致犹豫不决。 大多数人醒来时并没有一份清晰明了的“值得自动化的任务”清单。他们有工作要做，有截止日期要赶，还有几十个细小的决策需要做出。他们每天的精力往往分散在各种例外情况、判断、反复沟通和碎片化的系统中。他们或许能从人工智能中获益匪浅，但他们可能无法提前明确哪些工作应该通过提示、自动化、代理或应用程序来实现。 这就是为什么最初的热情过后，推广应用往往会停滞不前的原因之一。员工可能会尝试，但这些尝试并不会自动转化为组织共享的能力。 这与更广泛的市场数据相符。麦肯锡对人工智能现状的研究发现，各组织机构正在迅速提高人工智能的采用率，但只有极少数机构能够大规模地看到人工智能对企业盈利的实质性影响。德勤的报告也指出，尽管各组织机构热情高涨且投资巨大，但许多机构仍然难以从试点阶段过渡到规模化应用，从而创造价值。这种差距通常并非源于缺乏创意，而是缺乏可复制性、推广性和运营化。 培训能帮助人们跨越最初的障碍，但它本身并不能修建道路。 为什么“让我们开发一个应用”的范围太窄 当企业不再局限于培训时，他们通常会直接着手为特定用例构建定制软件。 这并没有错。有些流程确实需要专门的产品体验。例如，受监管的承保工作流程、临床审核流程或关键任务型开发平台，可能都需要一个功能完善、针对特定任务的应用程序，该应用程序应具备可审计性、基于角色的控制以及结构化的界面。 但这对于大多数机会来说，起点太高了。 企业人工智能价值的最初体现往往并非一个完整的应用程序，而是一个每天能节省 20 分钟的提示模板，或者是一个可复用的研究工作流程，又或者是一个能够从文档中提取上下文信息、总结工单、撰写回复、比较合同、生成初步 SQL 查询语句或准备代码审查清单的智能体。这些并非微不足道的成果，规模化应用后，其价值将成倍增长。 假设一家公司拥有 2000 名知识型员工。如果其中只有 25% 的员工每天通过可复用的 AI 技能和共享代理工作流程节省 20 分钟，那么一年下来就能节省超过 4 万小时。即使在流程重新设计之前，这也能带来显著的运营效益。而且，与单个定制应用程序不同，这些效益可以同时在多个团队中实现。 问题在于，大多数企业仍然缺乏获取、改进和推广这些成功经验的机制。 缺失的层面：共享的企业公共领域 企业需要的不仅仅是人工智能的使用权限，还需要用于共享的人工智能基础设施。 这意味着存在一个公共层，人们可以在该层上贡献代码并发现可重用的功能，例如： 能够可靠地执行有价值任务的提示 协调多步骤工作的代理 具备将可重复的方法或工作流程打包的技能 将人工智能与业务系统连接起来的工具 MCP 服务器可安全地向代理应用程序公开数据、系统和服务。 模板和评估模式使成功应用得以复现 团队认可的适用于 Claude Code、Codex 和其他代理工作空间等应用程序的最佳实践 这一层充当人工智能使用的组织记忆。 令人惊讶的是，我还没有遇到过哪个工程团队能够自主创建这种编码共享平台。 如果没有它，每个员工都将从零开始。有了它，一位员工的洞察力就能加速其他团队的工作。良好的内部提示将成为标准操作工具。实用的 MCP 集成将惠及全公司。高效的开发人员调试工具将成为每个工程团队可复用的功能。法务部门开发的合同汇总工作流程也将成为采购和销售运营部门值得信赖的工具。 这就是本地实验如何转化为企业优势的过程。 从个人发现到组织能力 企业人工智能最重要的转变不是从“人工操作”到“自动化”，而是从孤立的发现到共享的能力。 想想这在实践中会如何发展。 一位产品经理发现，结构化的提示加上文档检索工具，就能将杂乱的客户访谈记录整理成一份清晰的每周洞察简报。这本身对一个人来说就很有用。但如果将这一工作流程打包成一项可复用的技能，并编写文档、共享，同时将其发布到公司的AI工作区，那么其他几十位产品经理就能立即使用。随着时间的推移，还可以通过改进检索功能、优化架构和完善评估标准来进一步提升效率。 以软件工程为例。一位资深开发人员创建了一个 Claude Code 工作流，该工作流读取 GitHub 问题，检查相关代码库，识别可能需要修改的文件，制定计划并提出测试用例。这个工作流最初可能只是个人提高效率的小技巧。但一旦在内部共享，它就变成了一种可复用的工程能力。如果再添加一个 MCP 服务器，提供对代码库元数据、项目文档和 CI 信号的安全访问，那么这个工作流就会变得更加健壮，用途也更加广泛。 同样的逻辑也适用于整个企业： 在销售中，可重复使用的代理可以汇总客户信息、生成通话准备材料，并根据 CRM 环境起草后续跟进内容。 他们可以提供支持，对工单进行分类，识别重复出现的问题，并根据帮助中心的内容提出解决方案。 在财务方面，他们可以解释预算差异、撰写评论，并准备初稿董事会报告材料。 在法律领域，他们可以比较条款、识别风险并组织合同审查。 在操作中，它们可以将零散的标准操作程序转化为引导式执行流程。 共享资源使这些模式可见且易于移植。 为什么MCP比它们乍看起来更重要 模型上下文协议 (MCP) 服务器之所以重要，是因为真正有用的企业级人工智能很少仅仅关乎模型智能，它还关乎在正确的时间获取正确的上下文、工具和系统。 缺乏业务背景的模型虽然条理清晰，但却流于表面。而通过精心设计的管理控制点（MCP）连接的模型，则能真正发挥作用。 例如： 与从零开始的编码代理相比，连接到版本控制、问题跟踪和内部文档的编码代理可以提供更好的实现支持。 连接到产品文档、帐户历史记录和已知事件的支持代理可以生成更准确的回复。 连接到内部报告、分析和客户笔记的研究代理可以综合出原本需要数小时手动整理才能得出的见解。 因此，企业面临的挑战不仅仅是“我们应该使用哪种模型？”，而是“我们如何在整个组织内提供最佳功能（上下文、工具、提示和代理模式），使其可重用、可管理？” 领先者不仅可以使用前沿模型，还将拥有围绕这些模型构建的可重用功能的内部生态系统。 机遇背后的统计数据 越来越多的数据支持这一观点。 麦肯锡的报告指出，生成式人工智能每年可为全球经济创造数万亿美元的价值，其中大部分价值集中在客户运营、市场营销、软件工程和研发等知识密集型工作领域。与此同时，许多调查也显示出一个熟悉的模式：企业都在大力投资，但只有少数企业能够成功地将人工智能扩展到所有工作流程中。 IBM 的企业人工智能研究发现，领导者们认为数据复杂性、技能差距和工具碎片化等障碍是实现人工智能价值的主要阻碍。微软和 LinkedIn 的工作趋势指数也显示，员工已经开始将人工智能应用于工作中，其速度往往快于企业制定正式的使用规范。这是一个至关重要的信号：人工智能正在被广泛采用。问题在于，企业能否将分散的使用转化为共享优势。 基于共享资源的方法恰好弥补了这一缺口。它减少了重复工作，加快了新用户上手速度，总结了最佳实践，使治理能够应用于可重用的资产，而不仅仅是一次性的实验。此外，它还能帮助组织识别哪些新兴工作流程值得转化为产品。 更完善的企业人工智能成熟度模型 大多数公司实际上都遵循着如下的成熟度模型： 对人们进行人工智能基础知识培训。 先试运行几个试点项目。 开发一些自定义应用程序。 尝试按比例缩放。 更好的模型是： 让团队能够使用功能强大的AI工具。 为提示、代理、技能、工具和 MCP 创建一个共享的企业公共资源。 让员工贡献、发现、调整和改进可重用的工作流程。 观察哪些能力能够真正推动应用并创造可衡量的价值。 必要时，将最重要、经过验证的工作流程推广到专用应用程序或产品中。 为什么？因为它既降低了实验成本，又保留了标准化的优势。企业无需为每个有前景的应用场景都预先开发一个软件项目，而是可以在人们已经使用的环境（例如聊天工作区、编码代理、内部助手和桌面人工智能工具）中测试和改进各项功能。 只有当一个工作流程证明了它的价值、可重复性和市场需求后，才需要将其发展成为定制产品。 这种顺序至关重要。它既能防止企业过早过度建设，又能为规模化发展创造条件。 这在一家真实的公司里是什么样的呢？ 想象一下一个拥有 5000 名员工的企业，其团队涵盖工程、财务、销售、运营和法律等各个领域。 在传统的AI部署过程中： 提供培训 一些团队进行了试验 零星的成功出现 有些商业案例是为定制应用程序编写的。 大多数有用的发现仍然分散各处。 在基于公共资源的推广中： 每个团队都可以访问企业级人工智能工作空间。 员工可以发布有用的提示、代理和技能。 精选的 MCP 服务器连接已批准的系统和数据源。 团队负责人可以推荐或批准可重用的功能。 像 Claude Code 或 Codex 这样的应用程序中使用的工具可以共享，而无需重新构建。 高效的工作流程在各部门间获得可见性。 治理、版本控制、访问控制和评估均采用集中式管理。 产品团队可以确定哪些共享功能值得进行全面的应用投资。 区别在于，现在这家公司不再仅仅是“使用人工智能”，而是在构建机构级人工智能资本。 战略回报 这种模式的战略收益不仅仅体现在生产力方面。 共享企业资源创造了： 更快实现价值，因为实用功能无需等待完整的应用程序开发即可扩展。 实验的投资回报率更高，因为一个人的发现可以使数百人受益。 更好的治理，因为可重用资产可以进行审查、版本控制、权限管理和监控。 由于人们从成熟的工作流程入手，而不是从空白聊天框开始，因此采用率会更高。 更清晰的产品信号，因为使用最广泛、影响最大的功能自然会揭示哪些体验值得专门的软件投资。 换句话说，共享平台并非企业软件的替代品，而是检验企业软件优劣的试验场。在这里，企业可以学习哪些方法真正有效。 新的竞争优势 随着智能体应用变得越来越普遍，无论是在 Claude Code、Codex、内部副驾驶系统还是未来的 AI 工作空间中，竞争优势将越来越来自企业能够在这些环境中提供的功能。 它不仅仅是一个模型，也不仅仅是一个聊天界面，而是一个由共享提示、代理、技能、工具以及基于 MCP 的真实组织环境访问构成的鲜活生态系统。 那些能做到这一点的公司之所以能发展更快，并非因为它们将每个用例都开发成了应用程序，而是因为它们使有用的功能可以移植。它们会让组织从边缘发现价值，推广行之有效的方法，并将反复取得的成功转化为记录系统和执行系统。 这才是企业人工智能的真正行动指南。 培训人员，当然要。必要时，也一定要生产产品。 但首先，要建立公共资源。 因为实现企业人工智能价值的最快途径并非要求每位员工从零开始创造，也并非强行将每个想法都转化为软件项目。而是为企业提供一种共享的方式，用于捕获、推广和复用行之有效的方法。 这就是实验如何转化为基础设施的方式。这就是个人创造力如何转化为组织杠杆的方式。 这就是企业人工智能的最大秘密。
为全面贯彻落实党的二十大和二十届历次全会精神，深入落实中央经济工作会议和全国两会精神，按照“十五五”规划纲要任务部署，促进实体经济和数字经济深度融合，国家数据局印发《2026年数字经济发展工作要点》（以下简称《工作要点》）。 《工作要点》对2026年推进数字经济高质量发展重点工作作出部署，提出8个方面重点任务。 一是深化数据要素市场化配置改革。 加快建立全国统一数据产权登记制度，印发登记指引，推动各地加快建立健全公共数据授权运营价格形成机制，制定出台建设开放、共享、安全的全国一体化数据市场相关政策文件。 二是筑牢数字基础设施底座。 加快建设全国一体化算力网，推动数据、网络、算力、能源等资源协同布局，稳妥推进数据基础设施建设，支持行业、领域示范性设施建设。 三是强化数据赋能人工智能发展。 实施强基扩容、应用赋能、提质增效、管理服务、价值释放、标注攻坚6大专项行动，形成一批满足AI就绪度要求、有效训练先进模型、切实解决行业难题的标杆性高质量数据集。 四是提升数字经济核心竞争力。 因地制宜培育创新引领型、区域支柱型、区域特色型数字产业集群，培育数字经济创新型企业，构建“政府+企业+创新+投资”四合一的专业化遴选培育机制，组建数字经济创新型企业培育库，开展企业遴选。 五是促进实体经济和数字经济深度融合。 深入推进制造业数字化转型行动和重点行业数字化转型实施方案，加快赋能服务业扩能提质，丰富数据资源运营、数据技术创新、数据分析应用等服务供给，鼓励探索风险共担、收益共享的数据应用服务新模式，围绕数据赋能重大场景建设，培育一批数智化转型服务商。 六是提升数字化治理与服务能力。 推进数字经济促进法立法进程，持续推进数据安全管理，强化重要数据和核心数据识别与保护。 七是深化数字经济国际合作。 开展数字经济多双边合作，积极参与数据领域国际规则标准制定，鼓励有条件的地方探索建设数据跨境流动服务基础设施、国际数据中心，建设一批跨境可信数据空间。 八是营造良好发展环境。 探索构建央地协同、科学规范的数字经济监测评估体系，研究发布数字经济发展指数和有关先行指数，深化国家数字经济创新发展试验区建设，组织开展专家行活动。 下一步，国家数据局将会同有关部门抓好各项任务落实，以经济领域重大场景为切入，充分释放数据要素价值，助力建设现代化产业体系，加快培育新质生产力，赋能经济高质量发展。 来源（网站）：国家数据局
领导者们，现在的问题不再是这场变革是否会发生，而是你们是先于变革做好准备，还是被动地应对变革。 我想从最高层开始——不是从分析师的职业焦虑开始，而是从这一刻对于负责数据职能的领导者来说究竟意味着什么开始。 大多数商业智能和分析团队的架构都基于一个已被悄然推翻的核心假设：组织智能的主要制约因素是人对 SQL 的访问权限。消除这一障碍——通过增加分析师人数、完善商业智能工具、覆盖仪表盘——企业就能更加数据驱动。 这一假设推动了长达十年的分析投资。它催生了庞大的商业智能团队，推动了Tableau和Power BI许可证的增长，并将“数据驱动”变成了高管层的口头禅。而且，它的确达到了目的。至少在一段时间内是这样。 智能体人工智能已经使它过时了。 如今，制约组织智能发展的不再是查询权限，而是连接原始数据和业务决策的知识层的质量。更紧迫的问题是速度——仪表盘本质上是被动的，只有在用户主动查找后才能提供洞察，而业务领导者越来越需要在事件发生时就能获得答案。智能体系统不会等待用户提问，它们会持续监控、推理并呈现信息。 那是一种截然不同的模式，需要一支截然不同的团队。 智能体人工智能对商业智能功能究竟有何作用 让我们说得更具体些，因为关于人工智能取代分析师的模糊说法对任何人都没有帮助。 智能体分析的最佳应用方式是增强而非取代组织现有的嵌入式商业智能和数据系统——它建立在已有的数据管道、语义模型和治理框架之上，使人工智能代理能够直接在公司现有环境中运行。关键在于“建立在……之上”。没有“直接部署人工智能”的捷径。基础设施必须先存在。语义层必须构建完成。业务逻辑必须编码完成。而且，必须有人来管理它。 正在消亡的是被动的、请求驱动的分析工作流程。智能体人工智能系统可以在几秒钟内完成分析，而分析师手动收集、查询和验证数据则需要两到四个小时。这种时间压缩并非意味着分析师变得无关紧要——相反，它使得分析师的机构知识，如果被正确编码到系统中，其价值将远超以往仅存在于他们头脑中的情况。 转变之处在于：以前分析师的输出是一个查询语句，现在则是一个受控的定义，一百个用户无需提交任何工单即可同时进行查询。 智能体人工智能使数据分析民主化，让组织内的广大用户都能轻松获取数据——业务用户可以提出复杂的问题，并获得简洁明了、对话式的答案，而无需了解 SQL 或任何技术语言。这对领导者的影响显而易见。非技术背景的利益相关者现在有了一个可靠的替代方案，无需再向你的团队寻求帮助。如果你的团队没有构建确保答案准确性的智能层，其他人就会去做——更糟糕的是，人工智能可能会凭空捏造出一个听起来合理的答案。 领导者思维模式问题：关注结果还是关注原因 真正的问题在于此，我就直说了。 目前大多数数据领导者都处于观望状态。他们密切关注着通用商业智能（GenBI）市场的发展，等待观察哪些工具最终胜出，谨慎地开展试点项目，并告诉团队“人工智能将增强而非取代现有业务”。这种说法本身并没有错，但却是一种危险的被动姿态。这是一种等待外部事件明朗化后再确定方向的心态。 那些身居要职的领导者不会坐以待毙。他们做出了如下豪赌：他们组织中的语义层——即对业务指标实际含义进行编码、管理、机器可读的定义——是他们现在能够构建的最有价值的基础设施。而且，他们是在被迫之前就着手构建它。 这两种策略带来的结果差异将十分显著。将人工智能项目成果与可衡量的仪表盘挂钩的分析团队，将改变预算讨论的焦点——不再围绕工具成本，而是围绕可衡量的回报。这种转变将数据职能从成本中心提升为战略资产。率先展开这种讨论的领导者将主导讨论的走向。 身处事业之中意味着要做出那些在没有完全把握的情况下令人感到不舒服的决定： 在GenBI平台完全验证之前，将分析师的精力从报告撰写转移到语义层构建。 在自助查询模式全面投入运营之前，告知利益相关者被动式查询模式即将逐步停止运行。 在组织尚未完全理解原因之前，就通过智能基础设施重组团队角色和 OKR，降低每次洞察的成本。 这种不适感是走在时代前沿而不是落后于时代所要付出的代价。 重新思考组织设计：从服务台到智能基础设施 组织架构设计问题是大多数数据领导者遇到的瓶颈。当前的组织结构既熟悉又稳定，并且与利益相关者的关系紧密相连。要改变它，就必须正视组织结构本身存在问题这一事实。 如今大多数 BI 团队都是按照领域相关的服务职能构建的： 这种设计旨在优化对各个利益相关群体的响应速度。每位分析师都拥有一个队列、一组关系以及一套领域知识。问题在于，这三者——队列、关系和知识——都属于个人，而非系统。当分析师离职时，这些知识也随之流失。当队列增长时，系统会聘请另一位分析师。当利益相关方需要新的仪表盘时，则由工程师负责构建。 传统商业智能 (BI) 的局限性意味着只有经过培训的分析师才能获取洞察，或者需要 BI 团队的参与，而且报告反映的是历史数据，而非未来预测或可执行的建议。服务台模式在结构上无法改变这一点。它的规模与员工人数呈线性增长，并且只能生成特定时间点的快照，而非动态的智能层。 GenBI 时代的团队设计遵循不同的原则：一次编码，处处可用。但支撑这一理念的结构模型并非重新集中化的分析功能，而是联邦式结构。领域团队拥有各自的数据产品，而中央平台团队则拥有运行所有这些产品的基础设施。这就是应用于智能体人工智能时代的“数据网格”原则。 这个设计中有几点值得一提。 平台团队是赋能者，而非守门人。其职责是提供基础设施、标准和工具，使领域团队能够独立构建和发布数据产品——包括语义引擎、GenBI 运行时、治理框架和数据目录。平台团队不拥有业务逻辑，业务逻辑属于各个领域。 每个领域团队都是一个全栈数据产品单元。它包含语义知识（负责编码业务定义的专家）、构建能力（负责构建和维护转换层的分析工程师）以及对两者都负责的领域专业知识。如果商业团队对客户流失的定义有误，则由商业分析负责人负责，而不是由与业务背景相隔三层的集中式 BI 部门负责。 在这次转型中，分析工程师的角色最被低估。在旧模式下，分析工程师是 dbt 开发人员——他们编写 SQL 转换、建模数据并构建分析师查询的干净表。在新模式下，他们是智能层本身的架构师。原因如下：一个成熟的 dbt 项目不仅仅是一个转换库，它是一个结构化、版本控制且文档齐全的知识库。每个 dbt 模型都有名称、描述、列级文档以及内置的业务逻辑测试。在 dbt 语义层中定义的每个指标（通过 dbt Metrics 或 MetricFlow）都是一个机器可读的业务定义，并附带一个血缘图。这正是 Vanna 和 Wren AI 生成准确、上下文相关的 SQL 所需的训练语料库。懂得如何将 dbt 项目作为 GenBI 训练源的分析工程师并非在做一份新工作——他们只是以更高的效率完成现有工作。他们不再构建分析师查询的模型，而是构建用于训练所有人都在查询的 AI 的模型。 dbt 存储库成为动态语义层，随着业务的发展不断更新，自动向智能层提供受管控的定义，而无需从头开始手动标注。 每个领域的分析主管都是一种新型角色。他们并非负责协调分析师工作的经理，而是资深实践者，负责该领域语义层的产品开发，包括其覆盖范围、准确性、治理以及随着业务变化而不断演进。他们参与业务部门领导层的讨论，了解决策内容以及支持这些决策所需的定义。 跨域指标由统一的部门进行管理。跨越多个领域的指标——例如公司总收入、综合客户获取成本、综合客户流失率——通过相关领域负责人参与的联合流程进行定义，并由平台团队的治理层批准。任何单一领域都无权单方面拥有这些指标。这是大多数数据网格实现方案设计不足的棘手治理问题，需要明确的设计而非假设。 从纸面上看，人员编制可能与现在差不多。但问责模式却截然不同。知识不再属于个人，而是属于版本化、文档化和管理化的领域数据产品。即使管理员离职，语义层依然保留。随着业务发展，领域负责人会更新定义。智能基础设施将成为组织资产，而非依靠机构记忆和Slack聊天记录维系的个人专业知识集合。 真正有效的技能提升计划 大多数组织中关于技能提升的讨论都缺乏正确的视角。领导者宣布启动“人工智能技能提升计划”，购买平台许可，并衡量在线课程的完成率。三个月后，分析师的行为却没有任何改变。 这种方法行不通，因为它把技能再培训视为学习问题。实际上，它是一个工作设计问题。 人们很容易急于在所有岗位上同时提升GenAI素养，但正确的方法是从业务成果入手，思考人工智能投资如何促进或加速这些成果的实现，然后再明确实现这些成果所需的技能。如果只注重技能而忽略成果导向的再培训，最终只会培养出证书收集者，而非真正具备实践能力的从业者。 以下是商业智能和分析职能部门进行转型时，有效的技能再培训的具体内容： 第一层级：面向所有分析师的人工智能素养（第 1-4 周） 团队中的每位分析师都需要对 GenBI 工具的运作方式有一个清晰的理解——不是如何配置，而是它们的准确性如何取决于底层语义层的质量。这是基础。如果没有这个基础，分析师就会把 GenBI 当作玩具，而不是他们负责构建和管理的系统。 实用形式：每周一次 90 分钟的工作坊——一部分讲解概念，一部分使用您的实际数据和 GenBI 平台进行实践操作。使用您自己的指标作为培训材料。标注您自己的查询。学习与实践密不可分。 第二层级：高级分析师的语义策展技能（第 5-12 周） 这才是真正技能提升的关键所在。高级分析师需要学习如何系统地将 SQL 知识转化为结构化的语义定义。具体技能包括： 编写精准的业务定义，消除歧义 识别并记录对指标的常见误解 对 GenBI 工具可作为训练数据接收的注释进行结构化处理 运行验证测试——使用利益相关者提出的相同问题查询 GenBI 层，比较输出结果，并进行迭代。 为期 12 周的课程可以将初级分析师培养成人工智能运维专家——对于拥有深厚领域知识的高级分析师来说，转型速度更快。他们的专业知识是原材料，课程教他们如何将其转化为实际应用。 第三层级：面向 GenBI 的分析工程（第 3-6 个月） 这是最直接、最具杠杆效应的技能提升发生的地方——也是大多数组织错失重大价值的地方。 已经使用 dbt 的分析工程师拥有一个尚未被广泛理解的优势。一个维护良好的 dbt 项目本身就是一个语义知识库。模型描述、列级文档、dbt 测试和 MetricFlow 指标定义都是结构化、机器可读且版本化的工件。Vanna 基于 RAG 的训练管道可以直接将 dbt 模型 YAML 文件作为文档源导入。Wren AI 的原生 dbt 集成意味着您可以连接现有的 dbt 项目，并完全跳过手动语义层设置——转换层本身就成为了训练语料库。 因此，分析工程师的技能提升并非从零开始学习新工具，而是学习如何编写以 GenBI 使用为导向的 dbt 文档： 模型描述应解释业务目的，而不仅仅是技术结构 列描述应定义业务含义，而不仅仅是数据类型 dbt 测试对每个指标的“正确”状态进行编码，并将失败结果作为语义层治理信号呈现出来。 MetricFlow 指标定义使业务计算更加明确、可重用且可供 AI 查询 一位分析工程师如果在整个数据库项目中系统地执行此操作，实际上就为 Vanna 或 Wren AI 预先构建了语义层。原本需要语义标注员花费数周时间才能从原始 SQL 数据中手动完成的标注工作已经完成——只需根据业务上下文编写合适的代码，即可用作 GenBI 训练数据。 此层级的学习工具：选取一个领域的数据库项目，审核文档完整性，重写模型和列描述以符合 GenBI 就绪标准，连接到 Vanna 或 Wren AI，并测量修改前后的查询准确率。差值即为概念验证。 什么因素加速了这三个层次的发展： 将技能提升与绩效目标直接挂钩。语义覆盖率、自助服务采用率和人工智能数据产品使用率是新的关键绩效指标 (KPI)。当职业发展取决于构建智能层而非处理查询时，分析师就能更快地适应新模式。 引入适当的激励措施可以激发员工的学习意愿，而让高管团队走在变革的前沿至关重要。如果数据副总裁仍然以仪表盘交付量和工单解决率来衡量团队绩效，那么无论技能提升计划的质量如何，最终都将以失败告终。 责任归属：当人工智能出错时，谁该负责？ 这是大多数 GenBI 实施项目在出现问题之前都会回避的治理问题。但这个问题无法回避。 当业务用户向 GenBI 平台询问“我们上季度的转化率是多少？”却得到错误答案，并据此采取行动时，谁该为此负责？不是人工智能，也不是平台供应商。责任在于拥有生成该答案的语义定义的人。或者，如果没有人负责，那么责任就在于允许未经监管的人工智能输出结果传递给决策者的数据负责人。 这才是所有权真正发挥作用的地方，而不仅仅是激励作用。 语义层中的每个指标都需要一个负责人。该负责人负责： 业务定义的准确性 对支撑它的 SQL 进行验证 随着业务发展，需要定期审查该定义。 输出错误时的事件响应 这并非官僚主义，而是确保大规模部署 GenBI 系统可信度的最低限度治理结构。人工智能治理需要透明度、审批门槛和决策监控——这些措施确保人工智能代理以负责任的方式运行，与现有 BI 系统无缝集成，并交付可衡量的业务成果。 实际上，情况如下： 指标注册表：一份动态文档（或者更准确地说，它本身就是一个受监管的数据产品），它将语义层中的每个指标映射到所有者、定义、上次验证日期以及负责签署定义的业务利益相关者。 语义审查频率：每月或每季度，由审核员审查使用率最高的指标，根据当前的业务实际情况验证其定义，并标记偏离最初意图的指标。 查询审计跟踪：GenBI 的每个输出都可追溯到生成它的语义定义——这不仅便于调试，还能满足受监管行业和财务职能部门所需的审计置信度。 在需要之前就构建好这一治理层的团队将赢得信任。而在事件发生后才构建的团队则需要花费数月时间才能恢复信誉。 衡量投资回报率：数据领导者需要的框架 大多数数据转型项目在第二年就夭折的原因并非技术故障，而是无法用首席财务官和首席执行官能够理解的方式阐明投资回报率。 “我们减少了分析师的工作量”不是一个商业案例。“我们在保持员工人数不变的情况下，将可决策范围扩大了5倍”才是。 以下是我用来衡量 GenBI 转型效果的 ROIC 框架： 一支中等规模的分析团队（8-12人）预计在12个月内总共需要投资30万欧元至60万欧元，其中包括过渡期间的生产力下降。 三个值流： 第一部分：分析师能力的恢复 追踪转移到自助服务的重复性查询百分比。如果您的团队目前每月处理 200 个临时请求，而自助服务吸收了其中 70%，那么您就释放了相当于 2-3 名分析师全职员工的产能。这些产能可以重新部署到语义层构建和 AI 产品开发中——从而实现收益的倍增，而不是仅仅通过裁员来获取。 第二部分：决策速度和质量 一项针对 500 家公司的 2025 年研究表明，智能人工智能系统可将任务完成时间缩短 34%，并将资源利用率提高 14%。对于那些洞察延迟会直接影响收入的业务职能——例如定价决策、营销活动优化和客户维系措施——这种时间缩短会带来可量化的损益影响。请与您的首席财务官合作，将决策延迟缩短一天所带来的收入与最具价值的应用场景挂钩。 第三部分：数据消费者规模 旧模型的扩展是线性的：增加一名分析师，活跃数据用户数量也会相应增加。新模型的扩展是指数级的：构建一个完善的语义层，就能吸引数百名活跃用户。将每周/每月活跃数据用户数 (WAU/MAU) 作为核心指标进行跟踪。如果您的团队目前服务于 50 位活跃数据用户，而 GenBI 层在 12 个月后服务于 250 位用户，那么您的每次洞察成本计算的分母就降低了 5 倍。这就是其商业价值所在。 ROIC 计算（示例）： 第一年投资：450,000 欧元； 分析师产能回收：180,000 欧元（重新部署 3 名全职员工）； 决策速度价值：200,000 欧元（保守估计，主要用例的延迟降低）； 消费者规模价值：120,000 欧元（避免了未招聘分析师的成本）； 第一年总回报：500,000 欧元； 第一年投资回报率：11% ；第二年（复利增长）： 持续投资：150,000 欧元（平台 + 维护）； 回报（扩展层）：650,000 欧元；第二年投资回报率：330%+ 第一年的投资回报率并不高——这对于基础设施投资而言属于正常现象。能够带来高投资回报率的团队从一开始就注重价值创造，而非为了学习而学习，并且着眼于整体转型，而非仅仅关注单一用例。第二年的回报体现了构建完善的语义层的复利效应。第一年标注的每个指标在第二年都无需任何维护成本。第二年新增的每个数据使用者也无需占用额外的分析师资源。 你应该和你的首席财务官谈谈：不是“我们需要为人工智能工具制定预算”，而是“我们正在构建一个智能基础设施，为更多决策者提供服务的边际成本接近于零”。 分析师现在需要做什么 如果你是以分析师而非领导者的身份读到这里——那么这一部分就是为你准备的。 我所描述的组织架构重塑并非假设，而是已经在一些快速发展的组织中实施。能够展现适应能力而非仅仅具备技术能力的专业人士正变得不可或缺——沟通能力、利益相关者管理能力和数据叙事能力正日益与硬技能一起出现在职位描述中。 能够在这种转型中脱颖而出的分析师都具备一个共同的特质：他们不把SQL知识视为可按需部署的个人技能，而是将其视为需要编码、管理和扩展的机构知识。这种转变的重点在于从“做事”转向“构建能够执行操作的系统”。 具体而言： 立即开始编码。提取过去 90 天的查询记录。针对每个重复出现的指标，编写结构化的注释——包括业务问题、精确定义、常见误解以及经过验证的 SQL 语句。不要等到公司强制要求才开始。这是你的作品集，它能在正式设立语义注释员职位之前就展现你的相关技能。 学习工具，而不仅仅是概念。在个人环境中搭建 Vanna 或 Wren AI 系统。向它输入你标注过的查询。测试它。找出它的问题所在。理解它在哪里失败以及失败的原因——因为这些失败总是源于文档的缺失，而弥补这些缺失正是语义策展人的核心工作。 重新定位你对利益相关者的价值。如果分析师说“我来解答你们的数据问题”，那么他很容易受到攻击。但如果分析师说“我管理的系统能够可靠地解答你们的数据问题”，那么他就不会那么容易受到攻击。这种重新定位不仅仅是语言上的改变——它要求你真正去构建这个系统。但这种框架对于领导层如何看待你在转型过程中的角色至关重要。 要勇于承担责任。指标所有权——即作为业务定义准确性的指定负责人——是一种新型的职业责任。它比编写仅供自己审核的查询语句更具风险性。要积极应对。那些承担情报层责任的分析师，将成为组织不可或缺的人才。 窗口是有限的 只有31%的领导者预计能够在六个月内评估人工智能投资的回报率——这意味着大多数人仍处于试验阶段，开展试点项目，观察市场反应。这就是机会窗口。 大多数组织的语义层都是空的。查询库缺乏文档。业务定义只存在于人们的脑海中。这不是一个可以最终解决的问题。对于那些现在就采取行动的领导者和分析师来说，这是先发优势。 到 2027 年，数据功能将具备受管控的、全面的语义层——构建在 GenBI 基础设施之上，服务于数百名非技术决策者，并具有可追溯的投资回报率——这将与那些在确定性之前才采取行动的竞争对手在结构上形成差异。 确定性尚未到来。在智能体人工智能时代蓬勃发展的组织，都是在市场迫使他们做出选择之前，就决定主动出击的组织。 现在你就可以做出决定了。问题是，你是否愿意做出决定。 来源（公众号）：数据驱动智能
