Monitore o desvio de produção do LLM sem coletar tudo

O que a pesquisa e a documentação cobrem

ProxyDrift, uma pré-impressão de agosto de 2026, estuda como comparar o tráfego ao vivo com conjuntos de testes usando resumos estruturados de interações. Esses resumos representam acesso direto às interações brutas. A documentação do LangSmith descreve a pontuação de execuções ao vivo e a adição de exemplos a conjuntos de testes offline. Estas são abordagens diferentes. Nenhum dos dois prova que uma configuração de monitoramento protege a privacidade ou cobre todo tipo de solicitação do usuário.

Evidência: Detecção e recuperação de desvio de dados com preservação de privacidade para aplicativos LLM em grande escala por meio de representações de proxy [1]Avaliação LangSmith [2]

Observe três tipos de mudança

O desvio de entrada significa que as solicitações foram alteradas. Os usuários podem solicitar tarefas diferentes, usar novos idiomas ou enviar documentos mais longos. Desvio de resultados significa que os resultados mudaram, como mais erros ou respostas mais lentas. O desvio de medição significa que o processo de pontuação mudou. Um novo juiz, guia de pontuação ou regra de amostragem pode mover os números. Registre essas alterações separadamente.

Uma taxa de falhas mais alta pode significar que as tarefas recebidas serão mais difíceis. Nem sempre significa que o modelo é mais fraco. Uma média inalterada também pode esconder um problema se as solicitações mais fáceis equilibrarem as mais difíceis. Compare grupos importantes para o seu produto, como idioma ou tipo de tarefa. Mostre o número de exemplos por trás de cada pontuação.

Mantenha um registro de monitoramento focado

Rubrex recomenda começar com a decisão que cada alerta deve apoiar. Para investigar o tempo limite de uma ferramenta, você pode precisar do nome da ferramenta, da hora, do tipo de erro e da versão do software. Talvez você não precise da mensagem completa do usuário. Para verificar se uma resposta é verdadeira, você pode precisar do documento de origem. Combine quem pode acessar esses dados e quando eles devem ser excluídos.

Rótulos e representações baseadas em números, como incorporações, ainda podem conter informações confidenciais. Verifique se eles revelam detalhes privados ou podem estar vinculados a uma pessoa. Mantenha os dados ativos do usuário fora de exemplos públicos. Use exemplos fictícios ou remova detalhes confidenciais ao explicar uma falha. Os dados que foram transformados não são automaticamente seguros para serem compartilhados.

Exemplo: documentos digitalizados causam novas falhas

Suponha que um assistente de compras comece a receber documentos digitalizados após o lançamento de uma nova integração. O modelo não mudou, mas o sistema agora tem dificuldade para extrair o texto. O antigo conjunto de testes usa texto digital limpo. Ainda passa, mesmo que usuários reais vejam mais falhas.

Primeiro, confirme onde a extração falha usando exemplos que você tem permissão para revisar. Adicione documentos digitalizados a um grupo de teste separado, com texto de referência verificado. Em seguida, teste a etapa de extração, bem como a resposta final. Uma alteração imediata pode não corrigir o texto fonte ausente. Verifique se os novos testes detectam o problema real antes de confiar neles como um sinal de alerta.

Dê a cada alerta uma próxima etapa

Nomeie um proprietário para cada alerta. Explique por que seu limite é importante e o que o proprietário deve verificar primeiro. Revise alarmes falsos, bem como incidentes que o alerta não percebeu. Quando uma falha real se torna um caso de teste, registre de onde ela veio, o que deve acontecer e qual versão do conjunto de testes a contém. Observe as mudanças nas regras de tráfego e pontuação ao comparar resultados novos e antigos.

• Registre as versões de aplicação, conjunto de teste, juiz e amostragem.
• Compare a qualidade dentro de cada grupo de tarefas, bem como em geral.
• Revise uma ampla amostra juntamente com casos que acionam alertas.
• Verifique as regras de acesso e exclusão para dados brutos e rótulos derivados.

Torne o painel útil durante um incidente

O monitoramento mostra como os sinais selecionados mudam ao longo do tempo. A observabilidade ajuda a rastrear um sinal até uma solicitação, configuração do sistema ou dependência. A avaliação verifica se o resultado atendeu às necessidades do usuário. Rubrex recomenda conectar esses registros com um ID de execução. Mantenha apenas os dados necessários para a investigação, de acordo com as regras de dados acordadas para o produto.

Tente seguir um alerta do início ao fim. A equipe consegue encontrar os casos afetados e a versão do software? Alguém pode transformar a falha em um teste que outro engenheiro possa executar novamente? Mostre contagens de amostras, resultados ausentes, falhas graves e definições de pontuação ao lado de cada tendência. Após uma correção, execute novamente o teste e verifique se o resultado melhorou. Um painel é útil quando ajuda alguém a decidir o que fazer a seguir.

Perguntas comuns