随着重点领域行业高质量数据集的逐步建成，以及“场景—数据—模型—应用”双向循环反馈机制的形成，我国有望建立起一条完备的数据安全供给链。通过全面落实《实施方案》中的各项技术与治理举措，人工智能治理得以在数据输入端筑起坚实的合规屏障，实现技术快速演进与治理体系协同共生的新局面。

AI+数仓不是噱头，它能落地，但需要选对场景、管好预期、打好基本功。别指望AI一步到位解决所有问题，也别因为AI有缺陷就否定它的价值。用对了地方，它就是提升效率的好工具。

最近跟几个做数据治理的朋友聊天，大家的焦虑感出奇地一致：大模型在元数据标注、数据质量检测、血缘分析这些场景上越做越好，很多以前需要人工干的活，AI能自动干了。那数据团队以后还能干什么？ 这个问题问得好，也问得及时。2026年以来，AI+数据治理已经成为行业共识——IT之家、天极网等多家技术媒体近期发布的分析报告都指出，数据治理平台正在从"被动规则引擎"转向"主动智能协同中枢"。三维天地、数语科技等厂商也相继推出了AI驱动的治理产品。 但我想先把一个关键认知摆在这里：AI接管的不是数据团队的工作，而是数据团队工作中那些重复性高、标准化程度高的部分。剩下的部分——策略制定、复杂判断、跨部门协同、业务价值评估——恰恰是数据团队真正应该投入精力的地方。 一、AI在数据治理中到底能干什么？ 在讨论"数据团队该干什么"之前，先明确"AI能干什么"。目前来看，AI在数据治理中的价值主要集中在四个场景。 场景一，元数据智能管理。传统模式下，元数据的采集、标注、分类分级几乎全靠人工——逐张表、逐个字段地写注释、定义业务含义。大模型在自然语言理解上的能力，可以自动识别字段的业务语义、推断数据分类、推荐数据分级建议。人需要做的是审核和确认，而不是从零开始标注。 场景二，数据质量智能检测。传统数据质量治理依赖人工定义检核规则——空值检查、格式校验、一致性比对等。AI可以从历史数据中自动发现异常模式，推荐质量检核规则，甚至预测潜在的数据质量问题。比如AI发现某个字段的值分布突然发生偏移，可能是上游系统变更导致的，它会主动预警，而不是等问题被业务方投诉了才发现。 场景三，数据血缘自动追踪。传统血缘分析依赖人工维护或工具半自动采集，覆盖范围有限且容易断裂。AI可以通过分析SQL逻辑、ETL脚本、API调用链路，自动生成端到端的数据血缘图谱，并在数据变更时自动评估影响范围。 场景四，合规风险智能识别。随着《数据安全法》《个人信息保护法》的实施，数据合规成为治理重点。AI可以自动识别敏感数据字段（如身份证号、手机号等），匹配合规策略，并生成合规风险报告，帮助团队提前发现潜在的合规风险。 下面这张图展示了AI与人在数据治理中的协作关系。 从图1可以看出，AI和人各有分工、相互配合。AI负责执行和辅助，人负责决策和审核。这个关系定义清楚了，后面的事情就好 二、AI治理的能力边界在哪？ 谈AI赋能，不能只说好处不说局限。AI在数据治理中能做到什么程度，我画了一张成熟度模型来界定。 如图所示，我把它分成了四个层级。需要客观说明的是： L1（人工规则驱动）是目前不少企业所处的阶段。治理工作高度依赖人工，效率低但可控。这个阶段不丢人，关键是要有向L2升级的意识。 L2（AI辅助治理）是当前可行的目标。AI负责生成初稿（规则、标注、报告），人负责审核确认。这个阶段投入产出比相对较高，也是目前头部厂商产品主推的方向。 L3（AI深度参与）需要较强的数据基础。要让AI主动检测异常、推荐治理策略，前提是元数据完善、数据质量基线清晰、治理流程标准化。如果这些基础没打好，AI的能力也无法充分发挥。 L4（自治治理）目前更多是愿景。完全由AI自主处理治理任务、人只在关键节点把关——这个目标在技术上还有不少挑战需要克服，短期内不建议作为企业的主要目标。 务实建议：大多数企业应该把目标定在L2到L3之间——让AI承担执行层面的重复工作，让人聚焦于策略和判断。不要被厂商的营销话术带着跑，以为买了个AI治理平台就能直接跳到L4。 三、数据团队的角色怎么变？ AI接管的越多，数据团队就越需要重新定义自己的价值。我用一张图来说明这个转变。 如图所示，数据团队的角色正在从"治理执行者"转向"数据资产运营者"。具体来说，有四个变化。 3.1 从 写规则 到 审规则 以前数据团队的大量精力花在编写和维护数据质量规则上——一张表几十个字段，每个字段可能需要好几条检核规则，几百张表下来就是海量的规则维护工作。AI介入后，这部分工作可以大幅缩减。AI根据数据特征和历史模式推荐规则，数据团队的重点变成审核这些规则是否合理、是否覆盖了业务关注的质量维度。 3.2 从 做治理 到 建体系 AI能帮你发现数据质量问题，但"发现之后怎么办"需要人来设计：这个质量问题由谁负责？修复优先级怎么排？跨部门的数据口径冲突怎么协调？这些是治理体系建设的问题，AI替代不了。数据团队需要把更多精力放在治理组织架构、流程机制、考核标准的建设上。 3.3 从 对内支撑 到 对业务赋能 传统数据治理大多是"对内"的——给技术团队用、给数据团队用，业务方的感知很弱。AI介入后，数据团队可以从重复性工作中释放出精力，去思考一个更关键的问题：治理的成果怎么转化为业务价值？比如，数据质量提升之后，报表的准确率提高了多少？决策效率改善了多少？这些量化评估能让业务方看到治理的实际价值，从而更愿意配合治理工作。 3.4 从 被动响应 到 主动运营 以前数据治理的模式是"出了问题再处理"——业务投诉数据不准，再去排查修复。AI的主动检测能力让"事前预防"成为可能。数据团队可以基于AI的预警信息，提前介入处理潜在的数据风险，把治理从被动响应转变为主动预防与持续优化。 四、落地过程中容易踩的坑 基于行业观察和实践经验，总结几个常见的坑。 坑一，跳过基础建设直接上AI。有些团队元数据管理还没做起来、数据标准还没建立、质量基线都没量，就急着引入AI治理工具。结果AI生成的建议质量很差——因为连AI都不知道哪些字段是什么含义。数据基础是AI治理的前提，这个顺序不能颠倒。 坑二，把AI治理当成纯技术项目。数据治理本质上是一个管理问题。AI能提升治理的执行效率，但"数据标准由谁制定""质量不达标的责任怎么界定""跨部门数据冲突由谁协调"这些管理层面的问题，AI解决不了。必须有配套的治理组织、流程和机制。 坑三，期望AI完全自动化。目前阶段，AI在数据治理中更适合"辅助"定位。让AI自动执行所有治理任务、完全不需要人工介入——这个目标在当前技术条件下不现实。尤其在涉及敏感数据分级、合规判断等场景，人工审核环节不能省。 坑四，忽视AI自身的治理风险。网易的一篇文章提到，当AI Agent从"能对话"演进到"能执行"时，其引发的数据治理与安全风险较传统AI显著提升。比如AI在执行数据治理任务时可能误操作敏感数据，或者AI生成的治理规则本身存在偏见。因此，对AI的治理行为本身也需要建立监控和约束机制。 五、几个关键的优化建议 最后，给几个实操层面的优化建议。 建议一，分场景逐步引入AI，不要贪多。建议从元数据管理和数据质量检测这两个场景切入——这两个场景标准化程度高、效果容易衡量、投入产出比相对明确。验证成功后再逐步扩展到血缘分析、合规识别等场景。 建议二，建立"AI生成+人工审核"的标准流程。无论哪个场景，都应该设计明确的人机协作流程：AI生成治理建议→人工审核确认→执行→记录反馈→优化AI模型。这个闭环是AI治理效果持续提升的关键。 建议三，量化治理效果，让价值可见。AI介入前后，数据质量问题的发现效率提升了多少？元数据标注的人工投入降低了多少？数据治理报告的出具周期缩短了多少？这些量化指标不仅能评估AI治理的实际效果，也能帮助数据团队向管理层和业务方展示治理工作的价值。 建议四，关注AI治理平台的安全与合规。引入AI治理工具时，要确认其对敏感数据的处理方式——数据是否会上传到云端？是否支持私有化部署？对AI的治理行为是否有审计日志？《数据安全法》和《个人信息保护法》对数据处理有明确要求，AI治理工具也必须满足这些合规要求。 六、写在最后 回到开头的问题：当AI介入数据治理，数据团队该干什么？ 答案其实很清楚：AI接管的是"执行"，数据团队应该聚焦于"策略、协同和价值"。制定治理策略、审核AI的建议、推动跨部门协同、量化治理的业务价值——这些才是数据团队在新阶段的核心工作。 换个角度看，AI不是在抢数据团队的饭碗，而是在帮数据团队从繁琐的执行工作中解放出来，去做更有价值的事。关键在于你能不能抓住这个转变的窗口期，主动调整自己的定位和能力结构。 来源（公众号）：华哥聊数据

