RSS propone algo menos sexy, pero más sano: tú eliges las fuentes, tú decides dónde leerlas, tú puedes exportar tu lista, tú puedes cambiar de lector, tú puedes ordenar el ruido. No eres completamente dueño de la información, porque las fuentes, los medios, los buscadores y los poderes editoriales siguen existiendo. Pero sí eres parcialmente dueño de la forma en que te informas. Y eso, en internet, ya es bastante.

Antes de las cucharadas: una historia mínima de RSS

RSS nació para una web que todavía olía a páginas personales, blogs, portales y enlaces azules. Su historia tiene varias ramas, disputas y nombres, pero una línea básica sirve para orientarse: en 1999 Netscape publicó RSS 0.90 para My Netscape; después vino RSS 0.91, y más tarde UserLand y Dave Winer empujaron otras versiones que desembocaron en RSS 2.0. El historial del RSS Advisory Board registra esa secuencia: RSS 0.90 en marzo de 1999, RSS 0.91 en julio de ese mismo año, una versión de UserLand en 2000 y RSS 2.0 en 2002-2003.

La idea era sencilla: un sitio publica un archivo legible por máquinas con sus novedades. Ese archivo contiene ítems: título, enlace, descripción, fecha, autor u otros metadatos. Un lector RSS visita esos archivos por ti y te muestra lo nuevo. La especificación de RSS 1.0 lo describía como un formato ligero, extensible y multipropósito para describir y sindicar contenido, con canales compuestos por ítems recuperables por URL.

En esa historia aparece Aaron Swartz, y aparece muy joven. A los 14 años coescribió RSS 1.0, una de las ramas más semánticas y extensibles del estándar, vinculada a RDF. El Internet Hall of Fame lo resume así: en 2000, a los 14, Swartz coautoró RSS 1.0 y luego participó en un grupo de trabajo del W3C sobre formatos comunes para la web.

Mencionarlo no es adorno biográfico. Swartz encarna una forma de entender internet: abierta, interoperable, archivable, enlazable, más cerca del conocimiento público que del encierro en plataformas. RSS tiene algo de esa ética. No te pide que mires un muro administrado por una compañía. Te entrega una tubería. Una fuente. Un modo de decir: “cuando publique algo, ven a buscarlo sin pedirle permiso a un algoritmo”. ✊🏼

Durante años, Google Reader fue el gran hogar de esa costumbre. Lanzado en 2005, terminó siendo el lugar donde mucha gente armó su dieta informativa. En 2013 Google anunció que lo cerraría el 1 de julio de ese año, argumentando que su uso había bajado y que la empresa quería concentrarse en menos productos. Ese cierre fue un golpe cultural: no mató RSS, pero sí rompió el centro de gravedad de una práctica. Después vino la diáspora: Feedly, NewsBlur, Inoreader, lectores locales, lectores móviles, lectores autohospedados, lectores que aparecieron y desaparecieron.

RSS sobrevivió porque no dependía de una sola empresa. Esa es la gracia.

Cucharada 1: RSS como soberanía digital cotidiana

La soberanía digital suena a concepto de paper, pero en RSS se vuelve una práctica doméstica: elegir fuentes, ordenar carpetas, exportar una lista, leer en el momento propio, ignorar lo que no importa y no depender de un feed que optimiza tu atención para fines ajenos.

Las redes sociales no están diseñadas principalmente para informarte bien. Están diseñadas para retenerte. A veces eso coincide con estar informado; muchas veces coincide con estar irritado, ansioso, entretenido o atrapado. La diferencia es importante. Un lector RSS no elimina sesgos ni garantiza calidad, pero cambia la arquitectura de decisión. En vez de preguntar “qué quiere mostrarme esta plataforma”, preguntas “qué fuentes decidí seguir y qué publicaron”.

La literatura académica sobre personalización algorítmica ayuda a ponerle marco a esta intuición. Urbano Reviglio y Claudio Agosti proponen el concepto de “soberanía algorítmica” para discutir el poder que tienen las plataformas sobre la personalización, la curaduría y la modificación de conducta. Su punto no es que toda personalización sea mala, sino que buena parte de esa personalización ocurre en sistemas opacos, comerciales y difíciles de negociar socialmente.

También hay una dimensión cognitiva. La atención no es una bodega infinita. La sobrecarga informativa aparece cuando la cantidad de información que se nos exige procesar supera nuestra capacidad de procesarla con sentido. Una revisión sistemática sobre information overload muestra que este no es solo un problema de volumen, sino también de contexto, tareas, tiempo, interrupciones y diseño de los entornos donde leemos.

En el consumo de noticias, esto importa todavía más. Un estudio en Frontiers in Psychology sobre sobrecarga de noticias en redes sociales encontró relaciones significativas entre news overload, evitación de noticias, necesidad de noticias y conductas de filtrado. Dicho en simple: cuando el flujo se vuelve demasiado intenso, las personas no necesariamente se informan mejor; muchas veces filtran a la fuerza, leen en diagonal, se agotan o directamente evitan.

RSS no soluciona todo eso, pero introduce fricción buena. No hay autoplay. No hay “para ti”. No hay ranking emocional automático. No hay una máquina probando qué titular te retiene dos segundos más. Hay una lista. Hay carpetas. Hay leídos y no leídos. Hay una relación más explícita entre fuente, tiempo y atención. 🧘🏼‍♂️

La evidencia empírica sobre feeds algorítmicos es compleja. En un estudio publicado en Science sobre Facebook e Instagram durante la elección estadounidense de 2020, cambiar feeds algorítmicos por feeds cronológicos redujo el tiempo y la actividad dentro de las plataformas, aunque no produjo cambios significativos en varias actitudes políticas durante el período estudiado. Un trabajo más reciente en Nature, sobre el feed algorítmico de X, reportó que activar un feed algorítmico aumentó el engagement y movió algunas opiniones políticas en ciertos temas. No hace falta sacar una conclusión apocalíptica de esto. Basta con una conclusión práctica: importa quién ordena lo que lees. Importa bajo qué incentivos. Importa si puedes salirte.

RSS te devuelve una parte de ese control.

Cucharada 2: dónde leer, dónde agregar y mi historia con RSS

Un agregador es un lector que junta fuentes distintas en un solo lugar. La idea básica es que no tengas que ir sitio por sitio a buscar información, sino que esa información llegue a ti mediante un lector o agregador. La Biblioteca del Congreso Nacional de Chile lo explica de forma simple: RSS permite recibir contenidos actualizados desde sitios web sin tener que visitarlos manualmente uno por uno.

