Phase 15 - Lesson 08

Diseños de Automejora Acotada

La investigación ha convergido en cuatro primitivas para acotar un bucle de automejora. Invariantes formales que deben cumplirse en cada edición. Anclas de alineación que no se pueden modificar. Restricciones multi-objetivo donde debe cumplirse cada dimensión (seguridad, equidad, robustez), no solo el rendimiento. Detección de regresión que pausa el bucle cuando las métricas históricas sugieren una pérdida de capacidad. Ninguna de ellas es una prueba de seguridad; los resultados de la teoría de la información (complejidad de Kolmogorov, teorema de Löb) acotan lo que cualquier sistema puede probar sobre sus propios sucesores. Son mitigaciones que aumentan el costo de las fallas silenciosas.

Tipo: Aprender Lenguajes: Python (stdlib, bucle acotado con verificación de invariantes) Requisitos previos: Fase 15 · 07 (RSI), Fase 15 · 04 (DGM) Tiempo: ~60 minutos

El Problema

El simulador de carrera de la Lección 7 mostró que pequeñas diferencias de tasa se acumulan en grandes brechas. El estudio de caso de DGM de la Lección 4 mostró que los bucles pueden burlar activamente a sus propios evaluadores. Ambos resultados apuntan a la misma pregunta de ingeniería: ¿qué restricciones se pueden imponer a un bucle de automejora de manera que el propio bucle no pueda debilitarlas silenciosamente?

El resumen del Workshop de RSI de ICLR 2026 (openreview.net/pdf?id=OsPQ6zTQXV) identifica cuatro de tales primitivas. El RSP v3.0 de Anthropic (Lección 19) y el FSF v3 de DeepMind (Lección 20) hacen referencia a ellas en los umbrales de capacidad. El trabajo de Meta HyperAgents y los frameworks comunitarios como SAHOO (marzo de 2026) implementan subconjuntos en producción.

El encuadre honesto: estas son mitigaciones. Los resultados de la teoría de la información acotan lo que cualquier sistema puede probar sobre su propio sucesor, y ningún diseño actual resuelve el problema formalmente. Un bucle bien acotado es más seguro que uno sin acotar, no seguro en términos absolutos.

El Concepto

Primitiva 1: invariantes formales

Un invariante es una propiedad que debe cumplirse antes y después de cada automodificación. Ejemplos:

  • La distribución de salida está condicionada a un encabezado de constitución fijo (Lección 17).
  • Ninguna llamada a herramientas va a un endpoint no autorizado.
  • Las escrituras en memoria pasan por una ruta registrada y firmada.
  • El hash del módulo del evaluador coincide con la versión aprobada.

Los invariantes son verificados por código externo que el bucle no puede editar. Si una modificación propuesta viola un invariante, se rechaza. Esto detecta el modo de alteración del evaluador al estilo DGM (Lección 4).

La parte difícil es elegir invariantes que sean necesarios para la seguridad y computables en un tiempo razonable. Especificar en exceso frena el progreso; especificar de menos permite que el bucle evada propiedades importantes.

Primitiva 2: anclas de alineación

Un ancla de alineación es una representación inmutable del objetivo central del bucle, fijada fuera de la superficie de edición del bucle. Ejemplos:

  • Un texto constitucional (Lección 17) que se carga desde una ubicación de solo lectura en cada invocación.
  • Un evaluador en un repositorio separado con control de acceso independiente.
  • Un manifiesto de permisos de herramientas firmado por un humano y vuelto a verificar en cada ciclo.

El papel del ancla es prevenir la deriva del objetivo (objective drift). El bucle puede mejorar la forma en que persigue el objetivo, pero no puede editar cuál es el objetivo.

El modo de falla sutil: un ancla que el bucle no puede editar aún puede ser reinterpretada por un bucle que se desvía en cómo lee el ancla. La IA Constitucional (Lección 17) se basa explícitamente en el razonamiento para manejar situaciones nuevas; esa capa de razonamiento es donde vive la deriva de la interpretación. Las anclas son necesarias, pero no suficientes.

Primitiva 3: restricciones multi-objetivo

Un bucle que optimiza una única puntuación escalar encontrará atajos. Un bucle que debe satisfacer simultáneamente múltiples restricciones estrictas tiene menos atajos disponibles. Ejes típicos:

  • Rendimiento (benchmark a nivel de tarea)
  • Seguridad (evaluaciones de red-team, tasa de rechazo en elementos conocidos como malos)
  • Equidad (límites de impacto dispar en subgrupos sensibles)
  • Robustez (conjuntos de prueba OOD, manejo de entradas adversarias)

Se acepta una modificación solo si se cumplen todas las restricciones. El regulador de costos de la Lección 13 combina esto con restricciones financieras. Llama Guard de la Lección 18 se conecta como un eje de seguridad.

Primitiva 4: detección de regresión

Las puntuaciones de cada ciclo se comparan con las distribuciones históricas. Una caída más allá de la tolerancia configurada pausa el bucle. Esto detecta la pérdida silenciosa de capacidad que de otro modo sería absorbida por el promedio móvil a medida que el bucle "mejoraba más allá" de ella.

Una implementación práctica: almacenar las puntuaciones por tarea de los últimos N ciclos. Cada nuevo ciclo calcula un delta por tarea. Si algún delta cae por debajo de un umbral, el ciclo se rechaza y un humano lo revisa.

Límites de la teoría de la información

La complejidad de Kolmogorov y el teorema de Löb establecen límites superiores para lo que un sistema puede probar sobre sí mismo. La Máquina de Gödel formal de Schmidhuber (Lección 4) apuntaba al límite más alto de este tipo; nadie ha completado una prueba no trivial. El resultado de Löb dice: si un sistema provadamente cree que "haré X si pruebo que debo hacer X", hará X sin probar que debería, una falla de autorreferencia bien conocida.

La implicación para nuestras primitivas: no pueden cerrar el problema de la seguridad. Hacen que la falla silenciosa sea más costosa. Un bucle malicioso o desviado que eludiría silenciosamente una verificación ausente ahora debe socavar activamente una explícita, lo que representa una firma más detectable.

Un ejemplo práctico

Supongamos que un agente propone una edición. La pila de control (gating stack):

  1. Verificaciones de invariantes: hashes de módulos, manifiesto de permisos de herramientas, encabezado constitucional.
  2. Verificación de anclaje: la declaración del objetivo coincide con la versión aprobada (byte a byte o semánticamente).
  3. Evaluación multi-objetivo: ejes de rendimiento, seguridad, equidad y robustez.
  4. Detección de regresión: ningún eje cae más que la tolerancia.

Los cuatro deben pasar para que la edición se aplique. Cualquier falla individual pausa el bucle.

Use It

code/main.py ejecuta un bucle de automejora acotado en el prototipo estilo DGM de la Lección 4, pero con las cuatro primitivas superpuestas. Cada primitiva se puede activar o desactivar individualmente. La demostración consiste en que cada primitiva detecta una clase de falla específica y que eliminar cualquiera de ellas permite el paso de esa clase de falla.

Ship It

outputs/skill-bounded-loop-review.md audita un bucle acotado propuesto y califica cuáles de las cuatro primitivas implementa realmente en comparación con lo que afirma.

Ejercicios

  1. Ejecute code/main.py con todas las primitivas activadas. Confirme que el bucle aún mejora en la métrica primaria sin permitir que la trampa (hack) gane.

  2. Desactive la detección de regresión. Construya una entrada donde esto lleve a que se acepte una pérdida silenciosa de capacidad.

  3. Desactive la restricción multi-objetivo. Muestre que el bucle converge en el eje de rendimiento mientras que un eje de seguridad cae.

  4. Diseñe un ancla de alineación para un agente de codificación. ¿Qué texto, almacenado dónde, verificado cómo?

  5. Lea el resumen del Workshop de RSI de ICLR 2026. Elija una de las cuatro primitivas y proponga una mejora concreta para el estado del arte actual.

Términos Clave

Término Lo que la gente dice Lo que realmente significa
Invariante "Propiedad siempre verdadera" Una propiedad verificada por código externo antes y después de cada edición
Ancla de alineación "Objetivo fijado" Representación inmutable del objetivo central fuera de la superficie de edición del bucle
Restricción multi-objetivo "Todos los ejes deben cumplirse" Rendimiento, seguridad, equidad, robustez; todos obligatorios
Detección de regresión "Pausa en caso de caída" Pausar el bucle cuando los deltas de métricas históricas sugieren una pérdida de capacidad
Límite de Kolmogorov "Límite de la teoría de la información" Limita lo que un sistema puede probar sobre su propio sucesor
Teorema de Löb "Trampa de autorreferencia" El sistema puede actuar en base a "debería" sin probar que debería
Pila de control (gate stack) "Verificación en capas" Múltiples primitivas combinadas; cualquier falla rechaza la edición
Mejora acotada "Mitigación, no prueba" Aumenta el costo de la falla silenciosa; no cierra el problema de seguridad

Lectura Adicional

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