Pesquisa Vetorial em Catálogos Comerciais: Porque a Semântica Sozinha Não É Suficiente

Porque num catálogo comercial, o erro dispendioso não é “não soar semântico”—o erro dispendioso é recomendar algo real, mas incorreto.

Essa frase resume o problema de usar IA em catálogos comerciais como se fosse apenas uma questão de pesquisa semântica.

Quando um utilizador digita “preciso de algo para conter um derrame” ou “procurando sapatilhas para tempo chuvoso”, a tentação técnica é clara: gerar embeddings, executar pesquisa vetorial e devolver os produtos mais próximos. Isso pode ser uma grande melhoria em relação à pesquisa exata por palavras-chave, mas não resolve todo o problema.

Num catálogo comercial, uma boa resposta não é a que soa inteligente. É a que devolve produtos reais, disponíveis, adequados e rastreáveis—prontos para serem mostrados ou comprados.

Em resumo

A pesquisa vetorial é útil para entender a intenção, sinónimos e necessidades expressas em linguagem natural. Mas na descoberta comercial, não deve funcionar sozinha. Precisa viver dentro de uma arquitetura híbrida com pesquisa exata, filtros de negócio, validações de stock e preço, controlo de canal, rastreabilidade e avaliações.

O modelo pode ajudar a interpretar o que a pessoa quer. O backend deve decidir quais produtos são válidos para mostrar.

O erro comum: confundir similaridade com recomendação

A pesquisa vetorial responde a uma pergunta como:

“Quais itens no catálogo estão semanticamente próximos a esta consulta?”

Uma recomendação comercial precisa responder a uma pergunta diferente:

“Quais produtos reais posso recomendar a esta pessoa, neste canal, com estas restrições, sem inventar dados ou criar risco comercial?”

São problemas relacionados, mas não são os mesmos.

Um produto pode estar semanticamente próximo e ainda assim ser uma má recomendação se falhar em qualquer um destes critérios:

• Disponibilidade: está fora de stock.
• Categoria: pertence a uma categoria diferente.
• Orçamento: excede o que o cliente pode pagar.
• Canal ou país: não é vendido nesse mercado ou canal de vendas.
• Compatibilidade: não se adapta ao modelo, uso ou contexto do cliente.
• Aplicação real: tem uma descrição semelhante, mas serve uma necessidade diferente.
• Dados mínimos: falta imagem, URL, preço válido ou informação suficiente.
• Risco técnico: requer um aviso antes de recomendar.
• Segmentação: está oculto para esse segmento de vendas.

Se o sistema recomendar esse produto, o problema não é estilo. É confiança, conversão e responsabilidade operacional.

Porque um catálogo não é apenas uma base de dados de documentos regular

Numa base de conhecimento clássica, RAG geralmente recupera fragmentos de documentos para ajudar o modelo a responder melhor. Num catálogo comercial, o objetivo é mais difícil: é preciso devolver entidades acionáveis.

Um produto não é um parágrafo. É uma combinação de identidade, variante, preço, stock, imagem, URL, atributos, restrições e fonte.

É por isso que um catálogo preparado para agentes precisa de campos estruturados:

Campo	Porque é importante
id	Identidade estável do produto.
sku ou referência	Pesquisa exata, rastreabilidade e suporte a vendas.
título e descrição	Compreensão humana e correspondência semântica.
categoria	Filtragem de intenção e navegação.
preço	Recomendação acionável.
disponibilidade	Impede a recomendação de produtos não vendáveis.
image_url	Renderização de cartão ou carrossel.
product_url	Ação de detalhe ou compra.
atributos	Tamanhos, medidas, materiais, usos, compatibilidade e restrições.
source	Registo de origem, data de sincronização e trilha de auditoria.

Os embeddings podem representar parte desse produto, mas não substituem o contrato comercial.

O que o LLM deve fazer

O LLM não deve inventar produtos, preços, imagens, stock ou URLs. O seu trabalho é interpretar a intenção e devolver um pedido estruturado.

Por exemplo:

{
  "catalog_discovery": {
    "action": "search_products",
    "query": "produto para conter um derrame de hidrocarbonetos",
    "filters": {
      "availability": "in_stock",
      "use_case": "spill_containment"
    },
    "limit": 3
  }
}

Essa saída não contém produtos. Contém intenção.

Depois, o backend consulta o catálogo, aplica regras, valida restrições e devolve cartões:

{
  "type": "product_carousel",
  "items": [
    {
      "type": "product_card",
      "id": "prod_001",
      "title": "Kit de Contenção de Derrames de Hidrocarbonetos",
      "price": "$89.00",
      "availability": "Disponível",
      "image_url": "/media/catalog/prod_001.jpg",
      "product_url": "https://store.example/products/prod_001",
      "reason": "Ajusta-se porque foi projetado para conter derrames de hidrocarbonetos e está disponível."
    }
  ]
}

A diferença é importante: o modelo decide o que pesquisar; o sistema decide o que pode ser mostrado.

