Executar o Mesmo Prompt Cinco Vezes Produz Cinco Cópias do Mesmo Erro

A programação N-version assume que a diversidade vem de autores diferentes. Com LLMs, isso significa modelos diferentes, provedores diferentes, talvez diferentes execuções de treinamento. Mas a suposição está errada. Você pode obter diversidade significativa do mesmo modelo exato mudando como você pergunta, não o que você pergunta.

O problema: aumentar a temperature para 1.0 e executar seu prompt cinco vezes não é uma estratégia. Você obterá variação superficial. Os nomes de variáveis mudam. Os comentários se reordenam. A estrutura permanece idêntica, e os bugs também permanecem idênticos.

Se você quer implementações que falhem independentemente, você precisa solicitar padrões de pensamento diferentes, não saídas diferentes.

O Que a Programação N-Version Realmente Precisa dos LLMs

A programação N-version é uma técnica de tolerância a falhas onde múltiplas implementações independentes da mesma especificação são executadas em paralelo. As saídas são comparadas, e um voto majoritário determina o resultado correto. A ideia é que desenvolvedores diferentes, trabalhando independentemente, introduzirão bugs diferentes. Os bugs não se correlacionarão, então um voto majoritário os suprime.

É uma ideia antiga. Também é cara. Você está pagando N equipes para construir a mesma coisa.

LLMs a tornam barata o suficiente para tentar. Em vez de N equipes, você tem N chamadas de API. O problema é que N chamadas de API para o mesmo modelo com o mesmo prompt produzem N implementações quase idênticas. Os bugs se correlacionam perfeitamente. Seu voto majoritário é inútil.

A solução é tratar o prompt como o desenvolvedor, não o modelo. Prompts diferentes produzem desenvolvedores diferentes.

Por Que a Temperature Sozinha Produz Diversidade Cosmética

A temperature controla a distribuição de probabilidade sobre tokens. Em temperature alta, o modelo escolhe tokens seguintes menos prováveis. Isso cria variação na formulação, nomeação de variáveis e estrutura superficial.

Isso não cria variação na abordagem algorítmica. Se você pedir uma função para encontrar a substring palindrômica mais longa, a temperature muda se você usa left e right ou l e r. Isso não muda se você recorre a expand-around-center ou programação dinâmica.

Para programação N-version, isso é inútil. Você precisa de implementações que resolvam o problema de forma diferente, não implementações que pareçam diferentes enquanto o resolvem da mesma maneira.

Quatro Estratégias de Prompting que Forçam Diversidade Algorítmica

Aqui estão quatro abordagens que mudam como o modelo pensa sobre o problema.

Varie o Enquadramento do Problema

A mesma tarefa enquadrada como “escreva um parser” versus “escreva uma state machine que reconheça essa gramática” produzirá código diferente. Uma pode usar descida recursiva. A outra pode usar uma abordagem dirigida por tabela.

Você pode automatizar isso pedindo ao modelo para adotar um enquadramento específico antes de resolver:

import os
from openai import OpenAI

client = OpenAI(api_key=os.environ["OPENAI_API_KEY"])

def generate_with_framing(task: str, framing: str) -> str:
    prompt = f"""{framing}

Task: {task}

Write a complete, correct implementation. Do not explain your approach."""
    response = client.chat.completions.create(
        model="gpt-4o",
        messages=[{"role": "user", "content": prompt}],
        temperature=0.7,
    )
    return response.choices[0].message.content

task = "Parse a CSV string into a list of dictionaries, handling quoted fields and newlines within quotes."

framings = [
    "Approach this as a finite state machine with explicit state transitions.",
    "Approach this using recursive descent parsing with a lexer and parser.",
    "Approach this by splitting on delimiters and post-processing edge cases.",
]

for framing in framings:
    print(f"=== {framing} ===")
    print(generate_with_framing(task, framing))

Executando isso contra GPT-4o, o enquadramento de state machine produz consistentemente um parser caractere por caractere com um enum de estado explícito. O enquadramento de descida recursiva produz um lexer e funções parser separadas. O enquadramento de divisão-e-correção produz uma solução mais compacta, mas frágil.

Alterne Personas

Diferentes personas ativam diferentes conhecimentos. Um programador de sistemas escreve código diferente de um cientista de dados ou um programador competitivo.

personas = [
    "You are a systems programmer who prioritizes memory efficiency and avoids unnecessary allocations.",
    "You are a Pythonic developer who prefers concise, idiomatic code using standard library features.",
    "You are an algorithms researcher who reaches for theoretically optimal solutions even if the code is longer.",
]

O prompting de persona é surpreendentemente eficaz para diversidade estrutural. O programador de sistemas recorre a arrays e indexes. O desenvolvedor Pythonic recorre a itertools e compreensões. O pesquisador de algoritmos pode trazer uma biblioteca ou escrever uma solução mais formal.

