![\"Documentos](\"/assets/images/b2b-search-silent-failures.png\")
A busca no comércio B2B tem um segredo sujo: o algoritmo de ranqueamento raramente é o problema.
\n\nQuando os resultados são ruins, as equipes buscam as alavancas divertidas. Boosts, sinônimos, embeddings, rerankers e, ultimamente, compreensão de consultas com LLM. Já puxei todas essas alavancas eu mesmo. Na semana passada, fiz a coisa nada glamourosa: despejei todos os registros de produtos de quatro índices de busca de produção – 775.051 registros em quatro distribuidores B2B nos setores de HVAC, encanamento, suprimentos industriais e fixadores – e auditei os dados em si. Usei doze agentes de IA rodando em paralelo, cada um atribuído a uma dimensão: cobertura, qualidade do texto, números de peça, marcas, preços, especificações, categorias, mídia, duplicatas.
\n\nO que veio não surpreenderia ninguém que já trabalhou no catálogo de um distribuidor, e chocaria quem não trabalhou. Mas a parte que ficou comigo é esta: a correção já está publicada. Amazon, DoorDash e Instacart passaram dois anos escrevendo, em blogs de engenharia públicos, exatamente como usam LLMs para limpar, rotular e enriquecer catálogos bagunçados em escala. A distribuição comercial, em sua maioria, não percebeu. O que é estranho, porque seus catálogos são mais bagunçados, suas consultas valem mais (um empreiteiro encomendando um condensador de $4.000, não um almoço de $12), e os tamanhos de seus catálogos tornam a economia realmente mais favorável.
\n\nEntão, este post é esse manual, adaptado para a distribuição comercial: os problemas de dados que quebram a busca B2B, como encontrá-los com um agente de codificação esta tarde, como corrigi-los com LLMs, incluindo a categorização UNSPSC, e quanto tudo custa. Spoiler sobre o último: menos do que você imagina por duas ordens de grandeza.
\n\nAlguns do que as empresas de marketplace publicaram:
\n\nO fio condutor é fácil de perder: as vitórias do LLM estão no lado do catálogo e offline. Essas empresas enriquecem os dados antes de uma única consulta chegar. Os sistemas de descoberta se dividem em um lado offline que constrói artefatos (o catálogo, os índices, os embeddings) e um lado online que recupera e ranqueia sobre eles, e quase todo o valor publicado do LLM fica no offline. A camada de ranqueamento só pode ser tão boa quanto o que a alimenta.
\n\nAgora imagine o catálogo de um distribuidor típico de HVAC ou encanamento ao lado disso. Ele é montado a partir de exportações de ERP, planilhas de fornecedores, feeds de grupos de compras e um analisador CSV que alguém escreveu há uma década. Os "títulos" dos produtos são abreviações de fatura escritas para separadores de estoque. E o tráfego de busca que o atinge é tão denso em intenção quanto o tráfego de busca pode ser: metade são números de peça exatos, o restante é jargão comercial como "3/4 cxc 90 ell". Honestamente, não consigo pensar em um ambiente melhor para este manual. As consultas são valiosas, os dados são corrigíveis e, com algumas centenas de milhares de SKUs, uma passagem completa de LLM pelo catálogo custa centenas de dólares. Não milhões. Centenas.
\n\nAqui está o formato da auditoria, porque você vai querer reproduzi-lo:
\n\nflowchart TD\n D["Dump bruto do catálogo<br/>(JSONL, um registro por linha)"] --> C1["Agentes de cobertura por catálogo<br/>taxas nulas, distribuições, campos mortos"]\n D --> C2["Agentes de dimensão<br/>texto · números de peça · marcas · preços<br/>especificações · categorias · mídia · duplicatas"]\n C1 --> S["Síntese: descobertas classificadas por<br/>gravidade, com registros de exemplo"]\n C2 --> S\n S --> F["Pipeline de correção: regras + enriquecimento LLM<br/>+ classificação UNSPSC + portões de ingestão"]\nUma observação sobre o formato antes dos prompts. Tudo abaixo funciona em um dump genérico: um objeto JSON por linha, cada um com um id único e os campos do registro. Elasticsearch, OpenSearch, Solr, Algolia, Typesense, um PIM, uma exportação de banco de dados simples – não importa. Toda plataforma pode produzir esse formato, e todo prompt aqui roda contra ele.
A pior coisa que encontrei não foram dados ruins que alguém escreveu. Foram dados que o pipeline destruiu na entrada, sem avisar ninguém.
\n\nEsses catálogos constroem seu texto de busca primário no momento da ingestão, usando um regex de script que extrai dimensões e unidades dos títulos dos produtos. Em títulos longos, o regex ultrapassa o limite de complexidade do mecanismo, o processador falha e o registro é indexado de qualquer maneira – com um campo de erro que ninguém lê e nenhum campo de busca primário.
\n\n
Em toda a frota, 52.570 registros estavam sentados no índice, invisíveis para o caminho de consulta principal. No pior catálogo, isso é um em cada sete produtos. Nenhum painel detectou porque nada falhou. O pipeline retornou sucesso o dia todo, todos os dias, por meses.
\n\nMais duas descobertas da mesma família. O espelho desatualizado: um campo contém a verdade (um mapa de direito por conta), e um segundo campo achatado o espelha para filtragem. Em um catálogo, o espelho havia se desviado em 19,85% dos registros – 31.000 produtos ativos incorretamente ocultos da busca filtrada por conta. E o catálogo congelado: um índice não era atualizado há dez semanas enquanto seus irmãos eram atualizados diariamente. O tempo de atividade era monitorado. A atualização não era.
\n\nAs correções são chatas, e essa é a questão. Alerte sobre a cobertura de campos derivados (campo derivado vazio enquanto sua fonte não está). Não mantenha duas representações de um fato; derive o campo filtrável no momento da escrita. Monitore a atualização dos dados por catálogo da mesma forma que monitora o tempo de atividade.
\n\nAqui está o prompt para encontrar tudo isso em seu próprio catálogo (Claude Code ou codex exec; mecânica no final):
Aqui está um dump do meu catálogo de produtos como arquivos JSONL em ./dump/ - um registro\nJSON por linha, cada um com um "id" único e os campos do produto. Minha definição de\ncampo/esquema (se houver) está em schema.json.\n\nEscreva Python em streaming (não carregue tudo na memória) para encontrar falhas silenciosas\ndo pipeline:\n1. Registros que carregam qualquer campo de erro/exceção que um pipeline tenha carimbado neles.\n2. Para cada campo DERIVADO (concatenações, *_search, *_normalized variants):\n registros onde o campo derivado está vazio, mas sua fonte óbvia não está.\n3. Pares de campos que parecem espelhos um do outro (um aninhado/rico, um plano/filtrável):\n quantifique com que frequência eles discordam.\n4. A distribuição de carimbos de data/hora atualizados/indexados: alguma fatia do\n catálogo está congelada enquanto o resto é atualizado?\n\nRelate cada descoberta com contagens, % do catálogo, 5 ids de exemplo e se os\nregistros afetados estão ativos/visíveis. Classifique por gravidade.\nVerificações nulas são a ferramenta de qualidade de dados que todos já têm. Os placeholders as derrotam, porque um placeholder é preenchido. Só não é verdadeiro.
\n\nMeu exemplo favorito: em um catálogo de 313 mil SKUs, o campo de marca tinha 741 valores distintos e 99,99% de preenchimento. Parece saudável. O valor principal, em 88,8% de todos os registros, era "Fornecedor Aprovado". Um placeholder do ERP. A marca real mais popular cobria 0,3% do catálogo. Então, toda faceta de marca, todo boost de marca e toda reescrita baseada em marca estava efetivamente morta para nove décimos do catálogo, enquanto a interface da faceta oferecia alegremente "Fornecedor Aprovado" como o filtro de marca número 1.
\n\nDepois que você começa a procurar, esse tipo de coisa está em todo lugar:
\n\n99999999.000000 em 55% de um catálogo. O preço mediano desse índice era noventa e nove milhões de dólares."desconhecido" em 64 registros, que então ranqueiam para a consulta "desconhecido".true escrito em um campo de descrição de texto em 1.516 produtos ativos. O mecanismo coagiu para a string "true", o que tornou esses produtos encontráveis pesquisando por "true"."6.71E+11" – notação científica do Excel, com 51 produtos não relacionados compartilhando esse "identificador" – além de mais 15.121 UPCs perdendo seu zero à esquerda. O Excel ataca novamente.A lição que tirei desta categoria: audite as distribuições dos N principais valores por campo, não as taxas nulas. Um campo que está 100% preenchido pode ser 88% lixo, e nenhuma verificação nula jamais lhe dirá isso. Em seguida, coloque na lista de bloqueio as sentinelas na ingestão, mapeie-as para nulos reais com sinalizadores explícitos has_price / has_real_image, faça asserção de tipo no limite e valide identificadores estruturalmente. Trate tudo que já passou por uma planilha como suspeito.
Mesmo dump JSONL. Para cada campo no meu catálogo, calcule a distribuição dos 20 principais\nvalores (passagem completa, streaming).\n\nSinalize: (a) qualquer valor único cobrindo >10% dos registros – candidatos a placeholder/sentinela\ncomo "Fornecedor Aprovado", "desconhecido", 99999999, 0.0; (b) valores cujo\ntipo difere do tipo dominante do campo (booleanos em campos de texto, floats\nentre strings); (c) campos de identificador (UPC/EAN/GTIN/números de peça):\nvalide soma de verificação e comprimento, sinalize notação científica, zeros à esquerda removidos,\nespaços em branco/unicode incorporados e identificadores compartilhados por vários registros;\n(d) valores do tipo categoria ou linha de produto em campos de marca.\n\nPara cada sinalização: contagem, % do catálogo, 5 exemplos literais com ids e uma\nregra de ingestão de uma linha que o teria rejeitado.\nOs catálogos dos distribuidores são escritos por ERPs, não por merchandisers. O texto é abreviação de fatura: PROPRESS 2-1/2X1 CXC RED CPLG, HC HX 18X8 W. Em um catálogo, um terço dos nomes de produtos tinha menos de 60% de palavras do dicionário. Em outro, os campos de nome e descrição brutos eram 100% nulos – o texto só existia dentro de blobs de busca derivados, então tudo que lia os campos brutos (títulos de resultados, entradas de embedding, prompts de julgamento de relevância) estava lendo nada e ninguém sabia.
![\"Cobertura](\"/assets/images/b2b-search-field-coverage.png\")
Esse mapa de calor é meu artefato favorito da auditoria. Cada um desses campos existe em todos os esquemas. Os números indicam quanto de cada um realmente contém dados. A linha que me pega é a de descrições ML: a camada de enriquecimento que os esquemas prometiam em todos os registros foi preenchida em dezoito documentos de 775.051. Dezoito. Cada ramo "usar enriquecimento se presente" no pipeline de pontuação era um não-op silencioso. Esquema é uma aspiração; apenas a cobertura é um fato.
\n\nEsta categoria é onde o manual publicado se aplica mais diretamente – extração de atributos da DoorDash, geração offline da Instacart – e a seção de custos abaixo precifica isso. Mas quatro regras são importantes em um negócio de números de peça, aprendidas em parte com o que a tentativa de enriquecimento anterior errou:
\n\n{tamanho, material, tipo_conexão} para facetas.CXC, ELL, CPLG, "t-stat" pertencem à expansão de sinônimos no nível do analisador, corrigida uma vez. Não pague para reescrevê-los em meio milhão de registros.Mesmo dump. Avalie a qualidade do texto dos campos voltados para o cliente (nome, descrição\ncurta/longa) com uma passagem completa em streaming:\n\n1. Cobertura do título efetivo: % de registros ATIVOS com um nome de exibição não vazio.\n2. Legibilidade: % de nomes EM CAIXA ALTA; % com menos de 60% de tokens de palavras do dicionário\n (salada de abreviações); nomes com menos de 10 caracteres; descrições apenas com dígitos.\n3. Lixo: marcação HTML/CMS, artefatos de codificação, notas operacionais incorporadas\n (*** NÃO É UM ITEM FÍSICO ***), derramamento de coluna de CSV.\n4. Duplicação: descrições curtas/longas idênticas; texto padrão compartilhado por 20+\n SKUs; clusters de comprimento exato (254/255/500 caracteres) indicando limites\n de VARCHAR a montante.\n5. Verificação da realidade do enriquecimento: para cada campo ML/enriquecido/embedding que o esquema\n promete, sua cobertura real.\n\nNúmeros, 5 exemplos literais cada, gravidade e quais problemas precisam de uma passagem de enriquecimento\nLLM vs. uma correção de pipeline vs. uma correção de camada de sinônimo.\nMetade do tráfego de busca B2B é alguém digitando um número de peça. A correspondência exata é o jogo todo lá, e ele falha de maneiras silenciosas.
\n\nEm um catálogo, o número de peça indexado era um SKU numérico interno em 99,99% dos registros. O número do fabricante – aquele impresso na caixa – existia apenas dentro de descrições de texto livre. 183.000 produtos inalcançáveis pelo número que um cliente realmente digitaria.
\n\nOutro catálogo tinha um sistema de expansão de variantes: remova os traços, colapse os segmentos, indexe as variantes para que a busca por PN seja tolerante. Boa ideia. Mas o gerador era combinatório (até 80 variantes por produto) e, em 11.826 registros, uma variante gerada de um produto era exatamente igual ao número de peça canônico de um produto diferente. Fixadores são o caso brutal, porque a pontuação codifica dimensões físicas: 702-1-5/32 é uma peça de 1-5/32 polegadas e 702-15/32 é uma peça de 15/32 polegadas, e ambos normalizam para 7021532. Um cliente digita um número de peça exato e tem um cara ou coroa entre a peça certa e sua prima dimensional.
Também nesta categoria: referências cruzadas de concorrentes ("Eu tenho o número Ferguson, qual é o seu?") armazenadas como blobs não divididos delimitados por pipe, como 19MU82|Fastenal 0269214|Ferguson M48222407, em campos configurados como não pesquisáveis, então um movimento central de venda B2B simplesmente não funciona. E bifurcações de espaço em branco – o mesmo número de peça indexado três vezes (simples, com NBSP, com espaço à direita) – além de gêmeos mojibake de UTF-8 decodificado duas vezes.
O princípio que corrige a maior parte disso: o exato deve vencer o difuso estruturalmente, não probabilisticamente. Uma cláusula exata que preserva a pontuação pontuada estritamente acima de qualquer nível normalizado, nunca uma correspondência plana onde uma variante pode empatar com um acerto canônico. Verifique as variantes geradas em relação ao espaço PN canônico antes de indexar e descarte colisões. Normalize Unicode antes de derivar IDs de registro. Divida os blobs de referência cruzada em arrays; essa é uma única linha de código de ingestão que desbloqueia uma classe inteira de consulta.
\n\nMesmo dump. Meus usuários pesquisam por número de peça; audite a integridade da correspondência\nexata:\n\n1. Quais campos do tipo PN existem (part_number, mpn, PNs alternativos/concorrentes/clientes,\n UPC), sua cobertura e quais estão configurados como não pesquisáveis enquanto\n contêm dados reais.\n2. Registros cujo único token PN pesquisável é um SKU interno (o PN real do fabricante\n aparece apenas dentro do texto da descrição – mostre o padrão).\n3. Se houver um campo de expansão de variante/palavra-chave PN: encontre cada variante\n gerada que seja igual ao PN canônico de um registro DIFERENTE (normalize:\n minúsculas, remova pontuação). Mostre pares em colisão – especialmente\n tamanhos de fixadores com frações.\n4. PNs que diferem apenas por espaço em branco/caracteres invisíveis/maúsculas de minúsculas do PN\n de outro registro (bifurcações de identidade duplicada).\n5. Campos de referência cruzada de vários valores armazenados como blobs delimitados em vez de\n arrays.\n\nContagens, exemplos e, para cada problema, a regra de ingestão ou mudança no construtor de consulta\nque o corrige.\nAlgumas coisas que não cabiam acima, mas merecem uma frase: um gerador de sinônimos que transformava qualquer número em termos de bitola de fio, então REF#259286 se tornou "259286 awg" e um parafuso #8-32 se tornou "fio 8" (milhares de registros agora correspondem a consultas elétricas com as quais não têm nada a ver); sinalizadores internos de uma plataforma de e-commerce indexados como especificações de produto pesquisáveis, 2,1 milhões de pares chave-valor inúteis; e 18 campos de esquema preenchidos em zero registros em qualquer lugar. Geradores de expansão precisam de portões de contexto. Esquema morto é uma promessa falsa na qual alguém acabará construindo.
Há um quinto problema que merece sua própria seção, porque é onde a distribuição comercial está mais atrás dos marketplaces: a categorização.
\n\nNa minha auditoria, os campos de categoria estavam ausentes em 83% de um catálogo. As chaves de atributo não tinham taxonomia alguma – 7.068 chaves de especificação distintas em um catálogo de 156 mil registros, 64% delas usadas em menos de dez produtos, com deriva como horse_power vs horsepower dividindo o mesmo atributo entre facetas. E o detalhe em que continuo pensando: dois dos quatro catálogos tinham campos UNSPSC em seus esquemas, mapeados e prontos, preenchidos em exatamente zero registros. Alguém sabia que a categorização era importante, construiu o slot e nunca o preencheu. Aposto dinheiro no porquê: classificar 300 mil SKUs em uma taxonomia manualmente é um ano de trabalho da equipe de catálogo, então ficou para sempre no roteiro.
Se você está fora do B2B, UNSPSC é o Código Padrão de Produtos e Serviços da ONU, a taxonomia que os sistemas de compras falam. Esta é a parte que a busca ao consumidor não tem: os sistemas de compras de seus clientes exigem isso. Catálogos de compras, plataformas de e-procurement e ferramentas de análise de gastos são construídos em torno de códigos UNSPSC. Um distribuidor cujo catálogo carrega códigos limpos pode se conectar ao sistema de compras de um empreiteiro ou hospital. Um sem eles é uma lista de preços em PDF com uma caixa de busca. Internamente, também é o que alimenta as facetas de categoria, o ranqueamento com escopo de categoria ("um número que se analisa como bitola de fio só deve impulsionar fio"), a deduplicação entre catálogos e os portões de contexto para cada gerador de expansão na Categoria 4.
\n\nE agora é um trabalho em lote. Este é o mesmo formato de problema que a DoorDash descreve resolver com LLMs – rotulagem de alto volume contra um vocabulário controlado – e a abordagem se transfere diretamente:
\n\nO custo é quase embaraçoso de digitar. A classificação é uma tarefa de saída curta: aproximadamente 300 tokens de entrada por registro e 30 de saída. No Claude Haiku 4.5 com preço de API em lote, isso é cerca de 17 centavos por mil SKUs. Minha frota inteira de 775 mil registros seria classificada por cerca de $130. A coisa que ficou no roteiro por anos porque era um ano de trabalho manual custa menos do que o almoço da equipe onde você discutiria isso.
\n\nVocê classifica produtos de distribuidores B2B em UNSPSC. Anexado: a lista de famílias\nUNSPSC (nível 2, ~450 entradas) como dados de referência.\n\nPara cada registro de produto (título, descrição, marca, número de peça, qualquer texto de categoria\n existente), gere JSON:\n- unspsc_family: o código de família de 4 dígitos – escolha APENAS da lista anexada\n- family_confidence: alta | baixa\n- rationale: uma frase curta (ex.: "conexão de pressão de cobre -> conexões de tubo")\n\nRegras: julgue pela função do produto, não pela sua marca. Abreviações comerciais:\nCXC/FPT/MPT são conexões de tubo, ELL é cotovelo, CPLG é acoplamento, uma\nfração nua+material geralmente é um tamanho de conexão. Se o registro não for um produto\nfísico (linhas de frete, sobretaxas, "*** NÃO É UM ITEM FÍSICO ***"), gere\nNOT_A_PRODUCT. Use baixa confiança liberalmente – registros de baixa confiança recebem uma\nsegunda passagem com a lista de nível de classe.\nO pipeline de correção tem três camadas mais o trabalho de classificação. O truque é gastar na camada certa, porque você quase nunca precisa de uma chamada de LLM por registro.
\n\nflowchart LR\n A["Camada 0 - Regras<br/>código determinístico<br/>~$0"] --> B["Camada 1 - LLM em valores únicos<br/>marcas · chaves de especificação · unidades<br/>dezenas de dólares"]\n B --> C["Camada 2 - LLM por registro<br/>títulos · atributos · UNSPSC<br/>centenas de dólares"]\n C --> G["Portões de ingestão<br/>cada correção se torna um validador"]\nA Camada 0 é código determinístico e é basicamente gratuita. Remova HTML e decodifique entidades. Transforme sentinelas em nulos reais com sinalizadores explícitos. Repare UPCs (preencha à esquerda, rejeite notação científica, valide o dígito de verificação). Normalize Unicode em IDs. Divida as referências cruzadas delimitadas por pipe. Descarte variantes de PN que colidem com o número canônico de outro produto. Exclua esquema morto. Um agente escreve esses scripts em uma sessão, e esta camada corrigiu aproximadamente metade de tudo que minha auditoria encontrou. Faça isso antes de qualquer enriquecimento, ou você pagará a um modelo para reescrever lindamente títulos de produtos que seu pipeline descartou silenciosamente.
\n\nA Camada 1 executa o LLM sobre valores únicos, não registros. Este é o truque que torna os problemas de vocabulário baratos: meu pior catálogo tinha 313 mil registros, mas apenas 741 strings de marca distintas. A normalização de marca é um trabalho sobre 741 strings – agrupe as variantes de maiúsculas/minúsculas, mapeie sub-marcas para matrizes, sinalize os placeholders – não 313 mil chamadas. O mesmo vale para chaves de especificação e sufixos de unidade. Cada trabalho de vocabulário custa dígitos únicos de dólares e sua saída é uma tabela de alias estática que sua ingestão aplica para sempre, deterministicamente. Chame a camada inteira de $20-50 para uma frota, principalmente gasto em passagens de revisão.
\n\nAnexado: a distribuição de valores distintos completa dos meus campos de marca e\nfabricante (valor, record_count). Produza uma tabela de normalização:\n\ncanonical_brand, parent_manufacturer, [raw variants], confidence\n\nRegras: agrupe variantes de maiúsculas/minúsculas/pontuação/espaço em branco; mapeie sub-marcas para fabricantes\nmatrizes como uma coluna separada (não mescle); marque valores de placeholder como\nNULL_SENTINEL; marque linhas de produtos ou categorias arquivadas erroneamente como marcas como\nNOT_A_BRAND. Sinalize clusters incertos em vez de adivinhar. Gere CSV e, em seguida,\nescreva um script que o aplique na ingestão e registre novos valores não correspondidos.\nA Camada 2 é a passagem por registro: um título legível para o cliente, expansões de busca, atributos estruturados e um número de peça do fabricante recuperado para cada produto. Por SKU é pequeno – cerca de 400 tokens de entrada (o registro, mais instruções compartilhadas que o cache de prompt torna quase gratuito) e 250 de saída. Duas alavancas antes mesmo de escolher um modelo: enriqueça o que está ativo (no meu pior catálogo, apenas 14% dos registros estavam ativos, um corte de 86% logo ali), e use uma API em lote onde o provedor tiver uma, já que o enriquecimento não tem requisito de latência e tanto a Anthropic quanto a OpenAI dão 50% de desconto para lote.
\n\nEu precifiquei o mesmo trabalho em tudo que você usaria plausivelmente em 2026 – Claude, [os três níveis do GPT-5.6](https://openai.com/index/advancing-the-price-performance-frontier-with-gpt-5-6/) (Sol, Terra, Luna), Kimi K3, GLM-5.2, Qwen3.5 e [DeepSeek V4](https://deepseek.ai/pricing). Mesma carga de trabalho, taxas publicadas pelos provedores, desconto de lote aplicado onde existe:
\n\n![\"Custo](\"/assets/images/b2b-search-enrichment-cost-by-model.png\")
Eu tive que verificar esses números duas vezes porque pareciam errados. A versão de pior caso deste projeto – um modelo de fronteira, cada SKU, sem filtragem alguma – chega a cerca de $3.800. O piso fica abaixo de cem dólares: DeepSeek V4-Flash enriqueceria a frota inteira por aproximadamente o preço de uma furadeira decente. A versão que você realmente executaria mistura camadas: um modelo de orçamento (Haiku, Luna, Qwen Flash, DeepSeek) para a maioria mecânica, um modelo de nível médio (Sonnet, Terra, GLM-5.2) para a cauda de salada de abreviações que o pequeno sinaliza como baixa confiança, e um modelo de fronteira verificando uma amostra de 1-2% como o portão de qualidade. Isso chega a algumas centenas de dólares para os SKUs ativos, independentemente de quais fornecedores você escolher.
\n\nDuas ressalvas que o gráfico não pode mostrar. Modelos baratos só são baratos se sua saída sobreviver à sua avaliação – execute a comparação de 200 amostras antes de se comprometer, porque um modelo de orçamento que estraga 5% dos números de peça custa mais do que o modelo de fronteira que não estraga. E seu catálogo são dados competitivos: preços, referências cruzadas e números de peça de clientes estão nesses registros, então verifique as políticas de retenção de dados e treinamento de cada provedor antes de enviar 775 mil registros para o endpoint mais barato da lista. Para muitos distribuidores, essa verificação sozinha descarta alguns fornecedores, e as opções de peso aberto (DeepSeek, GLM, Qwen, Kimi) têm a propriedade extra de que você pode auto-hospedá-los se os dados não puderem sair.
\n\nAdicione a passagem UNSPSC de ~$130 (que escala da mesma forma entre modelos – na camada de orçamento, cai para trocados) e o trabalho de vocabulário, e a transformação completa do catálogo fica entre algumas centenas e alguns milhares de dólares, contra um trabalho que costumava ser o ano de uma equipe de merchandising. É a mesma economia de lote offline que a Instacart descreve, apenas na escala do catálogo comercial onde os números ficam pequenos o suficiente para colocar em um cartão de crédito.
\n\nComo fica em um registro real da minha auditoria:
\n\nENTRADA: part_number: 1678619\n short_desc: PROPRESS 2-1/2X1 CXC RED CPLG 20685\n brand: (placeholder)\n\nSAÍDA: display_title: 2-1/2" x 1" ProPress Copper Reducing Coupling\n search_expansions: ["copper press fitting", "reducing coupling",\n "press x press coupling"]\n attributes: {size_1: {value: 2.5, unit: in},\n size_2: {value: 1, unit: in},\n material: copper, connection: press}\n extracted_mpn: "20685"\n unspsc_family: 4017 (pipe fittings)\n confidence: high\nObserve a linha extracted_mpn. A mesma passagem recupera números de peça do fabricante que estavam anteriormente enterrados no texto da descrição – em um dos meus catálogos, isso são 183 mil produtos se tornando encontráveis pelo número impresso na caixa. Isso sozinho paga pelo trabalho em lote.
Você enriquece registros de produtos de distribuidores B2B para busca. Para cada registro de entrada\n(nome bruto do ERP, descrições, marca, número de peça, categoria), gere JSON:\n\n- display_title: legível para o cliente, <=80 caracteres, Title Case. Expanda abreviações\n comerciais (CXC -> conexão cobre x cobre, ELL -> cotovelo, CPLG ->\n acoplamento, RED -> redução). Mantenha TODO número de peça, código de modelo e\n dimensão LITERALMENTE como digitado – nunca soletre códigos em palavras.\n- search_expansions: 2-5 frases que um cliente pode digitar que não aparecem no\n texto bruto (tipo de produto em inglês simples, nomes comerciais comuns). Nunca invente\n especificações ausentes da fonte.\n- attributes: {nome: {valor, unidade}} extraído APENAS do texto de origem.\n- extracted_mpn: número de peça do fabricante se presente no texto da descrição\n (geralmente o token após a marca) e ausente dos campos PN, senão nulo.\n- confidence: alta | baixa. Use baixa sempre que tiver que adivinhar; uma resposta\n baixa encaminhada para revisão é melhor do que uma alucinação confiante.\nDuas notas de produção: coloque as instruções compartilhadas em um prefixo de prompt em cache (o cache reduz o lado da entrada em até 90% além do desconto de lote) e use saídas estruturadas com um esquema JSON para nunca pagar um imposto de falha de análise.
\n\nA última camada é a que as pessoas pulam, e é a que se acumula. A auditoria vale uma limpeza. Os validadores que ela gera valem cada feed futuro. Termine a sessão de correção com:
\n\nTransforme cada problema que acabamos de corrigir em uma verificação automatizada que falha o pipeline\nde ingestão ruidosamente: asserções de cobertura de campo derivado, listas de bloqueio de sentinela, asserções\nde tipo em campos de texto, validação de soma de verificação de identificador, verificação de\ncolisão de variante PN, regras de higiene de ID, rastreamento de cobertura UNSPSC e um alarme de\natualização de dados por catálogo. Emita-os como testes que a CI executa contra uma amostra de\ncada novo feed.\nPule isso e as mesmas exportações de ERP regenerarão o mesmo lixo dentro de um trimestre, e você pagará pela limpeza duas vezes. Eu sei porque dois dos bugs que minha auditoria encontrou claramente haviam sido corrigidos antes e voltaram.
\n\nUma etapa de configuração: exporte seu catálogo para JSONL, um objeto JSON por linha com um id único e os campos do registro. Seja qual for sua plataforma – Elasticsearch, OpenSearch, Solr, Algolia, Typesense, um PIM, o banco de dados por trás de tudo – basta pedir ao agente para escrever o exportador:
Escreva um script que exporte todos os registros de produtos do meu catálogo [descreva:\nnome do índice de busca / tabela do banco de dados / exportação do PIM] para ./dump/records-{n}.jsonl\nem blocos de 50 mil registros – um objeto JSON por linha com um "id" único mais todos\nos campos – e minha definição de campo/esquema (se a plataforma tiver uma) para\nschema.json. Verifique se a contagem exportada corresponde à contagem de origem.\nCom o Claude Code, solte qualquer prompt de categoria em uma sessão nesse diretório. Ele escreve e executa a análise sozinho, passagens completas sem desculpas de amostragem, e volta com recibos no nível do registro. Quando você diz "agora corrija", a mesma sessão produz o validador de ingestão, o script de retroalimentação e o trabalho de enriquecimento em lote. Execute as categorias como sessões paralelas ou subagentes; foi assim que executei as minhas, e a auditoria inteira levou cerca de doze minutos de tempo de parede. Com o Codex, codex exec lida com as passagens de análise somente leitura usando os mesmos prompts; mantenha as correções do lado da escrita em uma sessão que você revisa.
Três regras que aprendi da maneira mais difícil:
\n\nAmazon, DoorDash e Instacart não publicaram seu trabalho de catálogo com LLM como caridade. Eles publicaram porque as técnicas são gerais e o fosso é a execução. E as técnicas se transferem para a distribuição comercial melhor do que para quase qualquer outro lugar que consigo imaginar: os catálogos são pequenos o suficiente para que uma passagem completa seja barata, os dados são ruins o suficiente para que o espaço para melhoria seja enorme, as consultas carregam dinheiro real, e o mundo de compras já funciona em uma taxonomia que um trabalho em lote pode agora preencher por cerca de $130.
\n\nDas dezenas de problemas que minha auditoria revelou em quatro catálogos de distribuidores, nenhum era visível a partir da camada de ranqueamento. Todos o degradavam. A cadeia de suprimentos que alimenta esses índices – as exportações de ERP, as planilhas de fornecedores, os antigos analisadores CSV – é exatamente o que o manual publicado corrige. Os distribuidores que o executarem terão busca de nível de marketplace em catálogos onde seus concorrentes ainda não conseguem encontrar uma serpentina de condensador.
\n\nA pergunta "há algo errado com meus dados?" costumava custar duas semanas do tempo de alguém, e é por isso que ninguém a fazia. Agora custa um prompt. Faça-a.
", "source_hash": "sha256:beacaae673c45f36f13a5677632c8df46a2339c6bdea51c65c49f762d7f0805c", "model": "deepseek/deepseek-v4-flash", "generated_at": "2026-08-07T08:11:49.846151+00:00" }