现在整个行业都在谈论AI的下一个风口在哪里。 在我看来，AI数据治理就是最大的机会。 随着监管政策的收紧，那些重视数据治理的AI公司将获得巨大优势。而那些忽视数据治理的公司，随时可能因为数据安全问题被淘汰。

来源（公众号）：大数据AI智能圈 凌晨三点，数据分析师小王被电话吵醒。业务方在电话那头急得跳脚："王哥，咱们核心报表的数据又出问题了！用户数怎么突然少了30%？" 这样的场景，在数据圈里简直不要太常见。小王揉着惺忪的睡眼，打开电脑开始"侦探"工作。先问运营最近有没有活动，再问开发有没有改接口，最后还得翻遍所有ETL脚本找问题。等折腾到天亮，问题终于找到了——某个上游系统的数据接口在前一天晚上悄然发生了变化。 这就是数据团队最真实的写照：我们被数据问题绑架，却对数据本身的来龙去脉一无所知。 其实，这个问题用一个专业术语就能解决：数据血缘。 但恕我直言，市面上99%声称"建立了数据血缘"的企业，其实都是在自欺欺人。 从数据黑盒到透明工厂 记得去年在阿里的一次技术交流会上，某位大厂数据负责人说过一句话：**"没有数据血缘的数据平台，就是一个精心包装的数据黑洞。"** 这句话戳中了很多人的要害。 我们不妨想想，为什么Facebook能在用户数据泄露后迅速定位影响范围？为什么Netflix能在推荐算法出现问题时快速回滚？答案很简单——他们对数据的流转了如指掌。 数据血缘的本质，就是给每个数据都装上GPS定位器。 从它出生的那一刻起，途经哪些加工环节，最终流向何处，每一个环节都被完整记录。这不是技术炫技，而是数据治理的基础设施。 在传统的数据平台里，数据就像是被扔进了洗衣机搅了一夜，出来的时候你根本不知道它经历了什么。而有了数据血缘，数据就像有了一张详细的"旅行日志"，每个处理节点都留下了明确记录。 这样做有什么实际价值？我给你举个真实的案例。 某电商公司在做用户画像时，发现一个奇怪现象：活跃用户数的计算结果在不同报表中差异巨大。经过排查发现，不同团队使用的数据加工逻辑不一致，有的用了近30天的数据，有的只用了7天。如果没有完整的数据血缘，这个问题的定位至少需要一周时间。 这就是数据血缘的第一个核心价值：快速问题定位。 当数据出现问题时，你不用像个无头苍蝇一样到处询问，而是可以直接追溯到问题源头。 第二个价值更加重要：变更影响评估。 好比你要下线一张老旧的底层表。按照传统做法，你只能凭经验猜测会有哪些报表受到影响。而有了完整的数据血缘，你可以清晰地看到这张表被下游哪些任务依赖，影响哪些业务指标。在做决策之前，你就能胸有成竹地评估风险。 从概念到实践的三个关键步骤 当然，光知道数据血缘重要还不够，关键是怎么落地。 经过对多家企业的实际调研，我发现成功建立数据血缘的团队，都遵循了相似的路径。 第一步是自动化采集。 这里有个坑，很多团队一开始就想着大而全，想把所有数据源都纳入血缘管理。结果就是项目越做越重，最后胎死腹中。 正确的做法是从小场景开始，逐步扩展。 可以选择一个核心业务指标，比如"日活跃用户数"，把这条链路上涉及的所有表和任务都纳入血缘管理。验证效果后再逐步扩展到其他指标。 在技术实现上，现在有很多成熟的方案。比如可以基于SQL解析器自动提取字段级血缘，也可以通过大数据平台的作业日志来逆向推导数据流向。关键是选择一种适合你团队技术栈的方式。 第二步是统一存储和可视化。 血缘关系的本质是一个复杂的图结构，用传统的关系型数据库存储显然不合适。建议直接使用图数据库，比如Neo4j或者TigerGraph。节点表示数据表或字段，边表示数据流向，查询起来会非常高效。 第三步，也是最容易被忽视的一步：建立反馈机制。 很多人以为血缘系统建好就完事了，实际上这只是开始。真正的挑战在于如何让这个系统在日常工作中发挥作用，并且持续优化。 我见过最成功的案例，某团队把血缘系统集成到了数据质量监控平台。当数据质量告警时，系统会自动沿血缘链路上溯，帮助快速定位问题根源。同时，如果业务方发现某个血缘关系不准确，可以通过系统直接反馈给数据团队。 这种机制形成了一个正向循环：问题发现→血缘追溯→快速解决→反馈优化，血缘系统的准确性越来越高，团队工作效率也越来越高。 数据血缘背后的管理哲学 说了这么多技术层面的东西，但我觉得数据血缘更深层次的价值在于管理理念的转变。 传统的数据团队更像是一个"数据加工车间"，进来什么数据，出去什么报表，全凭经验和手工操作。而有了完整的数据血缘，数据团队就变成了一个"数据工厂"，每个环节都有明确的标准和流程。 这种转变带来的不仅仅是效率提升，更是思维方式的改变。 以前，当业务方问"这个数据准不准"时，数据团队的回答往往是"应该是准的"，或者"我们每天都有质量检查"。这种回答其实很苍白。 有了数据血缘之后，你可以直接展示数据的完整加工链路，告诉业务方数据从哪里来，经过了哪些验证和清洗，最后如何聚合计算。这种透明度本身就是对数据质量最好的背书。 更重要的是，数据血缘让数据团队从一个"支持部门"转变为一个"价值创造部门"。 以前，数据团队的价值很难衡量——做了很多报表，但业务效果如何，很难说清楚。而有了血缘关系，你可以清晰地看到数据如何驱动业务决策，哪些数据被频繁使用，哪些数据处于"闲置"状态。 基于这些数据，你可以主动向业务方提出建议：哪些数据资产需要加强保护，哪些数据可以适当清理节省成本。 这种从被动支撑到主动价值创造的转变，才是数据血缘真正的魅力所在。 结语 数据血缘不是什么高深莫测的技术概念，它更像是数据团队走向成熟的必经之路。 在这个数据爆炸的时代，我们不缺数据，缺的是对数据的理解和掌控。数据血缘就是帮助我们建立这种掌控感的工具。 当你能够清楚地知道每一滴数据的来龙去脉时，你就拥有了数据治理的话语权，也拥有了推动业务价值创造的能力。 数据血缘不是一个项目，而是一种思维方式的转变。从今天开始，让你的数据变得有"家谱"可查，让你的团队变得有"底"可依。

Zoho首席科学家兼联合创始人Sridhar Vembu近期分享了他对公司人工智能策略、产品集成以及这项技术长期愿景的见解。他在Zoholics India 2025大会上的主题演讲，以务实的视角探讨了人工智能的现状、潜力以及尚存的不足。以下是本次精彩演讲的十大要点： 大规模人工智能代码生成会带来安全和合规风险，因此人工审核必不可少：虽然人工智能可以快速生成大量代码（例如，几分钟内生成 10,000 行），但其工作量远远超出了人工审核的可行性。匆忙将此类代码投入生产环境是危险的，因为它会使组织面临严重的风险：安全漏洞、意外数据泄露和违反监管规定。Zoho 的政策是不部署未经审核的人工智能生成代码，因为合规性和安全运营的最终责任在于公司，而不是人工智能工具。 从数学角度来说，保证代码的质量或安全性是不可能的。人工智能也不例外。即使是最智能的人工智能，也受限于计算机科学的规则，例如停机问题和赖斯定理，无法保证代码完全没有漏洞或安全隐患。这意味着任何关于人工智能编写的软件完美无瑕或“绝对安全”的说法，从根本上来说都是无法实现的。人工智能可以增强人们的信心，但它无法取代严谨的人工测试和持续的监控。 人工智能的生产力提升主要集中在样板代码而非实质性的关键业务逻辑上：人工智能最受关注的部分是其驱动的开发带来的生产力提升（例如，一些公司声称提升了20-30%），而这种提升主要体现在重复性或模板化的任务上，例如用户界面模板设计。在解决复杂的后端业务问题时，人工智能带来的实际性能提升仍然有限，这意味着最有价值、最复杂的工作仍然严重依赖于人类的专业知识，而非自动化。 指望人工智能大规模取代人类从事编程和支持工作是过分夸大且风险极高的：数万亿美元人工智能投资背后的逻辑是，机器将取代相当一部分程序员和支持人员，从而降低成本。然而，如果这种取代真的发生（例如，裁减20-30%的岗位），服务质量和客户满意度的下降将立即显现。Zoho的招聘趋势——不断增加对支持人员的招聘——进一步印证了成熟可靠的人工服务目前还无法被人工智能取代的观点。客户会注意到这种变化，并且通常会反对这种替换。 管理和修改大型复杂代码库仍然是人工智能工具无法解决的一大难题。正如Vembu所说，“恐惧因素”意味着阅读、理解并安全地修改复杂的现有系统是编程界的一条“铁律”，而且随着代码库的增长，难度也会越来越大。这种困难会让程序员犹豫不决（“代码恐惧症”），从而降低他们的工作效率。目前的人工智能解决方案无法解决这些心理和实际障碍；因此，企业应该降低对人工智能变革性影响的预期。 人工智能应该被用作高级研究助手和知识合成器，而不是自主决策者：人工智能的优势在于能够收集、消化和综合来自博客、书籍和各种网络数据的海量公共领域信息，从而为人类决策者提供对某一主题的全面理解。保留人类对人工智能生成的洞见进行筛选、解读和最终决策的责任，才能获得最佳结果。 利用人工智能“自我批判”或其他人工智能输出结果，可以显著提升结果质量： Vembu 推荐采用“苏格拉底式”方法：让人工智能自我审查其建议，寻求其他人工智能的意见（例如，ChatGPT 可以批判 Gemini），或者促进对抗性反馈循环。这种方法能够揭示不一致之处，指出遗漏，并促使人工智能提供细致入微、平衡的答案，使其成为那些需要生成模型提供更深入、更客观结果的用户的强大工具。 由于存在产生幻觉的风险，人工智能生成的内容不适用于监管文件或法律文书：人工智能倾向于捏造引证或编造看似合理但实则错误的信息（即所谓的“人工智能幻觉”），这在法律、财务或合规性要求极高的场合尤为危险。现实中已经出现过相关的法律后果，例如律师因使用包含虚假案例的人工智能生成的法律文书而受到处罚。这表明，对于这些敏感的应用，人工监督至关重要。 目前人工智能在工作场所最有效的应用方式是作为一种增强工具，而非替代工具： Zoho 发现，通过人工智能驱动的建议和快速搜索功能赋能客服人员（以及其他面向客户的员工），能够实现更快、更明智的响应，从而获得最佳效果。这种模式并非要裁员，而是加快问题解决速度，提升客户满意度，因为员工仍然是互动的核心，只是被技术增强而非取代。 “人工智能等于失业”的说法并非全然正确：有时它被用来为裁员辩护，而非反映人工智能的实际能力。经济和技术批评人士经常将人工智能视为裁员的主要原因。然而，Vembu指出，至少在Zoho的经验中，“人工智能取代人工”经常被一些公司用作在市场低迷时期裁员的借口。事实上，强劲的业务增长（正如Zoho所展现的那样）可以推动招聘增加，即便人工智能的应用日益普及，因为技术和团队是共同发展的，而不是相互排斥的。 小结 斯里达尔·文布对人工智能提出了务实而深刻的观点。他承认人工智能作为科研和人类增强工具的巨大潜力，但同时强烈警告不要在关键且责任重大的领域过度自主部署人工智能。他认为，人工智能与传统计算的未来在于二者的协同作用；然而，这项技术飞跃可能会带来深刻的经济变革。 来源（公众号）：数据驱动智能

技术在进步，AI也在进化。 从最初的无记忆模式，到RAG的检索增强，再到CAG的缓存增强，每一步都更加贴近真实的业务需求。

一、先别谈技术，先问一句： 你到底要改变什么场景？ 这几年，我们被各种热词包围：大模型、算力中心、数据要素、元宇宙、低空经济…… 但如果你冷静问一句：“这些东西最后要落在哪个具体场景里？要改变谁、什么、哪一刻？” ——很多项目就开始含糊了。 国务院办公厅这份《加快场景培育和开放，推动新场景大规模应用的实施意见》（国办发〔2025〕37 号），干了一件很重要的事：把“场景”从一个模糊的 PPT 概念，正式抬升为国家级战略资源和改革工具。 文件开头就给场景做了一个非常清晰的定位： 场景是系统性验证新技术、新产品、新业态以及配套基础设施、商业模式、制度政策的具体情境，是连接技术和产业、打通研发和市场的桥梁。 翻成大白话就是： 新技术好不好用，不是专家拍脑袋，而要在真实场景里跑一跑； 场景是技术与产业之间的“过桥费”，不过桥就到不了真正的产业化； 你所有的“智能+、数据+、AI+”，最后都要在某个生产、生活、治理场景里，产生可感可量的变化，否则就是“概念股”。 所以，讨论数字化转型，不能再停留在“我要上什么系统、买什么平台、用什么模型”，而是要回到一句朴素的问题： 你要改造的那个具体场景，到底是什么？ 二、国家在做什么？ ——一张巨大的“场景资源地图” 这份文件其实给出了一个“全国场景资源总目录”，逻辑非常清楚，可以简单概括为三层： 新赛道、新空间的前沿场景 比如： 数字经济场景：元宇宙、虚拟现实、智能算力、各类机器人在办公、消费、娱乐中的应用； 人工智能场景：从科研、工业到民生、治理、国际合作，全链条找“AI 能落地”的点； 全空间无人体系：海陆空一体的无人文旅、政务、物流、卫星服务等； 生物技术场景：生物基材料、生物能源、绿色制备； 清洁能源场景：清洁能源车队、车网互动、虚拟电厂、绿电直供； 海洋开发场景：深海探测、深远海养殖、海洋药物等等。 传统产业转型升级的场景 制造业：智能工厂、零碳园区、工业大模型等； 交通运输：车联网、智能调度、空运转运等； 智慧物流：智慧公路、智慧港航、无人仓、无人配送等； 现代农业：智慧农场、育种数字化、畜牧/渔业全链路数字化。 治理与民生场景 应急管理、矿山安全、智慧水利、施工安全、林草生态保护； 智慧政务、智慧城市、数字乡村； 医疗健康、养老助残托育、数字文旅、跨界消费新场景。 用一个比喻理解： 国家在做一件事：把“场景”像矿藏一样标出来，把“场景资源”从隐形的变成显性的，让技术、资本、人才有地方“落脚”和“开采”。 同时，文件还做了两步“制度升级”： 一是把场景纳入要素与制度改革： 场景不只是工程项目，而是与市场准入、要素配置、金融支持、人才政策一起打包设计，用来催生“新质生产力”。 二是把场景当成制度试验田： 在场景里试点规则、监管方式、标准体系，试出来的再升级成更大范围的制度安排。 所以，“场景”已经不再是一个中性名词，而是真正进入了“资源—要素—制度工具箱”的视野。 三、为什么技术越多，很多数字化项目反而越“虚”？ 回到企业一侧，我们会看到另一种常见画风： 先做一个“宏大的蓝图”：统一平台、数据中台、AI 平台、数字孪生平台…… 然后一通上系统：ERP、CRM、WMS、MES、OA 全上； 再堆一些“智能”：预测模型、推荐引擎、知识图谱、机器人流程自动化； 最后发现： 一线业务觉得“很麻烦，不如 Excel 好用”； 领导觉得“报告更好看了，但业绩没感觉到多大的变化”； 数据团队每天忙着“救火”和“做报表”。 问题出在哪？出在“先有技术、再找场景”这个顺序本身。 如果没有清晰的高价值场景，再多的技术投入，很可能变成一种“数字化农家乐”： 地自己种（自己搞平台、自己采数、自己建模）； 菜自己炒（场景自说自话、不跟外部生态耦合）； 饭自己吃（数据不开放、不流动、不可复用）； 看着热闹，规模上不去，成本降不下来，外部引不进来。 相反，如果你先锁定高价值的、可复制的场景，再去倒推技术、数据、制度，就会形成一种**“数有引力”**的局面： 一个定义清晰、价值明确的好场景，会像“引力井”一样，把技术、数据、人才、资本主动吸附过来，而不是靠 PPT 和文件“拉人头”。 四、什么是一个“好场景”？ ——精益场景 SMART框架 把故事变成工程 那到底什么叫“高价值场景”？ 在精益数据方法论里，一个场景要过“五关”——SMART 原则： S：Specific（具体、独特） 越能一句话说清楚“在哪儿、为谁、改什么”，场景就越具体。 不是“要打造智慧城市”，而是“把某个核心商圈高峰期的拥堵指数降低 20%”； 不是“要做智慧工厂”，而是“将某条生产线单位产品的能耗降低 15%”。 M：Measurable（可度量） 这些指标，既是目标，也是验收标准。 办事时长从 15 天缩到 5 天； 交付准时率从 85% 升到 98%； 事故率下降一半； 一次性办结率提升到 90%。 没有数字，就没有共识。 好场景一定有 2–3 个关键指标，比如： A：Actionable（可执行） 哪些流程要改？ 哪些数据要采？ 哪些系统要改造或新建？ 哪些岗位要调整？ 场景要能拆成可执行的任务： 如果一拆发现什么都是“别人来配合、上面来支持”，说明场景定义还停留在口号层面。 R：Realistic（现实可行） 现有技术成熟吗？ 监管是否允许？ 预算撑不撑得住？ 组织里有没有靠谱的负责人？ 不要“想当然”： 有时候，把目标从“全国推广”收缩到“某一线城市或某个产业园区试点”，反而更现实。 T：Time-bound（有时效） 试点期（比如 6–12 个月）； 评估节点（3 个月一次复盘）； 推广期（2–3 年内复制到多少单位）。 场景不是无限期“试下去”； 通常需要明确： SMART 的本质，就是把“故事”压缩成“工程”： 讲得动人的不算，能拆成任务、能算账、能验收的，才叫高价值场景。 五、用“精益数据场景画布” 把一个好点子磨成好场景 光有 SMART 还是不够，你还需要一块“画板”，把场景相关的信息全都摊开来。 精益数据方法论里有一个非常实用的工具——精益数据场景画布，包含十个关键要素，可以当成一个共创工作坊的模板来用： 业务目标和价值： 这个场景从业务角度要达成什么？ 是降本、增效、提体验、控风险，还是支撑某个政策目标？ 用户画像： 谁是场景里的核心用户？ 是调度员、医生、司机、客服，还是市民、企业用户？ 不同用户在场景中的角色、动机是什么？ 场景背景： 现在是怎么做的？ 有什么外部变化逼得你必须改？政策？竞争？风险事件？ 用户痛点： 一线到底在哪儿喊累、喊烦、喊危险？ 哪些地方是关键的“吐槽高发点”？ 用户期待： 如果这个场景“成功了”，用户希望发生什么变化？ 更简单？更快？更透明？更安全？更可控？ 度量指标： 上文的 M——用 2–3 个指标，把“好不好”说清楚。 挑战与阻力： 是组织壁垒？部门利益？技术短板？数据质量？ 还是法律合规？人才缺口？预算不够？ 解决方案思路： 流程怎么变？ 机制怎么改？ 数据怎么组织？ 系统怎么协同？ 培训和考核怎么设计？ 不是一句“建一个平台”就完事，而是： 数据资产： 场景中有哪些关键数据？ 现在在哪儿？质量怎么样？缺什么？ 哪些数据是本单位就能解决的，哪些需要跨部门、跨行业协同？ 数字技术： 要用到哪些关键技术组件：物联网、大模型、知识图谱、数字孪生、区块链…… 哪些已经有，哪些需要引入新的伙伴？ 一个典型做法是： 把这十个要素印在一张大画布上，让业务、技术、数据、法务、财务、合作伙伴围在一起，从左到右、一项一项写，边写边吵，吵完基本就成了。 这个过程本身，就是“共创”和“筛选”： 写得清楚的场景，会变得越来越扎实、越来越可执行； 写到一半发现答不上来的场景，要么需要重构，要么就先“降级备选”。 六、数据要素的三重角色：底座、连接器、放大器 说到这里，有一个问题绕不过去： 在一个高价值场景里，数据要素到底干什么？ 在“数有引力”的框架里，数据有三个角色——底座、连接器、放大器。 1. 底座：没有数据，场景就是空心的 再完美的流程设计、再聪明的算法、再漂亮的界面，如果没有真实、持续、高质量的数据，最终都只能停留在“演示版”。 比如做虚拟电厂场景： 没有各类用电设备的实时负荷数据，就无法知道谁可以灵活调节； 没有历史负荷曲线，就无法做靠谱的预测； 没有合约执行与结算数据，就无法形成市场信号。 所以，每一个场景画布里，都需要回答一个问题： 这个场景的“必需数据清单”是什么？它们现在在哪里？质量如何？如何补齐？ 当你围绕场景把数据需求描绘清楚，再往上搭建数据治理、标准、目录、接口、平台，才是真正“以数据为底座”。 2. 连接器：数据把多种要素“织”成一个系统 在现实世界里，生产要素是碎片化的： 人在组织里； 钱在预算里； 设备和土地在资产表里； 算力在机房里； 制度在制度文件里。 场景要想真正跑起来，必须让这些东西协同，而数据正是连接它们的“神经系统”。 举两个简化例子： 交能融合场景 车的运行状态和位置信息来自车联网； 充电桩/换电站的状态来自物联网平台； 电网负荷、价格、峰谷时段来自电力系统； 订单、货物时效来自物流平台。 把这些数据打通，你才能做到： 把车引导到更合适的补能点； 在不影响履约的前提下参与削峰填谷； 既保证物流效率，又优化能耗与成本。 低空经济 + 应急救援场景 无人机状态数据； 气象与地形数据； 通信网络状态； 应急指挥系统的任务数据。 只有数据把这些要素连在一起，你才能做到： 实时改飞行路径； 评估风险； 追溯责任。 在精益数据方法论里，这种“连接”会进一步被抽象成： 一组跨系统、跨部门、跨主体的数据流与事件流。 场景里“谁和谁要对话”“谁给谁发什么信号”，最终都要落在数据模型与接口设计上。 3. 放大器：用算法和机制，把场景拉向“智能”与“演化” 当你有了稳定的数据底座和连通的要素网络，就可以叠加“放大器”： 用预测模型让计划更前瞻，比如： 预测拥堵、预测需求、预测设备故障； 用优化算法让资源更高效，比如： 配送路径优化、能量调度优化、人力排班优化； 用数字孪生做“先仿真后落地”，比如： 先在虚拟城市里调一次信号灯，再应用到真实交通系统； 用 A/B 测试和持续迭代，让制度和流程也能“试错”和“升维”。 此时，数据已经不只是“记录发生了什么”，而是在回答： 如果这样做，会发生什么？ 如果换一种做法，会更好吗？ 这就是数据在场景里的第三重作用——让场景从“能用”走向“好用”和“会变聪明”。 七、从“一个好案例”到“一张场景地图” 走出“农家乐心态” 很多地方和企业都有过非常成功的单点案例： 某个车间的效率提升了； 某个窗口的服务体验变好了； 某条线路的能耗下降了。 但如果你把视角拉远，会发现一个常见问题： 案例很好，但复制不了。 要走出“农家乐式的数字化”，需要把思路从“项目清单”升级到“场景地图”： 把所有经过 SMART 和画布校验的高价值场景，拼成一张“场景蓝图” 哪些场景是基础场景（例如统一身份、统一支付、统一设备管理）； 哪些是业务关键场景（例如关键产业链的生产与物流）； 哪些是治理类和民生类场景； 它们之间先后顺序、依赖关系如何。 用场景蓝图倒推三张“配套蓝图” 谁对整个场景组合负责？ 场景之间如何共享成果、分摊成本？ 怎么设计“开放场景”的准入标准和考核方式？ 哪些能力要共建（身份、支付、消息总线、物联网平台、大模型能力平台等）？ 避免每个场景单独建一套系统，造成烟囱。 哪些是场景共用的关键数据资产？ 哪些数据域必须统一标准？ 数据资产蓝图： 数字技术蓝图： 组织与机制蓝图： 把场景“开放出来”，让更多主体参与共建共用 这个场景要达成什么指标； 需要什么数据、什么能力； 有哪些边界和合规要求。 按文件要求：不得用地域、业绩、规模、企业性质等做不合理限制； 用场景公开招募技术方案、数据服务、生态伙伴； 对外说清楚： 这样，场景就不再是个别单位的“自留地”，而是一个可进入、可合作、可扩展的“引力场”。 八、给政府和企业的三条小建议 最后，用三条非常实操的话收个尾。无论你是政府部门、央企国企，还是地方龙头、民营企业，基本都适用： 建议一：先讲“场景故事”，再列“技术清单” 不要一上来就说要建“某某平台”“某某中心”，而是先问： 我要改变的第一个具体场景是什么？ 能否用一句话把场景讲给一线员工听懂？ 用一个个清晰的场景，去牵引技术、数据、制度，而不是反过来。 建议二：用 SMART 和场景画布，把场景做小、做深、做透 不要怕“小切口”，国家文件也明确鼓励“高价值小切口场景”； 从一个场景开始，用 SMART 原则“压实”，再用场景画布把十个要素填完整； 先在一个部门、一条线、一个区域赢一仗，再复制到更多地方。 这比“全域一把梭”要安全、要高效得多。 建议三：把数据当成场景资产去运营，而不是“报表燃料” 为每个重点场景列出“场景数据资产清单”： 关键业务数据、关键设备数据、关键治理数据； 明确谁负责采集、谁负责治理、谁可以使用、怎么计价、如何共享； 把这些场景数据资产逐步沉淀成“公共数据底座”，服务更多场景。 当你这样做的时候，你会发现： 同一类场景之间可以共享经验和数据； 新技术可以更快插到已有场景里试； 新伙伴可以按场景模块加入，而不是“从头谈起”。 九、精益场景咨询服务 让数据的“引力”，从 PPT 走进真实世界 “数有引力”这四个字，背后有两层意思： 一层是：好的数据本身具有引力——谁掌握了高质量数据，谁就更有能力优化决策、重构流程、创新业务； 另一层是：好的场景会创造引力——它让数据不再躺在孤立的系统里，而是在解决真实问题的过程中不断流动、沉淀、放大。 当我们用国家这份场景政策，叠加精益数据方法论的工具箱，把“场景”当成一种可规划、可运营、可复制的战略资源时： 数字化转型就不再是“技术采购项目”，而是围绕场景的系统工程； 数据要素就不再是“副产物”，而是真正成为其他生产要素的底座、连接器和放大器； 无论是一个城市、一条产业链，还是一家公司，都可以在一张张场景画布上，看清自己正在走向怎样的“新质生产力”。 数有引力，场景为场。 真正的数字化转型，终究要从一个个真实的场景开始——从某条路、某家厂、某个窗口、某个社区开始，让技术、数据和制度在具体的时间、具体的空间、具体的人身上，产生可见、可感、可复用的改变。 来源（公众号）：凯哥讲故事系列

LLM负责思考和推理，RAG负责提供准确的信息，AI Agent负责具体的执行。这就像一个完美的工作团队：聪明的头脑、丰富的信息源、强的执行力。

成功部署 AI 智能体（Agentic AI）绝非易事。我们从实践中总结了宝贵经验，告诉你如何把这件事做对。 AI 智能体革命已经开启一年，一个教训也愈发清晰：想把它做好，必须下苦功。 通过 AI 智能体实现企业转型，有望带来前所未有的生产力提升。虽然有些公司已经尝到了甜头，但更多企业却发现，他们的投入迟迟不见回报。在某些情况下，他们甚至不得不“开倒车”——在智能体搞砸的地方，重新把人招回来。 这些磕磕绊绊是任何新技术发展过程中的必经之路，我们在其他技术创新中也见过类似的模式。为了总结早期的经验教训，我们最近深入研究了麦肯锡内部主导的 50 多个 AI 智能体项目，以及市场上的几十个其他案例。我们将分析结果提炼为六条经验，希望能帮助领导者们成功地从 AI 智能体中捕获价值。 1. 重要的不是智能体，而是整体流程 要想用 AI 智能体创造商业价值，就必须改变工作流程。然而，很多公司常常过度关注智能体本身或某个工具。这必然导致一个结果：造出了看起来很酷的智能体，却无法真正改善整体工作流，最终价值寥寥。 那些致力于从根本上 重构整个工作流程 的项目，更有可能取得成功。所谓工作流程，指的是涉及人员、流程和技术的所有环节。 理解智能体如何在每个环节中提供帮助，才是通往价值的正确路径。人类员工依然是工作的核心，但人类员工将拥有新的智能体、工具和自动化系统来辅助他们。 重新设计工作流程的一个重要起点，是梳理现有流程并找出用户的核心痛点。 这一步至关重要，它能帮助我们设计出真正减少重复劳动、让智能体与人类高效协作的系统。这种协作可以通过学习循环和反馈机制实现，形成一个自我强化的闭环。智能体用得越多，就会变得越聪明、越契合业务需求。 以一家另类法律服务提供商为例，该公司正致力于合同审查流程的现代化。他们所处领域的法律推理在不断演变，新的判例法、司法管辖区的细微差异以及政策解读层出不穷，这使得将专业知识固化为代码变得极具挑战。 为了适应这种天然的变化，团队设计的智能体系统可以在工作流程中不断学习。例如，用户在文档编辑器中的每一次修改都会被记录和分类。这为工程师和数据科学家提供了丰富的反馈流，他们可以利用这些反馈来“教导”智能体，调整提示词（prompt）逻辑，并丰富知识库。久而久之，智能体便能将新的专业知识内化。 关注流程而非智能体本身，能让团队在恰当的节点部署最合适的技术。这在重构复杂的多步骤工作流时尤其重要。例如，保险公司通常有庞大的调查流程（如理赔处理和承保），每一步都涉及不同类型的活动和认知任务。公司可以通过周密部署，将基于规则的系统、分析型 AI、生成式 AI 和 AI 智能体等多种技术巧妙地组合起来，并用一个统一的编排框架（如开源的 AutoGen、CrewAI 和 LangGraph）来支撑。在这种模式下，智能体扮演着编排者和整合者的角色，调用各种工具，并将其他系统的输出整合到自己的上下文中。它们就像“胶水”，将整个工作流程粘合在一起，用更少的人工干预，交付真正的成果。 复杂的工作流程应该为每个任务选择最佳工具。 2. 智能体并非万能解药 AI 智能体（AI Agent）功能强大，但并非所有任务都适合用它来解决。很多时候，领导者们没有仔细审视需要完成的工作，也没有思考智能体是否是最佳选择。 为了避免投资浪费或不必要的复杂性，企业领导者可以像组建一支高绩效团队那样来评估智能体的角色。关键问题是：“需要完成的工作是什么？每个潜在的团队成员——或者说智能体——各自有什么天赋，如何协同工作以实现目标？” 许多业务问题完全可以用更简单的自动化方法解决，比如基于规则的自动化、预测性分析或简单的大语言模型（LLM）提示，这些方法通常比开箱即用的智能体更可靠。 在匆忙上马智能体方案之前，领导者应该先评估任务的性质。具体来说，就是要明确：这个流程的标准化程度应该有多高？需要处理多大的变数？哪些部分最适合交给智能体来做？ 从某种程度上说，这些问题很直观。例如，变化少、标准化程度高的工作流程，如投资者开户或监管信息披露，通常受到严格管控，遵循可预测的逻辑。在这种情况下，使用基于非确定性的大语言模型（LLM）的智能体，可能弊大于利，只会增加复杂性和不确定性。 相比之下，变化大、标准化程度低的工作流程，则能从智能体中获益匪-浅。例如，一家金融服务公司部署了智能体来提取复杂的财务信息，大大减少了人工验证的需求，并简化了工作流程。这些任务需要信息聚合、交叉验证和合规性分析——而这些正是智能体大显身手的领域。 最重要的一点是，不要陷入“用或不用智能体”的二元思维。有些智能体擅长完成特定任务，有些能帮助人类更好地工作，而在许多情况下，其他技术可能才是更合适的选择。关键在于，要弄清楚哪种工具或智能体最适合哪项任务，人类如何与它们最有效地协作，以及如何将人、智能体和工具组合起来，以实现最大产出。 3. 别制造“AI垃圾”：重视评估，建立用户信任 在部署 AI 智能体时，团队最常遇到的陷阱之一是：系统在演示（Demo）中看起来惊艳全场，但实际负责这项工作的用户却被它搞得头疼不已。 我们经常听到用户抱怨“AI 垃圾”（AI Slop），即智能体输出的低质量内容。用户很快就会对智能体失去信任，导致采用率极低。自动化带来的任何效率提升，都很容易被信任的丧失和质量的下降所抵消。 这个反复出现的问题给我们带来了一个来之不易的教训：公司应该像培养员工一样，大力投入智能体的开发。 正如一位企业领导者所说：“引入一个智能体，更像是招聘一位新员工，而不是部署一套软件。” 智能体应该有明确的岗位职责，需要“入职培训”，并获得持续的反馈，这样它们才能不断进步，变得更有效率。 开发高效的智能体是一项极具挑战性的工作。它需要利用领域专家的知识来创建评估体系（evals），并将最佳实践以足够精细的粒度固化下来。这种固化过程既是智能体的“培训手册”，也是它的“绩效测试”，确保其表现符合预期。 这些最佳实践可能存在于标准操作流程（SOP）中，也可能只是专家们心照不宣的默会知识。在固化这些实践时，关键是要关注那些区分顶尖员工与普通员工的核心要素。对于销售代表来说，这可能包括他们如何引导对话、处理异议以及匹配客户的沟通风格。 至关重要的是，专家必须持续参与，长期测试智能体的表现。在这个领域，绝不能“上线就完事”。这种对评估的承诺，要求专家们亲手为给定的输入，标注出期望的（甚至不期望的）输出。对于复杂的智能体，这样的标注有时可能需要成千上万条。通过这种方式，团队可以评估智能体的准确率，并进行必要的修正。 一家全球性银行在改造其“了解你的客户”（Know-Your-Customer）和信贷风险分析流程时，就深刻贯彻了这一方法。每当智能体对合规性的建议与人类的判断不符时，团队就会找出逻辑上的差距，优化决策标准，然后重新进行测试。 例如，在某个案例中，智能体最初的分析过于笼统。团队提供了这一反馈，然后开发并部署了额外的智能体，以确保分析的深度能提供恰当粒度的有用见解。他们使用的一种方法是，连续多次追问智能体“为什么”。这种方法确保了智能体的优异表现，也使得人类员工更愿意接受它的输出结果。 4. 盯紧每个环节，而不只是最终结果 当只与少数几个 AI 智能体打交道时，审查它们的工作、发现错误还相对容易。但当公司推广成百上千个智能体时，这项任务就变得极具挑战性。更糟糕的是，许多公司只追踪最终结果。因此，一旦出错——而随着规模化，出错是必然的——就很难准确找出问题到底出在哪里。 智能体的表现应该在工作流的每一步都得到验证。 将监控和评估嵌入到工作流程中，可以让团队及早发现错误，优化逻辑，并持续改进性能，即使在智能体部署后也是如此。 例如，在某个文档审查流程中，一家另类法律服务提供商的产品团队观察到，当系统遇到一批新案件时，准确率突然下降。但由于他们在构建智能体工作流时，内置了可观测性工具来追踪流程的每一步，团队迅速定位了问题所在：某些用户群体提交的数据质量较低，导致了错误的解读和糟糕的下游推荐。 基于这一洞察，团队改进了数据收集实践，向上游相关方提供了文档格式化指南，并调整了系统的解析逻辑。智能体的性能很快就恢复了。 5. 能复用就别重复造轮子 在急于推进 AI 智能体的过程中，公司常常为每个识别出的任务都创建一个独立的智能体。这会导致严重的冗余和浪费，因为许多不同的任务实际上共享着大量相同的动作（例如，数据导入、信息提取、搜索和分析），同一个智能体本可以完成。 决定在构建可复用智能体上投入多少资源（而不是只做一个执行单一任务的智能体），类似于一个经典的 IT 架构问题：公司既要快速构建，又不能锁定那些会限制未来能力的选择。如何找到这种平衡，往往需要大量的判断和分析。 一个好的起点是识别那些重复出现的任务。公司可以开发能够轻松在不同工作流中复用的智能体和智能体组件，并让开发者可以方便地调用它们。这包括开发一套集中的[2]、经过验证的服务（如 LLM 可观测性工具或预先批准的提示词）和资产（如应用模式、可复用代码和培训材料），并确保它们易于查找和使用。将这些能力整合到一个统一的平台至关重要。根据我们的经验，这几乎可以减少 30% 到 50% 的非必要重复工作。 6. 人类依然不可或缺，但角色正在改变 随着 AI 智能体的不断普及，关于人类将扮演何种角色的问题引发了广泛焦虑——一方面是对工作保障的担忧，另一方面是对生产力提升的过高期望。这导致了关于人类在当今许多工作岗位中角色的巨大分歧。 需要明确的是：智能体将能完成大量工作，但人类仍将是劳动力中不可或缺的一部分 ，尽管智能体和人类所做工作的类型都会随着时间而改变。例如，人类需要监督模型的准确性、确保合规性、运用判断力以及处理边缘案例。正如我们前面讨论的，智能体并非总是最佳答案，因此人类与机器学习（ML）等其他工具的配合仍然是必需的。然而，在某个特定工作流中所需的人员数量，很可能会在经过智能体改造后发生变化，并且通常会减少。企业领导者必须像管理任何变革项目一样，来管理这些转型，并深思熟虑地分配培训和评估智能体所需的工作。 我们经验中的另一大教训是，公司应有意识地重新设计工作，让人员和智能体能够良好协作。 如果缺乏这种关注，即使最先进的智能体项目也可能面临“静默失败”、错误累积和用户抵制。 以前面提到的那家另类法律服务提供商为例，他们希望在法律分析工作流中使用智能体。在设计流程时，团队花时间确定了在何处、何时以及如何整合人类的输入。例如，智能体能够以极高的准确率整理核心索赔项和金额，但考虑到这些信息对整个案件的核心重要性，律师必须进行复核和批准。 同样，智能体能够为案件推荐工作方案，但考虑到决策的重要性，人类不仅要审查，还要调整建议。智能体还被编程来高亮显示边缘案例和异常情况，帮助律师形成更全面的看法。而在流程的最后，仍然需要有人用自己的执照和资历来签署文件，为法律决定承担责任。 这种人机协作设计的一个重要部分，是开发简洁的可视化用户界面，让人们能轻松地与智能体互动。例如，一家财险公司开发了交互式视觉元素（如边界框、高亮和自动滚动），帮助审查员快速验证 AI 生成的摘要。当人们点击某条见解时，应用程序会直接滚动到正确的页面并高亮显示相应的文本。这种对用户体验的关注节省了时间，减少了反复猜测，并建立了对系统的信心，最终带来了接近 95% 的用户接受度。 AI 智能体的世界正在飞速发展，我们可以预见未来将学到更多。但除非公司在推进智能体项目时，从思想上和实践上都抱持着学习的心态，否则他们很可能会重蹈覆辙，减慢自己的发展步伐。 作者：Lareina Yee, Michael Chui, Roger Roberts 来源（公众号）：CDO之家

