Builders de EdTech con LLMs: el bug no está en tu prompt, está en tu arquitectura

Estaba probando ejercicios de español y me topé con un momento extraño.

En la pantalla había una tarea:

```text Traduce al español: Probablemente son las tres de la tarde.

Pista: Traduce usando futuro simple.

Respuesta correcta: Serán las tres de la tarde. ```

Formalmente, todo cuadraba.

El ejercicio estaba asignado al tema correcto. En la teoría sí aparecía que el futuro simple en español puede expresar no solo futuro, sino también probabilidad en el presente: Serán las cinco — "Probablemente son las cinco".

Y aun así me quedé clavado en una pregunta simple:

``text ¿qué tiene esto que ver con este tema? ``

Aquí es donde suele empezar la mala defensa ingenieril del producto.

"Pero si la regla está en la teoría".

Está. ¿Y qué?

Que la receta esté en la cocina no significa que la persona sepa cortar cebolla, sujetar un cuchillo y no convertir la cena en un simulacro de incendio. La teoría no es habilidad. La teoría solo dice qué debe entenderse. La práctica tiene que saber qué debe aprender a hacer la persona.

Ahí no había término medio.

El ejercicio era correcto. Y aun así, malo

Al principio quise echarle la culpa al generador.

Claro: otra vez el modelo creó un ejercicio raro, lo pegó donde no debía, y ahora toca arreglar el prompt.

Pero no.

Lo comprobé. La respuesta era correcta. El tema era correcto. La regla estaba en la teoría.

O sea, el bug no estaba donde era cómodo buscarlo.

El bug estaba en la suposición: si la regla está escrita, ya puedo usarla.

No puedo.

Para llegar a Serán las tres de la tarde, no bastaba con "recordar el tema". Necesitaba dar varios pasos pequeños que nadie me mostró en pantalla:

• ver en "probablemente son" no un futuro, sino una suposición sobre el presente;
• conectar esa suposición con el futuro simple;
• recordar cómo se conjuga ser en futuro;
• no confundir será con serán;
• armar la frase completa sobre la hora.

En la pantalla es una sola tarea.

En la cabeza, una escalera.

Yo estaba abajo, y el sistema ya me preguntaba desde el último peldaño.

Nos saltamos el mapa de práctica

Ahí estaba el agujero real.

Teníamos teoría. Teníamos un generador de ejercicios. Entre ambos parecía que todo encajaba: coges el tema, lanzas la tarea, compruebas la respuesta.

Pero es como decir: "Tenemos un mapa de la ciudad y un taxi, así que la ruta se construye sola".

No se construye.

El mapa dice que las calles existen. El taxi sabe conducir. Pero la ruta es una entidad aparte.

En el aprendizaje también hace falta esa entidad.

Yo la llamo Practice Map.

No "otra teoría más". No "otro prompt más". Sino un mapa de qué pequeñas acciones hay dentro de un tema y en qué orden entrenarlas.

En el esquema antiguo, el tema era un contenedor demasiado grande. Dentro cabían reglas, excepciones, construcciones, formas, ejemplos y trampas. El generador recibía el tema entero e intentaba crear un ejercicio.

Pero no sabía qué operación concreta debía entrenar yo en ese momento.

A esa pequeña operación ahora la llamo átomo objetivo de aprendizaje.

No "tiempo futuro" en abstracto.

Sino en concreto: reconocer una suposición sobre el presente, elegir futuro simple para esa suposición, recordar la forma serán, armar el patrón corto Serán las tres.

Estas cosas se pueden explicar, entrenar, medir y vincular con un error. Con un tema grande eso no funciona: es demasiado amplio para saber dónde exactamente fallé.

Qué átomos no veíamos

Cuando desmonté este ejemplo, se hizo evidente cuánto habíamos escondido dentro de un solo tema.

Teníamos el tema: futuro simple, ir a + infinitivo, presente. El tema tenía teoría. La teoría tenía ejemplos.

Pero debajo había átomos que no tratamos como ciudadanos de primera:

• nivel de vocabulario: ¿esta palabra le corresponde al alumno ahora mismo?;
• forma verbal: ¿conoce exactamente esta forma, no "el verbo en general"?;
• frecuencia: ¿estamos entrenando una construcción viva o un jarrón de museo?;
• ejemplo de uso: ¿ha visto una expresión parecida en una frase normal?;
• sintaxis y morfología: ¿entiende qué se conecta con qué?;
• vecinos semánticos: ¿confunde ideas cercanas, como futuro y suposición sobre el presente?

Eso son los átomos objetivo de aprendizaje.

No "tema completado". No "el ejemplo aparece en la teoría". No "el generador sabe crear una frase".

Sino en concreto:

• ¿sé reconocer la señal "probablemente son"?;
• ¿sé elegir futuro simple para una suposición?;
• ¿conozco la forma serán?;
• ¿entiendo por qué aquí no es será?;
• ¿he visto esta construcción antes de que me pidieran armarla yo solo?

Eso era lo que faltaba.

No los datos como referencia.

Sino los átomos como objetivos de entrenamiento.

Mientras no estén identificados, el sistema mira el ejercicio desde fuera: el tema coincide, la respuesta existe, todo bien.

