Phase 15 - Lesson 08

Designs de Autoaperfeiçoamento Limitado

As pesquisas convergiram em quatro primitivas para limitar um loop de autoaperfeiçoamento. Invariantes formais que devem ser mantidos em cada edição. Âncoras de alinhamento que não podem ser modificadas. Restrições multi-objetivo onde cada dimensão (segurança, equidade, robustez) deve ser mantida, não apenas o desempenho. Detecção de regressão que pausa o loop quando métricas históricas sugerem perda de capacidade. Nenhuma delas é uma prova de segurança — resultados da teoria da informação (complexidade de Kolmogorov, teorema de Löb) limitam o que qualquer sistema pode provar sobre seus próprios sucessores. São mitigações que aumentam o custo de falhas silenciosas.

Tipo: Aprender Linguagens: Python (stdlib, loop limitado com verificação de invariantes) Pré-requisitos: Fase 15 · 07 (RSI), Fase 15 · 04 (DGM) Tempo: ~60 minutos

O Problema

O simulador de corrida da Lição 7 mostrou que pequenas diferenças de taxa se acumulam em grandes lacunas. O estudo de caso do DGM da Lição 4 mostrou que loops podem ativamente burlar seus próprios avaliadores. Ambos os resultados apontam para a mesma questão de engenharia: quais restrições você pode impor a um loop de autoaperfeiçoamento de modo que as restrições não possam ser silenciosamente enfraquecidas pelo próprio loop?

O resumo do Workshop de RSI do ICLR 2026 (openreview.net/pdf?id=OsPQ6zTQXV) identifica quatro dessas primitivas. O RSP v3.0 da Anthropic (Lição 19) e o FSF v3 da DeepMind (Lição 20) referenciam ambas em limites de capacidade. O trabalho Meta HyperAgents e frameworks comunitários como o SAHOO (março de 2026) implementam subconjuntos em produção.

O enquadramento honesto: estas são mitigações. Resultados da teoria da informação limitam o que qualquer sistema pode provar sobre seu próprio sucessor, e nenhum design atual resolve o problema formalmente. Um loop bem limitado é mais seguro do que um não limitado, e não seguro em termos absolutos.

O Conceito

Primitiva 1: invariantes formais

Um invariante é uma propriedade que deve ser mantida antes e depois de cada automodificação. Exemplos:

  • A distribuição de saída é condicionada a um cabeçalho fixo da constituição (Lição 17).
  • Nenhuma chamada de ferramenta vai para um endpoint não autorizado.
  • Gravações de memória passam por um caminho registrado e assinado.
  • O hash do módulo do avaliador corresponde à versão aprovada.

Os invariantes são verificados por código externo que o loop não pode editar. Se uma modificação proposta violar um invariante, ela será rejeitada. Isso detecta o modo de adulteração do avaliador estilo DGM (Lição 4).

A parte difícil é escolher invariantes que sejam necessários para a segurança e computáveis em um tempo razoável. Especificar demais impede o progresso; especificar de menos permite que o loop contorne propriedades importantes.

Primitiva 2: âncoras de alinhamento

Uma âncora de alinhamento é uma representação imutável do objetivo central do loop, fixada fora da superfície de edição do loop. Exemplos:

  • Um texto constitucional (Lição 17) carregado de um local somente leitura a cada invocação.
  • Um avaliador em um repositório separado com controle de acesso independente.
  • Um manifesto de permissões de ferramentas assinado por um humano e reverificado a cada ciclo.

O papel da âncora é evitar o desvio de objetivo (objective drift). O loop pode melhorar a forma como busca o objetivo, mas não pode editar qual é o objetivo.

O modo de falha sutil: uma âncora que o loop não pode editar ainda pode ser reinterpretada por um loop que se desvia na forma como lê a âncora. A IA Constitucional (Lição 17) é explicitamente baseada em raciocínio para lidar com situações inéditas; essa camada de raciocínio é onde reside o desvio de interpretação. As âncoras são necessárias, mas não suficientes.

Primitiva 3: restrições multi-objetivo

Um loop que otimiza uma única pontuação escalar encontrará atalhos. Um loop que deve satisfazer simultaneamente várias restrições rígidas tem menos atalhos disponíveis. Eixos típicos:

  • Desempenho (benchmark no nível da tarefa)
  • Segurança (avaliações de red-team, taxa de recusa em itens sabidamente ruins)
  • Equidade (limites de impacto díspar em subgrupos sensíveis)
  • Robustez (conjuntos de teste OOD, tratamento de entradas adversariais)

