Cómo depurar una recomendación incorrecta en un catálogo con IA

Cuando una recomendación falla en un catálogo con IA, la tentación más común es revisar la respuesta final y concluir que “el modelo se equivocó”.

Casi nunca es el mejor punto de partida.

El error visible suele ser el último eslabón de una cadena anterior. El producto correcto pudo desaparecer mucho antes. O el incorrecto pudo sobrevivir una etapa donde ya tendría que haber sido excluido. Si no localizamos ese primer punto de fuga, acabamos tocando prompts, embeddings o reglas a ciegas.

En resumen

Para depurar una recomendación incorrecta conviene recorrer el pipeline en orden y localizar la primera etapa defectuosa: interpretación → mercado → retrieval → filtros → ranking → selección → texto → cards. Pinecone distingue varios modos de búsqueda con señales distintas; BM25 sigue siendo la referencia clásica para matching lexical; dense retrieval y BERT reranking operan como etapas separadas; y los marcos recientes de evaluación de RAG separan retrieval y generación precisamente para diagnosticar dónde nace el error.

No empieces por la respuesta final

La última respuesta es útil para detectar que algo está mal. No siempre sirve para saber por qué.

Si el sistema recomienda un producto incorrecto, pueden haber ocurrido varias cosas distintas:

• interpretó mal la intención;
• consultó el mercado equivocado;
• no recuperó el producto correcto;
• recuperó demasiado ruido;
• filtró mal;
• rankeó mal;
• seleccionó mal entre válidos;
• redactó una explicación engañosa;
• o renderizó cards incoherentes con la decisión.

RAGVUE insiste precisamente en separar calidad de retrieval, completitud de respuesta y fidelidad a la evidencia. La taxonomía reciente de errores en RAG también subraya que muchos fallos se encadenan: un error temprano en retrieval o reranking termina manifestándose como una respuesta aparentemente mal generada.

Pipeline de depuración

La pregunta correcta no es “¿qué dijo mal el sistema?”. Es esta:

¿En qué etapa exacta dejó de estar disponible el producto correcto o en cuál sobrevivió el incorrecto?

Fallos de interpretación

La interpretación falla cuando la consulta ya sale mal traducida a una intención estructurada.

Síntomas típicos:

• la necesidad implícita se resuelve como otra familia de producto;
• una referencia exacta se trata como lenguaje natural;
• un requisito obligatorio se degrada a preferencia;
• o una consulta ambigua se responde sin pedir aclaración.

Aquí el error todavía no es de retrieval. Es de contrato. Pinecone recomienda señales exactas cuando la consulta comparte tokens específicos con los datos —por ejemplo nombres de producto, identificadores o jargon técnico— y señales semánticas cuando lo que manda es la intención en lenguaje natural. Si el sistema clasifica mal el tipo de consulta, todo lo demás hereda esa decisión equivocada.

Fallos de mercado

A veces la recomendación parece relevante, pero pertenece al mercado incorrecto.

Síntomas:

• URLs de otro país;
• precios incompatibles con el catálogo activo;
• idioma correcto pero producto de otro mercado;
• o mezcla de disponibilidad entre catálogos.

Ese tipo de error suele indicar un problema de namespace, de selector de agente o de filtros de metadatos. Pinecone documenta que los namespaces sirven para aislamiento lógico y que las consultas se dirigen a un namespace concreto. También documenta el uso de metadatos para limitar resultados a registros que cumplan la expresión de filtro.

Fallos de retrieval

Retrieval falla cuando el producto correcto debería estar entre los candidatos y no aparece.

Aquí conviene distinguir:

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

BM25 sigue siendo una base muy útil cuando importan tokens exactos, y Pinecone sigue recomendando full-text o lexical search para nombres de producto, identificadores y frases precisas. Dense retrieval, por su parte, mejora consultas donde importa la similitud conceptual más que el token exacto. En otras palabras: una mala recuperación no siempre exige mejores embeddings; a veces exige cambiar el tipo de búsqueda o la mezcla de señales.

Fallos de filtros

Si el producto correcto sí aparece entre candidatos pero luego desaparece, el primer sospechoso son los filtros.

Los filtros fallan cuando excluyen algo que debía permanecer o dejan vivo algo que debía morir.

Ejemplos:

• producto correcto eliminado por metadato ausente o mal tipado;
• exclusión por disponibilidad stale;
• compatibilidad tratada como negativa por defecto;
• o regla de canal aplicada antes de normalizar el contexto.

Pinecone documenta los filtros por metadatos como una forma explícita de limitar resultados a registros que cumplan una expresión. Eso es potente, pero también significa que un metadato mal modelado puede matar el resultado correcto muy pronto.

Fallos de ranking

Ranking falla cuando el producto correcto sigue vivo, pero demasiado abajo.

Eso ocurre cuando la señal correcta existe, pero pesa menos de lo que debería, o cuando una señal de negocio rescata demasiado a un producto mediocre.

Vale la pena recordar la arquitectura clásica de dos etapas: un primer retrieval eficiente recupera candidatos y un reranker más caro los reordena. La literatura sobre BERT reranking parte precisamente de ese patrón: primero BM25 o un mecanismo escalable, después un modelo intensivo de reranking. Si el producto correcto entra pero no sube, probablemente el problema ya no es de cobertura sino de pesos, features o reranker.

Fallos de selección

A veces varios productos válidos sobreviven y el sistema escoge mal el último subconjunto.

Ese error no es estrictamente de ranking ni de generation. Es un error de política de selección:

• mostrar almacenamiento aunque el usuario no lo pidió;
• elegir el producto más completo en datos en lugar del más ajustado;
• favorecer margen o negocio contra la intención expresa;
• o elegir demasiadas variantes redundantes.

Aquí conviene registrar no solo el score final, sino el motivo de exclusión o inclusión de cada candidato.

Fallos de texto

Puede ocurrir algo más sutil: la selección es correcta, pero el texto explicativo no lo es.

Síntomas:

• el texto atribuye propiedades no presentes en facts;
• promete compatibilidad no comprobada;
• exagera disponibilidad;
• o resume mal lo que devolvió backend.

ARES y RAGVUE ayudan precisamente a pensar esta separación entre relevancia recuperada, completitud y fidelidad. La mejor selección puede perder credibilidad si la capa textual inventa o sobreinterpreta.

Fallos de cards

La última etapa también puede romper confianza aunque la selección y el texto sean correctos.

Ejemplos:

• card de otro ID;
• imagen cruzada;
• URL ausente;
• precio stale;
• atributos inconsistentes con la explicación.

Cuando esto ocurre, el problema ya no es el modelo. Es el contrato entre backend y render.

Qué registraría para depurar bien

Si tuviera que instrumentarlo de forma mínima, guardaría una traza por consulta con esto:

• consulta original;
• intención estructurada;
• mercado y namespace;
• candidatos lexicales;
• candidatos semánticos;
• candidatos fusionados;
• exclusiones por filtro con motivo;
• ranking final con señales;
• selección final;
• texto generado;
• payload definitivo de cards.

La razón es sencilla: no se puede localizar la primera etapa defectuosa si solo se conserva la última respuesta.

La idea de fondo

Depurar un catálogo con IA no consiste en discutir si el modelo “ha entendido” o “no ha entendido”.

Consiste en localizar la primera etapa donde la arquitectura perdió control. En cuanto encuentras ese punto, el trabajo deja de ser mágico y vuelve a ser ingeniería.

Lecturas relacionadas

• Vector search en catálogo comercial: por qué lo semántico no basta
• Cómo preparar la base de conocimiento de un agente IA comercial
• Reglas de negocio en agentes IA: cuándo preguntar, filtrar o derivar
• Por qué un prompt no es una estrategia de automatización comercial

Preguntas frecuentes

¿Una recomendación incorrecta siempre implica un problema de embeddings?

No. Puede fallar antes en interpretación o mercado, o después en filtros, ranking, selección, texto o cards.

¿Cómo sé si el problema es retrieval o ranking?

Si el producto correcto no entra en candidatos, falla retrieval. Si entra pero queda demasiado abajo, falla ranking o reranking.

¿Por qué registrar el namespace y los metadatos?

Porque un error de mercado o un filtro mal aplicado puede eliminar el producto correcto antes de que llegue al ranking.

¿El texto generado puede fallar aunque la selección sea buena?

Sí. Una explicación puede sobreinterpretar facts o prometer propiedades que backend nunca devolvió.