Vector search en catálogo comercial: por qué lo semántico no basta

Porque en catálogo comercial el error caro no es “no sonar semántico”; el error caro es recomendar algo real pero incorrecto.

Esa frase resume el problema de usar IA en catálogos comerciales como si fuera solo una cuestión de búsqueda semántica.

Cuando un usuario escribe “necesito algo para contener un derrame” o “busco zapatillas para correr con lluvia”, la tentación técnica es clara: generar embeddings, hacer vector search y devolver los productos más cercanos. Eso puede mejorar mucho frente a una búsqueda por palabras exactas, pero no resuelve el problema completo.

En un catálogo comercial, una respuesta buena no es la que suena inteligente. Es la que devuelve productos reales, disponibles, adecuados, trazables y listos para mostrarse o comprarse.

En resumen

Vector search es útil para entender intención, sinónimos y necesidades expresadas en lenguaje natural. Pero en discovery comercial no debería trabajar solo. Tiene que vivir dentro de una arquitectura híbrida con búsqueda exacta, filtros de negocio, validaciones de stock y precio, control de canal, trazabilidad y evaluaciones.

El modelo puede ayudar a interpretar lo que la persona quiere. El backend debe decidir qué productos son válidos para mostrar.

El error típico: confundir similitud con recomendación

La búsqueda vectorial responde a una pregunta parecida a esta:

“¿Qué elementos del catálogo están semánticamente cerca de esta consulta?”

La recomendación comercial necesita responder otra:

“¿Qué productos reales puedo recomendar a esta persona, en este canal, con estas restricciones, sin inventar datos y sin crear riesgo comercial?”

Son problemas relacionados, pero no iguales.

Un producto puede ser semánticamente cercano y aun así ser una mala recomendación si falla alguno de estos criterios:

• Disponibilidad: está agotado.
• Categoría: pertenece a otra categoría.
• Presupuesto: supera el rango que el cliente puede asumir.
• Canal o país: no se vende en ese mercado o canal comercial.
• Compatibilidad: no encaja con el modelo, uso o contexto del cliente.
• Aplicación real: tiene una descripción parecida, pero sirve para otra necesidad.
• Datos mínimos: carece de imagen, URL, precio válido o información suficiente.
• Riesgo técnico: requiere una advertencia antes de recomendarlo.
• Segmentación: está oculto para ese segmento comercial.

Si el sistema recomienda ese producto, el problema no es de estilo. Es de confianza, conversión y responsabilidad operativa.

Por qué el catálogo no es una base documental normal

En una base de conocimiento clásica, RAG suele recuperar fragmentos de documentos para ayudar al modelo a responder mejor. En un catálogo comercial, el objetivo es más exigente: hay que devolver entidades accionables.

Un producto no es un párrafo. Es una combinación de identidad, variante, precio, stock, imagen, URL, atributos, restricciones y fuente.

Por eso un catálogo preparado para agentes necesita campos estructurados:

Campo	Por qué importa
id	Identidad estable del producto.
sku o referencia	Búsqueda exacta, trazabilidad y soporte comercial.
title y description	Comprensión humana y matching semántico.
category	Filtro de intención y navegación.
price	Recomendación accionable.
availability	Evita recomendar productos no vendibles.
image_url	Renderizado en tarjeta o carrusel.
product_url	Acción de detalle o compra.
attributes	Tallas, medidas, materiales, usos, compatibilidad y restricciones.
source	Registro de origen, fecha de sincronización y auditoría.

Los embeddings pueden representar parte de ese producto, pero no sustituyen el contrato comercial.

Qué debería hacer el LLM

El LLM no debería inventar productos, precios, imágenes, stock ni URLs. Su trabajo es interpretar intención y devolver una petición estructurada.

Por ejemplo:

{
  "catalog_discovery": {
    "action": "search_products",
    "query": "producto para contener un derrame de hidrocarburos",
    "filters": {
      "availability": "in_stock",
      "use_case": "spill_containment"
    },
    "limit": 3
  }
}

Esa salida no contiene productos. Contiene una intención.

Después el backend consulta el catálogo, aplica reglas, valida restricciones y devuelve tarjetas:

{
  "type": "product_carousel",
  "items": [
    {
      "type": "product_card",
      "id": "prod_001",
      "title": "Kit de contención para hidrocarburos",
      "price": "89,00 €",
      "availability": "Disponible",
      "image_url": "/media/catalog/prod_001.jpg",
      "product_url": "https://tienda.example/products/prod_001",
      "reason": "Encaja porque está diseñado para contener derrames de hidrocarburos y está disponible."
    }
  ]
}

La diferencia es importante: el modelo decide qué buscar; el sistema decide qué se puede mostrar.

Dónde encaja vector search

Vector search tiene mucho sentido cuando el usuario no sabe el nombre exacto del producto.

Ejemplos:

• “algo para absorber aceite en un taller”;
• “una mochila para escapadas cortas con lluvia”;
• “un producto para almacenar bidones de forma segura”;
• “zapatillas para correr con mal tiempo”;
• “una cafetera compacta con molinillo”;
• “un accesorio compatible con mi modelo antiguo”.

En esas consultas, una búsqueda literal puede fallar porque las palabras del usuario no coinciden con las del catálogo. El catálogo puede decir “absorbente de hidrocarburos”, “cubeto de retención”, “membrana impermeable”, “depósito secundario” o “integrated grinder”, mientras el usuario habla de forma normal.

Ahí los embeddings ayudan a conectar necesidad con producto.

Pero hay consultas donde la búsqueda exacta es superior:

• referencias internas;
• SKUs;
• modelos;
• medidas;
• capacidades;
• normas técnicas;
• tallas;
• marcas;
• números de parte;
• nombres de producto.

Si alguien busca “RIDGEPACK-25-BLK”, “XZ-400”, “25L”, “GTX”, “120 cm” o una referencia concreta, la búsqueda semántica no debería improvisar. El sistema necesita precisión lexical y filtros estructurados.

La arquitectura correcta: híbrida

La solución práctica no es elegir entre keyword search y vector search. Es combinarlas.

Un flujo sano para catálogo comercial sería:

1. El usuario expresa una necesidad.
2. El LLM la convierte en una intención estructurada.
3. El backend valida la capability y normaliza filtros.
4. Se aplican reglas duras: canal, disponibilidad, país, permisos, precio y categoría si corresponde.
5. La búsqueda lexical recupera coincidencias exactas.
6. La búsqueda vectorial recupera coincidencias semánticas.
7. El sistema fusiona candidatos.
8. Un ranking ordena por relevancia, ajuste de atributos, disponibilidad, precio y calidad de datos.
9. Se revalidan precio, stock, URL e imagen.
10. El frontend renderiza tarjetas, carruseles o fallback.

En pseudopipeline:

intención del usuario
  -> salida estructurada del LLM
  -> filtros duros
  -> búsqueda lexical
  -> búsqueda vectorial
  -> ranking híbrido
  -> validación comercial
  -> product cards

Ese diseño permite que el sistema entienda lenguaje natural sin perder control comercial.

Filtros duros antes que ranking

Hay reglas que no deberían depender de un score.

Si un producto no está permitido, no se rankea. Se excluye.

Ejemplos:

• tenant incorrecto;
• canal no autorizado;
• producto oculto;
• país fuera de cobertura;
• stock no disponible;
• precio inválido;
• URL ausente;
• imagen obligatoria ausente;
• compatibilidad no demostrada;
• restricción comercial incumplida.

Después de excluir lo inválido, sí tiene sentido ordenar.

Un ranking comercial puede combinar:

Señal	Qué aporta
Relevancia semántica	Encaje con la necesidad expresada.
Relevancia lexical	Coincidencia exacta con referencia, marca, modelo o atributo.
Match de atributos	Cumplimiento de requisitos pedidos.
Disponibilidad	Preferencia por productos vendibles ahora.
Precio	Ajuste al presupuesto o rango esperado.
Calidad de datos	Imagen, descripción, atributos y URL completas.
Freshness	Datos sincronizados recientemente.
Regla comercial	Prioridad de negocio cuando no contradice al usuario.

El ranking ayuda a elegir entre productos válidos. No debería rescatar productos que fallaron las reglas duras.

El enriquecimiento no es decoración

En un catálogo con IA, enriquecer productos no significa escribir descripciones más bonitas. Significa hacer que cada producto sea más recuperable, evaluable y renderizable.

Campos útiles para enriquecer:

• usos recomendados;
• problemas que resuelve;
• términos comerciales equivalentes;
• atributos normalizados;
• unidades y rangos;
• compatibilidades;
• incompatibilidades;
• restricciones de uso;
• categoría canónica;
• señales de compra;
• preguntas que ayuda a responder;
• razón de recomendación permitida;
• nivel de confianza por atributo.

Ese enriquecimiento puede alimentar embeddings, filtros, explicaciones y evaluaciones. Pero debe ser trazable: qué modelo lo generó, con qué prompt, desde qué datos de origen y en qué fecha.

Si mañana una recomendación falla, hay que poder reconstruir por qué el sistema llegó ahí.

Cómo evitar recomendaciones inventadas

La regla principal es simple:

El LLM no crea product cards.

Puede hacer:

• interpretar intención;
• pedir una búsqueda;
• sugerir filtros;
• redactar una explicación basada en datos devueltos;
• pedir aclaración si falta información.

No debería hacer:

• crear productos;
• inventar precios;
• completar stock;
• deducir compatibilidades sin fuente;
• generar URLs;
• prometer disponibilidad;
• mezclar productos de catálogos distintos.

Cuando no hay resultados, el sistema debe decirlo de forma útil:

{
  "type": "no_results",
  "message": "No encontré productos disponibles que cumplan exactamente esos criterios.",
  "suggested_next_steps": [
    "Ampliar rango de precio",
    "Ver alternativas compatibles",
    "Consultar productos similares disponibles"
  ]
}

Un buen fallback vale más que una recomendación convincente pero incorrecta.

Evals: la parte que separa demo de producto

Un catálogo con IA necesita pruebas específicas.

No basta con mirar si la respuesta “suena bien”. Hay que comprobar si el sistema devuelve productos correctos.

Métricas útiles:

Métrica	Qué mide
top_1_relevance	Si el primer producto encaja con la consulta.
top_3_recall	Si hay al menos un producto correcto entre los tres primeros.
attribute_match_rate	Si respeta atributos pedidos.
availability_accuracy	Si el stock mostrado coincide con la fuente.
price_accuracy	Si el precio coincide con el catálogo.
hallucination_rate	Si aparecen productos o campos inventados.
fallback_quality	Si responde bien cuando no hay resultados.
render_contract_validity	Si la respuesta se puede pintar como tarjeta o carrusel.

Para un MVP, 30 o 50 consultas bien diseñadas ya detectan mucho:

• búsquedas por intención;
• búsquedas por SKU;
• productos agotados;
• presupuesto máximo;
• compatibilidad;
• consultas fuera de catálogo;
• ambigüedad real;
• productos parecidos pero incorrectos.

Ahí se descubre si vector search mejora de verdad o si solo añade resultados bonitos pero peligrosos.

Cómo empezaría en un MVP

La secuencia pragmática sería:

1. Crear una base propia del catálogo con productos limpios.
2. Normalizar campos mínimos: título, descripción, categoría, precio, stock, imagen, URL y atributos.
3. Enriquecer productos con usos, atributos canónicos y términos equivalentes.
4. Implementar búsqueda lexical y filtros duros.
5. Crear evals manuales con consultas reales.
6. Añadir embeddings como señal complementaria.
7. Comparar resultados antes y después.
8. Activar ranking híbrido solo si mejora relevancia sin subir errores.

No empezaría por una base vectorial compleja. Empezaría por demostrar que el sistema recomienda productos reales sin inventar.

Después sí: embeddings, búsqueda híbrida, reranking, MCP o integración con canales externos.

La idea de fondo

Un agente comercial no necesita “sonar como vendedor”. Necesita trabajar con datos comerciales reales.

En catálogo, la IA aporta valor cuando ayuda a traducir intención humana en productos accionables. Pero esa traducción tiene que pasar por contratos, filtros, trazabilidad y evaluación.

La arquitectura correcta separa responsabilidades:

• el usuario expresa una necesidad;
• el LLM interpreta intención;
• el backend consulta y valida;
• el catálogo aporta verdad comercial;
• el frontend muestra tarjetas;
• el equipo mide errores y mejora el sistema.

Vector search es una pieza muy útil de esa arquitectura. Pero no es la arquitectura.

Porque en catálogo comercial, el objetivo no es que la respuesta parezca inteligente. Es que la recomendación sea correcta.

Lecturas relacionadas

• Preparar una base de conocimiento para un agente IA comercial
• Por qué un prompt no es una estrategia de automatización comercial
• Reglas de negocio en agentes IA: preguntar, filtrar y derivar
• Agente IA para discovery comercial: qué preguntar antes de una llamada

Preguntas frecuentes

¿Vector search sirve para buscar productos en un catálogo comercial?

Sí, pero debería complementar a la búsqueda exacta, los filtros y las reglas de negocio. Es útil para intención semántica, no para sustituir validaciones de SKU, stock, precio, compatibilidad o canal.

¿Por qué no basta con embeddings para recomendar productos?

Porque una recomendación comercial debe ser correcta, disponible, trazable y accionable. Un vector puede encontrar productos parecidos, pero no garantiza que cumplan restricciones duras como precio, disponibilidad, categoría, compatibilidad o permisos.

¿Qué arquitectura conviene para un catálogo con IA?

Una arquitectura híbrida: el modelo interpreta la intención, el backend aplica filtros duros, la búsqueda combina señales lexicales y vectoriales, y el sistema valida la respuesta antes de renderizar tarjetas de producto.

¿El LLM debería crear las tarjetas de producto?

No. El LLM puede proponer una intención de búsqueda estructurada. Las tarjetas deben salir del catálogo real, con producto, imagen, precio, stock, URL y trazabilidad generados por el backend.