一、为什么突然都在聊AI+数仓？ 过去两年，大模型的风刮到了数据基础设施领域。从Text-to-SQL到AI辅助建模，从自动化ETL到智能数据治理，各大厂商和开源社区陆续推出一系列工具，试图用大模型改造传统数仓的工作方式。 这个方向的内在逻辑不难理解。传统数仓建设有几大痛点：建模周期长、数据清洗依赖人工规则、ETL链路出问题需要运维半夜爬起来定位。每个环节都存在大量重复性劳动，而这些恰好是大模型擅长的事情——理解自然语言、生成代码、识别模式规律。 但一个有意思的现象是：同样一套技术方案，有的公司用得比较顺畅，建模效率明显提升，数据质量问题大幅减少；有的公司投入了不少资源，折腾了大半年，最后得出的结论是"大模型没啥用"。相似的底层技术，结果差别很大。 这背后的原因在哪？结合我这几年的一线观察，我总结了四个层面的关键分水岭。 二、跑得通的公司，做对了什么？ 1. 先把数据底子打扫干净 这是最基础、也最容易被忽视的一点。跑得通的公司，在引入AI之前，已经完成了数据标准化的基础工作——字段命名规范统一、数据字典完整、指标口径明确、元数据管理到位。大模型进来之后，有标准的元数据做上下文，不需要去"猜"某个字段的业务含义。 反过来，跑不通的公司往往是"数据裸奔"状态。同一个客户ID，CRM系统里叫customer_id，订单系统里叫user_no，日志系统里叫uid。大模型面对这种混乱的局面，别说生成准确的SQL，连理解都费劲。很多项目一上来就希望大模型"端到端"解决问题，结果数据质量不过关，大模型输出的东西也是错的，团队信心一下就被打没了。 一个判断标准：如果你现有的数仓连基本的指标口径都没有对齐，先别急着上AI。把标准定了，把字典建了，再谈大模型赋能。 2. 选对了切入点，从小场景开始跑 从我了解到的情况来看，跑得通的公司通常遵循"小切口、速赢"的策略。很多不会一上来就搞一个"企业级AI平台"，而是先挑一个高频、痛点明确、价值可量化的场景。 比如： Text-to-SQL查询：让业务人员用自然语言查数，减少数据开发写SQL的重复需求 数据质量自动稽核：用大模型识别异常数据，补充人工校验规则的不足 元数据自动补充：根据表结构和业务上下文，自动生成字段描述和业务定义 这些场景的共同点是：边界清晰、见效快、业务方感知强。一旦跑通一个场景，团队信心建立，后续推进其他场景就容易得多。而一上来就想"用AI重构整个数仓体系"的公司，项目周期拖得太长，业务方耐心耗光，往往无疾而终。 3. 懂得"什么该交给AI，什么不该" 这是很多技术团队容易忽略的问题。大模型不是万能的，也不是所有任务都适合交给它。从我观察到的做法来看，跑得通的公司普遍建立了一套分层分工机制： 任务类型 处理方式 典型场景 简单、规则明确的 传统脚本/SQL 基础数据校验 固定报表查询 复杂、需要语义理解的 大模型处理 模糊查询转SQL、异常归因分析 高频且对延迟敏感的 轻量级模型或规则引擎 实时数据质量拦截 低频且对准确度要求高的 大模型+人工审核 复杂建模、数据口径映射 核心原则是：大模型只做"需要理解能力"的事情，不碰"可以用规则解决"的事情。这样做既能控制调用成本，又能保证效率和准确率的平衡。 三、跑不通的公司，踩了哪些坑？ 坑一，数据没清干净就上AI 最典型的场景是：企业把全量业务数据直接丢给大模型，期望它自动完成清洗和治理。结果大模型面对各种不一致的字段、缺失的关联关系、混乱的编码体系，输出的数据质量大打折扣。 举个常见的例子：供应商名称这个字段，在不同业务系统里可能写成完全不同的格式——全称、简称、中英文混写、带标点不带标点。如果不在入库前做标准化映射，大模型花再多精力去"理解"这些变体，效果也不如先把数据洗干净再喂给模型。这背后是一个基本的顺序问题：AI不能替代数据治理，但它能加速已经标准化的数据治理流程。顺序反了，结果就是事倍功半。 坑二，一上来就搞"全场景覆盖" 这个问题在传统IT项目中就常见，到了AI时代被放大了。从我的经验来看，AI项目的不确定性比传统项目更高，因为你无法预判大模型在某个具体场景下的表现。场景越多，不确定性叠加，项目失败的几率也随之上升。 常见的情况是：公司成立AI+数据专项组，目标同时覆盖销售、运营、供应链、客服多个场景，预算和周期定得很高。结果几个月过去了，连第一个场景还没跑通——每个场景都需要不同的数据准备、不同的Prompt调优、不同的评估标准。资源有限却全面铺开，很容易每个场景都做不透。 一个务实的建议：如果团队还在探索阶段，先集中资源打穿一个场景，验证了价值再横向复制。 坑三，技术部门单干，业务部门不参与 大模型需要"学"业务知识。如果业务部门不参与需求定义、不提供高质量的业务语料、不参与结果评估，大模型生成的SQL和模型很可能跟实际业务需求对不上。 举个例子，"计算客户流失率"这个需求，不同部门的理解可能完全不同。销售部门认为"三个月未下单"就算流失，运营部门认为"六个月未登录"才算，财务部门可能按"账户余额为零"来定义。口径差异，大模型自己是"悟"不出来的。 坑四，忽视成本与效率的平衡 大模型的API调用成本因模型和厂商而异，按token计费的模式下，高频调用会产生一定的开销。如果所有数据操作都走大模型，月结时的费用可能会比较可观。 比如，日常的GMV查询、转化率报表这类高频查询，用大模型走一遍自然语言转SQL，延迟可能比直接跑一条预计算的SQL慢不少，调用成本也更高。把任务分层——高频、确定性高的走规则引擎或预计算，低频、模糊的走大模型——可能是更合理的做法。 四、优化方向，怎么从"跑不通"变成"跑得通"？ 方向一，从高频痛点场景切入，快速验证 如果你的公司还在探索阶段，可以考虑从这些场景入手： 数据质量稽核：大模型识别异常数据的能力在一些场景下已经具备实用价值，落地门槛相对较低 元数据自动补全：基于表结构和字段名生成业务含义描述，能较快提升数据字典的覆盖率 自然语言查询（Text-to-SQL）：适用于报表需求频繁、数据开发资源紧张的团队 ETL脚本辅助生成：适合数据量大、重复性ETL任务多的场景 每个场景建议先做小范围POC验证，确认价值后再投入资源做生产化。 方向二，建立闭环验证机制 大模型输出结果建议配合人工确认机制： 项目初期：人工复核比例适当提高，重点关注大模型输出是否符合预期 稳定期：复核比例逐步降低，同时建立自动化监控基线 成熟期：通过bad case反向驱动模型和Prompt的持续优化 每次发现大模型输出有误，记录下来分析原因——是Prompt写得不够精准？是数据本身有问题？还是场景超出了模型的能力边界？这些积累会成为后续优化的重要基础。 方向三，数据安全底线不能破 数仓里存储着大量业务数据和用户信息，直接送到公有云大模型接口存在合规风险。在实际落地中，建议做到： 敏感字段（手机号、身份证、邮箱等）在输入大模型前进行脱敏处理 所有API调用留存审计日志 明确数据使用边界，不超出业务需要的范围 有条件的企业可优先考虑私有化部署方案 五、未来展望，AI+数仓会走向哪里？ 从过去两年的行业实践来看，AI+数仓的发展有几个方向已经逐渐清晰： 第一，AI辅助能力会逐步融入数仓工具链。就像OLAP引擎成为数仓标配一样，AI辅助建模、智能数据质量稽核、自动化运维诊断等能力，在未来几年可能会成为数据平台的基础功能。企业需要思考的不是"要不要用"，而是"用在哪些环节最合适"。 第二，不同规模的模型会协同工作。大模型擅长复杂推理和语义理解，在需要"理解"的场景下优势明显。而小模型或规则引擎在处理高频、确定性任务时，在成本和响应速度上更具优势。两者配合使用，可能是更务实的方案。 第三，数据治理的重要性不会降低，反而会提升。AI越强，对数据质量的要求越高。一条不准确的数据口径，经过大模型处理后，可能产出一份看起来逻辑严谨但结论错误的报告。数据治理不是可以被AI替代的工作，而是需要和AI同步加强的基础工程。 第四，人机协同是现阶段较为可行的模式。短期内"AI替代数仓工程师"不太现实。更务实的路径是：AI处理重复性、规则清晰的常规任务，人工负责复杂决策、异常处理和效果兜底。从我接触到的案例来看，这个分工模式在成本、效率和质量三个维度上综合表现不错。 最后说句实在话：AI+数仓这件事没有捷径。先把数据管好，选对场景，边界划清楚，再让AI进来干活。按这个顺序走，大概率能跑通。反过来，跳过前两步直接上AI，十有八九要交学费。 来源（公众号）：华哥聊数据

做数据这行的朋友，大概都熟悉这个流程：业务抛过来一个取数需求，你得先搞清楚人家说的"活跃用户"到底是哪个口径，然后翻表结构写SQL，跑完数还得跟业务对齐一遍，"这个数字跟你预期差多少？"整个流程走下来，快的两三天，慢的一周都不稀奇。 但2026年的风向已经很明朗了，这一切正在被Agent改写。 微软在Fabric里嵌入了Data Agent，阿里云推出了Agentic Lake，安克创新也在公开场合分享了第三代AI数据平台的架构设计。这些头部玩家不约而同在做同一件事：让数据仓库从一个"被动等着你查"的存储系统，变成一个"能理解你要什么、能自己想清楚该怎么做"的智能体底座。 这不是PPT上的画饼。接下来，我会基于当前已经公开的行业实践和技术走向，把Agent和数仓融合这件事拆开讲清楚，进展到哪一步了、架构长什么样、落地有哪些坑。 一、先纠正一个认知偏差，Agent要改造的不是数仓本身 很多人的第一反应是"Agent要替代数仓"，这个理解是有偏差的。 数据仓库真正的护城河，统一的数据存储、标准化的建模体系、稳定的计算性能，这些东西Agent替代不了，也不需要替代。Agent改变的是另外两件事：第一，人和数仓怎么打交道；第二，数仓自己怎么管自己。 具体来说，Agent在数仓场景里解决三个层面的问题： 门槛问题。业务人员不用再学SQL了，说人话就能查数据。但要注意，这跟早年那些"自然语言查数"产品有本质区别。那些产品本质上是个翻译器，你问一句它翻一句SQL，准确率惨不忍睹。Agent的做法是：先理解你的业务意图，再决定查哪些表、怎么关联、用什么口径，生成SQL之后还会自动校验，语法对不对、业务规则有没有违反、跑出来的数据合不合理，全部过了才给你结果。 效率问题。数据治理、质量监控、ETL调度这些日常运维工作，Agent能扛下来大部分。自动发现数据异常、沿血缘链路追踪问题源头、生成治理报告，这些以前需要数据工程师花大量时间做的事情，现在可以让Agent去跑。 决策问题。传统数仓的交互模式是"你问它答"，本质上是被动的。Agent驱动下的数仓能主动发现问题、提出建议，甚至在明确规则下直接执行修复。这形成了一个"感知-分析-决策-执行"的闭环，数仓从"被查询的工具"变成了"主动服务的系统"。 二、数仓架构的三代演进 要把Agent和数仓融合这件事讲透，得先把数仓自身的演进脉络捋清楚。大致可以分成三代： 第一代：传统数仓（约2000-2015年）。关键词是"批处理ETL +固定报表"。数据通过定时任务从业务库同步到数仓，工程师写ETL脚本做清洗转换，分析师写SQL出报表。这套东西跑起来很稳，但太笨重了，业务要加一个分析维度，可能要改好几个层级的表结构和ETL脚本，响应速度跟不上。 第二代：湖仓一体+语义层（约2015-2024年）。数据湖解决了非结构化数据的存储问题，湖仓一体进一步把存储和计算打通。语义层（比如dbt的Semantic Layer）让指标定义有了统一标准，业务方理论上可以自助取数了。但"自助分析"的门槛还是不低，你得懂数据模型，还得学BI工具怎么用。 第三代：Agent原生数据平台（2025年起）。在湖仓和语义层的基础上，Agent作为一层"智能中间件"插进了人和数据之间。它能理解自然语言意图、自动编排数据访问路径、自主执行治理任务。数仓不再只是个"存储+计算引擎"，而是一个具备感知和执行能力的智能体底座。 三、Agent原生数据平台的五层架构 综合微软Fabric、阿里云Agentic Lake、安克创新等公开实践，Agent原生数据平台的架构可以拆成五个层次。下面逐层讲。 1. 交互层：业务侧的入口 交互层支持文字、语音、图片等多模态输入。用户用自然语言描述需求，比如"帮我看看华东区上个月各品类的销售走势"，交互层负责把这个模糊的需求转成结构化的任务指令。 这里有一个关键的行业认知需要澄清：交互层的核心不是做一个"好看的聊天框"，而是意图理解的准确率。直接拿通用大模型来理解业务查询，准确率通常只有60%-70%，离生产可用差很远。真正的解法是在交互层和Agent编排层之间加一层语义校验机制，Agent生成的SQL要过三道关：语法校验、业务规则校验、数据合理性校验，全部通过后才返回结果。 2. Agent编排层：多智能体协作的中枢 这是整个架构的核心。它不是一个Agent单打独斗，而是一个由多个专业Agent组成的协作网络。根据当前公开案例，常见的Agent角色包括： Agent角色 核心职责 当前成熟度 意图识别Agent 解析自然语言，识别查询意图、筛选条件和聚合维度 较高 SQL生成Agent 基于语义层和元数据，生成可执行的SQL 较高 数据质量Agent 监控数据质量异常，自动触发告警和修复 中等 ETL调度Agent 智能调度数据同步任务，处理依赖和异常 中等 指标管理Agent 维护指标定义，检测口径冲突，自动对齐 早期 多个Agent之间怎么协作？当前行业主流的做法是"编排式"架构，一个中央编排器（Orchestrator）根据任务类型分派给对应的专业Agent。好处是可控、可审计；缺点是复杂任务的协作规则需要预先定义，灵活性受限。 另一种是"对等式"多Agent架构，各Agent自主协商完成任务。但目前基本还在学术研究阶段，企业级生产环境落地的案例非常少。 3. 语义与知识层：Agent的"业务常识" 这一层是Agent准确理解业务的前提。没有语义层，Agent就像一个精通SQL语法但完全不懂业务的人，能写出语法正确的查询，但结果可能南辕北辙。 语义层的建设核心包括三块： 业务词汇表。定义业务术语与物理表字段的映射。比如"活跃用户"在不同业务场景下怎么算、数据从哪来、计算逻辑是什么。这是Agent理解业务意图的地基。 知识图谱。存储数据之间的关联，数据血缘、指标依赖、业务实体关系。Agent做根因分析时，需要沿着图谱的关联路径进行推理。 指标存储。标准化的指标定义和管理，保证同一个指标在不同Agent、不同场景下的计算结果一致。 阿里云在2026年峰会上提出的"Agentic Lake"架构，核心思路就是把DLF（数据湖管理平台）升级成Agent的"记忆底座"，让Agent记住企业的数据资产关系、业务口径和历史交互上下文。这个思路很关键：语义层不只是翻译字典，更是Agent的长期记忆。 4. 数据存储与计算层 这一层本质上还是湖仓一体的存储和计算引擎，架构层面变化不大。核心组件包括数据湖（Iceberg/Hudi/Delta Lake）、数仓计算引擎（Spark/Flink/StarRocks等）、实时和离线两条计算链路。 Agent在这一层的价值主要体现在执行优化上，根据查询特征自动选择最优的计算引擎和资源配比，而不是靠人工经验配置。Snowflake的Cortex和Databricks的AI/ML功能已经在这个方向上做了不少探索。 5. 数据源层 结构化数据库、日志系统、SaaS应用、IoT设备、文件系统等，与传统架构没有本质区别。但Agent可以自动化完成更多的数据接入和Schema推断工作，降低运维成本。 四、数据治理，Agent最有可能率先规模化落地的场景 数据治理是数仓运营中最吃人力、也最容易被Agent改造的环节，值得重点展开。 传统的数据治理高度依赖人工，工程师发现问题、分析原因、修复问题、更新文档。整个链路是被动响应式的，出了事才处理，效率很低。 Agent驱动的数据治理，核心转变是从"被动响应"到"主动闭环"，六个环节形成自动化链条： 感知层：Agent充当数据哨兵 通过持续的数据探查（Data Profiling）和变更监控，自动捕捉异常。比如某个字段的空值率从2%突然跳到15%，或者某张表的行数同比减少了30%。这些异常散落在海量监控数据中，人工很难第一时间发现，但Agent可以7×24小时不间断扫描。 理解层：Agent充当数据侦探 发现异常后，Agent沿数据血缘链路追踪问题源头。比如某张报表数据异常，Agent可以自动追溯到上游ETL任务的调度延迟、源表Schema变更、或上游业务系统的数据传输故障。这一步技术难度最高，严重依赖元数据管理的完善程度。 决策层：Agent充当治理参谋 根据异常的严重程度和影响范围，Agent给出处理建议：低优先级问题自动创建工单排队，高优先级问题（如影响核心报表数据）立即告警并推荐修复方案。 执行层：Agent充当自动修复工 对于规则明确的问题（数据格式不统一、字段缺失、编码错误等），Agent可以直接执行修复。对于需要人工判断的问题（如业务口径变更），Agent生成详细的诊断报告和修复建议，交给数据治理专员审核后执行。 需要实话实说：完全自动化的数据治理闭环目前还做不到。行业实践采取的是人机协同策略，Agent处理80%的常规任务，剩下20%需要人类判断的复杂问题交给专员处理。这个比例在未来一两年内有望继续提升。 五、现实的进度条，哪些已经能落地，哪些还在画饼 已经可以落地的场景 Text-to-SQL查询。技术已相对成熟，dbt Copilot、Microsoft Fabric Data Agent等产品已支持生产级使用。前提条件是语义层建设到位，且查询场景相对标准化（如固定维度的销售分析、用户分析）。 自动化数据质量监控。规则明确的质量检测（空值率、唯一性、格式校验等）已可自动化。Agent在此基础上能做异常根因的初步分析和影响评估。 元数据管理和文档生成。Agent可以自动扫描表结构、生成数据字典、维护血缘关系文档。这是目前落地门槛最低的Agent应用场景之一。 仍在探索中的场景 自动化ETL开发。Agent能根据业务需求生成ETL脚本，但复杂的数据转换逻辑（多表Join、窗口函数、自定义UDF等）仍然需要工程师深度介入。当前Agent生成的ETL脚本需要人工Review的比例在60%以上。 智能数据建模。Agent可以根据业务描述建议维度模型的设计（事实表、维度表的选择），但数据建模需要对业务有深度理解，完全自动化尚不现实。 多Agent自主协作。"对等式"多Agent架构在学术层面有不少探索，但企业级生产环境的案例极少，可靠性和可审计性都不够。 一句话概括当前状态：Agent在数仓场景中的定位是"提效工具"，不是"替代方案"。它能显著降低数据消费的门槛、减少治理的人力投入，但离"完全自主运行"还有相当距离。2026年是Agent+数仓从POC走向规模落地的关键年份，但短期内的务实预期是"人机协同"，而非"全自动"。 六、给想动手的团队三条建议 如果你所在的数据团队正在考虑引入Agent能力，基于当前行业实践，有三条务实的切入路径： 第一条，先把语义层建好。语义层是Agent理解业务的前提。没有语义层，Agent就是"瞎子摸象"，能写SQL但不理解业务。语义层建设不依赖AI技术，核心是梳理业务指标体系、定义标准口径、建立术语表。这个工作即便不引入Agent，也是数据治理的基础工程，早做早受益。 第二条，从数据治理场景切入。相比直接让Agent写SQL给业务方用（涉及数据安全和准确性风险），让Agent先承担数据质量监控、元数据管理、文档生成等内部运维任务，风险更低、见效更快。这也是目前行业落地最成熟的路径。 第三条，建立 信任分级 机制。Agent在数仓场景中生成的SQL、做出的治理决策，必须经过可信度分级。高置信度的操作自动执行，低置信度的必须人工审批。微软Fabric Data Agent的设计中就包含明确的权限和审批机制，这个思路值得借鉴。 写在最后 Agent与数据仓库的融合，正在从技术讨论变成工程现实。2026年的信号已经非常清晰：头部云厂商和标杆企业都在围绕Agent重新构建数据平台的能力边界。 但作为从业者，需要保持清醒的认知。Agent不是万能药，不会一夜之间颠覆数仓的底层逻辑。数据仓库的核心价值，统一、标准、可信的数据基座，依然不可替代。Agent真正改变的是"人怎么用数仓"和"数仓怎么管自己"这两件事。 真正值得思考的问题不是"Agent会不会取代数仓"，而是"你的数仓准备好迎接Agent了吗"，语义层是否完善、元数据管理是否到位、治理流程是否标准化。这些基础功课做扎实了，Agent能力的引入才会水到渠成。 来源（公众号）：华哥聊数据

