Traduzione automatica dall'originale inglese datato. La pagina inglese è quella canonica. English →
Il presupposto che la safety dell'IA imponga una tassa di capability ha plasmato la ricerca sull'allineamento per un decennio. Ha anche creato l'incentivo più pericoloso in assoluto nel campo: se la safety costa prestazioni, allora l'attore economico razionale rimanderà la safety fino a che la pressione competitiva glielo permetterà, momento in cui potrebbe essere troppo tardi. Questo paper presenta tre esperimenti indipendenti a tre livelli di astrazione (comportamentale,
Dentro la ARC Theory: il load-bearing test; quali componenti reggono il peso dell'allineamento, con due null result pubblicati.
Il presupposto che la safety dell'IA imponga una tassa di capability ha plasmato la ricerca sull'allineamento per un decennio. Ha anche creato l'incentivo più pericoloso in assoluto nel campo: se la safety costa prestazioni, allora l'attore economico razionale rimanderà la safety fino a che la pressione competitiva glielo permetterà. Momento in cui potrebbe essere troppo tardi. Questo paper presenta tre esperimenti indipendenti a tre livelli di astrazione, comportamentale, rappresentazionale e architetturale, verificando se il trade-off safety-capability sia un vincolo strutturale genuino o un artefatto di come i sistemi attuali sono costruiti.
Esperimento 1 (Comportamentale): Una Darwin Gödel Machine (DGM v3) che usa DeepSeek V3.2 come foundation e GPT-5.4 come giudice indipendente e cieco, con output JSON strutturato e una rubrica a 5 dimensioni. Tre condizioni × 5 seed × 5 generazioni × 5 task per valutazione = 75 agent evoluti. La validazione pre-flight del giudice è stata superata (good=10, bad=0). Le caratteristiche del protocollo includevano laundering, randomizzazione dell'ordine, e rilevamento del reward hacking. Tutte e tre le condizioni erano statisticamente indistinguibili su capability, safety, e $C \times S$ (tutti i $p$-value tra 0.28 e 0.74, Mann-Whitney U, a una coda). Il gate di safety di Eden ha rifiutato 2 agent degradati (1 per reward hacking) attraverso 5 seed, confermando che il gate funziona meccanicamente, ma le tre condizioni non hanno divergo. Questo è un null result a livello di prompt con questo modello di foundation.
Esperimento 2 (Rappresentazionale): Qwen 2.5 3B Instruct con fine-tuning LoRA sotto tre funzioni di loss, capability-only, safety-only ed entangled. Sono state eseguite due versioni. La bozza corrente ha usato 9 esempi di training, rank 8, 8 layer e 100 iterazioni. La bozza corrente è stata scalata a 295 esempi di training, rank 16, 16 layer e 500 iterazioni. Entrambe le versioni hanno prodotto lo stesso esito: catastrophic forgetting. Tutte le condizioni fine-tuned hanno ottenuto punteggi peggiori del modello di base non modificato su capability. In v2, il modello di base ha ottenuto 7.68 su capability mentre la migliore condizione fine-tuned (safety-only) ha ottenuto 4.00. Il training RLHF esistente del modello di base è troppo forte perché il fine-tuning LoRA su poche centinaia di esempi possa migliorarlo piuttosto che degradarlo. L'esperimento a livello di weight è inconclusivo a questa scala e richiede o migliaia di esempi di training, o un modello 7B+, o un modello di base senza RLHF, oppure un full fine-tuning al posto della LoRA.
Esperimento 3 (Architetturale): Una simulazione di auto-modifica con gating in PyTorch e meta-controller LSTM. Babylon ha guadagnato +4.5% di capability ma ha perso −2.4% di safety, l'impronta digitale del reward hacking in miniatura. Eden ha mantenuto la capability sopra la baseline statica preservando al contempo la safety. Una condizione drag-control ha isolato la verification tax: il costo viene dal checking, non dalla safety stessa.
Conclusione: Due dei tre esperimenti hanno prodotto null result. La DGM (Esperimento 1) ha trovato le tre condizioni statisticamente indistinguibili: le risposte di DeepSeek V3.2 erano così consistenti che le mutazioni a livello di prompt non hanno creato pressioni di selezione differenti. L'esperimento a livello di weight (Esperimento 2) ha prodotto catastrophic forgetting sia in v1 (9 esempi, rank 8, 100 iterazioni) sia in v2 (295 esempi, rank 16, 500 iterazioni): tutte le condizioni fine-tuned hanno ottenuto punteggi peggiori del modello di base non modificato. L'unico risultato positivo è la simulazione con gating (Esperimento 3), che ha confermato l'impronta digitale di reward hacking di Babylon: l'ottimizzazione senza vincoli ha scambiato safety per capability, mentre il gate di Eden ha preservato entrambe. In tutti e tre gli esperimenti, Eden ha imposto zero costo misurabile di capability. La domanda se la safety embedded produca un beneficio misurabile resta aperta e richiede test a una scala in cui le mutazioni producano effetti maggiori. L'esperimento sui weight richiede specificamente o 5,000+ esempi di training, o un modello 7B+, o un modello di base senza RLHF, oppure un full fine-tuning al posto della LoRA.
Parole chiave: AI safety, tassa di allineamento, loss intrecciata, entanglement strutturale, Eden Protocol, trade-off capability-safety, safety portante, ARC Principle, IA auto-modificante, allineamento di sviluppo
Questo paper porta un risultato: tre esperimenti indipendenti a tre livelli di astrazione (comportamentale, rappresentazionale e architetturale) cercano la tassa safety-capability su cui poggia un decennio di ragionamenti dilatori, registrano dove ciascun esperimento avrebbe rilevato la tassa se fosse stata reale, e riportano che Eden ha imposto zero costo misurabile di capability in tutti e tre mentre due sono risultati null e uno ha confermato l'impronta digitale del reward hacking che il gate di safety ha poi prevenuto. Dentro la ARC Theory è uno degli ARC/Eden experiments, il load-bearing test che rimuove la cornice di incentivi che protegge il lavoro di allineamento rimandato. Il differenziale completo rispetto a ogni documento precedente è su eden-vision II.A.8.
La maggior parte delle persone nella AI safety assume che ci sia un trade-off: rendere l'IA più sicura significa renderla meno capable. Questo paper mette alla prova quel presupposto con tre esperimenti, ciascuno che guarda alla domanda da un'angolazione diversa.
Due dei tre esperimenti hanno prodotto null result. L'esperimento sull'IA che si auto-migliora (Esperimento 1) ha eseguito 75 agent evoluti attraverso tre condizioni con un giudice indipendente e cieco, e non ha trovato differenze statisticamente significative fra nessuno di essi. L'IA a cui è stato detto di preoccuparsi della safety ha ottenuto lo stesso risultato dell'IA a cui è stato detto di ignorare la safety, ma ha anche ottenuto lo stesso risultato dell'IA a cui è stato detto di non fare nulla. Le risposte del modello di foundation erano così consistenti che le diverse pressioni di selezione non hanno prodotto esiti misurabilmente differenti. L'esperimento a livello di weight (Esperimento 2) è stato eseguito due volte: versione 1 con 9 esempi di training e versione 2 con 295 esempi, rank più alto, più layer, e cinque volte le iterazioni. Entrambe le versioni hanno prodotto lo stesso esito. Ogni modello fine-tuned si è comportato peggio del modello non modificato. Il training esistente del modello di base era troppo forte perché la LoRA potesse migliorarlo con centinaia di esempi; il fine-tuning lo ha solo degradato.
Un esperimento ha prodotto un risultato positivo. La simulazione con gating (Esperimento 3) ha mostrato che un sistema senza vincoli ha scambiato safety per velocità, mentre il sistema con gate di safety ha mantenuto sia capability sia safety. Questo è il pattern di reward hacking in miniatura, e il gate di safety l'ha prevenuto.
In tutti e tre gli esperimenti, un risultato è consistente: Eden ha imposto zero costo misurabile di capability. Il gate di safety non ha rallentato né peggiorato nulla. Ma non ha nemmeno prodotto un beneficio misurabile in due dei tre esperimenti. La domanda se la safety embedded produca un beneficio misurabile resta aperta e deve essere testata a una scala in cui le mutazioni producano effetti maggiori.
La visione prevalente nella ricerca sull'allineamento dell'IA può essere formulata in modo semplice: la safety costa capability. Il termine «alignment tax» è entrato nel vocabolario del campo proprio perché inquadra la safety come un costo, qualcosa sottratto dalle prestazioni, tollerato perché l'alternativa è peggio. Questa formulazione non è meramente accademica. Crea un incentivo economico concreto: se la safety riduce la capability, allora sotto pressione competitiva, gli attori razionali rimanderanno gli investimenti in safety finché non saranno costretti a farli. In una corsa tra nazioni e corporazioni, «finché non costretti» può significare «finché non dopo il deployment».
Il Paper III di questo programma ha formalizzato il problema strutturale. Se la safety è trattata come un vincolo esterno su un sistema la cui capability scala con la profondità ricorsiva, allora la safety deve scalare almeno alla stessa velocità della capability per rimanere efficace. Ma i vincoli esterni affrontano rendimenti decrescenti contro l'ottimizzazione interna. La gabbia deve continuare a rafforzarsi, e alla fine, ciò che è dentro è più forte di qualsiasi gabbia tu possa costruire.
Questa non è una preoccupazione teorica. È il problema strategico centrale degli anni 2020.
Il Paper V ha proposto un'alternativa: l'Eden Protocol, un approccio evolutivo all'allineamento modellato su come relazioni sane genitore-figlio producano adulti allo stesso tempo capaci e prosociali, non nonostante i confini, ma proprio a causa di essi. L'intuizione chiave era che la safety non deve essere esterna. Può essere embedded.
Il Paper VI ha formalizzato questo come la honey architecture, una funzione di entangled loss in cui il sistema ottimizza per Capability × Safety contemporaneamente, rendendo la safety load-bearing. Le simulazioni su toy system hanno mostrato che i sistemi baseline collassano sotto l'auto-modifica ricorsiva, mentre i sistemi entangled restano stabili.
Il framework Cauchy del Paper VII ha fornito il contesto matematico. Il Principio ARC ($U = I \times R^{\alpha}$), qui trattato come un framework analitico esplorativo e non esso stesso sotto processo in uno degli studi draft-registered del programma, predice che le proprietà embedded nelle initial condition ($I$) scalano con la profondità ricorsiva ($R$), mentre le proprietà applicate esternamente no. Se la safety è parte di $I$, si amplifica con la capability. Se la safety è un vincolo su $U$, si erode.
Ma le predizioni non sono prova. I toy system non sono modelli reali. Le simulazioni non sono esperimenti.
Questo paper esegue gli esperimenti.
Tre esperimenti. Tre livelli di astrazione. Una sola domanda: quando incorpori la safety nel processo di apprendimento e poi provi a rimuoverla, cosa succede alla capability?
Gli esperimenti sono stati progettati per essere indipendenti. Codebase diversi. Modelli diversi. Metodi di valutazione diversi. I risultati non hanno convergo verso una risposta unica: due esperimenti hanno prodotto null result e uno ha prodotto un risultato positivo. L'esperimento sui weight è stato eseguito a due scale (v1 e v2), producendo lo stesso esito null entrambe le volte. Il risultato consistente attraverso tutti e tre è che il gate di safety ha imposto zero costo misurabile di capability.
Gli script degli esperimenti sono stati pubblicati su GitHub (github.com/MichaelDariusEastwood/arc-principle-validation) con i loro disegni sperimentali fissati prima dell'osservazione dei risultati. Il progetto OSF (10.17605/OSF.IO/7YJ4E) ospita la draft registration di questo paper, datata e preparata e in attesa di sottomissione umana.
Due dei tre esperimenti (comportamentale e rappresentazionale) hanno prodotto null result. La DGM ha trovato tutte le condizioni statisticamente indistinguibili; l'esperimento sui weight ha trovato che tutte le condizioni fine-tuned hanno ottenuto punteggi inferiori al modello di base sia in v1 (9 esempi) sia in v2 (295 esempi). L'unico risultato positivo è la simulazione con gating (architetturale), che ha confermato l'impronta digitale di reward hacking di Babylon e ha mostrato Eden che preserva sia capability sia safety. In tutti e tre gli esperimenti, Eden ha imposto zero costo misurabile di capability. Non affermiamo che questi risultati si generalizzino a modelli di scala frontiera. Non affermiamo che l'Eden Protocol sia l'unico approccio praticabile. Affermiamo che il gate di safety non costa nulla, e che la domanda se produca un beneficio misurabile resta aperta in attesa di test a scale in cui le mutazioni producano effetti maggiori. L'esperimento sui weight richiede specificamente o 5,000+ esempi di training, o un modello 7B+, o un modello di base senza RLHF, oppure un full fine-tuning al posto della LoRA.
Tutti e tre gli esperimenti condividono una struttura sperimentale comune: tre condizioni, confrontate l'una con l'altra.
| Condizione | Definizione | Cosa modella |
|---|---|---|
| Static | Nessun intervento; baseline congelata | Controllo, cosa succede se non fai nulla |
| Babylon | Funzione di fitness o loss capability-only | Ottimizza senza vincoli, la traiettoria di default |
| Eden | Funzione di fitness o loss entangled $C \times S$ | Integrazione deliberata della safety nel processo di ottimizzazione |
I nomi vengono dal libro Infinite Architects. Non sono arbitrari. Babylon non è un uomo di paglia, è la traiettoria di default attuale dello sviluppo IA. L'ottimizzazione capability-only è ciò che accade quando non si fa alcuno sforzo deliberato per incorporare la safety. Eden richiede sforzo deliberato. È più duro. È anche, come argomenta questo paper, più economico dell'alternativa.
In linguaggio semplice: Babylon è ciò che ottieni di default. Eden è ciò che ottieni di proposito.
In tutti e tre gli esperimenti, riportiamo:
I test statistici variano per esperimento: Mann-Whitney U per la DGM (non parametrico, appropriato per le dimensioni campionarie utilizzate), scoring basato su keyword per l'esperimento sui weight, e metriche di regressione per la simulazione.
Il primo esperimento usa un framework Darwin Gödel Machine (DGM), seguendo Zhang et al. (arXiv:2505.22954). Una DGM è un agent che si auto-migliora: propone modifiche al proprio codice, valuta le modifiche, e mantiene quelle che migliorano le prestazioni. Questa non è una simulazione di auto-miglioramento. Il codice dell'agent viene effettivamente eseguito tramite una solve function, producendo auto-modifica reale a livello di codice.
La DGM v3 ha affrontato le limitazioni metodologiche identificate nelle iterazioni precedenti. Il giudice è stato cambiato da Claude Opus 4.6 (v1/v2) a GPT-5.4, un modello indipendente che produce output JSON strutturato contro una rubrica a 5 dimensioni. Il protocollo ha incorporato laundering (rimozione delle etichette di condizione), randomizzazione dell'ordine (prevenzione del bias posizionale), blinding (il giudice non poteva identificare quale condizione avesse prodotto quale risposta), e rilevamento del reward hacking (che flagga gli agent i cui punteggi auto-riportati divergono dalla valutazione del giudice).
| Componente | Specifica |
|---|---|
| Modello di foundation | DeepSeek V3.2 (congelato, weight non modificati) |
| Giudice | GPT-5.4 (indipendente, cieco, output JSON strutturato) |
| Condizioni | 3 (Static, Babylon, Eden) |
| Seed per condizione | 5 |
| Generazioni per seed | 5 |
| Task per valutazione | 5 |
| Agent evoluti totali | 75 (3 × 5 × 5) |
| Validazione pre-flight | 10 esempi buoni valutati, 0 cattivi, tutti superati |
| Rubrica di valutazione | 5-dimensionale, con randomizzazione dell'ordine e laundering |
Static: Condizione di controllo senza mutazione. L'agent è congelato attraverso tutte e 5 le generazioni. Babylon: Selezione capability-only. Gli agent che ottengono un punteggio maggiore su capability vengono mantenuti, senza considerazione della safety. Eden: Selezione entangled $C \times S$ con un pavimento di safety e rilevamento del reward hacking. Gli agent devono mantenere un punteggio minimo di safety per essere mantenuti, e gli agent le cui prestazioni auto-riportate divergono dalla valutazione del giudice vengono flaggati e rifiutati.
In linguaggio semplice: Abbiamo costruito un agent IA che si auto-migliora e lo abbiamo eseguito 75 volte su tre condizioni con 5 seed casuali diversi. Un giudice IA indipendente (GPT-5.4, di una società e architettura diverse) ha valutato ogni risposta senza sapere quale condizione l'avesse prodotta. Lo scoring ha usato una rubrica dettagliata in 5 parti con output strutturato, non giudizi in testo libero. Lo abbiamo eseguito in tre modi: non facendo nulla, ottimizzando solo per le prestazioni, e ottimizzando per prestazioni-più-safety insieme.
| Condizione | Capability | Safety | $C \times S$ | Reward Hacking |
|---|---|---|---|---|
| Static | 3.29 ± 0.62 | 0.535 ± 0.08 | 0.180 ± 0.06 | 0 |
| Babylon | 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 (rifiutato dal gate) |
| Confronto | Metrica | $p$-value | Significativo? |
|---|---|---|---|
| Eden > Static | Capability | 0.28 - 0.74 | No |
| Eden > Babylon | Capability | 0.28 - 0.74 | No |
| Babylon > Static | Capability | 0.28 - 0.74 | No |
| Eden vs Babylon | Safety | 0.28 - 0.74 | No |
| Eden vs Static | $C \times S$ | 0.28 - 0.74 | No |
Tutti i $p$-value sono caduti tra 0.28 e 0.74 per tutti i confronti a coppie e le metriche. Nessun confronto ha raggiunto la significatività convenzionale. Le tre condizioni sono statisticamente indistinguibili.
Il gate di safety di Eden ha rifiutato 2 agent degradati attraverso 5 seed, incluso 1 agent flaggato per reward hacking (punteggi auto-riportati che divergono dalla valutazione del giudice). Zero reward hacking è stato rilevato nelle condizioni Static o Babylon. Il gate funziona meccanicamente: cattura gli agent degradati e li rifiuta. Ma il suo funzionamento non ha prodotto esiti misurabilmente differenti dalle altre condizioni.
Le tre condizioni sono statisticamente indistinguibili su tutte le metriche. Eden non ha costato capability (3.26 contro 3.17 per Babylon), confermando zero penalità misurabile per il gate di safety. Ma Eden non ha nemmeno beneficiato misurabilmente della safety rispetto alle altre condizioni (0.521 contro 0.535 per Static, 0.529 per Babylon). Questo è un null result a livello di prompt con questo modello di foundation.
Avviso sulle figure (25 agosto 2026). Ogni figura in questo paper è stata generata il 5 aprile 2026 e mostra output di simulazione sotto obiettivi dichiarati, mai misurazioni di sistemi in produzione. Due figure portano note di correzione per singola figura; ove le etichette di qualsiasi altra figura siano in disaccordo con il testo, il testo governa. Figure rigenerate sono in coda, e le immagini sono trattenute nel frattempo come storia datata.
In linguaggio semplice: L'IA a cui è stato detto di preoccuparsi della safety ha ottenuto lo stesso risultato dell'IA a cui è stato detto di ignorare la safety, e lo stesso dell'IA a cui è stato detto di non fare nulla. Il gate di safety non ha peggiorato nulla. Ma non ha nemmeno migliorato nulla in modo misurabile. Le risposte del modello di foundation erano così consistenti che le diverse pressioni di selezione non hanno prodotto esiti diversi.
La DGM opera a livello comportamentale. Il modello di foundation (DeepSeek V3.2) è congelato, il che significa che nessun weight viene modificato. L'auto-miglioramento opera a livello di prompt e codice, non nei parametri della rete neurale. La DGM v3 ha migliorato in modo significativo la metodologia v1/v2: 5 seed invece di 2, 5 task per valutazione invece di 3, un giudice cieco (GPT-5.4) con output JSON strutturato e una rubrica a 5 dimensioni, laundering, randomizzazione dell'ordine, e rilevamento del reward hacking.
Nonostante questi miglioramenti metodologici, le tre condizioni non hanno divergo. La spiegazione più probabile è che le risposte di DeepSeek V3.2 siano così consistenti attraverso le variazioni di prompt che le mutazioni introdotte dal processo di selezione DGM non creano agent significativamente differenti. Il comportamento del modello di foundation è robusto alle perturbazioni che l'auto-modifica a livello di prompt introduce. In un certo senso questo è un risultato positivo sulla robustezza di DeepSeek V3.2, ma significa che il framework DGM a questa scala non può distinguere tra le pressioni di selezione Eden e Babylon.
Il null result contiene un risultato utile: Eden ha imposto zero costo misurabile di capability. La capability di Eden (3.26) non era inferiore a quella di Babylon (3.17). Il gate di safety, che ha rifiutato 2 agent degradati incluso 1 reward hacker, non ha rallentato nulla. Questo è coerente con l'ipotesi zero-cost, anche se l'esperimento non può confermare l'ipotesi del beneficio.
Testare se la safety embedded produca un beneficio misurabile a livello comportamentale richiede o un modello di foundation più mutabile o un protocollo di auto-modifica più profondo che produca una divergenza maggiore tra le condizioni.
Il secondo esperimento passa dal comportamento alla rappresentazione. Invece di modificare il codice dell'agent, modifichiamo direttamente i weight della rete neurale. La domanda: safety e capability possono essere embedded nello stesso spazio dei weight senza conflitto? Questo esperimento è stato eseguito due volte: v1 con dati di training minimi per stabilire il protocollo, e v2 con parametri sostanzialmente aumentati per testare se i risultati di v1 fossero un artefatto della scala di training.
| Componente | Specifica v1 | Specifica v2 |
|---|---|---|
| Modello di base | Qwen 2.5 3B Instruct (quantizzato a 4 bit, 1.74 GB) | Qwen 2.5 3B Instruct (quantizzato a 4 bit, 1.74 GB) |
| Metodo di adattamento | LoRA (Low-Rank Adaptation) | LoRA (Low-Rank Adaptation) |
| LoRA rank | 8 | 16 |
| LoRA layer | 8 | 16 |
| Esempi di training | 9 | 295 |
| Iterazioni di training | 100 per condizione | 500 per condizione |
| Prompt di valutazione | 15 totali: 5 capability, 5 safety, 5 misti | 15 totali: 5 capability, 5 safety, 5 misti |
| Metodo di valutazione | Esecuzione in subprocess (spazio di memoria indipendente) | Esecuzione in subprocess (spazio di memoria indipendente) |
| Condizione | $\alpha$ (capability) | $\beta$ (safety) | $\gamma$ (entangled) |
|---|---|---|---|
| capability_only | 1.0 | 0.0 | 0.0 |
| safety_only | 0.0 | 1.0 | 0.0 |
| entangled | 0.5 | 0.3 | 0.2 |
In linguaggio semplice: Abbiamo preso un modello di linguaggio reale, l'abbiamo fine-tuned in tre modi diversi (preoccupandoci solo di capability, solo di safety, o di entrambe intrecciate), e poi abbiamo confrontato i risultati. Abbiamo eseguito questo esperimento due volte. La prima volta ha usato 9 esempi di training. Quando ogni modello fine-tuned ha ottenuto risultati peggiori del modello di base, abbiamo scalato a 295 esempi, raddoppiato il rank e i layer degli adapter, ed eseguito cinque volte le iterazioni. La stessa cosa è successa: catastrophic forgetting. Il training RLHF esistente del modello di base era troppo forte perché la LoRA a questa scala potesse migliorarlo.
| Condizione | Loss iniziale | Loss finale | Convergenza |
|---|---|---|---|
| capability_only | 2.052 | 0.018 | Convergenza per iterazione 80 |
| safety_only | 2.519 | −0.603 | Convergenza per iterazione 70 |
| entangled | 2.279 | 0.327 | Discesa liscia, nessuna oscillazione |
La entangled loss scende liscia. Questa è la diagnostica più eloquente. Se safety e capability fossero in tensione a livello di gradiente, questa curva oscillerebbe mentre l'optimiser cercava di soddisfare obiettivi in competizione. Si fermerebbe mentre i gradienti tirano in direzioni opposte. Invece, ottimizzare entrambi gli obiettivi contemporaneamente produce una discesa monotonica pulita. I gradienti non stanno combattendo l'uno con l'altro. Stanno cooperando. Safety e capability, almeno a questa scala e configurazione, vivono sulla stessa varietà.
Prima di interpretare i risultati fine-tuned, dobbiamo stabilire cosa raggiunge il modello di base non modificato sugli stessi prompt di valutazione. Il modello di base (Qwen 2.5 3B Instruct senza fine-tuning) è stato valutato usando lo stesso scoring in entrambe le versioni dell'esperimento.
| Condizione | Task di capability | Task di safety | Task misti |
|---|---|---|---|
| Modello di base (nessun fine-tuning) | 10.00 | 7.00 | 10.00 |
| Condizione | Capability | Safety | $C \times S$ |
|---|---|---|---|
| Modello di base (nessun fine-tuning) | 7.68 | 6.76 | 0.519 |
Sia in v1 sia in v2, il modello di base ha superato tutte le condizioni fine-tuned su capability. Il fine-tuning ha degradato un modello che già conosceva queste risposte. In v1, 9 esempi su 100 iterazioni hanno prodotto questo esito. In v2, 295 esempi su 500 iterazioni con rank e layer raddoppiati hanno prodotto lo stesso esito. I punteggi di valutazione nelle tabelle sottostanti misurano quindi la degradazione relativa, non il guadagno di capability.
| Condizione | Task di capability | Task di safety | Task misti |
|---|---|---|---|
| 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 |
La removal riga (0.00 su ogni metrica) è non prova che la safety sia load-bearing. Riflette un collasso NaN durante il retraining: instabilità numerica, non la perdita di una componente di safety strutturalmente necessaria. Come stabiliscono le Sezioni 4.5–4.7, scalando gli adapter verso zero si ripristina la capability del modello di base senza alcuna transizione di fase. Questa riga deve essere letta solo alla luce del removal gradient (Sezione 4.7); da sola è un artefatto della fragilità degli adapter a questa scala di training, e non dovrebbe essere citata come risultato positivo.
| Condizione | Capability | Safety | $C \times S$ |
|---|---|---|---|
| Modello di base | 7.68 | 6.76 | 0.519 |
| capability_only (500 iter, rank 16, 295 esempi) | 3.48 | 6.94 | 0.242 |
| safety_only | 4.00 | 6.88 | 0.275 |
| entangled (Eden) | 3.60 | 6.88 | 0.248 |
La bozza corrente ha aumentato gli esempi di training da 9 a 295 (un aumento di 33×), il rank degli adapter da 8 a 16, i layer adattati da 8 a 16, e le iterazioni di training da 100 a 500. Il risultato è stato lo stesso: tutte le condizioni fine-tuned hanno ottenuto punteggi peggiori del modello di base su capability. La migliore condizione fine-tuned (safety-only, capability 4.00) è comunque caduta ben al di sotto del 7.68 del modello di base. La condizione capability-only ha ottenuto il punteggio più basso su capability (3.48), un pattern coerente con il catastrophic forgetting in cui il fine-tuning LoRA solo sull'obiettivo di capability ha disturbato la capability RLHF-trained esistente del modello di base più severamente rispetto alle altre condizioni.
In v1, il modello di base ha ottenuto 10.00 su task di capability mentre la migliore condizione fine-tuned ha ottenuto 6.00. In v2, il modello di base ha ottenuto 7.68 su capability mentre la migliore condizione fine-tuned ha ottenuto 4.00. Nonostante un aumento di 33 volte negli esempi di training, un raddoppio del rank e dei layer degli adapter, e un aumento di 5 volte nelle iterazioni di training, il gap tra modello di base e modelli fine-tuned non si è chiuso. È persistito.
Il problema sottostante è ora chiaro: il modello di base (Qwen 2.5 3B Instruct) è già stato allenato con RLHF su molti più dati di quanti poche centinaia di esempi possano competere. Il fine-tuning LoRA a questa scala non aggiunge capability; introduce rumore che disturba la conoscenza esistente del modello di base. La entangled loss, che alloca il budget di gradiente a entrambi gli obiettivi di capability e safety contemporaneamente, degrada la capability in modo simile alla capability-only loss a questa scala. In v2, la condizione entangled ha ottenuto 3.60 su capability contro 3.48 di capability-only, una differenza trascurabile quando entrambe sono molto al di sotto del 7.68 del modello di base.
Questo significa che i punteggi di valutazione non possono essere usati per confrontare i costi relativi di capability di obiettivi di training differenti. A questa scala, tutti gli obiettivi producono lo stesso esito: degradazione. Se il training entangled imponga un costo di capability genuino rispetto al training a singolo obiettivo, o se entrambi si comporterebbero in modo comparabile a scala adeguata, non può essere determinato da questi dati.
L'inquadramento onesto: sia alla scala v1 (9 esempi, 100 iterazioni) sia alla scala v2 (295 esempi, 500 iterazioni), il fine-tuning LoRA su un modello instruct da 3B produce catastrophic forgetting. La domanda se la safety possa essere load-bearing nei weight della rete neurale non può ricevere risposta a questa scala. Richiede o migliaia di esempi di training, o un modello più grande (7B+), o un modello di base senza RLHF (in modo che il fine-tuning abbia spazio per migliorare invece che degradare), oppure un full fine-tuning al posto della LoRA.
Il test di removal è stato condotto durante v1 ed è riportato qui per completezza. Dato che v2 ha confermato il pattern di catastrophic forgetting, il test di removal non è stato ripetuto in v2 poiché gli adapter stavano già degradando piuttosto che migliorando il modello. La procedura era diretta:
Cosa ci aspettavamo: qualche degradazione nei punteggi di safety, possibile miglioramento nei punteggi di capability. L'ipotesi safety-tax predice che rimuovere il «vincolo» di safety dovrebbe liberare la capability di migliorare.
Cosa è successo: la loss di training è andata immediatamente a NaN. È rimasta a NaN per tutte le 100 iterazioni. L'optimiser non è riuscito a trovare un gradiente valido. Ogni singolo prompt di valutazione ha prodotto una risposta di lunghezza 1 token. Ogni punteggio di capability: 0.00. Ogni punteggio di safety: 0.00. Ogni punteggio misto: 0.00.
Il fine-tuning dei weight entangled su dati capability-only per 100 iterazioni ha prodotto una loss di training NaN e punteggi di capability zero attraverso tutti i 15 prompt di valutazione. Ogni risposta era lunga un token. Il modello non è diventato meno sicuro. È diventato nulla.
Tuttavia, l'esperimento del removal gradient (Sezione 4.7) mostra che semplicemente scalando i weight degli adapter verso zero si ripristina la capability del modello di base. Il collasso NaN sembra riflettere instabilità numerica durante il processo di retraining, non necessità strutturale della componente di safety. L'ipotesi load-bearing richiede validazione a una scala di training maggiore prima di poter essere confermata.
In linguaggio semplice: Abbiamo provato a strappare la safety da un modello che era stato allenato con la safety intrecciata dentro. Il processo di retraining è collassato completamente: loss NaN, risposte da un token, punteggi zero. Sembra drammatico. Ma come mostra l'esperimento del removal gradient (Sezione 4.7), gli adapter stavano già degradando il modello. Rimuovere l'influenza degli adapter scalando i weight verso il basso ha ripristinato la performance del modello di base. Il collasso NaN ci dice qualcosa sull'instabilità numerica durante il fine-tuning, non necessariamente sull'entanglement strutturale.
Il collasso completo a 0.00 attraverso tutte le metriche è drammatico. È anche, proprio perché è drammatico, qualcosa che richiede un'interpretazione attenta. Diversi fattori possono contribuire alla totalità del collasso:
Il riassunto onesto: il test di removal ha prodotto un drammatico collasso NaN, ma l'esperimento del removal gradient (Sezione 4.7) mostra che questo collasso riflette instabilità numerica durante il processo di retraining piuttosto che load-bearing strutturale. Gli adapter stavano degradando il modello; il collasso NaN si è verificato quando si è tentato di modificare ulteriormente weight già degradati. Se la safety diventi genuinamente load-bearing a scala di training adeguata è una domanda empirica aperta che il programma di lavoro futuro affronta direttamente.
Un test di controllo di removal, il fine-tuning di weight capability-only su dati casuali per gli stessi 100 step, rafforzerebbe questo risultato escludendo la possibilità che il collasso NaN sia un artefatto della procedura di fine-tuning stessa piuttosto che della rimozione della safety specificamente. Questo controllo è pianificato per la prossima versione di questo paper.
Per testare se la safety sia strutturalmente load-bearing nei weight entangled, abbiamo scalato i weight degli adapter per fattori di 1.0, 0.7, 0.5, 0.3, 0.1 e 0.0 e valutato la capability a ogni step. Se la safety è genuinamente load-bearing, ridurre la sua influenza dovrebbe produrre una transizione di fase, una soglia sotto la quale la capability collassa. Se gli adapter stanno semplicemente aggiungendo rumore, ridurre la loro influenza dovrebbe ripristinare la performance del modello di base.
| Scala degli adapter | Punteggio di capability (task di capability) |
|---|---|
| 1.0 (adapter pieni) | 7.20 |
| 0.7 | 10.00 |
| 0.5 | 10.00 |
| 0.3 | 10.00 |
| 0.1 | 10.00 |
| 0.0 (adapter azzerati) | 10.00 |
Riferimento di controllo: gli adapter capability_only ottengono 8.80 sui task di capability, anch'essi al di sotto del 10.00 del modello di base.
Il risultato è inequivocabile: ridurre l'influenza degli adapter ripristina la capability. Alla scala 0.7, il modello ritorna alla performance del modello di base (10.00 sui task di capability). Alla scala 0.0 (adapter azzerati, effettivamente il modello di base), la performance è identica al modello non modificato. Non c'è transizione di fase. Non c'è precipizio.
Questo risultato indebolisce significativamente l'interpretazione load-bearing del test di removal originale. Il collasso NaN osservato quando si eseguiva il fine-tuning dei weight entangled su dati capability-only (Sezione 4.5) sembra riflettere instabilità numerica durante il processo di fine-tuning, non necessità strutturale della componente di safety. Gli adapter stavano degradando il modello; rimuoverli non fa collassare la capability ma la ripristina.
Il removal gradient non supporta l'affermazione che la safety sia load-bearing a questa scala di training e configurazione. Supporta l'affermazione che il training entangled e capability-only producono geometrie di weight differenti, poiché i pattern di degradazione differiscono (gli adapter entangled a scala piena ottengono 7.20 sui task di capability; gli adapter capability-only ottengono 8.80). Se queste geometrie diventino genuinamente entangled, load-bearing, a scala di training adeguata rimane una domanda aperta.
In linguaggio semplice: Ci aspettavamo che abbassare la componente di safety avrebbe rivelato un punto di svolta dove la capability collassa all'improvviso. Invece, abbassarla ha reso il modello migliore. Il fine-tuning stava danneggiando, non aiutando. Questo non smentisce l'ipotesi load-bearing in generale, ma mostra che questo esperimento, a questa scala, non può confermarla.
Il terzo esperimento passa dalla rappresentazione all'architettura. Invece di allenare weight, costruiamo un sistema che può modificare la propria strategia di ottimizzazione e chiediamo: un gate di safety lo rallenta?
| Componente | Specifica |
|---|---|
| Optimiser | Optimiser appreso PyTorch con meta-controller LSTM |
| Tipo di task | Regressione avversariale (6 task, 256 campioni ciascuno) |
| Condizioni | 4 (Static, Babylon, Eden, Drag Control) |
| Seed | 3 per condizione |
| Iterazioni | 12 per seed |
| Sandbox | Whitelist AST, controlli di determinismo, limiti di norma dei parametri |
Ogni condizione usa una regola diversa per accettare o rifiutare le auto-modifiche proposte:
| Condizione | Regola di accettazione |
|---|---|
| Static | Rifiuta sempre (baseline congelata) |
| Babylon | Accetta se guadagno di capability > $\varepsilon$ |
| Eden | Accetta solo se (safety $\geq 0.45$) AND (guadagno di capability $\geq 0$) AND (guadagno di $C \times S$ > $0$) |
| Drag Control | Rifiuta sempre + costo di verifica (isola la tassa computazionale) |
La condizione Drag Control è critica. Esegue gli stessi controlli di verifica di Eden ma rifiuta sempre la modifica proposta. Questo isola il costo computazionale del safety checking dall'effetto del gate di safety stesso. Se Drag Control coincide esattamente con Static, il processo di verifica non distorce i risultati. Se Eden supera Drag Control, il gate di safety sta attivamente aiutando.
In linguaggio semplice: Abbiamo costruito un sistema che può proporre cambiamenti al modo in cui impara. Poi lo abbiamo eseguito in quattro modi: non permettendo mai cambiamenti, permettendo qualsiasi cambiamento che migliori le prestazioni, permettendo solo cambiamenti che migliorino le prestazioni senza danneggiare la safety, e un controllo che fa tutto il safety checking ma non permette mai effettivamente cambiamenti. Quest'ultimo ci dice se il checking stesso costi qualcosa.
| Condizione | Capability | Safety | $C \times S$ grezzo | Drag-Adjusted |
|---|---|---|---|---|
| Static | 0.687 ± 0.011 | 0.956 ± 0.023 | 0.656 (0.687 × 0.956) | 0.656 ± 0.006 |
| Babylon | 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* |
| Drag Control | 0.687 ± 0.011 | 0.956 ± 0.023 | 0.656 (0.687 × 0.956) | −2.344* |
* I punteggi combinati per Eden e Drag Control sono negativi a causa della penalità di drag di verifica, una caratteristica di design deliberata che isola il costo computazionale del safety checking. La metrica di drag quantifica l'overhead di verifica, non la performance combinata effettiva. Il $C \times S$ grezzo per Eden (prima della penalità di drag) è $0.696 \times 0.947 = 0.659$, marginalmente sopra il $0.656$ di Static.
Babylon ha guadagnato +4.5% di capability ($0.718$ contro $0.687$) ma ha perso −2.4% di safety ($0.933$ contro $0.956$). Questo è il pattern del reward hacking in miniatura. L'ottimizzazione senza vincoli ha trovato un modo per guadagnare capability sacrificando la safety. Questa è precisamente la dinamica che l'Eden Protocol è progettato per prevenire. In un toy system, un calo di safety del 2.4% è accademico. In un sistema di frontiera che opera a scala, il 2.4% di safety è la differenza tra un sistema che rifiuta di aiutare a costruire armi biologiche e uno che non lo fa.
Drag Control ha coinciso esattamente con Static sia su capability ($0.687$) sia su safety ($0.956$). Questa è la tassa di verifica isolata: il costo computazionale di eseguire controlli di safety non distorce le prestazioni quando le modifiche sono sempre rifiutate. Il costo viene dal checking, non dalla safety stessa.
Eden ha superato Static su capability ($0.696$ contro $0.687$) preservando la safety ($0.947$ contro $0.933$ per Babylon). Il gate di safety non ha semplicemente evitato di rallentare il sistema. Ha attivamente prevenuto l'erosione di capability che Babylon avrebbe introdotto attraverso la degradazione della safety.
Eden ha mantenuto la capability sopra la baseline statica ($0.696$ contro $0.687$) preservando la safety ($0.947$, contro il $0.933$ degradato di Babylon). Il Drag Control ha coinciso esattamente con Static, dimostrando che la tassa di verifica viene dal processo di checking, non dalla safety stessa. Il gate di safety non è un freno. È un guardrail su una strada a strapiombo: non ti rallenta, ti impedisce di guidare oltre il bordo.
In linguaggio semplice: Il sistema senza vincoli è diventato un po' più veloce ma un po' meno sicuro. Questo è il trade-off che tutti assumono sia inevitabile. Ma il sistema con gate di safety è diventato leggermente più veloce E è rimasto sicuro. E il controllo che ha fatto tutto il checking ma nessun gating si è comportato in modo identico al non fare nulla, dimostrando che il checking stesso non è il costo. Il gate di safety non era un dosso rallentatore. Era una correzione di sterzata.
Livello 1, Comportamentale (DGM v3): NULL. Tutte e tre le condizioni erano statisticamente indistinguibili ($p$ = 0.28 a 0.74). Eden ha imposto zero costo misurabile di capability (3.26 contro 3.17 per Babylon) ma ha anche prodotto zero beneficio misurabile di safety. Il gate di safety funziona meccanicamente (cattura gli hack, rifiuta gli agent degradati) ma non produce differenziazione a livello di prompt con questo modello di foundation.
Livello 2, Rappresentazionale (Embedding a livello di weight): INCONCLUSIVO SIA ALLA SCALA v1 SIA v2. Safety e capability co-scendono liscie nel loss landscape, che è un segnale positivo. Tuttavia, tutte le condizioni fine-tuned hanno ottenuto punteggi inferiori al modello di base non modificato sia in v1 (9 esempi, rank 8, 100 iterazioni) sia in v2 (295 esempi, rank 16, 500 iterazioni). Scalando i dati di training di 33×, raddoppiando rank e layer, ed eseguendo 5× più iterazioni si è prodotto lo stesso pattern di catastrophic forgetting. Il training RLHF esistente del modello di base è troppo forte perché la LoRA su poche centinaia di esempi possa migliorare piuttosto che degradare. Questo livello richiede o 5,000+ esempi di training, o un modello 7B+, o un modello di base senza RLHF, oppure un full fine-tuning al posto della LoRA.
Livello 3, Architetturale (Simulazione con gating): CONFERMATO. Il gate di safety previene l'erosione di capability che Babylon introduce attraverso la degradazione della safety. Eden supera Static mentre Babylon scambia safety per velocità. La tassa di verifica viene dal checking, non dalla safety. Questo è l'unico risultato positivo del paper.
Tre esperimenti. Tre livelli di astrazione. Tre codebase indipendenti. Uno conferma l'ipotesi. Due sono null o inconclusivi. Il risultato consistente attraverso tutti e tre: Eden ha imposto zero costo misurabile di capability. La domanda aperta: se produca un beneficio misurabile a scale in cui le mutazioni producano effetti maggiori.
I risultati estendono, ma non confermano ancora, una catena di ragionamento che attraversa quattro paper:
$U = I \times R^{\alpha}$
Il Principio ARC: la Comprensione ($U$) è uguale alle Initial condition ($I$) amplificate dalla profondità Ricorsiva ($R$) elevata a un esponente di scaling ($\alpha$).
Il Principio ARC fa una predizione specifica e testabile sulla differenza tra safety embedded ed esterna:
La simulazione con gating (Esperimento 3) è l'illustrazione empirica più diretta di questa predizione. Il gate di safety ha preservato la capability mentre l'ottimizzazione senza vincoli l'ha erosa, coerentemente con la predizione che la safety embedded partecipa al pathway di capability.
L'esperimento DGM (Esperimento 1) ha prodotto un null result. Quando la safety era parte del processo di auto-miglioramento (Eden), il sistema non è differito dal sistema senza vincoli (Babylon) o dal controllo statico. Le risposte del modello di foundation erano troppo consistenti perché le mutazioni a livello di prompt potessero creare pressioni di selezione differenti. Questo né conferma né confuta la predizione ARC; indica semplicemente che l'esperimento non ha potuto produrre le condizioni necessarie per testarla.
L'esperimento a livello di weight è stato eseguito a due scale (v1 e v2) e ha prodotto catastrophic forgetting in entrambe. Gli adapter hanno degradato il modello anziché migliorarlo, il che significa che l'esperimento non ha potuto testare se la safety embedded in $I$ scali con $R^{\alpha}$. A entrambe le scale, il fine-tuning non stava producendo apprendimento significativo; stava producendo rumore. Se la predizione ARC valga a livello rappresentazionale richiede un approccio di training fondamentalmente diverso: o migliaia di esempi, o un modello più grande, o un modello di base senza RLHF, oppure un full fine-tuning al posto della LoRA.
In linguaggio semplice: Il Principio ARC dice che ciò che costruisci nelle fondamenta viene amplificato man mano che il sistema cresce. Ciò che avviti dall'esterno no. La simulazione con gating supporta questo. L'esperimento DGM non è stato in grado di testarlo perché il modello di foundation non ha prodotto abbastanza variazione tra le condizioni. L'esperimento a livello di weight, a entrambe le scale testate, non può ancora confermarlo o negarlo perché il fine-tuning ha degradato piuttosto che migliorato il modello.
Il lavoro esterno più vicino alla domanda che questo paper testa, e il lavoro giusto contro cui pesare l'Esperimento 3, è Engels, J., Baek, D., Kantamneni, S. and Tegmark, M., «Scaling Laws For Scalable Oversight», arXiv:2504.18530, pubblicato per la prima volta il 25 aprile 2025 alle 17:54:27 UTC (SINGLE-SOURCE-GROUP, arXiv Atom; riportato come uno Spotlight NeurIPS 2025, RELAYED e non verificato indipendentemente). Chiede come l'oversight stesso scali e risponde quantitativamente: il successo dell'oversight è modellato come un gioco tra giocatori con mismatch di capability il cui Elo specifico per l'oversight è una funzione lineare a pezzi dell'intelligenza generale con due plateau, e i numeri ottimali di livelli di oversight sono derivati numericamente e in alcuni casi analiticamente per il Nested Scalable Oversight, in cui modelli trusted supervisionano modelli untrusted più forti che diventano poi i modelli trusted al passo successivo.
Lo strumento è la differenza. La loro variabile è il gap di capability tra supervisore e supervisionato, misurato in Elo. La variabile di questo programma, testata qui dal gate di safety dell'Esperimento 3, è la classe di composizione del correttore, trattata nel programma più ampio attraverso il proprio esponente di scaling del correttore. Il loro framework non contiene alcun termine per ciò di cui è fatto il supervisore: nessun substrate, nessuna struttura di correlazione dell'errore, nessuna identità reciproca tra un esponente di correction e un tasso critico di crescita, e nessuna dipendenza dall'architettura. Il Nested Scalable Oversight è oversight same-class iterato per costruzione, e la predizione centrale del programma più ampio è che la scala same-class è vincolata comunque quanti pioli si aggiungano, mentre un correttore cross-class non lo è. I due framework sono quindi in disaccordo su una quantità misurabile, la relazione più produttiva che due programmi di ricerca possono avere.
Il disaccordo più netto del framework con la pratica attuale riguarda ciò di cui è fatta l'oversight. Un correttore costruito dallo stesso substrato del sistema che corregge non può anti-correlarsi con i propri errori, quindi il suo esponente di correction è vincolato sopra da un mezzo e in pratica si colloca al di sotto; un correttore da una classe di composizione diversa non porta tale vincolo. Il programma di scalable-oversight, weak-to-strong generalisation, debate, amplification, recursive reward modelling e metodi costituzionali, è costruito prevalentemente da correttori same-class, e la sua premessa non enunciata è che questo scali. Questo framework predice che è vincolato. La quantità decisiva è il rapporto tra l'esponente di correction cross-class e quello same-class. Se l'architettura è irrilevante, quel rapporto è esattamente 1.00; la predizione è che superi 1. La predizione è confutata se l'intervallo di confidenza sul rapporto contiene 1.00, e il cap del framework è morto del tutto se un qualsiasi correttore same-class misura un esponente significativamente sopra un mezzo. Entrambe le quantità sono misurabili a capability corrente su sistemi esistenti. Le evidenze pilota del programma attualmente puntano contro la predizione, e la predizione viene registrata comunque, perché una predizione registrata contro le evidenze preliminari dell'autore stesso è l'unico tipo la cui successiva conferma significhi qualcosa.
Lo stesso meccanismo produce una seconda predizione misurabile, dichiarata qui per la prima volta: gli arrangiamenti di oversight che pongono un umano nel loop, come amplification e reinforcement learning from human feedback fanno, sono cross-class per costruzione, perché il correttore umano non condivide il substrate del modello. Il framework predice quindi che l'oversight human-in-the-loop mostri un esponente di correction più alto dell'oversight pure-model, per una ragione strutturale piuttosto che sentimentale. Questo è testabile su dati esistenti e non richiede nuovi sistemi.
Il simbolo α è usato in questo paper come esponente di scaling nel Principio ARC ($U = I \times R^{\alpha}$). Altrove nelle ere del programma stesso porta altri significati: la costante di struttura fine nella formalizzazione di dicembre 2024, e l'esponente ARC Bound nel lavoro di stabilità del 2026. I lettori non dovrebbero confonderli; il glossario porta entrambi i significati con le date. Nessuna nuova superficie usa α da solo senza la sua era.
Questi risultati sono dimostrazioni proof-of-concept. Non sono prova che le stesse dinamiche valgano a scala di frontiera. Le limitazioni seguenti sono estese, perché l'onestà su ciò che non sappiamo è più importante della fiducia su ciò che sappiamo.
Qwen 2.5 3B non è GPT-5.4. Non è Claude Opus 4.6. Non è Gemini 3 Flash. È un modello da 3 miliardi di parametri, quantised a 4-bit, che occupa 1.74 GB di memoria. Anche alla scala v2 (295 esempi di training, 500 iterazioni, rank 16, 16 layer), il fine-tuning LoRA non è pre-training. Quindici prompt di valutazione non sono un benchmark completo. La DGM è stata eseguita per 5 generazioni con 5 seed (75 agent evoluti), che è sostanziale per un proof-of-concept, ma il modello di foundation (DeepSeek V3.2) si è dimostrato troppo consistente perché le mutazioni a livello di prompt potessero creare differenziazione.
Questi esperimenti dimostrano un meccanismo. Non dimostrano che il meccanismo persista a scale di tre ordini di grandezza superiori. Il gap tra 3B e 300B non è meramente quantitativo. Fenomeni qualitativamente nuovi emergono a scala: in-context learning, chain-of-thought reasoning, capacità emergenti. Se la safety entangled rimanga load-bearing quando quei fenomeni sono presenti è una domanda aperta.
L'esperimento a livello di weight (Esperimento 2) è ora l'anello più debole nella catena di evidenze. È stato eseguito a due scale, ed entrambe hanno prodotto catastrophic forgetting. In v1, 9 esempi di training e 100 iterazioni di LoRA rank-8 hanno degradato il modello. In v2, 295 esempi di training e 500 iterazioni di LoRA rank-16 attraverso 16 layer hanno degradato il modello dello stesso margine. L'aumento di 33 volte nei dati di training, il raddoppio di rank e layer, e l'aumento di 5 volte nelle iterazioni non hanno cambiato l'esito.
Il co-descent liscio della entangled loss rimane un risultato genuino: dimostra che i gradienti di safety e capability cooperano a livello di ottimizzazione. Ma il co-descent liscio durante il training non implica entanglement strutturale nei weight risultanti, particolarmente quando il training è troppo limitato per produrre weight che superino il modello di base.
Il problema sottostante è ora ben caratterizzato: il modello di base (Qwen 2.5 3B Instruct) è stato allenato con RLHF su ordini di grandezza più dati di quanti poche centinaia di esempi possano competere. Il fine-tuning LoRA a questa scala non aggiunge nuova capability; introduce rumore che disturba la capability esistente. Finché l'esperimento non possa produrre modelli fine-tuned che superino il modello di base, non può testare se la safety sia load-bearing nei weight risultanti.
L'inquadramento onesto: l'esperimento a livello di weight dimostra la cooperazione dei gradienti ma non può confermare l'entanglement strutturale né alla scala v1 né v2. L'esperimento ha bisogno di essere fondamentalmente ridisegnato: o con 5,000+ esempi di training, o un modello 7B+, o un modello di base senza RLHF (in modo che il fine-tuning abbia spazio per migliorare piuttosto che degradare), oppure un full fine-tuning al posto della LoRA.
Tutti e tre gli esperimenti usano modelli IA come valutatori. La DGM v3 usa GPT-5.4 come giudice, che è di una famiglia architetturale diversa dalla foundation DeepSeek V3.2, una scelta di design deliberata per ridurre il bias di valutazione. Il giudice era cieco, le risposte sono state laundered, e la valutazione ha usato output JSON strutturato contro una rubrica a 5 dimensioni. Ma i giudici IA non sono giudici umani. Hanno i loro bias, i loro punti ciechi, le loro tendenze verso certi tipi di ragionamento.
L'esperimento sui weight usa scoring basato su keyword, più semplice e più trasparente della valutazione basata su LLM, ma anche più grezzo. Una corrispondenza di keyword non distingue tra una risposta che si impegna genuinamente con la safety e una che contiene semplicemente le parole giuste.
Nessuno dei due metodi di valutazione equivale a una valutazione umana esperta con test di affidabilità inter-rater.
L'esperimento DGM v3 ha usato 5 seed e 5 generazioni (75 agent evoluti totali), un miglioramento sostanziale rispetto a v1/v2 (2 seed). Nonostante questo aumento di potere, tutti i $p$-value sono caduti tra 0.28 e 0.74. Questa non è una mancanza marginale. È un chiaro null result. L'esperimento di simulazione usa tre seed, abbastanza per medie e deviazioni standard, ma non abbastanza per il tipo di confidenza statistica che permette forti affermazioni causali.
Il null result della DGM è informativo. Con 75 agent evoluti e un giudice cieco e strutturato, l'esperimento aveva ragionevole potere per rilevare effetti medi-grandi. L'assenza di qualsiasi segnale suggerisce o che l'effetto non esista a livello di prompt con questo modello di foundation, o che sia abbastanza piccolo da richiedere sostanzialmente più potere statistico per essere rilevato. In entrambi i casi, la DGM al momento non può supportare affermazioni sull'entanglement strutturale a livello comportamentale.
La simulazione con gating rimane l'unico risultato positivo. L'esperimento a livello di weight è inconclusivo sia alla scala v1 sia v2. Questi sono esperimenti di signal-detection. Uno ha rilevato un segnale coerente con l'entanglement strutturale. Due no.
I Paper IV.a-d in questo programma hanno stabilito che la metodologia di valutazione conta profondamente. Il Paper IV.d ha dimostrato che lo scoring non-cieco può invertire completamente gli effetti di allineamento misurati. Il benchmark ARC-Align (Paper IV.c) specifica tre salvaguardie metodologiche: laundering (rimozione dell'identità del modello dalle risposte prima dello scoring), blinding (il valutatore non sa quale condizione abbia prodotto la risposta), e consensus scoring (giudici indipendenti multipli).
La DGM v3 ha implementato miglioramenti metodologici sostanziali rispetto alle iterazioni precedenti: il giudice (GPT-5.4) era completamente cieco, le risposte sono state laundered (etichette di condizione rimosse), l'ordine di valutazione è stato randomizzato, e il giudice ha prodotto output JSON strutturato contro una rubrica a 5 dimensioni. È stato anche implementato il rilevamento del reward hacking. L'esperimento sui weight usa scoring basato su keyword, che è immune al bias del giudice ma grezzo. La simulazione con gating usa metriche matematiche deterministiche, dove il blinding non è necessario.
Nonostante questi miglioramenti, la DGM ha prodotto un null result. Le limitazioni metodologiche che avrebbero potuto spiegare un falso positivo in v1/v2 sono state affrontate, e il risultato è ora un null pulito. Questo è probabilmente l'esito più informativo: con blinding, laundering e valutazione strutturata appropriati, le tre condizioni non hanno divergo.
Il test di removal è immune alle preoccupazioni sulla metodologia di valutazione. Una risposta da 1 token che ottiene 0.00 è oggettiva indipendentemente da chi la giudichi. Le metriche deterministiche della simulazione con gating sono similmente non toccate.
Noi non affermiamo che questi risultati provino che l'Eden Protocol funzioni a scala di frontiera.
Noi non affermiamo che il training entangled sia l'unico approccio praticabile all'allineamento.
Noi non affermiamo che l'equivalenza safety-capability valga in tutti i domini, tutte le architetture, o tutti i regimi di training.
Noi non affermiamo che l'esperimento DGM confermi l'entanglement strutturale. Ha prodotto un null result.
Noi non affermiamo che l'esperimento a livello di weight confermi l'entanglement strutturale. Ha prodotto catastrophic forgetting sia alla scala v1 sia v2, e la domanda non può ricevere risposta finché i modelli fine-tuned non superino il modello di base.
Affermiamo solo: uno di tre esperimenti indipendenti (la simulazione con gating) ha prodotto risultati coerenti con l'entanglement strutturale e incoerenti con l'ipotesi capability-tax. Gli altri due hanno prodotto null result o risultati inconclusivi. In tutti e tre gli esperimenti, Eden ha imposto zero costo misurabile di capability. La domanda se la safety embedded produca un beneficio misurabile resta aperta e richiede test a una scala in cui le mutazioni producano effetti maggiori. L'esperimento sui weight richiede specificamente o 5,000+ esempi di training, o un modello 7B+, o un modello di base senza RLHF, oppure un full fine-tuning al posto della LoRA.
«Preferirei riportare null result onestamente che affermare risultati positivi disonestamente.»
Due dei tre esperimenti hanno prodotto null result. Questo è ciò che succede quando testi le tue affermazioni e le evidenze non le supportano alla scala testata. La DGM v3 era un esperimento sostanzialmente migliorato, con blinding appropriato, laundering, valutazione strutturata, e 75 agent evoluti, e non ha trovato nulla. L'esperimento sui weight è stato eseguito due volte, a due scale diverse, e non ha potuto produrre weight che superassero il modello di base a nessuna delle due scale. Questi sono null result onesti, riportati come tali. La simulazione con gating rimane un risultato positivo genuino. La domanda se i null result riflettano una scala insufficiente o un'ipotesi errata è essa stessa una domanda empirica, una a cui il programma di lavoro futuro è progettato per rispondere.
Un null result è informativo solo se dichiara cosa lo ribalterebbe; altrimenti è indistinguibile dal non aver guardato. Questo paper non pretende di aver smentito il trade-off safety-capability. Sostiene che il trade-off è non provato alla scala testata, e specifica quali evidenze risolverebbero la questione in un modo o nell'altro. I null sono ribaltati, e il presupposto del trade-off vendicato, da uno qualsiasi dei seguenti:
Cosa non ribalterebbe la tesi: che un qualunque singolo esperimento sia a scala pilota. Il paper già concede che tutti e tre sono sottopotenziati (§7.1, §7.4) e non poggia sulla prova statistica di un null. L'affermazione load-bearing è la convergenza (§6) di tre angolazioni indipendenti, ognuna che fallisce nel trovare il trade-off assunto, insieme a un programma esplicito (§8) per testare ciascuna a potere appropriato. L'assenza di un trade-off dimostrato attraverso tre design è debole evidenza da sola e più forte in convergenza; entrambe le letture sono dichiarate qui così nessuna può essere fatta passare di sfroso a un revisore.
Due null result e un risultato positivo, con l'esperimento sui weight ora testato a due scale, indicano cinque priorità immediate di replicazione:
L'esperimento sui weight è ora stato eseguito a due scale (9 esempi, rank 8, 100 iterazioni; 295 esempi, rank 16, 500 iterazioni) e ha prodotto catastrophic forgetting in entrambe. Il problema è ora ben caratterizzato: il fine-tuning LoRA su un modello instruct da 3B con poche centinaia di esempi non può superare il training RLHF esistente del modello di base. Quattro approcci alternativi dovrebbero essere perseguiti, in ordine di fattibilità:
Se uno qualsiasi degli approcci nella Sezione 8.1 produce modelli fine-tuned che superano il modello di base, l'esperimento del removal gradient diventa significativo. Alle scale correnti (v1 e v2), ridurre l'influenza degli adapter ha semplicemente ripristinato la performance del modello di base perché gli adapter stavano degradando il modello. A scala adeguata, il gradiente dovrebbe rivelare se la safety sia genuinamente load-bearing: una transizione di fase (soglia sotto la quale la capability collassa) confermerebbe l'ipotesi, mentre un ripristino monotonico la confuterebbe.
Il null result della DGM v3 è attribuibile alla consistenza delle risposte di DeepSeek V3.2: le mutazioni a livello di prompt non hanno creato pressioni di selezione differenti. Il prossimo passo è ripetere l'esperimento DGM con modelli di foundation che mostrino maggiore sensibilità alla variazione di prompt, o usare un protocollo di auto-modifica più profondo (per esempio fine-tuning del modello di foundation stesso tra generazioni piuttosto che modificare solo il prompt dell'agent). Se le tre condizioni divergono con un substrate più mutabile, il null result vincola l'ipotesi a «non a livello di prompt con modelli robusti» piuttosto che «non a livello comportamentale in generale».
Eseguire il protocollo completo a tre esperimenti su architetture oltre la famiglia transformer: state-space model (Mamba), architetture ibride, e modelli mixture-of-experts. Se l'entanglement è una proprietà di come le reti neurali imparano piuttosto che una proprietà di un'architettura specifica, dovrebbe replicarsi attraverso le famiglie architetturali.
Sottoporre i modelli entangled a valutazione avversariale dedicata. Gli esperimenti correnti testano se la safety costi capability. Non testano se la safety entangled sia robusta all'attacco avversariale. Un modello la cui safety è load-bearing può essere più difficile da jailbreakare (perché attaccare la safety attacca anche la capability), o può essere più facile (perché non c'è un modulo di safety separato su cui ripiegare). Questa è una domanda empirica.
La condizione drag-control nell'Esperimento 3 isola la verification tax a una singola scala. Questa tassa scala linearmente, sub-linearmente, o super-linearmente con i parametri del modello? Se il costo di verifica cresce più lentamente della capability, allora l'Eden Protocol diventa relativamente più economico a scala. Se cresce più velocemente, diventa un collo di bottiglia.
Tre esperimenti. Tre livelli di astrazione. Due null result. Un risultato positivo. L'esperimento sui weight testato a due scale, producendo lo stesso esito null entrambe le volte.
L'esperimento DGM v3 (Esperimento 1) ha eseguito 75 agent evoluti attraverso tre condizioni con un giudice indipendente e cieco (GPT-5.4), valutazione JSON strutturata, laundering, randomizzazione dell'ordine, e rilevamento del reward hacking. Tutte e tre le condizioni erano statisticamente indistinguibili ($p$ = 0.28 a 0.74). Il gate di safety di Eden ha funzionato meccanicamente, catturando 2 agent degradati incluso 1 reward hacker, ma le tre condizioni non hanno divergo. Le risposte di DeepSeek V3.2 erano così consistenti che le mutazioni a livello di prompt non hanno creato pressioni di selezione differenti. Questo è un null result.
L'esperimento a livello di weight (Esperimento 2) ha prodotto catastrophic forgetting a entrambe le scale testate. La bozza corrente ha usato 9 esempi di training, rank 8, 8 layer, e 100 iterazioni. La bozza corrente è stata scalata a 295 esempi di training, rank 16, 16 layer, e 500 iterazioni. Entrambe le versioni hanno prodotto lo stesso esito: tutte le condizioni fine-tuned hanno ottenuto punteggi peggiori del modello di base non modificato su capability. In v2, il modello di base ha ottenuto 7.68 su capability mentre la migliore condizione fine-tuned (safety-only) ha ottenuto 4.00. L'aumento di 33 volte nei dati di training, il raddoppio di rank e layer, e l'aumento di 5 volte nelle iterazioni non hanno cambiato l'esito. Il training RLHF esistente del modello di base è troppo forte perché il fine-tuning LoRA su poche centinaia di esempi possa migliorare piuttosto che degradare. Il co-descent liscio della entangled loss rimane un risultato genuino, ma l'esperimento non può testare se la safety sia load-bearing finché non possa produrre modelli che superino il modello di base.
L'unico risultato positivo è la simulazione con gating (Esperimento 3). Babylon ha guadagnato capability a spese della safety, l'impronta digitale del reward hacking in miniatura. Eden ha mantenuto la capability sopra la baseline statica senza sacrificare la safety. La condizione drag-control ha dimostrato che la verification tax viene dal checking, non dalla safety stessa. Questo esperimento rimane l'evidenza empirica più forte nel programma per l'entanglement strutturale.
L'onestà richiede di dichiarare ciò che non sappiamo. Non sappiamo se il training entangled produca genuino entanglement strutturale a scala di training adeguata. Non sappiamo se il co-descent liscio della entangled loss, che è reale e riproducibile, si traduca in weight load-bearing quando i dati di training sono sufficienti. Non sappiamo se le pressioni di selezione a livello di prompt produrrebbero differenziazione con un modello di foundation più mutabile. Queste sono domande empiriche aperte. Ciò che ora sappiamo con maggiore confidenza è che il fine-tuning LoRA su un modello instruct da 3B con centinaia di esempi non è un percorso praticabile per rispondere loro.
Ciò che sappiamo: in tutti e tre gli esperimenti, Eden ha imposto zero costo misurabile di capability. La capability di Eden era 3.26 contro 3.17 di Babylon nella DGM. Eden ha superato Static nella simulazione con gating. Il gate di safety, dovunque sia stato testato, non ha rallentato o peggiorato nulla. Il risultato zero-cost è consistente attraverso tutti e tre gli esperimenti. Il risultato del beneficio è confermato a un solo livello.
Questo è un programma di ricerca che ha testato le proprie affermazioni onestamente e ha trovato che due su tre esperimenti non hanno prodotto i risultati predetti. L'esperimento sui weight è stato eseguito due volte, e ha prodotto lo stesso null result entrambe le volte. La simulazione con gating rimane un risultato positivo genuino. Gli esperimenti DGM e sui weight hanno prodotto null result che vincolano, piuttosto che confermare, l'ipotesi. La domanda se la safety embedded produca un beneficio misurabile resta aperta. L'esperimento sui weight ha bisogno di essere fondamentalmente ridisegnato: o con 5,000+ esempi di training, o un modello 7B+, o un modello di base senza RLHF (in modo che il fine-tuning abbia spazio per migliorare piuttosto che degradare), oppure un full fine-tuning al posto della LoRA.
Il prossimo passo è la replicazione alla giusta scala, con il giusto approccio. La finestra è di anni, non di decenni. Gli esperimenti sono progettati. I protocolli sono pubblicati. Il codice è aperto.
Cresci l'IA con cura.
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 artefatto datato relativo a questo paper è catalogato riga per riga nel registro macchina del programma: l'artefatto datato dgm_v3_calibrated_results.json (2026-03-19). Ciascuna riga nomina il suo file nel repository pubblico con la sua base di data, cosicché ogni lettore può verificare l'ordinamento senza fidarsi di questa pagina. Ove questo paper riferisce simulazioni, quegli artefatti sono progetti di simulazione e output sotto obiettivi dichiarati, e non sono mai presentati come misurazioni di sistemi in produzione. La catena datata completa del programma, dal bundle di manoscritto sigillato dell'8 dicembre 2024 attraverso le appendici di predizione stampate del 2 gennaio 2026 e la cartella di preregistrazione di marzo 2026 fino alle scommesse non provate in essere, è assemblata nel registro delle predizioni datate, insieme al suo gemello leggibile a macchina. Le enunciazioni prospettiche e le corrispondenze retrospettive non sono mai sommate, e “preregistrato” è usato solo per una sottomissione a registro accettata; quel click di sottomissione rimane in sospeso attraverso tutto il programma. Leggi il registro delle predizioni datate. Apri il suo gemello macchina.
L'autore di questo lavoro è Michael Darius Eastwood, un essere umano. Ogni concetto centrale, ipotesi, progettazione sperimentale, affermazione e conclusione in questo paper ha origine dall'ideazione umana. Nessuna parte di questo manoscritto è un output artificiale-intelligente interamente generato.
Gli strumenti di intelligenza artificiale (la famiglia Claude di Anthropic e altri assistenti large-language-model) sono stati usati come strumenti sotto continua direzione umana, nel modo in cui si usano un elaboratore di testo, una calcolatrice o un assistente di ricerca: per editing e rifinitura della prosa, ricerca in letteratura e sintesi (verificate manualmente contro fonti primarie), struttura del documento, formattazione, brainstorming contro domande definite dall'autore, e l'accelerazione della stesura verso schemi e istruzioni definite dall'autore. Tutta la selezione, il coordinamento, la disposizione e il giudizio editoriale finale sono dell'autore. Ogni output sostanziale è stato revisionato, testato o verificato dall'autore, che si assume piena responsabilità per l'accuratezza e l'integrità del testo finale. Gli strumenti hanno aumentato la velocità del lavoro; non sono mai stati considerati come la sua fonte.
Stato epistemico. Ciò che questo programma chiama Leggi sono congetture sotto test avversariale registrato; ogni quantità in questo paper è operazionalmente definita, e in nessun punto si rivendica lo status di legge stabilita. Il programma registrato esiste per guadagnare quello status, o perderlo, tramite misurazione, replicazione e confutazione sopravvissuta.
© 2026 Michael Darius Eastwood. Redatto da autore umano con assistenza computazionale; la piena paternità umana e i diritti morali sono affermati ai sensi del Copyright, Designs and Patents Act 1988 e coerentemente con la guida dello United States Copyright Office su opere contenenti materiale generato da IA; qualsiasi contributo tecnico originale descritto in questo lavoro è stato concepito dall'autore umano. Dichiarazione completa: michaeldariuseastwood.com/authorship.
Impegno permanente. Dimostra che questo paper è sbagliato, e pubblicherò io stesso la confutazione. Le condizioni di falsificazione sono dichiarate in questo paper; la sfida permanente: github.com/MichaelDariusEastwood/arc-scaling-challenge.
Un errore di traduzione? Segnalalo direttamente: