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

{
  "questions": [
    {"question": "...", "answer_type": "Extractive"},
    {"question": "...", "answer_type": "Abstractive"}
  ]
}

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

1. 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.
2. Oversampling de Quote Verification y Causal en train para subir la validez de schema en las clases debiles.
3. Inspeccionar los 66 fallos de parseo (guardarlos en el notebook) para distinguir JSON malformado vs schema invalido vs truncamiento por max_new_tokens=300.
4. Acelerar la evaluacion (27 s/ejemplo es impractico): batched generation o vLLM/LoRA para el eval, no para el despliegue.