Una memoria más larga

En el capítulo anterior dejamos a nuestra máquina atrapada en un presente perpetuo. El modelo de bigramas solo podía recordar el último carácter que había leído o escrito. En cuanto avanzaba al siguiente, olvidaba todo lo anterior.

Ese era precisamente el origen de muchos de sus errores: situaciones que para nosotros son distintas, para la máquina parecían exactamente iguales.

¿Cómo podemos darle un poco más de contexto? La idea más sencilla es dejarle mirar un poco más atrás. ¿Cambia eso sus apuestas?

Un poco más de contexto y las cosas cambian bastante.

A partir de ahora, para no repetir «ventana de dos letras» o «ventana de tres letras», vamos a llamar a ese tamaño de ventana N. Nuestro viejo modelo de bigramas era, simplemente, un modelo con N=1. Veamos cómo construir uno con N=2.

Si queremos darle a la máquina una memoria de dos caracteres, tenemos que pensar cómo adaptar la herramienta que construimos en el capítulo anterior. La pregunta es cuánto hay que cambiar.

¿Necesitamos una máquina nueva? ¿O podemos aprovechar la que ya tenemos? Veámoslo con un ejemplo pequeño.

Si te fijas al avanzar paso a paso, la mecánica de contar es idéntica. Lo único que está cambiando aquí es que ahora registramos parejas en lugar de letras sueltas. Esto parece un detalle menor, pero tiene un impacto enorme en el tamaño de lo que estamos construyendo. Vamos a verlo con un texto real de Shakespeare y a fijarnos en cómo crece la tabla, empezando solo por la letra «a».

Ese número no sale de la nada. Para entender de dónde viene, dejemos la tabla completa a un lado y fijémonos en una parte mucho más pequeña.

Pon una tabla al lado de la otra. Todo este bloque ocupa exactamente el mismo espacio que nuestro viejo modelo de bigramas. Es como si cada letra necesitara su propio bigrama; y como hay 27 letras posibles, necesitamos 27 copias. Por eso la tabla crece de esta forma.

¿Y qué pasa si seguimos ampliando la ventana?

Al subir el tamaño de la ventana a N=3 o N=4, lo único que hacemos es añadir más filas a la misma estructura. El modelo que diseñamos en el primer capítulo no era inútil; simplemente le faltaba espacio para retener algo más de contexto. Hemos comprobado que la arquitectura es escalable. Veamos si de verdad escribe mejor y merece la pena.

Ya tenemos nuestra tabla llena de cuentas y porcentajes sacados de Shakespeare. Ahora viene lo interesante: usar esa información para escribir texto nuevo. ¿Cómo lo hace, exactamente, una máquina que solo sabe leer números de una tabla?

Si la interfaz te ha resultado familiar, es porque estás viendo exactamente el mismo proceso de antes: buscamos la pareja actual en nuestra gran tabla, convertimos sus conteos en porcentajes y tiramos el dado virtual para elegir la siguiente letra. El ciclo vuelve a empezar sin ninguna regla nueva.

Y como esta misma lógica vale para cualquier tamaño de ventana, podemos poner a competir a varios modelos a la vez y ver de verdad la diferencia.

Si lo piensas fríamente, es bastante sorprendente. Hemos partido literalmente de la nada: una máquina en blanco que no sabía una sola regla gramatical y que, a base de pura estadística y de contar letras, ha acabado escribiendo frases que engañan a la vista. No es que la máquina esté pensando, pero desde luego funciona.

Viendo la mejora tan evidente al pasar de un bigrama a un modelo de 6 letras, la intuición nos dice cuál es el siguiente paso. Si queremos un modelo perfecto, solo tenemos que subir la N. Con una ventana de 40 letras —suficiente para recordar una frase entera— deberíamos tener un sistema capaz de escribir textos largos sin equivocarse. Vamos a intentar construirlo.

Para construir un modelo con N=40 solo tenemos que seguir nuestra propia regla: coger el tamaño del modelo anterior y multiplicarlo por 27. Subamos el dial poco a poco.

