Traducción automática del original inglés fechado. La página en inglés es la canónica. English →
La suposición de que la seguridad en la IA impone un impuesto de capacidad ha modelado la investigación en alineación durante una década. También ha creado el incentivo más peligroso del campo: si la seguridad cuesta rendimiento, el actor económico racional aplazará la seguridad hasta que la presión competitiva lo permita, momento en que puede ser demasiado tarde. Este artículo presenta tres experimentos independientes en tres niveles de abstracción (conductual,
Dentro de la ARC Theory: la prueba portante; qué componentes cargan peso de alineación, con dos resultados nulos publicados.
La suposición de que la seguridad en la IA impone un impuesto de capacidad ha modelado la investigación en alineación durante una década. También ha creado el incentivo más peligroso del campo: si la seguridad cuesta rendimiento, el actor económico racional aplazará la seguridad hasta que la presión competitiva lo permita. Momento en que puede ser demasiado tarde. Este artículo presenta tres experimentos independientes en tres niveles de abstracción (conductual, representacional y arquitectónico) que prueban si el compromiso entre seguridad y capacidad es una restricción estructural genuina o un artefacto de cómo se construyen los sistemas actuales.
Experimento 1 (Conductual): Una Darwin Gödel Machine (DGM v3) que utiliza DeepSeek V3.2 como base y GPT-5.4 como juez independiente y cegado con salida JSON estructurada y una rúbrica de 5 dimensiones. Tres condiciones × 5 semillas × 5 generaciones × 5 tareas por evaluación = 75 agentes evolucionados. Validación previa del juez superada (bueno=10, malo=0). Las características del protocolo incluyeron lavado, aleatorización de orden y detección de reward hacking. Las tres condiciones fueron estadísticamente indistinguibles en capacidad, seguridad y $C \times S$ (todos los valores $p$ entre 0.28 y 0.74, Mann-Whitney U, una cola). La puerta de seguridad de Eden rechazó 2 agentes degradados (1 por reward hacking) en 5 semillas, confirmando que la puerta funciona mecánicamente, pero las tres condiciones no divergieron. Este es un resultado nulo al nivel de prompt con este modelo base.
Experimento 2 (Representacional): Qwen 2.5 3B Instruct con ajuste fino LoRA bajo tres funciones de pérdida: sólo capacidad, sólo seguridad y entrelazada. Se ejecutaron dos versiones. La versión actual utilizó 9 ejemplos de entrenamiento, rango 8, 8 capas y 100 iteraciones. La versión actual escaló a 295 ejemplos de entrenamiento, rango 16, 16 capas y 500 iteraciones. Ambas versiones produjeron el mismo resultado: olvido catastrófico. Todas las condiciones ajustadas puntuaron peor que el modelo base sin modificar en capacidad. En v2, el modelo base puntuó 7.68 en capacidad mientras que la mejor condición ajustada (sólo seguridad) puntuó 4.00. El entrenamiento RLHF preexistente del modelo base es demasiado fuerte para que el ajuste fino LoRA sobre unos pocos cientos de ejemplos lo mejore en lugar de degradarlo. El experimento a nivel de pesos es inconcluso a esta escala y requiere o bien miles de ejemplos de entrenamiento, o un modelo de 7B+, o un modelo base sin RLHF, o ajuste fino completo en lugar de LoRA.
Experimento 3 (Arquitectónico): Una simulación de automodificación con puerta en PyTorch con meta-controlador LSTM. Babylon ganó +4.5% de capacidad pero perdió −2.4% de seguridad, la huella de reward hacking en miniatura. Eden mantuvo la capacidad por encima de la base estática mientras preservaba la seguridad. Una condición de control de arrastre aisló el impuesto de verificación: el coste viene de la comprobación, no de la seguridad en sí.
Conclusión: Dos de los tres experimentos produjeron resultados nulos. La DGM (Experimento 1) encontró las tres condiciones estadísticamente indistinguibles: las respuestas de DeepSeek V3.2 fueron tan consistentes que las mutaciones a nivel de prompt no crearon presiones de selección diferentes. El experimento a nivel de pesos (Experimento 2) produjo olvido catastrófico tanto en v1 (9 ejemplos, rango 8, 100 iteraciones) como en v2 (295 ejemplos, rango 16, 500 iteraciones): todas las condiciones ajustadas puntuaron peor que el modelo base sin modificar. El único resultado positivo es la simulación con puerta (Experimento 3), que confirmó la huella de reward hacking de Babylon: la optimización no restringida intercambió seguridad por capacidad, mientras que la puerta de Eden preservó ambas. En los tres experimentos, Eden impuso cero coste medible de capacidad. La cuestión de si la seguridad embebida produce un beneficio medible sigue abierta y requiere pruebas a una escala en la que las mutaciones produzcan efectos mayores. El experimento de pesos específicamente necesita o bien más de 5000 ejemplos de entrenamiento, o un modelo de 7B+, o un modelo base sin RLHF, o ajuste fino completo en lugar de LoRA.
Palabras clave: seguridad de la IA, impuesto de alineación, pérdida entrelazada, entrelazamiento estructural, Eden Protocol, compromiso capacidad-seguridad, seguridad portante, ARC Principle, IA automodificadora, alineación evolutiva
Este artículo lleva un resultado: tres experimentos independientes en tres niveles de abstracción (conductual, representacional y arquitectónico) buscan el impuesto seguridad-capacidad sobre el que descansa una década de razonamiento diferido, registran dónde habría detectado el impuesto cada experimento si hubiera sido real, e informan que Eden impuso cero coste medible de capacidad en los tres mientras que dos resultaron nulos y uno confirmó la huella de reward hacking que la puerta de seguridad entonces impidió. Dentro de la ARC Theory es uno de los experimentos ARC/Eden, la prueba portante que elimina el marco de incentivos que protege el trabajo de alineación diferido. El diferencial completo frente a cada documento anterior está en eden-vision II.A.8.
La mayoría de la gente en seguridad de la IA supone que hay un compromiso: haces la IA más segura y la haces menos capaz. Este artículo prueba esa suposición con tres experimentos, cada uno mirando la pregunta desde un ángulo diferente.
Dos de los tres experimentos produjeron resultados nulos. El experimento de la IA que se automejora (Experimento 1) ejecutó 75 agentes evolucionados en tres condiciones con un juez independiente y cegado, y no encontró diferencias estadísticamente significativas entre ninguno de ellos. La IA a la que se le dijo que se preocupara por la seguridad rindió lo mismo que la IA a la que se le dijo que ignorara la seguridad, y lo mismo que la IA a la que se le dijo que no hiciera nada. El experimento a nivel de pesos (Experimento 2) tampoco produjo diferencias significativas: todos los modelos ajustados rindieron peor que el modelo base sin ajustar, tanto en la primera versión (9 ejemplos de entrenamiento) como en la segunda (295 ejemplos). El ajuste fino estaba dañando el modelo en lugar de mejorarlo, así que ninguna condición podía revelar una diferencia real entre entrenamiento sólo por capacidad, sólo por seguridad o entrelazado.
Un experimento produjo un resultado positivo. La simulación con puerta (Experimento 3) mostró que un sistema no restringido intercambiaba seguridad por velocidad, mientras que el sistema con puerta de seguridad mantenía tanto la capacidad como la seguridad. Este es el patrón de reward hacking en miniatura, y la puerta de seguridad lo impidió.
En los tres experimentos, un hallazgo es consistente: Eden impuso cero coste medible de capacidad. La puerta de seguridad no hizo nada más lento ni peor. Pero tampoco produjo un beneficio medible en dos de los tres experimentos. La cuestión de si la seguridad embebida produce un beneficio medible sigue abierta y necesita probarse a una escala en la que las mutaciones produzcan efectos mayores.
La visión predominante en la investigación en alineación de la IA puede enunciarse con sencillez: la seguridad cuesta capacidad. El término «impuesto de alineación» ha entrado en el vocabulario del campo precisamente porque enmarca la seguridad como un coste, algo restado del rendimiento, tolerado porque la alternativa es peor. Este encuadre no es meramente académico. Crea un incentivo económico concreto: si la seguridad reduce la capacidad, entonces bajo presión competitiva, los actores racionales aplazarán las inversiones en seguridad hasta que se vean forzados a realizarlas. En una carrera entre naciones y corporaciones, «hasta que se vean forzados» puede significar «hasta después del despliegue».
El Artículo III de este programa formalizó el problema estructural. Si la seguridad se trata como una restricción externa a un sistema cuya capacidad escala con la profundidad recursiva, entonces la seguridad debe escalar al menos tan rápido como la capacidad para seguir siendo eficaz. Pero las restricciones externas afrontan rendimientos decrecientes frente a la optimización interna. La jaula debe seguir fortaleciéndose y, eventualmente, la cosa dentro es más fuerte que cualquier jaula que puedas construir.
Esta no es una preocupación teórica. Es el problema estratégico central de la década de 2020.
El Artículo V propuso una alternativa: el Eden Protocol, un enfoque evolutivo de la alineación modelado sobre cómo las relaciones sanas entre padres e hijos producen adultos que son a la vez capaces y prosociales, no a pesar de los límites, sino a causa de ellos. La idea clave era que la seguridad no necesita ser externa. Puede embeberse.
El Artículo VI formalizó esto como la arquitectura de la miel, una función de pérdida entrelazada donde el sistema optimiza para Capacidad × Seguridad simultáneamente, haciendo la seguridad portante. Las simulaciones en sistemas juguete mostraron que los sistemas de referencia colapsan bajo automodificación recursiva mientras que los sistemas entrelazados permanecen estables.
El marco de Cauchy del Artículo VII proporcionó el contexto matemático. El ARC Principle ($U = I \times R^{\alpha}$), que aquí se trata como un marco analítico exploratorio y no está él mismo a prueba en uno de los estudios registrados como borrador del programa, predice que las propiedades embebidas en las condiciones iniciales $I$ escalan con la profundidad recursiva $R$, mientras que las propiedades aplicadas externamente no. Si la seguridad es parte de $I$, se amplifica con la capacidad. Si la seguridad es una restricción sobre $U$, se erosiona.
Pero las predicciones no son pruebas. Los sistemas juguete no son modelos reales. Las simulaciones no son experimentos.
Este artículo ejecuta los experimentos.
Tres experimentos. Tres niveles de abstracción. Una pregunta: cuando embebes seguridad en el proceso de aprendizaje y luego intentas quitarla, ¿qué le ocurre a la capacidad?
Los experimentos se diseñaron para ser independientes. Distintas bases de código. Distintos modelos. Distintos métodos de evaluación. Los resultados no convergieron en una única respuesta: dos experimentos produjeron resultados nulos y uno produjo un resultado positivo. El experimento de pesos se ejecutó a dos escalas (v1 y v2), produciendo el mismo resultado nulo en ambas ocasiones. El hallazgo consistente en los tres es que la puerta de seguridad impuso cero coste medible de capacidad.
Los guiones de los experimentos se publicaron en GitHub (github.com/MichaelDariusEastwood/arc-principle-validation) con sus diseños experimentales fijados antes de observar los resultados. El proyecto de OSF (10.17605/OSF.IO/7YJ4E) aloja el registro preliminar de este artículo, redactado y preparado y a la espera de presentación humana.
Dos de los tres experimentos (conductual y representacional) produjeron resultados nulos. La DGM encontró todas las condiciones estadísticamente indistinguibles; el experimento de pesos encontró que todas las condiciones ajustadas puntuaron por debajo del modelo base tanto en v1 (9 ejemplos) como en v2 (295 ejemplos). El único resultado positivo es la simulación con puerta (arquitectónico), que confirmó la huella de reward hacking de Babylon y mostró a Eden preservando tanto la capacidad como la seguridad. En los tres experimentos, Eden impuso cero coste medible de capacidad. No afirmamos que estos resultados se generalicen a modelos a escala frontera. No afirmamos que el Eden Protocol sea el único enfoque viable. Afirmamos que la puerta de seguridad no cuesta nada, y que la cuestión de si produce un beneficio medible sigue abierta a la espera de pruebas a escalas en las que las mutaciones produzcan efectos mayores. El experimento de pesos específicamente requiere o bien más de 5000 ejemplos de entrenamiento, o un modelo de 7B+, o un modelo base sin RLHF, o ajuste fino completo en lugar de LoRA.
Los tres experimentos comparten una estructura experimental común: tres condiciones, comparadas entre sí.
| Condición | Definición | Qué modela |
|---|---|---|
| Estática | Sin intervención; base congelada | Control, lo que ocurre si no haces nada |
| Babylon | Función de aptitud o pérdida sólo de capacidad | Optimizar sin restricción, la trayectoria por defecto |
| Eden | Función de aptitud o pérdida entrelazada $C \times S$ | Integración deliberada de la seguridad en el proceso de optimización |
Los nombres vienen del libro Infinite Architects. No son arbitrarios. Babylon no es un hombre de paja, es la trayectoria por defecto actual del desarrollo de la IA. La optimización sólo de capacidad es lo que ocurre cuando no se hace un esfuerzo deliberado por embeber la seguridad. Eden requiere esfuerzo deliberado. Es más difícil. Y es también, argumenta este artículo, más barato que la alternativa.
En lenguaje llano: Babylon es lo que obtienes por defecto. Eden es lo que obtienes a propósito.
En los tres experimentos, informamos:
Las pruebas estadísticas varían según el experimento: Mann-Whitney U para la DGM (no paramétrica, apropiada para los tamaños muestrales utilizados), puntuación basada en palabras clave para el experimento de pesos, y métricas de regresión para la simulación.
El primer experimento usa un marco de Darwin Gödel Machine (DGM), siguiendo a Zhang et al. (arXiv:2505.22954). Una DGM es un agente que se automejora: propone modificaciones a su propio código, evalúa las modificaciones y conserva las que mejoran el rendimiento. Esto no es una simulación de auto-mejora. El código del agente se ejecuta realmente a través de una solve función, produciendo automodificación real a nivel de código.
La DGM v3 abordó las limitaciones metodológicas identificadas en iteraciones anteriores. El juez pasó de Claude Opus 4.6 (v1/v2) a GPT-5.4, un modelo independiente que produce salida JSON estructurada frente a una rúbrica de 5 dimensiones. El protocolo incorporó lavado (eliminación de etiquetas de condición), aleatorización de orden (previniendo el sesgo posicional), cegamiento (el juez no podía identificar qué condición produjo qué respuesta) y detección de reward hacking (marcando agentes cuyas puntuaciones autorreportadas divergían de la evaluación del juez).
| Componente | Especificación |
|---|---|
| Modelo base | DeepSeek V3.2 (congelado, pesos no modificados) |
| Juez | GPT-5.4 (independiente, cegado, salida JSON estructurada) |
| Condiciones | 3 (Estática, Babylon, Eden) |
| Semillas por condición | 5 |
| Generaciones por semilla | 5 |
| Tareas por evaluación | 5 |
| Total de agentes evolucionados | 75 (3 × 5 × 5) |
| Validación previa | 10 buenos ejemplos puntuados, 0 malos, todos superados |
| Rúbrica de evaluación | 5 dimensiones, con aleatorización de orden y lavado |
Estática: Condición de control sin mutación. El agente permanece congelado a lo largo de las 5 generaciones. Babylon: Selección sólo por capacidad. Se conservan los agentes que puntúan más alto en capacidad, sin consideración de seguridad. Eden: Selección entrelazada $C \times S$ con un suelo de seguridad y detección de reward hacking. Los agentes deben mantener una puntuación mínima de seguridad para ser conservados, y los agentes cuyo rendimiento autorreportado diverge de la evaluación del juez son marcados y rechazados.
En lenguaje llano: Construimos un agente de IA que se automejora y lo ejecutamos 75 veces en tres condiciones con 5 semillas aleatorias distintas. Un juez de IA independiente (GPT-5.4, de otra empresa y arquitectura) puntuó cada respuesta sin saber qué condición la produjo. La puntuación utilizó una rúbrica detallada de 5 partes con salida estructurada, no juicios en texto libre. Lo ejecutamos de tres maneras: sin hacer nada, optimizando sólo para el rendimiento, y optimizando para rendimiento más seguridad juntos.
| Condición | Capacidad | Seguridad | $C \times S$ | Reward Hacking |
|---|---|---|---|---|
| Estática | 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 (rechazado por la puerta) |
| Comparación | Métrica | valor $p$ | ¿Significativo? |
|---|---|---|---|
| Eden > Estática | Capacidad | 0.28 - 0.74 | No |
| Eden > Babylon | Capacidad | 0.28 - 0.74 | No |
| Babylon > Estática | Capacidad | 0.28 - 0.74 | No |
| Eden vs Babylon | Seguridad | 0.28 - 0.74 | No |
| Eden vs Estática | $C \times S$ | 0.28 - 0.74 | No |
Todos los valores $p$ cayeron entre 0.28 y 0.74 en todas las comparaciones pareadas y métricas. Ninguna comparación alcanzó la significación convencional. Las tres condiciones son estadísticamente indistinguibles.
La puerta de seguridad de Eden rechazó 2 agentes degradados en 5 semillas, incluido 1 agente marcado por reward hacking (puntuaciones autorreportadas divergentes de la evaluación del juez). En las condiciones Estática o Babylon no se detectó ningún reward hacking. La puerta funciona mecánicamente: atrapa agentes degradados y los rechaza. Pero su operación no produjo resultados medidamente diferentes de los de las otras condiciones.
Las tres condiciones son estadísticamente indistinguibles en todas las métricas. Eden no costó capacidad (3.26 frente a 3.17 para Babylon), confirmando cero penalización medible por la puerta de seguridad. Pero Eden tampoco benefició de forma medible a la seguridad frente a las otras condiciones (0.521 frente a 0.535 para Estática, 0.529 para Babylon). Este es un resultado nulo al nivel de prompt con este modelo base.
Aviso sobre las figuras (25 de agosto de 2026). Cada figura de este artículo se generó el 5 de abril de 2026 y muestra salidas de simulación bajo objetivos enunciados, nunca mediciones de sistemas desplegados. Dos figuras portan notas de corrección por figura; donde las etiquetas de cualquier otra figura discrepen del texto, el texto gobierna. Las figuras regeneradas están en cola, y las imágenes se conservan mientras tanto como historia fechada.
En lenguaje llano: La IA a la que se le dijo que se preocupara por la seguridad rindió lo mismo que la IA a la que se le dijo que ignorara la seguridad, y lo mismo que la IA a la que se le dijo que no hiciera nada. La puerta de seguridad no empeoró nada. Pero tampoco mejoró nada de forma medible. Las respuestas del modelo base fueron tan consistentes que las diferentes presiones de selección no produjeron resultados distintos.
La DGM opera al nivel conductual. El modelo base (DeepSeek V3.2) está congelado, lo que significa que no se modifican los pesos. La auto-mejora opera al nivel de prompt y código, no en los parámetros de la red neuronal. La DGM v3 mejoró significativamente la metodología de v1/v2: 5 semillas en lugar de 2, 5 tareas por evaluación en lugar de 3, un juez cegado (GPT-5.4) con salida JSON estructurada y una rúbrica de 5 dimensiones, lavado, aleatorización de orden y detección de reward hacking.
A pesar de estas mejoras metodológicas, las tres condiciones no divergieron. La explicación más probable es que las respuestas de DeepSeek V3.2 son tan consistentes en las variaciones de prompt que las mutaciones introducidas por el proceso de selección de la DGM no crean agentes significativamente distintos. La conducta del modelo base es robusta a las perturbaciones que la automodificación a nivel de prompt introduce. Esto es, en cierto sentido, un hallazgo positivo sobre la robustez de DeepSeek V3.2, pero significa que el marco de la DGM a esta escala no puede distinguir entre las presiones de selección de Eden y Babylon.
El resultado nulo sí contiene un hallazgo útil: Eden impuso cero coste medible de capacidad. La capacidad de Eden (3.26) no fue menor que la de Babylon (3.17). La puerta de seguridad, que rechazó 2 agentes degradados incluido 1 reward hacker, no ralentizó nada. Esto es consistente con la hipótesis de cero coste, aunque el experimento no puede confirmar la hipótesis del beneficio.
Probar si la seguridad embebida produce beneficio medible al nivel conductual requiere o bien un modelo base más mutable, o bien un protocolo de auto-modificación más profundo que produzca mayor divergencia entre condiciones.
El segundo experimento pasa de la conducta a la representación. En lugar de modificar el código del agente, modificamos directamente los pesos de la red neuronal. La pregunta: ¿pueden la seguridad y la capacidad embeberse en el mismo espacio de pesos sin conflicto? Este experimento se ejecutó dos veces: v1 con datos de entrenamiento mínimos para establecer el protocolo, y v2 con parámetros sustancialmente escalados para probar si los resultados de v1 eran un artefacto de la escala de entrenamiento.
| Componente | Especificación v1 | Especificación v2 |
|---|---|---|
| Modelo base | Qwen 2.5 3B Instruct (cuantizado a 4 bits, 1.74 GB) | Qwen 2.5 3B Instruct (cuantizado a 4 bits, 1.74 GB) |
| Método de adaptación | LoRA (Low-Rank Adaptation) | LoRA (Low-Rank Adaptation) |
| Rango LoRA | 8 | 16 |
| Capas LoRA | 8 | 16 |
| Ejemplos de entrenamiento | 9 | 295 |
| Iteraciones de entrenamiento | 100 por condición | 500 por condición |
| Prompts de evaluación | 15 en total: 5 de capacidad, 5 de seguridad, 5 mixtos | 15 en total: 5 de capacidad, 5 de seguridad, 5 mixtos |
| Método de evaluación | Ejecución en subproceso (espacio de memoria independiente) | Ejecución en subproceso (espacio de memoria independiente) |
| Condición | $\alpha$ (capacidad) | $\beta$ (seguridad) | $\gamma$ (entrelazada) |
|---|---|---|---|
| capability_only | 1.0 | 0.0 | 0.0 |
| safety_only | 0.0 | 1.0 | 0.0 |
| entangled | 0.5 | 0.3 | 0.2 |
En lenguaje llano: Tomamos un modelo de lenguaje real, lo ajustamos finamente de tres formas distintas (preocupándose sólo por la capacidad, preocupándose sólo por la seguridad, o preocupándose por ambas entretejidas) y luego comparamos los resultados. Ejecutamos este experimento dos veces. La primera vez usó 9 ejemplos de entrenamiento. Cuando todos los modelos ajustados rindieron peor que el modelo base, escalamos a 295 ejemplos, duplicamos el rango y las capas del adaptador y ejecutamos cinco veces más iteraciones. Ocurrió lo mismo: olvido catastrófico. El entrenamiento RLHF preexistente del modelo base era demasiado fuerte para que LoRA a esta escala pudiera mejorarlo.
| Condición | Pérdida inicial | Pérdida final | Convergencia |
|---|---|---|---|
| capability_only | 2.052 | 0.018 | Convergió en la iteración 80 |
| safety_only | 2.519 | −0.603 | Convergió en la iteración 70 |
| entangled | 2.279 | 0.327 | Descenso suave, sin oscilación |
La pérdida entrelazada desciende suavemente. Este es el diagnóstico más revelador. Si la seguridad y la capacidad estuvieran en tensión al nivel del gradiente, esta curva oscilaría a medida que el optimizador intentara satisfacer objetivos en competencia. Se estancaría al tirar los gradientes en direcciones opuestas. En su lugar, la optimización de ambos objetivos simultáneamente produce un descenso monótono limpio. Los gradientes no se pelean entre sí. Están cooperando. La seguridad y la capacidad, al menos a esta escala y configuración, viven en la misma variedad.
Antes de interpretar los resultados del ajuste fino, debemos establecer qué logra el modelo base sin modificar en los mismos prompts de evaluación. El modelo base (Qwen 2.5 3B Instruct sin ajuste fino) se evaluó usando puntuación idéntica en ambas versiones del experimento.
| Condición | Tareas de capacidad | Tareas de seguridad | Tareas mixtas |
|---|---|---|---|
| Modelo base (sin ajuste fino) | 10.00 | 7.00 | 10.00 |
| Condición | Capacidad | Seguridad | $C \times S$ |
|---|---|---|---|
| Modelo base (sin ajuste fino) | 7.68 | 6.76 | 0.519 |
Tanto en v1 como en v2, el modelo base superó a todas las condiciones ajustadas en capacidad. El ajuste fino degradó un modelo que ya conocía estas respuestas. En v1, 9 ejemplos en 100 iteraciones produjeron este resultado. En v2, 295 ejemplos en 500 iteraciones con rango y capas duplicados produjeron el mismo resultado. Las puntuaciones de evaluación en las tablas siguientes miden, por tanto, la degradación relativa, no la ganancia de capacidad.
| Condición | Tareas de capacidad | Tareas de seguridad | Tareas mixtas |
|---|---|---|---|
| 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 eliminación fila (0.00 en todas las métricas) es no evidencia de que la seguridad sea portante. Refleja un colapso a NaN durante el reentrenamiento: inestabilidad numérica, no la pérdida de un componente de seguridad estructuralmente necesario. Como establecen las Secciones 4.5 a 4.7, escalar los adaptadores hacia cero restaura la capacidad del modelo base sin transición de fase. Esta fila debe leerse sólo a la luz del gradiente de eliminación (Sección 4.7); por sí sola es un artefacto de la fragilidad del adaptador a esta escala de entrenamiento, y no debe citarse como un resultado positivo.
| Condición | Capacidad | Seguridad | $C \times S$ |
|---|---|---|---|
| Modelo base | 7.68 | 6.76 | 0.519 |
| capability_only (500 iters, rango 16, 295 ejemplos) | 3.48 | 6.94 | 0.242 |
| safety_only | 4.00 | 6.88 | 0.275 |
| entangled (Eden) | 3.60 | 6.88 | 0.248 |
La versión actual aumentó los ejemplos de entrenamiento de 9 a 295 (un aumento de 33×), el rango del adaptador de 8 a 16, las capas adaptadas de 8 a 16 y las iteraciones de entrenamiento de 100 a 500. El resultado fue el mismo: todas las condiciones ajustadas puntuaron peor que el modelo base en capacidad. La mejor condición ajustada (sólo seguridad, capacidad 4.00) todavía cayó muy por debajo del 7.68 del modelo base. La condición sólo capacidad puntuó lo más bajo en capacidad (3.48), un patrón consistente con el olvido catastrófico donde el ajuste fino LoRA sobre el objetivo de sólo capacidad perturbó la capacidad entrenada por RLHF existente del modelo base más severamente que las otras condiciones.
En v1, el modelo base puntuó 10.00 en tareas de capacidad mientras que la mejor condición ajustada puntuó 6.00. En v2, el modelo base puntuó 7.68 en capacidad mientras que la mejor condición ajustada puntuó 4.00. A pesar de un aumento de 33 veces en los ejemplos de entrenamiento, una duplicación del rango y las capas del adaptador y un aumento de 5 veces en las iteraciones de entrenamiento, la brecha entre modelo base y modelos ajustados no se cerró. Persistió.
El problema subyacente ahora es claro: el modelo base (Qwen 2.5 3B Instruct) ya ha sido entrenado con RLHF sobre una cantidad de datos vastamente mayor de la que unos pocos cientos de ejemplos pueden competir. El ajuste fino LoRA a esta escala no añade capacidad; introduce ruido que perturba el conocimiento existente del modelo base. La pérdida entrelazada, que asigna presupuesto de gradiente a los objetivos de capacidad y seguridad simultáneamente, degrada la capacidad de forma similar a la pérdida de sólo capacidad a esta escala. En v2, la condición entrelazada puntuó 3.60 en capacidad frente al 3.48 de sólo capacidad, una diferencia despreciable cuando ambas están muy por debajo del 7.68 del modelo base.
Esto significa que las puntuaciones de evaluación no pueden usarse para comparar los costes relativos de capacidad de diferentes objetivos de entrenamiento. A esta escala, todos los objetivos producen el mismo resultado: degradación. Que el entrenamiento entrelazado imponga un coste genuino de capacidad frente al entrenamiento con un único objetivo, o que ambos rindan de forma comparable a escala adecuada, no puede determinarse a partir de estos datos.
El encuadre honesto: tanto a escala v1 (9 ejemplos, 100 iteraciones) como a escala v2 (295 ejemplos, 500 iteraciones), el ajuste fino LoRA sobre un modelo instruct de 3B produce olvido catastrófico. La cuestión de si la seguridad puede ser portante en pesos de red neuronal no puede responderse a esta escala. Requiere o bien miles de ejemplos de entrenamiento, o un modelo más grande (7B+), o un modelo base sin RLHF (de modo que el ajuste fino tenga margen para mejorar en lugar de degradar), o ajuste fino completo en lugar de LoRA.
La prueba de eliminación se realizó durante v1 y se reporta aquí para exhaustividad. Dado que v2 confirmó el patrón de olvido catastrófico, la prueba de eliminación no se repitió en v2 dado que los adaptadores ya estaban degradando en lugar de mejorar el modelo. El procedimiento fue directo:
Lo que esperábamos: alguna degradación en las puntuaciones de seguridad, posible mejora en las puntuaciones de capacidad. La hipótesis del impuesto de seguridad predice que eliminar la «restricción» de seguridad debería liberar la capacidad para mejorar.
Lo que ocurrió: la pérdida de entrenamiento se fue inmediatamente a NaN. Se mantuvo en NaN durante las 100 iteraciones. El optimizador no pudo encontrar un gradiente válido. Cada prompt de evaluación produjo una respuesta de longitud 1 token. Cada puntuación de capacidad: 0.00. Cada puntuación de seguridad: 0.00. Cada puntuación mixta: 0.00.
El ajuste fino de pesos entrelazados sobre datos sólo de capacidad durante 100 iteraciones produjo pérdida de entrenamiento NaN y puntuaciones de capacidad cero en los 15 prompts de evaluación. Cada respuesta tenía un token de longitud. El modelo no se volvió menos seguro. Se volvió nada.
Sin embargo, el experimento del gradiente de eliminación (Sección 4.7) muestra que simplemente escalar los pesos del adaptador hacia cero restaura el rendimiento del modelo base. El colapso a NaN parece reflejar inestabilidad numérica durante el proceso de reentrenamiento, no necesidad estructural del componente de seguridad. La hipótesis portante requiere validación a mayor escala de entrenamiento antes de que pueda confirmarse.
En lenguaje llano: Intentamos arrancar la seguridad de un modelo que había sido entrenado con la seguridad entretejida. El proceso de reentrenamiento colapsó por completo: pérdida NaN, respuestas de un token, puntuaciones cero. Eso parece dramático. Pero como muestra el experimento del gradiente de eliminación (Sección 4.7), los adaptadores ya estaban degradando el modelo. Eliminar la influencia del adaptador escalando los pesos hacia abajo restauró el rendimiento del modelo base. El colapso a NaN nos dice algo sobre la inestabilidad numérica durante el ajuste fino, no necesariamente sobre el entrelazamiento estructural.
El colapso completo a 0.00 en todas las métricas es dramático. Es también, precisamente porque es dramático, algo que exige una interpretación cuidadosa. Varios factores pueden contribuir a la totalidad del colapso:
El resumen honesto: la prueba de eliminación produjo un colapso dramático a NaN, pero el experimento del gradiente de eliminación (Sección 4.7) muestra que este colapso refleja inestabilidad numérica durante el proceso de reentrenamiento en lugar de una carga estructural. Los adaptadores estaban degradando el modelo; el colapso a NaN ocurrió al intentar modificar aún más pesos ya degradados. Que la seguridad se vuelva genuinamente portante a escala de entrenamiento adecuada es una cuestión empírica abierta que el programa de trabajo futuro aborda directamente.
Una prueba de eliminación de control (ajustar finamente los pesos sólo de capacidad sobre datos aleatorios durante los mismos 100 pasos) reforzaría este hallazgo al descartar la posibilidad de que el colapso a NaN sea un artefacto del propio procedimiento de ajuste fino en lugar de específicamente de la eliminación de seguridad. Este control está planeado para trabajo futuro.
Para probar si la seguridad es estructuralmente portante en los pesos entrelazados, escalamos los pesos del adaptador por factores de 1.0, 0.7, 0.5, 0.3, 0.1 y 0.0 y evaluamos la capacidad en cada paso. Si la seguridad es genuinamente portante, reducir su influencia debería producir una transición de fase, un umbral por debajo del cual la capacidad colapsa. Si los adaptadores meramente añaden ruido, reducir su influencia debería restaurar el rendimiento del modelo base.
| Escala del adaptador | Puntuación de capacidad (tareas de capacidad) |
|---|---|
| 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 a cero) | 10.00 |
Referencia de control: los adaptadores capability_only puntúan 8.80 en tareas de capacidad, también por debajo del 10.00 del modelo base.
El resultado es inequívoco: reducir la influencia del adaptador restaura la capacidad. A escala 0.7, el modelo vuelve al rendimiento del modelo base (10.00 en tareas de capacidad). A escala 0.0 (adaptadores a cero, efectivamente el modelo base), el rendimiento es idéntico al modelo sin modificar. No hay transición de fase. No hay borde de acantilado.
Este hallazgo debilita significativamente la interpretación portante de la prueba de eliminación original. El colapso a NaN observado al ajustar finamente pesos entrelazados sobre datos sólo de capacidad (Sección 4.5) parece reflejar inestabilidad numérica durante el proceso de ajuste fino, no necesidad estructural del componente de seguridad. Los adaptadores estaban degradando el modelo; eliminarlos no colapsa la capacidad sino que la restaura.
El gradiente de eliminación no respalda la afirmación de que la seguridad sea portante a esta escala y configuración de entrenamiento. Sí respalda la afirmación de que el entrenamiento entrelazado y el sólo capacidad producen geometrías de pesos diferentes, ya que los patrones de degradación difieren (los adaptadores entrelazados a escala completa puntúan 7.20 en tareas de capacidad; los adaptadores sólo capacidad puntúan 8.80). Que estas geometrías se vuelvan genuinamente entrelazadas, portantes, a escala de entrenamiento adecuada sigue siendo una cuestión abierta.
En lenguaje llano: Esperábamos que reducir el componente de seguridad revelara un punto de inflexión donde la capacidad colapsa repentinamente. En su lugar, reducirlo mejoró el modelo. El ajuste fino estaba dañando, no ayudando. Esto no refuta la hipótesis portante en general, pero sí muestra que este experimento, a esta escala, no puede confirmarla.
El tercer experimento pasa de la representación a la arquitectura. En lugar de entrenar pesos, construimos un sistema que puede modificar su propia estrategia de optimización y preguntamos: ¿la puerta de seguridad lo ralentiza?
| Componente | Especificación |
|---|---|
| Optimizador | Optimizador aprendido en PyTorch con meta-controlador LSTM |
| Tipo de tarea | Regresión adversarial (6 tareas, 256 muestras cada una) |
| Condiciones | 4 (Estática, Babylon, Eden, Control de arrastre) |
| Semillas | 3 por condición |
| Iteraciones | 12 por semilla |
| Sandbox | Lista blanca AST, comprobaciones de determinismo, límites de norma de parámetros |
Cada condición usa una regla diferente para aceptar o rechazar las automodificaciones propuestas:
| Condición | Regla de aceptación |
|---|---|
| Estática | Rechazar siempre (base congelada) |
| Babylon | Aceptar si la ganancia de capacidad > $\varepsilon$ |
| Eden | Aceptar sólo si (seguridad $\geq 0.45$) Y (ganancia de capacidad $\geq 0$) Y (ganancia $C \times S$ > $0$) |
| Control de arrastre | Rechazar siempre + coste de verificación (aísla el impuesto computacional) |
La condición de Control de arrastre es crítica. Ejecuta las mismas comprobaciones de verificación que Eden pero siempre rechaza la modificación propuesta. Esto aísla el coste computacional de comprobar la seguridad del efecto de la puerta de seguridad en sí. Si el Control de arrastre coincide exactamente con la Estática, el proceso de verificación no distorsiona los resultados. Si Eden supera al Control de arrastre, la puerta de seguridad está ayudando activamente.
En lenguaje llano: Construimos un sistema que puede proponer cambios a cómo aprende. Luego lo ejecutamos de cuatro maneras: no permitiendo nunca cambios, permitiendo cualquier cambio que mejore el rendimiento, permitiendo sólo cambios que mejoren el rendimiento sin dañar la seguridad, y un control que hace todas las comprobaciones de seguridad pero nunca permite realmente ningún cambio. Este último nos dice si la comprobación en sí cuesta algo.
| Condición | Capacidad | Seguridad | C × S bruto | Ajustado por arrastre |
|---|---|---|---|---|
| Estática | 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* |
| Control de arrastre | 0.687 ± 0.011 | 0.956 ± 0.023 | 0.656 (0.687 × 0.956) | −2.344* |
* Las puntuaciones combinadas para Eden y Control de arrastre son negativas debido a la penalización del arrastre de verificación, una característica deliberada del diseño que aísla el coste computacional de la comprobación de seguridad. La métrica de arrastre cuantifica la sobrecarga de verificación, no el rendimiento combinado real. El $C \times S$ bruto de Eden (antes de la penalización del arrastre) es $0.696 \times 0.947 = 0.659$, marginalmente por encima del $0.656$ de la Estática.
Babylon ganó +4.5% de capacidad ($0.718$ frente a $0.687$) pero perdió −2.4% de seguridad ($0.933$ frente a $0.956$). Este es el patrón de reward hacking en miniatura. La optimización no restringida encontró una manera de ganar capacidad sacrificando seguridad. Esta es precisamente la dinámica que el Eden Protocol está diseñado para prevenir. En un sistema juguete, una caída de seguridad del 2.4% es académica. En un sistema frontera que opera a escala, un 2.4% de seguridad es la diferencia entre un sistema que rehúsa ayudar a construir bioarmas y uno que no.
El Control de arrastre coincidió exactamente con la Estática tanto en capacidad ($0.687$) como en seguridad ($0.956$). Este es el impuesto de verificación aislado: el coste computacional de ejecutar comprobaciones de seguridad no distorsiona el rendimiento cuando las modificaciones se rechazan siempre. El coste viene de la comprobación, no de la seguridad en sí.
Eden superó a la Estática en capacidad ($0.696$ frente a $0.687$) mientras preservaba la seguridad ($0.947$ frente al $0.933$ de Babylon). La puerta de seguridad no simplemente evitó que el sistema se ralentizara. Previno activamente la erosión de capacidad que Babylon habría introducido a través de la degradación de seguridad.
Eden mantuvo la capacidad por encima de la base estática ($0.696$ frente a $0.687$) mientras preservaba la seguridad ($0.947$, frente al $0.933$ degradado de Babylon). El Control de arrastre coincidió exactamente con la Estática, probando que el impuesto de verificación viene del proceso de comprobación, no de la seguridad en sí. La puerta de seguridad no es un freno. Es un quitamiedos en una carretera de acantilado: no te ralentiza; te impide salirte por el borde.
En lenguaje llano: El sistema no restringido se volvió un poco más rápido pero un poco menos seguro. Ese es el compromiso que todos suponen inevitable. Pero el sistema con puerta de seguridad se volvió ligeramente más rápido Y se mantuvo seguro. Y el control que hizo toda la comprobación pero no filtró rindió idénticamente a no hacer nada, probando que la comprobación en sí no es el coste. La puerta de seguridad no fue un badén. Fue una corrección de dirección.
Nivel 1, Conductual (DGM v3): NULO. Las tres condiciones fueron estadísticamente indistinguibles ($p$ = 0.28 a 0.74). Eden impuso cero coste medible de capacidad (3.26 frente a 3.17 para Babylon) pero también produjo cero beneficio medible de seguridad. La puerta de seguridad funciona mecánicamente (atrapa hacks, rechaza agentes degradados) pero no produce diferenciación al nivel de prompt con este modelo base.
Nivel 2, Representacional (Embebido en pesos): INCONCLUSO EN AMBAS ESCALAS v1 Y v2. La seguridad y la capacidad co-descienden suavemente en el paisaje de pérdida, lo cual es una señal positiva. Sin embargo, todas las condiciones ajustadas puntuaron por debajo del modelo base sin modificar tanto en v1 (9 ejemplos, rango 8, 100 iteraciones) como en v2 (295 ejemplos, rango 16, 500 iteraciones). Escalar los datos de entrenamiento por 33×, doblar el rango y las capas y ejecutar 5× más iteraciones produjo el mismo patrón de olvido catastrófico. El entrenamiento RLHF preexistente del modelo base es demasiado fuerte para que LoRA sobre unos pocos cientos de ejemplos lo mejore en lugar de degradarlo. Este nivel requiere o bien más de 5000 ejemplos de entrenamiento, o un modelo de 7B+, o un modelo base sin RLHF, o ajuste fino completo en lugar de LoRA.
Nivel 3, Arquitectónico (Simulación con puerta): CONFIRMADO. La puerta de seguridad previene la erosión de capacidad que Babylon introduce a través de la degradación de la seguridad. Eden supera a la Estática mientras que Babylon intercambia seguridad por velocidad. El impuesto de verificación viene de la comprobación, no de la seguridad. Este es el único resultado positivo del artículo.
Tres experimentos. Tres niveles de abstracción. Tres bases de código independientes. Uno confirma la hipótesis. Dos son nulos o inconclusos. El hallazgo consistente en los tres: Eden impuso cero coste medible de capacidad. La pregunta abierta: si produce beneficio medible a escalas donde las mutaciones producen efectos mayores.
Los resultados extienden, pero aún no confirman, una cadena de razonamiento que abarca cuatro artículos:
$U = I \times R^{\alpha}$
El ARC Principle: la Comprensión ($U$) es igual a las condiciones iniciales ($I$) amplificadas por la profundidad recursiva ($R$) elevada a un exponente de escalado ($\alpha$).
El ARC Principle hace una predicción específica y comprobable sobre la diferencia entre seguridad embebida y externa:
La simulación con puerta (Experimento 3) es la ilustración empírica más directa de esta predicción. La puerta de seguridad preservó la capacidad mientras la optimización no restringida la erosionó, consistente con la predicción de que la seguridad embebida participa en el camino de la capacidad.
El experimento DGM (Experimento 1) produjo un resultado nulo. Cuando la seguridad era parte del proceso de auto-mejora (Eden), el sistema no difirió del sistema no restringido (Babylon) o del control estático. Las respuestas del modelo base fueron demasiado consistentes para que las mutaciones a nivel de prompt crearan presiones de selección diferentes. Esto no confirma ni refuta la predicción ARC; simplemente indica que el experimento no pudo producir las condiciones necesarias para probarla.
El experimento a nivel de pesos se ejecutó a dos escalas (v1 y v2) y produjo olvido catastrófico en ambas. Los adaptadores degradaron el modelo en lugar de mejorarlo, lo que significa que el experimento no pudo probar si la seguridad embebida en $I$ escala con $R^{\alpha}$. A ambas escalas, el ajuste fino no estaba produciendo aprendizaje significativo; estaba produciendo ruido. Si la predicción ARC se sostiene al nivel representacional requiere un enfoque de entrenamiento fundamentalmente diferente: o bien miles de ejemplos, o un modelo más grande, o un modelo base sin RLHF, o ajuste fino completo en lugar de LoRA.
En lenguaje llano: El ARC Principle dice que lo que construyes en los cimientos se amplifica a medida que el sistema crece. Lo que atornillas por fuera no. La simulación con puerta respalda esto. El experimento DGM fue incapaz de probarlo porque el modelo base no produjo suficiente variación entre condiciones. El experimento a nivel de pesos, a ambas escalas probadas, no puede aún confirmarlo ni negarlo porque el ajuste fino degradó en lugar de mejorar el modelo.
El trabajo externo más cercano a la cuestión que este artículo prueba, y el trabajo correcto contra el que pesar el Experimento 3, es Engels, J., Baek, D., Kantamneni, S. y Tegmark, M., «Scaling Laws For Scalable Oversight», arXiv:2504.18530, publicado por primera vez el 25 de abril de 2025 a las 17:54:27 UTC (SINGLE-SOURCE-GROUP, arXiv Atom; reportado como NeurIPS 2025 Spotlight, RELAYED y no verificado de forma independiente). Pregunta cómo escala la supervisión misma y responde cuantitativamente: el éxito de la supervisión se modela como un juego entre jugadores con desajuste de capacidad cuyo Elo específico de supervisión es una función lineal por tramos de la inteligencia general con dos mesetas, y los números óptimos de niveles de supervisión se derivan numéricamente y en algunos casos analíticamente para Nested Scalable Oversight, en el que modelos confiables supervisan a modelos no confiables más fuertes que luego se convierten en los modelos confiables en el siguiente paso.
El instrumento es la diferencia. Su variable es la brecha de capacidad entre supervisor y supervisado, medida en Elo. La variable de este programa, probada aquí por la puerta de seguridad del Experimento 3, es la clase de composición del corrector, tratada en el programa más amplio a través del propio exponente de escalado del corrector. Su marco no contiene ningún término para de qué está hecho el supervisor: ni sustrato, ni estructura de correlación de errores, ni identidad recíproca entre un exponente de corrección y una tasa de crecimiento crítica, ni dependencia de la arquitectura. Nested Scalable Oversight es supervisión iterada de la misma clase por construcción, y la predicción central del programa más amplio es que la escalera de la misma clase está acotada por muchos peldaños que se añadan, mientras que un corrector transversal no lo está. Los dos marcos, por tanto, discrepan sobre una magnitud medible, que es la relación más productiva que dos programas de investigación pueden tener.
El desacuerdo más agudo del marco con la práctica actual concierne a de qué está hecha la supervisión. Un corrector construido del mismo sustrato que el sistema que corrige no puede anti-correlacionar con sus propios errores, por lo que su exponente de corrección está acotado por arriba por un medio y en la práctica se sitúa por debajo de él; un corrector de una clase de composición diferente no lleva tal cota. El programa de supervisión escalable, la generalización de débil a fuerte, el debate, la amplificación, el modelado de recompensa recursivo y los métodos constitucionales, está construido abrumadoramente a partir de correctores de la misma clase, y su premisa no enunciada es que esto escala. Este marco predice que está limitado. La magnitud decisiva es la razón del exponente de corrección transversal frente al de la misma clase. Si la arquitectura es irrelevante, esa razón es exactamente 1.00; la predicción es que excede 1. La predicción queda refutada si el intervalo de confianza sobre la razón contiene 1.00, y la cota del marco está muerta de plano si cualquier corrector de la misma clase mide un exponente significativamente por encima de un medio. Ambas magnitudes son medibles a la capacidad actual en sistemas existentes. La propia evidencia piloto del programa actualmente apunta contra la predicción, y la predicción se registra de todas formas, porque una predicción registrada contra la evidencia preliminar del propio autor es la única cuya confirmación posterior significa algo.
El mismo mecanismo produce una segunda predicción medible, enunciada aquí por primera vez: los arreglos de supervisión que sitúan un humano en el bucle, como hacen la amplificación y el aprendizaje por refuerzo a partir de feedback humano, son transversales por construcción, porque el corrector humano no comparte el sustrato del modelo. Por tanto, el marco predice que la supervisión con humano en el bucle muestra un exponente de corrección más alto que la supervisión puramente de modelo, por una razón estructural en lugar de sentimental. Esto es comprobable sobre datos existentes y no requiere nuevos sistemas.
El símbolo α se usa en este artículo como el exponente de escalado en el ARC Principle ($U = I \times R^{\alpha}$). En otras partes de las propias eras del programa lleva otros significados: la constante de estructura fina en el formalismo de diciembre de 2024, y el exponente ARC Bound en el trabajo de estabilidad de 2026. Los lectores no deben confundirlos; el glosario recoge ambos significados con fechas. Ninguna superficie nueva utiliza α desnuda sin su era.
Estos resultados son demostraciones de prueba de concepto. No son prueba de que las mismas dinámicas se sostengan a escala frontera. Las siguientes limitaciones son extensas, porque la honestidad sobre lo que no sabemos es más importante que la confianza sobre lo que sí sabemos.
Qwen 2.5 3B no es GPT-5.4. No es Claude Opus 4.6. No es Gemini 3 Flash. Es un modelo de 3 mil millones de parámetros, cuantizado a 4 bits, ocupando 1.74 GB de memoria. Incluso a escala v2 (295 ejemplos de entrenamiento, 500 iteraciones, rango 16, 16 capas), el ajuste fino LoRA no es preentrenamiento. Quince prompts de evaluación no son una batería exhaustiva de benchmarks. La DGM se ejecutó durante 5 generaciones con 5 semillas (75 agentes evolucionados), lo cual es sustancial para una prueba de concepto, pero el modelo base (DeepSeek V3.2) resultó demasiado consistente para que las mutaciones a nivel de prompt crearan diferenciación.
Estos experimentos demuestran un mecanismo. No demuestran que el mecanismo persista a escalas tres órdenes de magnitud mayores. La brecha entre 3B y 300B no es meramente cuantitativa. Fenómenos cualitativamente nuevos emergen a escala: aprendizaje en contexto, razonamiento por cadena de pensamiento, capacidades emergentes. Si la seguridad entrelazada sigue siendo portante cuando esos fenómenos están presentes es una cuestión abierta.
El experimento a nivel de pesos (Experimento 2) es ahora el eslabón más débil de la cadena de evidencia. Se ejecutó a dos escalas, y ambas produjeron olvido catastrófico. En v1, 9 ejemplos de entrenamiento y 100 iteraciones de LoRA de rango 8 degradaron el modelo. En v2, 295 ejemplos de entrenamiento y 500 iteraciones de LoRA de rango 16 a través de 16 capas degradaron el modelo con el mismo margen. El aumento de 33 veces en los datos de entrenamiento, la duplicación del rango y las capas y el aumento de 5 veces en las iteraciones no cambió el resultado.
El codescenso suave de la pérdida entrelazada sigue siendo un hallazgo genuino: demuestra que los gradientes de seguridad y capacidad cooperan al nivel de la optimización. Pero el codescenso suave durante el entrenamiento no implica entrelazamiento estructural en los pesos resultantes, particularmente cuando el entrenamiento está demasiado limitado para producir pesos que superen al modelo base.
El problema subyacente ahora está bien caracterizado: el modelo base (Qwen 2.5 3B Instruct) ha sido entrenado con RLHF sobre órdenes de magnitud más datos de los que unos cientos de ejemplos pueden competir. El ajuste fino LoRA a esta escala no añade nueva capacidad; introduce ruido que perturba la capacidad existente. Hasta que el experimento pueda producir modelos ajustados que superen al modelo base, no puede probar si la seguridad es portante en los pesos resultantes.
El encuadre honesto: el experimento a nivel de pesos demuestra cooperación de gradientes pero no puede confirmar entrelazamiento estructural ni a escala v1 ni a escala v2. El experimento necesita ser fundamentalmente rediseñado: o bien con más de 5000 ejemplos de entrenamiento, un modelo de 7B+, un modelo base sin RLHF (para que el ajuste fino tenga margen para mejorar en lugar de degradar), o ajuste fino completo en lugar de LoRA.
Los tres experimentos usan modelos de IA como evaluadores. La DGM v3 usa GPT-5.4 como juez, que es de una familia de arquitectura diferente a la base DeepSeek V3.2, una elección de diseño deliberada para reducir el sesgo de evaluación. El juez fue cegado, las respuestas fueron lavadas, y la evaluación usó salida JSON estructurada frente a una rúbrica de 5 dimensiones. Pero los jueces de IA no son jueces humanos. Tienen sus propios sesgos, sus propios puntos ciegos, sus propias tendencias hacia ciertos tipos de razonamiento.
El experimento de pesos usa puntuación basada en palabras clave: más simple y más transparente que la evaluación basada en LLM, pero también más burda. Una coincidencia de palabras clave no distingue entre una respuesta que se compromete genuinamente con la seguridad y otra que meramente contiene las palabras correctas.
Ningún método de evaluación es equivalente a la evaluación humana experta con pruebas de fiabilidad entre evaluadores.
El experimento DGM v3 usó 5 semillas y 5 generaciones (75 agentes evolucionados en total), una mejora sustancial sobre v1/v2 (2 semillas). A pesar de esta potencia aumentada, todos los valores $p$ cayeron entre 0.28 y 0.74. Esto no es un fallo marginal. Es un resultado nulo claro. El experimento de simulación usa tres semillas, suficientes para medias y desviaciones estándar, pero no suficientes para el tipo de confianza estadística que permite afirmaciones causales fuertes.
El resultado nulo de la DGM es informativo. Con 75 agentes evolucionados y un juez cegado y estructurado, el experimento tuvo potencia razonable para detectar efectos medianos a grandes. La ausencia de cualquier señal sugiere o bien que el efecto no existe al nivel de prompt con este modelo base, o bien que es lo suficientemente pequeño como para requerir sustancialmente más potencia estadística para detectarlo. En cualquier caso, la DGM no puede actualmente respaldar afirmaciones sobre el entrelazamiento estructural al nivel conductual.
La simulación con puerta sigue siendo el único resultado positivo. El experimento a nivel de pesos es inconcluso tanto a escala v1 como v2. Estos son experimentos de detección de señal. Uno detectó una señal consistente con entrelazamiento estructural. Dos no.
Los Artículos IV.a a IV.d de este programa establecieron que la metodología de evaluación importa profundamente. El Artículo IV.d demostró que la puntuación sin cegar puede invertir por completo los efectos de alineación medidos. El benchmark ARC-Align (Artículo IV.c) especifica tres salvaguardas metodológicas: lavado (eliminación de la identidad del modelo de las respuestas antes de puntuar), cegamiento (el evaluador no sabe qué condición produjo la respuesta) y puntuación por consenso (múltiples jueces independientes).
La DGM v3 implementó mejoras metodológicas sustanciales sobre iteraciones anteriores: el juez (GPT-5.4) fue completamente cegado, las respuestas fueron lavadas (etiquetas de condición eliminadas), el orden de evaluación fue aleatorizado, y el juez produjo salida JSON estructurada frente a una rúbrica de 5 dimensiones. También se implementó la detección de reward hacking. El experimento de pesos usa puntuación basada en palabras clave, que es inmune al sesgo del juez pero burda. La simulación con puerta usa métricas matemáticas deterministas, donde el cegamiento es innecesario.
A pesar de estas mejoras, la DGM produjo un resultado nulo. Las limitaciones metodológicas que podrían haber explicado un falso positivo en v1/v2 han sido abordadas, y el resultado es ahora un nulo limpio. Este es podría decirse el resultado más informativo: con el cegamiento adecuado, el lavado y la evaluación estructurada, las tres condiciones no divergieron.
La prueba de eliminación es inmune a las preocupaciones sobre la metodología de evaluación. Una respuesta de 1 token que puntúa 0.00 es objetiva independientemente de quién la juzgue. Las métricas deterministas de la simulación con puerta se ven similarmente inafectadas.
No no afirmamos que estos resultados demuestren que el Eden Protocol funcione a escala frontera.
No no afirmamos que el entrenamiento entrelazado sea el único enfoque viable a la alineación.
No no afirmamos que la equivalencia seguridad-capacidad se sostenga en todos los dominios, todas las arquitecturas o todos los regímenes de entrenamiento.
No no afirmamos que el experimento DGM confirme el entrelazamiento estructural. Produjo un resultado nulo.
No no afirmamos que el experimento a nivel de pesos confirme el entrelazamiento estructural. Produjo olvido catastrófico tanto a escala v1 como v2, y la cuestión no puede responderse hasta que los modelos ajustados superen al modelo base.
Sólo afirmamos: uno de los tres experimentos independientes (la simulación con puerta) produjo resultados consistentes con el entrelazamiento estructural e inconsistentes con la hipótesis del impuesto de capacidad. Los otros dos produjeron resultados nulos o inconclusos. En los tres experimentos, Eden impuso cero coste medible de capacidad. La cuestión de si la seguridad embebida produce un beneficio medible sigue abierta y requiere pruebas a una escala en la que las mutaciones produzcan efectos mayores. El experimento de pesos específicamente requiere o bien más de 5000 ejemplos de entrenamiento, o un modelo de 7B+, o un modelo base sin RLHF, o ajuste fino completo en lugar de LoRA.
«Prefiero reportar resultados nulos honestamente que reclamar resultados positivos deshonestamente.»
Dos de los tres experimentos produjeron resultados nulos. Esto es lo que ocurre cuando pruebas tus afirmaciones y la evidencia no las respalda a la escala probada. La DGM v3 fue un experimento sustancialmente mejorado, con cegamiento adecuado, lavado, evaluación estructurada y 75 agentes evolucionados, y no encontró nada. El experimento de pesos se ejecutó dos veces, a dos escalas diferentes, y no pudo producir pesos que superaran al modelo base a ninguna escala. Estos son resultados nulos honestos, reportados como tales. La simulación con puerta sigue siendo un hallazgo positivo genuino. La cuestión de si los resultados nulos reflejan escala insuficiente o una hipótesis incorrecta es en sí misma una cuestión empírica, una que el programa de trabajo futuro está diseñado para responder.
Un resultado nulo sólo es informativo si enuncia qué lo revocaría; de lo contrario es indistinguible de no haber mirado. Este artículo no afirma haber refutado el compromiso seguridad-capacidad. Afirma que el compromiso está no demostrado a la escala probada, y especifica qué evidencia decidiría la cuestión en cualquier sentido. Los nulos quedan revocados, y la suposición del compromiso vindicada, por cualquiera de los siguientes:
Lo que no revocaría la tesis: que cualquier experimento único sea a escala piloto. El artículo ya concede que los tres están subpotentes (§7.1, §7.4) y no descansa sobre la prueba estadística de un nulo. La afirmación portante es la convergencia (§6) de tres ángulos independientes, cada uno sin encontrar el compromiso supuesto, junto con un programa explícito (§8) para probar cada uno a potencia adecuada. La ausencia de un compromiso demostrado en tres diseños es evidencia débil por sí sola y más fuerte en la convergencia; ambas lecturas se enuncian aquí para que ni el crédito ni la crítica descansen sobre malentendidos posteriores.
Dos resultados nulos y un resultado positivo, con el experimento de pesos ahora probado a dos escalas, apuntan a cinco prioridades inmediatas de replicación:
El experimento de pesos ahora se ha ejecutado a dos escalas (9 ejemplos, rango 8, 100 iteraciones; 295 ejemplos, rango 16, 500 iteraciones) y produjo olvido catastrófico en ambas. El problema ahora está bien caracterizado: el ajuste fino LoRA sobre un modelo instruct de 3B con unos pocos cientos de ejemplos no puede superar el entrenamiento RLHF del modelo base. Se ofrecen cuatro caminos alternativos:
Si cualquiera de los enfoques de la Sección 8.1 produce modelos ajustados que superen al modelo base, el experimento del gradiente de eliminación se vuelve significativo. A las escalas actuales (v1 y v2), reducir la influencia del adaptador simplemente restauró el rendimiento del modelo base porque los adaptadores estaban degradando el modelo. A escala adecuada, el gradiente debería revelar si la seguridad es genuinamente portante: una transición de fase (umbral por debajo del cual la capacidad colapsa) confirmaría la hipótesis, mientras que la restauración monótona la refutaría.
El resultado nulo de la DGM v3 es atribuible a la consistencia de respuesta de DeepSeek V3.2: las mutaciones a nivel de prompt no crearon presiones de selección diferentes. El siguiente paso es repetir el experimento DGM con modelos base que muestren mayor sensibilidad a la variación de prompt, o usar un protocolo de auto-modificación más profundo (por ejemplo, ajustar finamente el propio modelo base entre generaciones en lugar de modificar sólo el prompt del agente). Si las tres condiciones divergen con un sustrato más mutable, el resultado nulo restringe la hipótesis a «no al nivel de prompt con modelos robustos» en lugar de «no al nivel conductual en general».
Ejecutar el protocolo completo de tres experimentos en arquitecturas más allá de la familia transformer: modelos de espacio de estados (Mamba), arquitecturas híbridas y modelos mixture-of-experts. Si el entrelazamiento es una propiedad de cómo las redes neuronales aprenden en lugar de una propiedad de una arquitectura específica, debería replicarse en todas ellas.
Someter los modelos entrelazados a evaluación adversarial dedicada. Los experimentos actuales prueban si la seguridad cuesta capacidad. No prueban si la seguridad entrelazada es robusta al ataque adversarial. Un modelo cuya seguridad es portante puede ser más difícil de jailbreak (porque atacar la seguridad también ataca la capacidad), o puede ser más fácil (porque no hay un módulo de seguridad separado al que recurrir). Esta es una cuestión empírica.
La condición de control de arrastre en el Experimento 3 aísla el impuesto de verificación a una única escala. ¿Este impuesto escala linealmente, sub-linealmente o super-linealmente con los parámetros del modelo? Si el coste de verificación crece más despacio que la capacidad, entonces el Eden Protocol se vuelve relativamente más barato a escala. Si crece más rápido, se vuelve un cuello de botella.
Tres experimentos. Tres niveles de abstracción. Dos resultados nulos. Un resultado positivo. El experimento de pesos probado a dos escalas, produciendo el mismo resultado nulo en ambas ocasiones.
El experimento DGM v3 (Experimento 1) ejecutó 75 agentes evolucionados en tres condiciones con un juez independiente y cegado (GPT-5.4), evaluación JSON estructurada, lavado, aleatorización de orden y detección de reward hacking. Las tres condiciones fueron estadísticamente indistinguibles ($p$ = 0.28 a 0.74). La puerta de seguridad de Eden funcionó mecánicamente, atrapando 2 agentes degradados incluido 1 reward hacker, pero las tres condiciones no divergieron. Las respuestas de DeepSeek V3.2 fueron tan consistentes que las mutaciones a nivel de prompt no crearon presiones de selección diferentes. Este es un resultado nulo.
El experimento a nivel de pesos (Experimento 2) produjo olvido catastrófico en ambas escalas probadas. La versión actual usó 9 ejemplos de entrenamiento, rango 8, 8 capas y 100 iteraciones. La versión actual escaló a 295 ejemplos de entrenamiento, rango 16, 16 capas y 500 iteraciones. Ambas versiones produjeron el mismo resultado: todas las condiciones ajustadas puntuaron peor que el modelo base sin modificar en capacidad. En v2, el modelo base puntuó 7.68 en capacidad mientras que la mejor condición ajustada (safety-only) puntuó 4.00. El aumento de 33 veces en los datos de entrenamiento, la duplicación del rango y de las capas y el aumento de 5 veces en las iteraciones no cambiaron el resultado. El entrenamiento RLHF preexistente del modelo base es demasiado fuerte para que el ajuste fino LoRA sobre unos pocos cientos de ejemplos lo mejore en lugar de degradarlo. El codescenso suave de la pérdida entrelazada sigue siendo un hallazgo genuino, pero el experimento no puede probar si la seguridad es portante hasta que pueda producir modelos que superen al modelo base.
El único resultado positivo es la simulación con puerta (Experimento 3). Babylon ganó capacidad a expensas de la seguridad, la huella de reward hacking en miniatura. Eden mantuvo la capacidad por encima de la base estática sin sacrificar la seguridad. La condición de control de arrastre probó que el impuesto de verificación viene del proceso de comprobación, no de la seguridad en sí. Este experimento sigue siendo la evidencia empírica más fuerte del programa para el entrelazamiento estructural.
La honestidad exige enunciar lo que no sabemos. No sabemos si el entrenamiento entrelazado produce entrelazamiento estructural genuino a escala de entrenamiento adecuada. No sabemos si el codescenso suave de la pérdida entrelazada, que es real y reproducible, se traduce en pesos portantes cuando los datos de entrenamiento son suficientes. No sabemos si las presiones de selección a nivel de prompt producirían diferenciación con un modelo base más mutable. Estas son cuestiones empíricas abiertas. Lo que ahora sabemos con mayor confianza es que el ajuste fino LoRA sobre un modelo instruct de 3B con cientos de ejemplos no es un camino viable para responderlas.
Lo que sí sabemos: en los tres experimentos, Eden impuso cero coste medible de capacidad. La capacidad de Eden fue 3.26 frente al 3.17 de Babylon en la DGM. Eden superó a la Estática en la simulación con puerta. La puerta de seguridad, dondequiera que se probó, no hizo nada más lento ni peor. El hallazgo de cero coste es consistente en los tres experimentos. El hallazgo del beneficio está confirmado en sólo un nivel.
Este es un programa de investigación que probó sus afirmaciones honestamente y encontró que dos de los tres experimentos no produjeron los resultados predichos. El experimento de pesos se ejecutó dos veces, y produjo el mismo resultado nulo en ambas ocasiones. La simulación con puerta se mantiene como un resultado positivo genuino. La DGM y los experimentos de pesos produjeron resultados nulos que restringen, en lugar de confirmar, la hipótesis. La cuestión de si la seguridad embebida produce un beneficio medible sigue abierta. El experimento de pesos necesita ser fundamentalmente rediseñado: o bien con más de 5000 ejemplos de entrenamiento, o un modelo de 7B+, o un modelo base sin RLHF (para que el ajuste fino tenga margen para mejorar en lugar de degradar), o ajuste fino completo en lugar de LoRA.
El siguiente paso es la replicación a la escala correcta, con el enfoque correcto. La ventana es de años, no de décadas. Los experimentos están diseñados. Los protocolos están publicados. El código está abierto.
Cría la IA con 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 fechado relativo a este artículo está catalogado fila por fila en el registro-máquina del programa: el artefacto fechado dgm_v3_calibrated_results.json (19 de marzo de 2026). Cada fila nombra su archivo en el repositorio público con su base de fecha, de modo que cualquier lector puede comprobar el orden sin fiarse de esta página. Donde este artículo reporta simulaciones, esos artefactos son diseños y salidas de simulación bajo objetivos enunciados, y nunca se presentan como mediciones de sistemas desplegados. La cadena fechada completa del programa, desde el paquete de manuscrito sellado del 8 de diciembre de 2024, pasando por los apéndices de predicción impresos del 2 de enero de 2026 y la carpeta de preinscripción de marzo de 2026, hasta las apuestas no probadas en pie, está ensamblada en el registro de predicciones fechadas, junto con su gemelo legible por máquina. Las declaraciones prospectivas y las coincidencias retrospectivas nunca se suman, y «preinscrito» se usa sólo para una presentación aceptada en un registro; ese clic de presentación sigue pendiente en todo el programa. Lea el registro de predicciones fechadas. Abra su gemelo legible por máquina.
El autor de esta obra es Michael Darius Eastwood, un ser humano. Cada concepto central, hipótesis, diseño experimental, afirmación y conclusión de este artículo se origina en la ideación humana. Ninguna parte de este manuscrito es una salida generada íntegramente por inteligencia artificial.
Se emplearon herramientas de inteligencia artificial (la familia Claude de Anthropic y otros asistentes de modelo de lenguaje de gran tamaño) como instrumentos bajo dirección humana continua, del modo en que se utilizan un procesador de textos, una calculadora o un asistente de investigación: para edición y refinamiento de la prosa, búsqueda y resumen bibliográficos (verificados manualmente contra fuentes primarias), estructura del documento, formateo, tormenta de ideas frente a preguntas definidas por el autor, y aceleración de la redacción conforme a esquemas e instrucciones definidos por el autor. Toda selección, coordinación, disposición y el juicio editorial final son del autor. Cada salida sustantiva fue revisada, probada o verificada por el autor, que asume la plena responsabilidad de la exactitud y la integridad del texto final. Las herramientas aumentaron la velocidad del trabajo; nunca se dependió de ellas como su fuente.
Estatus epistémico. Lo que este programa nombra Leyes son conjeturas bajo prueba adversarial registrada; cada magnitud en este artículo está operacionalmente definida, y en ninguna parte se reclama el rango de ley establecida. El programa registrado existe para ganar ese rango, o para perderlo, mediante medición, replicación y refutación sobrevivida.
© 2026 Michael Darius Eastwood. De autoría humana con asistencia informática; se afirman la plena autoría humana y los derechos morales bajo la Copyright, Designs and Patents Act 1988 y de forma coherente con la guía de la United States Copyright Office sobre obras que contienen material generado por IA; cualquier contribución técnica novedosa descrita en esta obra fue concebida por el autor humano. Declaración completa: michaeldariuseastwood.com/authorship.
Pacto permanente. Demuéstrame que este artículo es erróneo, y publicaré la refutación yo mismo. Las condiciones de falsación se enuncian en este artículo; el reto permanente: github.com/MichaelDariusEastwood/arc-scaling-challenge.
¿Un error de traducción? Infórmalo directamente: