As Ressurreições das Métricas: Ação! Ação! Ação!

Fundo

Vendo a resposta incrível aos 3 primeiros artigos desta série, tive que publicar uma 4ª parte.

Nos três artigos anteriores, discutimos definições de métricas de desempenho, instrumentação e escalabilidade para agentes de IA de conversação. Caso você não tenha conferido os artigos anteriores, aqui estão os links:

• Parte 1 - Métricas: Engula a Pílula Vermelha
• Parte 2 - Métricas Recarregadas: O Oráculo
• Parte 3 - A Revolução das Métricas: Dimensionamento

Neste artigo, discutiremos como tornar essas métricas mais acionáveis (usando os últimos avanços do LLM) para melhorar o desempenho continuamente. O objectivo será manter a discussão simplificada e de nível bastante elevado para todos os que trabalham neste domínio.

O problema

Métricas percebidas pelo usuário e métricas relatadas pelo usuário são duas classes de métricas de alto nível que discutimos. Tradicionalmente, a primeira é considerada uma métrica de nível de sistema – essas métricas são medidas diretamente a partir de logs. Como resultado, as métricas percebidas pelo usuário são acionáveis por natureza e, portanto, operacionais.

As métricas operacionais são rastreadas regularmente a partir de registros de produção e podem ser usadas para definir metas para OKRs de toda a equipe.

No entanto, embora as métricas percebidas pelo usuário sejam fáceis de operacionalizar, deve-se notar que estas são métricas “percebidas” e não “reais” do usuário. Como resultado, o aumento nessas métricas pode não levar a uma melhoria significativa na percepção do usuário sobre seu agente de IA conversacional. Isto pode levar a uma gestão ineficiente de recursos se estes projetos se estenderem por vários trimestres.

É necessário haver uma maneira de medir o impacto esperado de todas as melhorias de desempenho diretamente em relação às métricas relatadas pelo usuário. Isto deve ser tratado como o impacto da “estrela norte”. Então qual é o problema?

Espera-se que o feedback direto do usuário seja desestruturado, não seja acionável e seja diferente de operacionalizar.

O feedback detalhado relatado pelo usuário deve ser desestruturado por natureza. Se o feedback relatado pelo usuário for estruturado, ele pode acabar focando em áreas que a equipe interna já conhece. Além disso, as métricas relatadas pelo usuário também são afetadas por fatores como sazonalidade e percepção da empresa.

O impacto nas métricas percebidas pelo usuário pode ser estimado com mais precisão, mas as métricas relatadas pelo usuário têm muitos fatores incontroláveis.

Solução

O feedback não estruturado relatado pelo usuário deve ser convertido em um formato estruturado que possa ser acionável. Pode haver modelos específicos de ML treinados com a finalidade de converter feedback não estruturado em métricas existentes no nível do sistema.

Deve-se observar que pode ser mais prático usar o objetivo principal das métricas relatadas pelo usuário para regressões de métricas “recentes” do usuário para proteger contra a distorção inerente nessas métricas. Para projetos mais horizontais de longo prazo , essas métricas devem ser usadas para medir o impacto na percepção do usuário, juntamente com métricas no nível do sistema.

LLMs são os divisores de águas

Agora permanece a questão: qual é o esforço necessário para treinar modelos de ML para as métricas específicas que procuramos? Com o recente aumento na popularidade e disponibilidade de LLMs, pode ser possível usar APIs prontas para uso para converter feedback não estruturado em algo que possa ser rastreado e medido de forma semelhante às métricas de nível de sistema.

É importante observar que, com o aumento do número de tokens que os LLMs podem processar, muitas informações específicas do produto podem ser fornecidas como parte do próprio “prompt”. Como resultado, APIs LLM prontas para uso, juntamente com alguma engenharia imediata, podem fornecer métricas relatadas pelo usuário acionáveis.

Isso fornece uma maneira realmente rápida de avaliar o impacto dos projetos de melhoria de métricas no nível do sistema na percepção do usuário, o que pode ser útil na priorização de projetos de melhoria de desempenho.

Mesmo com esta abordagem de métricas estruturadas relatadas pelo usuário, ainda há espaço para mudanças inesperadas. No entanto, pode-se presumir com algum nível de confiança que, se um projeto específico (que visa melhorar uma métrica no nível do sistema) acabar impactando positivamente as Métricas Reportadas, então o projeto provavelmente está realmente melhorando a percepção do usuário.

No entanto, não há garantia de que todas as mudanças realmente “boas” irão sempre melhorar efetivamente as métricas relatadas pelo usuário. Como resultado, é importante utilizar uma combinação de ambos para priorizar e avaliar projetos de melhoria de desempenho.