1. Modelo mental
Elegir modelo es un problema de optimización con restricciones. El mejor modelo global puede ser una mala elección para tu tarea si es demasiado lento, caro, limitado por región o incapaz de cumplir el formato que necesitas.
Separaproducto,modeloyproveedor. Una aplicación puede cambiar el modelo subyacente; una API puede ofrecer varias versiones; y el mismo modelo puede tener límites distintos según canal.
La decisión final debe salir de tus casos. Usa datos oficiales para filtrar lo imposible y un eval propio para distinguir entre las opciones que quedan.
2. Conceptos que debes dominar
Patrón de uso real: tokens, frecuencia, latencia, modalidad, herramientas y riesgo.
Máximo teórico de contexto; no garantiza que usarlo entero sea óptimo.
Límite de salida que puede romper generación larga aunque el contexto sea grande.
No sólo $/MTok: incluye cache, reintentos, herramientas y revisión.
Tiempo hasta primera respuesta y tiempo total; importa especialmente en interfaces interactivas.
Visión, audio, herramientas, JSON, razonamiento, embeddings o generación multimedia.
Versionado, deprecaciones, cuotas, región y comportamiento del proveedor.
Resultado en tus tareas y con tu prompt; tiene más peso que un benchmark genérico.
3. Workflow paso a paso
Describe workload
Mide entradas, salidas, volumen y SLA.
Tienes percentiles, no sólo un ejemplo.
Filtra requisitos duros
Modalidad, región, API, privacidad, output, herramientas.
Eliminaste opciones imposibles antes de puntuar.
Calcula coste
Incluye tokens de entrada/salida, cache y revisiones.
Puedes proyectar coste mensual.
Prueba calidad
Ejecuta el mismo golden set.
La comparación usa casos idénticos.
Mide latencia
Captura p50 y p95.
No comparas una sola llamada.
Evalúa operación
Cuotas, errores, observabilidad y soporte.
Sabes cómo se comporta bajo carga.
Diseña routing
Considera modelo barato por defecto y escalado premium.
No pagas el modelo más caro para todo.
Revisa periódicamente
Los modelos cambian rápido.
La decisión tiene fecha de caducidad.
4. Ejemplo completo
Workload:100.000 tickets/mes, 700 tokens de entrada, 120 de salida, SLA 3 s, salida JSON obligatoria.
Primero filtra modelos sin structured output o con disponibilidad incompatible. Después calcula coste sobre volumen real. Finalmente ejecuta 200 tickets históricos etiquetados y mide accuracy, coste y p95. Si dos modelos empatan en calidad, el modelo más barato o estable puede ganar aunque no lidere benchmarks.
Los benchmarks sirven para descubrir candidatos. Tus evals sirven para elegir.
5. Matriz de decisión
| Decisión | Qué mirar | Señal buena | Señal de riesgo |
|---|---|---|---|
| Calidad máxima | El error cuesta mucho | Eval propio superior | Ranking externo sin casos propios |
| Coste | Volumen alto | Coste por tarea estable | Sólo miras precio por token |
| Latencia | Interfaz en tiempo real | p95 dentro de SLA | Promedio oculta colas |
| Contexto | Documentos largos | Cabe + calidad estable | Contexto grande usado como sustituto de RAG |
| Privacidad | Datos sensibles | Contrato/configuración compatibles | Decisión basada en marketing |
6. Fallos y límites
Una guía útil también debe decir cuándo detenerse. Estos son los fallos que más cambian la calidad del resultado:
- Elegir por una tabla de benchmarks sin tus datos.
- Confundir contexto máximo con contexto recomendado.
- Olvidar output máximo o structured output.
- No medir reintentos y rate limits.
- Comparar precios con unidades distintas.
- Ignorar disponibilidad regional o de API.
- Usar un único modelo para tareas heterogéneas.
- No reevaluar tras deprecaciones o cambios de pricing.
7. Cómo medirlo
No midas sólo si “parece bueno”. Define una señal observable antes de escalar.
| Métrica | Qué mide | Cómo observarla | Umbral/alerta |
|---|---|---|---|
| Task score | Calidad en tu tarea | Golden set | Bajo el gate |
| Coste/tarea | Coste efectivo | Tokens+herramientas | Supera presupuesto |
| p95 latency | Experiencia real | Trazas | Supera SLA |
| Error rate | Fiabilidad | Errores/reintentos | Picos tras release |
| Escalation rate | Necesidad premium/humano | Routing logs | Sube inesperadamente |
| Freshness | Vigencia decisión | Fecha revisión | Decisión caducada |
8. Checklist de producción
9. Ejercicios para convertir lectura en habilidad
- Calcula el coste mensual de tres modelos con tu volumen.
- Crea una matriz con cinco requisitos duros y cinco ponderados.
- Ejecuta 20 casos idénticos y puntúa sin saber qué modelo los produjo.
- Diseña un router simple barato/medio/premium.
- Escribe qué cambio futuro obligaría a reevaluar la decisión.
10. Qué estudiar después
No intentes memorizar toda la IA. Encadena la siguiente pieza cuando resuelva una duda que ya has encontrado en la práctica.
Apéndice A · Preguntas que deberías poder responder
- ¿Qué parte del problema es determinista y cuál necesita juicio probabilístico?
- ¿Qué dato o ejemplo cambiaría tu decisión actual?
- ¿Cómo distinguirás una mejora real de una respuesta simplemente más convincente?
- ¿Qué ocurre cuando faltan datos, la herramienta falla o la respuesta es incierta?
- ¿Qué parte del proceso debe seguir bajo responsabilidad humana?
- ¿Qué coste operativo aparece después del primer prototipo?
- ¿Qué revisarías dentro de 30, 90 y 180 días para evitar que el sistema envejezca?
Si no puedes responder todavía a varias de estas preguntas, no significa que el proyecto esté mal: significa que has encontrado exactamente los huecos que la siguiente iteración debe cerrar. Ese es uno de los usos más valiosos de una guía técnica: convertir incertidumbre difusa en decisiones explícitas.
Apéndice B · Cuatro escenarios para practicar la decisión
Pregunta:El error cuesta mucho.Señal favorable:Eval propio superior.Alerta:Ranking externo sin casos propios.
Pregunta:Volumen alto.Señal favorable:Coste por tarea estable.Alerta:Sólo miras precio por token.
Pregunta:Interfaz en tiempo real.Señal favorable:p95 dentro de SLA.Alerta:Promedio oculta colas.
Pregunta:Documentos largos.Señal favorable:Cabe + calidad estable.Alerta:Contexto grande usado como sustituto de RAG.
No memorices la tabla como si fuera una regla universal. Cambia volumen, riesgo, disponibilidad, privacidad o coste y vuelve a recorrer la decisión. Un sistema robusto documenta qué variables sostienen la elección y cuáles podrían invalidarla.
Apéndice C · Cuaderno de campo para tu propio caso
Copia estas preguntas en un documento y complétalas con un caso real. El objetivo es que el conocimiento deje de estar en la página y pase a tu proceso.
- Problema¿Qué trabajo concreto intentas mejorar y para quién?
- Baseline¿Cómo se hace hoy, cuánto tarda y qué errores aparecen?
- Datos¿Qué entra, de dónde viene, quién puede verlo y qué no debería salir del entorno?
- Salida¿Qué formato y criterios convierten el resultado en usable?
- Prueba¿Qué 20–50 casos representarían el trabajo real?
- Riesgo¿Cuál es el fallo más costoso y cómo se detecta?
- Operación¿Quién observa, corrige, actualiza y puede detener el sistema?
- Revisión¿Qué evento o fecha obligará a reevaluar esta decisión?
Guarda también dos ejemplos que funcionaron y dos que fallaron. Con el tiempo, esos ejemplos se convierten en un pequeño dataset de evaluación mucho más útil que cualquier memoria informal de “esto parecía ir bien”.
Apéndice D · De prototipo a producción
Una demo responde a la pregunta “¿puede funcionar?”. Producción responde a otras: “¿funciona de forma repetible?”, “¿qué pasa cuando falla?”, “¿quién lo mantiene?”, “¿cómo sabemos que sigue siendo bueno dentro de tres meses?” y “¿podemos revertirlo?”. El salto entre ambas fases suele ser mayor que el salto entre dos modelos.
Antes de escalar, separa cuatro planos.Calidad:casos y métricas.Operación:latencia, cuotas, errores y costes.Gobernanza:permisos, datos, revisión y responsables.Cambio:versiones, fuentes y fechas de reevaluación. Si uno de estos planos no tiene dueño, el riesgo aparecerá precisamente cuando el uso crezca.
- Define un SLO de calidad y uno operativo.
- Registra versión de modelo, prompt, fuentes y configuración.
- Mantén una muestra estable para detectar regresiones.
- Añade un fallback para proveedor, herramienta o dato ausente.
- Decide qué errores se reintentan y cuáles se escalan.
- Presupuesta revisión humana, no sólo tokens.
- Evita permisos permanentes que sólo necesitabas para una prueba.
- Programa una revisión tras cambios de modelo, precio, política o dataset.
Finalmente, observa el sistema con tráfico real. Una mejora offline puede empeorar experiencia, coste o tasa de escalado. Las métricas de esta guía son el comienzo; adáptalas al impacto de tu caso y conserva siempre ejemplos concretos detrás de cada porcentaje.
Elegir modelo como una decisión de ingeniería
No existe un “mejor modelo” sin especificar tarea, restricciones y fecha. Empieza por requisitos que descartan opciones: modalidades, región, contexto, salida estructurada, herramientas, latencia, licencia o política de datos. Sólo después compara calidad. Esta secuencia evita gastar tiempo evaluando modelos que no pueden cumplir un requisito operativo básico.
Evalúa con tus entradas. Los leaderboards ayudan a descubrir candidatos, pero un promedio público no sustituye un conjunto de casos de negocio. Un modelo sobresaliente en razonamiento puede ser innecesario para clasificación simple; uno pequeño puede ganar cuando el volumen es alto y la tarea está bien delimitada.
Compara coste total. Precio por token es una parte: añade tokens de razonamiento cuando corresponda, reintentos, prompts largos, caché, herramientas, latencia, revisión humana y coste de fallo. También mide throughput y límites. Un modelo barato que necesita tres intentos puede ser más caro que otro con mayor coste unitario y mejor first-pass success.
Diseña una política de routing si los workloads son heterogéneos. No todas las solicitudes necesitan el mismo nivel de inteligencia. Clasificar tareas y escalar sólo las difíciles permite controlar coste y latencia. El routing, sin embargo, añade complejidad: necesita observabilidad, fallback y evals por ruta.
Finalmente registra la decisión con fecha y evidencia. Los catálogos de OpenAI, Google y otros proveedores cambian; estados preview/estable, precios y capacidades evolucionan. Una buena decisión de modelo incluye la condición que obligará a revisarla.
Una escala de madurez para elegir modelo como una decisión de ingeniería
Resuelve un caso real de principio a fin. Conserva entrada, salida y correcciones. Aquí buscas descubrir fallos, no automatizar.
La entrada y la salida ya tienen contrato, existen ejemplos límite y puedes medir calidad, tiempo y coste con el mismo criterio.
Hay observabilidad, permisos, fallback, responsable, revisión de cambios y un mecanismo para detectar regresiones antes de afectar al usuario.
La transición entre niveles debe estar motivada por evidencia. No pases a integración o autonomía sólo porque una demo salió bien. Pasa cuando hayas repetido la tarea con casos representativos, sepas dónde falla y el ahorro neto siga siendo positivo después de incluir revisión y operación.
Para los primeros 30 días, reúne ejemplos y construye el baseline. Entre 30 y 60 días, estabiliza el contrato de entrada/salida y convierte los fallos recurrentes en tests, checklist o reglas. Entre 60 y 90 días, si el volumen lo justifica, añade automatización, monitorización y revisión de costes. Si una etapa no supera sus propios criterios, mantén el sistema en la etapa anterior.
Documenta también las condiciones de salida: qué cambio de proveedor, política, precio, modelo, volumen o riesgo obligaría a reevaluar el diseño. Una arquitectura madura no pretende ser definitiva; hace explícito cuándo deja de ser válida.
Antes de considerar el trabajo terminado, realiza una revisión adversarial: busca deliberadamente entradas ambiguas, datos faltantes, instrucciones contradictorias, límites de cuota y resultados que parezcan correctos pero no puedan verificarse. El objetivo no es demostrar que el sistema funciona, sino descubrir bajo qué condiciones deja de funcionar y comprobar que esos fallos tienen una respuesta segura. Registra cada hallazgo y conviértelo en una prueba futura.
- Guarda al menos 20 casos reales, incluidos fallos.
- Define un criterio de aprobación que otra persona pueda aplicar.
- Separa métricas de calidad, coste y operación.
- Establece quién puede detener o revertir el sistema.
- Programa una fecha de revisión aunque nada parezca haber cambiado.
Documentación que sostiene y actualiza esta guía
Las capacidades y políticas cambian. Usa estas referencias para comprobar los puntos que dependan de un proveedor o de una versión concreta.