English

Cambia el modelo, no la app

Casi cada semana sale un nuevo modelo — más barato, más rápido, mejor en tu tarea exacta. Si adoptarlo implica reescribir código en cinco puntos de llamada, nunca lo vas a hacer de verdad; el cambio siempre va a perder frente a "este sprint no". La solución es arquitectónica: pon cada llamada al modelo detrás de una sola interfaz y haz que el modelo mismo sea un valor de configuración en lugar de una dependencia fija en el código.

El problema: código del proveedor incrustado en cada punto de llamada

La forma natural de agregar una función de IA es importar el SDK del proveedor directamente donde necesitas una completion — un punto de llamada en el manejador del chat, otro en el resumidor, otro en el clasificador. Cada uno importa el cliente del proveedor, referencia el string con el nombre del modelo del proveedor y arma su petición en el formato específico de ese proveedor.

Esto funciona bien hasta que necesitas cambiar de proveedor — el modelo con el que empezaste se volvió más caro, un competidor lanzó algo claramente mejor para tu carga de trabajo, o quieres un modelo más barato para las llamadas de bajo riesgo y uno más potente para las difíciles. Ahora el cambio no es una línea, es una búsqueda por todo el código de cada lugar que importa ese SDK, seguida de emparejar los parámetros de cada punto de llamada y las suposiciones sobre la forma de la respuesta con la API del nuevo proveedor.

La solución: una interfaz, el modelo como configuración

El código de tu aplicación nunca habla directamente con el SDK de un proveedor. Habla con una única función o interfaz interna — llámala getCompletion(), generateText(), lo que encaje en tu código — y esa función es el único lugar donde alguna vez se importa el SDK de un proveedor. El modelo mismo se vuelve un parámetro, o un valor de configuración, que se le pasa a esa única función.

# Every call site in your app looks the same regardless of provider:
result = ai.generateText({
  model: config.MODEL,   # e.g. "provider-a/model-name"
  prompt: "...",
})

# Swapping providers is a one-line change:
config.MODEL = "provider-b/model-name"

Como cada punto de llamada pasa por la misma interfaz, un nuevo modelo — incluso de un proveedor completamente distinto — solo requiere actualizar ese único valor de configuración y, si hace falta, la implementación interna de la interfaz. Ningún punto de llamada cambia. Sin refactor profundo.

Por qué esto es seguro, no solo cómodo

La seguridad viene de dónde se ubica la frontera. La lógica de tu aplicación — prompts, reglas de negocio, manejo de reintentos/errores — vive por completo de tu lado de la interfaz. El único trabajo de la interfaz es traducir una petición genérica de "genera texto/objeto dado este modelo y este prompt" a la forma que espera el proveedor subyacente, y traducir la respuesta de vuelta. Tu app nunca aprende el formato de petición del proveedor; solo conoce el formato de la interfaz, que no cambia cuando cambia el proveedor.

Esto también hace que probar sea más fácil: puedes simular (mock) la interfaz sin necesitar una API key en vivo para cada proveedor que podrías llegar a usar.

Cómo configurarlo

1. Elige o escribe una única función de interfaz por la que pase cada llamada al modelo — un wrapper delgado que escribas tú, o una librería de interfaz unificada que ya normalice varios proveedores detrás de una forma de llamada común.
2. Mueve el identificador del modelo a la configuración — una variable de entorno o un archivo de settings, no un literal de string desperdigado por los puntos de llamada.
3. Audita los imports directos del SDK fuera de ese único módulo de interfaz. Cada import directo es un costo de migración futuro.
4. Mantén las peculiaridades específicas del proveedor dentro de la interfaz, sin que se filtren al código de la app — convenciones de límite de tokens, formatos de streaming, tipos de error específicos del proveedor.

Trucos avanzados

• No dejes que "unificado" se vuelva mínimo común denominador por accidente. No tienes que exponer cada función del proveedor a través de la interfaz compartida — sé deliberado sobre qué capacidades se estandarizan versus cuáles quedan específicas del proveedor y opcionales.
• Prueba el cambio, no asumas compatibilidad directa (drop-in). Dos modelos detrás de la misma interfaz pueden aún producir salidas notablemente distintas para el mismo prompt — reevalúa antes de lanzar un cambio.
• Cuida los casos límite de la forma de la respuesta — respuestas vacías, rechazos, tool calls parciales pueden diferir entre proveedores incluso detrás de una interfaz unificada si esta no los normaliza.

Recursos

• Las interfaces unificadas de proveedores de LLM son un patrón común en los SDKs de IA modernos — busca en tu stack la documentación de "provider abstraction", "model interface" o "multi-provider".