Onde a pesquisa vetorial encaixa-se

A pesquisa vetorial faz muito sentido quando o utilizador não sabe o nome exato do produto.

Exemplos:

• “algo para absorver óleo numa oficina”;
• “uma mochila para viagens curtas na chuva”;
• “um produto para armazenar tambores com segurança”;
• “sapatilhas para mau tempo”;
• “uma máquina de café compacta com moedor”;
• “um acessório compatível com o meu modelo antigo”.

Nestas consultas, a pesquisa literal pode falhar porque as palavras do utilizador não correspondem às do catálogo. O catálogo pode dizer “absorvente de hidrocarbonetos”, “palete de derrame”, “membrana impermeável”, “contenção secundária” ou “moedor integrado”, enquanto o utilizador fala normalmente.

É aí que os embeddings ajudam a conectar a necessidade ao produto.

Mas há consultas onde a pesquisa exata é superior:

• referências internas;
• SKUs;
• modelos;
• medidas;
• capacidades;
• normas técnicas;
• tamanhos;
• marcas;
• números de peça;
• nomes de produtos.

Se alguém pesquisar por “RIDGEPACK-25-BLK”, “XZ-400”, “25L”, “GTX”, “120 cm” ou uma referência específica, a pesquisa semântica não deve improvisar. O sistema precisa de precisão lexical e filtros estruturados.

A arquitetura certa: híbrida

A solução prática não é escolher entre pesquisa por palavras-chave e pesquisa vetorial. É combiná-las.

Um fluxo saudável para um catálogo comercial seria:

1. O utilizador expressa uma necessidade.
2. O LLM converte-a numa intenção estruturada.
3. O backend valida a capacidade e normaliza filtros.
4. Regras rigorosas são aplicadas: canal, disponibilidade, país, permissões, preço e categoria, se necessário.
5. A pesquisa lexical recupera correspondências exatas.
6. A pesquisa vetorial recupera correspondências semânticas.
7. O sistema funde candidatos.
8. Uma classificação ordena por relevância, adequação de atributos, disponibilidade, preço e qualidade dos dados.
9. Preço, stock, URL e imagem são revalidados.
10. O frontend renderiza cartões, carrosséis ou fallback.

Em pseudopipeline:

intenção do utilizador
  -> saída estruturada do LLM
  -> filtros rigorosos
  -> pesquisa lexical
  -> pesquisa vetorial
  -> classificação híbrida
  -> validação comercial
  -> cartões de produto

Este design permite que o sistema compreenda a linguagem natural sem perder o controlo comercial.

Filtros rigorosos antes da classificação

Algumas regras não devem depender de uma pontuação.

Se um produto não é permitido, não é classificado. É excluído.

Exemplos:

• inquilino errado;
• canal não autorizado;
• produto oculto;
• país fora de cobertura;
• stock indisponível;
• preço inválido;
• URL em falta;
• imagem obrigatória em falta;
• compatibilidade não comprovada;
• restrição comercial não cumprida.

Depois de excluir itens inválidos, então faz sentido classificar.

Uma classificação comercial pode combinar:

Sinal	O que acrescenta
Relevância semântica	Ajuste com a necessidade expressa.
Relevância lexical	Correspondência exata com referência, marca, modelo ou atributo.
Correspondência de atributos	Cumpre os requisitos solicitados.
Disponibilidade	Preferência por produtos vendáveis agora.
Preço	Ajusta-se ao orçamento ou intervalo esperado.
Qualidade dos dados	Imagem, descrição, atributos e URL completos.
Atualidade	Dados sincronizados recentemente.
Regra de negócio	Prioridade comercial quando não contradiz o utilizador.

A classificação ajuda a escolher entre produtos válidos. Não deve resgatar produtos que falharam em regras rigorosas.

Enriquecimento não é apenas decoração

Num catálogo alimentado por IA, enriquecer produtos não significa escrever descrições mais bonitas. Significa tornar cada produto mais recuperável, avaliável e renderizável.

Campos úteis para enriquecimento:

• usos recomendados;
• problemas que resolve;
• termos comerciais equivalentes;
• atributos normalizados;
• unidades e intervalos;
• compatibilidades;
• incompatibilidades;
• restrições de uso;
• categoria canónica;
• sinais de compra;
• perguntas que ajuda a responder;
• razão permitida para recomendação;
• nível de confiança por atributo.

Esse enriquecimento pode alimentar embeddings, filtros, explicações e avaliações. Mas deve ser rastreável: qual modelo o gerou, com que prompt, a partir de quais dados de origem e em que data.

Se uma recomendação falhar amanhã, precisa ser capaz de reconstruir porque o sistema chegou lá.

Como evitar recomendações inventadas

A regra principal é simples:

O LLM não cria cartões de produto.

Pode:

• interpretar a intenção;
• solicitar uma pesquisa;
• sugerir filtros;
• redigir uma explicação com base nos dados devolvidos;
• pedir esclarecimentos se faltar informação.

Não deve:

