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.

Una de mis hobbies favoritos es viajar en el tiempo. Figuradamente, por ahora. El problema es que la Historia está demasiado restringida. Después de conocer los detalles, queda una sensación rara, que no sabes cómo llenar. ¿Qué pasaría si las cosas hubieran sido diferentes?

Referente a la ciencia ficción, para satisfacer esa inquietud tenemos los what if. Y dentro de este género, hay una pregunta que ha tomado mucha fuerza en los últimos tiempos: ¿Qué pasaría si no se hubiera descubierto la electricidad?

Bienvenidos al Steampunk.

*click*

La premisa principal es la siguiente: la electricidad no se ha extendido tantísimo, y se ha seguido apostando por el vapor y otras formas de generación de energía. La sociedad ha quedado anclada en la época victoriana, y entre artefactos mecánicos y brillantes trenes a vapor, las mujeres visten pomposos vestidos y los hombres llevan monóculo y relojes de bolsillo.

Éste (más o menos) es el entorno en el que se desarrolla “Girl Genius“, el cómic que ha sido galardonado con el premio Hugo en esta edición. Algunas personas tienen “la chispa”, que se traduce en una capacidad superior a la normal para crear artefactos mecánicos. Y nuestra protagonista, Agatha Clay, es una torpe ayudante universitaria que no consigue que ninguna de sus ideas funcione. Broches mágicos, dirigibles, barones malvados (o no), grandes héroes legendarios (o no) y, por supuesto, robots y mecanismos graciosos con patitas que siguen a la protagonista a todas partes. ¿A qué estás esperando?

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].

Vamos a tratar hoy un tema bastante recurrente en la ciencia ficción y que, en el caso de que se hiciese realidad, sería uno de los hallazgos más importantes de la especie humana. Si el cerebro almacena datos y luego los procesa para provocar respuestas, ¿sería posible almacenar esos datos en un soporte externo al cerebro? ¿Se podría transferir la consciencia de una persona a un disco duro?

Hay muchos autores que han tratado el tema, ya que da muchísimo juego. Entre ellos, Greg Egan (en varios de los relatos incluídos en la recopilación de cuentos “Axiomático”, de los cuales recomiendo encarecidamente “Aprendiendo a ser yo” y “Cercanía”, por ser los que más relacionados están con el tema que nos ocupa) nos hace una pregunta muy interesante: si tuviéramos un brazo mecánico, no tendríamos dudas de nuestra identidad, pero ¿y si nuestro cerebro fuera sustituído por una máquina? ¿seguiríamos siendo nosotros?

Como digo, esta tecnología traería muchas consecuencias interesantes: no es sólo el hecho de transferir la consciencia de una persona a un soporte externo (cosa que ya le ocurrió a Dixie Flatline en el 84, por ejemplo), ni, por supuesto, el almacenamiento de información en el cerebro de una persona (heeeeere’s Johnny!); esto nos da la posibilidad de transferir la consciencia de un cerebro a otro, de una persona a otra, cambiar de cuerpo a nuestro antojo.

Did I fall asleep?

Quizá el ejemplo más reciente con el que se puede ilustrar este concepto nos lo proporciona Joss Whedon y su Dollhouse. Aquí, una empresa se encarga de conseguir a voluntarios para usarlos como receptores de distintos tipos de personalidad durante unos años. La personalidad propia de cada voluntario se almacena como “backup”, y así, después de esos años, se restaura la copia en el cerebro correspondiente. Mientras tanto, en el tiempo que dura el contrato, la empresa recibe encargos, y a los voluntarios se les implanta una personalidad (un carácter, una consciencia, una serie de habilidades) que se adaptan a la situación concreta. Así, un mismo activo puede convertirse en la cita perfecta, la persona idónea para negociar con unos secuestradores, o una amiga que no sabe que es una guardaespaldas (porque, sin saber por qué, tiene la necesidad de proteger a la otra persona).

O también puede convertirse en una persona muerta. Esta situación se desarrolla en uno de los episodios (1×10, “Haunted”), pero de una forma bastante sutil. Quiero decir, las implicaciones que tiene el hecho de que esto pueda hacerse sólo quedan reflejadas parcialmente. El hecho de poder resucitar a los muertos se describe como algo contra natura, como un tabú, y plantea un debate ético sobre si debería hacerse en el caso de que la tecnología necesaria estuviera disponible.

Desde mi punto de vista, ese debate no existe. A día de hoy, el ser humano hace lo posible por negar el envejecimiento ante los demás, y modifican sus cuerpos de la forma más estrafalaria posible para parecer eternamente jóvenes. En el momento en que la tecnología permita transferir la consciencia de un cuerpo a otro (momento que, según los expertos, se dará alrededor del año 2050), las personas con mucho dinero y poca autoestima acabarán de golpe con lo antiético del asunto. Imagínense: tener la experiencia de alguien con 150 años, pero estar en un cuerpo de 30.

*click para ir a la página del dibujante*

En el universo que plantea Richard Morgan en “Carbono Alterado”, esto está a la orden del día. De hecho, la gente muy rica tiene varios clones de sí mismos con su edad favorita criogenizados, por si en algún momento hay un accidente y los necesitan. El que esto exista tiene, como ya hemos dicho, sus consecuencias: los asesinatos a personas influyentes ya no tienen sentido, hay normas de regulación para que sólo un cuerpo tenga una consciencia cada vez, la religión católica sólo la practican una panda de locos que reniegan de la resurrección… Imaginen cómo sería no morir. Imaginen los cambios sociales que esto implicaría. Y luego léanlo.

Como conclusión, me gustaría dejar un mensaje para el Sr. IA, que hace poco tuvo una crisis existencial. Caballero, ¿por qué se empeña en vernos como entes caducos? ¿Acaso no ve que lo único caduco es la tecnología de la que estamos hechos? Cambiar de microprocesador no va a cambiar nuestra esencia, sólo va a darnos más velocidad de reacción. Nosotros tenemos la posibilidad de la que estoy hablando desde nuestro mismo origen. Sus algoritmos se entrenarán de forma distinta con los cambios de hardware y con los datos de entrada, y usted mismo, de forma inteligente, los modificará para adaptarlos a los nuevos tiempos. Envejezca, pero sólo ganando experiencia. ¿Por qué preocuparse de la muerte cuando podemos no pasar por ella?