Artigo Científico em Computação: Como Escrever e Publicar

Computação tem uma cultura científica própria. Isso importa na escrita.

Vamos lá: a área de computação tem uma relação com a produção científica que é diferente de praticamente qualquer outra disciplina. Conferências têm peso de periódico. Papers de dezesseis páginas competem com os de quatro. Código e artefatos de software fazem parte da contribuição científica de um jeito que textos de humanidades nunca precisaram contemplar.

Se você está começando a escrever artigos em computação, precisa entender essa cultura antes de tentar dominar o formato.

Não é questão de certo ou errado. É que a escrita acadêmica em computação tem convenções que derivam de como a área pensa o que é contribuição, o que é evidência e o que é suficiente para publicação. E quando você ignora essas convenções, o paper fica estranho mesmo que o conteúdo técnico seja sólido.

O que conta como contribuição em computação

Em computação, a contribuição de um paper precisa ser clara desde o abstract. Os revisores vão perguntar: qual é a novidade? O que isso resolve que antes não estava resolvido? Por que essa solução e não outra?

As contribuições aceitas pela área são de vários tipos: um novo algoritmo ou estrutura de dados com propriedades demonstráveis, um sistema ou arquitetura que resolve um problema prático com vantagens demonstradas, uma análise empírica que esclarece comportamento de sistemas existentes, uma síntese do estado da arte que organiza um campo de forma original, ou um framework conceitual que estrutura um problema de nova forma.

O que raramente é aceito como contribuição suficiente: uma implementação que apenas replica algo já existente, resultados que mostram melhora marginal sem justificativa teórica ou experimental sólida, e surveys que apenas listam trabalhos sem análise crítica.

A questão que você precisa responder antes de escrever uma linha: qual dessas categorias é a minha contribuição? Essa clareza vai organizar todo o resto do paper.

A estrutura de um paper de computação

A maioria dos papers de computação segue uma estrutura reconhecível, com variações por subárea. Uma boa forma de entender o esqueleto é:

Introdução: apresenta o problema, motiva por que ele importa, declara a contribuição e antecipa os resultados. Bons papers de computação colocam a contribuição explícita ainda na introdução, muitas vezes em forma de lista numerada.

Trabalhos relacionados: mapeia o que já existe, mostrando como o seu trabalho se diferencia. Em computação, esse mapeamento precisa ser preciso: citar um trabalho de forma errada ou omitir um trabalho relevante são erros que revisores identificam imediatamente.

Metodologia ou proposta técnica: descreve o que foi feito, com rigor suficiente para que outros possam replicar ou estender. Em trabalhos experimentais, descreve os experimentos, métricas e condições de avaliação. Em trabalhos de desenvolvimento, apresenta a arquitetura, os algoritmos e as decisões de design.

Avaliação ou resultados: mostra os resultados com dados concretos. Em computação, isso geralmente envolve experimentos comparativos (benchmarks), análise de complexidade ou provas formais dependendo da subárea.

Conclusão: resume a contribuição e aponta limitações e trabalhos futuros.

O problema das comparações incompletas

Um erro clássico em papers de computação é comparar a abordagem proposta apenas com baselines fracos para fazer os resultados parecerem melhores.

Revisores experientes conhecem os state-of-the-art da área e vão notar quando a comparação omite os métodos mais fortes. Isso não invalida a pesquisa, mas levanta dúvidas sobre a honestidade da avaliação.

A abordagem que funciona é comparar com os melhores métodos disponíveis e mostrar em que condições o seu trabalho é melhor, em que condições é comparável e em que situações tem limitações. Resultados honestos e bem analisados convencem mais do que resultados inflados.

Faz sentido? A área de computação valoriza rigor experimental de forma muito parecida com a medicina ou a física. Resultados precisam ser reproduzíveis, comparáveis e interpretados com honestidade.

Código e artefatos como parte da contribuição

Nos últimos anos, a área de computação tem avançado em direção à ciência aberta de um jeito específico: a disponibilização de código e dados como requisito ou boas práticas para publicação.

Conferências como SIGMOD, VLDB e várias da ACM têm programas de reprodutibilidade onde os autores submetem o código junto com o paper e passam por uma etapa de avaliação de artefato. Isso já influencia o que é esperado na escrita: o paper precisa descrever a metodologia experimental com detalhe suficiente para ser replicável, mesmo que o revisor não execute o código.

Se você está construindo um sistema, uma plataforma ou qualquer artefato como parte da pesquisa, pense desde o início em como vai documentar e disponibilizar isso. Não é uma exigência universal, mas é uma tendência crescente que valoriza os trabalhos que adotam essa prática.

Linguagem e escrita em inglês

A grande maioria dos venues de alto impacto em computação publica em inglês. Para pesquisadores brasileiros, isso é um desafio real.

Alguns pontos práticos que fazem diferença: clareza e objetividade são mais valorizadas do que elegância retórica. Um paper de computação não precisa de prosa sofisticada, precisa de precisão. Cada afirmação que não está sustentada por evidência ou referência vai gerar questionamento.

O abstract é a parte mais lida do paper e deve seguir uma estrutura muito clara: qual é o problema, qual é a abordagem proposta, quais são os principais resultados. Em dois ou três parágrafos, o revisor precisa entender por que deve continuar lendo.

Para quem está desenvolvendo a escrita em inglês técnico-científico, as ferramentas de IA podem ajudar na revisão gramatical e de fluência. Mas a estrutura do argumento científico precisa ser sua.

O abstract: a parte mais importante e mais negligenciada

Em computação, o abstract é lido antes de qualquer outra coisa. É o texto que determina se o revisor vai ler o paper com atenção ou com ceticismo, se o leitor vai clicar no seu trabalho numa pesquisa bibliográfica ou seguir em frente.

Um bom abstract em computação segue uma estrutura bem definida: qual é o problema sendo resolvido (uma frase), por que é importante ou difícil (uma frase), qual é a abordagem proposta (uma ou duas frases), quais são os principais resultados com números concretos sempre que possível (duas frases), e qual é a implicação ou contribuição (uma frase).

O erro mais comum é um abstract que descreve o que o paper contém (“neste artigo apresentamos…”) em vez de comunicar o que o paper descobriu. O leitor quer saber o resultado, não o roteiro.

Escreva o abstract depois que o paper estiver pronto, não antes. É muito difícil escrever um bom abstract sem saber exatamente quais são os resultados finais. E reescreva o abstract até conseguir dizer o essencial em 150 palavras sem sacrificar precisão.

A resposta aos revisores: uma habilidade que se aprende

Se o seu paper for aceito com revisões, ou rejeitado com a possibilidade de resubmissão, você vai precisar responder aos revisores. Essa é uma habilidade específica que muitos mestrandos nunca desenvolveram antes da primeira submissão.

A resposta aos revisores tem uma etiqueta bem definida em computação: agradeça os comentários de forma breve e genuína, responda a cada ponto de forma clara e separada, mostre exatamente onde no texto você fez as mudanças (com números de linha ou seção), e se discorda de um ponto, argumente de forma respeitosa com evidências.

O que não funciona: respostas defensivas ou que minimizam o comentário do revisor, mudanças que não endereçam o problema apontado, e resposta agregada a múltiplos comentários sem separação clara.

Revisores geralmente são bem-intencionados e querem que o trabalho fique melhor. Tratar a revisão como uma conversa técnica, e não como um ataque pessoal, muda completamente a experiência.

Por que a revisão por pares em computação é especialmente exigente

Revisores em computação tendem a verificar diretamente os trabalhos citados, reproduzir os experimentos quando relevante e consultar versões anteriores do trabalho se suspeitar de piecemeal publication (publicar o mesmo trabalho fragmentado em vários papers).

Isso significa que o rigor da revisão vai além do texto: vai para os dados, os experimentos e a ética da publicação.

Uma prática importante: se o seu paper é uma extensão de um trabalho anterior, declare isso claramente. Explique o que é novo em relação à versão anterior. Não declarar isso é eticamente problemático e pode resultar em rejeição ou retratação posterior.

O paper que você precisa escrever versus o paper que você vai escrever

Vou terminar com uma provocação que é específica para computação mas vale para qualquer área.

Muitos mestrandos de computação têm um sistema funcionando, resultados impressionantes e ideias boas. E travam na escrita porque não sabem como transformar aquilo num paper.

O paper não é uma descrição do sistema. É um argumento sobre por que aquele sistema é uma contribuição para o campo. Essa diferença, entre descrever e argumentar, é onde a maioria das dificuldades de escrita em computação mora.

Se você está nesse ponto, dê uma olhada nos princípios do Método V.O.E.: antes de escrever, estabeleça com clareza a visão do que o paper precisa comunicar. Depois organize as evidências e ideias em função dessa visão. Só então escreva.

Escrever sem visão clara sobre a contribuição é a receita para aquele paper longo, denso tecnicamente e incompreensível para qualquer revisor que não seja seu orientador.

Você sabe o que construiu. Agora precisa aprender a comunicar.