一、传统数仓的“三座大山” ETL脚本上千行，调度任务上百个，元数据却一团乱麻。传统数仓的“三座大山”：开发效率低，一个ETL任务从需求到上线至少两三天；治理靠人工，元数据补全、质量监控还在用Excel维护；分析门槛高，业务方看个数据得排队，分析师70%的时间花在取数上。 2025年至2026年，AI Agent技术突然火了，给这些老问题带来了新解法。这篇文章不扯概念，直接说怎么落地。 二、Agent + 数仓到底是个啥？ 先说清楚，Agent不是来取代数据工程师的，就是个辅助。说白了就是给大模型接上API，让它能看懂元数据、能写SQL、能调接口、能盯着任务跑、出问题了还能自己试着修。数据工程师的角色从“写代码”变成“指挥Agent干活”，把精力腾出来做更有价值的事。 Agent + 数仓的核心逻辑很简单：把那些确定性的、重复的工作交给机器，不确定的、需要判断的留给人。不是无人驾驶，是辅助驾驶。 从架构上看，大概分三层： 三、四个能落地的方向 1. 智能ETL 这个方向目前落地最多。以前做个ETL任务，先跟业务对需求，再写SQL，配调度，上线后发现数据不对还得排查。现在Agent可以这么干：你丢一句“把昨天新增用户按省份汇总”，它自己去查元数据找到对应的表和字段，把SQL写好，跑测试用例校验数据质量，配好调度和告警，任务失败了还能自动翻日志找原因。 我们在一个200多张表、日均500多个任务的数仓上试过，ETL开发效率大概提了60%，数据质量出问题到发现的时间从小时级降到了分钟级。当然，复杂的业务逻辑和模型重构还是得人盯着。 2. 元数据管理 干过数仓的都懂，元数据基本是“欠债”状态。字段没注释、表关系不清楚、口径文档跟实际代码对不上——太常见了。 Agent在这块能干三件事：一是自动补全，读SQL脚本推断字段的业务含义，准确率能到85%以上，人工过一遍就行；二是血缘解析，自动建字段级的血缘关系，上游表结构变了能评估影响范围；三是对口径，对比同名指标在不同报表里的SQL实现，发现不一致的地方标出来。 注意，Agent不是从零建血缘，它是在已有的SQL解析结果上补充业务语义，让血缘关系变得“能看懂”。 3. 数据质量 传统质量监控两个痛点：规则全靠人工配，太累；告警太多，看不过来。Agent的做法是：根据字段的数据类型和分布特征，自动推荐质量规则，你审核一下就行。告警触发了，Agent自动拉上下游数据分析原因，给出修复建议。常见问题像空值填充、格式标准化这些，Agent直接修了，复杂问题生成方案等人确认。 在某电商数仓项目里，质量规则覆盖率从35%干到了79%，误报率降了大概36%。 4. 智能BI 这个场景用户感知最强。业务方直接问“上个月华东区销售额TOP10品类是哪些”，Agent理解问题、查元数据、生成SQL、出结果。追问“按周看趋势”，Agent保持上下文继续往下分析。还能定时扫关键指标，发现异常主动推预警。 但别指望Agent替代分析师，它只是把“取数”这个环节的门槛降低了。真正有价值的洞察，还得靠人。 来源（公众号）：华哥聊数据

数字化转型浪潮下，企业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友好的归纳结构。 企业人工智能的未来不在于选择哪个图论阵营，而在于了解何时需要推断含义，何时需要验证含义，何时需要传递含义，以及何时只需要快速查询。 来源（公众号）：数据驱动智能