一、开篇 上周，业务总监在会议上拍桌子：“为什么销售额是负数？这数据太假了！” 我点开系统日志——他用ChatSQL问：“最近三个月销售额情况。” 系统返回了1000行“销售额”字段，其中70%是负数。 真相是：他连“销售额”这个指标在数据库里叫什么都没搞清。 这场景太常见了。说清楚自己要什么数据的人，永远不用ChatSQL；用ChatSQL的人，往往连自己要什么都说不清。 今天，我就撕开智能问数的遮羞布，告诉大家为什么90%的企业在智能问数上踩了大坑。 二、Text2SQL Text2SQL的致命伤：表元数据≠理解需求 很多厂商吹嘘“自然语言转SQL”，本质是用表元数据拼凑SQL，而不是理解业务逻辑。 ✅ 为什么表元数据是基础？ 数据库表结构（字段名、关联关系）是Text2SQL的“地图” 没有这张地图，AI就像盲人摸象 ❌ 但为什么它失效？ 因为业务人员说的“销售额”，在数据库里可能是： sales_amount（财务系统） revenue（电商系统） order_total（ERP系统） 而AI只能根据表名猜——猜错了，就是负数！ 📌 业内真相：ChatSQL的准确率=表元数据的完整性×用户描述的清晰度 两者缺一，结果必崩。 三、ChatSQL 谁在用ChatSQL？谁在骂ChatSQL？ 用户类型 代表场景 为什么用ChatSQL 结果 专业数据人 “查2023Q4华东区订单量” 他们直接写SQL，效率高 从不碰ChatSQL 模糊需求业务人 “看看最近销售情况” 说不清要什么，只能问 得到一堆错误数据 技术决策者 “让业务自己查数据” 以为ChatSQL能解决一切 误判数据，决策失误 >>延伸：AI + 数仓AI 不会取代数仓，但会增强数仓：•自动化建模、SQL 生成•智能调度优化•自然语言查询（NLQ） 这也是我见过最讽刺的场景： CTO要求“用ChatSQL赋能全员”，结果业务部门每天问：“为什么我的销售额是负数？” 这不是技术问题，是认知问题。 四、语义层，不是ChatSQL的升级版 破局关键：语义层，不是ChatSQL的升级版 很多厂商还在做“NL2SQL”，但真正的破局点在语义层（Semantic Layer）。 为什么语义层是核心？ 传统NL2SQL 语义层方案 依赖物理表结构 抽象业务语义（销售额=收入-退款） 一个指标多个口径 统一指标定义（全公司只用1个“销售额”） 业务变化需重写SQL 业务规则变更，语义层改1处，全链路生效 数据孤岛，口径混乱 跨部门数据一致，无歧义 🌟 语义层的本质：把“业务语言”翻译成“数据语言”的中枢 例如： 业务说“销售额” → 语义层映射到revenue - refunds → 生成精准SQL 这才是智能问数的正确打开方式： 用户问“销售额” → 语义层解析业务含义 → 生成SQL → 返回数据 五、别再盲目上ChatSQL 给企业的血泪建议：别再盲目上ChatSQL ❌ 你正在踩的坑： 以为ChatSQL=自助分析 → 实际是“自助造错” 用宽表+NL2SQL → 业务一变，IT就重排期 把指标库当摆设 → 业务人员依然用“销售额”“订单量”等模糊词 ✅ 我的实战建议： 先建语义层，再上ChatSQL → 用指标平台（如 数势科技SwiftMetrics，Aloudata CAN）定义“销售额”“用户活跃度”等业务指标，统一口径。 让业务人员参与语义定义 → 业务部门自己写“销售额=收入-退款”，比IT猜100次都准。 ChatSQL只做最后一公里 → 业务人员问“Q3销售额”，语义层自动转成SELECT SUM(revenue - refunds) FROM sales WHERE quarter=3。 💡 我的铁律： “没有语义层的ChatSQL，是数据灾难的加速器，不是解决方案。” 六、结语 智能问数的终极目标👇 智能问数不是“让AI替你写SQL”，而是让业务人员真正理解数据。 对专业DE：语义层解放了你的时间，让你专注数仓建设与数据治理，而不是救火。 对业务人员：不再需要问“销售额是什么”，而是直接问“Q3销售额对比Q2如何？” 对企业：从“数据孤岛”走向“数据统一认知”，决策效率提升10倍。 记住： 说清楚需求的人，永远不需要ChatSQL； 用ChatSQL的人，永远说不清需求。 破局的关键，不是让AI更聪明，而是让业务更懂自己。 范老师重申： “我见过太多企业花百万买ChatSQL，结果数据还是错的。 真正的智能问数，是让业务人员先学会‘说清楚’， 而不是让AI去‘猜清楚’。” 来源（公众号）：数据仓库与Python大数据

