Reprodutibilidade e o projeto ponta a ponta: combinando tudo

Ganhos:

• Capacidade de garantir a reprodutibilidade com quatro pilares (fixação de sementes, controle de versão de dados, congelamento de mídia, monitoramento de experimentos) e produzir o mesmo resultado ao repetir a mesma execução
• Capacidade de combinar todas as etapas do módulo (métricas, dados, modelo, componentes LLM, avaliação, justiça, segurança, distribuição, monitoramento) em uma cadeia ponta a ponta
• Capacidade de verificar se a decisão crítica permanece com o ser humano em cada parada e documentar o projeto de maneira auditável

A falha mais insidiosa de um projeto de ML não é uma falha; "Não obtendo o mesmo resultado novamente." Se você não consegue reproduzir hoje a pontuação do modelo que colocou em produção há três meses, você não controla realmente esse modelo. Nesta unidade final, aprofundamos a reprodutibilidade: a capacidade de obter de forma confiável o mesmo resultado com as mesmas entradas e combinar todo o módulo em uma disciplina de projeto de ponta a ponta.

Por que a reprodutibilidade é difícil

No software comum, o mesmo código fornece a mesma saída. No ML existem muito mais variáveis que determinam o resultado:

• Aleatoriedade: embaralhamento de dados, inicialização de peso, divisão de dados – tudo depende de aleatoriedade.
• Dados: o mesmo código produz modelos diferentes com versões de dados diferentes.
• Ambiente: Versões da biblioteca, hardware (CPU/GPU) e até mesmo sistema operacional podem alterar o resultado.
• Caso oculto: um hiperparâmetro não salvo, uma etapa de pré-processamento manual, uma seleção não anotada.

A reprodutibilidade não é um “bom ter”, mas um imperativo científico e de engenharia. Um resultado que não pode ser reproduzido é uma afirmação que não pode ser provada.

Quatro pilares da reprodutibilidade

1. Corrija a aleatoriedade. Defina todas as sementes aleatórias em um só lugar: divisão de dados, inicialização do modelo, embaralhamento de dados. A semente fixa é a base da garantia de “mesmo resultado quando você repete a mesma corrida”.

2. Versão dos dados. Registre com qual versão de dados cada experimento foi realizado (versão de dados na unidade 2). “Dados mais recentes” são vagos; "versão de dados v3, hash abc123" é exato.

3. Congele o meio. Fixe todas as dependências em suas versões exatas (por exemplo, versões exatas como numpy==1.26.4 em requisitos.txt ou uma imagem de contêiner). A “versão mais recente” um dia quebrará tudo.

4. Acompanhe tudo (rastreamento de experimentos). Salve automaticamente para cada experimento: versão do código (git commit), versão dos dados, todos os hiperparâmetros, métricas e estruturas de saída. Ferramentas de rastreamento de experimentos como MLflow, Weights & Biases fazem isso sistematicamente. Sem registro, a pergunta “qual configuração foi melhor” permanece sem resposta.

Cuidado: “Lembrarei mais tarde” é a falácia mais cara. Duas semanas depois você não se lembrará de qual seed, quais dados, qual hiperparâmetro você usou. O rastreamento automático elimina a dependência da memória.

Abordagem fraca/abordagem forte

Fraco: “Encontrei o melhor modelo, está no notebook, acho que a pontuação foi de 89%.”

Forte: "Execute #147 na ferramenta de rastreamento de experimentos: git commit a3f9c, versão de dados v3 (hash abc123), seed 42, todos os hiperparâmetros registrados, teste PR-AUC 0.887. Quando executo o mesmo comando novamente, obtenho o mesmo resultado pouco a pouco. O modelo depende desta execução no registro."

A diferença: na abordagem forte o resultado não se baseia em uma memória, mas em uma cadeia fixa e monitorada. Todos podem produzir o mesmo resultado sempre.

Projeto ponta a ponta: combinação de módulo

Agora vamos combinar todo o módulo em um único fluxo de projeto. Um sistema de ML real passa por essas paradas, e cada parada se baseia na anterior:

1. Definição do problema: O que estamos resolvendo, como medir o sucesso (unidade 3: métrica certa, contexto empresarial). A métrica e o limite são claros desde o início.
2. Pipeline de dados: Coleta, validação, limpeza, particionamento sem vazamentos, versionamento (unidade 2).
3. Desenvolvimento de modelo: Treinamento, comparação de linha de base, validação cruzada, hard seed (unidade 3 + esta unidade).
4. Componentes do LLM (se aplicável): RAG (unidade 4) e/ou agentes (unidade 5); ajuste fino se necessário (unidade 6).
5. Avaliação: cluster de avaliação com casos de borda e segurança, avaliação multicamadas em sistemas LLM (unidade 8).
6. Auditoria de justiça e ética: análise de subgrupos, cartão modelo, explicabilidade (unidade 10).
7. Auditoria de segurança: Injeção imediata, privacidade, cadeia de suprimentos (unidade 9).
8. Distribuição: Embalagem, distribuição gradual, rollback, registro de modelo (unidade 7).
9. Monitoramento: Monitoramento de três camadas, alarmes de desvio (unidade 8).
10. Reprodutibilidade: Semente, versão de dados, mídia e rastreamento de experimentos em toda a cadeia (esta unidade).

Neste fluxo, a IA é um acelerador e gerador de blueprint em cada parada; mas a seleção de métricas, decisões de dados, priorização de justiça, limite de implantação e aprovação de lançamento – as decisões críticas permanecem com o ser humano. Esta é a essência do módulo.

Documentação: o futuro agradecerá

Um bom projeto de ML se documenta. No mínimo, o seguinte deve ser escrito: critérios de problema e sucesso, fonte e versão dos dados, seleções e justificativas de modelos, resultados da avaliação (incluindo subgrupos), limites e riscos conhecidos, procedimento de implantação e recuperação, plano de monitoramento. Este documento é o melhor amigo da pessoa (talvez você) que retorna ao projeto após seis meses.

três mini cases

Caso 1 - Resultado perdido. Um engenheiro treinou um ótimo modelo, mas não corrigiu a semente e não salvou a versão dos dados. Quando ele deixou o emprego, ninguém conseguiu reproduzir aquele resultado; o modelo se tornou uma "lenda da caixa preta" e acabou sendo construído do zero. Semanas foram desperdiçadas. Lição: um resultado não reproduzível é um resultado inexistente.

Caso 2 – Colapso ambiental. Uma equipe não corrigiu as dependências. Quando uma biblioteca era atualizada automaticamente, os resultados do modelo mudavam silenciosamente e a produção era interrompida. Demorou dias para encontrar o problema. Quando as dependências foram congeladas e conteinerizadas com as versões definitivas, o problema não ocorreu novamente. Lição: congele o meio ambiente.

Caso 3 – O poder do monitoramento. Uma equipe monitorou automaticamente cada experimento. Três meses depois, durante uma auditoria regulatória, responderam à pergunta “com quais dados, com quais configurações, que desempenho obteve em quais grupos?” com uma gravação completa em poucos minutos. A inspeção correu bem. Lição: o monitoramento é uma ferramenta de conformidade, não apenas de engenharia.

Modelos copiáveis

Faça uma verificação de reprodutibilidade para este projeto de ML. - Todas as sementes de aleatoriedade são fixas (dividir, inicializar, embaralhar)? - Os dados são versionados? - As dependências são congeladas para versões exatas? Escreva etapas concretas sobre como corrigi-lo para cada coluna ausente.Estrutura do projeto: [descrição]

Produza um esqueleto de plano para este projeto de ML completo. Problema: [descrição] Cubra as seguintes paradas e marque onde está a decisão HUMANA em cada parada: problema/métrica, pipeline, modelo, (RAG/agente/ajuste fino?), avaliação, imparcialidade, segurança, distribuição, monitoramento, reprodutibilidade. Escreva o principal risco e etapa de verificação para cada parada.