Pero por dentro hay cinco habilidades pequeñas distintas, y cualquiera de ellas puede ser el agujero.

Un átomo no vive en un solo tema

La siguiente trampa se abre enseguida: querer atar cada átomo a un único tema.

Por ejemplo, la forma serán.

Aquí la necesitamos porque hablamos de suposición sobre el presente: Serán las tres. Pero la forma en sí no pertenece solo a este tema.

Aparecerá en el futuro simple normal. En ejercicios sobre ser. En frases sobre la hora. En comparaciones entre "será" y "probablemente es ahora". En otros lugares donde el alumno ni siquiera piensa en nuestro bonito tema de la teoría.

Si hacemos que el átomo sea parte de un solo tema, volvemos a tener el mismo lío. Solo que más fino.

Es más correcto pensarlo así:

``text tema = contexto átomo = acción que se entrena conexión = para qué se necesita este átomo exactamente aquí ``

En unos casos es obligatorio. En otros, de apoyo. En otros, previo: sin él no se puede avanzar. Y a veces simplemente útil, pero no principal.

Entonces el sistema empieza a ver no "el tema entero", sino el tejido de habilidades que hay debajo.

Un átomo tiene etapas

Pero ni con eso basta.

Aunque hayamos encontrado el átomo, no podemos ponerlo a prueba directamente en combate.

"Reconocer" y "producir" son habilidades distintas.

Puedo identificar la regla cuando veo un ejemplo hecho. Eso no significa que sea capaz de armar la frase desde cero.

Con serán, la escalera es más o menos así:

• ver un ejemplo terminado y entender que es una suposición sobre el presente;
• elegir futuro simple entre opciones parecidas;
• recibir ser y la persona correcta, recordar la forma;
• insertar la forma en un patrón conocido;
• solo entonces armar la respuesta sin pista.

No son temas nuevos. Son peldaños de dominio de un único trozo pequeño del mapa.

Y cada peldaño tiene su propia dificultad.

Si el sistema no ve esto, no sabe dónde me rompí. Solo ve la respuesta final. Y lo que yo necesito no es que evalúen el final, sino el siguiente peldaño razonable.

Ahora no solo el generador va a tener que currar

Y de aquí sale una hipótesis nueva: /go ya no puede simplemente elegir un tema y pasárselo al generador.

Antes la cosa parecía casi cómoda:

``text aquí tienes el tema haz un ejercicio comprueba la respuesta ``

Ahora eso no basta.

Antes del generador tiene que aparecer otra capa de trabajo. Coge el tema y lo descompone en átomos: qué estamos entrenando exactamente ahora, en qué etapa, con qué palabras, con qué forma verbal y con qué trampa.

Solo después de eso el generador recibe el encargo.

No "haz algo sobre futuro simple".

Sino algo así:

``text entrenamos: reconocer suposición sobre el presente etapa: elección entre construcciones parecidas vocabulario: solo palabras conocidas forma: ser en futuro simple ``

O así:

``text entrenamos: la forma serán etapa: insertar en un patrón dado patrón: ___ las tres trampa: será vs serán ``

Ahí es cuando el generador por fin ocupa su sitio.

No decide qué enseñar. No adivina qué trozo del tema importa ahora. No se hace pasar por pedagogo.

Hace un ejercicio concreto para un átomo concreto.

Y /go deja de ser un botón de "dame el siguiente". Se convierte en un pequeño orquestador: elegir tema, encontrar el agujero en la Practice Map, entender la etapa, montar el encargo, actualizar el progreso del átomo después de la respuesta.

Las pistas y las explicaciones también se alimentarán de este mapa. Pero eso ya es consecuencia. El trabajo principal viene antes: entender qué átomo estamos entrenando.

Hay más trabajo. Pero es trabajo honesto.

Si no, cada vez estaremos cruzando los dedos para que el generador acierte no solo con el tema, sino con el micropaso de aprendizaje que toca.

Lo que ahora considero la arquitectura correcta

Después de este error veo la arquitectura de otra manera.

Antes pensaba: hay un tema, hay una teoría, hay un generador. Si todo está bien conectado, el sistema ya enseña.

Ahora pienso distinto.

Entre la teoría y el generador tiene que vivir una Practice Map: un mapa de las pequeñas acciones de las que está hecho realmente el dominio de algo.

No "aprendemos futuro simple".

Sino:

• reconocemos la suposición sobre el presente;
• la distinguimos del futuro;
• elegimos la construcción correcta;
• recordamos la forma del verbo;
• armamos un patrón corto;
• comprobamos en qué paso se rompió la persona.

Solo después de eso /go puede elegir con honestidad el siguiente ejercicio.

Si no, no elige el siguiente paso. Elige simplemente el siguiente intento.

Desde fuera la diferencia es pequeña. En la pantalla seguirá habiendo tarea, respuesta y corrección.

Por dentro la diferencia es enorme.

En el primer caso, el sistema sabe qué átomo está entrenando.

En el segundo, confía en que el generador haya acertado por casualidad en el sitio correcto.

Esa confianza ciega es lo que hay que eliminar.

Y yo pensaba que bastaba con conectar tema, teoría y generador.

Qué ingenuo fui.