💻 computer science

Taming the Drift: Context-aware Repair of Dockerfile Drift during Software Evolution

Este artículo presenta Cadre, un marco de trabajo sensible al contexto que aprovecha el análisis estático para construir un Grafo de Dependencias Sensible al Contexto (CDG) para generar parches dirigidos que reparan eficazmente la deriva de Dockerfile, superando a las líneas base existentes basadas en reglas y en modelos de lenguaje extenso (LLM) en el nuevo benchmark $D^3$ de 1,040 instancias de deriva del mundo real.

Autores originales: Chengjie Wang, Jingzheng Wu, Xiang Ling, Tianyue Luo, Chen Zhao

Publicado 2026-07-15

📖 6 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Chengjie Wang, Jingzheng Wu, Xiang Ling, Tianyue Luo, Chen Zhao

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina que estás construyendo un robot en tu garaje. Has escrito un manual de instrucciones perfecto (el Dockerfile) que le dice exactamente qué piezas tomar, dónde ponerlas y cómo ensamblarlas. Pero luego, decides actualizar el cerebro del robot (el código fuente) y cambias algunos cables. Olvidas actualizar el manual para que coincida con estas nuevas piezas.

Ahora, cuando intentas construir el robot, este tose y muere. El manual no está "roto" en un sentido gramatical; las palabras están bien. Pero el manual se está desviando de la realidad. Está intentando agarrar una pieza que ya no existe o usar una herramienta que ha sido reemplazada. En el mundo del software, esto se llama desviación del Dockerfile (Dockerfile drift), y causa que las computadoras fallen silenciosamente, dejando a los desarrolladores rascándose la cabeza durante días.

La forma antigua: Adivinar en la oscuridad

Las herramientas anteriores intentaban solucionar esto simplemente leyendo el manual y el mensaje de error. Es como intentar arreglar el motor de un coche mirando únicamente la luz de "Revisar Motor" y el manual del propietario, sin abrir nunca el capó para ver los cables reales.

Algunas herramientas usaban reglas rígidas (como una lista de verificación), mientras que otras usaban una IA superinteligente (Modelos de Lenguaje Extensos) para adivinar la solución. Pero aquí está el problema: estas herramientas de IA se estaban ahogando en información. Se les entregaba el garaje entero —cada tornillo, cada manual viejo y cada caja de chatarra— junto con el mensaje de error. La IA se abrumaba tanto por el ruido que o bien se rendía o alucinaba una solución loca que no funcionaba. De hecho, en aproximadamente 41 de cada 58 problemas, estas herramientas de IA simplemente no lograban producir ninguna respuesta porque la "lista de instrucciones" era demasiado larga para que pudieran leerla.

El nuevo héroe: Cadre (El detective)

Entra Cadre, un nuevo marco de trabajo que actúa como un brillante detective. Los autores, Chengjie Wang y su equipo, se dieron cuenta de que el secreto para arreglar el robot no es darle al detective más cosas para leer, sino darle el mapa adecuado.

Su gran idea es simple: La estructura importa más que el volumen. Saber qué cable específico se conecta a qué tornillo específico es mucho más importante que leer mil páginas de texto irrelevante.

Cadre hace esto en tres pasos mágicos:

El Perfilador de Contexto (El viajero en el tiempo): Antes de intentar arreglar nada, Cadre simula todo el proceso de construcción paso a paso. Observa exactamente qué archivos se copian, qué variables se establecen y qué herramientas se llaman. Construye un modelo mental del "estado" del proyecto en cada momento determinado.
El CDG (El mapa de dependencias): Utilizando esa simulación, Cadre dibuja un Grafo de Dependencias Sensible al Contexto (CDG). Piensa en esto como un mapa del metro para tu software. Muestra exactamente cómo la instrucción "FROM" (la base) se conecta con la instrucción "COPY" (las piezas) y finalmente con la instrucción "RUN" (el ensamblaje). Si un archivo cambia, el mapa muestra exactamente qué instrucciones tropezarán con él.
La solución de dos pasos (El filtro inteligente): En lugar de volcar todo el garaje sobre la IA, Cadre le hace primero una pregunta inteligente a la IA: "Basándote en este mapa y en el error, ¿qué archivos específicos necesitas ver realmente?"
- Paso 1: La IA elige solo los archivos relevantes (los "Archivos Clave").
- Paso 2: La IA lee solo esos archivos y escribe la solución.

Esto evita que el "cerebro" de la IA se desborde. Mientras que otros métodos fallaron en generar un parche en 41–58 casos porque el prompt era demasiado grande, Cadre produjo un parche para cada uno de sus intentos.

Los resultados: ¿Funciona?

El equipo probó Cadre en 1,040 ejemplos del mundo real que extrajeron del historial de GitHub (un conjunto de datos al que llamaron 𝐷3). Estos no eran problemas falsos; eran fallos reales que ocurrieron en proyectos de software reales, con la configuración exacta necesaria para reproducirlos.

Así es como Cadre se comparó:

Cadre solucionó el 35.22% de los problemas.
El mejor método de IA anterior (sin este mapeo inteligente) solucionó el 28.48%.
El viejo método basado en reglas de lista de verificación solo solucionó el 9.34%.

Eso significa que Cadre es 1.24 veces mejor que su competidor de IA más cercano y casi 3 veces mejor que las antiguas herramientas basadas en reglas.

Pero la verdadera magia ocurre cuando el problema se vuelve "viejo". Imagina una construcción rota que nadie arregló durante cinco o seis actualizaciones. Los cambios recientes en el código parecen totalmente ajenos al error original. La mayoría de las herramientas se confunden y se rinden. Pero debido a que Cadre utiliza el mapa CDG, puede rastrear el cable roto hasta su origen, incluso si está enterrado profundamente en la historia. A cinco o más actualizaciones de distancia, Cadre solucionó el 25.9% de los problemas, mientras que la siguiente mejor herramienta solo logró el 19.7%. La brecha se amplió conforme los problemas envejecían, demostiendo que el mapa es una señal duradera.

Lo que NO es

Es importante saber lo que Cadre no hace. No es una varita mágica que lo arregla todo.

No puede arreglar problemas causados por la caída de internet o por un servidor que se queda sin espacio en disco.
No puede arreglar errores dentro de la lógica del código real (como un error matemático en el programa mismo); solo arregla las instrucciones de construcción.
En aproximadamente el 65% de los casos en los que falló, el problema era una restricción compleja de la herramienta de construcción que simplemente no podía resolverse cambiando el manual (como un paquete faltante en un registro privado).

La conclusión

Los autores sugieren que para el futuro del mantenimiento de software, no debemos limitarnos a lanzar más datos a la IA, sino empezar a enseñarle a entender la estructura de las dependencias. Al construir un mapa de cómo se conectan los archivos y las instrucciones, Cadre demostró que un poco de contexto inteligente llega muy lejos. No se trata de leer toda la biblioteca; se trata de saber exactamente en qué página hay que detenerse.

Todo el código y el conjunto de datos de los 1,040 desvíos del mundo real están abiertos para que cualquiera los revise, asegurando que esto no es solo una teoría, sino una herramienta construida sobre evidencia real y reproducible.

Resumen Técnico: Domando la Deriva: Reparación Consciente del Contexto de la Deriva de Dockerfile durante la Evolución del Software

1. Definición del Problema: Deriva de Dockerfile (Dockerfile Drift)

El desarrollo de software moderno depende en gran medida de los flujos de trabajo de Integración Continua y Despliegue Continuo (CI/CD), donde Docker sirve como el estándar de facto para garantizar entornos de construcción reproducibles. Sin embargo, un problema crítico conocido como deriva de Dockerfile (Dockerfile drift) socava esta fiabilidad. La deriva ocurre cuando un Dockerfile no logra absorber los cambios realizados en el código fuente de la aplicación, lo que provoca un desajuste entre el script de construcción y el estado evolutivo del repositorio. A diferencia de los errores de sintaxis, la deriva es un problema de coevolución interna donde la información para la reparación reside dentro del mismo repositorio que produjo la falla.

La deriva se manifiesta como rutas de archivos incorrectas, variables de entorno desajustadas, especificaciones de dependencias desactualizadas o cambios de plataforma. Estas fallas son particularmente difíciles de reparar automáticamente debido a tres desafíos principales:

C1 (Extracción de Contexto): El estado de la construcción (directorio de trabajo, variables de entorno, conjuntos de archivos) se determina por la ejecución acumulativa de instrucciones previas, no solo por el texto del Dockerfile. Los métodos existentes basados en reglas y en LLM suelen tratar al Dockerfile de forma aislada, fallando al modelar estas interacciones dinámicas.
C2 (Dependencias entre Instrucciones): Las instrucciones suelen depender de artefactos producidos por pasos anteriores de formas no evidentes (por ejemplo, un comando RUN que opera sobre archivos introducidos por un COPY previo o variables establecidas por un ARG). Estas dependencias no son sintácticamente visibles de forma aislada.
C3 (Localización de Causas Raíz): Los registros de error suelen señalar la instrucción que falla, pero rara vez identifican la causa raíz, la cual puede derivar de un cambio en el código introducido en un commit previo.

2. Metodología: El Marco de Trabajo Cadre

Los autores proponen Cadre, un marco de trabajo consciente del contexto diseñado para reparar la deriva de Dockerfile mediante el modelado explícito del contexto de construcción. La idea central de diseño es que la estructura del contexto determina la calidad de la reparación más que el volumen del contexto. Cadre aborda los tres desafíos a través de cuatro fases integradas:

2.1 Extractor de Deriva de Dockerfile (DodeX)

Para abordar la falta de benchmarks realistas, los autores desarrollaron DodeX, un pipeline que mina instancias de deriva del mundo real a partir de los logs de CI de GitHub Actions. A diferencia de los conjuntos de datos de instantáneas estáticas, DodeX captura la configuración completa de la construcción, incluyendo argumentos de construcción dinámicos, plataformas objetivo y los diffs exactos de cambios de código que provocaron la falla. Esto asegura que cada instancia extraída sea localmente reproducible.

2.2 Perfilador de Contexto a Nivel de Instrucción

Para resolver C1, Cadre realiza una simulación con estado del proceso de construcción de Docker. Recorre el Dockerfile instrucción por instrucción, manteniendo un Estado de Contexto ( $\sigma$ ) que rastrea:

El directorio de trabajo actual ( $\delta$ ).
Variables de entorno resueltas ( $\varepsilon$ ).
El conjunto de archivos presentes en el contenedor ( $\Phi$ ).

Crucialmente, el perfilador emplea analizadores conscientes del sistema de construcción para 11 ecosistemas principales (ej. Go, Python, npm, Maven). En lugar de tratar los comandos RUN como cadenas opacas, estos analizadores infieren dependencias de archivos implícitas (ej. inferir que go build depende de go.mod y de todos los archivos *.go en el directorio). Esto produce un Mapa de Contexto de Instrucción (ICM) que vincula cada instrucción con su estado preciso en el momento de la construcción.

2.3 Grafo de Dependencias Consciente del Contexto (CDG)

Para resolver C2, el ICM se convierte en un Grafo de Dependencias Consciente del Contexto (CDG), un grafo acíclico dirigido ( $G = (V, E)$ ) que hace explícitas las dependencias entre instrucciones:

Vértices: Incluyen nodos de instrucción ( $V_I$ ) y nodos de archivo ( $V_F$ ).
Aristas: Incluyen aristas secuenciales ( $E_S$ ) que representan el flujo de control y aristas de flujo de datos ( $E_D$ ) que representan dependencias de "lectura desde" entre archivos e instrucciones.
Este grafo permite al sistema rastrear las rutas de propagación de fallas a través de las fronteras de las instrucciones, identificando cómo un cambio en un archivo fuente (ej. go.mod) invalida una instrucción RUN específica a través de pasos intermedios de COPY o ARG.

2.4 Flujo de Trabajo de Reparación Refinado por Contexto

Para resolver C3 y gestionar los límites de tokens, Cadre emplea un flujo de trabajo agéntico de dos pasos en lugar de un prompt de un solo paso:

Consulta de Contexto: Se presenta al LLM el registro de error, el diff del código y una versión podada del CDG. Se le pide que seleccione el conjunto mínimo de archivos relevantes y palabras clave de grep necesarias para la reparación. Este paso filtra el contexto irrelevante antes de cargar el contenido de los archivos.
Generación de Reparación: El sistema recupera únicamente los archivos seleccionados y genera un parche dirigido.
Este enfoque evita el desbordamiento de prompts (un modo de falla común en los métodos competidores de LLM) y asegura que el modelo se concentre en la evidencia causalmente relevante.

3. Contribuciones Clave

Marco Cadre: Un nuevo marco de reparación fundamentado en la idea de que la estructura del contexto es más valiosa que su volumen. Integra un perfilador de contexto con estado, un grafo de dependencias y un flujo de trabajo de LLM de dos pasos.
DodeX y Benchmark $D^3$ : La creación de DodeX, un pipeline para extraer instancias de deriva con configuraciones de construcción completas, y $D^3$ , el primer benchmark de deriva de Dockerfile donde las 1,040 instancias son localmente reproducibles utilizando los parámetros exactos de las ejecuciones originales de CI.
Evaluación Empírica: Una evaluación exhaustiva comparando Cadre contra baselines basados en reglas (Parfum), baselines basados en recuperación (FlakiDock) y LLMs puros (Vanilla LLM).

4. Resultados Experimentales

El marco fue evaluado en el benchmark $D^3$ (653 instancias ejecutables tras filtrar por tiempos de espera de red).

Efectividad de la Reparación: Cadre logró una tasa de reparación del 35.22%, superando al baseline basado en reglas (Parfum, 9.34%) por 2.78 $\times$ y al mejor baseline basado en LLM (Vanilla-LLM, 28.48%) por 1.24 $\times$ .
Eficiencia de Tokens y Robustez: Cadre eliminó por completo los fallos por desbordamiento de prompt ( $|F_r| = 0$ ), manteniendo el 95.25% de los prompts por debajo de 30k tokens. En contraste, los métodos de LLM competidores no pudieron generar parches en 41–58 casos debido a la superación de los límites de contexto.
Robustez ante la Deriva Estancada: A medida que las instancias de deriva se volvían "estancadas" (persistiendo a través de múltiples commits), el rendimiento de los enfoques basados solo en diffs se degradó significativamente. A una distancia de 5+ commits, Cadre mantuvo una tasa de éxito del 25.9% frente al 19.7% del mejor baseline, demostrando que el CDG proporciona una señal estructural robusta a la distancia de los commits.
Estudios de Ablación: Eliminar el CDG redujo la tasa de reparación en 4.29 puntos porcentuales, mientras que eliminar el flujo de trabajo de dos pasos la redujo en 3.67 puntos y reintrodujo los fallos por desbordamiento de prompt. Se encontró que los componentes se refuerzan mutuamente.

5. Significado y Reivindicaciones

El artículo sostiene que el modelado explícito de dependencias es una señal de reparación duradera. Los autores argumentan que la ventaja de los enfoques conscientes del contexto sobre los métodos basados solo en diff o en recuperación se amplía a medida que la deriva envejece a través de los commits. El estudio sugiere que el mantenimiento de la Infraestructura como Código (IaC) consciente del contexto es una dirección productiva para el desarrollo de herramientas futuras.

Los autores señalan modestamente ciertas limitaciones: el CDG se basa en análisis estático y no puede capturar completamente factores de tiempo de ejecución como los estados de los registros de paquetes o las condiciones de red, que explican algunas fallas no resueltas. Además, el benchmark está limitado a repositorios públicos de GitHub. Sin embargo, el trabajo establece que modelar el contexto de construcción de forma explícita —específicamente el flujo de datos y control a través de las instrucciones— es crítico para automatizar la reparación de configuraciones de software en evolución.