Vector search en catàleg comercial: per què no n'hi ha prou amb la semàntica

Perquè en catàleg comercial l’error car no és “no sonar semàntic”; l’error car és recomanar un producte real però incorrecte.

Aquesta frase resumeix el problema d’usar IA en catàlegs comercials com si fos només una qüestió de cerca semàntica.

Quan un usuari escriu “necessito alguna cosa per contenir un vessament” o “busco sabatilles per córrer amb pluja”, la temptació tècnica és clara: generar embeddings, fer vector search i retornar els productes més propers. Això pot millorar molt respecte a una cerca per paraules exactes, però no resol el problema complet.

En un catàleg comercial, una bona resposta no és la que sona intel·ligent. És la que retorna productes reals, disponibles, adequats, traçables i llestos per mostrar-se o comprar-se.

En resum

Vector search és útil per entendre intenció, sinònims i necessitats expressades en llenguatge natural. Però en discovery comercial no hauria de treballar sol. Ha de viure dins d’una arquitectura híbrida amb cerca exacta, filtres de negoci, validacions de stock i preu, control de canal, traçabilitat i avaluacions.

El model pot ajudar a interpretar el que la persona vol. El backend ha de decidir quins productes són vàlids per mostrar.

L’error típic: confondre similitud amb recomanació

La cerca vectorial respon una pregunta semblant a aquesta:

“Quins elements del catàleg són semànticament a prop d’aquesta consulta?”

La recomanació comercial necessita respondre’n una altra:

“Quins productes reals puc recomanar a aquesta persona, en aquest canal, amb aquestes restriccions, sense inventar dades i sense crear risc comercial?”

Són problemes relacionats, però no iguals.

Un producte pot ser semànticament proper i, tot i així, ser una mala recomanació si falla algun d’aquests criteris:

• Disponibilitat: està esgotat.
• Categoria: pertany a una altra categoria.
• Pressupost: supera el rang que el client pot assumir.
• Canal o país: no es ven en aquell mercat o canal comercial.
• Compatibilitat: no encaixa amb el model, ús o context del client.
• Aplicació real: té una descripció semblant, però serveix per a una altra necessitat.
• Dades mínimes: no té imatge, URL, preu vàlid o informació suficient.
• Risc tècnic: requereix una advertència abans de recomanar-lo.
• Segmentació: està ocult per a aquell segment comercial.

Si el sistema recomana aquest producte, el problema no és d’estil. És de confiança, conversió i responsabilitat operativa.

Per què el catàleg no és una base documental normal

En una base de coneixement clàssica, RAG sol recuperar fragments de documents per ajudar el model a respondre millor. En un catàleg comercial, l’objectiu és més exigent: cal retornar entitats accionables.

Un producte no és un paràgraf. És una combinació d’identitat, variant, preu, stock, imatge, URL, atributs, restriccions i font.

Per això un catàleg preparat per a agents necessita camps estructurats:

Camp	Per què importa
id	Identitat estable del producte.
sku o referència	Cerca exacta, traçabilitat i suport comercial.
title i description	Comprensió humana i matching semàntic.
category	Filtre d’intenció i navegació.
price	Recomanació accionable.
availability	Evita recomanar productes no vendibles.
image_url	Renderització en targeta o carrusel.
product_url	Acció de detall o compra.
attributes	Talles, mesures, materials, usos, compatibilitat i restriccions.
source	Registre d’origen, data de sincronització i auditoria.

Els embeddings poden representar part d’aquest producte, però no substitueixen el contracte comercial.

Què hauria de fer l’LLM

L’LLM no hauria d’inventar productes, preus, imatges, stock ni URLs. La seva feina és interpretar intenció i retornar una petició estructurada.

Per exemple:

{
  "catalog_discovery": {
    "action": "search_products",
    "query": "producte per contenir un vessament d'hidrocarburs",
    "filters": {
      "availability": "in_stock",
      "use_case": "spill_containment"
    },
    "limit": 3
  }
}

Aquesta sortida no conté productes. Conté una intenció.

Després el backend consulta el catàleg, aplica regles, valida restriccions i retorna targetes:

{
  "type": "product_carousel",
  "items": [
    {
      "type": "product_card",
      "id": "prod_001",
      "title": "Kit de contenció per a hidrocarburs",
      "price": "89,00 €",
      "availability": "Disponible",
      "image_url": "/media/catalog/prod_001.jpg",
      "product_url": "https://tienda.example/products/prod_001",
      "reason": "Encaixa perquè està dissenyat per contenir vessaments d'hidrocarburs i està disponible."
    }
  ]
}

La diferència és important: el model decideix què buscar; el sistema decideix què es pot mostrar.

On encaixa vector search

Vector search té molt sentit quan l’usuari no sap el nom exacte del producte.

Exemples:

• “alguna cosa per absorbir oli en un taller”;
• “una motxilla per a escapades curtes amb pluja”;
• “un producte per emmagatzemar bidons de forma segura”;
• “sabatilles per córrer amb mal temps”;
• “una cafetera compacta amb molinet”;
• “un accessori compatible amb el meu model antic”.

En aquestes consultes, una cerca literal pot fallar perquè les paraules de l’usuari no coincideixen amb les del catàleg. El catàleg pot dir “absorbent d’hidrocarburs”, “cubeta de retenció”, “membrana impermeable”, “dipòsit secundari” o “integrated grinder”, mentre l’usuari parla de manera normal.

Aquí els embeddings ajuden a connectar necessitat amb producte.

Però hi ha consultes on la cerca exacta és superior:

• referències internes;
• SKUs;
• models;
• mesures;
• capacitats;
• normes tècniques;
• talles;
• marques;
• números de part;
• noms de producte.

Si algú busca “RIDGEPACK-25-BLK”, “XZ-400”, “25L”, “GTX”, “120 cm” o una referència concreta, la cerca semàntica no hauria d’improvisar. El sistema necessita precisió lèxica i filtres estructurats.

L’arquitectura correcta: híbrida

La solució pràctica no és triar entre keyword search i vector search. És combinar-les.

Un flux sa per a catàleg comercial seria:

1. L’usuari expressa una necessitat.
2. L’LLM la converteix en una intenció estructurada.
3. El backend valida la capability i normalitza filtres.
4. S’apliquen regles dures: canal, disponibilitat, país, permisos, preu i categoria si correspon.
5. La cerca lèxica recupera coincidències exactes.
6. La cerca vectorial recupera coincidències semàntiques.
7. El sistema fusiona candidats.
8. Un ranking ordena per rellevància, ajust d’atributs, disponibilitat, preu i qualitat de dades.
9. Es revaliden preu, stock, URL i imatge.
10. El frontend renderitza targetes, carrusels o fallback.

En pseudopipeline:

intenció de l'usuari
  -> sortida estructurada de l'LLM
  -> filtres durs
  -> cerca lèxica
  -> cerca vectorial
  -> ranking híbrid
  -> validació comercial
  -> product cards

Aquest disseny permet que el sistema entengui llenguatge natural sense perdre control comercial.

Filtres durs abans que ranking

Hi ha regles que no haurien de dependre d’un score.

Si un producte no està permès, no entra al ranking. S’exclou.

Exemples:

• tenant incorrecte;
• canal no autoritzat;
• producte ocult;
• país fora de cobertura;
• stock no disponible;
• preu invàlid;
• URL absent;
• imatge obligatòria absent;
• compatibilitat no demostrada;
• restricció comercial incomplerta.

Després d’excloure allò que no és vàlid, sí que té sentit ordenar.

Un ranking comercial pot combinar:

Senyal	Què aporta
Rellevància semàntica	Encaix amb la necessitat expressada.
Rellevància lèxica	Coincidència exacta amb referència, marca, model o atribut.
Match d’atributs	Compliment dels requisits demanats.
Disponibilitat	Preferència per productes vendibles ara.
Preu	Ajust al pressupost o rang esperat.
Qualitat de dades	Imatge, descripció, atributs i URL completes.
Freshness	Dades sincronitzades recentment.
Regla comercial	Prioritat de negoci quan no contradiu l’usuari.

El ranking ajuda a triar entre productes vàlids. No hauria de rescatar productes que han fallat les regles dures.

L’enriquiment no és decoració

En un catàleg amb IA, enriquir productes no significa escriure descripcions més boniques. Significa fer que cada producte sigui més recuperable, avaluable i renderitzable.

Camps útils per enriquir:

• usos recomanats;
• problemes que resol;
• termes comercials equivalents;
• atributs normalitzats;
• unitats i rangs;
• compatibilitats;
• incompatibilitats;
• restriccions d’ús;
• categoria canònica;
• senyals de compra;
• preguntes que ajuda a respondre;
• raó de recomanació permesa;
• nivell de confiança per atribut.

Aquest enriquiment pot alimentar embeddings, filtres, explicacions i avaluacions. Però ha de ser traçable: quin model l’ha generat, amb quin prompt, des de quines dades d’origen i en quina data.

Si demà una recomanació falla, cal poder reconstruir per què el sistema ha arribat fins allà.

Com evitar recomanacions inventades

La regla principal és simple:

L’LLM no crea product cards.

Pot fer:

• interpretar intenció;
• demanar una cerca;
• suggerir filtres;
• redactar una explicació basada en dades retornades;
• demanar aclariment si falta informació.

No hauria de fer:

• crear productes;
• inventar preus;
• completar stock;
• deduir compatibilitats sense font;
• generar URLs;
• prometre disponibilitat;
• barrejar productes de catàlegs diferents.

Quan no hi ha resultats, el sistema ha de dir-ho de forma útil:

{
  "type": "no_results",
  "message": "No he trobat productes disponibles que compleixin exactament aquests criteris.",
  "suggested_next_steps": [
    "Ampliar rang de preu",
    "Veure alternatives compatibles",
    "Consultar productes similars disponibles"
  ]
}

Un bon fallback val més que una recomanació convincent però incorrecta.

Evals: la part que separa demo de producte

Un catàleg amb IA necessita proves específiques.

No n’hi ha prou amb mirar si la resposta “sona bé”. Cal comprovar si el sistema retorna productes correctes.

Mètriques útils:

Mètrica	Què mesura
top_1_relevance	Si el primer producte encaixa amb la consulta.
top_3_recall	Si hi ha almenys un producte correcte entre els tres primers.
attribute_match_rate	Si respecta atributs demanats.
availability_accuracy	Si el stock mostrat coincideix amb la font.
price_accuracy	Si el preu coincideix amb el catàleg.
hallucination_rate	Si apareixen productes o camps inventats.
fallback_quality	Si respon bé quan no hi ha resultats.
render_contract_validity	Si la resposta es pot pintar com a targeta o carrusel.

Per a un MVP, 30 o 50 consultes ben dissenyades ja detecten molt:

• cerques per intenció;
• cerques per SKU;
• productes esgotats;
• pressupost màxim;
• compatibilitat;
• consultes fora de catàleg;
• ambigüitat real;
• productes semblants però incorrectes.

Aquí es descobreix si vector search millora de veritat o si només afegeix resultats bonics però perillosos.

Com començaria en un MVP

La seqüència pragmàtica seria:

1. Crear una base pròpia del catàleg amb productes nets.
2. Normalitzar camps mínims: títol, descripció, categoria, preu, stock, imatge, URL i atributs.
3. Enriquir productes amb usos, atributs canònics i termes equivalents.
4. Implementar cerca lèxica i filtres durs.
5. Crear evals manuals amb consultes reals.
6. Afegir embeddings com a senyal complementari.
7. Comparar resultats abans i després.
8. Activar ranking híbrid només si millora rellevància sense pujar errors.

No començaria per una base vectorial complexa. Començaria per demostrar que el sistema recomana productes reals sense inventar.

Després sí: embeddings, cerca híbrida, reranking, MCP o integració amb canals externs.

La idea de fons

Un agent comercial no necessita “sonar com a venedor”. Necessita treballar amb dades comercials reals.

En catàleg, la IA aporta valor quan ajuda a traduir intenció humana en productes accionables. Però aquesta traducció ha de passar per contractes, filtres, traçabilitat i avaluació.

L’arquitectura correcta separa responsabilitats:

• l’usuari expressa una necessitat;
• l’LLM interpreta intenció;
• el backend consulta i valida;
• el catàleg aporta veritat comercial;
• el frontend mostra targetes;
• l’equip mesura errors i millora el sistema.

Vector search és una peça molt útil d’aquesta arquitectura. Però no és l’arquitectura.

Perquè en catàleg comercial, l’objectiu no és que la resposta sembli intel·ligent. És que la recomanació sigui correcta.

Lectures relacionades

• Preparar una base de coneixement per a un agent IA comercial
• Per què un prompt no és una estratègia d’automatització comercial
• Regles de negoci en agents IA: preguntar, filtrar i derivar
• Agent IA per a discovery comercial: què preguntar abans d’una trucada

Preguntes freqüents

Vector search serveix per buscar productes en un catàleg comercial?

Sí, però hauria de complementar la cerca exacta, els filtres i les regles de negoci. És útil per a intenció semàntica, no per substituir validacions de SKU, stock, preu, compatibilitat o canal.

Per què no n'hi ha prou amb embeddings per recomanar productes?

Perquè una recomanació comercial ha de ser correcta, disponible, traçable i accionable. Un vector pot trobar productes semblants, però no garanteix que compleixin restriccions dures com preu, disponibilitat, categoria, compatibilitat o permisos.

Quina arquitectura convé per a un catàleg amb IA?

Una arquitectura híbrida: el model interpreta la intenció, el backend aplica filtres durs, la cerca combina senyals lèxics i vectorials, i el sistema valida la resposta abans de renderitzar targetes de producte.

L'LLM hauria de crear les targetes de producte?

No. L'LLM pot proposar una intenció de cerca estructurada. Les targetes han de sortir del catàleg real, amb producte, imatge, preu, stock, URL i traçabilitat generats pel backend.