
En el artículo anterior contaba que, al probar nuestro sistema con 250 obras reales, descubrimos algo inquietante: una resolución aparentemente segura puede ser incorrecta.
Esa constatación nos llevó a tomar una decisión que quizá suene contradictoria en un proyecto tecnológico:
Preferimos no dar una respuesta antes que dar una respuesta equivocada.
Puede parecer obvio, pero en el mundo del software, especialmente cuando trabajamos con grandes volúmenes de datos, la tentación de ofrecer siempre un resultado es muy fuerte. Un sistema que dice «no lo sé» parece menos útil que uno que siempre da una respuesta, aunque sea dudosa.
Pero cuando hablamos de identificar obras musicales, una respuesta incorrecta no es simplemente un error. Es un problema que se arrastra.
Imaginemos que un sistema decide, de forma errónea, que dos obras de compositores distintos son la misma. A partir de ese momento, cualquier estadística, cualquier relación o cualquier búsqueda que dependa de esa decisión estará contaminada. El error se multiplica.
Por eso, en lugar de un simple «verdadero o falso», construimos un sistema que puede dar tres respuestas diferentes cuando compara dos representaciones de una obra:

1. SAME (misma obra)
El sistema tiene evidencia suficiente para afirmar que ambas representaciones corresponden a la misma obra musical. Esto ocurre cuando, por ejemplo:
- Coinciden el título, el compositor y el catálogo con suficiente precisión.
- Ambas representaciones comparten un identificador externo fiable (como un ID de MusicBrainz o Wikidata).
2. DIFFERENT (obras distintas)
El sistema tiene evidencia suficiente para afirmar que son obras diferentes. Por ejemplo, si los catálogos no coinciden y no hay otras señales que indiquen lo contrario.
3. POSSIBLE (posible coincidencia)
Este es el estado más interesante y, quizá, el más importante. El sistema ha encontrado indicios de que podrían ser la misma obra, pero la evidencia no es lo suficientemente sólida como para afirmarlo con seguridad.
En este caso, el sistema no decide. En lugar de eso, muestra las dos posibilidades y la evidencia que tiene, y deja que sea un revisor humano quien tome la decisión final.
¿Por qué es tan importante el estado POSSIBLE?
Porque nos obliga a ser honestos con lo que sabemos y, sobre todo, con lo que no sabemos.
Cuando trabajamos con fuentes de datos de calidad variable, es inevitable encontrarnos con ambigüedades. Un título puede estar mal escrito. Un compositor puede aparecer con un nombre corrupto por un problema de codificación. Un catálogo puede tener un número que no coincide exactamente.
Un sistema que siempre decide, incluso en estos casos, generará errores que serán muy difíciles de detectar después. Un sistema que tiene un estado intermedio y que sabe decir «aquí hay una duda», en cambio, convierte el problema en una oportunidad de mejora.
La evidencia es la clave
Para tomar estas decisiones, el sistema no se basa en una simple corazonada. Cada decisión —sea SAME, POSSIBLE o DIFFERENT— va acompañada de un rastro de evidencia.
¿Qué proveedores coincidieron?
¿Qué título encontraron?
¿Qué catálogo apareció?
¿Qué identificadores externos respaldan la decisión?
Este rastro de evidencia es lo que permite que un revisor humano pueda entender por qué el sistema ha llegado a una conclusión, o por qué no ha llegado a ninguna.
Y, como veremos en el próximo artículo, este enfoque también nos permite mejorar el sistema de forma continua: cuando un revisor corrige una decisión, esa corrección puede servir para afinar los criterios del sistema en el futuro.
Un principio que se extiende a todo el sistema
Este enfoque de «no inventar certezas» no es solo una curiosidad técnica. Es uno de los principios fundamentales de todo el proyecto. Lo aplicamos cuando:
- Identificamos a un compositor a partir de un nombre corrupto (preferimos no asignarlo si no estamos seguros).
- Relacionamos una obra con su catálogo (si hay ambigüedad, la mostramos).
- Fusionamos información de distintas fuentes (si los datos no coinciden, lo registramos como un conflicto en lugar de ocultarlo).
La idea central es siempre la misma:
La integridad del conocimiento es más importante que la apariencia de certeza.
En el próximo artículo, hablaremos de cómo conseguimos que el sistema pueda normalizar y comparar títulos, nombres y catálogos de forma fiable para tomar estas decisiones. Porque, como veremos, antes de poder decir si dos obras son la misma, hay que conseguir que el sistema «entienda» correctamente lo que está viendo.
Comparte esto:
- Comparte en Facebook (Se abre en una ventana nueva) Facebook
- Compartir en Telegram (Se abre en una ventana nueva) Telegram
- Compartir en WhatsApp (Se abre en una ventana nueva) WhatsApp
- Compartir en LinkedIn (Se abre en una ventana nueva) LinkedIn
- Compartir en X (Se abre en una ventana nueva) X
- Enviar un enlace a un amigo por correo electrónico (Se abre en una ventana nueva) Correo electrónico
- Más
Relacionado
Descubre más desde Recursos para formacion
Suscríbete y recibe las últimas entradas en tu correo electrónico.