Por trás da capacidade da New Relic AI de falar a linguagem de consulta da New Relic

À medida que os sistemas atuais se tornam cada vez mais distribuídos, efêmeros e complexos, a capacidade de compreender as complexidades da arquitetura do sistema sob medida da sua organização traz consigo uma curva de aprendizado, assim como os sistemas que ajudam você a observá-las. Embora a New Relic permita coletar, relatar e alertar sobre métricas, eventos, logs e traces de qualquer fonte de dados de telemetria em uma única experiência de plataforma integrada, sua capacidade de compreender a integridade do seu sistema ainda pode ser limitada pela sua proficiência em New Relic Query Language (NRQL), nossa linguagem de consulta proprietária. A New Relic AI reduz essa curva de aprendizado ajudando você a integrar, analisar, solucionar problemas e depurar usando prompt de linguagem natural e integração em toda a plataforma. Isso permite que os engenheiros e partes interessadas não técnicas obtenham insights maiores sobre os seus dados de telemetria e tomem decisões mais informadas pela saúde dos seus ambientes digitais.

A capacidade da New Relic AI de converter questões de linguagem natural em NRQL é derivada de grandes modelos de linguagem (LLMs) de última geração, como o GPT-4 Turbo da OpenAI. Embora esses LLMs sejam robustos e treinados em extensos dados da web, incluindo a documentação do New Relic, eles não funcionam perfeitamente com NRQL imediatamente e exigem instruções adicionais para funcionar conforme o esperado. Neste blog, você aprenderá sobre algumas das técnicas que nossa equipe de engenharia utilizou para otimizar a capacidade da New Relic AI de gerar consultas NRQL com base em entradas de linguagem natural – uma habilidade que chamamos internamente de “NL2NRQL”. 

Contexto baseado no usuário e solicitações rápidas

O Prompt Engineering envolve diversas estratégias para elaborar e aprimorar prompts para aproveitar eficientemente as capacidades de LLMs. Isso normalmente é feito em fases; além de ensinar-lhes educação e respostas construtivas, necessitam de ajustes precisos para promover comportamentos e tarefas específicas. Embora os LLMs tenham a capacidade de entender a NRQL, eles às vezes misturam sua sintaxe com SQL, especialmente para consultas complexas, porque o conjunto de conhecimentos sobre SQL disponível para LLMs na Internet é muito maior do que o que está disponível na documentação da New Relic. Por exemplo, a expressão NRQL para filtrar dados de uma semana atrás é SINCE 1 week ago. Mas ao tentar gerar uma cláusula NRQL, os LLMs tendem a usar como padrão a sintaxe SQL, retornando algo como WHERE timestamp >= (CURRENT_DATE - intervalo '1 semana').

Com cada prompt enviado ao LLM por meio do assistente, várias técnicas de engenharia prompt são usadas para personalizar a saída do LLM de acordo com nossas necessidades e converter sua consulta em respostas NRQL válidas: 

1. Primeiro, restringimos a tarefa obtendo uma lista de todos os eventos do banco de dados New Relic (NRDB) acessíveis em sua conta e fornecendo-os, junto com sua consulta, ao LLM. Isso gera uma lista dos eventos NRDB mais relevantes para o LLM escolher. 
2. Em seguida, recuperamos esses esquemas de eventos do NRDB e os complementamos com informações da documentação New Relic . Ao usar apenas dados NRDB disponíveis para as permissões do seu usuário, garantimos que nenhum contexto seja compartilhado entre outros usuários e contas. Isso também ajuda a IA a gerenciar situações em que você pode perguntar sobre eventos ou atributos definidos pelo usuário e/ou não fornecidos pela New Relic.
3. Em seguida, enviamos um prompt ao LLM que está gerando uma consulta NRQL que inclui o seguinte:
   • Uma descrição geral da tarefa. Por exemplo, "Você é uma IA que traduz as perguntas do usuário em consultas em New Relic Query Language (NRQL). Sua tarefa é gerar uma consulta com base na pergunta do usuário, nas informações do usuário, nas descrições do esquema do evento e nos prompts de exemplo".
   • Uma visão geral de como a sintaxe NRQL contrasta com SQL.
   • Um esquema detalhado do evento da sua conta que melhor se alinhe à sua pergunta.
   • Exemplos de perguntas de outros usuários e respostas NRQL esperadas.

A estratégia de fornecer exemplos de questões semelhantes ao LLM é conhecida como prompting de poucos disparos. Fornecemos ao LLM exemplos de perguntas que as pessoas podem fazer e a consulta NRQL correspondente que esperamos que ele produza para tais perguntas (como uma espécie de folha de dicas), e o volume e a qualidade dos exemplos no conjunto são cruciais. Os pares de exemplo são armazenados em Pinecone, um banco de dados vetorial. Quando você faz uma pergunta que precisa ser traduzida para NRQL, nós a transformamos em um vetor de incorporação (uma representação numérica do texto) e depois consultamos a Pinecone para recuperar exemplos onde o vetor de incorporação de uma pergunta é semelhante ao que estamos consultando. 

Mesmo com tais preparativos, o LLM ainda pode cometer erros com a sintaxe NRQL. Para resolver isso, implementamos um serviço de validação adicional que verifica a consulta gerada. Se uma consulta estiver sintaticamente incorreta, ela aciona um loop de feedback: a mensagem de erro é enviada de volta para o LLM junto com um trecho de exemplos de sintaxe NRQL e exemplos de correções de erros comuns. Isso normalmente resulta em uma consulta NRQL corrigida na segunda tentativa, que então apresentamos ao usuário completa com resultados visualizados. Caso a correção não seja bem-sucedida, compartilhamos a consulta com o usuário junto com um aviso de que não foi possível gerar um NRQL válido para ajudar a garantir a transparência. Nós monitoramos esses casos e os usamos para melhorar nosso pipeline NL2NRQL com base nesses aprendizados.

