Dónde encajan los modelos en una arquitectura

El modelo es una dependencia, no la arquitectura

La Sección 12.1 describió un modelo como una función probabilística a la que se accede mediante una API. En una arquitectura es un contenedor entre muchos y, normalmente, una pequeña parte del código. Un asistente de atención al cliente tiene un frontend de chat, un almacén de conversaciones, integraciones con los servicios de pedidos y de reembolsos, un índice de búsqueda, identidad, logging, un traspaso a agentes humanos y un pipeline de despliegue; la llamada al modelo es una línea en medio. Por tanto, las preguntas arquitectónicas son las de siempre, aplicadas a un nuevo tipo de dependencia: dónde se ejecuta, cómo se llama, qué hay entre ella y quienes la llaman, qué ocurre cuando es lenta, se equivoca o no está disponible, y quién responde de su salida.

Acertar con estas preguntas importa más que elegir el mejor modelo del mes. Los modelos se sustituyen cada pocos meses; el gateway, el diseño de las alternativas, el conjunto de evaluación y el proceso de revisión humana duran años. Las decisiones de esta sección son de las significativas y difíciles de revertir, en el sentido del Capítulo 1, así que merecen registros de decisiones; la elección de una versión concreta del modelo debe ser fácil de cambiar.

Tres lugares donde puede ejecutarse un modelo

API de modelos alojadas. El proveedor ejecuta el modelo y tú pagas por token. Esto abarca las API propias de los proveedores de vanguardia (OpenAI, Anthropic y Google, entre otros) y las plataformas en la nube que revenden los modelos de varios proveedores dentro de tu cuenta de nube existente. Es la forma más rápida de empezar y da acceso a los modelos más capaces, sin aceleradores que comprar ni operar. Los costos son un precio por token que crece con el uso, unos límites de tasa que fija otro, una dependencia de la disponibilidad del proveedor, modelos que quedan obsoletos según el calendario del proveedor y datos que salen de tu perímetro. Los contratos, las condiciones de tratamiento de datos, las opciones de conservación nula o limitada y el procesamiento regional reducen esta última preocupación, pero no la eliminan.

Modelos de pesos abiertos autoalojados. Un modelo de pesos abiertos (open-weight) publica sus pesos entrenados, así que puedes ejecutarlo en tus propios aceleradores o en aceleradores alquilados con un servidor de inferencia como vLLM. Algunos ejemplos son los modelos de Meta (Llama), Mistral, Alibaba (Qwen), DeepSeek, Google (Gemma) y OpenAI (gpt-oss). Tú controlas la ruta de los datos, la versión exacta y el fine-tuning, y con un volumen alto y constante el costo por token puede quedar muy por debajo de los precios de las API. A cambio, asumes la planificación de capacidad de un hardware escaso y caro, la utilización (los aceleradores ociosos cuestan lo mismo que los ocupados), las actualizaciones, los parches de seguridad y las guardias. Las licencias importan: algunos modelos de pesos abiertos usan licencias permisivas como Apache 2.0, mientras que otros usan licencias propias con condiciones de uso o de escala, y la mayoría no publican sus datos de entrenamiento. La Open Source AI Definition de la Open Source Initiative (versión 1.0, octubre de 2024) pone el listón más alto que los simples pesos abiertos. Una vía intermedia, la que usa el propio chatbot de este curso, es llamar a modelos de pesos abiertos a través de un proveedor de inferencia externo: precio por token, sin hardware y con la libertad de llevar el mismo modelo a otro sitio.

Modelos en el dispositivo. Los modelos pequeños, a menudo de unos pocos miles de millones de parámetros o menos y cuantizados a una precisión menor, se ejecutan en teléfonos, computadoras portátiles o en el navegador. Ofrecen privacidad (los datos nunca salen del dispositivo), funcionamiento sin conexión, ningún costo por llamada y una latencia muy baja, a cambio de una capacidad mucho menor, una gran dispersión del rendimiento entre dispositivos, descargas de la app más grandes y la dificultad de actualizar modelos ya distribuidos a millones de dispositivos. Muchos productos los combinan: un modelo pequeño en el dispositivo se encarga de las tareas rápidas y privadas y deriva las más difíciles a la nube.

Inferencia online y puntuación por lotes

La segunda pregunta es si hay un usuario esperando. La inferencia online llama al modelo en la ruta de la solicitud, así que se aplican objetivos de latencia: los usuarios notan el tiempo hasta las primeras palabras visibles, que es por lo que las respuestas del chat se envían en streaming, y abandonan una solicitud que tarda muchos segundos. Las llamadas online necesitan timeouts, límites de concurrencia y capacidad para el pico de la noche, exactamente igual que cualquier dependencia síncrona del Capítulo 6.

La puntuación por lotes procesa muchos elementos sin que nadie espere: etiquetar por la noche dos millones de platos de la carta con sus alérgenos, resumir las conversaciones de soporte del día anterior, volver a generar los embeddings de una colección de documentos. El trabajo por lotes puede usar el modelo adecuado más barato, ejecutarse cuando hay capacidad libre y reintentar con calma. Varios proveedores ofrecen interfaces asíncronas por lotes que aceptan un archivo de solicitudes y devuelven los resultados en unas horas con un descuento considerable. Entre ambas está la inferencia asíncrona: una solicitud se pone en cola, se avisa al usuario de que el resultado llegará después (una decisión de reembolso por correo electrónico, el resumen de un documento en unos minutos) y unos workers vacían la cola a un ritmo controlado, usando las colas y el back pressure del Capítulo 9 para absorber los picos y los límites de tasa del proveedor. Sacar el trabajo de la ruta online es una de las decisiones de costo y fiabilidad más eficaces que existen.

Un gateway de IA entre las aplicaciones y los modelos

En cuanto más de un equipo o una funcionalidad llaman a modelos, un gateway de IA (AI gateway) dedicado se amortiza. Desempeña el papel que un API gateway desempeña para los microservicios, especializado en el tráfico de modelos. Las aplicaciones llaman a un único endpoint interno con un único formato de solicitud y su propia identidad; el gateway guarda las claves de los proveedores, traduce a la API de cada proveedor, aplica el enrutamiento y las alternativas, hace cumplir las cuotas y los presupuestos de gasto por equipo, aplica límites de tasa, registra cada llamada (modelo, versión, número de tokens, latencia, costo, resultado) para el trazado y la asignación de costos, puede guardar respuestas en caché y ofrece un lugar donde conectar de forma centralizada los guardrails de entrada y de salida.

Las ventajas son arquitectónicas: la elección del proveedor pasa a ser una decisión de configuración en lugar de un cambio de código en cada servicio, las claves dejan de estar dispersas por las aplicaciones, el gasto es visible por funcionalidad y una caída de un proveedor se gestiona una sola vez. Los costos son los de cualquier intermediario compartido. Es una nueva dependencia crítica que debe tener alta disponibilidad, añade una pequeña latencia y sus logs se convierten en un almacén concentrado de prompts que pueden contener datos personales, por lo que se le aplican reglas de enmascarado y de conservación (consulta privacidad desde el diseño). Existen productos de gateway de código abierto y gestionados, y las plataformas en la nube incluyen funciones de gateway; construir uno ligero es razonable para un sistema pequeño, pero las cuotas, el streaming, los reintentos y la contabilidad dan más trabajo de lo que parece.

Enrutamiento y cascadas

No todas las solicitudes necesitan el modelo más capaz. El enrutamiento decide de antemano qué modelo debe atender una solicitud, mediante reglas (la funcionalidad, el nivel del cliente, el idioma) o un clasificador pequeño y rápido. En el asistente de soporte, ¿dónde está mi pedido? puede ir a un modelo pequeño y barato que llama a una herramienta, mientras que una queja sobre tres problemas distintos va a un modelo más grande. Una cascada de modelos, en cambio, prueba primero un modelo más barato y escala solo cuando una comprobación indica que su respuesta no es lo bastante buena. FrugalGPT (2023), de Chen, Zaharia y Zou, mostró que unas cascadas bien ajustadas pueden acercarse a la calidad del modelo más potente con una fracción del costo.

Una cascada solo es tan buena como su comprobación de escalado. Las comprobaciones fiables son deterministas: la salida no supera la validación del esquema, una fuente citada no existe, falta un campo obligatorio, una regla de negocio rechaza la propuesta. Un modelo verificador que puntúa la respuesta es más débil, pero a menudo útil. La declaración de confianza del propio modelo es la señal menos fiable y no debe usarse sola. Las cascadas también tienen costos: las solicitudes escaladas pagan dos llamadas y esperan a ambas, ahora hay dos modelos que evaluar y mantener sincronizados, y el techo de calidad lo fija la comprobación, no el modelo potente. Mide la tasa de escalado; si la mayoría de las solicitudes escalan, usa enrutamiento en su lugar.

Escaleras de alternativas entre modelos y proveedores

Las API de modelos fallan de todas las formas en que fallan las dependencias remotas, y de algunas propias: respuestas de límite de tasa (HTTP 429) cuando se agota una cuota, errores de sobrecarga en los momentos de más actividad, respuestas lentas que superan un timeout, caídas regionales y modelos retirados en una fecha de obsolescencia. Los patrones del Capítulo 9 se aplican directamente, organizados como una escalera de alternativas (fallback ladder): una lista ordenada de peldaños, cada uno de los cuales se prueba cuando falla el de arriba. Una escalera típica es el modelo principal; el mismo modelo en otra región o en otro proveedor de alojamiento; un modelo distinto de capacidad similar de un segundo proveedor; un modelo más pequeño y rápido; y, por último, una respuesta sin IA, como un mensaje predefinido útil, los resultados de búsqueda del centro de ayuda o un traspaso a una persona.

