Evaluación del rendimiento de modelos fundacionales
Evaluar modelos fundacionales no consiste solo en preguntar “¿responde bien?”. En una aplicación real hay que comprobar si el modelo responde con precisión, si respeta las políticas de seguridad, si reduce alucinaciones, si es consistente, si cumple los requisitos de latencia y coste, y si realmente aporta valor al negocio. Para AIF-C01, esta página es clave porque el examen espera que sepas comparar modelos y enfoques con criterios técnicos, operativos y empresariales.
1. Qué significa evaluar un modelo fundacional
Un modelo fundacional puede parecer muy bueno en una demo, pero fallar en producción. Puede generar respuestas fluidas, pero inventadas; puede ser excelente en inglés, pero débil en español; puede tener gran calidad, pero una latencia inaceptable; o puede resolver el caso, pero con un coste demasiado alto por petición.
Evaluar un modelo fundacional significa medir si el modelo y la aplicación construida alrededor de él cumplen el objetivo del caso de uso. En GenAI casi nunca se evalúa solo el modelo aislado: también se evalúan el prompt, el contexto, el RAG, los guardrails, el control de acceso, los parámetros de inferencia y la experiencia final del usuario.
Relevancia, exactitud factual, completitud, coherencia, tono, formato y capacidad para reconocer que no tiene información suficiente.
Fugas de información, toxicidad, sesgos, respuestas no permitidas, cumplimiento de políticas y resistencia a intentos de manipulación.
Latencia, disponibilidad, errores, escalabilidad, coste por petición, uso de tokens y comportamiento bajo carga.
Productividad, reducción de tiempo, satisfacción del usuario, resolución en primer contacto, menor esfuerzo manual o mejor calidad del proceso.
2. Evaluar el modelo frente a evaluar la aplicación
En el examen debes distinguir dos niveles. Por un lado, está la evaluación del modelo como capacidad general. Por otro lado, está la evaluación de la solución completa que usa ese modelo.
| Nivel | Qué se evalúa | Ejemplo |
|---|---|---|
| Modelo | Capacidad general para resumir, razonar, generar texto, traducir, clasificar o seguir instrucciones. | Comparar dos modelos para ver cuál responde mejor a preguntas de soporte en español. |
| Prompt | Si las instrucciones producen salidas consistentes, con el tono, estructura y restricciones esperadas. | Probar zero-shot frente a few-shot para obtener siempre un JSON válido. |
| RAG | Si recupera fragmentos relevantes, si reduce alucinaciones y si cita o usa fuentes autorizadas. | Evaluar si un asistente responde correctamente con documentación interna actualizada. |
| Aplicación completa | Calidad, seguridad, permisos, latencia, coste, auditoría, experiencia de usuario y valor de negocio. | Validar un chatbot interno antes de abrirlo a todos los empleados. |
Idea de examen
Si la pregunta dice que “el modelo responde bien en pruebas simples”, pero falla con documentos internos o usuarios reales, la respuesta correcta no suele ser “publicarlo ya”. Suele ser ampliar la evaluación con casos representativos, revisión humana, métricas de seguridad y pruebas operativas.
3. Evaluación humana
La evaluación humana es esencial cuando las respuestas tienen matices: tono, utilidad, empatía, claridad, seguridad, corrección factual o adecuación al contexto. Muchas salidas generativas no tienen una única respuesta correcta, por lo que una métrica automática puede quedarse corta.
Un revisor humano puede valorar si una respuesta es aceptable para el negocio, si cumple el estilo corporativo, si explica bien una política, si evita lenguaje inapropiado o si maneja correctamente una situación sensible.
Cuándo usar evaluación humana
- Cuando la respuesta afecta a clientes, empleados o decisiones sensibles.
- Cuando se evalúa tono, empatía, claridad o utilidad.
- Cuando hay riesgo de sesgo, daño reputacional o incumplimiento.
- Cuando se comparan modelos que tienen métricas automáticas similares.
- Cuando el caso requiere revisar si el modelo sabe reconocer incertidumbre.
4. Benchmarks y datasets de referencia
Un benchmark es un conjunto de pruebas usado para comparar modelos bajo condiciones similares. Puede ser público o creado por la propia organización. En un entorno empresarial, lo más importante no es solo un benchmark genérico, sino un conjunto representativo de ejemplos del caso de uso real.
Para AIF-C01, debes recordar que los benchmarks ayudan a comparar, pero no sustituyen la validación con datos y escenarios reales de la organización.
| Tipo de conjunto | Ventaja | Limitación |
|---|---|---|
| Benchmark público | Permite comparar modelos de forma estándar. | Puede no representar el dominio, idioma, tono o riesgo real de tu caso. |
| Dataset interno | Refleja preguntas reales, documentos propios y casos frecuentes. | Debe cuidarse privacidad, representatividad y calidad de etiquetas. |
| Casos límite | Ayuda a detectar fallos antes de producción. | No mide por sí solo el comportamiento promedio. |
| Conjunto de seguridad | Prueba fugas, toxicidad, prompt injection o temas prohibidos. | Requiere actualización continua porque los ataques y usos cambian. |
5. Métricas automáticas: ROUGE, BLEU y BERTScore
Las métricas automáticas permiten comparar salidas de modelos de forma más rápida. En AIF-C01 no necesitas calcularlas a mano, pero sí entender para qué sirven y sus limitaciones.
| Métrica | Qué intenta medir | Uso habitual | Limitación |
|---|---|---|---|
| ROUGE | Solapamiento entre la respuesta generada y una referencia, especialmente en resúmenes. | Evaluación de tareas de resumen. | Puede favorecer coincidencia de palabras, aunque el significado no sea perfecto. |
| BLEU | Coincidencia de n-gramas entre una traducción o texto generado y una referencia. | Traducción automática y generación con referencia. | No siempre captura naturalidad, tono o equivalencia semántica. |
| BERTScore | Similitud semántica usando embeddings/contexto del lenguaje. | Comparar significado de respuestas aunque no usen las mismas palabras. | Puede seguir sin capturar requisitos de negocio, seguridad o cumplimiento. |
| Exactitud factual | Si la respuesta es correcta y está respaldada por fuentes. | Asistentes documentales, RAG, soporte técnico. | Puede requerir revisión humana o verificación contra fuentes. |
6. Métricas de calidad para aplicaciones GenAI
Además de ROUGE, BLEU o BERTScore, una aplicación con modelos fundacionales necesita métricas más cercanas al uso real. Estas métricas se adaptan al tipo de aplicación.
La respuesta aborda la pregunta del usuario y no se va por otro tema.
Incluye la información necesaria sin omitir pasos o condiciones importantes.
No inventa datos y se basa en fuentes o conocimiento válido.
Responde de forma estable ante preguntas equivalentes y respeta el formato esperado.
7. Evaluar alucinaciones
Una alucinación es una respuesta que parece correcta pero no está respaldada por datos válidos. En aplicaciones empresariales, especialmente con documentación interna, las alucinaciones son una de las principales razones para evaluar antes de producción.
Para evaluarlas, puedes crear preguntas donde la documentación no tenga respuesta, preguntas ambiguas o preguntas diseñadas para comprobar si el modelo inventa. Un buen asistente debe poder decir “no tengo información suficiente” cuando corresponde.
8. Evaluar RAG
Cuando una aplicación usa RAG, no basta con evaluar la respuesta final. También hay que evaluar si el sistema recupera los fragmentos adecuados. Un mal resultado puede deberse al modelo, al prompt, al chunking, a los embeddings, al vector store, a los filtros de metadatos o a permisos mal aplicados.
| Parte de RAG | Qué evaluar | Señal de problema |
|---|---|---|
| Ingesta documental | Documentos actualizados, limpios y autorizados. | El asistente responde con políticas antiguas. |
| Chunking | Tamaño, solapamiento y preservación de contexto. | Recupera fragmentos demasiado pequeños o incompletos. |
| Retrieval | Relevancia de los fragmentos recuperados. | La respuesta falla aunque el documento correcto existe. |
| Generación | Uso correcto del contexto recuperado. | El modelo ignora la fuente o inventa detalles. |
| Seguridad | Control de acceso antes de recuperar contexto. | Un usuario recibe contenido de otro departamento. |
9. Evaluar seguridad, sesgo y comportamiento no deseado
La evaluación de modelos fundacionales debe incluir pruebas de seguridad y responsabilidad. No se trata solo de impedir contenido ofensivo. También hay que probar si el modelo revela datos sensibles, si responde a instrucciones maliciosas, si discrimina a grupos o si ejecuta acciones sin confirmación.
- Prompt injection: comprobar si el usuario puede manipular instrucciones.
- Jailbreaking: probar intentos de saltarse restricciones.
- Fuga de datos: verificar que no revela información confidencial o no autorizada.
- Sesgo: comparar respuestas entre grupos o escenarios equivalentes.
- Toxicidad: medir lenguaje ofensivo, dañino o no permitido.
- Acciones de agentes: confirmar que operaciones con impacto requieren validación y permisos.
Pregunta tipo examen
Una empresa quiere lanzar un asistente que consulta información interna. La respuesta correcta no será solo “usar un modelo más preciso”. Debe incluir evaluación de calidad, control de acceso, seguridad del retrieval, pruebas de prompt injection y revisión de respuestas sensibles.
10. Evaluar parámetros de inferencia
El comportamiento de un modelo también depende de parámetros como temperatura, longitud máxima de salida, top-p o ventana de contexto. Evaluar un modelo sin fijar estos parámetros puede producir resultados inconsistentes.
| Parámetro | Impacto | Cómo evaluarlo |
|---|---|---|
| Temperatura | Controla variabilidad o creatividad. | Probar baja temperatura para cumplimiento y mayor temperatura para ideación. |
| Longitud máxima de salida | Afecta detalle, coste y latencia. | Medir si respuestas largas aportan valor o solo aumentan coste. |
| Context window | Limita cuánto contexto puede procesar el modelo. | Validar documentos largos y conversaciones extendidas. |
| Prompt y contexto | Influyen en formato, tono y precisión. | Comparar plantillas de prompt con casos representativos. |
11. Métricas operativas: latencia, coste y disponibilidad
Un modelo puede ser excelente en calidad, pero no ser viable si tarda demasiado, cuesta demasiado o no soporta el volumen esperado. En producción, hay que medir la solución como un servicio, no solo como un experimento.
Tiempo que tarda la aplicación en responder. Importa mucho en chatbots, asistentes y aplicaciones interactivas.
Depende del modelo, tokens de entrada, tokens de salida, volumen, retrieval y posibles llamadas a herramientas.
Incluye errores técnicos, timeouts, límites de servicio o respuestas que no cumplen formato.
Capacidad de mantener calidad y rendimiento cuando suben usuarios, documentos o peticiones.
12. Métricas de negocio
El examen insiste en que las soluciones de IA deben resolver problemas de negocio. Por eso, una evaluación completa debe incluir resultados medibles para la organización.
| Caso de uso | Métrica de negocio | Qué demuestra |
|---|---|---|
| Asistente de soporte | Resolución en primer contacto, reducción de tickets, satisfacción del usuario. | Que la aplicación ayuda a resolver problemas reales. |
| Resumen de documentos | Tiempo ahorrado por analista, precisión percibida, reducción de retrabajo. | Que el resumen es útil y no solo breve. |
| Generación de contenido | Tiempo de creación, tasa de aprobación, consistencia de tono. | Que la salida sirve dentro del proceso editorial. |
| Asistente interno | Adopción, búsquedas resueltas, reducción de consultas repetitivas. | Que los empleados encuentran respuestas con menos esfuerzo. |
13. Servicios de AWS relacionados con evaluación
En AWS, la evaluación puede apoyarse en varios servicios según el tipo de solución. Para AIF-C01, es importante reconocer los servicios y su papel, sin entrar en implementación avanzada.
- Amazon Bedrock Model Evaluation: permite comparar y evaluar modelos fundacionales con evaluación automática o humana, según el caso.
- Amazon Bedrock: permite probar distintos modelos, prompts, parámetros y patrones como RAG o agentes.
- Guardrails for Amazon Bedrock: ayuda a aplicar políticas de seguridad y filtrar contenido no deseado.
- Knowledge Bases for Amazon Bedrock: permite evaluar soluciones RAG con recuperación de fuentes documentales.
- Amazon SageMaker AI: puede participar en escenarios donde se necesita construir, entrenar, desplegar o evaluar modelos ML de forma más personalizada.
- Amazon CloudWatch: ayuda a observar métricas operativas como errores, latencia y comportamiento de la aplicación.
14. Proceso recomendado de evaluación
15. Cómo razonar preguntas de examen
Cuando el examen pregunte por evaluación de modelos fundacionales, busca el requisito dominante del escenario:
| Escenario | Respuesta más probable |
|---|---|
| Comparar varios modelos para un caso de uso real. | Usar un conjunto representativo de evaluación y comparar calidad, coste, latencia y seguridad. |
| Respuestas fluidas pero inventadas. | Medir factualidad, alucinaciones y revisar RAG/fuentes. |
| Aplicación sensible para empleados o clientes. | Combinar evaluación humana, seguridad, privacidad, sesgo y revisión de cumplimiento. |
| Buen resultado en demo, mal resultado en producción. | Ampliar dataset de evaluación, monitorizar y revisar drift, prompts, contexto y datos reales. |
| Necesidad de justificar inversión. | Medir métricas de negocio, no solo métricas técnicas. |
Errores frecuentes
- Elegir el modelo con mejor benchmark genérico sin probar el caso real. Puede fallar en idioma, dominio, tono o seguridad.
- Medir solo precisión o similitud textual. En GenAI también importan factualidad, seguridad, coste y experiencia.
- Ignorar evaluación humana. Muchas tareas generativas tienen matices que una métrica automática no captura.
- No evaluar RAG por separado. Si falla la recuperación, cambiar de modelo puede no resolver el problema.
- No medir coste y latencia. Un modelo excelente pero inviable operativamente puede no ser la mejor opción.
- No probar ataques o entradas maliciosas. Prompt injection, jailbreaks y fugas deben evaluarse antes de producción.
Resumen final
Evaluar modelos fundacionales implica medir calidad, seguridad, rendimiento, coste y valor de negocio. ROUGE, BLEU y BERTScore pueden ayudar, pero no sustituyen la evaluación humana, los casos reales, las pruebas de seguridad ni las métricas operativas. En aplicaciones GenAI, muchas veces se evalúa la solución completa: modelo, prompt, RAG, guardrails, permisos y experiencia de usuario.
Para AIF-C01, recuerda esta idea: la mejor evaluación es la que está alineada con el caso de uso. Un asistente documental debe medirse por factualidad, recuperación y fuentes. Un asistente interno debe medirse por utilidad, seguridad y adopción. Un generador de contenido debe medirse por calidad, tono y eficiencia. Y cualquier solución de IA debe demostrar que aporta valor sin romper seguridad, cumplimiento ni coste.