Ese gesto cambia la relación con la web. En vez de abrir veinte pestañas, abres una bandeja. En vez de depender de que una red social te muestre una nota, sigues directamente al sitio que la publica. En vez de perder tus suscripciones cuando una empresa cambia de estrategia, exportas tu OPML y te vas a otro lector.

Mi historia con RSS empezó por ahí, entre 2006 y 2007, con Google Reader. Ahí agregué la mayoría de mis sitios. Ahí aprendí una forma de informarme que era también una forma de perder el tiempo, pero con cierto orden: revisar pendientes, bajar con el teclado, abrir lo interesante, marcar leído, volver al flujo. Era procrastinación, sí, pero una procrastinación +gobernada.

Después vino Android. Y ahí mi app fue gReader. De esa primera camada de lectores móviles, gReader tenía algo muy preciso: era suficientemente fea para parecer herramienta, suficientemente rápida para volverse costumbre y suficientemente cómoda para leer mucho sin pensar demasiado en la aplicación misma. En 2010, Gizmodo la puso como medalla de oro entre lectores RSS para Android, por encima de alternativas como NewsRob y FeedR. No sé si era la mejor en términos absolutos, pero sí era de esas apps que se pegaban a los dedos.

También recuerdo otros fantasmas de esa época. Una app con un cohete como icono, cuyo nombre se me perdió en la memoria, pero que queda ahí como objeto arqueológico: el RSS en Android fue también eso, probar lectores, cambiar interfaces, entusiasmarse por pequeños gestos de navegación. Y recuerdo Corgi, una promesa rara y simpática: un perro que te traía el diario al teléfono. Corgi for Feedly ponía tus feeds directamente en la pantalla de bloqueo de Android para leer sin abrir la app. En español, El Android Libre lo describía tal cual: Feedly en el lockscreen, con diseño Material Design, para pasar artículos desde la pantalla bloqueada. La idea era un poco absurda y un poco brillante: llevar el diario a la puerta de la casa, pero la puerta era la pantalla de bloqueo. 🐶

De esa época dejaría esta pequeña constelación Android:

1. gReader, mi app de verdad, la que más calzó con el hábito.
2. NewsRob, fuerte en sincronización y lectura offline, muy atada a la era Google Reader.
3. FeedR, una alternativa más independiente dentro de la primera ola Android.
4. Press, más cuidada visualmente y cercana a esa escuela de lectores bonitos.
5. Feedly, el gran sobreviviente de la diáspora post-Google Reader.

Cuando Google Reader anunció su cierre, Feedly se movió rápido. En junio de 2013 lanzó Feedly Cloud, una plataforma propia para dejar de depender del backend de Google Reader y facilitar la migración. Eso explica parte de su persistencia: no solo era una app bonita, sino un servicio de sincronización que logró recibir a usuarios que venían con años de carpetas, hábitos y feeds acumulados.

En Windows también usé software de agregación. Ahí conocí Feedly de otra manera: ya no solo como app, sino como servicio sincronizado. Después me pasé a Reeder. Y cada cierto tiempo, por inquietud o aburrimiento, probaba otros lectores en Windows y Linux: lectores más locales, más libres, más feos, más potentes, más minimalistas. Siempre terminaba volviendo a Feedly.

Pero nunca de pago. No por desprecio al producto, sino por escala de uso. Mi consumo de feeds no da como para pagar una suscripción. Esto también es parte de RSS: puede ser muy sofisticado, pero puede seguir siendo austero. Una lista de fuentes, un lector gratuito, algo de disciplina y nada más.

En iOS, Reeder merece un párrafo aparte. La app de Silvio Rizzi representa una de las líneas más cuidadas de esta tradición: leer bien, navegar rápido, no estorbar. Valoro mucho ese trabajo. Durante años Reeder fue, para mí, la prueba de que un lector RSS podía ser elegante sin convertirse en revista, minimalista sin volverse pobre, potente sin parecer una consola de administración.

Eso sí: me gustaría que la nueva etapa volviera, al menos para quienes leemos RSS de forma más clásica, al sistema previo de pago único y no suscripción. Aquí conviene ser justo: no es que todo Reeder se haya vuelto una sola cosa. La nueva app, Reeder, aparece como gratuita con compras dentro de la app y una suscripción mensual o anual; además, según MacStories, Reeder+ desbloquea feeds ilimitados y funciones adicionales. Al mismo tiempo, Reeder Classic sigue disponible como versión anterior para quienes prefieren una experiencia tradicional de RSS y read later. Aun así, mi preferencia sigue siendo clara: en lectores RSS, pago único antes que suscripción, salvo que el volumen de lectura justifique pagar infraestructura todos los meses.

Hoy el mapa se podría ordenar así: para empezar rápido, Feedly o Inoreader; para lectura local y privacidad, Feeder; para autohospedaje, FreshRSS, Tiny Tiny RSS o NewsBlur; para leer bonito en Apple, Reeder o Reeder Classic. Pero lo esencial no es la app. Lo esencial es el archivo: el OPML. Ese pequeño mapa exportable de tus fuentes. Tu jardín de enlaces vivos.

Cucharada 3: lo que viene después del RSS clásico

RSS no tiene por qué quedarse en “seguir blogs”. Puede ser una infraestructura personal para leer la web.

Primero, podemos hacer feeds donde no los hay. Hay sitios que no publican RSS, pero igual tienen patrones: una página de noticias, una sección de comunicados, una agenda, una lista de documentos, una página institucional que cambia cada cierto tiempo. Herramientas como RSS-Bridge existen precisamente para generar feeds de sitios que no tienen uno. RSSHub va en la misma dirección: una red y proyecto open source para crear rutas RSS desde muchas fuentes distintas. Y herramientas como Feed Creator de FiveFilters permiten generar feeds a partir de elementos de una página web que no ofrece RSS propio.

Segundo, podemos convertir feeds pobres en feeds útiles. Muchos medios entregan solo título y bajada para obligarte a entrar al sitio. Eso puede tener sentido para su negocio, pero para lectura personal a veces es una molestia. Herramientas de extracción de texto completo permiten limpiar artículos, quitar ruido visual y dejar una versión legible. El propio ecosistema de FiveFilters existe alrededor de esa idea: tomar contenido web y transformarlo en algo más portable, legible y procesable.

Tercero, podemos hacer digest o resumen propios. No todo merece ser leído al instante. Ese resumen no debería reemplazar la fuente. Debería apuntar hacia ella. El LLM no decide qué existe; ayuda a comprimir lo que tú ya decidiste seguir.

Cuarto, podemos mezclar RSS con mensajería. Un feed puede terminar en Telegram, en correo, en una página estática, en una base de datos personal, en un dashboard, en un bot que avisa solo cuando aparece cierta palabra. También puede funcionar al revés: newsletters convertidas en feeds, canales convertidos en resúmenes, sitios sin RSS convertidos en fuentes vigiladas. La web, cuando se deja conectar, vuelve a ser menos una línea de tiempo y más una caja de herramientas.

Quinto, podemos compartir mapas de lectura. Un OPML público es una invitación a husmear la dieta informativa de alguien. No como performance de influencia, sino como gesto de infraestructura: “estas son mis fuentes, llévatelas, rómpelas, cámbialas, impórtalas, arma las tuyas”.

Ese es el cierre natural de este post: parte por probar. No hace falta migrar toda tu vida informativa. Basta con elegir diez fuentes que de verdad quieras seguir: un medio, un blog, una revista académica, una cuenta institucional, un podcast, una página rara que siempre olvidas revisar. Las agregas a un lector. Las ordenas. Las lees por una semana. Después decides.

Y para partir, puedes husmear mi OPML: mi archivo con todos mis feeds, mis obsesiones, mis sitios muertos, mis fuentes persistentes, mis carpetas probablemente mal nombradas.

RSS no es nostalgia. Es una forma discreta de resistencia cotidiana contra la lectura gobernada por otros.

Gobierna cómo lees las noticias.

No es algo nuevo ni una promesa de autonomía total, de hecho mantenerlo da harta pega. Pero, es un contrato local de trabajo que ordena quién ejecuta, quién revisa, cuándo se usa MCP, cuándo entra Gemini/Antigravity, cuándo Copilot queda como apoyo, qué skills se cargan y qué evidencia o producto queda al cierre.

Lo cuento desde casos de uso concretos míos: minutas, revisión normativa, de planillas, modelos estadísticos, scripts de automatización en server de la casa, timers de sistema, nube propia, seguridad del router, backups, blog y mantenimiento cotidiano. En todos esos casos me ha servido tener algo de “gobernanza” agéntica. Quizás una falsa sensación de soberanía digital también.

La tesis es simple: un sistema multiagente sin roles, permisos ni trazas puede parecer sofisticado, pero en la práctica se parece demasiado a una reunión sin acta.

Tres ideas para comenzar:

• Codex me ha funcionado como ejecutor principal: lee archivos, aplica parches, corre validaciones y puede cerrar diffs con evidencia. No es infalible, por eso no debería autovalidarse en cambios críticos.
• Claude me ha servido como revisor fuerte (sobre todo con Opus): revisa arquitectura, normativa, supuestos estadísticos y riesgos argumentales. Lo uso como freno, y apoyo al ejecutor principal.
• Gemini/Antigravity, Copilot y LiteLLM (con DeepSeek y Z.ai) sirven mejor acotados: exploración, validación, canary o tareas pequeñas. Cuando empiezan a decidir con poco contexto, el flujo empeora.

Cucharada 1: el problema no era usar agentes, era no perder continuidad

En una tarea larga, el costo de una pausa no es solo el tiempo sin respuesta. Lo más caro es perder continuidad: qué se estaba probando, qué archivo cambió, qué hipótesis falló, qué validación quedó pendiente y qué contexto ya no conviene seguir arrastrando.

Mi primer error fue tratar cada modelo/agente como una “segunda opinión” o validación simétrica. Eso no escala. En una minuta o una revisión normativa, terminaba con comentarios útiles pero difíciles de reconciliar.

La solución fue más aburrida y más útil: separar roles. No porque sea “la” forma correcta para todo el mundo, sino porque en mi flujo baja el costo de volver a una tarea, sin recapitular era alto.

Me sirve leer la convergencia de proveedores desde ahí. Codex documenta configuración, sandbox, permisos, MCP, AGENTS.md, skills y subagentes; GitHub Copilot admite instrucciones de repositorio; Gemini Code Assist describe un agent mode con herramientas, MCP y aprobación de cambios; y Claude Code permite hooks en puntos como PreToolUse, PostToolUse y SessionStart.¹²³⁴

Tabla 2 — Roles actuales en penta-agent

La arquitectura local lo vuelve explícito. En routing.yaml, la regla penta_agent_ops mantiene a Codex como primary, a Claude como reviewer, a Gemini como validador/fallback y al humano como checkpoint:

id: penta_agent_ops
planner: codex
primary: codex
reviewer: claude
escalate_to: humano
validator_chain: [gemini]
fallback_chain: [gemini]
planning:
  proactive_skills: [handoff-protocol, recall-context]
  mcp_policy:
    mode: conditional
    allowed_paths: [claude_to_codex_mcp, gemini_to_codex_mcp]
  provider_roles:
    planning_sidecars:
      canary: copilot

El detalle clave es mcp_policy.mode: conditional. No todo se manda por MCP. No todo merece handoff. No todo merece un segundo proveedor. La evaluación luego de algunas iteraciones la hice proactiva, al igual que con los skills, que los activadores fuesen bien explicitos. Al principio no se activaban cuando querían o los handoffs eran escasos.

Cucharada 2: el repositorio como contrato de trabajo

La pieza que más me ayudó no fue un modelo. Fue una regla de arranque: si una tarea toca multiagente, MCP, Claude, Gemini, Copilot, routing, handoffs o penta-agent, primero se lee el canon local.

En mi caso, ese canon vive en archivos como:

• router/routing.yaml
• shared-references/arquitectura-multiagente.md
• playbooks/puente-mcp-codex.md
• .mcp.json

Esto evita un vicio frecuente: hacer uso genérico de CLIs, modelos y comandos antes de entender el “contrato” u objetivo del proyecto. En cosas chicas puede no importar. En una revisión normativa, una corrida estadística o un ajuste de seguridad local, sí importa, ya que la deriva gasta tokens como loco, y a veces termina varado en cualquier lugar.

Un AGENTS.md útil no necesita ser una novela, gasta contexto, tiene que evitar malas prácticas creo yo:

# Reglas multiagente del workspace

