Zalando商品建档：图片、主数据与人工审阅怎样接成可用属性

模型认出一件衣服的外观，还没有完成商品建档。Zalando需要的是符合类目规则、能被系统保存、可由编辑复核的属性代码。它没有先增加聊天入口，而是在原内容制作工具里预填建议，用紫色标记显示自动来源，再把最终决定留给人。

这项设计值得拆解的地方，是图片与主数据怎样装入Prompt、自然语言建议怎样回到系统代码，以及为何一份总体准确率还不足以决定哪些字段可以扩大使用。官方工程文章，2024-09-18

从录入工作中选出一段辅助，而不是接管全部制作

原流程中，内容人员在 Content Creation Tool 补充属性并做质量检查，之后商品才发布。文章称这一手工环节约占整体内容制作时间的25%，因此团队选择影响客户体验的图片属性建议来辅助工作。这是原工作量背景，不是新工具已经节省25%的测量结果。

用户仍在原界面检查和改动。自动建议带紫点并预先选入，使编辑知道哪些内容需要审阅；它减少的首先是从头填字段的动作，而不是取消质检。品牌资料、合作伙伴输入和图片等来源也可以通过聚合服务接入，避免产品只依赖某一个模型输出。Current Process、Solution、Challenges and Solutions

四个组件，把输入与输出接回字段

官方展示的简化流程有四个组件：

主数据不是模型生成后的附加字典，它先决定本次应该问哪些字段、允许哪些值。图片也不是一张可随意替换的附件：团队发现纯商品正面图效果最好，其次是模特穿着的正面图；输入图片选择同时影响准确性与成本。Design and Implementation、Challenges and Solutions

这个流程公开到了组件与职责，没有公开完整请求JSON、系统Prompt、重试与保存事务。因此图可以解释数据从哪里来、往哪里回，不能补画成未经披露的全自动发布链。

主数据代码要来回翻译，类目规则不能只靠图片猜

系统为多个市场保存属性代码，而模型更容易理解英文含义。文章举出的 assortment_type 有两个内部值代码，需要先转换成 Petite、Tall 等人类词语，收到建议后再转回代码。这里不应把代码字符串当成模型天然知道的业务知识。

团队还建设转换层，使输出与自身API兼容，过滤无关内容；另用类目映射规定哪些属性适合显示。某些商品类型不应填某个字段，模型却可能因为图像相似而给出答案，不能让“有一个合法枚举”掩盖“不适用于本商品”。复杂属性另有Prompt指导，例如区分普通V领与较低开口的V领。Challenges and Solutions

这构成三层不同错误：图片判断错、语言建议转码错、或代码虽合法却不适合该类目。只在最终字段上记一个对／错，会把三种修复工作混在一起。迁移到自己的目录时，应保留原图与来源、模型候选、代码映射及人工修改理由，才能决定该改输入、提示、字典还是界面。

“映射不了就标为未决”是迁移建议；公开文章未说明具体未决状态与回退接口。它的目的，是避免为填满字段而偷偷选最接近的枚举；具体状态与回退应按自己的接口定义。

少见属性，为什么要单独看

团队最初由领域专家审阅多种模型对实际目录样本的预测，比较准确性与覆盖。后续换用GPT-4o前也先人工对照，原因包括结果、速度和成本；它们是当时的选型经历，不是今天照搬模型版本的理由。

这篇工程文章没有给出完整评测集，但披露了有用失败类型：常见领口容易，细分时尚术语较难。在按真实商品比例采样时，少见属性的问题容易被掩盖；每种属性放同样数量的平衡样本，会更明显暴露差异。两种样本分别回答日常工作量与薄弱能力，不应只留一个总分。Our Approach、Challenges and Solutions

生成成本也曾高于预期。团队停止为不支持的属性集合生成建议，再更换模型降低成本。这比每次无差别生成后再丢弃更有针对性：不适用的字段在任务入口就应被识别，不能只靠输出过滤补救。

每周五万个属性，不代表免审发布

文章披露约75%准确率、平均每周丰富约50,000个属性，并说明可以控制哪些商品或属性进入上线范围。它没有完整说明准确率的样本构成、错误严重度、编辑采用率与净节时，不能解读成四分之三商品可直接免审发布。Results and Impact

用户没有修改，也只能说明他接受或略过了建议，不能独立证明事实正确。预填提高速度的同时，可能使编辑更少质疑已有值；这是迁移时需要测试的交互风险，而非本案例已量化的事故。

可以先按一个有明确类目和质检标准的范围比较完整制作时间：人工填值、审阅建议、质检与返工分别记录，对最终采用结果再独立抽查。稀有属性、来源冲突和图片不能判断的字段另列。只有合法值、适用范围和人工接受都能核对，属性建议才变成可用目录数据；更多生成数量本身不会完成这段交接。