La arquitectura encoder-decoder

Este bloque empieza con la arquitectura ya montada. La lección anterior, sobre modelos de secuencia a secuencia, encadenó dos redes —una que lee la entrada y la resume en un vector, otra que escribe la salida a partir de ese resumen— y las entrenó de punta a punta sobre una tarea de juguete. Lo que este bloque va a mirar con lupa es el punto donde las dos se tocan. Pero antes hay que cambiar de tarea, porque aquel juguete le perdonaba tres cosas a la arquitectura y traducir no le perdona ninguna.

Mira una frase y su traducción: ayer leí un libro muy bueno se convierte en yesterday i read a very good book. Entran seis tokens y salen siete, y el que sobra es i, un pronombre que en la entrada no aparece por ningún lado —el español lo lleva dentro de la conjugación del verbo y el inglés tiene que escribirlo aparte—. muy bueno, que en español va detrás del sustantivo, en inglés se le adelanta. Y esta no es «la» traducción, sólo una: yesterday i read a really good book sirve igual. Longitud distinta, orden distinto y respuesta no única. Son tres cosas.

Las tres tienen la misma forma: la tarea de juguete respondía por el modelo preguntas que en una tarea real tiene que contestar él.

La primera es el vocabulario. Cuando la salida se escribe con los mismos símbolos que la entrada hay un solo vocabulario, y cada una de sus entradas sirve igual para leer que para escribir. Traducir necesita dos, de idiomas distintos y de tamaños distintos: el libro que entra y el book que sale no son la misma entrada de la misma tabla, y el decoder no tiene que producir jamás una palabra española.

La segunda es la longitud, y es la que más cuesta. Un bucle que escribe tantos tokens como tenía la entrada funciona mientras la tarea garantice que entrada y salida miden lo mismo; en cuanto no lo garantiza, la longitud de la salida deja de ser un dato y pasa a ser una incógnita. Tiene que salir de algún sitio, y el único sitio disponible es el propio modelo: el vocabulario de salida gana un token que significa «he terminado», y escribirlo es lo que detiene la generación.

La tercera cambia lo que hay que leer en la salida del decoder. Si una frase admite varias traducciones aceptables, señalar un token no es la respuesta honesta; repartir probabilidad entre todos sí lo es. Y el decoder ya hacía eso —de cada estado cuelga una distribución, no un token—, así que lo que cambia no es la red sino qué significa lo que produce: en cada paso, una columna de probabilidades sobre el vocabulario de salida, y la frase escrita es un camino a través de esas columnas.

Dos vocabularios y una salida que se detiene sola

Fijemos los dos vocabularios: $V_x$ para la entrada y $V_y$ para la salida. La entrada es una secuencia de tokens $x_{1:T_x}$, cada $x_j$ una entrada de $V_x$; la salida es otra, $y_{1:T_y}$, sobre $V_y$, y las dos longitudes son independientes. El encoder no cambia nada respecto de la lección anterior: lee la entrada de principio a fin con la recurrencia de siempre y entrega su último estado,

donde $\mathbf{o}_{x_j} \in \{0,1\}^{\lvert V_x \rvert}$ es el one-hot del token $j$-ésimo y $\mathbf{W}^{\text{enc}}_{xh} \in \mathbb{R}^{d_h \times \lvert V_x \rvert}$ tiene una columna por cada entrada de $V_x$. El decoder tampoco cambia de recurrencia, y arranca donde el encoder terminó, $\mathbf{s}_0 = \mathbf{c}$. Lo que cambia es su salida, que ahora vive en el otro idioma:

con $\mathbf{W}_{hy} \in \mathbb{R}^{\lvert V_y \rvert \times d_h}$: una fila por cada entrada de $V_y$, y es la única forma del modelo que sabe cuántas entradas tiene el idioma de llegada. Nada obliga a que $\lvert V_x \rvert$ y $\lvert V_y \rvert$ se parezcan.

Dónde vive el final de la frase

