Un asistente de documentación puede dejar de responder dentro del plazo tras un cambio rutinario en el sistema de recuperación, aunque el modelo siga siendo el mismo, el servicio funcione correctamente y las comprobaciones de despliegue hayan sido satisfactorias. La razón es que el cambio puede enviar un contexto mayor al modelo, prolongar la generación y aumentar la acumulación de solicitudes ante el servidor de inferencia, mientras que revertir el contenedor de la aplicación no restaura la configuración de recuperación que cambió en otro lugar.
Este escenario hipotético pone de manifiesto un problema práctico en la operación de aplicaciones de inteligencia artificial: ¿qué se ha desplegado realmente? En las aplicaciones generativas, la versión del modelo por sí sola no determina el comportamiento del sistema; las entradas, el preprocesamiento, las indicaciones, el índice, los modelos de incrustación, los contratos de las herramientas y la configuración del servicio pueden cambiar por separado.
Deja claros los límites de la versión
El artículo propone comenzar con un manifiesto de versión versionado que conserve las referencias de todos los componentes probados conjuntamente. Esto puede incluir el identificador de la versión, la versión de la aplicación, la versión del modelo, la versión de la indicación, la versión del índice, la versión de las incrustaciones, la canalización de segmentación y reordenación, la configuración operativa, el conjunto de evaluación y, además, la versión anterior.
Estas referencias deben apuntar a configuraciones o elementos guardados e inspeccionables, almacenando referencias a los secretos en lugar de sus valores. La versión operativa debería abarcar los límites de tokens, la agrupación, los tiempos de espera y la asignación de recursos. En el caso de las aplicaciones que invocan herramientas, deben incluirse las versiones de los esquemas de las herramientas y de los adaptadores.
Este manifiesto no garantiza una reproducibilidad literal; los servicios externos pueden cambiar, la generación puede seguir siendo no determinista y algunos proveedores no ofrecen instantáneas fijas del modelo. Por ello, conviene registrar estas limitaciones, junto con un momento concreto para capturar los datos y la configuración de indexación cuando los datos cambien continuamente. Actualizar varios almacenes de configuración de forma secuencial no constituye una versión atómica.
Prueba la tarea completa, no solo la llamada al modelo
El éxito de una solicitud HTTP no significa que el usuario haya recibido una respuesta correcta. La puerta de evaluación debe medir las propias tareas del producto, como citar una fuente accesible, respetar la versión correcta del producto y abstenerse de inventar instrucciones cuando no existan pruebas.
El artículo recomienda un conjunto de datos versionado que incluya preguntas normales, fallos anteriores, solicitudes ambiguas, casos que carezcan de pruebas y tentativas de eludir los límites de autorización, conservando además un conjunto que no se haya utilizado para el ajuste. Pueden aplicarse comprobaciones deterministas a la validez del esquema, los argumentos de las herramientas, los identificadores de las citas y la aplicación de las autorizaciones. En cambio, los juicios semánticos requieren un criterio claro y revisión humana; el juicio de otro modelo puede ayudar a ordenar los casos, pero no constituye una verdad de referencia.
La versión debe ejecutarse a través del flujo completo, desde la recuperación hasta la generación y la validación de las salidas, y después se deben examinar los resultados por segmentos relevantes, como la longitud de las entradas, los idiomas, las versiones de los productos y los casos de escasez de pruebas. También deben definirse los criterios de aceptación antes de ver la versión candidata, incluida la prohibición de cualquier infracción de las autorizaciones, los límites de regresión de la calidad y los presupuestos de latencia y coste.
Mide la carga de trabajo y el coste tal como los percibe el usuario
No basta con probar el número de solicitudes por segundo. Las pruebas deben distribuirse entre distintas longitudes de entrada y salida, niveles de concurrencia, ráfagas de acceso y comportamiento de la memoria en caliente y en frío. En las respuestas en flujo, hay que separar el tiempo hasta el primer token de la tasa de tokens posteriores y del tiempo de finalización, midiendo también el tiempo de espera en la cola.
El artículo recomienda comenzar con trazas completas de la solicitud y después examinar la recuperación, la reordenación, las colas, las fases de inicialización y generación y las llamadas posteriores. No se deben combinar percentiles de etapas diferentes y tratarlos como un percentil global; cada medición puede describir solicitudes distintas.
También hay que vincular la misma identidad a la versión en las trazas y en los registros estructurados de solicitudes, y seguir la calidad, las distribuciones de latencia, los errores, el uso de tokens y las tasas de transferencia a rutas alternativas. Un coste menor por solicitud no implica necesariamente un coste menor por tarea completada; por ello, el artículo propone calcular el coste de la tarea exitosa, contando los intentos fallidos y declarando claramente cuándo se utilizan indicadores indirectos del éxito.
La reversión restaura las dependencias, no solo los pesos del modelo
La versión candidata puede presentarse a un porcentaje limitado del tráfico manteniendo disponible la versión actual, pero el éxito de la prueba gradual requiere comparar las señales de la candidata y del control, y garantizar que aquella esté expuesta a los segmentos de carga relevantes. Deben definirse el responsable de la decisión, las condiciones de detención, el periodo mínimo de observación y el procedimiento de restauración antes de comenzar el despliegue.
Si la versión candidata sustituye el índice de recuperación en su lugar, no bastará con dirigir las solicitudes a una imagen antigua de la aplicación. Es necesario conservar versiones compatibles de los índices o diseñar una migración reversible, teniendo en cuenta las operaciones de eliminación y la revocación de autorizaciones vigentes. También debe establecerse una política para drenar o cancelar las generaciones en curso y proteger los efectos secundarios de herramientas como el envío de correos electrónicos o la modificación de registros mediante idempotencia y límites de aprobación adecuados.
¿Por qué importa este enfoque?
El valor práctico de estas recomendaciones es que trasladan la gestión de aplicaciones de inteligencia artificial de la pregunta «¿qué modelo utilizamos?» a una pregunta más amplia: ¿se puede identificar la versión completa que produjo una respuesta deficiente y después restaurar una versión conocida y compatible? Esto significa que el mínimo útil puede vivir dentro de un repositorio existente y estar compuesto por un manifiesto de versión, una tarea de evaluación, una prueba de carga representativa, trazas vinculadas a la versión y formación práctica sobre la reversión.
Las limitaciones también son claras: superar un conjunto limitado de pruebas no demuestra la ausencia de fallos de seguridad ni de errores poco frecuentes, y las observaciones de producción son selectivas y no siempre equivalen a la corrección de la respuesta. Por ello, la revisión humana y la asignación de responsabilidades en los puntos de contacto entre la aplicación, la plataforma y los datos siguen formando parte de la arquitectura operativa, no simples complementos que puedan automatizarse por completo.