• criar produtos;
• inventar preços;
• preencher stock;
• deduzir compatibilidades sem uma fonte;
• gerar URLs;
• prometer disponibilidade;
• misturar produtos de diferentes catálogos.

Quando não há resultados, o sistema deve dizer isso de forma útil:

{
  "type": "no_results",
  "message": "Nenhum produto disponível encontrado que corresponda exatamente a esses critérios.",
  "suggested_next_steps": [
    "Expandir intervalo de preço",
    "Ver alternativas compatíveis disponíveis",
    "Verificar produtos semelhantes disponíveis"
  ]
}

Um bom fallback vale mais do que uma recomendação convincente, mas incorreta.

Avaliações: o que separa uma demonstração de um produto real

Um catálogo alimentado por IA precisa de testes específicos.

Não é suficiente verificar se a resposta “soa bem.” É preciso verificar se o sistema devolve produtos corretos.

Métricas úteis:

Métrica	O que mede
top_1_relevance	Se o primeiro produto se ajusta à consulta.
top_3_recall	Se há pelo menos um produto correto entre os três primeiros.
attribute_match_rate	Se os atributos solicitados são respeitados.
availability_accuracy	Se o stock mostrado corresponde à fonte.
price_accuracy	Se o preço corresponde ao catálogo.
hallucination_rate	Se produtos ou campos inventados aparecem.
fallback_quality	Se responde bem quando não há resultados.
render_contract_validity	Se a resposta pode ser renderizada como um cartão ou carrossel.

Para um MVP, 30 ou 50 consultas bem desenhadas já revelam muito:

• pesquisas baseadas em intenção;
• pesquisas de SKU;
• produtos fora de stock;
• orçamento máximo;
• compatibilidade;
• consultas fora do catálogo;
• ambiguidade real;
• produtos semelhantes, mas incorretos.

É aí que se descobre se a pesquisa vetorial realmente melhora as coisas ou apenas adiciona resultados bonitos, mas arriscados.

Como eu começaria para um MVP

A sequência pragmática seria:

1. Criar a sua própria base de dados de catálogo limpa.
2. Normalizar campos mínimos: título, descrição, categoria, preço, stock, imagem, URL e atributos.
3. Enriquecer produtos com usos, atributos canónicos e termos equivalentes.
4. Implementar pesquisa lexical e filtros rigorosos.
5. Criar avaliações manuais com consultas reais.
6. Adicionar embeddings como um sinal complementar.
7. Comparar resultados antes e depois.
8. Ativar classificação híbrida apenas se melhorar a relevância sem aumentar erros.

Não começaria com uma base de dados vetorial complexa. Começaria por provar que o sistema recomenda produtos reais sem inventar coisas.

Depois sim: embeddings, pesquisa híbrida, reclassificação, MCP ou integração com canais externos.

A ideia central

Um agente comercial não precisa “soar como um vendedor.” Precisa trabalhar com dados de vendas reais.

Nos catálogos, a IA acrescenta valor quando ajuda a traduzir a intenção humana em produtos acionáveis. Mas essa tradução deve passar por contratos, filtros, rastreabilidade e avaliação.

A arquitetura certa separa responsabilidades:

• o utilizador expressa uma necessidade;
• o LLM interpreta a intenção;
• o backend consulta e valida;
• o catálogo fornece verdade comercial;
• o frontend exibe cartões;
• a equipa mede erros e melhora o sistema.

A pesquisa vetorial é uma peça muito útil dessa arquitetura. Mas não é a arquitetura.

Porque num catálogo comercial, o objetivo não é que a resposta soe inteligente. É que a recomendação seja correta.

Leitura relacionada

• Preparar uma base de conhecimento para um agente IA comercial
• Porque um prompt não é uma estratégia de automação comercial
• Regras de negócio em agentes IA: perguntar, filtrar e encaminhar
• Agente IA comercial para discovery: o que perguntar antes de uma chamada

Perguntas frequentes

A pesquisa vetorial é útil para encontrar produtos num catálogo comercial?

Sim, mas deve complementar a pesquisa exata, filtros e regras de negócio. É útil para a intenção semântica, não como substituto para validações de SKU, stock, preço, compatibilidade ou canal.

Porque é que os embeddings não são suficientes para recomendações de produtos?

Porque uma recomendação comercial deve ser correta, disponível, rastreável e acionável. Um vetor pode encontrar produtos semelhantes, mas não garante que restrições rigorosas como preço, disponibilidade, categoria, compatibilidade ou permissões sejam cumpridas.

Qual é a arquitetura certa para um catálogo alimentado por IA?

Uma arquitetura híbrida: o modelo interpreta a intenção, o backend aplica filtros rigorosos, a pesquisa combina sinais lexicais e vetoriais, e o sistema valida a resposta antes de apresentar os cartões de produto.

Deve o LLM criar os cartões de produto?

Não. O LLM pode propor uma intenção de pesquisa estruturada. Os cartões de produto devem vir do catálogo real, com produto, imagem, preço, stock, URL e rastreabilidade gerados pelo backend.