Evaluación de modelos de IA antes de cambiar de proveedor de API: una lista de verificación del flujo de trabajo

Cambiar de proveedor de API de IA no es una decisión de clasificación de modelos. Es un cambio de producción que puede alterar al mismo tiempo la calidad de la salida, la validez del JSON, las llamadas a herramientas, la latencia, el comportamiento frente a límites de tasa, el manejo de errores y el costo total.

El enfoque más seguro es convertir el cambio propuesto en una prueba de aceptación repetible. Ejecute el proveedor actual y el candidato sobre los mismos casos con apariencia de producción, puntúe los resultados completos del flujo de trabajo, defina compuertas de migración estrictas antes de ver los resultados y exponga al candidato gradualmente detrás de una ruta lista para revertir.

Esta guía le ofrece ese proceso, incluyendo una tarjeta de puntuación, diseño del conjunto de datos, matriz de compatibilidad, método de prueba por pares, fórmula de costo, etapas de despliegue y memorando de decisión.

The short answer: use a provider-switch acceptance test

Antes de mover tráfico de producción, exija que la ruta candidata supere cinco comprobaciones:

1. Calidad del flujo de trabajo: Completa la tarea del usuario a una tasa aceptable en entradas representativas.
2. Compatibilidad de contrato: Las salidas estructuradas, las llamadas a herramientas, la transmisión, los errores y los estados de finalización funcionan con su aplicación.
3. Confiabilidad operativa: La latencia, los tiempos de espera, los límites de tasa, los reintentos y la concurrencia se mantienen dentro de sus objetivos de servicio.
4. Valor económico: El costo efectivo por tarea aceptada mejora o se mantiene dentro de una compensación aprobada.
5. Despliegue seguro: El tráfico sombra y un canario por etapas muestran que los resultados fuera de línea sobreviven a las condiciones de producción.

No apruebe un cambio porque el candidato gane un benchmark público, produzca unas cuantas respuestas impresionantes o tenga un precio de token anunciado más bajo. Esas señales pueden ayudar a crear una lista corta. No demuestran que el proveedor pueda ejecutar su flujo de trabajo.

Empiece con la decisión de migración, no con la lista de modelos

Escriba una decisión en una sola frase antes de construir la evaluación:

Reemplace la ruta A por la ruta B para el flujo de trabajo X si B no es inferior en éxito de la tarea, supera todas las compuertas de contrato, cumple con el presupuesto de latencia y confiabilidad de producción, y reduce el costo efectivo por tarea aceptada en la cantidad requerida.

Esa frase obliga al equipo a definir el alcance. Un proveedor puede ser adecuado para extracción pero no para el uso de herramientas por agentes, o para enriquecimiento por lotes pero no para un asistente interactivo. Evite una conclusión universal de "mejor modelo" cuando la decisión real se refiere a una sola ruta, una sola carga de trabajo y un solo entorno operativo.

Registre estas entradas en el plan de evaluación:

Si el propio cambio de integración todavía es incierto, revisa la lista de verificación de migración de una pasarela de API compatible con OpenAI antes de probar modelos. Una interfaz compartida reduce los cambios de código, pero no hace que el comportamiento del modelo sea idéntico.

Defina la unidad de evaluación como un trace completo

La unidad de evaluación debe coincidir con lo que experimenta tu cliente. Para un clasificador de un solo turno, eso puede ser una solicitud y una respuesta. Para un agente, puede ser un trace completo que contenga varias llamadas al modelo, invocaciones a herramientas, reintentos y una respuesta final.

Un registro de trace útil incluye:

{
  "case_id": "support-refund-042",
  "segment": "refund-policy",
  "input": {},
  "expected_contract": {},
  "route": "candidate-b",
  "attempts": 1,
  "latency_ms": 1840,
  "input_tokens": 3120,
  "output_tokens": 486,
  "provider_cost_usd": 0.0124,
  "schema_valid": true,
  "tool_sequence_valid": true,
  "task_success": true,
  "failure_class": null
}

Esto evita un error de medición habitual: puntuar solo la prosa final e ignorar argumentos mal formados, herramientas repetidas, reintentos ocultos o un pico de latencia que hizo que el flujo de trabajo fuera inutilizable.

Construya un conjunto de pruebas con forma de producción

El conjunto de evaluación debe representar la distribución y los modos de fallo de la ruta que planea migrar. Seleccionar al azar un pequeño montón de prompts "típicos" suele ocultar los casos que causan incidentes.

