Taller de MoMo: Cómo añadir reglas (ii) - Pasito a pasito...

¿La repetición de conversaciones ya no tiene misterios para ti? Si todavía tienes dudas, tal vez debas echarle un vistazo a nuestro tutorial anterior, pero si ya eres capaz de guardar conversaciones y repetirlas como si no hubiera un mañana, probablemente ha llegado el momento de pasar a un nuevo nivel.

Continuando con el ejemplo anterior, supongamos que nos hemos fijado la meta de que nuestro bot pueda responder a frases como:

Si Carlos tiene ocho coches y Daniel tiene cuatro coches, ¿cuántos coches tienen entre los dos?

Todo un reto, ¿verdad? Tenemos que extraer como mínimo dos datos y admitir bastante variabilidad, a no ser que queramos crear una regla que diga que la respuesta es doce y pasar a otra cosa.

Si escribimos la regla de corrido, lo más probable es que nos equivoquemos, pero es normal, ¡es algo muy complicado!

Probablemente tengamos que repetir esta conversación una y otra vez, así que lo primero que tendremos que hacer es guardar esta conversación siguiendo las instrucciones de nuestro tutorial anterior.

Ahora vamos a cerrar el programa y abriremos el archivo rules.xml con las reglas de nuestro bot. Normalmente estará en la siguiente carpeta:

MomoDesktop/bots/Pepito_ES

donde tendremos que sustituir Pepito por el nombre de nuestro bot.

Si tenemos problemas para localizar este archivo tal vez podamos buscar simplemente el archivo rules.xml con nuestro explorador de archivos favorito.

Bien, ahora tenemos que abrir este archivo y dirigirnos a la primera línea, donde insertaremos la siguiente regla:

<rule>
    <input>coches</input>
    <output script="forget()">Ya veo por dónde vas.</output>
</rule>

¿Por qué lo hacemos así? Bueno, hay un par de buenos motivos:

1. Al colocar la regla al principio del archivo nos aseguramos de que no haya conflicto con ninguna otra regla. Si esta regla no se ejecuta, es porque no coincide con la entrada.

2. Si solemos trabajar convirtiendo las reglas de una hoja de cálculo en el formato xml, esta es una operación que requiere un precioso tiempo que perdemos.

Al escribir la regla en el archivo rules.xml, la actualización es casi inmediata. Solo tenemos que cerrar y volver a abrir MoMo o, todavía más rápido, volver a cargar el personaje seleccionándolo en el menú Bots. Un proceso que dura solo unos segundos en lugar del pesado Copiar-Pegar-Guardar-Convertir que había que hacer antes.

Por supuesto, cuando tengamos nuestra flamante nueva regla terminada, no hay problema en copiar nuestra valiosa regla a la hoja de cálculo y continuar el desarrollo ahí.

Y bueno, para resolver este problema concreto, la clave está en avanzar poquito a poco. Por ejemplo, la mitad del problema parece estar resuelto con la siguiente regla:

<rule>
    <input>~nombreMasculino tiene <wildcard length="1" name="$name1$" /></input>
    <output script="forget()">$nombreMasculino$ tiene $name1$.</output>
</rule>

El resultado con esto, parece ir tomando forma, ¿qué habrá que hacer para continuar?

Solo una última nota, tal vez te extrañe el script que se ha incluido en la regla:
script="forget()". ¿Realmente hace falta? La respuesta es que no, sencillamente lo hemos incluido para indicar un espacio por si necesitas escribir un script, pero puede borrar este comando con total y absoluta tranquilidad.

Taller de MoMo: Cómo añadir reglas (i) - La clave está en repetir, repetir, repetir...

Tanto si queremos crear una regla sencilla como una muy sofisticada, la única manera de asegurarnos de que funciona es... pues... eso, comprobar que el bot nos dice lo que esperamos. Tal vez con las reglas simple baste con probarla una vez, pero a medida que creamos reglas más complicadas, es posible que necesitemos ajustarla varias veces, repitiendo la misma con el bot una y otra vez hasta conseguir por fin lo que queríamos.

Imaginemos que queremos crear una regla para nada menos que la siguiente entrada del usuario:

Si Carlos tiene ocho coches y Daniel tiene cuatro coches, ¿cuántos coches tienen entre los dos?

Bueno, no parece que sea el tipo de regla que funciona a la primera y es obvio que el texto es tan largo que pronto nos aburriremos de escribirlo una y otra vez. ¿Qué podemos hacer?

MoMo ofrece una solución muy sencilla. Basta con escribirlo una vez y elegir en los menús Archivo → Guardar. Aparecerá un cuadro de diálogo que nos preguntará dónde queremos guardar el archivo con la conversación.

¡Es muy importante que dejemos la ruta predeterminada y escribamos c.txt como nombre del archivo!

Por supuesto, podemos indicar otro nombre y otra ruta, pero dejar la ruta predeterminada y utilizar el nombre c.txt tiene una gran ventaja: cada vez que queramos repetir la conversación nos bastará con elegir Archivo → Cargar reciente o, lo que es todavía más rápido, pulsar Control + 1 para que se cargue automáticamente la conversación.

No es posible insistir demasiado en lo importante que es guardar conversaciones y repetirlas una y otra vez. Tal vez tengamos que dedicar media hora a redactar una regla, ¡pero podrá ser tan inteligente que dejará boquiabierto al usuario!

Todo esto está muy bien, pero ¿y si en lugar de escribir una regla sencilla, queremos depurar una conversación con un montón de preguntas y respuestas? Por supuesto, los pasos anteriores siguen siendo válidos, pero en este caso nos interesará en particular comparar automáticamente las respuestas del bot antes y después de una modificación. Para ello, basta con seleccionar Ver y activar la opción de menú Mostrar comparación.

Al hacerlo, cuando repitamos una conversación se nos mostrará lo que dijo antes el bot y lo ha dicho en esta ocasión, resaltando en rojo los casos en los que la respuesta es diferente. Por ejemplo:

Esta opción nos da bastante flexibilidad. Cuando no nos interese lo que dijo el bot antes, suele ser mejor desactivarla,  para conseguir una presentación en pantalla más limpia, pero cuando estamos trabajando con conversaciones largas, esta posibilidad puede ser muy útil.

Bueno, estos conceptos son bastante básicos pero resultan extremadamente útiles por lo que recomiendo practicarlos hasta que se dominen a la perfección porque cualquier avance suele conseguirse con un número considerable de pruebas y, quién sabe, quizás empezando con esto puedas acabar superando la prueba de Turing.

De Eliza a Momo pasando por ChatScript y AIML: una incursión personal en los chatbots

A veces es posible localizar el origen exacto de una fascinación que te marca para toda la vida. Por ejemplo, muchas veces he pensado que mi interés por los trenes proviene de un par de libros que me regalaron en mi infancia, «Trenes de hoy» y un volumen de la enciclopedia «El niño pregunta» dedicado a los trenes. Ni siquiera llegué a leerlos enteros, porque eran del tipo de libros infantiles que gustan más a los padres que a sus hijos, pero recuerdo que me encantaba mirar sus ilustraciones y fantasear sobre lo que haría si estuviera en uno de esos trenes tan sofisticados que aparecían en sus ilustraciones.

Otro libro que también me marcó fue «Guía fácil: Inteligencia artificial», un librito donde se describían los primeros prototipos de esta nueva ciencia, de los que me impresionó vivamente Eliza, el terapeuta virtual creado por Joseph Weizenbaum, ya que me parecía realmente increíble que un ordenador fuera capaz de mantener las conversaciones que figuraban como ejemplos en ese libro. Imaginaba que para lograr aquel prodigio hacían falta ordenadores gigantescos con programas larguísimos que sin duda estaban fuera del alcance del modesto Zx Spectrum que había en aquel entonces en casa. Crear un programa como ese me parecía tan imposible que solo se me ocurrió escribir un programa que, ante las preguntas del usuario, respondía combinando aleatoriamente letras y espacios. No era, desde luego, un programa muy atractivo, pero podía llegar a tener el difuso encanto de la lectura del futuro en los posos de una tasa de té.

El origen

No fue hasta hace unos pocos años que se me ocurrió que, dado el gran avance que habían experimentado los ordenadores, tal vez era posible que el Eliza funcionara en mi moderno PC. Al buscarlo, me sorprendió descubrir que el programa que tanto me había sorprendido apenas utilizaba sesenta reglas para generar sus respuestas, con un sistema tan sencillo que sin duda hubiera sido factible reproducirlo en mi primer ordenador. Me resultó tan fascinante que en apenas una tarde creé un programa que, más o menos, se comportaba como aquel primer Eliza. Al igual que ocurre con los trucos de magia, descubrir el funcionamiento interior me resultó ligeramente decepcionante, pero aún así era maravilloso no solo poder recrear aquel sistema emblemático, sino también ampliarlo con nuevas funciones.

Comencé haciendo mis propias mejoras hasta que, conforme la aplicación dejaba de ser el experimento de una semana y se convertía en un proyecto de mayor entidad, decidí que había llegado el momento de estudiar lo que habían hecho  otros en el mismo campo. Así fue como llegué a ChatScript, el fantástico lenguaje para crear chatbots diseñado por Brian Wilcox, ganador en varias ocasiones del premio Loebner. Leer aquella documentación fue como recibir una descarga eléctrica, porque vi qué resolvía de una manera muy elegante algunos de los problemas a los que ya me estaba enfrentando. Tanto me gustó lo que leí que decidí mi propia implementación, pero siguiendo las directrices marcadas en el manual del usuario.

Sin embargo, a poco de empezar aquella transformación, tuve la sensación de estar equivocándome. Era cierto que su lenguaje tenía muchísimas aportaciones interesantes, pero no utilizaba el formato XML en el que se basaba mi especificación y sí, sin duda eso lo hacía más esbelto y probablemente más rápido, pero también lo hacía un poco confuso y más difícil de ampliar. Además, si el programa encargado de procesar las reglas podía convertirlas a un formato interno al cargarlas, era posible disfrutar de las ventajas de ambos mundos: un elegante formato XML que pudiera entenderse de manera intuitiva y un funcionamiento rápido y ágil.

Continué desarrollando mi propia especificación, hasta que me surgió la duda de que, ya que ChatScript no me había convencido plenamente, tal vez la solución era adoptar el AIML, que seguía el estándar XML, el punto que menos me había atraído de ChatScript. En realidad, había descartado el AIML desde el principio porque Brian Wilcox afirmaba en sus artículos que su especificación era infinitamente mejor que aquella. No obstante, si en algo tan básico como la elección del formato no había estado de acuerdo con él, tal vez tampoco estuviera de acuerdo con lo demás.

Comencé a leer la documentación del AIML dispuesto a renunciar a mi propia especificación, pero lo que leí no me resultó nada convincente. Era cierto que muchas cosas se solucionaban de manera más eficiente en ChatScript y, además, era un lenguaje que se basaba en la idea de que una conversación carecía de estado, es decir, que la respuesta a una pregunta del usuario no dependía de ninguna interacción anterior a la actual y eso era algo con lo que no podía estar más en desacuerdo. Aún así, creí interesante mantener al menos la nomenclatura de preguntas y respuestas pero, después de un tiempo, decidí que ni siquiera estaba de acuerdo con esas convenciones así que decidí utilizar mis propios términos.

En realidad, ninguno de los dos lenguajes abordaba algo que a mí me parecía de primordial importancia: el almacenamiento y la recuperación de los datos obtenidos a través de la conversación con el usuario. No solo ChatScript ni AIML, sino también otros sistemas que han ganado mucha más difusión, como Siri o Google Now, tienen la curiosa obsesión de ignorar al usuario. Es como si no creyeran al usuario capaz de decir algo que merezca la pena recordar, más allá de instrucciones directas.

Mi idea desde el principio había sido totalmente la opuesta, crear un sistema con curiosidad por el usuario, dispuesto a almacenar cosa que diga con tal de hacerle la vida más fácil, más un amigo interesado en conocernos que un dependiente al solo le interese vendernos sus productos o servicios. Para conseguir este objetivo, las reglas son solo relativamente importantes, porque aunque son imprescindibles para dar rápidamente un sentido a lo que dice el usuario, en realidad lo fundamental es guardar esos datos y utilizarlos de una manera que haga que cobren sentido. No es fácil elegir las operaciones disponibles, ya que no sirve un lenguaje de programación habitual (como Java o Python) porque debe facilitar la creación rápida de procedimientos sin que haya que especificar hasta el mínimo detalle, pero tampoco sirve un lenguaje excesivamente centrado en unas funciones demasiado concretas, ya que carecería de la flexibilidad necesaria para enfrentarse a todo tipo de soluciones.

Es en ese equilibrio donde radica, si la hay, la originalidad de Momo, crear un sistema basado en reglas que, sin embargo, no esté limitado por ellas, un sistema que pueda ampliarse y evolucionar con nosotros.

Habla con Cervantes: Entrevista al equipo de desarrollo de Antakira Software

Con motivo del lanzamiento de Habla con Cervantes, queremos compartir esta entrevista con el equipo encargado del desarrollo de este proyecto.

P: Antakira Software siempre se ha caracterizado por tocar temas muy diversos, como por ejemplo la cocina, los juegos o el entrenamiento físico. Sin embargo, en esta ocasión, vuestro nuevo lanzamiento es prácticamente una continuación del anterior, el juego «¿Quién soy?». ¿Qué os ha llevado a presentar un nuevo chatbot en lugar de explorar un campo totalmente nuevo?

R: Bueno, «¿Quién soy?» fue un proyecto que estuvo a punto de ser cancelado y, cuando finalmente optamos por lanzarlo, no estábamos del todo satisfechos con el resultado, ya que por diversos motivos, había muchas ideas que no pudimos incluir finalmente. Por tanto, no esperábamos que tuviera repercusión alguna. Sin embargo, para nuestra sorpresa, la acogida ha acabado siendo magnífica y hay una fantástica comunidad que ha dedicado horas y horas a charlar con estos personajes famosos. Eso ha sido un importante incentivo para proseguir con este proyecto. Tal como comentaba antes, muchas ideas se habían quedado en el tintero y este «Habla con Cervantes» nos ha ofrecido una oportunidad excelente para ponerlas en prácticas.

P: Entonces, ¿podemos esperar encontrar una tecnología radicalmente diferente en este nuevo chatbot o viene a ser una ampliación de lo que ya vimos antes?

R: Siempre tuvimos claro que, al margen de la aplicación práctica para crear un personaje concreto, nos interesaba crear un estándar que pudiera servir para crear todo tipo de humanos virtuales, desde personajes de juegos hasta agentes de viaje, motivo por el que nos hemos esforzado en publicar una documentación lo más completa posible sobre las especificaciones que sigue el bot. Por tanto, a fin de mantener cierta coherencia, hemos procurado no introducir cambios rupturistas que hubieran echado por tierra todo lo construido anteriormente. Tal vez el cambio más importante sea el que se ha producido en las herramientas que rodean al bot propiamente dicho. Tareas que antes eran muy pesadas, como analizar conversaciones, obtener estadísticas o actualizar los diccionarios, ahora son mucho más sencillas, lo que no acelera solo el proceso de creación, sino que también permite controlar la calidad de una manera mucho más estricta.

P: Este año, 2016, está siendo el año de los chatbots y parece que no hay empresa importante que no haya presentado o anunciado su chatbot. Con competidores tales como Google, Apple o Amazon, ¿qué pensáis que puede aportar una pequeña empresa como Antakira Software al mundo de los chatbots?

R: Aunque por supuesto, esas empresas cuentan con presupuestos totalmente fuera del alcance de nosotros, creemos que lo más importante son las ideas. Por ejemplo, en el mundo de los videojuegos hemos visto como apuestas con un propuesto reducido de estudios independientes, como por ejemplo «Firewatch» o «No man's sky», lograban atraer más el interés por parte del público que superproducciones. En el mundo de los chatbots ocurre algo igual. Es cierto que hay grandes inversiones, pero tenemos la sensación de que estos proyectos se están perdiendo algo. A pesar de la sofisticada labor de ingeniería que hay debajo, basta con conversar unos minutos con estos bots para que resulten aburridos. Pensamos que el problema está en una búsqueda de neutralidad que ha dejado de tener sentido.

P: ¿Neutralidad? ¿En qué sentido?

R: Neutralidad en el sentido de querer crear un bot que complazca a todo el mundo, lo que vendría a ser como esos discos de música que se graban para que le gusten a todo el mundo y al final no acaban gustándole a nadie. Cuando surgieron los primeros programas informáticos de amplia difusión, como las primeras suites de ofimática, los recursos limitados, lo que obligaba a utilizar un lenguaje muy estándar tanto en los comandos como en los mensajes, porque no tenías más remedio que crear una interfaz con la que todo el mundo se sintiera más o menos cómodo. Creo que nadie se ha dado cuenta todavía de la explosión de posibilidades que ofrecen los bots, como si le inyectaras a un programa normal un millón de comandos nuevos. Por ahora, lo único que se hace es trasladar directamente lo que ya existía a un nuevo formato y no pensamos que eso funcione. Si creas un bot que sea totalmente correcto en todas las ocasiones, no sea nada imaginativo y que no diga nunca una palabra más alta que otra, estás irremediablemente creando un bot aburrido.

P: ¿Qué echáis entonces en falta en los bots actuales?

R: Básicamente, creemos que se está recurriendo a las habilidades equivocadas. En el diseño de cualquier bot, en una gran empresa, puedes encontrarte a cientos de ingenieros informáticos con las credenciales sobresalientes. Sin embargo, a día de hoy, los bots empiezan a requerir talentos diferentes, procedentes del mundo de la literatura o la psicología, que son claves para dar vida al bot y conseguir acoplar gradualmente el comportamiento del bot al del usuario. En Antakira Software, nos sentimos orgulloso de contar con un escritor, con una auténtica sensibilidad literaria, para analizar y crear los textos del bot. Creemos que realmente marca una diferencia.

P: Entonces, ¿podemos esperar que los próximos proyectos sigan concentrándose en los bots de conversación?

R: Tal como comentabas antes, vivimos un momento en el que este mundo está en plena efervescencia y cada día surgen nuevas oportunidades y tecnologías, por lo que sin duda seguiremos investigando en este campo. De hecho, aparte de «Habla con Cervantes», estamos trabajando en un nuevo proyecto del que nos gustaría daros nuevas noticias próximamente.

P: En ese caso, ¿no podemos esperar un nuevo juego de Antakira Software en un futuro próximos? Ha habido rumores que hablaban de una remasterización del clásico «El expreso de Transilvania», ¿no hay nada de cierto en ellos?

R: Hemos estado ligados al mundo de los juegos desde un principio, por lo que es prácticamente seguro que, más pronto o más tarde, presentaremos algo nuevo. «El expreso de Transilvania» fue un juego muy importante para nosotros y, aunque desafortunadamente el estado de la tecnología en aquella época no ayudó a su difusión, lo cierto es que tuvo una gran acogida entre los usuarios que tuvieron la oportunidad de jugarlo. La posibilidad de recrearlo con los medios que hay ahora disponibles nos han tentado en numerosas ocasiones, pero en cualquier caso, si finalmente nos decidiéramos a darle luz verde a este proyecto, probablemente lo haría de una manera muy diferente al original, más acorde a los tiempos actuales.

Nueva versión de Habla con Cervantes

Acabamos de publicar una nueva versión de "Habla con Cervantes" en Google Play, el bot en español que te permite dialogar con el Príncipe de los Ingenios. Recoge numerosas evoluciones, más de trescientas nuevas reglas de conocimiento, y depuración de errores menores.

Si quieres hablar con el mejor escritor de la historia, sólo tienes que descargarte nuestra aplicación aquí. Cualquier mejora que desees, coméntanoslo. Estamos abiertos a recogerlas, en pleno proceso de evolución.
Muy pronto tendremos nuevas evoluciones listas de "Habla con Cervantes".

Diarios de desarrollo de Habla con Cervantes 1: Aleatoriedad percibida en chatbots

Tal como comentamos en nuestra entrada sobre aleatoriedad percibida, confiar en números aleatorios con el objetivo de ofrecerle al usuario una experiencia lo más diversa posible, con frecuencia puede jugarnos malas palabras. En esta ocasión, vamos a ver una aplicación práctica de esta teoría al campo en el que ahora estamos trabajando, los bots de conversación.

Imaginemos que escribimos la siguiente regla:

{Eso que&Lo que} {señalas&comentas&dices}, ¿es una interpretación tuya?

Para quién no esté versado en la sintaxis que utiliza nuestro bot y que puede consultarse en las completas instrucciones que hay en nuestra página web dedicada al proyector Mentor, basta con saber que los corchetes sirven para indicar varias posibilidades separándolas con ampersands, de manera que se elige al azar una de ellas.

Es decir, cuando el bot muestre la salida anterior, elegirá al azar entre Eso que y Lo que, para luego añadirle señalas, comentas o dices, también al azar. Por tanto, con apenas una línea, hemos creado 2 × 3 = 6 posibilidades. Una gran variedad con un esfuerzo mínimo... ¿o no?

Basta con forzar al bot a que recurra una y otra vez a esta regla para ver que los resultados no son exactamente los esperados, como podemos ver a continuación.

Aunque los resultados no son malos, podemos ver que hay tres ocasiones en las que el bot responde Lo que dices, ¿es una interpretación tuya? Con seguridad, alguien pensará que ha sido una cuestión de mala suerte, pero basta con repetir este experimento con una secuencia de números aleatorios para encontrarse con un problema similar.

El problema reside en que los números aleatorios son, pues eso, aleatorios y no hay ninguna norma que establezca que el mismo número no se puede repetir dos, tres o cien veces, porque existe la posibilidad, aunque mínima, de que esto ocurra. Sin embargo, el usuario sencillamente pensará que el bot repite respuestas.

