Cómo evaluar si Lyria 3.5 sigue instrucciones musicales

Qué puede decir una evaluación publicada

Evaluar un generador musical exige distinguir dos preguntas que suelen mezclarse: ¿el audio resulta agradable o convincente?, y ¿la canción cumple lo que se pidió? Una respuesta afirmativa a la primera no demuestra la segunda. Una producción puede sonar pulida y, aun así, omitir el puente solicitado, cambiar de instrumento a mitad de una sección o ignorar una restricción de letra. También puede cumplir varios requisitos sin ser preferida por quienes la escuchan.

La ficha oficial de Lyria 3.5 es el punto de partida para entender qué evaluaciones declara el proveedor. Según la descripción disponible, incluye evaluaciones humanas y automáticas, pruebas dentro y fuera de distribución, y aspectos relacionados con la adherencia al prompt y las limitaciones del modelo. Eso ayuda a formular preguntas sobre qué se midió, pero no basta por sí solo para reconstruir un experimento: hay que consultar el detalle vigente de los procedimientos, las instrucciones de evaluación, el tamaño y la composición de las muestras, y las condiciones de generación.

El anuncio de Google sobre Lyria 3.5 también describe cambios declarados en musicalidad, letra, voces, adherencia y control de tempo y duración. Son afirmaciones del proveedor sobre el sistema; no equivalen a una medición independiente ni permiten inferir que cada instrucción específica se obedezca con una tasa determinada. Para interpretarlas, se necesita saber cómo se operacionalizó cada capacidad y si los resultados corresponden al canal y a la versión que se quieren usar.

La recomendación BS.1534 de la UIT puede orientar el diseño de evaluaciones subjetivas de audio, pero su propósito no es medir directamente si un modelo obedeció un prompt musical. Del mismo modo, trabajos como MusicEval y MusicGen ofrecen precedentes útiles para pensar en valoraciones humanas, calidad y alineación. No son evidencia directa del desempeño de Lyria 3.5. El protocolo de este artículo es una propuesta metodológica: no atribuye resultados a Lyria que las fuentes disponibles no documentan.

Definir la unidad de prueba antes de generar

La unidad básica no debería ser «una canción buena» ni «un prompt», considerados de forma vaga. Conviene registrar una instrucción, una generación obtenida bajo una condición concreta y una lista explícita de requisitos evaluables. Si se producen varias generaciones con la misma instrucción, cada audio es una observación distinta; el conjunto permite estudiar la variabilidad, pero no debe convertirse en una selección de los mejores ejemplos.

Para que el seguimiento sea verificable, hay que traducir expresiones generales en criterios observables. «Que suene cinematográfica» puede conservarse como una valoración subjetiva, pero no es una prueba binaria sin una definición acordada. En cambio, «incluir un puente instrumental entre el segundo estribillo y el final» permite evaluar presencia y ubicación, siempre que el audio tenga una estructura identificable. Aun así, si la estructura es ambigua, los evaluadores deben poder marcar «no determinable» en vez de forzar una decisión.

Cada registro debe identificar el nombre y versión exactos del modelo, el canal de acceso, la fecha de ejecución, el prompt textual y la configuración disponible. Si el canal permite fijar o registrar parámetros que alteran la generación, deben conservarse. La documentación de Google AI para desarrolladores identifica el modelo estable como `lyria-3.5`; ese identificador sirve como ejemplo de la información que se debe registrar, no como garantía de que todos los canales expongan controles idénticos.

También se debe fijar de antemano qué se considera cumplimiento parcial. Si se pide un instrumento «durante toda la canción», que aparezca brevemente no debería anotarse como cumplimiento completo. Para requisitos de estructura, es útil distinguir presencia de una sección, orden de las secciones y continuidad entre ellas. De otro modo, dos evaluadores pueden dar la misma etiqueta global por razones completamente distintas.

Diseñar prompts simples, compuestos y en conflicto

Las pruebas simples permiten averiguar si un atributo aislado puede evaluarse de manera consistente. Por ejemplo: pedir una pieza instrumental con percusión ligera, o una canción con voz principal y un ambiente sereno. Estos prompts no demuestran control general; sólo prueban una condición concreta. Para evitar que una respuesta favorable se deba a interpretaciones demasiado amplias, la instrucción debe especificar lo necesario y no añadir adjetivos que no se van a puntuar.

Los prompts compuestos prueban si varios requisitos pueden coexistir. Una instrucción podría solicitar una canción con verso, estribillo y puente; una línea de bajo presente en las tres secciones; tempo moderado; y una letra que no mencione marcas. Cada elemento se califica de forma independiente. Así se puede observar si el modelo satisface la estructura pero falla en la restricción lírica, en lugar de asignar una impresión general como «bastante fiel».

Los casos fuera de distribución deben definirse de manera operativa: instrucciones menos comunes, combinaciones inusuales o formas de especificar un atributo que no aparezcan en el conjunto principal. No hay que llamarlos pruebas «de generalización» sin describir qué los diferencia. Deben presentarse aparte y analizarse como un conjunto de estrés; no mezclarse con la prueba ordinaria para elevar o reducir una cifra sin contexto.

