端到端 94.2% / 82.8%：京东 Oxygen 怎么筛 Badcase

端到端 94.2% / 82.8%：京东 Oxygen 怎么筛 Badcase

京东云开发者社区在 2026 年 7 月 10 日发了 Oxygen AIIC 的商品知识生产记录。页面作者是社区账号 fe****。文内写完整报告在 arXiv:2606.28070，这篇社区稿本身给了评测口径和线上数字。线上那几项没有写统计窗口和分母。

Oxygen AIIC 是京东的商品知识生产平台，核心是大语言模型和视觉语言模型。它要在百万级本体、百亿级 SKU 上，把标题、主图、详情里的非结构化信息收成能给搜索、发品和治理用的属性。直接让大模型逐条生成，成本和延迟都撑不住。

自由生成先被判不合格

社区稿写了一项对照：本体一直在变，模型得反复重训；通用大模型直接生成属性值，精确率有限，千亿参数模型也不到 80%，而且幻觉重。这不是 Oxygen 自己的端到端分数，是他们不用「自由生成」的理由。

替代结构叫 S²D，Semantic Search-Then-Discrimination，先检索再判别。语义检索按商品信息从动态本体里召回 Top-K。判别阶段只在这 K 个候选里做 SKU 和本体的精确匹配。表征模型和判别模型用合成数据做领域微调。本体放在模型外面当知识库，本体变了不必重训参数。任务从「随便生成一个值」变成「在有限候选里筛选」。

先减计算，再报 92% / 78.3%

百亿 SKU 如果每条都跑完整链路，算力会耗在重复上。稿里写了三类现象：同一商品在多个店铺重复在售；通用属性极多、长尾属性极少，全量扫属性会浪费；同一 SPU 下的 SKU 介绍高度重合。同一 SPU 的不同 SKU，Prompt 里大约 85% 的信息相同。

所以计算从「全部 SKU × 全部属性」改成「有差异的 SKU × 高相关属性」：同质商品能复用结果就跳过推理；进 S²D 之前先做属性相关性探测，丢掉低相关属性。共享前缀用缓存避免重复 prefill。向量、检索、判别分在 NPU 和 CPU 上的 Faiss 集群，用细粒度数据并行和跨 Chunk 异步流水减少空等。

这套流程之后，AI 商品库的算法识别是 92% Precision、78.3% Recall。相对商家自填，平均每个 SKU 的属性数到 1.5 倍。商品知识资产规模（SKU × key × value）到 3.35 倍、千亿量级，其中 AI 生产占 70%，商家自填占 30%。吞吐写成提升 10 倍以上。92% / 78.3% 没有写测试集大小和标注方式。开篇另有一句「商品信息丰富度提升至原有的 3.35 倍」，和这里的资产规模倍数用了同一个数字，原文没有说明是不是同一次统计。

自演进是四段数据闭环，不是自动改线上

商品理解模型把知识抽取和知识识别放进同一个多任务底座，避免每个任务各养一个模型。新领域不重训底座：用 LoRAM 训轻量专家放进专家池，GROLE 按输入和任务给专家非负、加总为 1 的融合权重，权重用 GRPO 学。专家变多以后，再周期性全量微调，把增量收回到底座。增量负责快，全量负责整合。表征侧用 InstEmb 做隐式思维链蒸馏，用 FANoise、SDE 按谱方向加噪，避免营销话术盖住「防水级别」这类弱信号。这些名字是方法，稿里没有单列它们各自的消融分数。

真正对评测有操作定义的是第四段。只看宏观指标、不看失败原因就补数据，补进去的样本可能没用，甚至有害。以前靠算法工程师翻 Badcase。现在写成四段：数据评估，数据分析，数据合成，数据筛选。

• 评估：从线上反馈和主动探测样本里，用证据一致性、模型置信度、扰动稳定性挑 Badcase 和 Hardcase。
• 分析：把「结果错了」写成缺陷原因和修复建议。
• 合成：按这个原因造高信息密度的修复样本。
• 筛选：用现状模型和专家模型的损失差衡量样本值不值得学。点名的方法是 TANDEM 和 BLADE。

稿里没有写 Badcase 的条数、一致性阈值、扰动做了几次，也没有写损失差的通过线。

走完多任务微调、增量适配、指令表征和这套自演进之后，端到端商品知识生产是 94.2% Precision、82.8% Recall。相对上一阶段 C2，精确率高 2.2 个百分点，召回率高 4.5 个百分点。只有 0.8% 的属性精确率下降超过 5%。新增本体从属性键挖掘到数据生产完毕，周期从 30 天以上缩到 2 周。C2 是什么样本、94.2% 的分母是属性数还是 SKU 数，原文都没写。0.8% 说明多数属性没有明显退步，不能读成「只有 0.8% 的预测是错的」。

线上数字要和离线 Precision 分开

本体侧：人机协同沉淀到百万量级本体。商品平均刻画维度到 1.44 倍，本体规模提升 64.5%，本体对用户流量覆盖率 80.4%。验证链是质量校验、重要性评估、专家终审入库。专家先划骨架，算法只在骨架里挖。

商品总线按价值把生产分成离线基线、分钟级近线和实时。实时只留给强时效、高价值商品。版本按「商品 + 属性」顺序覆盖，避免旧结果盖住新结果。总线支撑每日亿级更新，时效有秒、分钟、天三档。

落到业务上，稿里分开写了四组，不能揉成一个准确率：

• 搜索商品信息质量问题占比下降 37%。开篇另写搜索流量覆盖率 80%，和本体流量覆盖率 80.4% 不是同一个数。
• 智能发品的核心属性自动填充率超过 80%。这是填充率，不是填对的比例。
• 从高转化商品图里抽视觉规则，做素材和文案，点击率大约提升 9%。
• 同品识别准确率超过 90%，覆盖京东零售实体类目，用于同款比价、大促控价和异常价。品类规划从两三周压到天级，这是分析耗时，不是模型分。

37%、9% 和 90% 都没有窗口、对照和样本量。

稿自己写了还没做完的部分

第五节说系统仍在初期。本体还缺关系，不只是概念。商品库还要把消费侧 Badcase 及时找回来再修，飞轮还没真正转起来。模型侧还要处理灾难性遗忘。所以 94.2% / 82.8% 是这一阶段端到端生产的离线结果，不是已经闭合的线上质量体系。

能直接拿去用的是筛选顺序：先用证据是否一致、置信度和扰动稳不稳把坏样本挑出来，再按缺陷原因合成，最后用现状模型和专家模型的损失差决定哪条值得学。自由生成精确率不到 80% 的时候，先改成候选内判别，而不是把参数再加大。

京东云开发者社区，fe****，JD Oxygen AIIC：以LLM/VLM为核心的工业级商品理解、管理与应用系统，2026-07-10，https://developer.jdcloud.com/article/4529