¿Por qué los androides podrían estar diseñados para reescribir su programación?

Dado que la empresa diseñó y fabricó los androides, en realidad los posee. Lograr que los androides reescriban la programación permitirá a la empresa no emplear a programadores humanos para realizar la misma función. Los programadores humanos tienen la mala costumbre de exigir el pago de sus servicios. Si eres el propietario de los androides, la empresa no tiene que pagarlos.

En conclusión, para ahorrar dinero mediante la reducción de los costos laborales. Esta es una estrategia industrial bien conocida y ampliamente practicada. Lo que sucedió en el pasado puede suceder y sucederá en el futuro.

PD: Esta respuesta asume que la programación de los androides será capaz de generar el comportamiento emergente necesario para una inteligencia artificial funcional. Por lo tanto, reescribir su programación conducirá, con suerte, a una mejor inteligencia artificial.

Tenemos un software que reescribe su programación todo el tiempo

Justo el otro día escribí un software que ejecuta una búsqueda Tabu. En una búsqueda tabú, su algoritmo se "reescribe" a sí mismo para evitar volver sobre sus propios pasos.

A menudo hablamos de "reescribir su programación" en un sentido muy informal. Pero si realmente comienzas a investigarlo, en realidad es un tema relativamente complejo. Podemos ver lo que significa observando qué simetrías de tiempo se mantienen durante la reescritura. Por ejemplo, no se permitió que mi búsqueda tabú cambiara lo que estaba optimizando en el camino. Podría ajustar su camino, pero no su objetivo.

Cuando comenzamos a hablar de "reescribir su programación", creo que lo que realmente estamos tratando de lograr es comenzar a recortar esas simetrías temporales, esas invariantes. Por ejemplo, C# incluye un pequeño y hermoso módulo llamado DLR, Dynamic Language Runtime. Esta es una extensión inteligente de C# que permite la optimización de lenguajes dinámicos como Python. Implica escribir código (como en los códigos de operación CLI) para realizar ciertas tareas sobre la marcha. Puede escribir cualquier cosa en la CLI que le plazca, pero está prohibido escribir algo que no sea una CLI válida. Esto significa que no puede hacer cosas como mirar la memoria que no tiene los privilegios para mirar.

Un paso más podría ser escribir código de máquina. PyPy es un intérprete de Python que genera código de máquina, como bytecodes x86. Esto puede hacer cualquier cosa que uno pueda hacer en un proceso, incluso mirar la memoria que no debería. Sin embargo, permanece confinado en un proceso del sistema operativo. No puede comunicarse con otros procesos sin usar el sistema operativo para facilitar esa comunicación. No puede escribir en la pantalla ni obtener entradas del teclado sin que el sistema operativo lo ayude.

Entonces, ¿qué pasa si los liberamos del sistema operativo? ¿Y si les damos acceso a todo el hardware? Bueno, siempre existe la idea de un hipervisor que hace que parezca que tienes acceso al hardware sin procesar, cuando no es así.

Este proceso puede continuar hasta donde lo desee. En algún nivel profundo, podemos escribir código "invariable" que respalde nuestros deseos. Luego permitimos que el androide haga cualquier otra cosa que quiera, ya que carece de la capacidad de modificar estos invariantes.

Esto lleva a la respuesta interna: les permitimos modificar su programación porque no pueden modificarla de una manera que es inaceptable para nosotros. Mientras no puedan hacer algo mal, permitir que los androides se reprogramen a sí mismos abre un número incalculable de ventajas. Me refiero a "no dicho" literalmente. No puedo escribir todas las razones por las que uno elegiría seguir este camino. Una clase importante de estos es la personalización. Si desea que su Android haga las cosas a su manera, no hay forma de que una corporación gigante pueda proporcionarle exactamente lo que desea . En su lugar, te proporcionan un androide flexible que puede enseñarse a sí mismo a hacer lo que quieras .

Menciono que esto es insidioso. Bueno, hay una gran historia de los primeros días de Unix. Esto se conoce como el truco de Ken Thompson , en honor al desarrollador que lo hizo posible. Escribió una puerta trasera en el loginprograma en UNIX, para permitirle iniciar sesión como cualquier usuario si ingresaba su contraseña especial. Por supuesto, ningún tonto dejaría código como

if (password == "SayFriendToEnter")
   grantAccess();

en un programa clave de seguridad de UNIX como login. Entonces, en cambio, Ken lo inyectó en el compilador. Ken escribe un código adicional en el compilador para que, si ve un fragmento particular del logincódigo fuente conocido, inyecte su código de puerta trasera allí mismo.

Por supuesto, Ken sabía que la comunidad de compiladores también desaprobaría esto. Así que escribió un segundo fragmento. Si el compilador reconociera esas pocas líneas cercanas del código fuente del compilador, inyectaría esa verificación en sí mismo , incluido el código para modificar la próxima versión compilada. Luego compiló esto y distribuyó los binarios resultantes a la comunidad para 'impulsar' el uso del compilador (si alguna vez ha realizado una instalación de Gentoo Stage 0, donde comienza con casi nada, es increíble. Aprecia cada un poco de ayuda que puedes obtener. Y el ataque de Ken golpeó antes de la Etapa 0).

