# Avaliação, observabilidade e controlo canonical_url: https://www.3.14financialcontents.com/gl-pt/capacidades/avaliacao-observabilidade-e-controlo/ markdown_url: https://www.3.14financialcontents.com/gl-pt/capacidades/avaliacao-observabilidade-e-controlo/index.md language: pt-PT content_type: capabilities status: published description: Desenhamos evals, testes adversariais, benchmarks, simulações, validadores, rastos, métricas e mecanismos de observabilidade para modelos, agentes, sistemas de conhecimento, workflows, software e sistemas físicos. Combinamos avaliação… Medir como funciona um sistema de IA, detetar onde falha e controlar o que pode fazer. ## O que a avaliação responde - que qualidade atinge - sob que condições - face a que baseline - que erro produz - como o detetamos - que consequência tem - como se recupera - o que o sistema aprende ## Tecnologias e práticas - pytest - avaliação programática - challenge sets - revisão humana - simulação - tracing distribuído - OpenTelemetry - métricas e dashboards - logs estruturados - versionamento - feature flags - shadow mode - canary - rollback - testes HIL - testes de segurança - DSPy e GEPA com evals - avaliações próprias de domínio Uma avaliação descobre sob que condições o sistema encontra os seus limites; a observabilidade permite saber o que convém melhorar depois. Um sistema inteligente pode encontrar os seus limites em muitos sítios. A fonte pode estar desatualizada. A recuperação pode selecionar um fragmento parecido. O modelo pode interpretar mal. Uma ferramenta pode executar duas vezes. Um workflow pode perder estado. Uma interface pode apresentar uma decisão sem contexto. Uma máquina pode atuar com uma estimativa insuficiente. Avaliamos o percurso completo. A observabilidade conserva os sinais necessários para responder depois de cada execução. O controlo limita a autoridade e permite parar, rever, reverter ou escalar. ## Avaliar do resultado para trás Começamos pelo resultado esperado. Depois identificamos decisões, ações, políticas, ferramentas, modelos, recuperação, fontes e dados. Cada componente possui métricas próprias e uma relação com o resultado. Um modelo pode melhorar a precisão e aumentar a latência. Um agente pode concluir mais casos e elevar o custo. Uma automação pode reduzir passos e aumentar as exceções. A avaliação do sistema relaciona essas consequências. ## Camadas de avaliação **Informação.** Cobertura, vigência, proveniência, resolução de entidades, suporte, contradição e abstenção. **Linguagem.** Fidelidade, terminologia, omissão, adição, naturalidade, registo e coerência multiformato. **Machine learning.** Desempenho, calibração, validação temporal, custo de erro, robustez, deriva e política. **Agentes.** Resultado, seleção de ferramentas, cumprimento de políticas, estado, custo, latência, recuperação e abstenção. **Workflows.** Transição, durabilidade, novas tentativas, eventos, idempotência, compensação e conclusão. **Interfaces humanas.** Compreensão, carga, correções, tempo, qualidade de decisão e recorrência. **Software.** Contratos, testes, disponibilidade, erros, segurança e observabilidade. **Inteligência Física.** Perceção, estimação, planeamento, controlo, segurança, verificação e recuperação. ## Evals representativas Um conjunto de avaliação deve representar a utilização: casos habituais, casos difíceis, fronteiras, exceções, dados incompletos, contradições, mudanças de regime, falhas, diferentes perfis e consequências desiguais. As evals são versionadas juntamente com critério, dados, respostas de referência, revisões, severidade, cobertura e condições. As métricas automáticas complementam-se com revisão humana quando a qualidade depende de significado, critério ou contexto. ## Revisão adversarial A revisão adversarial procura refutar a afirmação de que o sistema funciona. Pergunta: - que fonte parece pertinente e não sustenta a conclusão?; - que entrada plausível quebra o esquema?; - que permissão permite uma ação indevida?; - que evento chega duas vezes?; - que caso faz com que uma métrica agregada oculte uma falha?; - que frase é fluida e muda o significado?; - que ação técnica correta deixa o resultado por produzir?; - que simulação exclui uma tolerância relevante?; - que exceção transformaria uma regra numa má política? Esta prática descobre condições antes de a operação as transformar em incidentes. ## Simulação A simulação permite reproduzir cargas, eventos, falhas, sequências, ambientes, decisões e operações físicas. Pode ser utilizada para testar workflows, comparar políticas, examinar a recuperação, estudar a sensibilidade, gerar cenários, validar o controlo e preparar HIL. A simulação conserva os seus pressupostos. O resultado indica comportamento dentro desses pressupostos. ## Observabilidade por trajetória Os rastos organizam-se por caso, pergunta, decisão ou operação. Um rasto pode relacionar: ```text ENTRADA ↓ FONTES RECUPERADAS ↓ CONTEXTO ↓ MODELO E VERSÃO ↓ DECISÃO ↓ FERRAMENTA ↓ INTERVENÇÃO ↓ AÇÃO ↓ RESULTADO ``` Cada evento inclui identificadores, tempo, estado e versão. A observabilidade permite depurar, explicar, auditar, comparar, atribuir, recuperar e otimizar. Os dados sensíveis são protegidos através de permissões, minimização e políticas de retenção. ## Evidência e rastreabilidade Uma explicação gerada pode soar convincente. A rastreabilidade mostra o percurso real. Conservamos que informação entrou, que regra foi aplicada, que modelo e configuração foram utilizados, que ferramenta atuou, que pessoa decidiu e que resultado se observou. Em inteligência informacional, a afirmação liga-se à fonte. Em inteligência operacional, a ação liga-se ao estado e ao seu efeito. ## Controlo de autoridade O sistema classifica as ações por impacto, reversibilidade, sensibilidade, custo, risco e necessidade de autoridade. Os controlos podem incluir apenas leitura, proposta, simulação, shadow mode, confirmação, autorização, limites, duplo controlo, execução delimitada, paragem e rollback. A autonomia cresce por percurso e por ação, apoiada em evidência de comportamento. ## Gating e maturidade Cada capacidade pode avançar através de gates. Exemplo: ```text F0 — REPRESENTAÇÃO VALIDADA F1 — TESTES DETERMINISTAS F2 — EVAL REPRESENTATIVA F3 — CASOS ADVERSOS F4 — INTEGRAÇÃO F5 — SHADOW MODE F6 — OPERAÇÃO DELIMITADA F7 — AMPLIAÇÃO ``` O nome e o número podem adaptar-se a cada projeto. O gate declara evidência, critério, resultado, exceções, bloqueios e autoridade de aprovação. A maturidade comunica-se como estado e âmbito. ## Recuperação O sistema prepara resposta perante saída inválida, fonte ausente, permissão insuficiente, falha de ferramenta, duplicado, timeout, evento fora de ordem, inconsistência, perda de perceção e resultado ambíguo. A recuperação pode voltar a tentar, mudar de rota, solicitar informação, reduzir o âmbito, compensar, escalar, parar ou conservar pendente. O rasto regista a falha e o estado remanescente. ## Métricas operacionais Além da qualidade técnica, observamos tempo total, tempo de espera, custo, carga humana, novas tentativas, encaminhamentos, reaberturas, conclusões verificadas, disponibilidade, estabilidade, incidentes, adoção e melhoria face à baseline. Uma métrica interpreta-se juntamente com o objetivo e as restrições. ## Aprendizagem Os resultados podem modificar dados, prompts, modelos, regras, limiares, ferramentas, interfaces, rotas, permissões e avaliações. A alteração passa por versão e teste. Uma exceção conserva-se com contexto e é analisada por recorrência, impacto e semelhança antes de se transformar em regra. ## Fecho A confiança constrói-se tornando visível o comportamento e desenhando o que deve acontecer quando o sistema encontra os seus limites. --- https://www.3.14financialcontents.com/llms-gl-pt.txt · https://www.3.14financialcontents.com/llms-full-gl-pt.txt