Observabilidade para aplicações LLM: Um estudo de caso prático

A ascensão das aplicações LLM e a necessidade de observabilidade

O campo do desenvolvimento de software foi radicalmente transformado pela revolução dos modelos de linguagem de grande escala (LLM). Desde chatbots sofisticados e geradores de conteúdo inteligentes até assistentes de código e ferramentas de análise de dados, os LLM estão integrados em uma gama cada vez mais ampla de aplicações. Essa adoção rápida, embora empolgante, introduz uma nova classe de desafios, principalmente no que diz respeito à compreensão e manutenção desses sistemas em produção. As ferramentas de monitoramento tradicionais, projetadas para softwares determinísticos e baseados em regras, muitas vezes têm dificuldades em compreender as sutilezas do comportamento dos LLM.

É aqui que entra a observabilidade. A observabilidade, no contexto das aplicações LLM, é a capacidade de entender o estado interno de um sistema alimentado por um LLM a partir de suas saídas externas. Ela vai além das simples verificações de saúde para fornecer insights profundos sobre como o LLM interpreta as consultas, gera respostas, gerencia o contexto e interage com ferramentas ou fontes de dados externas. Sem uma observabilidade sólida, a depuração de problemas de desempenho, a garantia de equidade, a identificação de alucinações ou a otimização de custos podem se tornar uma tarefa desanimadora, se não quase impossível. Este artigo apresenta um estudo de caso prático sobre a implementação da observabilidade para uma aplicação LLM, demonstrando princípios e ferramentas chave.

Estudo de caso: ‘DocuChat’ – Um assistente de base de conhecimento interno

Vamos considerar uma aplicação hipotética chamada ‘DocuChat’. DocuChat é um assistente de base de conhecimento interno projetado para ajudar os funcionários a encontrar rapidamente respostas dentro de uma vasta coleção de documentos internos (páginas Confluence, arquivos Slack, wikis internos, etc.). Ele utiliza uma arquitetura de geração aumentada por recuperação (RAG):

1. Consulta do usuário: Um funcionário faz uma pergunta (por exemplo, “Como solicitar um novo laptop?”).
2. Recuperação: O sistema pesquisa em um banco de dados vetorial (alimentado por embeddings de documentos internos) para encontrar trechos relevantes de documentos.
3. Aumento: Esses trechos recuperados, juntamente com a consulta original do usuário, são fornecidos como contexto a um LLM.
4. Geração: O LLM sintetiza uma resposta com base no contexto fornecido e na consulta do usuário.

DocuChat utiliza o GPT-4 da OpenAI para a geração e um modelo de embedding auto-hospedado para a recuperação. Foi construído utilizando Python, LangChain e um banco de dados vetorial como Pinecone ou Weaviate. Inicialmente, a equipe de desenvolvimento se concentrou na funcionalidade, mas à medida que a aplicação ganhou usuários, uma infinidade de questões operacionais surgiram:

• Por que algumas respostas são lentas?
• O LLM alucina, ou a recuperação falha?
• Os usuários estão satisfeitos com as respostas?
• Quanto isso nos custa por consulta?
• Estamos atingindo os limites de taxa da API?
• Quais tipos de perguntas os usuários fazem com mais frequência?

Essas questões destacam a necessidade crítica de observabilidade.

Pilares da observabilidade LLM para DocuChat

Para DocuChat, vamos nos concentrar nos três pilares tradicionais da observabilidade, adaptados para aplicações LLM:

1. Logs: Registros estruturados de eventos.
2. Métricas: Medidas numéricas agregadas ao longo do tempo.
3. Traços: Vistas de ponta a ponta das consultas através de sistemas distribuídos.

Além disso, consideraremos um quarto pilar crucial para os LLM: Retorno de experiência / Avaliação.

1. Logs: O ‘O que aconteceu’

Os logs de aplicação tradicionais são vitais, mas para as aplicações LLM, eles devem capturar detalhes específicos centrados no LLM. Para o DocuChat, instrumentamos várias etapas do pipeline RAG para emitir logs estruturados.

Exemplo de estrutura de log (JSON):

