现在整个行业都在谈论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之家
引言 在本系列前面的文章中，我们分别介绍了《什么是数据中台》和《为什么数据治理是持续性的？》 也为大家介绍了康桥数据“理采存管用”的数据治理方法论。 不少读者反馈，对“数据仓库”这个词还不太清楚：它和数据中台到底是什么关系？数据中台既然覆盖“理采存管用”，那数据仓库又在其中扮演什么角色？ 在深入探讨“理”（梳理）和“采”（采集）之前，我们可以先把“存”（存储）这个环节讨论一下。 数据中台和数据仓库的区别与联系 数据仓库为什么需要分层 业界常用的分层思路有哪些 康桥数据在实战中总结的分层模型是怎样的 一、数据中台 vs 数据仓库 数据中台：是一个承载“理采存管用”全流程的“工具与管理平台” ，核心是让数据能力可复用、可服务化。 数据仓库：是中台体系中负责 “存”的 “数据地基”。 它们的关系是： 数据经过中台的治理（理）和采集（采）后，存入数据仓库；再通过中台的调度和管理（管），最终以服务形式（用）支撑业务应用。 通俗来讲，数据中台操作数据，负责把数据治好。数据仓库存储数据，负责把数据存好。 二、数据仓库为什么一定要分层？ 数据仓库的命名源于“仓库”的概念，其设计核心在于解决数据管理中的混乱与低效问题。若将原始数据、加工数据及应用数据混杂存储于单一存储层，将导致数据定位困难、管理复杂、查询性能低下。数据仓库分层设计正是为应对这一挑战，通过结构化组织实现数据的高效治理与利用，数据仓库有以下优点： 结构清晰：像“俄罗斯套娃”一样，采用分层架构（如ODS、DWD、DWS、ADS），每层职责单一，将复杂数据流程简化为可管理的模块化处理，复杂问题简单化。 数据复用：沉淀公共指标和宽表，避免“重复造轮子”，极大提升下游开发效率。 任务解耦：复杂任务拆成多个步骤，便于运维和重跑，一层失败不影响全局。 查询加速：空间换时间，通过预处理和汇总，让上层应用（AI用数、BI、大屏）查询更快。 水平扩展：多数数仓基于分布式架构支持弹性扩容，无缝适配数据量增长场景，确保系统在高负载下保持高性能与高可用性。 三、业界主流的分层思路 3.1 经典两大流派 Inmon（自顶向下）： 主张先建企业级数据仓库（EDW），再建数据集市。 Kimball（自底向上） 主张先围绕业务过程建数据集市，再通过一致性维度整合成企业视图。 Inmon（自顶向下）就像先建一个巨型中央仓库，把所有货物标准化后，再分发给各部门小店； 而Kimball（自底向上）则像先为各部门开专业零售店，但使用统一的商品编码和会员体系，让这些店能轻松连锁成一个大超市。 前者强调整合与统一，后者追求速度与实用。现代数据平台通常结合两者思想。 3.2 当前共识：五层模型 融合了经典思想，互联网和大厂普遍采用五层结构： ODS（贴源层） 贴源层顾名思义是从源头粘贴数据，同城使用数据集成工具（ETL），将源头业务系统数据进行归集，保持数据的原貌，不做任何修改，隔离源头业务系统，不影响原系统的运行。 DWD（明细层） 当原始业务数据进入ODS层时，会对数据进行标准、治理的检查，将问题数据进行清洗、转换、去重、标准化等动作，实现数据的自优化。 DWS（服务层） DWS服务层，更多地贴近业务场景，在DWD明细层的基础上进行汇总加工和聚合计算，例如将事实表中的聚合度量值和维度表中的数据进行汇总聚合，借助DIM公共维度层的不同维度，计算分析出多维度的业务信息。 ADS（应用层） ADS层为数据产品、报表和分析服务提供可直接使用的数据，支撑业务决策的数据应用和报表分析。 DIM（维度层） DIM贯穿于ODS、DWD、DWS、ADS，确保各层数据计算中维度的一致性和准确性。提供通用的维度属性，常见的维度包括，时间维度：年、季度、月、日、时等；空间维度：物理位置、网络地址等。 五层结构相互独立又协同工作，形成高效的数据处理与分析体系，支持智能化的业务应用。 数据流向：ODS → DWD → DWS → ADS DIM 贯穿所有层次，确保维度一致性 这种架构兼顾高内聚、低耦合的数据仓库建设思路，但对团队建模能力要求较高，不少中小企业在落地时感到吃力。 四、康桥数据的实战分层模型 如果说 3.2 的五层模型是学院派，康桥数据的数仓分层就是实战派。康桥数据中台目前支持多种常见数仓，也对信创数据库（如达梦、人大金仓）做了良好适配。无论底层选Doris、StarRocks还是PostgreSQL，都将分层思想内嵌到平台中，提出一套更实战、易用、低门槛的分层模型： SRC（来源层） → ODS（贴源层） → DW（治理层） → ADS（应用层） → DS（共享层） 4.1 设计思路：让数据好管好用 1. 可行性与易用性 架构不是为了“炫技”，而是为了更快更好地实施和使用。考虑到数据工作未来会引入更多业务人员，以及“中国式速度”的要求，我们的模型必须“开箱即懂”。 2. 强化“理采”与“用”的映射： 将「SRC-来源层」纳入： 明确映射“理采存管用”中的“理”和“采”的起点，方便从源头理解数据。 将「DS-共享层」纳入： 明确映射“用”的出口，让数据提供者和消费者清晰知道“数据成品”在哪。 3. 降低“存”与“管”的门槛： 弱化DW细化分层： 将业界DWD（明细）和DWS（汇总）合并简化为「DW-治理层」。 解耦DIM维度层： 将「DIM-维度」的管理从数仓ETL中剥离，交由康桥中台的“数据标准、数据清洗”模块进行维护。 让实施人员无需精通复杂的Kimball建模，大幅降低数据工作的门槛。 4. 确保规范（前提）： 简化不等于随意。没有规范的敏捷是“灾难”。康桥模型通过中台工具将规范（如标准、质量等）“嵌入”到数据的归集、清洗、共享流程中，确保“简化”后的数据质量。 4.2 康桥五层模型详解 第 0 层：SRC（来源层） 逻辑层，不存实际数据。作用是梳理数据资产，比如“CRM系统-客户表”，这是数据治理的起点。 第 1 层：ODS（贴源层） 物理层，把源系统数据原样同步过来，只做轻微格式处理，不做业务加工。作用是可回溯、解耦业务库压力。 第 2 层：DW（治理层） 核心层，融合了明细和汇总功能。在这里执行数据清洗、标准化、关联和轻度汇总，产出可信、可复用的数据。 第 3 层：ADS（应用层） 面向具体业务场景做深度加工，比如大屏数据、报表数据、算法样本等。DW 层保持稳定，ADS 层灵活响应需求。 第 4 层：DS（共享层） 逻辑层，将 ADS 的数据包装成 API 或数据目录，供业务系统或人员直接调用。使用者无需关心数据存在哪里。 五、康桥数据的实战分层模型 数据中台是平台，数据仓库是地基。分层是为了让数据更清晰、可复用、易治理。 业界有 Inmon、Kimball 等经典思路，也有通用的五层模型，但对实施能力要求高。康桥数据在此基础上，提出更注重实战的五层模型（SRC/ODS/DW/ADS/DS），通过中台工具降低建模门槛，能更快落地“存好、管好、用好”数据的目标。 本文基于小编当前实践经验整理，数据仓库领域发展迅速，数据湖等新概念也不断涌现，但分层管理的核心思路始终未变。康桥数据长期专注于数据管理能力的输出，目前我们正在将多年实战经验整理成书，未来也会在书中更系统地介绍数据仓库相关内容，希望能更好地助力大家的数据治理工作。
一、开篇 上周，业务总监在会议上拍桌子：“为什么销售额是负数？这数据太假了！” 我点开系统日志——他用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 流水线不再那么重要。情境学习使得范例精选比详尽的范例收集更有价值。 数据工程的重要性并没有降低，而是发生了变化。过去十年构建数据基础设施的技能依然宝贵，但需要应用于不同的目标。我们不再需要预先设计每个工作流程，而是要创建一种环境，让代理能够自行设计工作流程。 来源（公众号）：数据驱动智能
