Como Depurar uma Recomendação Incorreta em um Catálogo com IA

Quando uma recomendação falha em um catálogo com IA, o impulso mais comum é olhar para a resposta final e concluir que “o modelo errou”.

Quase nunca é o melhor ponto de partida.

O erro visível costuma ser o último elo de uma cadeia anterior. O produto correto pode ter desaparecido muito antes. Ou o incorreto pode ter sobrevivido numa etapa em que já deveria ter sido excluído. Se não localizarmos essa primeira fuga, acabamos alterando prompts, embeddings ou regras às cegas.

Em resumo

Para depurar uma recomendação incorreta, vale percorrer a pipeline em ordem e localizar a primeira etapa defeituosa: interpretação → mercado → retrieval → filtros → ranking → seleção → texto → cards. A Pinecone distingue modos de busca diferentes com sinais diferentes; o BM25 continua a ser referência clássica para matching lexical; dense retrieval e BERT reranking funcionam como etapas distintas; e frameworks recentes de avaliação de RAG separam retrieval e geração precisamente para diagnosticar onde o erro começa.

Não comece pela resposta final

A resposta final ajuda a perceber que algo está mal. Nem sempre ajuda a perceber porquê.

Se o sistema recomenda o produto errado, várias coisas podem ter acontecido:

• interpretou mal a intenção;
• consultou o mercado errado;
• não recuperou o produto correto;
• recuperou demasiado ruído;
• filtrou mal;
• ranqueou mal;
• selecionou mal entre válidos;
• escreveu uma explicação enganosa;
• ou renderizou cards incoerentes com a decisão.

O RAGVUE insiste precisamente em separar qualidade do retrieval, completude da resposta e fidelidade à evidência. A taxonomia recente de erros em RAG reforça a mesma ideia: muitos erros iniciais em retrieval ou reranking acabam parecendo falhas de generation.

Pipeline de depuração

A pergunta certa não é “o que o sistema disse errado?”. É esta:

Em que etapa exata o produto correto deixou de estar disponível, ou em qual etapa o incorreto sobreviveu?

Falhas de interpretação

A interpretação falha quando a consulta já sai mal convertida em intenção estruturada.

Sintomas típicos:

• uma necessidade implícita vira a família errada;
• uma referência exata vira linguagem natural;
• um requisito obrigatório vira preferência;
• ou uma consulta ambígua recebe resposta sem pedido de clarificação.

Aqui o problema ainda não é retrieval. É de contrato. A Pinecone recomenda sinais exatos quando a consulta compartilha tokens específicos com os dados — como nomes de produto, identificadores ou jargão técnico — e sinais semânticos quando o que manda é o significado em linguagem natural. Se o sistema classifica mal a consulta, todo o resto herda essa decisão.

Falhas de mercado

Às vezes a recomendação parece relevante, mas pertence ao mercado errado.

Sintomas:

• URL de outro país;
• preços incompatíveis com o catálogo ativo;
• idioma correto, mas produto do mercado errado;
• ou mistura de disponibilidade entre catálogos.

Esse tipo de erro costuma indicar problema de namespace, seleção de agente ou filtros por metadados. A Pinecone documenta que os namespaces são a unidade para a qual as queries apontam, e que os filtros por metadados limitam os resultados a registros que satisfaçam a expressão.

Falhas de retrieval

Retrieval falha quando o produto correto deveria entrar entre os candidatos e não aparece.

Aqui vale separar:

• exact match;
• sparse lexical;
• dense semantic;
• híbrido.

O BM25 continua muito útil quando importa o token exato, e a Pinecone segue recomendando full-text ou lexical search para nomes de produto, identificadores e frases precisas. Dense retrieval, por sua vez, ajuda quando importa mais a similaridade conceitual do que a palavra exata. Por isso, uma falha de retrieval nem sempre pede embeddings melhores; às vezes pede outro modo de busca ou outra mistura de sinais.

Falhas de filtros

Se o produto correto aparece nos candidatos mas some depois, o primeiro suspeito são os filtros.

Os filtros falham quando eliminam algo que devia continuar ou deixam vivo algo que devia morrer.

Exemplos:

• produto correto eliminado por metadado ausente ou mal tipado;
• exclusão por disponibilidade stale;
• compatibilidade tratada como negativa por defeito;
• ou regra de canal aplicada antes da normalização do contexto.

A Pinecone documenta filtros por metadados como mecanismo explícito para restringir resultados. Isso é poderoso, mas também significa que um campo modelado de forma errada pode matar o resultado correto muito cedo.

Falhas de ranking

Ranking falha quando o produto certo continua vivo, mas demasiado abaixo.

Isso acontece quando o sinal correto existe, mas pesa pouco, ou quando uma preferência de negócio resgata demais um produto mediano.

Vale lembrar a arquitetura clássica de duas etapas: um retrieval eficiente primeiro recupera candidatos e um reranker mais caro os reordena. A literatura sobre BERT reranking parte exatamente desse desenho: primeiro BM25 ou outro mecanismo escalável, depois um modelo intensivo de reranking. Se o produto correto entra mas não sobe, o problema já não é de cobertura. É de pesos, features ou reranker.

Falhas de seleção

Às vezes vários produtos válidos sobrevivem e o sistema escolhe mal o subconjunto final.

Esse erro não é puramente de ranking nem ainda de geração. É um erro de política de seleção:

• mostrar armazenamento quando o utilizador não pediu;
• escolher o item com melhores dados em vez do melhor encaixe;
• favorecer objetivo de negócio contra a intenção explícita;
• ou devolver variantes redundantes demais.

Aqui vale registar não apenas o score final, mas a razão de inclusão ou exclusão de cada candidato.

Falhas de texto

Pode acontecer algo mais subtil: a seleção está correta, mas o texto explicativo não.

Sintomas:

• o texto atribui propriedades ausentes nos facts;
• promete compatibilidade não comprovada;
• exagera disponibilidade;
• ou resume mal o que o backend devolveu.

ARES e RAGVUE ajudam justamente a pensar essa separação entre relevância recuperada, completude e fidelidade. Uma boa seleção pode perder credibilidade se a camada textual improvisar.

Falhas de cards

A última etapa também pode quebrar a confiança mesmo quando a seleção e o texto estão corretos.

Exemplos:

• card de outro ID;
• imagem trocada;
• URL ausente;
• preço stale;
• atributos incoerentes com a explicação.

Quando isso acontece, o problema já não é o modelo. É o contrato entre backend e renderização.

O que eu registaria

Se tivesse de instrumentar a pipeline minimamente, guardaria uma trace por consulta com:

• consulta original;
• intenção estruturada;
• mercado e namespace;
• candidatos lexicales;
• candidatos semânticos;
• candidatos fundidos;
• exclusões por filtro com motivo;
• sinais de ranking;
• seleção final;
• texto gerado;
• payload final de cards.

A razão é prática: não se consegue localizar a primeira etapa defeituosa se apenas se conserva a última resposta.

A ideia central

Depurar um catálogo com IA não consiste em discutir se o modelo “entendeu” ou “não entendeu”.

Consiste em localizar a primeira etapa onde a arquitetura perdeu controlo. Quando esse ponto aparece, o problema deixa de parecer magia e volta a ser engenharia.

Leituras relacionadas

• Pesquisa Vetorial em Catálogos Comerciais: Porque a Semântica Sozinha Não É Suficiente
• Como Preparar a Base de Conhecimento para um Agente IA Comercial
• Regras de Negócio em Agentes de IA Comercial: Quando Perguntar, Filtrar ou Encaminhar
• Porque um Prompt Não é uma Estratégia de Automação Comercial

Perguntas frequentes

Uma recomendação incorreta implica sempre problema de embeddings?

Não. A falha pode acontecer antes, na interpretação ou no mercado, ou depois, em filtros, ranking, seleção, texto ou cards.

Como sei se o problema é retrieval ou ranking?

Se o produto correto não entra nos candidatos, falha retrieval. Se entra mas fica baixo, falha ranking ou reranking.

Por que registar namespace e metadados?

Porque um erro de mercado ou um filtro mal aplicado pode eliminar o produto correto antes do ranking começar.

O texto gerado pode falhar mesmo com boa seleção?

Sim. A explicação pode sobreinterpretar facts ou afirmar propriedades que o backend nunca devolveu.