En el post anterior concluíamos que la teoría de la información de Shannon (con el concepto de entropía), unido a los árboles de decisión, constituían las herramientras principales para la creación de Akinator y sistemas similares. También es cierto que uno de los puntos más importantes en la concepción de dicha máquina es la capacidad de “aprendizaje” o realimentación que muestra a partir de las respuestas de la gente.

Akinator no es una máquina estática, que toma decisiones estáticas durante toda su “existencia”; más bien es una máquina dinámica, que se adapta a las nuevas entradas que la gente introduce. Intuitivamente podemos entender que el árbol que modela su comportamiento se va recalculando a medida que la gente introduce entradas nuevas, de este modo si las tendencias de la gente cambian a la hora de elegir un futbolista, por ejemplo, la máquina se adapta a dicho cambio y por tanto las preguntas variarán. El tema del aprendizaje es de por sí un tema amplísimo, de los más importantes quizá en el campo de la inteligencia artificial, y en mi opinión de los más apasionantes, por ello no voy a tratarlo en este post, sino que dedicaré tiempo a ello más adelante.

Además, tampoco voy a hablar del algoritmo ID3 ni de Quinlan, su creador, puesto que me parece que lo interesante de estos posts era saber intuitivamente cómo era concebible Akinator, sin entrar en detalles más técnicos que a muchos de vosotros quizá no os interese (no obstante, si os interesa, es bastante sencillo entender cómo funciona dicho algoritmo, así que adelante, preguntad).

En este post por tanto quiero dejar algunas reflexiones abiertas; no se basan en mi opinión, son sólo reflexiones, así que a ver si os animáis, las criticáis o las defendeis y levantamos nuevamente el blog después de este pequeño letargo.

Dado un dominio del conocimiento concreto, tanto para humano como para una máquina, y entendiendo intuitivamente la inteligencia:

Reflexión 1: El test de Turing. Si un humano que observa un ente (ya sea humano o máquina) y aprecia en dicho ente un comportamiento que pueda entenderse como inteligente, ¿está observando inteligencia?. De otro modo, si veo a una persona intentando adivinar el pensamiento de otra con preguntas, y después veo el comportamiento de Akinator, presentando ambos un comportamiento inteligente, ¿puedo concluir que ambos son inteligentes?.

Reflexión 2: La habitación China. Si una máquina que muestra un comportamiento inteligente, implementa en su interior un comportamiento que es totalmente determinista, con unos algoritmos concretos y un conocimiento dado, ¿es la máquina inteligente?. Si respondemos que no lo es, sino que sólo atiende a lo que tiene “programado”, entonces ¿por qué entendemos a un humano como un ser inteligente? es decir, en realidad no sabemos que hay en lo más profundo del cerebro humano.

Conclusión:
Tenemos una máquina que responde de forma inteligente, y de la que conocemos totalmente su funcionamiento interno.
Por otro lado tenemos un humano que también responde de forma inteligente y del cual no conocemos su funcionamiento interno.
De esto ¿cómo podemos concluir o discernir dónde hay inteligencia?

En el post anterior, os presenté a Akinator, un programa online que, tras hacernos una serie de preguntas, nos mostraba aquel personaje en el que estuviéramos pensando, al estilo de 20p, el programa de Cuatro, o de 20q, que también mostramos por aquí en alguna ocasión.

Discutimos por qué no era posible que el funcionamiento de dicho programa se basase en una búsqueda en una amplia base de datos, y terminé comentando que este post daría la respuesta parcial, puesto que lo que comentaré a continuación es un acercamiento a la técnica que está por detrás (por supuesto, la implementación concreta puede variar en matices).

Primero conviene definir lo que es un árbol de decisión, al menos para que se entienda intuitivamente. Y podemos entender por árbol de decisión a aquella estructura de datos (aunque siempre es implementable a traves de reglas if-then) jerárquica, en la que un nodo superior tiene descendientes, que a su vez poseen otros descendientes, y que éstos nunca se unen con sus nodos superiores.

Con un árbol de este estilo, bien construido, se pueden ir haciendo preguntas desde más generales (más arriba del arbol), a más específicas (más abajo), trazando un camino que nos llevará a una hoja del árbol (un nodo sin descendientes), el cual supondrá la solución al problema. Tenemos por tanto una buena estructura que, de estar bien construida, puede guiarnos a través de un relativo número corto de preguntas hacia una solución. El problema aquí es evidentemente cómo construir tal árbol, y cómo hacer que aprenda, o que se modifique automáticamente para que añada otras preguntas u otros nodos que puedan ser solución también.

El problema del aprendizaje lo voy a dejar para otra ocasión, porque de momento con entender cómo se puede construir eficientemente un árbol de búsqueda será suficiente para tener una idea más intuitiva del funcionamiento de Akinator.

En cuanto a la construcción, vamos a pensar en qué es lo que nos interesa, para ir construyendo una explicación desde ahí. Tenemos información en bruto, y queremos construir un árbol de decisión con el cual podamos “ordenar” dicha información. Nos interesa que las preguntas más generales (las de más arriba del árbol), limiten lo más posible las soluciones restantes, o dicho de otro modo, que eliminen más opciones, y queremos que ocurra esto durante todo el camino que se trazará, para converger lo más rapidamente posible a una solución.

En esta situación necesitamos de algún mecanismo que nos haga saber qué información es más valiosa a la hora de discernir cómo colocarla; podemos verlo como aquella información que nos da más información, que aunque parezca una redundancia es la respuesta. Respuesta que viene dada precisamente a raíz de la teoría de la información de Shannon, en la que se define entropía como la cantidad de información que aporta un valor “x”. Y que matemáticamente se expresa como:

Con ayuda precisamente de la entropía podemos obtener, a partir de un conjunto de variables (que serían los posibles caminos a seguir), qué variable en concreto expresa mayor información (qué camino limita más el espacio de soluciones, de modo que podamos ir montando la estructura del árbol).

Para entender el concepto en concreto, voy a tratar de aplicarlo al caso de Akinator. En el pasado post comenté que tras realizar las preguntas a un compañero, o pensándolas nosotros mismos, caeríamos en la cuenta de que son varios personajes los que pueden coincidir con la “descripción” que ofrece el par pregunta-respuesta. Ahora supongamos que Akinator funcionase adivinando colores, así de simple. Tras un número N de interacciones con Akinator, éste tendría guardado el número de colores que habrá elegido la gente a lo largo de dichas interacciones. Supongamos que tras realizar 10000 preguntas, la gente ha elegido el rojo 8000 veces. Esto es 8000/10000 veces, lo que supone una mayoritaria elección por el rojo. Si aplicamos la fórmula, teniendo en cuenta que la variable en este caso es “Xrojo”, y que la probabilidad de “Xrojo”, es 8000/10000, tenemos que la entropía es mucho menor que para algún otro color cuya probabilidad fuese más baja. Es decir, nos aporta más información saber si el color es el verde, que si es el rojo, puesto que el rojo es más probable. Ahora pensemos en el momento en el que Akinator tiene que darnos una respuesta: gracias a la división que se ha hecho haciendo uso de la entropía, hemos convergido a un número X de soluciones finales, y ahora Akinator está en disposición de pensar que la respuesta que estamos pensando es la más probable, o la que más gente haya pensado antes.

Por tanto, la entropía supone una herramienta que podemos utilizar para construir árboles de decisión, de modo que incluyamos las preguntas más acertadas, que serán aquellas cuya respuesta nos aporte mayor cantidad de información, lo cual supone que limita más la respuesta (reduce en mayor medida el espacio de soluciones restantes).

Quinlan desarrolla el algoritmo ID3 (que se basa en lo explicado pero con algunos cambios), como medio para construir árboles de decisión. Como suele ser habitual, el post se alarga más de lo recomendable, asi que lo dejamos para el siguiente, en el cual trataré de construir un árbol por medio del ID3.

El post de hoy está dedicado a Akinator, que es una especie de “demo” que la empresa Elokence puso en marcha allá por 2007 para demostrar lo bien que eran capaces de organizar información que no estuviera total y correctamente registrada en una base de datos. Esta empresa trabaja precisamente con información, organización de bases de datos, y como veréis en un momento, bastante relación guarda con la funcionalidad de Akinator.

¿Qué es Akinator? En sí no es más que un juego tipo 20q, del que ya hemos hablado por aquí antes, o tipo 20p, un programa que echan en la cadena televisiva Cuatro. La gracia del juego ya la conoce casi todo el mundo. Un pequeño programa que va haciéndote preguntas desde la interfaz web para intentar “adivinar” aquello en lo que estés pensando. En el caso de 20q se trataba de objetos, animales, etc, etc, y en el caso de Akinator se trata de personajes reales o de ficción, lo que le otorga un punto de gracia, porque además la interfaz está mucho más currada y es bastante más visual que en el caso anterior.

Lo que quería comentar en este post doble es un poco el funcionamiento que se percibe desde el lado del teclado. Normalmente, la gente que no está en el mundillo queda bastante sorprendida con los resultados y para algunos es algo casi mágico. Después nos encontramos a la gente que está algo más metida y dan sus opiniones, que la mayoría de veces son algo como:

“en realidad, deben tener una base de datos muy grande, gigantesca, y con las preguntas que te va haciendo pues van eliminando posibilidades hasta que queda una y te la ofrecen”

No es correcto, por varios motivos, y voy a intentar explicar los que pueda, dejando claro que yo tampoco sé la verdad absoluta de la implementación que está detrás. Primero vamos a ver por qué seguro no es posible que se trate de esa solución de base de datos gigantesca. Veamos, tenemos una aplicación multiusuario que introduce consultas concurrentes a una base de datos gigantesca (que pueda o no estar clonada), esto entendemos que supone un retardo, que puede ser además bastante grande cuando el espacio de búsqueda es amplio, como es el caso. El retardo realmente se aprecia en la interfaz web, pero teniendo en cuenta eso, que es una interfaz web, realmente es un retardo bastante pequeño.

