Tiempo de lectura: 16mins
GoDaddy ha realizado una inversión considerable en IA desde el lanzamiento de ChatGPT en diciembre de 2022. Durante este tiempo, hemos impulsado numerosos proyectos que utilizan modelos de lenguaje extenso (LLM) para ayudar a los clientes a crear contenido para sitios web, campañas de marketing en redes sociales, crear logotipos e incluso encontrar el nombre de dominio ideal para su empresa. Mi equipo, Digital Care, utiliza los LLM para brindar una experiencia de cliente excepcional en nuestros canales de mensajería (SMS, WhatsApp y web).
GoDaddy recibe más de 60,000 contactos de clientes diariamente en nuestros canales de mensajería. Muchas de estas conversaciones comienzan con una interacción con uno de nuestros bots. Nos entusiasman las posibilidades de la tecnología LLM aplicada a la atención al cliente. Experimentos iniciales demuestran que los LLM superan a las unidades de lenguaje natural más antiguas; sin embargo, implementarlos no es tarea fácil. Hemos aprendido mucho al implementar estos modelos, y esta publicación analiza esos hallazgos.
El primer experimento de Digital Care con tecnologías LLM fue nuestro Asistente de IA. Este se comunicaba con el cliente hasta clasificar la conversación en uno de los veinte temas de soporte que utilizamos para clasificar nuestras consultas. Una vez identificado el tema, el asistente formulaba preguntas específicas que ayudaban a nuestros Guías (agentes de soporte humanos) a agilizar el proceso. Una vez recopilada la retroalimentación, el asistente la utilizaba para dirigir la conversación a una cola de soporte relacionada con el tema.
El experimento inicial tuvo un buen desempeño, pero comenzamos a observar problemas con nuestra implementación a medida que añadíamos más temas y preguntas. El tema que se utilizaba para dirigir la conversación era cada vez más frecuente y el LLM a veces hacía preguntas no relacionadas con el tema objetivo (tomando ideas de otros). Nuestro segundo experimento con el asistente buscaba ofrecer autoayuda para problemas de soporte comunes. En lugar de formular preguntas y derivar a una cola de soporte, el asistente guiaba al usuario en el proceso de resolución del problema.
El nuevo mensaje alcanzó más de 1500 tokens para cuando lanzamos nuestro segundo experimento, lo que generó altos costos ambientales y, en ocasiones, superó los límites de tokens durante conversaciones largas. La precisión de nuestros mensajes también disminuyó al incorporar nuevas instrucciones y contextos. La gestión de la memoria adquirió mayor importancia al introducir la Generación Aumentada de Recuperación (RAG), incorporando artículos y contenido asociado a nuestros mensajes. En esencia, seguimos el enfoque de megamensajes: creamos un único mensaje para todas las interacciones del usuario.
Pronto nos dimos cuenta de que la transición a indicaciones orientadas a tareas podía lograr una mayor eficiencia en flujos conversacionales complejos. Estas indicaciones se centran en una sola tarea, como “recoger un pedido de café”, lo que permite a los autores dar instrucciones concisas con menos tokens, lo que mejora la precisión. Los autores también obtienen control sobre el resultado (perfeccionando las respuestas específicas), ya que el rango de respuestas viables es mucho menor. Sin embargo, la especificidad de las indicaciones orientadas a tareas significa que no son adecuadas para conversaciones generales y abiertas. Necesitábamos encontrar un equilibrio entre ambas estrategias.
En nuestros experimentos para combinar ambos enfoques, utilizamos indicaciones orientadas a tareas en transiciones clave del flujo de chat. Por ejemplo, cuando un usuario necesitaba transferirse a un agente humano, ejecutábamos una tarea para extraer información vital y proporcionarle un resumen. En otros casos, realizábamos búsquedas e inyectábamos los resultados en la conversación como contexto para la indicación.
Nuestro primer intento de combinar ambas estrategias fue algo rígido, dependiendo en gran medida de código determinista para decidir cuándo dirigir la conversación a una solicitud específica. A medida que nuestro enfoque fue madurando, nos inspiramos en el trabajo multiagente de Salesforce (en concreto, el artículo de BOLAA ). El equipo se centró en desarrollar una arquitectura multisolicitud utilizando el patrón Controlador-Delegado, donde la megasolicitud actúa como controlador que transfiere la conversación a solicitudes orientadas a tareas (delegados).
Los resultados preliminares de nuestros experimentos multiagente son prometedores. Permitir que el indicador del controlador determine cuándo delegar a otro indicador ha simplificado nuestra base de código y mejorado la capacidad de nuestro chatbot. Si bien nuestra implementación se encuentra en sus primeras etapas, este tipo de arquitectura de indicadores se generalizará hasta que los modelos sean más precisos y el costo de los modelos de contexto amplio disminuya.
Las respuestas de texto sin formato de los bots de IA son ideales para escenarios de chat, pero pueden ser menos productivas para sistemas basados en análisis de IA. Las respuestas estructuradas, como JSON o código, deben solicitarse al modelo de IA según sea necesario. Algunos modelos, incluidas las funciones ChatGPT, ya cuentan con capacidades integradas para generar resultados estructurados.
Sin embargo, es crucial validar las respuestas generadas. Antes de introducir las funciones, nuestras pruebas iniciales con ChatGPT 3.5 Turbo presentaban importantes problemas de fiabilidad. Desarrollamos un analizador personalizado para extraer información útil de los cuatro o cinco patrones de fallo típicos que detectamos en el modelo. Afortunadamente, la implementación de las funciones de ChatGPT mejoró los niveles de precisión, aunque no fueron perfectos (obtuvimos resultados no válidos en el 1 % de las solicitudes de ChatGPT 3.5 y el 0,25 % de las de ChatGPT 4).
Descubrimos varias estrategias para mejorar la confiabilidad de las salidas estructuradas:
I'm sorry, I can't assist with this issue. I will transfer you to a
customer support agent for further help.
{
"transfer": true,
"intent": "email",
"message": "I will connect you with customer support."
}Un error común es creer que un único conjunto de indicaciones (en esencia, las instrucciones textuales) puede aplicarse universalmente en diferentes modelos (p. ej., Titan, LLaMa y ChatGPT) manteniendo un rendimiento constante. Nuestros hallazgos demuestran que esto no solo es falso, sino que incluso diferentes versiones del mismo modelo (como ChatGPT 3.5 0603 y ChatGPT 3.5 1106) pueden presentar diferencias notables en el rendimiento.
Para demostrarlo, GoDaddy experimentó con su asistente de IA, comparando la eficiencia de ChatGPT 3.5 Turbo (0603) y ChatGPT 4.0 al abordar problemas de soporte. Inicialmente, supusimos que ChatGPT 4.0 superaría a 3.5 Turbo. Sin embargo, aún estábamos determinando las diferencias de rendimiento y los costos operativos totales de ambos modelos.
En la primera fase de nuestro experimento, utilizamos mensajes idénticos para ambas versiones (3.5 y 4.0). Interrumpimos el experimento después de tres días debido al bajo rendimiento de ChatGPT 3.5, que en ocasiones resultaba contraproducente para la gestión de casos de soporte debido a errores como la transferencia incorrecta de clientes y el diagnóstico erróneo de problemas.
En un intento posterior, ajustamos las indicaciones de cada modelo. Como resultado, observamos una mejora en el rendimiento y menos problemas en la cohorte de ChatGPT 3.5. Además, actualizamos los modelos a la versión de noviembre en un experimento de seguimiento con las versiones 3.5 y 4.0 (gpt-3.5-turbo-1106). Sorprendentemente, incluso sin modificar ninguna de las indicaciones, la diferencia de rendimiento entre las versiones 3.5 y 4.0 se redujo notablemente.
Concluimos que los equipos deben perfeccionar y probar continuamente las indicaciones para validar su desempeño según lo previsto.
Un peligro inherente al uso de LLM es que sus resultados son probabilísticos. Hemos visto indicaciones que han tenido un buen rendimiento en miles de pruebas pero que no ofrecen el resultado esperado al implementarse en los usuarios. Un error crítico que cometimos en los primeros experimentos fue permitir que los modelos determinaran cuándo transferir a los humanos sin una vía de escape para el usuario. En ocasiones, los usuarios se quedaban con un LLM que se negaba a transferirse.
Estos fallos nos advirtieron claramente que no se debe dejar que el modelo tome decisiones sobre ciertas acciones. Por ejemplo, no deberíamos permitir que un LLM negocie acciones sin un proceso de revisión por parte de los usuarios . En resumen, necesitamos “barreras de seguridad” para nuestras aplicaciones de IA. En GoDaddy, hemos implementado varias barreras de seguridad para minimizar los efectos adversos de una toma de decisiones deficiente por parte de la IA. En primer lugar, nuestros sistemas de chat (y otras herramientas) utilizan controles para detectar información personal identificable y contenido ofensivo en las respuestas de la IA, los mensajes de los usuarios y las instrucciones.
Utilizamos métodos deterministas en los sistemas de chat para decidir cuándo transferir las conversaciones a los usuarios. Por ejemplo, nos basamos en frases de parada identificadas por código en lugar del criterio del modelo. También limitamos el número de interacciones de chat entre bots y clientes para evitar que estos se queden bloqueados indefinidamente. Nos aseguramos de que las acciones sensibles que podrían afectar negativamente a un cliente reciban aprobación a través de canales externos al LLM. Esta práctica reduce la probabilidad de que el modelo realice acciones independientes que podrían confundir o perjudicar al usuario.
Finalmente, cuando la situación es incierta, recurrimos a la intervención humana, ya que ciertas acciones suponen un riesgo que no vale la pena tomar dadas las capacidades actuales de la IA.
Una lección fundamental que aprendimos al implementar modelos es que pueden ser lentos y poco fiables. Hemos observado un promedio del 1% de fallos en la finalización de chats con el proveedor del modelo (p. ej., OpenAI). Si bien es probable que las empresas mejoren la fiabilidad de sus sistemas, no está claro cómo resolverán los problemas de latencia en las finalizaciones. Nuestro uso ha demostrado que los modelos de contexto más amplio (con mayor capacidad), como ChatGPT 4.0, responden, en promedio, entre 3 y 5 segundos para finalizaciones inferiores a 1000 tokens. A medida que aumenta el tamaño de los tokens, el rendimiento se degrada significativamente (hemos visto llamadas que duran hasta 30 segundos, cuando agotamos el tiempo de espera de nuestro cliente). Si bien ChatGPT 3.5 Turbo tiene una latencia mucho menor, la tendencia de los modelos más nuevos a ser más lentos que las generaciones anteriores no es alentadora.
Afortunadamente, lidiar con sistemas lentos y poco fiables es un problema bien conocido en la industria. Implementar una lógica de reintento básica en las llamadas a los LLM mitiga la mayoría de los problemas de fiabilidad. Sin embargo, esto suele tener un coste, agravado por la latencia inherente de las llamadas LLM. Por ejemplo, ¿cuánto tiempo debemos esperar en una solicitud a ChatGPT 4 antes de reintentar? Y, si lo hacemos, ¿aceptará el usuario la latencia adicional? Otra estrategia consiste en realizar llamadas redundantes y paralelas al modelo, a costa de un mayor coste.
Los sistemas de chat son sensibles a problemas de latencia y fiabilidad. Los clientes acuden a estos sistemas con problemas; lo último que queremos es agravar sus problemas con una experiencia deficiente. Nuestro sistema era especialmente susceptible a la latencia porque nuestro proveedor de comunicación ascendente tiene un tiempo de espera de 30 segundos para las llamadas a nuestra integración. Los LLM nos obligan a utilizar respuestas asíncronas (es decir, confirmar la solicitud del proveedor y enviar mensajes a los clientes mediante API). Recomendamos, sobre todo si no está limitado por la arquitectura existente, adoptar las API de streaming que ofrecen los proveedores de LLM. Si bien implementar una API de streaming es más complejo, tiene el potencial de ofrecer una experiencia de usuario mucho mejor.
Desde nuestra perspectiva, uno de los mayores desafíos en el desarrollo de asistentes de IA conversacionales es la gestión del contexto del LLM. Si bien la industria ofrece variantes de modelo con grandes tamaños de contexto (OpenAI GPT ofrece hasta 32 000 tokens y Anthropic Claude hasta 100 000), su uso puede resultar prohibitivo a gran escala. Un mayor contexto solo es mejor en ocasiones (como se mencionó en el primer punto sobre megaindicaciones frente a las orientadas a tareas), ya que puede provocar que los modelos se centren en conceptos repetidos o prioricen los tokens más recientes en la predicción.
La comunidad de IA ha desarrollado numerosas estrategias para la gestión de memoria. La biblioteca LangChain incluye diversas técnicas como búferes (que conservan los últimos N mensajes o tokens), resumen, reconocimiento de entidades, grafos de conocimiento, recuperación dinámica por relevancia (mediante almacenes de vectores) y combinaciones de las técnicas mencionadas anteriormente.
Es mejor conservar la conversación completa para conversaciones cortas. Resumir prematuramente los mensajes del usuario y del asistente puede reducir la precisión de las respuestas posteriores del LLM. Para conversaciones más largas, resumir las primeras partes de la conversación, rastrear las entidades con nombre y conservar la mayor parte posible de la conversación posterior nos ha resultado útil. En el caso de ChatGPT, hemos aprendido que eliminar los resultados del uso de herramientas (p. ej., mensajes de función) a veces es beneficioso después de que el modelo haya tenido la oportunidad de responder. Conservar los mensajes ha generado imprevisibilidad en el modelo, incluyendo una fijación en los resultados.
Finalmente, a medida que profundizamos en la arquitectura multiagente, consideramos el uso de pilas para implementar la memoria. La idea principal es proporcionar memoria de trabajo efímera para las solicitudes de los delegados, pero para obtener (y resumir) los resultados cuando la conversación se centre de nuevo en el controlador.
Otra lección que aprendimos durante las primeras fases de nuestra iniciativa LLM fue la necesidad de cambiar los modelos dinámicamente para abordar problemas de fiabilidad y costes. Un ejemplo conmovedor fue una interrupción de varias horas de ChatGPT que dejó inoperativos nuestros chatbots. En un escenario ideal, habríamos podido cambiar de proveedor y continuar nuestras operaciones (incluso con una capacidad reducida).
Un escenario menos drástico es cambiar a modelos de contexto más alto cuando las conversaciones se acercan al límite de memoria (p. ej., ChatGPT 3.5 Turbo con un contexto de 4k al contexto de 32k). Estamos explorando este enfoque para gestionar el uso de herramientas de agente que podría generar un exceso de datos. Podemos aplicar el mismo concepto para minimizar los costos de soporte durante interrupciones del producto que causan un aumento repentino de contactos de soporte, o para aprovechar modelos más precisos (y costosos) al atender a clientes insatisfechos.
Si bien aún no hemos implementado la selección de modelos adaptativos, ya hemos observado interés en este enfoque. Sospechamos que la necesidad de seleccionar modelos dinámicamente cobrará cada vez mayor importancia para la industria a medida que las implementaciones de LLM maduren y las empresas busquen mejorar la eficacia y la rentabilidad de la tecnología.
RAG funciona recuperando información de una fuente externa, añadiendo el contenido a un mensaje y luego invocando un LLM. El objetivo es proporcionar información que el modelo podría no tener en su contexto parametrizado (o conocimiento base). Nuestras implementaciones iniciales de RAG implicaban ejecutar consultas en cada invocación del mensaje, basadas en el mensaje del usuario. Los resultados no fueron satisfactorios. Según nuestra experiencia, normalmente se necesitan tres o cuatro mensajes de usuario para comprender el problema de un cliente, ya que la mayoría de los mensajes iniciales son amables. Al recuperar documentos prematuramente, disminuimos la precisión de la generación al centrar la atención del modelo en el contenido incorrecto.
Implementaciones posteriores implicaron cambiar a un indicador RAG especializado tras determinar la intención de la conversación. Si bien este enfoque funcionó, resultó inflexible. Necesitábamos múltiples indicadores y una máquina de estados para modelar la conversación. Nos topamos con un patrón ya conocido llamado Agentes LLM (con Herramientas) . Un Agente LLM es un indicador asociado a un conjunto de acciones (herramientas). Durante una conversación, el indicador puede devolver una respuesta que indica que se debe invocar una acción con un conjunto de parámetros (p. ej., getWeatherFor('90210')). El software que gestiona el Agente realiza la acción (“llamar a weather.com”) y devuelve los resultados al indicador como un nuevo mensaje. El indicador utiliza los resultados para continuar la conversación con el usuario.
Sin embargo, encontramos ocasiones en las que era conveniente aprovechar RAG más allá del uso de herramientas. Por ejemplo, nuestro equipo de Diseñadores de Conversaciones mantiene instrucciones de voz y tono que queremos incluir en cada mensaje. Otro caso de uso fue proporcionar dinámicamente un conjunto estándar de preguntas de soporte disponibles para mensajes específicos, pero que nuestro departamento de operaciones pudiera actualizar dinámicamente.
Concluimos que existen dos patrones esenciales para implementar RAG. El primero implica incluir contenido dinámico para facilitar la personalización del comportamiento de las indicaciones. El segundo consiste en proporcionar contenido relevante para cada conversación. El segundo patrón implica permitir que el modelo decida cuándo ha recopilado suficiente información para generar sus propios términos de búsqueda (implementados como un Agente LLM). El uso del modelo para generar consultas de búsqueda mejoró la relevancia de las búsquedas en la Base de Conocimiento, lo que mejoró la calidad de las recomendaciones realizadas por el asistente de IA.
Otra lección que aprendimos al implementar RAG fue convertir nuestros conjuntos de datos a formatos más útiles para los modelos. La mayoría de los documentos (artículos, sitios web, etc.) contienen lenguaje complejo e información redundante. Si el modelo lee esa información con frecuencia, el contenido adicional se traducirá en un mayor uso de tokens por parte del modelo y probablemente perjudicará el rendimiento de la predicción.
En lugar de usar el contenido original, lo refinamos mediante Representaciones de Priming Disperso (SPR) . La idea general es que el LLM resuma el contenido de un documento en una representación optimizada para el modelo. Almacenamos las versiones SPR de los documentos en un almacén vectorial y utilizamos ese índice para RAG. Si bien aún no hemos implementado esta técnica, las primeras pruebas son prometedoras. En promedio, observamos una reducción de más del 50 % en el uso de tokens (pero necesitamos realizar experimentos adicionales para determinar si el rendimiento ha mejorado).
El siguiente es un ejemplo de cómo comprimir un artículo del Centro de ayuda de GoDaddy en su SPR:
Ejemplo:
Sin embargo, ni siquiera SPR soluciona un problema común en la implementación de RAG. Gran parte del contenido de nuestra base de conocimiento es similar. Cuando un modelo ejecuta una consulta, puede devolver cientos de documentos que cubren el mismo tema. Dado el contexto limitado de los modelos, solo se podrán usar unos pocos documentos, y estos probablemente serán muy similares (lo que reducirá arbitrariamente el espacio de conocimiento). Además de SPR, estamos experimentando con la agrupación de documentos para agrupar el contenido y aplicando SPR para reducir el contenido a un solo documento. Creemos que este enfoque mejorará el rendimiento al reducir la duplicación y ampliar el espacio de conocimiento al recuperar el contenido.
La última y más importante lección es que las pruebas suelen ser más difíciles y laboriosas que crear una integración LLM. Pequeños cambios en las indicaciones pueden tener un impacto significativo en su rendimiento. Dado que la gama de entradas en lenguaje natural es infinita, es imposible crear pruebas automatizadas más allá de las primeras interacciones del usuario. En cambio, el enfoque más lógico para las pruebas automatizadas es aprovechar las LLM para probar otras LLM. Sin embargo, incluso esta estrategia parece prohibitiva en términos de costos, especialmente cuando se pueden ejecutar miles de pruebas varias veces al día desde una canalización de CI.
Los LLM tampoco capturan la creatividad humana, por lo que las personas necesitarán probar, revisar y supervisar constantemente los sistemas de IA. Recomendamos crear los sistemas de informes necesarios para recopilar los resultados del LLM para su revisión por parte de los equipos de control de calidad. También hemos descubierto que trabajar en equipo (desarrolladores, redactores, gerentes de producto, analistas de negocio y control de calidad) para revisar las transcripciones durante los primeros días posteriores a un lanzamiento importante es muy útil. Contar con un equipo de revisión multidisciplinario nos permite detectar y solucionar problemas rápidamente.
Los LLM son una herramienta nueva y emocionante para mejorar la experiencia del usuario; sin embargo, presentan desafíos. Desde comprender que se necesita más de una indicación hasta comprender la importancia de las barreras de seguridad de la IA, una implementación cuidadosa y un ajuste continuo son clave. Los desarrolladores deben aprender a gestionar la memoria de forma eficiente y a usar RAG con eficacia. Además, hemos aprendido que los modelos pueden ser lentos y poco fiables, que las indicaciones no son universalmente aplicables y que los resultados estructurados deben manejarse con cuidado. A medida que las implementaciones se vuelven más sofisticadas, los equipos deben considerar estrategias para seleccionar modelos en tiempo de ejecución para optimizar el rendimiento y el coste. Finalmente, las pruebas exhaustivas y la monitorización continua son vitales para garantizar un rendimiento óptimo. Esperamos que estos conocimientos adquiridos en GoDaddy aporten valor a quienes se embarcan en su camino hacia un LLM.
Richard Clayton | director de ingeniería en GoDaddy
Artículo original: https://www.godaddy.com/resources/news/llm-from-the-trenches-10-lessons-learned-operationalizing-models-at-godaddy#h-1-sometimes-one-prompt-isn-t-enough
