| # Diseño Arquitectónico: De Drosophila a OpenSkyNet |
| ## Nota de diseño empírico, no validación cerrada |
|
|
| **Ubicación:** `~/openskynet/MODELADO_MATEMATICO_DROSOPHILA.md` |
|
|
| **Propósito:** Este documento ya no debe leerse como "ground truth final" ni como manifiesto cerrado. Debe leerse como una **nota de diseño empírico**: resume qué parte de la evidencia biológica y matemática sí es útil para OpenSkyNet, qué parte es extrapolación razonable, y qué parte todavía no está validada ni implementada. |
|
|
| ## Veredicto general |
|
|
| La hipótesis central: |
|
|
| `estado causal persistente + topología esparza y dirigida + mantenimiento local` |
|
|
| está **parcialmente respaldada** por la literatura y **sí** es una buena directiva de diseño. |
|
|
| Lo que **no** está respaldado hoy: |
|
|
| - que el artículo de Drosophila valide directamente `Mamba-3` |
| - que valide `Nested Learning` como solución general de entrenamiento |
| - que invalide por sí solo a los Transformers |
| - que autorice hablar de "yo", "voluntad" o "vida" como propiedades ya demostradas |
|
|
| La regla correcta es: |
|
|
| - usar la biología como restricción y fuente de hipótesis |
| - no usarla como licencia para vender más de lo que la evidencia permite |
|
|
| --- |
|
|
| ## PARTE I: Qué valida realmente Drosophila |
|
|
| ### 1. Topología esparza y dirigida |
|
|
| El conectoma de Drosophila muestra que un sistema cognitivo corporizado real puede operar sobre una red: |
|
|
| - fuertemente esparza |
| - dirigida |
| - modular |
| - causal en el tiempo |
|
|
| La lección útil no es "copiar la mosca", sino esta: |
|
|
| - no toda inteligencia requiere conectividad densa global |
| - la estructura del grafo importa |
| - el ruteo causal local puede ser suficiente para tareas sensorimotoras complejas |
|
|
| ### 2. Dinámica continua con estado interno |
|
|
| El modelo `Leaky Integrate-and-Fire` usa un estado que evoluciona en el tiempo: |
|
|
| `tau_m dV/dt = -(V - E_L) + R_m I` |
|
|
| Eso sí respalda una idea importante: |
|
|
| - la computación puede vivir en la evolución causal de un estado interno |
| - no hace falta reconstruir todo el pasado como contexto textual en cada paso |
|
|
| ### 3. Suficiencia de un pase causal hacia adelante |
|
|
| El artículo apoya una arquitectura donde la actividad se propaga sobre el grafo desde el pasado hacia el futuro. Eso es relevante para OpenSkyNet porque fortalece esta directiva: |
|
|
| - mover más mantenimiento interno a reglas locales verificables |
| - depender menos de reconsultar al LLM para cada decisión administrativa |
|
|
| ### 4. Qué no valida |
|
|
| El artículo **no** demuestra directamente: |
|
|
| - aprendizaje hebbiano online en ejecución |
| - `Nested Learning` como algoritmo general listo para producción |
| - `Mamba-3` como reemplazo de un LLM deliberativo |
| - una teoría completa del `self` |
| - una teoría completa de causalidad semántica o social |
|
|
| La traducción correcta es: |
|
|
| - **sí** respalda una familia de diseños |
| - **no** cierra el problema arquitectónico completo |
|
|
| --- |
|
|
| ## PARTE II: Qué significa esto para OpenSkyNet |
|
|
| ### 1. Qué ya existe en OpenSkyNet |
|
|
| Hoy OpenSkyNet ya tiene piezas compatibles con esa dirección: |
|
|
| - estado persistente de sesión |
| - kernel causal con goals, outcomes y tensión |
| - grafo causal mínimo entre goals y archivos |
| - mantenimiento ejecutivo local sin llamada al LLM en varios casos verificables |
|
|
| Eso significa que OpenSkyNet ya está recorriendo la parte defendible del camino: |
|
|
| - menos recálculo textual |
| - más continuidad operativa |
| - más causalidad local |
| - más mantenimiento determinista |
|
|
| ### 2. Qué no existe todavía |
|
|
| OpenSkyNet **todavía no** tiene: |
|
|
| - un motor `LIF` o `SSM` real en la ruta crítica |
| - aprendizaje local online sobre pesos |
| - una topología block-sparse de cómputo neuronal viva |
| - un world model predictivo serio sobre el entorno |
|
|
| Por tanto, no es correcto decir que OpenSkyNet ya implementa un "cerebro reptiliano" o una "vida matemática". |
|
|
| ### 3. Arquitectura híbrida correcta |
|
|
| La formulación operativa correcta hoy es esta: |
|
|
| - el LLM sigue siendo el subsistema deliberativo de alto nivel |
| - el kernel causal de OpenSkyNet actúa como capa ejecutiva persistente |
| - el objetivo no es matar al LLM de inmediato |
| - el objetivo es reducir progresivamente su papel en tareas que puedan resolverse con estado local, memoria exacta y reglas verificables |
|
|
| En otras palabras: |
|
|
| `OpenSkyNet no debe saltar directo a un cerebro biológico sintético; debe convertirse primero en un sistema ejecutivo causal más fuerte.` |
|
|
| --- |
|
|
| ## PARTE III: Extrapolaciones permitidas y extrapolaciones peligrosas |
|
|
| ### Extrapolaciones permitidas |
|
|
| Estas sí son razonables como hipótesis de trabajo: |
|
|
| - usar grafos esparzos de dependencias en vez de contexto plano |
| - mantener estado persistente explícito |
| - usar actualizaciones locales event-driven |
| - separar memoria episódica exacta de la inferencia deliberativa |
| - investigar un pequeño controlador dinámico encima del LLM |
|
|
| ### Extrapolaciones peligrosas |
|
|
| Estas deben evitarse por ahora: |
|
|
| - declarar que `x(t)` "es" el yo |
| - declarar que un umbral de activación equivale a voluntad |
| - presentar `Mamba/LIF` como validación cerrada por analogía |
| - exigir una matriz conectómica biológica completa como siguiente paso inmediato |
| - introducir optimizadores locales o plasticidad online sin una métrica viva y una ruta de rollback clara |
|
|
| --- |
|
|
| ## PARTE IV: Directiva ingenieril correcta |
|
|
| ### 1. Siguiente pieza defendible |
|
|
| La siguiente pieza defendible para OpenSkyNet **no** es una "mosca digital". |
|
|
| La siguiente pieza defendible es: |
|
|
| - un ejecutivo causal más fuerte |
| - con estado persistente |
| - con grafo esparzo de dependencias |
| - con acciones de mantenimiento local verificables |
| - y con menos llamadas al LLM cuando no hacen falta |
|
|
| ### 2. Orden correcto de construcción |
|
|
| #### Etapa A: Consolidar el ejecutivo causal |
|
|
| Prioridad: |
|
|
| - goals persistentes |
| - tensiones verificadas |
| - dependencias explícitas |
| - mantenimiento local determinista |
|
|
| #### Etapa B: Memoria episódica exacta |
|
|
| Prioridad: |
|
|
| - episodios direccionables |
| - relación entre goal, acción, evidencia y resultado |
| - recuperación exacta, no solo semántica |
|
|
| #### Etapa C: Controlador dinámico pequeño |
|
|
| Solo después: |
|
|
| - un pequeño modelo de estado sobre eventos |
| - no sobre texto crudo |
| - con métricas claras de continuidad, causalidad y ahorro de llamadas |
|
|
| #### Etapa D: Investigación de cómputo esparzo real |
|
|
| Recién ahí tiene sentido explorar: |
|
|
| - block-sparse compute |
| - SSM/LIF pequeño |
| - plasticidad local acotada |
|
|
| ### 3. Restricción metodológica |
|
|
| Toda pieza nueva debe cumplir esto: |
|
|
| - hipótesis falsable |
| - métrica antes/después |
| - rollback simple |
| - utilidad operativa demostrable |
|
|
| Si no cumple eso, no entra al runtime principal. |
|
|
| --- |
|
|
| ## PARTE V: Métricas correctas para OpenSkyNet |
|
|
| Las métricas relevantes no son "parece más vivo", sino estas: |
|
|
| - `false_success_rate` |
| - `goal_recovery_after_restart` |
| - `causal_consistency_after_failure` |
| - `mean_llm_calls_per_task` |
| - `useful_background_actions` |
| - `spurious_action_rate` |
|
|
| Si una propuesta inspirada en Drosophila no mejora al menos una de estas sin degradar el resto, entonces sigue siendo una analogía elegante, no una mejora real. |
|
|
| --- |
|
|
| ## PARTE VI: Conclusión práctica |
|
|
| El artículo de Drosophila sí importa. Pero su aporte correcto para OpenSkyNet es este: |
|
|
| - validar la importancia de topologías esparzas y causales |
| - reforzar la idea de estado persistente |
| - justificar más mantenimiento local y menos dependencia de contexto textual global |
|
|
| No autoriza todavía: |
|
|
| - declarar que ya entendimos el self |
| - prometer conciencia digital |
| - ni saltar directo a una arquitectura conectómica completa |
|
|
| La conclusión operativa correcta es: |
|
|
| `usar Drosophila como ancla para construir un mejor ejecutivo causal, no como excusa para sobrediseñar una mente biológica ficticia dentro del runtime.` |
|
|
