当一个企业决定把AI放进核心业务流程，它在本质上购买的是什么？
不是一份模型权重，不是一套API调用额度。它购买的是一个承诺——承诺那份概率性的、本质上不可完全预测的智能输出，能够被封装进确定性的、可审计的、可回滚的业务逻辑之中。这是一个几乎自相矛盾的需求。而最近几份来自不同方向的技术信号，恰好把这个矛盾的内在结构暴露得清清楚楚。
但在展开之前,我们需要先锚定一个词。当我们在谈论企业级AI的“不确定性”时,它至少指代三种不同的东西:第一,质量方差——同一个模型、同一个提示词,五次生成出五个水准完全不同的结果;第二,可解释性缺失——模型的决策链路长到无法追溯,当它犯错时你找不到“为什么”;第三,使用风险——当这种不可控被接入自动化的业务流程,每一次输出都可能成为累积性的安全债务。这三者关联但不相同,而它们共同指向同一个工程命题:如何把概率性的智能压缩进确定性的系统框架里。这才是我们要谈的核心。
先说Granite 4.1。表面上,IBM只是又发布了一组开放权重模型——3B/8B/30B,似乎是那条熟悉的“更大、更强”赛道上的又一个选手。但如果我们只盯着参数规模,就完全读错了这份更新的信号。真正值得注意的是它的训练工程结构——这不是一个“更大”的故事,而是一个“更完整”的故事。
15T tokens的总训练量,被刻意拆成了五个阶段。前两阶段打通用能力的底子;第三、四阶段逐步调高高质量数据、代码、数学、长CoT和指令数据的占比;第五阶段把上下文窗口扩展到512K。这意味着什么?如果只是在讲“先学通用后学专业”,那只是命名现象,不是揭示机制。更深一层:分阶段注入高质量数据,本质是通过课程学习控制模型在参数空间中的收敛路径。模型在训练的早期阶段,损失函数的地形还相对平缓,此时接触的数据类型决定了它向哪个局部最优滑去。如果前期就混入大量高噪声、低质量的数据,模型可能陷入那些容易产生幻觉的局部极小值——这些极小值的特征是,它们对训练分布的拟合看似还行,但泛化到未见的提示词时,输出方差会剧烈放大。反过来说,先把参数空间锚定在一个对通用语言结构有良好表征的区域,然后再逐步引入高价值数据做微调,是在训练动力学层面前置性地压缩输出方差。这不是比喻,这是优化路径的选择。第五阶段把上下文窗口扩到512K,也不是简单的“加长输入”——当模型需要在极长的上下文中保持推理的一致性,任何中段的注意力散失都会被放大为整体的逻辑断裂。这个阶段的训练,本质上是在调试模型对“长程因果链”的保真度。
这还不是全部。后续的SFT使用了大约410万条高质量样本,而后接的是on-policy GRPO + DAPO loss的强化学习流程。比较一下市面上大量模型“预训练+简单SFT”的粗糙流程,Granite 4.1这一套管线真正复杂的地方在于:它不只教模型“如何回答”,还通过强化学习让模型学会“如何回答得更好”。这里需要把GRPO的机制讲清楚一次:Group Relative Policy Optimization的核心是组内相对比较——不是看一个回答的绝对得分,而是在同一批提示词下生成的多个回答之间比较优劣,用相对优势信号来更新策略。这天然具备一个效果:它惩罚的是输出质量的大幅波动。因为一个模型如果在同一输入下时而好时而差,组内相对比较会持续地给那些“偶尔差”的轨迹负反馈,迫使策略网络学会稳定地产出高分回答。而DAPO loss解决的是奖励稀疏问题——当强化学习的反馈信号太少时,模型很难建立行为与奖励的因果关系。结合这两者,on-policy GRPO+DAPO这套流程不是在教模型成为“最聪明的那个回答者”,而是在教它成为“最稳定、最不犯低级错误的那个回答者”。这已经非常接近人类学徒制的逻辑:不是背诵答案,而是在反复的实操中被反馈修正推理路径,最终形成某种肌肉记忆式的可靠判断。
换个角度,这种工程结构的根本问题在于:对不确定性的控制,必须发生在训练阶段,还是可以发生在使用阶段?
如果我们把视线从Granite 4.1移开,看向Flowable AI Studio——那个将AI嵌入业务流程管理的尝试——我们会发现,同样的结构性焦虑在另一个维度上展开。Flowable的工程师在做的是把LLM的生成能力与BPM的工作流引擎松耦合起来。他们明确使用了REST API或消息队列来集成AI服务,避免紧耦合。为什么?因为紧耦合意味着业务流程的确定性被模型的概率性“污染”。一个审批流程如果在某一步依赖AI判断,而AI判断的结果是无法预期的,那么整个流程就从一个有限状态机变成了一个随机过程。而松耦合的本质是风险隔离——把AI的输出放进一个可控的沙箱里,转译为流程变量,再让确定性的工作流引擎去驱动后续逻辑。AI不直接参与流程跳转,它只提供“建议”,而建议本身可以被审计、覆盖、回滚。
更进一步:Flowable用execution variables传递AI分析结果,用TaskListener捕获节点事件并触发模型再训练。这看起来只是技术细节,但深一层看,它勾勒出企业级AI的真正形态:AI不是一个独立的“大脑”,而是业务流程中的一个可替换、可观测、可反馈的组件。它的输出被转译为流程变量,它的决策被事件监听器捕获,它产生的数据被送回训练管线。这是一个闭环——不是“AI替代流程”,而是“流程驯化AI”。
然而,同样的风险隔离逻辑,在软件开发生命周期中恰恰是缺席的——这正是Vibe Coding暴露出的缺口。
Karpathy描述的开发模式里,开发者不再逐行写代码,而是退居到“导演”角色。Checkmarx的数据显示,50%的受访者使用某种形式的AI编码助手,三分之一的组织通过这种方式生成多达60%的代码。这个数字令人不安。因为LLM的概率特性——同一个提示词拉五次杠杆出五个结果——在企业级场景中,“可能中大奖,可能什么都没有”的不确定性,本身就是一种安全债。当一个开发者用Vibe Coding的方式生成了一段代码,它没有经过类型检查、边界条件测试、安全审计这些传统软件工程中“隔离不确定性”的关卡。这些代码直接被部署到生产环境的速度越快,累积的不可控债务就越大。Granite 4.1试图从训练侧压缩输出方差,Flowable试图从流程侧隔离AI的风险,而Vibe Coding揭示的,恰恰是当这两层控制都缺席时,机器规模的风险会以多快的速度累积。
这就是三份材料交汇处的真正问题。
Granite 4.1在模型侧努力的方向,是让输出更可预期;Flowable在流程侧努力的方向,是让AI的结果可被封装和审计;而Vibe Coding揭示的,是当这种可预期性缺席时,软件体系的脆弱性会达到什么程度。三个故事,同一个主题:企业级AI的核心矛盾不是模型的智能上限,而是组织对不确定性的容忍下限。
更深一层:这解释了为什么对于高合规要求的企业,开源权重提供了一种难以替代的价值。不是意识形态,不是成本——而是因为开放的权重允许组织自己去验证、去对齐、去将模型嵌入那些需要确定性控制权的系统里。你无法审计一个封闭的黑盒,但你可以审计一份你自己跑完的权重。这才是“开放”对于企业的真正含义——不是代码可见,而是风险可控。
所以,当我们一开始问“企业在购买什么”,这个问题最终指向的是:它购买的是对“我们真的能审计吗”这个问题的阶段性信心。
而这种信心的构建,体现在训练的分阶段设计里,体现在流程的松耦合架构里,体现在对“老虎机式输出”的防御性编码里。它没有大模型发布那样的戏剧性,但它才是那个让AI从demo走向生产环境的桥梁。
然而我们还没有解决的问题是:当模型的输出越来越难以被人类审计——当推理链条长到超出人类的注意力跨度——我们引以为傲的“松耦合”和“审计能力”,会不会变成一种仪式性的安慰?当GRPO+DAPO把输出方差压缩到某个程度后,我们会不会在某一天突然发现,自己已经不再关心AI“为什么这么回答”,而只满足于它“看起来挺稳定”?
这份信心,目前尚在施工中。而Granite 4.1的“分阶段训练”和Flowable的“事件监听反馈回路”,或许正是在为回答那个追问准备着砖石——同时也提醒着我们,那座建筑可能远比我们想象的要高。
