💻 computer science

An Empirical Study of Sustainability in Prompt-driven Test Script Generation Using Small Language Models

Este estudo empírico analisa as compensações entre desempenho e sustentabilidade ambiental na geração de scripts de teste unitário utilizando Modelos de Linguagem Pequenos (SLMs) de 2B a 8B parâmetros, demonstrando que a escolha do modelo e a estrutura do prompt influenciam significativamente o consumo de energia, as emissões de carbono e a qualidade dos testes gerados.

Autores originais: Pragati Kumari, Novarun Deb

Publicado 2026-04-07

📖 5 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Pragati Kumari, Novarun Deb

Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

Imagine que você é um arquiteto de software e precisa construir uma casa (um programa de computador). Antigamente, você contratava apenas um mestre de obras gigante e super caro (os grandes modelos de IA) para desenhar os testes de segurança. Esse mestre era incrível, mas consumia tanta energia que deixava uma pegada de carbono enorme, como se tivesse queimado uma floresta inteira só para desenhar um único plano.

Recentemente, surgiram "ajudantes menores" e mais ágeis (os Modelos de Linguagem Pequenos, ou SLMs). Eles são mais baratos e rápidos, mas ninguém sabia exatamente quão "verdes" ou eficientes eles eram realmente quando o trabalho era criar testes de software.

Este estudo é como um laboratório de ecologia digital que colocou esses ajudantes menores para trabalhar e mediu o quanto eles poluíam o ar enquanto faziam seu trabalho.

Aqui está a explicação do que eles descobriram, usando analogias do dia a dia:

1. O Problema: A "Taxa Ambiental" da Inteligência Artificial

Usar inteligência artificial para escrever código gera calor e consome eletricidade. O estudo focou em modelos pequenos (entre 2 bilhões e 8 bilhões de "cérebros" ou parâmetros). A pergunta era: Se eu pedir para esses modelos escreverem testes de software, quanto de energia eles gastam e quanto de carbono eles emitem?

2. A Metodologia: O "Menu" de Instruções

Os pesquisadores não apenas pediram "escreva um teste". Eles testaram diferentes formas de pedir a mesma coisa, como se estivessem mudando o tom de voz de um chefe para um funcionário:

Pedido Básico: "Aqui está o código, faça um teste." (Como pedir um café sem pedir açúcar).
Pedido com Persona: "Aja como um especialista em testes e faça o melhor trabalho." (Como pedir um café com um barista experiente).
Pedido Super Detalhado: "Aja como um especialista, siga estas regras, não faça tal coisa, e use este formato." (Como dar um manual completo de 10 páginas para o barista).

Eles descobriram que quanto mais detalhado o pedido, mais energia o modelo gasta, mas às vezes o resultado (o teste) fica melhor. É como pedir um prato complexo: demora mais para cozinhar e gasta mais gás, mas pode sair mais gostoso.

3. O Fator "Localização": A Eletricidade Muda Tudo

Um dos achados mais interessantes foi sobre onde o computador estava rodando.

Imagine que você pede um teste para um modelo. Se o computador estiver na Holanda (onde a energia vem muito de vento e sol), a "pegada de carbono" é minúscula.
Se o mesmo computador estiver em Nevada, EUA (onde a energia vem mais de carvão), a pegada de carbono explode, mesmo que o modelo seja o mesmo.

Analogia: É como dirigir um carro elétrico. O carro é o mesmo, mas se você dirige em uma cidade onde a eletricidade é limpa, você é um herói do meio ambiente. Se dirige em uma cidade onde a eletricidade vem de usinas sujas, você ainda está poluindo, mesmo dirigindo o mesmo carro.

4. As Novas Ferramentas de Medição: O "Termômetro Verde"

Como saber qual modelo é o melhor? Não basta olhar apenas para quem é mais rápido ou quem gasta menos energia. Os autores criaram duas métricas (fórmulas matemáticas) para ajudar os arquitetos a escolherem:

Índice de Velocidade Sustentável (SVI): É como uma nota final de um aluno que precisa ser bom em tudo: rápido, barato, limpo e preciso. Se o aluno for super rápido mas sujar muito o quarto, a nota cai. Se for super limpo mas demorar uma eternidade, a nota também cai. O SVI busca o equilíbrio perfeito.
Pontuação Verde F-β (GFβ): Imagine um botão de controle deslizante.
- Se você quer priorizar o meio ambiente (economizar energia), você gira o botão para um lado.
- Se você quer priorizar a qualidade do código (cobrir todos os erros possíveis), você gira para o outro.
- Isso ajuda o arquiteto a decidir: "Hoje estou com pressa e quero economizar energia, então escolho o modelo X." ou "Hoje preciso de segurança máxima, então escolho o modelo Y, mesmo que ele gaste mais."

5. O Que Eles Descobriram? (O Veredito)

Não existe o "campeão único": Nenhum modelo venceu em tudo. Alguns são mais rápidos, outros são mais limpos, outros cobrem mais erros.
O local importa mais do que você pensa: Às vezes, um modelo "menos inteligente" rodando em um país com energia limpa é mais sustentável do que um modelo "super inteligente" rodando em um país com energia suja.
A precisão tem um custo: Usar modelos com menos "memória" (quantização) economiza energia, mas às vezes o teste fica menos preciso. É como usar uma régua de plástico barata vs. uma régua de metal: a barata é mais leve, mas pode não medir tão bem.

Conclusão: O Que Isso Significa Para Você?

Este estudo é um manual de instruções para quem usa Inteligência Artificial. Ele diz: "Não olhe apenas para o tamanho do modelo ou para a velocidade. Olhe para o conjunto completo: onde ele está rodando, como você está pedindo a tarefa e qual é o seu objetivo (economia ou qualidade)."

É como escolher um carro: às vezes o carro pequeno e econômico é o melhor, mas se você estiver em uma estrada de terra (energia suja), talvez seja melhor usar um carro híbrido em outro lugar. O importante é ter as ferramentas certas para fazer a escolha certa para o seu projeto e para o planeta.

Resumo Técnico: Estudo Empírico de Sustentabilidade na Geração de Scripts de Teste com Modelos de Linguagem Pequenos (SLMs)

1. Problema e Motivação

O uso crescente de Modelos de Linguagem (LLMs) na geração automatizada de scripts de teste trouxe avanços significativos, mas também levantou preocupações sobre seu impacto ambiental. A literatura atual foca predominantemente na sustentabilidade de Modelos de Linguagem Grandes (LLMs), que consomem muita energia e têm alta intensidade de carbono.

Existe uma lacuna crítica no conhecimento sobre as características de energia e carbono dos Modelos de Linguagem Pequenos (SLMs), especificamente na faixa de 2B a 8B parâmetros. Em ambientes com recursos limitados ou sensíveis à privacidade (onde a execução local é preferida), é crucial entender as compensações (trade-offs) entre a eficiência energética dos SLMs e seu desempenho na geração de testes. O objetivo deste estudo é preencher essa lacuna, avaliando empiricamente a relação sustentabilidade-desempenho na geração de scripts de teste unitário.

2. Metodologia

O estudo propõe um pipeline empírico estruturado em cinco fases, utilizando o benchmark HumanEval (164 tarefas de programação em Python) e variando prompts e configurações de modelos.

Modelos e Configurações:
- Foram selecionados cinco SLMs de ponta: Phi-3.5-mini, Qwen2.5-1.5B, deepseek-coder-7b, Mistral-7B e Llama-3-8B.
- Quantização: Os modelos foram testados em diferentes níveis de quantização (4-bit, 8-bit e não quantizado) para analisar o impacto da compressão na sustentabilidade.
- Prompts: Foram desenhados quatro templates de prompt progressivamente mais complexos (baseados no modelo da Anthropic), variando desde uma assinatura de função básica até prompts com personas de "testador especialista", regras estruturadas e exemplos.
Métricas de Coleta:
- Utilizou-se a biblioteca CodeCarbon para medir consumo de energia (kWh), emissões de carbono (gCO2eq) e duração (tempo).
- Utilizou-se Coverage.py para medir a cobertura de código dos scripts gerados.
- Fator Geográfico: Como os experimentos foram realizados no Google Colab, o estudo coletou dados sobre a localização do data center (intensidade de carbono da rede elétrica regional), reconhecendo que a fonte de energia local impacta diretamente a pegada de carbono.
Novas Métricas Propostas:
Para quantificar as compensações, os autores introduziram dois índices:
1. Índice de Velocidade Sustentável (SVI - Sustainable Velocity Index): Combina cobertura de código, intensidade de carbono de software (SCI), tempo de execução e estabilidade em uma única métrica normalizada. É projetado para evitar que um bom desempenho em uma área compense totalmente um desempenho ruim em outra.
2. Green F-β Score (GFβ): Um índice composto que equilibra eficiência ecológica e cobertura de código. O parâmetro β permite ajustar a prioridade:
  - $\beta < 1$ : Prioriza eficiência ecológica (menor emissão/tempo).
  - $\beta > 1$ : Prioriza a cobertura de código.

3. Contribuições Principais

Foco em SLMs: Primeiro estudo empírico focado especificamente nas características ambientais de SLMs (2B-8B) na geração de testes, diferenciando-se da literatura focada em LLMs massivos.
Análise Multidimensional: Introdução de métricas normalizadas (SVI e GFβ) que integram cobertura, tempo, estabilidade e impacto ambiental, permitindo uma comparação mais justa e holística.
Análise Regional e de Prompt: Demonstração de que a sustentabilidade não é apenas função do tamanho do modelo, mas é moldada pela interação entre complexidade do prompt, quantização e a intensidade de carbono da rede elétrica regional onde a inferência ocorre.
Ferramenta para Arquitetos: Fornece um mecanismo prático (via GFβ) para que arquitetos de software priorizem entre cobertura de teste e sustentabilidade ao escolher configurações de modelo.

4. Resultados Chave

RQ1 (Prompt e Região): A intensidade de carbono do software (SCI) é moldada conjuntamente pelo overhead do prompt e pela intensidade da rede elétrica. Mudanças na região de execução podem dominar o impacto das variações de prompt. Regiões com baixa intensidade de carbono (ex.: Holanda, Oregon) resultaram em SCIs significativamente menores.
RQ2 (Ranking Holístico): O SVI demonstra que não existe um "melhor modelo" absoluto. Modelos que performam bem em regiões de alta intensidade de carbono podem ter desempenho inferior em outras. O SVI revela que a escolha do modelo deve considerar o contexto de implantação.
RQ3 (Quantização): A sensibilidade à quantização é dependente do contexto. Em uma região fixa, maior precisão (não quantizado) melhorou o SVI, sugerindo que os ganhos de cobertura superaram as economias de energia da quantização. No entanto, ao mudar a região, a intensidade da rede elétrica tornou-se o fator dominante, anulando os benefícios aparentes da quantização.
RQ4 (Priorização): O uso do parâmetro β no GFβ altera drasticamente o ranking dos modelos. Um modelo que é o mais "verde" (baixo β) pode não ser o que oferece a melhor cobertura (alto β). Isso confirma que a seleção do modelo deve ser feita com base na prioridade específica do projeto e no local de execução esperado.

5. Significado e Conclusão

Este trabalho estabelece que a sustentabilidade na geração de testes automatizados é um problema complexo e multifacetado. A conclusão central é que nenhum modelo domina todas as dimensões de sustentabilidade.

A escolha de um SLM para geração de testes não deve ser baseada apenas no tamanho do modelo ou na precisão bruta, mas deve considerar:

A complexidade do prompt utilizado.
O nível de quantização adequado ao hardware disponível.
A localização geográfica da infraestrutura de inferência (intensidade da rede elétrica).
O objetivo de negócio (priorizar cobertura máxima ou minimização de emissões).

O estudo oferece evidências empíricas para a adoção de práticas de "IA Verde" (Green AI) no ciclo de vida de testes de software, fornecendo métricas e diretrizes para arquitetos de software tomarem decisões informadas que equilibrem eficácia técnica e responsabilidade ambiental.