Elegir un modelo fundacional

El dominio anterior ya te enseñó cómo elegir un modelo: elimina por restricciones duras, evalúa a los sobrevivientes sobre tu propia tarea y luego optimiza los que pasan por costo y latencia. Ese método es el orden de las operaciones. Esta lección es la lista de verificación sobre la que opera.

La guía del examen, en la tarea 3.1, nombra un conjunto específico de criterios para elegir un modelo fundacional preentrenado: costo, modalidad, latencia, soporte multilingüe, tamaño del modelo, complejidad del modelo, personalización y largo de entrada y salida. Cada uno es un tipo distinto de pregunta, y cada uno carga una consecuencia de diseño que sientes más tarde si te lo saltas. Una pregunta de este tema suele esconder uno de estos criterios en la redacción del escenario y hacer que la opción tentadora sea el modelo que ganaría si esa frase no estuviera ahí. Así que la habilidad útil es reconocer qué criterio está evaluando de verdad un escenario.

Los vamos a recorrer en el orden en que tienden a morder, no en el orden en que los lista la guía.

Modalidad: qué entra, qué sale

La modalidad es el tipo de dato que un modelo acepta y produce. Un modelo de texto lee y escribe texto. Un modelo multimodal puede aceptar imágenes, audio o video junto con texto. Un modelo de embeddings devuelve vectores en lugar de prosa. Un modelo de generación de imágenes produce imágenes a partir de una descripción.

Estos no son intercambiables, y ningún otro criterio puede rescatar un desajuste de modalidad. Un modelo de solo texto no puede leer una factura escaneada, transcribir una llamada ni describir una foto, y el ajuste fino no agrega un tipo de entrada. Por eso la modalidad es lo primero que revisas: elimina candidatos de entrada, antes de que la calidad siquiera entre en juego.

También es el criterio que el examen disfraza más seguido. Un escenario menciona documentos escaneados, fotos de productos o grabaciones de audio, y luego ofrece un modelo de solo texto como la opción con los mejores puntajes de benchmark. Los puntajes son una distracción. Lee el escenario para ver qué es la entrada realmente antes de leer las capacidades del modelo.

Largo de entrada y salida: dos límites, no uno

Todo modelo publica dos límites de largo, y confundirlos es una forma confiable de lanzar una funcionalidad rota.

La ventana de contexto es el número máximo de tokens que el modelo puede recibir en una sola petición. Todo cuenta contra ella: tus instrucciones, cualquier documento recuperado, la conversación hasta ese punto y la pregunta del usuario. El largo máximo de salida es un tope separado sobre cuántos tokens puede generar el modelo en una sola respuesta, y suele ser mucho más chico que la ventana de contexto.

La brecha entre ambos es más grande de lo que la mayoría espera. Un modelo puede publicar una ventana de contexto de 200,000 tokens con un máximo de salida de apenas unos miles. Esa combinación lee un documento muy largo con comodidad, pero no puede escribir uno muy largo. Un equipo que lee "200,000 tokens" y planea generar un informe completo en una llamada recibe una respuesta que se detiene a la mitad, y nada en el error explica por qué.

Así que la pregunta de diseño se parte en dos. Cuánto necesita recibir una sola petición, lo que fija el piso de la ventana de contexto, y cuán larga necesita ser la respuesta, lo que fija el piso del largo de salida. Una funcionalidad de resumen es pesada en entrada y ligera en salida. Una funcionalidad de redacción de textos largos es lo contrario. Empareja el modelo con la dirección hacia la que se inclina tu carga.

Soporte multilingüe

Un modelo entrenado sobre todo en inglés igual produce español o árabe cuando se lo pides, pero a menudo con gramática más débil, vocabulario más pobre y más errores de los que comete en inglés. La capacidad general no se transfiere de forma pareja entre idiomas, y por eso la guía lista el soporte multilingüe como criterio propio en lugar de meterlo dentro de la exactitud.

La consecuencia es práctica. Si tus usuarios escriben en portugués y leen respuestas en portugués, un modelo que lidera los benchmarks en inglés pero tropieza en portugués es la elección equivocada, y solo ves el problema probándolo en el idioma que tus usuarios usan de verdad. Cuando un escenario nombra una audiencia que no habla inglés o un requisito de varios idiomas, este criterio pasa al frente.

Tamaño del modelo y complejidad del modelo

La guía lista el tamaño del modelo y la complejidad del modelo como dos criterios, y apuntan a la misma concesión desde dos ángulos. El tamaño se refiere al número de parámetros. La complejidad se refiere a cuánta capacidad compra eso y cuánto cuesta correrlo.

El instinto que casi todos traen es que un modelo más grande es una elección más segura. No lo es, y el examen premia saber por qué. Un modelo más grande cuesta más por token, genera más lento porque hace más trabajo por token, y a menudo no muestra ninguna mejora medible en una tarea estrecha y bien especificada. Un clasificador que ordena tickets de soporte en ocho categorías no necesita razonamiento de frontera. Pagar por capacidad que la tarea nunca ejercita es desperdicio que se repite en cada una de las peticiones, para siempre.

El patrón que aguanta en la práctica es empezar con un modelo más chico y subir solo cuando tu evaluación muestra una brecha real. Los equipos que empiezan arriba rara vez bajan, porque nadie se ofrece a empeorar un poco el asistente para ahorrar dinero, así que el sobrepago se vuelve permanente. Cuando un escenario te da un presupuesto de latencia ajustado o una tarea simple y acotada y ofrece un modelo grande como opción, el modelo más chico que igual pasa suele ser la respuesta buscada.

Soporte de personalización

Si tu plan depende de adaptar el modelo, sea ajustándolo finamente con tus ejemplos o anclándolo en tus datos, tienes que confirmar que el modelo admite ese camino antes de comprometerte con él. No todo modelo se puede ajustar finamente, y los que sí difieren en qué métodos aceptan y qué formato de datos esperan.

Este es un criterio de selección justamente porque descubrir el límite tarde sale caro. Un equipo que elige un modelo solo por calidad, construye alrededor de él y luego se entera de que no se puede ajustar finamente como su caso de uso necesita, tiene que empezar la selección de nuevo. Las concesiones de personalización en sí son una lección posterior de este tema. Aquí el punto es más acotado: si la personalización es parte del plan, es parte de la selección.

Latencia y costo

Estos son los dos criterios que optimizas una vez que un modelo pasó todo lo anterior, y las lecciones previas los cubrieron a fondo, así que lo mantenemos corto.

La latencia es qué tan rápido responde el modelo. Los modelos más grandes son más lentos, y la generación es secuencial, así que una respuesta larga de un modelo grande puede tardar varios segundos. Una experiencia de chat en vivo tiene un presupuesto de latencia; un trabajo por lotes nocturno normalmente no. Verifica que un modelo cumpla el presupuesto antes de construir una funcionalidad en tiempo real sobre él, en vez de esperar cerrar la brecha después.

El costo lo maneja sobre todo la elección de modelo, más que cualquier optimización de prompt. La misma carga de trabajo puede diferir por órdenes de magnitud entre dos modelos de la misma familia. Entre los modelos que pasan todas las demás compuertas, el más barato y rápido que igual cumple tu umbral de calidad es la elección correcta.

Los criterios de un vistazo

Consejos para el examen

• Memoriza la lista nombrada: costo, modalidad, latencia, multilingüe, tamaño del modelo, complejidad del modelo, personalización, largo de entrada y salida. Después, para cualquier escenario, encuentra cuál está decidiendo.
• La modalidad es el filtro escondido más común. Entrada que no es texto en el escenario más un modelo de solo texto en las opciones significa que esa opción está mal, sin importar sus puntajes.
• El largo de entrada y el de salida son límites separados. Una ventana de contexto grande no promete una respuesta larga. Cuida el escenario que necesita generación larga y un modelo con tope de salida chico.
• El soporte multilingüe aparece cuando la audiencia se nombra como no angloparlante. Los puntajes generales de benchmark no lo resuelven.
• La complejidad del modelo es una concesión, no una meta. Latencia ajustada o una tarea estrecha apuntan al modelo más chico que igual pasa.
• El soporte de personalización se revisa antes de la selección, no después. Si el plan dice ajustar finamente, confirma que el modelo se pueda ajustar finamente.

La regla para llevar a una pregunta: lee primero la restricción, luego emparéjala con uno de los ocho criterios. La mayoría de los escenarios de elección de modelo giran sobre una sola frase. La próxima lección pasa de elegir el modelo a controlar cómo responde, con los parámetros de inferencia que fijas en cada petición.