pdqa-roberta-bne-em-tuned

Descripción

Modelo desarrollado para el Dominican News Question Answering Challenge. Recibe una pregunta y un contexto noticioso, y extrae la respuesta directamente del texto (QA extractivo). Es un fine-tuning de roberta-base-bne-finetuned-sqac, orientado específicamente a mejorar el Exact Match sobre el dataset pdqa.

Integrantes

• Scarlet Abreu (10153953)
• Renso Peralta (10154062)

Licencia

Apache License 2.0, heredada del modelo base (roberta-base-bne, de PlanTL-GOB-ES / BSC-LT), que también se distribuye bajo esta licencia.

Recursos oficiales

• Dataset: Lisibonny/pdqa
• Baseline: Lisibonny/modelo_qa_beto_squad_es_pdqa
• Aplicación: Lisibonny/Repartidor_Dominicano

Modelo base

• Repositorio: nlp-en-es/roberta-base-bne-finetuned-sqac
• Justificación: es un RoBERTa en español ya fine-tuneado para QA extractivo (sobre SQAC, un dataset parecido en estructura a pdqa). Lo elegimos porque ya viene adaptado a la tarea, así que el fine-tuning que hicimos nosotros solo tenía que enseñarle las convenciones de anotación específicas de pdqa, no la tarea de QA desde cero.
• Número aproximado de parámetros: ~125M (arquitectura RoBERTa-base)

Datos

División	Filas	Uso
train	45	Entrenamiento
validation	15	Comparación y selección
test	20	Predicciones finales

No se publicaron ni utilizaron respuestas privadas de test.

Nota de calidad de datos: encontramos 1/45 ejemplos de entrenamiento donde parecía que el answer_start estaba mal alineado con el contexto. Investigando, el problema no parecía corresponder a un error de anotación, sino a una diferencia en el tipo de espacio utilizado (uno era un espacio no separable, \xa0, y el otro un espacio normal). Corregimos la función de verificación para normalizar espacios antes de comparar. Esto no afectó el entrenamiento en sí, porque el cálculo de posiciones de tokens usa longitud de caracteres, no comparación exacta de strings.

Entrenamiento

Parámetro	Valor
Seed	42
Learning rate	2e-5
Batch size	4
Épocas	1 (seleccionada por early stopping según EM real en validation, de un máximo de 12)
Max length	384
Doc stride	128
Weight decay	0.05
Hardware	GPU T4 (Google Colab)
Tiempo	~1 minuto por configuración completa (12-15 épocas), dataset de 45 ejemplos

Sobre la selección de época: implementamos un callback (EMEarlyStoppingCallback) que evalúa Exact Match y F1 reales en validation al final de cada época, y se queda con los pesos de la época con mejor EM (desempate por F1) en vez de la última época o el menor eval_loss. En las 3 configuraciones que probamos, la mejor época fue siempre la época 1: con solo 45 ejemplos de entrenamiento, el modelo comenzó a sobreajustarse rápidamente. Después de la primera época las métricas dejaron de mejorar e incluso disminuyeron en algunas configuraciones (ver la sección de Comparación de configuraciones).

Experimentos

Experimento	Cambio	EM validation	F1 validation
Baseline oficial (Lisibonny/modelo_qa_beto_squad_es_pdqa)	Sin cambios	60.00	75.84
Modelo base sin fine-tuning (nlp-en-es/roberta-base-bne-finetuned-sqac)	Sin cambios	53.33	81.68
Variante 1 (Run 0)	lr=3e-5, weight_decay=0.01, época 1	66.67	83.84
Variante 2 (Run 1)	lr=2e-5, weight_decay=0.05, época 1	73.33	84.79
Variante 3 (Run 2)	lr=1e-5, weight_decay=0.05, época 1	60.00	81.64
Modelo final	Run 1 (lr=2e-5, weight_decay=0.05, época 1)	73.33	84.79

Comparación de configuraciones

Mantuvimos fijos el modelo base, el dataset, la tokenización (max_length=384, doc_stride=128) y la semilla (42) en las 3 variantes. Solo variamos learning_rate, weight_decay y el número máximo de épocas permitidas (con selección automática de la mejor época por EM real en validation).

El hallazgo clave: en una primera prueba sin early stopping (10 épocas fijas, lr=3e-5), el EM subió a 66.67 pero el F1 bajó a 76.63, por debajo incluso del modelo sin fine-tuning (81.68). Al revisar ejemplo por ejemplo, encontramos 2 casos donde el modelo, después de varias épocas, dejó de responder bien y empezó a dar respuestas totalmente erróneas (F1=0.00) que antes tenían F1 alto (0.50 y 0.95). Estos resultados son consistentes con un proceso de sobreajuste, dado el reducido tamaño del conjunto de entrenamiento.

Al agregar el callback de early stopping por EM (que en la práctica se detuvo en la época 1 en las 3 configuraciones), recuperamos la calidad en esos 2 casos y además ganamos uno adicional que ni el baseline ni la primera versión del fine-tuning resolvían. El resultado final (EM=73.33, F1=84.79) mejora ambas métricas a la vez frente al modelo base y al baseline oficial. Estos resultados sugieren que seleccionar la mejor época utilizando Exact Match en validación, en lugar del valor de loss, fue un factor importante en la mejora del desempeño.

Resultados

El modelo final obtuvo un Exact Match de 73.33% y un F1 de 84.79% sobre el conjunto de validación. Estos resultados superan tanto al modelo base sin ajuste como al baseline oficial proporcionado para la práctica.

• Exact Match en validation: 73.33
• F1 en validation: 84.79
• Exact Match en train: 84.44 (38/45)
• Diferencia train–validation: 11.11 pp, lo que sugiere un overfitting moderado. Dado el tamaño reducido del conjunto de entrenamiento (45 ejemplos), este comportamiento era esperable. Aun así, el modelo conserva una capacidad de generalización aceptable sobre el conjunto de validación.
• Script de evaluación: 05_evaluate_qa.py

Ejemplo de uso

from transformers import pipeline

qa = pipeline(
    "question-answering",
    model="[usuario/modelo]",
    tokenizer="[usuario/modelo]"
)

qa(
    question="¿Quién hizo el anuncio?",
    context="La ministra informó que el programa comenzará en agosto."
)

Análisis de errores

Revisando a mano los ejemplos con EM=0 en validation, identificamos tres patrones:

1. Boundary corto: el modelo agarra el núcleo correcto de la respuesta pero se le queda corto un artículo o preposición (ej. 11 en vez de a 11 bateadores). Era el error más común en el baseline; este comportamiento apareció con menor frecuencia después del fine-tuning, aunque no lo medimos de forma sistemática sobre todo el conjunto.
2. Answer-type mismatch: para preguntas con cómo (que piden una cualidad), el modelo a veces extrae un número en vez de una descripción, aun cuando ambos fragmentos son extraíbles del contexto. El baseline oficial comete el mismo error en nuestro ejemplo revisado, lo que sugiere que es una dificultad del ejemplo más que algo específico de nuestro fine-tuning; probablemente requeriría más ejemplos similares durante el entrenamiento o un ajuste adicional del modelo, no solo otro barrido de hiperparámetros.
3. Respuesta gold como enumeración: cuando el gold es una lista de nombres propios, el modelo devuelve un resumen corto en vez de la lista completa. Lo documentamos como una limitación del enfoque (QA extractivo de un solo span), no como algo que se arregle con más entrenamiento.

Limitaciones

• La respuesta debe estar presente en el contexto.
• El modelo puede confundir entidades, fechas o cantidades similares.
• El modelo no verifica la veracidad de la noticia.
• No debe utilizarse como única fuente para decisiones de alto impacto.
• Con solo 45 ejemplos de entrenamiento, el modelo sobreajusta con facilidad: entrenar más allá de la primera época empeora la calidad de varias respuestas, aunque el Exact Match pueda mejorar en algún caso puntual. Lo mitigamos con early stopping basado en EM real, pero no asumimos que el modelo sea robusto frente a preguntas muy distintas a las que vio en pdqa.
• No distingue de forma confiable entre respuestas cualitativas y cuantitativas cuando ambas aparecen en la misma oración del contexto.
• No maneja bien respuestas gold que son enumeraciones de varias entidades.

Reproducibilidad

• Repositorio de código: scarletabreu/pdqa-roberta-bne-em-tuned.git
• Commit: e136e68
• Notebook: 03_Introduccion_QA_Noticias.ipynb (extendido con celdas de fine-tuning)
• Archivo de dependencias: 09_requirements.txt
• Semillas: 42