Si el usuario menciona trabajo multiagente, MCP, Claude, Gemini,
Copilot, routing, handoff o penta-agent:

1. Usar `penta-agent/` como source of truth.
2. Leer primero routing, arquitectura, puente MCP y configuración MCP.
3. No hacer probing genérico de CLIs antes de leer el canon.
4. Delegar a Antigravity solo mediante `scripts/agent/agy-bridge`.
5. No entregar secretos, `.env`, llaves ni credenciales a proveedores externos.

La literatura reciente pareciera ir en una dirección parecida, pero con una advertencia sana. Galster et al. describen estos artefactos como mecanismos versionables para configurar herramientas agenticas y observan que AGENTS.md emerge como estándar interoperable.⁵ Arabat y Sayagh proponen mirarlos como “instructions-as-code”, no como notas al margen.⁶ Por otro lado, Gloaguen et al. advierten que los context files pueden reducir éxito y aumentar costo cuando agregan requisitos innecesarios.⁷ En mi experiencia, hay que buscar bien el equilibrio y estar dispuesto a tunear de forma constante.

Skills: procedimientos, no prompts eternos

Las skills me han servido cuando actúan como procedimientos reutilizables con activación clara, límites y referencias. Una skill de publicación, por ejemplo, no debería decir “escribe bonito”; debería decir cosas verificables:

name: jekyll-post
description: Posts Jekyll con front matter, drafts/posts, build y publicacion reproducible.

- Preparar front matter correcto y validar build.
- Mantener claims fechados y trazables.
- Revisar front matter y guía editorial.

La pregunta mínima para una skill es: cuándo se activa, qué no debe hacer, qué archivos debe leer y qué salida permite verificar que hizo bien su trabajo. Eso calza con la carga progresiva descrita por Anthropic: metadata primero, instrucciones cuando la skill se activa, y recursos o scripts solo si hacen falta.⁸ También calza con SkillJuror, que muestra que la organización de una skill cambia cómo los agentes buscan y aplican conocimiento, aunque el beneficio depende de que los recursos sean accionables.⁹

La advertencia de seguridad es igualmente importante: SKILL.md no es documentación pasiva.¹⁰ Si una skill trae scripts, instrucciones ambiguas o metadata manipulable, se parece más a instalar software que a pegar un prompt inocente.

MCP: puente, pero aún no le saco el jugo

El MCP real de penta-agent es deliberadamente pequeño:

{
  "mcpServers": {
    "codex": {
      "type": "stdio",
      "command": "scripts/codex_mcp.sh",
      "args": ["mcp-server"],
      "env": {}
    }
  }
}

La idea no es que todos los agentes se conecten con todos. El camino preferido es Claude/Gemini hacia Codex cuando necesitan filesystem, comandos, tests o edición local. Codex hacia Claude o Antigravity usa CLI/handoff controlado. No asumo bridge bidireccional ni filesystem MCP universal.

Esto también es una decisión de seguridad. La documentación oficial de MCP enumera riesgos como confused deputy, token passthrough, SSRF, secuestro de sesión y compromiso de servidores locales.¹¹ La investigación reciente sobre tool poisoning en MCP insiste en que el problema crítico muchas veces está del lado cliente: metadata maliciosa, baja visibilidad de parámetros y confianza implícita.¹². Aún no le saco todo el provecho.

Handoffs: el antídoto contra “yo le avisé”

Un handoff no es decir “que lo revise Claude”. Un handoff útil debe dejar rastro mínimo:

HANDOFF-TRACE: codex le solicita apoyo a claude (model: sonnet) via CLI
MODEL-REPORT: {"agent":"codex","provider":"openai","model":"__default__","source":"self_report"}
MODEL-REPORT: {"agent":"claude","provider":"anthropic","model":"sonnet","source":"self_report"}

Y debe separar lo básico:

metadata:
  from: codex
  to: claude
  via: CLI
  skill: handoff-protocol

contexto_esencial:
  - que se hizo
  - que se descarto
  - que falta validar

tarea_para_receptor:
  - revisar claims
  - detectar riesgos
  - no modificar archivos

verificacion:
  - pruebas corridas
  - fuentes consultadas
  - decision final

Esto parece burocracia hasta que algo falla. Cuando falla, la traza permite saber si el problema fue contexto insuficiente, modelo inadecuado, mala ruta, salida ambigua, cuota, permisos, sandbox o una instrucción mal escrita. OpenAI propone una lógica semejante en su loop de mejora de agentes: usar trazas, feedback y evaluaciones para modificar el arnés, no solo para pedirle al modelo que “lo haga mejor”.¹³ Esto me ha servido para usar la skill recall-context luego, ya que con una buena traza recupero trabajo previo de forma bien eficiente entre agentes.

Cucharada 3: lo que aprendí haciendo que fallara

La lista de errores propios vale más que la lista de herramientas. Este post más que vitrina, ojalá sirva de bitácora y probablemente añeje pronto, pero ojalá le sirva a más de alguien.

Tabla 3 — Errores propios y controles actuales

La parte de memoria merece un párrafo. En penta-agent, la memoria operativa vive en archivos append-only como experience-events.jsonl, experience-lessons.yaml e interaction-metrics.jsonl. Qdrant y FastEmbed ayudan a recuperar experiencias, pero son derivados. Si cambia el embedding o aparece una dimensión incompatible, se reconstruye el índice desde JSONL. Después de pelear con ese tipo de drift, no quiero que la fuente de verdad sea frágil.

El sidecar de LiteLLM sigue la misma filosofía. Sirve para delegar tareas baratas y acotadas a aliases como cheap, cheap-code o cheap-reasoner, pero no para arquitectura, seguridad ni decisiones finales. Además, el smoke real de proveedor importa más que el contenedor sano. Si DeepSeek responde Insufficient Balance, el sistema no está listo; solo aprendimos que Docker sabe prender una luz.

Cierre: bucle de optimización

No conviene mirar mi stack como si fuera plantilla universal, no lo es. Lo que sí puede servir es tomar elementos de la lógica: contratos pequeños para no depender de memoria humana ni de entusiasmo del momento. Dejé una versión pública y sanitizada del stack en tatanlabra/penta-agent. No es un volcado de mi entorno local: quité memoria runtime, rutas privadas, logs, .env, credenciales, IPs internas y cualquier cosa que pudiera revelar configuración personal. Quien lo clone debería tratarlo como plantilla y revisar los placeholders de AGENTS.md, .mcp.json, router/routing.yaml, scripts/agent/agy-bridge y skills/ antes de usarlo.

