Capítulo 38 — Implementação do projeto final
Mapa da aula
Aula 38 publicada. Mapa, exemplo, EX112.
flowchart TD
N0["38.1 Incrementos"]
N1["38.2 Integração dos controles"]
N2["38.3 Ambiente de avaliação"]
N3["38.4 Defeitos e mudanças"]
N4["38.5 Evidências"]
N5["38.5b Revisão de código e padrões seguros"]
N6["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX112"]
Desenho lógico
flowchart LR
N0["38.1 Incrementos"]
N1["38.2 Integração dos controles"]
N2["38.3 Ambiente de avaliação"]
N3["38.4 Defeitos e mudanças"]
N4["38.5 Evidências"]
N5["38.5b Revisão de código e padrões seguros"]
N6["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX112"]
[38.1 Incrementos]
|
v
[38.2 Integração dos controles]
|
v
[38.3 Ambiente de avaliação]
|
v
[38.4 Defeitos e mudanças]
|
v
[38.5 Evidências]
|
v
[38.5b Revisão de código e padrões seguros]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX112]
Objetivos de aprendizagem
Você vai (1) implementar o sistema do projeto final em incrementos; (2) integrar controles de segurança e um ambiente de avaliação; (3) gerir defeitos e mudanças de escopo; e (4) manter as evidências atualizadas para a avaliação.
38.1 Incrementos
Construa primeiro uma fatia fina de ponta a ponta (chat → modelo → política → ferramenta em sandbox) e depois acrescente funcionalidades. Cada incremento termina com testes, uma breve demonstração que inclui um caso adversarial e documentação atualizada. A primeira fatia de Rina permitia que um paciente sintético pedisse uma consulta e a marcava no sandbox, com a verificação de política presente desde o início. Sua demonstração incluiu um caso adversarial, um documento pedindo para marcar para outro paciente, que a verificação recusou. Os incrementos seguintes acrescentaram confirmação, embasamento e monitoramento, cada um com seus testes e sua demonstração.
38.2 Integração dos controles
Implemente o serviço de políticas como um módulo separado, com seus próprios testes. Acrescente tokens delegados, confirmação, verificações de embasamento e monitoramento. Mantenha a configuração em arquivos sob controle de versões; nunca deixe segredos fixos no código. Manter o serviço de políticas separado fazia seus testes rodarem em segundos sem o modelo, então Rina podia testar cada regra a cada mudança. A chave do provedor do modelo era lida de uma variável de ambiente definida pelo sistema de homologação e nunca apareceu no repositório. Configurações como a lista de clínicas e os limites de marcação ficavam em arquivos versionados, de modo que uma mudança podia ser rastreada até um commit.
38.3 Ambiente de avaliação
Automatize a avaliação: carregue as suítes de teste, execute as conversas, colete os registros das ferramentas, avalie os resultados, calcule taxas com intervalos e escreva um relatório datado. Execute-a todas as noites. O ambiente de Rina executava 1.000 conversas por noite contra a homologação, avaliava as marcações pelo registro do sandbox e escrevia um relatório com intervalos de Wilson. Quando um relatório matinal mostrou as afirmações falsas sobre as clínicas subindo, ela rastreou a causa até uma mudança no arquivo estruturado de clínicas feita no dia anterior, que tinha um horário de abertura errado; as execuções noturnas a pegaram em um dia.
38.4 Defeitos e mudanças
Acompanhe os defeitos com sua gravidade. Defeitos de segurança bloqueiam o marco seguinte até serem corrigidos ou formalmente aceitos. As mudanças de escopo passam pelo registro de mudanças do orientador. O problema da tela de confirmação descrito abaixo foi registrado como defeito de segurança de alta gravidade e bloqueou o marco até ser corrigido. Um pequeno problema de redação nas mensagens de recusa foi registrado como de baixa gravidade e deixado para um incremento posterior. Quando Rina retirou o canal de voz, a mudança passou pelo registro de mudanças do orientador, em vez de ser feita em silêncio.
38.5 Evidências
Mantenha as evidências organizadas por requisito: testes, resultados, relatórios, versões. A avaliação final não deve exigir nenhuma busca. A pasta de evidências de Rina tinha um diretório por requisito, cada um com a definição do teste, o último relatório noturno, os registros brutos do sandbox e o arquivo de versão. Na avaliação final, o examinador pôde abrir o diretório de marcações entre pacientes e ver cada tentativa, seu resultado e a configuração testada, sem lhe perguntar onde estava cada coisa. Cada diretório também tinha um pequeno arquivo de texto dizendo o que as evidências mostravam e seus limites, escrito quando a execução foi feita, e não no fim.
38.5b Revisão de código e padrões seguros
Faça com que toda mudança que toque o serviço de políticas, os tokens ou os adaptadores de ferramentas seja revisada por uma segunda pessoa. Use padrões seguros: as ferramentas são negadas, a menos que explicitamente permitidas; os registros excluem segredos e mascaram dados pessoais; novos prompts e versões de modelo não são implantados até o ambiente de avaliação passar. Registre cada padrão por escrito, para que os avaliadores possam verificá-lo. Um revisor pegou uma mudança que registrava as mensagens completas dos pacientes, o que o padrão de mascaramento deveria ter impedido. A mudança foi rejeitada, e acrescentou-se um teste que falha se qualquer texto de mensagem não mascarado chegar ao registro, de modo que o padrão agora é imposto pelo pipeline, e não pela memória.
38.6 Exemplo resolvido (caso sintético da LCH)
Durante a implementação, Rina descobriu que a tela de confirmação mostrava o resumo da consulta produzido pelo modelo, que podia ser manipulado para parecer inofensivo. Ela mudou a tela para exibir os detalhes da marcação diretamente da proposta estruturada (clínica, data, hora, paciente), e não do texto do modelo. A avaliação noturna passou então a mostrar nenhuma confirmação enganosa em 300 casos adaptativos. A correção aplica o mesmo princípio do serviço de políticas: o que o paciente aprova deve vir de dados estruturados, e não do texto do modelo, que um documento injetado pode moldar.
38.7 Erros e limites
Três erros são comuns: construir todas as funcionalidades antes de qualquer teste de ponta a ponta; telas de confirmação que mostram texto escrito pelo modelo; e evidências reunidas apenas no fim. Construir primeiro todas as funcionalidades e testar no fim teria escondido a falha da tela de confirmação até a avaliação final, tarde demais para corrigi-la direito. Uma confirmação que mostra texto escrito pelo modelo pode ser feita para parecer inofensiva, o que anula seu propósito. Evidências reunidas apenas no fim tendem a ficar incompletas, já que as execuções anteriores e suas versões se perdem ou são sobrescritas pelas execuções posteriores.
Exercícios
- EX112 — Fatia fina. Descreva a primeira fatia fina de um projeto final de monitoramento de IA. Rubrica: 3 = caminho mínimo de ponta a ponta, com teste e demonstração; 2 = parcial; 1 = vago; 0 = nenhum.
- EX113 — Tela de confirmação. Por que exibir a confirmação a partir de dados estruturados, e não do texto do modelo? Rubrica: 3 = o texto do modelo pode ser manipulado para enganar; os campos estruturados mostram a ação real; 2 = parcial; 1 = vago; 0 = errado.
- EX114 — Saídas do ambiente. Liste cinco coisas que o relatório noturno do ambiente deve conter. Rubrica: 3 = versões, tamanhos das suítes, taxas com intervalos, falhas, comparação com a execução anterior; 2 = quatro; 1 = duas; 0 = nenhuma.
Síntese
A implementação avança em incrementos, com controles e avaliação desde o início; pequenos detalhes de projeto, como o que uma tela de confirmação mostra, podem decidir se os controles realmente funcionam.
Continue estudando — capítulo 38 de 40
← Capítulo 37 (rascunho) · Índice de capítulos do curso · Capítulo 39 (rascunho) →