Volver al blog
Ajustar los modelos de LIA sin reiniciar y sin configuraciones imposibles
Técnico4 min de lectura

Ajustar los modelos de LIA sin reiniciar y sin configuraciones imposibles

El problema

En una instancia de LIA, decenas de tareas recurren a un modelo de lenguaje: entender tu petición, planificar, responder, resumir una reunión, escribir tu diario, preparar una notificación. Un administrador tiene que poder cambiar el modelo de una de ellas, porque un proveedor sube sus precios, sale un modelo más reciente o una tarea responde mal.

Si ese cambio pasa por un archivo de configuración y un reinicio, uno duda en hacerlo. Si pasa por un formulario que acepta cualquier cosa, se acaba guardando una combinación que el proveedor rechazará en cada llamada. Y si nada limita el gasto, una instancia abierta a varias cuentas puede costar mucho más de lo previsto.

Lo que quería

Quería un único sitio para estos ajustes, un efecto inmediato y una pantalla que solo proponga lo que va a funcionar. También quería que el gasto tuviera dos topes claros: el de cada cuenta y el de toda la instancia.

Cómo funciona

Cada tarea tiene valores por defecto escritos en el código y probados. En Administración › Configuración LLM, el administrador puede sustituirlos, tarea por tarea: proveedor, modelo, temperatura, presupuesto de respuesta, tiempo límite, profundidad de razonamiento. Esa sustitución se guarda en la base de datos y se aplica a las operaciones siguientes, sin reinicio. El botón «Restablecer» la borra y vuelve al valor por defecto del código. No hay una tercera fuente oculta: un ajuste de modelo antiguo que se haya quedado en un archivo de entorno se ignora.

La pantalla también sirve de salvaguarda:

  • Solo propone los niveles de razonamiento que acepta el modelo elegido, y oculta los ajustes que ese modelo no sabe recibir.
  • Un presupuesto de respuesta se ajusta al tope de salida conocido del modelo. Si pasas a un modelo más limitado, LIA envía la menor de las dos cifras y lo indica.
  • Un razonamiento profundo con un presupuesto de respuesta demasiado pequeño se rechaza al guardar: el razonamiento ocuparía todo el espacio y la respuesta llegaría vacía.

Lo que sabe hacer cada modelo (herramientas, imágenes, salida estructurada, topes) viene de un catálogo mantenido a partir de registros públicos, y cada fila dice de dónde vienen sus valores: un valor por defecto que nadie ha comprobado, un valor importado o un valor confirmado por una persona. Un modelo solo se desactiva si la fecha de retirada anunciada por su proveedor ya ha pasado y ninguna tarea lo usa todavía.

El coste, tarea por tarea

Esta división permite optimizar con precisión. Por ejemplo, la clasificación de las peticiones funciona con un modelo pequeño y económico, el planificador con un modelo más caro pero más fiable, la extracción de recuerdos con un modelo local gratuito. Los precios viven en un catálogo de tarifas que también conoce las horas valle de los proveedores que las ofrecen: cada llamada se cuenta a la tarifa de su momento. Cada llamada conserva el modelo realmente usado y los parámetros enviados, y los paneles permiten comparar las tareas entre sí.

Dos topes para el gasto

Cada cuenta puede tener sus límites, en tokens, en mensajes y en coste, por ciclo mensual o en total. Pero sumar cuentas no limita una instancia. Por eso el operador puede fijar un presupuesto diario de la instancia, que el administrador puede reducir desde la interfaz sin poder ampliarlo: se aplica el menor de los dos valores.

Los dos topes no reaccionan igual ante una avería. Si la base de datos no responde, un límite de cuenta deja pasar un mensaje de más. Un gasto de instancia desconocido, en cambio, bloquea, porque el peor caso por ese lado es el presupuesto entero. El rechazo dice lo que pasa: una pausa de la instancia, con la hora a la que se levanta. Así no crees haber agotado tu propia cuota. En segundo plano, una tarea rechazada se anota como omitida, lo que evita buscar una avería que no existe.

Los límites

  • Un cambio se aplica a las operaciones siguientes: una operación ya empezada puede conservar la configuración con la que arrancó.
  • Un precio del catálogo es una referencia. La factura real sigue siendo la del proveedor, que a veces aplica reglas que LIA no sabe expresar, como una tarifa más alta a partir de cierto tamaño de petición.
  • Algunas decisiones pequeñas, como clasificar un correo, pueden confiarse a un modelo de decisión especializado. Cada uso tiene su interruptor, apagado por defecto. En caso de duda, LIA retoma su recorrido habitual, y una decisión así no autoriza ninguna acción por sí sola.

Para profundizar: Un modelo para cada tarea, con el proveedor que elijas; Modificar todo el catálogo de modelos en una hoja de cálculo, sin riesgo.

#llm-config#admin-ui#governance#db-overrides#multi-provider#defaults