Cómo Clarus Care utiliza Amazon Bedrock para ofrecer interacciones conversacionales en el centro de contacto

Esta publicación fue coescrita por Rishi Srivastava y Scott Reynolds de Clarus Care.

Hoy en día, muchos consultorios sanitarios luchan por gestionar de forma eficiente grandes volúmenes de llamadas de pacientes. Desde la programación de citas y el reabastecimiento de recetas hasta consultas de facturación y preocupaciones médicas urgentes, los consultorios enfrentan el desafío de brindar respuestas oportunas y al mismo tiempo mantener una atención de calidad al paciente. Los sistemas telefónicos tradicionales a menudo generan largos tiempos de espera, pacientes frustrados y personal abrumado que procesa y prioriza manualmente cientos de llamadas diariamente. Estos cuellos de botella en la comunicación no solo afectan la satisfacción del paciente sino que también pueden retrasar la coordinación de cuidados críticos.

En esta publicación, ilustramos cómo Clarus Care, un proveedor de soluciones para centros de contacto de atención médica, trabajó con el equipo del Centro de innovación de IA generativa de AWS (GenAIIC) para desarrollar un prototipo de centro de contacto impulsado por IA generativa. Esta solución permite la interacción conversacional y la resolución de múltiples intenciones a través de un robot de voz automatizado y una interfaz de chat. También incorpora un modelo de servicio escalable para respaldar el crecimiento, capacidades de transferencia humana (cuando se solicite o para casos urgentes) y un canal de análisis para obtener información sobre el rendimiento.

Clarus Care es una empresa de tecnología sanitaria que ayuda a los consultorios médicos a gestionar la comunicación con los pacientes a través de un sistema de gestión de llamadas impulsado por IA. Al transcribir, priorizar y enrutar automáticamente los mensajes de los pacientes, Clarus mejora los tiempos de respuesta, reduce la carga de trabajo del personal y minimiza los tiempos de espera. Clarus es la empresa de gestión de llamadas de atención médica de más rápido crecimiento y presta servicios a más de 16 000 usuarios en más de 40 especialidades. La empresa atiende 15 millones de llamadas de pacientes al año y mantiene una tasa de retención de clientes del 99 %.

Descripción general del caso de uso

Clarus se está embarcando en un viaje innovador para transformar su sistema de comunicación con el paciente de una respuesta de voz interactiva (IVR) tradicional basada en menús a una experiencia conversacional más natural. La compañía tiene como objetivo revolucionar la forma en que los pacientes interactúan con los proveedores de atención médica mediante la creación de un centro de contacto generativo impulsado por inteligencia artificial capaz de comprender y abordar múltiples intenciones de los pacientes en una sola interacción. Anteriormente, los pacientes navegaban a través de opciones de menú rígidas para dejar mensajes, que luego se transcribían y procesaban. Este enfoque, aunque funcional, limita la capacidad del sistema para manejar de manera eficiente las necesidades complejas de los pacientes. Al reconocer la necesidad de una solución más intuitiva y flexible, Clarus colaboró ​​con GenAIIC para desarrollar un centro de contacto impulsado por IA que pueda comprender conversaciones en lenguaje natural, gestionar múltiples intenciones y brindar una experiencia perfecta a través de interfaces de chat de voz y web. Los criterios clave de éxito para el proyecto fueron:

Una interfaz de voz en lenguaje natural capaz de comprender y procesar múltiples intenciones de los pacientes, como preguntas de facturación, programación y resurtido de recetas, en una sola llamada. Latencia de <3 segundos para el procesamiento de backend y respuesta al usuario. La capacidad de transcribir, grabar y analizar información de llamadas. Capacidades de transferencia inteligente para llamadas urgentes o cuando los pacientes solicitan hablar directamente con los proveedores. Soporte para llamadas de voz e interfaces de chat web para adaptarse a las diversas preferencias de los pacientes. Una base escalable para respaldar la creciente base de clientes de Clarus y la red de centros de atención médica en expansión. Alta disponibilidad con una Requisito de SLA del 99,99 % para facilitar una comunicación confiable con el paciente

Descripción general y arquitectura de la solución

El equipo de GenAIIC colaboró ​​con Clarus para crear un centro de contacto generativo impulsado por IA utilizando Amazon Connect y Amazon Lex, integrado con los modelos básicos Claude 3.5 Sonnet de Amazon Nova y Anthropic a través de Amazon Bedrock. Connect fue seleccionado como el sistema central debido a su capacidad para mantener una disponibilidad del 99,99 % y, al mismo tiempo, proporcionar capacidades integrales de centro de contacto en todos los canales de voz y chat.

La flexibilidad del modelo de Bedrock es fundamental para el sistema, ya que permite la selección de modelos para tareas específicas en función de la precisión y la latencia. Se utilizó Claude 3.5 Sonnet por sus capacidades de comprensión del lenguaje natural de alta calidad, y los modelos Nova ofrecieron optimización para baja latencia y capacidades comparables de generación y comprensión del lenguaje natural. El siguiente diagrama ilustra la arquitectura de la solución para la solución principal del centro de contacto:

El flujo de trabajo consta de los siguientes pasos de alto nivel:

Un paciente inicia el contacto a través de una llamada telefónica o una interfaz de chat web. Connect procesa el contacto inicial y lo dirige a través de un flujo de contacto configurado. Lex maneja la transcripción y mantiene el estado de la conversación. Una función de cumplimiento de AWS Lambda procesa la conversación utilizando los modelos Claude 3.5 Sonnet y Nova a través de Bedrock para: Clasificar la urgencia y las intenciones Extraer la información requerida Generar respuestas naturales Administrar la programación de citas cuando corresponda

Los modelos utilizados para cada función específica se describen en las secciones de detalles de la solución.

Las transferencias inteligentes al personal se inician cuando se detectan casos urgentes o cuando los pacientes solicitan hablar con los proveedores. Los datos de las conversaciones se procesan a través de un proceso de análisis para monitorear y generar informes (que se describe más adelante en esta publicación).

Algunos desafíos que el equipo abordó durante el proceso de desarrollo incluyeron:

Formatear el flujo de llamadas y el modelo de servicio del centro de contacto de manera que sea intercambiable para diferentes clientes, con cambios mínimos de código y configuración. Administrar los requisitos de latencia para una experiencia de conversación natural. Transcripción y comprensión de los nombres de los pacientes.

Además de las llamadas de voz, el equipo desarrolló una interfaz web utilizando Amazon CloudFront y Amazon S3 Static Website Hosting que demuestra las capacidades multicanal del sistema. Esta interfaz muestra cómo los pacientes pueden participar en conversaciones impulsadas por IA a través de un widget de chat, brindando el mismo nivel de servicio y funcionalidad que las llamadas de voz. Si bien la demostración de la interfaz web utiliza el mismo flujo de contacto que la llamada de voz, se puede personalizar aún más para el idioma específico del chat.

Una interfaz web que utiliza Amazon CloudFront y Amazon S3 Static Website Hosting que demuestra las capacidades multicanal del sistema.

El equipo también creó un canal de análisis que procesa registros de conversaciones para proporcionar información valiosa sobre el rendimiento del sistema y las interacciones con los pacientes. Un panel personalizable ofrece una interfaz fácil de usar para visualizar estos datos, lo que permite que tanto el personal técnico como el no técnico obtengan información útil a partir de las comunicaciones con los pacientes. El proceso de análisis y el panel se crearon utilizando un activo de centro de contacto GenAI reutilizable publicado anteriormente.

Canal de análisis y panel de control

Detalles del manejo de conversaciones

La solución emplea un sofisticado sistema de gestión de conversaciones que organiza interacciones naturales con los pacientes a través de las capacidades multimodelo de Bedrock y capas de indicaciones cuidadosamente diseñadas. En el corazón de este sistema está la capacidad de Bedrock de brindar acceso a múltiples modelos básicos, lo que permite al equipo seleccionar el modelo óptimo para cada tarea específica en función de los requisitos de precisión, costo y latencia. El flujo del sistema de gestión de conversaciones se muestra en la siguiente imagen; NLU significa comprensión del lenguaje natural.

El flujo del sistema de gestión de conversaciones.

El flujo de la conversación comienza con un saludo y una evaluación de urgencia. Cuando un paciente llama, el sistema evalúa inmediatamente si la situación requiere atención urgente utilizando las API de Bedrock. Este primer paso garantiza que los casos de emergencia se identifiquen rápidamente y se dirijan de manera adecuada. El sistema utiliza un mensaje enfocado que analiza la declaración inicial del paciente comparándola con una lista predefinida de categorías de intención urgente, devolviendo "urgente" o "no_urgente" para guiar el manejo posterior.

