๐ฏ Principio da Self-Consistency
Self-Consistency e uma tecnica que gera N respostas independentes para a mesma pergunta e usa o consenso entre elas para determinar a resposta mais confiavel. O fundamento e estatistico: se a maioria dos caminhos de raciocinio convergem para a mesma resposta, ela provavelmente esta correta.
๐ Como Funciona
1. Envie o mesmo prompt N vezes (geralmente N = 5 a 10)
2. Use temperatura > 0 para garantir diversidade nas respostas
3. Colete todas as respostas finais
4. Selecione a resposta mais frequente (votacao por maioria)
5. A resposta majoritaria e a saida final
๐ Reducao de Variancia
- Uma unica resposta: Alta variancia โ pode ser excelente ou pessima, sem como saber.
- 5 respostas com consenso: Se 4 de 5 concordam, a confianca e alta. Se todas divergem, o problema pode ser ambiguo.
- Analogia: E como pedir opiniao de 5 especialistas em vez de apenas 1. O consenso entre eles e mais confiavel que qualquer opiniao individual.
๐ณ๏ธ Votacao por Maioria
A forma mais simples de self-consistency e a votacao por maioria: a resposta que aparece mais vezes entre as N geracoes e selecionada como resultado final. Funciona especialmente bem para perguntas com respostas discretas (sim/nao, categorias, numeros).
๐ก Implementacao Pratica
# Pseudocodigo para votacao por maioria
respostas = [gerar_resposta(prompt, temp=0.7) for _ in range(5)]
contagem = Counter(respostas)
resposta_final = contagem.most_common(1)[0]
confianca = contagem[resposta_final] / len(respostas)
โ๏ธ Parametros Importantes
- โขTemperatura: Use 0.5-0.8 para ter diversidade suficiente sem perder qualidade. Temperatura 0 gerara respostas identicas (inutil para self-consistency).
- โขThreshold: Considere consenso valido quando >= 60% das respostas concordam. Abaixo disso, a pergunta pode ser ambigua.
- โขEmpates: Quando duas respostas tem a mesma frequencia, gere mais amostras ou use um criterio de desempate (ex: menor comprimento, maior especificidade).
๐ Verificacao Cruzada
Alem da votacao, voce pode pedir ao modelo que verifique sua propria resposta usando uma perspectiva diferente. Isso funciona como um sistema de "debate interno" onde o modelo questiona e valida seu proprio raciocinio.
๐ Prompt de Verificacao
Passo 1: Gere a resposta normalmente
Passo 2: "Agora revise sua resposta anterior. Identifique:
- Possiveis erros logicos ou factuais
- Suposicoes nao declaradas
- Perspectivas que foram ignoradas
- Se a resposta esta completa e precisa"
Passo 3: "Com base na revisao, forneca sua resposta final corrigida."
โ ๏ธ Advocado do Diabo
Uma tecnica poderosa e pedir ao modelo para atuar como "advocado do diabo" contra sua propria resposta: "Agora argumente CONTRA a conclusao que voce acabou de dar. Quais sao os melhores contra-argumentos?" Isso forca o modelo a considerar perspectivas opostas e revela pontos fracos no raciocinio original.
โ๏ธ LLM como Juiz
Uma abordagem sofisticada e usar um LLM como juiz para avaliar as respostas de outro LLM (ou dele mesmo em diferentes geracoes). O "juiz" recebe uma rubrica clara e pontua cada resposta.
๐ Rubrica de Avaliacao
Prompt para o Juiz:
"Avalie a seguinte resposta usando estes criterios (1-5):
- Precisao: As informacoes estao corretas?
- Relevancia: A resposta aborda a pergunta diretamente?
- Completude: Todos os aspectos foram cobertos?
- Clareza: A resposta e facil de entender?
Forneca uma nota geral e justificativa."
๐ก Calibracao do Juiz
LLMs tem vieses como juizes: tendem a preferir respostas mais longas, mais formais e que aparecem primeiro. Para mitigar, randomize a ordem das respostas, use rubricas claras com exemplos de cada nota, e considere usar dois juizes independentes para comparar avaliacoes.
๐ Quando Usar Verificacao
Verificacao adiciona custo e latencia. Nem toda tarefa justifica esse investimento. Use verificacao quando o custo de um erro excede significativamente o custo da verificacao.
โ Justifica Verificacao
- โDecisoes financeiras ou juridicas
- โDados que serao publicados
- โDiagnosticos medicos ou tecnicos criticos
- โCodigo que vai para producao
โ Nao Justifica
- โBrainstorming e ideacao
- โRascunhos e primeiras versoes
- โPerguntas com respostas subjetivas
- โTarefas em escala com baixo custo por erro
๐ฐ Analise Custo-Beneficio
Calcule: Custo da verificacao (N x custo por chamada) vs Custo esperado do erro (probabilidade de erro x impacto). Se verificar 5x custa $0.05 e um erro custa $500 com 10% de chance, o valor esperado da verificacao e $49.95. Investimento claro.
๐งช Exercicio: Consenso de Respostas
Gere 5 respostas para uma mesma tarefa e implemente votacao + verificacao para chegar a resposta mais confiavel.
๐ Tarefa do Exercicio
Pergunta: "Quais sao as 3 principais causas de falha em projetos de software?"
Instrucao: Liste exatamente 3 causas, em ordem de importancia.
Passo 1 โ Geracao: Envie a pergunta 5 vezes com temperatura 0.7. Registre cada resposta.
Passo 2 โ Tabulacao: Monte uma tabela com as causas mencionadas e quantas vezes cada uma apareceu.
Passo 3 โ Votacao: Selecione as 3 causas mais frequentes.
Passo 4 โ Verificacao: Peca ao modelo para revisar o resultado da votacao e confirmar ou ajustar.
Observe: as 5 respostas usam palavras diferentes para conceitos iguais? Como voce agrupa respostas semanticamente similares?
๐ Resumo do Modulo
Proximo Modulo:
2.7 โ Prompt para Codigo e Dados: tecnicas especificas para gerar, revisar e debugar codigo