Agregadores de LLM: cómo elegir modelos gratuitos que funcionen y no mentir sobre el resultado

Cuando un proyecto incorpora un selector de LLM, lo más habitual es tomar el camino más obvio: una lista grande de modelos, el usuario elige uno y se envía la solicitud. A corto plazo funciona. A largo plazo empieza a romperse.

Dónde falla el enfoque simple

Los problemas aparecen no en la interfaz, sino en el comportamiento de los proveedores y de los propios modelos:

• Modelos gratuitos inestables — figuran como gratuitos, pero responden de forma irregular y se caen durante el downtime del proveedor
• Modelos que desaparecen — ayer estaban en el listado; hoy el proveedor los eliminó o los cerró a nuevos usuarios
• Caída de calidad — formalmente activo, pero sirve solo para demos o tareas sencillas
• Desajuste entre frontend y backend — la lista de la interfaz está desactualizada uno o dos días, mientras el backend conoce otra realidad
• Errores y redirecciones — se pidió un modelo y llegó un error, o la respuesta vino de un modelo completamente distinto

El mayor problema: la interfaz no sabe qué modelo respondió realmente. El usuario eligió Claude 3.5, pero la respuesta vino de Gemini, y el usuario no se entera. Eso genera confusión: si la calidad de la respuesta no coincide con el modelo elegido, el usuario pierde la confianza.

Un circuito de ingeniería estricto en lugar de un catálogo

La solución no se basa en una lista interminable, sino en el control desde el backend:

Paso 1: limpieza de la lista. El backend recibe la lista en bruto de modelos del proveedor y la filtra: conserva solo las opciones gratuitas adecuadas, descarta las inestables y elimina duplicados. Se pueden añadir health checks, que consultan periódicamente cada modelo para ver si sigue vivo.

Paso 2: un modelo por marca. Aunque OpenAI tenga 5 modelos gratuitos en su listado, al frontend llega uno solo: el más estable. Esto simplifica la elección del usuario y reduce la probabilidad de caer en un mal modelo.

Paso 3: fallback entre marcas. Durante una solicitud real, si el primer modelo devuelve un error, el sistema prueba automáticamente con el segundo y luego con el tercero. El usuario no se entera del fallo; para él solo tarda un poco más.

Paso 4: honestidad en la respuesta. Se devuelve no solo el texto generado, sino también actual_model, el modelo que realmente lo generó. Así la interfaz puede decirle al usuario con honestidad: «Respuesta de GPT 4o mini, porque el modelo principal estaba en downtime».

«El problema no es cómo mostrar con elegancia una lista de modelos.

El problema es cómo construir un sistema que elija modelos gratuitos que funcionen y no mienta sobre el resultado» — esa es la esencia de la tarea.

Esto convierte un catálogo inestable en un circuito predecible. Si un proveedor elimina un modelo, el backend lo detecta en la siguiente comprobación y actualiza la lista en el frontend. Si un modelo se cae, se activa el fallback y el usuario recibe una respuesta de otro proveedor.

Qué significa esto

Elegir un LLM deja de ser una tarea de interfaz y pasa a ser una tarea de ingeniería, con limpieza de datos, health checks, lógica de fallback y seguimiento honesto. Para el producto, eso significa fiabilidad y menos consultas a soporte. Para el usuario, la elección funciona, las respuestas llegan y la interfaz no miente.