Observabilidade de aplicações com IA: como rastrear qualidade, custo e falhas até à sua causa

Que problema a observabilidade resolve

Uma resposta deficiente não identifica, por si só, o componente que falhou. Pode ter sido uma geração sem fundamento, mas também uma consulta de recuperação que devolveu documentos pouco pertinentes, uma ferramenta externa que respondeu com erro, uma validação que aceitou uma saída incorreta ou uma tentativa que alterou o comportamento e o custo. Limitar-se a registar o texto final e uma marca de erro deixa demasiadas hipóteses em aberto.

A observabilidade transforma uma interação numa sequência reconstruível de factos técnicos. A sua finalidade prática é responder, para uma execução concreta e também para uma população de execuções, que versão tratou o pedido, que entradas estruturadas recebeu, que passos executou, quanto demorou cada um, que recursos consumiu e qual foi o resultado verificável. Esta evidência permite distinguir um incidente isolado de uma regressão após uma alteração.

Não substitui as avaliações anteriores à implantação nem garante que uma resposta seja correta. A sua função é complementar essas práticas com sinais de produção. As fontes fornecidas descrevem a necessidade de ligar modelo, prompt, tempos por etapa, tentativas, tokens, custo e qualidade quando o caso de uso o exige. Este guia traduz esse enquadramento num contrato mínimo de instrumentação, sem pressupor que uma métrica agregada explique, por si só, a causa raiz.

Para navegar deste enquadramento para materiais relacionados, a arquitetura de conteúdos pode ligar a [Aprender](route:learn.index), [Comparar](route:compare.index) e [Descobrir](route:discover.index). Essas ligações não substituem a evidência recolhida no rastreio de cada execução.

A unidade de análise: um rastreio de interação

A unidade mínima útil é um rastreio por interação de negócio, não por chamada isolada ao modelo. Deve começar quando a aplicação aceita uma tarefa identificável — por exemplo, responder a uma consulta ou processar um pedido — e terminar quando entrega, rejeita ou abandona um resultado. O rastreio tem um identificador estável e contém intervalos filhos para as etapas que o compõem.

Um intervalo representa uma operação delimitada: normalização de entrada, recuperação, chamada ao modelo, execução de ferramenta, tentativa, validação, pós-processamento ou entrega. Cada intervalo conserva a sua relação de parentesco, início, fim, estado e atributos específicos. Assim, uma latência total elevada pode ser decomposta sem atribuir automaticamente a demora ao fornecedor do modelo.

O rastreio deve relacionar-se com um identificador pseudonimizado de pedido ou conversa, um canal, um tipo de tarefa e uma coorte de implantação. Não é conveniente usar esses atributos para armazenar texto livre ou identificadores diretos de pessoas. O objetivo é conseguir segmentar uma degradação por versão, tarefa, ambiente ou canal sem reidentificar quem utilizou o serviço.

A reconstrução tem de incluir referências imutáveis às versões utilizadas: modelo e parâmetros relevantes, modelo de prompt, configuração de recuperação, definição de ferramentas, regras de validação e versão do fluxo. Se um identificador apontar para conteúdo mutável, uma investigação posterior pode reconstruir uma configuração diferente daquela que produziu o incidente.

O contrato mínimo de telemetria

Defina o contrato antes de instrumentar. Ao nível do rastreio, registe identificador, hora, ambiente, tipo de tarefa, canal, coorte, versão do fluxo, estado final e um resultado de negócio quando existir. Ao nível do intervalo, registe tipo de operação, estado, duração, número de tentativa, dependências e atributos que permitam comparar configurações. Utilize um vocabulário controlado para estados como sucesso, erro técnico, erro de validação, rejeição segura, cancelamento e tempo esgotado.

Para uma chamada ao modelo, os atributos mínimos incluem fornecedor ou família de modelo, versão ou alias resolvido quando disponível, parâmetros que alterem materialmente a saída, identificador do modelo, tokens de entrada e saída e custo calculado ou dados suficientes para o calcular de acordo com a tarifa em vigor. Para recuperação, inclua índice ou coleção versionada, estratégia, filtros, número de candidatos e documentos selecionados através de identificadores não sensíveis.

As ferramentas necessitam de nome e versão, operação pedida, código de resultado, classe de erro, duração e idempotência ou chave de correlação se executarem ações. Para validações, registe o nome e a versão da regra, o resultado e uma categoria de falha. Não confunda um JSON sintaticamente válido com uma resposta aceitável para o negócio: são sinais distintos.

O contrato deve documentar o que é excluído. Por predefinição, evite prompts, respostas, documentos recuperados, argumentos completos de ferramentas, endereço de e-mail, telefone, moradas, segredos, tokens de acesso e qualquer dado que não seja indispensável para o diagnóstico. Quando o texto for necessário para depuração autorizada, aplique minimização, mascaramento, controlos de acesso e retenção diferenciada.

