AI en Accion

Guía para desarrolladores de Azure
AI en acción
En tres estudios de caso técnicos
se muestra cómo los desarrolladores
utilizan Azure AI para crear la próxima
generación de aplicaciones
Contenido 2
01 / 02 / 03 /
Introducción Estudio de caso técnico: Estudio de caso técnico:
Three (Reino Unido) Powel (Europa)
04 / 05 / 06 /
Estudio de caso técnico: Conclusión ¿Qué viene a continuación?
NAVITIME (Japón)
Introducción 3
Los desarrolladores en todo

el mundo están utilizando
la inteligencia artificial (AI)
para crear aplicaciones más
útiles, intuitivas y con más
capacidad de respuesta.
En esta colección de estudios
de caso técnicos se destacan
tres ejemplos reales de cómo
los desarrolladores han
usado los servicios de Azure
AI para crear aplicaciones que
acortan las distancias entre
las personas y la tecnología.
Introducción 4
Ejemplos de Azure AI en acción

El proveedor de telecomunicaciones El fabricante de aplicaciones
Three creó un bot impulsado por AI con para viajes NAVITIME desarrolló
API de Cognitive Services que permite un bot de chat que los viajeros
un mejor autoservicio para las tareas pueden usar para encontrar
de los clientes, como activar tarjetas SIM, puntos de interés locales o buscar
migrar sus números o actualizar el servicio. restaurantes atractivos, al tiempo
que les permite superar las barreras
Ir a Estudio de caso Three del idioma local en espera de miles
de visitantes a los Juegos Olímpicos
El proveedor de servicios municipales de Tokio de 2020.
Powel ayuda a los técnicos que trabajan
en infraestructuras eléctricas peligrosas Ir a Estudio de caso NAVITIME
a permanecer más seguros con un bot
de chat manos libres llamado André,
que les permite gestionar la lista de
trabajo y, a la vez, les proporciona
información útil.
Ir a Estudio de caso Powel
En cada estudio de caso técnico se muestra cómo

los desarrolladores crearon sus aplicaciones con
Azure AI y la experiencia de usuario resultante.
En los estudios también se demuestra cómo
cualquier desarrollador puede crear rápidamente
sus propias aplicaciones mejoradas con AI.
Estudio de caso técnico: Three 5
Estudio de
caso técnico:
Three
Estudio de caso técnico:
Febrero LoremThree
ipsum dolor sit amet, consectetur 6
2018 adipiscing elit
Estudio de caso técnico El proveedor de servicios de Internet
El proveedor
y telecomunicaciones Three ha
experimentado informalmente con varios
de Internet
servicios de bot de chat en una variedad de
plataformas, pero busca garantizar la mayor
Three mejora
reutilización de código que sea posible
y reducir la sobrecarga de mantenimiento.
la atención
Su chat web existente ha demostrado tener
mucho éxito, pero aún hay consultas del
al cliente con
usuario sin resolver a través de esta interfaz.
Para resolver este problema, Three trabajó
un bot de chat
con Microsoft para crear un bot que guíe
a los usuarios a través de varios escenarios
de autoservicio
de autoservicio (que no requieran un agente
humano), como activar una tarjeta SIM
y responder preguntas generales, con el fin
Lilian Kasem
de comenzar rápidamente su producción.
13 de junio de 2017
La solución final fue un bot de chat

que responde las preguntas generales
en cualquier momento durante una
conversación. También ofrece dos flujos
de autoservicio que permiten a los usuarios
activar sus tarjetas SIM y migrar sus números
usando el bot, sin tener que salir de
la interfaz de chat. Por último, el bot
también otorgaba a los usuarios información
sobre cómo cancelar o actualizar su contrato
con Three. Como base de todo el bot,
usamos Azure Application Insights para
hacer un seguimiento de la telemetría
de todos los diálogos que esperamos
utilizar más adelante como aportes
en el bot a fin de realizar mejoras en el flujo
conversacional/UX.
Perfil del
Tecnologías clave
cliente:
• Microsoft Bot Framework
(Node.js)
• Microsoft QnA Maker
• Language Understanding
Intelligent Service (LUIS)
• Función Web Apps de Azure
App Service
• Azure Application Insights
Three es un proveedor
de telecomunicaciones y servicios
de Internet que opera en el Reino
Unido. La compañía comenzó en marzo
de 2003 como la primera red móvil
de video comercial del Reino Unido.
Ofrece servicios de 3G y 4G a través
de su propia infraestructura de red.
Three quiere facilitarles la vida a sus

clientes; por ello, los ayuda a obtener
el máximo provecho de sus dispositivos
móviles, les ofrece un valor real de los
servicios que presta y elimina las
barreras que los frustran.
Declaración Soluciones
del problema y pasos
Durante los últimos 18 meses,
Requisitos previos
la funcionalidad de chat web existente
de Three ha demostrado ser muy exitosa,
• Instalar el código de Visual Studio
pero aún hay consultas del cliente
• Instalar Node.js
no resueltas a través de este interfaz
• Obtener las claves de Cognitive Services
existente. Estas incluyen las siguientes:
• Obtener una suscripción a Azure
• Cancelar o actualizar un contrato.

• Nuevo cliente de Three.
Medidas de éxito
• Comprar un nuevo teléfono/contrato. de Three
• Reportar la pérdida o el robo de una
tarjeta SIM o un dispositivo. • Cantidad reducida de chats web
• Agregar o quitar servicios relacionados con los temas para los
y complementos del contrato. cuales hay recursos de autoayuda
• Reportar falta de servicio de Internet, en línea suficientes.
mala cobertura o falta de cobertura. • Aumento en la cantidad de visitas
• Alcanzar el uso del servicio. a los recorridos de autoservicio
• Modificar datos del usuario. seleccionados para resolver consultas
• Realizar consultas de saldo de cuenta. de clientes.
• Validación interna dentro del bot; por
ejemplo, la cantidad de personas que
dicen que la sesión de bot les resultó
útil; es decir, no tuvieron que hacer
llamadas o chatear, etc.
• Determinar el esfuerzo requerido por
los recursos de Three para configurar,
mantener y optimizar los casos del
usuario y las respuestas del bot.
Febrero Lorem ipsum dolor sit amet, consectetur 9
Solución y arquitectura
La solución final en el hackfest fue un bot
de chat que:
• Responde las preguntas frecuentes

mediante el servicio Microsoft
QnA Maker.
• Permite a los usuarios activar sus
tarjetas SIM Three.
◦◦ Los usuarios completan un
formulario a través de una
conversación con el bot.
• Permite a los usuarios migrar su número
de teléfono existente a Three.
• Permite a los usuarios actualizar
o cancelar su contrato con Three.
• Hace un seguimiento de la telemetría
de todos los diálogos utilizando Azure
Application Insights, que más adelante
se usará para retroalimentar el bot
a fin de realizar mejoras en el flujo
conversacional/UX.
El bot comienza con un mensaje de bienvenida que se activa cuando un usuario agrega un bot
a sus contactos o abre una conversación con el bot. Desde aquí, el usuario puede:
• Usar texto libre para hacer una pregunta (de la cual se encarga QnA Maker).
◦◦ Por ejemplo: "¿Qué es 3G?"
• Usar texto libre para indicarle al bot que haga algo (lo que activa el diálogo correspondiente).
◦◦ Por ejemplo: "Quiero migrar mi número".
• Simplemente puede hacer clic en un botón para activar el diálogo correspondiente.
◦◦ Por ejemplo: hacer clic en el botón "Activar SIM".
Todos los diálogos del bot incorporan la telemetría (mediante el uso de Azure Application Insights)
para hacer un seguimiento de dónde están navegando los usuarios dentro del flujo conversacional
del bot: qué tipos de preguntas hacen y cuánto tiempo toma completar una solicitud.
Puede encontrar toda la implementación técnica de lo anterior en la sección "Entrega técnica"

de este documento.
Los botones
(Nodo) seleccionados (Nodo)
Diálogo activan diálogos Diálogo Telemetría Azure
de bienvenida pertinente Application
con opciones. activado Insights
Texto Texto
** Todos los formularios pasan a través de
Reconoci- Entidades
miento de la de los "commonFormIntro.js" que:
(QnAMaker) entidad LUIS campos del 1. Pregunta al usuario si desea completar
Diálogo de formulario el formulario a través de un recurso HTML
bienvenida o mediante el bot.
con opciones. 2. Si elige la opción del bot, se le presentan
al usuario antes de que se ejecute
el formulario para asegurarse de tener
todos los datos necesarios.
** Al ejecutar un generador de formularios de nodo, se activa SIMForm.js que permitirá

reconocer cualquier entidad que ingrese inicialmente el usuario y la usará en el formulario
(después de la revalidación por parte del usuario).
Los principales flujos que Three quiso desarrollar durante el lanzamiento de la solución inicial
del bot fueron:
• Activar SIM
• Migrar un número
• Cancelar o actualizar un contrato
Entrega técnica
En esta sección se describen los detalles de implementación de la solución.
Principales capacidades del bot

