Opik LLM Observabilidade: pontuações de thread de auditoria antes do verde

Opik pode dizer muito sobre um agente multiturno, mas um rastro visível ou uma pontuação alta de conversação ainda não é um veredicto de saúde. O padrão razoável é usar Opik para evidências de rastreamento e avaliação e, em seguida, exigir quatro fatos adicionais antes de mostrar verde: os turnos pretendidos caíram sob uma identidade de thread, o thread era elegível para pontuação, a pontuação foi produzida após a atividade mais recente e o resultado solicitado existe em seu destino. Essa distinção é mais importante quando falta uma pontuação ou parece reconfortante. “Sem pontuação” pode significar que a conversa ainda está ativa, que a regra de amostragem a excluiu, que a pontuação está pendente ou que a pontuação foi interrompida. Uma pontuação 0.94 pode pertencer à versão anterior de um thread. Mesmo um 0.94 novo pode coexistir com um arquivo ausente, uma mensagem não enviada ou uma atualização com falha. Este guia cria um recibo sem conteúdo e reproduz dez casos contra ele. Foi verificado em relação a Opik 2.2.12 no commit do repositório c54a6a9 em 29 de julho de 2026. Não requer prompts, respostas, credenciais ou identificadores de cliente. Prove o tópico antes de julgar a pontuação Opik agrupa rastreios relacionados com um thread id definido pelo usuário. Isso é documentação de conversa fixada diz que o identificador deve ser único dentro de um projeto. Isso dá aos operadores um limite importante: uma conversa não é “qualquer linha que pareça relacionada” no painel. Antes de ler qualquer resultado do avaliador em nível de thread, registre: o espaço de trabalho e projeto que deverá receber os rastreamentos; um hash opaco ou representação não sensível do ID de thread esperado; os IDs de thread distintos observados para os turnos pretendidos; o último horário da atividade de rastreamento; o coletor ou o tempo de consulta usado para estabelecer a visibilidade. Um ID observado que corresponda ao ID esperado passa pela porta de identidade. Zero IDs é um problema de telemetria. Dois IDs para uma conversa pretendida são fragmentação, mesmo que ambos os fragmentos tenham intervalos válidos individualmente. Reutilizar o mesmo ID de fácil exibição em um projeto diferente também é um escopo de evidência diferente. Não comece culpando o avaliador quando falta um traço. Opik guia de configuração SDK fixado lote de documentos nos controles TypeScript SDK e client.flush() e flushAll() explícitos. Uma liberação concluída é uma prova de entrega útil, mas ainda não prova que o coletor aceitou o lote ou que a consulta está lendo o projeto pretendido. Confirme a visibilidade após o limite nivelado. Esta ordem evita um erro de diagnóstico comum: Trate o resfriamento e a amostragem como elegibilidade, não como falha A avaliação online em nível de thread é intencionalmente assíncrona. Opik documenta um resfriamento padrão de 15 minutos após a última atividade antes de um thread ser pontuado. O valor pode ser alterado nas configurações do espaço de trabalho ou por meio da configuração documentada do ambiente auto hospedado. O mesmo documentação fixada explica que o atraso tem como objetivo permitir que toda a conversa se resolva. Portanto, now last activity at < configured cooldown está ativo , e não atrasado. O agente pode estar trabalhando, aguardando a vez de um usuário legítimo ou simplesmente dentro da janela de observação. A paginação no minuto cinco, quando a política registrada é de 15 minutos, produz um incidente. A amostragem cria um segundo caminho sem falhas. Uma regra online Opik tem uma taxa de amostragem explícita junto com seu modelo, prompt, mapeamento de variável e definição de pontuação. Se um recibo indicar que um encadeamento não foi selecionado, o estado correto será coverage excluded . Não é scoring overdue . Para threads selecionados, adicione um período de carência de pontuação separado após o resfriamento. Esse período de carência é o seu SLO operacional, não uma garantia Opik: Entre esses momentos, mantenha o veredicto scoring pending . Após overdue at , inspecione logs de regras, credenciais do avaliador, disponibilidade do modelo, limites de taxa e integridade da fila. Isso cria um limite de alerta claro sem confundir atividade legítima com um avaliador com falha. O recibo precisa preservar a política que produziu a decisão. Armazene o tempo de espera configurado real, a versão da regra, a decisão de amostragem, o nome do avaliador e o período de carência com a classificação. Se o tempo de espera mudar de 15 para 30 minutos, os eventos históricos deverão permanecer explicáveis, em vez de adquirirem silenciosamente um novo significado. Uma pontuação visível ainda pode estar obsoleta Nova atividade altera a versão da evidência. Opik documentação de thread de conversa diz que adicionar um rastreamento preserva as pontuações de feedback existentes, reinicia o tempo de espera e executa novamente a avaliação on line após o novo tempo de espera. A preservação é útil para a continuidade, mas cria um risco temporário de verde obsoleto. Use esta regra: Se a pontuação visível for anterior à curva mais recente, classifique a como score stale independentemente do seu valor. Aguarde a nova execução ou avalie explicitamente a última revisão do thread. Não calcule a média da pontuação antiga em verde e não a apague; retenha o como evidência sobre um estado anterior do thread. O frescor é necessário, mas não suficiente. Opik armazena resultados de avaliação on line como pontuações de feedback e suas regras de thread podem julgar uma conversa inteira. O documentação de regras fixadas também descreve coerência de conversação, frustração do usuário e métricas personalizadas, incluindo acesso ao caminho de execução quando o modelo selecionado suporta chamada de ferramenta. Esses são resultados de avaliação. Eles respondem à pergunta codificada na métrica. Eles não provam automaticamente a existência de um efeito colateral externo ou produto final. Suponha que um agente de suporte receba uma pontuação alta de relevância e coerência após dizer que atualizou um ticket. A evidência do tópico pode apoiar “a conversa foi coerente” e talvez “a chamada de ferramenta esperada apareceu”. Somente o sistema de tickets pode provar que o ticket pretendido agora contém a alteração limitada pretendida. A porta final deve consultar esse destino usando uma chave de correlação não sensível e comparar o resultado com uma regra de aceitação determinística. Isso produz três decisões distintas: pontuação recente abaixo do limite: quality alert ; pontuação aceitável recente sem recibo de destino: outcome unverified ; nova pontuação aceitável mais um recibo de destino correspondente: verified . A ordem é deliberada. Um recibo de destino não torna saudável uma conversa ruim, e uma boa pontuação de conversa não cria o resultado de destino. Repita a auditoria dos dez estados O acessório opik thread score audit.mjs que acompanha não contém conteúdo de conversação. Cada caso fornece apenas visibilidade, identidade esperada e observada, última atividade, seleção de amostragem, pontuação e tempo de pontuação e um recibo de destino booleano. A política de exemplo usa o tempo de espera padrão documentado de 900 segundos, uma tolerância de pontuação de 300 segundos escolhida localmente e um limite de demonstração de 0.7 . A precedência de estado é mais fácil de aplicar como uma lista de decisões seguras para dispositivos móveis: 1. telemetry missing : o rastreamento pretendido não está visível. Verifique a atualização do flush, do coletor, do projeto e da consulta. 2. thread fragmented : os IDs observados não são iguais a um ID esperado. Repare a propagação antes de julgar. 3. active : a atividade mais recente está dentro do tempo de espera. Deixe isso em paz. 4. coverage excluded : o encadeamento elegível não foi amostrado. Cobertura recorde; não paginar. 5. scoring pending : o encadeamento selecionado é elegível, mas está dentro da graça. Mantenha o desconhecido e espere. 6. scoring overdue : o tópico selecionado está além da graça sem pontuação. Inspecione o caminho do avaliador. 7. score stale : o tempo de pontuação é anterior à atividade mais recente. Avalie a última revisão. 8. quality alert : uma nova pontuação está abaixo do limite escolhido. Revise as evidências com autoridade limitada. 9. outcome unverified : a pontuação é recente e aceitável, mas não há recibo de destino. Verifique o resultado real. 10. verified : identidade, tempo, pontuação e resultado, todos aprovados. Guarde os recibos. Execute o artefato em seu diretório: A reprodução fixa retorna dez estados esperados diferentes e sai diferente de zero se algum caso mudar inesperadamente. Vale a pena comparar dois casos: O primeiro tem pontuação 0.94 , mas a pontuação é anterior ao rastreamento mais recente. O segundo tem um 0.91 novo, mas nenhum recibo de destino. Apenas o terceiro possui um thread estável, avaliação atual concluída, pontuação aceitável e saída verificada. Adapte o dispositivo substituindo os recibos sintéticos por uma exportação com conteúdo minimizado do seu ambiente. Identificadores de hash se igualdade for tudo que você precisa. Mantenha textos de prompt, respostas, cargas de ferramentas, segredos e caminhos locais absolutos fora do fluxo de integridade. Defina a tolerância de pontuação e o limite de qualidade a partir dos dados de latência e calibração do seu próprio avaliador; nenhum dos valores é fornecido como padrão universal Opik. Use uma regra operacional calma Para observabilidade Opik LLM, a regra prática é: Não interprete uma pontuação de thread até que os rastreamentos pretendidos formem um thread atual e a política de pontuação indique que esse thread era elegível. Não apague a execução até que a pontuação seja mais recente que a última atividade e o resultado solicitado seja verificado de forma independente. Esta regra preserva a espera legítima, torna a amostragem visível e evita alarmes de pontuação perdida e estados verdes de pontuação obsoleta. Ele também mantém os limites honestos: Opik fornece rastreamento valioso e evidências de avaliação; seu destino fornece o recibo do resultado. A auditoria tem limites. Ele não testa a calibração do avaliador, a qualidade do prompt, a correção semântica, a integridade do provedor ou a disponibilidade de uma implantação Opik em tempo real. Uma máquina de estado sem conteúdo não pode decidir se 0.7 é o limite correto para sua tarefa. Calibre os juízes em relação a rótulos determinísticos e humanos, registre incertezas e mantenha um caminho de revisão humano para decisões importantes. A Sidewisp está atualmente em prévia privada. Sua camada de integridade planejada tem como objetivo colocar evidências, atualização, estados de espera e resultados verificados em uma visualização do operador, mas este artigo não implica que um adaptador Opik ou mecanismo de monitoramento de produção seja enviado hoje. Fontes primárias Documentação de conversação e identidade de thread Opik, fixada no commit revisado Regras de avaliação on line Opik, fixadas no commit revisado Configuração Opik SDK e controles de liberação, fixados no commit revisado