去年在Oracle AI World,Simon de Montfort Walker还在谈前沿模型只能覆盖行业应用60%的需求,剩下40%是技术问题。今年他坐在同一个活动上,重心已经变了。de Montfort Walker是Oracle行业应用执行副总裁(EVP Industry Applications),他今年的核心判断是:模型不再是这个体系的中心,应用才是。应用里装着大量企业级逻辑——权限矩阵、使用权利、流程的确定性输入输出。通用模型之所以能从一个用例的角度达到100%,恰恰是因为它成了这套应用逻辑的使用者,而不是替代者。
他因此说Oracle对应用业务更加看多了。过去一年的工作重心不是模型本身,而是模型周围运行时的东西:什么在跑、在哪里跑、谁在跑、它能在什么边界内工作。
从设计到运行时:风险转移在哪里
de Montfort Walker用了一个金融监管的类比来解释这个转变。上周在伦敦一个金融服务峰会上,他提到传统的合规保证方式是这样的:
监管者,这是我们的系统将如何工作。这是输入,这是输出,这是你应该感到放心的理由。
但在有生命、会呼吸的系统里,设计时固然重要,运行时才是真正需要确认的时刻——因为如果你没有恰当地设计运行时,系统这次可能和上次不太一样。你需要遥测数据、护栏、确定性和概率性组件的协作,才能确保结果是你想要的。
这个判断的实际含义是:企业AI治理的瓶颈正在从系统长什么样转移到系统跑起来之后谁来看着它。
旅队系统:当构建变得廉价
de Montfort Walker说,现在很多功能突然变得很便宜,生产应用变得容易,更小的团队效率极高。但我们以前那种工作方式不太管用了——流程的重心已经转移到了非开发环节:怎么把东西打包好?怎么工业化?
他举了设计师的例子,说这是他最喜欢的案例。以前Oracle有优秀的设计团队,专注于用户交互,但他们得把设计打包交给别人去写代码。现在设计师成了全栈工程师——他们和设计伙伴、行业专家以及大量token配合,产出接近可运行的应用。然后交给另一个团队:怎么架构它、加固它、跑完所有安全工具链?这就是他所说的旅队系统(brigade system)。一个团队负责生成,另一个团队负责架构、加固和安全。
来自APEX的教训
de Montfort Walker也坦承了风险。Oracle在自家低代码平台APEX上见过这个场景:当从没构建过应用的人突然能构建了,一下子就有了30个没人用的应用。
当构建变得便宜,商业论证和一个共同平台就变得更加重要。
他的建议
对客户,他的建议很直接:如果你只是把这些东西交给IT部门,当成一个看起来和以往所有项目一样的项目,我们大概走不了多远。
真正需要做的是拿起一个东西,从组织里抽出几个人,给他们打破东西和失败几次的许可,然后弄清楚新的旅队系统应该长什么样。
边界在哪里
需要指出的是,这是Oracle一位高管对自己公司路径的阐述。
60%到100%的叙事本身服务于Oracle的产品定位——它暗示Oracle的应用层逻辑是弥合差距的关键。旅队系统是Oracle内部经验,de Montfort Walker没有提供量化数据说明重组前后的效率变化,也没有讨论这种模式在多大程度上依赖于Oracle已有的平台生态。不过,他指出的机制——当生成成本下降时,瓶颈从做出来转移到跑起来之后谁负责——是一个不依赖于特定厂商的组织逻辑。
信息源:diginomica