penta-agent me ha servido no porque tenga muchos agentes, sino porque tiene frenos: roles, rutas, skills, permisos, handoffs, memoria reconstruible y validación. Eso no lo vuelve universal ni superior. Lo vuelve auditable para mis problemas. El vibe coding nombra bien la primera sensación de fluidez: pedir, ver aparecer código, corregir y seguir. Pero cuando el flujo madura, la pregunta cambia: qué tan eficiente, elegante y verificable es la solución que obtienes.

Referencias técnicas

Este post propone usar optimización bayesiana (BO) como una capa externa de decisión en Python. No gana siempre. Gana cuando el problema se parece a esto: función objetivo cara, espacio de búsqueda acotado, métrica razonablemente estable y presupuesto limitado.

Tres ideas para comenzar:

• BO no asume que el hiperparámetro tenga una distribución particular. En el caso clásico con procesos gaussianos, lo que se modela probabilísticamente es la función objetivo evaluada en distintos puntos del espacio de hiperparámetros.
• Random search sigue siendo un baseline serio. Bergstra y Bengio mostraron que puede ser mucho más eficiente que la grilla cuando no todos los hiperparámetros importan por igual. BO parte desde ahí y agrega memoria estadística.
• Optimizar hiperparámetros no arregla una mala función objetivo. En RSH, por ejemplo, se podría modelar una circularidad (lo que llaman ahora “fuga de información” 🌊). En ecommerce, sin ser mi campo (bienvenidos comentarios) sería confundir propensión con causalidad. En ambos casos, BO puede encontrar más rápido una solución si el diseño predictivo está bien planteado.

Tolerancia al contraste o cotejo con evidencia

Este post no compara resultados empíricos todavía (segunda patita), pero he probado su funcionamiento en productivo con un par de casos, por lo que viene desde lo empírico con datos reales y trazabilidad completa (SAT: Sistema de Alerta Temprana de Deserción Escolar, y Modelo de Subtramos de vulnerabilidad en RSH, tramos dentro del 40% más vulnerable con EBM).

Tabla 1 — Evidencia mínima para sostener el enfoque

Cucharada 1: dos problemas de ranking, no dos juguetes predictivos

Quiero usar dos ejemplos con igual peso. Uno viene del mundo público: ordenar hogares por vulnerabilidad relativa usando una muestra pública del RSH (sobre lectura territorial de datos sociales en Chile escribí antes en CASEN 2024 en 3 cucharadas). El otro viene del mundo privado: ordenar clientes, sesiones o contactos según el valor esperado de una acción comercial en ecommerce.

No son problemas equivalentes en lo sustantivo. El primero tiene consecuencias de legitimidad pública; el segundo, de eficiencia comercial. Pero ambos comparten una misma pregunta estadística: si lo importante es ordenar bien los casos, ¿cómo buscamos hiperparámetros que mejoren ese orden sin gastar cómputo en combinaciones poco informativas?

Tabla 2: Dos ejercicios equivalentes para pensar HPO como problema de ranking

Caso RSH: ranking de vulnerabilidad sin usar ingreso directo

El ejercicio RSH no debería formularse como “predecir pobreza” ni como “replicar la CSE”. Eso cerraría demasiado rápido la discusión y aumentaría el riesgo de circularidad. Lo más limpio es formularlo como un problema de ranking supervisado de vulnerabilidad relativa.

La función objetivo no busca solo acertar clases, sino mejorar la probabilidad de que el orden entre hogares sea correcto. Si el hogar $i$ es más vulnerable que el hogar $j$, el modelo debería asignar $s_i > s_j$. Ese score puede calibrarse como probabilidad, pero su primer uso analítico es ordinal: ordenar hogares con la mayor estabilidad posible.

Una forma simple de escribirlo es:

donde $s_i$ es el score de vulnerabilidad del hogar, $X_i$ contiene señales indirectas y $\theta$ representa los hiperparámetros del modelo. El ingreso directo queda fuera de $X_i$. También deberían quedar fuera las variables que sean una copia administrativa demasiado cercana del target.

En un EBM, el score tiene una ventaja importante: puede descomponerse en efectos por variable e interacciones acotadas.

Esa forma no vuelve al modelo “justo” por sí misma, pero permite auditarlo mejor. Si el score aumenta de manera brusca en un punto absurdo de escolaridad, materialidad o composición del hogar, la forma funcional queda a la vista. En este caso, la interpretabilidad no es estética: es parte de la defensa metodológica del ranking.

Para HPO, un hiperparámetro ilustrativo es max_bins. Controla cuán finamente se discretizan las variables continuas antes de aprender efectos. Con pocos bins, el modelo puede suavizar demasiado y perder diferencias reales. Con demasiados bins, puede capturar ruido, producir saltos artificiales y empeorar la estabilidad del orden.

La comparación correcta no es “grilla versus Bayes” en abstracto. La comparación relevante es esta:

Un movimiento bivariado más realista sería optimizar max_bins junto con interactions. La intuición es clara: más granularidad en variables principales puede exigir más cautela con interacciones. Si se aumentan ambas sin control, el ranking puede mejorar en validación interna y empeorar fuera de muestra.

La métrica objetivo principal sería Kendall’s tau-b, porque el propósito del modelo no es solo clasificar hogares vulnerables, sino preservar correctamente la prelación entre ellos: que hogares con mayor vulnerabilidad de referencia reciban sistemáticamente scores más altos que hogares menos vulnerables. AUCPR puede reportarse como métrica complementaria si la alta vulnerabilidad se define como evento minoritario; NDCG@k, si interesa auditar especialmente el tramo superior del ranking; y Brier/calibración, solo si el score será interpretado como probabilidad. En una versión más exigente, además del desempeño global, exigiría estabilidad por subgrupos y territorio: un ranking que ordena bien solo en la región o tipo de hogar dominante no está listo para discusión pública sería según mi opinión.

Caso ecommerce: lift operativo sin confundirlo con causalidad

En ecommerce hay que separar tres modelos que suelen mezclarse:

1. Propensión: probabilidad de compra futura.
2. Valor esperado: compra esperada ponderada por monto, margen o probabilidad de conversión.
3. Uplift causal: incremento atribuible a una acción, por ejemplo enviar un cupón, mostrar un banner o activar una recomendación.

Si no hay experimento, y aquí entro en territorio desconocido para mi conocimiento, yo no prometería causalidad. Haría un modelo de propensión o de valor esperado y lo evaluaría como ranking comercial. Si hay experimento A/B o grupo de control válido, entonces sí se puede hablar de uplift más real: la pregunta pasa a ser quién compra más porque fue tratado, no simplemente quién iba a comprar de todos modos.

Usaría H2O XGBoost con dos variantes:

En el caso observacional, un score útil podría ser:

Eso no mide causalidad, pero puede servir para priorizar acciones si el objetivo es eficiencia comercial. Si el costo del contacto o del descuento es conocido, conviene optimizar ganancia esperada:

En H2O XGBoost, un hiperparámetro ilustrativo es max_depth. Controla la profundidad máxima de cada árbol. Con árboles muy superficiales, el modelo puede perder interacciones relevantes: por ejemplo, clientes recurrentes, con abandono reciente de carrito, alta sensibilidad a descuentos y stock disponible. Con árboles demasiado profundos, puede memorizar ruido de campañas, estacionalidad o eventos puntuales.

El movimiento bivariado natural es max_depth con min_rows o learn_rate.

La intuición: si se permiten árboles más profundos, puede ser necesario exigir más observaciones mínimas por hoja para evitar reglas demasiado específicas. Otra dupla frecuente es max_depth con learn_rate: árboles más complejos con tasas de aprendizaje altas pueden sobreajustar rápido; tasas más bajas pueden necesitar más árboles y más tiempo.

Ahí BO tiene sentido práctico. No porque “Bayes sea mejor” por definición, sino porque una grilla cartesiana crece rápido. Si se prueban 8 valores de profundidad, 8 de min_rows, 6 de learn_rate, 5 de sample_rate y 5 de col_sample_rate, ya son 9.600 combinaciones antes de pensar en validación cruzada o ventanas temporales. Random search reduce el costo; BO intenta reducirlo aprendiendo de cada evaluación.

La idea de fondo para ambos ejemplos es la misma:

donde $M$ puede ser AUCPR, NDCG@k, lift@k, profit@k, Qini o una combinación penalizada por inestabilidad. BO no asume que los hiperparámetros tengan distribución normal. En su versión con procesos gaussianos, modela probabilísticamente la función objetivo: qué desempeño cabe esperar para una configuración todavía no evaluada, dado lo que ya se observó.

La decisión metodológica queda así: random search es el baseline mínimo; BO entra cuando cada entrenamiento cuesta, cuando el espacio de búsqueda es razonable y cuando la métrica de validación representa el uso real del modelo. Si esas tres condiciones no se cumplen, BO puede producir una optimización elegante sobre una pregunta mal planteada.

Cucharada 2: el experimento antes que el algoritmo

La optimización de hiperparámetros, creo yo, parte fijando como evaluaremos el éxito. En estos dos ejemplos, el contrato de éxito tendría seis piezas:

Tabla 3: Contrato mínimo antes de hacer HPO

La parte estadística clave es que la métrica observada no es la métrica verdadera. Cada trial entrega una estimación ruidosa del desempeño:

Ese ruido aparece por splits, folds, prevalencia del evento, tamaño muestral, cambios temporales, subgrupos pequeños y variación propia del entrenamiento. En RSH puede verse como inestabilidad por territorio o tipo de hogar. En ecommerce puede verse como estacionalidad, campañas simultáneas, cambios de stock, descuentos o ventanas de validación poco representativas.

Por eso, en lugar de optimizar solo una métrica limpia, conviene optimizar una métrica penalizada:

La intuición es simple. Una configuración no debería ganar solo porque sube marginalmente la métrica principal. Debería ganar porque mejora el ranking (particularmente en RSH/SIVUST, donde el orden es lo crítico), se sostiene fuera de muestra y no introduce una complejidad difícil de defender.

En el caso RSH, esa función podría premiar Kendall’s tau-b y castigar inestabilidad por territorio, composición del hogar o subgrupos relevantes. En ecommerce, podría premiar profit@k o lift@k y castigar volatilidad temporal, exceso de profundidad o dependencia de una campaña puntual.

El espacio de búsqueda también debe pensarse, no solo declararse. Una grilla amplia puede parecer neutral, pero en realidad contiene supuestos. Decidir que max_depth va de 2 a 20, o que max_bins puede llegar a 4096, no es inocente. Amplía el espacio, encarece la búsqueda y permite configuraciones que quizá nunca deberían competir.

Una regla práctica:

Tabla 4: Cómo pensaría el espacio de búsqueda

Aquí entra BO, pero con un rol acotado. No define el target, no corrige fugas/circularidad (“leakage” 🕶️) y no decide qué error es aceptable. La secuencia práctica sería esta:

1. correr una regla simple;
2. correr random search con un presupuesto fijo;
3. correr BO con el mismo presupuesto;
4. comparar no solo la mejor métrica, sino la curva de aprendizaje;
5. revisar estabilidad en test;
6. publicar también los trials fallidos.

La curva de aprendizaje importa mucho. Si BO supera a random search recién después de 300 trials, pero el presupuesto real era 30, no aportó. Si random search alcanza un resultado similar con menor complejidad, también es evidencia. La pregunta no es qué método tiene mejor reputación, sino cuál entrega mejor decisión con el presupuesto disponible.

Para este post, usaría Optuna como orquestador principal. No porque sea “más bayesiano” en abstracto, sino porque permite registrar estudios, reanudar trials, comparar samplers y guardar resultados (originalmente probé con otras librerías en SAT sin éxito, terminaba usando artefactor como pickle para suplir cosas que no tenía la librería). El motor de entrenamiento puede ser H2O XGBoost, EBM u otro modelo tabular; Optuna solo necesita una función objetivo que devuelva una métrica.

También distinguiría tres niveles de búsqueda:

Tabla 5: Tres niveles de búsqueda posibles

No sobredefendería el proceso gaussiano. Para explicar BO es útil, pero en espacios mixtos, discretos o condicionales, TPE o SMAC parecen ser más prácticos. En problemas pequeños y relativamente suaves, GP tiene sentido. En problemas grandes, con categorías, condicionalidad o ruido, conviene comparar. En resumen, hay que medir cuánto cuesta cada evaluación y qué inestabilidad no estamos dispuestos a aceptar.

Cucharada 3: Alternativas y cierre

En lugar de BO o en su complemento, el uso de LLM puede entrar como una capa. Primero, antes del tuning, para proponer espacios de búsqueda razonables, detectar hiperparámetros mal escalados y sugerir restricciones. Segundo, durante el tuning, para leer trials fallidos y proponer ajustes al espacio. Tercero, después del tuning, para revisar consistencia: pérdida de información, variables sospechosas, métricas que no calzan con la decisión o explicaciones demasiado frágiles (HAY QUE EXPERIMENTAR).

El flujo más interesante sería híbrido:

Y, en paralelo:

La gracia no es reemplazar Bayes por LLM ni LLM por Bayes. La gracia es que cada parte haga lo que sabe hacer mejor. El LLM puede ayudar a pensar, resumir, criticar y proponer. BO puede asignar mejor el presupuesto de evaluación. La validación, en cambio, sigue siendo el tribunal.

Cierre: una invitación a probar con datos reales

La pregunta que me interesa dejar abierta no es si BO es “mejor” que random search. Esa pregunta, así formulada, es demasiado amplia. La pregunta útil es más concreta:

con 30 entrenamientos disponibles, ¿qué estrategia entrega el ranking más estable, defendible y útil?

En RSH, eso significa probar si un modelo transparente puede ordenar vulnerabilidad relativa sin usar ingreso directo (por ausencia o fragilidad del dato directo), con auditoría por territorio y tipo de hogar. En ecommerce, significa probar si un modelo tabular optimizado mejora una regla simple de negocio en profit@k, lift@k o ganancia incremental, respetando ventanas temporales.

Considerar un set de estrategias:

Si alguien trabaja en política pública, me gustaría saber qué señales indirectas usan para ordenar sus modelos sin caer en circularidad. Si alguien trabaja en ecommerce u otra industria, cómo definen métricas cuando no hay experimento y cómo separan propensión de efecto incremental. Y si alguien ya usa LLM para diseñar búsquedas de hiperparámetros, feliz de leerlo 🤩.

La optimización de hiperparámetros no es el centro del problema. El centro es la decisión que viene después del ranking. En política pública, una mala prelación puede dañar legitimidad. En industrias, puede destruir margen. En ambos casos, ordenar bien importa más que declarar ganador a un algoritmo.

Referencias

• Ament, Sebastian; Daulton, Samuel; Eriksson, David; Balandat, Maximilian; Bakshy, Eytan. Unexpected Improvements to Expected Improvement for Bayesian Optimization, NeurIPS 2023.
• Balandat, Maximilian et al. BoTorch: A Framework for Efficient Monte-Carlo Bayesian Optimization, NeurIPS 2020.
• Bergstra, James; Bengio, Yoshua. Random Search for Hyper-Parameter Optimization, JMLR 2012.
• Bischl, Bernd et al. Hyperparameter Optimization: Foundations, Algorithms, Best Practices and Open Challenges, WIREs Data Mining and Knowledge Discovery, 2023. Versión abierta en arXiv.
• Caruana, Rich et al. Intelligible Models for HealthCare: Predicting Pneumonia Risk and Hospital 30-day Readmission, KDD 2015.
• H2O.ai. Grid (Hyperparameter) Search, documentación oficial.
• H2O.ai. XGBoost, documentación oficial.
• InterpretML. Explainable Boosting Machine y Hyperparameters, documentación oficial.
• Lindauer, Marius; Eggensperger, Katharina; Feurer, Matthias; Biedenkapp, André; Deng, Difan; Benjamins, Carolin; Ruhkopf, Tim; Sass, René; Hutter, Frank. SMAC3: A Versatile Bayesian Optimization Package for Hyperparameter Optimization, JMLR 2022.
• Liu, Tennison; Astorga, Nicolás; Seedat, Nabeel; van der Schaar, Mihaela. Large Language Models to Enhance Bayesian Optimization, 2024.
• Ministerio de Desarrollo Social y Familia, BIDAT. Registro Social de Hogares, Muestra diciembre 2025, publicado el 30 de enero de 2026.
• Optuna. Optuna: A Hyperparameter Optimization Framework y GPSampler, documentación oficial.
• Scikit-Optimize. gp_minimize, documentación oficial.
• Villagrán Prieto, Nicolás; Garrido-Merchán, Eduardo C. Default Machine Learning Hyperparameters Do Not Provide Informative Initialization for Bayesian Optimization, 2026, preprint.
• Zhou, Han; Ma, Xingchen; Blaschko, Matthew B. A Corrected Expected Improvement Acquisition Function Under Noisy Observations, 2023.

Este post documenta un análisis reproducible de CASEN 2024 en Julia, con validación cruzada de cifras oficiales públicas en BIDAT y buena trazabilidad del flujo en la repo.

Tres hallazgos para comenzar — estadísticamente robustos:

• Pobreza extrema: La Araucanía 13.0% IC 95 % [11.8%, 14.1%] versus Magallanes 4.2% [3.1%, 5.2%] — brecha de 8.8 pp con CIs no superpuestos.
• Cobertura FONASA: La Araucanía 91.1% [90.2%, 92.0%] versus Metropolitana 75.9% [75.0%, 76.7%] — brecha de 15.2 pp con CIs no superpuestos.
• Educación superior completa: Metropolitana 34.9% [34.0%, 35.7%] versus Maule 20.4% [19.2%, 21.6%] — brecha de 14.5 pp con CIs no superpuestos.

Los IC son del 95 % y fueron calculados por Taylor linearization (wiki) para el diseño muestral complejo de CASEN (estratificado bietápico, ponderadores expr). Que los CIs no se superpongan implica que estas diferencias regionales son estadísticamente significativas al nivel convencional.

Tolerancia al contraste o cotejo con datos oficiales

Todos los resultados fueron contrastados contra las tablas oficiales disponibles en BIDAT.

Tabla 1 — Resultados de validación oficial (BIDAT, CASEN 2024)

La diferencia máxima observada es inferior a 3 millonésimas de punto porcentual, tolerable 😀. Los resultados son numéricamente idénticos a los oficiales.

Cucharada 1: diseño muestral y expansión sin atajos

CASEN 2024 tiene diseño estratificado bietápico probabilístico (nota metodológica BIDAT). Para estimaciones a nivel regional, el factor correcto es expr; para nivel comunal se requiere expc — no son intercambiables. Este análisis usa expr y reporta estimaciones por región con IC 95 % calculados por Taylor linearization sobre el diseño complejo (estratos, UPM/PSU y pesos/factores).

Población representada en esta ejecución (suma de expr): 20.13 millones de personas (un trabajo pendiente es evaluar el impacto de nuevo Censo 2024 en lugar de proyecciones sobre Censo 2017).

# Especificación del diseño muestral CASEN 2024
design = (
    weight = :expr,     # factor de expansión regional
    strata = :estrato,  # estrato de muestreo
    psu    = :cod_upm,  # unidad primaria de muestreo (UPM)
    domain = :region,   # dominio de estimación
)

Cobertura por dimensión analizada:

Tabla 2 — Variables CASEN 2024 utilizadas y población objetivo

Resultados nacionales ponderados

Los porcentajes siguientes corresponden a proporciones ponderadas con expr, validadas contra datos oficiales en BIDAT. La diferencia con los valores oficiales es < 3×10⁻⁶ pp.

Tabla 3 — Distribución nacional ponderada (CASEN 2024, principales categorías)

Cucharada 2: el flujo técnico en Julia

El pipeline corre de punta a punta con julia --project=. scripts/run_all.jl (orquestador). Las dos piezas de código más relevantes para reproducir y “auditar” estos resultados son el algoritmo de asignación de celdas y la especificación del diseño muestral (ambos en el repositorio de gitlab/github).

Taylor linearization: SE e IC del diseño complejo

Se implementó el estimador de Taylor para proporciones en dominios (regiones). La variable linearizada para la proporción $\hat{p}_d$ en dominio $d$ es:

La varianza se estima con la fórmula del diseño estratificado por conglomerados:

# Varianza Taylor linearization (estratificado, PSU)
# e_{hi} = suma de w_j * z_j por PSU i en estrato h
var_total = sum over strata h:
    (n_h / (n_h - 1)) * sum_i (e_{hi} - mean(e_h))^2

se    = sqrt(var_total)
ci_lo = clamp(p̂ - 1.96 * se, 0.0, 1.0)
ci_hi = clamp(p̂ + 1.96 * se, 0.0, 1.0)

Se usan todos los PSU del diseño (incluidos los fuera del dominio, con $z_j = 0$), lo que es correcto para estimación de dominio aleatorio. El SE mediano regional es 1.66 pp de ancho de IC; el máximo es 5.76 pp (regiones pequeñas con categorías de baja prevalencia).

Próxima entrada, en algún momento 👀 — Jackknife y Bootstrap para CASEN como contraste: TSL es una aproximación de primer orden óptima para medias y proporciones, pero para estadísticos no lineales (Gini, medianas, razones de cuantiles) puede sub-estimar la varianza. El repositorio de código incluye la teoría y el código Julia en desarrollo para contrastar TSL con Jackknife (delete-1) y Bootstrap — entrada futura de esta serie, no lo he revisado en profundidad.

Resto Mayor o “Largest remainder”: por qué importa en un waffle chart

Un waffle chart de 100 celdas exige que las proporciones sumen exactamente 100 enteros. El redondeo directo introduce errores acumulados que hacen que la suma sea 99 o 101. Este flujo usa el algoritmo de largest remainder, que garantiza la suma exacta introduciendo una imprecisión en post de la visualización (tomenlo como una choreza visual solamente):

"""
Asigna `n_cells` celdas enteras a proporciones `p` usando largest-remainder.
Garantiza que sum(cells) == n_cells exactamente.
"""
function allocate_cells(p::AbstractVector{<:Real}, n_cells::Int = 100)
    raw    = p .* n_cells
    floors = floor.(Int, raw)
    remain = raw .- floors
    deficit = n_cells - sum(floors)
    # Asigna celdas restantes a las proporciones con mayor remainder
    idx = sortperm(remain, rev=true)[1:deficit]
    floors[idx] .+= 1
    return floors
end

Validado con tests unitarios: allocate_cells([0.5, 0.3, 0.2], 100) == [50, 30, 20].

Reproducibilidad

# Requisitos: Julia 1.10+
git clone <repo>
cd casen2024/julia_viz
julia --project=. -e "using Pkg; Pkg.instantiate()"
julia --project=. scripts/run_all.jl

El flujo genera hartos elementos (tablas CSV, gráficos PNG, logs de auditoría de cada insumo). El archivo Manifest.toml fija las versiones exactas de todas las dependencias (ocupé Julia 1.10).

Cucharada 3: evidencia visual

Composición nacional (Gráficos 1–3)

Cada waffle representa 100 celdas asignadas por “largest remainder” sobre las proporciones ponderadas.

Brechas regionales (Gráficos 4–6)

Cada panel usa un eje ajustado al rango de su propia categoría (no escala global compartida), lo que permite visualizar diferencias que se aplanan si todas las categorías comparten el mismo eje. Las barras horizontales son IC 95 % calculados por Taylor linearization. El punto vacío (○) marca la referencia nacional en cada panel (con su CI).

Brechas con IC 95 % — todas estadísticamente robustas

Tabla 4 — Brechas regionales con IC 95 % por Taylor linearization (CASEN 2024)

En todos los casos los IC no se superponen: las brechas son estadísticamente significativas al 5 %. IC calculados por Taylor linearization sobre diseño complejo (estratos, UPM/PSU, expr).

Cierre: tres preguntas para quienes usan la encuesta

Si usas CASEN 2024 para caracterización territorial u otros usos donde variables a nivel regional son relevantes, piensalo dos veces antes de usar un dato puntual (sin su intervalo de confianza):

1. ¿Tus resultados están validados contra BIDAT y tienen IC de diseño? Una diferencia de más de 1×10⁻⁵ pp respecto a las tablas oficiales no es técnica: es de proceso. Y sin IC de diseño complejo, una brecha de 8 pp puede parecer evidencia cuando es ruido en regiones pequeñas.
2. ¿Estás usando el factor de expansión correcto? expr es el apropiado para región; expc para comuna. No son intercambiables y usar el incorrecto sesga las estimaciones de cobertura.
3. ¿Tu análisis es reproducible? Un flujo que no puede ser auditado no puede ser defendido frente a una contraparte técnica ni actualizado cuando salga CASEN 2026.

Los IC aquí incorporados son de diseño complejo (Taylor linearization), no asintóticos simples. Cubren la varianza de muestreo pero no el error de no respuesta ni la subcobertura. Para inferencia causal entre subpoblaciones se requiere diseño adicional.