Como medir o custo real por interação

O custo por interação não equivale ao custo médio de uma chamada principal. Some as chamadas de entrada e saída do modelo, as tentativas, as chamadas de ferramentas com faturação própria, a recuperação se gerar despesa atribuível e os passos falhados. Mantenha separado o custo observado de uma estimativa: o primeiro provém de dados de utilização e preços aplicados; a segunda pode depender de tarifas, arredondamentos ou informação incompleta.

Atribua cada componente ao mesmo rastreio e preserve a moeda, a data de cálculo e a versão da tabela tarifária ou do método de estimativa. Esta precaução é importante porque uma alteração de preço, modelo ou modalidade de processamento pode fazer com que dois períodos não sejam diretamente comparáveis. Se não existir custo verificável para um componente, marque-o como desconhecido em vez de imputar zero.

Meça distribuições, não apenas médias. Uma média estável pode ocultar uma cauda de interações com múltiplas tentativas ou contextos excessivos. Segmente por tarefa, canal, versão e resultado final. O custo de uma execução que termina em erro continua a ser custo operacional e deve aparecer tanto no total como na análise de desperdício.

Quando houver revisão humana, é preferível registá-la como custo ou esforço operacional separado, com um método explícito de estimativa. Misturá-la com a despesa de inferência pode ocultar que uma otimização de latência transferiu trabalho para as pessoas.

Separar as fontes de latência

A latência de ponta a ponta é o tempo que quem utiliza a aplicação percebe, mas não indica que componente deve ser corrigido. Registe intervalos para fila ou admissão, preparação de contexto, recuperação, chamadas ao modelo, rede quando possa ser observada, ferramentas, tentativas, validação e serialização de saída. A soma pode não coincidir exatamente com o total se existirem operações paralelas; por isso, também deve ser registada a relação temporal entre intervalos.

Compare percentis de duração por etapa, e não apenas o valor médio total. Uma subida no percentil elevado das ferramentas com latência de modelo estável orienta a investigação para uma dependência externa. Um aumento da recuperação pode provir de um índice, de um filtro ou de um crescimento do número de candidatos. Uma resposta lenta devido a tentativas exige rever tanto a condição que as desencadeia como a sua política de limites.

Evite atribuições simplistas. O facto de um rastreio conter uma chamada ao modelo não demonstra que o modelo tenha sido o gargalo. A evidência adequada é uma distribuição temporal segmentada pela mesma versão, tipo de tarefa e condições comparáveis. Alterações de tráfego, conteúdo ou mistura de utilizadores são fatores de confusão que devem ficar registados.

Sinais de qualidade em produção e os seus limites

A qualidade não deve ser reduzida a uma única pontuação. O feedback dos utilizadores reflete a experiência percebida, mas pode ser escasso, enviesado para casos extremos ou não ter contexto. A revisão humana permite aplicar critérios definidos e detetar falhas subtis, embora tenha custo e cobertura limitada. As regras determinísticas são reproduzíveis para requisitos verificáveis, como um esquema ou uma autorização, mas não captam, por si só, utilidade, exatidão factual ou adequação contextual.

Os avaliadores automáticos podem ajudar a priorizar amostras e acompanhar tendências se forem versionados, calibrados face a revisão humana e usados com limites explícitos. Não constituem uma prova independente de verdade, especialmente quando avaliam tarefas ambíguas ou partilham enviesamentos com o sistema avaliado. Registe a sua versão, entrada disponível, critério, resultado e nível de confiança se o método o produzir.

Ligue todos os sinais ao rastreio e distinga claramente a sua proveniência. Uma queda de avaliações positivas não é equivalente a uma regra de negócio incumprida; uma saída com JSON válido não demonstra que os seus valores estejam corretos. O painel deve permitir ver cada sinal em separado e, depois, examinar coincidências ou divergências.

Amostre casos sem feedback além dos negativos. Caso contrário, a equipa aprende sobre quem reporta problemas, mas não sobre erros silenciosos. O desenho da amostra deve ser documentado: população, período, estratos, tamanho e critério de revisão.

Diagnóstico de quatro incidentes frequentes

Uma resposta inventada deve ser investigada a partir do resultado, para trás. Verifique se a tarefa exigia fundamentação, se existiu contexto recuperado, que documentos foram selecionados, que instruções de utilização de fontes se aplicavam e se uma regra ou revisão detetou afirmações não sustentadas. Se a configuração de recuperação ou a versão do prompt não foi registada, a causa pode permanecer indeterminada; não atribua a falha ao modelo por exclusão.

Perante contexto irrelevante, compare consulta normalizada, filtros, coleção versionada, estratégia, número de candidatos e seleção final. O problema pode estar na indexação, nos filtros, nos metadados, em alterações do corpus ou na estratégia de ranking. A baixa relevância também pode resultar de o pedido ter sido classificado numa tarefa errada antes de recuperar informação.

