亚博 AI 与食品供应链大模型

如果你问一个食品供应链大模型"供应商A的碳足迹认证还有多久到期",它给出一个流畅、格式工整、语气笃定的答案——但这个答案其实是编出来的,你当场很难发现,因为它读起来完全合理。这正是纯粹依靠对话历史和通用语料训练出来的大模型,放到食品供应链场景里最危险的地方。

大模型本质上是在预测"接下来最可能出现的词"。它见过大量关于认证、批次、碳排放的表述方式,知道这类回答通常长什么样子,但它并不掌握某个具体供应商此刻的认证状态,也不掌握某个具体批次此刻的碳足迹数值。这两类信息不在训练语料里,也不会随着企业系统里数据的更新而更新。如果直接问模型"批次R2601现在的碳足迹是多少",又没有接入真实数据的能力,它大概率会给出一个数值区间合理、单位正确、格式像模像样的答案——但这个数字很可能和系统里的真实记录完全对不上,模型自己也不知道错在哪里。

为什么这类问题必须经过检索,而不是靠模型"记住"

企业实际会问的问题,往往具备三个特征:需要实时状态(认证是否已经到期)、需要可追溯的具体记录(某一批次,而不是"某类产品的平均水平")、需要在出错后说得清数据从哪来。这三点决定了答案不能来自模型参数里存储的统计规律,而必须来自这次提问触发的一次真实数据检索。

这也是检索增强生成(RAG)存在的原因。RAG 的思路不是让模型"凭记忆回答",而是先把用户的问题转换成对企业数据的一次检索动作,取回和问题相关的真实记录,再让模型基于取回的内容组织语言、生成表达。模型负责理解问题、组织语言,不负责编造事实。完整链路大致是:用户提问(User Question)进入大模型(LLM),大模型判断这是一个需要查数据的问题,触发数据检索(Data Retrieval),把自然语言问题转成对数据库或知识图谱的结构化查询(Structured Query),查询结果还要经过业务规则校验(Business Rule Validation)——比如认证记录是否包含"到期日期"字段、批次记录是否真实存在、数值是否落在合理区间——最后才把校验过的结果(Result)返回给用户。

拿"供应商A的认证是否过期"这个问题举例。合理的处理方式是:大模型识别出这是一次认证状态查询,生成一条结构化查询,去认证记录表里按供应商ID和认证类型检索,取回发证日期、有效期、签发机构等字段,再用当前日期和有效期字段做比较,得到"已过期"或"还剩多少天"的结论。这个结论准不准,取决于查询语句写得对不对、认证记录本身是否更新及时,而不是模型的语言能力强不强。同样,"批次R2601当前碳足迹"这类问题,也必须经过结构化查询取到该批次实际使用的原料、加工工序,以及对应版本、对应生效年份的排放因子记录,再按公式计算,而不是让模型直接凭"感觉"输出一个数字,例如把供应商A去年1.7 kg CO₂e/kg的排放因子和今年改用可再生能源后1.3 kg CO₂e/kg的新因子搞混,套错年份就会算出一个看似正常、实际错误的结果。

值得一提的是,2026年行业里已经有数十个软件平台声明符合WBCSD发布的PACT方法论第三版的数据交换协议,这套协议本身依赖的就是供应商之间结构化数据的直接交换,而不是自然语言描述。这从另一个角度说明,碳足迹这类数字从源头开始就被当作结构化数据在系统间传递和核对,大模型没有理由绕开这套体系,自己"估"出一个数字来搪塞用户。

编造在食品供应链场景里不是"答错一道题"

在普通聊天场景里,大模型编造一个不存在的历史细节或者算错一道数学题,后果通常是用户重新提问、体验打折扣。但在食品供应链场景里,如果模型编出一个不存在的供应商名字、一个听起来合理但系统里根本查不到的批次号,或者一个自己"估算"出来却没有真实排放因子支撑的碳足迹数字,这类内容一旦被写进内部报告、提交给审计方,或者被下游团队当作事实引用,产生的是实质性的合规风险和追责难题。因为它披着"系统给出的数据"这层外衣,反而比一个人凭经验估算更容易被误当成权威结论。这也是为什么食品供应链场景对大模型的要求,不是"回答得像不像样",而是每一个具体的批次、供应商、碳排放数字、检测结果、认证、温度记录,是不是真的能在结构化数据里找到出处——找不到出处的内容,无论语言组织得多流畅,都不能作为最终结果输出给用户。

结构化数据和知识图谱,是答案"有根"的另一半

结构化数据校验解决的是"这一条记录本身对不对"的问题,比如认证记录的有效期字段不能为空、批次记录必须关联到真实存在的生产工厂。但企业里供应商、物料、批次之间往往是网状关系,一个批次可能追溯到好几个上游供应商,一个供应商也可能同时对应几十个批次,这类多跳关系光靠一张张孤立的数据表去查,效率很低,也容易漏查。这部分工作通常交给知识图谱(Knowledge Graph)来承担——把供应商、物料、批次、工厂之间的关系组织成图,大模型再基于图谱结构做多跳查询,而不是自己在脑子里"拼凑"这些关系。这个话题展开会很长,这里只需要记住一点:无论走的是关系型数据库的结构化查询,还是知识图谱的多跳查询,原则都是一样的——大模型负责理解问题、组织语言,真正的数字、名称、状态,必须来自查询取回的真实记录,而不是模型自己"想"出来的。

供应商数量到了几万、几十万这个规模以后,"这个批次涉及哪些供应商"这种问题,已经不是一次简单的数据库查询能答完的,因为答案本身是一条链,而不是一行记录——批次牵出原料批次,原料批次牵出供应商,供应商还牵出认证、审计、风险信号,一层套一层。

供应商-物料-批次-工厂,是一张网,不是一张表

把这些实体各自建一张表当然可行,但表和表之间的关联一旦超过两三层,写查询语句的复杂度会迅速上升。比如生产批次P0312这一个批次,可能同时用到原料批次R2601拆分出来的一部分,也用到另一个原料批次R2605拆分出来的一部分,而R2601和R2605又分别来自供应商A和供应商C。如果还要往下问"供应商C是否有有效认证""供应商C最近是否被标记过风险信号",这就是从批次出发,经过原料批次、再到供应商、再到认证记录、再到风险信号,一共四五跳的关系。这种"多跳"结构,正是知识图谱(Knowledge Graph)要解决的问题——把供应商、物料、批次、工厂都作为节点,把"供应""生产""流向""认证"这些关系作为边组织起来,查询的时候不是一张表一张表地对,而是沿着图里的边一跳一跳走过去。

大模型在这里承担的角色,是把用户的自然语言问题——比如"批次P0312涉及哪些供应商,这些供应商是否都有有效认证"——转成图谱能理解的多跳查询路径:先从批次节点找到关联的原料批次节点,再从原料批次节点找到供应商节点,再从供应商节点找到认证记录节点,最后逐个比对认证的有效期字段。模型做的是"把问题拆解成正确的路径",走图和取数据这部分,靠的是结构化查询(Structured Query)在图谱里的确定性遍历,不是模型自己"记得"供应商C的认证状态。

2026年的一个真实趋势:风险判断必须能拆开看

供应链风险图谱这类系统,行业里通行的做法是把大量企业实体和供应关系组织成图,用来识别潜在的中断风险。2026年一个比较明显的变化是,行业对"可解释性"的要求明显提高了——当一个供应商被系统标记为高风险时,无论是负责审核的人还是辅助分析的AI,都必须能够回答清楚三件事:是哪些具体信号导致了这个判断、这些信号是什么时候采集的、每个信号在最终判断里占多大权重。换句话说,"高风险"这三个字不能是一个孤零零的结论,它背后必须挂着一串可以逐条打开检查的证据链。

放到图谱结构里看,这件事其实是自然的——因为风险信号本来就可以作为图里的一类节点存在,每个信号节点带着自己的来源、采集时间、权重,再通过边连接到具体的供应商节点。假设供应商C的风险状态是"高风险",拆开看可能是三个信号叠加的结果:一是最近一次审计记录显示存在整改项且尚未关闭,采集于审计当月;二是该供应商关联的某张认证在近期已过期,采集时间是系统例行核验认证有效期的当天;三是同一供应商在另一条产品线上被下游企业标记过交付延迟,采集时间来自另一套物流系统的同步记录。这三个信号各自的权重不同,采集时间也不同,把它们分别列出来,而不是只给一个笼统的"高风险"标签,审核人员才能判断这个结论现在还站不站得住——比如那个整改项如果上个月已经关闭,风险等级就应该跟着往下调整,而不是一直沿用旧结论。

图谱让答案"有据可查",而不是一个黑箱分数

大模型基于图谱回答问题的完整链路,和前面提到的结构化查询链路是一致的:用户提问(User Question)进入大模型(LLM),模型判断这是一个需要多跳关系的问题,触发数据检索(Data Retrieval),生成对知识图谱的结构化查询路径(Structured Query),取回的信号、认证、批次关联关系还要经过业务规则校验(Business Rule Validation)——比如信号是否已经过期、权重加总方式是否符合企业自己定的风险评分规则——最后才把校验过的结果(Result),连同证据链一起返回给用户。这里同样必须明确一点:大模型不能凭空创造批次、供应商、碳排放数字、检测结果、认证或者风险信号本身,它能做的是沿着图谱把已经存在的这些记录找出来、拼接成一条可读的解释链,而不是在图谱查不到答案的时候自己编一个供应商名字或者编一条认证记录去填补空白。

这也是知识图谱和大模型配合的核心价值所在:如果只让大模型直接输出"供应商C风险较高,建议关注",这是一个黑箱结论,审核人员没法验证,出了问题也没法追责是模型判断错了还是数据本身有问题。但如果答案背后挂着图谱里可以逐条点开的信号节点、时间戳和权重,任何一个结论都可以被拆解、被复核、被推翻,这才是几十万级供应商规模下,企业愿意把风险判断这件事交给系统去辅助处理的前提。

如果一个大模型可以直接把某个批次的碳足迹数字改写进系统,那你以后永远没法确定,这个数字是设备实测出来的、还是供应商更新报送的、还是模型某一次"理解错了"顺手改的。一旦这三种来源混在一起且没有留痕,整条批次的历史数据就再也说不清楚了。这正是大模型接入企业ERP、MES、WMS等系统时,最需要划清楚的一条边界。

连接系统,不等于拥有写入权限

企业让大模型接入ERP(企业资源计划)、MES(生产执行系统)、WMS(仓储管理系统)以及供应商系统,目的通常是让员工能用自然语言问出"批次P0312现在在哪个仓""供应商C这个月交付延迟了几次"这类问题,省去自己翻好几个系统、拼好几张表的功夫。这件事本身,靠的是模型把自然语言问题转成对这些系统的查询,和前面反复提到的链路是一样的:用户提问(User Question)进入大模型(LLM),触发数据检索(Data Retrieval),生成结构化查询(Structured Query)分别打到ERP、MES、WMS各自的数据接口上,取回结果后经过业务规则校验(Business Rule Validation),最后把校验过的结果(Result)返回给用户。这条链路从头到尾都是"读",模型只是把散落在不同系统里的真实记录找出来、组织成一段人能看懂的话,数字、批次号、供应商名称全部来自查询结果,不是模型自己编出来的。

但"查询和分析"跟"直接写入修改"是两件完全不同的事。让模型拥有直接修改批次记录或碳排放数据的权限,风险不在于它"大多数时候"会不会做错,而在于哪怕只错一次,后果也可能扩散得很远。

一次理解错误,可能污染整条历史数据

假设有员工对着系统说"把P0312的碳足迹按最新的供应商数据重新算一下,改过来吧"。如果模型有直接写入权限,而它对"最新"这个词的理解出现偏差——比如把应该用的2026年新版排放因子,当成了还没正式生效的草案版本;或者把P0312和另一个编号相近的批次P0311搞混——系统里这条批次记录就会被一个错误的数字覆盖掉。更麻烦的是,碳足迹数据往往不是孤立存在的,它会被汇总进季度报告,被引用进对外披露材料,如果下游还有基于这个批次做的分摊计算,错误会跟着一起传下去。等到有人发现数字不对劲,原始的正确记录可能已经被覆盖,不留痕迹地"消失"了,想查清楚是哪一次操作、哪一句指令导致的改动,往往非常困难,因为自然语言指令本身就存在多种理解方式,不像一条明确的系统日志那样可以直接对应到一次具体的写入动作。这种"污染且难追责"的组合,在批次记录和碳排放数据这类需要长期保持一致性、并且可能被审计方或监管方回溯核查的数据上,是不能承受的代价。

合理的架构:模型出草稿,规则和人来把关

比较稳妥的做法,是把"生成建议"和"真正写入系统"这两步拆开,中间插入结构化的业务规则校验和人工确认,也就是前面链路里业务规则校验(Business Rule Validation)这一环真正该发挥作用的地方——它不只是用来校验"读"出来的结果对不对,更要用来把关"写"这个动作能不能发生。具体来说,模型基于用户的自然语言请求生成的,应该是一份可读、可比对的修改草稿,比如"建议将批次P0312的碳足迹从X改为Y,依据是供应商C申报的2026年新排放因子",而不是直接执行覆盖。这份草稿要先经过业务规则的校验,比如新数值是否超出该类产品历史波动的合理区间、引用的排放因子版本是否已经正式生效、修改是否与批次的原料构成对应得上;校验通过之后,还需要有权限的人工确认这份草稿确实符合实际情况,才允许真正写入系统,而且这次写入本身要留下清楚的记录——是谁在什么时候基于哪一份草稿确认的。

这套流程看起来比"模型直接改"要慢一步,但慢的这一步恰恰是碳排放数据和批次记录能够被信任的原因。每一次变更都有草稿、有校验依据、有确认人,出了问题可以顺着这条链条往回查,而不是面对一堆已经被覆盖、说不清楚来源的数字束手无策。大模型在这里的定位,自始至终是帮人把问题问清楚、把数据查出来、把修改建议写明白,凭空创造批次、供应商、碳排放数字、检测结果、认证或者温度数据,以及绕过校验直接改写这些关键记录,都不在它的职责范围内。