Quan una recomanació falla en un catàleg amb IA, la temptació més habitual és mirar la resposta final i concloure que “el model s’ha equivocat”.
Gairebé mai és el millor punt de partida.
L’error visible acostuma a ser l’últim esglaó d’una cadena anterior. El producte correcte pot haver desaparegut molt abans. O l’incorrecte pot haver sobreviscut una etapa on ja hauria d’haver estat exclòs. Si no localitzem aquesta primera fuga, acabem tocant prompts, embeddings o regles a cegues.
En resum
Per depurar una recomanació incorrecta convé recórrer la pipeline en ordre i localitzar la primera etapa defectuosa: interpretació → mercat → retrieval → filtres → rànquing → selecció → text → cards. Pinecone distingeix modes de cerca diferents amb senyals diferents; BM25 continua sent una base clàssica per al matching lèxic; dense retrieval i BERT reranking funcionen com a etapes separades; i els frameworks recents d’avaluació de RAG separen retrieval i generació precisament per diagnosticar on comença l’error.
No comencis per la resposta final
La resposta final ajuda a detectar que alguna cosa està malament. No sempre ajuda a saber per què.
Si el sistema recomana un producte incorrecte, poden haver passat diverses coses:
- ha interpretat malament la intenció;
- ha consultat el mercat equivocat;
- no ha recuperat el producte correcte;
- ha recuperat massa soroll;
- ha filtrat malament;
- ha ordenat malament;
- ha seleccionat malament entre els vàlids;
- ha redactat una explicació enganyosa;
- o ha renderitzat cards incoherents amb la decisió.
RAGVUE insisteix a separar qualitat de retrieval, completesa de resposta i fidelitat a l’evidència. La taxonomia recent d’errors en RAG apunta en la mateixa direcció: molts errors primerencs de retrieval o reranking acaben apareixent com si fossin fallades de generation.
Pipeline de depuració
La pregunta correcta no és “què ha dit malament el sistema?”. És aquesta:
En quina etapa exacta el producte correcte ha deixat d’estar disponible, o en quina etapa ha sobreviscut l’incorrecte?
Fallades d’interpretació
La interpretació falla quan la consulta ja surt mal convertida en una intenció estructurada.
Símptomes típics:
- una necessitat implícita es resol com una altra família de producte;
- una referència exacta es tracta com llenguatge natural;
- un requisit obligatori es degrada a preferència;
- o una consulta ambigua es respon sense demanar aclariment.
Aquí el problema encara no és retrieval. És de contracte. Pinecone recomana senyals exactes quan la consulta comparteix tokens específics amb les dades —com noms de producte, identificadors o jerga tècnica— i senyals semàntics quan domina el significat en llenguatge natural. Si el sistema classifica malament el tipus de consulta, tota la resta hereta aquella decisió.
Fallades de mercat
De vegades la recomanació sembla rellevant, però pertany al mercat equivocat.
Símptomes:
- URL d’un altre país;
- preus incompatibles amb el catàleg actiu;
- idioma correcte però mercat incorrecte;
- o barreja de disponibilitat entre catàlegs.
Això acostuma a apuntar a un problema de namespace, selecció d’agent o filtres per metadades. Pinecone documenta els namespaces com la unitat a la qual s’adrecen les consultes, i els filtres per metadades com el mecanisme per limitar resultats a registres que compleixen l’expressió.
Fallades de retrieval
Retrieval falla quan el producte correcte hauria d’estar entre els candidats i no hi apareix.
Aquí convé distingir:
- exact match;
- sparse lexical;
- dense semantic;
- híbrid.
BM25 continua sent molt útil quan importen tokens exactes, i Pinecone continua recomanant full-text o lexical search per a noms de producte, identificadors i frases precises. Dense retrieval, en canvi, ajuda quan importa més la similitud conceptual que no pas la paraula exacta. Per tant, una fallada de retrieval no implica necessàriament “més bons embeddings”; de vegades implica un altre mode de cerca o una altra combinació de senyals.
Fallades de filtres
Si el producte correcte apareix entre candidats però després desapareix, el primer sospitós són els filtres.
Els filtres fallen quan eliminen alguna cosa que hauria de continuar o deixen viu alguna cosa que hauria de morir.
Exemples:
- producte correcte eliminat per metadada absent o mal tipada;
- exclusió per disponibilitat stale;
- compatibilitat tractada com a negativa per defecte;
- o regla de canal aplicada abans de normalitzar el context.
Pinecone documenta els filtres per metadades com una manera explícita de restringir resultats. Això és potent, però també significa que un camp mal modelat pot matar el resultat correcte molt aviat.
Fallades de rànquing
El rànquing falla quan el producte correcte continua viu, però massa avall.
Això passa quan el senyal correcte existeix però pesa massa poc, o quan una preferència de negoci rescata massa un producte mediocre.
Val la pena recordar l’arquitectura clàssica en dues etapes: un primer retrieval eficient recupera candidats i un reranker més costós els reordena. La literatura sobre BERT reranking parteix exactament d’aquest patró: primer BM25 o un altre mecanisme escalable, després un model intensiu de reranking. Si el producte correcte entra però no puja, el problema ja no és de cobertura. És de pesos, features o reranker.
Fallades de selecció
De vegades sobreviuen diversos productes vàlids i el sistema escull malament el subconjunt final.
Aquest error no és estrictament de rànquing ni encara de generació. És un error de política de selecció:
- mostrar emmagatzematge quan l’usuari no ho ha demanat;
- triar l’ítem més complet en dades en lloc del més adequat;
- afavorir negoci contra la intenció explícita;
- o retornar massa variants redundants.
Aquí convé registrar no només l’score final, sinó també el motiu d’inclusió o exclusió de cada candidat.
Fallades de text
També pot passar una cosa més subtil: la selecció és correcta, però el text explicatiu no.
Símptomes:
- el text atribueix propietats absents als facts;
- promet compatibilitat no demostrada;
- exagera disponibilitat;
- o resumeix malament el que ha tornat el backend.
ARES i RAGVUE són útils exactament per pensar aquesta separació entre rellevància recuperada, completesa i fidelitat. Una bona selecció pot perdre credibilitat si la capa textual improvisa.
Fallades de cards
L’última etapa també pot trencar la confiança encara que la selecció i el text siguin correctes.
Exemples:
- card d’un altre ID;
- imatge creuada;
- URL absent;
- preu stale;
- atributs incoherents amb l’explicació.
Quan això passa, el problema ja no és el model. És el contracte entre backend i render.
Què registraria
Si hagués d’instrumentar la pipeline de manera mínima, guardaria una traça per consulta amb:
- consulta original;
- intenció estructurada;
- mercat i namespace;
- candidats lèxics;
- candidats semàntics;
- candidats fusionats;
- exclusions per filtre amb motiu;
- senyals de rànquing;
- selecció final;
- text generat;
- payload final de cards.
La raó és pràctica: no es pot localitzar la primera etapa defectuosa si només es conserva l’última resposta.
La idea de fons
Depurar un catàleg amb IA no consisteix a discutir si el model “ha entès” o “no ha entès”.
Consisteix a localitzar la primera etapa on l’arquitectura ha perdut control. Quan aquest punt queda clar, la feina deixa de semblar màgia i torna a ser enginyeria.
Lectures relacionades
- Vector search en catàleg comercial: per què no n’hi ha prou amb la semàntica
- Com preparar la base de coneixement d’un agent IA comercial
- Regles de negoci en agents IA: quan preguntar, filtrar o derivar
- Per què un prompt no és una estratègia d’automatització comercial
Preguntes freqüents
- Una recomanació incorrecta implica sempre un problema d’embeddings?
- No. La fallada pot aparèixer abans, a la interpretació o al mercat, o més tard, als filtres, al rànquing, a la selecció, al text o a les cards.
- Com sé si el problema és retrieval o rànquing?
- Si el producte correcte no entra als candidats, falla retrieval. Si entra però queda massa avall, falla el rànquing o el reranking.
- Per què cal registrar namespace i metadades?
- Perquè un error de mercat o un filtre mal aplicat pot eliminar el producte correcte abans que comenci el rànquing.
- El text generat pot fallar encara que la selecció sigui bona?
- Sí. L’explicació pot sobreinterpretar facts o atribuir propietats que el backend mai no ha retornat.