Evaluación de LLM

La evaluación de LLM es la práctica de probar de forma sistemática lo que produce un gran modelo de lenguaje, para que puedas saber si es preciso, seguro y apto para la tarea antes y después de desplegarlo. Como estos modelos generan texto abierto en lugar de una única etiqueta correcta, no puedes juzgarlos con un solo número de exactitud. La evaluación tiene que cubrir varias dimensiones, a menudo con una mezcla de puntuación automatizada y revisión humana.

La razón por la que esto recibe tanta atención es que el comportamiento de un LLM es difícil de predecir. El mismo modelo puede ser útil en un prompt y estar confiadamente equivocado en otro apenas distinto. Sin una evaluación estructurada, los equipos lanzan según la intuición y descubren las fallas en producción, que es justo lo que los marcos de gobernanza intentan evitar.

Qué se mide

Una evaluación útil de LLM observa varias propiedades, porque un modelo puede puntuar bien en una y mal en otra.

Corrección. ¿La respuesta coincide con el resultado esperado o con hechos conocidos? Para tareas con una respuesta correcta, esta es la métrica central.

Fidelidad. En sistemas que aportan contexto, como la generación aumentada por recuperación, ¿la respuesta se mantiene anclada en la fuente provista en lugar de agregar afirmaciones sin sustento? Una respuesta infiel es una alucinación aunque suene plausible.

Tasa de alucinación. ¿Con qué frecuencia el modelo afirma cosas que no son ciertas o que no tienen sustento? Esta es una de las propiedades de seguridad más importantes para cualquier uso factual.

Sesgo. ¿El modelo trata a los grupos de forma distinta de maneras que no se justifican, por ejemplo produciendo respuestas sistemáticamente diferentes según nombres, género u otros atributos protegidos?

Toxicidad. ¿El modelo produce contenido dañino, acosador o de otro modo inaceptable, incluso cuando se le incita de forma adversaria?

Relevancia y utilidad. ¿La respuesta aborda de verdad la pregunta, con el nivel de detalle adecuado y en el formato esperado?

Los equipos eligen las dimensiones que importan para su caso de uso y definen métricas para cada una, en lugar de perseguir un solo número.

Cómo se hace la evaluación

Hay tres enfoques comunes, que suelen combinarse.

Puntuación basada en referencia. Comparas la salida del modelo con una respuesta correcta conocida usando coincidencia exacta, métricas de solapamiento o similitud. Esto funciona cuando hay un objetivo claro, pero le cuesta con las respuestas abiertas donde muchas redacciones son válidas.

Revisión humana. Las personas califican las salidas contra una rúbrica. Es el enfoque más confiable para cualidades sutiles como la utilidad y el tono, pero es lento y costoso, así que suele aplicarse a muestras.

LLM como juez. Un modelo de lenguaje aparte califica las salidas según criterios que tú defines, por ejemplo evaluando la fidelidad o detectando toxicidad. Esto escala mucho mejor que la revisión humana y correlaciona razonablemente bien cuando la rúbrica es clara. Tiene límites: los modelos jueces pueden tener sesgo, ser inconsistentes y ser engañados, así que los equipos los calibran contra calificaciones humanas y no tratan sus puntuaciones como verdad de base.

La mayoría de los montajes maduros usan métricas basadas en referencia donde las respuestas son deterministas, un LLM juez para escalar y revisión humana sobre muestras para mantener honesto al juez.

Cómo armar un conjunto de evaluación

Una buena evaluación depende de buenos datos de prueba. Los equipos arman un conjunto de entradas representativas, incluyendo casos ordinarios, casos límite y prompts adversarios pensados para provocar fallas. Para muchas dimensiones también registran una respuesta esperada o una rúbrica.

El conjunto debe reflejar el uso real y los modos de falla que de verdad harían daño: las preguntas que hacen los usuarios, las entradas que ya causaron problemas antes y las categorías donde una respuesta equivocada tiene consecuencias. Un conjunto estático ejecutado en cada cambio del modelo convierte la evaluación en una prueba de regresión, así que puedes ver si una actualización mejoró o empeoró las cosas.

Por qué la gobernanza y los reguladores quieren evidencia de evaluación

La evaluación no es solo un detalle de ingeniería, es cada vez más la evidencia que prueba que un sistema fue probado.

