龙石亮相DAMA数据大讲堂：探索AI重塑数据治理新路径
视频简介
DAMA数据大讲堂系列活动数聚大咖第七十八讲，龙石数据创始人练海荣分享AI如何重塑数据管理：从All in AI的决策思考，到企业智能体的两种开发模式（深度工程型与敏捷组装型），再到智能问数、混合检索、元数据治理的落地实践，并探讨本体论、数据异构与FDE前沿部署工程师等话题。从理念到落地，为数据治理智能化转型提供可复制的路径。
视频内容
一、开场：龙石的由来，数据人的自嘲
今天晚上我们非常荣幸，请到了一位老朋友——苏州龙石数据的创始人兼总经理练海荣先生，来跟我们分享一下，AI这玩意到底是如何重塑数据管理行业的。
介绍一下练总：他是高级工程师，也是东华大学的校外导师，深耕数据治理与AI智能体领域多年，专注数据治理体系的搭建、AI数据中台的研发和数据资产价值转化。
练总拥有丰富的企业数智化落地经验，带领团队打造出了全流程、可落地、高实用的AI数据治理解决方案，助力数百家校政企客户实现了数据好管、好用和增值。
练总，我想问问你，你们"龙石数据"有什么特别的含义吗？
创建公司的时候，因为我本身是技术出身嘛，当时我们想研发一个产品，就希望它又快又稳——"迅如飞龙、坚如磐石"，所以叫龙石。
很好的名字。我相信任何一个创始人，在给企业或者产品起名字的时候，肯定都蕴含着深刻的含义。像当年的天猫，人家跟我说，是马老师在上厕所的时候想出来的名字，当时我就想笑，但还真的挺有底蕴。我觉得龙石特别好。
说到今天的数据管理，人家说那些编程序的、搞程序的是"牛马"，我觉得我们搞数据的是"牛马的平方"，牛马不如。所以人家经常问我：你在美国干了30年，在国内也干了好几年，美国跟中国搞数据的人是不是都很苦？
我实实在在讲，真的蛮苦的。所以我经常定义我们搞数据的人，就是生活在社会的最底层——为什么？因为我们要为数字经济打基础。
另外一个定义，我们数据人是"夹心饼干"，夹在技术和业务之间，有气没地方出，你看苦不苦。
二、为什么All in AI：不是颠覆，是机会
这几年人工智能突飞猛进，真的给了我们一个非常好的机会、一个工具，让我们从那种非常繁琐的、牛马不如的数据管理工作中解脱出来。
我今天邀请你来，是因为我知道你最近在All in人工智能，想用它重塑数据管理相关的产品和方法。你以前有一个非常好的数据质量管理平台，为什么连平台也不管了，要All in重塑所有产品？这是个机会，还是被逼的？
我今天邀请你来，是因为我知道你最近在All in人工智能，想用它重塑数据管理相关的产品和方法。你以前有一个非常好的数据质量管理平台，为什么连平台也不管了，要All in重塑所有产品？这是个机会，还是被逼的？
就这一个问题，我想了大概半年。我也跟TGO鲲鹏会里很多专门研究AI的大佬交流，问这到底会不会颠覆我们。后来结合朋友们的建议和我自己的想法，我得出的结论是：不是颠覆，是机会。
为什么这么讲？原来我们干的都是"地下"的活、牛马不如的活。因为甲方经常问我们：我花了几百万、几十万，干的活到底有什么价值？我们干的是基础设施、地基工程，很难表达价值。
现在AI来了。第一，它让我们能更好地使用数据。 原来要开发系统、做数据分析，难度很高才能发挥数据价值；现在AI能让业务端直接用数据，我们治理的价值自然就出现了。
第二，原来我们干的都是苦活累活，AI能帮我们把人力很难做到、甚至根本做不到的活做到。 基于这两点，再不All in AI，更待何时？
实际上你刚才讲的这个"机会还是颠覆"的问题，今年2月初，Oracle甲骨文居然开除了近4万个员工。那天早上我接到4个电话，都是好朋友打来的，说自己在Oracle被裁了。我说怎么可能，你都干了10年15年了。其中一位告诉我，他那个团队43个DBA，只留了3个。
所以我觉得，AI到底是颠覆还是机会，恐怕因人而异。如果我们固步自封、还是以前那一套，那很可能就是颠覆；如果我们能把它好好利用起来，不管作为工具还是认知方式，那很可能就是机会。
我很多朋友，各行业做得好的、搞研发做得好的，都是把AI跟自己原有的经验结合，让自己更强，而不是全新的东西。
没有AI赋能的话，今天我们仍然是牛马不如。但我也看到，最近FDE热得一塌糊涂。
现在确实有个问题：我们花了几十万、几千万甚至几个亿，业务价值到底在哪？一方面数据管理大量人力堆在上面，另一方面产出确实不理想。所以完全同意你的观点：如果真能好好掌握人工智能，对我们来说就是个机会。
三、龙石创始人的纠结与转型
作为公司创始人，做这个决策非常重要，因为意味着你以前所有的软件系统、方式方法恐怕都要重做了。你当时犹豫过吗？
犹豫过，因为这个投入非常大。对我原有的产品，我个人不太喜欢用"颠覆"这个词，更喜欢中性、理性一些的词。
我原有的产品已经很成熟了，自己也觉得还可以，这时候重做一遍有必要吗？这么多投入能得到回报吗？要组建新团队，对现有团队的影响这么大，能承受吗？好多好多问题，都纠结过。所以作为创始人，更加是任重道远。
我有个好朋友，是印度人，在美国，跟你很像。借数据质量这个软件来讲，他的数据质量软件做得非常成熟，有很多客户，比如宝洁。最近他也做了一个非常重要的决策：把自己原来那套数据质量管理系统放弃了。当然经验一直在，knowledge是在的，他就用人工智能把这套系统完全改变了。
他跟你不一样的是，你有一系列产品，他只有一个数据质量的产品。
所以我想问问练总：你从技术的角度，怎么转换到这种基于AI的方式方法上来？能不能介绍一下你的产品系列，以及从技术角度到底是怎么实现的？如果你有PPT，也可以分享一下。
四、"将来没有软件"：一切都会变成智能体
好，那我把PPT打开，晚一些如果可能的话也稍微做一些演示，让大家对界面有个直观的认识。
我也很好奇，基于人工智能的数据管理系统应该是怎么样的。我看过许多产品，觉得你这个还挺好的。
其实我这个人更喜欢聊技术，讲的时候就不讲那些道理和商业的东西，我们讲思路，供大家参考。
之前我们对智能体做了很久的研究，发现了几个问题。先说为什么我决定All in，其实还有一点：以前我有一个客户，也是个非常专业的人，两年前跟我讲了一句话，他说"将来是没有软件的"。就这一句话，我想了好久。
后来我想，为什么没有软件了呢？本质上，现在人跟电脑还得通过鼠标、键盘来交互；将来AI的语言能力已经很强了，为什么人跟人之间是语言交流、视频交流，跟软件系统之间却要通过键盘文字这个媒介来交流呢？所以有人说APP都会消失
基于这些点，我想：如果软件消失了，软件承载的东西还在——软件系统承载的只是工作流程和数据，数据交换还是必须要发生的。那将来会变成什么？我认为都会变成智能体，一个又一个的智能体。
现有的软件系统承载工作流和数据，上面的应用全部变成智能体，智能体将会越来越多。
五、企业AI助手的四大困难与平台的整体逻辑
我的理解是：企业AI助手看似遍地开花，实则面临多重困难。
哪些困难？
第一，入口越来越分散。 大家左建一个、右建一个，又回到了二三十年前建设信息化孤岛的老路，现在是"智能体孤岛"
第二，结果难以核验。 这个大家都明白，AI有的时候有幻觉。
第三，运营缺位。 这个我觉得非常重要——我们做一桩事情要拿到反馈，基于反馈完善改进，才能更好地服务业务，但现在大家对运营的重视度不高。
第四，开发成本高，时间周期太长。
【图（1）】
关于第四点，我上次直播也讲过：以前做个主数据管理的项目，没有一年到三年真的完不成。现在我走到许多客户那边，人家跟我说"你这个主数据要一年半、三年？对不起，我们不干了"。以前用年来计算项目周期的逻辑，真的走不通了。
所以基于这些理解，我们龙石做的逻辑是什么？
【图（2）】
首先目标：统一入口，用户的体验、账号、权限这些基础设施要一致。
然后是公共能力层：数据查询、知识检索、文档处理、图表生成，以及外部生态——把外部的MCP接口、公共的skill、做得好的开源skill全拿进来。我们刚开的FDE班也就在讲MCP、skill这些东西，讲知识检索、讲幻觉，也提到了RAG。
如果你搞数据管理，却不会RAG、不会做企业知识库建设、不懂什么叫MCP，我觉得根本就没法做数据管理了，因为这是新的一个时代。
再往下是管理侧：知识库管理，一上传就能生成知识库，不需要从头到尾介入构建；数据集怎么管理起来，包括需求、反馈、审计、角色权限，全构建起来。
把这三桩事情做完，我们就能让智能体建设从单点交付转向整体能力建设。这也是我们从今年初得出的心得，所以就做了这么一桩事情。
六、两种开发模式：深度工程型与敏捷组装型
接下来我把比较核心的内容挑出来分享。我们做智能体，我认为有两种模式，并不去决定哪个更好、哪个不好——一个是更快，一个是更准。
深度工程型：结果必须准
比如智能问数，给业务人员用，他不用快、也不用强大，但你要能把业务端常用的数据 100%准确地提交给他，这个一定要做到。
因为业务人员看到一个数据不准，宁可不用。特别是医疗健康的数据、银行里的数据，容不得半点闪失。而且不能太复杂，太复杂、太麻烦他都不愿意用。所以我们要面向业务，他怎么想，而不是我觉得应该要强大。
【图（3）】
敏捷组装型：开发必须快
第二点，敏捷组装也是要的。比如FDE到了现场，客户提了个需求，能不能快速开发出一个智能体让业务端先体验，再给我们反馈意见？然后FDE工程师把前台需求拿到后台，让研发用深度工程型的方法把它产品化。
所以这两个是协同的作用。这次我们也讲到了business discovery，业务发现。
今天大家都在讲"翻译"这个技能，我认为除了翻译，还有一个很重要的技能就是"拆解"——把目标一个一个拆解，这是很有讲究的。
以前我在Oracle也干过两年，那是20年前了。那时候我们有一个岗位叫"需求工程师"，有点像现在互联网时代的产品经理，只不过我们当时用更工程化的方法，按部就班地做需求分析和迭代；互联网是更快的敏捷迭代，以前我们有点像瀑布迭代。
敏捷组装重要就重要在"快"。怎么做到？最重要的能力，是把市场上已经开源的skill、MCP接口装到平台里来，让AI认识这些skill和MCP接口，然后自己做规划，去调哪些skill、调哪些接口，利用现有的能力快速组装。
深度工程详解：智能问数如何做到100%准
那我举例子告诉大家具体怎么做。先说深度工程，以智能问数这个智能体为例。
【图（4）】
用户提问，我们有一个"智能体路由"。其实我们现在慢慢想把它改成叫"超级智能体"——因为用户真的嫌麻烦，还要去找能满足需求的智能体。他说我什么都不想干，就像以前的Google、百度搜索框，只有一个框给我。
进来就先到超级智能体，你问一句话，它会找到对应的智能体。比如问数，它就跳到问数智能体的能力里面来。
第一步是要素提取。比如我问"今年华东区的销售额、销售总额是多少"，就提取出几个要素：今年是时间维度，华东区是区域位置维度，销售额是指标。
把这三个提取出来以后，去知识库里找对应的数据集。如果这三个指标在一个数据集里完全匹配，那就简单了——用Java代码，这个是我们后台自己写的，不是AI生成的。以前的老版本是AI生成，所以只能达到95%的准确率。
现在这边全是自己写的程序，当然也是AI帮我们写的，等于人工最后审核，是Human in the Loop。然后用程序生成图表，这样就能做到100%准。
如果他找不到呢？我们就要跟用户澄清，或者提示他重新提问。我们有一个原则：宁可不答，也不错答。 因为深度工程型必须要准。当然它有个前提条件：数据治理、指标定义和指标开发都必须要做好。
敏捷组装详解：合同审核智能体为例
敏捷组装型是什么样？用户提问，大模型制定计划。以合同审核为例：大模型说怎么审，制定计划，然后读取合同内容，执行合同审核的skill——这个skill里定义了合同要审核哪些项——最后大模型直接反馈结果。
敏捷组装型是什么样？用户提问，大模型制定计划。以合同审核为例：大模型说怎么审，制定计划，然后读取合同内容，执行合同审核的skill——这个skill里定义了合同要审核哪些项——最后大模型直接反馈结果。
这两种模式，一个是先要准，一个是先要快，协同着来。
七、本体与语义层的探索
那天我们在讲本体建模，其实就涉及到知识库查找数据集的事情。我们当时在想：万一找不到数据集怎么办？也许语义层、也许本体，能够帮助我们解决这个问题。
当然，本体是否真的能彻底解决，还有待进一步讨论——能全部找到是一回事，万一没找到，说不定底层本体里反而能找到一些答案。
当然，本体是否真的能彻底解决，还有待进一步讨论——能全部找到是一回事，万一没找到，说不定底层本体里反而能找到一些答案。
包括今天我也在跟上海一个同行交流，他们把语义层做得非常好，语义层再往前，就可以构建本体了。但工作量确实很大，特别是业务一旦变更，会直接影响到语义层和本体——以前这些东西都是手工在更新，那真是不得了。
像Palantir，他们确实充分利用人工智能工具，希望用AI来实时更新本体。这个开发成本确实大，但一旦建好了，我相信它发挥的作用也是很大的。
就像我们做数据一样：数据做好了、管理好了，后面做应用、做分析都方便，一模一样的道理。本体也是基础设施，但它比我们还要再往下一层。
特别感谢练总能够非常直白地告诉我们：很多领域目前只能达到90%或者95%，许多工作还是需要人工参与的。
我经常听到有些大会上讲PPT，说我们能做到100%，难道真的是100%吗？效果真的那么好吗？
我们搞技术的人，可能情商不一定很高，但我们讲的是实话。讲一个不真的话，你真的把这个工作接下来了，交付不了的时候，自己也带到泥坑里去了，也害了客户。烂尾楼对各方都没有好处。 所以这个我们是不愿意做的。
八、龙石AI智能体（开发）平台技术架构
智能体形形色色：数据管理、数据治理、业务端全覆盖
刚才汪主席您提问的是，我们到底用了哪些技术、掌握了哪些技术才能把智能体做好。插一嘴，智能体其实是形形色色的。
在数据管理领域，有智能问数、智能报告；在数据治理领域，有质量规则智能体、模型建设智能体、元数据语义增强智能体等等。
业务端也有很多，比如智能填单——工厂里有些单子还是手写的，拍个照能不能全解析出来直接入库，这就提高了工作效率。
还有智能监管，比如政府里的投诉举报智能体：老百姓投诉时都是随便写的，"某某某小吃店、哪个路上的"，你对不到企业是哪一家，就没法处罚、没法监管，所以要能识别。
过往的经验案例是什么、处罚意见是什么、法律法规的依据是什么，这是一整套流程，既涉及数据，又涉及知识库——法律法规是知识库，市场主体要去数据仓库里找，处罚意见要形成报告，还需要Word处理的智能体。
所以任何一个智能体都涉及方方面面，我们就要把这些基础能力构建好。
【图（5）】
能力服务层：把智能体包装成MCP
那要构建哪些能力呢？大模型接入就不说了，一般情况下开放出来的都可以接。能力服务层主要就是MCP：比如我们自己做了智能问数智能体，就要把它包装成一个数据查询的MCP。
刚才那个投诉举报的例子，我要去查数据，不能自己写SQL去查，应该调用平台里的公共能力智能化地查。我要查法律法规，已经构建好了法律法规的RAG库，那也要有知识检索的MCP接口开放给投诉举报智能体用。
混合检索：全文30% + 向量70%
平台的知识库里，比如刚才那个法律法规库，我们要做全文检索。很有意思：为什么大家都在用向量检索，我们还要全文检索呢？
因为全文检索是硬碰硬的匹配，能检索出来的匹配度是100%；向量检索是语义匹配。所以我们做的时候，30%用全文检索，70%用向量检索。
然后多拿一些：我明明要3个，就拿了10个、20个，只要上下文长度能支撑，就多拿一点出来，让大模型进行组织——这就是混合检索。
30:70这个比例是很重要的数字，我们做了很多探索，这个比例还不错。像我们以前做推荐引擎也是这个样子，一般三七开：70%的数据拿来训练，30%的数据拿来核验。供大家参考。
龙石AI智能体开发平台平台定位
你这个整体，有人给它一个大的名字叫data agent。实际上你这边不是一个data agent，而是有许多许多agent，从事不同的服务。
对，其实我们改的名字叫"龙石AI智能体开发应用平台"，所以东西就特别多了，就不只是限于data本身。
只不过我们公司不会去做其他业务，那些都是给合作伙伴做的——我们不懂业务，刚才提的投诉举报、工厂填单，那些都是合作伙伴做的。我们是做平台，提供这么一个平台。
工作流编排与公共组件
那接下来就是agent要有运行时，工作流要能够编排。工作流编排我们也用了几个：LangChain、LangGraph，还有Dify也都可以用。
我们最早用的是Dify，它有好处，就是拖拖拽拽，开发起来方便、比较简单。但现在比如做数据中台智能体，那是很复杂的智能体，如果还拖拖拽拽反而不方便了，所以还是要编程。这就是为什么我们平台里支持多种方式——每个点都是一步步演变而来的。
权限控制这些就不用说了，我们也要做。交互层呢，也要做成一些组件：比如做问数的时候要跟用户确认，那个确认的对话框，不要每次做智能体都去写，应该做成公共组件放在里面；生成的折线图、柱状图这些也是公共组件，以后做智能体直接复用。
右侧这边是智能体的管理，包括运营能力，常见的我就不说了：权限、工单、会话、MCP管理接入，还有模型、凭证、TOKEN配额。大概就是这些，把这些东西做完，我们就有比较强的智能体底座了。基于这些能力，再去做用数、做业务智能体，就会很快。
九、搞数据的一定要学编程吗
我有个感觉：国内跟美国还真有些不一样，国内搞数据的，真的学编程的人不多。在美国，你搞数据肯定要知道编程，这是必须的。
大家知道我的底细，我是浙大哲学系毕业的，但我是倒过来的——从编程开始，然后再搞数据。我在国内看了一下，身边好多搞数据的，编程真的很弱。
所以这里我倒有个建议：为了今后能把工作做得更好，搞数据的真的要学习编程。SQL每个人都没问题，这是搞数据必须要有的技能。但我说的是Java、Python之类的，特别是Python。难吗？我觉得并不是很难，我一个搞文科的人都能搞得定，你肯定也行。
我顺便讲一下，我记得黄仁勋曾经说过"以后大家都不要学编程了，人工智能会给你编程"。我一直觉得这个话不对。你不懂编程，说实话你连装个OpenClaw都搞不定。
包括我们最近说，大家都在用WorkBuddy之类的，WorkBuddy里面有许多东西，你不懂计算机还真的搞不定。所以我不太认同黄仁勋在这件事上的说法，他说"不要学计算机了，在美国学计算机的人找不到工作"，我心里想，是这么回事吗？别误人子弟了。
我非常赞同这个观点。就拿我们公司来说，有几个专家都是985计算机专业毕业的，但毕业之后就没写代码，因为搞研究。
到了AI时代，尤其是智能体时代，我们理解的事情会越来越深，越来越接近业务端，效率要求越来越高，因为中国卷嘛。所以他们也会觉得有些掣肘，说"我虽然不要写代码了，但是我要会写代码"，这个逻辑矛盾吗？
其实很简单：他不用自己像我们搞个IDE写那么多代码，现在他能跟AI交互，让AI去写，至少能看得懂——写完了以后他来看一看，逻辑跟我的想法是否一致。甚至看的过程当中，他发现我原来的逻辑有什么漏洞、缺了什么，提给AI继续补、继续改。所以不用会写，但是要会。
所以我也经常讲一句话，有一次我在教首席数据官的课，我说你们都是公司的领导者，我跟大家讲一句废话：最新的那些技术，你可以不懂，但是你要知道。
十、龙石AI智能体开发平台产品演示：智能问数为例
【图（6）】
一句话问出销售排行
这边我举一个例子，这是我们新版本问数的界面。之前这边叫"智能体总入口"，我现在改成叫"超级智能体"。我就以一次问数经验为例。
第一个用户在下面的对话框提问："第二季度华东地区产品销售量排行"。AI就能识别到这是智能问数这个智能体，自动跳过来。
跳过来以后把数据查出来，用7种样式展现出来。如果这个数据我以后还经常想看，可以把它加到一个看板里面去，以后再进来字都不用敲了，直接去看数据。这就是一个很简单的用数体验。
点一点就能查数据
下面我们做了一些数据准备工作，给用户方便。我们把数据分成各种主题：人力资源、生产、销售，都有不同主题，里面有哪些数据集，用户可以简单查看。
我们会自动把里面的指标维度提取出来，意味着用户也不用输字了，理论上就点：我要查销售额，点一下；要查各个城市的销售额，一点、一提交，数据就问出来了。
深度思考与快速模式、连续追问
下面提供了两个模式：一个是深度思考模式，一个是快速模式。快速模式追求快，深度思考模式会更准一点，因为它问的那个切词会切得更好，但也会更慢。所以我们的选择没有绝对的好跟坏，都是在求平衡。
像ChatGPT也好、DeepSeek也好，都有个上下文的概念，你这边也有吗？也要啊，它可以追问嘛。你看"第二季度"，追问——所谓的追问，里面叫continuous Q&A，连续性的问。不错不错，这个非常好。
严谨模式与探索模式
再往下，我们分为两种模式，一种叫严谨模式、一种叫探索模式，这个字在右下角这边也能看到。
严谨模式的特点就是宁可不答、也不乱答，就是刚才讲的深度工程型。
探索模式呢，是尽量找到相关的数据回答——有些时候用户对这个事情的准确率要求不是那么高，但尽量拿到；拿到以后可以生成一个报告，把数据丢给IT部门请他们帮忙核实。这样IT部门和业务部门之间的协作就更好了。这就是我们问数的逻辑。
龙石AI智能体开发平台·数据看板
【图（7）】
看板简单介绍一下：给业务端自己配置，配置很简单，不像BI报表还要设置很多数据，这边什么都不能设——才那么简单嘛。就像马斯克的Cybertruck没有方向盘，你用就行了，只能调调大小、前后顺序。
这些看板从哪来？就是你问数问得好的，自己把它加进来，它是一种新时代的收藏。对，收藏。
大概就是这样的逻辑。我们的问数智能体、业务智能体、数据中台的智能体，都是这个逻辑，都在整个底座上研发。
十一、数据中台4.0与公司定位
这个还真不容易。我经常看到一个问题：把人工智能彻底融入到数据管理的方方面面。你刚才讲的是问数，那数据质量管理、数据安全管理，比如用AI做分类分级，你有没有这方面的智能体研发，或者已经产品化了？
我解释一下：那个产品叫"数据中台4.0"，是把它做智能化的改造，但还没有正式上线，所以暂时演示可能不行。对，不必演示。
有些东西说不定还是商业机密，但其实我们现在比较开放，只是我们觉得，成熟度够了、能达到生产级了，才把它拿出来。
那练总，在产品研发过程中，有没有一种FDE的方式？就是前沿部署的专家们在客户那边收集要求，比如用智能问数过程中的反馈、好的需求，再提炼上来，回头让智能体做得更好。你有没有在做这方面的工作？
其实我们没有真正去做FDE，因为我们公司的定位不一样。我们公司一个核心逻辑——这个我今天不打广告——就是：赋能客户和合作伙伴成为数据治理专家。
我们公司在上海、苏州、无锡这三个地方自己做，外地全部交给合作伙伴来交付。
那你就更像Palantir这样的公司了？对，Palantir自己有产品，让客户、合作伙伴去落地。从它的角度，怎么把产品做得更好？
开始的时候投入很大，因为许多都是定制化的，规模化实现不了。但它们趟出一条路：有许多FDE在客户那端收集大量个性化需求——A公司有这需求，刚好B公司也有，那这需求是不是共性的？
拿回来进一步优化产品功能、性能，再往外推的时候，定制化需求就越来越小，所以它的边际成本递减，效益特别好。
十二、好产品源于一线：客户反馈驱动迭代
你有没有在做这样的工作？这个有啊，我给你看两个东西，两个可能大家觉得鸡毛蒜皮、但我觉得很重要的。这是我们那个数据中台，做了八年。我举一个例子，这都是我们的合作伙伴提出来的。
原来我们这种ETL引擎，加一个数据清洗转换组件，只能左右拖。有一个客户跟我说不方便，因为组件太复杂了，满屏幕都是，如果只能左右，那个线就很乱。他说你应该搞个从上到下也能弄、从右到左也能弄。
那时候我一开始是拒绝这个需求的，人家把截屏一发过来——做！因为他的场景太复杂了。我相信不止一个客户会有这种需求，然后你把这种共性的东西拿回来，就进一步提升自己的产品。
这个实验也是Palantir一直在做的工作——我在那边也干了两年半。当时做客户化、定制化真的是劳民伤财，工作量非常大，但通过不断积累，产品就越来越好。
所以到了现在，其实定制化我们也有。经常有客户问：能不能拿你们的源代码做二次开发？我问他，你为什么要开发、开发什么？基本都没有了。
拿过去以后，我们做了8年、几十个研发天天在搞，你怎么接得住？怎么在我的基础上做优化？很难，其实没必要。
而且我们每年都给客户做免费升级——只要是我的客户，每年做一次免费升级，只要我们公司不倒闭，你每年都能用到新产品。
十三、数据异构问题怎么破？本体论是根本中的根本
我们上面有个问题：如何用智能体解决数据治理、数据异构的问题？ 你有些什么建议？
我不太知道他讲的"数据异构"指的是哪个方面，我用我的理解来说。这其实是两个问题。
怎么用智能体来解决治理的问题？我们做智能体，AI数据中台4.0里面几乎所有模块都智能化了，但不是所有功能都智能化了。我们核心是把人做不到的、或者人做起来很麻烦的点，用智能体来做。
举个例子，我们原来做元数据管理，每个字段的含义是什么，这件事做治理工作非常难。因为技术人员不懂，原厂供应商有些都不在了，或者没有成本配合你；业务部门的人也不懂，他不懂数据库。
怎么办？我们做法很简单：把表结构、随机抽取的样本数据、企业行业特征、业务系统的用户手册说明书拿过来，给AI，AI就能帮我们推荐字段的业务含义。基于数据、用户手册、表结构分析出来，有的时候比人识别得还要好。我有同样的体验，人做起来太麻烦了。
他指的这个异构，上面进一步写了，是机构的异构、语义的异构。我觉得要解决这个问题，恐怕确实需要好好讲一讲本体论。
我们前面有一讲，跟数语科技的Allen刚好也讨论过本体的问题。目前这个本体忽然之间那么热，它应该是用来解决我们这种异构的——结构异构、语义异构，还有好多异构，比如主体的异构。
特别是这次，我们有几位专家，其中一位是国家信息中心的前主任高新民主任，在写一本书叫《数据的互操作》，专门强调各种异构：机构异构、语义异构、主体异构、地域异构。这本书应该是非常好的东西。
尽管这个名称不叫本体论，我们叫"数据观"，一种新的数据观念。数据的互操作问题，在DAMA那本书里讲了一章，但实际工作中许多人不太重视。你提的这个问题非常好：数据互操作到底如何解决？那就是我的一个回答。
练总你同不同意？针对不管什么样的异构，要做好数据治理，本体论恐怕是根本当中的根本。
本体确实是理解企业业务的一个比较好的方式。我这么理解：本体构建出来以后，能够帮助AI理解我们的企业、业务、物理世界，所以它在语义治理上面有很大帮助。
但我要提一个不太一样的看法：本体的构建是非常难的。在这么一个情况下，我有一个尚方宝剑、倚天屠龙剑，但这个宝剑我没有——那怎么办？这个是当下我觉得大家更应该关注的问题。
我的总体感觉是，至少Palantir这样的公司已经有验证，本体论确实能帮我们做许多工作。只是说它是不是能解决所有问题，我同意练总讲的，恐怕不一定。但这个东西不解决的话，异构的、所谓数据互操作的，更加难上加难了。
我再提另外一个。刚才钟总提的那个问题，我的看法是：语义层上面语义异构的问题，很多时候还得回到传统方法。刚才您问我很多问题，我都说我们有经验分享；这一件事情反而我说"不能"——不能的意思我打个引号，我想说"不能"，是告诉大家，这个就是我们今天在讲的FDE了。
