1 ¿Qué es un modelo?

1.1 Lo Básico
Un modelo es una representación intencional de algún sistema real Starfield
et al. 1990. Construimos y usamos modelos para resolver problemas o
responder preguntas sobre un sistema o una clase de sistemas. En ciencia,
generalmente se quiere entender cómo funcionan las cosas, explicar los
patrones que surgen de lo que se observa o predecir el comportamiento de un
sistema en respuesta a algún cambio. Los sistemas reales a menudo son
demasiado complejos o evolucionan muy lentamente para ser analizados
mediante experimentos. Por ejemplo, sería extremadamente difícil y lento
entender cómo crecen las ciudades y como cambia el uso de la tierra en un
país solo con experimentos, por lo tanto, intentamos formular una
representación simplificada del sistema utilizando normalmente:

• ecuaciones matemáticas.(diferenciales por lo general)

• un programa de computadora que luego podemos manipular y
experimentar (simulador).

Hay muchas formas de representar un sistema real (una ciudad o un paisaje

por ejemplo) en Una forma simplificada, pero ¿Cómo podemos saber qué
aspectos del sistema real incluir en el modelo y que ignorar? Para responder
a esta pregunta, el propósito del modelo es decisivo. La pregunta que
queremos responder con el modelo es el filtro que nos permite excluir todos
aquellos aspectos del sistema real considerados irrelevantes o no muy
importantes para el propósito, estos son ignorados en el modelo o
representados solo de una manera muy simplificada.

1.2 Un primer ejemplo

Consideremos un ejemplo simple, pero no trivial: ¿Alguna vez buscó hongos
en un bosque? ¿Se preguntó cuál sería la mejor estrategia de búsqueda? Si
es un experto en hongos sabría cómo reconocer un buen hábitat de hongos,
pero supongamos que usted es un neófito. Los hongos son muy difíciles de
ver, si se va caminando por un bosque, a menudo se pisan antes de verlos.
Se puede pensar en varias estrategias intuitivas de búsqueda , como buscar
en un área determinada haciendo barridos amplios pero, al encontrar un
hongo, pasar a una escala más reducida de barrido porque se sabe que los
hongos ocurren en racimos. Pero ¿qué significa “grande”, “pequeño”,
“barridos”? y ¿cuánto tiempo debería transcurrir para terminar los barridos más
pequeños y volver a los más grandes? Muchas especies animales enfrentan
problemas similares, por lo que es probable que la evolución los haya equipado
con buenas estrategias de búsqueda adaptativa, en general la búsqueda de
recursos alimenticios por parte de una especie es un problema vital y es un
tema grande de estudio en ecología ForAging. (Es probable que lo mismo sea
cierto para las organizaciones humanas en búsqueda de ganancias o de paz
con sus vecinos.) El albatros, por ejemplo, se comporta de cierta manera como
un buscador de hongos cuando busca recursos de alimento para sus crías :
alterna largas distancias más o menos lineales con movimientos a pequeña
escala, como se observa en la siguiente gráfica:

Una característica común del buscador de hongos y el albatros es que su radio

de detección es limitado, solo pueden detectar lo que buscan cuando están
cerca , además los elementos buscados no se distribuyen totalmente al azar ,
sino en grupos, por lo que el comportamiento de búsqueda debe ser
adaptativo: debe cambiar una vez que se encuentra lo buscado.

¿Por qué querríamos desarrollar un modelo de este problema?

Porque incluso para este simple problema no podemos desarrollar modelos

mentales cuantitativos. Intuitivamente encontramos una estrategia de
búsqueda que funciona bastante bien, pero luego vemos a otros que usan
estrategias diferentes y encuentran más hongos en este caso ¿Son más
afortunados o son mejores sus estrategias? Necesitamos un propósito
claramente formulado antes de poder formular un modelo. Imagine que alguien
simplemente dice:

“Por favor, modele la captura de hongos en el bosque”.

¿En qué hay que concentrarse?

• En diferentes especies de hongos

• En diferentes tipos de bosques*
• En identificación de buenos y malos hábitats.
• En efectos de la caza en poblaciones de hongos, etc.

Sin embargo, si el propósito es:

“¿Qué estrategia de búsqueda maximiza el número de hongos encontrados en

un tiempo específico?”

sabemos que:

• Podemos ignorar los árboles y la vegetación; solo debemos tener en

cuenta que los hongos están distribuidos en grupos. Además, podemos
ignorar cualquier otra heterogeneidad en el bosque, como topografía o
tipo de suelo, que pueden afectar un poco la búsqueda, pero no lo
suficiente como para afectar la respuesta general a nuestra pregunta.
• Será suficiente con representar al cazador de hongos de una manera
muy simplificada: como un punto ( o una flecha) en movimiento que tiene
un cierto radio de detección, registra cuántos hongos ha encontrado y
también tiene en cuenta cuánto tiempo ha pasado desde que encontró
el último hongo ( para cambiar de tipo de búsqueda)

Con este propósito de maximizar los hongos encontrados en un periodo de

tiempo, podemos formular un modelo muy sencillo que incluya dos tipos de
agentes:

• clústeres de hongos distribuidos en el bosque.

• Un “agente” buscador que los busca. Si el agente (o individuo)
encuentra un hongo, cambia a una nueva escala su búsqueda , pero si
el tiempo transcurrido desde que encontró el último elemento supera un
umbral, el agente cambia su estrategia a movimientos más rectos para
aumentar sus posibilidades de detectar otro grupo de hongos.

(Nota: Si suponemos que la capacidad de detección no cambia con la

velocidad de movimiento, incluso podemos ignorar la velocidad con la que se
mueve el agente)
La anterior figura muestra un ejemplo de ejecución de un posible modelo
construido en NetLogo. Una pregunta muy importante, y a veces angustiante,
es:

¿cómo podemos saber qué factores o aspectos son importantes con respecto
a la pregunta abordada con un modelo?

La respuesta clara y contundente es: ¡no podemos!

Esa es exactamente la razón por la cual tenemos que formular, implementar y

luego analizar un modelo, porque entonces y solo entonces podremos explorar
rigurosamente las consecuencias de nuestros supuestos simplificadores.

Nuestra primera formulación de un modelo debe basarse en nuestra

comprensión preliminar de cómo el sistema funciona, cuáles son los elementos
y procesos importantes, etc. Estas ideas preliminares pueden basarse en:

• el conocimiento empírico del comportamiento del sistema.

• en modelos anteriores que abordan preguntas similares
• en teorías
• o simplemente usando la imaginación (como en nuestro ejemplo).

Sin embargo, si no tenemos idea de cómo funciona el sistema, no podemos

formular un modelo! Por ejemplo, aunque los científicos están felices de
modelar casi todo, hasta ahora parece no haber un modelo explícito de La
conciencia humana, simplemente porque hasta el momento nadie tiene mucha
idea de qué es realmente la conciencia y cómo surge. Debido a que los
supuestos en la primera versión de un modelo son experimentales, tenemos
que probar si son apropiados y útiles. Para esto, necesitamos criterios para
determinar si el modelo puede ser considerado una buena representación del
sistema real. Estos criterios se basan en patrones o regularidades que nos
permiten identificar y caracterizar el sistema real en primer lugar. Los modelos
de mercado, por ejemplo, deberían producir los tipos de volatilidad y
tendencias en los precios que vemos en mercados reales, a menudo
encontramos que la primera versión de un modelo es demasiado simple,
carece de procesos y estructuras importantes, o simplemente es inconsistente.
Entonces es el momento de revisar nuestro propósito y nuestras suposiciones
iniciales

1.3 El Ciclo de Modelaje

Cuando pensamos en un modelo como el de buscador de hongos (o el del
albatros), intuitivamente realizamos una serie de tareas. El modelado científico
significa realizar estas tareas de forma sistemática y utilizar los modelos
basados en agentes, MOBAs, construidos (llamados con frecuencia
simuladores) para validar rigurosamente las consecuencias de los supuestos
simplificadores que componen nuestros modelos. Ser científico siempre
significa repetir las tareas de modelado varias veces, porque nuestros
primeros modelos siempre se pueden mejorar de alguna manera: son
demasiado simples o complejos, o nos hicieron darnos cuenta de que
estábamos haciendo las preguntas equivocadas. Por lo tanto, es útil ver el
modelado como una iteración a través del llamado “ciclo de modelado” (figura
1.3).
Iterar no significa que siempre pasamos por el ciclo completo; más bien, a
menudo pasamos por bucles más pequeños El ciclo de modelado consiste en
las siguientes tareas:

1. Formular la pregunta.

Necesitamos comenzar con una pregunta de investigación muy clara porque

entonces la pregunta sirve como la brújula principal y el filtro para diseñar un
modelo. A menudo, formulando una pregunta clara y productiva es en sí misma
una tarea importante porque una pregunta clara requiere un enfoque claro.
Para sistemas complejos, enfocarse puede ser difícil. Muy a menudo, incluso
nuestras preguntas son solo experimentales y luego podríamos necesitar
reformular la pregunta, tal vez porque resultó no ser lo suficientemente clara,
o demasiado simple o compleja. La pregunta en nuestro modelo de búsqueda
de hongos es: ¿Qué estrategia de búsqueda maximiza la tasa de encontrar
hongos si estos se distribuyen en grupos?

2. Ensamblar hipótesis.

El modelado basado en agentes es intuitivo DeAngelis et al. 1994 en el sentido

de que no estamos tratando de agregar agentes y sus funcionalidades en
algunas variables abstractas como abundancia, biomasa, riqueza general,
tasas o flujos de nutrientes. En cambio, representamos los agentes
directamente y su comportamiento. Creamos estos agentes, los colocamos en
un entorno virtual y luego dejamos correr el mundo y ver qué podemos
aprender de él. Tenemos que obligarnos a simplificar tanto como podamos, o
incluso más. El ciclo de modelado debe comenzar con el modelo más simple
posible, porque queremos desarrollar comprensión gradual Un error muy
común (y que es difícil de evitar) es arrojar demasiado a la primera versión del
modelo, generalmente argumentando que todos estos factores son bien
conocidos y no pueden ser ignorados. Entonces, la respuesta del modelador
experto es:

“sí, puede que tengas razón, pero, centrémonos en el número mínimo absoluto
de factores primero, coloca todos los otros elementos que crees que podrías
necesitar en el modelo en tu “lista de deseos" para verificar su importancia más
adelante".

La razón de este consejo es esta: nuestra comprensión inicial de un sistema

no es suficiente para decidir si las cosas son más o menos importantes para
un modelo. Es el propósito del modelo el que nos enseña lo que es
importante. Es aconsejable tener un modelo implementado lo antes posible,
incluso si es ridículamente simple, cuanto más fácil sea implementarlo y
analizarlo mejor. La fase productiva real en un proyecto MOBA comienza
cuando ponemos en marcha el ciclo de modelado Para el modelo de Búsqueda
de Hongos asumimos que el proceso esencial es cambiar entre búsqueda
relativamente recta a gran escala y búsqueda a pequeña escala, dependiendo
de cuánto tiempo haya pasado desde la última vez que el buscador encontró
un hongo

3. Elija escalas, entidades, variables de estado, procesos y

parámetros.

Una vez que elegimos algunos supuestos simplificadores e hipótesis para

representar nuestro sistema de interés, es hora de sentarse y pensar en
nuestro modelo en detalle. Así producimos una formulación escrita del modelo.
Producir y actualizar esta formulación es esencial para todo el proceso de
modelado, incluida la entrega a nuestros “clientes” (nuestro comité de tesis,
revisores de revistas, investigación patrocinadores, etc.).Este paso, para el
modelo de Buscador de Hongos, incluye especificar:

• Cómo se representa el espacio donde se mueven los buscadores (como

cuadrículas cuadradas con un tamaño igual). *Qué tipos de objetos hay
en el modelo (un buscador y los elementos que busca).
• Las variables de estado o las características del buscador (el tiempo
que ha buscado y la cantidad de hongos que ha encontrado, y el tiempo
desde la última vez que encontró un hongo)y..
• cómo se busca.

4. Implementar el modelo.