Reglas de diseño para una escalera: da a cada peldaño su propio timeout y a toda la escalera un plazo total, para que el usuario nunca espere cuatro fallos lentos seguidos; respeta Retry-After y pon un modelo con límite de tasa en un periodo de enfriamiento (un circuit breaker sencillo) en lugar de bombardearlo; no reintentes los errores que volverán a fallar, como una solicitud demasiado grande o rechazada por un filtro de contenido; valida la salida en cada peldaño, porque un peldaño inferior puede producir respuestas con una forma ligeramente distinta; evalúa cada peldaño con el mismo conjunto de evaluación, ya que los prompts suelen necesitar ajustes por modelo; y registra qué peldaño respondió, para que los paneles de calidad puedan distinguir una respuesta degradada de una normal.

Las propias funcionalidades de IA de este curso son un ejemplo pequeño y real. Las respuestas de ArchitectBot y la corrección de las respuestas escritas de las pruebas se generan a través de una escalera de varios modelos de pesos abiertos servidos por un único proveedor de inferencia, que se prueban en un orden de preferencia fijo. A un modelo que devuelve una respuesta de límite de tasa se le aplica un periodo de enfriamiento durante el tiempo que pide el proveedor (dentro de unos límites fijados); una solicitud que falla, agota su timeout o devuelve una respuesta inutilizable pasa al siguiente peldaño; esos peldaños comparten un presupuesto de tiempo global, y un segundo proveedor sirve como último peldaño. El diseño cambia algo de calidad de las respuestas en los peldaños inferiores por disponibilidad: es preferible una respuesta algo más débil a ninguna.

Humanos en el bucle

El concepto de humano en el bucle (human in the loop) describe varios diseños distintos, y conviene nombrar a cuál se refiere uno. Aprobación antes del efecto: el modelo redacta y una persona aprueba (un reembolso por encima de un límite, una respuesta a un regulador, un cambio en producción). Revisión después del efecto: las salidas surten efecto de inmediato y las personas revisan una muestra o los casos marcados. Escalado: el modelo gestiona lo que puede y pasa el resto a una persona, con la conversación y la evidencia. Retroalimentación: las personas etiquetan o corrigen las salidas para crear conjuntos de evaluación y mejorar los prompts.

Cada diseño tiene consecuencias arquitectónicas. La aprobación crea una cola que debe dimensionarse para el volumen máximo, como la cola de revisión de fraude de la sección 12.1, y añade una latencia que se mide en minutos u horas. Las personas que aprueban cientos de sugerencias buenas empiezan a aprobar sin leer (sesgo de automatización), así que la interfaz debe mostrar la evidencia y la acción exacta, resaltar lo inusual y registrar con qué frecuencia los revisores cambian la propuesta; una tasa de modificación cercana a cero es una señal de alarma, no un éxito. Los traspasos necesitan todo el contexto para que el cliente no tenga que repetirse. La supervisión humana que exige la normativa para algunos usos es aún más exigente: la persona debe entender los límites del sistema y poder anularlo.

Construir o comprar, y cómo elegir un modelo

La pregunta de construir o comprar tiene más de dos respuestas. Puedes comprar una funcionalidad de IA completa dentro de un producto que ya usas (el asistente de un proveedor de software de helpdesk); construir sobre API alojadas; hacer fine-tuning de un modelo para tu tarea; autoalojar pesos abiertos; o, rara vez, entrenar el tuyo propio. Usa la lente estratégica del diseño guiado por el dominio: compra para capacidades genéricas, como la transcripción de reuniones, y construye donde la IA toca tu dominio central y tus propios datos te dan una ventaja. Construyas lo que construyas, mantén el código específico de cada proveedor detrás de un puerto con un adaptador por proveedor, y evita depender de funcionalidades que solo ofrece un proveedor, salvo que su valor justifique la dependencia del proveedor (lock-in).

Elige los modelos con tu propio conjunto de evaluación, no con las clasificaciones públicas (leaderboards). Las clasificaciones miden tareas generales que pueden no parecerse a las tuyas, y hay modelos que se han ajustado para puntuar bien en algunas de ellas. Define los criterios y sus pesos antes de probar, como en cualquier decisión ponderada, y después preselecciona dos o tres candidatos y mídelos con unos cientos de ejemplos reales. Espera que la respuesta sea una combinación, como un modelo pequeño para el enrutamiento y uno más grande para los casos difíciles, más que un único ganador.