Después de esto, el sistema pasa a la detección de intenciones. Una innovación clave aquí es la capacidad del sistema para procesar múltiples intenciones dentro de una sola interacción. En lugar de obligar a los pacientes a pasar por árboles de menú rígidos, el sistema puede aprovechar potentes modelos de lenguaje para comprender cuando un paciente menciona tanto un reabastecimiento de recetas como una pregunta sobre facturación, poniendo en cola estas intenciones para el procesamiento secuencial mientras se mantiene el flujo natural de la conversación. Durante esta extracción, nos aseguramos de que se extraigan tanto la intención como la cita de la entrada del usuario. Esto produce dos resultados:

Razonamiento del modelo integrado para garantizar que se extraiga la intención correcta. Referencia del historial de conversaciones que condujo a la extracción de la intención, de modo que la misma intención no se extraiga dos veces a menos que se solicite explícitamente.

Una vez que el sistema comienza a procesar los intentos de forma secuencial, comienza a solicitar al usuario los datos necesarios para atender el intento en cuestión. Esto sucede en dos etapas interdependientes:

Comprobar si faltan campos de información y generar un mensaje en lenguaje natural para solicitar información al usuario. Analizar las expresiones del usuario para analizar y extraer los campos recopilados y los campos que aún faltan.

Estos dos pasos ocurren en bucle hasta que se recopila la información requerida. El sistema también considera los servicios específicos del proveedor en esta etapa, donde se recopilan los campos requeridos por proveedor. La solución relaciona automáticamente los nombres de los proveedores mencionados por los pacientes con el proveedor correcto en el sistema. Esto maneja variaciones como la coincidencia de "Dr. Smith" con "Dra. Jennifer Smith" o "Jenny Smith", eliminando los rígidos requisitos de extensión o coincidencia de nombres de los sistemas IVR tradicionales. La solución también incluye capacidades de transferencia inteligente. Cuando el sistema necesita determinar si un paciente debe hablar con un proveedor específico, analiza el contexto de la conversación para considerar la urgencia y las necesidades de ruta para la intención expresada. Este proceso preserva el contexto de la conversación y la información recopilada, lo que facilita una experiencia fluida cuando se solicita la intervención humana. A lo largo de la conversación, el sistema mantiene un seguimiento integral del estado a través de los atributos de la sesión Lex mientras que el procesamiento del lenguaje natural se produce a través de invocaciones del modelo Bedrock. Estos atributos sirven como memoria de la conversación y almacenan todo, desde la información recopilada del usuario y el historial de la conversación hasta las intenciones detectadas y la información recopilada. Esta gestión de estado permite que el sistema mantenga el contexto en múltiples llamadas a la API de Bedrock, creando un flujo de diálogo más natural.

Gestión de intenciones

El sistema de gestión de intenciones se diseñó a través de una estructura de modelo de servicio jerárquico que refleja cómo los pacientes expresan naturalmente sus necesidades. Para recorrer este modelo de servicio jerárquico, las entradas del usuario se analizan utilizando la comprensión del lenguaje natural, que se maneja a través de llamadas a la API de Bedrock.

El modelo de servicio jerárquico organiza las intenciones en tres niveles principales:

Nivel de urgencia: separar los servicios urgentes de los no urgentes facilita el manejo y el enrutamiento adecuados. Nivel de servicio: agrupar servicios relacionados como citas, recetas y facturación crea categorías lógicas. Nivel específico del proveedor: una mayor granularidad se adapta a los requisitos y subservicios específicos del proveedor.

Esta estructura permite que el sistema navegue de manera eficiente a través de posibles intenciones mientras mantiene la flexibilidad para la personalización en diferentes instalaciones de atención médica. Cada intención en el modelo incluye instrucciones personalizadas que se pueden inyectar dinámicamente en las indicaciones de Bedrock, lo que permite un comportamiento altamente configurable sin cambios de código. El proceso de extracción de intenciones aprovecha las capacidades avanzadas de comprensión del lenguaje de Bedrock a través de un mensaje que indica al modelo que identifique las intenciones presentes en el lenguaje natural del paciente. El mensaje incluye instrucciones completas sobre lo que constituye una nueva intención, la lista completa de posibles intenciones y requisitos de formato para la respuesta. En lugar de forzar la clasificación en una única intención, pretendemos detectar múltiples necesidades expresadas simultáneamente. Una vez que se identifican las intenciones, se agregan a una cola de procesamiento. Luego, el sistema analiza cada intención de forma secuencial y realiza llamadas de modelo adicionales en múltiples capas para recopilar la información requerida a través de una conversación natural. Para optimizar tanto la calidad como la latencia, la solución aprovecha la flexibilidad de selección de modelos de Bedrock para diversas tareas de conversación de manera similar:

La extracción de intenciones utiliza Claude 3.5 Sonnet de Anthropic a través de Bedrock para un análisis detallado que puede identificar múltiples intenciones a partir del lenguaje natural, asegurando que los pacientes no necesiten repetir la información. La recopilación de información emplea un modelo más rápido, Amazon Nova Pro, a través de Bedrock para la extracción de datos estructurados mientras se mantiene el tono conversacional. La generación de respuestas utiliza un modelo más pequeño, Nova Lite, a través de Bedrock para crear respuestas empáticas, naturales y de baja latencia basadas en el estado de la conversación.

Hacer esto ayuda a garantizar que la solución pueda:

Mantener un tono conversacional y empatía Solicitar solo la información específica que falta Reconocer la información ya proporcionada Manejar casos especiales como deletrear nombres

Todo el proceso de gestión de intenciones se beneficia de la API Converse unificada de Bedrock, que proporciona:

Interfaz consistente en todas las llamadas de modelo, lo que simplifica el desarrollo y el mantenimiento. Control de versión del modelo que facilita un comportamiento estable en todas las implementaciones. Arquitectura preparada para el futuro que permite la adopción perfecta de nuevos modelos a medida que estén disponibles.

Al implementar este sistema jerárquico de gestión de intenciones, Clarus puede ofrecer a los pacientes una experiencia de comunicación más natural y eficiente, manteniendo al mismo tiempo la estructura necesaria para el enrutamiento y la recopilación de información adecuados. La flexibilidad de combinar las capacidades multimodelo de Bedrock con un modelo de servicio configurable permite una personalización sencilla por centro de atención médica y al mismo tiempo mantiene la lógica de conversación central consistente y mantenible. A medida que haya nuevos modelos disponibles en Bedrock, el sistema se puede actualizar para aprovechar capacidades mejoradas sin cambios arquitectónicos importantes, lo que facilita la escalabilidad a largo plazo y la optimización del rendimiento.

Programación

El componente de programación de la solución se maneja en un módulo separado diseñado específicamente. Si se detecta una intención de "cita" en el controlador principal, el procesamiento se pasa al módulo de programación. El módulo funciona como una máquina de estados que consta de estados de conversación y próximos pasos. El flujo general del sistema de programación se muestra a continuación:

Flujo del sistema de programación 1. Estado inicial – Mencione el horario de oficina – Solicite preferencias de programación – Mover a GATHERING_PREFERENCES 2. Estado GATHERING_PREFERENCES – Extraiga y procese preferencias de tiempo usando LLM – Verifique las preferencias de tiempo con la base de datos de programación existente – Tres resultados posibles: a. Hora específica disponible – Hora actual para la confirmación – Pasar a CONFIRMACIÓN b. Preferencia de rango – Buscar la hora más temprana disponible en el rango – Presentar esta hora para confirmación – Pasar a CONFIRMACIÓN c. Sin disponibilidad (específica o rango) – Buscar horarios alternativos (±1 día desde el tiempo solicitado) – Presentar bloques de tiempo disponibles – Solicitar preferencia – Permanecer en GATHERING_PREFERENCES – Incrementar el contador de intentos 3. Estado de CONFIRMACIÓN – Dos resultados posibles: a. El usuario confirma (Sí) – Reservar cita – Enviar mensaje de confirmación – Mover al FINAL b. El usuario rechaza (No) – Solicitar nuevas preferencias – Mover a GATHERING_PREFERENCES – Incrementar el contador de intentos 4. Funciones adicionales – Seguimiento de intentos máximos (predeterminado MAX_ATTEMPTS = 3) – Cuando se alcanza el máximo de intentos: – Disculparse y derivar al personal de la oficina – Mover a END 5. Estado END – Conversación completada – Ya sea con reserva exitosa o derivación al personal

Hay tres indicaciones principales de LLM que se utilizan en el flujo de programación:

Extraer preferencias de tiempo (Nova Lite se utiliza para baja latencia y comprensión de preferencias de uso)

