Herramientas y plataformas de código abierto para el desarrollo de la AGI

Buena parte de la investigación sobre inteligencia artificial general se hace con herramientas de código abierto. Eso tiene una ventaja que va más allá de lo económico: cualquiera puede comprobar en qué estado está realmente un proyecto, sin depender de lo que diga su página de presentación. Este artículo repasa las plataformas relevantes y, de paso, enseña a hacer esa comprobación.

El marco teórico que sí tiene un documento detrás

La formalización más citada del problema es la de Marcus Hutter, recogida en «Universal Artificial Intelligence: Sequential Decisions based on Algorithmic Probability» (Springer, 2005). Su idea, en corto: unir la teoría de la decisión secuencial con la teoría algorítmica de la información para definir un agente óptimo —lo que llama AIXI— que elige acciones maximizando la recompensa esperada bajo todas las hipótesis compatibles con lo observado, ponderadas por su simplicidad.

AIXI no es implementable: requiere un cómputo infinito. Su valor es otro, y conviene entenderlo porque explica para qué sirve la teoría en este campo: establece un límite superior contra el que comparar. La página del propio Hutter mantiene el índice del libro, cerca de cuatrocientas diapositivas de sus cursos y una lista de problemas abiertos con premios en metálico.

Las plataformas, y su estado real

OpenCog

OpenCog es el proyecto de código abierto más ambicioso orientado explícitamente a la AGI. Su pieza central es AtomSpace, un almacén de conocimiento en forma de hipergrafo sobre el que operan procesos de razonamiento simbólico y aprendizaje. La apuesta es lo contrario a la dominante: en lugar de escalar el aprendizaje a partir de datos, construir sentido común y comprensión conceptual explícita.

Y aquí conviene ser exacto sobre su estado, porque es donde suele fallar la cobertura. El núcleo AtomSpace se declara activo, estable y soportado, y hay repositorios con actividad reciente. Pero el propio proyecto clasifica parte de su código como «fósiles» —abandonado— y mantiene un aviso de «se busca ayuda» por falta de recursos. El desarrollo vivo hacia la AGI se ha desplazado a un sucesor declarado, OpenCog Hyperon, que se construye bajo SingularityNET.

Presentarlo como un proyecto en plena marcha sería inexacto. Presentarlo como muerto, también.

SingularityNET

SingularityNET se define hoy como «investigación e infraestructura para una AGI descentralizada», y se presenta como miembro fundador de la Artificial Superintelligence Alliance. Su planteamiento es un mercado descentralizado donde distintos servicios de inteligencia artificial puedan combinarse, y es también donde se desarrolla el marco Hyperon citado arriba.

Un apunte para quien lea material antiguo sobre el proyecto: su token ya no es AGIX, sino FET, tras la fusión en esa alianza. Cualquier texto que siga hablando de AGIX está desactualizado.

ROS, y un equívoco que conviene deshacer

ROS aparece en casi todas estas listas, y casi siempre mal descrito. Sus siglas significan Robot Operating System, pero no es un sistema operativo. Su propia web lo dice con todas las letras: «El Robot Operating System (ROS) es un conjunto de librerías de software y herramientas que te ayudan a construir aplicaciones de robótica». Su repositorio oficial lo matiza como «meta sistema operativo».

La distinción no es pedante. Un sistema operativo gestiona el hardware de una máquina; ROS se ejecuta encima de uno —típicamente Linux— y aporta un modelo de comunicación entre módulos. Lo que lo hace relevante aquí no es que sirva para construir una AGI, sino su arquitectura: componentes independientes que se comunican por mensajes, un esquema de modularidad que sí interesa a cualquiera que piense en integrar capacidades heterogéneas.

Y es un buen recordatorio general: el nombre de un proyecto no es su documentación.

Por qué una arquitectura cognitiva no es un modelo

Conviene deshacer una confusión que atraviesa todo este terreno, porque explica por qué estos proyectos se comparan mal con lo que domina hoy los titulares.

Un modelo de lenguaje es una función: entra texto, sale texto, y todo lo que sabe está en sus pesos. Una arquitectura cognitiva como AtomSpace es otra cosa: un almacén de conocimiento explícito más unos procesos que operan sobre él. El conocimiento no está disuelto en números, está escrito en estructuras que se pueden leer, editar y contradecir.

Esa diferencia trae ventajas reales: se puede añadir un hecho sin reentrenar nada, se puede preguntar por qué el sistema concluyó algo y seguir la cadena, y se puede corregir un error concreto sin tocar el resto. Y trae la desventaja que ha decidido la partida hasta ahora: alguien tiene que poner ese conocimiento, y el mundo tiene más hechos de los que nadie va a escribir a mano.

Por eso comparar ambos enfoques por su rendimiento en una prueba de lenguaje es comparar mal. No compiten en la misma dimensión: uno escala con datos y el otro con trabajo humano de modelado.

Cómo leer la hoja de ruta de un proyecto de AGI

Estos proyectos publican planes a años vista, y ahí conviene un criterio, porque es donde más se confunde la ambición con el avance.

Separe lo que ya funciona de lo que está previsto. Un repositorio con actividad reciente demuestra lo primero; una hoja de ruta no demuestra nada, por detallada que sea. La ambición es barata de escribir y el código no.

Y desconfíe del salto sin peldaños. Cuando un plan va de un componente que funciona a una capacidad general sin explicar qué hay en medio, ese hueco es el proyecto entero. Los proyectos honestos lo dicen — OpenCog marca sus partes muertas y pide ayuda; eso vale más que cualquier promesa.

Y una comprobación que cuesta un minuto y ahorra meses: mire la fecha del último cambio en el componente que usted necesita, no en el proyecto en general. Un repositorio muy activo puede tener parado justo el módulo del que dependería su trabajo, y esa distinción no aparece en ninguna página de presentación.

Cómo medir el progreso: dónde mirar

Evaluar el avance hacia la generalidad es un problema abierto, y la referencia práctica más útil no está en estas plataformas sino en las pruebas diseñadas para ello. La más citada es el Abstraction and Reasoning Corpus, propuesto por François Chollet en «On the Measure of Intelligence» (2019), donde argumenta que lo que hay que medir no es lo que un sistema sabe hacer, sino su «eficiencia en la adquisición de destrezas». El proyecto sigue vivo en ARC Prize, con resultados actualizados.

La capacidad: cómo comprobar si un proyecto abierto está vivo

Esta es la destreza que deja el artículo, y sirve para cualquier herramienta de código abierto que le propongan adoptar:

1. Vaya al repositorio, no a la página de presentación. Una web de proyecto se actualiza cuando hay algo que anunciar; un repositorio registra cada cambio con su fecha. Mire cuándo fue el último commit en los componentes que le interesan, no en el proyecto en general.

2. Busque lo que el propio proyecto declara muerto. Los proyectos honestos marcan sus partes obsoletas — OpenCog las llama «fósiles». Esa etiqueta vale más que cualquier reseña externa, porque la pone quien conoce el código.

3. Pregunte dónde se ha ido el desarrollo. Cuando un proyecto tiene sucesor declarado, la actividad interesante está allí. Adoptar el predecesor porque es el nombre conocido es el error caro.

El fondo

• Repositorios de OpenCog, con su clasificación en componentes activos, investigación en curso, fósiles e incubadora. Merece la pena mirarla antes de citar el proyecto.
• SingularityNET, donde se desarrolla Hyperon.
• ros.org y el repositorio de ROS 2, para ver la definición en sus propias palabras.
• Hutter (2005), para el marco teórico. Enlace directo a la página del libro: la raíz del sitio es un armazón antiguo sin contenido legible.
• Chollet (2019) y ARC Prize, para la parte de medición.