CarlosAGDev/ltv-lora-qa
LoRA-QA (v0.2.0) del LTV Framework. Genera 2-4 sub-preguntas atomicas y
auto-contenidas para verificar una afirmacion check-worthy clasificada.
Mejoras en v0.2.0
- Pool ~6.7x mas grande: ~4,879 claims con sub-preguntas (vs 727 en v0.1.0),
re-anotados 100% con prompts v2 por
gemini-3.1-flash-lite.
- Quote Verification presente: ~290 ejemplos de entrenamiento (0 en v0.1.0).
- Sin cap de Event/Property: la distribucion natural del dataset v2 (E/P ~52%)
ya esta bajo el 57.8% real de AVeriTeC — no se descarto ningun ejemplo.
- Prompts v2: guia de n_questions (media humana AVeriTeC: 2.6, no colapsar a 3)
y de answer_type (Boolean con moderacion).
Formato de salida
1{
2 "questions": [
3 {"question": "...", "answer_type": "Extractive"},
4 {"question": "...", "answer_type": "Abstractive"}
5 ]
6}
answer_type: Boolean, Extractive, o Abstractive.
Detalles del Entrenamiento
| Parametro | Valor |
|---|
| Modelo Base | google/gemma-4-E2B-it |
| Max Sequence Length | 512 |
| Epochs | 1 |
| Batch Size (Per Device) | 4 |
| Gradient Accumulation | 4 |
| Learning Rate | 2e-4 |
| Optimizer | paged_adamw_8bit |
| GPU | NVIDIA L4 (23.7 GB VRAM) |
| Eval set | 732 claims, estratificado por claim_type |
| Tiempo de evaluacion | 331 min (~27 s/ejemplo, max_new_tokens=300) |
Resultados (v0.2.0)
Metricas globales
| Metrica | v0.1.0 | v0.2.0 |
|---|
| JSON valido + schema OK | 100% (110/110) | 91.0% (666/732) |
| Tipos con soporte en eval | 4 de 5 | 5 de 5 |
| Sesgo hacia 3 preguntas | 97% | 85% |
Distribucion n_questions (eval n=732)
| n | Referencia | Generado |
|---|
| 2 | 432 (59%) | 92 (14%) |
| 3 | 287 (39%) | 566 (85%) |
| 4 | 13 (2%) | 8 (1%) |
Media de referencia: 2.43 preguntas/claim (el maestro v2 si adopto la guia del
prompt). Media generada: 2.87 — el adaptador sigue colapsando a 3.
Distribucion answer_type
| answer_type | Referencia | Generado |
|---|
| Boolean | 558 (31.4%) | 74 (3.9%) |
| Extractive | 976 (54.9%) | 1471 (76.9%) |
| Abstractive | 243 (13.7%) | 369 (19.3%) |
Validez por claim_type
| Tipo | Validez | Nota |
|---|
| Numerical Claim | 94% (208/222) | |
| Event/Property Claim | 93% (355/382) | |
| Causal Claim | 83% (50/60) | |
| Position Statement | 83% (20/24) | |
| Quote Verification | 75% (33/44) | clase nueva — primer entrenamiento |
Hallazgos principales
Colapso de Boolean (31.4% -> 3.9%) — el hallazgo central. El prompt v2 (presente
en el turno de usuario de cada ejemplo) instruye "use Boolean sparingly". El adaptador
sobre-aprendio la instruccion literal en lugar de imitar la distribucion real del
maestro (que uso Boolean en 31% de sus preguntas). Es un caso de conflicto
instruccion-vs-demostracion: cuando el prompt dice una cosa y los ejemplos muestran
otra, el modelo pequeno se ancla a la instruccion.
El sesgo de 3 preguntas persiste (85%). Mejoro respecto al 97% de v0.1.0, pero el
maestro v2 se movio a 2 preguntas como moda (59%) y el adaptador no lo siguio. La
distribucion de salida del adaptador cambia mas lento que la del maestro.
Regresion en validez JSON (100% -> 91%). Tres factores: eval 6.7x mas grande y
diverso, clases nuevas dificiles (Quote 75%), y salidas mas variadas. Los fallos se
concentran en las clases minoritarias (Quote 25% de fallos, Causal/Position 17%).
Limitaciones conocidas (v0.2.0)
- Boolean casi ausente: las preguntas si/no (17% del uso humano en AVeriTeC) casi
no se generan. Para claims tipo Quote Verification ("did X really say this?") el
Boolean suele ser la pregunta natural — su ausencia dana justo a la clase mas debil.
- Quote Verification fragil: 75% de validez con solo 44 ejemplos de eval; los
fallos de schema se concentran aqui.
- Referencia = maestro sintetico: mide imitacion de
gemini-3.1-flash-lite con
prompts v2, no calidad absoluta de las preguntas.
Mejoras propuestas para v0.3.0
- Resolver el conflicto instruccion-demostracion: alinear la instruccion del
prompt con la distribucion real del maestro (p. ej. "aim for roughly 1 in 3 Boolean")
o quitar la guia cuantitativa del prompt de entrenamiento y dejar que los ejemplos
hablen.
- Oversampling de Quote Verification y Causal en train para subir la validez de
schema en las clases debiles.
- Inspeccionar los 66 fallos de parseo (guardarlos en el notebook) para distinguir
JSON malformado vs schema invalido vs truncamiento por max_new_tokens=300.
- Acelerar la evaluacion (27 s/ejemplo es impractico): batched generation o
vLLM/LoRA para el eval, no para el despliegue.