Eu Ficava Tentando Consertar o Modelo. O Problema Era a Luz.

O primeiro número que coloquei no quadro branco para esta construção foi 97 por cento. O segundo foi 14.

Eles descrevem o mesmo modelo. No exemplo de estampagem da nossa pesquisa, um modelo de visão validado com 97% de acurácia no laboratório vai para uma prensa de matriz progressiva de 200 toneladas rodando a 40 golpes por minuto e começa a rejeitar falsamente 14% das peças boas. Nada dentro do modelo mudou. As entradas mudaram: o brilho das luzes de teto do galpão que se desloca com o ângulo do golpe, o lubrificante se acumulando de forma diferente em matrizes quentes do que em frias, as primeiras 50 peças de cada turno feitas antes de a prensa atingir o equilíbrio térmico. A física da linha tirou as imagens da distribuição em que o modelo foi validado, e nenhum modelo, em qualquer acurácia, é confiável lá fora.

Passei o último trecho deste projeto construindo uma demo para levar essa frase a sério. Chama-se Inspection Trust Gate, e você pode vê-la decidir, peça a peça, em veriprajna.com/pt-BR/demos/inspecao-de-qualidade-com-ia-de-borda-inspection-trust-gate. Não é um modelo de defeito melhor. É a camada de runtime entre o modelo de visão e o atuador de rejeição do CLP, e sua única tarefa é decidir, para cada peça, se o veredito do modelo é seguro de acionar.

O que segue é a história da construção através dos três momentos que mudaram como penso sobre IA de inspeção: um evento de deriva às 06:00 programadas, um número de benchmark que me recusei a acreditar, e uma regra que quase deletei.

A correção não é um modelo melhor

Resisti a essa frase por mais tempo do que deveria. Quando um detector se comporta mal, cada instinto que tenho como construtor diz para retreiná-lo, atualizar o backbone, comprar mais rótulos. A pesquisa se recusou a cooperar. Sistemas AOI de prateleira rejeitam falsamente de 5 a 15% das peças boas, e os bem ajustados ficam abaixo de 2%, o que a nossa página de solução chama de "um problema de calibração e de dados, não um problema de arquitetura de modelo". A mesma pesquisa relata que 84% dos projetos de integração de sistemas fracassam ou fracassam parcialmente, e que em uma implantação típica de inspeção o trabalho de integração é 60% do cronograma do projeto enquanto o treinamento do modelo é 15%. A linha que eu ficava relendo: "O hardware é uma ordem de compra."

Então fiz algo que pareceu levemente herético: tornei o modelo de defeito da demo deliberadamente sem nada de extraordinário. É uma distância kNN até textura conhecida como boa, um substituto PatchCore-lite, e marca um AUROC de 0,845 separando peças boas limpas das defeituosas no conjunto de teste held-out do MVTec AD metal_nut (fotografias reais de peças manufaturadas reais, rótulos públicos). Não estou escondendo esse número e não o estou vendendo. Em produção, aquele slot segura seu pipeline NVIDIA Metropolis, seu sistema Cognex, seu modelo customizado, atrás de uma interface fixa. O produto é a camada em torno do motor, não o motor.

A camada começa com uma pergunta que nenhuma métrica de acurácia responde: esta imagem está dentro das condições de captura em que o modelo foi validado? O EnvelopeDetector da demo calcula uma distância de Mahalanobis no espaço de sinais físicos (exposição, contraste, faixa dinâmica, um proxy de foco, detalhe de alta frequência, desvio de cor térmico, saturação, fração de brilho), ajustado nas 220 imagens de treinamento conhecidas como boas e nada mais. Quando uma peça cai fora desse envelope validado, o gate deixa de confiar inteiramente na saída do modelo, por mais confiante que o modelo se sinta a respeito.

Mesmo um modelo perfeito só é válido em entradas dentro do seu envelope validado.

Essa é a frase em que toda a construção se apoia. A deriva é uma falha de entrada, não uma falha de modelo, e uma falha de entrada nunca aparece no seu painel de acurácia. Aparece na sua caçamba de refugo.

O que acontece às 06:00?

O momento em que mais confio em toda a demo é um carimbo de tempo. O app reproduz um turno scriptado determinístico na estação "Line 3 - metal_nut press," transmitindo fotografias reais do MVTec AD metal_nut por todo o pipeline. Em certo ponto, um marcador atravessa a tela: "SHIFT CHANGE 06:00 - cold dies, bay lights on." Então 12 peças boas chegam corrompidas com brilho, desfoque e desvio térmico. Quero ser preciso sobre o que isso é: as fotografias são reais, a deriva é corrupção honesta de imagem aplicada a elas, e o app rotula como tal. Eu não tinha uma linha de estampagem para filmar, e fingir o contrário envenenaria o ponto inteiro.

O que acontece em seguida é a razão pela qual a demo existe. O monitor de envelope fica vermelho. O gate lê cada peça sob deriva como fora do envelope validado e se recusa a deixar o veredito do modelo tocar o atuador. Veredito após veredito volta HOLD, roteado para a fila de escalonamento para um humano, enquanto o painel ao lado mostra o que um AOI ingênuo sem verificação de envelope teria feito com a mesma imagem: REJECT.

Na primeira vez que vi a fila encher, cliquei numa peça retida esperando ver uma desculpa vaga de "anomalia detectada". Em vez disso, o monitor de envelope decompôs a violação sinal a sinal, porque eu o tinha construído a partir de medições físicas em vez de embeddings, e medições físicas conseguem se explicar. Numa peça sob deriva, o brilho fica a 7,6 sigma do ajuste validado e carrega 87,1% da distância de Mahalanobis ao quadrado. Isso não é um modelo tendo uma sensação. É uma leitura de instrumento.

Ao fim da fase de deriva o placar é duro. A linha de base ingênua rejeitou automaticamente 12 peças boas. O Trust Gate rejeitou automaticamente zero, retendo todas para revisão. As mesmas imagens, o mesmo modelo de defeito substituto, os mesmos limiares no escore de defeito. A única diferença é que um caminho verificou a entrada antes de confiar na saída.

A linha de base ingênua e o gate viram as mesmas peças e o mesmo modelo. A única diferença foi a permissão de acionar.

Sobre aquela cifra em dólares, porque é aqui que as demos geralmente começam a mentir: o painel extrapola a taxa medida de falsa rejeição da linha ingênua para um turno completo (40 golpes por minuto durante 8 horas são 19.200 peças) a US$ 2,42 por peça descartada. Os US$ 2,42 são uma ordem de magnitude com fonte, ancorada a um caso publicado de fabricante de cookies em que uma redução de 8,7% no desperdício por refugo economizou US$ 94 mil por ano e 38.800 kg de produto. Não é o número de um cliente, e o contador está rotulado como projeção em todo lugar em que aparece. Eu medi as falsas rejeições; projetei os dólares; a UI diz qual é qual.

Mais uma coisa que verifiquei antes de acreditar na minha própria história de deriva: peças defeituosas injetadas durante a fase de deriva ainda são capturadas ou escalonadas, nunca aprovadas automaticamente. Em todo o conjunto held-out essa figura é 93 de 93. Reter peças boas não vale nada se peças ruins passam no caos.

Minha verificação de envelope estava corrigindo a própria lição de casa?

O número de benchmark de que mais desconfiei foi o meu próprio melhor. Quando rodei o script do bench pela primeira vez, o detector de envelope separou imagens sob deriva das limpas de forma essencialmente perfeita. Minha reação imediata não foi orgulho. Foi suspeita, porque eu tinha construído os dois lados do exame: eu escrevi as corrupções de brilho, desfoque e desvio térmico, e escolhi os sinais físicos que o detector observa. Claro que um detector de brilho captura brilho. Um revisor com qualquer dente chamaria isso de circular, e estaria certo.

Então mantive uma família de deriva completamente de fora. O detector nunca foi ajustado contra subexposição, nunca a viu durante o desenvolvimento. Então rodei de novo bench.py (mais recentemente em 2026-07-17) no conjunto de teste held-out do MVTec AD metal_nut: 22 peças boas, 93 defeituosas, ajuste de treino apenas nas 220 imagens boas. Na família held-out de underexpose, o detector de envelope marcou AUROC 1.000. Esse é o número que carrega a tese, precisamente porque foi conquistado num modo de falha para o qual eu nunca engenhei. O script imprime "THESIS HOLDS" só se os números medidos de fato sustentam a afirmação; eu o escrevi assim para que o marketing não pudesse se afastar da medição.

O resto do benchmark merece o seu escopo exato, então aqui está sem arredondar a meu favor. Em peças boas sob deriva, a linha de base ingênua sem envelope rejeita falsamente de 95,5 a 100% por família de deriva (brilho 100%, desfoque 100%, desvio térmico 100%, underexpose 95,5%, média 98,9%). O Trust Gate rejeita falsamente 0,0% delas, retendo todas para revisão. E a ressalva honesta: as corrupções estão em força total, então o colapso da linha de base é quase total por construção. A afirmação que defenderei é a direção, de que um modelo limpidamente validado colapsa quando as entradas saem do seu envelope, não o percentual particular. Estas são medições num benchmark de pesquisa sob deriva sintética. Não são garantias de mundo aberto, e quem as citar como desempenho de produção as está usando mal, eu incluído.

A regra que quase deletei

A chamada de honestidade mais difícil que fiz nesta construção foi sobre uma regra que mal funciona. Cedo eu adicionei uma regra de zona geométrica: localizar a anomalia numa grade grosseira de 8 por 8, e tratar um defeito dentro da zona funcional de forma diferente de uma mancha lá na borda cosmética. Soa como metrologia de verdade. Então medi, e as medições foram humilhantes. O proxy de rugosidade local localiza uma anomalia em 33 de 93 defeitos held-out, cerca de 35%. Ele muda o resultado do gate em exatamente 1 de 93. E 0 das 18 auto-rejeições são respaldadas por uma anomalia localizada de verdade; quando nada localiza, o centróide cai de volta no centro da grade, que lê como dentro da zona por padrão.

Fiquei com três opções. Deletar a regra e fingir que nunca tentei. Mantê-la e deixar a UI sugerir metrologia de precisão que eu não tenho. Ou mantê-la e fazer a interface confessar. Escolhi a confissão. Quando o defeito herói da demo auto-rejeita (peça test-flip-264, um defeito estrutural grosseiro real da classe flip do MVTec), o drill-in de geometria declara abertamente que nada foi localizado nesta peça e a rejeição repousa só na confiança de textura.

A regra de fato se paga exatamente uma vez, e eu fiz o app provar isso em vez de encenar. Na inicialização, a demo busca todos os 93 defeitos held-out por uma peça com uma anomalia genuinamente localizada fora da zona funcional numa peça que de outro modo é confiante. No split enviado, essa busca encontra test-flip-251, centróide na linha 2, coluna 6, e o gate a roteia para HOLD em vez de disparar o atuador. Se os dados mudassem e nenhuma peça se qualificasse, aquele compasso simplesmente não apareceria. Eu até A/B testei o limiar de sigma da regra com validação cruzada de 5 dobras; o valor ajustado não mostrou melhoria sobre o 2,5 definido à mão, então mantive 2,5 e registrei o resultado negativo no repositório com "shipped": false. Num engajamento de produção esta regra é substituída por metrologia pixel-exata ancorada em CAD. Na demo ela é um substituto honesto, e a UI diz isso em cada peça.

Uma camada de confiança que se vende demais é uma contradição em termos.

Aquela linha virou uma regra de design. Se a promessa inteira do produto é saber quando não confiar num modelo, ele não pode ao mesmo tempo blefar sobre o seu componente mais fraco.

Agentes aconselham, o código decide

A decisão que me recuso a delegar é a que move metal. O próprio gate é código determinístico simples, fora de qualquer LLM e fora do modelo de visão também. Seus limiares são ajustados a partir dos dados da própria demo, não chutados: auto-aprovação abaixo de 0,948 e auto-rejeição acima de 1,30 na escala de confiança calibrada, com tudo no meio, e tudo fora do envelope, indo para HOLD. Roda contra um orçamento duro de janela de golpe de 750 ms, e no log de auditoria enviado as decisões caem em dezenas de milissegundos: test-good-288 auto-aprovada em 37,7 ms, test-good-289 em 24,4 ms, e o log do atuador de rejeição para test-flip-264 lê "REJECT actuated in 25ms (budget 750ms)."

Eu deveria ser claro sobre o que aciona: nada, ainda. O caminho EtherNet/IP até um atuador de rejeição Allen-Bradley ControlLogix é um simulador que registra exatamente o que teria feito, e o sink MES é um stub que escreve a linha de rastreabilidade que teria escrito. Ambos estão rotulados como stubs no app. Eles são moldados como os adaptadores reais porque a realidade de OT (plantas mistas Siemens e Allen-Bradley, uma janela de rejeição medida em milissegundos) é a superfície real do produto, mas uma demo que implicasse uma linha ao vivo falharia no seu próprio teste de confiança.

Há agentes no sistema, e eu os limitei de propósito. Quando as peças se acumulam na fila de escalonamento, um par Drift Triage entra em ação: um agente de diagnóstico lê os desvios de sinal físico ranqueados nas peças retidas e propõe uma hipótese de causa-raiz com uma ação recomendada, e um agente crítico então checa essa hipótese contra a evidência numérica, rebaixando-a para "investigação manual" se o sinal citado não for de fato o desvio dominante. Eles são construídos sobre Pydantic AI e trocáveis de provedor, e sem chave de API configurada o conjunto todo degrada para um triage templateado determinístico, então a demo roda totalmente offline. O que os agentes não podem fazer, por construção, é tocar o atuador. Quando eles falam, o gate já decidiu.

Agentes aconselham, o código decide.

Cada uma dessas decisões deixa um recibo. Cada peça escreve um registro de linhagem JSONL: id da peça, estação, model id metalnut-defect-knn versão v7, hash do dataset ae95b5b533c8, confiança de defeito, escore OOD, os sinais físicos, quais regras do gate dispararam, latência contra o orçamento de 750 ms, as linhas de log de acionamento e MES, o que a linha de base ingênua teria feito, e a tag de risco high-risk:quality-gate (EU AI Act Annex III, eff. 2026-08-02). Um clique exporta o turno como inspection_audit.jsonl.

O relógio regulatório importa aqui. As obrigações de alto risco do EU AI Act tornam-se plenamente aplicáveis em 2 de agosto de 2026, decisões de qualidade críticas para a segurança ficam no Annex III, e as multas máximas chegam a €35M ou 7% do faturamento global para as violações de práticas proibidas mais graves. Quero ser cuidadoso com as palavras, porque é exatamente aqui que palavras cuidadosas importam: a demo não é certificada pelo EU AI Act, e nenhuma demo pode ser. O que ela mostra é linhagem pronta para o EU AI Act, um registro por decisão desenhado para ser evidência arquivável num dossiê de conformidade de alto risco, gerado na velocidade da linha em vez de reconstruído depois de um incidente.

O que sobrevive à próxima atualização de modelo?

A pergunta que eu ficava me fazendo enquanto construía isto era brutal para um criador de demos: se o próximo modelo de defeito do cliente for dramaticamente melhor que o meu substituto, alguma coisa disso ainda importa? Agora penso que isso é exatamente ao contrário. A Deloitte prevê a adoção de IA agêntica na manufatura subindo de 6% para 24% em 2026 (Deloitte), o que significa mais modelos e mais autonomia chegando a mais atuadores. Cada um desses modelos terá um envelope validado, e a física de uma linha de prensa (brilho, matrizes frias, equilíbrio térmico) continuará tirando as entradas dele. Um modelo perfeito não muda nada nisso, porque a falha que o gate impede é uma falha de entrada, e a obrigação de auditoria que ele serve é jurídica, não de modelagem. Drift-gating, proveniência e acionamento governado valem em qualquer acurácia de modelo. Essa é a propriedade que me convenceu de que esta camada, e não outro modelo, era o que valia a pena construir; o turno scriptado em veriprajna.com/pt-BR/demos/inspecao-de-qualidade-com-ia-de-borda-inspection-trust-gate é minha tentativa de deixar você vê-la conquistar essa afirmação peça a peça.

E se você preferir vê-lo a me ler descrevendo, aqui está o corte do fundador, de ponta a ponta.

Então a pergunta que eu faria sobre qualquer modelo de inspeção na sua linha, inclusive um de 97%, não é "quão acurado ele é?". É: para a peça que acabou de cruzar a câmera, você sabe se aquela imagem estava dentro do envelope em que o modelo foi validado? Se você não consegue responder por peça, em milissegundos, com um registro que poderia entregar a um auditor, então eu não acho que você tem um problema de acurácia. Acho que você tem um problema de envelope, e eu genuinamente gostaria de saber qual dos dois a sua linha tem.