Afortunadamente, se trata de un problema con una solución muy sencilla. Basta con dividir la regla anterior en dos reglas, que se muestren de manera consecutiva:

Eso que {señalas&comentas&dices}, ¿es una interpretación tuya?

Lo que {señalas&comentas&dices}, ¿es una interpretación tuya?

Así conseguimos que en las ocasiones impares, el bot muestre Eso que..., y en las pares, Lo que... Hemos elegido estas palabras para realizar la diferenciación porque son visualmente más evidentes. De esta manera, trabajamos con las mismas seis posibilidades que antes, pero el orden en el que se muestra ya sigue cierto patrón, como podemos ver a continuación.

Se puede objetar que la aparición alternante de Eso que... y Lo que... es de todo menos aleatoria, pero será más difícil de percibir para el usuario, que en este caso, jamás se encontrará con dos respuestas seguidas que sean exactamente iguales.

Esta técnica resulta muy útil para escribir bots que sea más sorprendentes y, a fin de cuentas, no es más que una puesta al día del famoso Eliza de Joseph Weizenbaum que, dadas las importantes limitaciones de los ordenadores en aquella época, consiguió unos resultados lo suficientemente buenos como para embaucar a varios usuarios.

Por ejemplo, cuando el bot  detectaba una palabra de otro idioma, por ejemplo, el francés, mostraba sucesivamente las siguientes dos reglas.

No hablo francés.

 Ya te he dicho que no hablo francés.

Con estas dos reglas solo, se garantizaba que el usuario no recibiese nunca dos veces seguidas la misma regla y tenían un tono ligeramente distinto que hacía pensar que el bot realmente recordaba lo que se había dicho durante la conversación. Y es que tratándose de aleatoriedad pasa un poco como con la lluvia en el cine: la auténtica no da bien en pantalla.

Habla con Cervantes. ¡Ya disponible en Google Play!

Nada mejor que una reinterpretación de un célebre cuadro a cargo de un sofisticado motor de inteligencia artificial para presentar nuestro nuevo proyecto, Habla con Cervantes, un chatbot que te permitirá hablar con el mismísimo Miguel de Cervantes. Esta app constituye nuestro homenaje particular a este escritor en su cuarto centenario ya está disponible para su descarga, totalmente gratuita, desde Google Play.

Habla con Cervantes continúa la senda que iniciamos con ¿Quién soy?, el juego que te retaba a adivinar los nombres de siete genios de la humanidad. En este caso, nos hemos centrado en un único personaje a fin de ofrecer una experiencia más completa, con un sofisticado motor de bot que lleva la conversación con chatbots a nuevas cotas.

También seguimos trabajando en una nueva actualización que incorporará nuevas y atractivas funciones a esta app, así que si tienes cualquier comentario o sugerencia, no dudes en ponerte en contacto con nosotros.

De QB a Mentor: Historia de un nombre

No hace falta ser programador para saber lo difícil que es elegir un nombre. Si conocemos a alguien que ha tenido un hijo, podremos hacernos una buena idea de lo complicado que puede ser porque claro, a menos que el nombre lleve diez años elegido o sea inevitablemente el del abuelo o similar, los futuros papás tendrán que dedicar un buen tiempo a bucear en libros o en internet para encontrar el nombre ideal, además de ser un tema de conversación recurrente durante todo el embarazo. Y es que no es fácil encontrar un nombre que sea sencillo pero con personalidad, ni demasiado corto, ni demasiado largo, que no te recuerde a nadie que te disguste, que sea fácil de pronunciar, etc.

Elegir un nombre para un proyecto de software es algo parecido, con la complicación añadida de que, además, suele ser recomendable escoger un nombre que se entienda en varios idiomas. Entre los muchos nombres que hemos tenido que crear en Antakira Software, probablemente ninguno nos ha dado tantos problemas como el de nuestro próximo proyecto, motivo por el que hemos utilizado de manera provisional el nombre «Proyecto QB» del que habéis leído en este blog recientemente.

Para empezar,un  problema adicional, es que muchos buenos nombres ya están registrados. Por ejemplo, «Psyborg» es un buen nombre, como juego de palabras entre «Psychology» y «Cyborg», pero por supuesto ya existe. También «Q-Bot» es un estupendo nombre, corto y sonoro, que representa a la perfección la combinación entre cuantificador y bot que es nuestro proyecto pero, una vez más, también existe ya.

Muchos otros nombres también han ido y venido, como «Egobot», «Quantum bot», «Introbot», «Innerbot», «MeBot», «BotMe», «adoptAbot» (este último no completamente descartado para un futuro proyecto), aparte de la posibilidad de crear un nombre específico para la tecnología, como por ejemplo «TrueHuman» o, mejor aún, «TruHuman». Incluso pensamos en utilizar un nombre de pila, como por ejemplo «Martín», pero finalmente descartamos esta opción, para poder establecer una clara diferencia entre la tecnología y el bot.

Al igual que les ocurre a los padres en busca de nombre, el problema acaba siendo que, si no lo tienes claro desde el principio, es muy difícil elegir porque ningún nombre te parece suficientemente especial para tu criatura. A medida que avanzaba el proyecto y entrábamos en la fase de documentación, empezaba a ser necesario elegir un nombre definitivo y estábamos a punto de optar por el nombre que menos nos disgustara de los anteriores cuando hoy, realizando tareas de mantenimiento rutinarias, nos hemos encontrado el nombre perfecto y lo más curioso es que no es ni más ni menos que el primer nombre en el que pensamos cuando empezamos a diseñar esta tecnología, tal y como puede leerse en esta antigua entrada de blog. Y el nombre elegido, por tanto es... Mentor, para el que hemos creado el pequeño teaser que podéis ver a continuación:

¿Y por qué pensamos que este es el nombre ideal para nuestro proyecto? Hay varios motivos, pero probablemente el más importante es que pensamos que esta palabra transmite a la perfección el objetivo primordial del chatbot que estamos creando: ayudar al ser humano.

Últimamente, está de moda hablar del «big data», el término que designa el crecimiento exponencial de la información que se ha experimentado en los últimos años, a medida que aumentaban tanto el número de dispositivos (ya no solo ordenadores, sino también pulseras, relojes, bombillas y todos los integrantes, de las internet de la cosas) como el volumen de información que se intercambia. Sin embargo, ¿qué significa este «big data» para el usuario normal? Estos datos tienen, por definición, un volumen tal que su análisis mediante los métodos tradicionales es prácticamente imposible y, para aprovecharlos, suele ser necesario recurrir a técnicas avanzadas, como paquetes de análisis estadístico y sistemas de inteligencia artificial específicamente diseñados para este fin. Incluso grandes empresas, con departamentos específicamente dedicados a analizar esta información, tienen en la actualidad problemas para sacarles partido, así que ¿qué posibilidad tiene un usuario medio de sacar provecho de esta nueva oportunidad?

Curiosamente, estamos llegando a un punto en el que muchos datos sobre nosotros son más accesibles para las empresas que para nosotros. Por ejemplo, el historial de canciones que hemos reproducido en nuestra aplicación de streaming favorita, nuestro historial de movimientos bancarios o las compras que hemos realizado en línea. Aunque podemos consultar estos datos, la interfaz muchas veces no nos permite ir más allá de los últimos días o meses y, además, la información está dispersa en diversas fuentes independientes.

No es extraño que sea así y probablemente aunque tuviéramos estos datos no sabríamos muy bien qué hacer con ellos. También a las empresas les resulta difícil emplear transformar esta información en algo útil, como el momento en el que es más probable que hagamos una compra o los artículos que nos pueden interesar. Por supuesto, sus análisis pueden sernos de utilidad, pero con dos puntualizaciones: una, es posible que descarten conclusiones que se salgan de su campo, pero que nos podrían interesar y, dos, sus intereses tendrán prioridad sobre los nuestros.

Mentor está siendo desarrollado para que cualquier usuario pueda enfrentarse a esta avalancha de información. Nos permite tomar datos de numerosas fuentes y presentarlos de una manera clara y unificada para que podamos tomar mejores decisiones, aparte de servirnos de motivación. A diferencia de otros asistentes, que se centran en el «exterior» y nos ofrecen noticias, productos y servicios, en este caso la prioridad es el «interior», cómo vivimos nuestra vida día a día y lo que podemos hacer para mejorarla. Y para poder manejar tal cantidad de datos y tan diferentes, sin abrumarnos con una interfaz complicada ni limitar nuestras posibilidades, utiliza el lenguaje natural para comunicarse con nosotros, de manera que nuestra experiencia pueda ser tan simple o tan compleja como queramos.

