Síntesis de programas: principios y relación con la AGI

La síntesis de programas consiste en construir automáticamente un programa que cumpla una especificación: propiedades lógicas, ejemplos de entradas y salidas o una combinación de restricciones. Puede combinar búsqueda simbólica y aprendizaje profundo para proponer, ejecutar y seleccionar soluciones. Es una vía de investigación hacia sistemas capaces de adquirir nuevas habilidades, pero producir un programa correcto en un ámbito limitado no demuestra una inteligencia general.

El principio: buscar una regla ejecutable

En la programación convencional, usted describe los pasos que deben ejecutarse. En la síntesis, describe sobre todo el resultado esperado y un sistema busca un procedimiento compatible con esa petición. La diferencia está en lo que queda por descubrir: una transformación, una condición, una combinación de operaciones o una función completa.

Una tarea de síntesis suele incluir tres elementos:

una especificación, que describe los comportamientos aceptables;
un espacio de programas, definido por un lenguaje y unas operaciones permitidas;
un procedimiento de búsqueda y comprobación, que propone candidatos y evalúa si cumplen lo solicitado.

El programa obtenido puede ser código de uso habitual, una expresión matemática o una secuencia de operaciones en un lenguaje especializado. Debe tener una semántica definida: se sabe cómo ejecutarlo y qué significan sus instrucciones.

Esto distingue la síntesis de una simple explicación en lenguaje natural. Una respuesta puede describir correctamente un método sin ofrecer un procedimiento ejecutable; a la inversa, un programa pequeño puede resolver una tarea sin aportar una explicación didáctica.

La generalización entra en juego en cuanto el programa debe funcionar con entradas que no aparecen en los ejemplos. Por tanto, no basta con reproducir las respuestas proporcionadas: hay que descubrir una regla que también sirva para los demás casos pertinentes.

Un ejemplo: deducir una transformación de texto

Imaginemos un ejercicio didáctico. Usted proporciona las siguientes transformaciones:

Entrée : facture_rouge.pdf
Sortie : rouge

Entrée : facture_bleue.pdf
Sortie : bleue

Hay varios procedimientos que encajan: eliminar un prefijo y una extensión fijos, extraer el texto situado después del primer separador o seleccionar un fragmento según su posición. En estos ejemplos producen las mismas respuestas, pero dan resultados distintos con otros nombres de archivo.

Añadamos una entrada:

Entrée : archive_facture_verte.pdf
Sortie attendue : verte

Este caso permite descartar algunas hipótesis. Sin embargo, todavía no indica cómo tratar una extensión diferente, la ausencia de un separador o un nombre compuesto. Esas decisiones forman parte de la especificación, aunque la interfaz las deje implícitas.

El sintetizador debe resolver, por tanto, una ambigüedad en la intención. Puede ordenar las soluciones según su simplicidad, pedir un ejemplo que permita distinguirlas o presentar varias interpretaciones. Ningún algoritmo puede deducir con certeza una intención si los datos disponibles no permiten diferenciarla de otras.

Esta lógica aparece en los trabajos de Sumit Gulwani sobre transformaciones de cadenas de texto, publicados en enero de 2011. La publicación original sobre programación mediante ejemplos describe un lenguaje especializado y una búsqueda de programas compatibles con los ejemplos. El objetivo va más allá de generar texto: se trata de construir una transformación reutilizable y resolver las ambigüedades que plantea.

Una historia anterior a los modelos de lenguaje

La síntesis no nació con los asistentes de programación. Una de sus tradiciones históricas procede de la lógica: si se puede demostrar de forma constructiva que existe una salida que cumple determinadas condiciones, la demostración puede proporcionar el método para calcularla.

Zohar Manna y Richard Waldinger desarrollaron este enfoque deductivo. Su exposición de los fundamentos de la síntesis deductiva, publicada en 1992, explica cómo extraer un procedimiento de una demostración suficientemente constructiva. La garantía que se busca se refiere a una especificación explícita, en lugar de basarse en el parecido con programas conocidos.

Otra tradición parte de ejemplos y busca una regla que los explique. Así resulta más fácil expresar lo que se necesita, aunque la información suele ser menos completa. La programación mediante ejemplos ilustra este equilibrio: mostrar una transformación deseada puede ser sencillo; precisar todas sus excepciones resulta más difícil.

El sketching ofrece una vía intermedia. El desarrollador proporciona un esbozo del programa y deja algunas decisiones para que se resuelvan automáticamente. Conserva parte de la estrategia, mientras el sintetizador explora los detalles que faltan.

Estas tradiciones coexisten. La historia del campo no es, por tanto, una simple sustitución de la lógica por las redes neuronales. Recoge distintas respuestas a una misma dificultad: expresar las necesidades con suficiente precisión y explorar de manera eficiente las implementaciones posibles.

Las principales familias de métodos

Los métodos se diferencian por la forma de representar los candidatos, buscarlos y comprobarlos. Una misma arquitectura puede combinar varios de ellos.

Método	Principio de búsqueda	Información necesaria	Limitación característica
Enumeración	Construir y probar programas permitidos	Gramática, ejemplos o propiedades	Multiplicación de las combinaciones
Resolución de restricciones	Codificar las decisiones en un problema lógico	Semántica y restricciones formalizables	Dificultad y tamaño de la codificación
Deducción constructiva	Extraer un procedimiento de una demostración	Especificación lógica adecuada	Formalización y búsqueda de la demostración
Búsqueda guiada por aprendizaje	Dar prioridad a los candidatos considerados prometedores	Datos de entrenamiento y comprobación de resultados	Sesgos del modelo que guía la búsqueda y costo de exploración

Enumerar no significa necesariamente probar a ciegas todas las cadenas de caracteres. Los tipos permiten descartar combinaciones incompatibles; la semántica permite agrupar expresiones equivalentes, y los resultados intermedios pueden reutilizarse.

Los solucionadores de restricciones funcionan de otra manera: buscan una asignación de valores a las decisiones que permita satisfacer las condiciones. Su eficacia depende mucho de cómo se formule el problema. Convertir una tarea en restricciones no la vuelve fácil de forma automática.

El aprendizaje aporta un criterio para establecer prioridades en la búsqueda. Puede sugerir una operación, una estructura de programa o una descomposición probable. En ocasiones, esa sugerencia reduce la exploración necesaria, pero su plausibilidad no garantiza que la solución sea correcta.

La cuestión práctica sigue siendo la misma: qué mecanismo determina que un candidato puede aceptarse y en qué ámbito es válida esa decisión.

Los contraejemplos transforman la búsqueda

Una arquitectura central alterna la construcción de soluciones con la búsqueda de casos que las refuten. El sintetizador propone un programa compatible con los casos conocidos; después, un verificador busca una entrada con la que ese programa incumpla la especificación. Si la encuentra, pasa a ser una restricción adicional.

Este ciclo se conoce como CEGIS, por counterexample-guided inductive synthesis, o síntesis inductiva guiada por contraejemplos. Armando Solar-Lezama describe su uso en el trabajo sobre program sketching, difundido en 2012 y publicado posteriormente en una revista en 2013.

Un contraejemplo aporta más que un simple resultado negativo. También excluye a los demás candidatos que cometerían el mismo error. De este modo, la búsqueda acumula información sobre los comportamientos que debe evitar.

No obstante, el alcance de las comprobaciones debe quedar claro. Una prueba mediante casos concretos observa el resultado para determinadas entradas. Una verificación acotada explora un dominio limitado; una demostración puede establecer una propiedad general bajo ciertos supuestos. Estos niveles no son intercambiables.

Además, una especificación puede ser coherente y, aun así, insuficiente. Un programa que respete todas las restricciones puede no satisfacer la necesidad real si se ha omitido una regla del negocio.

Para valorar un resultado, conviene preguntar qué propiedad se ha comprobado, con qué supuestos y dentro de qué límites. La palabra «verificado» solo aporta información cuando se precisan esos elementos.

Qué aporta el aprendizaje profundo

El principal obstáculo suele ser combinatorio: cada instrucción adicional abre nuevas posibilidades de composición. Una red puede aprender qué operaciones parecen útiles a partir de los ejemplos y orientar un motor de búsqueda hacia esas zonas del espacio de programas.

DeepCoder, presentado en ICLR en 2017, ilustra este reparto de tareas. La red predice propiedades del programa buscado, entre ellas las funciones que probablemente incluya; esas predicciones orientan las técnicas de búsqueda. El modelo entrenado ayuda a encontrar el programa, mientras que su comportamiento se sigue evaluando mediante ejecución o resolución.

Otra posibilidad consiste en generar candidatos directamente, probarlos y corregirlos. La ventaja es aprovechar regularidades aprendidas del código y de las descripciones de tareas. El riesgo consiste en dar prioridad a una solución familiar que no se ajuste a las restricciones del problema actual.

También hay que distinguir entre síntesis neuronal y ejecución neuronal. En la primera, una red contribuye a producir un programa que después se ejecuta según reglas explícitas. En la segunda, la propia red realiza una transformación, sin proporcionar necesariamente un procedimiento simbólico que se pueda examinar.

Estos enfoques pueden complementarse. Un sistema de percepción aprendido puede identificar objetos en una imagen; después, una búsqueda de programas puede determinar cómo moverlos. Sin embargo, la conexión entre ambos pasa a ser un punto crítico: una representación inicial inadecuada puede impedir que se encuentre la regla correcta.

Aprender abstracciones con DreamCoder

Un lenguaje especializado facilita la búsqueda, pero sus operaciones suelen elegirse manualmente. Si no encajan bien con las tareas, las soluciones se vuelven largas o imposibles de expresar. Esto plantea otra cuestión: si el sistema puede ampliar por sí mismo su vocabulario de programas.

DreamCoder, descrito en una publicación depositada en junio de 2020, combina búsqueda de programas, aprendizaje de una biblioteca de componentes y aprendizaje de un modelo neuronal que guía la búsqueda. Las estructuras que aparecen de forma recurrente en las soluciones pueden convertirse en abstracciones reutilizables.

El beneficio es acumulativo. Una combinación útil, que antes había que reconstruir para cada problema, pasa a ser una operación disponible para los siguientes. Así, la biblioteca modifica el espacio de búsqueda, mientras el modelo aprende a explorarlo mejor.

Hay que distinguir este mecanismo del simple almacenamiento de respuestas. Reutilizar una abstracción significa aplicar una estructura a nuevas entradas o integrarla en otra composición. El valor de esa abstracción se mide por los problemas que permite resolver después.

Esta idea no elimina las decisiones iniciales. El sistema conserva un lenguaje de partida, unas reglas de ejecución y un procedimiento de aprendizaje definidos por sus diseñadores. Una biblioteca aprendida también puede llegar a ser demasiado grande o excesivamente especializada.

DreamCoder ofrece, por tanto, un ejemplo de mecanismo para adquirir abstracciones, no una demostración de autonomía intelectual general. La transferencia a ámbitos muy distintos sigue siendo una cuestión diferente del progreso dentro de los ámbitos estudiados.

Por qué esta vía interesa a la investigación sobre la AGI

Un programa puede representar una regla compacta y aplicarla a situaciones nuevas. Esta propiedad hace que la síntesis resulte interesante para estudiar la combinación de conocimientos, la adaptación y el aprendizaje a partir de pocos ejemplos.

En On the Measure of Intelligence, publicado en noviembre de 2019, François Chollet distingue las habilidades alcanzadas de la eficiencia con la que un sistema adquiere otras nuevas. Su marco propone tener en cuenta los conocimientos previos, la experiencia y la dificultad de generalización.

Esta postura invita a examinar cómo se adquiere una solución, además del resultado obtenido. La página sobre generalización desarrolla esa distinción. La síntesis ofrece un terreno para estudiarla, porque las hipótesis pueden adoptar la forma de procedimientos ejecutables.

Las tareas de transformación de cuadrículas, tratadas en la página de referencia sobre ARC-AGI, permiten razonar en términos de objetos, relaciones y operaciones. Encontrar un procedimiento compatible con los ejemplos de demostración es una de las formas posibles de abordarlas.

Sin embargo, un resultado satisfactorio no permite identificar por sí solo el mecanismo utilizado. Puede proceder de una búsqueda estructurada, del reconocimiento de patrones ya aprendidos o de una combinación de ambos. Hacen falta experimentos adicionales para distinguir estas explicaciones.

Esta página expone los principios duraderos; el artículo relacionado sobre la síntesis de programas y la vía de Ndea aborda el tema desde la perspectiva del proyecto de investigación.

Los desacuerdos también afectan a los conocimientos iniciales

Los investigadores no coinciden en cuánta estructura conviene proporcionar a un sistema. Los objetos, las relaciones espaciales y las operaciones predefinidas pueden facilitar el aprendizaje. También pueden orientar los resultados hacia las categorías previstas por los diseñadores.

Richard Sutton defiende otra prioridad en The Bitter Lesson, publicado en marzo de 2019: dar preferencia a métodos generales de búsqueda y aprendizaje que puedan aprovechar una mayor capacidad de cálculo, en lugar de acumular conocimientos humanos específicos.

Esta postura no refuta la síntesis de programas. La búsqueda en un espacio de programas también puede ser general y estar guiada por aprendizaje. La tensión aparece sobre todo cuando el éxito depende de un lenguaje muy especializado, ajustado a los problemas de la evaluación.

Por eso conviene separar varias cuestiones: si las operaciones básicas se definen manualmente, si el modelo que guía la búsqueda se aprende, si el sistema puede inventar abstracciones y si puede cambiar de representación cuando su lenguaje actual resulta insuficiente.

Presentar este debate como una oposición entre símbolos y neuronas ocultaría las arquitecturas híbridas. La discrepancia también afecta a cómo se obtiene la estructura útil y en qué condiciones puede transferirse.

Una postura prudente consiste en comparar los mecanismos en tareas nuevas, documentando los recursos utilizados. Ni una preferencia teórica ni un resultado aislado resuelven la cuestión de qué arquitectura necesita la AGI.

Los límites: representación, costo e intención

La síntesis presupone que la solución sea accesible dentro del espacio explorado. Si el lenguaje no permite expresar una operación imprescindible, prolongar la búsqueda no resuelve el problema. Ampliar el lenguaje permite expresar más soluciones, pero también aumenta las posibilidades que hay que examinar.

La elección de la representación es igual de decisiva. Una imagen descrita como una lista de píxeles no ofrece los mismos atajos que una imagen descrita como un conjunto de objetos. Construir la representación adecuada puede exigir tanto trabajo como descubrir la transformación.

La simplicidad de un programa también depende del lenguaje disponible. Una regla parece breve cuando una operación básica ya realiza la mayor parte del trabajo. Por ello, para comparar la longitud de los programas también hay que examinar la biblioteca y los conocimientos que contiene.

El costo no se limita al número de llamadas a un modelo. Incluye los candidatos explorados, su ejecución, la verificación, la memoria y las posibles adaptaciones. Un resultado obtenido mediante una búsqueda más extensa debe presentarse junto con los recursos que ha requerido.

Por último, un programa explícito no es automáticamente seguro. Sus efectos pueden ir más allá de la transformación esperada si tiene acceso a archivos o a una red. Al ejecutar candidatos desconocidos, un entorno aislado y unos límites de recursos ayudan a contener esos efectos durante la evaluación.

Evaluar una demostración y reconocer los usos útiles

Una evaluación convincente debe distinguir los ejemplos utilizados para buscar soluciones de los casos reservados para medir su rendimiento. También debe precisar las intervenciones humanas: elección de las operaciones básicas, correcciones de la especificación y selección final de los candidatos.

Al leer una publicación o examinar un prototipo, revise:

La petición: solo ejemplos, una descripción libre o propiedades formales.
El espacio explorado: lenguaje, biblioteca y restricciones.
La comprobación: pruebas, búsqueda de contraejemplos o demostración.
Los recursos: cálculo, tiempo, memoria e intervención humana.
La transferencia: variantes próximas o cambios de estructura.

La guía para evaluar un agente de IA ofrece un método complementario cuando la síntesis forma parte de un ciclo de uso de herramientas. Una mejora puede proceder del modelo, del motor de búsqueda o de un verificador más eficaz: los experimentos deben permitir distinguir esas aportaciones.

Los asistentes de desarrollo como Codex, Claude Code y OpenHands pertenecen a un ámbito cercano. Sin embargo, su presencia en una tarea de programación no basta para afirmar que haya una síntesis verificada formalmente: hay que examinar las restricciones y las comprobaciones que se han utilizado en la práctica.

Los usos más fáciles de delimitar tienen una salida ejecutable, un ámbito acotado y criterios de éxito observables. Cuanto más dependa el objetivo de una intención implícita o de efectos difíciles de simular, más peso adquieren la especificación y la validación.

Puntos clave

La síntesis construye un procedimiento a partir de restricciones; su fiabilidad depende de la especificación y de las comprobaciones.
El aprendizaje profundo puede guiar la búsqueda, proponer candidatos y contribuir a la adquisición de abstracciones.
Resolver los ejemplos no demuestra ni la corrección general ni la transferencia a otros ámbitos.
La síntesis aporta mecanismos pertinentes para estudiar la inteligencia, sin demostrar por sí sola que sea una vía suficiente hacia la AGI.

El dossier AGI e investigación sitúa estos mecanismos junto a otros enfoques del aprendizaje, el razonamiento y la evaluación.

Páginas relacionadas

Preguntas frecuentes

¿Qué diferencia hay entre la síntesis de programas y la compilación?

Un compilador suele traducir un programa ya definido a otra representación, conservando su comportamiento. Un sintetizador debe encontrar una implementación a partir de una descripción que deja decisiones abiertas. Algunas herramientas combinan ambas funciones.

¿La síntesis de programas necesita un modelo de lenguaje?

No. Puede recurrir a la enumeración de programas, a solucionadores de restricciones o a demostraciones lógicas. Un modelo entrenado puede ayudar a explorar las posibilidades, pero no es un requisito.

¿Un programa sintetizado siempre es fácil de leer?

No. Su legibilidad depende del lenguaje, de las abstracciones disponibles y de los criterios de selección. Un programa compacto puede resultar difícil de entender si sus operaciones son poco transparentes o si los nombres no describen su función.

¿La síntesis de programas puede sustituir a los desarrolladores?

Automatiza parte de la búsqueda de implementaciones, pero deja pendientes la definición de las necesidades, el diseño del sistema y la evaluación de sus consecuencias. Su utilidad depende de la precisión de las restricciones y de la posibilidad de comprobar el resultado.

¿La capacidad de escribir código permite identificar una AGI?

Es un elemento de evaluación, pero no un criterio suficiente. También hay que examinar la adquisición de nuevas habilidades, la transferencia entre ámbitos y los recursos necesarios. El rendimiento en programación no basta para responder a esas cuestiones.