LLM在电商商品属性提取中的工程实践与优化
·
1. 项目背景与核心挑战
在电商推荐系统与搜索优化领域,准确提取商品属性是提升用户体验的关键环节。Instacart作为北美领先的即时配送平台,面临着每天处理数百万SKU的属性标注难题。传统基于规则或监督学习的属性提取方案存在三大痛点:人工标注成本高、长尾属性覆盖不全、多语言商品描述解析困难。
去年我们团队接手了一个典型场景:平台新增了20万种有机食品,需要快速提取"无麸质"、"非转基因"等细分属性。传统NLP模型在新品类上F1值仅有62%,而人工标注需要45人天。这时候我们开始尝试将LLM(大语言模型)引入生产流水线,最终在保证95%准确率的前提下,将处理时间压缩到8小时。
2. 技术架构设计
2.1 整体解决方案
我们的系统采用三级处理流水线:
- 粗筛层 :用轻量级BERT模型快速过滤无关商品(如"电视机"显然不需要食品属性)
- 精炼层 :LLM并行处理候选商品描述
- 校验层 :基于规则的后处理校验
# 伪代码示例
def process_product(text):
if not food_classifier.predict(text): # 粗筛
return None
attributes = llm_extractor.generate(
f"从以下商品描述提取属性,只输出JSON:{text}"
)
return validate_rules(attributes) # 校验
2.2 关键创新点
动态提示工程 :针对不同品类自动优化prompt模板。例如化妆品类会增加成分分析指令:
"特别注意提取以下属性:是否含酒精、是否适合敏感肌、主要活性成分"
成本控制策略 :
- 对高频商品采用缓存机制
- 对长尾商品使用小模型预标注+LLM校验
- 通过API限流平衡响应时间与费用
3. 核心实现细节
3.1 高并发优化方案
当QPS超过500时,我们发现直接调用GPT-4会导致显著延迟。最终采用的技术组合:
- 异步批处理 :将请求打包成每批50条
- 本地小模型兜底 :当LLM超时自动切换回蒸馏后的T5模型
- 智能降级 :根据服务负载动态调整提取粒度
实测数据显示,该方案使99分位延迟从3.2s降至780ms:
| 方案 | 吞吐量(QPS) | P99延迟 | 准确率 |
|---|---|---|---|
| 直接调用GPT-4 | 120 | 3200ms | 96% |
| 批处理+降级 | 610 | 780ms | 93% |
3.2 属性归一化处理
不同商品对同一属性的表述差异很大(如"不含糖"、"无添加糖"、"零糖")。我们开发了基于Embedding的聚类后处理器:
- 将所有提取结果向量化(使用text-embedding-3-small)
- 用DBSCAN算法聚类相似表述
- 人工审核后建立映射词典
4. 生产环境实战经验
4.1 冷启动技巧
- 先用100个种子数据做few-shot learning
- 对LLM输出做敏感性分析,识别易混淆属性
- 构建"拒绝回答"机制处理模糊描述
4.2 常见问题排查
问题1 :LLM过度解读描述
- 现象:将"天然香料"误判为"有机"
- 解决方案:在prompt中加入负面示例
问题2 :多语言混合描述
- 现象:西班牙语和英语混杂导致漏提
- 解决方案:添加语言识别预处理步骤
5. 效果评估与迭代
上线三个月后的核心指标对比:
| 指标 | 传统方案 | LLM方案 |
|---|---|---|
| 日均处理量 | 8万 | 54万 |
| 平均准确率 | 82% | 94% |
| 新属性发现能力 | 12种/月 | 63种/月 |
| 人工复核工时 | 35h/天 | 6h/天 |
当前我们正在试验的改进方向:
- 用LoRA微调专属小模型替代部分API调用
- 构建属性间关系图谱提升连贯性
- 开发自学习的prompt优化器
这个项目的关键收获是:LLM不是简单替代原有系统,而是需要重新设计人机协作流程。我们现在将70%的预算用于常规处理,30%用于人工审核关键属性,实现了成本与质量的平衡。
更多推荐




所有评论(0)