En catàleg comercial, ensenyar un sistema “perquè ja respon” pot ser la manera més ràpida d’afeblir una conversa prometedora.

El problema no és només tècnic. És un problema de confiança. Un agent d’IA pot sonar convincent, recuperar productes propers i fins i tot mostrar targetes ben resoltes. Però si una sola consulta visible retorna un producte real i incorrecte, la reunió deixa d’avaluar l’oportunitat i passa a avaluar l’error.

Aquest és el punt de partida: una demo segura no és una producció més petita. És un estat diferent del producte.

En resum

Una demo segura d’un agent d’IA per a catàlegs necessita abast tancat, univers aprovat de productes, validació local abans del retrieval extern, filtres durs abans del rànquing, staging reversible, feature flag, comparació visible amb un baseline i criteris explícits de GO / NO-GO. La documentació actual de Pinecone cobreix cerca híbrida, filtres per metadades i aïllament per namespace; Microsoft recomana entorns de staging equivalents a producció i feature flags; i Google recomana comparar contra un baseline i mantenir judici manual fins que la pipeline sigui fiable.

Flux visual d’una demo segura: abast tancat, manifest aprovat, validació, retrieval acotat, staging i rollback
Una demo fiable avança per gates explícits. Si falla un producte, una card o el rollback, la decisió correcta és NO-GO.

L’error habitual: “es pot ensenyar” no és el mateix que “hi ha un widget a staging”

Tenir un widget a staging no vol dir tenir una demo segura.

Staging serveix per validar integracions, builds, logs, latència o un flux tècnic. Una demo comercial demana una altra cosa: cada resposta visible ha de reforçar la confiança. L’estàndard no és “funciona força bé”. L’estàndard és “no contradiu el producte que volem ensenyar”.

Per això val la pena separar estats:

  • prototype_ready
  • local_scope_ready
  • demo_scope_ready
  • staging_ready
  • production_ready

El problema apareix quan tot això es resumeix en un sol booleà.

Demo-ready no és production-ready

L’estat més útil aquí no és “ja està tot a punt”. És una formulació més honesta:

full_runtime_ready = false
demo_scope_ready = true

Aquesta separació evita dos errors cars:

  • bloquejar una demostració útil fins que el catàleg complet estigui resolt;
  • o presentar una cobertura incompleta com si fos producció.

ARES és una bona analogia perquè separa dimensions diferents d’avaluació, com la rellevància del context, la fidelitat de la resposta i la rellevància de la resposta, en lloc d’aplanar-ho tot en un únic valor opac. Un subconjunt ben aïllat i ben mesurat pot ser demostrable abans que el sistema complet.

L’abast del pilot s’ha de definir per pertinença, no per paraules màgiques

Si el pilot depèn de detectar expressions com “oli”, “emmagatzematge” o “seguretat”, l’abast continuarà sent difús.

Una demo seriosa necessita una altra unitat de control:

  • famílies canòniques;
  • IDs aprovats;
  • restriccions explícites;
  • facts mínims obligatoris;
  • cards vàlides;
  • hash o versió del manifest;
  • i comportament no_results fora d’abast.

Això importa perquè el retrieval semàntic és útil per trobar candidats, però no hauria de tenir autoritat comercial final. Pinecone documenta la combinació de senyals semàntics i lèxics, l’ús de metadades per restringir resultats i l’aïllament per namespace. Aquesta lògica encaixa molt millor amb un manifest explícit que amb instruccions toves amagades al prompt.

Conjunt acotat de productes aprovats dins d’un manifest de demo, amb la resta del catàleg exclosa.
L’abast segur es defineix per pertinença explícita: els productes aprovats queden dins; qualsevol altre candidat s’exclou abans del rànquing.

Separar mercat, coneixement i idioma

Un error freqüent en catàlegs multilingües és confondre idioma de la pregunta amb mercat de les dades.

Un contracte més net seria aquest:

catalog_market = ES
knowledge_source_locale = es
response_language = dynamic

Això permet una cosa comercialment molt potent: la necessitat pot arribar en anglès, francès o portuguès, mentre que productes, preus, disponibilitat i URLs continuen pertanyent al mateix mercat aprovat. Pinecone documenta que lectures i escriptures sempre apunten a un namespace concret i que els namespaces serveixen per a aïllament lògic i multitenancy. La mateixa idea serveix per aïllar mercats.

Validar primer el selector local

Abans de connectar un retriever semàntic extern, convé demostrar que el sistema ja sap escollir correctament dins d’un univers local conegut.

Això separa dues famílies d’error:

problema d’elegibilitat o selecció
≠
problema de retrieval

Sense aquesta separació, qualsevol recomanació dolenta es pot atribuir a embeddings, índex, rànquing, prompt, filtres o UI. I el debug perd el primer sospitós.

Retrieval proposa; el backend decideix

En un agent de catàleg, retrieval no hauria de tenir l’autoritat comercial final.

Pinecone distingeix clarament full-text search, cerca semàntica densa, sparse lexical i cerca híbrida. També recomana senyals exactes o basades en tokens quan la consulta comparteix identificadors, noms de producte o jerga tècnica amb les dades. És a dir: la cerca pot proposar candidats; la decisió final sobre què es pot mostrar ha de continuar al backend, amb les regles de mercat, stock, qualitat de dades i permisos.

El gate real de la demo

Una demo es guanya abans d’obrir el navegador.

El meu checklist mínim seria:

  • el manifest exacte està aprovat;
  • tots els productes en abast tenen card vàlida;
  • cap ID inesperat sobreviu a la pipeline;
  • el mercat es manté estable en totes les variants d’idioma;
  • fora d’abast retorna no_results;
  • no hi ha fallback silenciós;
  • hi ha comparació visible amb el baseline;
  • rollback i health checks estan provats;
  • i una contradicció entre text i cards bloqueja la demo.

Google recomana comparar el canary amb un baseline equivalent, i no pas amb producció directa, i mantenir una etapa de judici manual fins a confiar en la pipeline. Microsoft recomana feature flags i entorns de staging que repliquin producció. Tot això encaixa molt bé amb una demo de catàleg que encara no s’ha de tractar com un rollout general.

Promoure a staging també forma part del producte

No n’hi ha prou amb “fer deploy”.

Una demo segura necessita:

  • commit identificable;
  • flag explícita;
  • smoke tests;
  • health checks;
  • shadow traffic o trànsit molt limitat;
  • i rollback real.

Microsoft documenta shadow traffic com una manera de validar comportament sota càrrega real sense exposar noves respostes a l’usuari final, i recomana feature flags com a capa de seguretat entre deployment i release. Azure també documenta revisions múltiples, labels estables, partició de trànsit i retorn a revisions anteriors.

Entorn de staging amb feature flag, comparació contra baseline, health checks i rollback disponible.
Desplegar no equival a alliberar: staging, flags, health checks i rollback mantenen la demo reversible.

La idea de fons

Una demo segura no promet cobertura total. Promet una cosa més valuosa: que el sistema no fingirà capacitats que encara no controla.

En catàleg comercial, això importa molt. Perquè l’error car no és “semblar menys intel·ligent”. L’error car és recomanar una cosa real però incorrecta davant de qui decideix si confia o no en el producte.

Lectures relacionades

Preguntes freqüents

Una demo segura exigeix que tot el catàleg estigui complet?
No. Exigeix que el subconjunt que s’ensenya estigui aprovat, sigui reproduïble i tingui validació suficient.
Per què staging no és suficient?
Perquè staging valida integració i entorn. Una demo comercial també necessita coherència visible, límits clars i reversibilitat.
La cerca semàntica pot decidir quins productes mostrar?
No hauria. Retrieval pot proposar candidats; l’autoritat final ha de continuar al backend i a les regles de negoci.
Què bloqueja una demo encara que la resta sembli correcta?
Una sola contradicció entre resposta i card, un fallback silenciós o un rollback no provat.

Tornar a l’arxiu