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.
No hay comentarios:
Publicar un comentario