Un agente que hace cada noche la misma tarea no mejora. Tampoco empeora. Se queda exactamente igual de bueno que el texto que alguien le escribió hace cuatro meses.
Esa es la parte incómoda de los sistemas de agentes. La calidad depende casi por completo de la instrucción, y la instrucción es un trozo de prosa que alguien tecleó una vez y luego olvidó. No se nota, porque un agente nunca dice que con una instrucción mejor podría más.
Darwin es nuestra respuesta a eso. Es un paquete abierto, cualquiera puede usarlo, y hace una sola cosa: deja que los agentes evolucionen su propio texto de instrucciones.
Cómo va el ciclo#
Cada ejecución de un agente se puntúa. No por una persona sino por un modelo evaluador con un baremo fijo.
De las ejecuciones puntuadas sale un aspirante: una versión revisada de la instrucción, construida a partir de los puntos débiles de la actual. El aspirante no sustituye al titular de inmediato. Ambos corren en paralelo un tiempo y las tareas se reparten entre ellos.
Cuando hay suficientes ejecuciones decide una prueba estadística. No "uno tiene mejor media" sino la pregunta de si la diferencia es lo bastante grande como para no ser azar. Si gana el aspirante, pasa a ser el nuevo titular. Si no gana, todo se queda como estaba y la versión antigua conserva su sitio.
La parte más importante es el freno#
Un sistema que se cambia a sí mismo es una buena idea con un peligro evidente: puede evolucionar en una dirección que nadie quería.
Por eso las barreras de seguridad no están en el borde sino en el centro. Hay un número mínimo de ejecuciones antes de decidir nada. Hay un límite de tiempo para las comparaciones abiertas, para que una prueba no se quede abierta eternamente. Y hay un camino de vuelta: cuando la versión activa empieza a fallar, el sistema regresa a la última versión buena conocida.
El camino de vuelta es la parte que más trabajo dio, y eso es típico. Hacia delante siempre es fácil. La vuelta es lo que separa un experimento de un sistema en producción.
Por qué estadística en vez de intuición#
El atajo tentador sería: la versión nueva puntuó mejor de media, así que la cogemos.
Con números pequeños eso está casi siempre mal. Si un agente ha corrido un puñado de veces y la versión nueva salió por delante algo más a menudo, eso no dice aproximadamente nada. Hace falta un procedimiento que reconozca cuándo hay pruebas suficientes y que hasta entonces se calle.
Ahí está exactamente la diferencia entre un sistema que mejora y uno que cambia su instrucción cada semana y se siente bien por ello.
Qué hacemos nosotros con él#
Corremos Darwin sobre nuestra propia flota de agentes. No sobre todos a la vez, sino primero sobre dos, con observación cercana de lo que pasa.
Esa prudencia tiene un motivo. Un procedimiento que cambia a la vez las instrucciones de toda la flota no es valiente, es inobservable. Si después algo va peor, nadie sabe cuál de los cambios fue.
Así que: dos agentes, dejarlos correr lo suficiente para que los números signifiquen algo, y luego el resto.
Código abierto, y por qué#
Darwin está en abierto. Cualquiera puede instalarlo, leerlo y usarlo, sin preguntarnos y sin pagar.
El motivo no tiene nada de espectacular: un procedimiento que mide la calidad de los agentes es justo el tipo de herramienta que mejora cuando la lee gente de fuera. Hemos aprendido más sobre nuestros propios puntos débiles a partir de comentarios y revisiones externas que de nuestras propias pruebas.
Y es más honesto. Quien afirme que sus agentes mejoran con el tiempo debería poder enseñar contra qué lo mide.
Lo que no es#
Darwin no vuelve listo a un modelo flojo ni correcto a un agente mal diseñado. Mejora una instrucción a lo largo de un baremo que alguien fija. Si el baremo está torcido, el agente se torcerá de forma fiable.
Eso no es una limitación de la implementación, es la naturaleza del asunto. Un sistema que se optimiza a sí mismo optimiza exactamente lo que se mide y nada más. Quien despliegue algo así debería por tanto pensar más tiempo en el baremo que en el mecanismo.
