Con decenas de foundation models disponibles en Bedrock, elegir el correcto para tu caso de uso requiere comparar criterios objetivos — no solo escoger "el más grande" o "el más nuevo".
Contenido
No existe "el mejor modelo" en abstracto — existe el modelo más adecuado para tu tarea, tu presupuesto y tus restricciones.
Costo
El precio varía por millón de tokens de entrada/salida, y también según si el modelo es grande o pequeño. Un modelo más caro no siempre aporta valor si tu tarea es simple.
Latencia
Cuánto tarda el modelo en responder. Crítico en aplicaciones en tiempo real (chat, asistentes de voz) donde el usuario espera una respuesta casi inmediata.
Tamaño del context window
Cuánta información (texto, historial de conversación, documentos recuperados con RAG) puede procesar el modelo de una sola vez. Tareas que analizan documentos largos necesitan una ventana de contexto amplia.
Capacidad multimodal
Si el caso de uso requiere procesar no solo texto sino también imágenes, audio o vídeo, necesitas un modelo multimodal específicamente entrenado para eso.
Precisión para la tarea específica
Un modelo puede destacar en generación creativa pero ser mediocre en razonamiento matemático, o viceversa. La precisión debe medirse en la tarea real, no en benchmarks genéricos.
Requisitos de cumplimiento y residencia de datos
Algunos modelos o regiones tienen restricciones de disponibilidad o certificaciones distintas, relevantes en industrias reguladas.
Evaluar un modelo generativo es más difícil que evaluar un modelo de clasificación tradicional: no siempre hay una única "respuesta correcta".
BLEU / ROUGE
Métricas automáticas que comparan el texto generado por el modelo contra un texto de referencia "correcto", midiendo el solapamiento de palabras o frases. Útiles para tareas como traducción (BLEU) o resumen (ROUGE), pero limitadas: no capturan bien la calidad semántica o la creatividad.
BERTScore
Métrica automática que, a diferencia de BLEU/ROUGE, no compara palabras exactas sino que usa embeddings para medir la similitud SEMÁNTICA entre el texto generado y el de referencia. Detecta como "correctas" respuestas que dicen lo mismo con palabras distintas, algo que BLEU/ROUGE penalizarían.
LLM-as-a-judge
Usa otro foundation model como "juez" para evaluar y puntuar las respuestas del modelo que se está evaluando, según criterios como relevancia, corrección o tono. Escala mejor que la evaluación humana y captura más matiz que las métricas automáticas tipo BLEU/ROUGE, aunque hereda los posibles sesgos del modelo evaluador.
Evaluación humana
Personas revisan y puntúan las respuestas del modelo según criterios como relevancia, coherencia, utilidad o tono. Más costosa y lenta, pero captura matices que las métricas automáticas no pueden medir.
Benchmarks estandarizados
Conjuntos de pruebas públicas (de razonamiento, conocimiento general, código, etc.) que permiten comparar el desempeño relativo entre distintos modelos de forma consistente.
Idea clave para el examen
El AIF-C01 espera que entiendas estas métricas a nivel conceptual: qué miden y para qué tipo de tarea son relevantes (BLEU/ROUGE para texto con referencia, evaluación humana para calidad subjetiva). No es necesario memorizar fórmulas matemáticas.
Qué permite hacer
Bedrock incluye una funcionalidad de evaluación de modelos que permite comparar el desempeño de distintos foundation models usando tus propios datos y prompts de prueba, antes de decidir cuál llevar a producción.
Por qué importa
En lugar de elegir un modelo basándose solo en benchmarks públicos genéricos, puedes validar cuál rinde mejor específicamente para tu caso de uso real, con tus propios datos — antes de comprometerte a usarlo en producción.
Compara la calidad de respuesta de dos foundation models con Bedrock Model Evaluation.
+1 más...
Evaluar solo el foundation model de forma aislada no es suficiente. En producción, el modelo es una pieza dentro de una aplicación más grande (una solución de RAG, un agente, un workflow de varios pasos), y hay que evaluar si la aplicación completa cumple el objetivo de negocio.
Aplicaciones de RAG
No basta con evaluar si el modelo genera texto fluido: hay que medir si la recuperación encontró los fragmentos correctos y si la respuesta final está realmente fundamentada en esos fragmentos (relevancia de la recuperación + fidelidad de la respuesta al contexto).
Agentes
Hay que evaluar si el agente eligió las herramientas correctas, las llamó con los parámetros correctos, y si la secuencia de pasos llevó a completar la tarea solicitada — no solo si el texto final "suena bien".
Workflows de varios pasos
Cuando varios componentes (modelos, herramientas, reglas de negocio) se encadenan, hay que evaluar el resultado de extremo a extremo, porque un fallo en un paso intermedio puede no ser visible si solo se mira la salida final.
Más allá de las métricas técnicas del modelo, el examen espera que sepas conectar la evaluación con el impacto real en el negocio.
Task completion rate
Porcentaje de solicitudes o tareas que la aplicación completa efectivamente resuelve de principio a fin, sin intervención adicional.
User satisfaction
Qué tan satisfechos quedan los usuarios reales con las respuestas o resultados — medido con encuestas, calificaciones o tasas de escalado a un humano.
Cost per interaction
Costo promedio (tokens, cómputo, llamadas a herramientas) de cada interacción completa con la aplicación, clave para decidir si la solución es sostenible a escala.
Idea clave para el examen
Un modelo con excelentes métricas técnicas (BLEU alto, buena puntuación de LLM-as-a-judge) puede seguir siendo una mala solución de negocio si el costo por interacción es demasiado alto o si los usuarios reales no quedan satisfechos — la evaluación técnica y la evaluación de negocio son complementarias, no sustitutas.
Modelos grandes
Ideales para tareas complejas donde la calidad de respuesta importa más que la velocidad o el costo.
Modelos pequeños
Ideales para tareas simples y de alto volumen, como clasificación rápida o extracción sencilla, donde velocidad y costo son prioritarios.
Regla de decisión para el examen
Si el escenario enfatiza costo y velocidad a gran escala con tareas relativamente simples, favorece un modelo más pequeño. Si enfatiza calidad y razonamiento en tareas complejas, favorece un modelo más grande — incluso a mayor costo y latencia.
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
Una empresa necesita clasificar automáticamente millones de mensajes de soporte al día en categorías simples (facturación, técnico, general) con el menor costo y latencia posible. ¿Qué tipo de modelo es más adecuado?
Inicia sesión para llevar tu progreso.