Las instrucciones en conflicto también merecen una categoría propia. Por ejemplo, pedir simultáneamente una canción «sin voces» y una letra cantada plantea requisitos incompatibles. El resultado no debe puntuarse como si existiera una única respuesta correcta. La evaluación puede preguntar si el sistema identifica el conflicto, satisface una instrucción sobre la otra o produce una salida ambigua, pero la regla de puntuación debe anunciarse antes de escuchar. Sin una regla previa, el evaluador puede adaptar el criterio después de ver el resultado.

Separar las dimensiones en los resultados

Un informe útil conserva al menos cuatro familias de resultados. La primera es el seguimiento de instrucciones: si cada requisito aparece, en qué grado y con qué evidencia. La segunda es la calidad musical percibida, que puede incluir valoraciones de coherencia, composición o agrado, siempre que se definan como juicios subjetivos y no como comprobaciones del prompt. La tercera es la calidad técnica del audio, por ejemplo, si se oyen cortes o distorsión. La cuarta es la calidad vocal cuando hay voces: inteligibilidad, estabilidad y adecuación percibida son preguntas diferentes de si se incluyó una voz cuando se pidió.

No conviene reducir esas familias a una sola nota. Una media agregada puede ocultar el caso importante en el que una canción recibe valoraciones altas de agrado, pero incumple la mitad de los requisitos estructurales. También puede ocultar que dos audios con el mismo resultado global fallan en atributos distintos. Presentar distribuciones y resultados por requisito facilita detectar esos patrones sin sugerir que una dimensión compensa automáticamente a otra.

La escucha ciega reduce algunos sesgos: quienes puntúan no deberían conocer qué prompt produjo cada audio, qué generación es la preferida por el equipo ni qué hipótesis se está poniendo a prueba. El orden de escucha debe variar, y las instrucciones de calificación deben permanecer iguales. Si los evaluadores ven la letra o el prompt, la prueba deja de ser ciega respecto a esa información; cuando esa información sea necesaria para puntuar, conviene describir con precisión qué se ocultó y qué no.

Una rúbrica necesita anclajes concretos. Para presencia de un instrumento, podría diferenciar «ausente», «detectable sólo de forma breve», «presente en parte de la canción» y «presente en las secciones especificadas». Para estructura, podría registrar cada sección y su orden, además de una opción de indeterminación. Los anclajes son una propuesta que debe probarse con evaluadores; no son una escala universal validada para toda música.

Rúbrica humana y desacuerdo entre evaluadores

Una escucha ciega no garantiza por sí misma una evaluación fiable. Antes de la prueba principal, conviene hacer una calibración con ejemplos de práctica y revisar si las definiciones se interpretan de manera parecida. Esa fase sirve para descubrir ambigüedades —por ejemplo, qué cuenta como «instrumento continuo»—, no para eliminar diferencias legítimas de gusto musical. Los criterios de cumplimiento deben referirse a evidencia observable, no a si el evaluador disfruta de la canción.

Cada atributo se evalúa de manera independiente por más de una persona, y se conserva la calificación individual. El informe debe mostrar acuerdo o desacuerdo por dimensión, no sólo una cifra general. Puede informar proporciones de coincidencia y una medida de concordancia apropiada al tipo de escala, explicando su definición. Si el tamaño del conjunto es pequeño o algunas categorías aparecen muy pocas veces, esa limitación también debe comunicarse en vez de presentar estimaciones con una precisión aparente.

Los desacuerdos son información metodológica. Si una parte de los oyentes detecta el puente y otra no, tal vez el audio tenga una transición difícil de delimitar o la rúbrica no precise qué cuenta como puente. Si discrepan sobre el ambiente, el atributo quizá depende de preferencias o de referencias culturales que el protocolo no definió. No se debe resolver automáticamente cada diferencia por mayoría y luego ocultarla: una adjudicación puede ser útil, pero debe quedar separada de las calificaciones originales.

La recomendación BS.1534 de la UIT trata la evaluación subjetiva de calidad de audio en condiciones controladas. Puede inspirar atención a la preparación y presentación de estímulos, pero no debe citarse como validación de una rúbrica de obediencia musical. Una evaluación de «¿se oye bien?» y otra de «¿aparece el instrumento durante las secciones indicadas?» necesitan preguntas, anclajes y análisis distintos.

Automatización: comprobaciones acotadas, no sustitutos de la escucha

El análisis automático puede ser útil cuando la pregunta es estrecha y el método tiene validez suficiente para ella. La duración se puede contrastar con un objetivo si se dispone de una señal de audio medible y una tolerancia definida. La presencia de voz o la detección aproximada de ciertos rasgos pueden explorarse con herramientas adecuadas, pero cada herramienta puede producir falsos positivos y falsos negativos. La etiqueta de un detector no demuestra por sí sola que una persona perciba el mismo atributo.

Tempo, instrumento y estructura son más difíciles de convertir en comprobaciones universales. Un estimador puede proponer pulsos por minuto sin demostrar que la música se perciba con el carácter solicitado; una detección de timbre no establece necesariamente qué instrumento interpreta un oyente; y los cambios de intensidad no identifican automáticamente verso, estribillo o puente. Para una evaluación técnica responsable, hay que describir el método, su rango de validez, la incertidumbre y los errores observados frente a anotaciones humanas.