Ahora el token que faltaba. A $V_y$ —y sólo a $V_y$— le añadimos una entrada más, <EOS>, el símbolo de fin de secuencia, y toda traducción del entrenamiento termina en ella: si la salida correcta tiene $n$ tokens, la secuencia de entrenamiento tiene $T_y = n + 1$ y el último es $y_{T_y} = \texttt{<EOS>}$. La pérdida es la de la lección sobre modelos de secuencia a secuenciaBlock 3 · Lesson 8Seq2seq: de secuencia a secuenciaDos RNN encadenadas: un encoder que lee la secuencia de entrada y la comprime en un solo vector de contexto, y un decoder que escribe una secuencia nueva a partir de ese vector. Entrena de punta a punta —el encoder aprende sólo por el gradiente que el decoder le devuelve en c— sobre una tarea de juguete, invertir tiras de símbolos, que se resuelve en el navegador. Funciona con las cortas y se degrada con las largas: toda la entrada, sea cual sea su longitud, tiene que caber en los mismos d_h números. Ese cuello de botella es la puerta al bloque 4., sin tocar una línea,

y ese detalle de contabilidad es todo el mecanismo: como la última posición está dentro del sumatorio, aporta su propio término, y el descenso de gradiente empuja hacia arriba la probabilidad de <EOS> exactamente ahí —y, por el mismo camino, hacia abajo en las posiciones anteriores, donde el token correcto es otro—. Aprender a parar es aprender a predecir un token más.

La consecuencia es la que hacía falta: $T_y$ ya no es un dato que reciba el bucle, sino algo que sale del modelo. Al generar, el modelo escribe token a token y para cuando el elegido es <EOS>. En el código habrá además un tope, max_len, para que un modelo mal entrenado no escriba indefinidamente; es una red de seguridad de la implementación, no parte del modelo, y conviene no confundir las dos cosas.

El decoder define una distribución sobre traducciones

Podemos escribir cualquier distribución sobre secuencias, sin suponer nada de nada, como un producto de distribuciones sobre un token cada una. Es la regla de la cadena de la probabilidad, aplicada posición a posición:

donde $y_{<i}$ es el prefijo $y_1, \dots, y_{i-1}$, lo ya escrito antes del paso $i$. Hasta aquí no hay arquitectura ninguna: la igualdad vale para cualquier modo de asignar probabilidades a secuencias. La arquitectura entra al decir qué mira cada factor, y lo que dice el encoder-decoder es esto:

Léela despacio, porque el bloque entero vive de ella. A la izquierda, el paso $i$ podría mirar la entrada completa; a la derecha, mira un vector. Cada uno de los dos condicionantes de la derecha está en un sitio concreto del modelo: $\mathbf{c}$ es el estado inicial $\mathbf{s}_0$, y el prefijo $y_{<i}$ entra realimentado token a token, de modo que ambos llegan al paso $i$ resumidos en $\mathbf{s}_{i-1}$. Y las probabilidades del factor son las coordenadas que ya calculamos: $P(y_i = k \mid y_{<i}, \mathbf{c}) = \hat{y}_{i,k}$.

Generar es recorrer el producto

Escribir una traducción es elegir un camino por esas columnas. El camino más barato de todos es tomar en cada paso la coordenada mayor,

realimentar el token elegido y seguir hasta <EOS>. Es la decodificación voraz, la misma de la lección sobre el modelo de lenguaje a nivel de carácterBlock 3 · Lesson 7Proyecto: un modelo de lenguaje a nivel de carácterLa RNN vanilla y la BPTT, juntas en una red que predice el siguiente carácter en cada posición: un texto de T caracteres son T ejemplos apilados, y la etiqueta de cada paso es, gratis, el carácter que viene. Se entrena con recorte del gradiente sobre unos miles de caracteres —pocos pasos, para caber en el navegador— y después escribe, realimentando lo que muestrea. La pérdida cae de ln 32 a alrededor de 2.5 y el texto pasa de ruido a español mal hecho —palabras cortas reales, cuasi-palabras largas, ni una frase con sentido—: es lo que aprende un modelo de caracteres, y decirlo sin adornos es la lección., y cuesta un paso por token de salida.

