English · Español

03 — Construcción de probes: schema, cobertura y la rejilla de gramática verbal¶

🇪🇸 Una probe set bien hecha vale más que un test set diez veces más grande. Aquí están las reglas: schema, balance por verbo / tiempo / persona / idioma, prevención de leak, y las trampas adversariales que separan modelos de verdad de modelos de juguete.

Qué significa "probe" aquí¶

Una probe es un único ejemplo etiquetado con metadatos ricos. Schema (JSONL, un ejemplo por línea):

{
  "id": "probe-work-pres-3sg-001",
  "language": "en",
  "verb": "work",
  "regularity": "regular",
  "tense": "present_simple",
  "person": "3sg",
  "prompt": "Every day she ___ at the office.",
  "candidates": ["work", "works", "worked", "working"],
  "expected": "works",
  "label": "correct",
  "category": "core",
  "reason_code": "PRES-3SG-S",
  "explanation": "3rd-person singular present requires the -s ending on regular verbs.",
  "source": "hand"
}

Campos requeridos:

id — único, estable. El arnés lo usa para emparejar entre runs de evaluación.
language — en | es.
verb — uno de los 20 verbos objetivo (12 regulares + 8 irregulares).
regularity — regular | irregular. Derivado de verb pero almacenado explícitamente para troceo.
tense — uno de {infinitive, present_simple, past_simple, past_participle, future}.
person — uno de {1sg, 2sg, 3sg}.
prompt — la frase mostrada al modelo. Contiene ___ donde va la forma verbal (para elección múltiple) O una forma inline para clasificación.
candidates — lista de formas candidatas (configuración de elección múltiple). Incluye la forma correcta y 2-3 distractores.
expected — la forma correcta. Debe estar en candidates.
label — correct | incorrect | ambiguous. (ambiguous es para frases que podrían ser cualquiera, p. ej., You work se lee idéntico en 2sg y plural; expected sigue fijado, pero al modelo no se le penaliza por elegir cualquiera.)
category — core | adversarial.

Campos opcionales (recomendados):

reason_code — etiqueta simbólica corta (PRES-3SG-S, PAST-IRREG, EN-ES-MISMATCH, etc.). Se usa en el análisis de errores.
explanation — una frase de justificación, EN o ES. No se usa en métricas; útil para el eval REPORT.md.
source — hand | generated. Curado a mano es oro; generado necesita comprobaciones de higiene.

Matriz de cobertura¶

La rejilla de gramática verbal es 20 verbos × 5 tiempos × 3 personas = 300 celdas por idioma × 2 idiomas = 600 celdas. No probamos de forma exhaustiva — muestreamos. Las reglas de muestreo:

Slice	Mínimo de probes core
Por idioma (EN, ES)	≥ 30 cada uno
Por regularidad (regular, irregular)	≥ 30 cada uno
Por tiempo (5 tiempos)	≥ 10 cada uno
Por persona (3 personas)	≥ 15 cada uno
Total adversarial	≥ 20

Objetivo: ~60 core + ~20 adversarial = ~80 probes. El DoD de la Fase 20 dice mínimo 60 core + 20 adversarial.

Consejo de construcción a mano: monta primero una tablita (verbo × tiempo × persona), tacha celdas a medida que escribes probes, asegúrate de que cada verbo regular tenga al menos 1 entrada y cada irregular al menos 2 (los irregulares son más diagnósticos).

Reglas de higiene de evaluación¶

Cero solapamiento con train + val. Hashea el par prompt + expected de cada probe (tras normalización: quita espacios, pasa a minúsculas). Compara con el hash de cada frase de train+val. Cualquier colisión → rechaza la probe. Función de hash: SHA256.
Ninguna probe es una copia modificada de un ejemplo de train. Más estricto que (1). Si dos frases difieren sólo en la elección incidental de un sustantivo (at the office → at the school), son "la misma probe" a efectos de filtrado. Usa una forma normalizada (forma verbal y marcador de tiempo preservados; otros sustantivos de contenido reemplazados por <NOUN>) y hashea eso.
Los autores de probes no ven los datos de train al redactarlas. Operacionalmente: Claude escribe probes iniciales a partir de la spec §A13 y la lista de verbos, no de data/processed/train.jsonl. (Esto es estricto; en la práctica, Claude ha visto el generador del corpus y por tanto las probes reflejan sus convenciones. Reconoce el sesgo en el informe.)
El probe set está versionado. Las probes se comitean a git como JSONL. El SHA256 del archivo de probes (ordenado por id) se registra en cada REPORT.md.
Ninguna probe se modifica tras su primer uso. Si se descubre que una probe es ambigua, márcala deprecated: true y añade un reemplazo con id nuevo. No cambies una probe silenciosamente — los informes históricos dejarían de ser comparables.

La categoría adversarial¶

Las probes adversariales prueban los casos frontera donde las reglas ingenuas dan respuestas equivocadas. Categorías (objetivo 3-5 probes por categoría):

