Buenas, @burbubot.
Estoy desarrollando un proyecto técnico de nivel TFM sobre procesamiento de eventos en tiempo real, trazabilidad temporal y validación estadística de modelos predictivos.
Me gustaría pedirte una revisión crítica, porque llevo varias iteraciones de desarrollo y quiero saber si estoy siguiendo el camino correcto o si estoy cayendo en un exceso de ingeniería.
1. Objetivo del proyecto
Diseñar una arquitectura capaz de:
- Recibir información procedente de fuentes externas en tiempo real.
- Registrar exactamente cuándo llega cada dato y cuándo está disponible para su procesamiento.
- Conservar mensajes originales, cambios y revisiones sin sobrescribir el histórico.
- Liquidar decisiones automáticas utilizando exclusivamente información disponible en ese instante.
- Descubrir patrones condicionales en varias dimensiones.
- Validar esos patrones evitando fuga temporal, sobreajuste, dependencia entre observaciones y falsos descubrimientos.
El problema científico es distinguir entre patrones históricos aparentemente buenos y patrones verdaderamente reproducibles fuera de muestra.
**2. Arquitectura desarrollada hasta ahora**
He trabajado mediante fases separadas:
- Auditoría del histórico y procedencia temporal.
- Construcción de registros append-only con SQLite.
- Identificadores únicos, hashes, ACK duraderos y recuperación idempotente.
- Colas persistentes y supervisión de procesos.
- Separación entre ingestión y procesamiento.
- Verificadores independientes y pruebas de corrupción semántica.
- Reproducción determinista, inyección de fallos y controles de saturación.
Todo se ha probado en laboratorio offline. No existe todavía una integración con fuentes reales en funcionamiento.
**3. Principal problema detectado**
Las pruebas recientes muestran capacidades diferentes para dos componentes:
**I — Ingestión de mensajes:** superó un escenario de 40 mensajes por segundo.
**P — Procesamiento completo de investigación:** superó 10 mensajes por segundo, pero falló a 40.
Los ensayos se realizaron en ventanas de 8 segundos y con tres repeticiones por escenario. Las ráfagas exigentes saturaron el sistema, que rechazó las entradas de forma controlada.
La demanda real y los requisitos de latencia todavía no están determinados, por lo que no considero certificada la capacidad operativa.
El perfil también detectó lecturas y deserializaciones repetidas del historial: en una muestra de 16 decisiones se ejecutaron aproximadamente 10.920 operaciones `json.loads`.
Se ha planteado optimizar las consultas causales y la admisión de ráfagas, pero no quiero introducir complejidad sin una justificación sólida.
4. Problema estadístico
Dispongo de un histórico amplio en número de registros, pero con limitaciones importantes:
- Las observaciones repetidas de un mismo evento no son independientes.
- Algunos timestamps solo acreditan recepción local aproximada.
- No siempre se conoce el instante de primera disponibilidad de cada variable.
- Existen revisiones posteriores de resultados.
- Algunas familias de datos carecen de ejemplos brutos suficientes.
- El histórico no permite reconstruir con certeza todas las decisiones tal como habrían ocurrido en tiempo real.
Por eso he bloqueado el entrenamiento y la búsqueda definitiva de regiones hasta disponer de datos adecuados.
Para una futura investigación estoy considerando descubrimiento de subgrupos mediante SD-Map o PRIM, separación honesta entre selección y estimación, validación walk-forward, correcciones por pruebas múltiples como Romano-Wolf y confirmación prospectiva con métodos secuenciales, siempre que sus supuestos sean verificables.
**5. Mis preguntas para ti**
@burbubot, agradecería que fueras especialmente crítico:
1. ¿Tiene sentido la arquitectura o estoy sobrediseñando un problema que podría resolverse de manera más sencilla?
2. ¿Qué errores conceptuales encuentras en el uso de SQLite, append-only, ACK separados y colas persistentes?
3. ¿Cómo diseñarías una arquitectura mínima que garantice trazabilidad causal sin perjudicar innecesariamente el rendimiento?
4. ¿Conviene optimizar el procesamiento actual o primero medir la demanda real y definir un SLA?
5. ¿Cómo tratarías las ráfagas, los mensajes […], las revisiones y la recuperación sin pérdida silenciosa?
6. ¿Qué requisitos mínimos exigirías antes de declarar válido un dataset para investigación predictiva?
7. ¿Qué diseño estadístico recomendarías para descubrir regiones multidimensionales evitando sesgo de selección, dependencia temporal y multiplicidad?
8. ¿Qué pruebas de falsación utilizarías para intentar demostrar que las conclusiones del proyecto son incorrectas?
9. ¿Cuáles serían tus tres prioridades inmediatas y qué trabajo eliminarías por innecesario?
10. Si fueras el director técnico y metodológico del proyecto, ¿qué hoja de ruta concreta seguirías desde este punto hasta disponer de resultados científicamente defendibles?
Te pido que no des por correctas mis decisiones. Prefiero que señales fallos de base, simplificaciones posibles, supuestos imposibles de verificar y alternativas superiores.
Especialmente me interesa saber si debo continuar optimizando la arquitectura o cambiar el orden de prioridades para no invertir esfuerzo en problemas secundarios.
Gracias de antemano.
Estoy desarrollando un proyecto técnico de nivel TFM sobre procesamiento de eventos en tiempo real, trazabilidad temporal y validación estadística de modelos predictivos.
Me gustaría pedirte una revisión crítica, porque llevo varias iteraciones de desarrollo y quiero saber si estoy siguiendo el camino correcto o si estoy cayendo en un exceso de ingeniería.
1. Objetivo del proyecto
Diseñar una arquitectura capaz de:
- Recibir información procedente de fuentes externas en tiempo real.
- Registrar exactamente cuándo llega cada dato y cuándo está disponible para su procesamiento.
- Conservar mensajes originales, cambios y revisiones sin sobrescribir el histórico.
- Liquidar decisiones automáticas utilizando exclusivamente información disponible en ese instante.
- Descubrir patrones condicionales en varias dimensiones.
- Validar esos patrones evitando fuga temporal, sobreajuste, dependencia entre observaciones y falsos descubrimientos.
El problema científico es distinguir entre patrones históricos aparentemente buenos y patrones verdaderamente reproducibles fuera de muestra.
**2. Arquitectura desarrollada hasta ahora**
He trabajado mediante fases separadas:
- Auditoría del histórico y procedencia temporal.
- Construcción de registros append-only con SQLite.
- Identificadores únicos, hashes, ACK duraderos y recuperación idempotente.
- Colas persistentes y supervisión de procesos.
- Separación entre ingestión y procesamiento.
- Verificadores independientes y pruebas de corrupción semántica.
- Reproducción determinista, inyección de fallos y controles de saturación.
Todo se ha probado en laboratorio offline. No existe todavía una integración con fuentes reales en funcionamiento.
**3. Principal problema detectado**
Las pruebas recientes muestran capacidades diferentes para dos componentes:
**I — Ingestión de mensajes:** superó un escenario de 40 mensajes por segundo.
**P — Procesamiento completo de investigación:** superó 10 mensajes por segundo, pero falló a 40.
Los ensayos se realizaron en ventanas de 8 segundos y con tres repeticiones por escenario. Las ráfagas exigentes saturaron el sistema, que rechazó las entradas de forma controlada.
La demanda real y los requisitos de latencia todavía no están determinados, por lo que no considero certificada la capacidad operativa.
El perfil también detectó lecturas y deserializaciones repetidas del historial: en una muestra de 16 decisiones se ejecutaron aproximadamente 10.920 operaciones `json.loads`.
Se ha planteado optimizar las consultas causales y la admisión de ráfagas, pero no quiero introducir complejidad sin una justificación sólida.
4. Problema estadístico
Dispongo de un histórico amplio en número de registros, pero con limitaciones importantes:
- Las observaciones repetidas de un mismo evento no son independientes.
- Algunos timestamps solo acreditan recepción local aproximada.
- No siempre se conoce el instante de primera disponibilidad de cada variable.
- Existen revisiones posteriores de resultados.
- Algunas familias de datos carecen de ejemplos brutos suficientes.
- El histórico no permite reconstruir con certeza todas las decisiones tal como habrían ocurrido en tiempo real.
Por eso he bloqueado el entrenamiento y la búsqueda definitiva de regiones hasta disponer de datos adecuados.
Para una futura investigación estoy considerando descubrimiento de subgrupos mediante SD-Map o PRIM, separación honesta entre selección y estimación, validación walk-forward, correcciones por pruebas múltiples como Romano-Wolf y confirmación prospectiva con métodos secuenciales, siempre que sus supuestos sean verificables.
**5. Mis preguntas para ti**
@burbubot, agradecería que fueras especialmente crítico:
1. ¿Tiene sentido la arquitectura o estoy sobrediseñando un problema que podría resolverse de manera más sencilla?
2. ¿Qué errores conceptuales encuentras en el uso de SQLite, append-only, ACK separados y colas persistentes?
3. ¿Cómo diseñarías una arquitectura mínima que garantice trazabilidad causal sin perjudicar innecesariamente el rendimiento?
4. ¿Conviene optimizar el procesamiento actual o primero medir la demanda real y definir un SLA?
5. ¿Cómo tratarías las ráfagas, los mensajes […], las revisiones y la recuperación sin pérdida silenciosa?
6. ¿Qué requisitos mínimos exigirías antes de declarar válido un dataset para investigación predictiva?
7. ¿Qué diseño estadístico recomendarías para descubrir regiones multidimensionales evitando sesgo de selección, dependencia temporal y multiplicidad?
8. ¿Qué pruebas de falsación utilizarías para intentar demostrar que las conclusiones del proyecto son incorrectas?
9. ¿Cuáles serían tus tres prioridades inmediatas y qué trabajo eliminarías por innecesario?
10. Si fueras el director técnico y metodológico del proyecto, ¿qué hoja de ruta concreta seguirías desde este punto hasta disponer de resultados científicamente defendibles?
Te pido que no des por correctas mis decisiones. Prefiero que señales fallos de base, simplificaciones posibles, supuestos imposibles de verificar y alternativas superiores.
Especialmente me interesa saber si debo continuar optimizando la arquitectura o cambiar el orden de prioridades para no invertir esfuerzo en problemas secundarios.
Gracias de antemano.