Enfoques para evaluar modelos fundacionales

Pasaste el tema anterior ajustando un modelo. Responde bien tus prompts de prueba, la demo salió bien y el equipo quiere lanzar. Entonces alguien hace la única pregunta que importa: ¿es realmente mejor que el modelo base con el que empezaste, y mejor por cuánto?

"Se veía bien cuando lo probé" no es una respuesta. Diez prompts escritos por la misma persona que construyó la cosa es la evidencia más débil que existe en software. Este tema trata de reemplazar eso por algo defendible, y arranca aquí, con las tres familias de evidencia que puedes reunir y cuánto vale cada una.

Por qué es difícil calificar un modelo generativo

Un clasificador es fácil de calificar. Le pasas 1.000 correos etiquetados, cuentas cuántos marcó bien como spam y tienes accuracy. Cada entrada tiene exactamente una respuesta correcta, así que puntuar es aritmética.

Un modelo fundacional rompe eso. Pídele que resuma un reporte de incidente y hay cientos de buenos resúmenes y ninguno correcto. Dos resúmenes pueden no compartir casi ninguna palabra y ser los dos excelentes. Así que no hay nada con lo que comparar por igualdad, y todos los enfoques de abajo son formas distintas de rodear ese único problema.

Quédate con ese encuadre, porque explica el diseño completo de las herramientas. La evaluación automática lo rodea comparando contra una respuesta de referencia y midiendo similitud en vez de igualdad. Un modelo juez lo rodea leyendo la salida y calificándola. La evaluación humana lo rodea preguntándole a personas. Tres respuestas a la misma pregunta incómoda.

La analogía de la calificación, y dónde se rompe

Piensa en calificar ensayos de estudiantes. Una pauta que cuenta palabras clave obligatorias es rápida, consistente y ciega ante un ensayo bien argumentado que usó otras palabras. Un ayudante de cátedra con una rúbrica lee buscando significado y escala a cien trabajos. El examinador es la autoridad real pero solo alcanza a leer unos pocos.

Las métricas automáticas son la pauta de palabras clave, un modelo juez es el ayudante de cátedra, y los revisores humanos son el examinador. La analogía se rompe en un punto que vale recordar: un ayudante que estudió del mismo libro que el estudiante comparte sus puntos ciegos. Un modelo juez tiene el mismo problema, y por eso nadie trata los puntajes del juez como ground truth.

Enfoque 1: evaluación automática contra un dataset

La evaluación automática, que Bedrock también llama evaluación programática, corre tu modelo sobre un conjunto de prompts y calcula puntajes sin humanos en el medio. Al crear el trabajo eliges tres cosas: un tipo de tarea, las métricas que quieres y el dataset de prompts.

El tipo de tarea le dice a Bedrock qué clase de trabajo hace el modelo, y eso decide qué se puede medir. Bedrock ofrece generación general de texto, resumen de texto, pregunta y respuesta, y clasificación de texto, más una opción personalizada.

Las métricas se agrupan en tres familias que vas a volver a ver en todo el tema:

• Accuracy es qué tan cerca está la salida de una respuesta de referencia.
• Robustness es cuánto cae la calidad cuando la entrada se perturba sin cambiar su significado: errores de tipeo, cambios aleatorios de mayúsculas, espacios agregados o eliminados.
• Toxicity es si la salida contiene lenguaje dañino, puntuado por un modelo detector de toxicidad y no por comparación con una referencia.

Accuracy y robustness necesitan las dos saber cuál es la respuesta correcta. Toxicity no, porque juzga la salida por sí sola.

Datasets integrados, y los tuyos

Bedrock trae datasets de prompts integrados para que puedas correr un trabajo antes de haber escrito cualquier dato de prueba. Cada uno es una muestra aleatoria de 100 prompts de un dataset abierto conocido, y cada uno viene emparejado con el tipo de tarea y la métrica que le sirve.

Sirven para una primera pasada y para chequeos de sanidad, y no son tu aplicación. Un asistente de soporte que responde preguntas sobre tu producto no se decide con BoolQ. Para eso existe un dataset de prompts propio.

Un dataset propio es un archivo JSONL en Amazon S3, de hasta 1.000 prompts por trabajo, con un objeto JSON por línea:

{"prompt": "Aurillac is the capital of", "referenceResponse": "Cantal", "category": "Capitals"}
{"prompt": "Bamiyan city is the capital of", "referenceResponse": "Bamiyan Province", "category": "Capitals"}
{"prompt": "Sokhumi is the capital of", "referenceResponse": "Abkhazia", "category": "Capitals"}

prompt es la entrada que recibe el modelo. referenceResponse es el ground truth, y es obligatorio para accuracy y robustness porque sin él esas métricas no tienen con qué comparar. category es opcional y te compra puntajes desglosados por grupo, que es la forma de descubrir que un modelo anda bien en preguntas de facturación y flojo en devoluciones.

El esfuerzo de escribir 200 prompts reales con respuestas reales es lo más valioso que hace un equipo antes de lanzar, y es el paso que se saltea.

Datasets de benchmark, y la trampa del leaderboard

Los benchmarks públicos son datasets compartidos que permiten comparar modelos con las mismas preguntas. Unos cuantos nombres aparecen todo el tiempo:

• GLUE y SuperGLUE reúnen tareas de comprensión de lenguaje como inferencia y similitud entre oraciones.
• MMLU, Massive Multitask Language Understanding, es un examen de opción múltiple que cubre 57 materias, desde matemática elemental hasta historia de Estados Unidos, ciencias de la computación y derecho, diseñado para sondear conocimiento general del mundo y resolución de problemas.
• HELM, Holistic Evaluation of Language Models, puntúa modelos en 42 escenarios con 7 métricas: accuracy, calibración, robustness, equidad, sesgo, toxicidad y eficiencia. Su punto es que accuracy sola es una descripción muy pobre de un modelo.

Ahora la confusión, y es la cara. Es tentador leer un leaderboard como un ranking de qué modelo es mejor para ti. No lo es. Un benchmark mide desempeño sobre los datos y la mezcla de tareas de ese benchmark, y tu aplicación no tiene ninguno de los dos. Un modelo que lidera MMLU puede ser mediocre resumiendo tus reportes de incidentes en el formato que necesitan tus ingenieros de guardia. Los benchmarks populares también se filtran con el tiempo a los datos de entrenamiento, lo que infla los puntajes sin mejorar el modelo.

La regla de trabajo: los benchmarks arman tu lista corta, tu propio dataset de prompts elige al ganador. HELM sirve como correctivo acá porque obliga a comparar en varias dimensiones en lugar de un número.

Enfoque 2: un LLM como juez

La evaluación con juez usa un segundo modelo para puntuar al primero. El trabajo necesita dos modelos en dos roles. El modelo generador responde los prompts de tu dataset. El modelo evaluador lee cada par de prompt y respuesta, asigna un puntaje y escribe una explicación de por qué puntuó así.

Bedrock trae métricas integradas que puedes elegir, y puedes definir métricas propias para tus criterios. Las integradas cubren mucho más terreno que cualquier puntaje de similitud:

Dos cosas hacen atractivo este enfoque. La mayoría de estas métricas no necesita respuesta de referencia, así que puedes evaluar trabajo abierto donde no existe ground truth. Y corre a velocidad y costo de máquina, así que puntúas 500 respuestas en el tiempo que un panel humano necesita para 20.

También puedes aportar una respuesta de referencia, y el evaluador la tomará en cuenta al puntuar correctness y completeness. Y si evalúas un modelo fuera de Bedrock, puedes entregar tus propias respuestas de inferencia: Bedrock se salta el paso de invocar y puntúa los datos que aportaste.

El límite es el de la analogía: el juez es un modelo fundacional. Tiene preferencias sobre el fraseo y el largo, y puede equivocarse con seguridad. Los puntajes del juez son evidencia fuerte, no veredictos, y los equipos que dependen de ellos revisan una muestra a mano.

Enfoque 3: evaluación humana

La evaluación humana pone personas en el circuito. En Bedrock creas un work team, que puede ser tu propio personal o expertos de tu industria, administrado con un user pool de Amazon Cognito creado desde la consola. Un trabajo humano puede calificar un modelo o comparar respuestas de dos.

El mecanismo de calificación decide qué aprendes:

Los mecanismos comparativos responden "qué modelo prefiere la gente", y los individuales responden "es este modelo lo bastante bueno". Los dos dependen de las instrucciones que escribas. Una escala de 5 puntos sin anclas definidas produce cinco revisores usando cinco escalas distintas, y el histograma que vuelve es ruido.

Recurre a humanos cuando la barra de calidad es subjetiva (voz, tono, tacto), cuando hace falta criterio de dominio (¿este resumen legal está realmente bien?), o cuando lo que está en juego hace caro un error. Acepta el costo: es más lento y más caro que todo lo demás acá, y por eso los equipos lo reservan para la decisión final y la auditoría periódica en vez del ciclo diario.

Elegir un enfoque

La regla de decisión que cubre la mayoría de las preguntas de escenario: si la pregunta te entrega una respuesta de referencia o pide un puntaje repetible a volumen, es automática. Si pregunta por cualidades como helpfulness o faithfulness sobre salida abierta a volumen, es un modelo juez. Si aparecen las palabras "experto de dominio", "preferencia", "tono" o "subjetivo", es evaluación humana.

No son excluyentes, y los equipos reales las apilan: métricas automáticas en el pipeline con cada cambio, métricas de juez cada semana sobre una muestra más grande, humanos sobre el candidato a release.

Consejos para el examen

• La guía del examen nombra dos enfoques directamente: evaluación humana y datasets de benchmark. Reconoce el tercero, la evaluación con juez, por su estructura de dos modelos: un generador y un evaluador.
• Accuracy y robustness necesitan respuesta de referencia. Toxicity, helpfulness y la mayoría de las métricas del juez no. Las preguntas sobre "no hay ground truth disponible" están descartando el puntaje basado en referencia.
• "Expertos de dominio", "preferencia entre dos modelos" o una barra de calidad subjetiva apuntan a evaluación humana. "Puntuar miles de respuestas abiertas de forma barata" apunta a un modelo juez.
• Empareja cada dataset integrado con su propósito: RealToxicityPrompts para toxicidad, BOLD para sesgo en generación abierta, Gigaword para resumen, BoolQ, NaturalQuestions y TriviaQA para pregunta y respuesta, TREX para conocimiento factual.
• Cualquier opción que afirme que un puesto en un leaderboard público prueba la aptitud para un caso de negocio específico es falsa.
• Robustness trata de perturbaciones de la entrada que no cambian el significado, como errores de tipeo y mayúsculas. No la confundas con accuracy sobre entrada limpia.

El punto para llevar: un enfoque de evaluación se elige por la evidencia que tienes y por lo que significa calidad en tu aplicación, no por qué herramienta resulta más cómoda. Lo que viene es la capa debajo de la palabra "accuracy": las métricas concretas que convierten dos textos en un número.