Metodología
Cómo construimos el mapa de debilidades, qué datos usamos y dónde están los límites.
Fuente de datos
Todos los datos provienen de la API pública de OpenReview. Ningún dato privado, ningún login, ningún acceso especial. Solo lo que cualquier persona con un navegador puede ver hoy en la página pública del venue.
Para cada venue obtenemos los envíos con sus respuestas (revisiones, meta-revisión, decisión) en una sola llamada masiva. Los identificadores concretos de papers no se exponen aquí: este sitio agrega, no enlaza.
Cómo agrupamos las debilidades
El campo `weaknesses` de cada revisión oficial suele contener entre cinco y ocho críticas distintas, a menudo en forma de bullet points. Lo primero que hacemos es partir cada párrafo en items individuales por sus delimitadores naturales (guiones, números, viñetas).
Después aplicamos un pipeline clásico de clustering de texto:
- Vectorizamos los items con TF-IDF (uni-grama y bi-grama, frecuencia sublineal, normalización L2).
- Reducimos a 64 dimensiones latentes con Truncated SVD (Latent Semantic Analysis).
- Re-normalizamos y agrupamos con KMeans (semilla fija, 20 inicializaciones).
- Para cada cluster recuperamos los términos TF-IDF más representativos y tres ejemplares cercanos al centroide.
Las etiquetas de los clusters y las descripciones que ves no las pone el algoritmo: están escritas a mano leyendo los términos y los ejemplares. El algoritmo encuentra la estructura; nosotros la nombramos.
Privacidad y respeto al ToS
- No mostramos identificadores de papers, ni listas de papers rechazados, ni enlaces a revisiones individuales.
- Los ejemplares textuales se exponen anonimizados (sin reviewer ID, sin paper ID) y truncados.
- Todo el contenido se basa en datos públicos. Si eres autor o revisor de un paper y quieres que retiremos un ejemplar concreto, escríbenos a contact@opencodice.org.
- Este es un proyecto de ciencia abierta sin ánimo de lucro.
Limitaciones honestas
- TF-IDF agrupa por similitud léxica, no semántica. Dos críticas que dicen lo mismo con vocabulario distinto pueden caer en clusters separados.
- Cada venue expone una porción distinta de su proceso. NeurIPS sólo expone los envíos que llegaron a decisión; COLM solo expone aceptados. Mostramos lo que existe y avisamos cuándo el dato está sesgado.
- El muestreo dentro de los rechazados es uniforme. Un análisis ponderado por margen de decisión o por confianza del revisor saldría distinto.
- Algunos clusters son mayoritariamente ruido o se concentran en un sub-tema concreto (federated learning, modelos de difusión). Lo señalamos cuando es el caso.
Documentación completa
El diseño del pipeline, la arquitectura del servidor MCP que produce los datos y un caso de estudio completo sobre ICLR 2024 están documentados en el informe técnico OC-TR-2026-007: