一个容易被忽略的风险：让大模型直接"算"排放量

大语言模型在处理自然语言、总结信息、生成结构化描述方面表现出色，这很容易让人产生一种想法：既然模型能理解赛事的各种运营信息，能不能直接让它输出一个碳排放数字？米兰体育在设计AI大模型层时，明确否定了这种做法。原因很直接：大语言模型生成数值的方式，本质上是基于语言模式的预测，而不是逐项相乘相加的确定性运算，即便它给出的数字看起来合理，也无法保证每一次计算都严格遵循同一套排放因子和边界规则，这类风险一旦发生在碳排放报告里，后果比普通的文字错误严重得多。

LLM擅长什么：把自然语言描述，转成结构化事实

大语言模型真正擅长的，是处理非结构化的现场信息。比如场馆运营人员写下的一段现场记录："今天下午观众入场比预期多了不少，临时开了两个补充停车区，晚上灯光加班到十点半"，这类文字里其实包含了可能影响碳核算的信息，但格式完全不适合直接输入计算模型。LLM的作用，是把这类描述解析成结构化字段，例如"临时停车区数量增加""场馆照明延时运行时长"，再交给下一环节处理。这部分能力，正好对应体育赛事碳模型到底需要多少种数据？中提到的九类输入数据里，那些原始来源本就是文字记录而非表格数据的部分。

碳核算引擎擅长什么：确定性规则下的重复计算

碳核算引擎是一套基于固定规则的计算系统：活动数据乘以对应的排放因子，再按照统一的边界规则汇总求和。这套逻辑一旦确定，就必须保证每一次输入相同的数据，得到的都是完全相同的结果，不能因为表达方式不同、上下文不同而产生偏差。这正是确定性引擎和语言模型的根本区别：引擎没有"创造性"，它的唯一职责是准确、可重复地执行既定公式。

为什么算术不能交给一个会"编"的系统

大语言模型存在生成看似合理但实际错误内容的可能性，这在碳排放计算这类需要绝对准确性的场景里是不能接受的风险。如果让LLM直接输出排放数字，即使大多数情况下结果正确，也无法从机制上排除个别情况下数字被"编造"出来的可能，而且这种错误往往很难被察觉，因为数字本身看起来完全合理。把计算职责严格限定在确定性引擎内，相当于从架构层面切断了这条风险路径：LLM不管有没有出错，都不具备直接生成排放数字的权限。

Function Calling：两者之间的连接方式

LLM和碳核算引擎之间不是各自独立工作，而是通过Function Calling机制衔接：当LLM从文字记录里解析出结构化信息后，不会自己计算结果，而是调用碳核算引擎提供的特定计算函数，把解析出的字段作为参数传入，由引擎完成实际运算，再把结果返回。这种方式让"理解语言"和"执行计算"始终是两个独立环节，LLM只负责判断该调用哪个函数、传什么参数，不负责决定最终数字是多少。

一个具体例子：场馆经理的一段现场记录，是怎么被处理的

回到前面提到的那段记录，LLM解析后会生成类似"停车区数量：临时增加2个""照明加班时长：约2.5小时"这样的结构化字段，这些字段随后作为参数传入碳核算引擎里对应的计算函数，由引擎按照场馆的用电排放因子完成实际的排放量计算。整个过程里，LLM没有在任何一步"猜"出一个排放数字，它只是把文字转成了引擎能理解的输入。这个处理链条，和米兰体育官网的赛事碳数据流程：从一张门票到最终碳足迹报告中描述的整体流程是衔接在一起的，文字记录只是众多原始数据来源中的一种。

分工之后，报告的可追溯性从哪里来

严格的职责划分带来的另一个好处，是报告具备可追溯性。因为每一个最终排放数字，都能对应到一次明确的引擎计算调用、一组具体的输入参数和一条排放因子，如果结果需要复核，可以逐层回溯到最初的原始数据，而不是面对一个无法解释来源的黑箱数字。这种可追溯性，是碳排放报告能被审计、被信任的基础，也是米兰体育坚持把LLM和计算引擎分开设计的核心原因。

如果没有这层分工，可能出现的问题

假设米兰体育没有坚持这层分工，而是让大语言模型根据场馆运营的自然语言描述直接生成一个排放数字，可能出现的问题主要有两类。一类是同样的场景描述，在不同的对话轮次里可能得出略有差异的数字，因为语言模型的生成过程本身带有一定的不确定性，即便底层信息完全相同，也无法保证每次输出完全一致。另一类是模型在缺乏明确排放因子依据的情况下，可能会基于训练数据里的常见数值做出"合理但缺乏依据"的估算，这种数字表面上看不出异常，但实际上并没有经过真实的排放因子和边界规则计算，一旦被当作正式报告数据使用，风险很难被及时发现。严格的职责分工，正是为了从架构层面避免这两类问题的出现。

工程实现上的具体做法

在具体实现上，碳核算引擎会预先注册一组具备明确输入输出定义的计算函数，例如"计算场馆用电排放""计算交通出行排放"等，每个函数都对应固定的参数格式和计算公式。大语言模型在处理完一段现场记录后，只能从这组预注册的函数里选择合适的一个进行调用，并且传入的参数会经过格式校验，任何不符合预期格式的参数都会被拒绝，模型需要重新解析或标记为"信息不完整，需人工确认"。这种预先注册、严格校验的方式，进一步收窄了大语言模型在整个链条里可能引入偏差的空间。

这套分工模式的适用边界

需要说明的是，这套"LLM读数据、引擎算排放"的分工模式，处理的是结构清晰、有明确计算规则的排放核算场景，对于一些暂时缺乏统一计算标准的新兴排放来源，模型给出的更多是定性描述而非定量结果，这类情况会在报告中单独说明，而不会被强行套入现有的计算函数框架。这种边界意识本身，也是米兰体育在设计AI大模型层时始终坚持的原则：宁可某些信息暂时无法量化呈现，也不让不成熟的计算逻辑混入正式的碳排放数字当中。

文本描述之外，LLM还能处理哪些辅助工作

除了解析现场记录，大语言模型在整个碳核算流程里还承担一些辅助性工作，比如对最终生成的排放报告做语言层面的润色和结构化呈现，把引擎计算出的分类数字和边界说明，组织成便于非专业读者理解的文字描述。这类工作同样不涉及数值本身的生成或修改，模型处理的对象是已经由引擎计算完成的结果，职责仍然局限在语言表达层面。这种"计算结果不变，表达方式可以调整"的分工方式，让报告既能保持数字上的严谨性，又能在呈现给不同读者(比如赛事主办方和普通观众)时采用不同的语言风格，而不需要重新触碰核心计算逻辑。

这种分工对使用者意味着什么

对于实际使用米兰体育碳核算服务的场馆或赛事组织方来说，这种分工模式意味着他们提交的现场记录可以保持自然、口语化的表达，不需要提前整理成结构化表格，大语言模型会承担这部分转换工作；与此同时，他们也可以放心，最终报告里的每一个数字，都是经过确定性引擎计算得出，而不是语言模型基于文字描述直接"猜"出来的结果。这种既降低了数据提交门槛、又保证了计算严谨性的设计，是这套分工模式在实际使用体验上的直接体现，也是它相比"一步到位让AI生成报告"这类看似便捷的方案更值得信赖的原因。