Uber Eats：修好照片之前，先证明没有改掉食物

外卖照片更漂亮，并不代表更适合发布。新增配料、改变份量、抹掉酱汁或把各家餐厅都修成同一种风格，都可能让“质量提升”变成误导。Uber Eats 团队公开的多模态照片增强实践，把真实性放在了生成效果之前。

这里的工程问题不是选一个会修图的模型，而是把三件事分别做对：这张照片该不该改，应该改哪里，改完能不能发布。一个环节的高分，不能替另一个环节签字。Uber 团队公开演讲与图示

路由器先决定“值得编辑吗”

输入不只有图像，还包括菜品描述与相关信息。理解阶段提取图像特征，路由器依据评价规则决定跳过还是增强。这里“正例”的含义是应该增强，不能把评测中的 precision、recall 脱离这个定义直接搬用。

路由错误有两类不同代价。把已经合适的照片送去编辑，会增加无益变化甚至失真的机会；漏掉确有问题的照片，则保留了原来的质量缺陷。二者在总体“照片变好比例”里可能互相掩盖。

团队用覆盖地区、菜品和质量差异的样本，让人工判断与路由器判断对照，再分析不一致。评测集需要包括本来就好的照片，否则系统可能通过“什么都改”取得虚假的积极表现。

演讲 9:44 附近展示过照片中的鸡翅数量与描述不一致的例子：它用于说明路由阶段的漏检如何把风险传给下游。讲者进一步讨论了生成阶段可能补出食物的危险，不是已披露的线上事故。

编辑提示词针对本图生成，失败反馈回到下一次尝试

进入增强链后，提示词生成环节结合原图、路由指令和质量检查反馈，提出本图的修改方向，再交给生成环节。它不是一段万能“美食摄影”提示词套所有图片。

这条链必须同时保留两个参照：原图说明食物本来是什么，修改目标说明本次要改善什么。只有目标没有原图约束，容易把真实菜品重新创作；只有原图没有明确目标，则可能生成一张几乎相同、却仍有原问题的图。

团队公开的迭代例子包括：第一轮编辑让摆盘或份量不理想，检查反馈再进入下一轮。循环有尝试预算，但没有公开具体上限。

这里的实质是让失败成为下一步可用的信息。反馈如果只有“质量差”，生成环节并不知道应该保持什么、修复什么；反馈若能定位真实性、构图或物理合理性，才可能减少盲目重试。如何表达这些反馈，公开材料没有给出完整提示词。

质量检查比较原图和新图，而非单看新图

单独看成片，新增的虾或消失的酱汁可能都很自然。只有与原图、菜品信息一起比较，才有机会发现不忠实。

团队把评价拆成真实性、完整性、自然程度和视觉合理性等方面，允许“不确定”判断。公开例子分别揭示了不同失败：

• 图像更丰富，却加入了原本没有的食材。
• 画面更干净，却删除了菜品的一部分。
• 盘子或背景换了，实际没有改善原来的问题。
• 遮挡关系或酱汁位置违反物理常识。
• 份量无法可靠判定，不能因为成片好看就默认通过。

这些失败不应揉成一个美学分数。商品展示对真实性的要求，与海报创作不同；较高的摄影效果不能补偿错误的食物内容。

本案例能借鉴的，是把“未能确认真实性”与“确认不真实”都视为需要处理的状态，而不是强迫评价器对所有图片给一个肯定答案。具体拒绝规则和阈值仍需按业务验证，不能从演讲推导一个通用数值。

发布检查是另一道责任边界

生成迭代后的检查，服务于修图过程；最终发布检查则面对整张图能否进入菜单。这两个位置可以有重叠规则，但责任不同：前者给修改反馈，后者决定是否接受产物。

演讲把多道检查比作互补防线。它不是宣称层数越多越可靠，而是承认单个判断器会有盲点。若所有检查使用完全相同的证据与错误倾向，堆叠次数未必能增加保护。

可横向查看，点击打开原尺寸 ↗

图依据公开演讲重构：生成反馈、配置改进与上线效果分别闭环；未展示未披露的服务接口或审核阈值。

最终检查也不能替代商家和用户反馈。模型能检查图像一致性，未必知道包装、摆盘是否仍符合这家餐厅的品牌；从业人员与商家判断仍有信息增量。人工审批权限与具体审核流程未公开。

三层闭环，各自改不同的东西

单次生成循环使用本图检查反馈，尝试改善当前图片。它不应在失败后直接改全局规则。

配置改进循环从生产样本与人工标签的不一致出发，经诊断、反思与方案合成，生成候选配置，再通过基准测试后进入配置库。这里测试的是改动能否推广：解决一种错误，是否同时损伤另一类原本正确的照片？迁移团队还应验证部署后的监控与回滚能力。

产品反馈循环把内部试用、商家与设计/产品团队意见，以及上线后的行为信号带回诊断。点赞或自由文本反馈可能指向路由、提示词、生成或质量检查的多个环节，不能每次都归咎于模型本身。

演讲提到加购、转化和订单完成等下游指标，并按地区、设备、菜品等观察差异。这是上线后的验证方向，不是已经公开一项确定的提升幅度。照片表现可能受到流量、价格和商家运营等因素影响，不能把相关性直接归功于修图。

能追踪执行，才知道该改哪一环

团队介绍了把代理执行信息整理为扁平记录并接入 Arize 等观测工具。它的作用是把一次失败追到具体判断或调用，而不是只保存最后一张图片。

公开材料没有发布完整事件结构、模型供应商、检索内容、提示词、重试预算或接受阈值。检索对象未说明，尚不能判断是否包含品牌规范。

迁移时应先验证一条最小可追踪链：原图和描述是什么，为什么决定编辑，本次改什么，哪一项检查失败，是否重试，为什么最终允许或拒绝发布。每个问题都应该能定位到证据，而不是用一段事后生成的解释补齐。

先用失败对照审查现有方案

从已授权的真实照片与已发生的编辑结果中，选出三类：无须修改却被改动、视觉更好却内容失真、系统无法确定是否忠实。让业务人员逐一说明拒绝理由，再看这些理由目前归谁判断、在哪一步生效。

如果系统只能回答“新图得分更高”，还不能支持商品照片的发布决策。这个案例的关键，是把好看、真实与可发布分开，让每个判断都有自己的证据和纠错入口。