ODESIA Challenge @ SEPLN 2024 (26 Septiembre - 2 Febrero)

ODESIA-CORE contiene 10 tareas discriminativas con datasets de entrenamiento públicos y datasets de test privados (no se han distribuido previamente por ningún medio) creados dentro de la iniciativa ODESIA. El carácter privado de los datos de test garantiza la ausencia de contaminación en los resultados del leaderboard: los LLMs no deberían haber podido podido ver las anotaciones del test set en su fase de preentrenamiento. Este es un resumen de las tareas:

Nombre	Dominio	Task	Tarea abstracta	Métrica
DIANN 2023	Biomédico	Detección de discapacidades	Etiquetado de secuencias	F1 Macro
DIPROMATS 2023	Política	Identificación de propaganda	Clasificación binaria	ICM-Norm
		Caracterización gruesa de propaganda	Clasificación jerárquica multiclase, multietiqueta	ICM-Norm
		Caracterización fina de propaganda	Clasificación jerárquica multiclase, multietiqueta	ICM-Norm
EXIST 2022	Social	Detección de sexismo	Clasificación binaria	Accuracy
		Categorización de sexismo	Clasificación multiclase	F1 Macro
EXIST 2023	Social	Detección de sexismo	Clasificación binaria	Soft-ICM-Norm
		Categorización de la intención de la fuente	Clasificación jerárquica multiclase	Soft-ICM-Norm
		Categorización de sexismo	Clasificación jerárquica multiclase, multietiqueta	Soft-ICM-Norm
SQUAD-SQAC 2024	Científico (diverso)	Pregunta-Respuesta extractiva	Etiquetado de secuencias	F1

El sistema ganador será aquel que, a fecha de fin de la competición, obtenga la mejor puntuación promedio en las tareas ODESIA-CORE en español.

Se aceptan todos los tipos de sistemas de Procesamiento del Lenguaje Natural (PLN), siempre que se apliquen de forma uniforme en todas las tareas utilizando la misma arquitectura o enfoque metodológico. Así pues, cada participación debe consistir en un único sistemaque aborde todas las tareas. No se aceptarán propuestas en las que se utilicen modelos o enfoques totalmente diferentes para cada tarea de forma independiente.

Por «sistema único» se entiende un enfoque metodológico uniforme y/o una arquitectura que se aplica a todas las tareas, como:

• Utilizar la misma arquitectura de modelo básico discriminativo para todas las tareas.
• Utilizar el mismo modelo generativo para todas las tareas. Los participantes pueden utilizar grandes modelos generativos del lenguaje (LLMs) como modelos base, aplicándolos de forma uniforme a todas las tareas (el mismo modelo interviene en la resolución de todas las tareas).
• En los modelos que sólo utilizan decodificadores se pueden aplicar estrategias de prompting uniformes, adaptando los prompts a la tarea según sea necesario (véanse a continuación los ajustes específicos permitidos para las tareas).
• Emplear ensembles de modelos de forma uniforme para todas las tareas (la misma combinación de modelos participa en la resolución de todas las tareas). Por ejemplo, se permite el uso de modelos base y auxiliares o un enfoque RAG, siempre que sean los mismos en todas las tareas (pero con estrategias que pueden variar en cada tarea).

Ajustes Específicos de la Tarea Permitidos:

• Preprocesamiento: Se permiten diferentes pasos de preprocesamiento por tarea (antes del entrenamiento).
• Fine-Tuning: Se permite el ajuste específico del mismo modelo base para cada una de las tareas.
• Hiperparámetros y Prompts: Está permitido el ajuste de hiperparámetros, prompts u otros parámetros para cada tarea, si se utiliza el mismo modelo base consistentemente en todas las tareas.
• Datos Externos y Estrategias de Recuperación de Datos: Se permite el uso de diferentes fuentes de datos externos o estrategias de recuperación de datos específicos para cada tarea.

Ejemplos de Sistemas Admitidos (no exhaustiva; consulte a los organizadores si tiene dudas sobre la validez del enfoque):

1. LLMs de Tipo Codificador con Fine-Tuning:
   • Utilizar el mismo LLM (o ensemble de LLMs) como base, con un ajuste fino específico para cada tarea. Pueden utilizarse datos de entrenamiento del paquete de los participantes o de otras fuentes externas de datos adecuadas.
2. LLMs Generativos con Estrategia de Prompting Uniforme:
   • Utilizar el mismo o varios LLM(s) en combinación con una estrategia de prompting zero-shot, one-shot, o few-shot.
   • Mientras que el enfoque general es uniforme para todas la tareas, los prompts pueden adaptarse a cada tarea. Por ejemplo, usar GPT-3 para todas las tareas con prompts específicos para cada tarea se considera un sistema único aplicado de forma uniforme a todas las tareas. Incluso si los prompts o las estrategias de recuperación de datos difieren por tarea, el modelo generativo subyacente sigue siendo el mismo.
3. Retrieval-Augmented Generation:
   • Emplear uno o más LLMs generativos con una estrategia de RAG, utilizando conjuntos de datos o fuentes de entrenamiento externos. Para cada tarea pueden utilizarse diferentes estrategias de recuperación o datos externos.
4. Combinaciones de Métodos:
   • Cualquier combinación de los métodos anteriores, siempre que se aplique el mismo modelo o modelos de base con un enfoque metodológico uniforme para todas las tareas.

Ejemplos de Sistemas no Admitidos:

1. Usar Diferentes Modelos Base para cada Tarea sin un Fundamento Compartido:
   • Ejemplo: Un equipo presenta una solución en la que utiliza un modelo BERT ajustado para la Tarea A, un modelo GPT-2 para la Tarea B y un modelo XLNet para la Tarea C, sin un modelo base compartido ni una metodología general.
   • Razón: Este enfoque implica modelos completamente diferentes para cada tarea sin una base común, lo que viola el requisito de utilizar la misma arquitectura de modelo base o un enfoque metodológico uniforme para todas las tareas.
2. Emplear Arquitecturas y Metodologías Diferentes por Tarea:
   • Ejemplo: Para la Tarea A, el participante utiliza un sistema basado en reglas; para la Tarea B, aplica un modelo estadístico de traducción automática; y para la Tarea C, utiliza una red neuronal entrenada desde cero.
   • Razón: Utilizar arquitecturas y metodologías fundamentalmente diferentes para cada tarea sin ningún elemento común no constituye un sistema único.
3. Sistemas Independientes Desarrollados por Separado para Cada Tarea:
   • Ejemplo: El participante presenta tres bases de código separadas, cada una desarrollada de forma independiente para las Tareas A, B y C, sin componentes, código o modelos compartidos.
   • Razón: Este envío contiene múltiples sistemas independientes en lugar de un sistema unificado aplicado a todas las tareas.
4. Combinar Modelos Preentrenados no Relacionados sin Integración:
   • Ejemplo: Utilizar un modelo de análisis de sentimientos preentrenado para la Tarea A, un modelo de reconocimiento de entidades nombradas para la Tarea B y un algoritmo de modelado de temas para la Tarea C, sin ningún intento de integrarlos en un sistema unificado.
   • Razón: La simple agrupación de modelos no relacionados entre sí, sin un modelo de base o un enfoque metodológico común, no cumple los criterios de un sistema único.
5. Aplicar Diferentes Paradigmas de Aprendizaje Automático por Tarea:
   • Ejemplo: Utilizar aprendizaje supervisado para la Tarea A, aprendizaje no supervisado para la Tarea B y aprendizaje por refuerzo para la Tarea C, sin un marco común o modelo base que conecte estos enfoques.
   • Razón: Este enfoque carece de una base metodológica uniforme para todas las tareas.
6. Usar Diferentes Modelos Generativos para Cada Tarea sin un Modelo Base Compartido:
   • Ejemplo: Un participante presenta una solución en la que utiliza GPT-3 para la Tarea A, PaLM para la Tarea B y LLaMA para la Tarea C, sin modelo base compartido ni enfoque metodológico global. Cada tarea se aborda utilizando un modelo de IA generativa diferente de forma independiente.
   • Razón: Este enfoque implica el uso de modelos generativos completamente diferentes para cada tarea sin un modelo base común o una metodología consistente. Viola el requisito de aplicar la misma arquitectura de modelo base o un enfoque metodológico consistente en todas las tareas.

Reproducibilidad y Verificación:

• Para garantizar la originalidad y validez de las soluciones, los organizadores podrán solicitar a los participantes que faciliten su código y todos los materiales necesarios para reproducir los resultados. El código deberá facilitarse como enlace a un repositorio GitHub (posiblemente junto con una imagen Docker para facilitar la ejecución), previa solicitud.
• Los modelos o sistemas para los que no se faciliten los materiales de verificación o reproducción requeridos no podrán optar al premio del challenge y podrán ser eliminados del Leaderboard.

• Los equipos tendrán que registrarse previamente en el concurso antes de poder participar.
• Cada equipo registrará una única cuenta en el sistema de evaluación ODESIA-Leaderboard a través del formulario habilitado a tal efecto (enlace).
• La organización proporcionará un nombre de usuario y contraseña en la plataforma ODESIA-Leaderboard una vez que se validen los datos de registro.

• Los resultados se enviarán a través de ODESIA Leaderboard en https://leaderboard.odesia.uned.es/leaderboard/submit , donde serán evaluados automáticamente usando las métricas correspondientes a cada tarea.
• Para realizar cada envío, los equipos deberán formatear sus ficheros de predicciones siguiendo las especificaciones que se describen en los ficheros README de cada conjunto de datos (incluidos en el paquete de descarga).
• Además, se deberán rellenar los siguientes campos en la página de envío de predicciones:
  • Nombre del equipo: Nombre de usuario del representante del equipo en la plataforma ODESIA, que se proporcionará al registrarse en el concurso.
  • Correo electrónico: Correo electrónico de contacto usado en el registro en el concurso.
  • Afiliación: Institución/es a la/s que pertenece/n el/los participante/s (si se aplica).
  • Nombre del sistema: Se formateará como “{nombre_del_equipo}-{número_de_envio}”, donde nombre_del_equipo será un identificador invariante para todos los envíos de un mismo participante, y donde “número_de_envío” será un número de 1 a 20 correspondiente a cada uno de los veinte envíos permitidos por equipo durante el concurso.
  • URL del modelo: (opcional) URL del modelo (por ejemplo en Hugging Face) si se aplica.
  • Descripción del sistema: Descripción de entre 300 y 500 palabras del sistema usado para generar las predicciones.
  • GitHub URL: De manera opcional, los equipos podrán añadir en este campo el enlace al código fuente utilizado para generar los resultados.
  • Leaderboard version: "Challenge" se elegirá obligatoriamente.
  • Idiomas del envío: Marcar sólo "Spanish".
  • ZIP File: Los resultados del sistema se envían mediante un fichero comprimido con las predicciones formateadas de acuerdo con el fichero indicado más arriba.

El proceso de evaluación puede tardar hasta dos minutos. Una vez completado, la aplicación de envío de ejecuciones permite comprobar los resultados de la evaluación de un envío y elegir si hacerlos públicos o no en el leaderboard. Con independencia de que se hagan públicos o no, cada envío contará para el máximo de veinte (20) por equipo permitido durante el concurso.

El Leaderboard ODESIA utiliza la librería de evaluación PyEvALL para las tareas de clasificación. PyEvALL es accesible desde el gestor de paquetes Pip y puede ser utilizada durante la fase de desarrollo de los sistemas para evaluar las tareas de DIPROMATS 2023, EXIST 2022 y EXIST 2023. Así mismo, la métrica F1 implementada para evaluar las tareas del dataset SQUAD/SQAC original ha sido adaptada para evaluar las tareas del dataset SQUAD-SQAC 2024. Su implementación original, para su uso en la fase de desarrollo, se puede encontrar en SQUAD METRIC. Por su parte, la tarea de etiquetado de secuencias DIANN 2023 utiliza la métrica Macro F1 implementada en la librería HuggingFace Evaluate que también ha sido adaptada para ser utilizada en el Leaderboard ODESIA.

Las únicas restricciones sobre los equipos participantes son:

• Todos los miembros del equipo deben ser mayores de edad.
• Ninguna persona puede ser miembro de más de un equipo.