Utilice seis grupos de casos:

1. Casos frecuentes: Las entradas responsables de la mayor parte del tráfico normal.
2. Casos de alto valor: Tareas en las que una respuesta incorrecta provoca una corrección humana costosa o una pérdida de conversión.
3. Casos de cola larga: Idiomas, formatos, dominios o intenciones de usuario poco frecuentes.
4. Casos de contrato: Entradas que ponen a prueba esquemas, enumeraciones, objetos anidados, herramientas y ensamblado de streaming.
5. Casos adversarios: Instrucciones ambiguas, evidencia contradictoria, inyección de prompts y solicitudes no compatibles.
6. Casos operativos: Contextos grandes, salidas largas, ráfagas concurrentes, timeouts y errores del lado del proveedor.

Estratifique el conjunto de datos para que cada segmento importante tenga suficientes ejemplos para inspeccionarlo por separado. Un candidato puede parecer aceptable en el agregado y, aun así, fallar en un idioma, una herramienta o un nivel de cliente.

Mantenga tres capas de datos:

• Conjunto de desarrollo: Casos visibles utilizados para mejorar prompts y validadores.
• Conjunto de decisión: Casos reservados utilizados para aprobar o rechazar la migración.
• Conjunto de auditoría de producción: Casos nuevos muestreados después del despliegue para detectar desviaciones.

No ajuste repetidamente el sistema contra el conjunto de decisión. Una vez que el equipo ha visto sus fallos y ha cambiado el sistema, esos casos se han convertido, de hecho, en datos de desarrollo.

Congele las condiciones de prueba

Las comparaciones por pares solo son útiles cuando el sistema actual y el candidato reciben un trabajo equivalente. Congele o registre:

• Instrucciones del sistema y del desarrollador.
• Entrada del usuario y archivos adjuntos.
• Definiciones de herramientas y esquemas JSON.
• Temperatura, salida máxima, seed cuando esté disponible y configuraciones de razonamiento.
• Resultados de recuperación y orden de los documentos.
• Región, versión de API, identificador del modelo y ruta del proveedor.
• Política de reintentos, tiempo de espera y concurrencia.
• Marca de tiempo de la evaluación y fuente de precios.

Si una ruta usa un prompt diferente porque el proveedor lo requiere, versionen ambos prompts y traten esa diferencia como parte del paquete de migración. La decisión de negocio trata sobre el nuevo sistema, no sobre un modelo abstracto aislado de su integración.

Ejecútese cada caso por ambas rutas. Aleatorice o ciegue la presentación cuando las personas califiquen resultados subjetivos, para que los revisores no estén influidos por los nombres de los proveedores.

Establezca límites estrictos antes de las puntuaciones ponderadas

Una puntuación ponderada es útil para los compromisos, pero no debería permitir que un modelo barato compense un fallo contractual crítico.

Defina primero límites no negociables. Los límites de ejemplo podrían incluir:

• Ninguna ejecución de herramientas no autorizada.
• Ningún secreto ni dato restringido en las salidas.
• El JSON requerido se analiza y valida contra el esquema de producción.
• Los idiomas requeridos se mantienen por encima de su umbral mínimo de éxito de la tarea.
• Las tasas de tiempo de espera y errores del servidor permanecen dentro del presupuesto aprobado.
• El cliente gestiona correctamente la terminación del streaming y los errores del proveedor.
• Se prueba una ruta de reversión antes de la exposición en producción.

Los umbrales deben derivarse del riesgo de su producto y de la línea base actual. Los números siguientes son una tarjeta de puntuación ilustrativa, no recomendaciones universales:

Publique los pesos y las barreras antes de la ejecución final. Cambiarlos después de que lleguen los resultados convierte la evaluación en una justificación.

Compruebe objetivos de puntuación antes de usar jueces de modelo

Use validadores deterministas siempre que sea posible:

• Análisis de JSON y validación de JSON Schema.
• Coincidencia exacta o normalizada de campos.
• Comprobaciones de tolerancia numérica.
• Validación de citas y URL.
• Validación de herramientas permitidas y de argumentos.
• Comprobaciones de secuencia de herramientas y de máximo de pasos.
• Compilación de código, pruebas unitarias y ejecución en sandbox.
• Reglas de política y detectores de contenido prohibido.
• Cobertura de evidencia de recuperación.

