LikeShop多商户商品智能分类打标体系建设：向量召回+大模型精判两阶段方案落地

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

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

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

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

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

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

1.2 标签体系碎片化与不可复用

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

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

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

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

1.4 传统技术方案的局限性

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

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

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

二、方案选型与设计原则

2.1 三类主流方案对比

在方案选型阶段，我们对三种主流技术路线做了系统性对比：

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

2.2 核心设计原则

作为基于现有商城系统的扩展能力，方案设计严格遵循四项原则：

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

三、整体架构与技术栈

3.1 四层架构设计

系统自下而上分为四层，AI能力作为独立扩展层挂载于原生商品体系之上：

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

3.2 技术栈选型

全部基于Java技术栈扩展，无需引入重型大数据组件：

四、核心技术方案：两阶段智能打标

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

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

4.1.1 类目文本构造

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

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

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

4.1.2 向量化与入库

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

4.1.3 召回策略

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

4.2 阶段二：大模型精判与置信度体系

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

4.2.1 Prompt设计方法论

Prompt是大模型效果的核心杠杆。我们围绕“角色、约束、输出、边界”四个维度构建Prompt模板：

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

Prompt核心结构示例：

你是专业的电商类目审核专员，请严格依据平台类目体系，从候选类目中选择最匹配的三级类目。

【商品信息】
标题：{goods_title}
卖点：{goods_subtitle}
核心属性：{goods_attrs}

【候选类目列表】
{category_list}

【输出要求】
1. 只能从候选中选择一个最优三级类目；
2. 置信度取值0-1，代表分类把握程度；
3. 全部不匹配时，category_id返回null；
4. 同时提取5-8个标准商品标签。

【标准JSON输出】
{
  "category_id": 数字,
  "confidence": 数字,
  "reason": "分类理由",
  "tags": ["标签1", "标签2"]
}

4.2.2 置信度分级策略

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

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

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

4.2.3 标签抽取与标准化映射

分类确定后，同步从商品文本中抽取三类标签：属性标签、场景标签、营销标签。

抽取的原始标签不直接绑定商品，先经过标准化映射流程：

1. 与平台标准标签库做语义匹配，命中的直接关联；
2. 未命中的进入待审核标签库，由运营确认是否纳入标准体系；
3. 高频命中的新标签自动沉淀为标准标签，持续丰富标签库。

五、数据模型设计

全部采用新增表方式扩展，最小化对原生表结构的侵入。

5.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 COMMENT '类目完整路径',
  vector TEXT NOT NULL COMMENT '向量数据JSON数组',
  embedding_model VARCHAR(64) NOT NULL COMMENT '向量模型版本',
  update_time DATETIME NOT NULL,
  UNIQUE KEY uk_category_id(category_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='平台类目向量表';

5.2 智能打标任务表

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

CREATE TABLE ls_goods_ai_tag_task (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  task_no VARCHAR(32) NOT NULL COMMENT '任务编号',
  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 COMMENT '预测类目ID',
  confidence DECIMAL(3,2) COMMENT '分类置信度',
  predict_tags VARCHAR(500) COMMENT '预测标签集合',

  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打标任务表';

5.3 AI标签映射表

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

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标签映射表';

六、核心模块代码实现

6.1 大模型统一适配层

抽象统一接口，屏蔽不同厂商差异，支持模型热切换。

/**
 * 大模型通用接口
 */
public interface LlmService {
    /**
     * 结构化生成，自动解析JSON返回结果
     */
    <T> T structuredGenerate(String prompt, Class<T> clazz, LlmConfig config);
}

/**
 * 通义千问实现
 */
@Service
public class QwenLlmServiceImpl implements LlmService {

    @Value("${ai.qwen.api-key}")
    private String apiKey;

    @Override
    public <T> T structuredGenerate(String prompt, Class<T> clazz, LlmConfig config) {
        QwenClient client = new QwenClient(apiKey);
        QwenResult result = client.call(
                prompt,
                config.getModelName(),
                config.getTemperature()
        );

        String content = result.getOutput().getText();
        String jsonContent = extractJsonFromText(content);

        try {
            return JSON.parseObject(jsonContent, clazz);
        } catch (Exception e) {
            log.error("大模型返回格式解析失败 content={}", content, e);
            throw new BizException("大模型返回格式异常");
        }
    }
}

6.2 两阶段分类主服务

完整实现向量召回 → 大模型精判 → 置信度分级 → 结果落库全流程。

@Service
public class GoodsAiTagService {

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

    @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("智能打标处理失败");
        }
    }
}

6.3 批量打标异步消费

通过消息队列削峰填谷，控制调用速率与成本。

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

    @Autowired
    private GoodsAiTagService aiTagService;
    @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)) {
                    aiTagService.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.1 幂等控制

• 按商品ID + 日期做幂等校验，避免重复打标浪费Token；
• 任务表唯一约束兜底，防止消息重复消费导致重复处理；
• 标签映射按原始标签唯一键去重。

7.2 成本与限流

• 批量任务通过消费并发数控制大模型调用速率；
• 平台与商家维度设置每日调用上限，超出阈值告警；
• 高置信商品优先复用历史结果，减少不必要的大模型调用。

7.3 异常降级

• 大模型服务异常时，自动降级为纯向量检索Top1推荐，标记待人工确认；
• 向量库故障时，退回关键词匹配方案，保证商品发布流程不阻塞；
• 全链路异常均有兜底，不阻断商家正常发布商品。

7.4 数据一致性

• 打标失败不影响商品原有分类，只更新任务表状态；
• 自动生效的分类更新放在事务内，任务表与商品表同时成功或回滚；
• 标签绑定失败异步重试，不阻塞主分类流程。

八、效果评估与持续迭代

8.1 评估指标体系

从四个维度衡量方案效果：

1. 分类准确率：AI自动通过的商品中，分类正确的比例；
2. 人工审核率：需要人工介入的商品占总发布量的比例；
3. 标签覆盖率：商品平均有效标签数量；
4. 审核效率：单商品平均审核耗时。

8.2 落地效果数据

在实际多商户服饰+数码综合类目场景落地三个月后，核心指标提升显著：

8.3 Badcase回流闭环

效果持续提升的核心在于建立闭环优化机制：

1. 人工驳回、修正的分类结果自动回流样本库；
2. 每月基于badcase迭代Prompt，补充边界案例；
3. 高频错分类目补充类目描述文本，优化向量质量；
4. 标签映射库持续沉淀，标准标签体系自动丰富。

九、实践踩坑与经验总结

9.1 不要直接做开放式全类目分类

很多团队一开始直接让大模型从全量类目中选结果，很容易出现层级错乱、跨类目幻觉。一定要先走向量检索缩小候选集，把开放题变成选择题，准确率会有质的提升。

9.2 置信度阈值不能一刀切

不同品类的容错成本完全不同。合规要求高、佣金差异大的类目，阈值应当更高；标准品类、低客单价类目可以适当放宽阈值，提升自动化率。统一阈值本质是在准确率和效率之间做次优选择。

9.3 类目变动必须同步更新向量

平台类目调整、合并、新增后，如果不更新向量库，召回准确率会持续衰减。建议类目变更时触发增量更新，每月做一次全量重算，保证向量库与类目体系同步。

9.4 人工审核不是过渡方案，是常态机制

不要追求100%全自动化。AI处理80%的标准品，人工处理20%的边界与特殊品类，人机协同才是长期可持续的治理模式。

十、结语

大模型与向量检索在多商户商品治理场景的价值，不在于完全替代人工，而在于将标准化、重复性的类目匹配与标签抽取工作自动化，让运营人力从机械审核中释放出来，聚焦于规则制定、质量管控与特殊品类处理。

LikeShop多商户标准版本身已经具备成熟的商品、类目、商家管理底座，在此基础上通过新增扩展层的方式落地智能打标，不需要重构核心业务，既可以快速获得AI能力带来的效率提升，又能保留系统后续的官方版本升级空间。

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