← Volver a artículos
Quando l'AI aziendale non sa quello che sa Capítulo 4 de 6
AI 2026-04-16 ProtoMedia

La alucinación heredada

Traducido automáticamente del italiano · leer el original

Capítulo 4 — La alucinación heredada

Esta es quizás la historia más instructiva de toda la investigación, porque toca un tema que los tutoriales ignoran y que en cambio causa más daños que todos los demás juntos: la calidad de los datos que entran.

Una empresa estadounidense de bicicletas —llamémosla así por respeto— tenía un archivo fotográfico enorme, miles de imágenes de producto, eventos, clientes en bicicleta, viajes promocionales. Era el patrimonio visual de la empresa, acumulado en quince años de campañas. En un momento de visión de futuro, alguien había utilizado un servicio de etiquetado automático para añadir, a cada foto, una lista de "objetos presentes": "bici, casco, carretera, montaña, persona". Metadatos útiles, en teoría, para la futura búsqueda visual. Archivados junto a las fotos, olvidados durante años, luego recuperados e ingeridos en el nuevo RAG empresarial con la natural convicción de que "cuanto más metadatos, mejor".

Después de la ingestión, la búsqueda por imágenes daba resultados surrealistas. Buscabas "bici en la ciudad" y te aparecía una foto de un lago. Buscabas "modelo mujer con casco" y te aparecía un coche antiguo. Buscabas "montaña" y te aparecía, indistintamente, cualquier cosa — una muestra aleatoria de todo el archivo, como si el sistema hubiera echado a suertes. El equipo, inicialmente, señaló con el dedo al modelo de embedding visual. Luego al reranker (ver capítulo anterior, para entender por qué esta pista era particularmente seductora). Luego a la calidad de las descripciones generadas por la IA.

La investigación real, realizada esta vez con una query SQL directa a la base de datos, mostró algo grotesco. De 3997 fotos del catálogo, todas, absolutamente todas, tenían la misma lista de objetos. Una lista de diecinueve elementos — "auto, moto, lago, mar, montaña, bici, casco, carretera, ciudad, persona..." — que no tenía ninguna relación con el contenido de la foto individual. Había sido importada, años antes, de otro sitio web, como conjunto de etiquetas genéricas para rellenar un campo obligatorio del CMS. Nadie en la empresa lo recordaba ya. Las fotos habían pasado de sistema en sistema arrastrando consigo esas etiquetas fantasma, plausibles en apariencia pero lo suficientemente venenosas como para corromper cualquier búsqueda basada en ellas. El motor de búsqueda, diligente, las utilizaba como síntoma de contenido. Y devolvía cualquier foto para cualquier consulta, con un cierto grado de alucinación garantizado por ley de la naturaleza.

El quid de la cuestión, lo que duele cuando se comprende, es que en un RAG los datos "ruidosos" no hacen ruido que se escuche. No ralentizan el sistema, no generan errores, no encienden luces de advertencia. Simplemente erosionan silenciosamente la calidad de los resultados. Y cuando el modelo de lenguaje posterior recibe cinco documentos de los cuales cuatro no son relevantes, no te dice "estos no vienen al caso, pregúntame otra cosa": construye diligentemente una respuesta que los mezcla, y la respuesta siempre suena plausible. Siempre. La alucinación final — esa respuesta inventada de la que nos quejamos — no nace del modelo, como se cuenta en la narrativa dominante. Nace aguas arriba, de los datos. El modelo es solo quien la empaqueta en una frase gramaticalmente impecable. Pero la culpa está en otro lugar, más atrás, en lo que le diste de comer al sistema meses antes de pedirle algo.

Esta observación tiene consecuencias prácticas que cuestan dinero. El primer trabajo de quien construye un RAG empresarial serio, antes de escribir una línea de código, es hacer la autopsia de sus propios datos. De dónde vienen. Quién los ha tocado. Qué campos se observan y cuáles son herencias fósiles de sistemas anteriores. Qué metadatos tienen significado hoy y cuáles lo tenían en 2017 y nadie se ha molestado en limpiarlos. Es un trabajo poco glamuroso, muy archivístico, completamente ausente de los tutoriales, a menudo percibido como "no técnico" y, por lo tanto, desdeñado por los equipos de desarrollo. Pero sin esa higiene inicial, cualquier arquitectura genial que pongas aguas arriba se convierte simplemente en un amplificador muy potente de basura muy antigua.

En el caso de la empresa americana, la solución fue brutal y correcta: vaciar el campo "objetos", reconstruir los metadatos desde cero con un modelo de visión moderno aplicado a cada foto individual, y rastrear, esta vez, cuándo y cómo se produjo cada metadato. Trabajo tedioso. Resultado: la búsqueda finalmente comenzó a funcionar. No porque hubieran cambiado el modelo. Porque habían limpiado el trastero.

La lección en breve: Antes de escribir una línea de código, haz la autopsia de tus datos. Sin esa higiene inicial, cualquier arquitectura se convierte en un amplificador de basura.

¿Tienes una observación? Escríbenos

El mensaje llega solo para nosotros. Si tu comentario es interesante, podríamos publicarlo al final del artículo, pero solo tras evaluarlo.

Mientras escribes, tu navegador resuelve un pequeño cálculo: es nuestra forma de evitar el correo automático sin usar servicios externos ni pedirte que identifiques semáforos. No se te solicita nada y ningún dato sale de este sitio.