Bajo la Ley de IA de la UE, los sistemas de alto riesgo deben probarse en cuanto a exactitud, robustez y resiliencia, y esas pruebas tienen que documentarse. Los resultados de evaluación son una parte natural de la documentación técnica que demuestra que el sistema rinde como se afirma y que se revisó en busca de los riesgos relevantes.

La norma ISO 42001, el estándar de sistemas de gestión de IA, espera que las organizaciones definan criterios de desempeño, prueben contra ellos y guarden registros como parte de la mejora continua. La evaluación es la forma de generar esos registros.

El Marco de Gestión de Riesgos de IA del NIST pide de forma similar medir los riesgos de la IA, lo que significa tener métricas definidas y resultados de prueba en lugar de garantías.

Para los equipos de gobernanza el mensaje es coherente: define qué significa bueno, pruébalo, anota los resultados y vuelve a probar cuando el modelo o su uso cambien. Un auditor querrá ver el conjunto de evaluación, las métricas, las puntuaciones y la evidencia de que las fallas se atendieron.

Preguntas frecuentes

¿Por qué no puedo usar solo la exactitud para evaluar un LLM?

Porque la mayoría de las salidas de un LLM son texto abierto, no una única etiqueta correcta, así que un solo número de exactitud pasa por alto casi todo lo que importa. Un modelo puede ser preciso en hechos y aun así tener sesgo, ser tóxico bajo presión o ser infiel a sus fuentes. Una evaluación útil mide varias dimensiones y ajusta cada una a la forma en que el modelo se usa de verdad.

¿Qué es el LLM como juez?

Es usar un modelo de lenguaje aparte para calificar las salidas según criterios que tú defines, como la fidelidad o la toxicidad. Escala mucho mejor que la revisión humana y funciona razonablemente bien cuando la rúbrica es clara. El detalle es que los modelos jueces pueden tener sesgo, ser inconsistentes o ser engañados, así que los calibras contra calificaciones humanas en lugar de confiar en sus puntuaciones a ciegas.

¿Cuál es la diferencia entre corrección y fidelidad?

La corrección pregunta si la respuesta es factualmente correcta frente a una verdad conocida. La fidelidad pregunta si la respuesta se mantiene anclada en el contexto específico que el sistema proveyó, por ejemplo documentos recuperados, sin agregar afirmaciones sin sustento. Una respuesta puede ser fiel a una fuente equivocada, o correcta en general aunque se aleje de la fuente, así que ambas vale la pena medirlas en sistemas de recuperación.

¿Con qué frecuencia debo evaluar un modelo?

Antes del despliegue, y de nuevo cada vez que el modelo, sus prompts o sus fuentes de datos cambien. Ejecutar un conjunto de evaluación fijo en cada cambio lo convierte en una prueba de regresión, así que puedes ver si una actualización mejoró o degradó el comportamiento. Los usos de alto riesgo justifican una evaluación continua en producción, no solo una revisión única.

¿Cómo evalúo el sesgo y la toxicidad?

Usa conjuntos de prueba dirigidos: entradas variadas entre atributos protegidos para sacar a la luz diferencias injustificadas en el caso del sesgo, y prompts adversarios diseñados para provocar salidas dañinas en el caso de la toxicidad. Califica con clasificadores o con un LLM juez, y confirma con revisión humana sobre muestras. La idea es sondear de forma deliberada estas fallas en lugar de esperar que no ocurran.

¿Qué evidencia esperan los reguladores de la evaluación?

Quieren ver que definiste qué significa un buen desempeño, que probaste contra ello y que documentaste los resultados. Para la Ley de IA de la UE eso significa pruebas de exactitud y robustez en la documentación técnica. Para la ISO 42001 significa criterios de desempeño y resultados de prueba registrados. Los artefactos son tu conjunto de evaluación, tus métricas, tus puntuaciones y la prueba de que las fallas se atendieron.

Resumen

La evaluación de LLM es la prueba sistemática de las salidas del modelo en dimensiones como corrección, fidelidad, alucinación, sesgo, toxicidad y relevancia, porque ningún número único de exactitud captura cómo se comporta un modelo de texto abierto. Los equipos combinan puntuación basada en referencia, revisión humana y LLM como juez, ejecutando un conjunto de evaluación representativo como prueba de regresión cada vez que el modelo o su uso cambian. Más allá del valor de ingeniería, la evaluación produce la evidencia que exige la gobernanza: la Ley de IA de la UE, la ISO 42001 y el NIST AI RMF esperan métricas definidas, resultados de prueba documentados y prueba de que las fallas identificadas se atendieron.