Mover un prototipo a inferencia administrada

Suposiciones que viajan mal

Un prototipo suele ser un delgado envoltorio alrededor de un proveedor. Esa es la elección correcta para un prototipo y la base incorrecta para un servicio, porque varias propiedades que parecen hechos sobre LLMs son en realidad propiedades de la implementación del primer proveedor.

• Tokenización. El mismo texto es una cantidad diferente de tokens en un tokenizador diferente. Las estimaciones de costos, los límites de contexto y la lógica de truncamiento que asumen lo contrario se rompen silenciosamente, produciendo truncamiento en medio de un pasaje recuperado.
• Llamada a herramientas. La forma de la solicitud y la respuesta para herramientas es específica del proveedor, al igual que la forma en que estrictamente se requiere que el modelo produzca argumentos válidos. Un esquema que un proveedor aplica puede ser consultivo en otro.
• Salida estructurada. Algunas plataformas admiten esquemas JSON obligatorios y otras solo los fomentan en la invitación. El código que analiza la respuesta sin un respaldo funciona hasta que no lo hace.
• Transmisión. Los límites de los bloques, los informes de uso y las señales de finalización difieren, y las diferencias se manifiestan como errores de renderizado intermitentes en lugar de excepciones.
• Filtrado de seguridad. Qué entradas y salidas están bloqueadas, y si el bloqueo es un error o una sustitución, varía. Un prototipo que nunca vio una negativa puede verlas con frecuencia en otro lugar.

Dos cambios a nivel de origen que facilitan la configuración de migración

Coloca un adaptador delante de la llamada al modelo. Un módulo que toma una forma de solicitud interna y devuelve una forma de respuesta interna, con una implementación por proveedor. El resto de la aplicación se escribe entonces contra tu forma, y agregar un proveedor es una nueva implementación en lugar de una edición en cuarenta lugares.

Hacer que la forma de la solicitud sea explícita y con versión. Campos para el modelo, el contexto, las herramientas, la longitud máxima de salida, la temperatura y el identificador de correlación — con la traducción específica del proveedor que ocurre dentro del adaptador. Un identificador de versión en la forma significa que un cambio en ella es un evento revisable en lugar de un refactor invisible.

Establecer estos antes de la primera solicitud de producción

• Manipulación de datos. Si se conservan las invitaciones y las salidas, durante cuánto tiempo y si se utilizan para mejorar los modelos del proveedor. Esta es una pregunta contractual con una respuesta escrita, y pertenece al paquete de seguridad.
• Límites de velocidad y cuotas. Los límites del proveedor en las regiones que se sirven, y el comportamiento de tu cliente cuando se alcanzan. Un cliente que vuelve a intentar en el límite de velocidad sin un presupuesto convierte un límite suave en un incidente de costo.
• Respaldo. Qué proveedor se utiliza cuando el principal se degrada, decidido de antemano, con el adaptador ya implementado. Un respaldo diseñado durante una interrupción es una segunda interrupción.
• Anclaje de versión de modelo. Si se ancla una versión de modelo o se sigue la última del proveedor, y quién revisa el cambio de comportamiento cuando el proveedor retira la versión anclada.
• Attribución de costos. Qué equipo paga, y cómo se etiqueta el uso para que la respuesta no sea una reconstrucción mensual a partir de registros.

Qué migrar primero

Migrar la ruta menos crítica primero — una herramienta interna, un trabajo por lotes, un punto final de bajo tráfico — y usarla para validar el adaptador, la contabilidad de tokens y el respaldo. El propósito es descubrir el comportamiento específico del proveedor en una carga de trabajo cuyo fracaso es barato, antes de que los mismos descubrimientos se hagan por parte de los clientes.