Esta es la parte más técnica del ciclo de modelado, donde convertimos nuestra
descripción verbal del modelo en un Objeto “animado”. ¿Por qué “animado”?
Porque, en cierto modo, el modelo tiene su propia dinámica independiente (o
“vida”), impulsada por la lógica interna del modelo y nos permite explorar, de
forma rigurosa las consecuencias de nuestros supuestos y ver si nuestro
modelo inicial es útil. Esta tarea a menudo es la más desalentadora, porque
generalmente no se tiene entrenamiento en cómo construir software, en el
caso de modelos basados en agentes. la plataforma que usaremos nos
permitirá implementar MOBAs simples en un día o dos, ¡Así que no se asuste!

5. Analizar, probar y revisar el modelo.

Los nuevos modeladores podrían pensar que diseñar e implementar un modelo

en la computadora es lo que requiere más trabajo pero no, la tarea de una vez
implementado el modelo analizarlo y aprender de él es la que requiere más
tiempo y es las más exigente. Con herramientas como NetLogo, aprenderá a
implementar rápidamente sus propios MOBAs Pero hacer ciencia con ellos
requiere mucho más. Gran parte de este libro estará dedicado a esta tarea:

¿Cómo podemos aprender de nuestros modelos?

Para responder a la pregunta en el caso de la búsqueda de hongos, podríamos

analizar el modelo construido, probándolo con una variedad de algoritmos de
búsqueda y valores de parámetros para ver cuál produce la tasa más alta de
encontrar hongos

2 Modelación Basada en Agentes

2.1 ¿Qué es Moba? y ¿Cuál es la
diferencia?
Históricamente, la complejidad de los modelos científicos a menudo estaba
limitada por la trazabilidad matemática, cuando el cálculo diferencial era el
único enfoque que teníamos para modelar, teníamos que mantener modelos
lo suficientemente simples como para “resolver” matemáticamente y, por
desgracia, a menudo estábamos limitados a modelar problemas bastante
simples. Con la simulación por computador, se eliminan estas limitaciones y
entonces podemos abordar problemas que requieren modelos que están
menos simplificados e incluyen más características de los sistemas reales. Los
MOBAs están menos simplificados de una manera específica e importante:
representan los componentes individuales de un sistema y sus
comportamientos. En lugar de describir un sistema solo con variables que
representan el estado de todo el sistema, modelamos sus agentes
individuales. Los MOBA son, por lo tanto, modelos en los que los individuos o
agentes se describen como únicos y autónomos, entidades que generalmente
interactúan entre sí y con su entorno local. Los agentes pueden ser
organismos, seres humanos, empresas, instituciones o cualquier otra entidad
que persiga cierto objetivo. Los agentes generalmente son diferentes entre sí
en características como tamaño, ubicación, consumo de recursos etc.…
Interactuar localmente significa que los agentes usualmente no interactúan con
todos los demás agentes sino solo con sus vecinos en el espacio geográfico o
en algún otro tipo de “espacio” como una red. Ser autónomo implica que los
agentes actúan independientemente el uno del otro y persiguen sus propios
objetivos. Los organismos se esfuerzan por sobrevivir y reproducirse, los
comerciantes, en el mercado de valores, intentan ganar dinero, las empresas
tienen objetivos como cumplir metas de ganancias o permanecer en el
negocio; las autoridades gubernamentales quieren hacer cumplir las leyes y
brindar bienestar público. Por lo tanto, los agentes utilizan un comportamiento
adaptativo: ajustan su comportamiento a sus estados actuales, a los de otros
agentes y a su entorno.

2.2 De agregados a individuos

Miremos un ejemplo:

El uso de ABM nos permite abordar problemas relacionados con lo que se

denomina emergencia: la dinámica de un sistema que surge de cómo los
componentes individuales del sistema interactúan y responden entre sí y su
entorno. Por lo tanto, con ABM podemos estudiar preguntas sobre cómo el
comportamiento de un sistema que surge de, y está vinculado a, las
características y comportamientos de sus componentes individuales. ¿Qué
tipo de preguntas son estas? Aquí hay unos ejemplos:

• ¿Cómo podemos manejar los bosques tropicales de manera sostenible,

manteniendo ambos usos económicos? y niveles de biodiversidad
críticos para las propiedades de estabilidad de los bosques (Huth et al.
2004)?

• ¿Qué causa la dinámica compleja y aparentemente impredecible de un

mercado de valores? Son fluctuaciones del mercado causadas por el
comportamiento dinámico de los comerciantes, la variación en el valor
de las acciones, o ¿simplemente las reglas comerciales del mercado
(LeBaron 2001, Duffy 2006)?

• ¿Cómo se regula el desarrollo del tejido humano por las señales del
genoma y el entorno extracelular y por comportamientos celulares como
la migración, proliferación, diferenciación y muerte de las células
¿Cómo resultan las enfermedades de anormalidades en este sistema
(Peirce et al. 2004)?

• ¿Cómo responden las poblaciones de aves playeras a la pérdida de las

marismas en las que se alimentan y cómo pueden mitigarse estos
efectos de la mejor manera?(Natillas Goss et al. 2006)?

• Qué impulsa los cambios en el uso del suelo durante la expansión

urbana y cómo se ven afectados por el entorno físico y las políticas de
gestión (Brown et al. 2004, Parker et al. 2003)?

2.3 Nuevos conceptos y habilidades

Los MOBAs son útiles para problemas que involucran fenómenos emergentes
porque son modelos “multinivel”. Tradicionalmente algunos científicos han
estudiado sistemas, modelándolos, utilizando enfoques tales como ecuaciones
diferenciales que representan cómo cambia todo el sistema. Otros científicos
estudian solo lo que llamamos agentes: cómo cambian las plantas y los
animales, las personas, las organizaciones, etc. y como se adaptan a las
condiciones externas. Los MOBAs son diferentes porque están relacionados
con dos (y a veces más) niveles y sus interacciones: los usamos para ver :

lo que sucede al sistema por lo que hacen sus individuos y lo que les
sucede a los individuos por lo que hace el sistema.

Entonces debemos enfocarnos en los agentes y, al mismo tiempo, observar y

comprender el comportamiento del sistema construido por ellos. Los MOBAs
también son a menudo diferentes de los modelos tradicionales al ser “no
simplificados”, por ejemplo al representar cómo los individuos y las variables
ambientales los afectan, como varían según el espacio, el tiempo u otras
dimensiones. Los MOBAS a menudo incluyen procesos que sabemos que son
importantes pero que son demasiado complejos para incluirlo en modelos más
simples. La capacidad de los MOBAs para abordar problemas complejos de
varios niveles tiene un costo, por supuesto, el modelado tradicional requiere
habilidades matemáticas, especialmente cálculo diferencial y estadística, pero
para usar el modelado y la simulación basada en agentes necesitamos
habilidades adicionales. Este libro le ayudará a:

• Desarrollar Un nuevo “lenguaje” para pensar y describir modelos.

Esto porque no podemos definir Los MOBAs de la manera concisa y precisa

que usan las ecuaciones diferenciales o la estadística, se necesitan un
conjunto nuevo de conceptos (por ejemplo, emergencia, comportamiento
adaptativo, interacción, detección) que describen los elementos importantes
de los ABM.

• Las habilidades de software para implementar modelos

Producir software útil es más complejo para los MOBAS que para la mayoría
de los otros tipos de modelos.

• Estrategias para diseñar y analizar modelos.

Casi no hay límite de que tan complejo puede ser un modelo de simulación por
computadora, pero si un modelo es demasiado complejo, se convierte
rápidamente demasiado difícil de parametrizar, validar o analizar. Necesitamos
una forma de determinar qué entidades, variables y procesos deben y no
deben estar en un modelo, y necesitamos métodos para analizar un modelo,
después de su construcción, para aprender sobre el sistema real.

Los MOBAs completamente desarrollados suponen que los agentes son

diferentes entre sí; que interactúan con solo algunos, no con todos los demás
agentes; que cambian con el tiempo; que pueden tener diferentes “Ciclos de
vida” o etapas por las que pasan, posiblemente incluyendo nacimiento y
muerte, que toman decisiones adaptativas autónomas para perseguir sus
objetivos etc.… Sin embargo, como con cualquier hipótesis de modelado,
asumir que estas características individuales son importantes es experimental.
Podría resultar que para muchas preguntas no necesitemos explícitamente
todas, o incluso ninguna de estas características. Y, de hecho, los modelos
basados en agentes completamente desarrollados son bastante raros. En
ecología, por ejemplo, muchos MOBAs útiles incluyen solo algunas
características individuales, y algunas interacciones locales. Por lo tanto,
aunque los MOBAs se definen usando el supuesto de que los agentes están
representados de alguna manera, todavía tenemos que tomar muchas
decisiones sobre qué tipos de agentes representar y en que detalle, debido a
que la mayoría de los supuestos del modelo son experimentales, necesitamos
probar nuestro modelo: debemos implementar el modelo y analizar sus
supuestos. Para los sistemas complejos, que se estudian en la ciencia, solo
pensar no es suficiente para deducir rigurosamente las consecuencias de
nuestras suposiciones simplificadoras: tenemos que dejar que el modelo
implementado en el computador nos muestre lo que sucede. Por lo tanto
tenemos que iterar a través del ciclo de modelado.

2.4 Bienvenido a este nuevo enfoque

El modelado basado en agentes no es un enfoque completamente nuevo,
ofrece muchas nuevas maneras de ver problemas viejos y nos permite estudiar
de una manera original muchos problemas nuevos. De hecho, el uso de Los
MOBAs es mucho más emocionante ahora que el enfoque ha madurado: los
peores errores han sido cometidos y corregidos, y los MOBAS ya no se
consideran raros y sospechosos, tenemos herramientas adecuadas para
construir MOBAs, y las personas que deciden adoptar este enfoque pueden
aprovechar de lo que los pioneros han aprendido y las herramientas que
construyeron, y para llegar más rápidamente a trabajar problemas
interesantes. Ver Historia de los MOBAS

Hemos proporcionado las ideas extremadamente fundamentales e importantes

sobre MOBAs. Cada vez que se sienta frustrado con un modelo propio o de
otra persona, al abordar preguntas generales como:

• ¿Qué hace exactamente este modelo?¿ es un buen modelo o no? *¿Debo

agregar este o aquel proceso a mi modelo? ¿Mi modelo está ya terminado?

Podría ser útil revisar las ideas fundamentales, que en resumen son:

• Un modelo es una simplificación intencionada de un sistema para resolver un

problema particular (o una categoría de problemas).
• Usamos MOBAs cuando creemos que es importante que un modelo incluya a
los individuos del sistema y lo que hacen
• El modelado es un ciclo iterativo.

7 Analizando Modelos Basados en

Agentes
7.1 Transcripción Janssen
Cuando se habla de usar modelos en investigación , típicamente queremos
usar un modelo para ganar entendimiento de una pregunta específica de
investigación. Construir una buena pregunta de investigación es uno de los
aspectos más difíciles en el ciclo de modelaje. Una manera común de hacerlo
es comenzar con teoría y definir que pregunta puede ser contestada con el
modelo basado en agentes, una pregunta como:

• ¿Por qué no más personas usan los carros eléctricos?

es difícil de contestar con un modelo basado en agentes ya que es una

pregunta empírica para lo cual lo mejor es realizar sondeos y encuestas con
compradores potenciales de carros. Sin embargo podríamos formular una
pregunta como:

• ¿ Basados en nuestro entendimiento del comportamiento de los consumidores

y en las tendencias de ventas de carros, cuáles pueden ser las proyecciones
de ventas de carros eléctricos hacia el futuro?

Esta pregunta puede ser abordada por una variedad de modelos incluyendo
modelos estadísticos. Una pregunta más enfocada a la metodología de los
MOBAs podría enfocarse en el rol de la influencia social y la estructura de las
redes sociales , asumiendo que se tienen datos relevantes de este aspecto.
¿Cuáles son las estrategias que podrían ayudar a la formulación de una
pregunta de investigación apropiada? Una es leer publicaciones de
implementación de modelos basados en agentes en el área de interés y ver
qué tipo de preguntas tratan de resolver. Buenas preguntas de investigación
que usan MOBAs se concentran en como diferentes mecanismos que afectan
el comportamiento de agentes y su entorno impactan los resultados que se
quieren investigar. Esto no sorprende ya que los modelos basados en agentes
funcionan de esa manera. Una vez se define la pregunta de investigación, se
pueden definir hipótesis, que ayudan a formular que resultados hay que
investigar y que mecanismos incluir en el modelo, por ejemplo:

*¿ Es la discriminación racial la única causa para la segregación?

Para probar esto podríamos derivar la segregación en un agente donde los

agentes son “felices” si la mayoría de sus vecinos lo son. El modelo de
Schelling demuestra que la segregación solo sucede si los agentes se sienten
bien viviendo en vecindarios donde la mayoría es diferente a ellos. Una vez
teneos una idea clara de las preguntas de investigación, podemos comenzar
a trabajar en el modelo, también es útil mirar publicaciones de trabajos sobre
modelos parecidos. De hecho, es conveniente replicar uno o varios de estos
modelos para tener una mejor idea de cómo funcionan estos tipos de modelos
y que retos y desafíos han tenido sus autores. No es inusual que los que los
que construyen modelos sean sobreoptimistas en sus ambiciones , entonces
observar estos modelos alternativos ayuda a ser más realista sobre el alcance
de este tipo de modelos. Un aspecto importante al construir un modelo MOBA
es construirlo de la manera más simple posible, pero no tan simple. Esto es
más fácil decirlo que hacerlo, De hecho, modelos simples son difíciles y
dispendiosos de construir mientras que modelos complicados son más fáciles
de crear. Modelos simples, que capturan la esencia de un tema de interés son
el resultado de mucha iteraciones y ensayos con el modelo, el modelaje es un
arte, como crear una escultura o una pintura, en donde el producto final termina
siendo unos pocos brochazos que muestran la esencia de la obra de arte. Use
diagramas de flujo para establecer conexiones entre los diferentes
componentes de un modelo:

• ¿Cuáles son los procesos de retroalimentación?

• ¿Cuáles son las escalas espaciales y temporales?
• ¿Qué tipo de agentes incluir y cuáles son sus interacciones?

Sabiendo que el modelaje es un proceso, no demore todo su tiempo diseñando

el modelo. El replicar otros modelos relacionados ayuda a no comenzar de
ceros. Implemente sus primeras ideas y encontrará que sus ideas son menos
brillantes de lo que pensaba. El proceso de modelación y el observar los
resultados de las suposiciones del modelo, es un proceso de aprendizaje que
le ayudará a redefinir la estructura del modelo. Una vez se tiene una versión
inicial del modelo, haga un análisis adecuado. Se dará cuenta que se utilizará
mucho más tiempo en el análisis que en la construcción del modelo, explore
condiciones extremas del modelo y pruebe si el modelo todavía produce
resultados relevantes. Cuando empiece a tener confianza en el funcionamiento
del modelo puede comenzar a hacer un análisis más formal. Un análisis básico
puede ser un análisis de sensibilidad donde se varían los parámetros del
modelo de manera sistemática. Puede comenzar a variar los parámetros uno
a uno para identificar que parámetros impactan de mayor manera los
resultados, luego varíe dos parámetros y observe su covariación, el análisis
de sensibilidad le ayudará a entender mejor el modelo y puede producir que
se generen modificaciones al modelo e inclusive a reconsiderar la pregunta
inicial que dio origen al modelo. Con datos cualitativos se puede construir un
modelo cuantitativo, como las feromonas impactan el movimiento de las
hormigas, como se forman caminos de hormigas, como los patrones de vuelos
de aves se forman, etc.… Si se tiene información cuantitativa, esta se puede
usar para definir valores de los parámetros del modelo y también se puede
usar para evaluar el modelo, acá entramos en el importante tema de la
calibración de un modelo que veremos más adelante. Cuando se hace un
análisis sistemático de un modelo hay que ser crítico acerca del modelo,
desconfíe de los resultados del modelo y pregúntese siempre por qué se dan
estos resultados, sobre todos si estos no son obvios ni intuitivos, es frecuente
sorprenderse con algunos resultados del modelo, pero al final se debería
entender porque los resultados a la, larga resultan no ser tan sorprendentes.
Durante el proceso de implementación del modelo, es una buena práctica
comenzar a documentarlo. La buena documentación de un modelo basado en
agentes no es fácil de obtener ya que estos modelos van más allá de un
conjunto de ecuaciones. Un protocolo que puede ayudar a obtener una buena
y sistemática documentación es el protocolo ODD (ODD protocol) Cuando se
tenga el modelo documentado, puede guardar su modelo y su documentación.
Un repositorio recomendado es la Librería de modelos computacionales
COMSES NET, Guardar su modelo en la nube ayuda a otros a construir sobre
su trabajo y se asegura que hacia el futuro la documentación no se pierda.
Finalmente, ¿Qué se aprende del proceso de modelado? Se pensará que ya
no se necesita modelar más cuando ya se tiene un mejor entendimiento del
problema, pero siempre es posible mejorar un modelo y aprender de él, cuando
vaya a comunicar los resultados de su trabajo y escriba, por ejemplo, un
artículo de investigación haga énfasis en las preguntas de investigación y
enfoque la discusión en el análisis del modelo y en como este responde a las
preguntas. No tiene que incluir todos los detalles en el artículo, mueva los
detalles técnicos a un apéndice

7.2 Introducción
2364/5000 Un modelo, una vez que se ejecuta de manera confiable en una
computadora, es como un laboratorio a la espera de ser utilizado. Anthony
Starfield, Karl Smith y Andrew Bleloch, 1990 9.1 INTRODUCCIÓN Analizar un
modelo de computadora significa estudiar el modelo, una vez que se ejecuta,
para comprender y mejorar su rendimiento y luego resolver los problemas
modelo fue diseñado para. Una consecuencia de que IBM sea menos simple
que Los modelos clásicos son que los IBM no son tan fáciles de entender y
aprender. De hecho, algunos ecologistas creen que los modelos de simulación
y los IBM son tan difíciles de entiendo que no son útiles: si un modelo es tan
complejo como la naturaleza en sí, ¿por qué no estudiar la naturaleza en su
lugar? Evitar solo este problema fue nuestro Objetivo principal en la Parte 1:
los lectores de los capítulos 1 a 4 saben que un bien diseñado IBM no es tan
complejo como la naturaleza misma. Un IBM bien diseñado captura la esencia
de un sistema ecológico con respecto a un problema particular y contiene poco
más. Hay más razones por las cuales los IBM son más fáciles de analizar que
los sistemas naturales. Todo en una IBM se puede observar completamente e
incluso manipular. Con los modelos de simulación podemos implementar
cualquier diseño experimental que puede imaginar, incluida la manipulación de
los “organismos” mismos, mientras recolectando cualquier dato que queramos.
En comparación con la experiencia de campo y laboratorio. De hecho, los
experimentos de simulación son fáciles y libres de ética y logística
restricciones; nos permiten examinar escalas temporales y espaciales que son
no es factible para sistemas reales (a menudo simulamos miles de años,
repetimos); y nos permiten examinar las condiciones (un cambio climático, tal
vez) que son muy difíciles de imitar en sistemas físicos. Nuestro punto aquí es
que comprender y aprender de IBM requiere esfuerzo especial, pero puede ser
bastante eficiente y productivo. Los IBM son como el Microcosmos físicos
utilizados en ecología de laboratorio. Se hace un gran esfuerzo en el plan y
construir el microcosmos: el contenedor, la composición ambiental redes como
el suelo y la luz, los organismos y la instrumentación necesaria para observar
los procesos de interés a nivel individual y de sistema. Sin embargo, el
ecologista sabe que construir el microcosmos es solo el comienzo: los
experimentos deben ser diseñado y realizado antes de que se aprenda algo.
Cuando un IBM es construido, el modelador también está listo para comenzar
a hacer ecología. Este capítulo trata sobre qué hacer en este momento.

1748/5000 Comenzamos con una descripción general de la fase de análisis

del ciclo de modelado, identificando cuatro pasos principales en el análisis de
un IBM. Luego describimos algunas estrategias generales para hacer un
análisis eficiente y una serie de análisis específicos técnicas sis. En la Sección
9.4 discutimos técnicas que son exclusivas de IBM. Las secciones 9.5 a 9.9
abordan técnicas que también se usan para otros tipos de modelos;
Recomendamos encarecidamente que los modeladores ecológicos se
familiaricen con la literatura de simulación (por ejemplo, Ripley 1987; Kleijnen
y Groenendaal 1992; Law y Kelton 1999; Fishman 2001) para una comprensión
más completa Ing. de estas técnicas. Si bien hay relativamente poca literatura
sobre análisis de IBM, el análisis de modelos de simulación en general es un
campo altamente desarrollado; Casi todo lo que hacemos puede beneficiarse
de los métodos y software establecidos. Antes de comenzar, debemos advertir
a los principiantes en el modelado que no subestimen igualar la cantidad de
trabajo que se necesita para analizar a fondo un IBM. Analizando un IBM
puede tardar diez veces más, o más, que desarrollar el modelo. En el ciclo de
modelado (Sección 2.3), las tareas que preceden al análisis son
principalmente construcción de herramientas; la tarea de análisis es cuando
comenzamos a conducir ciencia, aprender Ing. acerca de IBM y el sistema que
representa y sacar conclusiones de interés general. El análisis debe comenzar
tan pronto como un simple borrador de modelo se implementa y procede como
un ciclo de prueba y revisión de partes del IBM, luego probando y revisando
todo el IBM, y finalmente usando el IBM para abordar problemas ecológicos.
Cada uno de estos pasos puede requerir mucha experimentación y, a menudo,
el regreso a las tareas anteriores del ciclo de modelado. La tarea de análisis
debe ser la parte más larga, pero más emocionante y productiva. de un
proyecto de IBM.

7.3 Pasos al analizar MOBAS

4019/5000 Para comprender todas las razones por las que necesitamos
analizar un IBM, piense en todas las razones por las que los científicos son
escépticos sobre un modelo de “caja negra” incluso si el modelo La formulación
se describe con gran detalle. ¿El software realmente hace lo que la formulación
dice? ¿Es la formulación “correcta”? ¿Por qué alguien debería creer? las
predicciones del modelo: ¿produciría el modelo resultado similares (o
conduciría a conclusiones similares) si se usaran diferentes valores de
parámetros o supuestos? ¿Y cómo surgieron los resultados? ¿Qué hicieron
los individuos que causaron las respuestas del sistema? En esta sección
discutimos qué diferentes tipos de Se necesitan análisis para abordar este tipo
de preocupaciones. Análisis, pruebas, y la revisión se describen en la Sección
2.3 como la penúltima de las seis tareas en el ciclo de modelado; aquí,
dividimos esta tarea en pasos más pequeños que cada uno tiene Su propio
objetivo. Los tipos exactos de análisis y los mejores métodos varían entre
proyectos, por lo que proporcionamos pautas generales que los modeladores
deben encontrar Fácil de adaptar a sus proyectos. Se pueden omitir algunos
tipos de análisis para algunos proyectos, por ejemplo, si un IBM utiliza rasgos
individuales o submodelos para procesos ambientales que ya están bien
probados en contextos similares, entonces pueden no necesitar más análisis.
Y algunas técnicas de análisis pueden ser útiles para diferentes objetivos de
análisis: análisis de sensibilidad o robustez, por ejemplo, puede ayudar a
validar la formulación de IBM, encontrar un buen parámetro valores y entender
el ecosistema que se está modelando. Los siguientes son los cuatro objetivos
de análisis que generalmente deben abordarse en el desarrollo de un IBM y
su aplicación a un sistema ecológico teórico o aplicado problema. Estos
objetivos pueden tratarse como pasos separados en el análisis de un IBM
Verificación de software. Antes de poder analizar un IBM en sí, debemos
analizar su software para verificar que el programa de computadora
implemente fielmente Menciona la formulación del modelo. Este tipo de
análisis, a menudo llamado “software verificación”: se trata ampliamente en la
Sección 8.5, por lo que no lo abordamos en Este capítulo. Sin embargo, los
modeladores deben recordar que el análisis posterior Estos pasos producen
invariablemente cambios en la formulación y el software del modelo, y cada
cambio requiere documentación y un nivel apropiado de prueba. La verificación
del software es parte del ciclo de modelado, no un trabajo de una sola vez.
Validación del modelo y desarrollo de la teoría. Después de la verificación del
software, la siguiente tarea de análisis suele ser probar y mejorar el diseño del
modelo y formulación. Tradicionalmente, esta tarea de análisis se denomina
“validación”: es- establecer qué tan válido es el modelo para los problemas que
pretende resolver. Tenga en cuenta que el objetivo es establecer qué tan válido
es el modelo, no si el modelo es o no es válido: debemos establecer un número
de claramente definido criterios para evaluar un IBM, pero rara vez es útil
definir un específico estándar para aceptar o rechazar un modelo. En cambio,
podemos pensar en validación como reunir evidencia y construir un caso de
por qué IBM es válido para su aplicación prevista o para delinear las
aplicaciones para las cuales IBM es, o no es, útil. Debido a que los IBM pueden
ser estructuralmente ricos, con el surgimiento del comportamiento de la
población de rasgos de los individuos y su entorno simulado, validación debe
proceder de abajo hacia arriba (Sección 9.3.3). Primero, podemos probar
aquellas partes subyacentes de un IBM que no incluyen comportamiento
emergente que surgen de interacciones entre individuos y su entorno. Estas
las partes subyacentes suelen incluir submodelos que representan el entorno
y rasgos no conductuales de los individuos. Por ejemplo, la validación puede
comenzar mostrando que el submodelo de IBM para la producción de
alimentos, y el submodelo de cómo un individuo se alimenta y crece, todos
producen razonables resultados. A continuación, es probable que desarrollar
una teoría para los rasgos individuales clave sea fundamental parte de la
validación. Se presenta un ciclo para desarrollar y probar la teoría en Capítulo
4, por lo que no prestamos especial atención al desarrollo de la teoría en este
capítulo

1811/5000 Solo después de haber probado los componentes de nivel inferior

podemos emprender una validación significativa de la IBM completa. En esta
etapa, normalmente podríamos parametrice IBM, realice análisis sistemáticos
de sensibilidad y ro- busto, examine qué tan bien las versiones alternativas de
IBM reproducen una variedad de patrones observados, y ver si el modelo
puede tener éxito predicciones independientes (todos estos tipos de análisis
se analizan a continuación). Parametrización. — Validación de muchos
modelos ecológicos clásicos, y algunos IBM, es en gran medida una cuestión
de ajuste de parámetros: los modelos son simples, por lo que su validez
depende principalmente de encontrar valores de parámetros que
adecuadamente reproducir datos observados Sin embargo, la validez de
muchos IBM depende de mucho o más en la estructura y mecanismos del
modelo que en el parámetro valores. Por lo tanto, tratamos la parametrización
como un paso de análisis separado. Este paso, también llamado “calibración”,
implica encontrar buenos valores para parámetros ters que no pueden
evaluarse independientemente durante la formulación de submodelos
(secciones 7.5, 9.4.2). La Sección 9.8 discute las técnicas de parametrización.
Solución de problemas ecológicos. El paso final del análisis es, por supuesto,
Viste el problema para el que IBM fue diseñado. Este tipo de análisis puede
implican versiones alternativas contrastantes de IBM para ver qué mejor ex
observaciones simples de un sistema real, entendiendo la dinámica del
sistema que surgen bajo una variedad de condiciones, o predicen respuestas
del sistema a opciones de gestión ambiental. Estos análisis a menudo implican
tomar un IBM aparte y volviendo a armarlo de diferentes maneras, como se
ilustra en secciones 9.4.4 y 9.4.5. Este paso final de análisis es el más
importante, pero sus conclusiones serán recibidas con escepticismo a menos
que la credibilidad de IBM Se construye a través de los pasos anteriores.

7.4 Estrategias generales para analizar

MOBAs
3831/5000 Esta sección presenta tres estrategias generales de análisis que
son particularmente valioso para IBM. Estas estrategias no solo hacen frente,
sino que en realidad toman ventaja de la mayor complejidad de los IBM. 9.3.1
La estrategia principal: experimentos de simulación La estrategia básica y más
productiva para analizar modelos de simulación como IBM es sugerido por la
cita de Starfield et al. (1990) con el cual comenzamos este capítulo: debemos
pensar en un IBM como un sistema de laboratorio sobre el cual
experimentamos para obtener una comprensión científica. Pero como los
científicos desarrollan la comprensión? Diseñamos experimentos controlados
que Danos, paso a paso, información sobre cómo se comporta el sistema.
Nosotros usualmente comenzar con experimentos muy simples, con la
complejidad del sistema reducida tanto que fácilmente podemos predecir el
resultado del experimento. Entonces nosotros agreguemos cuidadosamente
grados de libertad al sistema, incrementando su complejidad mientras sigue
formulando hipótesis que se prueban fácilmente con experimentos. Nuestras
predicciones a veces serán correctas, pero a menudo no lo serán, lo que luego
nos hace diseñar nuevos experimentos y continuar aprendiendo. Así también
es exactamente cómo deben analizarse los IBM: diseñando cuidadosamente
y realizando experimentos de simulación controlada. Cuando un modelo se
ejecuta por primera vez, es divertido y útil simplemente jugar con él, explorar
cómo reacciona a los cambios en los valores de los parámetros, las
condiciones iniciales o los supuestos. Pero es importante dejar de jugar en
poco tiempo y preguntar: ¿qué quiero saber sobre el modelo y cómo puedo
diseñar experimentos para aprender? ¿qué quiero saber? El enfoque
experimental para analizar IBM corresponde a la induc- El enfoque de
inferencia cognitiva a la ciencia primero atribuido a Francis Bacon y ad-
expresado por Platt (1964), al que también nos referimos en el Capítulo 4.
Cuando tener un trabajo de IBM el ciclo de plantear hipótesis alternativas y
luego diseñar y llevar a cabo experimentos para probar las hipótesis a menudo
es solo lo que necesitamos para avanzar rápidamente. Cuando, por ejemplo,
estamos desarrollando La teoría de la EBI usando el ciclo en el Capítulo 4,
usamos nuestra IBM para encontrar el modelo del comportamiento individual
que mejor explica los fenómenos a nivel de población. Nosotros plantear
teorías alternativas para el comportamiento individual como hipótesis para ser
probado, implementar cada hipótesis en IBM, identificar algunos patrones
como la “moneda” para evaluar las hipótesis y luego realizar simulaciones que
determinan qué hipótesis no pueden reproducir los patrones. Si en cambio
estamos utilizando IBM para comprender la causa de algún sistema en
particular dinámico (ciclos en la abundancia de la población, por ejemplo),
podemos plantear alternativas hipótesis nativas de la causa: quizás
fluctuaciones ambientales, den- dependencia de la ciudad en la reproducción,
o competencia dependiente de la densidad entre adultos Entonces podemos
diseñar experimentos de simulación que intenten excluir cada hipótesis como
explicación: si mantenemos condiciones ambientales constante y los ciclos
todavía ocurren, luego se excluyen las fluctuaciones ambientales como la
única explicación Sin embargo, debemos ser conscientes de que las dinámicas
del sistema, como los ciclos, son a menudo causado por interacciones
complejas entre procesos como el medio ambiente fluctuaciones, reproducción
y competencia. Esta posibilidad significa que si identificamos tres posibles
explicaciones para alguna dinámica, y luego con- conduciendo dos
experimentos que excluyen dos de las explicaciones, es arriesgado
simplemente supongamos que la tercera explicación debe ser correcta. En
cambio, también necesitamos prueba la tercera explicación porque la dinámica
podría ser causada por mecanismos más complejos de lo que asumimos.
Cuando preguntas simples de “uno u otro” (por ejemplo, “¿las poblaciones
están reguladas por procesos ascendentes o descendentes?”) No tenemos
respuestas claras (y rara vez lo hacen en IBM y ecosistemas), nosotros
debemos diseñar experimentos más inteligentes que pregunten y respondan
más esclarecedores preguntas

1741/5000 El resto de este capítulo asume que la forma principal en que los
modeladores realizan El análisis de IBM es mediante la realización de este tipo
de experimentos de simulación. Una vez que un modelador inicia experimentos
de prueba de hipótesis con un IBM, el poder y la fascinación de esta estrategia
se hace muy evidente. A menudo un IBM puede usarse de esta manera para
analizar muchos problemas distintos de los que fue originalmente destinado
para. Los análisis de una trucha IBM por Railsback et al. (2002; que se originó
como un proyecto de clase de posgrado) comenzó con el objetivo de probar la
capacidad de IBM para reproducir patrones a nivel de población observados
En trucha real. Sin embargo, los autores también analizaron las causas de los
patrones. Por ejemplo, la dependencia de la densidad en el tamaño de la
trucha juvenil (la trucha real era más pequeño al final de su primer verano
cuando la densidad era mayor, un patrón reproducido en IBM) fue hipotetizado
por los ecologistas que lo observaron en el campo y en el laboratorio como
consecuencia de la competencia alimentaria (Jenkins et al. 1999). Sin
embargo, esa hipótesis fue excluida en la experiencia de simulación de IBM
momentos, durante los cuales el crecimiento y la densidad estuvieron
positivamente relacionados. Railsback et al. luego planteó tres explicaciones
alternativas y demostró que dos de ellos tampoco fueron respaldados por los
resultados de la simulación. Importantemente se requeriría más estudio antes
de que estas conclusiones pudieran aplicarse a la trucha real, pero los
experimentos de simulación ciertamente indican que la hipótesis original, más
intuitiva, debe ser cuestionada. La simulación ex- Los experimentos también
sugieren estudios de campo que podrían probar hipótesis alternativas. (Este
tipo de análisis desarrolla rápidamente la creencia en la “navaja inversa de
Occam”: explicaciones simples y obvias para el comportamiento de un sistema
complejo son muy a menudo mal)

7.5 Analizando bottom up

3111/5000 Tiene poco sentido analizar el comportamiento a nivel de sistema
de IBM antes de aumentar la confianza de que el comportamiento a nivel
individual del modelo es aceptable, y no hay razón para esperar que el
comportamiento individual sea aceptable Por lo tanto, los procesos
ambientales que impulsan el comportamiento individual han sido probado
Parece evidente que los modelos ascendentes como los IBM deben ser
valiosos desapareció comenzando con los niveles inferiores donde emergen
los comportamientos a nivel del sistema de. Sin embargo, una de las razones
más comunes por las que IBM no logra desarrollar credibilidad (además de no
analizar el modelo) está intentando analizar el nivel del sistema sin probar
primero la validez del comportamiento individual. El fondo de la mayoría de los
IBM es una representación de los individuos entorno, porque el
comportamiento de los individuos depende en parte del entorno condiciones
ambientales Por lo tanto, el análisis del modelo debe comenzar con las
pruebas. y validar cómo se simula el entorno. Entonces comportamiento
individual puede ser analizado Especialmente importante es probar el
comportamiento que surge de los rasgos adaptativos clave de los individuos,
porque los más interesantes. La dinámica del sistema importante surge de
estos rasgos adaptativos; este problema es abordado utilizando el ciclo de
desarrollo de la teoría del Capítulo 4. A menudo, es muy eficaz para comenzar
a analizar rasgos individuales al contrastar el comportamiento de individuos
aislados con el comportamiento de individuos que interactúan con cada uno
otro. Un problema obvio con este enfoque de abajo hacia arriba es que el nivel
superior los procesos afectan niveles más bajos en muchos IBM: no solo la
dinámica del sistema surge del comportamiento individual, pero el
comportamiento individual se ve afectado por el sistema dinámica del tema. Si
los individuos adaptan su comportamiento de alimentación a la disponibilidad
de alimentos, y la disponibilidad de alimentos depende del consumo de todos
los individuos, entonces el comportamiento de alimentación de un individuo se
verá afectado por la densidad de población. En algunos IBM, incluso los
procesos ambientales más bajos pueden ser afectado por la forma en que los
individuos usan los recursos: la producción de alimentos puede ser una función
del consumo de alimentos por individuos, por ejemplo. Sin embargo, la
estrategia de La experimentación controlada puede superar fácilmente este
problema: podemos diseñar experimentos que aíslan el comportamiento en un
nivel lo suficientemente bien como para probarlo de manera convincente.
Estos experimentos pueden usar escenarios poco realistas (Sección 9.4.5)
como la reproducción congelada, la mortalidad y el crecimiento, por lo que el
consumo de alimentos es constante. La estrategia de análisis de abajo hacia
arriba es importante para la eficiencia, manteniéndonos de perder el tiempo
analizando los comportamientos del sistema cuando están adversamente
afectado por problemas en los niveles inferiores. Sin embargo, esta estrategia
es aún más importante para la credibilidad de IBM con los revisores y otros
“clientes” del modelo. Para evitar que los escépticos digan que “un modelo con
tantos parámetros los eters pueden calibrarse para producir los resultados que
desee”, el modelador debe mostrar que IBM fue parametrizado y probado en
todos los niveles els, usando muchos tipos de información; y que los
comportamientos del sistema surgieron de rasgos ambientales e individuales
que se analizaron de forma independiente antes de examinar los
comportamientos del sistema.

7.6 Analizando la estructura

3357/5000 9.3.3 Análisis de la estructura del modelo por separado El hecho
de que la incertidumbre ocurra tanto en la estructura del modelo como en los
parámetros ter valores es un problema bien conocido en el análisis de
modelos. ¿Cómo sabemos si una la incapacidad del modelo para producir
algún resultado esperado se debe a problemas con el ¿Ecuaciones y reglas
del modelo o con sus valores de parámetros? Clásico simple los modelos no
pueden ser probados o analizados significativamente hasta que su valor de
parámetro Los datos se ajustan a los datos, por lo que los efectos de la
incertidumbre estructural solo se pueden examinar parametrizando y
analizando estructuras de modelo alternativas (por ejemplo, Mooij y DeAngelis
2003). Sin embargo, este enfoque puede enmascarar algunos de los efectos.
de estructura modelo. Al ajustar cada modelo alternativo a los mismos datos,
los modelos alternativos se ven obligados hasta cierto punto a comportarse de
manera similar. Cómo podemos saber si el ajuste de parámetros oculta
problemas subyacentes con el modelo ¿estructura? Estos problemas a
menudo se consideran intratables; pero para IBMs La estrategia de modelado
orientado a patrones ofrece una manera de separarse al menos en parte
análisis de estructura a partir del análisis de valores de parámetros. Con IBMs
que son ricos en estructura y proceso, podemos seguir un modelo estrategia
de análisis que nos permite analizar la estructura de IBM antes del parámetro
ización, separando el análisis de incertidumbre estructural y de parámetros
para cierto punto. Esta estrategia es simplemente la que se describe en los
capítulos 3 y 4: utilice patrones observados para probar y contrastar diseños
de modelos alternativos, pero Este análisis estructural se realiza antes de que
IBM se calibre o parametrice en detalle. A medida que IBM está diseñado, los
parámetros reciben los mejores valores que se puede determinar sin calibrar
el modelo completo. Entonces la estructura de IBM La validez natural se puede
evaluar probando su capacidad para reproducir una variedad de patrones que
capturan la esencia estructural del sistema que se está modelando. Estos
patrones pueden ser cualitativos, pero las pruebas pueden ser claras y
cuantitativas. Criterios adecuados para determinar si IBM reproduce los
patrones: ¿entran las tendencias? ¿la dirección correcta? ¿Alguna respuesta
esperada sucede o no? Si algún La versión de un IBM inesperadamente no
puede reproducir algunos de los patrones de prueba, Un análisis adicional
puede determinar si la falla se debe solo a un mal elección de valores de
parámetros. La calibración y la parametrización completas pueden continuar
después de que este análisis orientado a patrones haya identificado el modelo
más válido estructura. IBM altamente mecanicistas que se han demostrado
mediante análisis orientado a patrones El análisis para ser estructuralmente
realista a menudo se puede utilizar para abordar muchos problemas con poco
o ningún ajuste detallado de parámetros. De hecho, nuestra experiencia
(incluyendo El modelo de trucha descrito en las secciones 1.2 y 6.4.2 y el
bosque de hayas. modelo descrito en las secciones 1.2 y 6.8.3) indica que si
un IBM produce comportamiento razonable: reproducción de patrones
generales y cualitativos observados en el sistema real: solo para un rango
estrecho de valores de parámetros, es probable algo mal con su estructura.
(Sin embargo, a menudo todavía usamos calibración para reproducir patrones
detallados; Sección 9.8.) La estrategia de conducir El análisis orientado a
patrones de una estructura de IBM primero puede permitirnos comprender y
reducir la incertidumbre estructural antes de abordar la incertidumbre de los
parámetros. Esta capacidad puede ser muy importante para demostrar que un
IBM es más que una caja negra que puede calibrarse para producir los
resultados deseados.

8 Verificación, Validación
Replicación
En los siete capítulos anteriores, hemos defendido la importancia y utilidad de
ABM, aprendió a ampliar el ABM existente y construir otros nuevos, tomó una
visión amplia de las componentes que entran en un entorno ABM y aprendieron
a recopilar y analizar resultados de un ABM. En este capítulo, aprenderemos
a evaluar la corrección y la utilidad. de un ABM. ¿Cómo podemos saber si
nuestro ABM implementado corresponde a nuestro conceptual ¿modelo?
¿Cómo podemos evaluar la coincidencia entre nuestro ABM y el mundo real?

8.1 Corrección de un modelo

Si un modelo es útil para responder preguntas del mundo real, es importante
que el modelo proporciona resultados que abordan los problemas relevantes
y que los resultados son precisos: El modelo debe proporcionar resultados que
sean útiles para el usuario del modelo. La precisión del modelo puede ser
evaluado a través de tres procesos de modelado diferentes: validación,
verificación y replicación La validación del modelo es el proceso de determinar
si el modelo implementado corresponde a, y explica, algún fenómeno en el
mundo real. Verificación del modelo es el proceso de determinar si un modelo
implementado corresponde al modelo conceptual objetivo. Este proceso es
equivalente a asegurarse de que el modelo ha sido corregido implementado
correctamente Por último, la replicación del modelo es la implementación por
un investigador o Grupo de investigadores de un modelo conceptual
previamente implementado por otra persona. Al garantizar que un modelo
implementado corresponde a un modelo conceptual (verificación) cuyas
salidas se reflejan en el mundo real (validación), la confianza crece en el
correcto ness y poder explicativo de los modelos conceptuales e
implementados. Además, mientras otros científicos y constructores de
modelos replican el trabajo del científico original, el científico La comunidad
específica en su conjunto llega a aceptar el modelo como correcto. Verificación
validación, y la replicación sustentan colectivamente la corrección y, por lo
tanto, la utilidad de un modelo. Sin embargo, demostrar que un conjunto
particular de resultados de un modelo corresponde a El mundo real no es
suficiente. Como se discutió en capítulos anteriores, debido al estocástica
naturaleza de los ABM, a menudo se necesitan múltiples ejecuciones para
confirmar que un modelo es exacto. Por lo tanto, las metodologías de
verificación, validación y replicación a menudo se basan en métodos de
estadística. Comenzamos nuestra discusión mirando más de cerca la
verificación.

8.2 Verificación
A medida que un modelo basado en agentes crece, se hace más difícil
simplemente mirar su código para determinar si realmente está llevando a
cabo su función prevista. El proceso de veri La notificación aborda este
problema, teniendo como objetivo la eliminación de “errores” del código. Sin
embargo, esto no es tan simple como puede parecer, y si los diseñadores e
implementadores de modelos Si hay personas diferentes, el proceso de
depuración puede volverse mucho más complejo. Una pauta general para
habilitar la verificación del modelo implica construir el modelo simplemente
para empezar, expandir la complejidad del modelo solo según sea necesario.
Por lo tanto, adherirse Según el principio de diseño básico de ABM descrito en
el capítulo 4, se obtiene un importante beneficio adicional: Si un modelo es
simple para empezar, es más fácil de verificar que un modelo complejo.
Igualmente, si las partes adicionales agregadas al modelo también son de
naturaleza incremental - construyendo hacia su pregunta de interés en lugar
de tratar de desarrollar toda la elaboración del modelo a la vez: esos
componentes también serán más fáciles de verificar (y, por extensión, el
modelo de la que forman parte) Aun así, debe tenerse en cuenta que incluso
si todos los componentes de un se verifican los modelos, el modelo en sí puede
no serlo, ya que pueden surgir complicaciones adicionales de las interacciones
entre los componentes del modelo. A lo largo de esta sección, examinamos el
tema de la verificación en el contexto de un simple ABM del comportamiento
de votación, utilizando la siguiente narrativa ficticia para guiar nuestra
discusión: Imagine que se nos acerca un grupo de politólogos que desean
desarrollar Un modelo simple de comportamiento de votación. 1 explican que
piensan que las personas son sociales Las interacciones determinan en gran
medida la votación en las elecciones. Con base en sus observaciones de
encuestas y resultados electorales, piensan que las personas tienen alguna
forma inicial en la que quieren votar, y cuando son encuestados inicialmente,
expresan esos sentimientos. Sin embargo, en el intervalo entre cuando son
encuestados y cuando realmente emiten su voto, hablan con sus vecinos y
colegas y discuten la forma en que planean votar; esto puede cambiar la forma
en que deciden votar. De hecho, esto puede suceder varias veces durante el
período previo a una elección. Los politólogos nos piden que construyamos un
ABM de este fenómeno.

8.3 Comunicación
2874/5000 A menudo, el implementador del modelo y el autor del modelo son
la misma persona, pero esto no es siempre el caso. A veces, un equipo de
personas construye un modelo, en el que una o más personas Describa el
modelo conceptual mientras que otros miembros del equipo realmente
implementan el modelo. Esto sucede con frecuencia cuando el experto en el
dominio no tiene las habilidades técnicas para crear El modelo por su cuenta.
En estas situaciones, la verificación se vuelve especialmente crítica, ya que no
un individuo tiene un conocimiento completo de todas las partes del proceso
de modelado. Cuando modelos están construidos de esta manera, la
comunicación es crítica para asegurar que el modelo implementado refleja
correctamente el modelo conceptual del experto en dominio. La mejor manera
de verificar modelos construido en este tipo de equipos es para que el experto
en el dominio (o expertos) se familiarice con las herramientas del modelo y,
asimismo, los implementadores para aprender sobre el tema del modelo
importar. Si bien uno no puede esperar que las dos partes se conviertan en
expertos en los dominios del otro, Construir este terreno común es esencial
para garantizar que las ideas se comuniquen de manera efectiva y el modelo
refleja correctamente las intenciones de los modeladores. Por ejemplo, en
nuestro modelo de votación, sería útil que los politólogos conocieran diferencia
entre los barrios de Moore y von Neumann, qué red de mundo pequeño
parecía, y las posibilidades de una cuadrícula hexagonal versus una
cuadrícula rectangular. Este conocimiento les permitiría tomar decisiones
informadas sobre cómo su modelo conceptual debería ser implementado.
Además, ayudaría si el implementador tuviera una idea básica de cómo Los
mecanismos de votación se conceptualizan dentro de la disciplina de la ciencia
política, ya que podría ayudarlos a darse cuenta de posibles simplificaciones
para el modelo o incluso potencial conceptual trampas en el modelo a medida
que se implementa. Por ejemplo, ¿es razonable suponer que solo hay dos
partes? ¿Es razonable suponer que el grupo de cada persona amigos no
cambia durante el período de tiempo modelado en la simulación? Cuando se
trata de la comunicación del modelo conceptual, a menudo hay espacio para
humanos. error y malentendido En una situación ideal, el autor del modelo y el
implementador son la misma persona, lo que evita el tipo de errores de
comunicación que pueden resultar de diferentes vocabularios ent y supuestos
diferentes. Sin embargo, el tiempo requerido para los expertos en dominios
para aprender programación de computadora, o por el contrario, el tiempo
requerido para el programa de computadora Mers para aprender un dominio
particular, puede ser sustancial. Esto fue particularmente cierto en el pasado
décadas, cuando a menudo era inviable convertirse en un implementador de
modelos experto y autor modelo. Sin embargo, los nuevos lenguajes ABM de
bajo umbral, como NetLogo, tienen un objetivo explícito de disminuir la
cantidad de tiempo necesario para aprender a escribir ABM, por lo tanto reducir
(o eliminar) la brecha entre el autor y el implementador.

8.4 Descripción de Modelos Conceptuales