Las restricciones de letra pueden comprobarse mediante transcripción y búsqueda sólo si la letra se reconoce con suficiente fidelidad. Una ausencia en la transcripción no prueba que una palabra no aparezca en el audio. Si una herramienta sugiere una coincidencia, hay que escuchar el fragmento y verificar el contexto antes de marcar cumplimiento o infracción. En particular, una prohibición de mencionar marcas no queda demostrada por un análisis automático sin errores.

La idea no es excluir la automatización, sino usarla como evidencia complementaria y declarar qué respalda. MusicEval estudia la evaluación automática de música generada y la relación con valoraciones expertas; esa clase de investigación puede orientar la cautela, pero no valida de antemano una herramienta para medir Lyria 3.5. Si una métrica no ha sido contrastada con la tarea concreta, se presenta como señal exploratoria, no como prueba definitiva.

Variabilidad, casos difíciles y presentación de resultados

Una generación aislada no permite estimar la consistencia del modelo. Para cada prompt, el equipo debe fijar con antelación cuántas generaciones realizará y aplicar el mismo plan a todas las condiciones. No existe un número universal que pueda recomendarse sin conocer el coste, la variabilidad esperada y el propósito del estudio. La decisión debe justificarse y publicarse. Elegir sólo las salidas más logradas sesga el resultado hacia una capacidad de selección, no hacia la probabilidad de cumplimiento de una generación ordinaria.

El análisis debe informar cumplimiento por requisito y por prompt, además de variación entre generaciones. Para estructura, por ejemplo, puede mostrar qué proporción de audios contiene las secciones solicitadas y cuántos respetan el orden previsto. Para instrumentos, puede separar presencia inicial de continuidad a lo largo de las partes especificadas. Los datos ausentes o no determinables no deberían convertirse silenciosamente en aciertos o errores.

Los resultados de casos compuestos se deben comparar con los de prompts simples con cuidado. Si una instrucción larga falla más a menudo, ese patrón puede reflejar una dificultad al combinar requisitos, pero también una ambigüedad mayor del texto, una interacción entre atributos o una diferencia en la exigencia del conjunto. La interpretación debe apoyarse en los registros y no atribuir una causa que el diseño no pueda distinguir.

El informe debería incluir ejemplos representativos de aciertos, incumplimientos y desacuerdos, sin seleccionar sólo los más sorprendentes. Una canción agradable que omite el puente ilustra por qué calidad y cumplimiento son ejes separados. Una detección automática de un instrumento que los oyentes no pueden localizar sirve para mostrar por qué la herramienta no sustituye la escucha. Ninguno de esos ejemplos, por sí solo, establece el rendimiento general del modelo.

Reproducibilidad y criterios prácticos para decidir

Un protocolo es más útil cuando otra persona puede reconstruir las condiciones. Publicar prompts, rúbricas, instrucciones para evaluadores, reglas de inclusión y exclusión, versión del modelo y canal utilizado permite revisar qué se evaluó. Cuando el acceso o los términos aplicables impidan compartir audios, debe explicarse esa limitación y ofrecerse lo que sí pueda publicarse. Antes de divulgar letras, voces u otros materiales, también hay que comprobar que su publicación y reutilización sean compatibles con los derechos y las condiciones pertinentes; no se debe asumir que todo material generado puede redistribuirse sin restricciones.

La identificación exacta del modelo importa porque una evaluación depende de la versión y del canal, no sólo del nombre comercial. Si se ejecuta el protocolo con el modelo estable `lyria-3.5` a través de la API, hay que dejar constancia de ese canal y de los controles disponibles. Un resultado obtenido por una vía no debe presentarse como garantía de comportamiento idéntico en otra sin evidencia que permita esa comparación.

Para equipos de producción, la decisión práctica no debería basarse en una puntuación general. Hay que partir de los requisitos que de verdad importan para el flujo de trabajo, revisar qué atributos fueron medidos directamente y comprobar cuánta variación existe entre generaciones. Si la continuidad instrumental es crítica, una alta valoración subjetiva no compensa un incumplimiento repetido de esa continuidad. Si la letra tiene restricciones estrictas, se necesita una verificación específica, no una impresión global de que la canción «siguió el prompt».

La contribución principal de un benchmark de seguimiento de instrucciones no es proclamar que un modelo es bueno o malo, sino hacer visibles sus condiciones de éxito y sus modos de fallo. Para Lyria 3.5, eso significa describir las instrucciones probadas, informar por separado cumplimiento y calidad percibida, conservar las generaciones y tratar la incertidumbre como parte del resultado. El índice de benchmarks puede servir de contexto para esta clase de evaluación, pero una prueba reproducible debe sostenerse en su propio protocolo, sus datos y sus límites.

Continúa explorando

Correcciones y transparencia

Si detectas un dato incorrecto o desactualizado, puedes enviarnos una corrección indicando la página y la fuente que debemos revisar.