百家乐AI资源研究组把一张垃圾桶照片丢给语言模型，它可能会写出一段像模像样的分析，但未必能准确指出外卖包装里哪一层是复合材料、瓶盖和瓶身是不是同一种塑料——识别材料这件事，从来不是语言模型真正擅长的能力。家庭资源管理需要的，是几种模型各司其职，而不是一个模型包揽所有工作，这也是理解百家乐整套系统绕不开的一层架构逻辑。
五个环节，需要五种完全不同的能力
把家庭资源管理拆开来看，至少能分出五个环节，每个环节需要的能力都不一样：
- 理解用户目标、生成解释：交给语言模型（LLM）
- 识别垃圾、食品、材料的图像内容：交给视觉语言模型（VLM）
- 预测食材消耗速度、家电用电模式：交给时序预测模型
- 计算材料的隐含碳与全生命周期影响：交给生命周期数据库匹配模型
- 在多个目标之间取舍，给出具体行动方案：交给优化算法
这五种能力如果都压在一个模型身上，结果往往是每一项都做得不够精准：图像识别的边缘细节会变粗糙，数值预测会变得不稳定，最后给用户的解释也会因为模型要兼顾太多任务而变得笼统。反过来，如果每个环节只交给最擅长这件事的模型，各自的输出质量都能维持在一个更可控的水平，代价是需要多花精力设计模型之间怎样交接结果。这种分工思路其实和常见的软件系统架构逻辑很像——把一个复杂系统拆成职责单一的模块，每个模块只对自己负责的那部分输出质量负责，而不是造一个什么都会一点、但哪个环节都不够扎实的单体系统。
为什么不能用一个大模型把这些都做了
语言模型的强项是理解语义、组织语言，让它去判断一张照片里塑料盒和纸套的边界在哪，属于典型的"用错工具"：细粒度视觉识别需要专门在图像数据上训练、针对材质边缘和纹理做判断的模型，语言模型缺乏这种像素级别的敏感度。反过来，视觉模型虽然认得出"这是一片菜叶"，但不擅长做跨越几周的消耗趋势推理，也不擅长把多个目标之间的取舍讲清楚。时序模型能预测出一个数字，却解释不清这个数字背后的逻辑——它可以告诉你"下周叶菜消耗预计下降35%"，但没法自己组织成一句用户愿意读下去的话。每种模型都有自己明确的能力边界，架构设计的核心就是承认这些边界，而不是指望某一个模型"够聪明就能通吃"。
模型之间怎么交接数据
百家乐AI的处理流程大致是：视觉模型识别垃圾和食品后，输出的不是一句话描述，而是结构化的标签和置信度（比如"塑料盒，置信度0.91"）；这些结构化结果进入时序模型，与历史库存、采购记录一起预测未来几天的消耗或浪费趋势；预测结果再交给优化算法，在成本、隐含碳、食品安全等多个目标之间做权衡，产出具体的行动建议；最后由语言模型把这些偏"工程语言"的结果，转写成用户能直接看懂的一句话或几条建议。每一步交接的都是结构化数据，而不是自然语言，这样才能避免信息在传递过程中变形。如果中间某一步改成用自然语言传递——比如让视觉模型直接生成一句"垃圾桶里大概有一个塑料盒"交给下一个模型去理解——反而会引入额外的解析误差，这也是为什么模型之间的接口更像是工程系统里的数据协议，而不是几个模型互相"聊天"。
模型选不对，协作也会白搭
多模型架构还有一层容易被忽视的成本：选错模型规模同样会拖累整体效果。如果视觉识别环节用了一个过于轻量的模型，虽然响应快，但复合材料的细分类别识别不准，后面时序模型和优化算法拿到的就是错误的输入，越往后修正成本越高；反过来如果每个环节都堆最大规模的模型，推理延迟会明显增加，用户等一条建议要好几秒甚至更久，体验上也不划算。比较现实的做法是按环节的重要性和容错空间分配模型规模——直接影响后续判断的识别环节适当加大，最后负责语言表达的环节可以相对轻量，因为它出错的代价是"话说得不够自然"，而不是"整条建议方向错了"。
模拟场景：一次跨模型的协作是怎么发生的
以一个模拟家庭为例：本周视觉模型识别出厨余垃圾中约31%是叶菜类，置信度0.88；同一时间，时序预测模型注意到这个家庭未来三天将有成员出差，参考历史数据判断叶菜类消耗量在类似情形下平均会下降约35%；优化算法结合这两个结果，建议本周叶菜类采购量减少约0.8公斤，并把结余的预算和厨房空间提示留给保质期更长的根茎类蔬菜；语言模型最后把这些整合成一句具体建议："这周有人出差，叶菜可以少买一些，冰箱里现有的量预计能撑到周五。"这条建议背后其实经过了四个模型的接力，但呈现给用户的只是一句自然的话。如果这个家庭没有出差安排，同样31%的叶菜厨余占比，时序模型给出的预测结论会完全不同，优化算法也不会建议减少采购——这说明同一个视觉识别结果，配合不同的时序背景，最终指向的行动建议可能完全相反，单看识别结果本身是得不出这个结论的。
协作也会出错——分工带来的新问题
多模型协作不是没有代价的。最常见的问题是置信度冲突：视觉模型识别某种材料的置信度只有62%，但时序模型和优化算法已经基于这个识别结果算出了一套明确的建议，这时候如果直接把建议推给用户，一旦识别是错的，建议也会跟着错。百家乐的处理方式是设置置信度阈值，低于阈值时优先提示用户确认而不是直接给结论，这一点和食品浪费预测里"宁可少判断也不乱判断"的逻辑是一致的。另一个问题是数据不同步——库存数据更新延迟几个小时，可能让预测结果和实际情况脱节，这需要在架构层面设计好各模块的更新频率，而不是简单地把所有数据都当成实时数据处理。还有一种更隐蔽的失效方式：某个环节的模型在训练数据之外的场景下表现变差，比如识别一款市面上少见的包装材料时置信度整体偏低，这时候如果下游模型继续按常规逻辑处理这批低质量输入，错误会被逐级放大。比较稳妥的设计是让每个环节都能把"我对这个结果不确定"这个信号继续往下传，而不是在某一步就把不确定性抹平、假装一切正常。
分工不是麻烦，而是精度的来源
把一个复杂任务拆成五个模型分别处理，看起来比"一个模型解决所有问题"更麻烦，需要维护更多接口、处理更多边界情况，但这恰恰是精度的来源。给出可执行的低碳建议之所以能做到具体、可执行，前提正是背后有识别、预测、计算、决策这几层分工清楚的模型在支撑，而不是指望一个足够大的模型凭直觉给出答案。往前看，这套多模型协作的思路也不是一成不变的——随着端侧模型能力的提升，未来一部分识别和预测工作有可能下放到本地设备完成，但语言模型负责理解和解释、专门模型负责计算和预测这个基本分工逻辑，短期内很难被一个单一模型取代，因为这背后对应的是完全不同类型的能力，不是靠堆参数就能同时补齐的，也不会因为某一个模型的版本升级就自动消失。