A medida que comenzamos a implementar el modelo de votación, podemos
darnos cuenta de que hay algunos mecanismos y propiedades de agentes que
no entendimos completamente cuando hablamos con Los politólogos. Para
aliviar este problema, decidimos escribir un documento que describa cómo
planeamos implementar el modelo para que podamos verificar que nosotros y
la ciencia política Los expertos tienen el mismo modelo conceptual en mente.
Este documento servirá como un documento más formal. Descripción del
modelo conceptual. Una forma de describir modelos conceptuales en términos
más formales es usar un diagrama de flujo. UNA El diagrama de flujo es una
descripción gráfica del modelo que describe el flujo de decisiones que ocurrir
durante la operación de una pieza de código de software. Para el modelo
conceptual descrito arriba, podríamos usar un diagrama de flujo como el de la
figura 7.1. Los diagramas de flujo usan cuadrados redondeados para indicar
los estados de inicio y detención del sistema, cuadrados para indicar procesos
y diamantes para indicar puntos de decisión en el código. Estas Los símbolos
proporcionan una forma clara de entender cómo fluye el control a través del
software. También podemos tomar el diagrama de diagrama de flujo y
reescribirlo en pseudocódigo. El objetivo de El seudocódigo sirve como punto
intermedio entre el lenguaje natural y el programa formal. lenguaje Ming El
pseudocódigo puede ser leído por cualquier persona, independientemente de
su programación conocimiento, mientras que, al mismo tiempo, contiene una
estructura algorítmica que lo hace más fácil para implementar directamente en
código real. Por ejemplo, al describir el modelo de votación, podríamos use un
pseudocódigo como este: Los votantes tienen votos = {0, 1} Para cada votante:
Establezca el voto 0 o 1, elegido con igual probabilidad Loop hasta la elección
Para cada votante Si la mayoría de los votos de los vecinos = 1 y voto = 0,
establezca el voto 1 De lo contrario, si la mayoría de los votos de los vecinos
= 0 y voto = 1, establezca el voto 0 Si voto = 1: establece el color azul De lo
contrario: color = verde Mostrar recuento de votantes con voto = 1 Mostrar
recuento de votantes con voto = 0 Bucle final

882/5000 Además de los diagramas de flujo y el pseudocódigo, varios otros

métodos para describir modelos conceptuales merecen mención. Por ejemplo,
Booch, Rumbaugh y Jacobson idearon El lenguaje de modelado unificado
(UML). UML está diseñado para que diferentes lectores tengan diferentes
puntos de entrada a la descripción del modelo conceptual, por ejemplo,
entrada diferente puntos para usuarios de modelos versus creadores de
modelos (2005). UML usa una combinación de gráficos vistas y texto en
lenguaje natural para describir modelos. También ha habido intentos recientes
para integrar conceptos específicos de ABM en UML (Bauer, Muller y Odell,
2000). Otro El método implica elegir un lenguaje que sea lo suficientemente
similar al pseudocódigo que pueda ser claramente entendido por un no
experto. Usar un lenguaje de bajo umbral como NetLogo ayuda facilitar el
proceso de verificación porque su sintaxis de código se corresponde
estrechamente con el natural idioma.

8.5 Verification Testing

Después de diseñar el modelo conceptual con nuestros colegas de ciencias
políticas, podemos comenzar codificación. Seguimos el principio de diseño
central de ABM y comenzamos a verificar de forma simple e incremental La
alineación entre nuestro modelo conceptual y el código. Por ejemplo, podemos
escribir el procedimiento de configuración, como aquí:

patches-own [ vote ;; my vote (0 or 1) total ;; sum of votes around me] to setup

clear-all ask patches [ if (random [ set vote] ask patches [ if (random 2 = [ set
vote] ask patches [ recolor-patch] end 2 = 0) ;; half a chance of this 1 ] 0) ;; half
a chance of this 0 ] to recolor-patch ;; patch procedure ifelse vote = 0 [ set
pcolor green ] [ set pcolor blue ] end

648/5000 Luego podemos escribir una pequeña prueba que examine si el

código creó el número correcto de votantes verdes y azules. 2 En el estado
inicial del modelo de votación, el número de votantes con voto 0 debería ser
aproximadamente igual al número de votantes con voto 1. Podemos verificar
esto fácilmente al configurar nuestro modelo varias veces, comparando los
recuentos de cada voto. Si la diferencia en estas muchas configuraciones es
más de aproximadamente el 10 por ciento, por ejemplo, nuestro código podría
tener un insecto. 3 Si la diferencia es inferior al 10 por ciento del número total,
podemos sentir relativamente confiamos en que las poblaciones se generan
como pretendíamos. Este código se vería así:

to check-setup let diff abs ( count patches with [ vote = 0 ] - count patches with
[ vote = 1 ] ) if diff > .1 * count patches [ print “Warning: Difference in initial
voters is greater than 10 4 %.”] end

832/5000 Podemos insertar una llamada a CHECK-SETUP en la parte inferior

del procedimiento de CONFIGURACIÓN. Esta prueba luego se ejecutará cada
vez que el modelo ejecute SETUP y, si hay un problema, alertará Quien está
ejecutando el modelo que hay un desequilibrio de votación. Usando este
procedimiento de CONFIGURACIÓN, la advertencia aparece casi cada vez
que ejecutamos el modelo, lo que nos dice que el código no está logrando lo
que pretendíamos. Además, es visualmente Es evidente que este código crea
muchos más parches que son verdes (voto = 0) que azules (voto = 1). Debido
a que todos los errores no son aparentes visualmente, es importante escribir
pruebas de verificación Tant. (Se alienta a los lectores a examinar el código
de configuración anterior y determinar su falla). Después de descubrir el error,
podemos reescribir el procedimiento de configuración con lo siguiente (más
simple) código, que logra el equilibrio correcto de los votantes iniciales.

to setup clear-all ask patches [ set vote random 2] ask patches [ recolor-patch]
check-setup end

Esta técnica de verificación es una forma de prueba unitaria. Pruebas unitarias

(relacionadas con el componente prueba) es un enfoque que implica escribir
pequeñas pruebas que verifican si las unidades individuales funcionan
correctamente en el código (Rand & Rust, 2011). Al escribir pruebas unitarias
a medida que desarrollamos nuestro código, podemos asegurarnos de que los
cambios futuros en nuestro código no interrumpan el código anterior. Dado que
esta prueba unitaria se ejecutará cada vez que ejecutemos este modelo,
garantiza que podamos modificar el código sin temor a que nuestros cambios
alteren indetectable el código anterior. De Por supuesto, esta es solo una
prueba unitaria, y hay muchas más que podrían escribirse. Lo anterior es un
ejemplo de prueba de unidad “en modelo”, a veces llamada unidad “en línea”
prueba porque sucede mientras se ejecuta el modelo. También es posible
escribir por separado conjunto de pruebas unitarias que no forman parte del
modelo implementado, sino que están escritas para ejecutarse el modelo con
entradas particulares y compruebe si las salidas corresponden a lo esperado
resultados. Este enfoque a veces se denomina prueba de unidad “fuera de
línea”. (Una cuenta más detallada de pruebas unitarias está más allá del
alcance de este libro de texto, pero para obtener más información sobre el
software prueba, consulte Patton, 2005.) Después de estar seguros de que se
verifica el código de CONFIGURACIÓN, nosotros comenzar un proceso similar
para el procedimiento GO. Traducimos el pseudocódigo en NetLogo código de
la siguiente manera:

to go ask patches [ set total (sum [vote] of neighbors)] ;; this is equivalent to