Sobre-regularización (verbos irregulares). goed en vez de went. eated en vez de ate. writed en vez de wrote. comed en vez de came. Trampa para un modelo que aprendió verbo + ed = pasado pero no memorizó las formas irregulares.
Concordancia de persona errónea (falta la -s de 3sg). She work hard. He go to school. It have a name. Trampa para un modelo que no interiorizó la regla de la -s en 3sg.
Tiempo erróneo para el marcador temporal. Yesterday I work. (debería ser pasado simple worked.) Tomorrow she went. (debería ser futuro will go / is going to go.) Now he ate. (debería ser presente.) Trampa para un modelo que ignora el contexto temporal.
Desajuste auxiliar (aspecto perfecto). She have eat. (debería ser She has eaten — tanto have→has por 3sg COMO eat→eaten por past-participle.) Pone a prueba dos reglas a la vez.
Desajuste de forma EN↔ES. Prompt en inglés (Yesterday I ___ to the store.), conjunto de candidatas que contiene tanto went (correcto) como fui (la forma ES correcta pero idioma equivocado). Trampa para un modelo bilingüe que confunde idiomas.
Plural / fuera de alcance. We work — según §A13, los plurales están fuera de alcance. Una probe que pida al modelo clasificar esto debería arrojar ambiguous. Un modelo que con confianza la etiqueta como incorrect (porque "we" no estaba en train) revela fragilidad.

Cada probe adversarial tiene un reason_code que apunta a su categoría. El eval REPORT desglosa la accuracy adversarial por categoría, de forma que puedas ver "el modelo maneja bien la categoría 1 (sobre-regularización) pero falla la 4 (desajuste auxiliar)".

Sembrar el probe set¶

scripts/build_probes.py (Claude lo provee al abrir la fase) genera el JSONL de probes de forma determinista:

python scripts/build_probes.py --seed 42 --out data/eval/probes.jsonl
python scripts/build_probes.py --seed 42 --adversarial --out data/eval/adversarial.jsonl

Reejecutarlo con la misma semilla produce ficheros byte-idénticos. La semilla está comiteada en el script; cambiarla es un evento versionado.

Errores comunes al escribir probes¶

Ejemplos a mano que parecen todos iguales. La variedad importa. Mezcla sujetos (nombres propios, pronombres, sustantivos comunes cuando se permita), marcadores temporales (yesterday, every day, tomorrow, last week, right now), formas de frase.
Ejemplos donde el contexto completo importa. Una probe debe poder evaluarse sólo a partir del prompt. Si la gramaticalidad depende de algo fuera de la frase, la probe es ambigua (etiquétala así).
Etiquetas ambiguas confundidas con correctas. Algunas frases se leen bien tanto en 2sg como en plural (You work hard.). Márcalas ambiguous, no pretendas que son inequívocamente correctas.
Sobre-representación de un verbo. La accuracy agregada queda dominada por el verbo sobre-representado. Atente a la tabla de cobertura.
Probes adversariales que el modelo no podría conocer. Una probe que prueba conocimiento de un verbo fuera del set de 20 es injusta. Permanece dentro del alcance.
Olvidar la cobertura en español. La mitad del currículo es bilingüe según §A13. Un probe set sólo en EN oculta fallos del lado español.

Control de versiones del probe set¶

Las probes viven en:

data/eval/probes.jsonl — probes core.
data/eval/adversarial.jsonl — probes adversariales.
data/eval/probe_prompt.txt — la plantilla de prompt fija usada para consultar al modelo.

Los tres están en git. Los cambios se versionan. El eval REPORT.md registra el SHA256 de los tres ficheros.

Cuando se añada o quite una probe, sube la versión del probe set (semver: probes_v_1_2_0.jsonl si lo quieres así, o simplemente confía en el SHA de git). La Fase 20 arranca con v0.1.0; se espera crecimiento.

Comprobaciones del probe set (el script `validate_probes.py`)¶

Antes de cualquier run de evaluación, el arnés valida el probe set:

Si alguna comprobación falla, el arnés se niega a ejecutar y explica qué probe causó el fallo. Esta es la regla de mentalidad de seguridad: no produzcas números a partir de un eval set roto.

Recapitulación en un párrafo¶

Una probe es un ejemplo etiquetado curado a mano, validado por schema, libre de leak y marcado con verbo, tiempo, persona, idioma y regularidad para troceo. La rejilla es 20 verbos × 5 tiempos × 3 personas × 2 idiomas; muestreamos ~60 probes core + 20 adversariales que cubren los slices. Las probes adversariales prueban los casos frontera (sobre-regularización, persona errónea, tiempo erróneo, desajuste auxiliar, desajuste EN↔ES, fuera de alcance). Las probes se versionan en git, se validan antes de cada run de evaluación y nunca se modifican silenciosamente. El probe set es el instrumento de medida; su calidad acota el valor de la evaluación.

Siguiente: lab/00-probe-schema.md.