Utilice revisión humana o un evaluador basado en modelo para criterios que no puedan reducirse a una comprobación determinista, como la claridad, el tono, la síntesis o si una respuesta sigue instrucciones matizadas.

Al usar un evaluador de modelo:

1. Déle una rúbrica estrecha con condiciones de aprobación observables.
2. Calíbralo frente a una muestra puntuadas por humanos.
3. Oculte la identidad del proveedor cuando sea posible.
4. Conserve los prompts del evaluador, la versión del modelo y la justificación en bruto.
5. Envíe las discrepancias y los casos límite a revisión humana.

La guía de evaluación de OpenAI recomienda evaluaciones específicas para cada tarea y evaluación continua, mientras que Anthropic también recomienda definir criterios de éxito observables y construir evaluaciones en torno a ellos. La implicación práctica es sencilla: su rúbrica debe describir el resultado del flujo de trabajo que necesita, no una inteligencia genérica.

Compare resultados emparejados e incertidumbre

Una puntuación media por sí sola puede ocultar inestabilidad. Como ambas rutas procesan los mismos casos, compárelas caso por caso.

Para el éxito binario de la tarea, cree una tabla emparejada:

Los dos grupos de desacuerdo son especialmente útiles. Revíselos manualmente y clasifique la causa raíz antes de aprobar el cambio.

Para obtener un resultado apto para la toma de decisiones, informe un intervalo de confianza alrededor de la diferencia en éxito de la tarea, costo y latencia. Un bootstrap sobre los IDs de caso es un método práctico porque puede preservar la estructura emparejada sin asumir que cada métrica siga una distribución normal.

Utilice una regla de no inferioridad cuando el candidato ofrezca un beneficio claro, como un menor costo o una mejor disponibilidad regional, y el producto pueda tolerar una pequeña diferencia de calidad acotada. Defina el margen permitido antes de la prueba. Apruebe solo cuando el intervalo de confianza no cruce el límite de regresión inaceptable.

También inspeccione los resultados por segmento. Un aprobado general no debería ocultar un caso contractual fallido, un idioma, una herramienta o un flujo de trabajo de alto valor.

Use una taxonomía de fallos a nivel de traza

Cada caso fallido debe recibir una clase principal de fallo. Una taxonomía coherente convierte la evaluación en trabajo de ingeniería en lugar de un debate sobre anécdotas.

Realice un seguimiento tanto del primer fallo como del resultado final de la traza. Un reintento que recupera una solicitud sigue consumiendo tiempo y dinero, y la recuperación repetida puede convertirse en un problema de capacidad de producción. La guía de límites de tasa de LLM explica cómo separar RPM, TPM, colas, reintentos y comportamiento de fallback.

Pruebe la compatibilidad del proveedor como una matriz

Un endpoint compatible con OpenAI puede reducir el trabajo de migración, pero la compatibilidad no es binaria. Pruebe las funciones exactas que utiliza su aplicación.

La documentación de salida estructurada de Google, por ejemplo, señala que la compatibilidad con esquemas se basa en un subconjunto de JSON Schema. Por eso debes probar tu esquema real en lugar de asumir que un esquema aceptado por un proveedor se comportará de forma idéntica en todas partes.

Calcula el costo efectivo por tarea aceptada

El precio por token es solo un componente de la economía de la migración. Mide el costo total de obtener un resultado utilizable:

costo efectivo por tarea aceptada =
  (uso del modelo
   + reintentos
   + uso de respaldo
   + costos de herramientas y recuperación
   + llamadas de evaluación o moderación
   + costo incremental de infraestructura)
  / tareas aceptadas

También estima el costo de revisión humana generado por resultados de baja confianza o mal formados. Un candidato con tokens más baratos puede resultar más caro si aumenta los reintentos, los bucles de herramientas, las colas de revisión o las salidas rechazadas.

Para los precios actuales de las rutas, usa la comparación de precios de API de IA como punto de partida y luego confirma el modelo y el precio exactos en el momento de la decisión. Guarda la marca de tiempo de precios junto con tus resultados porque los precios y la disponibilidad de modelos pueden cambiar.

Informa el costo por segmento, además del costo total. Los casos de contexto largo, las tareas multilingües, las entradas de imagen y los trazos de agentes pueden producir un ganador distinto al de las solicitudes de texto corto.

Prueba de carga del candidato bajo la política real de reintentos

Las pruebas de calidad fuera de línea suelen ejecutarse lentamente y de forma secuencial. La producción no.