Produza um modelo de documentação técnica para este projeto. Seções: problema+critérios de sucesso, dados (fonte+versão), seleções de modelo+justificativa, avaliação (incluindo subgrupos), limites conhecidos+riscos, implantação+reversão, plano de monitoramento. Forneça os campos a serem preenchidos para cada seção como perguntas.

Verifique a configuração de monitoramento do meu experimento: ele é salvo automaticamente em cada execução: git commit, versão/hash dos dados, todos os hiperparâmetros, todas as métricas, ambiente (versões da biblioteca)? Obtenho o mesmo resultado quando executo a mesma execução novamente? Configuração: [descrição]. Liste as falhas e corrija.

Tabela de colunas de reprodutibilidade

coluna

O que é fixo

Exemplo de veículo

aleatoriedade

todas as sementes

configuração de sementes

Dados

Versão/hash dos dados

DVC

meio ambiente

Versões da biblioteca

pino de requisitos, Docker

Monitoramento

Código+dados+configuração+métrica

MLflow, W&B

Erros comuns

• Não consertar a semente. O resultado não pode ser repetido.
• Não salvando a versão dos dados. “Com que dados?” permanece sem resposta.
• Não congelar vícios. Uma atualização quebrará tudo silenciosamente.
• Deixando experimentos na memória. Duas semanas depois, nada é lembrado.
• Deixando decisões críticas para a inteligência artificial. As decisões sobre métricas, justiça e distribuição devem permanecer com as pessoas.
• Adiamento de documentação. A futura equipe (e você) paga o preço.

Em resumo

A reprodutibilidade é a assinatura da engenharia séria de ML: o resultado não reproduzível é a afirmação improvável. Ele vem com quatro colunas – corrigir aleatoriedade, versão de dados, congelar ambiente, rastrear cada experimento. Um projeto ponta a ponta combina todas as etapas deste módulo (métrica, dados, modelo, componentes LLM, avaliação, justiça, segurança, distribuição, monitoramento) em uma cadeia interconectada; A inteligência artificial é um acelerador em cada parada, mas as decisões críticas permanecem com o ser humano. Documente tudo – para futuras equipes e auditorias. Esta disciplina é a estrutura que sustenta tudo o que você aprende ao longo do módulo.

Tarefa de aplicativo

Verifique um projeto de ML em relação a quatro pilares de reprodutibilidade: as sementes são imutáveis, os dados são versionados, o ambiente está congelado, os experimentos são rastreados? Corrija todas as colunas ausentes e prove que você pode executar a mesma execução duas vezes e obter o mesmo resultado. Em seguida, imprima o fluxo ponta a ponta do projeto (10 paradas) em uma página e marque “onde está a decisão humana” em cada parada. Por fim, escreva um breve rascunho de documentação técnica.

lista de verificação

• [] Todas as sementes de aleatoriedade foram corrigidas.
• [] A versão/hash dos dados é registrada com cada experimento.
• [] As dependências são congeladas em versões firmes (pino/contêiner).
• [ ] Cada experimento é monitorado automaticamente (código+dados+configuração+métrica).
• [] Quando repito a mesma execução, obtenho o mesmo resultado.
• [ ] Verifiquei e documentei que decisões críticas no fluxo ponta a ponta são tomadas por humanos.

Exame do Módulo

1. Como engenheiro de ML, qual é a melhor abordagem ao posicionar a inteligência artificial no fluxo de trabalho?

• A) A IA é um acelerador em negócios de baixo risco; Decisões críticas como métricas, dados e produção permanecem validadas e deixadas para o ser humano ✔
• B) Desde que os resultados da IA pareçam bons, não há necessidade de verificação
• C) Deixar a decisão de colocar o modelo em produção para a inteligência artificial economiza tempo.
• D) A inteligência artificial só é útil para escrever texto, não tem nada a ver com dados e trabalho de modelo

Descrição: IA é um acelerador poderoso para tarefas de baixo risco e facilmente verificadas, como código, resumos de dados e documentos; No entanto, a responsabilidade pelas decisões que afetam dinheiro, confidencialidade e responsabilidade legal, como a seleção de métricas, quais dados vão para o treinamento e a colocação do modelo em produção, cabe ao engenheiro e à equipe qualificados. Cada saída não deve ser usada sem verificação.

2. Por que a validação do esquema é colocada no início de um pipeline de dados?

• A) Porque aumenta diretamente a precisão do modelo
• B) Porque torna desnecessário o versionamento de dados
• C) Porque ele detecta dados corrompidos o mais cedo e mais barato e evita que vazem para as próximas etapas ✔
• D) Porque elimina a necessidade de rotulagem

Explicação: Quanto mais cedo os dados corrompidos forem detectados, mais barato será corrigi-los. A validação do esquema evita que dados corrompidos vazem silenciosamente para o treinamento ou produção, rejeitando dados fora do tipo e intervalo esperados no início da linha (por exemplo, mudança de preço 100x com mudança de unidade); O mesmo erro detectado na produção é muitas vezes mais caro.

3. Qual a abordagem correta ao dividir os dados em treinamento e teste em um problema que envolve tempo (série temporal)?

• A) Usando divisão aleatória porque é sempre o método mais justo
• B) Usando divisão temporal: evite vazamentos treinando com o passado e testando no futuro ✔
• C) Usando todos os dados como treinamento e teste
• D) Incorporação de dados de teste em parâmetros de escala antes do treinamento

Explicação: A divisão aleatória em séries temporais dá ao modelo uma vantagem de “visão do futuro” que nunca acontecerá na produção e inflaciona artificialmente as métricas (vazamento temporal). O correto é a divisão temporal: treinar com o passado, testar no futuro. Isso mede o desempenho real que o mantém em produção.

4. Por que a precisão é enganosa em um modelo de detecção de fraude com uma taxa de classe positiva de 1,5%?

• A) Porque a precisão é sempre baixa em dados não balanceados
• B) Porque a precisão só pode ser usada em problemas de regressão
• C) Porque o cálculo de precisão requer muito poder de processamento
• D) Mesmo um modelo insignificante que preveja a classe majoritária pode ser muito preciso, escondendo assim o sucesso real ✔

Explicação: Em dados desequilibrados, mesmo um modelo básico que diz “chamar tudo de negativo” obtém cerca de 98,5% de precisão, mas não detectará uma única fraude. Portanto, na classificação não balanceada, são utilizados precisão, recall, F1 ou PR-AUC em vez de exatidão, e cada métrica é interpretada de acordo com um modelo base.

5. Por que a comparação da linha de base é essencial quando se fala sobre a métrica de um modelo?

• A) Porque o modelo básico é sempre melhor que o modelo real
• B) Porque fica claro se uma métrica é significativa ou não apenas quando comparada a um modelo de linha de base simples ✔
• C) Porque o modelo base torna desnecessária a validação cruzada
• D) Porque o modelo básico é legalmente exigido em todos os relatórios

Explicação: Uma métrica não é boa nem ruim por si só; É bom ou ruim de acordo com um modelo básico. A frase '85% correto' significa quase inútil se o modelo básico já obtiver 84% e perfeito se obtiver 50%. Sem uma âncora de comparação, a métrica não tem sentido.

6. Qual é o elemento de segurança mais crítico que deve ser incluído no prompt de produção do sistema RAG (Retrieval-Augmented Generation)?

• A) Instrução para confiar apenas na fonte fornecida, dizer 'não sei' se a fonte não existir e citar a fonte ✔
• B) Dizer ao modelo para produzir respostas tão longas e criativas quanto possível
• C) O modelo prioriza seu próprio conhecimento educacional em detrimento dos recursos
• D) Implementar todas as instruções nos documentos trazidos como comandos