Extraiga las preferencias de programación actuales de la conversación. La respuesta debe tener este formato: Explique: – Qué tipo de preferencias se expresaron (específicas o de rango) – Cómo interpretó las fechas u horas relativas – Por qué estructuró y priorizó las preferencias como lo hizo – Cualquier suposición que hizo [ {{ "type": "specific", "priority": n, "specificSlots": [ {{ "date": "AAAA-MM-DD", "startTime": "HH:mm", "endTime": "HH:mm" }} ] }}, {{ "tipo": "rango", "prioridad": n, "dateRange": {{ "startDate": "AAAA-MM-DD", "endDate": "AAAA-MM-DD", "daysOfWeek":[], // "m", "t", "w", "th", "f" "timeRanges": [ {{ "startTime": "HH:mm", "endTime": "HH:mm" }} ] }} }} ] Directrices: – Si las preferencias de tiempo han cambiado a lo largo de la conversación, solo extraiga las preferencias actuales – Puede tener varias preferencias del mismo tipo si es necesario – Asegúrese de que el formato JSON sea el adecuado, la parte JSON de la salida debería funcionar correctamente con json.loads(). No incluya comentarios en JSON. – Convertir fechas relativas (mañana, próximo martes) a fechas específicas – Palabras clave: * mañana: 09:00-12:00 * tarde: 12:00-17:00 – Convertir descripciones de tiempo a rangos específicos (por ejemplo, "mañana antes de las 11": 09:00-11:00, "2-4 pm": 14:00-16:00) – Las citas solo están disponibles los días laborables desde 9:00-17:00: si no se especifica una hora de finalización para un espacio, suponga una duración de 30 minutos. Ejemplo: (Se eliminó la sección de ejemplo por razones de brevedad) Ahora, extraiga las preferencias de programación de la conversación dada. Hora actual: {current_time} Hoy es {current_day} Conversación: {conversation_history}

Determinar si el usuario está confirmando o negando el tiempo (Nova Micro se usa para baja latencia en una tarea simple)

Determine si el usuario está confirmando o rechazando la hora de cita sugerida. Devuelve "verdadero" si lo confirman claramente, "falso" en caso contrario. verdadero|falso Mensaje de usuario: {user_message}

Genere una respuesta natural basada en el siguiente paso (Nova Lite se utiliza para baja latencia y generación de respuesta)

Dado el historial de conversaciones y el siguiente paso, generar una respuesta natural y contextualmente apropiada para el usuario. Escriba su respuesta en etiquetas: Su respuesta aquí Historial de conversaciones: {conversation_history} Siguiente paso: {next_step_prompt}

Los posibles pasos son:

Pregunte al usuario cuándo le gustaría programar su cita con {provider}. No digas Hola o Hola, esto es a mitad de una conversación. Mencione que nuestro horario de oficina es {office_hours}.
La hora {time} está disponible con {provider}. Solicita al usuario que confirme sí o no si este tiempo le conviene antes de proceder con la reserva. No digas que la cita ya está confirmada.
Informar al usuario que la hora solicitada {requested_time} no está disponible. Ofrezca estos horarios o rangos de tiempo alternativos con {provider}: {blocks} Pregunte qué horario sería mejor para ellos.
Reconozca que el tiempo sugerido no les conviene. Pregunte qué otro día u hora preferirían para su cita con {proveedor}. Recuérdeles que nuestro horario de atención es {office_hours}.

Informe al usuario que lo derivará a la oficina

Disculpe que no haya podido encontrar un momento adecuado. Informe al usuario que el personal de nuestra oficina se comunicará con él para ayudarlo a encontrar un horario de cita que le convenga. Agradézcales por su paciencia.

Finalizar una conversación con la confirmación de la reserva

MUY BREVEMENTE confirma que su cita está confirmada con {provider} para {time}. No digas nada más. Ejemplo: Cita confirmada para el 5 de junio con el Dr. Wolf

Extensiones del sistema

En el futuro, Clarus podrá integrar el voicebot del contact center con Amazon Nova Sonic. Nova Sonic es un LLM de voz a voz que ofrece conversaciones de voz similares a las humanas en tiempo real con un precio líder, rendimiento y baja latencia. Nova Sonic ahora está directamente integrado con Connect.

Bedrock tiene varios servicios adicionales que ayudan a escalar la solución e implementarla en producción, que incluyen:

Conclusión

En esta publicación, demostramos cómo el equipo de GenAIIC colaboró ​​con Clarus Care para desarrollar un centro de contacto de atención médica generativo impulsado por IA utilizando Amazon Connect, Amazon Lex y Amazon Bedrock. La solución presenta una interfaz de voz conversacional capaz de manejar múltiples intenciones de pacientes, gestionar la programación de citas y proporcionar capacidades de transferencia inteligente. Al aprovechar los modelos de lenguaje Claude 3.5 Sonnet de Amazon Nova y Anthropic y los servicios de AWS, el sistema logra una alta disponibilidad al tiempo que ofrece una experiencia de comunicación con el paciente más intuitiva y eficiente. La solución también incorpora un canal de análisis para monitorear la calidad y las métricas de las llamadas, así como una interfaz web que demuestra soporte multicanal. La arquitectura de la solución proporciona una base escalable que puede adaptarse a la creciente base de clientes de Clarus Care y a las futuras ofertas de servicios. La transición de un IVR tradicional basado en menús a una interfaz conversacional impulsada por IA permite a Clarus ayudar a mejorar la experiencia del paciente, aumentar las capacidades de automatización y agilizar las comunicaciones de atención médica. A medida que avanzan hacia la implementación, esta solución permitirá a Clarus Care satisfacer las necesidades cambiantes tanto de los pacientes como de los proveedores de atención médica en un panorama de atención médica cada vez más digital.

Si desea implementar una solución similar para su caso de uso, considere el blog Implemente agentes de IA generativos en su centro de contacto para voz y chat utilizando Amazon Connect, Amazon Lex y Amazon Bedrock Knowledge Bases para la configuración de la infraestructura.

Sobre los autores

Rishi Srivastava es vicepresidente de ingeniería de Clarus Care. Es un líder experimentado de la industria con más de 20 años en ingeniería de software empresarial, especializándose en el diseño de arquitectura SaaS basada en la nube multiinquilino y soluciones agentes de IA conversacional relacionadas con la participación del paciente. Anteriormente, trabajó en servicios financieros y finanzas cuantitativas, creando modelos de factores latentes para análisis de cartera sofisticados para impulsar estrategias de inversión basadas en datos.

Scott Reynolds es vicepresidente de producto de Clarus Care, una plataforma de participación del paciente basada en inteligencia artificial y comunicaciones SaaS para el cuidado de la salud. Ha pasado más de 25 años en el mercado de tecnología y software creando plataformas seguras e interoperables que agilizan los flujos de trabajo clínicos y operativos. Ha fundado varias empresas emergentes y posee una patente estadounidense para tecnología de comunicación centrada en el paciente.

Brian Halperin se unió a AWS en 2024 como estratega de GenAI en el Centro de innovación de IA generativa, donde ayuda a los clientes empresariales a desbloquear valor empresarial transformador a través de la inteligencia artificial. Con más de 9 años de experiencia que abarca la implementación de IA empresarial y la transformación de la tecnología digital, aporta un historial comprobado en la traducción de capacidades complejas de IA en resultados comerciales mensurables. Anteriormente, Brian se desempeñó como vicepresidente de un equipo operativo en una firma global de inversión alternativa, liderando iniciativas de inteligencia artificial en todas las empresas de la cartera.

Brian Yost es arquitecto principal de aprendizaje profundo en el Centro de innovación de IA generativa de AWS. Se especializa en aplicar capacidades de IA agente en escenarios de atención al cliente, incluidas soluciones de centros de contacto.

Parth Patwa es científico de datos en el Centro de Innovación de IA Generativa de Amazon Web Services. Es coautor de artículos de investigación en los principales lugares de IA/ML y tiene más de 1500 citas.

Smita Bailur es científica aplicada sénior en el Centro de innovación de IA generativa de AWS, donde aporta más de 10 años de experiencia en IA/ML tradicional, aprendizaje profundo e IA generativa para ayudar a los clientes a desbloquear soluciones transformadoras. Tiene una maestría en Ingeniería Eléctrica de la Universidad de Pensilvania.

Shreya Mohanty Shreya Mohanty es estratega en el Centro de innovación de IA generativa de AWS, donde se especializa en personalización y optimización de modelos. Anteriormente, fue arquitecta de aprendizaje profundo, centrada en la creación de soluciones GenAI para clientes. Utiliza su experiencia multifuncional para traducir los objetivos de los clientes en resultados tangibles e impacto medible.

Yingwei Yu Yingwei Yu es gerente de ciencias aplicadas en el Centro de innovación en IA generativa (GenAIIC) de Amazon Web Services (AWS), con sede en Houston, Texas. Con experiencia en aprendizaje automático aplicado e inteligencia artificial generativa, Yu lidera el desarrollo de soluciones innovadoras en diversas industrias. Tiene múltiples patentes y publicaciones revisadas por pares en congresos profesionales. Yingwei obtuvo su doctorado. en Ciencias de la Computación de la Universidad Texas A&M – College Station.