食品生命周期研究组
从一杯燕麦酸奶杯出发
设定一款燕麦酸奶杯：配料是酸奶、燕麦片、少量蜂蜜和坚果碎。产品经理想问三个问题：每杯有多少蛋白质和糖？哪一种原料对碳排影响最大？用水集中在哪个环节？在传统做法里，这三个问题要分别去查营养表、LCA数据库和水足迹报告，再人工拼在一起。
图谱的做法是把它们连成一张图，让查询沿着关系走。
产品节点连着配方节点，配方节点列出每种原料的占比；每个原料节点向一边连到营养成分，向另一边连到加工工艺（烘烤、发酵、浓缩）和产地；工艺与产地再各自连到排放因子和水足迹条目。问“哪个原料的碳排最高”，就是沿着“原料、排放因子”这两跳读出来，再乘上配方占比。
同一种原料有五个名字
图谱最先遇到的麻烦是实体对齐。“燕麦”在不同数据库里可能叫“燕麦，生”“燕麦片”“即食燕麦片”“Oats”“rolled oats”，含义并不相同：有的指未加工的籽粒，有的已经蒸过、压片、烘干。
对齐的原则是能合并的合并，不能合并的保留差异。籽粒与压片燕麦含水量不同，能耗不同，排放因子也不同，强行合并成一个节点，等于把加工阶段的差别抹掉。较稳妥的做法是给它们建立“同类但不等同”的关系，让查询时既能找到近似条目，又能看见差别，并且在最终结果里标明“使用了近似数据”。
单位和口径：最不起眼，最容易出错
| 数据类型 | 常见的口径差异 | 统一时的做法 |
|---|---|---|
| 营养成分 | 每100g可食部与每100g整体；生重与熟重 | 统一到每100g可食部，并记录含水量 |
| LCA排放因子 | 每kg产品与每kg原料；系统边界不同 | 记录边界（摇篮到大门等）和功能单位 |
| 水足迹 | 体积型（升/kg）与稀缺加权 | 分开存放，标注来源与方法 |
| 产地 | 国家、省份、流域粒度不一 | 存最细的粒度，向上聚合 |
这些差异看上去琐碎，代价却很大。如果把“每kg产品”的排放因子当成“每kg原料”，结果可能整体偏差数倍。这也是食品LCA数据来自不同国家、不同年份时的对齐问题在图谱层面的体现：图谱可以把口径信息记录下来，却不能替使用者决定哪种口径更合适。
RAG：让模型引用可核对的数据
检索增强生成（RAG，Retrieval-Augmented Generation）的思路很直接：用户提问以后，系统先到图谱和数据库里检索相关节点与数值，再把它们连同来源一起交给大模型，由模型组织成回答。回答里的每个数字，都能回到某个具体条目。
图谱让检索不止于“找相似文字”。问“这款酸奶杯的水足迹热点在哪里”，系统可以沿着原料、产地、水足迹这条路径取数，而不是让语言模型凭印象回答。这也符合2026年《Advanced Science》那篇综述对数据的划分：食物侧包括基础营养成分、加工过程的动态变化和活性成分组学，健康侧和个体侧则对应临床与穿戴、基因与问卷。图谱首先服务食物侧，再逐步与其他两侧对接。
在数字生命周期的设想里，工厂和物流的实时数据还会流进动态生命周期清单，图谱也需要为这类时间上会变化的数据预留位置，而不是只存一个年度平均值。
维护成本与授权，是图谱最现实的限制
图谱不是一次建成就结束的工程。新产品上市、配方调整、数据库更新版本，都要求节点与关系同步修改，而且每次修改都应保留版本和来源，否则半年后谁也说不清某个数字来自哪一版。
授权则是另一道门槛。商业数据库往往限制再分发，供应商的工艺参数和用水数据属于保密信息。数据缺失时，图谱应当如实显示“暂无数据”，而不是让模型补一个看起来合理的数。
要点：知识图谱的价值不在于数据多，而在于每条数据都带着名称、单位、边界和来源。带着这些信息，大模型才有资格“引用”，而不只是“说得像”。
纵横国际的思路是先把营养、原料、生命周期和水足迹四类数据的口径记录清楚，再谈上层的问答与推荐，让模型的回答可以逐条回溯。这套数据层与个性化营养为什么不能只依靠聊天模型、不同问题为什么需要不同模型是同一条链路上的不同环节，入口汇总在AI大模型栏目。