Restrinja as Ferramentas Disponíveis

Restringir ou expandir o conjunto de ferramentas disponível força abordagens diferentes.

constraints = [
    "You may only use the Python standard library. No external dependencies.",
    "You may use numpy and pandas. Optimize for vectorized operations.",
    "You must implement this without using regular expressions.",
]

Isso é particularmente útil quando você sabe que uma abordagem tem um ponto cego. Se seus parsers baseados em regex continuam tratando incorretamente aspas aninhadas, force uma versão que não use regex.

Chain-of-Thought com Raciocínio Divergente

Em vez de pedir código diretamente, peça ao modelo para gerar múltiplas estratégias de solução e escolher a menos óbvia.

cot_prompt = f"""Task: {task}

First, list three different algorithms or approaches to solve this problem.
Then, pick the one that is most different from the others and implement it.
Do not pick the most obvious approach."""

response = client.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": cot_prompt}],
    temperature=0.7,
)

O chain-of-thought força o modelo a expor seu raciocínio. A restrição de “mais diferente” o empurra para longe da solução padrão. Na prática, isso produz a maior diversidade estrutural de qualquer técnica única.

Onde Isso Falha: O Teto de Diversidade

A diversidade de mesmo modelo tem limites, e você os atingirá.

Lacunas de conhecimento fundamentais são compartilhadas. Se os dados de treinamento contêm um mal-entendido sistemático sobre comparação de ponto flutuante, todo enquadramento e toda persona reproduzirão esse mal-entendido. O modelo tem um conjunto de pesos. Você não contorna isso com prompts.

Há também retornos decrescentes. Os três primeiros enquadramentos podem lhe dar uma state machine, um parser recursivo e uma abordagem baseada em divisão. O quarto enquadramento pode lhe dar uma state machine com nomes de variáveis diferentes. Depois de três a cinco abordagens genuinamente diferentes, você está raspando o fundo do barril.

Algumas técnicas degradam a qualidade. A restrição de “mais diferente” ocasionalmente produz soluções que são diferentes porque estão erradas. Divergência pelo próprio valor não é útil. Você precisa de um mecanismo de votação ou teste para filtrar as más ideias.

Uma Configuração Prática que Você Pode Implantar Hoje

Se você está construindo isso em um sistema, não randomize. Projete sua diversidade.

Escolha três a cinco técnicas da lista acima. Gere uma implementação por técnica. Execute sua test suite ou testes baseados em propriedades contra todas elas. Mantenha as que passam. Use um voto majoritário simples para a saída final.

from collections import Counter

def majority_vote(outputs: list[str], test_fn) -> str:
    passing = [o for o in outputs if test_fn(o)]
    if not passing:
        raise RuntimeError("No implementation passed tests")

    # Exact match voting; swap for AST comparison if needed
    return Counter(passing).most_common(1)[0][0]

A etapa de filtragem por testes é inegociável. Diversidade sem corretude é apenas ruído.

FAQ

Isso funciona com modelos menores?

Sim, mas o teto de diversidade é mais baixo. Modelos menores têm menos estratégias de solução distintas em seus dados de treinamento. Você pode obter duas abordagens genuinamente diferentes em vez de quatro. As técnicas ainda funcionam; elas apenas produzem menos variação.

Quantas implementações eu realmente preciso?

Três é o mínimo prático para votação majoritária. Cinco lhe dá melhor cobertura, mas com custo crescente de forma linear. Depois de cinco, a diversidade de mesmo modelo degenera em variação cosmética. Se você precisar de mais de cinco, mude para diversidade cross-model.

A diversidade de mesmo modelo é tão boa quanto a diversidade cross-model?

Não. Modelos diferentes têm diferentes dados de treinamento, arquiteturas e fine-tuning. Eles falham de formas genuinamente diferentes. A diversidade de mesmo modelo é uma troca entre custo e conveniência operacional. Use-a quando você precisa de boa tolerância a falhas rapidamente, não quando precisa de tolerância a falhas perfeita.

Posso combinar essas técnicas?

Com certeza. Um prompt de persona combinado com uma restrição de ferramenta e uma etapa de chain-of-thought produzirá mais diversidade do que qualquer técnica isolada. O custo é um prompt mais longo e mais tokens por geração. Para caminhos de código críticos, os tokens extras valem a pena.

O Que Tentar Primeiro

Comece com variação de enquadramento. É a mais fácil de implementar e produz a diversidade estrutural mais consistente. Adicione alternância de persona se precisar de mais. Reserve a diversidade cross-model para os casos onde a diversidade de mesmo modelo atinge seu teto.

Execute suas implementações pela mesma test suite antes de deixá-las votar. Uma implementação diversa não testada é apenas uma implementação com bugs que você ainda não conhece.