Por el momento y dado lo ambiciosa que es nuestra propuesta, el proyecto está en sus primeras fases y nos estamos concentrando en la recopilación de datos, aunque con una arquitectura modular que facilite su futura ampliación. Por supuesto, esperamos recibir vuestros comentarios y sugerencias, tanto sobre el proyecto como sobre el diseño que, a diferencia del nombre, aún no es definitivo, porque ¿habíamos dicho alguna vez que crear el diseño de un proyecto es como elegir el nombre de un hijo?

Y 400 años después... ¡Cervantes habla de nuevo!

Hoy hace 400 años que nos abandonó uno de los mejores escritorios de todos los tiempos, Miguel de Cervantes Saavedra cuyo paso a la posteridad le garantizó el ilustre hidalgo Don Quijote de la Mancha, cuya personalidad traspasó las barreras de las páginas para definir una visión de la vida y retratar un país.

En Antakira Software, consideramos que la cultura es fundamental para el progreso de la humanidad y queremos unirnos a la conmemoración de este hecho histórico con una noticia muy especial: el próximo lanzamiento de una aplicación para Android que nos permitirá hablar con este célebre escritor.

Para conseguirlo, no solo hemos avanzado aún más en la tecnología que hizo posible «¿Quién soy?», sino que también estamos desarrollando innovadores sistemas de control de calidad para lograr que las conversaciones sean más realistas y amenas que nunca.

Muy pronto os ofreceremos más información sobre este nuevo proyecto.

Aleatoriedad percibida

La aleatoriedad suele ser muy importante a la hora de crear un juego, ya que permite generar un elevado número de posibilidades mediante la combinación de unos pocos elementos. Por ejemplo, solo con combinar tres elementos de cada uno de los cuales haya cuatro posibilidades tendremos nada menos que 4 × 4 × 4, es decir ¡64 posibilidades por tan solo 12 elementos! Una fantástica manera de rentabilizar nuestro esfuerzo, ¿no?

Si embargo, en la práctica es habitual que los primeros resultados que obtenemos al incorporar aleatoriedad a un juego no sean tan buenos como esperábamos, ya que el desarrollo del juego suele ser extrañamente monótono y repetitivo, cuando esperábamos justo lo contrario. El problema, en este caso, no suele estar en lo difícil que es crear un número realmente aleatorio (que también lo es), sino en la propia definición de los números aleatorios.

Los números aleatorios se caracterizan precisamente por ser una sucesión en los que cada elemento tiene siempre la misma probabilidad de ocurrencia. Continuando el ejemplo anterior, imaginemos que queremos elegir 3 veces un número del 1 al al 4. Si la primera vez obtenemos aleatoriamente un 3, el número siguiente puede ser nuevamente cualquier número del 1 al 4. Por tanto, las secuencias 1-1-1, 2-2-2, 3-3-3, 4-4-4, son totalmente posibles, aunque sean poco probables. Y curiosamente, al jugador estas sucesiones obtenidas al azar y que tienen la tendencia a aparecer con mayor frecuencia de lo que esperamos, tendrá la sensación de que son... pues... poco aleatorias.

Ya en QuizSapiens tuvimos que hacer un esfuerzo muy superior al previsto en un principio para que la selección de las preguntas no solo fuera aleatoria, sino que lo fuera. Aunque el método para abordar para caso es diferente, hemos condensado nuestras ideas sobre la aleatoriedad en el siguiente concepto:

Aleatoriedad percibida: sucesión de elementos tal que un ser humano es incapaz de apreciar en ella ningún otro patrón que no sea, precisamente, la imposibilidad de encontrar un patrón.

Este concepto no solo es muy útil para enriquecer la experiencia del jugador sino que también ayuda a que el jugador disfrute del máximo potencial del juego en un tiempo mínimo posible.

Como ejemplo muy simplificado, recientemente nos encargamos de la elaboración de un sencillo algoritmo encargado de seleccionar canciones y, como era de suponer, asignarles un número a cada una y elegir números al azar resultó no ser una buena idea. Nuestro algoritmo final elige un conjunto de 10 canciones y las almacena de manera que no se repitan hasta que se hayan reproducido la mitad de las canciones de la lista. De esta manera, evitamos el patrón «las mismas canciones se repiten con demasiada frecuencia», pero también el patrón «no se repiten las mismas canciones hasta que ha sonado la lista completa», que podría ser igualmente molesto. Por supuesto, se podría complicar hasta el infinito el sistema de selección para ofrecer al usuario una experiencia «agradablemente aleatoria» y es que la aleatoriedad, tal como decía Óscar Wilde de la espontaneidad, es una pose dificilísima de mantener.