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
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
1from transformers import pipeline
2
3qa = pipeline(
4 "question-answering",
5 model="[usuario/modelo]",
6 tokenizer="[usuario/modelo]"
7)
8
9qa(
10 question="¿Quién hizo el anuncio?",
11 context="La ministra informó que el programa comenzará en agosto."
12)
Análisis de errores
Revisando a mano los ejemplos con EM=0 en validation, identificamos tres patrones:
- 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.
- 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.
- 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
