#IBMs #NetLogo #Modelización
El modelado basado en agentes, especialmente utilizando una plataforma como NetLogo, ofrece una poderosa herramienta para abordar la comprensidad y los problemas multinivel presentes en sistemas reales. Un modelo es, por definición, una representación simplificada y con propósito de la realidad, diseñada para responder preguntas de investigación o resolver problemas específicos. Para usar ABMs, se requieren habilidades adicionales a las del modelado tradicional, incluyendo un nuevo lenguaje conceptual (como emergencia, comportamiento adaptativo, interacción, detección), habilidades de software para implementar y analizar modelos, y estrategias para el diseño y análisis.
El proceso de modelado se concibe como un ciclo iterativo. Una parte fundamental de este ciclo es la formulaciónexplícita del modelo, que transforma las ideas heurísticas iniciales en una representación formal. Dado que los ABMs carecen de una notación matemática estándar como las ecuaciones diferenciales, el Protocolo ODD (Overview, Design Concepts, Details) se ha convertido en una forma estandarizada y ampliamente utilizada para describir y pensar sobre el diseño de ABMs. ODD busca crear descripciones fácticas, completas, fáciles de entender y reproducibles, lo cual es crucial para la ciencia. El protocolo ODD consta de siete elementos que cubren desde una visión general hasta los detalles de los submodelos. Describir los submodelos con detalle, incluyendo ecuaciones, reglas, algoritmos, parámetros y su base/justificación, es esencial para la reproducibilidad. Para la programación compleja del orden de las acciones, se puede usar pseudocódigo en la descripción ODD.
La implementación de un ABM en NetLogo comienza traduciendo la descripción ODD a código. NetLogo organiza el código en procedimientos definidas con to y terminadas con end. El procedimiento go es el núcleo que se ejecuta repetidamente, a menudo llamando a otros procedimientos para realizar las acciones de los agentes. El procedimiento setup se usa para inicializar el modelo.
La programación en NetLogo implica definir variables. Las variables pueden ser globals (accesibles en todo el modelo), patches-own (propiedad de las celdas del espacio), turtles-own (propiedad de los agentes móviles) y links-own(propiedad de las conexiones entre agentes). Las variables locales se crean dentro de un procedimiento o bloque con let y solo existen dentro de ese contexto. Es una buena práctica evitar “cablear” valores importantes en el código profundo, sino hacerlos parámetros globales que se pueden cambiar fácilmente, por ejemplo, mediante sliders en la Interfaz.
NetLogo proporciona primitivas (comandos y reporteros) para interactuar con los agentes y el entorno. Primitivas clave incluyen ask para indicar a un agente o conjunto de agentes que ejecuten acciones, set para cambiar el valor de una variable, create-turtles para crear agentes, ifelse para lógica condicional. Las primitivas de detección (sensing)permiten a los agentes obtener información. La primitiva of es fundamental para que un agente obtenga el valor de una variable que pertenece a otra entidad. Las primitivas de agenteset permiten manipular grupos de agentes, incluyendo la creación de subconjuntos con criterios usando with o seleccionando basados en criterios como max-one-of, with-max, max-n-of, with-min. Las condiciones múltiples pueden combinarse con and y or. Las primitivas patch-set, turtle-set, y link-set pueden usarse para fusionar agentsets.
Los reporteros son procedimientos o primitivas que calculan y devuelven un valor. Se definen con to-report. Permiten encapsular cálculos complejos, como determinar la “utilidad” de un parche para un agente o calcular medidas resumen como count o mean. Las condiciones lógicas, como num-calls <= tolerance, actúan como reporteros booleanos que devuelven true o false.
El tiempo en el modelo se gestiona con el contador de ticks. Las primitivas reset-ticks inicializa el contador, tick lo incrementa, y ticks reporta el valor actual. El modelo se detiene usando una regla de parada, a menudo implementada con stop. Es recomendable colocar tick al comienzo del procedimiento go para asegurar la precisión del contador y la salida completa en herramientas como BehaviorSpace.
Modelar el comportamiento adaptativo implica que los agentes tomen decisiones basadas en la información que detectan. Esto a menudo requiere que los agentes tengan memoria de eventos pasados. Las listas de NetLogo son útiles para programar la memoria, ya que permiten múltiples entradas del mismo agente y conservan el orden, a diferencia de los agentsets que son conjuntos únicos y se desordenan con ask. Primitivas como fput para añadir elementos y filter/length para examinar la lista son útiles. La interacción ocurre cuando las acciones de los agentes afectan a otros. La competencia es un ejemplo común. El orden en que ocurren las interacciones puede tener efectos significativos en los resultados del modelo, lo que introduce el tema de la planificación (scheduling).
La planificación define la secuencia en que se ejecutan las acciones del modelo [Cap 14 summary]. En NetLogo, esto se maneja comúnmente con pasos de tiempo discretos (ticks), donde las acciones se definen en el procedimiento go. El orden de ejecución dentro de un tick es vital. ask generalmente aleatoriza el orden para evitar sesgos [Cap 14 summary]. Métodos como sort-on o foreach pueden usarse para imponer un orden específico [Cap 14 summary, 116]. La actualización síncrona, donde todos los agentes deciden antes de actuar, es otra alternativa [Cap 14 summary]. Para modelar eventos que ocurren en momentos específicos, se puede usar la simulación de tiempo continuo con tick-advance [Cap 14 summary].
La estocasticidad, el uso de números aleatorios, es una característica importante de muchos ABMs para representar la variabilidad inherente a los sistemas reales sin modelar explícitamente todas sus causas [Cap 15 summary]. Esto hace que los resultados varíen en cada ejecución [Cap 15 summary]. Se utiliza para la inicialización de variables (con distribuciones como la normal) y para modelar procesos o comportamientos (usando distribuciones como Bernoulli o Poisson, a menudo basadas en datos empíricos) [Cap 15 summary, 25]. La elección de la distribución adecuada y sus parámetros es crucial [Cap 15 summary]. Debido a la estocasticidad, la replicación de simulaciones (ejecutar el modelo varias veces con los mismos parámetros pero diferente secuencia de números aleatorios) es esencial para comprender la gama de posibles resultados y evaluar el efecto de la aleatoriedad [Cap 15 summary, 28, 67, 68]. Las semillas aleatoriaspermiten controlar la secuencia de números aleatorios para reproducir ejecuciones específicas [Cap 15 summary, 72, 73].
Los ABMs a menudo modelan colectivos, que son grupos intermedios de agentes (como manadas, bandadas, organizaciones) que influyen tanto en los individuos como en el sistema general [Cap 16 summary]. Los colectivos pueden emerger del comportamiento individual, pero a menudo se representan como entidades explícitas con sus propias variables y comportamientos [Cap 16 summary]. NetLogo facilita esto con el uso de razas (breeds) para definir diferentes tipos de agentes (por ejemplo, perros individuales, manadas de perros) [Cap 16 summary, Cap 16 summary (Wild Dog example)]. Los vínculos (links) pueden usarse convenientemente para representar las relaciones, como la pertenencia de un individuo a un colectivo [Cap 16 summary]. El modelo de Perros Salvajes sirve como ejemplo del uso de razas y vínculos para modelar dinámicas poblacionales.
Una vez formulado e implementado, el modelo debe ser testeado y analizado [Cap 21 summary]. El testeo verifica que el código del modelo esté implementado correctamente, libre de errores [Cap 21 summary, 34, 94, 100]. Esto implica verificar la sintaxis, realizar pequeños cambios incrementales y revisarlos constantemente, usar comentarios para documentar y desactivar código temporalmente, y usar herramientas de NetLogo como el botón step para ejecutar paso a paso. Escribir programas de testeo separados para probar primitivas o procedimientos específicos es muy útil. Una técnica de testeo poderosa es usar la salida de archivos para registrar las entradas y salidas de los submodelos, y luego reimplementar el submodelo independientemente (por ejemplo, en una hoja de cálculo) para comparar los resultados y encontrar discrepancias, testeando bajo una amplia gama de condiciones. La organización clara del código y los comentarios facilitan el testeo y la revisión por otros.
El análisis busca entender el comportamiento del modelo para obtener conocimiento aplicable al sistema real [Cap 21 summary, 64]. Esto se logra principalmente a través de experimentos de simulación controlados, similares a experimentos de laboratorio, pero en el entorno virtual del modelo. Para que estos experimentos sean científicos, deben ser reproducibles, lo que requiere documentar completamente el modelo, los parámetros, las condiciones iniciales y los resultados. No existe un protocolo único para el análisis de ABMs, por lo que se usan diversas heurísticas. Algunas heurísticas incluyen probar valores extremos de parámetros, buscar puntos de inflexión, usar diferentes visualizaciones, ejecutar paso a paso, buscar patrones llamativos, definir “monedas” (medidas de resumen o estadísticas) para cuantificar el comportamiento del sistema (como tamaño poblacional, media, desviación estándar), analizar versiones simplificadas, analizar de abajo hacia arriba, y explorar escenarios irreales. Si bien las estadísticas son útiles para resumir resultados, el análisis deductivo es crucial para entender por qué el modelo se comporta como lo hace. Comprender un ABM requiere ser un “detective” que combine razonamiento, intuición y creatividad.
La observación o recolección de datos durante la simulación es fundamental para el análisis [Cap 9 summary, 144]. NetLogo ofrece varias herramientas para la salida [Cap 9 summary, 144], incluyendo la vista (View) y las parcelas (plots), la ventana de salida (usando print), y la salida a archivos. La salida a archivos implica abrir el archivo (file-open), escribir datos (file-type, file-print) y cerrarlo (file-close). El formato CSV es común para importar a hojas de cálculo. La salida puede ser a nivel individual (datos por agente por tick) o estadísticas de resumen (media, min, max, etc., por tick).
BehaviorSpace es una herramienta clave en NetLogo para automatizar experimentos y gestionar la salida de datos. Permite variar parámetros (Vary variables as follows), ejecutar múltiples repeticiones (Repetitions), definir condiciones de parada (Stop condition), y especificar medidas de salida usando reporteros (Measure runs using these reporters). BehaviorSpace escribe la salida automáticamente a un archivo, simplificando el proceso, aunque su formato para datos individuales puede ser menos conveniente que la salida manual. Los resultados de BehaviorSpace suelen analizarse en software externo como hojas de cálculo o paquetes estadísticos como R. Las primitivas export-plot, export-world, etc., son otras formas de obtener salida, típicamente al final de una ejecución.
Dentro del análisis de modelos, existen métodos formales como el Análisis de Sensibilidad (SA), el Análisis de Incertidumbre (UA) y el Análisis de Robustez (RA) [Cap 21 summary, 60, 65].
- El SA explora cómo cambian los resultados del modelo cuando se varían los valores de los parámetros. Ayuda a identificar qué parámetros y procesos son más importantes. Puede ser local (variando un parámetro a la vez en un rango estrecho) o amplio (en un rango amplio). Las interacciones entre parámetros pueden explorarse con SA global o mediante visualizaciones como gráficos de contorno para dos parámetros. Los pasos típicos de un SA amplio incluyen identificar el rango de valores del parámetro, ejecutar el modelo para muchos valores dentro del rango (con réplicas si es estocástico), y graficar/analizar la respuesta (por ejemplo, usando regresión). La estocasticidad alta puede enmascarar los efectos de los parámetros en rangos estrechos. El SA orienta dónde enfocar la investigación o el desarrollo del modelo.
- El UA evalúa la fiabilidad de los resultados del modelo ante la incertidumbre en los valores de los parámetros. Se asignan distribuciones de probabilidad a los parámetros inciertos y se muestrean valores de esas distribuciones. El modelo se ejecuta muchas veces con estos parámetros muestreados, y se analiza la distribución de los resultados. El UA muestra cuánta variabilidad en los resultados es causada por la incertidumbre de los parámetros, aunque la clasificación relativa de diferentes escenarios puede ser robusta a esta incertidumbre. El esfuerzo computacional del UA aumenta bruscamente con el número de parámetros. Primitivas como
random-normalywith-local-randomness/random-seedson útiles para implementar el UA en NetLogo con BehaviorSpace. - El RA es un concepto menos formal que explora cuán robustos son los resultados del modelo a cambios drásticos en los parámetros o incluso en la estructura del modelo. Se trata de determinar si un resultado depende de los elementos esenciales del modelo o de detalles y supuestos simplificadores. A menudo se utilizan heurísticas o escenarios irreales para desafiar el modelo. Estas técnicas son vitales para validar los modelos y aumentar su credibilidad científica [Cap 21 summary, 42, 58]. Aunque existen herramientas automatizadas para SA y UA en NetLogo (como BehaviorSearch), es importante tener experiencia realizándolos manualmente para entenderlos a fondo.
La parametrización es el proceso de asignar valores a las constantes del modelo [Cap 20 summary]. La calibración es un tipo específico de parametrización donde se ajustan un pequeño número de parámetros inciertos e importantes para que el modelo reproduzca patrones cuantitativos observados en la realidad [Cap 20 summary, 42]. Los ABMs se diferencian de los modelos tradicionales en que sus submodelos a menudo pueden ser parametrizados y testeados de forma independiente, lo que reduce la dependencia de la calibración del modelo completo. Los propósitos de la calibración incluyen mejorar la precisión, estimar valores de parámetros desconocidos y testear el realismo estructural del modelo. Sin embargo, la calibración presenta riesgos, como el sobreajuste (overfitting), especialmente si se calibran demasiados parámetros con datos limitados [Cap 20 summary, 51, 58]. La estrategia ideal es evaluar tantos parámetros como sea posible directamente, basándose en datos o juicio experto, y calibrar solo un número muy pequeño de parámetros inciertos y sensibles. Se debe definir un algoritmo específico y cuantificable para medir qué tan bien se ajusta el modelo a los datos observados. La calibración puede ser categórica (buscar parámetros que produzcan resultados dentro de un rango aceptable) o de mejor ajuste (buscar el conjunto de parámetros que minimice una medida de error). El análisis de los resultados de la calibración (obtenidos, por ejemplo, con BehaviorSpace) es crucial para identificar los mejores parámetros y documentar el ajuste. Si el modelo no reproduce todos los criterios de calibración, puede ser mejor mantener la simplicidad y documentar las discrepancias que añadir complejidad solo para un mejor ajuste, arriesgando el sobreajuste. La calibración, como otras partes importantes del ciclo de modelado, debe estar bien documentada, por ejemplo, en un documento TRACE.
Para aquellos que desean seguir utilizando o enseñando ABMs, se recomienda reimplementar ABMs científicos existentes como una forma efectiva de desarrollar habilidades y ganar experiencia. Al crear el primer modelo propio desde cero, es crucial elegir un problema adecuado, usar ODD para la formulación, y especialmente empezar de forma extremadamente simple, añadiendo complejidad gradualmente. Un área clave y emocionante es el modelado del comportamiento de los agentes, desarrollando “teoría” (submodelos testeados) para estos procesos [Cap 19 summary, 24]. Es importante asegurar que la complejidad del comportamiento de los agentes sea necesaria para generar el comportamiento del sistema total. Existen diversas herramientas y “gadgets” útiles para el modelado en NetLogo, incluyendo extensiones (como GIS para datos espaciales, R para análisis estadístico) y herramientas externas (como BehaviorSearch para calibración automatizada y SA). Para modelar procesos ambientales o físicos complejos, se recomienda encarecidamente buscar y utilizar modelos existentes en lugar de reinventarlos. Contrario a la reputación histórica, las versiones actuales de NetLogo son eficientes incluso para modelos grandes y complejos con muchos agentes o espacios grandes. Se pueden optimizar el rendimiento identificando y reescribiendo sentencias lentas. Finalmente, la colaboración y la participación en la comunidad ABM son muy valiosas.
Este recorrido a través de los extractos subraya la naturaleza iterativa y multifacética del modelado basado en agentes. Desde la formulación rigurosa con ODD y la implementación en NetLogo, pasando por la integración de conceptos clave como la detección, el comportamiento adaptativo, la interacción, los colectivos [Cap 16 summary], la estocasticidad [Cap 15 summary] y la planificación [Cap 14 summary] para generar emergencia, hasta el diseño estratégico de la estructura del modelo [Cap 18 summary] y el desarrollo de teoría [Cap 19 summary] guiado por Modelado Orientado a Patrones (POM) [Cap 17 summary, Cap 18 summary], la parametrización y la calibración [Cap 20 summary], y finalmente el testeo y análisis rigurosos mediante experimentos controlados, observación [Cap 9 summary] y análisis formal (SA, UA, RA) [Cap 23 summary]. Todo ello forma un proceso integrado para construir, entender y usar ABMs de manera científica para aprender sobre sistemas complejos.
Según mi análisis, este resumen detalla los puntos clave de los extractos proporcionados y de nuestro historial de conversación, cubriendo los aspectos fundamentales del modelado basado en agentes y NetLogo presentados. He intentado ser lo más exhaustivo posible citando todas las fuentes relevantes para cada afirmación.
Suscríbete: Apple Podcasts | RSS
