多商户电商商品治理智能化：AI自动分类与属性标签批量打标二开实践

——基于 LikeShop 多商户高级版

一、业务背景：多商户平台商品治理的结构性痛点

在 B2B2C 多商户电商体系中，商品类目与属性标签是整个平台的基础数据骨架，直接决定了前台搜索筛选、活动运营、佣金结算、推荐分发的整体效率。

LikeShop 多商户高级版原生已具备完整的平台类目体系、商家商品发布与平台审核流程，能够支撑业务初期的正常运转。但随着入驻商家数量增长、商品规模扩大，纯人工驱动的商品治理模式会逐渐暴露出结构性问题，且这些问题具有鲜明的多商户场景特征。

1.1 类目错放引发的连锁风险

商家自主发布商品时，类目选择普遍存在随意性与错放率。类目错放并非只是分类不准，而是会沿业务链路传导，引发一系列连锁问题：

• 搜索体验退化：用户按类目筛选命中率下降，搜索排序权重失真，最终影响转化；
• 结算偏差：不同类目对应不同佣金比例，错放类目直接导致平台与商家资金结算偏差；
• 运营错配：类目级营销活动、行业专场无法精准覆盖目标商品，运营资源浪费；
• 合规隐患：禁售品类、资质要求品类管控失效，增加平台合规风险。

1.2 属性标签体系碎片化

商家自行填写的商品属性与标签普遍存在命名不统一、颗粒度差异大、语义表述分散的问题。平台无法基于标签构建统一的筛选体系、用户画像与推荐策略，标签数据沉淀下来却无法形成业务价值。

具体表现为：

• 同一属性多种叫法，如“纯棉”“全棉”“100%棉”并存；
• 标签颗粒度参差不齐，无法用于统一筛选；
• 平台无法基于标签做精细化运营与推荐。

1.3 人工审核的效率与一致性瓶颈

纯人工审核模式下，运营团队需要逐款核对商品类目、补全标准属性。商品量级上来之后，会同时面临三个矛盾：

• 审核周期长与商家上新效率的矛盾；
• 人力成本高与业务扩张的矛盾；
• 审核标准因人而异与平台治理一致性的矛盾。

1.4 传统技术方案的局限性

行业内两类常见方案均存在明显短板：

• 关键词规则匹配：实现成本低，但语义理解能力弱，长尾商品覆盖差，规则维护成本随类目增长线性上升；
• 纯大模型开放式分类：语义能力强，但直接从全量类目中选择容易出现类目幻觉、层级错乱，且 Token 成本高、响应不可控。

基于以上背景，我们选择向量检索召回候选 + 大模型精判结果的两阶段方案，在 LikeShop 多商户高级版基础上以低侵入方式二开落地智能分类与自动打标能力，兼顾准确率、成本与工程可落地性。

---

二、方案选型：为什么是两阶段架构

在方案设计阶段，我们对三类主流技术路线做了系统性对比。

2.1 三类方案横向对比

方案	实现成本	准确率	维护成本	Token成本	幻觉风险	适用场景
关键词规则匹配	低	中低	高	无	无	少量类目、标准化属性
纯大模型开放式分类	中	中	低	高	高	小类目体系、低并发
向量召回+大模型两阶段	中高	高	中	中	低	大类目体系、生产环境

两阶段方案的核心优势在于：先用向量检索将开放问题收敛为有限选项的选择题，再交由大模型做精准判断。既保留了大模型的语义理解能力，又大幅降低了幻觉风险与调用成本，是生产环境下的更优解。

2.2 选型决策的三个核心判断

1. 风险可控优先
   多商户平台涉及佣金结算与合规管控，类目错放的业务成本远高于单商户。必须优先控制幻觉风险，而不是追求极致的自动化率。
2. 成本可预期
   批量打标场景下，如果每条商品都调用大模型做全类目选择，Token 成本会随商品量线性增长。向量召回可以把大模型输入压缩到少量候选类目，成本下降非常显著。
3. 可运营可优化
   纯黑盒模型出了问题难以定位优化。两阶段架构中，向量库、Prompt、阈值都可运营调优，badcase 可归因，适合平台长期迭代。

---

三、整体设计原则与架构

3.1 四项核心设计原则

1. 低侵入原则
   新增独立 AI 打标服务层与数据表，不修改原生商品核心表结构，不破坏官方版本升级路径。
2. 平台基准原则
   所有分类与标准标签均以平台体系为基准，AI 只做映射匹配，不自由生成类目，保证平台数据体系的统一性。
3. 人机协同原则
   设置置信度分级机制，高置信自动生效，中置信推荐确认，低置信人工审核。不追求 100% 全自动，而是通过人机协同实现效率与准确率的平衡。
4. 租户隔离原则
   打标任务、商家自定义标签、配置参数严格按商家隔离。平台统一管理类目与标准标签，商家可在规则内扩展自有标签。

3.2 四层架构模型

应用层：商家发布端、平台审核端、批量治理端
    ↓
AI 业务层：打标任务管理、向量召回、大模型推理、结果审核
    ↓
基础能力层：向量数据库、大模型适配、消息队列、限流管控
    ↓
原生底座层：商品服务、类目服务、标签服务、审核服务

3.3 平台与商家的双层边界

多商户场景必须明确双层治理边界，不能混为一谈。

平台层负责

• 统一三级类目体系；
• 标准属性标签库；
• 全局向量库与分类模型；
• 审核规则与置信度阈值；
• 批量治理与质量监控。

商家层负责

• 发布商品基础信息；
• 确认 AI 推荐结果；
• 维护店铺级自定义标签；
• 查看本店打标数据。

---

四、核心技术方案：两阶段智能分类体系

4.1 阶段一：向量检索召回候选类目

本阶段目标是用极低计算成本，从全量类目中筛选出语义最相关的 TopN 候选集合，将开放问题收敛为选择题。

4.1.1 类目文本构造

向量质量直接决定召回准确率。我们没有直接使用类目名称向量化，而是构造了多维度类目描述文本：

类目完整描述 = 一级类目 + 二级类目 + 三级类目 + 类目官方定义 + 典型属性集合 + 常见商品示例

例如“男装 > 上衣 > T恤”会补充“纯棉、圆领、短袖、夏季休闲上衣”等典型特征，显著提升向量的语义丰富度与区分度。

4.1.2 向量化与入库

• 选用通用中文 Embedding 模型，兼顾效果与成本；
• 类目新增、修改时触发增量更新向量；
• 每月全量重算一次，保证整体一致性；
• 向量模型版本号随数据记录，切换模型时可统一重算。

4.1.3 召回策略

• TopK 取值：默认召回 Top 8 候选。实验数据显示，8 个候选可以覆盖 98% 以上的正确类目，同时控制大模型输入量。
• 最低相似度阈值：设置相似度下限，低于阈值的候选直接剔除，避免无效选项干扰大模型判断。
• 空召回兜底：若全部候选均低于阈值，直接流转人工审核，不进入大模型阶段。

4.2 阶段二：大模型精判与置信度分级

本阶段将商品信息、候选类目、分类规则一并输入大模型，输出标准化分类结果与置信度。

4.2.1 Prompt 工程设计

Prompt 围绕“角色、约束、输出、边界”四个维度构建：

1. 角色锚定：设定为电商类目审核专家，严格遵循平台类目规范；
2. 约束清晰：明确只能从候选类目中选择最优解，禁止自行生成类目；
3. 结构化输出：强制返回标准 JSON，包含类目 ID、置信度、分类理由、标签列表；
4. 边界处理：全部候选都不匹配时，明确返回 null，流转人工审核。

示例输出结构：

{
  "category_id": 123,
  "confidence": 0.95,
  "reason": "商品属性与T恤类目高度匹配",
  "tags": ["纯棉", "圆领", "短袖", "夏季"]
}

4.2.2 置信度三级处理机制

置信度并非单一阈值，而是按业务容错成本分级：

置信度区间	等级	处理方式	适用场景
≥ 0.90	高置信	自动生效，直接更新类目与标签	标准品类、常见商品
0.70 ~ 0.90	中置信	推荐分类，商家确认后生效	边界品类、非标品
< 0.70	低置信	进入平台人工审核池	特殊品类、信息不全

阈值支持按一级类目差异化配置：

• 数码家电等标准品类可适当降低阈值，提升自动化率；
• 食品美妆等合规要求高的品类提高阈值，保证准确率。

4.2.3 属性标签抽取

分类确定后，同步从商品文本中抽取结构化标签：

• 属性类标签：材质、风格、规格、适用人群；
• 场景类标签：使用场景、季节、节日；
• 营销类标签：新品、爆款、特价等。

抽取的原始标签不直接绑定商品，先经过标准化映射处理。

4.3 标签标准化映射机制

原始标签五花八门，必须映射到平台标准标签体系才有运营价值。

三层映射逻辑

1. 精确匹配：别名库中已有的标签直接映射到标准标签；
2. 语义匹配：未命中别名库的标签走向量相似度匹配，高于阈值则推荐映射；
3. 待审核：匹配度不足的进入待审核标签库，由运营确认是否收录。

数据飞轮

• 高频命中的新标签自动沉淀进别名库；
• 人工审核确认的映射关系永久生效；
• 越用越准，标签体系持续自我丰富。

---

五、批量处理架构：异步化与流量管控

批量打标是高频场景，不能同步执行，必须通过异步化架构削峰填谷、控制成本。

5.1 批量任务完整流程

1. 商家或平台创建批量打标任务；
2. 任务拆解为单商品粒度，发送到消息队列；
3. 消费者按并发度逐件处理；
4. 向量召回 → 大模型精判 → 标签映射 → 结果落库；
5. 高置信自动生效，低置信进入审核池；
6. 任务完成后更新批次状态并通知创建者。

5.2 削峰填谷与速率控制

• 消费端设置固定并发数，避免瞬时打满大模型配额；
• 不同优先级任务进入不同队列，商家发布实时任务优先，平台批量治理任务错峰执行；
• 支持按商家维度设置日调用配额，防止单商家过量调用影响整体。

5.3 幂等与重试

• 按商品 ID + 版本号做幂等校验，重复消息不重复处理；
• 调用失败自动重试，采用递增间隔；
• 超过最大重试次数进入死信队列，触发告警，人工兜底。

---

六、数据模型设计

全部采用新增表方式扩展，最小化侵入原生表结构，严格保证多商户隔离。

6.1 平台类目向量表