Activar SIM
Este flujo de bot está compuesto por varios diálogos:
• ActivateSIM
• ActivateSIMForm
• CommonFormIntro
• ActivateSIMSubmit
ActivateSIM
Primero se pregunta a los usuarios cuál es el perfil que más se ajusta a ellos; esto ayudará al bot
de Three a completar el formulario correcto según el tipo de cliente con quien interactúe. Esto
se hace a través de un sistema de opciones. Según la respuesta del usuario, se llama a diferentes
diálogos, como CommonFormIntro o ActivateSIMForm. En muchos de los siguientes diálogos,
se utilizarán preguntas similares, como se muestra a continuación, para guiar a los usuarios.
builder.Prompts.choice(
session,
'OK\n which of these best describes you?',
[
'I ordered a replacement for a missing or broken SIM',
'I ordered a different size SIM',
'I have just upgraded',
'I am a new customer'
],
{listStyle: builder.ListStyle.button}
)
ActivateSIMForm
En este diálogo se hacen a los usuarios diversas preguntas que deben responder para completar
el formulario necesario a fin de activar la SIM. Este es un método útil para crear fácilmente
un formulario en el marco del bot.
function (session, args) {

// Save entity data to dialogData
if (args.entityData) {
session.dialogData.entityData = args.entityData
}
session.dialogData.index = args.index ? args.index : 0
session.dialogData.form = args.form ? args.form : {}
// Check if entityData exists

if (session.dialogData.entityData) {
// If the entityData exists and it possesses the property for this
question, send a confirm prompt
if
(session.dialogData.entityData.hasOwnProperty(questions[session.dialog
Data.index].field)) {
var prompt = questions[session.dialogData.index].prompt
prompt = prompt.replace('{' +
questions[session.dialogData.index].field + '}',
session.dialogData.entityData[questions[session.dialogData.index].fiel
d])
builder.Prompts.confirm(session, prompt)
} else {
// If the entityData exists but the property for this question
doesn't, send a text prompt
builder.Prompts.text(session,
questions[session.dialogData.index].question)
}
} else {
// If there is no entityData, proceed as normal
questions[session.dialogData.index].question)
}
},
function (session, results, next) {
// Check if the user responding via a Confirm or Text prompt
if (results.response === true) {
// If the confirm prompt is true then we save the entity to the
form object and increment the index
var field = questions[session.dialogData.index++].field
session.dialogData.form[field] =
session.dialogData.entityData[field]
} else if (results.response === false) {
// If the confirm prompt is false then we delete the entity from
the entityData object but we do NOT increment the index
field = questions[session.dialogData.index].field
delete session.dialogData.entityData[field]
CommonFormIntro
En este diálogo se presenta el formulario al usuario y se detalla la información necesaria.
var requirements = ['You will need the following information: \n'];

for (var requirement in session.dialogData.formRequirements) {
requirements.push('\n * ' +
session.dialogData.formRequirements[requirement])
}
requirements = requirements.join('');
session.send(requirements);
Febrero LoremThree
ActivateSIMSubmit
Se llama a este diálogo una vez que se ha completado ActivateSIMForm y se envía el formulario
a Three usando la solicitud para hacer una llamada REST POST a la API de Three. En la siguiente
imagen se muestra lo que ve el usuario después de haber enviado correctamente un formulario.
Migrar un número
Este diálogo es muy similar al de ActivateSIMForm y le hace al usuario las preguntas necesarias
para enviar un formulario que permitirá la migración del número del cliente. El envío también
se hace mediante una llamada POST a Three.
var questions = [
{field: 'mobileNumber', question: 'What is the
existing number you want to keep?'},
{field: 'mobileNumber2', question: 'What is your
temporary new Three number?'},
{field: 'pac', question: 'What is your PAC
number?'},
{field: 'emailPayMonthly', question: 'What is your
email address?'},
{field: 'fullName', question: 'What is your full
name?'},
{field: 'dob', question: 'What is your birthday
(e.g. 01/01/1901)?'},
{field: 'address1', question: 'What is the first
line of your address?'},
{field: 'postcode', question: 'What is your
postcode?'}
];

session.dialogData.index = args ? args.index : 0;
session.dialogData.form = args ? args.form : {};
questions[session.dialogData.index].question);
},
function (session, results) {
{field: 'dob', question: 'What is your birthday
(e.g. 01/01/1901)?'},
{field: 'address1', question: 'What is the first
line of your address?'},
{field: 'postcode', question: 'What is your
postcode?'}
];

session.dialogData.index = args ? args.index : 0;
session.dialogData.form = args ? args.form : {};
questions[session.dialogData.index].question);
},
// Save users reply
var field = questions[session.dialogData.index+
+].field
session.dialogData.form[field] = results.response
Cancelar o actualizar
En este flujo hay tres diálogos:
• Actualizar o Cancelar
• Cancelar
• Actualizar
Actualizar o Cancelar
Este diálogo simplemente pregunta a los usuarios si desean actualizar o cancelar; luego, se llama al
diálogo correspondiente según la elección del usuario. Esto se implementa con un sistema de opciones.
Cancelar
Este diálogo pregunta a los usuarios, mediante un sistema de opciones, si desean un código
PAC o conocer la fecha de finalización de su contrato. Según cuál sea la respuesta, responde
con el número de teléfono para llamar o el sitio web al que deben dirigirse.
Actualizar
Este diálogo hace lo mismo que el diálogo "Cancel" (Cancelar). Solicita el tipo de contrato y, luego,
según la respuesta, le da al usuario la página web que necesita para realizar la actualización.
Febrero LoremThree
Inteligencia del bot

LUIS
En este proyecto, nos basamos principalmente en el uso de regex para determinar la intención
del usuario. Sin embargo, también quisimos utilizar Microsoft Language Understanding Intelligent
Service (LUIS) como respaldo en caso de que el usuario decida ingresar consultas de texto libre.
Creamos un modelo LUIS para manejar las intenciones de los tres flujos que creamos en este bot
(activar SIM, migrar un número, cancelar o actualizar).
Ejemplo del regex utilizado:
matches: /^Activate SIM/i

matches: /^Port my number/i
matches: /^Upgrade or cancel/i
Modelo de LUIS
Primero, configuramos el reconocedor de LUIS dentro de config.js:

// Import LUIS Model
var recognizer = new
builder.LuisRecognizer(process.env.LUIS_MODEL_URL);
bot.recognizer(recognizer);
A continuación, configuramos acciones de activación para cada diálogo del flujo principal, de modo
que si el modelo de LUIS reconocía la intención, activaría el diálogo requerido.
Por ejemplo, si el usuario dice: "Quiero activar mi tarjeta SIM", LUIS lo interpreta como una
intención ActivateSIM, que luego activaría el inicio del diálogo ActivateSIM porque la intención
coincide con la palabra clave triggerAction (ver a continuación). También configuramos
intentThreshold del activador de intención de LUIS para que solo las coincidencias superiores
a una clasificación de confianza de 0,5 activen el diálogo.
.triggerAction({
matches: 'ActivateSIM',
intentThreshold: 0.5
})
Febrero LoremThree
Puede aprender fácilmente cómo crear su propio modelo de LUIS en el sitio web de LUIS.
Febrero LoremThree
QnA Maker
Three usó el servicio QnA Maker de Microsoft Cognitive Services para responder a las preguntas
simples del cliente que se encuentran disponibles en línea (página de preguntas frecuentes de Three).
Esto se implementó rápidamente y permitió separar las consultas simples del cliente de la asistencia
humana directa.
Este es el diálogo de QnA que maneja todas las preguntas frecuentes. Llamamos a endDialog
para que el bot regrese al diálogo anterior en el que estaba el usuario cuando se hizo la pregunta.
module.exports = function () {
bot.dialog('QnA', (session, results) => {
console.log(process.env)
var client = restify.createJsonClient('https://
westus.api.cognitive.microsoft.com')
var options = {
path: '/qnamaker/v2.0/knowledgebases/' + process.env.QNA_KB_ID +
'/generateAnswer',
headers: {
'Ocp-Apim-Subscription-Key': process.env.QNA_SUBSCRIPTION_KEY
}
}
var question = {'question': results.question}
client.post(options, question, (err, req, res, obj) => {

if (err == null && obj.answers.length > 0) {
for (var i in obj.answers) {
if (parseInt(obj.answers[i].score) > 0.80) {
session.endDialog(obj.answers[i].answer)
} else {
session.endDialog('Sorry, I couldn\'t find an answer in
our FAQs. Don\'t forget, you can type
\'help\'
if you need assistance')
}
}
} else {
session.endDialog('Sorry, there was an error!')
}
})
})
}
Febrero LoremThree
A continuación, se llama a este diálogo a través de UniversalBot. Esto significa que QnA Maker
aparece a nivel global en todo el bot. Si LUIS o cualquiera de las expresiones de regex no reconoce
la consulta del usuario, se enviará al diálogo de QnA.
global.bot = new builder.UniversalBot(connector, function (session) {

session.send('I\'ll just check that for you...',
session.message.text)
session.replaceDialog('QnA', { question: session.message.text })
});
La funcionalidad de QnA Maker también se activa cuando el usuario dice help (ayuda), quit (salir),
problem (problema) o support (soporte) y no quiere el menú principal:
if (results.response && results.response.entity === 'no') {

builder.Prompts.text(session, 'Ok, why don\'t you try asking your
query here and I\'ll search our FAQs');
}
.
.
.
function (session, results, next) {
session.replaceDialog('QnA', { question: session.message.text });
}
Febrero LoremThree
Azure Application Insights

Configuramos Application Insights para capturar la telemetría dentro del bot. Esto se usa para
hacer un seguimiento de los flujos conversacionales que atravesó el usuario dentro del bot
y también para hacer un seguimiento de las métricas sobre cuánto tardó en completarse una tarea
en particular.
Primero, configuramos el cliente Application Insights en el archivo config:
global.telemetryModule = require('./telemetry-module')
const appInsights = require('applicationinsights')
appInsights.setup(process.env.APPINSIGHTS_INSTRUMENTATION_KEY).start()
global.appInsightsClient = appInsights.getClient()
A continuación, creamos un módulo de telemetría para manejar el trabajo de telemetría:
Por último, creamos diferentes objetos de telemetría en cada diálogo para registrar que el usuario
visitó el diálogo. Por ejemplo:
// Store entity data in dialogData

session.dialogData.entities = data;
// Create a new telemetry module with session data
session.dialogData.telemetry =
telemetryModule.createTelemetry(session, { setDefault: false });
// Track that the user has been to the activate sim dialog
appInsightsClient.trackTrace('activateSIM',
session.dialogData.telemetry);
Febrero LoremThree
A continuación, podemos recuperar los resultados del seguimiento dentro del portal de Analytics
en Azure Application Insights:
Para rastrear cuánto tiempo tomó el envío de un formulario, se usó el siguiente código:
// Setup a telemetry module

session.dialogData.measuredEventTelemetry =
telemetryModule.createTelemetry(session);
// Start timer. We want to track how long it takes for us to submit a
SIM activation request
session.dialogData.timerStart = process.hrtime();
.
.
.
// Submittion has been made, calculate how long it took.
var timerEnd = process.hrtime(session.dialogData.timerStart);
// Save the time it took to 'metrics' within the
measuredEventTelemetry module
session.dialogData.measuredEventTelemetry.metrics = (timerEnd[0],
timerEnd[1] / 1000000);
// Track the above metric as 'timeTaken'
appInsightsClient.trackEvent('timeTaken',
session.dialogData.measuredEventTelemetry);
Febrero LoremThree

Conclusión Desafíos
Comenzamos este proyecto con • La documentación del SDK de Node.js

el objetivo de crear un bot que pueda puede ser difícil de seguir en su forma
guiar a los usuarios por varios escenarios actual y está limitada en comparación con
de autoservicio, como activar una tarjeta la documentación del SDK de C#. Esto
SIM y responder preguntas frecuentes a veces dificultó encontrar la información
generales, con el fin de comenzar necesaria para preparar el bot. Sin
rápidamente su producción. embargo, se encuentran disponibles
muchos ejemplos de código útiles.
Como resultado, desarrollamos un bot
convincente que debería permitirle • La información sobre errores de los
a Three ahorrar mucho tiempo y dinero. servicios LUIS y QnA es limitada
Hará el trabajo más fácil para los o inexistente en el caso de QnA
agentes de atención al cliente, porque Maker. Esto dificultó la depuración
ya no tendrán que lidiar con preguntas y averiguación de por qué las cosas
frecuentes simples o generales, lo que les no funcionaban según lo previsto.
dejará tiempo para atender las consultas
más específicas y complicadas. El bot • Las guías claras sobre los
también debería proporcionar a los procedimientos recomendados de
clientes un método más simple y más desarrollo del marco de bot aún están
rápido para obtener las respuestas a sus en evolución. Cuando se desarrolla un
consultas a través de una experiencia bot previsto para la producción, resulta
de conversación guiada. Three cree que útil saber cuáles son los procedimientos
esto va a cambiar el comportamiento recomendados para llevar a cabo
de los clientes y los agentes por igual, algunas tareas, como, por ejemplo:
al hacerlos más productivos.
◦◦ Determinar la estructura del
proyecto.
◦◦ Solicitarle al usuario sus comentarios
al final de un diálogo.
◦◦ Usar LUIS frente a regex.
Febrero LoremThree
Aprendizajes
Los mensajes de bienvenida no funcionan con Slack
A diferencia de otros canales, no se activa onConversationUpdate cuando se agrega un bot

a Slack. Además, no se activa contactRelationUpdate cuando se agrega un usuario a Slack. Esto
significa que actualmente no hay forma de darle la bienvenida a un usuario de Slack y presentarle
el bot sin que interactúe con el bot primero. Descubrimos que el canal nativo de Slack se encarga
de esto. Si se usa un socket web, el marco Slack envía un evento bot_added para informarle cuando
un usuario ha agregado un bot a su canal Slack. Sin embargo, Microsoft Bot Framework no usa
sockets web con Slack ni recibe notificaciones sobre este evento.
El paquete de QnA Maker desarrollado previamente es "semipermanente"
Si inicia el diálogo de QnA, no hay salida obvia de este flujo de diálogo. El usuario se quedaría atascado
utilizando el servicio de QnA y no podría continuar usando los otros diálogos del bot, a menos que use
el comando restart (reinicio) global. La solución es llamar a la API de QnA directamente y finalizar
el diálogo una vez respondida la pregunta. De esta manera, los usuarios pueden hacer una pregunta
en medio de cualquier otro diálogo, obtener una respuesta a través del servicio de QnA y, luego,
continuar con el diálogo en el que estaban. Puede encontrar la implementación en la sección "Entrega
técnica" de este documento (en QnA Maker) o en este repositorio de GitHub de ejemplo.
Cómo implementar palabras seguras
Mediante el uso de regex y acciones, podemos configurar comandos globales que los usuarios
pueden utilizar en cualquier momento en el bot. Esto permite a los usuarios regresar de un diálogo
cuando se atascan en un flujo conversacional.
bot.endConversationAction('goodbye', 'Goodbye :)', { matches: /^bye/

i });
bot.beginDialogAction('home', '/start', { matches: /^home/i });
bot.beginDialogAction('help', '/help', { matches: /^help/i });
Febrero LoremThree
Uso de las intenciones de LUIS a través de triggerActions y la configuración de intentThreshold
En lugar de usar el método habitual de coincidencia de intenciones de LUIS:
intents = new builder.IntentDialog({recognizers: [recognizer]});
intents
.matches('LUIS_Intent', '/dialog')
.matches('LUIS_Intent', '/dialog')
.onDefault(builder.DialogAction.send("I'm sorry. I didn't
understand."));
Descubrimos que era mucho más fácil hacer coincidir las intenciones de LUIS con los diálogos
a través de triggerActions (que simplemente se agrega al final de un diálogo). Esto también nos
permitió descubrir que puede configurar un umbral que deben alcanzar las intenciones de LUIS
antes de que se activen mediante el uso de intentThreshold. La opción predeterminada es activar
acciones incluso si la confianza de la coincidencia es menor que 0,1.
.triggerAction({
matches: 'ActivateSIM',
intentThreshold: 0.5
})
También puede agregar un intentThreshold a nivel global, para que se aplique a todas las
coincidencias de LUIS:
intents = new builder.IntentDialog({ recognizers: [recognizer],

intentThreshold: 0.5 });
Febrero LoremThree
Una forma fácil y clara para completar formularios
Hemos desarrollado una manera clara de hacer preguntas a los usuarios para completar
un formulario mediante recursividad del diálogo.
Primero, cree una serie de preguntas:
var questions = [
{field: 'mobileNumber', question: 'What is the existing number you
want to keep?'},
{field: 'mobileNumber2', question: 'What is your temporary new
Three number?'},
{field: 'pac', question: 'What is your PAC number?'},
{field: 'emailPayMonthly', question: 'What is your email
address?'},
{field: 'fullName', question: 'What is your full name?'},
{field: 'dob', question: 'What is your birthday (e.g.
01/01/1901)?'},
{field: 'address1', question: 'What is the first line of your
address?'},
{field: 'postcode', question: 'What is your postcode?'}
]
A continuación, recorra cada pregunta llamando al mismo diálogo y pasando un contador

de índice; además, guarde la respuesta del usuario después de cada pregunta:
bot.dialog('FillOutForm', [ Puede encontrar

function (session, args) { un ejemplo de código
session.dialogData.index = args ? args.index : 0
session.dialogData.form = args ? args.form : {} de seguimiento
de este aquí: Ejemplo
questions[session.dialogData.index].question) de formulario simple
}, para SDK de nodo
// Save users reply
var field = questions[session.dialogData.index++].field
session.dialogData.form[field] = results.response
// Check for end of form

if (session.dialogData.index >= questions.length) {
session.privateConversationData.portForm = session.dialogData.form
session.beginDialog('EndofForm')
} else {
session.replaceDialog('FillOutForm', session.dialogData)
}
}
Febrero LoremThree
Planes de producción
El plan para este bot es atravesar una prueba A/B en las próximas semanas, para que
lo puedan evaluar clientes reales. Después de esta prueba A/B de una semana, el plan
es pasar este bot a producción en el término de meses.
Desde una perspectiva más lejana, Three reconoce que puede brindar una experiencia más
enriquecedora mediante lo siguiente:
• En lugar de que haya vínculos a recursos en el sitio web de Three, el usuario puede
hacerle preguntas al bot sobre el tema de la página y recibir respuestas según el
contenido de esta.
• Integración con las API: hay API basadas en la red sobre problemas de interrupción
y cobertura, así como sobre notificación de problemas, que se podrían incluir en una
experiencia de bot.
• Publicación en formularios: por ejemplo, solicitar una SIM o migrar un número a Three
se puede facilitar mediante el bot.
• Transferencia a un centro de llamadas o agentes en vivo.
• Personalidad y personalización: llamar al usuario por su nombre y personalizar

el contenido para que se ajuste a él.
Febrero LoremThree
"Gracias a todos por invitarnos

a esta increíble semana. Ha sido
realmente divertida y tenemos más
que el prototipo de un producto
real para llevar al mercado. Estamos
destrozados por tener que regresar
al trabajo real mañana".
Justin Beasley
Gerente principal de desarrollo digital
"Gracias @microsoft-simon y al resto

del equipo de MS. La pasamos muy
bien y aprendimos mucho".
Stuart Brown
Gerente de desarrollo digital
Recursos Documentación:
Microsoft Bot Framework
adicionales QnA Maker

LUIS
Código:
Ejemplo de indicación única de QnA para el SDK
de Node.js
Ejemplo de llenado de formulario simple para el SDK
de Node.js
Equipo Microsoft:
Lilian Kasem, evangelizadora técnica
Simon Michael, evangelizador técnico sénior
Bill Barnes, ingeniero principal de desarrollo de software
Three:
Justin Beasley, gerente principal de desarrollo digital
Nick Bishop, gerente de desarrollo digital
Stuart Brown, gerente de desarrollo digital
Thomas Barton, líder de Scrum
Dimos Fountoukos, desarrollador de software
Estudio de caso técnico: Powel 41
Estudio de
caso técnico:
Powel
Febrero LoremPowel
Estudio de caso técnico Durante marzo de 2017, en las oficinas
Usar CaaP y André,

de Microsoft en Lysaker, Noruega,
Microsoft se asoció con Powel para crear
el bot asistente
un nuevo bot llamado André. El objetivo
del hackfest fue crear un bot de chat
impulsado por
impulsado por voz que podría ayudar a los
ingenieros de campo en las redes eléctricas
voz, para mejorar
a responder preguntas y proporcionar
funcionalidades de informes durante las
la inspección
inspecciones para que ellos no tuvieran
que usar las manos. La solución se creó con
en el lugar
herramientas de Microsoft que hacían uso
de bots de chat y conversaciones como
plataforma (CaaP).
Pedro Dias y Anders Gill
19 de junio de 2017
En este hackfest, utilizamos las

siguientes tecnologías clave:
Equipo principal
• Microsoft Cognitive Services
• Language Understanding Intelligent
Powel
Services (LUIS) • Damian Plaza,
• Xamarin.Forms ingeniero de software
• Bing Speech API
• GitHub • Jakub Hiszczyn,
• Visual Studio Team Services
ingeniero de software
• Visual Studio 2017 • Karol Stosik,
Además, el equipo expresó la necesidad
de obtener más experiencias prácticas con • Maksymilian Jastrzebski,
los siguientes:
• Tor Hovland,
• Automatización de pruebas ingeniero de software
• Escenarios de integración continua/
entrega continua (CI/CD) • Simen Karlsen,
activador de red inteligente
El hackfest tuvo lugar después de varias • Øystein Askeland,
llamadas en las que se desmitificó el área diseñador de interacción
problemática y se establecieron las
metas del hackfest. Microsoft
• Pedro Dias,
evangelizador técnico sénior
• Anders Gill,
evangelizador técnico
Resumen
de la solución
Powel prevé un futuro en el cual los El objetivo fue ser capaces de diseñar dos
ingenieros del lugar puedan usar su voz diálogos de conversación muy diferentes
natural para acceder al soporte asistido con las suficientes funcionalidades
por computadora durante las inspecciones para probarse en el campo. En función
de las instalaciones de energía. Durante de estos diálogos, Powel habrá acumulado
la inspección de una estación eléctrica suficiente experiencia con CaaP para
o línea de energía, André, una aplicación enriquecer André y diseñar aplicaciones
de telefonía basada en Xamarin, permitirá conversacionales similares para usar
que los ingenieros tengan las manos en otras áreas.
libres, lo que proporcionará un proceso
más fluido que el tener que completar Utilizamos Xamarin.Forms, Microsoft Bot
un formulario de papel o registrar Framework, LUIS y Cognitive Services
datos en una aplicación del dispositivo. para desarrollar un bot que permitiría que
Mediante el uso de las capacidades los ingenieros le hablen a la aplicación
de un dispositivo portátil, como un de Android Xamarin.Forms. La aplicación
teléfono móvil, la aplicación entenderá utiliza el motor de reconocimiento de voz
automáticamente qué instalación se está de Google para convertir audio en texto;
inspeccionando al obtener la ubicación a continuación, el texto se enviaría
GPS del usuario y proporcionará las listas a LUIS para determinar la intención
de verificación necesarias y los diálogos del usuario en cualquier momento
correspondientes a esa instalación. durante la conversación. En función
de las intenciones y entidades detectadas,
El hackfest se centró en dos objetivos Bot Framework enviaría la respuesta
distintos de la inspección: correspondiente de nuevo a la aplicación
del cliente que leería la respuesta
• Centrales eléctricas al ingeniero, ayudándolo a permanecer
• Tendido eléctrico seguro al no tener que usar las manos.
Una característica en particular que realmente amplía la utilidad de este bot es la integración de Bot
Framework en el sistema de back-end de Powel. Integramos correctamente el bot a los sistemas
que, por ejemplo, permitirían a los ingenieros extraer información valiosa, como, por ejemplo:
• el historial de las inspecciones en instalaciones específicas

• partes específicas propensas a mantenimiento constante
• información ampliada sobre las instalaciones
• la ruta más rápida a la siguiente instalación priorizada crítica que debe repararse
• una lista de verificación de los posibles métodos de rectificación
"Microsoft Bot Framework y Cognitive

Services nos ayudarán en Powel
a empoderar a nuestros clientes al
hacer que su día de trabajo sea más
simple, más seguro y más eficaz".
Simen Karlsen
Activador de red eléctrica, Powel
Perfil del Declaración

cliente: del problema
El aspecto número uno que recalcan
todas las compañías es la seguridad de los
trabajadores. Powel no es la excepción.
Sin embargo, ciertos trabajos son
más peligrosos que otros. Powel tiene
algunos de los clientes más importantes
Powel se extiende por Europa con una base
en Noruega que mantienen y desarrollan
de clientes amplia y sostenible, además
las redes eléctricas. Estas inspecciones
de una larga trayectoria como proveedor
deben realizarse una vez al año en cada
confiable de soluciones de software para
instalación. Las otras inspecciones técnicas
ciudades, municipios, condados, la industria
más profundas deben llevarse a cabo
energética y el sector de contratación.
una vez cada 10 años para todos los
Powel genera alrededor de USD 50 millones
componentes de la red eléctrica. Estos
de ingresos cada año y se fundó |
períodos de inspección se exigen por ley.
en Noruega en 1996. Powel ha crecido
hasta convertirse en una corporación
Para realizar una inspección, un ingeniero
internacional con un personal que asciende
probablemente tenga que subirse
a 460 empleados y oficinas en estos
a postes altos, lo que puede crear situaciones
seis países, además de Noruega: Suecia,
peligrosas según el clima y otros factores.
Dinamarca, Suiza, Chile, Turquía y Polonia.
Estas inspecciones se realizan especialmente
en invierno cuando la helada en el suelo
Segmentos de negocio de Powel:
impide el desarrollo de nuevas redes. Esto
obliga a las compañías a concentrarse en
• Energía inteligente
el mantenimiento, lo que también constituye
• Rendimiento de activos
un trabajo importante. Por este motivo,
• Medición
sería muy incómodo tener un teléfono
• Agua y comunidad
celular o una computadora portátil en
• Construcción
la mano cuando probablemente podría estar
colgando muchos metros sobre el suelo.
Como resultado, un ingeniero debe recordar Una inspección podría constar de varias
qué tiene que verificar, qué problemas etapas: desde evaluar las instalaciones
potenciales podría haber, si se realizó y brindar datos sobre los tipos de
otro tipo de mantenimiento en este poste problemas descubiertos (actualmente
o esta estación en particular, qué tipos basados en una lista de verificación) hasta
de soluciones permiten resolver cualquiera realmente resolver los problemas. Algunos
de los problemas descubiertos, entre otras de los problemas comunes varían desde
cuestiones. Con estos datos, el ingeniero pájaros carpinteros que picotean los postes
tiene que dirigirse nuevamente a la oficina o grafitis hasta problemas más graves,
principal para entregar la información a sus como fallas en componentes eléctricos
colegas o digitalizarla él mismo. Durante de alta tensión.
este período, se podría perder información
valiosa y contextos específicos que En resumen, el bot de chat podrá
se reunieron durante la inspección. realizar las siguientes tareas:
Powel requiere de una solución que permita • Permitirá evitar problemas de seguridad
a los ingenieros no usar las manos mientras al no usar las manos.
siguen sumando valor a la conversación. • Proporcionará información específica
Un bot de chat activado por un simple relacionada con instalaciones
"Hola, André" podría posiblemente aliviar en particular.
al ingeniero de tener que recordar todas • Gestionará la entrega de notas
las tareas que debe ejecutar durante de la inspección actual para que
la inspección. Lo bueno de un bot de chat no se pierda ninguna información
de este tipo es que se podría conectar durante la inspección.
a todos los otros sistemas que son relevantes • Respaldará al ingeniero con otra
y, de esta manera, podría proporcionar información relevante que podría ser
al ingeniero toda la información que importante conocer o que podría haber
necesita. Este fue uno de nuestros objetivos olvidado durante la inspección.
para el hackfest: poder desarrollar un
bot de chat simple que pueda transmitir
diálogos a sistemas externos y devolver
información valiosa que pueda aumentar
la eficiencia durante una inspección.
Solución
Como trabajador de campo, quisiera
poder enviar las inspecciones correctas
y pasos
a un bot para no tener que llenar un
formulario para tal fin.
Definimos las características y las tareas

Pedro fue quien inició el hackfest y quien para facilitar la distribución del trabajo
presentó Bot Framework al equipo con en el equipo. Creamos dos repositorios: uno
ejemplos de un bot en funcionamiento; para la aplicación del bot ASP.NET y otro
además, explicó las características y se para la aplicación Xamarin.Forms. También
aseguró de que todo el equipo estuviera configuramos CI en Bot Framework para
listo antes de comenzar el desarrollo. que se cree e implemente en Microsoft
Azure después de cada confirmación.
El objetivo de la hackfest de tres días era
crear una aplicación del cliente en Xamarin.
Forms para Android que permitiera
visualizar la conversación que el ingeniero
tendría utilizando Bot Framework con LUIS
y Cognitive Services. Creamos una historia
de usuario en Visual Studio Team Services
que consistía en múltiples tareas.
La historia de usuario era la siguiente:

Panel de Kanban
Decidimos usar Android para la parte El bot de prueba de concepto (PoC)

de visualización porque todos los desarrollado durante el hackfest
desarrolladores de Powel tenían se utilizaría como una base que ayudaría
dispositivos Android. Además de desarrollar a Powel a comenzar la producción de
una aplicación que funcionaba, el objetivo su propio bot después de mayor desarrollo.
también era capacitar a los desarrolladores
de Powel en Bot Framework y CaaP para
que pudieran plasmar sus conocimientos
en la mesa de dibujo cuando desarrollen
y amplíen sus aplicaciones para escenarios
que podrían aprovechar Bot Framework
y Cognitive Services.
Bosquejo de cómo un ingeniero de campo generalmente inspeccionaría

una central eléctrica
Se logró lo siguiente al finalizar el hackfest: Lo siguiente no se implementó, pero

estuvo en el ámbito del hackfest:
• Inspección de la central eléctrica
◦◦ Listas de control y diálogo • Inspección del tendido eléctrico
adecuados para una instalación • Traducción del texto del noruego
específica al inglés
◦◦ Selección de subestaciones • Carga de una imagen desde una
◦◦ Selección del tipo de discrepancia aplicación móvil
◦◦ Registro de discrepancias con • Activación de una conversación
comentarios, integrados mediante voz sin usar un botón
con el back-end de Powel
El bot de chat de PoC actual permite al ingeniero de campo ejecutar una inspección iniciando una
conversación a través de su voz natural, preguntar sobre sus capacidades, seleccionar una subestación
y registrar una discrepancia de un tipo específico con un comentario. Esto satisface el sistema de
retroalimentación al enviar datos directamente al back-end de Powel para que el ingeniero de campo
ya no tenga que estar presente físicamente en las oficinas a fin de registrar la misma información.
Diagrama de la arquitectura
Entrega técnica
Ahora tiene todo lo que necesita para crear
una aplicación de bot. Para obtener una
referencia completa sobre cómo empezar
con Bot Builder, consulte el SDK de Bot
Builder para .NET.
Configuración del
entorno de desarrollo Día de logros 1
André es una aplicación de Xamarin.Forms,
Para empezar con el proyecto, tuvimos
por lo que tuvimos que implementar los
que instalar y configurar lo siguiente:
servicios nativos para que la aplicación
móvil escuchara y hablara a través
Visual Studio
de la interfaz de reconocimiento de voz
de Google. También comenzamos
• Instale Visual Studio 2017 (Visual Studio
a trabajar en los componentes de chat
2015 también funciona) Nota: Asegúrese de
de la aplicación.
que Xamarin se incluya en la instalación de Visual
Studio para desarrollar la aplicación André.
Con LUIS, hicimos 10 intentos descritos
y probados con enunciados. Comenzamos
• Descargue e instale el emulador de Bot
a escribir diálogos imaginarios entre
Framework
un usuario y la aplicación para comprender
mejor cómo fluiría la conversación.
• Descargue e instale la plantilla del bot
También empezamos a experimentar con
para Visual Studio para C#
entidades de LUIS y logramos que las
intenciones reconocieran y utilizaran estas
Language Understanding Intelligent
entidades.
Services (LUIS)
Para Bot Framework, creamos una

Para usar LUIS, vaya a la página de inicio
aplicación de bot en el espacio dev.
de LUIS y cree una cuenta. Puede probarlo
framework.com y un sitio en Azure
en forma gratuita por una generosa
para la API web.
cantidad de mensajes por día.
Configuración del bot en Azure Optamos por usar la clase

CloudConfigurationManager para leer
Bot Framework básicamente funciona la configuración directamente desde
como cualquier servicio de aplicación App Service.
de ASP.NET. Tiene un controlador que
gestiona los mensajes de la conversación,
de modo que, en esencia, todo lo que debe Configuramos CI en Visual Studio Team
hacer es lo siguiente: Services para crear e implementar
el bot en Azure en cada confirmación.
• Crear o registrar un nuevo bot en el sitio A continuación, agregamos la integración
para desarrolladores de Bot Framework. de LUIS para empezar a trabajar con las
Esto le dará un identificador de bot intenciones. En este punto, implementamos
(GUID) y un secreto de la aplicación dos intenciones.
para su bot.
• Anote el id. de la aplicación

y la contraseña en el mismo portal.
• Implemente el código del bot

en Azure App Service.
• Configúrelo de manera tal que incluya

el id. de la aplicación y la contraseña
para que pueda conectar la API web
a Bot Framework.
(Para una referencia completa a este

proceso, consulte Cómo implementar
un bot en la nube).
Día de logros 2
Concluimos la conexión directa mediante el uso de la biblioteca de clases portátiles (PCL)
WebSockets, pero al final optamos por HTTP, porque no pudimos lograr que PCL funcionara.
Esto se debió en gran parte al desafío de conseguir que WebSockets funcionara en Android; en este
punto, no estábamos seguros si habíamos logrado una solución rápida, así que, por cuestiones
de tiempo, dejamos de intentarlo y centramos nuestros esfuerzos en conseguir que todo funcione.
Conectamos correctamente la aplicación de bot al back-end de Powel (una API denominada

Condition Monitoring) mediante el uso de API.
Una observación acerca de las API del back-end
Conectamos las API del back-end de Powel a través de algunos paquetes de NuGet
internos de Powel y llamamos a los métodos en los objetos que están dentro.
Fue fácil acceder a estos paquetes de NuGet a través de Visual Studio Team Services
para CI. Debido a la sensibilidad del código, no podemos compartir ejemplos de código
específicos, pero en esencia usamos las API para obtener identificadores de instalación
por ubicación de GPS (longitud/latitud) y para enviar los datos del informe.
Conectamos la aplicación móvil al bot y logramos que funcionara. También destinamos un tiempo
a diseñar la aplicación Xamarin.Forms y a asegurarnos de que la interfaz y la experiencia del usuario
fueran buenas.
La siguiente imagen es un bosquejo básico inicial de la interfaz de diseño que hicimos con
PowerPoint Storyboarding.
También trabajamos para incluir los paquetes de NuGet de las API principales de Powel
(específicamente, la API Condition Monitoring) en la compilación para el bot. Trabajamos
en algunos planes de flujo de conversación para una posterior implementación y pasamos más
tiempo trabajando con las intenciones y capacitando a LUIS para que las reconociera.
Pasamos mucho tiempo en los objetos PromptDialog porque nos olvidamos de establecer
la implementación del diálogo como [Serializable].
Otros puntos débiles que experimentamos:
Algunos problemas con la versión de .NET Framework que no coincidía con Bot Framework
WebApiConfig de la plantilla del bot hizo que todos los nombres de parámetros quedaran con
mayúsculas y minúsculas estilo JSON. La API interna de Powel no lo aceptó, lo que nos tomó
un tiempo descubrir.
La configuración inicialmente era algo como esto.
JsonConvert.DefaultSettings = () => new JsonSerializerSettings()

{
ContractResolver = new CamelCasePropertyNamesContractResolver(),
Formatting = Newtonsoft.Json.Formatting.Indented,
NullValueHandling = NullValueHandling.Ignore,
};
Simplemente quitamos la línea ContractResolver y parece que eso resolvió el problema.
Terminamos el día probando el bot en exteriores

para ver cómo manejaba el ruido de fondo
y si sería capaz de captar la intención del
ingeniero de campo. El lugar elegido fue
un entorno ruidoso (una carretera) que muy
bien podría ser un sitio de inspección real donde
un ingeniero tendría que inspeccionar una línea
aérea o un poste de energía. La prueba fue
satisfactoria y se obtuvieron resultados positivos.
Día de logros 3
La última parte del hackfest fue la configuración de la automatización de la compilación del
proyecto Xamarin.Forms mediante el uso de Visual Studio Mobile Center, además de descubrir
las posibilidades para lograr que una conversación fluya por diferentes diálogos.
En el siguiente diagrama se muestra el flujo final del bot de chat PoC. (Lamentablemente,
no implementamos la traducción del texto debido a las limitaciones de tiempo, pero
sí incluimos esa parte en la siguiente imagen).
Un trabajador de campo le habla a André (la aplicación móvil) en su idioma natural. El motor
de reconocimiento de voz de Google transforma la voz en texto y lo regresa a la aplicación
móvil. La aplicación envía el texto para su traducción y recibe un texto completamente traducido
a cambio. A continuación, la aplicación pasa el texto traducido a LUIS, que capta la intención
y las entidades para devolver la respuesta a la aplicación móvil. La aplicación móvil envía
la intención y las entidades detectadas (incluido el id. del trabajador de campo) a Bot Framework,
que envía una solicitud al back-end de Powel. La respuesta adecuada se devuelve a la aplicación
móvil, que traduce el texto al idioma del trabajador de campo y dice el texto en voz alta.
Gestión de diálogos
En Bot Framework, un diálogo funciona como el "cerebro" del bot de chat.
Un diálogo proporciona un par de características claras que permiten administrar

el estado de la conversación y gestionar las sesiones, así como la persistencia que se basa
en la implementación de una interfaz denominada IDialog. Esta interfaz gestiona la transición
de estado mediante IDialogContext. Estos principios se han incluido en la manera en que
trabajamos con el bot durante el hackfest y forman una parte integral del bot, lo que le permite
dirigir una conversación usando la pila subyacente, donde guarda datos en el objeto de la sesión,
a la que se puede acceder durante el transcurso de la conversación.
Por ejemplo, cuando LUIS reconoce la intención del usuario como "happy" (feliz), Bot Framework
procederá a ese método en particular con la intención y proporcionará la respuesta adecuada.
[LuisIntent("happy")]
public async Task Happy(IDialogContext context, LuisResult result)
{
await context.PostAsync("That's so kind of you!");
context.Wait(MessageReceived);
}
Otro ejemplo es cuando LUIS reconoce que el usuario quiere seleccionar una subestación.
[LuisIntent("selectSubstation")]
public async Task SelectSubstation(IDialogContext context, LuisResult
result)
{
AssetService assetService = new AssetService(new
AssetRepository());
string extractedName;
string message = "I'm sorry, I didn't catch the name of the
substation.";
if (TryExtractingSubstationName(result, out extractedName))

{
var asset = await assetService.GetByName(extractedName);
substationName = asset != null ? extractedName : null;
message = asset != null ? $"The substation {substationName}
has been chosen." : $"Sorry, I didn't find a substation called
'{extractedName}'.";
}
await context.PostAsync(message);
}
También se desarrollaron diálogos más complejos en los que Bot Framework se comunica con
el back-end correspondiente de Powel y menciona los tipos de discrepancia posibles entre los
cuales el ingeniero puede elegir.
[LuisIntent("getDiscrepancyType")]
public async Task SelectControlPoints(IDialogContext context,
LuisResult result)
{
if (String.IsNullOrEmpty(substationName))
{
await context.PostAsync($"You need to tell what substation you
want to select.");
}
else
{
DiscrepancyTypeService discrepancyService = new
DiscrepancyTypeService(new DiscrepancyTypeRepository(new
InspectionRepository(new AssetRepository()), new AssetRepository()));
AssetService assetService = new AssetService(new
AssetRepository());
InspectionService inspectionService = new
InspectionService(new InspectionRepository(new AssetRepository()));
var asset = await assetService.GetByName(substationName);
var inspection = await
inspectionService.GetNotPerformedByAssetId(asset.ObjectId);
var discrepancyTypes = await
discrepancyService.Get(asset.ObjectId, inspection.Id);
await context.PostAsync($"You have your discrepancy types

here:\n {JsonConvert.SerializeObject(discrepancyTypes)}");
}
}
Diálogo de solicitud
Bot Framework incluye varias solicitudes incorporadas que pueden recoger las entradas de
un usuario. Este tipo de solicitud se usó durante todo el proyecto del bot, como cuando André
le pregunta al ingeniero de campo si está satisfecho con la inspección y desea terminar. Esto
se basa en el reconocimiento de una intención de LUIS de assetAllGood.
[LuisIntent("assetAllGood")]
public async Task AssetAllGood(IDialogContext context, LuisResult
result)
{
if (String.IsNullOrEmpty(substationName))
{
await context.PostAsync($"You need to tell what substation you
want to select.");
}
else
{
PromptDialog.Confirm(context, AfterConfirmAsync, "Are you sure
that you want to finish this inspection?");
await Task.FromResult<Object>(null);
}
}
En el escenario anterior, al ingeniero de campo se le pide que confirme con "Sí" o "No" (presionando
el botón correspondiente o usando su voz natural para responder), pero se pueden elegir muchos
otros tipos de entradas de colección de datos:
• Prompts.text Le solicita al usuario que ingrese una cadena de texto

• Prompts.confirm Le solicita al usuario que confirme una acción
• Prompts.number Le solicita al usuario que ingrese un número
• Prompts.time Le solicita al usuario que indique una hora o una fecha
• Prompts.choice Le solicita al usuario que elija de una lista de opciones
• Prompts.attachment Le solicita al usuario que cargue una foto o un video
FormFlow
Como hemos visto, los diálogos funcionan como un poderoso mecanismo para guiar una
conversación, pero pueden volverse complejos cuando el rompecabezas tiene muchas piezas
pequeñas, como ordenar un sándwich. Para simplificar una conversación guiada, Bot Framework
ofrece una forma mucho más fácil de crear un diálogo, denominada FormFlow. Un diálogo FormFlow
guía al usuario para completar el formulario mientras le brinda ayuda y orientación en el transcurso.
El diálogo del formulario se usa cuando el ingeniero de campo necesita enviar una discrepancia, para
la cual debe completar los campos restantes, incluidos el tipo de discrepancia y el comentario.
[Serializable]
public class DiscrepancyFormDialogBuilder
{
public string DiscrepancyType;
public string Comment;
public static IForm<DiscrepancyFormDialogBuilder> BuildForm()

{
return new FormBuilder<DiscrepancyFormDialogBuilder>()
.AddRemainingFields()
.Build();
}
public static IFormDialog<DiscrepancyFormDialogBuilder>

Build(FormOptions options = FormOptions.PromptInStart)
{
// Generated a new FormDialog<T> based on IForm<BasicForm>
return FormDialog.FromForm(BuildForm, options);
}
};
Connector
Bot Framework Connector es un componente que proporciona una sola API para que el bot
se comunique a través de varios servicios del cliente, como Skype, correo electrónico y Slack.
Debido a que ya estábamos usando Slack para la comunicación en el hackfest, decidimos configurar
la integración con Slack para que podamos hablar con el bot eficazmente (lea sobre los pasos para
configurar los canales del bot en la sección "Configuración de canales" de Introducción a Connector).
En la siguiente imagen, puede ver cómo se prueba una conversación con Slack.
Pudimos configurar la integración de Slack al registrar el bot en el espacio dev.botframework

y seleccionar el tipo de conector sin la necesidad de codificación.
Comunicación del bot

Direct Line es una API REST simple que se usa para conectarse directamente al bot. El objetivo
principal de esta API es permitir a los desarrolladores conectar agentes personalizados al bot
para habilitar las conversaciones. Como se mencionó anteriormente, inicialmente comenzamos
a implementar la conectividad a través de WebSockets en la aplicación móvil desarrollada
en Xamarin.Forms, pero decidimos optar por HTTP porque no pudimos lograr que PCL funcionara.
El código siguiente muestra una tarea de envío simple.
public async Task Send<T>(T item)

{
var client = new HttpClient();
client.DefaultRequestHeaders.Accept.Clear();
client.DefaultRequestHeaders.Accept.Add(new
MediaTypeWithQualityHeaderValue("application/json"));
client.DefaultRequestHeaders.Authorization = new
AuthenticationHeaderValue("Bearer",
_conversationStartedResponse.Token);
var content = JsonConvert.SerializeObject(item);
var response = await client.PostAsync($"https://

directline.botframework.com/api/conversations/
{_conversationStartedResponse.ConversationId}/messages", new
StringContent(content, Encoding.UTF8, "application/json"));
}
Otras medidas implementadas

En Bot Framework, debe proporcionar directamente BotId, MicrosoftAppId
y MicrosoftAppPassword en el archivo web.config para realizar la correcta configuración
de la aplicación. Por cuestiones de seguridad, no quisimos hacerlo. Para proporcionar
la configuración de una forma más segura, obtuvimos los valores de configuración
de CloudConfigurationManager o un archivo JSON local que tiene la configuración del bot.
Escribimos el siguiente código para el lector de configuración.
public string this[string index]

{
get
{
var settingValue =
CloudConfigurationManager.GetSetting(index);
if (string.IsNullOrEmpty(settingValue))
settingValue = GetByLocalJsonFile(index);
return settingValue;
}
}
private string GetByLocalJsonFile(string index)

{
var path =
Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.UserP
rofile), "FieldWorkerBotSettings.Json");
if (!File.Exists(path))
return string.Empty;
var fileContent = File.ReadAllText(path);

if (string.IsNullOrEmpty(fileContent))
var json = JObject.Parse(fileContent);
if (!json.HasValues)
return json[index].Value<string>();
}
Esto nos permite crear un nuevo objeto LuisModelAttribute por el que pasamos la appId
y la appKey en el controlador de mensaje.
private static readonly LuisService _service;
static MessagesController()
{
var settings = new SettingsReader();
var appId = settings["LUIS:AppId"];
var appKey = settings["LUIS:AppKey"];
var model = new LuisModelAttribute(appId, appKey);
_service = new LuisService(model);
}
Dado que hay demasiado código para mostrar y explicar en este informe, puede encontrar
todo el código fuente para el hackfest en el repositorio de GitHub
readyforchaos/Powel-power-station-inspection-bot.
Interfaz de usuario del agente

El siguiente GIF animado muestra la aplicación móvil del cliente a la izquierda desarrollada
en Xamarin.Forms y la aplicación Condition Monitoring de Powel a la derecha que muestra
el estado de una central eléctrica.
Conclusión
Los resultados del hackfest fueron empezar. Una vez que haya entendido
sorprendentes; además, es fascinante pensar cómo hacerlo, pasará la mayor parte del
que los desarrolladores de Powel pasaron de tiempo diseñando flujos conversacionales
no saber nada sobre Bot Framework a crear y menos tiempo creando códigos.
satisfactoriamente un bot de chat integrado
que pudiera gestionar conversaciones en Poder acceder a toda la información dentro
varios sistemas y proporcionar información del back-end de Powel a través de la voz
muy necesaria para los ingenieros de natural en una aplicación impulsa a los
campo. Powel está dedicado a continuar ingenieros a tomar decisiones basadas
con el desarrollo del bot de chat durante en conocimientos que simplemente pueden
los próximos meses para incluir los análisis y obtener mediante la aplicación, lo que deriva
la vista histórica de partes específicas antes en informes de inspección más precisos.
de su lanzamiento. Además, se dedica a
ampliar el concepto a áreas y dominios de Poder registrar discrepancias de inmediato,
aplicación de Powel más allá del segmento solicitar detalles de inspección y obtener
de negocios de la energía. otra información relacionada permite a
los ingenieros no tener que usar papeles
Desde el punto de vista de un desarrollador, durante las inspecciones. De este modo, hay
todas las piezas necesarias están ahí, menos probabilidades de que se olviden
e integrarlas para crear una solución un punto de inspección; además, no tienen
pareció demasiado fácil. Los obstáculos el trabajo extra de tener que regresar
que encontramos no se relacionaron a la oficina a digitalizar sus hallazgos.
directamente con el propio Bot Framework,
sino más específicamente con los desafíos Lo bueno de este hackfest es que pudimos
de Xamarin. crear algo que realmente funciona y que
podríamos comenzar con su producción
Los lineamientos proporcionados para ahora mismo. Con LUIS y Bot Framework,
Bot Framework y LUIS tienen el potencial ahora podemos darle al trabajador de
de mejorar, pero es suficiente como para campo el soporte que necesita cuando
lo necesita y sin que use las manos.
Progreso
No pudimos incluir todas las características que esperábamos en el hackfest de tres días.
Las características previstas que no se incluyeron fueron las siguientes:
• Traducir el texto
• Cargar imágenes desde la aplicación del cliente
• Activar André mediante voz natural en lugar de usar un botón
• Descubrir el PCL de WebSockets y solucionarlo
Powel tiene como objetivo resolver estas cuestiones en breve después del hackfest para producir
un prototipo que funcione y que se pueda probar en el campo lo antes posible.
Recursos adicionales
¿Desea probar Bot Framework ahora mismo? Comience aquí:
Microsoft Bot Framework
¿Desea probar LUIS y Microsoft Cognitive Services? Vaya a

Microsoft Cognitive Services
Se puede encontrar el código fuente del hackfest en GitHub:

readyforchaos/Powel-power-station-inspection-bot
Estudio de caso técnico: NAVITIME 70
Estudio de
caso técnico:
NAVITIME
Febrero LoremNAVITIME
Estudio de caso técnico Los viajantes quieren tener experiencias
NAVITIME agrega
únicas, pero encontrar comida local,
excursiones y afines puede ser todo
bots de chat
un desafío. Con las aplicaciones de viaje
típicas, los viajantes pueden encontrar
para mejorar
restaurantes y lugares famosos, pero
no información local. Entonces, los
la experiencia
viajantes preguntan a la gente local,
lo que puede ser difícil por las barreras
en aplicaciones
del idioma. Por ejemplo, muchos viajantes
conocen el sushi como comida japonesa,
de viaje
pero no conocen excelentes comidas
locales como shirasu-don y motsu-yaki.
Masayuki Ota NAVITIME quiere resolver este problema,

28 de junio de 2017 de modo que implementó un bot de chat
en la aplicación Kamakura Travel Guide
(Guía de viaje de Kamakura). Los usuarios
pueden usar la aplicación para buscar
información sobre puntos de interés
famosos. Además, los usuarios se pueden
comunicar con el bot para encontrar
comidas locales y lugares interesantes.
Tecnologías usadas:
• Language Understanding Intelligent • Azure Cosmos DB (anteriormente
Service (LUIS) llamado DocumentDB)
• API Bing Spell Check • Azure Search
• API Bing Images Search • Azure Storage
• Custom Vision Service • Power BI
• API Text Analytics
• API Direct Line
• Azure Web Apps
• Azure Functions
• API Management
Miembros del proyecto Ayako Omori (@ayako_omori),

evangelizador técnico, Microsoft Japón
de NAVITIME Travel:
Hiroyuki Watanabe (@hiwatan007),
Ikuo Odanaka, gerente de desarrollo,
NAVITIME JAPÓN
Naoki Sato (@satonaoki), evangelizador

Shinichi Tanabe, ingeniero de desarrollo de
técnico sénior, Microsoft Japón
software sénior, NAVITIME JAPÓN
Daiyu Hatakeyama (@dahatake),

Makoto Yoshihama, ingeniero de desarrollo
desarrollador de software principal,
de software, NAVITIME JAPÓN
Microsoft Japón
Naoya Sasaki, ingeniero de desarrollo de

Masayuki Ota (@masota0517),
software, NAVITIME JAPÓN
Perfil del cliente
NAVITIME JAPÓN es un proveedor líder de tecnología y servicios de navegación. Ofrece

principalmente aplicaciones de navegación de negocio a negocio (B2B) y de negocio
a consumidor (B2C).
En el caso de B2B, ofrece aplicaciones de navegación para empresarios, consultas de transporte

y publicidad. En el caso de B2C, ofrece aplicaciones de navegación para viajar por tren, ómnibus,
automóvil, bicicleta o a pie y comenzó un negocio de viajes llamado NAVITIME Travel.
Declaración del problema

Las barreras de idioma pueden desafiar incluso a los viajantes con más experiencia. Navitime quería
abordar este desafío antes de los Juegos Olímpicos de Tokio 2020, para el cual habrá muchos
viajantes extranjeros que visitarán Japón.
Solución y pasos
Arquitectura
Custom Vision Service

Cognitive
Services
API Bing Image Search
LUIS API Bing Spell

API Check
Management
API Text Analytics
Azure Web
Apps
Azure
Search Storage Power BI
Bot Framework
Direct
Line
Azure Azure Cosmos DB

Functions (datos para búsqueda)
Azure Cosmos DB (registro de comunicación)
Usamos Bot Framework para implementar un bot de chat y también usamos la API Direct Line para
comunicarnos con el bot de chat de nuestra aplicación iOS. (Las aplicaciones de Android y Windows
también pueden usar Direct Line). Para extraer las intenciones y las entidades de las entradas del
usuario, usamos LUIS. Proporcionamos compatibilidad con la corrección ortográfica mediante
el uso de la API Bing Spell Check antes de pasar el texto a LUIS. Después de extraer las intenciones
y las entidades, llamamos a Azure Search para obtener información sobre comidas locales
y excursiones almacenadas en Cosmos DB.
Los usuarios pueden ingresar texto libremente, lo que significa que a veces LUIS no puede
identificar entidades. Por este motivo, también usamos la API Text Analytics para obtener la frase
clave. (Consulte Cómo detectar opiniones, frases clave e idiomas en la Guía de inicio rápido
de Azure Text Analytics). A continuación, pasamos la frase clave a Azure Search.
Los usuarios también pueden comunicarse con el bot mediante fotos. Para respaldar este escenario,
implementamos el reconocimiento de imágenes mediante el uso de la API Bing Images Search
y la API Custom Vision.
DevOps y la mejora continua también son importantes cuando se desarrollan bots. Para administrar
las versiones del bot, utilizamos API Management. Para almacenar el registro de entrada del
usuario, llamamos a Azure Functions y guardamos los datos en Cosmos DB. También usamos Azure
Search, Azure Storage y Power BI para monitorear los términos de búsqueda. Podemos recibir las
solicitudes de los usuarios de los registros de texto y pulir el bot una y otra vez.
Experiencia del usuario por combinación de aplicación

y bot de chat
Implementamos el bot en una aplicación iOS porque creímos que un bot de chat podría ampliar
la experiencia del usuario con la aplicación. Mostramos un mensaje de notificación (la ventana
verde en la siguiente imagen) en la aplicación e invitamos a los usuarios a utilizar el bot de chat
en dos situaciones:
1. Cuando un usuario ejecuta la aplicación por primera vez, aparece un mensaje de notificación
que dice: "¡Bienvenido! No dude en pedirme sugerencias de viaje e información de lugares".
2. Si la aplicación detecta que el usuario ha visto varios artículos recomendados, pero no

seleccionó ninguno, llega a la conclusión de que el usuario no puede encontrar la información
adecuada y dice: "¿No le interesan nuestros artículos recomendados? También puede…"
Los usuarios pueden presionar el botón de chat (el cuarto desde la izquierda) en la lista del menú
para iniciar la comunicación con el bot de chat. Los usuarios pueden ingresar texto libre en inglés
y japonés, como "Quiero comer soba". El bot responde: "¿Desea...?" y recomienda un restaurante.
La aplicación también muestra un menú en el cual los usuarios pueden seleccionar la próxima acción.
El usuario puede presionar "Ver más resultados" para ver otra recomendación o "Probar con otra
palabra clave" para ingresar palabras clave diferentes. Presionando el botón de mapa, aparece
un mapa; presionando "Ir al lugar (Obtener dirección)", el usuario puede ver el mapa y cómo llegar
a la ubicación. Dado que NAVITIME tiene su propia tecnología de enrutamiento, el bot redirige
al usuario a la aplicación web de enrutamiento NAVITIME.
El usuario puede presionar "Ver más resultados" para ver otra recomendación o "Probar con otra
palabra clave" para ingresar palabras clave diferentes. Presionando el botón de mapa, aparece
un mapa; presionando "Ir al lugar (Obtener dirección)", el usuario puede ver el mapa y cómo llegar
a la ubicación. Dado que NAVITIME tiene su propia tecnología de enrutamiento, el bot redirige
al usuario a la aplicación web de enrutamiento NAVITIME.
Los viajantes suelen subir fotos a los servicios de redes sociales, como Instagram y Facebook.
Cuando otros usuarios ven esas fotos, quieren ir a ese lugar o comer esa comida, pero no saben
dónde está o cómo conseguirla. Los usuarios pueden enviar fotos a nuestro bot, lo que ayuda
a reconocer imágenes e indica a los usuarios qué es y cómo conseguirlo.
Entrega técnica
MultiDialogSample en GitHub. Debido
a que queríamos lanzar una aplicación iOS,
utilizamos la API Direct Line.
En esta sección se describe cómo
implementar un bot similar mediante Extraer la intención y
el uso de Bot Framework, Cognitive
Services y Azure.
las entidades con LUIS
y la API Bing Spell Check
Requisitos previos Para la extracción de intenciones y entidades
de los mensajes del usuario, usamos LUIS.
• Instale Visual Studio y el SDK de Bot
Dado que los usuarios a veces escriben
Builder siguiendo los pasos en el
de forma incorrecta y LUIS no puede extraer
tutorial Cree un bot con el SDK de Bot
la intención, también utilizamos la API Bing
Builder para .NET.
Spell Check para detectar y corregir errores
• Instale el emulador de Bot Framework;
antes de enviar mensajes a LUIS mediante
consulte Cómo depurar bots con
los pasos siguientes.
el emulador de Bot Framework para
obtener más detalles.
1. Desde el portal de Azure, agregue
• Cree una cuenta gratuita de Azure
la API Bing Spell Check.
si aún no tiene una.
2. En el menú de LUIS, elija Mis claves.
• Cree una aplicación con LUIS que
3. Elija Claves externas y Agregar nueva
se ajuste a su escenario y llámela desde
clave para agregar una clave de la API
el bot (consulte el enlace de acción
Bing Spell Check a LUIS.
de LUIS para aplicaciones web).
4. Vaya a la aplicación LUIS y elija Publicar
aplicación en el menú de la izquierda.
Desarrollar un bot con 5. En la parte inferior, seleccione el botón
Bot Framework Agregar asociación de clave para
vincular la API Bing Spell Check con LUIS.
Después de los pasos de requisitos previos, 6. Seleccione Habilitar verificación
comenzamos a implementar nuestro ortográfica de Bing, lo que cambia
propio bot mediante el uso del código la URL del punto de conexión. Use
esta URL para llamar a LUIS con
la API Bing Spell Check.
Guardar datos NoSQL en Cosmos DB

Utilizamos el servicio de base de datos NoSQL totalmente administrado, Cosmos DB, para
almacenar información de ubicaciones de NAVITIME, que adquiere el formato JSON. También
utilizamos Cosmos DB para almacenar registros de comunicación entre los usuarios y los bots.
Si desea obtener información sobre cómo inicializar Cosmos DB y escribir código para ello,
comience con el tutorial Azure CosmosDB: desarrolle con la API DocumentDB en .NET. Debe
importar datos para pruebas y producción siguiendo las instrucciones en Cómo importar datos
a Azure Cosmos DB para la API de DocumentDB.
Implementar Azure Search

Si bien LUIS puede extraer correctamente las intenciones, a veces los usuarios ingresan solo palabras,
no oraciones, de modo que también utilizamos Azure Search. Con la siguiente arquitectura,
podemos manejar oraciones y palabras, así como responder con la información correcta.
Para usar Azure Search, escribimos el código C# de la siguiente manera.

[Serializable]
public class AzureSearchService
{
private static readonly string QueryString = $"https://
{WebConfigurationManager.AppSettings["SearchName"]}.search.windows.net
/indexes/{WebConfigurationManager.AppSettings["IndexName"]}/docs?api-
key={WebConfigurationManager.AppSettings["SearchKey"]}&api-
version=2015-02-28&";
public async Task<SearchResult> SearchByName(string name)

{
using (var httpClient = new HttpClient())
{
string nameQuey = $"{QueryString}search={name}";
string response = await
httpClient.GetStringAsync(nameQuey);
return
JsonConvert.DeserializeObject<SearchResult>(response);
}
}
public async Task<FacetResult> FetchFacets()

{
{
string facetQuey = $"{QueryString}facet=Era";
string response = await
httpClient.GetStringAsync(facetQuey);
return
JsonConvert.DeserializeObject<FacetResult>(response);
}
}
public async Task<SearchResult> SearchByEra(string era)

{
{
Puede utilizarlo desde Bot Framework con el siguiente código. Si desea ver un proyecto de ejemplo,
vaya a ryanvolum/AzureSearchBot en GitHub. En este proyecto se describe cómo configurar Azure
Search y Cosmos DB, además de cómo llamar a Azure Search desde un bot.
public virtual async Task MessageRecievedAsync(IDialogContext context,

IAwaitable<IMessageActivity> result)
{
var message = await result;
try
{
SearchResult searchResult = await
searchService.SearchByName(message.Text);
if(searchResult.value.Length != 0)
{
CardUtil.showHeroCard(message, searchResult);
}
else{
await context.PostAsync($"No musicians by the name
{message.Text} found");
}
}
catch(Exception e)
{
Debug.WriteLine($"Error when searching for musician:
{e.Message}");
}
context.Done<object>(null);
}
Reconocer imágenes con Bing Image Search

y Custom Vision Service
Podemos usar Bing Image Search para buscar imágenes similares y las "consultas más
representativas". Por ejemplo, si envía una foto del templo visto anteriormente en este artículo
a Bing Image Search, responde con URL con imágenes similares y "Templo Tsuruoka Hachimangu,
Kamakura", como bestRepresentativeQuery. Bing tiene grandes conocimientos de imágenes
y podemos utilizarlos para reconocer lugares famosos y comidas con el siguiente código. Para usar
Azure Search, escribimos el código C# de la siguiente manera.
public virtual async Task MessageRecievedAsync(IDialogContext context,

IAwaitable<IMessageActivity> result)
{
var message = await result;
try
{
SearchResult searchResult = await
searchService.SearchByName(message.Text);
if(searchResult.value.Length != 0)
{
CardUtil.showHeroCard(message, searchResult);
}
else{
await context.PostAsync($"No musicians by the name
{message.Text} found");
}
}
catch(Exception e)
{
Debug.WriteLine($"Error when searching for musician:
{e.Message}");
}
context.Done<object>(null);
}
Puede encontrar un proyecto de ejemplo en el repositorio de GitHub NT-D/suggesttriplocationBot

y obtener información sobre cómo publicar imágenes en un bot y cómo utilizar Bing Image Search
para reconocer imágenes y obtener bestRepresentativeQuery. Puede ver más detalles en la
referencia de la API Bing Image Search.
Si bien Bing Image Search nos ayuda a encontrar lugares famosos y comidas, es difícil reconocer
las comidas y los lugares locales o poco conocidos. Por lo tanto, decidimos utilizar Custom Vision
Service. Para crear, probar y usar esta API, comenzamos con el documento de introducción Crear un
clasificador mediante "machine learning" de Custom Vision Service.
Impulsar ciclos de retroalimentación con Power BI,

Cosmos DB y Azure Search
Dado que es importante mejorar la lógica del bot con entradas reales de los usuarios, queremos
ver las entradas de los usuarios y los registros de búsqueda fácilmente.
Para guardar las búsquedas de los usuarios, llamamos a las funciones de Azure y almacenamos
los datos en Cosmos DB. Las funciones de Azure son compatibles nativamente con los enlaces
de Cosmos DB y pueden guardar los datos utilizando solo un pequeño código, como el siguiente.
#r "Newtonsoft.Json" Puede usar Power BI

para acceder a los datos
using System;
en Cosmos DB siguiendo
using System.Net;
using Newtonsoft.Json; la información en las
fuentes de datos de
public static HttpResponseMessage Run(HttpRequestMessage req,
Power BI Desktop. Para
TraceWriter log, out string outputDocument)
{ analizar los registros
log.Info($"Webhook was triggered!"); de búsqueda, consulte
string jsonContent = req.Content.ReadAsStringAsync().Result;
//Store Data in Cosmos DB
Cómo analizar sus datos
outputDocument = jsonContent; con Power BI.
dynamic data = JsonConvert.DeserializeObject(jsonContent);
//Return HTTP Response (BadRequest or OK)

if (data.first == null || data.last == null) {
return req.CreateResponse(HttpStatusCode.BadRequest, new {
error = "Please pass first/last properties in the input
object"
});
}
return req.CreateResponse(HttpStatusCode.OK, new {

greeting = $"Hello {data.first} {data.last}!"
});
}
Mejorar el rendimiento
de respuesta
Implementamos el bot en la región oeste Al principio implementamos el bot en

de EE. UU. para minimizar el tiempo la región oriental de Japón, lo que provocó
de respuesta. (El servicio estatal Bot una respuesta lenta porque cuando el bot
Framework y LUIS están alojados en llama a LUIS y al servicio estatal, el tráfico
la región oeste de EE. UU. y los extremos recorre el Océano Pacífico una y otra vez.
de Direct Line se encuentran en Asia Si experimenta una respuesta lenta, puede
oriental, Europa y Norteamérica). mejorar el rendimiento moviendo el bot
a la región occidental de EE. UU.
Web Apps en la región Conector de bot

oriental de Japón y servicio estatal
Se conectan al conector del bot y al servicio estatal
Usuarios
finales
La aplicación
se comunica entre
Japón y EE. UU. ida
y vuelta.
Conclusión
Los viajeros quieren tener una experiencia única de viaje, pero les resulta difícil encontrar comidas
locales, excursiones turísticas y mucho más con una aplicación normal. También son difíciles
de encontrar comunicándose con la gente local debido a la barrera del idioma.
El bot de chat se encuentra activo en la aplicación Kamakura Travel Guide (Guía de viaje
de Kamakura). Los usuarios pueden encontrar información local conocida y desconocida
mediante el uso de la aplicación y el bot integrado.
"Es difícil hacer la lógica de NLP en varios idiomas, pero LUIS soluciona este
problema. LUIS es muy bueno para descubrir las intenciones en el mensaje".
Ikuo Odanaka
Gerente de desarrollo, NAVITIME JAPÓN
"[Cosmos DB] es un almacén de datos muy bueno. Allí podemos guardar

datos NoSQL y recuperar datos con consultas tipo SQL, por lo que
es muy fácil de usar. La velocidad de lectura y escritura es muy rápida;
la integración con Azure Search es inigualable".
Shinichi Tanabe
Desarrollador de software sénior, NAVITIME JAPÓN
"Para mí, es el proyecto con menos problemas. PaaS, como Cosmos

DB y Azure Search, pueden ayudarnos a hacer nuevas cosas con
mayor rapidez".
Shinichi Tanabe
Desarrollador de software sénior, NAVITIME JAPÓN
Conclusión 89
Como se ha demostrado mediante

estos estudios de caso, Azure
AI está marcando una verdadera
diferencia en cómo trabajan
y crean los desarrolladores.
Las herramientas de AI listas
para usarse, la infraestructura
en la nube avanzada y la
plataforma flexible ofrecen a los
desarrolladores lo que necesitan
para trasladar sus aplicaciones
a un mundo completamente
nuevo de interesantes productos,
atención al cliente superior y
excelente agilidad comercial.
Conclusión 90
Los desarrolladores 1. Herramientas potentes y

productivas.
tienen grandes
Los desarrolladores no quieren perder
oportunidades a medida tiempo escribiendo código para las
funciones principales de AI. Necesitan
que AI es cada vez API listas que se puedan implementar
más importante en un fácilmente en aplicaciones.
mundo centrado en la
2.
Datos y AI para
experiencia del cliente cada desarrollador.
y que las compañías
Los desarrolladores desean aumentar sus
buscan nuevas formas aplicaciones con AI de la mejor manera para
ellos. Para aprovechar AI al máximo, desean
de obtener una ventaja integrarla en sus aplicaciones mediante
competitiva. Para el uso de una amplia gama de lenguajes
de programación y de la elección entre una
aprovechar al máximo variedad de fuentes de datos.
esas oportunidades, los

desarrolladores buscan:
3.
Una plataforma abierta y
flexible.
Los desarrolladores están más conformes

cuando pueden elegir la tecnología
y los marcos que mejor se adecuan a sus
escenarios y habilidades.
¿Qué viene a continuación? 91
¿Qué viene a
continuación?
Lo invitamos a explorar Azure AI Services a
través de los siguientes enlaces:
Más información sobre Azure AI
Pruebe las API de Cognitive Services

en forma gratuita
Cree una cuenta gratuita de Azure
Copyright © 2018 Microsoft, Inc. Todos los derechos reservados. Este contenido tiene
únicamente fines informativos. Microsoft no realiza garantías, expresas o implícitas,
con respecto a la información que aquí se presenta.

AI en Accion

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

AI en Accion

Cargado por

Copyright:

Formatos disponibles

Guía para desarrolladores de Azure

Los desarrolladores en todo

Ejemplos de Azure AI en acción

Ir a Estudio de caso Powel

En cada estudio de caso técnico se muestra cómo

Estudio de caso técnico El proveedor de servicios de Internet

La solución final fue un bot de chat

Three quiere facilitarles la vida a sus

• Cancelar o actualizar un contrato.

• Responde las preguntas frecuentes

Puede encontrar toda la implementación técnica de lo anterior en la sección "Entrega técnica"

** Al ejecutar un generador de formularios de nodo, se activa SIMForm.js que permitirá

Principales capacidades del bot

Este flujo de bot está compuesto por varios diálogos:

function (session, args) {

// Check if entityData exists

En este diálogo se presenta el formulario al usuario y se detalla la información necesaria.

var requirements = ['You will need the following information: \n'];

function (session, args) {

function (session, args) {

En este flujo hay tres diálogos:

Inteligencia del bot

Ejemplo del regex utilizado:

matches: /^Activate SIM/i

Primero, configuramos el reconocedor de LUIS dentro de config.js:

var question = {'question': results.question}

client.post(options, question, (err, req, res, obj) => {

global.bot = new builder.UniversalBot(connector, function (session) {

if (results.response && results.response.entity === 'no') {

Azure Application Insights

Primero, configuramos el cliente Application Insights en el archivo config:

A continuación, creamos un módulo de telemetría para manejar el trabajo de telemetría:

// Store entity data in dialogData

// Setup a telemetry module

Estudio de caso técnico: Three 34

Comenzamos este proyecto con • La documentación del SDK de Node.js

A diferencia de otros canales, no se activa onConversationUpdate cuando se agrega un bot

El paquete de QnA Maker desarrollado previamente es "semipermanente"

Cómo implementar palabras seguras

bot.endConversationAction('goodbye', 'Goodbye :)', { matches: /^bye/

Uso de las intenciones de LUIS a través de triggerActions y la configuración de intentThreshold

En lugar de usar el método habitual de coincidencia de intenciones de LUIS:

intents = new builder.IntentDialog({recognizers: [recognizer]});

intents = new builder.IntentDialog({ recognizers: [recognizer],

Una forma fácil y clara para completar formularios

Primero, cree una serie de preguntas:

A continuación, recorra cada pregunta llamando al mismo diálogo y pasando un contador

bot.dialog('FillOutForm', [ Puede encontrar

// Check for end of form

• Transferencia a un centro de llamadas o agentes en vivo.

• Personalidad y personalización: llamar al usuario por su nombre y personalizar

"Gracias a todos por invitarnos

"Gracias @microsoft-simon y al resto

adicionales QnA Maker

Estudio de caso técnico Durante marzo de 2017, en las oficinas

Usar CaaP y André,

En este hackfest, utilizamos las

• el historial de las inspecciones en instalaciones específicas

"Microsoft Bot Framework y Cognitive

Perfil del Declaración

Definimos las características y las tareas

La historia de usuario era la siguiente:

Decidimos usar Android para la parte El bot de prueba de concepto (PoC)

Bosquejo de cómo un ingeniero de campo generalmente inspeccionaría