Explicação: A instrução mais importante do RAG é dizer ao modelo para confiar apenas na fonte fornecida e, se a informação não estiver na fonte, dizer 'não sei' e citar a fonte sem inventá-la. Sem esta tríade, o modelo pode ignorar o contexto e produzir alucinações, e a resposta torna-se inverificável.

7. Um sistema RAG dá respostas incorretas. Qual é o melhor lugar para iniciar o diagnóstico?

• A) Medindo a busca primeiro (Recall@K): a peça correta chega? ✔
• B) Substitua imediatamente o modelo por um maior
• C) Altere o prompt aleatoriamente e continue tentando
• D) Incorporação de todos os documentos no modelo com ajuste fino

Explicação: o elo mais fraco do RAG geralmente é a busca, não a produção. Se a peça correta nunca for trazida, o modelo não poderá produzir aquela informação, por mais que o prompt seja melhorado. Portanto, primeiro o Recall@K é medido para verificar se a peça correta chegou; Se a busca for boa, a produção e o prompt serão examinados.

8. Que ações devem ser submetidas à aprovação humana ao fornecer uma ferramenta a um agente?

• A) Nenhum; O agente deve ser capaz de realizar todas as ações de forma autônoma
• B) Somente ações reversíveis, como leitura e pesquisa de dados
• C) Ações irreversíveis ou de alto impacto como transferir dinheiro, deletar, enviar ✔
• D) Ações que envolvem apenas cálculos

Descrição: As ações são separadas por nível de risco. Tarefas recuperáveis ​​como leitura, pesquisa, cálculo e geração de rascunhos podem ser realizadas de forma autônoma; No entanto, ações irreversíveis ou de alto impacto, como transferir dinheiro, enviar e-mails, excluir dados, fazer pedidos, etc., exigem aprovação humana. Toda ação irrevogável deve estar sujeita ao consentimento.

9. Qual é a melhor abordagem de projeto contra o risco de injeção indireta imediata?

• A) Basta adicionar uma única frase 'ignorar instruções incorretas' ao prompt do sistema
• B) Dê mais autoridade ao modelo confiando em instruções de conteúdo externo
• C) Não tomar quaisquer precauções porque a injeção é inevitável
• D) Isolar conteúdo externo como dados não confiáveis e estabelecer defesas em camadas com autorização, aprovação e controle de saída mínimos ✔

Descrição: O conteúdo externo processado pelo agente ou RAG, como página da web, documento, e-mail, etc., são dados não confiáveis ​​e podem conter instruções secretas. A abordagem correta é a defesa em camadas: isolar o conteúdo externo como “dados, não comandos” com delimitadores claros, aplicar autorização mínima, vincular ações irreversíveis à aprovação humana e auditar a saída. Uma única linha de instruções não é suficiente.

10. Qual é a principal distinção ao decidir se um problema deve ser resolvido com ajuste fino ou RAG?

• A) Problemas de informação são melhor resolvidos com RAG, problemas de comportamento/formato são melhor resolvidos com ajuste fino ✔
• B) Todo problema deve sempre ser resolvido por meio de ajustes finos
• C) RAG é usado apenas para geração de código, o ajuste fino é usado apenas para tradução
• D) O ajuste fino sempre pode ser atualizado de forma mais barata e rápida que o RAG

Explicação: O ajuste fino é fraco e arriscado para ensinar novas informações ao modelo; mas é poderoso no ensino de comportamento, formato, tom e estilo. ‘A empresa modelo não conhece os nossos dados’ é um problema de informação e pertence à RAG. 'Deixe o modelo sempre produzir em nosso formato estrito' é um problema comportamental e um candidato para ajuste fino. Além disso, alguns disparos rápidos e rápidos devem ser consumidos antes do ajuste fino.

11. O que é obrigatório para uma implantação segura ao colocar um novo modelo em produção?

• A) Se o modelo for bom em testes, abra-o diretamente para 100% do tráfego
• B) Não configurar o monitoramento após a implantação
• C) Implantação em fases (sombra/canário) e um plano de reversão pré-testado ✔
• D) Publicar o modelo mesmo que o limite de avaliação não seja atingido