智能体人工智能正在颠覆大数据范式，它要求我们主动将数据引入专门的智能计算平台，而不是反过来。这种转变从根本上改变了我们对数据建模和存储的固有认知，因为低级机器学习（LLM）能够利用远小于传统机器学习的数据集进行上下文学习。因此，现代人工智能不断扩展的上下文窗口和工具调用能力正迅速使许多传统的ETL/ELT流程过时，迫使数据工程师彻底重新思考他们的整个方法。 造成这种混乱的原因是什么？ 造成这种转变的原因之一是人们使用数据的方式正在发生变化。 企业应用和仪表盘由软件工程师和数据科学家构建，旨在满足非技术用户的需求。反过来，业务分析师和最终用户则被动地接收这些内容。应用可能内置了一些交互功能，但这些交互都遵循僵化的、预先设定的工作流程。作为数据工程师，我们的工作是提供此类应用能够使用的数据格式。 从以“构建者”为中心的模式（技术用户创建应用程序）过渡到以“交互者”为中心的模式（非技术用户通过人工智能代理直接与数据交互）。 越来越多的非技术用户直接与数据交互。他们能够根据自身需求编写应用程序和工具。现有的SaaS应用程序不再局限于集成并排聊天界面，而是利用CopilotKit等框架更原生地嵌入自然语言交互。具有前瞻性的开发者并没有简单地重复僵化的工作流程，而是将AI代理嵌入到应用程序中，使代理能够以工具调用的形式访问后端API。 其次，重心正在转移。过去，数据量庞大，因此需要将计算资源部署到数据所在位置，以避免大量数据迁移。然而，如今前沿人工智能模型（LLM）才是重心所在，人工智能应用也围绕它们构建。 重心发生了转移，因此技术架构也随之翻转。与以往需要定制计算资源处理数据不同，智能体人工智能应用使用大型语言模型（LLM）作为推理引擎，能够理解用户意图、推理任务并调用工具执行操作。这一新应用浪潮旨在将用户意图直接转化为行动。 这两种动态变化如何影响数据工程师的工作？以下五个原则在准备用于人工智能的数据时需要牢记。 1. 重新思考 ETL/ELT：从规范化到上下文 如今，数据工程师投入大量精力进行数据规范化、创建清晰的数据模式并构建转换管道。其目标是使下游分析师和应用程序能够理解数据。 这并不意味着 ETL/ELT 就变得无关紧要，提供数据仍然至关重要。但您可以依靠代理来解释模式、理解关系，并处理各种格式的数据，而无需进行大量的预处理。 然而，仅仅在现有表上添加数据目录和 MCP 服务器，是对智能体技术能力的极大浪费。此外，这样做还会大大增加 AI 智能体的工作难度。为什么呢？ 人工智能代理能够理解上下文中的数据，它们不需要所有数据都预先规范化到僵化的模式中。事实上，随着表数量的增长，如今的代理很难正确解读数据并编写正确的 SQL 语句来连接所有数据。此外，随着数据切片数量的增加，冲突和歧义的概率也会增加。例如，两个表中可能都有“贷款金额”列。在一个表中，它可能代表借款人申请的金额，而在另一个表中，它可能代表贷款人实际发放的本金。数据结构越是经过处理、规范化和分散化，上下文信息就越难传递。 维护数据可用性工作流程，但要质疑每个规范化步骤是否仍然必要。代理人能否在适当的上下文中理解这些数据，而无需进行转换？委托人信息能否从原始条款清单或融资备忘录中摘录一段文字，解释该委托人将分期获得哪些款项，而不是仅仅用一个数字表示？ 避免只向 AI 代理开放非结构化数据的诱惑——虽然很容易对 PDF、电子邮件等进行处理，但组织中真正可操作的数据通常仍然是结构化数据。 2. 优先考虑数据整理而非数据收集 情境式学习使得内容整理比资料收集更为重要。 在大数据时代，目标是收集尽可能多的数据，因为你想在极其庞大的数据集上训练机器学习模型——更多的数据意味着更好的机器学习模型。 然而，人工智能代理的构建基于情境学习，即在提示中提供一两个示例。学习学习模型（LLM）可以有效地模仿这些示例，无论是遵循某种流程（思维链）还是遵循某种格式或风格（少样本学习）。随着情境学习的出现，示例的质量比数量更为重要。 你向代理展示的示例数据会影响它对所有类似数据的理解。你可能会创建一个示例库，并选择哪些示例用于特定类型的用户查询。随着数据管理的重要性日益凸显，作为数据工程师，构建以下工具变得至关重要： •找出最高质量的数据，例如完整、准确且具有代表性的数据样本。 •随着标准的演变，应定期更新这些示例。 •验证精心整理的数据是否确实能作为智能体学习的有效示例。 作为数据工程师，你需要赋能的关键角色之一是数据管理员。你需要支持的存储类型也会发生变化，包括图数据库和向量数据库。 3. 构建面向代理的基础设施：感知与行动 人工智能代理需要支持两种核心能力的基础设施：感知数据和根据数据采取行动。 并非所有数据格式都能被基于语言模型的智能体平等地访问。请考虑智能体解析、理解和提取数据格式含义的难易程度。能够保留语义含义且预处理需求极低的格式可以降低交互阻力。 AI 代理通过调用工具（包括函数、API 和服务）来执行操作，这些工具使它们能够处理数据。您的基础架构需要确保代理能够发现并使用这些工具。这意味着清晰的接口、完善的文档和可靠的执行。 从人工智能代理的角度审核您的数据访问模式和工具。一个自主系统需要了解哪些信息才能有效使用它们？哪些环节存在阻碍，导致运行不畅？ 4. 将代理工件作为一级数据进行管理 人工智能代理不仅会消耗数据，还会生成数据。事实上，你会发现，人工智能生成的内容将远远超过系统中“原始”数据的数量。 当智能体生成输出、做出决策、编写代码或记录其推理过程时，这些也变成了数据。 无论内容是由人工创建、从软件系统收集，还是由人工智能代理生成，都必须符合您所在行业的通用规范和法规。除了合规性之外，这些代理生成的数据对于调试、审计、训练未来的代理以及理解系统行为也具有价值。 对代理程序生成的数据应与其他数据一样严格对待： •存储代理输出系统 •保留决策日志和推理痕迹 •将代理生成的代码作为版本化工件进行管理 •确保这些数据可供分析和未来培训使用 这些工件将成为您数据生态系统的一部分。请据此设计存储和访问模式。 5. 将观察与训练联系起来 提升智能体性能的最快途径是实现可观测性和训练之间的闭环。人工智能智能体基础设施需要双向管道，将模型性能和可观测性与持续训练联系起来。 首先，你需要一个可观测性平台，它能够追踪数据质量指标，尤其重要的是，能够检测数据漂移（输入数据特征的变化）和概念漂移（输入和输出之间关系的变化）。同时，它还必须监控关键的模型性能指标，例如准确率、延迟和幻觉率。建立与预定义阈值关联的自动触发器。 您的可观测性平台也需要扩展，以纳入人工反馈。用户对生成内容所做的每一次修改都需要记录下来，并用于改进人工智能模型。 其次，你需要一个重训练流程，该流程会在收到监控系统触发的事件时自动激活。它必须完全自动化，负责提取最新版本的训练数据，启动模型重训练或微调任务，并对新训练的模型进行全面的评估和回归测试。在智能体时代，构建这种将性能监控直接连接到自动化部署的闭环系统，对于机器学习/数据工程师来说至关重要，两者之间的界限将日益模糊。 数据工程师的角色如何变化 这五大转变都围绕着一个共同的主题：从僵化、预设的工作流程转向灵活、情境感知的架构。现代代理的工具调用和反射能力使得僵化的 ETL/ELT 流水线不再那么重要。情境学习使得范例精选比详尽的范例收集更有价值。 数据工程的重要性并没有降低，而是发生了变化。过去十年构建数据基础设施的技能依然宝贵，但需要应用于不同的目标。我们不再需要预先设计每个工作流程，而是要创建一种环境，让代理能够自行设计工作流程。 来源（公众号）：数据驱动智能

本文将详细介绍五种重要的数据格式： •CSV •JSON •Parquet •Avro •ORC 在大数据时代，数据源之间的数据迁移和存储需要更具策略性的方法。如果没有优化的决策，通过 ETL 流程处理 TB 级数据可能会耗费大量时间和成本。本地部署系统虽然相对容易发现问题，但其基础设施不会自动适应新的情况，问题必须手动解决。 然而，在云端，资源可以自动扩展。虽然我们可能认为一切运行顺畅，但一些被忽略的小步骤却可能导致数万元的不必要成本。在我看来，根据项目需求选择合适的数据格式是大数据时代最关键的决策之一。 存储在 S3 中的物联网数据应该采用 CSV 格式还是 Parquet 格式？每周销售报告文件的最佳格式是什么？大小文件是否应该使用相同的格式？只有充分了解每种数据格式的特性，才能有效地做出这些决策。 近年来，某些格式——尤其是 Parquet 和 Avro——越来越受欢迎。尽管它们存在一些缺点，但它们的灵活性，尤其是在云环境中，极大地促进了它们的应用。在本文中，我将解释这些格式的特性、优势和劣势，并讨论哪种格式最适合特定场景。 一 CSV CSV是一种基于文本的表格数据格式，其中每一行代表一条记录。记录中的列或字段通常用分隔符（最常见的是逗号）分隔。第一行通常包含列名作为标题。CSV 格式被广泛支持，因此成为数据交换的热门选择。 1.编码 CSV 文件通常采用UTF-8编码，这样可以确保字符兼容性并使文件可压缩。 2.优势 •易于阅读： CSV 文件易于阅读和理解。 •通用性强： 几乎所有编程语言和工具都支持它。 •易于使用：可以手动生成、编辑和检查。 •兼容性：与电子表格和临时分析工具兼容。 3.缺点 •我认为，这种格式最大的缺点之一是它不存储元数据，不强制执行模式或数据类型，并且默认情况下将所有数据都视为文本。（例如，当使用其他工具读取 CSV 文件时，包含年龄等数值的列可能会被解释为整数，但这完全是一种解释，可能不正确，需要手动验证。否则，错误在所难免。） •由于其体积庞大且 I/O 速度慢，因此对于大型数据集来说效率低下。与 Parquet 格式相比，根据具体情况，它可能占用大约 10 倍的空间。 •CSV格式不适用于嵌套数据，这是由于CSV格式本身的设计缺陷造成的。例如，在更适合嵌套数据的格式（例如JSON）中，嵌套结构如下所示： { "user" : { "id" : 123 , "name" : "Alice" } , "actions" : [ { "type" : "click" , "time" : "2025-11-05T12:00Z" } ] } 相同的 CSV 数据必须以 JSON 字符串的形式表示在单个单元格中： user_id,user_name,actions 123,Alice,"[{""type"":""click"",""time"":""2025-11-05T12:00Z""}]""[{" "type" ":" "click" "," "time" ":" "2025-11-05T12:00Z" "}]" 这使得阅读、筛选和分析变得更加困难。 4.何时选择 CSV 格式 •适用于对人类可读性要求较高的中小型数据集。 •应用程序、分析师或团队之间轻松共享数据。 •不支持二进制或列式格式的系统或工具。 •快速原型制作或从电子表格（Excel、Google Sheets）导出。 二 JSON 多年来，JSON 一直是最流行的数据格式之一。它可以被视为一种通用语言，使不同的应用程序能够相互理解。其主要目的是促进 Web 服务和应用程序之间的数据交换。在 JSON 出现之前，XML 曾被广泛用于此目的，但它存在诸多缺陷。 XML格式非常冗长，难以阅读，尤其是在处理冗长且嵌套结构的情况下。它占用大量存储空间，解析XML文件会消耗大量的CPU和内存资源，因此不适合处理大数据。此外，XML的兼容性也有限，通常需要专门的库才能解析。 一个简单的 XML 结构示例： <user> <id> 1 </id> <name> Alice </name> <is_active> true </is_active> <address> <city> Berlin </city> <postal_code> 10115 </postal_code> </address> <hobbies> <hobby> music </hobby> <hobby> cycling </hobby> </hobbies> </user> JSON 随后应运而生，它是一种更简洁、更紧凑、人机可读且通用兼容的格式，极大地简化了跨语言数据交换。JSON以文本格式存储键值对数据。它支持嵌套和层级结构，能够自然地表示复杂且深度嵌套的数据。其通用性使其被广泛用于 API 数据传输和配置文件。 一个简单的JSON结构示例： { "id" : 1 , "name" : "Alice" , "is_active" : true , "address" : { "city" : "Berlin" , "postal_code" : "10115" } , "hobbies" : [ "music" , "cycling" ] } 1.编码 UTF-8 通常被使用，因为它既兼容 ASCII，又支持国际字符。由于采用了 UTF-8 编码，JSON 文件可以在不同的平台上无缝共享。 2.优势 •人类可读： JSON 文件是基于文本的，易于人类阅读。 •支持嵌套数据：可以自然地表示复杂和分层的数据结构。 •通用互操作性：几乎所有现代编程语言都支持。 •无模式灵活性：每条记录可以有不同的字段；不需要严格的模式。 •API友好： REST和GraphQL服务的标准格式。 3.缺点 •存储效率低下：每个记录中都重复出现键，这会增加大型数据集的大小。虽然它适用于消息传递，但并不适合大规模存储。 •不强制类型：数字、布尔值或空值均被视为文本；正确的类型由应用程序自行决定。这种缺乏强制的做法可能是一个缺点，尤其是在 ETL 流程中，新数据可能需要持续关注以避免类型错误。 •解析成本：与二进制格式相比，CPU 和 RAM 使用率更高，尤其是对于大文件而言。 •无元数据： JSON 中不包含最小值、最大值或空计数等信息。 •大文件处理：大文件需要流式传输或分块传输；一次性将整个文件加载到内存中是不切实际的。 4.何时选择 JSON •API 数据交换（REST/GraphQL）： JSON 非常适合在不同系统和编程语言之间传输数据。它为 Web 服务、微服务和移动应用程序提供了一种标准、快速且易于解析的格式。 •适用于快速原型设计和共享的中小型数据集：虽然 JSON 不是存储大型数据的最佳选择，但对于中小型数据集来说效果很好。 •人的可读性很重要：与 XML 或二进制格式相比，其基于文本的键值结构使得错误和缺失字段更容易识别和调试。 •嵌套和分层数据： JSON 自然地支持嵌套对象和数组，可以轻松地以清晰有序的方式表示复杂的结构，例如包含地址和订单的用户对象。 三 Parquet Parquet 是当今最流行的数据格式之一，专为Apache Hadoop 生态系统中的大数据分析而设计。它的主要目标是在高效存储大型数据集的同时，优化查询和分析性能。其最重要的特性是列式结构，这显著提升了查询和存储性能。从很多方面来看，Parquet 都可以被视为大数据时代的主流。 Parquet文件的结构 Parquet文件由三个主要层组成： Parquet 文件 •行组： Parquet 文件的一部分（例如，100 万行一组）。 •列块：行组中特定列的数据(e.g., user_id, age, country)。 💡注意：每一列（例如，country）并没有存储在整个文件的单个连续块中，而是作为每个行组中的单独列块存储。 行组允许并行读取和基于行的过滤（谓词下推），从而只读取必要的行块，降低 I/O 成本并提高读取性能。 1.编码 Parquet 格式以二进制列式结构存储数据。虽然 Parquet 中的文本数据可能使用 UTF-8 编码，但其效率并非源于编码本身，而是源于其他特性，我们将在下文讨论这些特性。 2.优势 （1）列式结构 采用列式结构可以显著提高 Parquet 格式的效率。其最大的优势在于，在大型查询中，系统只会读取所需的列，而忽略不必要的列。这不仅提高了I/O 性能，还降低了成本。 对基于行的格式（例如 CSV）和基于列的格式（例如 Parquet）的数据进行查询的方式如下： （2）基于行的查询（CSV） 在 CSV 文件中，所有行都以文本形式存储： 1，爱丽丝，30，美国，100 2，鲍勃，25，美国，200 3，卡罗尔，40，德国，150 4，戴夫，35，德国，300 5，伊芙，28，美国，250 查询： “美国客户总消费额”→ 仅需要列country和spend 因为 CSV 是基于行的，所以会读取和解析所有行，包括id、name、age。 I/O 成本： 5 行 × 5 列（读取整个文件）。 （3）列式查询（Parquet） 在 Parquet 格式中，列存储在单独的块中： 列ID：1、2、3、4、5 ； 列名称：Alice、Bob、Carol 、Dave 、Eve； 列年龄：30、25、40、35、28 ； 列国家/地区： US 、US、DE 、DE、US ； 列消费金额：100、200、150、300、250 •查询： “美国客户总支出”→ 仅读取country和spend列块。 •id、name 和 age 不会从磁盘读取，从而降低了 I/O 和 CPU 开销。 •列式格式结合字典编码、游程编码（RLE）和位打包（bit-packing）可减小文件体积并加速读取。 格式 ｜ 读取的数据 ｜I/O -----｜-------------｜------ CSV（行式）｜所有行 + 所有列｜高 Parquet（列式）｜仅 country 和 spend 的数据块｜低 （4）行组 行分组不仅按列划分数据，还按行划分数据，具体如下： •提高I/O 性能 •减少过多的随机磁盘访问 例如：一个文件有 3 个行组，每个行组有 50 万行： 如果我们只查询 ` idA` 和 ` ageB`，就不会访问 `C` name、country`D` 和 `D`salary中的 450 万行数据，从而节省大量资源。行组也可以并行读取，进一步提升性能。 如果我们需要的数据只在一个行组中，则跳过其他行组，从而节省高达 80-90% 的 I/O。 （5）字典编码 Parquet 的另一个效率提升之处在于字典编码。重复值存储在字典中，并通过索引进行引用，从而减少了高度重复数据的存储空间。 例子： 列：[美国, 美国, 德国,美国,德国, … ] 字典：{ 0 :美国, 1:德国} 编码列： [ 0 , 0 , 1 , 0 , 1 , … ] 如果我们有 10K 行：6K United States+ 4K Germany，我们存储索引而不是完整的字符串，最多可以节省约 90% 的空间。 原始文本（CSV）： 6,000 × 13 = 78,000字节4,000 × 7 = 28,000字节总计：106,000字节≈ 103.5 KB字典编码（Parquet ） 10,000行→ 2个类别→每行1字节（或至少1位）总编码：10,000字节≈ 9.8 KB （6）游程编码（RLE） RLE 对连续重复的值进行数值计数： 列： [ 0 , 0 , 0 , 1 , 1 , 2 , 2 , 2 , 2 ] RLE： [ (0 , 3 ) , (1 , 2 ) , (2 , 4 ) ] # 前三个值为 0 等 •数值使用最少位数。 例如：值为 0-3 的列只需要2 位而不是 32 位。（7）模式强制执行与元数据 Parquet 文件包含有关文件及其数据类型的元数据。 元数据存储模式和数据类型，以便下游消费者可以信任数据类型，而无需重新定义模式或依赖自动检测（自动检测容易出错）。 元数据还包括 Parquet 版本、创建者、写入工具（Spark、Pandas 等）、列最小值/最大值（启用谓词下推）、空值计数和值计数。 3.缺点 Parquet 格式不具备可读性：它是一种二进制格式；直接读取它只会显示原始二进制数据。需要使用专门的工具（例如 PyArrow、Pandas、Spark、DuckDB）来检查或处理数据。 小型数据集的写入开销：元数据、编码信息和字典表会使 Parquet 文件比小型 CSV 文件大得多。例如，一个包含几百行的 CSV 文件可能只有 10 KB，而相同数据的 Parquet 文件则可能需要 100 KB。 兼容性问题：并非所有系统或轻量级工具都直接支持 Parquet 格式，包括： •遗留系统 •基本电子表格或商业智能工具 •小型嵌入式或基于脚本的解决方案 •通常需要中间库（例如 Pandas、PyArrow、Spark）才能读取。 4.何时选择Parquet •大规模分析和大数据查询： Parquet 格式非常适合拥有数百万甚至数十亿行数据的数据集，尤其适用于对查询性能和 I/O 效率要求极高的情况。其列式结构允许仅读取必要的列，从而减少磁盘和内存使用量。 •嵌套或复杂的数据结构： Parquet 支持结构体、数组和映射等复杂数据类型，使其适用于分层或半结构化数据，而这些数据在 CSV 等基于行的格式中会显得很繁琐。 •云存储和成本效益：在云环境中，仅读取所需列可降低 I/O 和计算成本。Parquet 的压缩和编码特性可进一步减少存储占用。 •ETL管道和分析框架： Parquet可与Spark、Hive、Presto和DuckDB等大数据工具无缝集成。当数据将被多个下游分析系统使用时，它堪称完美之选。 •基于列值过滤场景：当查询涉及基于列值进行过滤时（例如，WHERE country = 'US'），Parquet 的行组和元数据允许跳过不相关的数据块，从而大幅提高查询速度。四 Avro Apache Avro 是 Apache Hadoop 生态系统中最古老、最成熟的数据格式之一。它由 Hadoop 的创建者 Doug Cutting 开发。其主要目的是解决数据可移植性和模式定义方面的不足。Avro基于行，与早期格式不同的是，它采用二进制而非文本格式。这使其更高效、更快速、更节省空间。 例如，考虑一个 10 位数： 1234567890 •在 CSV 或 JSON 格式中，每个数字都存储为一个字符（每个数字占用 1 个字节）： '1' → 00110001 '2' → 00110010 ... '0' → 00110000 •总计：10 字节。解析需要将每个字符转换回整数。 •在像 Avro 这样的二进制格式中，该数字以 int32（4 字节）形式存储，节省了约 6 个字节，并且允许直接内存访问而无需解析，从而显著提升了速度。 Avro 也像 Parquet 一样提供模式强制执行，这意味着模式存储在文件元数据中。 1.文件结构 Avro 文件由三个主要部分组成： Avro 文件 •头部：包含描述数据结构的“魔数”和模式定义（JSON 格式）。 •数据块：以压缩二进制形式存储实际数据。数据块支持并行处理；程序可以跳过不需要的数据块以加快访问速度。 •同步标记：充当断点，帮助在文件损坏时恢复数据。 编码 •Avro 以二进制格式存储数据，比 JSON 或 CSV 格式小得多。 •无需进行文本解析，因此CPU 使用率低。 2.优势 •模式演化与类型强制执行 •该模式嵌入在文件中，确保类型安全和向前/向后兼容性。 向后兼容性示例： 旧模式： { "type" : "record" , "name" : "User" , "fields" : [ { "name" : "id" , "type" : "int" } , { "name" : "name" , "type" : "string" } ] } 旧数据（二进制表示，以 JSON 格式显示）： { "id" : 1 , "name" : "Alice" } { "id" : 2 , "name" : "Bob" } 新增模式，添加了字段（is_active）及其默认值true： { "type" : "record" , "name" : "User" , "fields" : [ { "name" : "id" , "type" : "int" } , { "name" : "name" , "type" : "string" } , { "name" : "is_active" , "type" : "boolean" , "default" : true } ] } 使用新模式读取旧文件会产生以下结果： { "id" : 1 , "name" : "Alice" , "is_active" : true } { "id" : 2 , "name" : "Bob" , "is_active" : true } •旧数据不包含新字段，但Avro 会使用默认值填充该字段，从而确保向后兼容性。向前兼容性则以相反的方向实现。 紧凑二进制格式 •比文本格式小得多（大约是 JSON 大小的 10-20%），但比 Parquet 大。 快速序列化和反序列化 •序列化和反序列化数据时 CPU 使用率极低，使其成为Kafka、Flink 和 Spark Streaming 等实时系统的理想选择。 与语言无关 •模式在 JSON 中定义，数据是二进制的 → 可以轻松地在 Python、Java、Go、C++、Scala 等中使用。 非常适合流媒体播放 •基于行的结构意味着每个记录都是独立的，非常适合基于事件的处理（Kafka 主题、消息传递系统）。 3.缺点 人类无法阅读 二进制格式无法直接读取；需要 PyArrow、Avro 工具或 Spark 等工具进行检查。 基于行的结构 SELECT AVG(price)对于分析查询（例如，在大数据集上），列式格式（Parquet/ORC）效率较低。 读取模式所需 没有模式就无法读取数据。模式必须嵌入在文件中或可从外部获取。 压缩技术不如Parquet/ORC先进 行式存储限制了压缩效率；列式格式可以实现更好的存储空间缩减。 4.何时选择 Avro 流式传输和消息传递系统： Kafka、Flink、Pulsar 等，其中事件需要快速序列化。 模式管理和向后兼容性：跨版本自动模式演化。 类型安全：与 JSON 不同，Avro 强制执行数据类型。 适度的存储优化：比文本格式小，但不需要列式压缩。 高频 ETL 和微服务：适用于服务间数据流密集的系统。 五 ORC（优化行列式） ORC 是一种专为 Hadoop 生态系统开发的高性能列式二进制数据格式。它专为分析海量数据而设计，因此具有很高的查询效率和压缩率。它也像 Parquet 一样具有模式强制执行功能。 1.文件结构 ORC 文件包含三个主要部分： Postscript：数据以大块形式存储，每列都是独立的。也就是说，一个条带包含一组行的逐列数据。 Footer：包含所有架构、统计信息和条带位置。 Stripes：提供有关压缩、文件格式版本和页脚长度的信息。 下面我们通过一个例子来更清楚地理解这三个部分； 假设我们有一个客户表； ORC 文件 2.编码方法 ORC 的编码方式与 Parquet 非常相似；我们在此不再赘述。您可以在上面的 Parquet 部分阅读相关内容。不过，我们可以大致讨论三种基本方法； 字典编码：对于重复值，创建一个字典，并存储字典中的索引而不是数据本身。 游程编码（RLE）：连续相同的值用一个值及其重复次数表示。 位打包：对于数值，使用最少的位数，例如，对于 0 到 3 之间的值，只需 2 位就足够了。 3.优势 •高压缩比： ORC 具有很高的压缩比。这主要是因为数据是按列存储的，并且相似的数据是连续存储的。我们在 Parquet 部分已经提到过这一点，并指出这种方法称为游程编码 (Run-Length Encoding)。 •模式强制执行：与 Parquet 格式一样，ORC 也具有模式强制执行机制。我们前面已经讨论过它的重要性。 •快速分析： ORC 与 Parquet 类似，仅在需要时才访问数据，从而显著提升读取性能。更多详细信息，请参阅 Parquet 部分。 4.缺点 ORC的缺点与Parquet的缺点非常相似；简而言之，这些缺点包括： •不可读：由于 ORC 是二进制格式，因此无法浏览或读取。 •基于行的更新很困难：它专为追加或批量分析而设计，而非事务性的行级更新。它更侧重于分析，因此不适合行级更新。这是因为数据以列为单位存储在较大的数据块（条带或行组）中；更改单行需要重写所有相关的列数据块。 •小数据集的元数据开销：对于非常小的表，元数据和条带开销可能会使 ORC 比 CSV 或 Avro 更大。 •工具依赖性：某些轻量级工具或旧系统可能不支持 ORC 原生支持。 5.何时选择 ORC •对大型数据集进行分析查询： ORC 在读取密集型分析工作负载（如 Hive 或 Spark 中的聚合、过滤和连接）中表现出色。 •需要高压缩率：重复性或低基数数据集可受益于 ORC 的列式压缩。 •Hadoop 生态系统集成：与 Hive、Spark、Presto、Impala 或 HDFS/S3 存储配合使用时非常理想。 •谓词下推/更快的过滤： ORC 的条带级元数据可以高效地跳过不必要的数据。 •具有批量追加功能的稳定模式：非常适合追加密集型管道，但不太适合事务性行更新。 6.Parquet 与 ORC区别 这两种文件类型都是二进制、列式存储，并且在许多方面都使用非常相似的方法。然而，它们在某些方面也存在差异。首先，ORC 格式的优化更为激进。因此，在某些情况下，ORC 格式可以获得更好的压缩效果，并且由于其元数据更详细、更全面，因此也能提供更好的读取性能。 我们将在平台上使用的工具也很重要。ORC 主要面向 Hive 和 Hadoop，因此在这里速度可能更快；而 Parquet 在云端和异构系统中表现更佳，具有更强的平台兼容性和通用性。虽然这两种工具通常都适用于批量分析，但使用 ORC 添加少量数据或进行基于行的数据更改效率较低。Parquet 在这方面则更加灵活，可以根据具体情况用于此类操作。让我们简要比较一下这两种工具： 今天，我们介绍了大数据生态系统中的关键数据格式：CSV、JSON、Parquet、Avro 和 ORC。我们分析了它们的主要特性、优势、劣势以及各自最适用的场景，包括存储、性能、模式强制执行、压缩和兼容性等方面的考量。您可以在下方找到总结表。 来源（公众号）：数据驱动智能