El crecimiento exponencial es implacable. Llega un punto en el que la tabla es físicamente imposible de guardar en ningún ordenador del planeta.

De acuerdo, el tamaño es un problema. Pero el almacenamiento siempre se acaba abaratando. Imaginemos por un momento que tenemos discos duros infinitos y podemos guardar la tabla que queramos.

Y fíjate en lo que pedimos al guardarla. Con una ventana de cuarenta letras —una frase entera— cada fila ya no responde «qué letra sigue a th»; responde algo mucho más ambicioso: qué viene después de esta frase completa. La llave de cada fila es, prácticamente, una frase entera.

Aun así, incluso sin el límite físico, el método tiene un fallo mucho más grave.

Tras haber leído todo el texto de Internet, la inmensa mayoría de la tabla sigue vacía. Y es lógico que lo esté: hay combinaciones de letras que sencillamente nunca van juntas porque no significan nada. Si nunca aparecen en el mundo real, parece que no debería importarnos que su celda sea un cero. ¿Qué problema tiene, exactamente, que la tabla esté vacía?

Pruébalo tú: escríbele una frase de lo más normal y mira qué fila busca.

Este es el problema de tener una tabla vacía. «The quantum elephant» es una frase extraña, pero no tiene nada de incorrecto. Aunque nunca la hayas oído antes, probablemente podrías inventarte varias formas razonables de continuarla. Nuestra máquina no puede.

Al basarse únicamente en coincidencias exactas, necesita haber visto esa combinación concreta en algún momento de su entrenamiento. Cuando intenta buscarla en la tabla y no encuentra nada, se queda sin información sobre la que apoyarse.

Y este problema no desaparece por mucho que añadamos datos. Por mucho texto que recopilemos, siempre existirán frases nuevas, combinaciones inesperadas, expresiones que nadie había escrito antes. El lenguaje cambia constantemente; la tabla, no. Por eso, cuando la máquina se topa con algo que cae fuera de lo que ha memorizado, se queda sin respuesta.

Pero aquí aparece una duda interesante. ¿El problema son de verdad los huecos de la tabla? ¿O hay algo más profundo que se nos escapa?

El ejemplo del elefante cuántico nos mostró qué ocurre cuando la máquina se topa con una combinación que nunca había visto. Podríamos pensar que ese es el problema principal: si la tabla está vacía, es normal que no sepa qué hacer.

Pero resulta que la máquina sigue fallando incluso cuando la información que necesita sí existe en la tabla. Veámoslo con un ejemplo mucho más cotidiano que el elefante.

Para nosotros es obvio que, si un perro duerme, un gato también puede hacerlo. Sabemos que ambos son animales y comparten comportamientos; no necesitamos haber leído la frase exacta para intuir cómo sigue.

Pero fíjate en la tabla. Para el modelo, «el perro» cae en una fila y «el gato» en otra que está a miles de filas de distancia. Son cajas herméticas, sin ningún puente entre ellas. A la máquina le da exactamente igual que ambos sean animales: para ella son dos secuencias de letras distintas que no tienen nada que ver la una con la otra.

Si no ha memorizado la coincidencia exacta, se queda ciega. No sabe generalizar, no sabe aplicar la lógica.

Es, literalmente, un loro con muy buena memoria.

Hemos llevado el método de contar letras hasta su límite físico y lógico. Y aunque nos ha servido para llegar muy lejos, este muro es infranqueable.

Si queremos construir una verdadera inteligencia artificial que pueda sobrevivir a frases que nunca ha visto, tenemos que abandonar la idea de usar tablas gigantes. Tenemos que cambiar el paradigma por completo.

En lugar de construir una máquina que se dedique a contar y memorizar el pasado, necesitamos construir una máquina que pueda intentar adivinar, darse cuenta de que se ha equivocado, y ajustar sus engranajes internos para no volver a fallar. Necesitamos un sistema que, en lugar de contar, sea capaz de aprender.

Y para lograr eso, los ingenieros tuvieron que dejar de mirar a los libros de estadística y empezar a mirar a la biología.

Bienvenido a la era del aprendizaje.