Para JSON inválido, separe a camada sintática da semântica. Reveja o esquema exigido, o método de saída estruturada, a versão do parser, as tentativas e a resposta de validação. Uma tentativa bem-sucedida pode ocultar uma taxa crescente de primeiras respostas inválidas e elevar o custo e a latência.

Perante uma ação de ferramenta falhada, determine se a ferramenta foi chamada, se recebeu argumentos permitidos, se a dependência respondeu, se ocorreu um tempo esgotado e se existiram efeitos parciais. As ações com consequências devem incorporar chaves de idempotência, estados de confirmação e limites de tentativas. Uma resposta final satisfatória não prova que a ação foi executada.

Alertas, limiares e decisões de interrupção

Um alerta útil especifica métrica, janela, segmento, limiar, responsável, evidência necessária e ação inicial. “A qualidade baixa” não cumpre esse critério. Uma formulação operacional poderia vigiar o aumento de erros de validação de uma versão concreta durante uma janela definida, exigir rastreios de amostra e atribuir uma revisão à pessoa responsável pelo fluxo.

Utilize limiares como regras de atenção, não como prova de causalidade. Devem basear-se numa linha de base do próprio serviço e ser revistos quando mudam o volume, a mistura de tarefas ou o produto. Combine alertas de disponibilidade e segurança com revisão de qualidade e custo: otimizar uma métrica isolada pode piorar outra.

Interrompa, reverta ou limite uma alteração quando violar uma condição de segurança, uma regra de negócio crítica ou um limite económico acordado, ou quando a evidência mostrar uma degradação relevante face a uma coorte comparável. Noutros casos, reduza a exposição através de implantações graduais e aumente a amostragem antes de concluir.

As fontes fornecidas recomendam relacionar desempenho, custo e qualidade e comparar versões ou ambientes. A escolha concreta de limiares não é estabelecida de forma universal nessas fontes; deve resultar dos riscos, da linha de base e dos compromissos do serviço.

Retenção, minimização e acesso

Um rastreio detalhado pode transformar-se num repositório sensível se for concebido sem limites. Comece pela pergunta diagnóstica e registe apenas os atributos necessários para a responder. Identificadores pseudonimizados, hashes com gestão adequada e categorias de erro tendem a oferecer mais valor operacional do que armazenar indiscriminadamente prompts, respostas ou documentos completos.

Separe dados operacionais de dados de depuração excecional. Os primeiros podem incluir durações, versões, contadores, estados e referências técnicas; os segundos, se justificados, exigem acesso limitado, mascaramento, registo de acesso e uma retenção curta definida. Reveja também que dados as bibliotecas de instrumentação enviam a terceiros antes de as ativar.

Defina quem pode consultar rastreios, quem pode aceder a conteúdo excecional e quem pode alterar regras de redação ou retenção. Os pedidos de eliminação, os requisitos regulamentares e as políticas internas podem variar segundo a jurisdição e o caso de uso. Este guia não determina obrigações legais; estas exigem uma avaliação aplicável ao contexto da organização.

A documentação fornecida da New Relic menciona filtros para descartar dados sensíveis antes do seu envio. Esse facto sustenta a viabilidade técnica de filtrar, mas não demonstra que uma configuração concreta seja suficiente para todas as categorias de dados nem para todos os enquadramentos normativos.

Modelo final de lançamento e painel mínimo

Antes de lançar uma versão, confirme que cada execução pode ser ligada a uma versão imutável de fluxo, prompt, modelo, recuperação, ferramentas e validações. Verifique que as tentativas aparecem como intervalos ou atributos distinguíveis, que os tokens e custos são atribuídos a todas as tentativas e que os resultados de negócio não são confundidos com erros técnicos.

O painel mínimo deve combinar volume de rastreios, taxa de estados finais, latência total e por etapa, tokens e custo por interação, tentativas, resultados de validação, erros de ferramentas e sinais de qualidade separados por origem. Todos os gráficos devem permitir filtros por período, ambiente, versão, tarefa, canal e coorte, para evitar comparações entre populações heterogéneas.

Para o lançamento, selecione uma coorte de controlo ou uma linha de base anterior e defina antecipadamente as condições de ampliação, pausa e reversão. Conserve amostras de rastreios representativas, incluindo execuções bem-sucedidas, falhadas e de custo elevado. Documente alterações de tráfego, corpus, preços ou políticas que possam alterar a interpretação.

O resultado esperado não é uma explicação automática para cada incidente. É um sistema que reduz a dependência de memórias, capturas de ecrã e impressões isoladas, e que mostra explicitamente quando a evidência permite uma conclusão e quando ainda não permite.

Continue a explorar

Correções e transparência

Se encontrar informação incorreta ou desatualizada, envie-nos a página e a fonte que devemos rever.