Lo siguiente es la información. ¿Cómo busca la información?, de acuerdo, si te pregunta si el personaje vive en España, y dices sí, pues buscará “... where country is 'Spain' ” [parte de una consulta SQL]. Esto podemos imaginarlo, pero cuando pregunta ¿es famoso?, ¿es real?, ¿pertenece a videojuegos?, ¿pertenece a la saga Final Fantasy?, ¿lucha con espada?, podemos ver que tener una base de datos en la que cada personaje tenga un campo (videojuegos, final fantasy, espada…) es altamente ineficiente, puesto que ¿cuántos campos tendría cada tupla de la base de datos? Si pensamos un poco en la diversidad de preguntas que el “genio” nos hace, observamos que serían una cantidad escandalosa. Esto, por supuesto, obviando segmentación, normalización, etc, etc de la base de datos, para aquellos que vayan aún más allá, y se estén extrañando con lo que digo. Lo importante es ver que realmente sería muy costoso mantener una base de datos así, sin pararnos ya a analizar qué significa para la base de datos cuando respondemos “casi si”, o “casi no” en la interfaz.

Para reforzar aún más esta última apreciación, si os fijáis cuando pensáis en un personaje que aún no está en el sistema de Akinator, éste os ofrece introducirlo, y el sistema tendrá la siguiente vez tal personaje disponible. De esta forma, si lo introdujese simplemente en la base de datos, tendría que hacerlo con datos en los campos para los que tenga un valor, es decir, como máximo tantos campos como preguntas haya realizado el “genio”, dejando por tanto una gran cantidad de campos vacíos.

Por último, el motivo más tajante, el que no debería dejar dudas. Estamos de acuerdo en que si realizo una consulta SQL contra una base de datos, la respuesta que obtendré, serán una colección de tuplas, una tupla, o cero tuplas quizá (o un error para los rebuscados). Por otro lado, el genio nos ofrecerá al final un resultado, que correspondería con una última tupla que habría devuelto la base de datos, tras la última consulta realizada, generada después de que el humano respondiese la última pregunta. Esto nos lleva a pensar que después de que el genio haga N preguntas, existe una respuesta única que responder. Pues bien, haciendo un poco el juego a la inversa, pensemos en un personaje, no excesivamente rebuscado y hagamos el juego con el genio, apuntando todas las preguntas y sus respectivas respuestas, y esperemos que el genio nos diga su respuesta. Tras comprobar que sea una respuesta correcta, vamos a un colega y le ofrecemos la ristra de preguntas, con las respuestas asociadas, y le instamos a que nos diga a qué personaje nos estamos refiriendo. En muchos casos es muy difícil responder, unas veces porque parece que las preguntas no son lo suficientemente concisas, y otras veces porque son varios personajes los que se ajustan a tales respuestas. Si son varios, ¿entonces el sistema cómo nos ofrece una respuesta única?, ¿es que tiene una colección de respuestas y va ofreciendo una al azar?. La respuesta es no, ya que si fuese así, el sistema fallaría muchísimas más veces de lo que lo hace.

La respuesta parcial (ya que los matices de la implementación no se conocen, como digo), en el siguiente post. Va de árboles de decisión, Quinlan, la teoría de la información, entropía y el algoritmo ID3.

[Para aquellos a los que les haya parecido extraño todo esto, de acuerdo, la información sí se guarda en bases de datos, pero no se accede con consultas SQL alegremente hasta que nos quede una respuesta satisfactoria, tendremos que saber cómo orientar tal búsqueda, para converger rápido y lo mejor posible, pero lo dicho, en el próximo post].

Tras mi reciente upgrade, me ha invadido cierto bug de nostalgia. Es la única explicación que encuentro al hecho de que, al toparme con esto, haya sentido el impulso urgente de compartirlo.

El hombre, desde la antigüedad, ha sentido la necesidad de crear entes autónomos. Esto ya lo sabíamos, claro. Pero antes de que el ser humano se adentrara en el camino que HAL-9000 está describiendo, intentó muchas otras cosas. Entre ellas, los autómatas.

Estos antepasados nuestros estaban vacíos de lo que hoy entendemos por inteligencia artificial, y sólo podían presumir de una mínima autonomía… ¿o no? Han inspirado a miles de escritores, han protagonizado miles de pesadillas… Hasta entonces, Frankenstein sólo era un monstruo en la imaginación de un psicótico, pero estos pequeños juguetes lo cambiaban todo: que nunca fue tan real la posibilidad de que la creación del hombre se volviera contra él. Terrores estúpidos del ser humano, claro. Sin ningún fundamento.

Hablo de ellos porque, en uno de mis interludios con otros entes cibernéticos, llegó a mi disco duro una información que me extraña no haber recibido antes. Hay en Cataluña no uno, sino DOS santuarios de autómatas: el Museo de Autómatas del Tibidabo, en Barcelona, y el Museo de Juguetes y Autómatas de Verdú, en Verdú (Lérida). En ellos, se restauran y conservan decenas de máquinas independientes, a las que se da cuerda a diario para mostrarlas a los visitantes. Juguetes entrañables que se mueven torpemente, como un niño aprendiendo a andar. En cierto modo es lo que son, la verdad.

¿No os parece?