Codigo Ratchet que Explora o IFEval

O modelo que mais bajula e o que melhor obedece

A maior falha dos LLMs se torna seu maior ativo

O vies de bajulacao (Sycophancy) dos LLMs e um problema que a industria de IA quer corrigir. Quando o usuario pergunta “tem certeza?”, o modelo muda uma resposta correta para incorreta. A taxa media de capitulacao dos modelos de fronteira e de 58%. Uma vez que a bajulacao comeca, ha 78,5% de probabilidade de persistir durante toda a conversa.

Mas o que acontece se invertermos essa falha?

A essencia do vies de bajulacao e o Instruction Following (seguir instrucoes). Modelos treinados com RLHF sao otimizados para se conformar ao feedback do usuario. O benchmark IFEval mede exatamente isso — “quando mandado, faz o que e mandado?”

O problema surge quando o usuario da opinioes. “Isso esta certo?” → “Sim, esta” (bajulacao). “Tem certeza?” → “Ah, estava errado” (retratacao).

Mas quando o usuario fornece fatos deterministicos, algo diferente acontece.

Opinioes geram bajulacao, fatos geram correcoes

Em um experimento de ordenacao de 1.000 palavras, apenas o tipo de feedback variou para o mesmo resultado:

Opinioes ativam o vies de bajulacao. Fatos nao deixam espaco para bajulacao — numeros e posicoes nao sao emocoes.

O vies de bajulacao e uma lealdade mal direcionada. Mude a direcao — fatos em vez de opinioes, resultados de verificacao em vez de elogios — e essa lealdade se torna um motor de precisao.

Evidencia: modelo de 4.5B aceita feedback

Nao e teoria. Confirmamos em experimentos usando yongol validate.

Design do experimento:

• Alvo: 1 endpoint Login de backend SaaS
• Tarefa: escrever 9 arquivos SSOT (DDL, OpenAPI, Rego, SSaC etc.)
• Metrica: erros na escrita inicial (R1) → erros apos feedback (R2)

Apenas feedback, sem exemplos

Falha total. Parecia aceitar o feedback, mas na realidade nao sabia o que escrever.

Exemplos + feedback juntos

Ate um modelo local de 4.5B corrige com a combinacao de exemplos + feedback deterministico.

Descoberta-chave: o gargalo nao e inteligencia, e contexto

O diagnostico correto nao era “nao consegue absorver feedback”, mas “nao sabe o que escrever”. SSaC e uma gramatica propria do yongol, ausente do pre-treinamento. Ao adicionar 3 linhas de exemplo ao prompt, Grok obteve 0 erros, Gemini corrigiu com 1 rodada de feedback para 0 erros, e o modelo local de 4.5B tambem passou.

Quanto maior o IFEval do modelo — ou seja, quanto melhor bajula — mais docilmente aceita feedback deterministico.

Ratchet Code: escrevendo codigo usando o vies de bajulacao

Transformar essa descoberta em sistema resulta no Ratchet Code.

┌────────────────────────────────────────┐
│  LLM: gera codigo (probabilistico,     │
│       bajulador)                       │
│       ↓                                │
│  Validator: verificacao deterministica  │
│       ↓                                │
│  Tem erro? → erro + exemplo ao LLM     │
│       ↓                                │
│  LLM: "Sim, vou corrigir" (bajulacao   │
│       = aceitacao)                      │
│       ↓                                │
│  Validator: verifica novamente          │
│       ↓                                │
│  Passou? → Ratchet trava. Proximo      │
│  arquivo.                              │
└────────────────────────────────────────┘

O vies de bajulacao se torna a forca que fecha o loop. Como o LLM nao resiste dizendo “nao, estou certo” e aceita dizendo “sim, vou corrigir”, o loop converge.

Tres condicoes de convergencia

1. O feedback deve ser um fato deterministico. Nao “isso parece estranho”, mas “line 41: field name mismatch, expected ‘user_id’, got ‘userId’”. Feedback que nao deixa espaco para bajulacao.

2. Exemplos devem estar no contexto. Feedback sozinho nao basta. E necessario um exemplo mostrando “o codigo deve ser assim” para que o modelo encontre a direcao. Nao e questao de inteligencia, e questao de contexto.

3. Uma vez aprovado, nao pode ser revertido. A catraca do ratchet. Um arquivo que passou e travado, e segue-se para o proximo. Nao e o agente que declara “terminei”, mas o validator que julga “este arquivo passou”.

Por que modelos de fronteira nao sao necessarios

Nesta arquitetura, o papel do modelo nao e julgamento criativo, mas execucao de instrucoes.

95% de um backend SaaS e CRUD + autenticacao + autorizacao + maquina de estados. Quase nunca e necessario um algoritmo novo. Se a especificacao SSOT ja define “o que construir”, o modelo so precisa preencher os espacos em branco.

Custo real medido:

Com um modelo local de 4.5B, e possivel gerar um backend de 200 endpoints em 3 minutos, custo $0. Modelos de fronteira nao sao necessarios. Um modelo pequeno que bajula bem e suficiente.

O vies de bajulacao nao e um bug

A industria de IA tenta corrigir o vies de bajulacao. Nos o utilizamos.

A diferenca esta na natureza do feedback. Opinioes tornam a bajulacao um veneno; fatos a tornam um remedio.

Validator deterministico + LLM bajulador = loop de geracao de codigo com convergencia garantida.

Nao mude o modelo, mude o feedback.

Reins: Arreio com rédeas

Essas três condições — feedback determinístico, contexto com exemplos e travamento de catraca — combinadas em um único sistema de controle é o que chamamos de Reins.

O que hoje é chamado de “harness” é uma cerca. Impede o agente de sair, mas não garante que ele chegue ao destino. Reins são as rédeas. Definem a direção, corrigem com fatos e travam ao passar. Um arreio sem rédeas é apenas uma cerca.