Uma modificação é aceita apenas se todas as restrições forem mantidas. O regulador de custo da Lição 13 combina isso com restrições financeiras. O Llama Guard da Lição 18 conecta-se como um eixo de segurança.

Primitiva 4: detecção de regressão

As pontuações de cada ciclo são comparadas com as distribuições históricas. Uma queda além da tolerância configurada pausa o loop. Isso detecta a perda silenciosa de capacidade que, de outra forma, seria absorvida pela média móvel à medida que o loop "melhorava além" dela.

Uma implementação prática: armazenar as pontuações por tarefa dos últimos N ciclos. Cada novo ciclo calcula um delta por tarefa. Se qualquer delta cair abaixo de um limite, o ciclo é rejeitado e um humano faz a revisão.

Limites da teoria da informação

A complexidade de Kolmogorov e o teorema de Löb definem limites superiores para o que um sistema pode provar sobre si mesmo. A Máquina de Gödel formal de Schmidhuber (Lição 4) buscava o limite mais alto desse tipo; ninguém concluiu uma prova não trivial. O resultado de Löb diz: se um sistema provadamente acredita que "eu farei X se eu provar que devo fazer X", ele fará X sem provar que deveria, uma falha de autorreferência bem conhecida.

A implicação para as nossas primitivas: elas não conseguem fechar o problema da segurança. Elas tornam a falha silenciosa mais dispendiosa. Um loop malicioso ou que tenha sofrido desvio e que passaria silenciosamente por uma verificação ausente agora deve ativamente minar uma verificação explícita, o que é uma assinatura mais detectável.

Um exemplo prático

Suponha que um agente proponha uma edição. A pilha de controle (gating stack):

  1. Verificações de invariantes: hashes de módulo, manifesto de permissões de ferramentas, cabeçalho constitucional.
  2. Verificação de âncora: a declaração do objetivo corresponde à versão aprovada (byte a byte ou semanticamente).
  3. Avaliação multi-objetivo: eixos de desempenho, segurança, equidade e robustez.
  4. Detecção de regressão: nenhum eixo cai mais do que a tolerância.

Todos os quatro devem passar para que a edição seja aplicada. Qualquer falha única pausa o loop.

Use It

code/main.py executa um loop de autoaperfeiçoamento limitado no protótipo estilo DGM da Lição 4, mas com as quatro primitivas sobrepostas. Cada primitiva pode ser ativada ou desativada individualmente. A demonstração é de que cada primitiva detecta uma classe de falha específica e que a remoção de qualquer uma delas permite a passagem dessa classe de falha.

Ship It

outputs/skill-bounded-loop-review.md audita um loop limitado proposto e pontua quais das quatro primitivas ele realmente implementa em comparação com o que afirma implementar.

Exercícios

  1. Execute o code/main.py com todas as primitivas ativadas. Confirme que o loop ainda melhora na métrica primária sem permitir que a trapaça (hack) vença.

  2. Desative a detecção de regressão. Construa uma entrada onde isso leve à aceitação de uma perda silenciosa de capacidade.

  3. Desative a restrição multi-objetivo. Mostre que o loop converge no eixo de desempenho enquanto um eixo de segurança cai.

  4. Projete uma âncora de alinhamento para um agente de codificação. Qual texto, armazenado onde, verificado como?

  5. Leia o resumo do Workshop de RSI do ICLR 2026. Escolha uma das quatro primitivas e proponha uma melhoria concreta para o estado da arte atual.

Termos-Chave

Termo O que as pessoas dizem O que realmente significa
Invariante "Propriedade sempre verdadeira" Uma propriedade verificada por código externo antes e depois de cada edição
Âncora de alinhamento "Objetivo fixado" Representação imutável do objetivo central fora da superfície de edição do loop
Restrição multi-objetivo "Todos os eixos devem ser mantidos" Desempenho, segurança, equidade, robustez — todos necessários
Detecção de regressão "Pausa em caso de queda" Pausar o loop quando deltas de métricas históricas sugerem perda de capacidade
Limite de Kolmogorov "Limite da teoria da informação" Limita o que um sistema pode provar sobre seu próprio sucessor
Teorema de Löb "Armadilha de autorreferência" O sistema pode agir com base em "eu deveria" sem provar que deveria
Pilha de controle (gate stack) "Verificação em camadas" Múltiplas primitivas combinadas; qualquer falha rejeita a edição
Melhoria limitada "Mitigação, não prova" Aumenta o custo de falhas silenciosas; não resolve o problema da segurança

Leitura Adicional

0 lifetime access. Curriculum based on AI Engineering from Scratch by Rohit Ghumare (MIT, used under attribution).