Utilización modelos de Azure Open AI con Dataverse

En el entorno empresarial actual, la eficiente gestión de casos y la categorización adecuada de los correos electrónicos recibidos son aspectos clave para brindar un excelente servicio al cliente. En este artículo, nos adentraremos y exploraremos cómo aprovechar el poder de Azure Open AI Service para automatizar la clasificación de casos dentro del módulo de CRM Customer Service, mejorando así la productividad y la eficiencia en la gestión de incidencias, evolutivos y preguntas.

El objetivo es hacer un repaso de Azure OpenAI, utilizar uno de sus modelos «gpt-35-turbo» y realizar una integración entre Dataverse y el modelo, para crear casos categorizados a partir de un email. Todo esto de manera automática, la petición hacia el modelo se realizará desde un plugin desde Dynamics 365.

Lo primero de todo, es conocer qué es Azure Open AI Service y qué es lo que nos ofrece. Es un servicio alojado en Azure que nos proporciona acceso a los modelos OpenAI más avanzados GPT-4, GPT-3, Codex y DALL-E. Este servicio al estar alojado en la nube de Microsoft está dotado de la promesa empresarial y de seguridad que establece Azure. En definitiva, ofrece a los clientes los mismos modelos OpenAI pero con las capacidades de seguridad y escalado de Azure.

La suscripción para Azure OpenAi Service se encuentra actualmente limitada, para poder acceder a ella es necesario solicitar su acceso y rellenar el siguiente formulario Solicitud Azure Open AI Service (el acceso no es inmediato).

Una vez se obtiene el acceso, desde la cuenta de Azure, hay que crear un recurso «Azure Open AI» desde Marketplace:

Para crear el recurso es necesario rellenar los siguientes parámetros:

• MyOpenAIResource
• OAIResourceGroup
• eastus
• subscriptionID

Dentro del recurso se puede acceder a Azure OpenAI Studio, que es una interfaz de usuario sencilla y amigable donde se puede trabajar con los diferentes modelos.

Existen muchos modelos, que se pueden dividir por familia y por capacidad. Se van a señalar los principales, en este artículo se va a trabajar con GPT-3, modelo «gpt-35-turbo»:

Es fundamental comprender el concepto de token, ya que los modelos de OpenAI operan utilizando tokens, y el costo del uso de dichos modelos dependen de ellos. Los tokens son las partes más pequeñas en las que el modelo puede dividir una palabra para interpretarla, no siempre coinciden con el número de sílabas de una palabra. En palabras cortas, el token podría ser la palabra completa.

Cada modelo tiene unas cuotas de facturación distintas y siempre se calculan por cada 1000 token. Además, los modelos tienen establecido un límite de tokens por solicitud, en el caso de gpt-35-turbo el máximo es de 4096 token, contando tanto la solicitud, como la respuesta del modelo.

Una vez dentro de Azure OpenAI Studio, se selecciona la página implementaciones dentro de Administración, desde ahí puedes seleccionar el modelo que se quiera implementar y se le indica un nombre adecuado

Desde el botón «Abrir en el área de juegos” realizar una redirección hacia las páginas de «Chat» y «Finalizaciones», aquí es donde se puede acceder e interactuar con el modelo. Existen plantillas por defecto que tienen definido el comportamiento del modelo, aunque se pueden modificar. También ofrece la opción de coger una plantilla vacía para configurar el modelo desde cero.

Para configurar y definir el comportamiento del modelo se pueden utilizar una serie de parámetros.

• Temperatura: Controla la aleatoriedad. Reducir la temperatura significa que el modelo generará respuestas más repetitivas y deterministas. El aumento de la temperatura dará lugar a respuestas más inesperadas o creativas. Intenta ajustar la temperatura o la P superior, pero no ambos.

• P superior: De forma similar a la temperatura, controla la aleatoriedad, pero usa un método diferente. Al reducir la P superior, se restringirá la selección de tokens del modelo a tokens atípicos. Si aumenta top P, el modelo podrá elegir entre tokens con alta y baja probabilidad. Intenta ajustar la temperatura o la P superior, pero no ambos.

• Longitud máxima (tokens): Establezca un límite en el número de tokens por respuesta del modelo. La API admite un máximo de 4000 tokens compartidos entre el símbolo del sistema (incluidos el mensaje del sistema, ejemplos, historial de mensajes y consulta de usuario) y la respuesta del modelo. Un token tiene aproximadamente 4 caracteres para el texto típico en inglés.

• Secuencias de detención: Haga que las respuestas se detengan en un punto deseado, como el final de una oración o una lista. Especifique hasta cuatro secuencias en las que el modelo dejará de generar más tokens en una respuesta. El texto devuelto no contendrá la secuencia de detención.

• Penalización de frecuencia: Reduzca la posibilidad de repetir un token proporcionalmente en función de la frecuencia con la que ha aparecido en el texto hasta ahora. Esto reduce la probabilidad de repetir exactamente el mismo texto en una respuesta.

• Penalización de presencia: Reduzca la posibilidad de repetir cualquier token que haya aparecido en el texto hasta ahora. Esto aumenta la probabilidad de introducir nuevos temas en una respuesta.

Para poder definir correctamente el modelo es necesario indicarle el comportamiento que debe de seguir el sistema. También, ofrece la posibilidad de añadir ejemplos de como debe comportarse el asistente según las preguntas del usuario, para ello utilizamos el concepto de rol. Tenemos los siguientes roles.
• System -> Definir el comportamiento del asistente.
• User -> Añadir ejemplo de una posible interactuación de un usuario.
• Assistant -> Añadir cuál sería la respuesta hacia el mensaje del usuario.

Por último, tras definir los parámetros y los roles del modelo (gpt-35-turbo), podemos realizar pruebas dentro del propio Azure OpenAI Studio.

En este ejemplo se va a definir un modelo cuya función sea clasificar correos que se pueden recibir de distintos usuarios y clasificarlos en evolutivo, pregunta o incidencia. Para ello, dentro de la implementación del modelo previamente creado (gpt-35-turbo) hay que definir tanto sus parámetros como su comportamiento basado en roles.

Configuración de roles:
Sistema:
«Eres una inteligencia artificial que se encarga de tipificar casos a partir de mensajes de correo electrónico que recibes desde una app. Solo necesito la respuesta de la categoría. Existen 3 tipos: Pregunta, Incidencia y Evolutivo. Pregunta: Se categoriza como Pregunta cuando un usuario no sepa cómo funciona algún tema, o tenga dudas de que pasos seguir para realizar una acción. Incidencia: Se categoriza como Incidencia, cuando el usuario indique que ha tenido algún problema con su pedido, o el servicio recibido. También cuando indique que ha recibido algo en mal estado. Evolutivo: Se categoriza como Evolutivo cuando un usuario exprese la necesidad de implementar una nueva necesidad.»

Ejemplo 1.
Usuario:
«Buenas tardes, me cuesta mucho trabajo realizar cargas, quiero solicitar un proceso para quitarme ese trabajo.»
Asistente:
«Evolutivo»

Ejemplo 2.

Usuario:

«No puedo comprar el producto, no me aparece el botón. Un saludo»

Asistente:

«Pregunta»

Mientras más específica sea la función del sistema y más ejemplo se utilicen, mayor es la probabilidad de acierto en la categorización.

Con el modelo ya configurado podemos realizar pruebas desde la «Sesión de Chat» para verificar que el funcionamiento es el adecuado.

Azure OpenAI Studio proporciona en varios lenguajes la posibilidad de realizar peticiones al modelo, desde el botón «Ver código». Aparecen los siguientes lenguajes:

• • Json
  • Python
  • C#
  • Curl

En un entorno de Dataverse, Customer Service, se ha adecuado un escenario para categorizar casos a partir de correos electrónicos enviados por el cliente.

El funcionamiento es el siguiente, cuando se reciben correos electrónicos se ejecuta un plugin, asociado a la entidad Email, en la creación. Este plugin realiza una serie de comprobaciones y monta la llamada basándose en el código que proporciona Azure OpenAI Studio.

Al objeto que se envía en la petición añadirle el cuerpo del mensaje del email recibido para que pueda analizar y categorizar el mensaje. El código proporcionado por el modelo está muy completo, pero es necesario realizar adaptaciones para adecuarlo a las necesidades.

En este ejemplo se ha utilizado una llamada «HttpRequest»:

Como se comentó con anterioridad, el modelo devuelve la categoría del email, una vez se recibe la respuesta, se crea un registro en la tabla Incident con la tipología adecuada y queda asociado al correo electrónico recibido.

Ejemplo 1

Creación de correo:

Ejemplo 2
Creación de correo:

Espero que os haya sido de utilidad, el futuro nos espera ;)