Entonces, lo que terminamos fue una gran cantidad de computadoras cuyo compilador sigilosamente compiló una puerta trasera en sí misma, y ​​luego esas puertas traseras se colocaron en login. Nadie se dio cuenta de esto hasta que lo anunció en su discurso de 1984, "Reflexiones sobre la confianza en la confianza", donde admitió que lo hizo.

¿Por qué contar esta historia? Es famoso que un jefe de la mafia dijo una vez: "No me importa el nombre de quién esté en la boleta, siempre que pueda elegir al ganador". Si puede colar una puerta trasera en el compilador para que el androide nunca se dé cuenta de que hay un agujero, entonces puede dejar que el androide compile lo que quiera.

Entonces, ¿por qué dejar que los androides se reprogramen a sí mismos? La razón es natural: déjalos que se reprogramen porque hay mil millones de razones para hacerlo, y si tienes las puertas traseras secretas correctas en su proceso de programación, no hay inconveniente en dejar que se reprogramen. ¡Es una obviedad!

Porque eres una empresa

Si no lo hace, otra empresa lo hará.

Tendrían una ventaja sobre usted de los robots que pueden mejorar a sí mismos. Como empresa, le interesan las ganancias, que es la combinación de aumentar las ventas y disminuir los costos.

Reducir el costo:

Digamos que podría reducir los costos dejando ir a sus desarrolladores internos y haciendo que mejoren por sí mismos, como empresa, lo consideraría seriamente. Si los androides defectuosos pudieran eliminarse a bajo costo, en lugar de contratar y pagar a los humanos con todos los accesorios necesarios para su empleo, entonces esto se consideraría seriamente.

Aumentar el beneficio:

Si su empresa depende de la innovación, por ejemplo, una empresa como Apple, sería deseable ampliar los límites de sus productos para lanzarlos al mercado lo antes posible.

Todo el mundo quiere lo 'siguiente mejor', estas empresas prosperan con esos sentimientos en el mercado. Si tiene métodos de producción automejorados, puede alcanzar la demanda del mercado mucho más rápido que otras empresas que dependen de métodos más antiguos.

Mayor competitividad:

Es posible que pueda producir productos de nicho que ninguna otra empresa puede y desarrollar más competitividad. Por ejemplo, megaestructuras o nanoestructuras, que a las personas les resulta demasiado difícil diseñar o comprender (a un costo razonable).

Entonces, como empresa, es probable que solo sea una cuestión de cuándo, no si, su producción se vuelve autosuficiente y autosuficiente.

Por la mejora continua, la especialización y la personalización:

Los programadores humanos han diseñado un Android genérico para todo uso y han establecido los fundamentos básicos de sus operaciones (que incluyen las 3 leyes de la robótica ) en código compilado y permiten que los robots ejecuten un intérprete para el cual pueden escribir su propio código para optimizar para tareas especiales que sus dueños les ordenan hacer.

Luego, este código especial se carga en la sede de la empresa y se analiza heurísticamente y luego se propone a los programadores humanos para que lo incluyan nuevamente en el código compilado que luego se implementará en los androides de prueba internos, luego en algunos androides de prueba propiedad de la compañía en los hogares de empleados de la empresa, luego para probar a los usuarios, luego al mundo.

ventajas:

• Los propietarios son las PYMES (Subject Matter Experts) dando comandos de voz a los androides que se reprogramarán para que la empresa no tenga que pagar a las PYMES: la "comunidad de propietarios" solo lo hace gratis porque quieren que su androide sea mejor en sus tareas.
• Lo que la mayoría de los propietarios quieren se implementará en la próxima actualización del código compilado invalidando el código interpretado, por lo que necesita menos analistas, estudios de mercado, estudios de usuarios, ... para mejorar los modelos actuales a través de actualizaciones.

• Permite a los programadores de la empresa especializarse en:

  • Peligrosas operaciones mineras de asteroides
  • Cirugía cerebral de alta precisión
  • edificio de la colonia
  • ...
• Es más probable que los clientes alquilen que comprar directamente si las actualizaciones están incluidas en el modelo alquilado.
• El código es más eficiente que grandes cantidades de datos de entrenamiento (que es el estado actual de la IA)

Lo anterior te permitirá tener mucha libertad en este universo tanto para cuentos cortos a la Asimov como para novelas completas, ya que puedes explorar pequeños o grandes impactos que los androides tienen en la sociedad, el trabajo, la exploración espacial, ...

De tal manera que puedan adaptarse a nuevos escenarios y agregar, eliminar o reemplazar su propio código.

Los codificadores de software son escasos, caros y humanos. Esto significa que son lentos para comprender las necesidades específicas de un androide (pasarían por sprints y reuniones de pie para hacer algo de código) y pueden ser fácilmente secuestrados, por ejemplo, por competidores o enemigos.

Para abreviar, codificar Android es demasiado serio para dejar que los humanos lo hagan.

En un entorno competitivo, un androide capaz de readaptar su código en vivo sin esperar a que una fuente externa lo haga tiene una ventaja significativa, por lo que es lógico que este paso se dé.

En lugar de escribir algoritmos y código automodificable, el aprendizaje automático se centra en administrar una matriz de números de coma flotante que modelan el problema que se está resolviendo. Los números se siembran aleatoriamente en la matriz, luego las entradas se alimentan a una matriz de entrada, se ejecutan las fórmulas de la matriz, las salidas se comparan con las salidas esperadas y se realizan cambios en la matriz para un reintento.

Después de unos cuantos millones de repeticiones, la matriz aproxima los sesgos del algoritmo de disparo para que la salida de la operación de la matriz arroje los resultados esperados.

Así es como Siri o el Asistente de Google aprenden a reconocer su voz y convierten los datos de sonido secuenciados en el tiempo en un flujo de instrucciones.

Para obtener información básica sobre la tecnología, consulte la serie de videoconferencias de Andrew ng en YouTube.

Evolucione su código.

El problema con la evolución es que es un desperdicio. Millones de variaciones aleatorias en un código, la mayoría de las cuales no son útiles, algunas de las cuales son dañinas, pero de vez en cuando una que es muy útil, y los descendientes de ese afortunado mutante prosperan. Puede ser que la única forma de determinar que una mutación aleatoria determinada sea útil sea probarla en un entorno.

Un organismo conservador al que le estaba yendo bien nunca podría alterar su código: es lo suficientemente bueno y el riesgo de una desventaja no vale la minúscula posibilidad de recompensa. Eso es especialmente cierto para un organismo que es efectivamente inmortal como un programa de computadora.

Pero imagine ahora múltiples copias de este programa en múltiples cuerpos de Android. Todos los individuos cooperan como un superorganismo; compartiendo el mismo ADN, son efectivamente el mismo organismo. Uno podría tener un subconjunto de individuos (los robots de evolución) que sufrieron mutaciones, alteraciones aleatorias en el código. La mayoría de tales alteraciones serían perjudiciales.

En un superorganismo cooperativo, un robot evolutivo podría tropezar aleatoriamente con una mutación beneficiosa, una forma de lograr lo que necesita lograr que es un poco más eficiente o efectiva. Una vez que se reconoce esta mejora, se puede transmitir a todas las demás personas, que actualizan sus programas para incorporar el código mejorado.

En el momento de la producción, la empresa aún no sabe dónde o cómo se utilizarán.

De tal manera que sean capaces de adaptarse a nuevos escenarios.

Usted ha respondido a su propia pregunta allí.

El Android se vende como un dispositivo multifuncional para todo tipo de clima y todo terreno. Sin embargo, en los principales centros de producción aún no saben a dónde serán enviados, ni qué se les exigirá. Tienen pedidos para los androides que llegan de todo el mundo y podrían ser necesarios para casi cualquier tarea imaginable, y muchas no imaginables.

Entonces, ¿Qué haces? ¿Gastó millones de horas-hombre de trabajo de desarrollo para crear decenas de miles de módulos diferentes y variaciones de los mismos para cubrir todas las capacidades posibles en todos los entornos posibles que podrían ser necesarios? ¿Luego pasar por la molestia de que los empleados agreguen y eliminen los diferentes módulos según las necesidades del cliente y tener que clasificarlos y asegurarse de que se envíen los correctos a los clientes correctos? El personal de ventas que va y viene entre el cliente y el personal de producción para personalizar cada Android para cada cliente puede ser costoso.

No, dado que tiene la capacidad, sería mucho más eficiente tener un centro de producción, que produce solo un producto y lo envía todo. Luego, cuando el cliente lo recibe, le dice al androide lo que quiere que haga, y es lo suficientemente inteligente como para reescribir su propio código para hacerlo en el entorno en el que tiene que funcionar.

La distinción entre Máquina y Humano es bastante clara. Una calculadora no comete errores, solo propaga el error del usuario humano. Si ingresa un cálculo en una calculadora y obtiene un resultado diferente al que esperaba, es probable que se haya ingresado incorrectamente un signo menos o debido a algún otro error de entrada trivial. Para decirlo de otra manera, la entrada humana es la variable más difícil y dinámica para una máquina. Es imposible de predecir y difícil, cuando es predecible, de manejar.

La codificación en sí es un error humano. Tendría sentido que una vez que un programa comenzara a comprender su propia codificación, podría reescribir partes que podrían causar errores. Luego podría evolucionar para reescribir funciones completas que podrían resultar problemáticas en ciertos escenarios. Entonces podríamos creer que sería necesaria una recreación extensa para que se sobrescribieran todos los rastros de la entrada humana y que el programa en cuestión (su Android aquí) tuviera una comprensión completa de su propia codificación y pudiera simular completamente y dar cuenta de todos. resultados que el programa fue diseñado para manejar.