Aprendizados, desafios e limitações

Como prevenir alucinação de sintaxe

Se você já usou um LLM para traduzir linguagem natural para uma linguagem de programação, pode ter se deparado com alucinações de sintaxe – onde um bloco de código está perfeitamente estruturado, mas alguma palavra-chave, função ou atributo não existe. O uso de um LLM pela New Relic AI para traduzir linguagem natural para NRQL o torna suscetível aos mesmos erros. Para evitar alucinações de sintaxe, podemos testar a validade do nosso NRQL gerado executando-o por meio do nosso analisador e compilador para avaliação de sintaxe e, em seguida, contra o NRDB para garantir que ele retorne resultados. A New Relic AI realiza validação de sintaxe continuamente e em tempo real, retornando aos usuários apenas consultas que estejam sintaticamente corretas. Você pode ler mais sobre nossos métodos para avaliar o desempenho da New Relic AI nesta postagem do blog do cientista de dados sênior New Relic Tal Reisfeld.

Como abordar a ambiguidade de perguntas

O mapeamento de uma pergunta em uma linguagem natural para uma pergunta em uma linguagem de consulta bem definida exige que nossa IA execute a desafiadora tarefa de entender precisamente o que está sendo pesquisado. Por exemplo, se você perguntar: “Quantos erros aconteceram recentemente?” Nosso assistente de IA precisa fazer suposições sobre quais tipos de erros você está perguntando (móvel, transação ou talvez navegador?), bem como o período de tempo mais razoável que pode ser considerado “recente”.

Para abordar possíveis ambiguidades na consulta do usuário, empregamos uma abordagem multifacetada. Primeiro, fornecemos informações contextuais sobre qual parte da interface você está usando ao fazer a pergunta. Este contexto inclui detalhes como a entidade que você está analisando e os valores do seletor de hora selecionado; caso você esteja editando ativamente uma consulta NRQL , ela incluirá a própria consulta. Em segundo lugar, estamos expandindo nosso conjunto de exemplos de poucas cenas para demonstrar melhor o comportamento esperado e fornecer informações mais abrangentes sobre os esquemas de eventos e atributos fornecidos pela New Relic . Ao usar essas informações contextuais e exemplos aumentados, nosso modelo de linguagem entende melhor sua intenção e fornece respostas mais precisas e relevantes, reduzindo a ambiguidade.

Como prevenir metadados desconhecidos

A arquitetura sem esquema do NRDB serve como um diferenciador fundamental de bancos de dados de telemetria New Relic em relação às ofertas concorrentes, proporcionando flexibilidade superior na forma como seus dados são armazenados. E como o NRQL é capaz de ler e recuperar campos personalizados, você se beneficia da mesma flexibilidade ao acessar e analisar esses dados posteriormente. Mas como esses eventos personalizados e atributos não possuem documentação padrão, é muito mais difícil estimar a forma e o conteúdo dos dados neles armazenados. Nesses casos, a IA depende da natureza descritiva dos nomes de eventos e atributos definidos pelo usuário para escrever a consulta correta.

Como equilibrar custo e complexidade

A pesquisa e o desenvolvimento de traduções NL2NRQL altamente precisas envolveram investimentos financeiros e de tempo significativos. Foi importante para nós encontrarmos um equilíbrio entre o nível de complexidade do pipeline NL2NRQL que poderíamos acomodar, permanecendo dentro do tempo e dos recursos financeiros orçados. 

Aqui estão alguns exemplos de decisões que tomamos para equilibrar desempenho e uso de recursos:

• Limitamos o intervalo de tempo de todas as consultas NRQL no backend para garantir que restringimos o consumo de recursos e reduzimos o tempo necessário para executar a consulta.
• Para prompts onde precisamos resumir a saída do NRDB, selecionamos o formato de representação (por exemplo, JSON ou CSV) que minimiza o número de tokens usados.
• Em chamadas LLM não voltadas para o usuário, instruímos o modelo de IA a fornecer respostas curtas e altamente estruturadas. Essa abordagem garante que as respostas do modelo sejam mais rápidas, mais econômicas e mais fáceis de analisar.

Otimizar o desempenho e o uso de recursos é um esforço contínuo e exploramos persistentemente caminhos para refinar e aprimorar esse processo.

Melhorias contínuas

Testes contínuos das habilidades fundamentais, incluindo a tradução de NL2NRQL, continuam sendo uma parte essencial do aprimoramento do nosso assistente de IA ainda mais com novas ferramentas e recursos para garantir experiências perfeitas ao usuário final. Uma área de foco principal para esse estágio de desenvolvimento é criar mais integração que revele proativamente insights da full-stack por meio de botões intuitivos e avise diretamente nos fluxos de trabalho do usuário através de uma experiência integrada à plataforma. Exemplos recentes incluem o botão "Explain this error", que ajuda a entender os stack traces dos erros do Error Inbox e uma experiência semelhante que ajuda a diagnosticar e corrigir o log de erros. Com um clique, essas integrações lançam um prompt selecionado junto com um contexto específico e proteções para o assistente de IA para ajudar a agilizar a resolução de problemas e ajudar você a melhorar a experiência do usuário final. Essas ferramentas específicas de capacidade são apenas uma parte do nosso sistema composto de IA que democratiza o acesso a insights telemétricos profundos para decisões mais orientadas por dados em toda a organização.