Mejorar la precisión de los bots en Amazon Lex comienza con el manejo de la forma en que los clientes se comunican de forma natural. Sus clientes expresan la misma solicitud de decenas de formas diferentes, combinan varios datos en una frase y, a menudo, hablan de forma ambigua. La función NLU asistida (comprensión del lenguaje natural) de Amazon Lex le ayuda a mejorar la precisión del bot al manejar estas variaciones del lenguaje natural. Los sistemas tradicionales de comprensión del lenguaje natural luchan con esta variabilidad, lo que puede llevar a los clientes a repetir o abandonar las conversaciones.
El desafío: los sistemas NLU basados en reglas requieren que los desarrolladores configuren manualmente cada variación posible de expresión, una tarea que requiere mucho tiempo y que aún deja lagunas en la cobertura. Un robot de reservas de hoteles entrenado para "reservar un hotel" falla cuando sus clientes dicen: "Me gustaría reservar alojamiento para mi viaje". Las solicitudes complejas como “Resérveme una suite en su ubicación en el centro de Seattle del 15 al 18 de diciembre” a menudo pierden detalles críticos (tipo de habitación, ubicación, fechas). Frases ambiguas como "Necesito ayuda con mi reserva" dejan a los robots adivinando si los clientes quieren reservar, ver, modificar o cancelar.
La solución: la función NLU asistida por Amazon Lex utiliza modelos de lenguaje grandes (LLM) para comprender las variaciones del lenguaje natural y mejorar la precisión del bot. No se requiere configuración manual. Al combinar el aprendizaje automático (ML) tradicional con los LLM, Assisted NLU maneja cómo se comunican los clientes reales, creando experiencias de conversación naturales que mejoran la precisión del reconocimiento.
La NLU asistida (incluido el modo principal, el modo alternativo y la desambiguación de intención) se incluye sin costo adicional con el precio estándar de Amazon Lex.
En esta publicación, aprenderá cómo implementar NLU asistida de manera efectiva. Aprenderá cómo mejorar el diseño de su bot con descripciones efectivas de intenciones y espacios, validará su implementación usando Test Workbench y planificará su transición de NLU tradicional a NLU asistida para bots nuevos y existentes.
Requisitos previos: en esta guía se supone que está familiarizado con los conceptos de Amazon Lex, incluidas intenciones, espacios y expresiones. Si es nuevo en Amazon Lex, comience con la Guía de introducción.
Presentamos NLU asistida
La NLU asistida por Amazon Lex utiliza LLM para mejorar las capacidades de clasificación de intenciones y resolución de espacios. Utiliza los nombres y descripciones de sus intenciones y espacios para comprender las entradas del usuario. Maneja errores tipográficos, frases complejas y extracción de múltiples ranuras sin necesidad de configurar manualmente cada variación. La NLU asistida por Amazon Lex mejora el rendimiento en las tareas de comprensión del lenguaje natural, logrando una precisión de clasificación de intenciones del 92 por ciento y una precisión de resolución de ranuras del 84 por ciento en promedio. Con cientos de clientes activos incorporados a Assisted NLU, los comentarios de los clientes validan estas mejoras en implementaciones del mundo real. Los clientes han informado aumentos en la clasificación de intenciones del 11 al 15 por ciento, un 23,5 por ciento menos de respuestas alternativas y un 30 por ciento mejor manejo de entradas ruidosas. Los primeros usuarios han informado de mejoras significativas en sus implementaciones de IA conversacional, y varios planean implementaciones más amplias basadas en los resultados de las pruebas iniciales. La NLU asistida opera en dos modos:
Modo primario: utiliza el LLM como medio principal para procesar cada entrada del usuario. Modo alternativo: utiliza primero la NLU tradicional, la invocación del LLM ocurre solo cuando la confianza es baja o se dirige a FallbackIntent.
Puede habilitar NLU asistida con algunas selecciones en la consola de Amazon Lex. Navegue hasta la configuración regional de su bot, active NLU asistida, seleccione su modo preferido y cree su bot.
Para obtener instrucciones de configuración detalladas, referencias de API y guías de habilitación paso a paso, consulte Habilitación de NLU asistida en la Guía para desarrolladores de Amazon Lex.
Para la configuración programática, consulte la referencia de la API NluImprovementSpecification.
1. Mejores prácticas para la implementación de NLU asistida
Las siguientes mejores prácticas le ayudarán a aprovechar al máximo la NLU asistida y abarcan la selección de modo, la redacción de descripciones, la optimización de espacios y la desambiguación de intenciones.
1.1 Modos de funcionamiento: primario y alternativo
El modo primario utiliza el LLM para cada entrada del usuario. El modo alternativo utiliza primero la NLU tradicional, la invocación de LLM ocurre solo cuando la confianza es baja o se dirige a FallbackIntent.
HACER:
Utilice el modo principal cuando cree nuevos bots o cuando tenga datos de entrenamiento limitados (menos de 20 expresiones de muestra por intención). Ejemplo: un robot de atención médica que gestiona la programación de citas en las que los pacientes dicen: "Necesito ver a alguien sobre mi rodilla" o "Reservame con un cardiólogo la próxima semana" sin necesidad de una extensa ingeniería de expresión. Utilice el modo alternativo cuando tenga bots existentes que ya funcionen bien. Ejemplo: un robot bancario establecido con una precisión del 95 % que ocasionalmente falla en variaciones como "¿Cómo es mi saldo?" en lugar de "Verificar saldo", donde el LLM detecta estos casos extremos. Supervise la métrica cumplimientoByAssistedNlu en Amazon CloudWatch Logs para determinar el modo correcto para su caso de uso. Si más del 30 por ciento de las solicitudes invocan el LLM en modo alternativo, considere cambiar al modo Primario para mantener la coherencia.
NO:
Cambie al modo principal sin pruebas A/B si tiene un bot con buen rendimiento, ya que podría introducir latencia innecesaria sin ganar precisión. Suponga que un modo funciona para cada caso de uso porque su distribución de datos específica y los patrones de idioma del usuario determinan el modo correcto.
1.2 Elaboración de descripciones de intención efectivas
Las descripciones de las intenciones son indicaciones para el LLM, no documentación para su equipo. Son la señal principal utilizada para la clasificación y su calidad determina directamente la precisión, del mismo modo que la calidad inmediata determina la calidad de salida del LLM. Un patrón consistente ofrece resultados confiables: Intención de [verbo de acción] [objeto/entidad] [contexto/restricciones]
"Intención de…" ancla la descripción en el propósito, alineándose con la forma en que el LLM evalúa lo que el usuario está tratando de lograr. Los verbos de acción crean una separación clara. Reservar, cancelar, modificar y verificar son inequívocos, lo que permite al LLM distinguir con confianza entre intenciones. Los objetos y entidades especifican el objetivo. "Reservar un hotel", "reservar un coche" y "reservar un vuelo", cada uno de ellos se relaciona con un objetivo de usuario distinto. El contexto resuelve los casos extremos. Agregar restricciones como el contexto "Intención de cancelar un vuelo debido a una emergencia médica" versus "Intención de cancelar un vuelo por conflicto de horarios" puede ayudar a determinar la elegibilidad para la exención y las políticas de reembolso.
HACER:
Comience las descripciones con "Intención de…" seguido de un verbo de acción claro. Ejemplo: "Intención de reservar una habitación de hotel para pasar la noche". Derive descripciones de tus expresiones de muestra existentes. Reflejan cómo hablan los usuarios y proporcionan la señal más potente para el LLM. Ejemplo: Descripciones como "reservar una habitación" y "reservar una suite" se convierten en: "Intención de reservar o reservar una habitación de hotel o suite para pasar la noche". Agregue contexto de dominio cuando tenga intenciones similares que necesiten desambiguación. Ejemplo: "La intención de reservar una habitación de hotel en StayBooker" fundamenta el entendimiento del LLM. Refleje el vocabulario de sus usuarios a partir de análisis de conversaciones reales. Ejemplo: si los clientes dicen "reserva", utilice ese término de forma coherente. Pruebe las descripciones con declaraciones de casos extremos antes de la implementación. Ejemplo: Verificar que "Necesito un lugar donde quedarme" dirige correctamente a BookHotel.
NO:
Deje las descripciones vacías o utilice texto de marcador de posición. Mal ejemplo: "TBD" o "Intent 1" no proporciona ninguna señal al LLM. Combina múltiples acciones en una sola intención. Mal ejemplo: "Intención de reservar y gestionar reservas de hotel", considere dividirla en intenciones independientes. Utilice lenguaje superpuesto en diferentes intenciones. Mal ejemplo: "Verificar saldo de cuenta" y "Verificar transacciones de cuenta" confundirán la clasificación. Incluya valores de ranura o ejemplos específicos en la descripción. Mal ejemplo: "Intención de reservar un hotel en Seattle por 2 noches" por encima de la coincidencia de restricciones.
1.3 Mejora de las descripciones de las ranuras
Las descripciones de las ranuras proporcionan una señal contextual al LLM sobre qué información extraer y cómo interpretarla. Cuanto más sólida y específica sea su descripción, más eficazmente el LLM podrá priorizar los valores relevantes. A medida que la NLU asistida evolucione, las descripciones de las ranuras tendrán un peso cada vez mayor en las decisiones de extracción. Escribir descripciones precisas hoy prepara a su bot para beneficiarse automáticamente de futuras mejoras. Las descripciones efectivas siguen este patrón: [Lo que captura el espacio] [restricciones contextuales] [orientación de valores válidos]
Lo que captura el espacio define la información específica que el espacio extrae de la entrada del usuario, como el nombre de una ciudad, la fecha o el recuento. Las restricciones contextuales limitan el alcance. La "fecha de entrada para la reserva de hotel, no la fecha de salida o de reserva" ayuda al LLM a extraer la fecha correcta de entradas como "del 15 al 18 de diciembre". Una guía de valores válida resuelve la ambigüedad. El "código de moneda ISO de tres letras, como USD, EUR o JPY", permite que el LLM resuelva entradas como “euros” o “yenes japoneses” en el código estándar sin mantener un catálogo de monedas completo en el tipo de ranura.
HACER:
Utilice descripciones de ranura para resolver valores sin un tipo de ranura integrado dedicado. Ejemplo: para capturar códigos de aeropuerto, utilice AMAZON.AlphaNumeric con la descripción "Un código de aeropuerto IATA válido (por ejemplo, SEA, JFK, LAX)". El LLM utiliza este contexto para extraer códigos del lenguaje natural, asignando "Estoy volando desde Seattle" a SEA, sin enumerar cada valor en un tipo de espacio personalizado. Si tiene dos espacios de AMAZON.Number (noches + invitados), la descripción es importante para ayudar a LLM a diferenciar entre tipos de espacios similares. Ejemplo: "Número de noches de estadía en el hotel" versus "Número de huéspedes que se registran"; sin estos, el LLM podría tener dificultades para asignar "3" al espacio correcto. Aclare el papel del espacio dentro de la intención. Ejemplo: "Fecha de entrada" para una intención de reserva de hotel elimina la ambigüedad entre las fechas de entrada, salida y reserva. Especifique restricciones que coincidan con sus reglas comerciales. Ejemplo: "Número de noches de estancia en el hotel" aclara que se trata de un recuento de duración, no de habitaciones ni de huéspedes. Utilice descripciones de ranuras para definir el significado de cada valor para ranuras personalizadas con resolución de valor ampliada. Ejemplo: un espacio personalizado RoomType con valores Estándar, Deluxe y Suite y la descripción "Tipo de habitación de hotel. Estándar es una habitación básica, Deluxe es una habitación de nivel medio con comodidades adicionales, Suite es la habitación de lujo de primer nivel con más espacio y las mejores características y cocina adjunta" ayuda al LLM a asignar el lenguaje natural a la categoría correcta. Si un cliente dice "una habitación con cocina" o "la habitación más grande", el LLM los resuelve en Suite según el contexto semántico proporcionado en la descripción.
NO:
Deje las descripciones de las ranuras vacías, especialmente para las ranuras personalizadas. Mal ejemplo: "Pago" sin descripción no le brinda al LLM ninguna orientación sobre qué formatos de moneda esperar. Supongamos que el tipo de ranura por sí solo proporciona suficiente contexto. Mal ejemplo: AMAZON.Number podrían ser noches, invitados, habitaciones o números de confirmación sin descripción. Utilice descripciones que entren en conflicto con el tipo de ranura. Mal ejemplo: describir "número de cuenta" pero usar el tipo AMAZON.Number puede causar problemas de extracción con números de cuenta formateados. Olvídese de actualizar las descripciones cuando cambie la lógica empresarial. Mal ejemplo: expandirse a ciudades internacionales pero mantener "solo Estados Unidos" en la descripción.
1.4 Mejores prácticas de desambiguación de intenciones
Cuando varias intenciones pueden coincidir con la entrada de un usuario, Assisted NLU presenta opciones de desambiguación para aclarar el objetivo del usuario. Una desambiguación bien diseñada reduce la fricción y mantiene las conversaciones encaminadas.
HACER:
Utilice descripciones y nombres de intenciones claros y distintos que no se superpongan. Estos son los datos principales que utiliza el LLM para tomar decisiones de desambiguación. Ejemplo: "BookHotelRoom" con descripción "Reservar una habitación de hotel para fechas futuras" frente a "CancelHotelReservation" con descripción "Cancelar una reserva de hotel existente": propósitos claramente separados. Proporcione nombres para mostrar fáciles de usar para nombres de intenciones técnicas. Asegúrese de que los nombres para mostrar estén alineados y representen claramente los nombres de intenciones reales. Ejemplo: el nombre de intención "ModifyReservationDates" con el nombre para mostrar "Cambiar las fechas de mi reserva" deja la opción inmediatamente clara para los usuarios. Configure cuidadosamente la cantidad máxima de opciones de intención. Equilibrio entre ofrecer suficientes opciones y evitar la parálisis de decisiones mediante las pruebas. Ejemplo: limitar la desambiguación a 3 o 4 opciones como máximo; Si "reservar hotel" puede coincidir con 6 intenciones, el diseño de su intención está demasiado fragmentado. Elabore mensajes de desambiguación concisos que reconozcan la aportación del usuario. Guíe a los usuarios de forma natural hacia la selección de la opción de intención correcta. Ejemplo: "Puedo ayudarte con las reservas de hotel. ¿Quieres:" seguido de opciones claras, en lugar de "Selecciona una intención:". Pruebe minuciosamente con expresiones ambiguas. Valide que el flujo de desambiguación parezca natural y presente consistentemente las opciones de intención correctas. Ejemplo: pruebe frases como "Necesito ayuda con mi reserva" en los intentos de reserva, modificación y cancelación para asegurarse de que aparezcan las opciones correctas.
NO:
Ignore los patrones de desambiguación. Supervise qué intenciones desencadenan con frecuencia la desambiguación y refinelas para reducir la confusión. Mal ejemplo: si "verificar mi reserva" genera constantemente una desambiguación entre "VerReserva", "ModificarReserva" y "VerificarReserva", consolide o aclare estas intenciones. Utilice la desambiguación como solución general. Si la mayoría de las conversaciones llegan a la desambiguación, el diseño de su intención necesita una mejora fundamental. Mal ejemplo: si la mayoría de las solicitudes de los usuarios desencadenan la desambiguación, esto indica definiciones de intención superpuestas que necesitan rediseñarse, no mejores mensajes de desambiguación. Olvídese de manejar las fallas de desambiguación. Tenga una estrategia alternativa clara cuando los usuarios no seleccionen ninguna opción. Mal ejemplo: mostrar las mismas opciones de desambiguación repetidamente cuando los usuarios dicen "ninguno" o "algo más" en lugar de recurrir al soporte humano. Trate la desambiguación como algo que se establece y se olvida. Analice continuamente las selecciones de los usuarios para identificar puntos de confusión y mejorar la separación de intenciones con el tiempo. Mal ejemplo: nunca revisar qué opciones de desambiguación seleccionan los usuarios; Si todos eligen la opción dos cuando se les muestran tres opciones, las opciones uno y tres podrían ser innecesarias.
Una vez que haya aplicado estas mejores prácticas, valide su configuración mediante pruebas sistemáticas.
2. Probar su implementación de NLU asistida
Una vez establecidas la intención y las descripciones de los espacios, el siguiente paso es la validación. Utilice Amazon Lex Test Workbench para medir qué tan bien su configuración de NLU asistida maneja las variaciones de expresiones del mundo real.
Para conocer la configuración y el uso de Test Workbench, consulte la documentación de Test Workbench y el vídeo de demostración.
Importante: Al configurar la ejecución de su conjunto de pruebas, asegúrese de seleccionar el bot y el alias donde está habilitada la NLU asistida. La prueba solo ejercerá NLU asistida si el alias seleccionado apunta a una versión con el modo alternativo o primario configurado.
2.1 Qué probar
Concéntrese en dónde la NLU asistida agrega más valor: casos extremos Pruebe las entradas que se desvían de la redacción estándar para verificar que la NLU asistida maneje el desorden del mundo real:
Errores tipográficos y gramaticales: "quiero reservar un hotel" Expresiones coloquiales: "conéctame con una habitación en el centro" Solicitudes ambiguas: "Necesito transporte" Enunciados incompletos: "reservar para la próxima semana"
Variaciones de tragamonedas
Para los espacios integrados, pruebe variaciones como formatos de fecha (“el próximo martes”, “el 15”), alias de ubicación (“NYC”, “Nueva York”), variaciones de nombres (“Bob” vs “Robert”) y formatos de correo electrónico (“john dot doe en gmail dot com”).
Para espacios personalizados, pruebe que las frases del usuario se asigne a valores definidos, especialmente en el modo de expansión. Por ejemplo, verifique que "habitación más grande" se resuelva en "Suite" para un espacio de tipo de habitación.
A diferencia de las aplicaciones abiertas de IA generativa donde el LLM produce texto de formato libre que se devuelve directamente a los usuarios, Assisted NLU utiliza el LLM estrictamente como un motor de clasificación y extracción restringido por la definición de su bot. El LLM solo puede seleccionar una intención y extraer los valores de espacio definidos en la definición de su bot. No puede inventar nuevas intenciones, desencadenar acciones fuera de la definición de su bot ni devolver texto sin formato generado por LLM a los usuarios finales. Esta arquitectura limitada por definición de bot limita significativamente la superficie de ataque de inyección rápida, pero aun así se debe validar que las entradas adversarias se dirijan de manera predecible a FallbackIntent.
2.2 Análisis de los resultados de las pruebas
Una vez completada la prueba, utilice las tasas de aprobación para priorizar dónde centrar sus esfuerzos de mejora. Las intenciones con tasas de aprobación más bajas necesitan la mayor atención:
0–30 por ciento: alta prioridad. Vuelva a escribir la descripción de la intención y verifique que no haya superposiciones con intenciones confusas. 30–70 por ciento: prioridad media. Analice expresiones fallidas en busca de patrones y refine las descripciones. 70-100 por ciento: prioridad baja. Ajustes menores o no es necesario realizar ninguna acción. Descargue los resultados detallados y examine: Intención esperada versus intención real: identifica clasificaciones erróneas. Valores de ranura de salida real versus los esperados: para discrepancias en extracción y resolución. Pronunciación del usuario: la entrada que falló. Mensaje de error: explica el motivo del error. Resultado de la conversación de un extremo a otro: pasa/no pasa en general para todo el flujo de la conversación, no solo en los turnos individuales.
2.3 Iterando sobre descripciones
Cuando los resultados de las pruebas revelen clasificaciones erróneas, utilice el siguiente proceso iterativo para refinar sus descripciones:
Exporte sus resultados detallados y filtre las expresiones fallidas. Identifique en qué intención se clasificaron erróneamente. Compare las descripciones de ambas intenciones. Reescriba la descripción de su intención fallida para enfatizar la diferenciación. Vuelva a ejecutar el mismo conjunto de pruebas para validar su mejora.
2.4 Versionado para una iteración segura
Utilice el control de versiones y los alias de Amazon Lex para probar los cambios en la descripción de forma segura sin afectar el tráfico de producción:
Refinar las descripciones en la versión borrador Probar con TestBotAlias Crear una versión numerada cuando los resultados sean aceptables Señalar el alias BETA para validar y luego promocionar a PROD Revertir redireccionando PROD a una versión anterior si es necesario
Para obtener más información, consulte la Guía de versiones y alias.
Control de acceso: utilice las políticas de AWS Identity and Access Management (IAM) para restringir quién puede modificar las definiciones, intenciones y descripciones de espacios de los bots. Limite los permisos lex:UpdateBotLocale, lex:UpdateIntent y lex:UpdateSlot a desarrolladores autorizados. Esto evita cambios no autorizados en las descripciones que podrían degradar la precisión de NLU o introducir un comportamiento no deseado. Para obtener más información, consulte Gestión de acceso e identidad para Amazon Lex en la Guía para desarrolladores de Amazon Lex.
2.5 Seguimiento de la producción
Habilite los registros de conversaciones en su alias de producción para realizar un seguimiento del rendimiento de NLU asistida con tráfico real. Para la configuración, consulte Configuración de registros de conversaciones.
Campos clave para monitorear
CumplidoByAssistedNlu: indicador booleano que muestra cuándo el LLM manejó la clasificación o la resolución de espacios nluConfidence: puntuación de confianza para la intención seleccionada missUtterance: booleano que indica que se clasificó la intención alternativa.
Qué rastrear
Tasa de invocación de NLU asistida: las tasas altas en el modo alternativo pueden indicar que las expresiones de muestra necesitan expansión. Precisión del reconocimiento de intenciones: compare la NLU tradicional con la NLU asistida habilitada. Precisión de la resolución de la ranura: compare la NLU tradicional con la NLU asistida habilitada. Patrones de expresión omitidos: agrupe por tema para identificar lagunas en la cobertura o las descripciones de la intención. Frecuencia de desambiguación: controle qué pares de intenciones provocan una aclaración con mayor frecuencia.
Modos de prueba A/B Para comparar el modo primario con el modo alternativo, cree versiones de bot independientes para cada modo, apúnteles diferentes alias y compare métricas entre alias en CloudWatch.
3. Estrategia de implementación recomendada
Con sus descripciones mejoradas y las pruebas validadas, está listo para planificar su implementación de producción. Si está creando un nuevo bot, comience con el modo Primario. Comience con entre 10 y 15 ejemplos de expresiones por intención e invierta su esfuerzo en escribir descripciones de intención y espacios de alta calidad. Si tiene un bot existente que ya funciona bien, comience con el modo alternativo para que el LLM solo intervenga cuando la NLU tradicional sea incierta. Ejecute pruebas A/B para comparar el rendimiento antes de considerar cambiar al modo principal y conserve la capacidad de reversión manteniendo una versión anterior del bot a la que pueda volver.
Lista de verificación de implementación
[ ] Métricas de referencia documentadas [ ] Probadas en desarrollo con casos extremos [ ] Registros de conversaciones habilitados [ ] Panel de CloudWatch configurado [ ] Procedimiento de reversión definido
Conclusión
En esta publicación, le mostramos cómo mejorar la precisión del bot con NLU asistida por Amazon Lex. Aprendió a elaborar descripciones efectivas de intenciones y espacios, validar su configuración con Test Workbench e implementar NLU asistida de forma segura en producción utilizando el modo primario o alternativo.
¿Listo para empezar? ¡Habilite NLU asistida en su bot hoy!
Sobre los autores
Dipkumar Mehta es consultor principal de IA en lenguaje natural en AWS. Diseña y amplía soluciones de IA Agentic para centros de contacto empresariales. Lidera el desarrollo de productos de inteligencia artificial que aceleran la adopción de experiencias autónomas de los clientes. Su trabajo ayuda a las organizaciones a pasar de pilotos de IA conversacionales a implementaciones agentes de nivel de producción en AWS.
Rakshit Parashar es ingeniero de software en el equipo de Amazon Lex, donde trabaja para ayudar a los creadores a crear bots conversacionales más precisos y sólidos. Sus intereses se centran en hacer que los sistemas de diálogo orientados a tareas sean más fiables y dignos de confianza, combinando el poder de razonamiento de los LLM con la validación determinista.
Karthik Konaraddi es ingeniero de desarrollo de software en el equipo de Amazon Lex y se centra en la intersección del reconocimiento de voz, la comprensión del lenguaje y la IA generativa. Trabaja para ofrecer funciones que mejoren la forma en que los bots resuelven las intenciones y responden a los usuarios. Lo impulsa la idea de que los LLM pueden remodelar fundamentalmente la forma en que los bots manejan las conversaciones, pasando de reglas estáticas a sistemas que realmente comprendan el contexto.
Alampu Maakaru es gerente de desarrollo de software en el equipo de Amazon Connect (Lex). Dirige los equipos de ingeniería de experiencia de desarrollador de bots y reconocimiento automático de voz (ASR), creando y entregando soluciones que mejoran las capacidades de IA conversacional, mejoran las experiencias de los clientes y simplifican la adopción de servicios de IA lingüística.
Mahesh Sankaranarayanan es gerente de desarrollo de software en el equipo de Amazon Connect (Lex). Dirige el equipo de ingeniería de Comprensión del lenguaje natural (NLU), creando y entregando soluciones NLU aumentadas por LLM que mejoran las capacidades de IA conversacional, mejoran el reconocimiento de intenciones y la comprensión del lenguaje, y simplifican la adopción de servicios de Language AI.