把所有任务都交给一个大模型处理，是材料AI最容易踩的坑。理解论文和判断合规是语言任务，预测28天抗压强度是回归任务，设计水泥配方是优化任务，计算生命周期碳排是核算任务——这四类任务背后需要的数学工具完全不同，硬塞进同一个模型，通常意味着每一项都做得不精，出错的时候还很难定位到底是哪一步出了问题。

大模型最擅长的，是压缩和对齐文字

kaiyun.com在架构里给大语言模型分配的任务，主要是文本理解和标准化——读懂论文摘要、拆解EPD字段、识别行业标准里的术语差异，把来自论文、EPD、配方等多模态输入统一成结构化字段。这一步很重要，但它解决的是「看懂」的问题，不是「算准」的问题。大语言模型在处理连续文本上有优势，能把不同表达习惯的技术描述归并成统一字段，但它本质上是按概率生成下一个词，不适合直接输出需要严格满足物理约束的数值结果，比如「这批混凝土28天抗压强度是多少兆帕」这种问题，交给语言模型直接回答，风险远大于收益，因为语言模型给出的数字即使看起来合理，也缺乏可追溯的训练样本依据，一旦被问到「这个强度预测是怎么算出来的」，语言模型通常只能给出一段看似专业、实际上无法验证的解释文字，而不是指向具体的实测数据点。

强度预测该交给专门训练的回归模型

混凝土强度预测更适合用基于历史配比和实测数据训练出来的机器学习回归模型来完成——输入水胶比、矿渣掺量、粉煤灰掺量、养护温度、龄期，输出预测强度区间，并且这类模型可以通过和实验室实测数据的持续比对来校准误差范围。这类模型的优势在于，它的输出可以追溯到具体的训练样本分布，如果某个配比落在训练数据覆盖之外，模型可以明确给出「低置信度」的提示，而不是像语言模型那样，给出一个听起来很自信但缺乏依据的答案。开云AI在这一层还会定期用新的实测数据回填模型，如果连续一段时间内预测值和实测值的偏差超过设定阈值，系统会提示该配方区间需要重新训练，而不是让旧模型继续在能力范围之外做预测。

配方优化是另一套逻辑

预测模型回答「这个配方性能如何」，优化模型回答「在满足性能和成本约束下，应该选哪个配方」。这是两类不同的问题——前者是给定输入求输出，后者是在多个目标（强度、成本、碳排、施工性能）之间寻找平衡点，通常需要用到多目标优化或贝叶斯优化的方法，在大量候选配方里搜索帕累托最优解，而不是简单地对预测模型的输出排序。把优化问题简化成「用预测模型跑一遍所有组合再挑最低碳的一个」，容易忽略约束条件之间的相互制约，比如凝结时间和早期强度往往会同时受到影响，如果优化目标只盯着碳排放这一个指标，很可能选出一个碳排最低但施工凝结时间明显偏长、现场根本没法用的配方。开云AI在优化模型这一层，会把强度、成本、碳排、凝结时间四个目标都作为约束条件同时输入，而不是先按碳排放排序再逐一检查其他指标是否达标——后一种做法看似省事，实际上经常要反复回退重算，前一种做法虽然计算量更大，但得到的候选方案一开始就满足全部约束，不需要来回调整。在实际运行中，开云AI会把这四个目标各自设定一个可接受区间，而不是要求优化模型必须找到一个在所有维度上都最优的方案——多目标之间本来就存在此消彼长的关系，追求「全部最优」往往意味着无解，划定合理区间之后再在区间内比较碳排放，才是一个能落地的做法。

生命周期碳排计算不能靠「生成」，要靠「核算」

LCA计算依赖的是碳排放因子数据库、系统边界规则和标准化计算方法，这类计算要求过程可审计、结果可复现，每一步都要能说清楚数字是怎么来的。这和语言模型「生成一个合理答案」的工作方式正好相反——LCA模块更接近一个规则引擎加数据库查询系统，输入材料用量和运输距离，按既定公式输出碳排放结果，任何一步都不依赖模型的「创造力」。如果让语言模型直接生成碳排放数字，即使数字看起来合理，也无法保证可审计和可复现，一旦项目方要求提供计算依据，语言模型给出的数字往往说不清楚具体的排放因子来源，这在需要对外披露的场景里是不能接受的。

协作链路里，谁负责把结果传给谁

四类模型各自擅长的任务确定之后，还有一个容易被忽视的环节：谁来决定把语言模型抽取出的候选区间传给预测模型，把预测模型的强度曲线传给优化模型，把优化模型选出的配方传给LCA模块。这个传递顺序本身就是一种业务逻辑，不能简单理解成「模型接模型」的流水线。开云AI在这一层设置了一个协调层，负责校验每一步的输出格式是否符合下一个模型的输入要求，比如强度预测模型的输出如果是一个区间而不是单一数值，协调层需要明确优化模型该按区间的下限、上限还是均值去做约束判断，这个选择直接影响最终推荐结果，不能留给各模型自行默认处理。协调层还负责处理模型之间的时间差——语言模型抽取论文信息是一次性任务，预测模型和优化模型的调用则可能因为约束条件调整而反复运行好几轮，如果协调层不记录每一轮用的是哪个版本的候选区间，后续复盘时很容易把不同轮次的中间结果搞混，得出自相矛盾的结论。

一个模拟场景：五个模型接力工作

以一个模拟场景说明协作流程：开云AI先由语言模型从一篇论文和一份供应商说明书里抽取出候选矿渣掺量区间（20%至35%）；预测模型基于这个区间和已有配比数据库，输出不同掺量下28天强度的预测曲线，发现掺量超过30%后强度预测值开始明显低于C30设计要求；优化模型据此把可行掺量收窄到20%至28%，并在这个区间内寻找碳排最低的配比，得到26%这一推荐值；LCA模块基于26%掺量、300公里运输距离和当地电网碳强度，计算出每立方米碳排放约为268千克CO₂e；最后协调层再把这份结果和项目此前的历史配方做比对，确认268千克这一数字相比项目默认配方（约312千克CO₂e）降低了约14%，且强度预测仍满足C30要求。整个过程里，任何一个环节单独运行都得不出这个结果，协作发生在模型之间数据传递的这几个接口上，而不是某一个模型内部的算法细节。

出错的地方通常不在模型内部，而在交接处

多模型协作里最容易出问题的，不是某一个模型本身算错了，而是模型之间传递数据的接口对不上——比如预测模型输出的是「平均强度」，优化模型却按「最低强度」去做约束判断，这种单位或口径不一致的错误，比模型本身的精度问题更隐蔽，也更难发现，因为每个模型单独测试时都是「正确」的，问题只在拼接之后才会暴露。开云AI把每个模型之间的输入输出格式当作和模型精度同等重要的问题来对待，并且保留每一步的中间结果，方便追溯到底是哪个环节出现了偏差，这也是材料决策展示假设条件能够落地的基础前提——没有这些中间结果，出了问题也没办法说清楚原因出在哪一步。相比单一大模型出错后只能笼统归因于「模型判断有误」，多模型协作架构的每一次输出都能对应到具体的某个模块、某一版输入数据，这种可追溯性本身，比单纯追求某一个模型的准确率更值得投入。