Qué sobrevive cuando una pintura se convierte en sonido
Seis maneras de contar el mismo proyecto — desde una frase para quien no sabe nada, hasta la arquitectura formal para un revisor de ICAD. Todas describen la misma idea central: pasar de una caja negra a un proceso auditable.
Y = g(X) + R — RMA audita si R todavía contiene estructura
La pregunta que origina todo
¿Qué información de una pintura permanece cuando la convertimos en una experiencia sonora?
Una pintura tiene muchas propiedades medibles: distribución de color, variación cromática, complejidad espacial, bordes, textura, estructura fractal, organización de regiones. El pipeline ARGIRA toma esas características visuales y las transforma en parámetros acústicos: frecuencia, timbre, armónicos, modulación, ritmo, espacialización.
Pero aparece una pregunta científica más profunda: cuando una imagen pasa por una transformación visual → acústica, ¿qué parte de su estructura sigue presente y puede ser recuperada? Ahí aparece RMA.
¿Qué es RMA?
RMA significa Residual Model Auditor. Si tenemos una transformación:
Imagen → ARGIRA → Sonido
podemos construir modelos que intenten explicar el resultado:
Características visuales → Parámetro acústico
El modelo explica una parte. Pero queda un residuo:
Residuo = resultado real − resultado explicado
La pregunta de RMA es siempre la misma: ¿el residuo todavía contiene información estructural?
sin estructura el modelo explica bien la relación.
predecible queda información que el modelo no capturó.
Eso permite estudiar las limitaciones reales del mapeo, no solo su capacidad predictiva.
El Explorer
El HTML autocontenido es una interfaz para explorar todo este sistema. No es solamente una visualización: es una capa de investigación donde se conectan el pipeline, los datos, la evidencia, las hipótesis y los análisis.
CAPTURA — pantalla de bienvenida del Explorer
Vista general del HTML abierto en el navegador, mostrando el conjunto de pestañas (Network, Inspector, Evidence, Research, Analysis).
¿Qué hace especial a ARGIRA ↔ RMA?
No es solamente "una pintura produce un sonido" — eso ya sería una sonificación. La pregunta más profunda es:
¿Qué estructura sobrevive cuando una representación artística cambia de dominio?
ARGIRA estudia la traducción. RMA estudia la información que permanece después de esa traducción. El Explorer une ambas cosas en un instrumento donde se puede ver, analizar y auditar el proceso completo.
Para presentar en el póster · ICAD 2026
La versión de dos minutos
ARGIRA ↔ RMA es un instrumento de investigación que estudia qué ocurre cuando transformamos una pintura en sonido.
ARGIRA es un pipeline de sonificación: extrae características visuales de una imagen —como distribución de color, complejidad espacial, densidad de bordes o dimensión fractal— y las convierte en parámetros acústicos, creando una representación sonora de la obra.
Pero la pregunta principal no es solamente cómo generar un sonido a partir de una imagen. La pregunta es:
¿Qué información de la imagen permanece después de esa transformación?
Para estudiar esto desarrollé RMA, Residual Model Auditor. RMA analiza la relación entre las características visuales de entrada y los parámetros acústicos de salida, estudiando también la información que queda en los residuos de los modelos. Si después de explicar el mapeo todavía queda estructura recuperable, significa que existe información que la transformación no ha capturado completamente.
El ARGIRA ↔ RMA Knowledge Explorer reúne todo este proceso en una aplicación web autocontenida. Permite visualizar la red de dependencias entre características visuales y parámetros acústicos, inspeccionar la procedencia de cada variable, separar evidencia validada de hipótesis exploratorias y ejecutar análisis reproducibles directamente en el navegador.
Frase ancla para la presentación: pasar de una caja negra —una imagen que entra y un sonido que sale— a un proceso auditable donde podemos estudiar qué se conserva, qué se pierde y qué nuevas estructuras pueden emerger durante una traducción entre dominios. Es el salto conceptual de ARGIRA hacia RMA — conviene enfatizarla.
ARGIRA no es solamente un sistema de sonificación. Es una plataforma para investigar la relación entre representación visual, sonido e información estructural.
Póster ARGIRA — ICAD 2026, 31st International Conference on Auditory Display (28–31 julio 2026)
Versión impresa/digital real del póster presentado. Incluye el resumen de correlaciones (hue_std → Ds, r=0.887, N=45; ampliado a N=74, r=0.923), las extensiones post-revisión y el QR al póster interactivo.
Presentación oral extendida · ICAD 2026
La versión de diez minutos
1. Introducción: la pregunta de investigación
ARGIRA nace de una pregunta sencilla pero profunda:
¿Qué ocurre con la información de una imagen cuando la transformamos en sonido?
Una pintura contiene múltiples niveles de información: color, distribución espacial, textura, complejidad, organización de formas y patrones. Una sonificación convierte algunas de esas características visuales en parámetros acústicos.
En ARGIRA, una imagen no se traduce directamente en un sonido de forma arbitraria. Primero se extraen características visuales cuantificables y después estas alimentan un pipeline que genera parámetros acústicos: determinadas propiedades del color, la estructura espacial o la complejidad visual pueden influir en frecuencia, timbre, ritmo, modulación o espacialización.
Pero la pregunta científica más interesante aparece después, cuando la imagen ya cambió de dominio: ¿qué información permanece?
¿El sonido conserva estructura de la imagen original?
¿Existe información que se pierde?
¿Existen relaciones que el mapeo inicial no explica completamente?
Para responder a estas preguntas desarrollé RMA: Residual Model Auditor.
2. Del mapeo visual-acústico a la auditoría residual
Un sistema de sonificación puede verse como una función:
Imagen → ARGIRA → Parámetro acústico
Podemos intentar explicar esa relación mediante modelos estadísticos. El modelo aprende una parte de la transformación:
Pero siempre existe una diferencia entre el valor observado y el valor predicho. Ese resto es el residuo. RMA estudia precisamente ese residuo — la pregunta no es solo "¿qué tan bien predice el modelo?", sino algo más profundo:
Después de explicar la relación principal, ¿queda todavía información estructurada?
sin estructura el modelo captura adecuadamente la relación.
predecible existe información que el modelo no está representando completamente.
Esto permite estudiar limitaciones del mapeo y no solamente su capacidad predictiva.
3. El Knowledge Explorer
Para hacer este proceso transparente desarrollé el ARGIRA ↔ RMA Knowledge Explorer: una aplicación web autocontenida que funciona completamente en el navegador. Su objetivo no es solo mostrar resultados, sino permitir inspeccionar todo el camino desde la imagen hasta el análisis estadístico.
La arquitectura está dividida en tres capas principales:
Evidence — resultados auditados.
Research — exploración de hipótesis.
Analysis — laboratorio reproducible.
4. Evidence: resultados auditados
La primera capa es Evidence. Aquí se encuentran únicamente resultados confirmados y auditados — es una capa de solo lectura.
La razón es metodológica: una herramienta interactiva puede generar muchas exploraciones, pero una exploración no debe convertirse automáticamente en evidencia. Por eso Evidence permanece separada. Los resultados confirmados tienen una identidad clara: sabemos de dónde vienen, cómo fueron obtenidos y qué nivel de validación tienen.
5. Research: exploración de hipótesis
La segunda capa es Research. Esta zona permite formular preguntas nuevas, por ejemplo:
¿Existe una relación inesperada entre determinadas características visuales y parámetros acústicos?
¿Aparecen patrones que merecen una investigación posterior?
Pero una hipótesis no es una evidencia. Research permite explorar sin contaminar los resultados confirmados: una hipótesis solamente puede pasar a Evidence después de una validación independiente.
6. Analysis: el laboratorio reproducible
La tercera capa es Analysis. Aquí el usuario puede ejecutar el motor RMA directamente, usando:
el corpus incluido de 227 pinturas;
o un dataset externo proporcionado por el usuario.
El análisis se ejecuta localmente mediante Pyodide en el navegador. Esto significa que los resultados de una exploración permanecen en la sesión del usuario y no modifican la evidencia almacenada. La herramienta permite generar informes y exportar resultados para continuar el análisis fuera del Explorer.
7. La red de dependencias: hacer visible la transformación
Una de las partes centrales del Explorer es el Design Graph. Este grafo representa cómo una característica visual atraviesa el pipeline hasta convertirse en un parámetro acústico — por ejemplo, una propiedad de color puede alimentar una función del pipeline, que genera un parámetro acústico concreto.
La red permite responder preguntas como:
¿De dónde viene este parámetro?
¿Qué variables lo afectan?
¿Es una relación directa o derivada?
¿Existe evidencia de sensibilidad?
La intención es eliminar la caja negra. En lugar de ver solamente imagen → sonido, podemos estudiar todo el camino intermedio.
Design Graph real del Explorer (v1.6)
Grosor de línea = sensibilidad ante perturbación ±5% (ver bloque 4, "Sensitivity Evidence"). La conexión más gruesa del grafo es fractal_D → mod_depth (14.2), la mayor sensibilidad medida en todo el sistema. Nodos en gris (roughness, value_mean, golden_distance) son features sin conexión marcada o de menor peso relativo.
8. El inspector de nodos: trazabilidad
Cada elemento del grafo puede inspeccionarse. El sistema muestra:
nombre
categoría
unidad
rango
función o módulo de origen
estado de validación
Esto convierte cada variable en un objeto trazable. No solamente sabemos qué variable existe, sino qué papel cumple dentro del sistema.
9. Reproducibilidad
Otro objetivo fundamental fue que el trabajo pudiera ser inspeccionado por otras personas. Por eso el artefacto incluye:
la aplicación completa
el dataset del corpus
plantillas CSV
ejemplos de análisis
informes HTML y PDF
exportación del grafo
El archivo principal contiene todo lo necesario para explorar el sistema sin instalar un servidor ni reconstruir manualmente el entorno.
10. Idea final
ARGIRA comenzó como un sistema de sonificación de pinturas. Pero con RMA se convirtió en algo diferente: un instrumento para estudiar qué ocurre cuando una representación cambia de dominio.
La pregunta ya no es solamente ¿cómo convertir una imagen en sonido? La pregunta es:
¿Qué estructura, qué información y qué relaciones sobreviven cuando una imagen se transforma en una experiencia acústica?
El Knowledge Explorer hace visible ese proceso y permite estudiarlo de una manera reproducible, auditable y abierta a nuevas investigaciones.
Explicación técnica para investigadores
La versión técnica
1. Visión general del sistema
ARGIRA ↔ RMA es una arquitectura reproducible para estudiar transformaciones cross-modales entre representación visual y representación acústica. El sistema está compuesto por dos elementos principales:
ARGIRA: un pipeline determinista de sonificación visual-acústica.
RMA (Residual Model Auditor): un framework para auditar qué información estructural permanece después del mapeo.
El objetivo no es únicamente generar una salida acústica a partir de una entrada visual, sino analizar la estructura informacional de la transformación. Formalmente:
X = características visuales extraídas de la imagen
Y = parámetros acústicos generados por ARGIRA
El sistema estudia:
X → f(X) = Y
y posteriormente analiza si una clase de modelos g(X) puede explicar completamente la relación:
Y ≈ g(X)
La diferencia:
R = Y − g(X)
define el residuo que RMA audita.
2. Pipeline ARGIRA
ARGIRA comienza con una imagen. El sistema extrae características visuales que representan diferentes dimensiones de la obra:
estadísticas de color
distribución cromática
entropía
densidad de bordes
complejidad espacial
dimensión fractal
características derivadas de partición espacial
Estas variables entran en el pipeline de sonificación, que las transforma mediante funciones explícitas en parámetros acústicos:
frecuencia base
componentes armónicos
peso de osciladores
modulación
envolvente
tempo
posición espacial
La arquitectura mantiene una separación clara entre: datos de entrada, transformaciones, parámetros generados y salida acústica.
3. Design Graph
El Design Graph representa la estructura computacional del pipeline. No es un grafo conceptual generado manualmente, sino una representación de dependencias extraída del sistema real.
Cada nodo representa un elemento del proceso:
feature visual
variable intermedia
parámetro acústico
componente funcional
Cada conexión representa una dependencia. Esto permite inspeccionar:
qué entradas producen cada salida
qué variables son centrales
qué parámetros dependen de múltiples fuentes
dónde existen transformaciones directas o derivadas
El objetivo es aportar interpretabilidad estructural.
4. Sensitivity Evidence
Las relaciones del grafo se complementan con evidencia de sensibilidad. La sensibilidad se obtiene mediante perturbaciones controladas: ±5% sobre variables de entrada.
Se observa cómo cambia la salida acústica ante esas perturbaciones. La intensidad de una conexión no representa únicamente existencia de una relación, sino magnitud de respuesta bajo una perturbación definida. Esto permite distinguir relaciones presentes de relaciones con impacto cuantificable.
5. Residual Model Auditor (RMA)
RMA evalúa si una hipótesis de modelado captura completamente una transformación. El procedimiento general:
Seleccionar una variable acústica objetivo Y.
Definir variables explicativas X.
Ajustar un modelo g(X).
Obtener predicciones mediante validación cruzada.
Calcular residuos fuera de muestra.
Evaluar si esos residuos conservan estructura.
La utilización de predicciones cross-validation es fundamental porque evita interpretar como información real patrones producidos por ajuste dentro de muestra.
6. Residual predictability
La métrica central es la capacidad de predecir los residuos.
sin estructura si R² residual ≈ 0 → la información restante no presenta estructura recuperable bajo el modelo utilizado.
predecible si R² residual > 0 → existe estructura no explicada.
Esto no significa automáticamente que exista un fenómeno nuevo. Significa que existe información que la hipótesis del modelo no captura. La interpretación requiere análisis adicional.
7. Caso de estudio end-to-end: tempo_bpm ~ fractal_D, hue_std
Para ilustrar el procedimiento de la sección anterior con un resultado real del Explorer, se audita aquí una relación concreta extraída de sonificacion_resultados.csv (n = 227 imágenes).
Hipótesis de modelado. Se plantea si el tempo generado (tempo_bpm) queda explicado por un modelo lineal a partir de dos features visuales: dimensión fractal (fractal_D) y desviación estándar del matiz (hue_std).
Parámetro
Valor
target
tempo_bpm
features
fractal_D, hue_std
modelo
linear
cv_strategy
kfold
n_total / n_clean
227 / 227
coverage
0.7127
residual R²
0.1905
residual_std
0.0639
IBDS
0.2441
Colinealidad. El VIF de ambas features es 1.042, por lo que fractal_D y hue_std aportan información esencialmente independiente: el resultado no es un artefacto de redundancia entre predictores.
Lectura del resultado. Coverage = 0.7127 indica que el modelo lineal explica una fracción sustancial de tempo_bpm. Pero el residual R² = 0.1905 muestra que, incluso tras ese ajuste, el residuo R = Y − g(X) conserva estructura recuperable bajo validación cruzada — no es ruido plano. Según el criterio de la sección 6, esto clasifica la relación como:
estructura parcial el modelo lineal captura parte de la relación, pero deja un residuo predecible: existe información que fractal_D y hue_std por sí solos no explican.
Robustez vía bootstrap. El intervalo de confianza bootstrap (95%, 10 muestras válidas) sobre el residual R² es [0.3839, 0.6368], con media 0.4847. Al excluir el 0, el IC respalda que la señal residual es probablemente real y no un efecto de un fold particular de la validación cruzada — el hallazgo es una candidata razonable para investigación adicional, no una confirmación definitiva.
Fragmento del Design Graph: la arista auditada
Recorte del grafo completo (ver vista 10 min, bloque 7) mostrando solo las dos aristas relevantes para este caso. fractal_D → tempo_bpm tiene grosor 8.23 frente a 1.90 de hue_std → tempo_bpm: la dimensión fractal domina la relación estructural, pero ninguna de las dos, combinadas linealmente, agota la información — de ahí el residual R² > 0.
Nota: este informe se generó automáticamente desde la pestaña 📊 Analysis del Explorer (rma_core.py vía Pyodide, orquestado por analysis_bridge.js) y se conserva como JSON crudo sin reinterpretar, siguiendo la separación Evidence/Research/Analysis descrita a continuación.
8. Separación Evidence / Research / Analysis
La arquitectura incorpora una separación explícita entre estados epistemológicos.
Capa
Características
Evidence
solo lectura · procedencia conocida · no modificable por exploración
Research
generación de preguntas · búsqueda de patrones · no constituye evidencia
Analysis
resultados locales · reproducibles · no promocionados automáticamente
Esta separación evita mezclar exploración con confirmación.
9. Arquitectura del Explorer
El Explorer es una aplicación HTML autocontenida. Incluye:
interfaz visual
lógica de interacción
corpus embebido
motor estadístico ejecutable mediante Pyodide
sistema de exportación
El usuario puede abrir el archivo, inspeccionar la arquitectura, ejecutar análisis y exportar resultados. No requiere infraestructura externa.
Captura real del Explorer — pestaña ▦ Dependency Matrix
Vista real de la interfaz: barra de pestañas (Network, Dependency Matrix, Research Mode, Analysis), buscador, toggle "Evidence Links: off" y la matriz feature × parámetro (15 edges total, 13 auditados con RMA, 2 pendientes de datos, 3 marcados como estructura impuesta).
Cada etapa mantiene una relación explícita con la siguiente. Esto permite auditar no solamente resultados, sino también el camino que los produce.
11. Interpretación científica
ARGIRA ↔ RMA no intenta afirmar que existe una traducción perfecta entre imagen y sonido. El objetivo es estudiar las propiedades de una transformación cross-modal:
qué información se conserva
qué información desaparece
qué información queda oculta para modelos simples
qué estructuras emergen después del mapeo
La contribución metodológica es proporcionar un marco donde una transformación artística pueda ser analizada como un sistema computacional auditable.
En ese sentido, ARGIRA ↔ RMA funciona como un puente entre sonificación, análisis estadístico, reproducibilidad científica y auditoría de modelos.
Nota: la explicación técnica revela algo que quizá no se nota al mirar el HTML: el verdadero producto no es el archivo. El archivo es el contenedor. El producto intelectual es la arquitectura de auditoría de una transformación visual-acústica.
Herramienta de referencia personal
Mapa maestro
No es una explicación para otros, sino algo que puedas mirar y decir "ahora entiendo qué es cada pieza y cómo encaja".
A. La pregunta central
¿Qué información de una imagen sobrevive cuando una transformación la convierte en sonido?
Pregunta: ¿queda información recuperable en el residuo?
D. El explorador — Knowledge Explorer
Es la ventana para estudiar todo. Tiene cuatro grandes funciones:
Ver — Network → "¿Cómo está conectado el sistema?"
Entender — Inspector → "¿Qué es cada elemento y de dónde viene?"
Separar conocimiento — Evidence / Research → "¿Qué sé y qué estoy investigando?"
Experimentar — Analysis → "¿Qué ocurre si pruebo nuevos modelos o datos?"
E. La filosofía del proyecto
No es:
"Una IA que convierte cuadros en música."
Eso sería una descripción superficial.
Es:
"Un marco para estudiar la conservación y pérdida de información durante una transformación entre dominios."
F. Las grandes preguntas abiertas
Aquí empieza la verdadera investigación:
¿Qué características visuales son más estables después del mapeo?
¿Qué parámetros acústicos conservan más información?
¿Cuándo un residuo representa una limitación del modelo y cuándo una propiedad emergente?
¿Qué relaciones sobreviven a validaciones perceptuales humanas?
¿Puede una representación sonora transmitir estructuras visuales sin acceso visual directo?
Guía pestaña por pestaña · v1.6
Guía del Knowledge Explorer
El Explorer real (v1.6) tiene 4 pestañas de nivel superior: 🕸 Network, ▦ Dependency Matrix, 🧪 Research Mode y 📊 Analysis. Esta guía conserva 6 bloques de contenido porque dos de esas pestañas agrupan más de una función: Dependency Matrix cubre tanto el Inspector de nodo como la vista Evidence, y Analysis cubre tanto la ejecución RMA como la exportación de informes. Cada bloque indica a qué pestaña real pertenece.
Introducción
El ARGIRA ↔ RMA Knowledge Explorer es una aplicación web autocontenida diseñada para explorar, auditar y analizar la relación entre características visuales de pinturas y parámetros acústicos generados por el pipeline ARGIRA.
El Explorer organiza el conocimiento en tres niveles conceptuales, repartidos entre sus 4 pestañas:
Pestaña real del Explorer: 🕸 Network (mapeo directo, sin agrupar).
Objetivo: la vista Network muestra el grafo de dependencias del sistema ARGIRA.
¿Cómo llega una característica visual hasta un parámetro acústico?
Qué muestra: cada nodo representa un elemento del sistema (característica visual, variable intermedia, parámetro acústico, componente del pipeline). Las conexiones representan relaciones dentro de la arquitectura.
Cómo leerlo:
hue_std ↓ función ARGIRA ↓ freq_base_hz
Interpretación: la variabilidad del color participa en la generación de un parámetro acústico concreto.
Qué buscar:
nodos centrales
parámetros con múltiples entradas
relaciones directas e indirectas
componentes con evidencia de sensibilidad
Grafo real: ver vista 10 min, bloque 7 "La red de dependencias"
El grafo completo (nodos, conexiones, categorías visual/acústico, grosor = sensibilidad ±5%) está embebido en la vista 10 min. Aquí se resume: hay 11 features visuales y 10 parámetros acústicos; la conexión más sensible es fractal_D → mod_depth (grosor 14.2).
Captura real — pestaña Network, cabecera y grafo completo (abrir imagen)Captura real — pestaña Network, vista con título y leyenda (abrir imagen)
Pestaña 2 — Node Inspector
Pestaña real del Explorer: ▦ Dependency Matrix (el Inspector es la función de detalle-de-nodo dentro de esta pestaña, no una pestaña independiente).
Objetivo: el Inspector convierte cada elemento del grafo en un objeto trazable. No solamente muestra el nombre de una variable, sino su contexto dentro del sistema.
Información disponible por nodo:
nombre
categoría
unidad
rango
origen
función o módulo responsable
estado de validación
Ejemplo: variable fractal_D → representa una medida de complejidad estructural; procede del análisis visual; participa en determinadas transformaciones acústicas.
Importancia científica: permite responder "¿De dónde sale este valor?" y "¿Por qué esta variable participa en este resultado?"
Campo
Valor real (nodo fractal_D)
nombre
fractal_D
categoría
visual
rango observado
1.1161 – 2.0000 (n=227, media 1.732)
origen
análisis visual de la pintura
conexión más sensible
fractal_D → mod_depth (grosor 14.2, la más alta del grafo)
estado de validación
usado como feature en RMA validado (VIF 1.042, sin colinealidad problemática)
Cifras extraídas directamente del dataset real sonificacion_resultados.csv (227 filas) y del grafo de dependencias exportado por el Explorer.
Captura real — pestaña Dependency Matrix (abrir imagen)
Pestaña 3 — Matrix / Evidence
Pestaña real del Explorer: ▦ Dependency Matrix (misma pestaña que el Inspector; Evidence es la vista de matriz/relaciones auditadas dentro de ella).
Objetivo: mostrar relaciones que forman parte de la evidencia auditada. Esta zona representa conocimiento confirmado.
Principio fundamental: explorar el sistema no modifica la evidencia. Los resultados validados permanecen separados de los experimentos.
Qué contiene: relaciones verificadas, resultados de auditorías previas, matrices de dependencia.
Cómo interpretarlo: una relación visible en Evidence significa "esta conexión ha pasado por un proceso de validación definido".
No significa "todas las relaciones posibles están demostradas".
Campo
Valor real (caso tempo_bpm ~ fractal_D, hue_std)
relación
fractal_D, hue_std → tempo_bpm
tipo
RMA validado (kfold, n=227/227)
coverage
0.7127
residual_r2
0.1905 (IC bootstrap 0.3839–0.6368, excluye 0)
clasificación
estructura parcial
indicador de validación
VIF 1.042/1.042 — sin colinealidad; señal residual probablemente real
Esta fila corresponde a un resultado auditado y confirmado: ha pasado por validación cruzada y verificación de estabilidad (bootstrap CI), no a una hipótesis sin probar.
Pestaña 4 — Research
Pestaña real del Explorer: 🧪 Research Mode (mapeo directo, sin agrupar).
Objetivo: Research es el espacio de exploración científica. Su función es generar preguntas.
Importante: una hipótesis no es un resultado. Research permite estudiar patrones interesantes, posibles relaciones, preguntas futuras.
Ejemplo:
Observación: "Un parámetro acústico parece relacionarse con varias características visuales."
Pregunta: "¿Esta relación permanece bajo otros modelos o datasets?"
Eso pertenece a Research.
Flujo correcto:
Research ↓ Análisis adicional ↓ Validación independiente ↓ Evidence
Campo
Valor real (hipótesis derivada del caso auditado)
observación
tempo_bpm ~ fractal_D + hue_std deja un residual_r2 de 0.1905 no explicado, y el IC bootstrap (0.3839–0.6368) excluye 0
estado
exploratorio — todavía no es evidencia
pregunta
¿qué otra(s) feature(s) del dataset (p. ej. edge_density, roughness) explican ese residuo?
siguiente paso
ampliar el modelo con features adicionales y volver a correr RMA con validación cruzada
Hipótesis construida a partir del propio resultado auditado en Analysis/Evidence, sin introducir variables no observadas en el dataset real.
Captura real — pestaña Research Mode (abrir imagen)
Pestaña 5 — Analysis
Pestaña real del Explorer: 📊 Analysis (cubre tanto la ejecución del análisis como su exportación, ver también bloque 6).
Objetivo: Analysis permite ejecutar RMA directamente. Es el laboratorio computacional del Explorer.
Entrada: el usuario puede utilizar el corpus integrado de ARGIRA o un CSV externo.
Qué estudia RMA: no solamente "¿Predice bien el modelo?", también "¿Qué información queda fuera de la explicación?"
Ejemplo: modelo tempo_bpm ~ fractal_D + hue_std. RMA evalúa: ajuste del modelo, residuos, estructura residual, estabilidad del resultado.
Parámetro
Valor real
target
tempo_bpm
features
fractal_D, hue_std
model
linear
cv_strategy
kfold
n_total / n_clean
227 / 227 (sin missing)
coverage
0.7127
residual_r2
0.1905
residual_std
0.0639
ibds
0.2441
VIF (fractal_D / hue_std)
1.042 / 1.042 — sin colinealidad problemática
clasificación
estructura parcial
Cifras extraídas directamente del informe RMA real generado por el Explorer (dataset sonificacion_resultados.csv, motor rma_core.py vía Pyodide). Ver caso de estudio completo, incluyendo el bootstrap CI del residual R², en la sección siguiente.
Captura real — pestaña Analysis, motor Pyodide en el navegador (abrir imagen)
Pestaña 6 — Reports / Export
Pestaña real del Explorer: 📊 Analysis (misma pestaña que el bloque 5; la exportación es el paso final del flujo de Analysis, no una pestaña aparte).
Objetivo: convertir una exploración en un objeto reproducible.
Exportaciones disponibles: HTML, PDF, JSON, CSV, SVG. Ejemplo real: el mismo informe tempo_bpm ~ fractal_D + hue_std exportado como HTML y como PDF (ver vista Técnica), con el bootstrap CI incluido en una versión y ausente en la otra según el momento de exportación.
Ejemplo: una persona puede ejecutar un análisis, exportar el informe, compartirlo, y revisar exactamente qué datos y parámetros utilizó.
Campo
Exportación 07:47:34
Exportación 07:50:31
formatos
HTML, PDF
HTML, PDF
residual_r2
0.1905
0.1905
bootstrap CI
ausente
presente (0.3839–0.6368, n=10)
advertencias
ninguna
1 (señal residual probablemente real)
Ejemplo real de trazabilidad: el mismo caso tempo_bpm ~ fractal_D + hue_std exportado tres minutos después incorpora el bootstrap CI del residual R², que aún no se había calculado en la primera exportación. Cada archivo (HTML/PDF) conserva el JSON crudo (source_result) para verificar exactamente qué cambió.
Captura real — panel de ejecución RMA y exportación (abrir imagen)
Ejemplo de recorrido completo
Un investigador quiere estudiar un parámetro acústico.
Abre Network → "¿Qué variables visuales influyen en este parámetro?"
Abre Inspector → "¿Cuál es el origen exacto de estas variables?"
Consulta Evidence → "¿Qué relaciones ya están auditadas?"
Explora Research → "¿Qué hipótesis nuevas aparecen?"
Ejecuta Analysis → "¿Qué ocurre bajo un análisis estadístico reproducible?"
Exporta resultados → "¿Puedo compartir este análisis?"
Idea central del Explorer
El Explorer no es solamente una interfaz gráfica. Es una capa de transparencia sobre una transformación compleja:
