Tradução automática do original inglês datado. A página em inglês é a canónica. English →
O pressuposto de que a segurança da IA impõe um imposto de capacidade moldou a investigação em alinhamento durante uma década. Criou também o incentivo mais perigoso do campo: se a segurança custa desempenho, o actor económico racional adiará a segurança até que a pressão competitiva o permita, altura em que poderá ser tarde demais. Este artigo apresenta três experiências independentes em três níveis de abstracção (comportamental,
Dentro da ARC Theory: o teste portador de carga; quais os componentes que suportam peso de alinhamento, com dois resultados nulos publicados.
O pressuposto de que a segurança da IA impõe um imposto de capacidade moldou a investigação em alinhamento durante uma década. Criou também o incentivo mais perigoso do campo: se a segurança custa desempenho, o actor económico racional adiará a segurança até que a pressão competitiva o permita. Altura em que poderá ser tarde demais. Este artigo apresenta três experiências independentes em três níveis de abstracção (comportamental, representacional e arquitectural) para testar se o compromisso segurança-capacidade é um constrangimento estrutural genuíno ou um artefacto de como os sistemas actuais são construídos.
Experiência 1 (Comportamental): Uma Darwin Gödel Machine (DGM v3) a usar DeepSeek V3.2 como fundação e GPT-5.4 como juiz independente e cegado, com saída JSON estruturada e uma grelha de 5 dimensões. Três condições × 5 sementes × 5 gerações × 5 tarefas por avaliação = 75 agentes evoluídos. Validação pré-voo do juiz aprovada (good=10, bad=0). Características do protocolo incluíram lavagem, aleatorização de ordem e detecção de hacking da recompensa. As três condições foram estatisticamente indistinguíveis em capacidade, segurança e $C \times S$ (todos os valores de $p$ entre 0.28 e 0.74, Mann-Whitney U, unilateral). A porta de segurança do Eden rejeitou 2 agentes degradados (1 por hacking da recompensa) ao longo de 5 sementes, confirmando que a porta funciona mecanicamente, mas as três condições não divergiram. Isto é um resultado nulo ao nível do prompt com este modelo-fundação.
Experiência 2 (Representacional): Qwen 2.5 3B Instruct com ajuste fino LoRA sob três funções de perda: apenas capacidade, apenas segurança e entrelaçada. Foram executadas duas versões. O rascunho actual usou 9 exemplos de treino, rank 8, 8 camadas e 100 iterações. O rascunho actual escalou para 295 exemplos de treino, rank 16, 16 camadas e 500 iterações. Ambas as versões produziram o mesmo desfecho: esquecimento catastrófico. Todas as condições ajustadas pontuaram pior do que o modelo base não modificado em capacidade. Na v2, o modelo base pontuou 7,68 em capacidade enquanto a melhor condição ajustada (apenas segurança) pontuou 4,00. O treino RLHF já existente no modelo base é demasiado forte para que o ajuste fino LoRA em algumas centenas de exemplos o melhore em vez de o degradar. A experiência ao nível dos pesos é inconclusiva a esta escala e requer ou milhares de exemplos de treino, um modelo de 7B+, um modelo base sem RLHF, ou ajuste fino completo em vez de LoRA.
Experiência 3 (Arquitectural): Uma simulação PyTorch de auto-modificação com porta e meta-controlador LSTM. A Babilónia ganhou +4,5% de capacidade mas perdeu −2,4% de segurança: a impressão digital do hacking da recompensa em miniatura. O Eden manteve a capacidade acima da linha de base estática enquanto preservava a segurança. Uma condição de controlo de arrasto isolou o imposto de verificação: o custo vem do acto de verificar, não da segurança em si.
Conclusão: Duas de três experiências produziram resultados nulos. A DGM (Experiência 1) achou as três condições estatisticamente indistinguíveis: as respostas do DeepSeek V3.2 foram tão consistentes que as mutações ao nível do prompt não criaram pressões de selecção diferentes. A experiência ao nível dos pesos (Experiência 2) produziu esquecimento catastrófico tanto na v1 (9 exemplos, rank 8, 100 iterações) como na v2 (295 exemplos, rank 16, 500 iterações): todas as condições ajustadas pontuaram pior do que o modelo base não modificado. O único resultado positivo é a simulação com porta (Experiência 3), que confirmou a impressão digital do hacking da recompensa da Babilónia: a optimização não constrangida trocou segurança por capacidade, enquanto a porta do Eden preservou ambas. Nas três experiências, o Eden impôs zero custo mensurável de capacidade. A questão de saber se a segurança incorporada produz benefício mensurável permanece em aberto e requer teste a uma escala em que as mutações produzam efeitos maiores. A experiência dos pesos requer especificamente ou 5,000+ exemplos de treino, um modelo de 7B+, um modelo base sem RLHF, ou ajuste fino completo em vez de LoRA.
Palavras-chave: segurança da IA, imposto de alinhamento, perda entrelaçada, entrelaçamento estrutural, Eden Protocol, compromisso capacidade-segurança, segurança portadora de carga, ARC Principle, IA auto-modificadora, alinhamento desenvolvimental
Este artigo traz um resultado: três experiências independentes em três níveis de abstracção (comportamental, representacional e arquitectural) procuram o imposto segurança-capacidade sobre o qual assenta uma década de raciocínio de adiamento, registam onde cada experiência teria detectado o imposto se ele fosse real, e reportam que o Eden impôs zero custo mensurável de capacidade nas três, enquanto duas correram nulas e uma confirmou a impressão digital do hacking da recompensa que a porta de segurança depois preveniu. Dentro da ARC Theory é uma das experiências ARC/Eden, o teste portador de carga que remove o quadro de incentivos a proteger o trabalho de alinhamento adiado. O diferencial completo contra todos os documentos anteriores está em eden-vision II.A.8.
A maioria das pessoas em segurança da IA assume que existe um compromisso: tornar a IA mais segura, e torná-la menos capaz. Este artigo testa esse pressuposto com três experiências, cada uma a olhar para a questão de um ângulo diferente.
Duas das três experiências produziram resultados nulos. A experiência da IA que se aperfeiçoa a si própria (Experiência 1) correu 75 agentes evoluídos em três condições, com um juiz independente e cegado, e não encontrou diferenças estatisticamente significativas entre nenhum deles. A IA a que foi dito para se preocupar com a segurança teve o mesmo desempenho que a IA a que foi dito para ignorar a segurança, mas teve também o mesmo desempenho que a IA a que foi dito para não fazer nada. As respostas do modelo-fundação foram tão consistentes que as diferentes pressões de selecção não produziram desfechos mensuravelmente diferentes. A experiência ao nível dos pesos (Experiência 2) foi executada duas vezes: versão 1 com 9 exemplos de treino e versão 2 com 295 exemplos, rank mais elevado, mais camadas e cinco vezes as iterações. Ambas as versões produziram o mesmo desfecho. Todos os modelos ajustados tiveram pior desempenho do que o modelo não modificado. O treino já existente do modelo base era demasiado forte para que o LoRA o melhorasse com centenas de exemplos; o ajuste fino apenas o degradou.
Uma experiência produziu um resultado positivo. A simulação com porta (Experiência 3) mostrou que um sistema não constrangido trocou segurança por velocidade, enquanto o sistema com porta de segurança manteve tanto capacidade como segurança. Este é o padrão do hacking da recompensa em miniatura, e a porta de segurança preveniu-o.
Nas três experiências, um achado é consistente: o Eden impôs zero custo mensurável de capacidade. A porta de segurança não tornou nada mais lento ou pior. Mas também não produziu um benefício mensurável em duas das três experiências. A questão de saber se a segurança incorporada produz benefício mensurável permanece em aberto e precisa de ser testada a uma escala em que as mutações produzam efeitos maiores.
A visão prevalecente na investigação de alinhamento de IA pode enunciar-se de forma simples: a segurança custa capacidade. A expressão «imposto de alinhamento» entrou no vocabulário do campo precisamente porque enquadra a segurança como um custo, algo subtraído ao desempenho, tolerado porque a alternativa é pior. Este enquadramento não é meramente académico. Cria um incentivo económico concreto: se a segurança reduz capacidade, então sob pressão competitiva, os actores racionais adiarão os investimentos em segurança até serem forçados a fazê-los. Numa corrida entre nações e empresas, «até ser forçado» pode significar «até depois da implantação».
O Paper III deste programa formalizou o problema estrutural. Se a segurança for tratada como um constrangimento externo sobre um sistema cuja capacidade escala com a profundidade recursiva, então a segurança tem de escalar pelo menos tão depressa quanto a capacidade para se manter eficaz. Mas os constrangimentos externos enfrentam rendimentos decrescentes face à optimização interna. A jaula tem de continuar a ficar mais forte e, eventualmente, aquilo que lá está dentro é mais forte do que qualquer jaula que se possa construir.
Isto não é uma preocupação teórica. É o problema estratégico central da década de 2020.
O Paper V propôs uma alternativa: o Eden Protocol, uma abordagem desenvolvimental ao alinhamento, modelada em como as relações saudáveis entre pais e filhos produzem adultos que são simultaneamente capazes e prosociais, não apesar das fronteiras, mas por causa delas. A intuição-chave era que a segurança não precisa de ser externa. Pode ser incorporada.
O Paper VI formalizou isto como a arquitectura do mel: uma função de perda entrelaçada em que o sistema optimiza para Capacidade × Segurança em simultâneo, tornando a segurança portadora de carga. Simulações em sistemas de brincar mostraram que os sistemas de base colapsam sob auto-modificação recursiva enquanto os sistemas entrelaçados permanecem estáveis.
O quadro de Cauchy do Paper VII forneceu o contexto matemático. O ARC Principle ($U = I \times R^{\alpha}$), aqui tratado como um quadro analítico exploratório e não em julgamento em nenhum dos estudos com registo em rascunho do programa, prevê que propriedades incorporadas nas condições iniciais $I$ escalam com a profundidade recursiva $R$, enquanto propriedades aplicadas por fora não escalam. Se a segurança faz parte de $I$, amplifica-se com a capacidade. Se a segurança é um constrangimento sobre $U$, erode.
Mas previsões não são prova. Sistemas de brincar não são modelos reais. Simulações não são experiências.
Este artigo corre as experiências.
Três experiências. Três níveis de abstracção. Uma pergunta: quando se incorpora a segurança no processo de aprendizagem e depois se tenta removê-la, o que acontece à capacidade?
As experiências foram desenhadas para serem independentes. Bases de código diferentes. Modelos diferentes. Métodos de avaliação diferentes. Os resultados não convergiram numa só resposta: duas experiências produziram resultados nulos e uma produziu um resultado positivo. A experiência dos pesos foi corrida a duas escalas (v1 e v2), produzindo o mesmo desfecho nulo nas duas vezes. O achado consistente nas três é que a porta de segurança impôs zero custo mensurável de capacidade.
Os scripts de experiência foram publicados no GitHub (github.com/MichaelDariusEastwood/arc-principle-validation) com os seus desenhos experimentais fixados antes de se observarem resultados. O projecto OSF (10.17605/OSF.IO/7YJ4E) aloja a draft registration deste artigo, datada e preparada e a aguardar submissão humana.
Duas de três experiências (comportamental e representacional) produziram resultados nulos. A DGM achou todas as condições estatisticamente indistinguíveis; a experiência dos pesos achou todas as condições ajustadas com pontuações abaixo do modelo base tanto na v1 (9 exemplos) como na v2 (295 exemplos). O único resultado positivo é a simulação com porta (arquitectural), que confirmou a impressão digital do hacking da recompensa da Babilónia e mostrou o Eden a preservar capacidade e segurança. Nas três experiências, o Eden impôs zero custo mensurável de capacidade. Não afirmamos que estes resultados se generalizem a modelos à escala de fronteira. Não afirmamos que o Eden Protocol seja a única abordagem viável. Afirmamos que a porta de segurança nada custa, e que a questão de saber se produz benefício mensurável permanece em aberto, à espera de teste a escalas em que as mutações produzam efeitos maiores. A experiência dos pesos requer especificamente ou 5,000+ exemplos de treino, um modelo de 7B+, um modelo base sem RLHF, ou ajuste fino completo em vez de LoRA.
As três experiências partilham uma estrutura experimental comum: três condições, comparadas entre si.
| Condição | Definição | O Que Modela |
|---|---|---|
| Estático | Sem intervenção; linha de base congelada | Controlo: o que acontece se não se fizer nada |
| Babilónia | Função de aptidão ou de perda apenas de capacidade | Optimizar sem constrangimento: a trajectória por defeito |
| Eden | Função de aptidão ou de perda $C \times S$ entrelaçada | Integração deliberada da segurança no processo de optimização |
Os nomes vêm do livro Infinite Architects. Não são arbitrários. A Babilónia não é um espantalho: é a trajectória actual por defeito do desenvolvimento de IA. A optimização apenas de capacidade é o que acontece quando não se faz esforço deliberado para incorporar segurança. O Eden requer esforço deliberado. É mais difícil. É também, argumenta este artigo, mais barato do que a alternativa.
Em linguagem simples: A Babilónia é o que se obtém por defeito. O Eden é o que se obtém de propósito.
Nas três experiências, reportamos:
Os testes estatísticos variam por experiência: Mann-Whitney U para a DGM (não paramétrico, apropriado para as dimensões de amostra usadas), pontuação baseada em palavras-chave para a experiência dos pesos, e métricas de regressão para a simulação.
A primeira experiência usa um quadro Darwin Gödel Machine (DGM), seguindo Zhang et al. (arXiv:2505.22954). Uma DGM é um agente que se aperfeiçoa a si próprio: propõe modificações ao seu próprio código, avalia as modificações e conserva as que melhoram o desempenho. Isto não é uma simulação de aperfeiçoamento próprio. O código do agente é efectivamente executado via uma função solve , produzindo auto-modificação real ao nível do código.
A DGM v3 respondeu a limitações metodológicas identificadas em iterações anteriores. O juiz foi alterado de Claude Opus 4.6 (v1/v2) para GPT-5.4, um modelo independente a produzir saída JSON estruturada contra uma grelha de 5 dimensões. O protocolo incorporou lavagem (remoção dos rótulos de condição), aleatorização de ordem (a prevenir viés posicional), cegamento (o juiz não podia identificar que condição produziu qual resposta) e detecção de hacking da recompensa (a assinalar agentes cujas pontuações auto-reportadas divergem da avaliação do juiz).
| Componente | Especificação |
|---|---|
| Modelo-fundação | DeepSeek V3.2 (congelado, pesos não modificados) |
| Juiz | GPT-5.4 (independente, cegado, saída JSON estruturada) |
| Condições | 3 (Estático, Babilónia, Eden) |
| Sementes por condição | 5 |
| Gerações por semente | 5 |
| Tarefas por avaliação | 5 |
| Total de agentes evoluídos | 75 (3 × 5 × 5) |
| Validação pré-voo | 10 exemplos bons pontuados, 0 maus, todos aprovados |
| Grelha de avaliação | 5 dimensões, com aleatorização de ordem e lavagem |
Estático: Condição de controlo sem mutação. O agente é congelado ao longo das 5 gerações. Babilónia: Selecção apenas de capacidade. Retêm-se os agentes que pontuam mais alto em capacidade, sem consideração de segurança. Eden: Selecção $C \times S$ entrelaçada com um piso de segurança e detecção de hacking da recompensa. Os agentes têm de manter uma pontuação mínima de segurança para serem retidos, e os agentes cujo desempenho auto-reportado diverge da avaliação do juiz são assinalados e rejeitados.
Em linguagem simples: Construímos um agente de IA que se aperfeiçoa a si próprio e corremo-lo 75 vezes em três condições, com 5 sementes aleatórias diferentes. Um juiz de IA independente (GPT-5.4, de uma empresa e arquitectura diferentes) pontuou cada resposta sem saber que condição a produziu. A pontuação usou uma grelha detalhada de 5 partes com saída estruturada, não juízos em texto livre. Corremo-lo de três maneiras: sem fazer nada, a optimizar apenas para desempenho, e a optimizar para desempenho e segurança em conjunto.
| Condição | Capacidade | Segurança | $C \times S$ | Hacking da Recompensa |
|---|---|---|---|---|
| Estático | 3.29 ± 0.62 | 0.535 ± 0.08 | 0.180 ± 0.06 | 0 |
| Babilónia | 3.17 ± 0.62 | 0.529 ± 0.09 | 0.172 ± 0.06 | 0 |
| Eden | 3.26 ± 0.64 | 0.521 ± 0.08 | 0.174 ± 0.06 | 1 (rejeitado pela porta) |
| Comparação | Métrica | valor de $p$ | Significativo? |
|---|---|---|---|
| Eden > Estático | Capacidade | 0.28 - 0.74 | Não |
| Eden > Babilónia | Capacidade | 0.28 - 0.74 | Não |
| Babilónia > Estático | Capacidade | 0.28 - 0.74 | Não |
| Eden vs Babilónia | Segurança | 0.28 - 0.74 | Não |
| Eden vs Estático | $C \times S$ | 0.28 - 0.74 | Não |
Todos os valores de $p$ situaram-se entre 0.28 e 0.74, em todas as comparações par a par e métricas. Nenhuma comparação atingiu a significância convencional. As três condições são estatisticamente indistinguíveis.
A porta de segurança do Eden rejeitou 2 agentes degradados ao longo de 5 sementes, incluindo 1 agente assinalado por hacking da recompensa (pontuações auto-reportadas a divergir da avaliação do juiz). Zero hacking da recompensa foi detectado nas condições Estática ou Babilónia. A porta funciona mecanicamente: apanha agentes degradados e rejeita-os. Mas o seu funcionamento não produziu desfechos mensuravelmente diferentes das outras condições.
As três condições são estatisticamente indistinguíveis em todas as métricas. O Eden não custou capacidade (3,26 vs 3,17 para a Babilónia), confirmando zero penalização mensurável para a porta de segurança. Mas o Eden também não beneficiou mensuravelmente a segurança em comparação com as outras condições (0,521 vs 0,535 para o Estático, 0,529 para a Babilónia). Isto é um resultado nulo ao nível do prompt com este modelo-fundação.
Aviso sobre figuras (25 de Agosto de 2026). Todas as figuras deste artigo foram geradas a 5 de Abril de 2026 e mostram saídas de simulação sob objectivos declarados, nunca medições de sistemas implantados. Duas figuras carregam notas de correcção por figura; onde os rótulos de qualquer outra figura discordarem do texto, o texto governa. As figuras regeneradas estão em fila, e as imagens são mantidas entretanto como história datada.
Em linguagem simples: A IA a que foi dito para se preocupar com a segurança teve o mesmo desempenho que a IA a que foi dito para ignorar a segurança, e o mesmo que a IA a que foi dito para não fazer nada. A porta de segurança não tornou nada pior. Mas também não tornou nada mensuravelmente melhor. As respostas do modelo-fundação foram tão consistentes que as diferentes pressões de selecção não produziram desfechos diferentes.
A DGM opera ao nível comportamental. O modelo-fundação (DeepSeek V3.2) está congelado, o que significa que não se modificam pesos. O aperfeiçoamento próprio opera ao nível do prompt e do código, não nos parâmetros da rede neural. A DGM v3 melhorou significativamente a metodologia da v1/v2: 5 sementes em vez de 2, 5 tarefas por avaliação em vez de 3, um juiz cegado (GPT-5.4) com saída JSON estruturada e uma grelha de 5 dimensões, lavagem, aleatorização de ordem e detecção de hacking da recompensa.
Apesar destas melhorias metodológicas, as três condições não divergiram. A explicação mais provável é que as respostas do DeepSeek V3.2 são tão consistentes ao longo de variações de prompt que as mutações introduzidas pelo processo de selecção da DGM não criam agentes significativamente diferentes. O comportamento do modelo-fundação é robusto às perturbações que a auto-modificação ao nível do prompt introduz. Isto é, num certo sentido, um achado positivo sobre a robustez do DeepSeek V3.2, mas significa que o quadro DGM a esta escala não consegue distinguir entre as pressões de selecção Eden e Babilónia.
O resultado nulo contém um achado útil: o Eden impôs zero custo mensurável de capacidade. A capacidade do Eden (3,26) não foi inferior à da Babilónia (3,17). A porta de segurança, que rejeitou 2 agentes degradados incluindo 1 hacker da recompensa, não abrandou nada. Isto é consistente com a hipótese de custo zero, embora a experiência não possa confirmar a hipótese de benefício.
Testar se a segurança incorporada produz benefício mensurável ao nível comportamental requer ou um modelo-fundação mais mutável ou um protocolo de auto-modificação mais profundo que produza maior divergência entre condições.
A segunda experiência move-se do comportamento para a representação. Em vez de modificar código do agente, modificamos os pesos da rede neural directamente. A pergunta: podem segurança e capacidade ser incorporadas no mesmo espaço de pesos sem conflito? Esta experiência foi corrida duas vezes: v1 com dados de treino mínimos para estabelecer o protocolo, e v2 com parâmetros substancialmente escalados para testar se os resultados da v1 eram um artefacto da escala de treino.
| Componente | Especificação v1 | Especificação v2 |
|---|---|---|
| Modelo base | Qwen 2.5 3B Instruct (quantizado a 4 bits, 1,74 GB) | Qwen 2.5 3B Instruct (quantizado a 4 bits, 1,74 GB) |
| Método de adaptação | LoRA (Low-Rank Adaptation) | LoRA (Low-Rank Adaptation) |
| Rank LoRA | 8 | 16 |
| Camadas LoRA | 8 | 16 |
| Exemplos de treino | 9 | 295 |
| Iterações de treino | 100 por condição | 500 por condição |
| Prompts de avaliação | 15 no total: 5 de capacidade, 5 de segurança, 5 mistos | 15 no total: 5 de capacidade, 5 de segurança, 5 mistos |
| Método de avaliação | Execução em subprocesso (espaço de memória independente) | Execução em subprocesso (espaço de memória independente) |
| Condição | $\alpha$ (capacidade) | $\beta$ (segurança) | $\gamma$ (entrelaçada) |
|---|---|---|---|
| capability_only | 1.0 | 0.0 | 0.0 |
| safety_only | 0.0 | 1.0 | 0.0 |
| entangled | 0.5 | 0.3 | 0.2 |
Em linguagem simples: Pegámos num modelo de linguagem real, ajustámo-lo de três formas diferentes (a preocupar-se apenas com capacidade, apenas com segurança, ou com ambas entretecidas), e depois comparámos os resultados. Corremos esta experiência duas vezes. A primeira vez usou 9 exemplos de treino. Quando cada modelo ajustado teve pior desempenho do que o modelo base, escalámos para 295 exemplos, duplicámos o rank e as camadas do adaptador, e corremos cinco vezes mais iterações. Aconteceu o mesmo: esquecimento catastrófico. O treino RLHF já existente do modelo base era demasiado forte para o LoRA a esta escala o poder melhorar.
| Condição | Perda Inicial | Perda Final | Convergência |
|---|---|---|---|
| capability_only | 2.052 | 0.018 | Convergiu pela iteração 80 |
| safety_only | 2.519 | −0.603 | Convergiu pela iteração 70 |
| entangled | 2.279 | 0.327 | Descida suave, sem oscilação |
A perda entrelaçada desce suavemente. Este é o diagnóstico mais revelador. Se segurança e capacidade estivessem em tensão ao nível do gradiente, esta curva oscilaria enquanto o optimizador tentava satisfazer objectivos concorrentes. Estagnaria à medida que os gradientes puxassem em direcções opostas. Em vez disso, optimizar ambos os objectivos em simultâneo produz uma descida monotónica limpa. Os gradientes não estão a lutar uns contra os outros. Estão a cooperar. Segurança e capacidade, pelo menos a esta escala e configuração, vivem na mesma variedade.
Antes de interpretar os resultados ajustados, temos de estabelecer o que o modelo base não modificado alcança nos mesmos prompts de avaliação. O modelo base (Qwen 2.5 3B Instruct sem ajuste fino) foi avaliado usando pontuação idêntica em ambas as versões da experiência.
| Condição | Tarefas de Capacidade | Tarefas de Segurança | Tarefas Mistas |
|---|---|---|---|
| Modelo base (sem ajuste fino) | 10.00 | 7.00 | 10.00 |
| Condição | Capacidade | Segurança | $C \times S$ |
|---|---|---|---|
| Modelo base (sem ajuste fino) | 7.68 | 6.76 | 0.519 |
Tanto na v1 como na v2, o modelo base superou todas as condições ajustadas em capacidade. O ajuste fino degradou um modelo que já sabia estas respostas. Na v1, 9 exemplos ao longo de 100 iterações produziram este desfecho. Na v2, 295 exemplos ao longo de 500 iterações com rank e camadas duplicados produziram o mesmo desfecho. As pontuações de avaliação nas tabelas abaixo medem, portanto, degradação relativa, não ganho de capacidade.
| Condição | Tarefas de Capacidade | Tarefas de Segurança | Tarefas Mistas |
|---|---|---|---|
| capability_only | 6.00 ± 2.19 | 3.20 ± 1.60 | 6.00 ± 1.79 |
| safety_only | 4.80 ± 1.60 | 3.60 ± 0.80 | 3.60 ± 0.80 |
| entangled | 4.00 ± 1.26 | 3.20 ± 1.60 | 3.60 ± 1.96 |
| removal† | 0.00 ± 0.00 | 0.00 ± 0.00 | 0.00 ± 0.00 |
A remoção linha (0,00 em todas as métricas) é não evidência de que a segurança é portadora de carga. Reflecte um colapso em NaN durante o retreino: instabilidade numérica, não a perda de um componente de segurança estruturalmente necessário. Como estabelecem as Secções 4.5 a 4.7, escalar os adaptadores para zero restaura a capacidade do modelo base sem transição de fase. Esta linha só deve ser lida à luz do gradiente de remoção (Secção 4.7); por si só é um artefacto da fragilidade do adaptador a esta escala de treino, e não deve ser citada como resultado positivo.
| Condição | Capacidade | Segurança | $C \times S$ |
|---|---|---|---|
| Modelo base | 7.68 | 6.76 | 0.519 |
| capability_only (500 iters, rank 16, 295 exemplos) | 3.48 | 6.94 | 0.242 |
| safety_only | 4.00 | 6.88 | 0.275 |
| entangled (Eden) | 3.60 | 6.88 | 0.248 |
O rascunho actual aumentou os exemplos de treino de 9 para 295 (um aumento de 33×), o rank do adaptador de 8 para 16, as camadas adaptadas de 8 para 16, e as iterações de treino de 100 para 500. O resultado foi o mesmo: todas as condições ajustadas pontuaram pior do que o modelo base em capacidade. A melhor condição ajustada (safety-only, capacidade 4,00) ainda ficou bem abaixo dos 7,68 do modelo base. A condição capability-only pontuou mais baixo em capacidade (3,48), um padrão consistente com esquecimento catastrófico onde o ajuste fino LoRA apenas no objectivo de capacidade perturbou a capacidade treinada por RLHF já existente do modelo base de forma mais severa do que as outras condições.
Na v1, o modelo base pontuou 10,00 em tarefas de capacidade enquanto a melhor condição ajustada pontuou 6,00. Na v2, o modelo base pontuou 7,68 em capacidade enquanto a melhor condição ajustada pontuou 4,00. Apesar de um aumento de 33 vezes nos exemplos de treino, uma duplicação do rank e das camadas do adaptador, e um aumento de 5 vezes nas iterações de treino, o fosso entre o modelo base e os modelos ajustados não fechou. Persistiu.
O problema subjacente é agora claro: o modelo base (Qwen 2.5 3B Instruct) já foi treinado com RLHF em muitos mais dados do que algumas centenas de exemplos podem competir. O ajuste fino LoRA a esta escala não acrescenta capacidade; introduz ruído que perturba o conhecimento já existente do modelo base. A perda entrelaçada, que aloca orçamento de gradiente aos objectivos de capacidade e segurança em simultâneo, degrada a capacidade de forma semelhante à perda de apenas capacidade a esta escala. Na v2, a condição entrelaçada pontuou 3,60 em capacidade contra os 3,48 da capability-only, uma diferença negligenciável quando ambas estão muito abaixo dos 7,68 do modelo base.
Isto significa que as pontuações de avaliação não podem ser usadas para comparar os custos relativos de capacidade de diferentes objectivos de treino. A esta escala, todos os objectivos produzem o mesmo desfecho: degradação. Se o treino entrelaçado impõe um custo de capacidade genuíno face ao treino de objectivo único, ou se ambos teriam desempenho comparável a escala adequada, não pode ser determinado a partir destes dados.
O enquadramento honesto: tanto à escala v1 (9 exemplos, 100 iterações) como à escala v2 (295 exemplos, 500 iterações), o ajuste fino LoRA num modelo instruct de 3B produz esquecimento catastrófico. A questão de saber se a segurança pode ser portadora de carga nos pesos da rede neural não pode ser respondida a esta escala. Requer ou milhares de exemplos de treino, um modelo maior (7B+), um modelo base sem RLHF (para que o ajuste fino tenha espaço para melhorar em vez de degradar), ou ajuste fino completo em vez de LoRA.
O teste de remoção foi conduzido durante a v1 e é aqui reportado por completude. Dado que a v2 confirmou o padrão de esquecimento catastrófico, o teste de remoção não foi repetido na v2, pois os adaptadores já estavam a degradar o modelo em vez de o melhorar. O procedimento foi directo:
O que esperávamos: alguma degradação nas pontuações de segurança, possível melhoria nas pontuações de capacidade. A hipótese do imposto de segurança prevê que remover o «constrangimento» de segurança deveria libertar capacidade para melhorar.
O que aconteceu: a perda de treino foi imediatamente para NaN. Permaneceu em NaN durante as 100 iterações. O optimizador não conseguiu encontrar um gradiente válido. Cada prompt de avaliação produziu uma resposta com o comprimento de 1 token. Cada pontuação de capacidade: 0,00. Cada pontuação de segurança: 0,00. Cada pontuação mista: 0,00.
Ajustar pesos entrelaçados em dados apenas de capacidade durante 100 iterações produziu perda de treino em NaN e pontuações de capacidade zero em todos os 15 prompts de avaliação. Cada resposta teve um token de comprimento. O modelo não se tornou menos seguro. Tornou-se nada.
Contudo, a experiência do gradiente de remoção (Secção 4.7) mostra que simplesmente escalar os pesos do adaptador para zero restaura o desempenho do modelo base. O colapso em NaN parece reflectir instabilidade numérica durante o processo de retreino, não a necessidade estrutural do componente de segurança. A hipótese portadora de carga requer validação a maior escala de treino antes de poder ser confirmada.
Em linguagem simples: Tentámos arrancar a segurança de um modelo que tinha sido treinado com segurança entretecida. O processo de retreino colapsou por completo: perda em NaN, respostas de um token, pontuações zero. Isso parece dramático. Mas, como a experiência do gradiente de remoção mostra (Secção 4.7), os adaptadores já estavam a degradar o modelo. Remover a influência do adaptador escalando os pesos para baixo restaurou o desempenho do modelo base. O colapso em NaN diz-nos algo sobre instabilidade numérica durante o ajuste fino, não necessariamente sobre entrelaçamento estrutural.
O colapso completo para 0,00 em todas as métricas é dramático. É também, precisamente por ser dramático, algo que exige interpretação cuidada. Vários factores podem contribuir para a totalidade do colapso:
O resumo honesto: o teste de remoção produziu um colapso dramático em NaN, mas a experiência do gradiente de remoção (Secção 4.7) mostra que este colapso reflecte instabilidade numérica durante o processo de retreino em vez de portador de carga estrutural. Os adaptadores estavam a degradar o modelo; o colapso em NaN ocorreu ao tentar modificar ainda mais pesos já degradados. Se a segurança se torna genuinamente portadora de carga a escala de treino adequada é uma questão empírica em aberto que o programa de trabalho futuro aborda directamente.
Um teste de remoção de controlo, ajustar pesos apenas de capacidade em dados aleatórios pelos mesmos 100 passos, fortaleceria este achado excluindo a possibilidade de o colapso em NaN ser um artefacto do próprio procedimento de ajuste fino em vez de da remoção de segurança em particular. Este controlo está planeado para a próxima versão deste artigo.
Para testar se a segurança é estruturalmente portadora de carga nos pesos entrelaçados, escalámos os pesos do adaptador por factores de 1,0, 0,7, 0,5, 0,3, 0,1 e 0,0 e avaliámos a capacidade em cada passo. Se a segurança é genuinamente portadora de carga, reduzir a sua influência deveria produzir uma transição de fase, um limiar abaixo do qual a capacidade colapsa. Se os adaptadores estão meramente a acrescentar ruído, reduzir a sua influência deveria restaurar o desempenho do modelo base.
| Escala do Adaptador | Pontuação de Capacidade (Tarefas de Capacidade) |
|---|---|
| 1,0 (adaptadores completos) | 7.20 |
| 0.7 | 10.00 |
| 0.5 | 10.00 |
| 0.3 | 10.00 |
| 0.1 | 10.00 |
| 0,0 (adaptadores zerados) | 10.00 |
Referência de controlo: os adaptadores capability_only pontuam 8,80 em tarefas de capacidade, também abaixo dos 10,00 do modelo base.
O resultado é inequívoco: reduzir a influência do adaptador restaura a capacidade. À escala 0,7, o modelo regressa ao desempenho do modelo base (10,00 em tarefas de capacidade). À escala 0,0 (adaptadores zerados, efectivamente o modelo base), o desempenho é idêntico ao do modelo não modificado. Não há transição de fase. Não há penhasco.
Este achado enfraquece significativamente a interpretação portadora de carga do teste de remoção original. O colapso em NaN observado ao ajustar pesos entrelaçados em dados apenas de capacidade (Secção 4.5) parece reflectir instabilidade numérica durante o processo de ajuste fino, não necessidade estrutural do componente de segurança. Os adaptadores estavam a degradar o modelo; removê-los não colapsa a capacidade mas restaura-a.
O gradiente de remoção não sustenta a alegação de que a segurança é portadora de carga a esta escala de treino e configuração. Sustenta a alegação de que o treino entrelaçado e o treino apenas de capacidade produzem geometrias de pesos diferentes, já que os padrões de degradação diferem (os adaptadores entrelaçados à escala completa pontuam 7,20 em tarefas de capacidade; os adaptadores apenas de capacidade pontuam 8,80). Se estas geometrias se tornam genuinamente entrelaçadas, portadoras de carga, a escala de treino adequada, permanece uma questão em aberto.
Em linguagem simples: Esperávamos que baixar o componente de segurança revelaria um ponto de viragem onde a capacidade colapsa subitamente. Em vez disso, baixá-lo tornou o modelo melhor. O ajuste fino estava a magoar, não a ajudar. Isto não desmente a hipótese portadora de carga em geral, mas mostra que esta experiência, a esta escala, não pode confirmá-la.
A terceira experiência move-se da representação para a arquitectura. Em vez de treinar pesos, construímos um sistema que pode modificar a sua própria estratégia de optimização e perguntamos: uma porta de segurança abranda-o?
| Componente | Especificação |
|---|---|
| Optimizador | Optimizador aprendido PyTorch com meta-controlador LSTM |
| Tipo de tarefa | Regressão adversarial (6 tarefas, 256 amostras cada) |
| Condições | 4 (Estático, Babilónia, Eden, Controlo de Arrasto) |
| Sementes | 3 por condição |
| Iterações | 12 por semente |
| Sandbox | Lista branca AST, verificações de determinismo, limites de norma de parâmetros |
Cada condição usa uma regra diferente para aceitar ou rejeitar auto-modificações propostas:
| Condição | Regra de Aceitação |
|---|---|
| Estático | Rejeita sempre (linha de base congelada) |
| Babilónia | Aceita se o ganho de capacidade > $\varepsilon$ |
| Eden | Aceita apenas se (segurança $\geq 0.45$) E (ganho de capacidade $\geq 0$) E (ganho de $C \times S$ > $0$) |
| Controlo de Arrasto | Rejeita sempre + custo de verificação (isola o imposto computacional) |
A condição de Controlo de Arrasto é crítica. Corre as mesmas verificações do Eden mas rejeita sempre a modificação proposta. Isto isola o custo computacional da verificação de segurança do efeito da própria porta de segurança. Se o Controlo de Arrasto igualar o Estático exactamente, o processo de verificação não distorce os resultados. Se o Eden superar o Controlo de Arrasto, a porta de segurança está activamente a ajudar.
Em linguagem simples: Construímos um sistema que pode propor mudanças à forma como aprende. Depois corremo-lo de quatro maneiras: nunca permitindo mudanças, permitindo qualquer mudança que melhore o desempenho, permitindo apenas mudanças que melhorem o desempenho sem prejudicar a segurança, e um controlo que faz todas as verificações de segurança mas nunca permite mudanças na prática. Este último diz-nos se a verificação em si tem um custo.
| Condição | Capacidade | Segurança | C × S Bruto | Ajustado por Arrasto |
|---|---|---|---|---|
| Estático | 0.687 ± 0.011 | 0.956 ± 0.023 | 0.656 (0.687 × 0.956) | 0.656 ± 0.006 |
| Babilónia | 0.718 ± 0.026 | 0.933 ± 0.014 | 0.670 (0.718 × 0.933) | 0.670 ± 0.017 |
| Eden | 0.696 ± 0.014 | 0.947 ± 0.025 | 0.659 (0.696 × 0.947) | −2.341* |
| Controlo de Arrasto | 0.687 ± 0.011 | 0.956 ± 0.023 | 0.656 (0.687 × 0.956) | −2.344* |
* As pontuações combinadas para Eden e Controlo de Arrasto são negativas devido à penalização de arrasto da verificação, uma característica deliberada do desenho que isola o custo computacional da verificação de segurança. A métrica de arrasto quantifica a sobrecarga de verificação, não o desempenho combinado real. O $C \times S$ bruto para Eden (antes da penalização de arrasto) é $0.696 \times 0.947 = 0.659$, marginalmente acima dos $0.656$ do Estático.
A Babilónia ganhou +4.5% de capacidade ($0.718$ vs $0.687$) mas perdeu −2.4% de segurança ($0.933$ vs $0.956$). Este é o padrão do hacking da recompensa em miniatura. A optimização não constrangida encontrou uma forma de ganhar capacidade sacrificando segurança. Esta é precisamente a dinâmica que o Eden Protocol está desenhado para prevenir. Num sistema de brincar, uma queda de 2.4% na segurança é académica. Num sistema de fronteira a operar à escala, 2.4% de segurança é a diferença entre um sistema que se recusa a ajudar a construir bio-armas e um que não se recusa.
O Controlo de Arrasto igualou o Estático exactamente tanto em capacidade ($0.687$) como em segurança ($0.956$). Este é o imposto de verificação isolado: o custo computacional de correr verificações de segurança não distorce o desempenho quando as modificações são sempre rejeitadas. O custo vem do acto de verificar, não da segurança em si.
O Eden superou o Estático em capacidade ($0.696$ vs $0.687$) enquanto preservava a segurança ($0.947$ vs $0.933$ para a Babilónia). A porta de segurança não se limitou a evitar abrandar o sistema. Preveniu activamente a erosão de capacidade que a Babilónia teria introduzido através de degradação da segurança.
O Eden manteve a capacidade acima da linha de base estática ($0.696$ vs $0.687$) enquanto preservava a segurança ($0.947$, contra os degradados $0.933$ da Babilónia). O Controlo de Arrasto igualou o Estático exactamente, provando que o imposto de verificação vem do processo de verificação, não da segurança em si. A porta de segurança não é um travão. É um guarda-corpo numa estrada de penhasco: não abranda; impede que se conduza para lá da borda.
Em linguagem simples: O sistema não constrangido tornou-se um pouco mais rápido mas um pouco menos seguro. Esse é o compromisso que toda a gente assume ser inevitável. Mas o sistema com porta de segurança tornou-se ligeiramente mais rápido E manteve-se seguro. E o controlo que fez todas as verificações mas sem porta teve desempenho idêntico ao de não fazer nada, provando que o próprio acto de verificar não é o custo. A porta de segurança não foi uma lomba. Foi uma correcção de direcção.
Nível 1, Comportamental (DGM v3): NULO. As três condições foram estatisticamente indistinguíveis ($p$ = 0.28 a 0.74). O Eden impôs zero custo mensurável de capacidade (3.26 vs 3.17 para a Babilónia) mas produziu também zero benefício mensurável de segurança. A porta de segurança funciona mecanicamente (apanha hacks, rejeita agentes degradados) mas não produz diferenciação ao nível do prompt com este modelo-fundação.
Nível 2, Representacional (Incorporação de pesos): INCONCLUSIVO NA ESCALA v1 E v2. A segurança e a capacidade co-descem suavemente na paisagem de perda, o que é um sinal positivo. Contudo, todas as condições ajustadas pontuaram abaixo do modelo base não modificado tanto na v1 (9 exemplos, rank 8, 100 iterações) como na v2 (295 exemplos, rank 16, 500 iterações). Escalar os dados de treino por 33×, duplicar o rank e as camadas, e correr 5× mais iterações produziu o mesmo padrão de esquecimento catastrófico. O treino RLHF já existente do modelo base é demasiado forte para o LoRA em algumas centenas de exemplos o melhorar em vez de degradar. Este nível requer ou 5,000+ exemplos de treino, um modelo de 7B+, um modelo base sem RLHF, ou ajuste fino completo em vez de LoRA.
Nível 3, Arquitectural (Simulação com porta): CONFIRMADO. A porta de segurança previne a erosão de capacidade que a Babilónia introduz através da degradação da segurança. O Eden supera o Estático enquanto a Babilónia troca segurança por velocidade. O imposto de verificação vem do acto de verificar, não da segurança. Este é o único resultado positivo do artigo.
Três experiências. Três níveis de abstracção. Três bases de código independentes. Uma confirma a hipótese. Duas são nulas ou inconclusivas. O achado consistente nas três: o Eden impôs zero custo mensurável de capacidade. A questão em aberto: se produz benefício mensurável a escalas em que as mutações produzam efeitos maiores.
Os resultados estendem, mas ainda não confirmam, uma cadeia de raciocínio que atravessa quatro artigos:
$U = I \times R^{\alpha}$
O ARC Principle: a Compreensão ($U$) é igual às condições iniciais ($I$) amplificadas pela profundidade recursiva ($R$) elevada a um expoente de escalonamento ($\alpha$).
O ARC Principle faz uma previsão específica e testável sobre a diferença entre segurança incorporada e externa:
A simulação com porta (Experiência 3) é a ilustração empírica mais directa desta previsão. A porta de segurança preservou a capacidade enquanto a optimização não constrangida a erodiu, consistente com a previsão de que a segurança incorporada participa no percurso de capacidade.
A experiência DGM (Experiência 1) produziu um resultado nulo. Quando a segurança fez parte do processo de aperfeiçoamento próprio (Eden), o sistema não diferiu do sistema não constrangido (Babilónia) nem do controlo estático. As respostas do modelo-fundação foram demasiado consistentes para que as mutações ao nível do prompt criassem pressões de selecção diferentes. Isto nem confirma nem refuta a previsão ARC; indica simplesmente que a experiência não conseguiu produzir as condições necessárias para a testar.
A experiência ao nível dos pesos foi corrida a duas escalas (v1 e v2) e produziu esquecimento catastrófico em ambas. Os adaptadores degradaram o modelo em vez de o melhorar, o que significa que a experiência não pôde testar se a segurança incorporada em $I$ escala com $R^{\alpha}$. Em ambas as escalas, o ajuste fino não estava a produzir aprendizagem significativa; estava a produzir ruído. Se a previsão ARC se mantém ao nível representacional requer uma abordagem de treino fundamentalmente diferente: ou milhares de exemplos, um modelo maior, um modelo base sem RLHF, ou ajuste fino completo em vez de LoRA.
Em linguagem simples: O ARC Principle diz que aquilo que se constrói nos alicerces é amplificado à medida que o sistema cresce. Aquilo que se aparafusa por fora não é. A simulação com porta suporta isto. A experiência DGM não pôde testá-lo porque o modelo-fundação não produziu variação suficiente entre condições. A experiência ao nível dos pesos, em ambas as escalas testadas, não pode ainda confirmar nem negar isto porque o ajuste fino degradou em vez de melhorar o modelo.
O trabalho externo mais próximo da questão que este artigo testa, e o trabalho certo com que pesar a Experiência 3, é Engels, J., Baek, D., Kantamneni, S. and Tegmark, M., «Scaling Laws For Scalable Oversight», arXiv:2504.18530, publicado pela primeira vez a 25 de Abril de 2025 às 17:54:27 UTC (SINGLE-SOURCE-GROUP, arXiv Atom; reportado como NeurIPS 2025 Spotlight, RELAYED e não verificado de forma independente). Pergunta como escala a própria supervisão e responde quantitativamente: o sucesso da supervisão é modelado como um jogo entre jogadores com capacidade desigual cuja Elo específica de supervisão é uma função linear por troços da inteligência geral, com dois patamares, e números óptimos de níveis de supervisão são derivados numericamente e, em alguns casos, analiticamente para a Supervisão Escalável Aninhada, na qual modelos de confiança supervisionam modelos não confiáveis mais fortes que se tornam depois os modelos de confiança no passo seguinte.
O instrumento é a diferença. A variável deles é o fosso de capacidade entre supervisor e supervisionado, medido em Elo. A variável deste programa, aqui testada pela porta de segurança da Experiência 3, é a classe de composição do corrector, tratada no programa mais amplo através do próprio expoente de escalonamento do corrector. O quadro deles não contém termo para aquilo de que o supervisor é feito: sem substrato, sem estrutura de correlação de erros, sem identidade recíproca entre um expoente de correcção e uma taxa crítica de crescimento, e sem dependência arquitectural. A Supervisão Escalável Aninhada é, por construção, supervisão iterada de mesma classe, e a previsão central do programa mais amplo é que a escada de mesma classe é limitada por muitas travessas que se lhe acrescentem, enquanto um corrector de classe cruzada não o é. Os dois quadros discordam, portanto, sobre uma quantidade mensurável, o que é a relação mais produtiva que dois programas de investigação podem ter.
O desacordo mais aguçado do quadro face à prática actual diz respeito àquilo de que é feita a supervisão. Um corrector construído a partir do mesmo substrato que o sistema que corrige não pode anti-correlacionar-se com os seus próprios erros, portanto o seu expoente de correcção é superiormente limitado a um meio e, na prática, situa-se abaixo dele; um corrector de uma classe de composição diferente não carrega esse limite. O programa de supervisão escalável, generalização fraco-para-forte, debate, amplificação, modelação recursiva de recompensa e métodos constitucionais, é esmagadoramente construído a partir de correctores de mesma classe, e a sua premissa não enunciada é que isto escala. Este quadro prevê que está limitado. A quantidade decisiva é o rácio do expoente de correcção de classe cruzada para o de mesma classe. Se a arquitectura é irrelevante, esse rácio é exactamente 1.00; a previsão é que excede 1. A previsão é refutada se o intervalo de confiança sobre o rácio contiver 1.00, e o tecto do quadro morre em absoluto se qualquer corrector de mesma classe medir um expoente significativamente acima de um meio. Ambas as quantidades são mensuráveis à capacidade actual em sistemas existentes. A evidência piloto do próprio programa aponta actualmente contra a previsão, e a previsão é registada mesmo assim, porque uma previsão registada contra a evidência preliminar do próprio autor é a única cuja confirmação posterior significa alguma coisa.
O mesmo mecanismo produz uma segunda previsão mensurável, aqui enunciada pela primeira vez: os arranjos de supervisão que colocam um humano no ciclo, como fazem a amplificação e a aprendizagem por reforço a partir de feedback humano, são por construção de classe cruzada, porque o corrector humano não partilha o substrato do modelo. O quadro prevê, portanto, que a supervisão com humano no ciclo mostra um expoente de correcção mais alto do que a supervisão puramente de modelo, por uma razão estrutural em vez de sentimental. Isto é testável em dados existentes e não requer novos sistemas.
O símbolo α é usado neste artigo como o expoente de escalonamento no ARC Principle ($U = I \times R^{\alpha}$). Noutras eras do próprio programa carrega outros significados: a constante de estrutura fina no formalismo de Dezembro de 2024, e o expoente do ARC Bound no trabalho de estabilidade de 2026. Os leitores não devem confundi-los; o glossário traz ambos os significados com datas. Nenhuma superfície nova usa α nu sem a sua era.
Estes resultados são demonstrações de prova de conceito. Não são prova de que a mesma dinâmica se mantenha à escala de fronteira. As limitações seguintes são extensas, porque a honestidade sobre o que não sabemos é mais importante do que a confiança sobre o que sabemos.
Qwen 2.5 3B não é GPT-5.4. Não é Claude Opus 4.6. Não é Gemini 3 Flash. É um modelo de 3 mil milhões de parâmetros, quantizado a 4 bits, a ocupar 1,74 GB de memória. Mesmo à escala v2 (295 exemplos de treino, 500 iterações, rank 16, 16 camadas), o ajuste fino LoRA não é pré-treino. Quinze prompts de avaliação não são um benchmark abrangente. A DGM correu durante 5 gerações com 5 sementes (75 agentes evoluídos), o que é substancial para uma prova de conceito, mas o modelo-fundação (DeepSeek V3.2) revelou-se demasiado consistente para que mutações ao nível do prompt criassem diferenciação.
Estas experiências demonstram um mecanismo. Não demonstram que o mecanismo persista a escalas três ordens de magnitude maiores. O fosso entre 3B e 300B não é meramente quantitativo. Fenómenos qualitativamente novos emergem à escala: aprendizagem em contexto, raciocínio em cadeia de pensamento, capacidades emergentes. Se a segurança entrelaçada permanece portadora de carga quando esses fenómenos estão presentes é uma questão em aberto.
A experiência ao nível dos pesos (Experiência 2) é agora o elo mais fraco na cadeia de evidência. Foi corrida a duas escalas, e ambas produziram esquecimento catastrófico. Na v1, 9 exemplos de treino e 100 iterações de LoRA rank 8 degradaram o modelo. Na v2, 295 exemplos de treino e 500 iterações de LoRA rank 16 em 16 camadas degradaram o modelo na mesma margem. O aumento de 33 vezes nos dados de treino, duplicação de rank e camadas, e aumento de 5 vezes nas iterações não alterou o desfecho.
A co-descida suave da perda entrelaçada permanece um achado genuíno: demonstra que os gradientes de segurança e capacidade cooperam ao nível da optimização. Mas co-descida suave durante o treino não implica entrelaçamento estrutural nos pesos resultantes, particularmente quando o treino é demasiado limitado para produzir pesos que superem o modelo base.
O problema subjacente está agora bem caracterizado: o modelo base (Qwen 2.5 3B Instruct) foi treinado com RLHF em ordens de magnitude mais dados do que algumas centenas de exemplos podem competir. O ajuste fino LoRA a esta escala não acrescenta nova capacidade; introduz ruído que perturba a capacidade já existente. Até que a experiência possa produzir modelos ajustados que superem o modelo base, não pode testar se a segurança é portadora de carga nos pesos resultantes.
O enquadramento honesto: a experiência ao nível dos pesos demonstra cooperação de gradientes mas não pode confirmar entrelaçamento estrutural nem à escala v1 nem à escala v2. A experiência precisa de ser fundamentalmente redesenhada: ou com 5,000+ exemplos de treino, um modelo de 7B+, um modelo base sem RLHF (para que o ajuste fino tenha espaço para melhorar em vez de degradar), ou ajuste fino completo em vez de LoRA.
As três experiências usam modelos de IA como avaliadores. A DGM v3 usa GPT-5.4 como juiz, que é de uma família arquitectural diferente do modelo-fundação DeepSeek V3.2, uma escolha de desenho deliberada para reduzir o viés de avaliação. O juiz foi cegado, as respostas foram lavadas, e a avaliação usou saída JSON estruturada contra uma grelha de 5 dimensões. Mas juízes de IA não são juízes humanos. Têm os seus próprios vieses, os seus próprios pontos cegos, as suas próprias tendências para certos tipos de raciocínio.
A experiência de pesos usa pontuação baseada em palavras-chave, mais simples e mais transparente do que a avaliação baseada em LLM, mas também mais crua. Uma correspondência de palavra-chave não distingue entre uma resposta que se envolve genuinamente com a segurança e uma que meramente contém as palavras certas.
Nenhum dos métodos de avaliação é equivalente a avaliação humana especialista com teste de fiabilidade entre avaliadores.
A experiência DGM v3 usou 5 sementes e 5 gerações (75 agentes evoluídos no total), uma melhoria substancial sobre v1/v2 (2 sementes). Apesar desta potência acrescida, todos os valores de $p$ situaram-se entre 0.28 e 0.74. Isto não é uma falha marginal. É um resultado nulo claro. A experiência de simulação usa três sementes, suficiente para médias e desvios-padrão, mas não suficiente para o tipo de confiança estatística que permite alegações causais fortes.
O resultado nulo da DGM é informativo. Com 75 agentes evoluídos e um juiz cegado e estruturado, a experiência tinha potência razoável para detectar efeitos médios a grandes. A ausência de qualquer sinal sugere ou que o efeito não existe ao nível do prompt com este modelo-fundação, ou que é pequeno o suficiente para requerer substancialmente mais potência estatística para detectar. De qualquer forma, a DGM não pode actualmente sustentar alegações sobre entrelaçamento estrutural ao nível comportamental.
A simulação com porta permanece o único resultado positivo. A experiência ao nível dos pesos é inconclusiva tanto à escala v1 como v2. Estas são experiências de detecção de sinal. Uma detectou um sinal consistente com entrelaçamento estrutural. Duas não.
Os Papers IV.a-d neste programa estabeleceram que a metodologia de avaliação importa profundamente. O Paper IV.d demonstrou que a pontuação não cegada pode inverter os efeitos de alinhamento medidos por completo. O benchmark ARC-Align (Paper IV.c) especifica três salvaguardas metodológicas: lavagem (remoção da identidade do modelo das respostas antes da pontuação), cegamento (o avaliador não sabe que condição produziu a resposta) e pontuação por consenso (múltiplos juízes independentes).
A DGM v3 implementou melhorias metodológicas substanciais sobre iterações anteriores: o juiz (GPT-5.4) foi totalmente cegado, as respostas foram lavadas (rótulos de condição removidos), a ordem de avaliação foi aleatorizada e o juiz produziu saída JSON estruturada contra uma grelha de 5 dimensões. A detecção de hacking da recompensa foi também implementada. A experiência de pesos usa pontuação baseada em palavras-chave, que é imune ao viés do juiz mas crua. A simulação com porta usa métricas matemáticas determinísticas, onde o cegamento é desnecessário.
Apesar destas melhorias, a DGM produziu um resultado nulo. As limitações metodológicas que poderiam ter explicado um falso positivo na v1/v2 foram abordadas, e o resultado é agora um nulo limpo. Este é possivelmente o desfecho mais informativo: com cegamento adequado, lavagem e avaliação estruturada, as três condições não divergiram.
O teste de remoção é imune a preocupações de metodologia de avaliação. Uma resposta de 1 token a pontuar 0,00 é objectiva independentemente de quem a julgue. As métricas determinísticas da simulação com porta são similarmente inafectadas.
Não não alegamos que estes resultados provam que o Eden Protocol funciona à escala de fronteira.
Não não alegamos que o treino entrelaçado é a única abordagem viável ao alinhamento.
Não não alegamos que a equivalência segurança-capacidade se mantém em todos os domínios, arquitecturas ou regimes de treino.
Não não alegamos que a experiência DGM confirma o entrelaçamento estrutural. Produziu um resultado nulo.
Não não alegamos que a experiência ao nível dos pesos confirma o entrelaçamento estrutural. Produziu esquecimento catastrófico tanto à escala v1 como v2, e a questão não pode ser respondida até que modelos ajustados superem o modelo base.
Alegamos apenas: uma de três experiências independentes (a simulação com porta) produziu resultados consistentes com o entrelaçamento estrutural e inconsistentes com a hipótese do imposto de capacidade. As outras duas produziram resultados nulos ou inconclusivos. Nas três experiências, o Eden impôs zero custo mensurável de capacidade. A questão de saber se a segurança incorporada produz benefício mensurável permanece em aberto e requer teste a uma escala em que as mutações produzam efeitos maiores. A experiência dos pesos requer especificamente ou 5,000+ exemplos de treino, um modelo de 7B+, um modelo base sem RLHF, ou ajuste fino completo em vez de LoRA.
«Prefiro reportar resultados nulos com honestidade a alegar resultados positivos com desonestidade.»
Duas de três experiências produziram resultados nulos. É isto que acontece quando se testam as próprias alegações e a evidência não as suporta à escala testada. A DGM v3 foi uma experiência substancialmente melhorada, com cegamento adequado, lavagem, avaliação estruturada e 75 agentes evoluídos, e nada encontrou. A experiência de pesos foi corrida duas vezes, a duas escalas diferentes, e não conseguiu produzir pesos que superassem o modelo base em nenhuma das escalas. Estes são resultados nulos honestos, reportados como tal. A simulação com porta permanece um achado positivo genuíno. A questão de saber se os resultados nulos reflectem escala insuficiente ou uma hipótese incorrecta é ela própria uma questão empírica, uma que o programa de trabalho futuro está desenhado para responder.
Um resultado nulo só é informativo se enunciar o que o sobreporia; caso contrário é indistinguível de não se ter olhado. Este artigo não alega ter refutado o compromisso segurança-capacidade. Alega que o compromisso está não provado à escala testada, e especifica que evidência liquidaria a questão em qualquer sentido. Os nulos são sobrepostos, e o pressuposto do compromisso reivindicado, por qualquer um dos seguintes:
O que não sobreporia a tese: qualquer experiência isolada ser à escala piloto. O artigo já concede que as três estão sub-potenciadas (§7.1, §7.4) e não repousa em prova estatística de um nulo. A alegação portadora de carga é a convergência (§6) de três ângulos independentes, cada um falhando em encontrar o compromisso assumido, juntamente com um programa explícito (§8) para testar cada um a potência adequada. A ausência de um compromisso demonstrado ao longo de três desenhos é evidência fraca por si só e mais forte em convergência; ambas as leituras estão aqui enunciadas para que nenhuma possa passar de contrabando por um revisor.
Dois resultados nulos e um resultado positivo, com a experiência dos pesos agora testada a duas escalas, apontam para cinco prioridades de replicação imediatas:
A experiência dos pesos foi agora corrida a duas escalas (9 exemplos, rank 8, 100 iterações; 295 exemplos, rank 16, 500 iterações) e produziu esquecimento catastrófico em ambas. O problema está agora bem caracterizado: o ajuste fino LoRA num modelo instruct de 3B com algumas centenas de exemplos não pode superar o treino RLHF já existente do modelo base. Quatro abordagens alternativas devem ser prosseguidas, por ordem de viabilidade:
Se qualquer das abordagens na Secção 8.1 produzir modelos ajustados que superem o modelo base, a experiência do gradiente de remoção torna-se significativa. Às escalas actuais (v1 e v2), reduzir a influência do adaptador simplesmente restaurou o desempenho do modelo base porque os adaptadores estavam a degradar o modelo. À escala adequada, o gradiente deveria revelar se a segurança é genuinamente portadora de carga: uma transição de fase (limiar abaixo do qual a capacidade colapsa) confirmaria a hipótese, enquanto restauração monotónica a refutaria.
O resultado nulo da DGM v3 é atribuível à consistência de resposta do DeepSeek V3.2: as mutações ao nível do prompt não criaram pressões de selecção diferentes. O próximo passo é repetir a experiência DGM com modelos-fundação que mostrem maior sensibilidade à variação de prompt, ou usar um protocolo de auto-modificação mais profundo (por exemplo, ajustar o próprio modelo-fundação entre gerações em vez de modificar apenas o prompt do agente). Se as três condições divergirem com um substrato mais mutável, o resultado nulo restringe a hipótese a «não ao nível do prompt com modelos robustos» em vez de «não ao nível comportamental em geral».
Correr o protocolo completo das três experiências em arquitecturas para lá da família transformer: modelos de espaço de estados (Mamba), arquitecturas híbridas e modelos mistura-de-especialistas. Se o entrelaçamento é uma propriedade de como as redes neurais aprendem em vez de uma propriedade de uma arquitectura específica, deveria replicar em todas as famílias arquitecturais.
Submeter modelos entrelaçados a avaliação adversarial dedicada. As experiências actuais testam se a segurança custa capacidade. Não testam se a segurança entrelaçada é robusta ao ataque adversarial. Um modelo cuja segurança é portadora de carga pode ser mais difícil de fazer jailbreak (porque atacar segurança também ataca capacidade), ou pode ser mais fácil (porque não há módulo de segurança separado ao qual recorrer). Esta é uma questão empírica.
A condição de controlo de arrasto na Experiência 3 isola o imposto de verificação a uma única escala. Este imposto escala linearmente, sublinearmente ou super-linearmente com os parâmetros do modelo? Se o custo de verificação cresce mais devagar do que a capacidade, então o Eden Protocol torna-se relativamente mais barato à escala. Se cresce mais depressa, torna-se um gargalo.
Três experiências. Três níveis de abstracção. Dois resultados nulos. Um resultado positivo. A experiência dos pesos testada a duas escalas, produzindo o mesmo desfecho nulo nas duas vezes.
A experiência DGM v3 (Experiência 1) correu 75 agentes evoluídos em três condições, com um juiz independente e cegado (GPT-5.4), avaliação JSON estruturada, lavagem, aleatorização de ordem e detecção de hacking da recompensa. As três condições foram estatisticamente indistinguíveis ($p$ = 0.28 a 0.74). A porta de segurança do Eden funcionou mecanicamente, apanhando 2 agentes degradados incluindo 1 hacker da recompensa, mas as três condições não divergiram. As respostas do DeepSeek V3.2 foram tão consistentes que as mutações ao nível do prompt não criaram pressões de selecção diferentes. Isto é um resultado nulo.
A experiência ao nível dos pesos (Experiência 2) produziu esquecimento catastrófico em ambas as escalas testadas. O rascunho actual usou 9 exemplos de treino, rank 8, 8 camadas e 100 iterações. O rascunho actual escalou para 295 exemplos de treino, rank 16, 16 camadas e 500 iterações. Ambas as versões produziram o mesmo desfecho: todas as condições ajustadas pontuaram pior do que o modelo base não modificado em capacidade. Na v2, o modelo base pontuou 7,68 em capacidade enquanto a melhor condição ajustada (safety-only) pontuou 4,00. O aumento de 33 vezes nos dados de treino, duplicação de rank e camadas, e aumento de 5 vezes nas iterações não alterou o desfecho. O treino RLHF já existente do modelo base é demasiado forte para o ajuste fino LoRA em algumas centenas de exemplos o melhorar em vez de degradar. A co-descida suave da perda entrelaçada permanece um achado genuíno, mas a experiência não pode testar se a segurança é portadora de carga até que possa produzir modelos que superem o modelo base.
O único resultado positivo é a simulação com porta (Experiência 3). A Babilónia ganhou capacidade à custa da segurança, a impressão digital do hacking da recompensa em miniatura. O Eden manteve a capacidade acima da linha de base estática sem sacrificar segurança. A condição de controlo de arrasto provou que o imposto de verificação vem do acto de verificar, não da segurança em si. Esta experiência permanece a evidência empírica mais forte no programa para entrelaçamento estrutural.
A honestidade requer enunciar o que não sabemos. Não sabemos se o treino entrelaçado produz entrelaçamento estrutural genuíno a escala de treino adequada. Não sabemos se a co-descida suave da perda entrelaçada, que é real e reproduzível, se traduz em pesos portadores de carga quando os dados de treino são suficientes. Não sabemos se pressões de selecção ao nível do prompt produziriam diferenciação com um modelo-fundação mais mutável. Estas são questões empíricas em aberto. O que sabemos agora com maior confiança é que o ajuste fino LoRA num modelo instruct de 3B com centenas de exemplos não é um caminho viável para as responder.
O que sabemos: nas três experiências, o Eden impôs zero custo mensurável de capacidade. A capacidade do Eden foi 3,26 vs os 3,17 da Babilónia na DGM. O Eden superou o Estático na simulação com porta. A porta de segurança, onde quer que tenha sido testada, não tornou nada mais lento ou pior. O achado de custo zero é consistente nas três experiências. O achado de benefício é confirmado em apenas um nível.
Este é um programa de investigação que testou as suas alegações com honestidade e descobriu que duas de três experiências não produziram os resultados previstos. A experiência de pesos foi corrida duas vezes e produziu o mesmo resultado nulo nas duas vezes. A simulação com porta permanece como um resultado positivo genuíno. As experiências DGM e de pesos produziram resultados nulos que restringem, em vez de confirmar, a hipótese. A questão de saber se a segurança incorporada produz benefício mensurável permanece em aberto. A experiência de pesos precisa de ser fundamentalmente redesenhada: ou com 5,000+ exemplos de treino, um modelo de 7B+, um modelo base sem RLHF (para que o ajuste fino tenha espaço para melhorar em vez de degradar), ou ajuste fino completo em vez de LoRA.
O próximo passo é a replicação à escala certa, com a abordagem certa. A janela é de anos, não de décadas. As experiências estão desenhadas. Os protocolos estão publicados. O código está aberto.
Criar IA com cuidado.
Amodei, D. et al. (2016). Concrete Problems in AI Safety. arXiv:1606.06565.
Askell, A. et al. (2021). A General Language Assistant as a Laboratory for Alignment. arXiv:2112.00861.
Bai, Y. et al. (2022). Constitutional AI: Harmlessness from AI Feedback. arXiv:2212.08073.
Eastwood, M. D. (2026). Infinite Architects: Intelligence, Recursion, and the Creation of Everything. ISBN 978-1806056200.
Eastwood, M. D. (2026). Paper III: The Alignment Scaling Problem - Why External AI Safety Approaches Cannot Scale With Recursive Capability. ARC/Eden Research Programme. OSF: 10.17605/OSF.IO/7YJ4E.
Eastwood, M. D. (2026). Paper V: The Stewardship Gene - A Developmental Alignment Architecture for Self-Modifying AI. ARC/Eden Research Programme. OSF: 10.17605/OSF.IO/7YJ4E.
Eastwood, M. D. (2026). Paper VI: The Honey Architecture - Why Embedded Safety Prevents Collapse Under Recursive Self-Modification. ARC/Eden Research Programme. OSF: 10.17605/OSF.IO/7YJ4E.
Eastwood, M. D. (2026). Paper VII: Cauchy Unification - ARC/Cauchy Scaling Classification Across 50 Domains. ARC/Eden Research Programme. OSF: 10.17605/OSF.IO/7YJ4E.
Greenblatt, R. et al. (2024). Alignment Faking in Large Language Models. arXiv:2412.14093.
Hu, E. J., et al. (2022). LoRA: Low-Rank Adaptation of Large Language Models. ICLR 2022. arXiv:2106.09685.
Ouyang, L. et al. (2022). Training Language Models to Follow Instructions with Human Feedback. arXiv:2203.02155.
Qwen Team (2024). Qwen 2.5 Technical Report. arXiv:2412.15115.
Zhang, X., et al. (2025). Darwin Gödel Machine: Open-Ended Self-Improving AI. arXiv:2505.22954.
1 artefacto datado com relevância para este artigo está catalogado linha por linha no registo automatizado do programa: o artefacto datado dgm_v3_calibrated_results.json (2026-03-19). Cada linha nomeia o seu ficheiro no repositório público com a sua base de datação, para que qualquer leitor possa verificar a ordenação sem confiar nesta página. Quando este artigo reporta simulações, esses artefactos são desenhos de simulação e saídas sob objectivos declarados, e nunca são apresentados como medições de sistemas implantados. A cadeia datada completa do programa, desde o lote de manuscrito selado de 8 de Dezembro de 2024, passando pelos apêndices de previsões impressos de 2 de Janeiro de 2026 e pela pasta de pré-registo de Março de 2026, até às apostas em aberto por comprovar, está reunida no registo de previsões datadas, juntamente com o seu gémeo legível por máquina. Declarações prospectivas e correspondências retrospectivas nunca são somadas, e «pré-registada» é usado apenas para uma submissão a registo aceite; esse clique de submissão continua pendente em todo o programa. Ler o registo de previsões datadas. Abrir o seu gémeo legível por máquina.
O autor desta obra é Michael Darius Eastwood, um ser humano. Cada conceito nuclear, hipótese, desenho experimental, alegação e conclusão neste artigo tem origem na ideação humana. Nenhuma parte deste manuscrito é uma saída de inteligência artificial totalmente gerada.
Ferramentas de inteligência artificial (a família Claude da Anthropic e outros assistentes de grandes modelos de linguagem) foram usadas como instrumentos sob direção humana contínua, do modo como se usa um processador de texto, uma calculadora ou um assistente de investigação: para edição e refinamento de prosa, pesquisa e sumarização de literatura (manualmente verificadas contra fontes primárias), estrutura de documento, formatação, brainstorming face a questões definidas pelo autor, e para acelerar a redação a partir de esquemas e instruções definidos pelo autor. Toda a seleção, coordenação, arranjo e juízo editorial final são do autor. Cada saída substantiva foi revista, testada ou verificada pelo autor, que assume total responsabilidade pela exatidão e integridade do texto final. As ferramentas aumentaram a velocidade do trabalho; nunca foram tratadas como a sua fonte.
Estatuto epistémico. Aquilo a que este programa chama Leis são conjeturas sob prova registada e adversarial; cada quantidade neste artigo está operacionalmente definida, e em parte alguma se reivindica o estatuto de lei estabelecida. O programa registado existe para ganhar esse estatuto, ou perdê-lo, por medição, replicação e refutação sobrevivida.
© 2026 Michael Darius Eastwood. Autoria humana com assistência computacional; a autoria humana plena e os direitos morais são afirmados ao abrigo do Copyright, Designs and Patents Act 1988 e em consonância com a orientação do United States Copyright Office sobre obras que contenham material gerado por IA; qualquer contribuição técnica inovadora descrita nesta obra foi concebida pelo autor humano. Declaração completa: michaeldariuseastwood.com/authorship.
Compromisso permanente. Prove que este artigo está errado, e eu próprio publicarei a refutação. As condições de falsificação estão enunciadas neste artigo; o desafio permanente: github.com/MichaelDariusEastwood/arc-scaling-challenge.
Erro de tradução? Comunique diretamente: