El gestor de arranque del conocimiento
El alienígena y la manzana
Imagina que un alienígena llega a la Tierra sin ningún conocimiento de nuestro mundo.
Se encuentra con algo.
Al principio no lo llama manzana. Ni siquiera sabe que es un objeto.
Simplemente observa un cambio.
Hay una configuración de información sensorial. Cambia cuando el alienígena interactúa con ella. El alienígena registra la diferencia.
Prueba la misma interacción otra vez.
El resultado es parecido.
Prueba algo distinto. El resultado cambia.
Ya tiene el comienzo de un patrón.
Puede empezar a hacer predicciones:
Si repito esta acción en condiciones similares, debería ocurrir algo similar.
Entonces intenta romper esa predicción.
Cambia las condiciones. Repite el experimento. Busca excepciones.
Con el tiempo, puede notar que ciertos patrones se repiten juntos. Algunas cosas aparecen de forma constante junto a otras. Algunos cambios persisten. Otros desaparecen. Algunas transformaciones se pueden reproducir.
Solo después de suficientes observaciones empieza a ponerles nombre a esas regularidades y a construir abstracciones a su alrededor.
Con el tiempo podría descubrir lo que nosotros llamamos una manzana. Más tarde, podría descubrir que las manzanas vienen de los árboles. Más tarde aún, podría descubrir que los árboles forman parte de un sistema biológico más grande.
Pero ninguno de esos conceptos se le da de antemano.
Primero viene el mundo. Los conceptos vienen después.
Esa es la idea detrás del gestor de arranque del conocimiento.
Un gestor de arranque es el pequeño programa que se ejecuta primero, antes de que exista el resto de un sistema operativo, y prepara el sistema para que todo lo demás pueda funcionar. El nombre encaja porque este proceso cumple un papel parecido para el conocimiento: le da a un sistema una manera de empezar con muy poco, construir afirmaciones fiables sobre el mundo y levantar poco a poco una comprensión más compleja, sin dar por supuestas las conclusiones que intenta descubrir.
El gestor de arranque del conocimiento
El gestor de arranque del conocimiento es un proceso para convertir observaciones en afirmaciones fiables.
La idea básica es simple: cualquier afirmación sobre el mundo tiene que pasar por un proceso antes de que el sistema deba confiar en ella.
Es, en esencia, el método científico formalizado a partir de mi experiencia construyendo sistemas.
El proceso es:
Cambiar → Comparar → Formular hipótesis → Predecir → Falsar → Verificar de forma independiente → Generalizar → Abstraer → Aislar e intervenir → Componer → Calibrar → Elegir el siguiente objetivo
No es necesariamente lineal. Es un bucle. Una predicción fallida puede devolverte a la hipótesis. Una calibración fallida puede dejar al descubierto un problema varios pasos atrás. Un error en un cimiento puede devolverte al sistema de tipos.
Lo importante es que las afirmaciones se ganan su lugar en el sistema a través de este proceso.
El resto de este artículo sigue ese proceso.
1. Cambiar: empezar por lo que realmente ocurre
El alienígena empieza por el cambio.
No empieza por un objeto, una categoría o una explicación. Algo es distinto de lo que era antes.
Esta es la primera etapa del gestor de arranque porque no hay nada que explicar hasta que algo ocurre.
Hay una configuración de información sensorial. Cambia cuando el alienígena interactúa con ella. El alienígena registra la diferencia.
El sistema todavía no sabe qué causó el cambio.
Solo sabe que hubo uno.
El sistema todavía no sabe qué causó el cambio.
Solo sabe que hubo uno.
Por ejemplo, imagina que el alienígena suelta un objeto pequeño. El objeto se mueve respecto al alienígena. Lo suelta de nuevo, y el objeto se mueve otra vez. En este punto, el alienígena no sabe qué es «caer», ni siquiera que hay una fuerza actuando sobre el objeto. Solo sabe que el estado del mundo cambió después de soltarlo.
Esa distinción es importante. El gestor de arranque empieza por la observación, no por la interpretación.
2. Comparar: convertir el cambio en un patrón
Cuando hay un cambio, el siguiente paso es compararlo con lo que había antes y con lo que ocurre cuando se repite la interacción.
El alienígena prueba la misma interacción otra vez.
El resultado es parecido.
Prueba algo distinto.
El resultado cambia.
Ahora hay algo más útil que una sola observación. Hay una relación entre acciones y resultados que se puede comparar entre observaciones.
El alienígena suelta objetos de distintas formas y tamaños. Los suelta desde distintas posiciones. Los objetos siguen moviéndose hacia la misma región del espacio. El alienígena sigue sin saber por qué. Simplemente ha descubierto que los cambios están relacionados de una manera repetible.
Aquí es donde el gestor de arranque empieza a pasar del cambio en bruto hacia el conocimiento.
Comparar todavía no explica la diferencia.
Establece que existe una diferencia y le da al sistema algo que se puede investigar.
3. Formular hipótesis: proponer una explicación
Cuando el sistema empieza a ver patrones, puede proponer una hipótesis.
El alienígena podría llegar a algo como:
Si repito esta acción en condiciones similares, debería ocurrir algo similar.
En este punto, el sistema tiene una explicación que investigar.
Pero todavía no tiene conocimiento.
Una hipótesis es una propuesta. El gestor de arranque mantiene a propósito esa distinción, porque aceptar una hipótesis demasiado pronto convertiría una suposición en un cimiento.
Ahora el alienígena podría proponer: «Los objetos soltados en estas condiciones tienden a moverse hacia esta región». No llama a esa región «abajo» y no llama al fenómeno «gravedad». Esos conceptos todavía no se han establecido. La hipótesis solo describe el patrón que ha observado.
La siguiente etapa existe para hacer que la hipótesis se pueda poner a prueba.
4. Predecir: hacer la hipótesis vulnerable a la realidad
Una hipótesis se vuelve útil cuando produce una predicción.
Si el sistema cree que una acción concreta produce un resultado concreto en ciertas condiciones, debería poder decir qué espera que ocurra cuando esas condiciones se den otra vez.
El alienígena predice que si suelta otro objeto desde el mismo lugar, el objeto debería moverse hacia la misma región. Después predice que soltarlo desde un lugar más alto debería seguir produciendo movimiento hacia esa región.
Ahora la afirmación puede encontrarse con la realidad.
Es una transición importante en el gestor de arranque.
El sistema ha pasado de:
«Creo que esto podría ser verdad».
a:
«Si esto es verdad, debería observar esto».
Eso le da al sistema algo que puede intentar romper.
5. Falsar: intentar romper la afirmación
La siguiente etapa es la falsación.
En lugar de preguntarse solo cómo confirmar la hipótesis, el sistema cambia las condiciones. Repite el experimento. Busca excepciones.
Intenta romper su propia predicción.
El alienígena suelta objetos desde distintos lugares. Usa objetos diferentes. Los suelta a distintas alturas. Cambia las condiciones del entorno. Busca un objeto que no se comporte como se predijo. Si lo encuentra, la hipótesis tiene que cambiar. Si no, la hipótesis ha sobrevivido a otro intento de romperla.
Aquí es donde las pruebas pasan a formar parte del gestor de arranque.
Una prueba es, en esencia, un intento de falsación. Hace una afirmación sobre lo que el sistema debería hacer y luego trata de encontrar una situación en la que esa afirmación falle.
Por eso las partes genéricas del sistema deberían tener pruebas genéricas.
Prueba los átomos.
Prueba los tipos.
Prueba la mecánica de las máquinas de estados.
Prueba las reglas que deberían seguir cumpliéndose sea cual sea el dominio que se construya encima.
Esas pruebas pueden mantenerse estables mientras el dominio cambia.
Las pruebas de extremo a extremo cumplen otro propósito.
Prueban el sistema compuesto en el punto donde se encuentran todas las piezas. Una prueba de Playwright, por ejemplo, puede tomar una afirmación que parece correcta de forma aislada e intentar falsarla a través de la aplicación real.
Esto importa porque algunos fallos solo aparecen después de la composición.
Los componentes genéricos pueden ser correctos cada uno por separado y su combinación no serlo.
Si cada dominio tiene su propia colección de pruebas atadas de cerca a su implementación, esas pruebas se vuelven caras de mantener. Los dominios cambian. Las pruebas cambian con ellos. Al final, el conjunto de pruebas se convierte en una fuente de deuda técnica.
Probar el sustrato genérico funciona de otra manera.
Las pruebas pueden mantenerse estables mientras el dominio cambia porque ponen a prueba las afirmaciones que se supone que deben mantenerse estables.
6. Verificar de forma independiente: no dejar que una implementación se demuestre a sí misma
Sobrevivir a un intento de falsación no siempre basta.
Hay una segunda capa de verificación que es fácil pasar por alto: la verificación independiente.
Dos sistemas que comparten la misma implementación pueden coincidir simplemente porque comparten el mismo error. Las implementaciones independientes ofrecen una prueba más fuerte.
El alienígena usa ahora un segundo montaje experimental para medir el movimiento del objeto. En lugar de apoyarse en el mismo mecanismo de observación, usa uno diferente. Si ambos producen de forma independiente la misma relación, el alienígena tiene más motivos para confiar en el resultado.
Un compilador y un entorno de ejecución, dos intérpretes, o un verificador de especificaciones y un motor de ejecución pueden ofrecer este tipo de comparación.
Si llegan al mismo resultado de forma independiente, la afirmación ha superado una prueba más fuerte que la mera coherencia interna.
Esto le da al gestor de arranque otra propiedad importante.
Una afirmación no debería volverse fundamental solo porque una implementación coincida consigo misma.
Cuanto más importante se vuelve la afirmación, más valiosa es la verificación independiente.
7. Generalizar: determinar qué sobrevive al experimento
Si una afirmación sobrevive a la falsación y a la verificación independiente, el gestor de arranque puede plantear una pregunta nueva:
¿Qué parte de este resultado se aplica más allá del caso concreto en el que se descubrió?
El alienígena prueba con rocas. Luego con trozos de metal. Luego con agua. Luego consigo mismo. La observación parece aplicarse a muchas cosas distintas. Ahora puede pasar de «este objeto concreto se comportó así» hacia «los objetos de este entorno muestran este comportamiento en estas condiciones».
Esto es la generalización.
No dejes un parche para un caso especial en un consumidor si la regla de fondo pertenece al sustrato genérico.
Llévala a la capa donde pueda proteger todo lo que se construye encima.
Aquí es donde el gestor de arranque empieza a convertir descubrimientos individuales en conocimiento reutilizable.
Pero la generalización por sí sola no basta.
El sistema todavía tiene que determinar qué forma debe adoptar ese conocimiento.
8. Abstraer: poner el conocimiento estable en estructuras reutilizables
La generalización lleva a la abstracción.
La pregunta arquitectónica central pasa a ser:
¿Qué debe permanecer estable y qué se debe permitir que cambie?
Un sistema útil necesita ambas cosas.
La capa genérica aporta reglas y mecanismos estables. La capa específica del dominio aporta el comportamiento cambiante construido encima. Las dos deben mantenerse separadas.
El alienígena necesita ahora una manera de representar lo que ha aprendido. Con el tiempo, tras suficiente investigación, podría desarrollar una abstracción para la relación persistente que ha descubierto. Mucho más tarde, nosotros podríamos llamar «gravedad» a esa relación. Lo importante es que la abstracción vino después de las observaciones, las predicciones y los experimentos que la respaldaban.
Esta separación es una consecuencia del gestor de arranque.
Una vez que una regla ha superado el proceso y se ha demostrado que se aplica más allá de un caso particular, no debería tener que ser redescubierta de forma independiente por cada dominio.
Puede pasar a formar parte de la capa genérica.
Composición atómica
Los bloques básicos deberían ser lo bastante pequeños como para reutilizarse en todas partes.
Piensa en LEGO. Las mismas piezas se pueden ensamblar en muchas estructuras distintas. No modificas el ladrillo de LEGO cada vez que construyes una casa diferente.
Esto es lo que hace real la división entre lo genérico y lo específico del dominio. El comportamiento del dominio surge de componer los átomos de otra manera, en lugar de crear sin parar nuevas versiones de los átomos.
Por tanto, el gestor de arranque puede producir piezas de conocimiento pequeñas y estables que más adelante se pueden componer en sistemas más complejos.
Tipado estricto
El sistema de tipos se convierte en un punto de referencia compartido.
Debería haber una sola definición de un tipo, importada en todos los lugares que la necesiten. Cuando esa definición cambia, las consecuencias se propagan por el sistema.
Esto es útil porque el propio sistema saca a la luz el desacuerdo. Una edición de un tipo compartido debería obligar al código que depende de él a demostrar que sigue teniendo sentido.
Por eso el sistema de tipos actúa como parte de la capa de referencia genérica.
Esto es especialmente importante porque las afirmaciones fundamentales son las que más se propagan.
Un error en una funcionalidad de alto nivel puede afectar a una sola funcionalidad. Un error en un tipo compartido o en una primitiva puede afectar a todo lo construido encima.
Eso convierte al cimiento en un objetivo especialmente importante para el gestor de arranque.
Cuanto más fundamental es la abstracción, con más cuidado tiene que superar el proceso.
9. Aislar e intervenir: encontrar dónde vive realmente el problema
El gestor de arranque no se detiene en la abstracción.
Un sistema puede descubrir que algo va mal sin saber de inmediato dónde está el problema de fondo.
Un error puede aparecer en una funcionalidad de alto nivel mientras el problema real existe en una primitiva compartida.
Por eso el sistema necesita aislar la causa real e intervenir ahí.
Supón que uno de los experimentos del alienígena produce un resultado distinto. No cambia de inmediato todo su modelo. Cambia una variable cada vez. ¿Es el objeto? ¿El lugar? ¿El aparato de medición? ¿El entorno? Al aislar las variables, puede determinar dónde se origina realmente el desacuerdo e intervenir ahí.
Este es el papel de Aislar e intervenir.
El objetivo no es simplemente parchear el síntoma visible.
Es identificar dónde es errónea la afirmación o el mecanismo de fondo y hacer el cambio ahí.
Esta es otra razón para separar los mecanismos genéricos del comportamiento específico del dominio.
Si el problema es genérico, corrígelo en el sustrato genérico.
Si es específico del dominio, mantén la intervención en el borde.
Efectos secundarios
La parte específica del dominio es donde el sistema toca el mundo exterior.
Las bases de datos, las API, los archivos, los usuarios, las redes y otros sistemas externos introducen comportamiento específico del dominio e incertidumbre.
Mantener aislados estos efectos significa que pueden cambiar sin contaminar el sustrato genérico.
La maquinaria genérica se mantiene estable. El comportamiento específico del dominio vive en los bordes.
Esto le da al gestor de arranque un lugar donde intervenir sin cambiar constantemente los cimientos que ya han sobrevivido a ciclos anteriores de verificación.
10. Componer: volver a unir las piezas validadas
Una vez aislado y hecho el cambio pertinente, el sistema tiene que volver a componerlo dentro del sistema más grande.
Aquí es donde las máquinas de estados resultan útiles.
Las máquinas de estados ofrecen un sustrato genérico para la mutación.
Una máquina de estados puede entenderse como una secuencia de fotogramas. Algo está en un estado, ocurre un evento y pasa a otro estado.
El mecanismo no necesita saber qué significan esos estados. Solo necesita saber que los estados existen y que las transiciones siguen reglas.
Eso hace que la máquina de estados sea útil como contenedor genérico para muchos dominios distintos.
Así, el mecanismo genérico puede mantenerse estable mientras el conocimiento específico del dominio se compone encima.
El alienígena ahora puede combinar su conocimiento sobre el comportamiento de los objetos con su conocimiento sobre el movimiento, la medición y la navegación. Cada pieza se puede usar como parte de un sistema más grande sin tener que redescubrir cada vez las relaciones de fondo.
Esta es la etapa de componer del gestor de arranque: los mecanismos y las abstracciones validados se combinan en algo que puede funcionar en un dominio concreto.
Algunos fallos solo se hacen visibles aquí.
Los componentes genéricos pueden ser correctos cada uno por separado y su combinación no serlo.
Por eso la composición retroalimenta las etapas anteriores en lugar de ser el final del proceso.
11. Calibrar: determinar si el sistema sigue coincidiendo con la realidad
Después de que el cambio se haya compuesto dentro del sistema, el gestor de arranque necesita determinar si el sistema sigue comportándose como se espera.
Esto es la calibración.
El alienígena predice dónde debería llegar un objeto después de soltarlo desde una posición concreta. Mide lo que ocurre de verdad y descubre que la predicción es ligeramente errónea. Mide la diferencia, ajusta su modelo y vuelve a ejecutar el experimento. La calibración es el proceso de acercar de nuevo el modelo y el mundo observado.
Un sistema puede tener una regla local correcta mientras su modelo más amplio se queda obsoleto.
Puede pasar sus pruebas actuales mientras el entorno que lo rodea cambia.
Por eso la calibración cierra el ciclo actual preguntando si el conocimiento producido por el proceso sigue siendo útil y lo bastante preciso para el entorno en el que opera el sistema.
Aquí es donde las etapas anteriores se juntan:
Comparar → Formular hipótesis → Predecir → Falsar → Verificar → Calibrar
El sistema observa lo que ocurrió, lo compara con sus expectativas y determina si su modelo sigue correspondiendo lo bastante bien con la realidad.
Si no, el proceso empieza a retroceder.
Una calibración fallida puede dejar al descubierto un problema varias etapas atrás.
Entropía: la restricción para ejecutar el gestor de arranque
El gestor de arranque describe cómo aprende un sistema qué es correcto.
La entropía describe la restricción bajo la cual opera ese proceso.
Los recursos son limitados. Un sistema solo puede absorber cierta cantidad de desorden de su entorno y devolver al exterior cierta cantidad. Pero la variable importante no es simplemente cuánto desorden existe en un momento dado.
El tiempo importa.
Lo que importa es el ritmo al que se acumula el desorden en comparación con el ritmo al que el sistema puede procesarlo y exportarlo.
Un pico no es un problema si el sistema tiene tiempo suficiente para ocuparse de él antes de que llegue el siguiente.
Es parecido a una deuda. Tener deuda no es necesariamente el problema. El problema empieza cuando la acumulación supera de forma constante a la amortización.
El gestor de arranque es parte de ese proceso de amortización:
Comparar → Formular hipótesis → Predecir → Falsar → Verificar → Calibrar
Cada ciclo lleva tiempo.
Por tanto, la supervivencia de un sistema depende de si puede completar sus ciclos con la rapidez suficiente para seguir el ritmo de su entorno.
Si el entorno cambia más rápido de lo que el sistema puede completar su bucle, su modelo puede quedar obsoleto antes incluso de haber sido verificado.
El sistema puede tener un proceso perfectamente sólido para producir conocimiento, pero si el mundo cambia más rápido de lo que el proceso puede ejecutarse, el conocimiento llega demasiado tarde.
Esa obsolescencia es en sí misma entropía que se acumula.
Por eso el equilibrio no es quietud.
Es un cambio mutuo acotado entre el sistema y su entorno.
El sistema cambia en respuesta al entorno, y el entorno cambia en respuesta al sistema.
Un sistema cuyas afirmaciones sobre el mundo son erróneas empeora el problema. Sigue actuando sobre el modelo equivocado, de modo que sus interacciones con el entorno se vuelven derrochadoras o perjudiciales para sí mismo.
Esta es una manera directa en que un proceso epistémico roto hace que un sistema supere su límite de entropía mientras sigue comportándose como si mantuviera el equilibrio.
Cuando un sistema no puede seguir reduciendo la entropía, congelarse es el último recurso.
Congelarse no reduce el desorden. Detiene la exposición a él.
El sistema renuncia a parte de su capacidad de adaptación a cambio de detener la acumulación.
Pero un sistema vivo no puede permanecer congelado indefinidamente.
Mantener el equilibrio requiere un flujo continuo, de la misma manera que el cuerpo humano mantiene el equilibrio mediante procesos constantes y no alcanzando un estado estático final.
12. Elegir el siguiente objetivo: el gestor de arranque vuelve a empezar
El gestor de arranque termina su ciclo eligiendo qué investigar a continuación.
Siempre habrá otra incertidumbre, otro cambio sin explicar, otra suposición que podría ser errónea u otra afirmación fundamental que se beneficiaría de una verificación.
El alienígena ahora tiene un modelo útil de este fenómeno concreto, pero ese modelo también deja al descubierto nuevas preguntas. ¿Cambia la relación en otro lugar? ¿Cambia fuera de este entorno? ¿La afecta otro objeto grande?
Elige una de esas incertidumbres como siguiente objetivo y empieza de nuevo.
Cambiar → Comparar → Formular hipótesis → Predecir → Falsar → Verificar de forma independiente → Generalizar → Abstraer → Aislar e intervenir → Componer → Calibrar → Elegir el siguiente objetivo.
Y repetir.
La arquitectura existe para hacer que este proceso sea barato y repetible. Se hace un cambio, se compara con lo que ya existe y se convierte en una hipótesis y una predicción. Después la predicción se pone a prueba, se intenta romper siempre que es posible y se verifica de forma independiente cuando es práctico.
El resultado se generaliza, se abstrae y se compone de nuevo dentro del sistema. Cuando algo no se comporta como se esperaba, el sistema aísla la causa, interviene ahí y calibra contra la realidad.
Luego elige el siguiente objetivo.
El objetivo no es construir un sistema que nunca cambie. Es construir uno que pueda cambiar sin perder su capacidad de determinar si el cambio fue correcto.
Más allá de todo esto
El gestor de arranque no tiene por qué detenerse en la comprensión del mundo. Cuando el bucle es lo bastante estable como para confiar en él, puede volverse sobre sus propios cimientos. Una afirmación puede convertirse en el siguiente objetivo, luego el método usado para establecer esa afirmación, luego las metas que determinan qué investigar y, por último, las suposiciones detrás de esas metas. El mismo proceso sigue funcionando: el sistema usa su método para adquirir conocimiento para examinar el propio método. En ese sentido, el gestor de arranque no es solo una manera de construir conocimiento. Es una manera de que un sistema examine y refine, de forma progresiva, la maquinaria con la que conoce.