Operar un sistema basado en un modelo de lenguaje de gran tamaño no termina cuando se pone a disposición o se mejora su precisión inicial. El sistema puede seguir estando completamente disponible mientras aprueba silenciosamente decisiones incorrectas, consume el presupuesto con rapidez o cambia durante las interrupciones a un modelo cuya calidad no se ha probado. Por eso, la quinta parte de la serie Running LLM systems in production se centra en la operabilidad diaria, entendida como la capa que hace que el sistema pueda observarse, controlarse, detenerse y recuperarse.
Supervisa la decisión, no solo el servicio
Las métricas de servicio tradicionales, como la tasa de solicitudes y errores, la latencia y el consumo de CPU, no revelan si el agente está tomando buenas decisiones. La fuente propone añadir una capa de supervisión específica de las decisiones que incluya el volumen de decisiones, la proporción de ejecución automatizada, la distribución de la confianza compuesta, la duración de cada nodo, los casos de bloqueo de los controles de seguridad, el consumo de tokens y el coste, la tasa de intervención humana y los resultados de evaluaciones ocultas sobre muestras del tráfico de producción.
La fuente identifica cuatro familias de señales: decisión, seguridad, coste y rendimiento, y calidad. Si no es posible medirlo todo, la prioridad debe ser la proporción de ejecución automatizada, los bloqueos de los controles de seguridad, el coste total de los modelos y la tasa con la que los humanos anulan las decisiones del sistema.
También recomienda dividir los registros en tres capas: datos operativos de gran volumen, metadatos de la decisión dentro de los límites de confianza y datos sin procesar o estructurados sujetos a cifrado y control estricto. Cada decisión debe llevar un identificador fijo, decision_id, que vincule las métricas, los registros, las trazas y el registro de auditoría, de modo que se pueda investigar una decisión desde el principio hasta el final.
Haz que el coste sea medible y limitable
Las llamadas a los modelos no deberían distribuirse en distintas partes del código, porque eso dificulta asignar y controlar el coste. En su lugar, la fuente propone una única puerta de enlace por la que pasen todas las llamadas, encargada de calcular los tokens y el coste por arrendatario, capacidad y modelo, además de aplicar límites de tasa y de presupuesto.
Las herramientas de reducción de costes aparecen en el siguiente orden: no llamar al modelo cuando basta una regla determinista, agrupar los elementos en una sola llamada, almacenar temporalmente los resultados deterministas, elegir un modelo más pequeño para las tareas sencillas y, después, reducir el contexto y las instrucciones innecesarias. También se deben calcular los tokens estimados antes de la llamada, en lugar de contar cada solicitud como una sola unidad, y establecer un límite total para la plataforma y límites para los reintentos y los bucles de herramientas ilimitados.
Enrutamiento, recuperación e interruptor de apagado
En la práctica no existe un único modelo para todas las tareas. Las tareas de bajo riesgo y gran volumen pueden dirigirse a un modelo más pequeño, los casos ambiguos o sensibles pueden asignarse a un modelo más capaz y puede utilizarse una familia diferente para el modelo de evaluación, de modo que los modelos no compartan los mismos puntos débiles. Se debe evaluar cada modelo presente en la ruta de enrutamiento o recuperación, porque cambiar a un modelo alternativo puede modificar la calidad.
Durante la interrupción de un proveedor, se debería utilizar una cadena de recuperación definida con un único tiempo de espera total, un disyuntor que impida llamar a un proveedor conocido por estar caído y claves de idempotencia para evitar procesar la decisión dos veces si el tiempo de espera de la llamada termina después de que esta haya tenido éxito. Cuando la alternativa no sea aceptable, la decisión debe transferirse a una persona en lugar de ocultar la degradación.
En cuanto al interruptor de apagado, la fuente propone que funcione como un estado operativo compartido que pueda ser general o específico de un arrendatario o una capacidad. Los estados incluyen: funcionamiento normal, HUMAN_ONLY, que detiene la ejecución automatizada y mantiene las propuestas para las personas, y HALTED, que detiene por completo la toma de decisiones. Si no se puede acceder al interruptor, el comportamiento seguro es pasar al modo de revisión humana, no continuar con el funcionamiento normal.
La arquitectura que evita el caos
La fuente vincula la operabilidad con una arquitectura de seis direcciones que separa la lógica del dominio de los paquetes de los proveedores de modelos mediante una interfaz y puertas de enlace de adaptación. De este modo, se puede cambiar de proveedor sin reescribir la lógica empresarial y se puede probar el dominio utilizando un modelo simulado sin red ni coste.
La arquitectura básica incluye servicios de agentes sin estado, una puerta de enlace de modelos, un almacén de auditoría de solo adición, una memoria compartida para los límites y el interruptor de apagado, un almacén de secretos y almacenamiento de objetos para las entradas y los datos sensibles. La fuente también hace hincapié en una identidad independiente para cada servicio, el mínimo de privilegios y la verificación de que la identidad del arrendatario coincide con la solicitud en cada salto, especialmente cuando se utilizan concesiones de autorización de corta duración para tareas aplazadas.
¿Por qué importa esta noticia?
El valor práctico no reside en añadir un componente nuevo, sino en reunir los puntos críticos de control en una única entrada: la puerta de enlace que hace posible cambiar de modelo es la misma que mide el coste, aplica los límites, gestiona el enrutamiento y la recuperación y activa el apagado. El éxito de este enfoque sigue estando condicionado a probar realmente los escenarios de fallo, como la interrupción del proveedor del modelo, la activación del interruptor de apagado, una carga repentina y el reinicio de un nodo durante una decisión en curso. Sin estas pruebas, los mecanismos de recuperación siguen siendo supuestos no verificados.