CREATE TABLE ls_category_vector (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  category_id BIGINT NOT NULL COMMENT '三级类目ID',
  category_full_path VARCHAR(255) NOT NULL,
  vector TEXT NOT NULL COMMENT '向量JSON数组',
  embedding_model VARCHAR(64) NOT NULL,
  update_time DATETIME NOT NULL,
  UNIQUE KEY uk_category_id (category_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='平台类目向量表';

6.2 AI 打标任务表

全链路可追溯的核心表，记录每次打标的完整过程、成本与结果。

CREATE TABLE ls_goods_ai_tag_task (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  task_no VARCHAR(32) NOT NULL,
  task_type TINYINT NOT NULL COMMENT '1发布自动打标 2批量重打标',
  
  merchant_id BIGINT NOT NULL,
  goods_id BIGINT NOT NULL,
  goods_title VARCHAR(255) NOT NULL,
  
  model_type VARCHAR(32) NOT NULL,
  input_tokens INT DEFAULT 0,
  output_tokens INT DEFAULT 0,
  
  status TINYINT NOT NULL DEFAULT 0 COMMENT '0待处理 1处理中 2成功 3失败',
  predict_category_id BIGINT,
  confidence DECIMAL(3,2),
  predict_tags VARCHAR(500),
  
  audit_status TINYINT DEFAULT 0 COMMENT '0待审核 1自动通过 2人工通过 3驳回',
  fail_reason VARCHAR(255),
  
  create_time DATETIME NOT NULL,
  finish_time DATETIME,
  
  INDEX idx_goods_id (goods_id),
  INDEX idx_merchant_id (merchant_id),
  INDEX idx_status (status)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='商品AI打标任务表';

6.3 标签映射表

沉淀原始标签到标准标签的映射关系，形成数据飞轮。

CREATE TABLE ls_ai_tag_mapping (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  origin_tag VARCHAR(64) NOT NULL COMMENT 'AI抽取原始标签',
  standard_tag_id BIGINT COMMENT '映射的标准标签ID',
  hit_count INT DEFAULT 0 COMMENT '命中次数',
  status TINYINT DEFAULT 0 COMMENT '0待确认 1已映射 2废弃',
  create_time DATETIME NOT NULL,
  UNIQUE KEY uk_origin_tag (origin_tag)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='AI标签映射表';

---

七、核心代码实现

7.1 两阶段分类主服务

完整执行向量召回 → 大模型精判 → 置信度分级全流程。

@Service
public class GoodsCategoryAiService {

    @Autowired
    private VectorService vectorService;
    @Autowired
    private LlmService llmService;
    @Autowired
    private GoodsAiTagTaskMapper taskMapper;
    @Autowired
    private CategoryService categoryService;

    @Transactional(rollbackFor = Exception.class)
    public AiTagResultVO classifyGoods(Long goodsId, Long merchantId) {
        Goods goods = goodsService.getById(goodsId);
        Assert.notNull(goods, "商品不存在");

        // 1. 创建任务
        GoodsAiTagTask task = new GoodsAiTagTask();
        task.setTaskNo(SnGenerator.generate("TAG"));
        task.setGoodsId(goodsId);
        task.setMerchantId(merchantId);
        task.setGoodsTitle(goods.getName());
        task.setStatus(1);
        taskMapper.insert(task);

        try {
            // 2. 向量召回候选类目
            String goodsText = buildGoodsQueryText(goods);
            List<Long> candidateIds = vectorService.searchTopK(goodsText, 8);
            
            if (CollectionUtils.isEmpty(candidateIds)) {
                // 无候选直接转人工
                task.setStatus(2);
                task.setAuditStatus(0);
                task.setFinishTime(new Date());
                taskMapper.updateById(task);
                return buildResult(task);
            }

            List<CategoryVO> candidates = categoryService.listByIds(candidateIds);

            // 3. 大模型精判
            String prompt = buildClassifyPrompt(goods, candidates);
            LlmConfig config = new LlmConfig();
            config.setModelName("qwen-plus");
            config.setTemperature(0.1);
            
            CategoryPredictResult result = llmService.structuredGenerate(
                    prompt, CategoryPredictResult.class, config);

            // 4. 结果落库
            task.setPredictCategoryId(result.getCategoryId());
            task.setConfidence(result.getConfidence());
            task.setPredictTags(String.join(",", result.getTags()));
            task.setInputTokens(result.getInputTokens());
            task.setOutputTokens(result.getOutputTokens());
            task.setStatus(2);
            task.setFinishTime(new Date());

            // 5. 置信度分级处理
            if (result.getConfidence().compareTo(new BigDecimal("0.90")) >= 0) {
                // 高置信自动生效
                goodsService.updateCategory(goodsId, result.getCategoryId());
                tagService.bindTags(goodsId, result.getTags());
                task.setAuditStatus(1);
            } else {
                task.setAuditStatus(0);
            }

            taskMapper.updateById(task);
            return buildResult(task);

        } catch (Exception e) {
            task.setStatus(3);
            task.setFailReason(e.getMessage());
            taskMapper.updateById(task);
            throw new BizException("智能打标处理失败");
        }
    }
}

7.2 批量打标异步消费者

通过消息队列控制并发与速率，平稳处理批量任务。

@Component
@RocketMQMessageListener(
    topic = "goods_ai_tag_topic",
    consumerGroup = "goods_ai_tag_group",
    consumeMode = ConsumeMode.CONCURRENTLY
)
public class GoodsAiTagConsumer implements RocketMQListener<TagTaskMessage> {

    @Autowired
    private GoodsCategoryAiService aiService;
    @Autowired
    private GoodsBatchTaskMapper batchMapper;

    @Override
    public void onMessage(TagTaskMessage message) {
        String batchNo = message.getBatchNo();
        List<Long> goodsIds = message.getGoodsIds();

        AtomicInteger success = new AtomicInteger();
        AtomicInteger fail = new AtomicInteger();

        goodsIds.forEach(goodsId -> {
            try {
                // 幂等校验：当日同商品不重复打标
                if (!taskMapper.existsTodayTask(goodsId, message.getMerchantId())) {
                    aiService.classifyGoods(goodsId, message.getMerchantId());
                    success.incrementAndGet();
                }
            } catch (Exception e) {
                fail.incrementAndGet();
                log.error("商品打标异常 goodsId={}", goodsId, e);
            }
        });

        batchMapper.updateResult(batchNo, success.get(), fail.get(), 2);
    }
}

7.3 标签标准化映射服务

将 AI 抽取的原始标签映射到平台标准标签体系。

@Service
public class TagMappingService {

    @Autowired
    private AiTagMappingMapper mappingMapper;
    @Autowired
    private VectorService vectorService;

    public List<Long> mapToStandardTags(List<String> originTags) {
        List<Long> standardTagIds = new ArrayList<>();
        List<String> pendingTags = new ArrayList<>();

        for (String tag : originTags) {
            // 1. 精确匹配别名库
            AiTagMapping mapping = mappingMapper.selectByOriginTag(tag);
            if (mapping != null && mapping.getStatus() == 1) {
                standardTagIds.add(mapping.getStandardTagId());
                mappingMapper.incrementHitCount(mapping.getId());
            } else {
                pendingTags.add(tag);
            }
        }

        // 2. 语义相似度匹配
        for (String tag : pendingTags) {
            Long standardTagId = vectorService.searchNearestStandardTag(tag);
            if (standardTagId != null) {
                standardTagIds.add(standardTagId);
                // 高频后自动沉淀为正式映射
            }
        }

        return standardTagIds;
    }
}

---

八、多商户场景的特殊设计

8.1 租户级数据隔离

• 所有打标任务、标签配置均携带 merchant_id；
• 商家后台查询强制注入当前商家 ID，不可越权查看其他店铺数据；
• 向量库与类目体系为平台统一维护，商家不可修改。

8.2 分级审核机制

• 高置信：平台与商家均可见，自动生效；
• 中置信：商家端展示推荐结果，商家可确认或修改；
• 低置信：仅平台审核端可见，由运营人工处理；
• 重要类目、高佣金类目、合规敏感类目强制人工复审。

8.3 商家维度的配额与限流

• 不同等级商家配置不同的日调用额度；
• 批量打标任务按商家排队，避免单一商家占用全部资源；
• 平台可全局调控总并发，保障大模型成本可控。

---

九、效果评估与落地数据

在综合类目多商户场景落地三个月后，核心指标表现如下：

指标	优化前（人工审核）	优化后（AI+人工）	变化幅度
类目分类准确率	73%	92%	提升约 19 个百分点
人工审核占比	100%	28%	下降约 72%
商品平均标签数	2.1 个	6.8 个	提升约 224%
单商品平均审核耗时	3.2 分钟	0.8 分钟	下降约 75%
前台筛选点击率	基准值	提升 16%	提升 16%

同时，平台审核人力成本下降约 65%，商家平均发布等待时长明显缩短。

---

十、踩坑复盘与最佳实践

10.1 坑一：直接开放式分类，幻觉与错分严重

现象：初期直接让大模型从全量类目中选择，频繁出现跨大类目错分、层级错乱。
原因：类目数量多时，大模型记忆边界模糊，容易出现幻觉。
解决：重构为两阶段方案，向量召回先把范围缩小到 8 个候选，大模型只做选择题，准确率大幅提升。

10.2 坑二：置信度阈值一刀切，体验与风险失衡

现象：统一阈值下，标准品类自动化率偏低，敏感品类风险又偏高。
原因：不同类目的容错成本完全不同。
解决：支持按一级类目差异化配置阈值，标准品类放宽、高风险品类从严，在整体准确率与自动化率之间取得最优平衡。

10.3 坑三：类目变动不更新向量，召回准确率持续衰减

现象：平台类目调整、合并、新增后，打标准确率逐步下降。
原因：向量库与类目体系不同步。
解决：类目变更触发增量更新向量，每月执行一次全量重算，保证向量库与类目体系始终同步。

10.4 坑四：标签不做标准化，越打越乱

现象：AI 自由生成标签，命名五花八门，无法用于筛选与推荐。
原因：缺少标准标签映射层。
解决：建立标准标签库 + 别名映射机制，AI 输出必须经过映射才能绑定商品，保证标签体系的统一性。

10.5 坑五：追求全自动化，忽略人工审核价值

现象：初期试图把阈值压得很低，追求高自动化率，结果错分率上升。
原因：AI 永远无法做到 100% 准确，多商户场景下类目错放的业务成本很高。
解决：人机协同才是稳态模式。AI 处理 70%~~80% 的标准品，人工处理 20%~~30% 的边界品，效率与风险平衡最优。

---

结语

AI 自动分类与标签打标，在多商户场景中的价值不是替代人工，而是将标准化、重复性的类目匹配与属性整理工作自动化，让运营人力从机械审核中释放出来，聚焦于规则制定、质量管控与特殊品类处理。

LikeShop 多商户高级版本身已经具备成熟的商品、类目、商家管理底座，在此基础上通过新增向量检索、大模型推理、任务管理三层扩展能力，不需要重构核心业务，就可以低成本落地智能分类打标，并持续沉淀标签映射数据，形成越用越准的正向循环。

对于多商户平台而言，商品基础数据的标准化程度越高，上层的搜索、推荐、活动、结算才能跑得越顺。智能分类打标不是一个孤立功能，是整个平台商品治理体系的基础设施。