Detrás de la capacidad de New Relic AI para hablar el lenguaje de consulta New Relic

A medida que los sistemas actuales se vuelven cada vez más distribuidos, efímeros y complejos, la capacidad de comprender las complejidades de la arquitectura del sistema personalizada de su organización conlleva una curva de aprendizaje, al igual que los sistemas que lo ayudan a observarlos. Si bien New Relic le permite recopilar, informar y alertar sobre métricas, eventos, registros y trazas de cualquier fuente de datos de telemetría en una experiencia de plataforma integrada, su capacidad para comprender el estado de su sistema aún puede estar limitada por su dominio de New Relic consulta Language (NRQL), nuestro lenguaje de consulta patentado. New Relic AI reduce esta curva de aprendizaje al ayudarlo a incorporar, analizar, solucionar problemas y depurar empleando símbolos de lenguaje natural y una integración en toda la plataforma. Esto permite que tanto los ingenieros como las partes interesadas no técnicas obtengan mayor información valiosa en sus datos de telemetría y tomen más decisiones informadas por el estado de sus entornos digitales.

La capacidad de New Relic AI para para convertir preguntas en lenguaje natural en NRQL se deriva de modelos de lenguaje extenso (LLM) de vanguardia, como el GPT-4 Turbo de OpenAI. Aunque estos LLM son robustos y se han entrenado con numerosos datos de la web, incluida la documentación de New Relic, no funcionan perfectamente con NRQL listo para usar y requieren instrucciones adicionales para funcionar como se espera. En este blog, aprenderás sobre algunas de las técnicas que nuestro equipo de ingeniería emplea para optimizar la capacidad de New Relic AI para generar consultas NRQL basadas en entradas de lenguaje natural, una habilidad a la que nos referimos internamente como "NL2NRQL ". 

Contexto basado en el usuario e indicaciones breves

La ingeniería de instrucciones implica diversas estrategias para elaborar y mejorar las instrucciones con el fin de aprovechar eficazmente las capacidades de los LLM. Esto generalmente se hace en fases; además de mostrarles cortesía y respuestas constructivas, requieren ajustes para promover conductas y tareas específicas. Aunque los LLM tienen la capacidad de comprender NRQL, a veces mezclan su sintaxis con SQL, especialmente para consultas complejas, porque el conjunto de conocimientos sobre SQL disponible para los LLM en el Internet, es mucho mayor que el que está disponible en la documentación de New Relic. Por ejemplo, la expresión NRQL para filtrar datos de una semana de antigüedad es SINCE 1 week ago. Pero al intentar generar una cláusula NRQL , los LLM tienden a emplear de forma predeterminada la sintaxis SQL, devolviendo algo como WHERE timestamp >= (CURRENT_DATE - interval '1 week').

Con cada instrucción que se envía al LLM a través del asistente, se emplean varias técnicas de ingeniería de instrucciones para personalizar la salida del LLM según nuestras necesidades y convertir su consulta en respuestas NRQL válidas: 

1. Primero, limitamos la tarea obteniendo una lista de todos los eventos de la base de datos de New Relic (NRDB) accesibles en su cuenta y los proporcionamos, junto con su consulta, al LLM. Esto genera una lista de los eventos NRDB más relevantes para que el LLM elija. 
2. Luego recuperamos el esquema de estos eventos de NRDB y los complementamos con información de la documentación de New Relic. Al emplear únicamente datos NRDB que están disponibles para sus licencias de usuario, nos cercioramos de que no se comparta ningún contexto entre otros usuarios y cuentas. Esto también ayuda a la IA a gestionar situaciones en las que puede preguntar sobre eventos o atributos definidos por el usuario y/o no proporcionados por New Relic.
3. A continuación, enviamos una instrucción al LLM que está generando una consulta NRQL que incluye lo siguiente:
   • Una descripción general de la tarea. Por ejemplo, "usted es una IA que traduce las preguntas de los usuarios a la consulta de New Relic Query Language (NRQL). Su tarea es generar una consulta basada en la pregunta de un usuario, información del usuario, descripciones del esquema del evento y símbolo de ejemplo".
   • Una descripción general de cómo la sintaxis NRQL contrasta con SQL.
   • Un esquema detallado de los eventos de su cuenta que mejor se alineen con su pregunta.
   • Ejemplos de otras preguntas de usuarios y respuestas NRQL esperadas .

La estrategia de proporcionar ejemplos de preguntas similares al LLM se conoce como indicaciones de pocas oportunidades. Proporcionamos al LLM muestras de preguntas que la gente podría hacer y la consulta NRQL correspondiente que esperamos que genere para dichas preguntas (como una especie de hoja de referencia), y el volumen y la calidad de los ejemplos en el grupo, son cruciales. Los pares de ejemplo se almacenan en Pinecone, una base de datos vectorial. Cuando hace una pregunta que necesita ser traducida a NRQL, la transformamos en un vector de incrustación (una representación numérica del texto) y luego consultamos a Pinecone para recuperar ejemplos donde el vector de incrustación de una pregunta es similar al que estamos consultando. 

Incluso con tales preparativos, el LLM aún puede cometer errores con la sintaxis NRQL. Para solucionar esto, implementamos un servicio de validación adicional que verifica la consulta generada. Si una consulta es sintácticamente incorrecta, desencadena un ciclo de retroalimentación: el mensaje de error se retroalimenta al LLM junto con fragmentos de ejemplos de sintaxis NRQL y ejemplos de correcciones de errores comunes. Por lo general, esto da como resultado una consulta NRQL corregida en el segundo intento, que luego presentamos completa al usuario con resultados visibles. En caso de que la corrección no tenga éxito, compartimos la consulta con el usuario junto con la advertencia de que no hemos podido generar un NRQL válido para ayudar a garantizar la transparencia. Monitoreamos estos casos y los empleamos para mejorar nuestro proceso NL2NRQL en función de estos aprendizajes.

Aprendizajes, desafíos y limitaciones

Prevención de la alucinación de sintaxis

Si empleó un LLM para traducir un lenguaje natural a un lenguaje de programación, es posible que se encuentre una alucinación de sintaxis, donde un bloque de código está perfectamente estructurado, pero alguna palabra clave, función o atributo no existe. El uso de un LLM por parte de New Relic AI para traducir el lenguaje natural a NRQL lo hace susceptible a los mismos errores. Para evitar estas alucinaciones, podemos probar la validez de nuestro NRQL generado ejecutándolo a través de nuestro analizador sintáctico y compilador para la evaluación de la sintaxis y, luego, contra la NRDB a fin de asegurarnos de que devuelva resultados. New Relic AI realiza la validación de sintaxis de manera continua y en tiempo real, y solo devuelve a los usuarios las consultas que son sintácticamente correctas. Puede leer más sobre nuestros métodos para evaluar el rendimiento de New Relic AI en esta publicación de blog del científico de datos senior de New Relic, Tal Reisfeld.

Abordar la ambigüedad de las preguntas

Mapear una pregunta en un lenguaje natural a una pregunta en un lenguaje de consulta bien definido requiere que nuestra IA realice la desafiante tarea de comprender con precisión lo que se está buscando. Por ejemplo, si pregunta: "¿Cuántos errores ocurrieron recientemente?" Nuestro asistente de inteligencia artificial tiene que hacer suposiciones sobre qué tipos de errores está preguntando (¿móvil, transacción o quizás browser?), así como el periodo de tiempo más razonable que puede considerar "reciente".

Para abordar posibles ambigüedades en la consulta de usuarios, empleamos un enfoque múltiple. Primero, proporcionamos información contextual sobre qué parte de la UI se está empleando cuando hace la pregunta. Este contexto incluye detalles como la entidad que está analizando y los valores del selector de tiempo seleccionados; en el caso de que esté editando activamente una consulta NRQL, incluirá la consulta misma. En segundo lugar, estamos ampliando nuestro conjunto de ejemplos de pocas tomas para demostrar mejor el comportamiento esperado y proporcionar información más completa sobre los esquemas del evento y atributo proporcionados por New Relic. Al emplear esta información contextual y ejemplos aumentados, nuestro modelo de lenguaje comprende mejor su intención y proporciona respuestas más precisas y relevantes, lo que reduce la ambigüedad.

Predecir metadatos desconocidos

La arquitectura sin esquema de NRDB sirve como un diferenciador fundamental de la base de datos de telemetría New Relic sobre las ofertas de la competencia, brindándole una flexibilidad superior en la forma en que se almacenan sus datos. Y como NRQL puede leer y recuperar campos personalizados, usted se beneficia de la misma flexibilidad cuando acceda y analice posteriormente estos datos. Pero debido a que estos eventos personalizados y atributos carecen de documentación estándar, es mucho más difícil estimar la forma y el contenido de los datos almacenados en ellos. En tales casos, la IA se basa en la naturaleza descriptiva de los nombres de eventos y atributos definidos por el usuario para escribir la consulta correcta.

Equilibrando costo y complejidad

La investigación y el desarrollo de una traducción NL2NRQL de alta precisión implica importantes inversiones financieras y de tiempo. Para nosotros era importante lograr un equilibrio entre el nivel de complejidad del proceso NL2NRQL que podíamos acomodar y al mismo tiempo mantenernos dentro del tiempo y los recursos financieros presupuestados. 

A continuación se muestran algunos ejemplos de decisiones que tomamos para equilibrar el rendimiento y el uso de recursos:

• Limitamos el rango de tiempo de todas las consultas NRQL en el backend para cerciorarnos de limitar el consumo de recursos y reducir el tiempo necesario para ejecutar la consulta.
• Para la instrucción donde necesitamos resumir la salida de NRDB, seleccionamos el formato de representación (por ejemplo, JSON o CSV) que minimice la cantidad de tokens empleados.
• En las convocatorias de LLM dirigidas a no usuarios, instruimos al modelo de IA para que proporcione respuestas breves y altamente estructuradas. Este enfoque garantiza que las respuestas del modelo sean más rápidas, más rentables y más fáciles de analizar.

Optimizar el rendimiento y el uso de recursos es un esfuerzo continuo y exploramos persistentemente vías para refinar y mejorar este proceso.

Mejoras continuas

Las pruebas continuas de habilidades esenciales, incluida la traducción NL2NRQL, siguen siendo una parte esencial para mejorar aún más nuestro asistente de IA con nuevas herramientas y características que permiten garantizar una experiencia perfecta del usuario final. Un área de enfoque clave para esta etapa de desarrollo es crear más integración que muestre proactivamente información de stack completa a través de botones intuitivos y símbolos directamente en el flujo de trabajo del usuario a través de experiencias de plataforma integradas. Los ejemplos recientes incluyen un botón "Explicar este error" que lo ayuda a comprender el rastreo de la pila de errores de Errors Inbox y una experiencia similar que lo ayuda a diagnosticar y corregir el registro de errores. Con un solo clic, estas integraciones lanzan un aviso curado junto con el contexto específico y barreras de seguridad para el asistente de IA para ayudar a agilizar la resolución de problemas y ayudarlo a mejorar la experiencia del usuario final. Estas herramientas de capacidad específica son solo una parte de nuestro sistema de IA compuesto que democratiza el acceso a información de telemetría profunda y valiosa para decisiones más impulsadas por datos en toda la organización.