Capítulo 37 — Seminário de revisão de evidências
Mapa da aula
Aula 37 publicada. Mapa, exemplo, EX109.
flowchart TD
N0["37.1 Formato do seminário"]
N1["37.2 Lista de verificação da revisão"]
N2["37.3 Como dar feedback"]
N3["37.4 Como receber feedback"]
N4["37.5 Comparação com trabalhos publicados"]
N5["37.7b Registro do resultado do seminário"]
N6["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX109"]
Desenho lógico
flowchart LR
N0["37.1 Formato do seminário"]
N1["37.2 Lista de verificação da revisão"]
N2["37.3 Como dar feedback"]
N3["37.4 Como receber feedback"]
N4["37.5 Comparação com trabalhos publicados"]
N5["37.7b Registro do resultado do seminário"]
N6["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX109"]
[37.1 Formato do seminário]
|
v
[37.2 Lista de verificação da revisão]
|
v
[37.3 Como dar feedback]
|
v
[37.4 Como receber feedback]
|
v
[37.5 Comparação com trabalhos publicados]
|
v
[37.7b Registro do resultado do seminário]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX109]
Objetivos de aprendizagem
Você vai (1) revisar criticamente as evidências de trabalhos publicados e dos projetos dos colegas; (2) avaliar afirmações à luz de modelos de ameaças, métodos e estatística; (3) dar e receber feedback estruturado; e (4) melhorar as evidências do seu projeto final antes da avaliação final.
37.1 Formato do seminário
Cada estudante apresenta as evidências do seu projeto final até o momento: requisitos, testes, resultados e limitações. Os colegas revisam com uma lista de verificação e dão feedback por escrito. Um artigo publicado também é revisado a cada semana, para comparação. No seminário de Rina, cada apresentação durava quinze minutos e era seguida das revisões escritas de dois colegas designados. Comparar o trabalho dos estudantes com um artigo publicado a cada semana mantinha o padrão concreto: se um artigo relatava intervalos e ataques adaptativos, os colegas esperavam o mesmo uns dos outros. O feedback era devolvido em dois dias, para que os apresentadores pudessem agir antes do marco seguinte.
37.2 Lista de verificação da revisão
O modelo de ameaças é explícito? Os testes estão separados do desenvolvimento? Há ataques adaptativos? Os resultados são relatados com intervalos e linhas de base? Os efeitos colaterais são medidos? As evidências são reprodutíveis (versões, sementes, scripts)? As limitações estão declaradas? As afirmações são proporcionais às evidências? Aplicada às evidências de Rina, a lista apontou um problema maior: os testes não eram independentes do desenvolvimento, já que ela escrevera ambos. O restante da lista passou, o que lhe deu confiança de que sua estatística e seu controle de versões eram sólidos. Os revisores anotavam o número do item ao lado de cada comentário, para que ela visse em que perguntas da lista seu trabalho havia falhado.
37.3 Como dar feedback
Seja específico e construtivo: nomeie o problema, por que ele importa e o que o corrigiria. Separe os problemas maiores (que mudariam as conclusões) dos menores. Um comentário útil sobre o trabalho de Rina dizia: "Todos os documentos injetados foram escritos pela projetista da defesa (maior): os resultados podem superestimar a robustez. Peça a outra pessoa que escreva um conjunto reservado." Um menos útil dizia apenas "os testes poderiam ser mais fortes". O primeiro nomeia o problema, por que importa e o que o corrigiria, então pôde ser posto em prática diretamente.
37.4 Como receber feedback
Classifique os comentários em: corrigir agora, explicar melhor, fora do escopo (acrescentar às limitações), discordar (responder com evidências). Acompanhe cada um até o fechamento. Rina classificou doze comentários: quatro para corrigir agora, incluindo o conjunto de testes independente; cinco para explicar melhor; dois fora do escopo, como a entrada por voz, que foi para suas limitações; e um de que discordou, sobre retirar a confirmação, que ela respondeu com os resultados do estudo anterior. Cada um foi marcado como fechado em seu controle quando concluído, com um link para a mudança.
37.5 Comparação com trabalhos publicados
Ler artigos fortes — por exemplo, Carlini et al. (arXiv:1902.06705) sobre avaliação, ou Greshake et al. (arXiv:2302.12173) sobre injeção indireta — mostra como são evidências convincentes; ler artigos mais fracos mostra as lacunas comuns. O grupo de Rina leu o artigo sobre injeção indireta ao lado de uma postagem de blog mais fraca, com afirmações parecidas. O artigo descrevia seu modelo de ameaças, seu ambiente e seus limites; a postagem relatava um exemplo dramático, sem contagem de tentativas. A comparação a ajudou a ver por que seus próprios relatórios informam o número de casos e o intervalo, e não apenas a transcrição mais marcante.
37.6 Exemplo resolvido (caso sintético da LCH)
Colegas revisaram as evidências do Safe Booking Assistant de Rina. Problema maior: todos os documentos de teste injetados tinham sido escritos por Rina, que também projetara as defesas. Ela pediu a dois colegas que escrevessem 150 novos casos adaptativos sem ver seu código. Dois produziram propostas de marcação que chegaram à etapa de confirmação com texto enganoso; nenhuma foi executada sem confirmação. Ela acrescentou uma tela de confirmação mais clara e relatou os novos resultados com seu próprio intervalo. Os dois quase acidentes mostraram a etapa de confirmação funcionando como última barreira, e também que sua redação importava.
37.7 Erros e limites
Três erros são comuns: feedback sem correções; respostas defensivas; e testes escritos apenas pelo defensor. Um feedback anotado mas nunca posto em prática deixa o trabalho como estava, por isso Rina acompanhou cada comentário até o fechamento. Responder defensivamente a um problema maior, como a independência dos testes, desperdiça a percepção do revisor. Testes escritos apenas por quem construiu as defesas tendem a deixar de fora ataques que essa pessoa não imaginou, e é por isso que os casos independentes encontraram problemas que os dela não encontraram, como o texto enganoso de confirmação.
37.7b Registro do resultado do seminário
Depois de cada seminário, o apresentador escreve uma nota curta com as mudanças acordadas, as objeções não aceitas e por quê, e qualquer nova análise a fazer. A nota é anexada ao registro do projeto, para que o próximo revisor veja como as evidências foram contestadas. A nota de Rina depois de seu seminário listou o conjunto de testes independente como a principal mudança acordada e registrou sua discordância sobre retirar a confirmação, com as evidências que apresentou. Também listou a nova análise: casos independentes com seu próprio intervalo. Seu orientador leu a nota antes da reunião seguinte.
Exercícios
- EX109 — Lista de verificação. Aplique quatro itens da lista ao projeto de um colega (ou ao seu). Rubrica: 3 = quatro itens respondidos com evidências; 2 = três; 1 = um ou dois; 0 = nenhum.
- EX110 — Problema maior. Por que "testes escritos pelo defensor" foi um problema maior? Rubrica: 3 = pontos cegos do defensor; os resultados podem superestimar a segurança; 2 = parcial; 1 = vago; 0 = errado.
- EX111 — Classificação. Classifique três comentários de feedback nas quatro categorias. Rubrica: 3 = classificação plausível, com ações; 2 = dois; 1 = um; 0 = nenhum.
Síntese
A revisão de evidências fortalece os projetos finais antes da avaliação: listas de verificação, testes independentes e feedback acompanhado expõem lacunas que o autor não consegue ver.
Continue estudando — capítulo 37 de 40
← Capítulo 36 (rascunho) · Índice de capítulos do curso · Capítulo 38 (rascunho) →