Explicação: Abrir o novo modelo diretamente a todo o tráfego é arriscado; Se estiver errado, todos serão afetados. O correto é que seja uma distribuição gradual (sombra, canário) e toda distribuição tenha um plano de rollback testado. Uma distribuição não está completa sem um plano de recuperação; Ser capaz de reverter para a versão anterior em minutos protege o usuário quando o modelo se comporta de forma inesperada na produção.

12. Como um modelo de ML pode falhar “silenciosamente” na produção e qual é a maneira de detectar isso?

• A) O modelo entra em colapso; logs do servidor mostram isso
• B) Produzindo previsões erradas sem cometer erros; ✔ Captura monitoramento operacional, em camadas de entrada e saída
• C) O modelo nunca pode falhar silenciosamente, sempre alarma
• D) Apenas monitorar a latência é suficiente para detectar qualquer degradação

Explicação: O modelo pode falhar simplesmente por produzir previsões incorretas sem travar ou apresentar erros; A principal razão para isso é o desvio de dados e de conceito. Apenas monitorar as métricas operacionais (latência, taxa de erro) não é suficiente; a distribuição de insumos e a distribuição de resultados/previsão também devem ser monitoradas. O desvio de entrada fornece um aviso antecipado se o resultado real for atrasado.

13. Qual princípio é essencial ao usar o LLM como juiz para avaliar um sistema LLM?

• A) O árbitro LLM está sempre correto, a verificação humana é desnecessária
• B) O árbitro deve tomar uma decisão baseada apenas no comprimento da resposta.
• C) Controles baseados em regras e avaliação humana devem ser completamente descartados quando árbitros são usados
• D) As pontuações dos juízes devem ser calibradas com uma amostra rotulada por humanos e seu viés medido antes que possam ser confiáveis ✔

Descrição: O árbitro LLM também é um modelo; Pode ser alucinatório, tendencioso (favorecendo respostas longas e confiantes) e inconsistente. Portanto, as pontuações dos árbitros devem ser calibradas com uma amostra rotulada humana e seu viés sistemático deve ser medido antes que a decisão de produção seja tomada. Um árbitro não verificado dá falsa confiança.

14. Por que a análise da precisão geral é inadequada ao avaliar o viés do modelo?

• A) A precisão geral é suficiente porque sempre reflete o desempenho do pior grupo
• B) A precisão geral por si só é insuficiente, pois pode obscurecer a diferença sistemática (discriminação oculta) entre subgrupos ✔
• C) Porque a precisão é uma métrica que não tem nada a ver com preconceito
• D) O viés vem apenas do modelo e não tem nada a ver com os dados.

Explicação: A precisão geral pode ocultar diferenças sistemáticas entre subgrupos. Por exemplo, embora a precisão global seja de 88%, a recordação pode ser de 91% num grupo e de 67% noutro grupo; O modelo falha sistematicamente nesse grupo. Portanto, o modelo deve ser avaliado com base em subgrupos (demográficos/segmento) e qual definição de justiça deve ser priorizada deve ser decidida com as partes interessadas.

15. Quais são as quatro coisas que devem ser corrigidas para que um resultado de ML seja reproduzível?

• A) Apenas nome do modelo, tamanho, preço e data de lançamento
• B) Apenas marca GPU e velocidade da internet
• C) Apenas a pontuação final de precisão do modelo; o resto pode ser guardado na memória
• D) Semente de aleatoriedade, versão de dados, ambiente (versões de dependência) e rastreamento de experimento ✔

Descrição: A reprodutibilidade é alcançada por meio de quatro pilares: correção de sementes de aleatoriedade, versionamento de dados (versão/hash), congelamento do ambiente (versões/contêiner exatos da biblioteca) e rastreamento de cada experimento (confirmação de código, dados, hiperparâmetro, métrica). Sem esta cadeia não é possível reproduzir o mesmo resultado; Um resultado não reproduzível é uma afirmação que não pode ser provada.