La concesión es que ese camino no es, en general, el más probable. Nada garantiza que el producto de los máximos sea el máximo de los productos: un token que gana su columna por poco puede dejar al decoder en un estado desde el que todo lo que sigue es malo, y la decodificación voraz no vuelve nunca sobre esa decisión. Buscar de verdad el mejor camino obligaría a puntuar $\lvert V_y \rvert^{T_y}$ frases, y eso no lo hace nadie; entre lo voraz y lo exhaustivo hay búsquedas intermedias —la habitual es el beam search— que este curso no cubre.

Un traductor de juguete en NumPy

Vamos a entrenar un traductor diminuto: un idioma de juguete con seis palabras en español y otro con siete en inglés. De juguete a propósito —la traducción automática de verdad no cabe en el navegador—, pero con las tres cosas que esta lección ha puesto sobre la mesa: dos vocabularios distintos, una salida cuya longitud decide el modelo, y una reordenación que obliga a esperar. Las frases españolas son verbo + sustantivo + adjetivo opcional, y su traducción mete un i al principio y adelanta el adjetivo al sustantivo. Ejecuta la celda y mira las parejas.

Compara las dos columnas de la derecha. La traducción lleva una palabra más que la frase —ese i que el español no escribe— y la secuencia que el decoder tiene que producir lleva una más todavía, porque <EOS> ocupa una posición como cualquier otro token y también hay que predecirlo: $T_y = T_x + 2$. Doce frases posibles en total, así que este modelo no va a aprender español —va a aprender esas doce—; lo que está a prueba es el mecanismo, no el traductor.

La celda siguiente monta las dos redes y entrena. La función paso es la de la lección anterior línea por línea: encoder hacia delante, decoder hacia delante con teacher forcing, vuelta del decoder y, colgada del gradiente en $\mathbf{c}$, vuelta del encoder. Lo único que cambia son los dos vocabularios —nx columnas a la entrada, ny filas a la salida— y el <EOS> que frase ya dejó puesto al final de cada objetivo.

La pérdida arranca cerca de $\ln 8 \approx 2.08$ —repartir la probabilidad por igual entre las ocho entradas de $V_y$, contando <EOS>— y baja hasta rozar el cero. Ahora la parte que importa: generar. El bucle de abajo no recibe la longitud de la salida por ningún sitio; escribe, mira si lo escrito es <EOS> y, si lo es, para. max_len está sólo por seguridad.

Dos cosas en esa tabla. La columna de longitudes: entran dos o tres tokens y salen tres o cuatro, uno más siempre, y ese número lo ha decidido el modelo al colocar <EOS> —no hay ningún range(len(x)) en el bucle—. Y el orden: cuando la frase lleva adjetivo, el modelo lo escribe antes que el sustantivo, aunque lo leyó después. Para hacerlo tuvo que retener el sustantivo mientras escribía el adjetivo, y todo lo que tenía para retenerlo era $\mathbf{c}$.

Comprueba tu intuición

Cuatro preguntas: por qué hace falta un token de fin, qué distribución define exactamente el decoder, si la decodificación voraz es óptima, y de dónde sale la habilidad de parar en el sitio.

La arquitectura ya está dicha con precisión, y esa precisión deja a la vista una línea incómoda: $P(y_i \mid y_{<i}, x_{1:T_x}) = P(y_i \mid y_{<i}, \mathbf{c})$. La igualdad no es un teorema, es una decisión de diseño, y afirma algo fuerte —que $d_h$ números bastan para todo lo que la entrada tenga que aportar a cualquier posición de la salida—. En un juguete de tres tokens nadie lo notaría. La pregunta es qué le pasa a esa afirmación cuando la entrada es una frase de verdad.

Esa pregunta tiene una respuesta que se puede medir, y es la lección siguiente, sobre el cuello de botella del vector de contexto. Allí la entrada se va alargando mientras se mira qué le ocurre a la salida, hasta ver dónde deja de aguantar la igualdad de arriba y por qué el sitio donde se rompe no depende de cuánto se entrene.