He escrito ya alguna vez sobre esa especie de que la incertidumbre y el azar no existen en el mundo. Que esos conceptos —junto con la teoría de la probabilidad que los sistematiza— son solo una construcción de la mente y existen solamente en ella. Que si no fuésemos tan perezosos, podríamos recopilar todas las causas y deducir con precisión milimétrica el futuro (como hacen Diaconis y compañía en el artículo que traté aquí con los lanzamientos de monedas), y advertiríamos que en el mundo real solo hay certidumbres. Etc.

Comienzo la entrada de hoy con un enlace al muy denso Interpretations of probability, en la Enciclopedia de Filosofía de Stanford que, admito, no será del interés de la mayoría.

Podría llegar a decirse —aunque no me atreveré a tanto— que en toda disciplina intelectual tiene que haber paradojas porque de otra manera, sería indistinguible del uso sistemático del sentido común. Así que hoy traigo a colación este análisis de un caso particular de la paradoja de Berkson (que se añade a las ocasiones en las que ya me he referido a ella) y este otro sobre la de Lindley. La primera tiene que ver con la correlación que aparece entre dos variables aleatorias independientes cuando de repente observamos información concomitante; la segunda, con los test de hipótesis (asunto del que, por fortuna, me he mantenido alejado durante largo tiempo).

Hoy, como cada 31 de marzo, se celebra el día de la copia de seguridad.

Así que ya sabéis qué hacer:

Coda

Revisando mis archivos, vi que ya hablé del asunto en 2015, 2017, 2023 y 2024.

Otra coda

Creo que alguna vez lo comenté, pero uso syncthing para mantener sincronizado (y replicado) mi contenido más importante entre mi ordenador de sobremesa, el portátil y el servidor doméstico (que está encendido 24/7).

He implementado las entradas relacionadas en el blog. Dos entradas están relacionadas cuando el producto escalar de sus embeddings es alto.

Así que en primer lugar he asociado a cada entrada un embedding. Las entradas son ficheros de markdown con un preámbulo en yaml. Los embeddings no están creados directamente sobre el texto bruto de la entrada sino sobre la entrada y algunos de los elementos, no todos, del preámbulo.

Todo el mundo lleva días hablando del MCP. Creo que ni merece la pena decir qué cosa es.

MCP es un mecanismo para empoderar agentes. Para los primeros que creé utilié CrewAI pero he migrado a LangChain porque:

• A CrewAI le encantan las dependencias tochas: para cualquier trivialidad crea entornos de varios GB.
• CrewAI está diseñado para un tipo de agentes muy concreto —agentes a los que se delega enteramente el control del flujo del proceso— que no son exactamente los que más me interesan ahora –que suelen incluir un elemento de control por mi parte—.

Aunque todo el mundo habla de LangChain y CrewAI, hay algunas innovaciones interesantes, entre las cuales:

Arranco con un experimento mental: A lleva un chaleco antibalas. B le dispara, la bala atraviesa el chaleco y lo hiere de gravedad en el pecho. Varios sujetos distintos examinan lo sucedido:

• La policía determina que B (y el disparo que realiza) es la causa de lo sucedido.
• Los médicos que reciben a A en el hospital encuentran que la bala incrustada en su pecho es la causa de su estado.
• El técnico de la empresa que fabrica los chalecos antibalas especula que el inusual calibre de la bala y el ángulo de impacto son la causa de que atravesase el chaleco.
• Incluso, uno puede especular que gente que conoce a B (p.e., su siquiatra, su familia o sus amigos íntimos) aventuren otras causas para lo sucedido.

En el mundo, realmente, ha sucedido lo que ha sucedido y nada más: hay, a lo más, razones. La razón de que A se debata entre la vida y la muerte es que tiene una bala en el pecho. Pero determinados sujetos identifican causas que los apelan en tanto que son lo que son y que los mueven a la acción: unos a detener e interrogar a B, otros a intubar a B, etc.

Uber ha desarrollado H3, una retícula global de hexágonos para georeferenciar puntos y objetos. Cada hexágono tiene asociado un único ID y el sistema está concebido para poder correr de manera eficiente los algoritmos habituales: vecinos próximos, ruta más corta, etc.

OpenTimes es un sistema para mostrar el tiempo de viaje (en distintos medios) entre ubicaciones de EEUU. Tiene precalculados los miles de millones de valores de la correspondiente matriz y lo particular de la cosa es que almacena y sirve los datos desde R2, un sistema de Cloudfare similar al archiconocido S3 de Amazon pero orientado a la distribución eficiente de información para aplicaciones web.

Muchos fenómenos tienen una periodicidad intrínsecamente semanal (p.e., el tráfico). Eso puede motivar el uso la semana como unidad temporal de referencia en determinados análisis en lugar del mes o el día.

Existe gente que tal vez no esté al tanto de que existe un estándar ISO para definir y representar las semanas sin ambigüedad, el ISO 8601. Sus principales características son

• Las isosemanas comienzan el lunes y terminan el domingo.
• La primera isosemana del año es la que contiene el primer jueves del año.
• Un año contiene típicamente 52 isosemanas, aunque algunos (entre ellos, 1903, 1908, 1914, 1920, 1925, 1931, 1936, 1942, 1948, 1953, 1959, 1964, 1970, 1976, 1981, 1987, 1992, 1998, 2004, 2009, 2015, 2020, 2026, 2032, 2037, 2043, 2048, 2054, 2060, 2065, 2071, 2076, 2082, 2088, 2093, 2099) contienen 53.
• Las isosemanas se representan con el formato YYYY-Www (e.g., 2025-W10 para la décima semana de 2025)

Hoy en día no merece la pena que indique cómo calcular ni manipular isosemanas en los lenguajes de programación más usuales: casi cualquier LLM lo sabe y lo puede ayudar a uno a crear funciones como

I.

Tiene Andrew Gelman una entrada en su blog, Rubinism: separating the causal model from the Bayesian data analysis, que es, según se mire, relevante o trivial. Esencialmente distingue entre el RCM (modelo causal de Rubin) y el análisis bayesiano (de datos):

• El RCM (o modelo de los efectos potenciales en inferencia causal) lo resume como un modelo en el que se entiende que los datos proceden de una muestra en la que, en el mejor de los casos, se ha visto el efecto de un tratamiento dado en cada sujeto.
• El análisis bayesiano como un marco más amplio que puede servir para analizar el RCM (aunque hay alternativas) o para otras cuestiones.

A todo esto, el RCM se llama también modelo de Neyman-Rubin. Neyman (el de los intervalos de confianza) introdujo una versión limitada del modelo en su tesis de maestría de 1923 y muchos años después, en los 70, Donald Rubin lo extendió y generalizó en una serie de artículos como este.

Tiene Ripley, el gran Ripley, un artículo de hace 20 años titulado Selecting Amongst Large Classes of Models donde discute la cuestión —la del título de esta entrada— y dice:

Deberíamos preguntarnos por qué queremos seleccionar un modelo. Parece ser un error extendido que la selección de modelos trata de “seleccionar el mejor modelo”. Si buscamos un modelo explicativo, deberíamos tener presente que puede haber varios modelos explicativos (aproximadamente) igual de buenos: lo aprendí de David Cox cuando era un profesor novato en el Imperial College tras haber hecho muchas selecciones informales de modelos en problemas aplicados en los que me hubiera resultado útil haber podido presentar soluciones alternativas.