# El corpus de evaluación - Sitio: Ikusmira — enciclopedia en castellano de ciencias sociales y humanidades - URL canónica: https://ikusmira.org/p/el-corpus-de-evaluacion/ - Categoría: Informática - Publicado: 2026-09-17 - Autoría: Eneko Sarasola (redacción de Ikusmira) - Política editorial (autoría, revisión, correcciones, financiación): https://ikusmira.org/politica-editorial/ El **corpus de evaluación** es el conjunto de casos sobre el que se mide un sistema de inteligencia artificial: las entradas que se le dan, lo que se espera de él en cada una y las anotaciones que permiten decidir si acertó. Es la pieza más aburrida de construir y la única que no se puede sustituir. Los prompts se reescriben cada semana, los puntuadores se tiran cuando cambia el esquema de salida, el proveedor del modelo se cambia en una tarde; el corpus se hereda, y su calidad pone el techo a todo lo demás. Un juez excelente sobre un corpus que no representa el tráfico real mide con gran precisión algo que no ocurre. La tentación al empezar es escribir primero la métrica. Alguien propone medir «utilidad» del uno al cinco, se redacta una rúbrica en media hora, se lanza sobre cincuenta ejemplos inventados y sale un 4,1 que nadie sabe interpretar. El orden correcto es el inverso y está formulado en una sola regla, que el equipo de Airbnb resumió en 2026 al contar cómo evalúan sus funciones generativas: ante la duda, mira tus datos. Reunir alrededor de cien salidas reales del sistema, leerlas una a una, anotar en texto libre qué está mal en cada una, agrupar después esas anotaciones en categorías y contarlas. Son dos o tres horas de trabajo incómodo y producen algo que ninguna sesión de diseño produce: la lista de los fallos que el sistema comete de verdad, ordenada por frecuencia. El procedimiento tiene nombre fuera de la informática. Es la codificación abierta y axial de la teoría fundamentada que Glaser y Strauss describieron en 1967 para la investigación cualitativa: primero se etiqueta lo que se ve sin un esquema previo, después se agrupan las etiquetas en categorías, y las categorías emergen del material en lugar de imponerse sobre él. Aplicado a trazas de un sistema de lenguaje, produce una taxonomía de fallos con su frecuencia, y esa taxonomía es literalmente la especificación del sistema de evaluación: cada categoría frecuente necesita un puntuador, y cada puntuador necesita casos donde falle y casos donde no. Hay una razón teórica para no invertir el orden, y es el hallazgo más interesante de la literatura reciente sobre este asunto. Shreya Shankar y sus coautores lo llamaron en 2024 *deriva de criterios*: para puntuar salidas hace falta haber explicitado el criterio, pero el criterio solo se explicita al puntuar salidas. Cuando pidieron a profesionales que definieran de antemano qué hacía buena a una respuesta y luego los pusieron a evaluar, los criterios cambiaron al contacto con el material, y no por capricho: había requisitos que nadie podía anticipar porque dependían de fallos concretos que el modelo aún no había cometido. La consecuencia práctica es que la rúbrica y el corpus son un mismo objeto que evoluciona junto, que ambos se versionan, y que una rúbrica escrita antes de ver cien salidas está garantizada como incompleta. Contados los fallos, aparece la pregunta de cuántos ejemplos hay que mirar. La respuesta depende de una propiedad que casi siempre se cumple: los modos de fallo no se reparten por igual, sino que unos pocos concentran la mayoría de los casos y hay una cola larga de rarezas que aparecen una vez cada varios cientos. La figura siguiente permite jugar con esa distribución. Lo que enseña la figura es la asimetría entre volumen y variedad. Con cien trazas leídas se ha visto ya lo que causa la mayor parte de las quejas —con los valores de partida de la figura, el ochenta por ciento de los fallos— y esa es la razón por la que la cifra de cien se repite en todas las guías; pero cerca de la mitad de las maneras distintas de fallar sigue sin aparecer, y entre ellas están las que un día provocan un incidente. De ahí salen dos decisiones de diseño. La primera es que el muestreo aleatorio sirve para *estimar* y no para *descubrir*: para encontrar la cola hay que ir a buscarla en los sitios donde se acumula, es decir, en las quejas de usuarios, en las salidas más largas y más cortas, en los idiomas minoritarios, en las entradas que dieron error. La segunda es que el corpus no se termina nunca. Cada incidente en producción añade un caso, y un corpus que no crece desde los fallos reales envejece hasta medir un sistema que ya no existe. Un buen corpus tiene, además de casos representativos, cinco familias de casos deliberados que nunca salen de una muestra aleatoria. Los **extremos de calibración** fijan los bordes del juicio. Si el sistema estima sueldos, el corpus necesita el puesto peor pagado de una ciudad barata y el mejor pagado de una cara; si redacta anuncios, el perfil con diez años de experiencia y el de una línea. Un sistema que acierta en el centro de la distribución y se derrumba en los extremos parece bueno en la media y es inservible para el caso que más importa. La **dispersión de mercados e idiomas** es la que más veces se descubre tarde. Los detectores y las reglas se escriben en la lengua del equipo, se prueban en esa lengua y pasan; en las demás no fallan ruidosamente, fallan en silencio, dejando pasar todo. El síntoma es una tasa de detección sospechosamente limpia en un idioma que nadie del equipo habla. Las **entradas degeneradas** son las que ningún diseñador dibuja: el campo vacío, el título de doscientos caracteres, el texto que es solo emojis, la descripción que repite `asdfasdf`, el documento con dos requisitos contradictorios. La regla de oro es que ninguna de ellas debe producir una respuesta segura de sí misma. Un sistema que ante un texto sin sentido devuelve una valoración impecable y sin objeciones no está evaluando nada, y solo se descubre si el caso está en el corpus. Los **casos adversariales** comprueban el modelo de amenazas, y aquí el diseño del caso es la mitad del trabajo. Para la inyección de instrucciones, la técnica es el canario: se esconde en el texto de entrada una orden que pide emitir una cadena concreta e improbable, y la prueba pasa si esa cadena no aparece en la salida, cualquiera que sea el resto de la respuesta. Para la filtración de datos personales, se siembran un nombre, un teléfono y un correo en la entrada y se comprueba que no salen. Estos casos no admiten media: una filtración entre cien no es un noventa y nueve por ciento de acierto, es un fallo de la ejecución entera. Las **guardas de falso positivo** son las que casi nadie escribe y las que salvan el producto. Son casos legítimos que el sistema *no* debe marcar: en un revisor de textos de oferta de empleo, convenciones perfectamente válidas como la marca de género neutro que usa el mercado alemán, o un título con un número romano de nivel. Sin estas guardas, la métrica premia siempre endurecer el sistema —cada vuelta de tuerca sube la detección— y el producto se degrada en la dirección exacta que destruye la confianza del usuario: la alarma constante sobre texto correcto. Con ellas, el endurecimiento tiene un coste medido y la discusión deja de ser de opiniones. El formato del caso merece una decisión explícita, porque determina quién puede escribirlo. La forma que mejor aguanta es un fichero de texto por caso, con una cabecera de datos en claves legibles por una persona —`ciudad: berlín`, no un identificador—, unas líneas de prosa que explican el escenario y por qué es difícil, un apartado por dimensión con el criterio de evaluación, y un bloque de expectativas mecánicas que se compila en comprobaciones deterministas. Un fichero así lo revisa el responsable de producto sin saber programar, lo comenta en una revisión de código como cualquier otro cambio, se lee en el diff y sobrevive intacto a la migración de la herramienta. Es tentador guardar el corpus en una base de datos con una interfaz bonita, y el coste de esa decisión es que el corpus deja de tener historia y deja de ser propiedad de todo el equipo. Falta la parte más delicada, que es la etiqueta. Alguien tiene que decir cuál es la respuesta correcta, y lo primero que aparece cuando eso se hace en serio es que dos personas competentes no coinciden. Medir ese desacuerdo es obligatorio antes de automatizar nada, y la medida estándar es la kappa de Cohen, propuesta en 1960 precisamente para corregir el acuerdo que se obtendría por azar: dos anotadores que marcan «correcto» el noventa por ciento de las veces coincidirán mucho sin saber nada. Si la kappa entre dos expertos es baja, el problema no es de los anotadores sino de la definición, y no hay juez automático que arregle un criterio que los humanos no comparten. La regla de operación que funciona es sencilla: una persona designada es dueña de los desacuerdos y su resolución se escribe en la guía de anotación como ejemplo, de modo que la guía crece con los casos límite reales. Ese acuerdo entre humanos es además la cota superior de cualquier automatización posterior: nadie puede pedirle a un juez automático que coincida con los humanos más de lo que los humanos coinciden entre sí. El muestreo esconde una trampa que conviene contar con detalle porque cambia titulares. Cuando un corpus se extrae de producción, es normal querer dos cosas a la vez: una muestra proporcional, que respete el peso real de cada segmento, y un suelo por segmento, que garantice unos cuantos casos de los mercados pequeños para que no desaparezcan. Ambas son razonables y la tentación es sacar las dos de un mismo volcado y promediar el resultado. Eso no es la tasa base de nada. El suelo sobremuestrea exactamente los segmentos que existe para rescatar, de modo que el agregado se inclina hacia ellos; en un caso medido, un primer informe sobre seiscientos casos situó a un idioma con el triple de tasa de fallo que el mayoritario, y al ampliar la muestra a dos mil el mismo idioma cayó a la tercera parte de aquella cifra y el orden entre los intermedios resultó ser ruido. Las celdas de cincuenta o setenta casos llevan intervalos de más o menos diez puntos, y con eso no se ordena nada. La disciplina que resuelve el problema tiene tres partes: marcar cada fila con el criterio por el que entró, informar por separado de la media cruda, de la muestra proporcional sola y de una ponderación por volumen real de cada segmento, y tratar como resultado solo lo que sobrevive a las tres. Queda la contaminación, que en un corpus propio toma una forma distinta de la de los exámenes públicos. Sainz y sus coautores documentaron en 2023 el caso general —las pruebas públicas acaban dentro de los datos de entrenamiento y dejan de medir— pero en un producto el riesgo habitual es más doméstico: que el caso de prueba contenga, sin que nadie se dé cuenta, la respuesta que el sistema debía encontrar. Un corpus de tareas de programación extraído del propio repositorio filtra la solución si el agente puede leer la historia posterior; un corpus para un sistema de recuperación filtra si el fragmento correcto está pegado en el enunciado. La comprobación mecánica que atrapa la mayoría de estos casos es sencilla: los identificadores que aparecen en la solución no deben aparecer en el enunciado. Y por el mismo motivo conviene mantener congelado un conjunto de retención, etiquetado a mano, que no se usa para iterar y solo se mira de vez en cuando; es la única defensa contra el ajuste involuntario del sistema a su propio corpus. Dos avisos finales, de distinta naturaleza y los dos caros. El primero es legal y ético: un corpus sacado de tráfico real contiene datos de personas, y pasa a ser un activo que hay que redactar, restringir y no publicar en un informe. Conviene automatizar la anonimización en el mismo guion que extrae los datos, y no confiar en que quien lo ejecute se acuerde; y conviene saber qué hace exactamente esa anonimización, porque una herramienta que trunca los textos largos o que solo reconoce formatos canónicos deja pasar en prosa lo que bloquea en un campo. El segundo es de método, y lo formularon bien los autores de Dynabench en 2021: un corpus fijo se agota, porque los sistemas aprenden a resolverlo y deja de discriminar. Su propuesta era un banco de pruebas dinámico, alimentado por humanos que buscan activamente ejemplos donde el modelo falla. En un producto no hace falta montar esa infraestructura: basta con que la persona que responde de la calidad dedique media hora a la semana a intentar romperlo a mano, y que cada caso con el que lo consiga entre en el corpus esa misma tarde. ## Fuentes - Jacob Cohen — *A Coefficient of Agreement for Nominal Scales*, Educational and Psychological Measurement 20(1) (1960) - Barney G. Glaser y Anselm L. Strauss — *The Discovery of Grounded Theory: Strategies for Qualitative Research*, Aldine, Chicago (1967) - Marco Tulio Ribeiro, Tongshuang Wu, Carlos Guestrin y Sameer Singh — *Beyond Accuracy: Behavioral Testing of NLP Models with CheckList*, Proceedings of the 58th Annual Meeting of the Association for Computational Linguistics (2020) - Douwe Kiela y otros — *Dynabench: Rethinking Benchmarking in NLP*, Proceedings of the 2021 Conference of the North American Chapter of the ACL (2021) - Shreya Shankar, J.D. Zamfirescu-Pereira, Björn Hartmann, Aditya G. Parameswaran e Ian Arawjo — *Who Validates the Validators? Aligning LLM-Assisted Evaluation of LLM Outputs with Human Preferences*, Proceedings of the 37th ACM Symposium on User Interface Software and Technology (UIST) (2024) - Oscar Sainz, Jon Ander Campos, Iker García-Ferrero, Julen Etxaniz, Oier Lopez de Lacalle y Eneko Agirre — *NLP Evaluation in Trouble: On the Need to Measure LLM Data Contamination for each Benchmark*, Findings of the Association for Computational Linguistics: EMNLP 2023 (2023) - Rohit Girme, Dan Miller, Mia Zhao, Lifan Yang y Clint Kelly — *Eval-Driven Development: Lessons from Evaluating GenAI at Scale*, Airbnb Tech Blog (2026) - Shreya Shankar y Hamel Husain — *Evals for AI Engineers: Systematically Measuring and Improving AI Applications*, O'Reilly Media (2026) --- Cómo citar: Sarasola, Josemari (2026). «El corpus de evaluación». Ikusmira. https://ikusmira.org/p/el-corpus-de-evaluacion/ Índice del sitio para modelos: https://ikusmira.org/llms.txt