{
 "timestamp": "2023-10-27T10:30:00Z",
 "service": "docuchat-rag-api",
 "level": "INFO",
 "event_type": "user_query",
 "session_id": "abcd-1234-efgh",
 "user_id": "user_123",
 "query": "How do I request a new laptop?",
 "metadata": {
 "user_agent": "Mozilla/5.0...",
 "ip_address": "192.168.1.10"
 }
},
{
 "timestamp": "2023-10-27T10:30:01Z",
 "service": "docuchat-rag-api",
 "level": "INFO",
 "event_type": "retrieval_start",
 "session_id": "abcd-1234-efgh",
 "query": "How do I request a new laptop?",
 "vector_db_query": "laptop request policy",
 "k_value": 5
},
{
 "timestamp": "2023-10-27T10:30:02Z",
 "service": "docuchat-rag-api",
 "level": "INFO",
 "event_type": "retrieval_complete",
 "session_id": "abcd-1234-efgh",
 "retrieved_docs_count": 3,
 "retrieved_docs": [
 {"id": "doc-456", "source": "confluence/laptop-policy", "score": 0.89},
 {"id": "doc-789", "source": "slack/it-announcements", "score": 0.81}
 ],
 "retrieval_duration_ms": 1000
},
{
 "timestamp": "2023-10-27T10:30:03Z",
 "service": "docuchat-rag-api",
 "level": "INFO",
 "event_type": "llm_generation_start",
 "session_id": "abcd-1234-efgh",
 "model_name": "gpt-4",
 "temperature": 0.7,
 "prompt_tokens": 500,
 "system_prompt_hash": "abc123def456" 
},
{
 "timestamp": "2023-10-27T10:30:08Z",
 "service": "docuchat-rag-api",
 "level": "INFO",
 "event_type": "llm_generation_complete",
 "session_id": "abcd-1234-efgh",
 "response": "To request a new laptop, please visit the IT portal...",
 "completion_tokens": 150,
 "total_tokens": 650,
 "llm_duration_ms": 5000,
 "finish_reason": "stop"
},
{
 "timestamp": "2023-10-27T10:30:09Z",
 "service": "docuchat-rag-api",
 "level": "INFO",
 "event_type": "response_sent",
 "session_id": "abcd-1234-efgh",
 "total_request_duration_ms": 9000
}

Ao centralizar esses logs (por exemplo, utilizando ELK Stack, Splunk, Datadog), a equipe pode:

• Filtrar por session_id para reconstruir uma interação completa.
• Identificar chamadas de recuperação ou LLM lentas.
• Analisar as consultas comuns e seus resultados.
• Depurar problemas examinando o prompt exato fornecido ao LLM e os documentos recuperados.

2. Métricas: O ‘Quanto’ e ‘A que velocidade’

As métricas fornecem insights agregados e quantificáveis sobre o desempenho e a utilização do sistema. Para o DocuChat, seguimos as métricas-chave utilizando Prometheus e as visualizamos com Grafana.

Métricas-chave específicas para LLM:

• Latência:
  • docuchat_total_request_duration_seconds_sum/_count (tempo de resposta total do sistema)
  • docuchat_retrieval_duration_seconds_sum/_count
  • docuchat_llm_api_duration_seconds_sum/_count
• Uso de tokens & Custo:
  • docuchat_llm_prompt_tokens_total (contador)
  • docuchat_llm_completion_tokens_total (contador)
  • docuchat_llm_total_tokens_cost_usd_total (calculado com base no preço do modelo)
• Estado da API:
  • docuchat_llm_api_calls_total (contador, rotulado por model_name, status_code)
  • docuchat_vector_db_queries_total (contador, rotulado por status_code)
  • docuchat_llm_api_rate_limit_errors_total (contador)
• Desempenho da recuperação:
  • docuchat_retrieved_documents_count_sum/_count (média de documentos recuperados por consulta)
  • docuchat_retrieved_documents_avg_score (gauge/síntese)
• Engajamento do usuário:
  • docuchat_successful_responses_total (contador)
  • docuchat_failed_responses_total (contador)

Essas métricas permitem que a equipe:

• Estabeleça alertas para alta latência ou aumento nas taxas de erro.
• Monitore o custo financeiro do uso dos LLM em tempo real.
• Identifique gargalos no pipeline RAG (por exemplo, recuperação lenta vs LLM lento).
• Compreenda a distribuição de pontuações dos documentos recuperados, indicando a eficácia da recuperação.

3. Traços: O ‘Caminho percorrido’

Os traços fornecem uma visão geral do caminho de uma única consulta através de um sistema distribuído. Para o DocuChat, o OpenTelemetry é utilizado para instrumentar o pipeline LangChain e todas as chamadas de API externas. Cada etapa do processo RAG se torna um intervalo dentro de um traço.

Exemplo de fluxo de traço para o DocuChat:

1. Intervalo: Consulta do usuário (Intervalo raiz)
   • Atributos: user_id, query, session_id
2. Faixa: Recuperação
   • Atributos: vector_db_query, k_value, retrieval_engine
   • Faixa filho: Consulta Vector DB
     • Atributos: query_vector_size, response_time_ms
   • Faixa filho: Pré-processamento de documento (se aplicável)
     • Atributos: num_docs_processed
   • Eventos: “3 documentos recuperados”, “Nenhum documento relevante encontrado”
3. Faixa: Geração LLM
   • Atributos: model_name, temperature, prompt_tokens, completion_tokens
   • Faixa filho: Chamada API OpenAI
     • Atributos: api_endpoint, status_code, request_id
   • Eventos: “A geração do LLM começou”, “A geração do LLM foi concluída”, “Alucinação do LLM detectada (confiança baixa)”
4. Faixa: Pós-processamento & Resposta
   • Atributos: response_length_chars, sentiment_score

Com o auxílio de um backend de rastreamento (como Jaeger, Honeycomb, Datadog APM), a equipe pode:

• Inspecionar visualmente a sequência exata das operações para uma consulta específica.
• Identificar qual etapa do pipeline RAG consome mais tempo.
• Compreender o contexto passado ao LLM (documentos recuperados) para um rastreamento específico.
• Identificar erros ou comportamentos inesperados em intervalos específicos.

4. Retorno de Informação Humano & Avaliação: O ‘Como Fazer Bem’

Os LLMs, por natureza, são probabilísticos. Enquanto os logs, métricas e rastros nos informam sobre os mecanismos do sistema, eles nem sempre dizem qual é a qualidade da saída do LLM. É aqui que o retorno de informação humano e as métricas de avaliação automatizadas se tornam cruciais.

Para o DocuChat, implementamos:

1. Botões de Voto Positivo/Negativo: Mecanismo de retorno de informação simples para cada resposta. Votos negativos acionam um alerta para revisão manual se um certo limite for atingido.
2. Funcionalidade “Relatar um Problema”: Permite aos usuários fornecer feedback em texto livre sobre alucinações, respostas incorretas ou informações irrelevantes.
3. Avaliação de Conjunto de Dados Golden: Um conjunto de perguntas conhecidas com respostas verificadas por especialistas. Executar regularmente o DocuChat contra esse conjunto de dados e avaliar as respostas usando métricas como:
   • RAGAS: Um framework especificamente para avaliação RAG, medindo aspectos como fidelidade, relevância das respostas, precisão do contexto e recuperação do contexto.
   • Similaridade Semântica: Uso de modelos de embedding para comparar a resposta gerada com a resposta de referência.
   • Sobreposição de Palavras-Chave: Verificações simples para a presença de termos chave.
4. LLM-como-Julgador: Em alguns casos, um LLM mais poderoso (por exemplo, GPT-4) pode ser usado para avaliar a saída de um LLM menos poderoso (por exemplo, GPT-3.5) em relação a uma referência ou para critérios específicos (por exemplo, concisão, tom).

A integração desses retornos permite à equipe:

• Medir diretamente a satisfação dos usuários e identificar problemas.
• Melhorar de forma iterativa o pipeline RAG (por exemplo, refinando a estratégia de segmentação, melhorando o modelo de embedding, ajustando a engenharia das solicitações).
• Acompanhar o desempenho das diferentes versões de LLM ou algoritmos de recuperação ao longo do tempo.

Implementação Prática e Ferramentas

A pilha de observabilidade para o DocuChat utiliza uma combinação de ferramentas de código aberto e comerciais:

• Registro: O módulo logging do Python, configurado para produzir JSON, enviado ao Loki (o sistema de agregação de logs do Grafana Labs).
• Métricas: Prometheus para a coleta de dados temporais, expresso via um endpoint FastAPI personalizado com prometheus_client. Grafana para a criação de dashboards e alertas.
• Rastreamento: OpenTelemetry Python SDK para instrumentação, enviando rastros ao Jaeger. LangChain oferece lembretes integrados que podem ser adaptados ao OpenTelemetry.
• Plataformas Específicas para LLM: Ferramentas como LangSmith (para rastreamento e avaliação com LangChain), Weights & Biases (para acompanhamento de experiências e avaliação de modelos), ou Arize AI (para observabilidade e monitoramento de LLM) podem simplificar significativamente o processo, especialmente para casos de uso avançados e equipes grandes. Para este estudo de caso, optamos por uma abordagem mais DIY usando componentes de código aberto para ilustrar os fundamentos.
• Retorno de Informação Humano: Elementos de interface do usuário personalizados integrados a um serviço de retorno de informação dedicado que registra para o Loki e atualiza um contador de métricas.

Vantagens e Resultados para o DocuChat

A implementação dessa estratégia de observabilidade aprofundada resultou em benefícios significativos para a equipe do DocuChat:

• Depuração Mais Rápida: Quando um usuário relatou uma resposta incorreta, os engenheiros puderam rapidamente rastrear a consulta, examinar os documentos recuperados, o prompt exato e a resposta do LLM, geralmente identificando problemas em poucos minutos.
• Otimização de Custos: Ao monitorar o uso de tokens, a equipe identificou oportunidades para reduzir o tamanho dos prompts e experimentar com modelos de LLM mais baratos para casos de uso específicos, resultando em uma redução de 15% nos custos da API.
• Desempenho Aprimorado: As métricas revelaram que o banco de dados vetorial estava às vezes lento. Isso levou a otimizar a estratégia de indexação vetorial e expandir o banco de dados, resultando em uma melhoria de 20% no tempo médio de resposta.
• Confiabilidade Reforçada: Os alertas para erros da API do LLM ou altas taxas de alucinação permitiram uma intervenção proativa, evitando uma insatisfação generalizada dos usuários.
• Iteração Baseada em Dados: O retorno de informação humano e as métricas de avaliação forneceram evidências concretas sobre as mudanças mais eficazes a serem feitas no pipeline RAG ou na engenharia dos prompts, promovendo assim uma melhoria contínua.
• Transparência: As partes interessadas tiveram uma melhor visão geral do desempenho do sistema e do valor que ele entregava.

Desafios e Trabalhos Futuros

Embora tenha sido bem-sucedida, a implementação não ocorreu sem desafios:

• Volume de Dados: As interações com os LLM podem gerar muitos dados (prompts, respostas, contexto). Gerenciar e armazenar esses dados de maneira eficaz é crucial.
• Compreensão Contextual: Interpretar as saídas dos LLM ainda requer frequentemente julgamento humano. A avaliação automatizada está melhorando, mas não é perfeita.
• Mudanças na Engenharia dos Prompts: Mudanças frequentes nos prompts exigem um gerenciamento cuidadoso de versões e a garantia de que as métricas de avaliação permaneçam relevantes.
• Detecção de Alucinações: Embora algumas métricas (como a fidelidade RAGAS) ajudem, a detecção sólida e em tempo real de alucinações continua a ser um campo de pesquisa ativo.

Os trabalhos futuros para o DocuChat incluem:

• Integrar uma detecção avançada de anomalias para as saídas dos LLM.
• Desenvolver estruturas de testes A/B mais sofisticadas para diferentes configurações de RAG.
• Explorar a detecção proativa de prompts adversariais ou tentativas de injeção de prompts.
• Utilizar modelos menores e ajustados para tarefas específicas para otimizar ainda mais os custos e a latência.

Conclusão

A observabilidade não é apenas uma vantagem, mas uma exigência fundamental para construir aplicações LLM confiáveis, performáticas e econômicas. Como mostra o estudo de caso do DocuChat, uma estratégia aprofundada que incorpora registros estruturados, métricas detalhadas, rastreamentos de ponta a ponta e um feedback humano crucial fornece os insights necessários para navegar nas complexidades únicas dos sistemas alimentados por LLM. Ao investir em observabilidade desde o início, as equipes de desenvolvimento podem ganhar confiança em suas aplicações LLM, depurar problemas rapidamente, otimizar o desempenho e, finalmente, oferecer uma experiência de usuário superior.

🕒 Published: April 1, 2026