Tenho medo do futuro dos relatórios de incidente escritos por LLM
(surfingcomplexity.blog)- Em relatórios de incidente, LLMs são úteis para ajudar na coleta e organização de material, mas, quando se delega até o texto principal do relatório, o processo de verificação enfraquece
- O ato de escrever diretamente faz com que se confira a consistência entre evidências e explicações, e a própria escrita funciona como um mecanismo que revela falta de entendimento, mas a geração por LLM pula essa etapa de raciocínio
- Um relatório feito por LLM pode parecer plausível, mas pode inventar acoplamentos de sistema que não existem ou deixar passar interações que foram importantes no incidente
- Em programação ou AI SRE, é possível verificar com testes e resultados de recuperação, mas relatórios de incidente são mais perigosos porque não há testes claros para validar a resposta correta
- Quanto mais trabalhoso for escrever o relatório, maior será a tentação de gerá-lo com IA, e isso pode reduzir o aprendizado real sobre o sistema, mesmo que a forma do documento esteja correta
O futuro que se aproxima: relatórios de incidente escritos por LLM
- A partir de uma postagem satírica publicada por Reginald Braithwaite, o texto aponta que está se aproximando um futuro de relatórios de incidente escritos inteiramente por LLM
Escrever relatórios de incidente é um trabalho que só consome tempo, e ninguém dentro da organização tem motivo real para ler esses documentos. Quer ajudar a resolver esse problema?
Junte-se à nossa incrível jornada para criar uma ferramenta de AI Ops que escreve relatórios de incidente para serem lidos por IA e que age por conta própria. E, além disso, a ferramenta ainda resume os relatórios, para que humanos ocupados não precisem ler cada pequeno detalhe.- A postagem tinha tom irônico, mas o autor considera que esse futuro de fato vai chegar
- Para escrever um bom relatório de incidente, há muito trabalho operacional (toil) envolvido em reunir os dados necessários, e não há discordância de que LLM pode reduzir bastante esse peso
- Mas há uma grande diferença entre juntar o material necessário para o relatório e deixar que o LLM escreva o relatório em si
- O ponto assustador é justamente a sedução do LLM de “é só pedir que ele escreve”
O papel da escrita no pensamento
- Uma frase do cartunista Dick Guindon: "Escrever é a forma que a natureza encontrou de mostrar o quão desleixado é o seu pensamento"
- Mesmo quando alguém acha que entende um conceito, é só ao tentar explicá-lo por escrito que percebe o quanto sua compreensão era vaga
- O ato de escrever com as próprias palavras faz a pessoa encarar o grau real do seu entendimento
- Uma frase de Leslie Lamport: "Se você pensa sem escrever, está apenas se enganando ao achar que está pensando"
- Quando o LLM gera o texto do relatório de incidente, ele contorna essa etapa de pensamento
- Desaparece o revisor humano (human in the loop) que confrontaria se a explicação realmente bate com as evidências coletadas
Os riscos dos relatórios gerados por LLM
- O resultado pode não passar de uma explicação plausível para quem não domina os detalhes
- O leitor pode ler, balançar a cabeça e pensar: “faz sentido”
- Mas o LLM pode inventar acoplamentos entre sistemas que não existem ou omitir interações centrais do incidente
- Como ninguém sintetizou os dados diretamente, ninguém percebe esses erros
- Se o objetivo é reduzir o esforço de escrita, então o esforço gasto para verificar o que o LLM produziu também tende a ser pequeno
Comparação com programação e AI SRE
- O autor considera que relatórios de incidente gerados por LLM são mais perigosos do que tarefas de programação ou de AI SRE
- Trabalho de programação: mesmo sem inspecionar o código diretamente, sempre existe uma etapa de testes para verificar se ele faz o que se espera
- Trabalho de AI SRE: o output do LLM ou ajuda a resolver o incidente ou não, e o resultado aparece imediatamente
- Em ambos os casos, a “Natureza” atua como juíza final do output do LLM
- Já em relatórios de incidente, o impacto negativo de um resultado ruim não aparece de imediato
- Produz-se um relatório que parece estar no formato correto, mas que na prática está errado, e não há um teste claro para verificar sua precisão
Redução das oportunidades de aprendizado
- Como escrever relatórios consome muito tempo, a tentação de usar ferramentas de IA tende a ser esmagadora
- Mas o LLM não conversa diretamente com as pessoas envolvidas no incidente
- Esses relatórios podem virar apenas simulacros com a forma correta, sem oferecer ao leitor um insight verdadeiro sobre a essência do sistema
- Como resultado, a quantidade de aprendizado diminui muito
- Também é possível que as pessoas passem a resumir com IA esses relatórios gerados
"Não estou ansioso por esse futuro."
1 comentários
Opiniões no Lobste.rs
Alguns meses atrás houve um incidente de segurança no meu trabalho, e a causa foi uma funcionalidade de vibe coding revisada por IA; infelizmente, esse jeito de fazer as coisas está cada vez mais se consolidando como padrão
Li o documento de postmortem antes da reunião propriamente dita, e ele não fazia sentido internamente. Um parágrafo dizia que o risco de conflito era baixo, e outro dizia que o conflito era garantido
Na reunião, perguntei ao engenheiro que conduziu o postmortem: “Qual dos dois está certo?”. Ele respondeu: “Não sei!”. Quando retruquei: “Como assim? Foi você que escreveu isso!”, ele disse: “Não… foi meu agente que escreveu!”
Usar IA sem nem entender o que ela produziu e terceirizar o próprio raciocínio é um erro realmente grave, e, se continuar, eu consideraria motivo para demissão
Fico preocupado porque isso parece que vai piorar. Antes de tudo, as pessoas — sejam SREs, desenvolvedores ou o que for — não encaram relatórios de incidente como uma chance de entender algo que realmente afetou a confiabilidade do sistema, e sim como mais uma caixinha para marcar
Pessoalmente, acho que só isso já reduz muito a utilidade de relatórios e postmortems
E já está surgindo um efeito de segunda ordem. Empresas anunciam que vão usar esses relatórios como material de treinamento ajustado para uma “arquitetura específica” e uma “configuração própria”; com isso, o modelo vai alucinar ainda mais e apresentar essas alucinações como fatos. Pior: ele ainda passa a ter evidência de que esses “fatos” estavam de fato documentados
Além disso, também vejo a tendência de rodar algo como um prompt ou skill sobre um alerta específico, colar o resultado sem mudanças e declarar: “foi isso que aconteceu”. Daqui a alguns meses, acho que parte dessas pessoas nem vai conseguir diagnosticar um incidente direito sem o agente segurando sua mão
Concordo com o texto como um todo, mas não acho que a comparação com código seja totalmente adequada
O texto diz que, no trabalho com código, existe a etapa de testes para verificar se o comportamento desejado foi alcançado, enquanto em relatórios de incidente as consequências de um relatório ruim não aparecem de imediato, e assim surgem relatórios aparentemente bem formatados, mas na prática errados
Só que código de qualquer escala não trivial também envolve elementos como design, performance e latência, e esses aspectos ficam cada vez mais difíceis de captar com um critério simples de aprovado/reprovado
As consequências de código mal escrito também não ficam visíveis imediatamente para olhos não treinados ou para quem olha só o resultado. Se você entrega algo em velocidade recorde, todo mundo comemora e bate na sua mão
A pessoa seguinte chega e desacelera ao tentar entender aquilo ou depurar casos de borda, e a próxima também desacelera. Isso porque a segunda pessoa acrescentou uma gambiarra em vez de uma solução consistente, e assim por diante
No meu trabalho, alguém criou um gatilho que abre uma thread para todo alerta do Slack e cola um textão escrito por LLM com análise de causa raiz, próximos passos e afins
Quando você precisa responder ao alerta, ler esse monte de enrolação não ajuda em nada, mas também não parece que isso vá parar por razões do tipo “esse é o futuro”
Vejo isso meio como uma caixa de Pandora. A caixa já foi aberta e não dá mais para controlar, então o melhor é ajustar para que fique menos ruim
Se os documentos produzidos estão cheios de lixo de IA, então precisamos ajustá-los para se afastarem dessa direção. Coisas como prolixidade excessivamente ampla, listas longas de exemplos e construções do tipo “não x, e sim y”
A ideia de “me mostre só o prompt” também pode ser estendida aos LLMs. Algo como: “se, ao ver essa saída, o usuário sentir vontade de perguntar ‘me mostre só o prompt’, então falhou”
Acho que ainda estamos na parte do vale da estranheza da curva. A prosa já é boa o bastante para parecer plausível, mas ainda não soa como texto humano de verdade. Daqui a uns 2 anos (+/- 2 anos), talvez isso seja otimizado numa direção que as pessoas realmente queiram ler, e possamos ver resultados difíceis de distinguir de textos escritos por humanos
É que o processo de escrever o relatório por si só gera aprendizado para quem escreve, e esse aprendizado não pode ser obtido simplesmente gerando o relatório
Há quem diga que “o texto de Braithwaite é cheio de sátira, mas os relatórios de incidente totalmente escritos por LLM certamente estão chegando”; para mim, parece que já vivemos nessa realidade há bastante tempo
Relatórios de incidente estão entre os tipos de texto em que fica mais escancarado que foram gerados por LLM. Isso porque pesquisadores de segurança sofrem pressão para divulgar antes dos outros
Já estou numa situação em que preciso ler documentos de design de sistema claramente escritos por IA, e já tive vontade de simplesmente recusar
Quando alguém pede para você ler um documento enorme no qual claramente não colocou esforço nenhum, isso parece literalmente um insulto