010 — Cómo leer papers, benchmarks y claims de IA

← Clase anterior · Índice de la parte · Clase siguiente →

Parte: 00 — Fundamentos, historia y método científico
Nivel: fundamentos · Horas estimadas: 4
Laboratorio: evaluation · Estado: EXECUTABLE_CORE

🎯 Propósito

Comprender cómo leer papers, benchmarks y claims de ia dentro de la evolución de la inteligencia artificial, implementar un experimento mínimo verificable y distinguir qué parte constituye evidencia frente a una afirmación todavía no comprobada.

📚 Resultados de aprendizaje

Al finalizar podrás:

1. Explicar cómo leer papers, benchmarks y claims de ia usando los conceptos papers, benchmarks, claims, replicación.
2. Ejecutar el laboratorio con una semilla explícita y revisar su contrato JSON.
3. Identificar al menos un supuesto, una limitación y un riesgo de aplicación.
4. Comparar el enfoque con la etapa anterior de la ruta de aprendizaje.
5. Producir una evidencia reproducible y una conclusión que no exceda los datos.

🧩 Conceptos centrales

papers, benchmarks, claims, replicación

🗺️ Ubicación en el mapa de la IA

La IA produce decenas de miles de papers al año y un flujo constante de anuncios con métricas espectaculares; la capacidad de leerlos críticamente es tan parte del oficio como programar. Esta clase aplica la falsabilidad (clase 008) y la reproducibilidad (clase 009) al material publicado: cómo desarmar un paper, qué mide realmente un benchmark y qué preguntas hacerle a un claim antes de creerlo. Es la herramienta de supervivencia para el resto del programa, donde se leerán papers seminales en casi cada parte.

📖 Fundamentos

📄 Anatomía de un paper de ML

Las secciones tienen funciones retóricas distintas y se leen con niveles de confianza distintos:

• Abstract/Introducción: el claim en su versión más vendedora. Anotar qué se promete.
• Método: qué se hizo. Buscar los detalles que afectan la comparación: ¿mismo presupuesto de cómputo y de búsqueda de hiperparámetros para el baseline?
• Experimentos: la evidencia real. Aquí viven las tablas, los datasets y las condiciones. Es la sección contra la que se audita el abstract.
• Limitaciones/Apéndices: donde los autores honestos entierran las malas noticias (varianza entre semillas, resultados negativos, trucos de preprocesamiento).

Método de lectura en tres pasadas (Keshav): (1) título, abstract, figuras y conclusión — 5 minutos, decidir si sigue; (2) lectura completa sin demostraciones, anotando supuestos — 1 hora; (3) reconstrucción mental o real del experimento — la única pasada que habilita a citarlo como evidencia.

📏 Qué mide (y qué no) un benchmark

Un benchmark es una muestra congelada de una tarea, no la tarea. Cadena de representatividad que puede romperse en cada eslabón:

capacidad real → tarea idealizada → dataset recolectado → split de test → métrica agregada

Modos de fallo documentados:

• Contaminación: el test estuvo en los datos de entrenamiento (crítico con LLMs entrenados sobre la web: el benchmark público está en la web).
• Sobreajuste comunitario (Goodhart): años de optimizar contra el mismo leaderboard producen mejoras específicas del benchmark que no transfieren.
• Artefactos y atajos: el modelo explota regularidades espurias del dataset (longitud, léxico) en lugar de la capacidad nominal.
• Saturación: cerca del techo, las diferencias entre sistemas son ruido de anotación.
• Métrica ≠ calidad: accuracy agregada oculta el desempeño por subgrupos y el costo asimétrico de errores.

🧾 Checklist para auditar un claim

Preguntas mínimas ante "X alcanza el estado del arte" o "X supera a los humanos":

1. ¿Comparación justa?    mismo dato, mismo cómputo, misma búsqueda de hiperparámetros
2. ¿Baselines fuertes?    ¿incluye el baseline trivial y el clásico bien afinado?
3. ¿Cuántas semillas?     ¿reportan media ± dispersión o una corrida afortunada?
4. ¿Población definida?   ¿"supera a humanos" — a cuáles, en qué subconjunto, con qué UI?
5. ¿Test limpio?          ¿auditaron contaminación/leakage? ¿test temporalmente posterior?
6. ¿Código y datos?       ¿se puede reproducir? ¿hay lockfile/pesos/configuración?
7. ¿Quién paga?           conflictos de interés declarados; los press releases no son papers
8. ¿Sobrevive fuera?      ¿hay evaluación out-of-distribution o replicación independiente?

Dodge et al. (2019) mostraron que reportar resultados sin el presupuesto de búsqueda de hiperparámetros hace incomparables los sistemas: con más intentos, cualquier método "gana". Pineau et al. (2021) convirtieron esta clase de preguntas en la checklist oficial de NeurIPS.

🎭 Tipología de claims

• Claim de capacidad: "el modelo puede razonar" — exige definición operativa y test falsable, si no, es marketing.
• Claim de métrica: "94.3 en el benchmark Y" — verificable pero estrecho; preguntar por la cadena benchmark→capacidad.
• Claim de superioridad: "supera a GPT-x / a médicos" — auditar la comparación (versión, prompt, fecha, subconjunto).
• Claim de tendencia: "la escala resolverá Z" — extrapolación; pedir la curva con incertidumbre, recordar la clase 003.

🧮 Ejemplo trabajado

Claim publicado: "Nuestro modelo diagnostica neumonía mejor que radiólogos (AUC 0.94 vs 0.87)". Auditoría con la checklist:

Reescritura honesta del claim: "En imágenes del hospital H con equipos del fabricante F, con partición por imagen (no por paciente), el modelo obtiene AUC 0.94 frente a 0.87 de radiólogos evaluados sin contexto clínico". Así formulado, el propio autor vería los huecos. Este patrón (split por imagen, un centro, comparación asimétrica) no es hipotético: es la falla modal que Kapoor y Narayanan catalogaron en la literatura de ML aplicado.

📊 Propiedades y comparación

flowchart TD
    CL["Claim: 'X supera el estado del arte'"] --> P1["Pasada 1 (5 min):<br/>abstract, tablas, conclusión"]
    P1 --> Q{"¿El claim del abstract<br/>coincide con las tablas?"}
    Q -- "No" --> DES["Descartar o degradar<br/>a 'hipótesis interesante'"]
    Q -- "Sí" --> P2["Pasada 2 (1 h):<br/>método, splits, baselines, semillas"]
    P2 --> A{"Checklist: ¿comparación justa,<br/>test limpio, población definida?"}
    A -- "Falla" --> DES
    A -- "Pasa" --> P3["Pasada 3:<br/>reproducir o replicar localmente"]
    P3 --> V{"¿Se sostiene en<br/>MIS datos/dominio?"}
    V -- "Sí" --> USE["Adoptar con monitoreo"]
    V -- "No" --> INF["Resultado informativo:<br/>documentar la brecha"]

⚠️ Errores conceptuales frecuentes

1. "Está publicado/revisado por pares, luego es cierto." La revisión filtra errores groseros, no verifica reproducibilidad; la tasa de resultados no replicables en ML aplicado es sustancial (Kapoor & Narayanan, 2023).
2. "Mejor número en el benchmark = mejor sistema para mi problema." El benchmark es una muestra congelada de otra distribución; la transferencia al dominio propio se mide, no se supone.
3. "Superhumano en el test = superhumano en la tarea." Los "humanos" del claim suelen ser anotadores con tiempo limitado y sin contexto; la tarea real incluye información y responsabilidad que el test excluye.
4. "Una décima más de métrica importa." Sin varianza entre semillas ni test de significancia, décimas son ruido; exigir media ± desviación sobre varias corridas.
5. "El abstract resume fielmente el paper." El abstract es la sección de ventas; la auditoría se hace contra la sección de experimentos y los apéndices.

🚀 Del aprendizaje a la operación

En la práctica profesional, este material se convierte en un protocolo de adopción de tecnología: ningún modelo o técnica entra al stack sin (a) replicar el claim clave en un subconjunto de datos propios, (b) comparar contra el baseline interno actual con el mismo presupuesto de ajuste, (c) registrar el experimento con el contrato de la clase 009, y (d) documentar la brecha entre el número publicado y el observado — que existirá, y cuya magnitud es información de planificación, no una decepción.

🧪 Laboratorio

python lab.py

El laboratorio llama a ai_evolution.labs.run_lab("evaluation"). Esta decisión evita 183 implementaciones divergentes: cada clase tiene un entrypoint propio, pero los motores didácticos se prueban como una biblioteca común.

🔍 Evidencia esperada

• tipo de laboratorio y semilla;
• entradas o decisiones observables;
• resultado estructurado;
• lista evidence con hechos que pueden inspeccionarse;
• lista limitations que impide presentar la demo como producción.

📓 Notebooks

• 📓 notebook.ipynb: recorrido guiado con la materia resumida.
• ✍️ notebook_student.ipynb: ejercicios para resolver.
• ✅ notebook_solution.ipynb: solución de referencia explicada.

📝 Evaluación

Consulta assessment.md para preguntas y criterio de aceptación.

⚠️ Errores comunes

❓ Preguntas frecuentes

¿Debo usar una API comercial?
No. El núcleo funciona localmente. Las extensiones LIVE se documentan por separado.

¿El laboratorio representa una implementación industrial?
No por sí solo. Enseña el contrato y el patrón; producción exige integración, seguridad, observabilidad, pruebas y operación.

¿Dónde profundizo?
Revisa las especializaciones enlazadas en el README raíz y la ruta siguiente.

📜 Dónde practicar esto

Este programa tiene un eje entero para aplicar lo de esta clase sobre papers reales: 148 fichas fundacionales, de Pearson (1901) a DeepSeek-R1 (2025), cada una con su fuente primaria, sus límites y sus errores comunes documentados.

Empieza por una ficha corta —P01 Perceptrón— y compara tu lectura del artículo original con lo que la ficha declara como fecha de consulta, evidencia y límites. Ese contraste es el ejercicio.

🔗 Referencias

• Keshav, S. (2007). How to Read a Paper (método de tres pasadas) — uso: fuente primaria del mecanismo estudiado
• Dodge et al. (2019). Show Your Work: Improved Reporting of Experimental Results — uso: fuente primaria del mecanismo estudiado
• Pineau et al. (2021). Improving Reproducibility in ML Research (checklist NeurIPS) — uso: fuente primaria del mecanismo estudiado
• Kapoor, S. & Narayanan, A. (2023). Leakage and the Reproducibility Crisis in ML-based Science — uso: fuente primaria del mecanismo estudiado
• Ioannidis, J. (2005). Why Most Published Research Findings Are False — uso: fuente primaria del mecanismo estudiado

📜 Papers que fundamentan esta clase

Bloque generado por python scripts/link_papers_to_classes.py. La fuente es papers/catalog/papers.json.

Cada ficha explica el problema anterior, la matemática mínima, los límites y los errores de atribución más frecuentes. Para leerlas con método: cómo leer un paper de IA · anexos matemáticos.

📚 Bibliografía de apoyo

Bloque generado por python scripts/link_sources_to_classes.py. Cada obra lleva su localizador verificado en sources/bibliography.json.

Los papers dicen de dónde salió el mecanismo. Estas obras lo desarrollan con el espacio que una clase no tiene: teoría completa, demostraciones y ejercicios.

⬅️ Clase anterior

009 — Entornos Python, Git y experimentos reproducibles

➡️ Siguiente clase

011 — Ética desde el diseño y límites de automatización

📝 Evaluación completa

❓ Preguntas

1. Define cómo leer papers, benchmarks y claims de ia sin usar una marca o framework como definición.
2. Explica la relación entre papers, benchmarks, claims, replicación.
3. Ejecuta lab.py dos veces con la misma semilla. ¿Qué debe conservarse?
4. Identifica una afirmación permitida y una afirmación exagerada sobre el resultado.
5. Propón una prueba negativa o un caso límite.

🏆 Reto verificable

Amplía el resultado del laboratorio con una clave student_extension que incluya:

• el supuesto que estás probando;
• una medición o comprobación;
• la conclusión;
• una limitación.

✅ Criterio de aceptación

• [ ] lab.py termina con código 0.
• [ ] El resultado contiene kind, seed, evidence y limitations.
• [ ] La extensión no modifica el comportamiento de otras clases.
• [ ] La interpretación referencia datos impresos por el laboratorio.
• [ ] Se declara al menos un riesgo o condición de no uso.