count neighbors with [vote = 1] ;; use two ask patches blocks so all patches
compute “total” ;; before any patches change their votes ask patches [ ifelse
vote = 0 and total >= 4 [ set vote 1] [if vote = 1 and total <= 4 ] [ [set vote 0]
recolor-patch] tick end
389/5000 En este código, primero pedimos a los parches que calculen el
número total de vecinos con voto. = 1. Si el parche está votando 0 y tiene un
total mayor o igual a 4, entonces cambia a votación 1. Del mismo modo, si el
parche está votando 1 y tiene un total menor o igual a 4, cambia su voto a 0.
Después de verificar los procedimientos SETUP y GO, podemos comenzar a
investigar los resultados del modelo

8.6 Más allá de la verificación

A pesar de los mejores esfuerzos para verificar que el modelo implementado
basado en el agente corresponde a En el modelo conceptual, a veces
producirá resultados que no parecen corresponder a lo que los
implementadores y los autores plantearon. Con el tiempo, puede quedar claro
que no hay “error” en el modelo, sino que los resultados emergentes y
sorprendentes de la modelo son consecuencias no deseadas de decisiones a
nivel individual que el modelador tiene codificado.
Por ejemplo, después de codificar el modelo anterior, presentamos los
resultados a nuestra política colegas científicos (figura 7.2). Los resultados del
modelo confunden a los politólogos, porque esperaban que el modelo se
uniera con los votantes formando bloques estáticos con suavidad bordes, en
lugar de los bordes irregulares que aparecen en la figura. De hecho, este
modelo nunca alcanza el equilibrio; Continuamente recorre un conjunto de
estados. Después de un examen más detallado, queda claro que lo que está
causando el ciclo del modelo y tener bordes dentados es empatar votos. Como
lo codificamos, el modelo hace que los votantes cambien su voto si el recuento
de votos de sus vecinos está vinculado. Por lo tanto, los votantes al borde de
la concentración Los bloques siguen yendo y viniendo entre los dos votos.
Podemos cambiar el modelo para que los votantes no cambien su voto si los
votos de sus vecinos están empatados. Después de hacer esto cambiar, los
bloques se unen con bordes lisos (figura 7.3). Sin embargo, como lo político
los científicos se han interesado en cómo un cambio aparentemente pequeño
crea una gran diferencia En el resultado, deciden hacer de este un elemento
del modelo que puedan controlar agregando un interruptor, llamado CAMBIAR-
VOTAR-SI-TIED? Tener esta opción como elemento controlable nos permite
explorar nuevos comportamientos de votación. Por ejemplo, ¿qué pasaría si
los votantes decidieran ponerse del lado del partido minoritario en su ¿barrio?
Es decir, imagine una comunidad donde, cuando los vecinos de un miembro
están divididos estrechamente entre dos candidatos, el miembro decide votar
por el desvalido (quienquiera que la mayoría de sus vecinos no voten), ya que
el miembro podría ser capaz de asegurar la victoria del desvalido. Tenga en
cuenta que esta perversidad hipotética de los agentes puede No refleja las
prácticas de votación del mundo real. Sin embargo, esta es una cuestión de
validación del modelo. (que discutiremos más adelante), en lugar de la
verificación. A continuación se muestra el código para el programa go cedure
con las dos opciones agregadas:
to go ask patches [ set total (sum [vote] of neighbors) ] ;; use two ask patches
blocks so all patches compute “total” ;; before any patches change their votes
ask patches [ if total > 5 [ set vote 1 ] if total < 3 [ set vote 0 ] if total = 4 [ if
change-vote-if-tied? [ set vote (1 - vote) ] ] ;; switch vote if total = 5 [ ifelse
award-close-calls-to-loser? [ set vote 0 ] [ set vote 1 ] ] if total = 3 [ ifelse award-
close-calls-to-loser? [ set vote 1 ] [ set vote 0 ] ] recolor-patch ] tick end

1655/5000 La oportunidad de explorar situaciones hipotéticas intrigantes es

uno de los puntos fuertes de modelado basado en agentes. Cuando la opción
“votar por los desvalidos” está activada, que es controlado por nuestro
PREMIO-CIERRE-LLAMADAS-A-PERDEDOR? interruptor, otro emergente
resultado del patrón (figura 7.4). En este caso, bloques de azules y verdes se
unen mientras son irregulares Los límites entre las zonas se desvían y
distorsionan gradualmente a medida que pasa el tiempo. Si decidimos activar
tanto el “CAMBIAR-VOTAR-SI-TIED?”Y el" PREMIO- ¿LLAMADAS
CERCANAS AL PERDEDOR? “Opción, obtenemos un resultado diferente.
Esta última opción (figura 7.5) da como resultado un patrón de colores
aparentemente aleatorio, sin grandes bloques sólidos De cualquier color. Este
ejemplo ilustra que, al examinar los resultados del modelo, puede ser difícil
descifrar si el resultado de un modelo es el resultado de errores en el código,
una falta de comunicación entre el autor del modelo y el implementador, o un
resultado “correcto" pero no anticipado del Reglas de agente. Por lo tanto, es
vital que el implementador del modelo y el autor del modelo discutan ambos
modelar reglas y resultados con la mayor frecuencia y regularidad posible, y
no simplemente cuando finalice izing el modelo. Saltarse este proceso de
comunicación puede resultar en el modelo implementador creando un modelo
con comportamiento de agente que el autor del modelo no tenía la intención.
Sin embargo, al mantener estas comunicaciones, el autor del modelo puede
descubrir que Las variantes en su modelo conceptual resultan en resultados
dramáticamente diferentes. Incluso si la misma persona es autor e
implementador del modelo, es útil revisar las reglas del modelo y resultados
de forma iterativa y discutirlos con personas que están familiarizadas con el
fenómeno modelado
8.7 análisis de sensibilidad y robustez
2011/5000 Después de que hayamos terminado de construir un modelo y
encontrado algunos resultados interesantes, es importante explorar estos
resultados para determinar qué tan sensible es nuestro modelo al conjunto
particular de condiciones iniciales que estamos usando. A veces, esto solo
significa variar un grupo de parámetros que ya tenemos dentro de nuestro
modelo, pero otras veces, esto implica agregar nuevos parámetros al modelo.
Este proceso, llamado análisis de sensibilidad, crea una comprensión. de cuán
sensible (o robusto) es el modelo a varias condiciones. Un tipo de análisis de
sensibilidad implica alterar los valores de entrada del modelo. Por ejemplo, uno
de los politólogos está preocupado por las condiciones iniciales del modelo,
piensa Ing. que el comportamiento actual del modelo puede depender
inicialmente de tener un equilibrio Número de votantes para cada partido
(color). Ella se pregunta si inclinar el saldo inicial en una dirección u otra daría
como resultado que un color domine el paisaje. Probar Con esta hipótesis,
creamos un parámetro (un control deslizante en la interfaz del modelo) que
controla El porcentaje de agentes verdes en el estado inicial del modelo.
Usando BehaviorSpace (como discutido en el capítulo 6), luego ejecutamos un
conjunto de experimentos donde variamos este porcentaje del 25 por ciento al
75 por ciento en incrementos del 5 por ciento. Al establecer la condición de
parada para En este experimento, debemos tener en cuenta que es posible
tener patrones oscilantes interminables. Por esta razón, decidimos establecer
dos condiciones de parada diferentes: (1) el modelo detenerse si ningún
votante cambió de votos en el último paso de tiempo, y (2) el modelo se
detendrá después de uno se han ejecutado cien pasos de tiempo, ya que
parece ser tiempo suficiente para llegar a una final estado del modelo. Esta
investigación significará que tenemos que reevaluar nuestro componente
prueba (configuración de verificación creada durante el proceso de verificación
inicial, ya que ahora estamos alterando completamente la distribución inicial.
Por lo tanto, podemos alterar este código para que tome en cuenta el nuevo
parámetro:

to check-setup let expected-green (count patches * initial-green-pct / 100) let

diff-green (count patches with [ vote = 0 ] ) - expected-green if diff-green > (.1
* expected-green) [ print “Initial number of green voters is more than
expected.”] if diff-green < (- .1 * expected-green) [ print “Initial number of green
voters is less than expected.”] end

2035/5000 Podemos examinar la relación entre la distribución inicial de

votantes y el recuento final de votos por ejecutando diez ejecuciones para cada
porcentaje inicial. La medida más simple del dominio de cada partido político
debe contar el porcentaje de votantes finales que son verdes o azules.
Después de ejecutar nuestro experimento BehaviorSpace, podemos trazar los
resultados del porcentaje final edad contra el porcentaje de entrada,
obteniendo el gráfico en la figura 7.6. Estos resultados muestran que, a medida
que nos alejamos de una distribución inicial de votantes medio azules y
votantes medio verdes, hay un efecto no lineal en la distribución final de los
votantes. El modelo es sensible a estos parámetros, y por lo tanto, un ligero
cambio en el número de inicial los votantes de un partido dan como resultado
un mayor número de votantes finales para ese mismo partido. Sin embargo,
La definición de “sensibilidad” depende de los resultados del modelo que esté
considerando. Por ejemplo, la sensibilidad en los resultados cuantitativos no
significa necesariamente que habrá sensibilidad en los resultados cualitativos.
Si el resultado de su modelo principal es el hallazgo cualitativo que se forman
islas sólidas de votantes de ambos colores, dejando la segregación, entonces
esta cualitativa el resultado sigue siendo cierto incluso si perturba la
distribución inicial de los votantes en un 10 por ciento en cualquier dirección.
Cuando están perturbadas, las islas de un color u otro pueden ser mucho más
pequeño, pero aún habrá bloques sólidos. Por lo tanto, para esta medida
cualitativa, podría Concluimos que este modelo es insensible a pequeños
cambios en el balance inicial de votantes. El análisis de sensibilidad es un
examen del impacto de diferentes parámetros del modelo en Resultados del
modelo. Para determinar qué tan sensible es un modelo, examinamos el efecto
que diferentes Las condiciones iniciales y los mecanismos del agente tienen
en los resultados del modelo. Además, podemos examinar el entorno en el que
opera el modelo. Por ejemplo, en el modelo de votación, estamos usando una
cuadrícula toro bidimensional, pero estos resultados podrían cambiar
drásticamente si los votantes se ubicaron en una cuadrícula hexadecimal, una
red o alguna otra topología.

1056/5000 También se han realizado investigaciones anteriores sobre

metodologías para automatizar el proceso de envío. análisis de sitividad.
BehaviorSpace de NetLogo facilita el proceso de análisis de sensibilidad al
facilitar el barrido de un gran conjunto de parámetros y examinar los
resultados. Molinero (1998) desarrollaron una metodología llamada Prueba no
lineal activa (ANT), que toma un conjunto de parámetros, un modelo y un
criterio como sus entradas. El criterio es el aspecto de la modelo que nos
gustaría probar, como la cantidad de votantes verdes al final de la carrera. ANT
luego usa una técnica de optimización, como algoritmos genéticos, para
encontrar un conjunto de parámetros que maximizan este criterio. Presenta al
usuario un conjunto de parámetros que mejor “romper” el modelo de acuerdo
con algunos criterios. Stonedahl y Wilensky (2010b, 2010c) han desarrollado
técnicas y una herramienta, llamada BehaviorSearch, 6 para automatizar
parámetros exploración y análisis mediante la búsqueda de comportamientos
del modelo objetivo. BehaviorSearch puede ser muy útil cuando el espacio de
parámetros es demasiado grande para buscar exhaustivamente.

8.8 Beneficios de la verificación

2924/5000 Existen muchos beneficios al realizar análisis de verificación, que
incluyen el desarrollo de un comprensión de la causa de resultados
inesperados y exploración del impacto de los pequeños cambios en las reglas
El nivel básico de verificación es que el implementador del modelo compare la
descripción conceptual del modelo con el código implementado para
determinar si El modelo implementado corresponde al modelo conceptual.
Cuanto más riguroso sea el modelo proceso de verificación, es más probable
que el modelo implementado resultante corrija responder al modelo
conceptual. Si los dos modelos corresponden exactamente, entonces el
modelo los autores entienden las reglas de bajo nivel del modelo. Esto significa
que entienden cómo El modelo genera sus resultados. Aun así, comprender
los componentes de bajo nivel del modelo no garantiza una comprensión de
todas las interacciones de estos componentes o de por qué el modelo genera
los resultados agregados que hace. La verificación es importante porque
ayuda a garantizar que el autor (o autores) entiendan los mecanismos que
subyacen fenómeno que se está explorando. Sin pasar por este proceso, los
autores no pueden ser confía en las conclusiones extraídas del modelo. La
verificación puede ser difícil de lograr porque es difícil determinar si Un
resultado sorprendente es el producto de un error en el código, una falta de
comunicación entre el autor e implementador del modelo, o un resultado
inesperado de una regla de bajo nivel. Pelaje- además, aún puede ser difícil
aislar y eliminar un error, o corregir el error. Incluso si estamos seguros de que
el resultado es una consecuencia inesperada pero precisa, Puede ser difícil
descubrir qué causó que los resultados fueran diferentes de lo que esperado.
El proceso de comprender cómo funciona un modelo también puede
ayudarnos a comprender el Pregunta de “por qué”. Por ejemplo, en el modelo
anterior, como examinan los politólogos En el modelo, comienzan a
comprender la razón por la que el segundo modelo se une en bloques. Al
pensar en las reglas del modelo desde el punto de vista del agente, queda
claro que una vez que se forma un bloque de individuos permanecerá
constante, mientras que si la mayoría de los vecinos del agente votan de una
manera y ninguno de ellos está cambiando, entonces el agente lo hará seguir
votando de la misma manera. Por lo tanto, una vez que todos los agentes
hayan alcanzado la mayoría consenso de sus vecinos, se quedarán así para
siempre. Es solo cuando damos agentes la capacidad de cambiar colores
según los recuentos que los rodean, como en las otras dos reglas, que vemos
un cambio perpetuo en los resultados. El proceso de verificación no es binario.
Un modelo no está verificado o no verificado, pero más bien existe a lo largo
de un continuo de verificación. Siempre es posible escribir más pruebas de
ponente o para realizar más análisis de sensibilidad. Por lo tanto, depende del
autor del modelo implementador (y más tarde un replicador de modelos) para
decidir cuándo la verificación

8.9 Validación
1699/5000 La validación es el proceso de asegurar que haya una
correspondencia entre modelo implementado y realidad. La validación, por su
naturaleza, es compleja, multinivel y relativa. Los modelos son simplificaciones
de la realidad; Es imposible que un modelo exhiba todos los mismas
características y patrones que existen en la realidad. Al crear un modelo,
queremos incorporar los aspectos de la realidad que sean pertinentes a
nuestras preguntas. Así, cuando se emprende Al realizar el proceso de
validación, es importante tener en cuenta las preguntas del modelo conceptual.
y validar aspectos del modelo que se relacionan con estas preguntas. Hay dos
ejes diferentes para considerar los problemas de validación (Rand & Rust,
2011). El primer eje es el nivel en el que se produce el proceso de validación.
Microvalida- es asegurarse de que los comportamientos y mecanismos
codificados en los agentes del modelo coincidir con sus análogos del mundo
real. La macrovalidación es el proceso de asegurar que las propiedades
agregadas y emergentes del modelo corresponden a las propiedades
agregadas en el mundo real. El segundo eje de validación es el nivel de detalle
del proceso de validación. La validación facial es el proceso de mostrar que
los mecanismos y propiedades del modelo parecen mecanismos y
propiedades del mundo real. La validación empírica asegura que el modelo
genera datos que pueden demostrarse que corresponden a patrones similares
de datos en el mundo real. Para ayudar a ilustrar el proceso de validación de
un ABM, utilizaremos el modelo Flocking de la sección de Biología de la
biblioteca de modelos NetLogo. Este modelo intenta recrear patrones de aves
que acuden como existen en la naturaleza (ver figura 7.7). El modelo de
flocado es

1195/5000 Un modelo clásico basado en agentes basado en los modelos

originales de Boids de Reynolds (1987). El modelo demuestra que pueden
surgir bandadas de pájaros sin ser guiados de ninguna manera por Aves
líderes especiales. Por el contrario, cada ave sigue exactamente el mismo
conjunto de reglas, desde qué bandadas emergen. Cada ave sigue tres reglas:
“alineación”, “separación” y “coherencia” Sion. "" Alineación “significa que un
pájaro gira para que se mueva en la misma dirección que cerca aves.
“Separación" significa que un pájaro gira para evitar golpear a otro pájaro.
“Cohesión” significa un pájaro se mueve hacia otras aves cercanas. La regla
de “separación” anula las otras dos, lo que significa que si dos pájaros se
acercan, siempre se separarán. En esto caso, las otras dos reglas se
desactivan hasta que se logra la separación mínima. las tres reglas afectan
solo el rumbo del ave. Cada ave siempre avanza al mismo tiempo velocidad
constante. Las reglas son notablemente robustas y se pueden adaptar al
enjambre de insectos, escolarización de peces y patrones de flocado, como la
“V” de gansos (Stonedahl y Wilensky, 2010a). Describamos brevemente la
implementación de estas tres reglas. La regla de alineación es codificada de
la siguiente manera

to align ;; turtle procedure turn-towards average-flockmate-heading max-align-

turn end

372/5000 Este código le dice al pájaro que gire hacia el rumbo promedio de
sus compañeros de manada, pero no más que el control deslizante MAX-
ALIGN-TURN, que especifica el ángulo máximo que puede girar un pájaro con
el fin de alinearse con sus compañeros de rebaño. Este código requiere dos
procedimientos auxiliares: uno para encontrar los compañeros de bandada de
un pájaro y otro para encontrar su rumbo promedio. El primero es sencillo:

to find-flockmates ;; turtle procedure set flockmates other turtles in-radius

vision end

8.10 Replicación
3044/5000 Uno de los componentes fundamentales del método científico es la
idea de replicación. (Latour y Woolgar, 1979). Desde este punto de vista, para
que un experimento sea considerado aceptable por la comunidad científica,
los científicos que originalmente realizaron el experimento debe publicar los
detalles de cómo se realizó el experimento. Esta La descripción de puede
ayudar a los equipos de científicos posteriores a realizar el experimento ellos
mismos para determinar si sus resultados son lo suficientemente similares
como para confirmar los resultados originales. Esta el proceso confirma el
hecho de que el experimento no dependía de ninguna condición local, mientras
que la descripción escrita del experimento es lo suficientemente satisfactoria
como para registrar el conocimiento ventaja obtenida en el registro
permanente. La replicación es una parte importante del proceso científico y es
tan importante dentro el ámbito de los modelos computacionales como lo es
dentro del ámbito de los experimentos físicos. Reps- La reproducción de un
experimento físico ayuda a demostrar que los resultados originales no se
deben a errores o descuidos en la ejecución probando y comparando tanto la
configuración experimental como resultados posteriores. La replicación de un
modelo computacional sirve para este mismo propósito. Adicionalmente,
replicar un modelo computacional aumenta nuestra confianza en la verificación
del modelo ya que Una nueva implementación del modelo conceptual ha
arrojado los mismos resultados que el original. La replicación también puede
ayudar en la validación del modelo, ya que requiere que los replicadores del
modelo intenten entender las elecciones de modelado que se hicieron y cómo
los modeladores originales vieron la coincidencia entre el modelo conceptual
y el mundo real. Wilensky y Rand (2007) 7 dan Una descripción detallada de
la replicación de un modelo basado en agentes utilizando el modelo de
etnocentrismo de Axelrod y Hammond (2002, 2006; ver figura 7.11). En este
modelo, los agentes compiten por espacio limitado a través de interacciones
de tipo Dilema de prisioneros. Los agentes tienen uno de cuatro posibles etnias
y cada agente tiene una estrategia que incluye si coopera o si falla con agentes
de su propia etnia y con otras etnias. Los agentes “etnocéntricos” tratan a los
agentes dentro de su grupo más beneficiosamente que aquellos fuera de su
grupo. El modelo incluye un mecanismo de herencia (genético o cultural) de
estrategias. El modelo sugiere que El comportamiento “etnocéntrico” puede
evolucionar bajo una amplia variedad de condiciones, incluso cuando hay no
son “etnocéntricos” nativos y no hay forma de que los agentes sepan de
antemano si otro agente Cooperará con ellos. En el proceso de intentar la
replicación, se descubrieron diferencias entre los Modelo Wilensky-Rand y el
modelo Axelrod-Hammond; el modelo replicado tenía que ser modificado para
producir los resultados originales. El esfuerzo de replicación finalmente tuvo
éxito pero el proceso que se requirió para determinar que la replicación fue
exitosa fue problemas imprevistos complicados e involucrados. Wilensky y
Rand describieron la consideración acciones que deben examinarse
cuidadosamente y extraer algunos principios para ambos modelos
replicadores y autores de modelos. Revisaremos los de este documento.

4993/5000 Límite de caracteres: 5000 La replicación es la implementación por

un científico o grupo de científicos de un concepto modelo (modelo replicado)
descrito y ya implementado (modelo original) por una ciencia o grupo de
científicos en un momento anterior. La implementación del modelo replicado
debe diferir de alguna manera del modelo original y también debe ser
ejecutable (en lugar de otro modelo conceptual formal). Dado que la replicación
se refiere a la creación de una nueva implementación de un modelo conceptual
basado en los resultados previos de una implementación. Los términos modelo
original y modelo replicado siempre se refieren a modelos implementados. Un
modelo original y un modelo replicado asociado pueden diferir en al menos
seis dimensiones: (1) tiempo, (2) hardware, (3) idiomas, (4) juegos de
herramientas, (5) algoritmos y (6) autores. Esta lista está ordenada según la
probabilidad de que el esfuerzo de replicación produzca Resultados diferentes
del modelo original. Por lo general, más de una de estas dimensiones son
variado en el curso de un modelo único de replicación. Tiempo Un modelo
puede ser replicado por el mismo individuo en el mismo hardware y en el
mismo kit de herramientas y entorno de lenguaje pero reescrito en un momento
diferente. Este cambio en es menos probable que la dimensión produzca
resultados significativamente diferentes pero, si lo hiciera, lo haría indicar que
la especificación publicada es inadecuada, ya que incluso el investigador
original no se pudo volver a crear el modelo a partir del modelo conceptual
original. Este es la única dimensión de replicación que siempre será variada.
Hardware El modelo puede ser replicado por el mismo individuo pero en
diferente hardware mercancía. Como mínimo, por un cambio en el hardware
queremos decir que el modelo implementado fue correr en una máquina
diferente. Los cambios de hardware también se pueden obtener replicando el
modelo en una plataforma de hardware diferente. Independientemente, dada
la prevalencia de hardware idiomas independientes, ninguno de estos cambios
debe proporcionar significativamente diferentes resultados. Sin embargo, si los
resultados son diferentes, las investigaciones (a menudo técnicas) están
justificadas y podría, por ejemplo, señalar que el modelo es susceptible a
pequeños cambios en el orden de ejecución de comportamiento. Idiomas El
modelo podría replicarse en un lenguaje de computadora diferente. Por un
lenguaje informático, nos referimos al lenguaje de programación que se utilizó
para codificar la instrucción iones en el modelo implementado. Java, Fortran,
Objective-C y NetLogo son ejemplos de diferentes idiomas A menudo, la
sintaxis y la semántica de un lenguaje (p. Ej., Procesal versus lenguajes
funcionales) tienen un efecto significativo en cómo el investigador traduce el
modelo conceptual en una implementación real. Por lo tanto, la replicación en
un nuevo idioma puede Destacar las diferencias entre el modelo conceptual y
la implementación. Incluso apareciendo detalles menores en lenguaje y
especificaciones algorítmicas, como los detalles de flotante la aritmética
puntual o las diferencias entre implementaciones de protocolos, pueden
causar diferencias en modelos replicados (Izquierdo y Polhill, 2006; Polhill e
Izquierdo, 2005; Polhill, Izquierdo y Gotts, 2005, 2006). Para que un modelo
sea ampliamente aceptado como parte de la investigación científica
conocimiento, debe ser robusto a tales cambios. Juegos de herramientas El
modelo podría replicarse en un juego de herramientas de modelado diferente
basado en el mismo lenguaje de ordenador. Un juego de herramientas, en este
sentido, es una biblioteca de software o un conjunto de bibliotecas escritas en
un idioma particular con el propósito de ayudar al desarrollo de un modelo. Por
ejemplo, Repast (Collier, Howe y North, 2003), Ascape (Parker 2000) y
MASON (Luke et al., 2004) son kits de herramientas claramente diferentes
para construir ABM, aunque todos están escritos en Java. NetLogo es un
ejemplo interesante porque, si bien el software de NetLogo está escrito en una
combinación de Java y Scala, los modeladores usan otro lenguaje (también
referido como NetLogo) para desarrollar modelos. Por lo tanto, clasificamos
NetLogo como un kit de herramientas y un idioma. Con muchos kits de
herramientas de modelado diferentes disponibles para su uso, los resultados
de la replicación Inventar un modelo en un conjunto de herramientas diferente
a menudo puede iluminar problemas no solo con lo conceptual modelo, pero
también, con los propios kits de herramientas. Algoritmos El modelo podría
replicarse usando diferentes algoritmos. Por ejemplo, hay muchas formas de
implementar algoritmos de búsqueda (por ejemplo, primero en amplitud,
primero en profundidad) o actualizar una gran cantidad de objetos (por
ejemplo, en orden de creación de objetos, en un orden aleatorio elegido en el
comienzo de la carrera, en un orden aleatorio cada vez). De hecho, un modelo
replicado puede simplemente realice los pasos de un modelo en un orden
diferente al del modelo original. Todas estas diferencias pueden
potencialmente crear disparidades en los resultados. Por otra parte, También
es posible que la descripción algorítmica difiera, pero que los resultados no lo
hagan. Esta podría suceder porque dos individuos describen el mismo
algoritmo de manera diferente, o que las diferencias algorítmicas no afectan
los resultados. Autores Los individuos, aparte del investigador original, pueden
replicar el modelo.

4425/5000 Autores Los individuos, aparte del investigador original, pueden

replicar el modelo. Esto es una prueba sólida de la replicabilidad de un modelo.
Si otro investigador puede tomar una descripción formal del modelo y recrearlo
para producir los mismos resultados, tenemos evidencia razonable de que el
modelo se describe con precisión y los resultados son robustos a los cambios
en las dimensiones de replicación que han sido alteradas. Una replicación
exitosa es aquella en la que los replicadores pueden establecer que El modelo
replicado crea salidas suficientemente similares a las salidas del original. Esta
no significa necesariamente que los dos modelos tengan que generar
exactamente los mismos resultados. Muchas veces es más importante que
cambios similares generen efectos similares, pero disuadir la minería del
estándar para el éxito queda en manos del investigador que realiza la
replicación. El criterio por el cual se juzga el éxito de la replicación se llama
estándar de replicación (RS) Existen diferentes estándares de replicación para
el nivel de similitud entre los resultados del modelo. Axtell y col. (1996)
examinaron esta cuestión de estándares. Desarrollaron tres categorías. de
estándares de replicación para un experimento de replicación. La primera
categoría de replicación. estándares, “identidad numérica”, es difícil de
establecer, ya que implica mostrar que el origen Los modelos finales y
replicados producen exactamente los mismos resultados numéricos. Una
forma de minimizar El riesgo de fracaso de la identidad numérica es mediante
el uso de semillas aleatorias especificadas. 8 El segundo La categoría de los
estándares de replicación es “equivalencia distributiva”. “Aquí, el objetivo es
mostrar que los dos modelos implementados son suficientemente similares
entre sí según las estadísticas medidas de cal. Para cumplir con este criterio,
los investigadores de RS a menudo intentan mostrar indistintos estadísticos,
es decir, que dados los datos actuales, no hay pruebas de que los modelos no
sean distribucionalmente equivalente (Axtell et al., 1996; Edmonds y Hales,
2003). 9 La categoría final de los estándares de replicación es la “alineación
relacional”. Existe alineación relacional si los resultados de los dos modelos
implementados muestran relaciones cualitativamente similares entre variables
de entrada y salida. Por ejemplo, si aumenta la variable de entrada x en ambos
modelos, la variable de salida y debería responder de la misma manera tanto
en el primer modelo como en el segundo modelo. Después de decidir la
categoría de RS para un esfuerzo de replicación, es importante definir los
detalles del RS particular que pretendes seguir más concretamente ya que hay
muchos estándares de replicación más específicos que podrían definirse. Los
ABM generalmente producen grandes cantidades de datos, muchos de los
cuales generalmente son irrelevantes para el objetivo de modelado real. Solo
los datos que son centrales para el modelo conceptual deben medirse y
probarse durante replicación. Por ejemplo, la replicación de salidas como
coordenadas x e y para cada agente con el tiempo, o la generación de números
aleatorios particulares, puede ignorarse durante el proceso de replicación si
no son parte integral del fenómeno que se está modelando. Por lo general, uno
debe elegir las funciones apropiadas en un subconjunto de las variables de
salida para que sean las medidas para replicación Una vez que se han elegido
las medidas particulares, también es necesario elegir cómo a menudo se
compararán los resultados. Un RS específico es simplemente hacer coincidir
un conjunto particular de salidas al final de la ejecución. Otra RS más detallada
sería hacer coincidir un conjunto de valores en varios puntos intermedios a lo
largo de la carrera. Alternativamente, uno podría Intente hacer coincidir todas
las salidas a lo largo de la ejecución para demostrar la equivalencia en la
evolución de las salidas a lo largo del tiempo. Este último RS está quizás más
en el espíritu ABM en que se preocupa menos por el equilibrio y más por la
dinámica a lo largo del tiempo. Como Epstein afirma en su artículo seminal de
1999: “Si no lo cultivaste, no explicaste su emergencia. En otras palabras, para
comprender completamente un fenómeno, es importante modelar el proceso
que lo crea en lugar de simplemente ajustar una curva a algunos de los
números que caracterízalo Tenga en cuenta que las medidas mismas también
deben reproducirse en el modelo replicado. En Para evitar un retroceso infinito
de repeticiones, los replicadores de modelos a menudo proceden con la
suposición de que una determinación de la replicación exitosa de las medidas
puede ser logrado al comparar las medidas replicadas con su descripción
conceptual (es decir, “verificación” de las medidas).