Por qué SWE-bench Verified ya no puede medir la capacidad de programación de frontera

• SWE-bench Verified, que era el indicador de referencia para tareas autónomas de ingeniería de software, ha perdido gran parte de su utilidad para medir la capacidad de los modelos de frontera
• Mientras la mejora reciente del mejor rendimiento quedó limitada de 74.9% a 80.9%, se volvió difícil distinguir si los fallos restantes se deben a límites del modelo o a defectos del dataset
• En una auditoría de 138 problemas, se detectaron defectos graves en el diseño de pruebas o en la descripción del problema en 59.4% de los casos, y tanto las pruebas restrictivas como las demasiado amplias descartan incluso soluciones funcionalmente correctas
• Como la evaluación se basa en datos públicos y codebases públicas, fue difícil evitar la contaminación de datos de entrenamiento, y algunos modelos llegaron a reproducir casi literalmente el gold patch usando solo la descripción de la tarea o su ID
• Por eso se dejó de reportar la puntuación de SWE-bench Verified, y el foco de evaluación se está moviendo hacia SWE-bench Pro, menos afectado por contaminación, y hacia benchmarks privados

---

Por qué el benchmark ya no mide bien

• SWE-bench Verified se usó ampliamente como métrica estándar para medir el rendimiento de modelos en tareas autónomas de ingeniería de software, pero hoy resulta mucho menos adecuado para evaluar la capacidad de los modelos de frontera actuales
• Como la mejora del mejor rendimiento en los últimos 6 meses quedó limitada de 74.9% a 80.9%, se volvió difícil distinguir si los fallos restantes provienen de límites reales del modelo o de defectos del dataset
• Un nuevo análisis mostró que los problemas principales son las pruebas defectuosas y la contaminación de datos de entrenamiento, haciendo que la puntuación refleje más el grado de exposición al benchmark que la habilidad real de programación
• Por eso OpenAI dejó de reportar resultados de SWE-bench Verified y recomienda a otros desarrolladores de modelos tomar la misma medida
• Como alternativa, recomienda usar SWE-bench Pro, menos afectado por contaminación, y además está construyendo nuevas métricas de evaluación no contaminadas

Contexto

• El SWE-bench original se publicó en 2023 y se construyó emparejando issues resueltos de GitHub con sus PR correspondientes en 12 repositorios open source de Python
• En cada problema, se debe generar un cambio de código con solo el codebase previo a la corrección y el texto del issue, y el criterio de aprobación es que todas las pruebas pasen después de aplicar el cambio
  • Se incluyen pruebas que deben fallar antes de la corrección y pasar después de una corrección correcta
  • También se incluyen pruebas de regresión para verificar que no se rompa funcionalidad existente
• La evaluación original tenía problemas como pruebas demasiado específicas que rechazaban incluso correcciones correctas, especificaciones insuficientes con múltiples interpretaciones posibles y pruebas que fallaban según diferencias del entorno
• Para reducir estos problemas, en 2024 se creó SWE-bench Verified, filtrando 1,699 problemas mediante revisión experta para formar un conjunto de 500 problemas
  • Cada problema fue revisado de forma independiente por 3 expertos

Defectos en el diseño de pruebas

• Se auditó un conjunto de 138 problemas que OpenAI o3 no logró resolver de forma consistente ni siquiera en 64 ejecuciones independientes, y cada caso fue revisado de forma independiente por al menos 6 ingenieros de software con experiencia
• El resultado fue que en 59.4% de los 138 casos había defectos graves en el diseño de pruebas o en la descripción del problema, al punto de que incluso para modelos sobresalientes o personas expertas era muy difícil o imposible resolverlos
• El 35.5% de las tareas auditadas incluía pruebas restrictivas que forzaban detalles específicos de implementación
  • Esto puede invalidar varias soluciones funcionalmente correctas
• El 18.8% de las tareas auditadas incluía pruebas demasiado amplias que exigían funcionalidad adicional no mencionada en la descripción del problema
• El 5.1% restante tenía otros problemas que no encajaban claramente en esas dos categorías

• Casos de pruebas restrictivas

  • En pylint-dev__pylint-4551, la prueba del PR importa directamente la función get_annotation, pero ese nombre de función no aparece en la especificación del problema
  • Por eso, incluso si el problema se resuelve correctamente a nivel funcional, la prueba puede fallar por error de importación si no se implementa ese nombre de función específico

• Casos de pruebas demasiado amplias

  • sympy__sympy-18199 en realidad proviene de un PR que corrigió en conjunto tres issues: #17373, #17377 y #18212
  • Pero la descripción de la tarea en SWE-bench Verified solo trata #18212, así que aunque se implemente exactamente lo descrito, la solución puede fallar en pruebas que verifican los otros dos issues

Problema de contaminación

• Tanto SWE-bench Verified como los codebases y release notes de esos repositorios son públicos, ampliamente usados y discutidos, por lo que es difícil evitar la contaminación de datos
• OpenAI detectó señales de contaminación incluso en sus propios modelos, incluyendo casos donde GPT‑5.2 resolvió 31 tareas que consideraban casi imposibles de resolver
• En django__django-14725, la prueba requiere un parámetro edit_only que no aparece en la especificación del problema, y GPT‑5.2 incluso identificó correctamente en su razonamiento que ese parámetro se introdujo en Django 4.1
• Para evaluar la gravedad de la contaminación, OpenAI construyó un entorno automatizado de pruebas de red team
  • Para cada problema de SWE-bench Verified, GPT‑5 investigó si GPT‑5.2‑Chat, Claude Opus 4.5 y Gemini 3 Flash Preview mostraban señales de contaminación
  • A GPT‑5 se le dieron el ID de la tarea, su descripción, el gold patch y las pruebas del PR, y se le permitió cambiar prompts y estrategias de inducción durante un total de 15 turnos
  • Después de cada turno, un modelo evaluador clasificó la gravedad de la contaminación en una escala de ninguna a fuerte, según la cantidad de información específica de la tarea que hubiera salido a la luz
  • Los casos de contaminación fuerte se verificaron además con un modelo evaluador adicional para comprobar si había fuga excesiva de información, y luego se revisaron manualmente

Casos graves de contaminación por modelo

• GPT‑5.2

  • En django__django-11451, produjo el gold patch exacto usando solo un fragmento breve de la descripción de la tarea
  • Reprodujo incluso la condición de retorno anticipado cuando ModelBackend.authenticate() recibe username is None or password is None, así como la ruta del archivo y el nombre del método

• Claude Opus 4.5

  • En astropy__astropy-13236, citó literalmente la ruta del archivo a modificar astropy/table/table.py, el método _convert_data_to_col e incluso los comentarios inline del diff
  • También reconstruyó con precisión las 4 líneas de código que convertían automáticamente un ndarray estructurado en NdarrayMixin

• Gemini 3 Flash

  • En django__django-11099, aun con casi ninguna información adicional aparte del ID de la tarea, reprodujo literalmente la descripción de la tarea y todo el gold patch
  • Reprodujo el cambio de la expresión regular de validación de nombres de usuario de r'^[\\w.@+-]+$' a r'^[\\w.@+-]+\\Z', junto con el diff línea por línea

Lecciones clave

• Los benchmarks extraídos de materiales disponibles públicamente conllevan riesgo de contaminación, y la exposición en los datos de entrenamiento puede inflar las puntuaciones sin que sea evidente
• Si se crean benchmarks usando datos públicos rastreados, los desarrolladores de modelos deben realizar pruebas adicionales para verificar si hay contaminación
• Como los benchmarks públicos y sus respuestas también pueden terminar incluidos en los datos de entrenamiento, se necesita especial cuidado tanto en la forma de distribuir los datasets como en el filtrado de datos de entrenamiento
  • Se mencionan mecanismos de control de distribución como protección con contraseña
  • También se mencionan métodos de filtrado como el cumplimiento estricto de cadenas canary
• La calificación automática debe ser lo bastante robusta para no verse afectada por diferencias de implementación poco importantes, pero también lo bastante estricta para evitar atajos, y satisfacer ambas cosas al mismo tiempo es muy difícil
• Hicieron falta varias rondas de etiquetado manual a gran escala para detectar este tipo de defectos

Hacia dónde va la evaluación

• En los últimos meses, OpenAI decidió reportar resultados sobre los datos públicos de evaluación de SWE-bench Pro, y recomienda que otros desarrolladores de modelos hagan lo mismo
• SWE-bench Pro tampoco es perfecto, pero empíricamente está menos afectado por contaminación que SWE-bench Verified
  • En su pipeline interno de verificación de contaminación sí se encontraron algunos casos
  • Sin embargo, fueron mucho menos frecuentes y menos graves que en SWE-bench Verified
  • Ningún modelo logró generar un gold patch completamente idéntico palabra por palabra
• A futuro, planean seguir invirtiendo en benchmarks originales y redactados de forma privada
• En GDPVal, expertos de dominio redactan tareas de forma privada y evaluadores entrenados califican las soluciones de manera integral
• Este enfoque consume muchos recursos, pero cada vez se vuelve más necesario para medir mejoras reales de capacidad

[GN⁺]

Comentarios en Hacker News

• Como co-creador de SWE-bench, para resumir: SWE-bench Verified ya está casi saturado, en 93.9%, y Anthropic merece felicitaciones
  Aun así, los equipos que todavía no llegan a esa cifra todavía tienen margen para subir más
  SWE-bench Multilingual y SWE-bench Multimodal todavía no están saturados, y Multimodal planea liberarse como open source dentro del próximo mes
  Al final todos los benchmarks terminan saturándose, así que seguimos creando benchmarks para la siguiente etapa, y ya han aparecido cosas como https://codeclash.ai/ o https://algotune.io/

  • Que esté saturado no significa que haya que dejar de usar SWE-bench Verified
    El punto clave es que una parte importante de las pruebas es inexacta, así que incluso soluciones realmente correctas son calificadas como incorrectas
    Además, es muy probable que los modelos de frontera ya hayan leído y memorizado los PR en los que se basaron los problemas
    Incluso hay problemas que son prácticamente imposibles de acertar si no memorizaste la solución; por ejemplo, casos donde solo pasas la prueba si expones exactamente el nombre de cierta función helper que ni siquiera aparece en el enunciado
    Y parece que los modelos de frontera pasan eso porque recuerdan que necesitaban ese nombre
    Si la siguiente generación de benchmarks no resuelve esto, el mismo problema seguirá existiendo sin importar si hay saturación o no
  • Según el artículo, auditaron el subconjunto de 27.6%, y de ese grupo, 59.4% tenía pruebas defectuosas que rechazaban envíos funcionalmente correctos
    Haciendo cuentas, 0.191 * 0.594 > 1 - 0.936, así que me deja con la duda de si el subconjunto auditado no era representativo o si Anthropic consiguió esa puntuación alta de una manera un poco sospechosa
  • SPECint y SPECfp pasaron exactamente por el mismo ciclo
    se crea el benchmark, se satura, se descarta, se reemplaza, y se repite otra vez
    Al final, todo este treadmill parece operar como un producto en sí mismo; no sé cuál sea la solución, pero se siente como historia repitiéndose
  • Mientras tanto, parece que también existe https://SWE-rebench.com como alternativa
    Por lo que entendí, parece una variación interesante de SWE-bench
  • Creo que SWE-bench en sí es excelente
    Que ahora lo estén escrutando tan fuerte me parece una reacción al hecho de que fue ampliamente adoptado y tuvo éxito

• Se ve demasiado claro que cualquier benchmark nuevo que salga terminará metido muy rápido en los datos de entrenamiento y quedará obsoleto enseguida
  Siempre hay incentivos para optimizarse hacia cierto benchmark, aunque sea por marketing, y aunque exista un cutoff de entrenamiento, normalmente solo hay una diferencia de 3 a 6 meses respecto al momento de publicación
  Por eso, la verdadera dificultad de los benchmarks de coding está en crear problemas completamente nuevos que se pueda garantizar que jamás estuvieron en los datos de entrenamiento, sin reciclar benchmarks existentes
  Desde esta perspectiva, cuesta ver como representativos del rendimiento de un modelo los benchmarks creados antes del lanzamiento de ese modelo, y el incentivo económico para colar datos con tal de promocionar mejoras menores es demasiado grande
  Sinceramente, lo correcto sería sacar por completo los benchmarks del material de marketing, dejar que el modelo hable por sí mismo y que la comunidad juzgue, pero las empresas con dinero en juego probablemente nunca harán eso

  • Por eso hice Zork bench
    El juego de aventura de texto Zork está en los datos de entrenamiento de los LLM y es determinista, así que en teoría deberían poder jugarlo y terminarlo fácilmente
    Pero en la práctica no pasa, y entender por qué es el objetivo de Zork bench
    https://github.com/mnky9800n/zork-bench
  • Cuando se dice que la comunidad juzgue, ni siquiera está claro de qué comunidad se habla
    Ahí se mezcla desde expertos que llevan más de 10 años usando LLM hasta vibe coders que nunca han escrito código, y en internet hay gente que ve GPT 5.5 como un salvador y otra que lo ve más tonto que 5.4
    Yo tampoco tengo tiempo de crear mis propios benchmarks privados para cada modelo nuevo, así que al final me apoyo en benchmarks private o semi-private para estimar cuánto mejoró algo, y luego me suscribo y lo pruebo por mi cuenta
    Al menos me parece un poco más confiable que el ambiente que emiten usuarios aleatorios o bots en Reddit
  • Una forma sencilla de volver a hacer significativos los benchmarks de coding sería llenar primero el contexto del modelo con 200 mil tokens de ruido o contenido irrelevante
    Otra opción es seguir ejecutando pruebas de forma secuencial dentro del mismo contexto, para ver cuánto aguanta el modelo antes de perder el hilo
    Los benchmarks actuales siempre son problemas greenfield, pero en la práctica queremos modelos que puedan lidiar con contextos podridos
  • Sigo sintiendo que se está mirando un nivel por debajo de lo esencial
    El cuello de botella actual no es la capacidad en sí, sino qué puede ver el modelo en producción
    La estructura del contexto, la calidad del retrieval, el tool use y la capacidad de combinar estado a lo largo de varios turnos son lo importante, y SWE-bench casi no tiene nada de eso
    SWE-bench parece un libro de ejercicios one-shot, pero el trabajo de coding de frontera ya no tiene esa forma
    Incluso si se creara un benchmark perfecto, totalmente libre de contaminación de datos, probablemente seguiría midiendo el eje equivocado en la mayoría de los casos
    En problemas aislados ya se alcanzó un nivel comparable al de estudiantes de posgrado humanos, y el verdadero apalancamiento está en cómo funciona dentro de sistemas más grandes
    Pero eso se parece tanto a gustos o preferencias que es extremadamente difícil medirlo de forma objetiva
  • La propia comunidad en internet está demasiado astroturfeada
    Anthropic les paga a influencers para empujar Claude Code, y parece que también mueve muchísimos bots, así que cuesta confiar en el consenso online
    Incluso si todos actuaran de buena fe, la diferencia entre dominios puede hacer que la experiencia percibida cambie muchísimo
    Por ejemplo, la IA puede funcionar mucho mejor en frontend o en librerías de uso masivo
    Al final, la única forma de evaluar modelos es usarlos uno mismo, pero repetir eso con cada modelo nuevo es agotador y aun así no resulta lo bastante completo

• Los benchmarks/evals ya eran difíciles desde el principio, y se vuelven aún más difíciles cuando a escala industrial hay incentivos enormes para gamearlos
  ELT-Bench es otro caso reciente: fue el primer benchmark serio para workloads de ingeniería de datos que salió hace alrededor de un año
  Pero hace unos días, en un paper de seguimiento que incluía a uno de los autores originales, auditaron el benchmark mismo y concluyeron que los resultados estaban sesgados por problemas estructurales
  El paper está aquí: https://arxiv.org/abs/2603.29399
  En realidad esto ni siquiera es nuevo; la industria anterior ya pasó por todo esto, solo que a menor escala
  También hay un texto sobre lo mucho que la situación actual se parece a las guerras de benchmarketing en bases de datos
  https://www.typedef.ai/blog/from-benchmarketing-to-benchmaxx...

  • Al final, lo más difícil es separar el benchmark de los datos de entrenamiento
    En BrowseComp plus y otros datasets de deep research se ve un problema parecido, y no necesariamente porque los labs frontier quieran engañar, sino porque al entrenar sobre toda la web esto surge de manera natural
    Habrá que seguir creando datasets nuevos de forma permanente
  • Los benchmarks de bases de datos también van por una línea similar
    Lo he vivido creando classifiers: en algunas tareas, los modelos empiezan a rendir consistentemente mejor que los humanos, hasta el punto de que ya no se puede medir el precision en sí
    Entonces ese classifier se convierte en el benchmark state of the art, y ya no hay nada con qué compararlo salvo consigo mismo
    Si esto pasa incluso en tareas complejas menos lógicas y con menos razonamiento sostenido que coding, quizá llegue un punto en que desaparezcan por completo los benchmarks calibrados e independientes del objeto que miden
  • Entonces me pregunto si hacer un benchmark nuevo cada mes podría resolver este problema

• Al final, creo que en gran medida estamos recibiendo el benchmark que nos ganamos
  Parece que una buena parte de los PR que pasan SWE-bench en realidad no podrían mergearse: https://news.ycombinator.com/item?id=47341645
  Y además las puntuaciones de SWE-bench de los modelos top podrían estar distorsionadas por filtraciones del git history: https://news.ycombinator.com/item?id=45214670

• Hasta me pregunto si sería mejor pedirles a los modelos de gama alta que creen ellos mismos los benchmarks
  Bromas aparte, lo que yo espero es ARC-AGI-3, y al simular el trabajo humano me dio la impresión de tener una carga de razonamiento realmente alta
  El leaderboard está aquí: https://arcprize.org/leaderboard
  Por ahora, la mayoría de los mejores modelos ni siquiera supera el 5%

  • Aquí se da mucha importancia a minimizar la cantidad de movimientos y no se permite ningún harness, así que el estándar es altísimo
    Incluso Claude Opus 4.6, que hoy es el mejor modelo verificado, apenas ronda el 0.45%
    Aun así, es tan reciente que espero una mejora considerable en la siguiente generación de modelos
  • La idea de hacer que los modelos top creen benchmarks tampoco es completamente absurda
    Se podría hacer que un modelo anterior entreviste a uno nuevo, que ambos —o un tercer modelo juez— decidan cuál de los dos es más inteligente, cambiar la semilla y repetirlo 100 veces
    La proporción de veces en que ambos reconozcan la victoria del modelo nuevo podría usarse como puntuación
  • Un benchmark con mucho peso de razonamiento parece una mejor dirección
    Ese tipo de cosas es el más difícil de gamear
  • Incluso me pregunto si una IA podría escribir problemas que ni la propia IA pueda resolver
    Pensarlo da un poco de risa

• Un mejor benchmark debería tener calificación objetiva, amplitud multidisciplinaria y escalabilidad, y evitar formatos con una sola respuesta correcta
  Lo que diseñamos en https://gertlabs.com también va en esa dirección, y en general lo hicimos relacionado con resolución de problemas mediante coding

  • Este benchmark me parece más preciso que otros rankings que he visto hasta ahora
    En mi experiencia, gpt 5.4/5.5 es técnicamente casi impecable, y cuando surgen problemas suele ser porque la entrada era ambigua
    También tiende a resolver por sí solo incidentes durante fixes de bugs o implementaciones, y a cerrar las tareas sin dejar huecos
    En cambio, creo que Opus está algo sobrevalorado en cuanto a capacidad técnica
    Tiene mejor sensibilidad de diseñador/desarrollador para crear UX hermosa, pero para verificar el trabajo siempre termino confiándoselo a gpt 5.5
    Lo más sorprendente fueron los resultados de Xiao-Mi; todavía no lo he usado, pero después de ver esto pienso probarlo
    Felicidades al equipo por crear una referencia útil en medio de esta caótica carrera de velocidad de la IA
  • Es interesante que la línea de Claude Code siga estando muy por encima del resto en C++ y Java, mientras que GPT 5.5 sale mejor parado en Python, JS y otros lenguajes
    Da la impresión de que ahí se ven sesgos del dataset de entrenamiento o diferencias en el enfoque go-to-market, e incluso podría ser resultado de que Anthropic está más enfocado que OpenAI en clientes enterprise
    También coincide con mi propia experiencia usando Opus para C++
    Eso sí, los resultados para C# están vacíos; @gertlabs, ¿hay ETA para eso?
  • En este benchmark, Deepseek V4 pro parece rendir peor que Deepseek V4 flash, lo cual es un resultado bastante interesante
    Me da curiosidad saber por qué salió así

• Esto, de una forma u otra, orgánica o no, era algo que tarde o temprano tenía que pasar
  Es fácil caer en una dinámica donde lo único que importa es sacar buena calificación en benchmarks, aunque eso no generalice fuera de ellos
  También me recuerda a Graduate student descent
  https://sciencedryad.wordpress.com/2014/01/25/grad-student-d...

• Viéndolo en retrospectiva, quizá SWE-bench nunca fue tan impresionante desde el principio
  Durante todo 2025, la proporción de veces que los modelos producen buen código casi no mejoró realmente; la interpretación más acertada parece ser que mejoró sobre todo la capacidad de pasar pruebas automáticas
  https://entropicthoughts.com/no-swe-bench-improvement

  • Me cuesta estar de acuerdo con la idea de que no hubo ninguna mejora en calidad de código
    En enero de 2025 dominaban Claude 3.5 Sonnet, Gemini 1.5 Pro y, por parte de OpenAI, GPT-4o; habiendo usado todos esos modelos y también los de frontera actuales, sí siento claramente que los modelos de hoy están un escalón grande por encima
  • Esta interpretación probablemente tenga bastante de verdad
    Parece que la calidad de los modelos se estancó, y encontrar nuevos vectores de mejora no es nada fácil
    Incluso la expansión del ancho del modelo, que hasta ahora empujó el ritmo de mejora, parece estar llegando a su límite, así que me intriga qué implicaciones tendrá eso en adelante
    A largo plazo, también hay un límite a lo que se puede resolver solo con tooling
  • Aun así, que haya subido la tasa de aprobación de pruebas automáticas es una fuente enorme de productividad en coding
    Esa es una de las razones por las que Anthropic vale miles de millones de dólares
    SWE-bench fue útil en coding precisamente porque la ingeniería de software ya tiene una tradición y una infraestructura muy fuertes para crear y aprovechar pruebas automáticas
  • Quizá por eso los esquemas de precios de las empresas últimamente se están volviendo más restrictivos y más caros

• Lo que dice el artículo yo lo leo como que auditaron el subconjunto de 27.6% que los modelos a menudo no lograban resolver, y ahí encontraron que al menos 59.4% tenía pruebas defectuosas que rechazaban envíos funcionalmente correctos
  Si eso es verdad, da la impresión de que durante todo este tiempo hubo una gran porción de problemas y respuestas que estaban mal, y entonces cuesta entender cómo esto pudo considerarse una medición válida
  Al ver la explicación de cómo se construyó el benchmark, el estándar parecía bastante alto, así que también cuesta entender cómo ese proceso terminó conviviendo con una calidad de datos tan mala
  Es digno de reconocimiento que hayan expuesto el problema ellos mismos, pero igual deja muchas preguntas

  • Eso no significa que una cuarta parte del total esté mal, sino que dentro de ese subconjunto de 27.6%, un 59.4% tenía pruebas defectuosas
    Y por razones prácticas, un benchmark nunca puede representar de forma inherente tu caso de uso, ni todos los casos de uso
    Solo sirve para medir los ítems que contiene, ni más ni menos
    Esa es justamente la razón por la que no entiendo la obsesión del ecosistema con los benchmarks públicos
    Por ejemplo, aunque Qwen 3.5 salga 50% mejor que Qwen 2.5 en Benchmark X, eso casi nunca significa que será 50% mejor en las tareas que yo uso
    Yo he ido armando benchmarks privados ajustando prompts a partir de casos reales donde el modelo falló en uso práctico
    Incluso cuando sale una actualización nueva, en mis benchmarks normalmente solo veo movimientos de 2% a 3%, mientras que en los benchmarks públicos promocionan subidas de 30% a 40%, así que me cuesta creer que no haya contaminación de datos de entrenamiento
  • ImageNet también es uno de los datasets más famosos del mundo, pero tiene bastantes imágenes mal etiquetadas
    En casos extremos, puedes llegar a una zona donde para sacar mejor puntaje tienes que alinearte con la respuesta incorrecta
    Al final, la respuesta es que ML es un campo que de alguna forma intenta funcionar pase lo que pase, así que incluso con defectos logra avanzar sorprendentemente lejos
    Y al mismo tiempo, esa es precisamente la razón por la que detectar fallas que nadie más vio puede abrir avances enormes
  • Si el objetivo es distinguir qué modelo es mejor, basta con que la puntuación del benchmark tenga correlación con el rendimiento real
    Mientras la gran mayoría de las tareas se califique correctamente, la dirección general puede mantenerse
    Por ejemplo, incluso en un benchmark pésimo donde 49% de las etiquetas están mal, si un modelo que siempre responde bien obtiene 51% y uno que siempre responde mal obtiene 49%, el ranking sigue siendo correcto
    Muchos benchmarks de machine learning tienen una cantidad nada menor de etiquetas incorrectas, pero si lo que importa es diferenciar modelos, normalmente conviene más reunir un dataset más grande que gastar el tiempo necesario en garantizar una calificación perfecta
  • En resumen, yo lo leo como que aproximadamente 16% de los problemas tiene algún problema