5 Maneiras de Combinar Variantes de Produtos da AliExpress

TL;DR — Eu comparei 5 abordagens técnicas para combinar variantes de produtos entre fornecedores do AliExpress: regras de string, embeddings vetoriais, prompting de LLM, modelos de visão (CNN/CLIP) e algoritmos híbridos. Cada uma tem trocas claras em precisão, velocidade, custo e tolerância ao caos de nomenclatura do mundo real. Acabei construindo um algoritmo híbrido — sem modelo, sem GPU, sem chamada de API — especificamente projetado para rodar dentro das chamadas de ferramentas MCP onde latência e determinismo são importantes. Este artigo detalha cada abordagem com exemplos reais do AliExpress para que você possa escolher o que se encaixa na sua pilha.

O Problema: Substituição de Fornecedor é um Problema de Correspondência

Quando um fornecedor de dropshipping sai do ar — link quebrado, fora de estoque, aumento de preço — você precisa encontrar um substituto e remapear cada variante SKU para o novo fornecedor.

Isso parece simples até você ver como os dados de variantes do AliExpress realmente se parecem:

Fornecedor A (atual)         Fornecedor B (substituto)
───────────────────────      ─────────────────────────
Cor: Azul Marinho             颜色: Azul Escuro
Tamanho: XL                     尺码: XL
Envia de: China            (sem opção de Envio)
100*130cm                    1x1.3m
4PC-32x42cm                  4pcs 32*42
Branco Quente                   暖光
Cor: 03                    Cor: C

O campo "Cor" pode conter modelos de telefone, tipos de material ou números isolados. As dimensões vêm em todos os formatos imagináveis. Idiomas se misturam dentro de uma única listagem. Quantidades estão embutidas em strings de tamanho. Isso é normal no AliExpress.

A pergunta é: qual tecnologia lida melhor com esse caos, e a que custo?

Eu testei e comparei 5 abordagens. Aqui está o que eu encontrei.

Abordagem 1: Correspondência de String Baseada em Regras

Como funciona: Compare os valores das variantes usando correspondência exata, distância de edição de Levenshtein, similaridade de Jaccard ou TF-IDF cosseno. Defina um limite — se a similaridade > 0.8, é uma correspondência.

Ferramentas: Python difflib, fuzzywuzzy, RapidFuzz, regex personalizado.

Pontos fortes:

• Extremamente rápido (~0.01ms por par)
• Zero infraestrutura — roda em qualquer lugar, sem dependências
• Comportamento previsível, fácil de depurar

Pontos fracos:

• Falha em sinônimos. "Azul Marinho" vs "Azul Escuro" → distância de Levenshtein = 5, similaridade cosseno ≈ 0.3. Não é uma correspondência por nenhum limite que não também false-positive "Vermelho Escuro" e "Verde Escuro."
• Falha em múltiplas línguas. "红色" vs "Red" → zero sobreposição de string.
• Falha em unidades. "100*130cm" vs "1x1.3m" → strings completamente diferentes, mesmas dimensões.
• Falha em valores compostos. "4PC-32x42cm" vs "4pcs 32*42" → a distância de edição diz que estes são não relacionados.

Veredicto: Bom para correspondências exatas ou quase exatas. Desmorona no momento em que os fornecedores usam diferentes convenções de nomenclatura — o que é quase sempre no AliExpress.

Cartão de Pontuação
⚡ Velocidade: ~0.01ms/par — extremamente rápido
💰 Custo: $0 — zero infraestrutura
🎯 Precisão: ██░░░░░░░░ 30-45%
🌐 Múltiplas línguas: ❌
📐 Conversão de unidades: ❌
🔮 Caos de nomenclatura: ❌

Abordagem 2: Embeddings Vetoriais (Sentence-BERT, MiniLM)

Como funciona: Codifique os nomes das variantes em vetores de alta dimensão usando um modelo pré-treinado. Calcule a similaridade cosseno entre os vetores. Textos semanticamente similares acabam próximos no espaço vetorial.

Ferramentas: sentence-transformers, multi-qa-MiniLM-L6-cos-v1, FAISS para recuperação rápida, Milvus para escala de produção.