• Se establece un único premio de 3.000 euros (donados por la empresa Llorente y Cuenca Madrid, SL) para el equipo que presente el sistema con el mejor rendimiento promedio en todas las tareas de ODESIA-CORE en español.
• Para poder optar al premio, se establecen las siguientes condiciones:
  • Los equipos deben hacer públicos sus resultados en el leaderboard de ODESIA antes de la fecha de fin del concurso.
  • El equipo ganador debe obtener una puntuación promedio superior a la de los modelos baseline proporcionados por la organización. En particular, deben superar al modelo que obtiene el mejor promedio, que es XLM-Roberta-Large con una puntuación de 0.5873.
  • Debe haber un mínimo de cinco equipos que hayan enviado resultados válidos. Si no se llega a este mínimo, la organización se reserva el derecho de aplazar la fecha límite de la competición.
  • El equipo ganador se compromete a presentar su solución en la sesión de entrega de premios del concurso (ver sección "Presentación de Resultados y Entrega del Premio").
  • Los empleados de UNED, LLyC Madrid S.L., Red.es, SEDIA y cualquier otra entidad relacionada con el proyecto ODESIA podrán participar en la competición, pero no optar al premio final en metálico.

• Se deben respetar las reglas éticas y profesionales de sentido común. La organización se reserva el derecho de descalificar equipos que violen las reglas.
• No se imponen límites a la cuantía de los costes derivados de la implementación de las soluciones, pero la organización podrá solicitar información sobre los mismos.
• Los organizadores se reservan el derecho de actualizar las normas en respuesta a circunstancias imprevistas con el fin de servir mejor a la misión del concurso.
• Los organizadores se reservan todos los derechos en cuanto al fallo final.

• Al equipo ganador, y a aquellos equipos que presenten soluciones innovativas, se les solicitará un informe técnico en formato PDF de un mínimo de 4 páginas (excluidas las referencias) detallando su solución.
• El informe incluirá una discusión de las estrategias adoptadas por el equipo en la confección de su propuesta y de los resultados de evaluación.
• El informe incluirá un detalle de los costes de implementación del sistema y del uso de los conjuntos de datos utilizados, tanto aquellos proporcionados por la organización como los de terceros.
• En caso de haber material suficiente, se considerará la opción de publicar los informes técnicos en un número especial o en un artículo conjunto de una revista del área.

• El equipo ganador será invitado a presentar su solución en una ceremonia de premios durante el ODESIA Final Project Workshop en febrero de 2025. La aceptación del premio implica la asistencia obligatoria (presencial u online) a dicha sesión.
• Todos los participantes recibirán certificados de participación a la finalización del concurso.

Esta competición se organiza en el marco del Proyecto ODESIA, fruto de un convenio entre la universidad pública española UNED y Red.es, Entidad Pública Empresarial adscrita al Ministerio para la Transformación Digital y la Función Pública, a través de la Secretaría de Estado de Digitalización e Inteligencia Artificial. El proyecto está parcialmente financiado por la Unión Europea (fondos NextGenerationEU) a través del "Plan de Recuperación, Transformación y Resiliencia'', por el Ministerio de Economía y Transformación Digital y por la Universidad UNED. Pertenece a las actividades del "Plan de Tecnologías del Lenguaje de la Secretaría de Estado de Inteligencia Artificial y Digitalización" de España.

• Comité Organizativo:
  • Alejandro Benito-Santos (co-chair, UNED)
  • Roser Morante (co-chair, UNED)
  • Julio Gonzalo (UNED)
  • Jorge Carrillo-de-Albornoz (UNED)
  • Laura Plaza (UNED)
  • Enrique Amigó (UNED)
  • Víctor Fresno (UNED)
  • Andrés Fernández (UNED)
  • Adrián Ghajari (UNED)
  • Guillermo Marco (UNED)
  • Eva Sánchez (UNED)
  • Miguel Lucas (LLyC)
• Consejo Asesor:
  • TBA

Para preguntas relacionadas con la competición, recomendamos acceder al servidor Discord: #odesia-challenge-2024. Alternativamente puede escribirse a la presidencia del comité de organización, Alejandro Benito-Santos (al.benito@lsi.uned.es) y Roser Morante (r.morant@lsi.uned.es).

• Inicio del concurso: 26 de septiembre de 2024
• Cierre de inscripciones: 20 de Enero, 2025^*
• Cierre del concurso: 2 de febrero de 2025^*
• Anuncio oficial de resultados: mitad de septiembre de 2025.
• Sesión de presentación de resultados y entrega de premios: final de Febrero 2025

^*23:59 AoE (Anywhere on Earth)