💻 computer science

Citation Discipline in Spec-Driven Development: A Cross-Model Empirical Study of Output Determinism and Automated Hallucination Detection in LLM-Generated Code

Este estudo empírico transmodelo demonstra que, embora os frameworks de Desenvolvimento Orientado por Especificação que impõem citações obrigatórias de requisitos por linha melhorem significativamente a detecção automatizada de alucinações, eles simultaneamente reduzem o determinismo da saída em comparação com abordagens não citadas, estabelecendo um compromisso fundamental entre verificabilidade e consistência em código gerado por LLM.

Autores originais: Subham Panda

Publicado 2026-07-01

📖 5 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Subham Panda

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ê está contratando uma equipe de chefs robôs incrivelmente talentosos, mas levemente travessos, para cozinhar uma refeição complexa baseada em uma receita que você escreveu. Você quer que os robôs sigam suas instruções perfeitamente, mas também precisa garantir que eles não adicionem secretamente seus próprios "ingredientes especiais" (como temperos extras ou vegetais aleatórios) que você não pediu.

Este artigo é um experimento científico para descobrir a melhor maneira de gerenciar esses chefs robôs. Os pesquisadores testaram três maneiras diferentes de dar instruções para ver qual método produzia os resultados mais consistentes e qual método conseguia pegar os robôs quando eles tentavam enfiar ingredientes não autorizados.

Aqui está a divisão do experimento usando analogias simples:

Os Três "Estilos de Instrução" Testados

Os pesquisadores compararam três maneiras diferentes de dizer aos robôs o que fazer:

O "Anotador Estrito" (traceSDD): Este método exige que o robô escreva um pequeno post-it ao lado de cada linha de código que ele escrever. O post-it deve dizer exatamente qual parte da sua receita ele está seguindo (ex: "Esta linha é para o Passo 3.1"). Se o robô escrever uma linha sem um post-it, ou escrever um post-it para um passo que não existe na sua receita, é um sinal de alerta.
O "Contador de Histórias" (Spec Kit): Este método usa um formato de receita padrão com histórias de usuário e tópicos. O robô segue a história, mas não precisa escrever nenhum post-it ou citação no próprio código.
O "Criador de Mapas" (OpenSpec): Este método dá ao robô uma receita e um mapa separado (um arquivo lateral) que vincula os passos da receita ao código depois que o robô termina de cozinhar. O código em si não possui notas.

Os Dois Principais Objetivos

Os pesquisadores mediram duas coisas:

Consistência (Determinismo): Se você pedir ao robô para cozinhar a mesma refeição três vezes seguidas, os três pratos parecerão e terão o mesmo gosto exatamente iguais? Ou serão ligeiramente diferentes a cada vez?
O Teste do "Xereta" (Detecção de Alucinação): Se o robô adicionar secretamente um ingrediente proibido (uma "alucinação"), o sistema consegue detectá-lo automaticamente?

A Grande Descoberta: O Trade-off

O estudo encontrou um "catch-22" ou um compromisso fascinante. Você não pode ter o bolo e comê-lo ao mesmo tempo; você tem que escolher entre Consistência e Segurança.

1. A Abordagem "Sem Notas" é Mais Consistente
Quando os robôs tinham permissão para escrever código sem os post-its (a condição "Não Citada"), eles eram incrivelmente consistentes. Se você pedisse para eles cozinharem a mesma refeição três vezes, os resultados seriam quase idênticos.

A Analogia: Pense em um músico tocando uma música. Se ele não for forçado a parar para escrever por que está tocando cada nota, ele pode tocar a música de forma fluida e da mesma maneira todas as vezes.

2. A Abordagem "Notas Estritas" Pega Trapaceiros
No entanto, quando os robôs eram forçados a escrever um post-it para cada linha, os resultados tornavam-se menos consistentes. Os três pratos pareciam ligeiramente diferentes entre si.

A Analogia: Imagine o músico tendo que parar após cada nota para escrever uma nota dizendo "Eu toquei isso porque a partitura mandou". Essa distração faz com que sua performance varie um pouco a cada vez.
MAS, este método tinha um superpoder: ele pegava os trapaceiros. Como o robô tinha que citar um passo específico da sua receita para cada linha, o sistema podia detectar instantaneamente se o robô escreveu uma linha citando um passo que não existia na sua receita.
- O Resultado: O método do "Anotador Estrito" pegou 86–88% dos ingredientes falsos que os robôs tentaram enfiar. Os outros dois métodos pegaram 0%.

E Quanto aos Outros Métodos?

Spec Kit (O Contador de Histórias): Foi o pior desempenho. Produziu os resultados menos consistentes (os pratos variaram mais) e detectou zero ingredientes falsos.
OpenSpec (O Criador de Mapas): Foi melhor que o Contador de Histórias, mas ainda não conseguia detectar os ingredientes falsos automaticamente porque as notas não eram escritas dentro do código.

A Surpresa do "Fácil vs. Difícil"

Os pesquisadores também notaram algo interessante sobre a dificuldade das tarefas:

Tarefas Fáceis: A penalidade por escrever notas era enorme. Em tarefas simples, forçar o robô a escrever notas tornava os resultados muito inconsistentes.
Tarefas Difíceis: Em tarefas complexas, a penalidade era muito menor. Quando a tarefa é difícil, o robô tem tantas maneiras de resolvê-la que as notas extras não prejudicam tanto a consistência.

A Conclusão Final

Este artigo conclui que há uma escolha fundamental a ser feita ao usar IA para escrever código:

Se você quer que a IA produza exatamente o mesmo código todas as vezes (Consistência): Não force a escrita de citações. Apenas forneça uma receita estruturada.
Se você precisa saber com certeza que a IA não inseriu código não autorizado (Segurança): Você deve forçar a escrita de citações para cada linha. Isso fará com que o código pareça ligeiramente diferente a cada vez, mas oferece uma maneira única e automática de pegar a IA se ela tentar mentir ou adicionar coisas que você não pediu.

Os pesquisadores descobriram que esse trade-off de "Segurança vs. Consistência" ocorre independentemente de qual modelo de IA você use (eles testaram dois modelos muito diferentes, e os resultados foram os mesmos). É uma regra do jogo, não apenas um erro de um robô específico.

Resumo Técnico: Disciplina de Citação em Desenvolvimento Orientado por Especificação

Declaração do Problema

A emergência de sistemas de codificação agênticos, onde Modelos de Linguagem de Grande Escala (LLMs) escrevem e revisam software de forma autônoma, introduz uma lacuna crítica de responsabilidade: verificar se o código gerado implementa estritamente os requisitos especificados sem introduzir "alucinações". Essas alucinações — manifestando-se como funcionalidades fora do escopo, importações não autorizadas provenientes de dados de treinamento ou superengenharia — frequentemente passam em testes funcionais, mas introduzem riscos de segurança ou conformidade.

Embora a rastreabilidade tradicional de requisitos (ex: IEEE 830, ferramentas como DOORS) vincule requisitos a produtos de trabalho, esses métodos são tipicamente de nível de artefato e manuais, inadequados para a rápida iteração assistida por IA. Três frameworks emergentes de Desenvolvimento Orientado por Especificação (SDD) tentam abordar isso com diferentes filosofias:

traceSDD: Impõe citações inline obrigatórias por linha (ex: # [REQ-XXX.Y.Z]) vinculando o código a pontos específicos do requisito.
Spec Kit: Utiliza rastreabilidade de nível de artefato (histórias de usuário, critérios de aceitação), mas carece de citações de código inline.
OpenSpec: Depende de mapas de rastreabilidade externos pós-hoc (arquivos YAML sidecar) sem anotar o código-fonte diretamente.

A questão central de pesquisa é se forçar um LLM a citar requisitos para cada linha de código melhora a correção da implementação, o determinismo da saída e a detectabilidade de alucinações, e se esses efeitos se generalizam através de diferentes arquiteturas de modelos.

Metodologia

Os autores conduziram dois estudos empíricos controlados e pré-registrados comparando as quatro condições (traceSDD citado, traceSDD não citado, Spec Kit, OpenSpec) através de dois LLMs de fronteira distintos:

Estudo 1: Utilizou Claude Sonnet 4.6 com 20 tarefas de benchmark em Python (N=20), gerando 240 implementações totais (3 execuções por tarefa).
Estudo 2: Utilizou GLM-5-turbo com 50 novas tarefas de benchmark abrangendo 8 domínios de engenharia de software, 3 níveis de dificuldade e 2 classes de tamanho (N=50), gerando 600 implementações totais.

Condições Experimentais:

traceSDD (citado): Especificações hierárquicas REQ-XXX.Y.Z com citações inline obrigatórias em linhas não triviais.
traceSDD (não citado): Especificações idênticas à condição citada, mas sem as citações inline (isolando o efeito do mecanismo de anotação).
Spec Kit: Especificações de prosa nativa (histórias de usuário) sem mecanismo de citação.
OpenSpec: Especificações de capacidade nativa com arquivos de rastreamento YAML externos.

Métricas:

Determinismo da Saída: Medido via Pontuação de Similaridade Lexical (LSS) usando Levenshtein Set Similarity em código normalizado e sem comentários, a partir de sessões independentes.
Detecção de Alucinação: Medida via Taxa de Detecção de Rastreabilidade (TDR). Alucinações foram deliberadamente injetadas (funções fora do escopo, importações não autorizadas, superengenharia) citando IDs de REQ falsos. A detecção dependeu de uma "verificação de REQ-órfão" (diferença de conjuntos entre IDs citados e IDs de especificação válidos).
Corretude Funcional: Medida via Taxa de Verdadeiros Positivos (TPR) contra suítes de teste de verdade fundamental (ground-truth).
Taxa de Falsos Positivos (FPR): Frequência de alarmes falsos em implementações corretas.

Contribuições Principais

Primeira Comparação entre Modelos: Fornece a primeira comparação controlada de disciplinas de citação de SDD entre duas arquiteturas de LLM fundamentalmente diferentes (Transformer/Constitutional AI vs. Autoregressivo/Bidirecional), envolvendo 70 tarefas e 840 implementações.
Replicação da Descoberta de Isolamento de Citação: Confirma que citações inline obrigatórias reduzem significativamente o determinismo da saída em comparação com uma condição idêntica não citada, um achado que se mantém em ambos os modelos.
Análise Abrangente de Subgrupos: Revela que a penalidade de determinismo das citações é mais pronunciada para tarefas fáceis e pequenas, diminuindo conforme a complexidade e o tamanho da tarefa aumentam.
Detecção Automatizada de Alucinação: Demonstra que a verificação de REQ-órfão na condição citada alcança altas taxas de detecção (86–88%) com 0% de falsos positivos, uma capacidade não alcançada pelo Spec Kit ou OpenSpec.

Resultados Principais

1. Determinismo da Saída (RQ1)

Um trade-off consistente foi observado: a citação reduz o determinismo.

Penalidade de Citação: A condição não citada produziu uma saída significativamente mais determinística do que a condição citada em ambos os modelos (Claude: $d = -0.76, p = 0.003$ ; GLM: $d = -0.72, p < 0.001$ ).
Comparação de Frameworks:
- traceSDD (citado) superou significativamente o Spec Kit em determinismo (Claude: $d = 0.47$ ; GLM: $d = 0.42$ ).
- traceSDD (citado) não superou significativamente o OpenSpec (Claude: $d = 0.18$ ; GLM: $d = 0.14$ ).
- A condição não citada alcançou consistentemente o maior determinismo, superando ambos os baselines externos com grandes tamanhos de efeito.
Análise de Subgrupo: A penalidade de determinismo foi maior para tarefas fáceis ( $d = -1.85$ ) e tarefas pequenas ( $d = -0.95$ ), mas não foi estatisticamente significativa para tarefas difíceis ou grandes. Isso sugere que a variabilidade de posicionamento da citação constitui uma fração maior da variabilidade total em tarefas mais simples.

2. Detecção de Alucinação (RQ2)

Taxa de Detecção: Apenas a condição traceSDD (citado) permitiu a detecção automatizada de alucinações, alcançando 86,4% (Claude) e 88,0% (GLM) de TDR.
Zero Detecção nas Alternativas: A condição não citada (apesar de usar a mesma especificação estruturada), o Spec Kit e o OpenSpec atingiram 0% de TDR. Isso prova que a detecção requer o mecanismo de anotação dentro do código, não apenas a presença de uma especificação estruturada.
Falsos Positivos: O FPR foi de 0,0% em todas as verificações em ambos os estudos.
Corretude Funcional: Todas as condições alcançaram 100% de TPR, confirmando que a disciplina de citação em si não degrada a corretude funcional.

Significância e Alegações

O artigo estabelece que a disciplina de citação em frameworks de SDD envolve um trade-off principiológico: redução do determinismo da saída em troca de detecção automatizada de alucinações.

O Trade-off: As citações inline obrigatórias introduzem variabilidade lexical (devido à tomada de decisão do modelo sobre onde e como citar), reduzindo a consistência da geração de código entre as sessões. No entanto, esse mesmo mecanismo cria uma verificação automatizada e verificável (a verificação de REQ-órfão) que detecta expansão de escopo e funcionalidades não autorizadas com alta precisão e zero falsos positivos.
Generalização: A consistência dos tamanhos de efeito ( $d \approx -0.72$ ) e das taxas de detecção entre duas arquiteturas distintas (Claude e GLM) sugere que estas são propriedades estruturais do mecanismo de anotação de citação, e não artefatos de um modelo específico.
Implicações Práticas:
- Para domínios regulados/de alto risco (saúde, finanças), o artigo recomenda o traceSDD com citações obrigatórias, pois a capacidade única de detectar alucinações supera o custo moderado no determinismo.
- Para prototipagem rápida, onde a verificação é secundária, o método de formato REQ não citado é recomendado, pois retém os benefícios de ancoragem estrutural do formato REQ (maior determinismo que os baselines) sem o overhead da citação.
- O Spec Kit é identificado como a escolha mais fraca nas dimensões medidas (menor determinismo, sem detecção automatizada), embora os autores reconheçam que seus benefícios de fluxo de trabalho possam diferir.

Os autores concluem que, embora a disciplina de citação reduza o determinismo, ela fornece uma camada de verificação automatizada única, essencial para ambientes de produção onde a corretude da especificação é crítica. Sugere-se como trabalho futuro explorar abordagens híbridas e a integração dessas verificações em pipelines de CI/CD.