Repite un subconjunto representativo con la concurrencia esperada y la máxima. Mide:

• Latencia de la traza de extremo a extremo en p50, p95 y p99.
• Tiempo hasta el primer token y tiempo de finalización cuando el streaming importa.
• Tiempo en cola frente al tiempo del proveedor.
• Respuestas por límite de velocidad y comportamiento de Retry-After.
• Timeouts, fallos de conexión y errores 5xx del upstream.
• Conteo de reintentos y tasa de recuperación de reintentos.
• Efectos secundarios duplicados causados por acciones de herramientas reintentadas.
• Frecuencia de fallback y ruta final exitosa.

Utilice el mismo comportamiento de reintento acotado previsto para producción. Los reintentos ilimitados pueden hacer que la tasa de éxito parezca buena, mientras violan los límites de latencia y coste. Si el candidato requiere ajustes de reintento o de cola materialmente diferentes, incluya ese cambio operativo en la decisión de migración.

Ejecute tráfico en sombra antes de un canary

Las pruebas en sombra envían una copia de las entradas de producción elegibles al candidato mientras el proveedor actual sigue atendiendo al usuario. Revelan distribuciones realistas de prompts y el comportamiento del proveedor sin permitir que la salida del candidato afecte al cliente.

Proteja la ruta en sombra:

• Excluya el tráfico sensible salvo que los controles de datos del candidato hayan sido aprobados.
• Desactive las herramientas que producen efectos secundarios o enrútelas a simulacros.
• Redacte o tokenize los campos restringidos cuando sea necesario.
• Limite el volumen y el coste de la sombra.
• Mantenga enlazados los trace IDs del proveedor actual y del candidato para análisis por pares.
• No permita que los reintentos en sombra consuman el presupuesto de capacidad de la ruta principal.

Los resultados en sombra deben evaluarse con los mismos validadores y la misma taxonomía de fallos que el conjunto de decisión offline.

Canarice el cambio de proveedor por etapas

Después de que pasen los filtros offline y en sombra, exponga una pequeña fracción observable del tráfico. Una secuencia práctica es:

1. Tráfico interno y sintético.
2. Usuarios o flujos de trabajo de bajo riesgo.
3. Un pequeño porcentaje del tráfico de producción elegible.
4. Aumentos graduales con una ventana de observación fija en cada etapa.
5. Despliegue completo solo después de que el candidato se mantenga dentro de todos los guardarraíles.

Defina activadores automáticos de reversión antes de comenzar. Los ejemplos incluyen una regresión en el éxito de la tarea, un pico de fallos de esquema, una infracción del p95 de latencia, una tasa de fallback elevada, sobrecoste o un fallo crítico de política.

Utilice un enrutamiento estable para que la misma conversación, ejecución del agente o cliente permanezca en una sola ruta cuando cambiar a mitad de sesión pudiera corromper el estado. Mantenga caliente al proveedor actual hasta que se cierre la ventana de reversión.

Para patrones de fiabilidad con varios proveedores, consulte el manual de enrutamiento de fallback de API LLM para producción.

Mantenga la política de enrutamiento después de la evaluación

El resultado no tiene que ser "moverlo todo". Muchos equipos obtienen un mejor resultado enrutando de forma deliberada:

• Una ruta centrada en la calidad para tareas complejas o de alto valor.
• Una ruta de bajo coste para extracción y clasificación acotadas.
• Una ruta de baja latencia para sugerencias interactivas.
• Una ruta regional para requisitos de ubicación de datos o disponibilidad.
• Una ruta de fallback para límites de tasa e interrupciones.

Esto hace que la evaluación sea reutilizable. Cada ruta tiene un contrato, un conjunto de datos y un presupuesto operativo. Los nuevos candidatos compiten por un trabajo definido en lugar de convertirse en otro proyecto de migración a nivel de plataforma.

Flatkey proporciona una capa de acceso compatible con OpenAI única a través de múltiples proveedores de modelos, lo que puede simplificar las pruebas comparativas y el enrutamiento. No elimina la necesidad de evaluación; reduce el trabajo de integración necesario para ejecutar la evaluación y mantener una opción de reversión. Compare las rutas actuales en precios de Flatkey.

Plantilla de memorando de decisión para el cambio de proveedor

Concluya la evaluación con un breve registro de decisión firmado:

Adjunte los resultados a nivel de caso, la versión del runner, los prompts, los validadores, las respuestas sin procesar y la instantánea de precios. Un revisor futuro debería poder reproducir por qué se aprobó el cambio.

Lista de verificación final de evaluación de modelos de IA

Antes de cambiar de proveedor de API de IA, confirme que tiene:

• Definido el flujo de trabajo exacto y la ruta candidata.
• Registrada la línea base del modelo actual y el margen operativo.
• Construidos conjuntos de desarrollo, decisión retenida y auditoría de producción.
• Incluidos casos comunes, de alto valor, de cola larga, adversariales, contractuales y operativos.
• Congelados los prompts, herramientas, configuraciones, entradas de recuperación y la política de reintentos.
• Ejecutadas pruebas emparejadas entre el modelo actual y el candidato.
• Aplicados validadores deterministas antes de la evaluación subjetiva.
• Calibrado cualquier evaluador basado en modelo frente a humanos.
• Definidos de antemano los controles obligatorios, los pesos y los márgenes de no inferioridad.
• Informados los intervalos de confianza y los resultados a nivel de segmento.
• Clasificadas las fallas de trazas de forma coherente.
• Probados esquemas, herramientas, streaming, errores, uso y límites de tasa.
• Calculado el costo efectivo por tarea aceptada.
• Realizadas pruebas de carga para la concurrencia esperada y máxima.
• Completada la revisión de privacidad, retención, regional y control de acceso.
• Superadas las comprobaciones de tráfico shadow y canary por etapas.
• Probada la reversión automática y mantenido disponible el modelo actual.
• Firmado y almacenado el memorando de decisión de cambio de proveedor.

Preguntas frecuentes

¿Cuántos casos de prueba son suficientes para una evaluación de un modelo de IA?

No existe un número universal. Use suficientes casos para cubrir cada segmento material y reducir la incertidumbre en torno a la decisión de migración. Los segmentos de alto riesgo o baja frecuencia pueden requerir un sobremuestreo deliberado. Informe intervalos de confianza en lugar de tratar el tamaño de la muestra como prueba por sí solo.

¿Debería usar benchmarks públicos para elegir un proveedor de API?

Use los benchmarks para crear una lista corta o comprender capacidades generales. No los use como el control de migración. Sus prompts, herramientas, esquemas, presupuesto de latencia, política de reintentos, controles de datos y mezcla de tráfico determinan la idoneidad para producción.

¿Puede una sola URL base compatible con OpenAI hacer que los proveedores sean intercambiables?

Puede centralizar la autenticación y reducir los cambios en el cliente. No puede garantizar compatibilidad idéntica de parámetros, salidas estructuradas, comportamiento de herramientas, eventos de streaming, límites o calidad del modelo. Pruebe la matriz de compatibilidad para cada ruta que utilice.

¿Cuál es la métrica más importante para cambiar de proveedor?

Para la mayoría de los sistemas de automatización, empiece por la finalización exitosa del flujo de trabajo de extremo a extremo. Luego explique ese resultado usando calidad, validez del contrato, latencia, fiabilidad, reintentos, fallback y coste efectivo.

¿Cuándo deberíamos volver a ejecutar la evaluación?

Vuelva a ejecutarla cuando la versión del modelo, la ruta del proveedor, el prompt, las herramientas, el sistema de recuperación, los precios, la distribución de la carga de trabajo, la política de riesgo o el margen de tráfico cambien de forma material. Mantenga en marcha una auditoría continua más pequeña después del lanzamiento para que las regresiones aparezcan antes de la siguiente migración planificada.

Haga que cada cambio de proveedor sea reproducible

El activo duradero no es el modelo ganador. Es el sistema de evaluación: casos versionados, captura de trazas, validadores, evaluadores, tarjetas de puntuación, pruebas de carga, controles de despliegue y un registro de decisiones.

Con ese sistema en su lugar, un nuevo proveedor se convierte en un experimento acotado en lugar de una reescritura arriesgada. Puede medir al candidato frente al mismo contrato de producción, exponerlo gradualmente y revertir el cambio rápidamente si la realidad no coincide con el laboratorio.

Fuentes

• OpenAI: mejores prácticas de evaluación
• OpenAI: trabajar con evals
• Anthropic: definir criterios de éxito y crear evaluaciones
• API de Anthropic: límites de velocidad
• API de Google Gemini: salidas estructuradas
• API de Google Gemini: llamada a funciones