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   (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. essas métricas mais acionáveis  O problema      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,   são acionáveis por natureza e, portanto, operacionais. Métricas percebidas pelo usuário e  métricas relatadas pelo usuário as métricas percebidas pelo usuário  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   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. as métricas percebidas pelo usuário  É necessário haver uma maneira de medir o impacto esperado de todas as melhorias de desempenho diretamente em relação   Isto deve ser tratado como o  às métricas relatadas pelo usuário. 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,   também são afetadas por fatores como sazonalidade e percepção da empresa. as métricas relatadas pelo usuário  O impacto nas   pode ser estimado com mais precisão, mas   têm muitos fatores incontroláveis. métricas percebidas pelo usuário as métricas relatadas pelo usuário  Solução  O   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. feedback não estruturado relatado pelo usuário  Deve-se observar que pode ser mais prático usar o objetivo principal   para   para proteger contra a distorção inerente nessas métricas. Para   , 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. das métricas relatadas pelo usuário regressões de métricas “recentes” do usuário projetos mais horizontais de longo prazo  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   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   então o projeto provavelmente está realmente melhorando a percepção do usuário. métricas estruturadas relatadas pelo usuário, as Métricas Reportadas,  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.

Read My Stories

Este áudio é produzido no idioma original da história!

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

About Author

COMENTARIOS

Rótulos

ESTE ARTIGO FOI APRESENTADO EM

Related Stories

Navegando pelas águas: desenvolvendo aplicações RAG de nível de produção com data lakes

Valhalla de Floki se junta como patrocinador associado da viagem da Índia ao Sri Lanka

As camadas invisíveis: por que as entrevistas com usuários são um ativo insubstituível

Criando produtos criptográficos centrados no usuário: a importância do feedback do cliente

Navegando pelas águas: desenvolvendo aplicações RAG de nível de produção com data lakes

Valhalla de Floki se junta como patrocinador associado da viagem da Índia ao Sri Lanka

As camadas invisíveis: por que as entrevistas com usuários são um ativo insubstituível

Criando produtos criptográficos centrados no usuário: a importância do feedback do cliente

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps