CarlosAGDev
/

ltv-lora-qa

@@ -12,104 +12,122 @@ tags:
 # CarlosAGDev/ltv-lora-qa
-LoRA-QA (v0.1.0) del LTV Framework. Genera 2-4 sub-preguntas atomicas y
-auto-contenidas para verificar una afirmacion check-worthy clasificada. Tercer
-paso del pipeline de Triage, despues de LoRA-CW y LoRA-CLF.
 ## Formato de salida
 ```json
 {
   "questions": [
-    {"question": "...", "answer_type": "Boolean"},
-    {"question": "...", "answer_type": "Extractive"}
   ]
 }
 ```
-`answer_type` puede ser: `Boolean`, `Extractive`, o `Abstractive`.
 ## Detalles del Entrenamiento
-Entrenado sobre anotaciones sinteticas generadas por `gemini-3.1-flash-lite`.
-Pool balanceado: Event/Property Claim capeado a 500 (de 973 disponibles), split
-estratificado por claim_type (15% eval, 85% train).
-| Claim type entrenado | Claims (pool) |
-| :--- | :---: |
-| Event/Property Claim | 500 (cap desde 973) |
-| Numerical Claim | 207 |
-| Causal Claim | 12 |
-| Position Statement | 8 |
-| Quote Verification | 0 (ausente en v0.1) |
-| **Total** | **727** |
-### Hiperparametros
-- **Modelo Base:** `google/gemma-4-E2B-it`
-- **Max Sequence Length:** `512`
-- **Epochs:** `1`
-- **Batch Size (Per Device):** `4`
-- **Gradient Accumulation Steps:** `4`
-- **Learning Rate:** `0.0002`
-- **Optimizer:** `paged_adamw_8bit`
-## Resultados (v0.1.0)
-Evaluado sobre 110 muestras (15% held-out, estratificado por claim_type).
-Tiempo de evaluacion: 32m 6s (~17.5 s/ejemplo).
-### Validez del esquema de salida
-| Metrica | Valor |
-| :--- | :--- |
-| **JSON valido + schema OK** | **110/110 (100%)** |
-| **Fallos de parseo** | **0** |
-### Validez por claim_type
-| Claim type | Validos / Total | % |
 | :--- | :---: | :---: |
-| Event/Property Claim | 76/76 | 100% |
-| Numerical Claim | 31/31 | 100% |
-| Causal Claim | 2/2 | 100% |
-| Position Statement | 1/1 | 100% |
-### Distribucion de n_questions (Referencia vs Generado)
-| n preguntas | Referencia | Generado |
-| :---: | :---: | :---: |
-| 2 | 14 | 2 |
-| 3 | 92 | **107** |
-| 4 | 4 | 1 |
-### Distribucion de answer_type (Referencia vs Generado)
-| answer_type | Ref count | Ref % | Gen count | Gen % |
-| :--- | :---: | :---: | :---: | :---: |
-| Boolean | 130 | 40.6% | 127 | 38.6% |
-| Extractive | 146 | 45.6% | 171 | **52.0%** |
-| Abstractive | 44 | 13.8% | 31 | 9.4% |
-### Notas de comportamiento
-- **Generacion perfecta en v0.1:** el modelo produce JSON valido y schema-correcto en
-  el 100% de los casos evaluados, para los 4 tipos de claim disponibles.
-- **Preferencia por 3 preguntas:** el modelo genera 3 sub-preguntas en el 97% de los
-  casos (referencia: 84%), colapsando los extremos (2 y 4 preguntas se usan mucho menos).
-  Para la mayoria de afirmaciones esto es correcto, pero puede infragenerar preguntas
-  para claims complejos que merecen 4.
-- **Sesgo Extractive / falta de Abstractive:** genera Extractive un 6% mas de lo esperado
-  (52% vs 45.6%) y Abstractive un 4% menos (9.4% vs 13.8%). El modelo favorece preguntas
-  de hecho concreto sobre preguntas de sintesis o explicacion causal.
-### Limitaciones y mejoras para v0.2.0
-1. **Quote Verification ausente:** 0 ejemplos en el batch sintetico actual. Al completar
-   las 7,440 anotaciones aparecera este tipo. Hasta entonces el modelo no ha aprendido a
-   generar preguntas para citas textuales.
-2. **Causal y Position muy escasos (12 y 8 claims):** los resultados 100% para estos tipos
-   son prometedores pero no estadisticamente robustos con 2 y 1 ejemplos de eval.
-3. **Distribucion de n_questions sesgada hacia 3:** agregar ejemplos con 2 y 4 preguntas
-   equilibrara la distribucion generada.
-4. **Reducir sesgo Extractive:** el batch sintetico completo dara mas ejemplos con
-   Abstractive (tipicamente en Causal y Position Statement).

 # 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
 ```json
 {
   "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.