Pontos fortes:

• Lida bem com sinônimos — "Azul Marinho" e "Azul Escuro" estão próximos no espaço de embedding
• Lida com alguma correspondência entre idiomas se usar modelos multilíngues (por exemplo, paraphrase-multilingual-MiniLM-L12-v2)
• Escala bem com bancos de dados vetoriais para catálogos grandes

Pontos fracos:

• Dificuldade com unidades e dimensões. Embeddings codificam significado semântico, mas 100*130cm e 1x1.3m não estão semanticamente relacionados nos dados de treinamento — são números formatados, não linguagem natural.
• Códigos opacos são ruído aleatório. "03" e "C" não têm conteúdo semântico. Embeddings não podem ajudar.
• Requer um modelo. MiniLM é pequeno (~80MB), mas você ainda precisa carregá-lo, e a inferência não é gratuita — ~5ms por codificação na CPU, mais para lotes.
• Falsos positivos em strings curtas. "S" (pequeno) e "M" (médio) estão muito próximos no espaço de embedding porque frequentemente co-ocorrem, mas são tamanhos diferentes.
• Valores compostos são opacos. "4PC-32x42cm" é embutido como um bloco — o modelo não o analisa em contagem=4, dimensões=32×42, unidade=cm.

Veredicto: Significativamente melhor do que a correspondência de string para nomes de variantes em linguagem natural. Mas os dados do AliExpress são frequentemente estruturados (números, unidades, códigos), não linguagem natural — e é aí que os embeddings têm dificuldades.

Cartão de Pontuação
⚡ Velocidade: ~5ms/par — rápido o suficiente
💰 Custo: ~$0 auto-hospedado, 80-200MB de RAM do modelo
🎯 Precisão: ████░░░░░░ 50-65%
🌐 Múltiplas línguas: ⚠️ com modelo multilíngue
📐 Conversão de unidades: ❌
🔮 Caos de nomenclatura: ⚠️ sinônimos sim, unidades/códigos não

Abordagem 3: Prompting de LLM (GPT-4o, Claude)

Como funciona: Envie um prompt para um LLM com ambas as listas de variantes e peça para ele produzir um mapeamento. O modelo usa seu conhecimento de mundo para entender que "Azul Marinho" = "Azul Escuro", analisar unidades e lidar com texto em várias línguas.

Ferramentas: OpenAI API, Anthropic API, qualquer LLM com chamada de função.

Exemplo de prompt:

Dadas essas variantes da loja e variantes do fornecedor,
produza um mapeamento JSON das melhores correspondências com pontuações de confiança.
Loja: ["Azul Marinho / XL", "Branco Quente / 100*130cm"]
Fornecedor: ["Azul Escuro / XL", "暖光 / 1x1.3m"]

Pontos fortes:

• Melhor precisão para linguagem natural. LLMs entendem que "Branco Quente" = "暖光" = "3000K" em várias línguas e domínios.
• Pode lidar com casos novos. Se um fornecedor usa uma terminologia incomum, o conhecimento de mundo do LLM geralmente cobre isso.
• Pode raciocinar sobre valores compostos. Um bom LLM pode analisar "4PC-32x42cm" em contagem + dimensões.

Pontos fracos:

• Lento. Uma única chamada de API para 40×40 variantes leva de 3 a 10 segundos. Se você está avaliando 10 fornecedores candidatos, isso leva de 30 a 100 segundos apenas para a correspondência.
• Caro. A correspondência de variantes para uma substituição de produto consome de 2K a 5K tokens. Com a precificação do GPT-4o, isso custa cerca de $0.01-0.03 por produto. Para uma varredura de catálogo de 500 produtos, isso custa de $5 a $15 por execução.
• Não determinístico. A mesma entrada pode produzir saídas diferentes em chamadas. Temperatura=0 ajuda, mas não elimina a variação. Você não pode armazenar em cache ou pré-computar resultados de forma confiável.
• Limites de taxa. Atingir os limites da API da OpenAI ou da Anthropic ao realizar operações em lote é uma preocupação operacional real.
• Latência prejudica chamadas de ferramentas MCP. Se sku m