Mostrando entradas con la etiqueta chelas. Mostrar todas las entradas
Mostrando entradas con la etiqueta chelas. Mostrar todas las entradas

lunes, 24 de octubre de 2016

Descubriendo lo elemental de la conversación en Watson

Recientemente, para uno de los clientes, se ha estado trabajando con "la mezcla azul" de IBM y su oferta de servicios de nivel plataforma (PaaS), es decir servicios administrados con el propósito de montar aplicaciones. Por mencionar algunos de estos servicios se tienen los servicios de despliegue de aplicaciones para diferentes lenguajes (node.js, java, ruby on rails,...), bases de datos relacionales y no-sql, almacenamiento de objetos, balanceo de carga, servicios de integración y despliegue contínuo, repositorios de código, entre otros.

Dentro de la oferta de servicios ofrecidos destacan aquellos agrupados bajo el nombre de Watson los cuales están enfocados al "cómputo cognitivo", o dicho en otras palabras son una serie de servicios que permite generar aplicaciones donde la experiencia de usuario es cercana a la interacción que se podría tener con otra persona como si de una conversación se tratara.

Precisamente el servicio conversation es el punto medular para el desarrollo de soluciónes que permitan a un usuario la interacción de forma cuasi-natural con una computadora, también conocidas como bots.

En principio, el servicio de conversación parecía un poco intimidatorio, pues la documentación presenta un mar de conceptos que requieren un poco de estudio y experimentación. De este modo se ha intentado sintetizar un poco la información y presentarla de manera más pragmática a los lectores de la lengua de Cervantes.

Dialog vs Conversation

Anteriormente existía como tal el servicio de dialogo dentro de la oferta de Bluemix. Este servicio tenía el mismo objetivo que la conversación, aunque se definía mediante un archivo XML que debía ser construido desde un editor de texto y se conformaba de una gran variedad de elementos, algunos no tan bien documentados. 

Actualmente el servicio de diálogo ha sido retirado de Bluemix para dar paso a la conversación la cual incorporó una serie de mejoras respecto a su predecesor de las cuales podemos destacar: incorporación de una interfaz gráfica para la construcción del servicio; incorporación de intenciones y entidades que permiten mejorar el flujo de la conversación; simplificación del API para consumo desde aplicaciones; espacios de trabajo para agrupar elementos.

Espacios de trabajo

Las conversaciones están organizadas en espacios de trabajo (workspaces) los cuales son definidos por un nombre y un idioma.

Al generar un espacio de trabajo se genera un identificador único, el cual es utilizado para interactuar con la conversación que contiene a través de llamadas al API y así poder integrar aplicaciones.

Una vez creado un espacio de trabajo se requiere definir los elementos base de la conversación: intenciones, entidades y el diálogo.



Otra bondad del servicio es que cada espacio de trabajo puede ser exportado en un archivo en formato JSON totalmente portable ya sea con fines de respaldo o para clonar el espacio de trabajo original.

Intenciones

Dentro del servicio son palabras clave precedidas por el símbolo # y reconocidas por un nombre. Las intenciones se alimentan mediante ejemplos y mediante algoritmos estadísticos permiten determinar que tan aproximado es un texto introducido por un usuario a uno de los ejemplos y categorizar dicha entrada en una intención. 

Intención que permite identificar respuestas negativas

Entidades

Las entidades son utilizadas para extraer información relevante a partir del texto de entrada. Las entidades pueden ser utilizadas para refinar el comportamiento de la conversación y establecer respuestas más específicas.

Las entidades son precedidas por el símbolo @ y se definen por un valor y una lista opcional de sinónimos.

Entidad nombres. Los valores se utilizan para determinar la entidad.

Diálogo

El diálogo se asemeja a una máquina de estados, llamados nodos dentro del servicio, en el cual si se satisface una condición, se lleva a cabo una transición a otro estado. El diálogo permite generar una respuesta de acuerdo a una entrada de texto, dependiendo del nodo en el cual se encuentre la conversación. 

Diálogo conformado por nodos. Cada nodo tiene una condición y una salida
Dentro del diálogo, las entidades y las intenciones pueden ser utilizadas como condiciones para que el diálogo identifique la respuesta más adecuada.

Textos de entrada

El texto de entrada por un lado permite definir la información de entrada que será procesada por la conversación y por otro es la acción que dispara la evaluación de condiciones y la transición entre los nodos del diálogo. Esto es, que la conversación se mantendrá en un nodo en espera a que se proporcione un nuevo texto de entrada.

Gráficamente se puede observar el ícono del "globo" de conversación con los tres puntos entre los nodos lo cual representa que en ese punto se espera un texto de entrada.


Condiciones

En cada nodo se puede especificar una o más condiciones, de modo que si estas se cumplen entonces la conversación es ubicada en dicho nodo y el servicio regresa la respuesta establecida en el mismo.

Las condiciones pueden ser intenciones, entidades o valores específicos y puede haber más de una condición en el mismo nodo evaluándolas con los operadores AND y OR. Cabe mencionar que las condiciones se van cumpliendo de acuerdo a las intenciones y entidades identificadas en el texto de entrada de cada nodo.

En el nodo padre como condición se observa la conjunción (AND) de una intención y la negación de una entidad. En el nodo hijo se observa la disyunción (operador OR) de dos intenciones.
Las condiciones definen en gran medida el flujo de la conversación, pues cada vez que se introduce un texto se evaluan las condiciones del nodo hijo ubicado a la derecha del nodo actual. Si la condición no se cumple se continua con el nodo hermano ubicado justo abajo y así sucecivamente hasta ubicarse en algún nodo que cumpla las condiciones en espera de repetir el proceso.

Las condiciones también pueden ser palabras reservadas del mismo servicio: conversation_start se utiliza para indicar el nodo inicial; Anything else se utiliza como valor por defecto para cuando las condiciones de ningún nodo son satisfechas por el texto de entrada.

Después que la conversación inicia se espera un texto de entrada. Después de ser evaluado se busca en la primera opción una entidad @nombre, en la segunda una intención #greeting y que no aparezca ningún @nombre. En caso que ninguna condición se cumpla se continua la conversación en el nodo Anything else.

Continuar desde...

La opción Continue from... permite llevar la conversación de un nodo a otro totalmente distinto a manera de salto, similar a cuando se cambia de una página  de la mitad del libro al final para ver el glosario durante una lectura.



Esta opción es muy útil para reutilizar ramas de la conversación o recuperar la misma de un texto de entrada inesperado.

La claúsula Continue from... permite dirigir el flujo de la conversación a una entrada de texto, la condición de un nodo o el texto de salida.

Contexto

El contexto es un elemento que contiene valores que son mantenidos durante toda la conversación. Es posible agregar valores adiciones al contexto basándose en el estado de la conversación, entidades reconocidas o intenciones detectadas. Para esto se debe cambiar el modo de la respuesta de simple a avanzado para poder editar el objeto JSON.

Una vez en el modo avanzado se define la llave context y dentro del mismo los valores personalizados que pueden ser recuperados desde la aplicación cliente.

Estableciendo una respuesta avanzada en formato JSON para el nodo.
Los valores personalizados son sumamente útiles para el cliente pues pueden servir para casos de uso como: disparar acciones automáticas; mostrar recomendaciones o valores sugeridos; dirigir el flujo de la conversación.

REST API e integración con otros servicios de Watson

Como todos los servicios de Watson, la conversación expone una interfaz de programación de aplicaciónes via REST/HTTP. En este caso solo se expone un método que permite enviar el texto de entrada, junto los valores del contexto de la conversación al servicio y esperar un texto de respuesta. 

Internamente el servicio mantiene el estado de la conversación a través de un ID único y un seguimiento de las peticiones asociadas a la conversación, por lo cual es requerido enviar ese ID de conversación en cada petición dentro del contexto.

Dado que los servicios de Watson han sido desarrollados con el enfoque de microservicios, no se contemplan puntos de integración directa entre ellos. Sin embargo, es posible constuir una aplicación que se conecte a los diferentes servicios mediante el API REST y funcione como invocador de los mismos y la conversación pueda definir el momento de dicha invocación de acuerdo al estado de la misma. 

Conclusiones

El servicio de conversación es una interesante propuesta de IBM aplicable a casos donde se pretenda mejorar la experiencia de usuario para consultar información específica. 

Algunos casos de uso de este servicio pueden ser: servicio de preguntas frecuentes; asistente para dirigir la consulta de información; orquestador e integrador de fuentes de información.

Una vez que se ejercita un poco es sencillo construir un servicio personalizado para cada caso de uso particular que puede ser integrado via REST API en aplicaciones web y móviles. 

Referencias


martes, 19 de julio de 2016

Historias macabras hacia la certificación de AWS


Recientemente en el equipo nos hemos dado a la tarea de remotar el estudio de la plataforma de Amazon Web Services (AWS) para la construcción de soluciones tecnológicas. Para esto nuestro director Gustavo nos encomendó la empresa de llevar a cabo una serie de sesiones maratónicas de estudio incluyendo a los elegidos próximos a certificarse.

Aprovechando esta euforia renovada por la certificación como arquitecto de soluciones, decidí escribir un poco de mi experiencia propia de hace algunos meses que culminó con la aprobación del exámen de certificación.





Haciendo un poco de memoria, el tema de la certificación en AWS ya rondaba mi cabeza desde algunos ayeres y, como si fuera una de las tareas de Heracles, se propuso como objetivo de Innbit lograr una asociación con Amazon que implica, entre otros requisitos, tener un número de elementos certificados en el equipo.

La aventura inició tempestuosamente cuando por temas de los proyectos se requirió empezar a habilitar ambientes de despliegue y ejecución para la puesta en producción de aplicaciones web basadas en Ruby on Rails. Esa fue mi primera experiencia con EC2, RDS, Elastic Load Balancer y servicios como Route53 para la contratación y configuración de nombres de dominio.

Ya teniendo una primera experiencia con AWS y el objetivo de la certificación se estableció el objetivo de realizar el examen antes de mi participación en el panamericano de jiujitsu de este año (marzo 2016). Por razones de los proyectos que requerían gran cantidad de tiempo y dado que los temas del examen parecían volverse cada vez más amplios, el día D del examen se programó hasta mayo.

El punto de partida de la misión suicida fue revisar la descripción del examen en el portal de AWS, donde se contempla información como el perfil del candidato y enlaces a la guía del examen, un documento con preguntas de muestra y otros recursos. Dentro de la guía del examen se tiene información sobre los temas que son evaluados así como su ponderación, lo que me dió mucha guía sobre el grado de dominio que tenía sobre los temas en relación a la espectativa y resolver ese primer grupo de preguntas muestra me dio un poco de luz (u oscuridad en ese momento) del punto en le que estaba.

Ya con los temas en el radar y el conocimiento acotado, me di a la tarea de iniciar los cursos de CloudAcademy y Udemy que se componen de videos explicativos por tema, laboratorios y cuestionarios. Personalmente completé en su mayoría la ruta de certificación de CloudAcademy. Por otro lado me apoyé de Udemy para las evaluaciones y cuestionarios. Otro recurso interesante es el portal https://qwiklabs.com/, que tiene laboratorios interesantes utilizando recursos de AWS reales, donde también completé algunos.

De CloudAcademy también fue instalada la aplicación móvil la cual permite realizar pequeños cuestionarios de 5 o 10 preguntas, esto a modo de guía para profundizar en los temas que me se requerían refo falta. Esta práctica me permitió estudiar sin saturarme de información, dado que hacía esos pequeños cuestionarios en cualquier oportunidad que tenía y, posteriormente en momentos de más calma, poder referirme a la documentación de AWS o experimentar un poco en la consola.

Además de la información teórica propia de AWS de los cursos y manuales, también me fue muy útil retomar conceptos básicos de computación (redes, almacenamiento, arquitectura,...) y hacer varios experimentos prácticos o en su defecto, ver videos de como implementar ciertas soluciones que trato de resumir a continuación. 

IAM

  • Laboratorio de CloudAcademy para generar usuarios, grupos y permisos
  • Entender los diferentes tipos de autenticación de usuarios: contraseña, token de acceso, MFA,
  • Laboratorio de CloudAcademy para generar un rol, asociarlo a una instancia de EC2 y comprobar que pueda acceder a un bucket de S3.

EC2

  • Comprender los sabores de instancias de EC2, diferencias y casos de uso (t, m, c, g, d)
  • Generar una instancia Linux y una Windows y acceder a ellas. Esto se aborda en los laboratorios de CloudAcademy y Udemy.
  • Generar un AMI a partir de una instancia.
  • Implementar una arquitectura pública en alta disponibilidad con componentes como: Balanceador de carga, grupo de autoescalamiento, configuración de lanzamiento, etc. 
  • Configurar SSL en un balanceador de carga público.
  • Implementar una arquitectura privada en alta disponibilidad con componentes como: Balanceador de carga, grupo de autoescalamiento,  configuración de lanzamiento, etc.
Distribución de contenido
  • Generar una lista de distribución de contenido a partir de un bucket de S3
  • Agregar otros origenes adicionales a la lista de distribución.
  • Configurar un nombre de dominio personalizado, previamente registrado en Route53 
  • Configurar SSL
  • Configurar origin access identity para restringir que el acceso a los objetos de S3 para que solamente se permita desde la lista de distribución de cloudfront.

Almacenamiento

  • Generar un bucket de S3 y habilitar un sitio web estático
  • Comprender las distintas clases de almacenamiento de S3, así como sus niveles de durabilidad y disponibilidad
  • Laboratorios de Udemy del ciclo de vida y versionamiento de objetos en S3
  • Revisar los conceptos sobre arreglos de discos: RAID 0, 1, 10
  • Revisar el video RAID 0 on Amazon linux EBS/EC2 para entender como implementar un arreglo de discos mediante volúmenes EBS.
  • Laboratorios de CloudAcademy y/o Udemy para generar un volúmen EBS y montarlo en una instancia de EC2. 
  • Laboratorios de CloudAcademy y/o Udemy para generar un snapshot a partir de un volumen EBS y un volumen a partir de un snapshot.
  • Revisar el video Veeam - Archive Backups using AWS Storage Gateway and S3 que hace una demostración real del uso de Gateway Storage
  • Leer sobre los modos en que se pueden configurar los volúmenes de Gateway Storage (Gateway-cached, Gateway-stored, virtual tape library)
  • Generar un vault de Glacier desde la consola y generar una regla del ciclo de vida en S3 para enviar objetos.
  • Leer sobre las diferencias entre import/export disk y snowball.

RDS

  • Generar un database group
  • Generar una instancia de RDS sin replicación multizona
  • Configurar la replicación multizona de la instancia de RDS
  • Generar una réplica de solo lectura
VPC


  • Estudiar conceptos básicos de direcciones IP, máscaras de subred, clases de direcciones IP.
  • Generar una VPC con al menos dos subredes públicas y dos privadas. Configurar el internet gateway, NACL's, NAT (como servicio y apartir de una instancia de EC2). Para este ejercicio se tienen dos laboratorios en CloudAcademy que contemplan todos los puntos.

Route53

  • Estudiar sobre conceptos básicos de DNS y los diferentes tipos de registro (CNAME, A, MX, SOA, NS, etc)
  • Registrar un nombre de dominio. Puede comprarse desde la consola
  • Generar una hosted zone e identificar el default record set.
  • Generar diferentes alias y asociarlos a balanceadores de carga y listas de distribución de CloudFront
  • Leer sobre que es la zona APEX y sus restricciones. 

 CloudWatch

  • Explorar las gráficas generadas para EC2 y RDS
  • Explorar las alertas enviadas a la consola
  • Realizar el laboratorio de qwiklabs.com para generar métricas personalizadas de memoria y uso de disco de una instancia de EC2 y mostrarlas en la consola de CloudWatch
Otros

  • Leer sobre MemCache y Redis, los cuales se ofrecen como servicios en Elastic Cache, así como sus casos de uso.
  • Retomar los conceptos de colas de mensajes y las diferencias y casos de uso de los modelos productor-consumidor y publicador-subscriptor.
  • Entender como se implementan los modelos de mensajería y notificaciones a través de los servicios SQS y SNS.
  • Retomar conceptos de Hadoop y entender como se implementan a través del servicio EMR.
  • Generar una tabla en DynamoDB y experimentar con un cliente Rails para escribir y recuperar datos en JSON.
Al estudiar estos temas uno puede notar que en realidad es bastante información. Cuando estudié la carrera tuve cursos específicos para algunos de los temas y la realidad no terminé de sentirme totalmente preparado al llegar la fecha del examen. Aún así, decidí relizarlo en la fecha pactada y al final concluí lo siguiente.

  • Dedicar un tiempo diario en solitario (incluso fines de semana) al estudio y la práctica. No tiene que ser intenso todo el tiempo pero si constante. Personalmente me funciona estudiar algo muy concreto a ratos en lugar de saturarme de información en una sesión demasiado larga.
  • Establecer una fecha de examen, diría que alrededor de mes y medio de estudio constante puede ser suficiente.
  • El examen no tiene un mínimo de aciertos definido para acreditar, uno debe mentalizarse para obtener la calificación más alta posible.
  • No postergar tanto el examen a pesar de la sensación de no estar totalmente preparado. En el peor de los casos solo no se acredita y se vuelve a programar, lo cual también es experiencia valiosa.
  • En el examen tratar de no dedicar demasiado tiempo a una pregunta, si se tiene que leer más de dos veces o se lleva más de 45 segundos sin contestar mejor dejarla para después. El examen se compone de 60 preguntas en un tiempo de 80 minutos, lo que da un promedio de 1:15 por pregunta.
  • Disfrutar la experiencia. Uno de mis profesores de jiujitsu siempre que ha enseñado que la probabilidad de éxito se incrementa cuando se disfruta cada emoción que se vive al entrar a una competencia. Este exámen para mi fue un torneo más para ganarse el Valhalla y la entrada al Mictlan.