La compatibilidad define la forma; el contrato define la conducta
Un formato común de entrada y salida reduce el trabajo del cliente y permite cambiar de modelo o proveedor con menos modificaciones. También puede concentrar el acceso en una interfaz. Pero tener los mismos campos no indica si se aceptó una solicitud, qué proveedor la ejecutó, cuándo se puede reintentar, cómo se clasifica una respuesta parcial ni cómo se concilia el consumo final. Cuando una persona depende del sistema, esas preguntas pasan a formar parte del contrato del producto.
Por eso, una pasarela debe delimitar validación, política y elegibilidad, selección de ruta, ejecución, clasificación del resultado y prueba del consumo. Son responsabilidades de diseño, no una afirmación de que todas las pasarelas las implementen igual. Una comunicación HTTP correcta no demuestra que el trabajo haya concluido. A la inversa, el cliente puede perder la respuesta después de que el proveedor ya haya trabajado. Llamar «error» a ambos casos oculta la decisión que realmente debe tomar el operador.
Un flujo es una secuencia de pruebas, no una única respuesta
La transmisión en flujo permite mostrar texto mientras el modelo todavía lo genera. El flujo HTTP documentado por OpenAI, por ejemplo, utiliza eventos enviados por el servidor y distingue incrementos de texto de un evento de finalización. La aplicación puede mostrar un comienzo útil antes de saber si la respuesta ha terminado. Si recibe dos párrafos y luego la conexión caduca, el texto visible no demuestra que la operación se completó. [2]
La pasarela debería conservar lo que sabe: identidad de la solicitud, ruta elegida, aceptación por el proveedor, eventos observados y confirmación o ausencia de finalización. La respuesta parcial visible debe distinguirse de un resultado final. Es una recomendación arquitectónica, no la promesa de que cualquier proveedor permita reanudar un flujo. El sistema puede mostrar el resultado incompleto, pedir una nueva decisión al cliente o consultar un registro del proveedor si existe. Lo esencial es nombrar la incertidumbre en vez de convertirla silenciosamente en éxito o fracaso.
Antes de reintentar, considere el trabajo duplicado
Imagine una solicitud de redacción explícitamente ilustrativa. El proveedor empieza a enviar texto; la aplicación recibe dos párrafos y pierde la conexión por tiempo de espera. El proveedor podría seguir generando y cobrar por lo realizado. Si la aplicación repite el mismo prompt de inmediato, podría producir una segunda generación y un segundo coste, aunque muestre una sola respuesta. El tiempo de espera no prueba que el primer intento nunca ocurrió. La documentación de Chat Completions de OpenAI también advierte que una interrupción puede impedir recibir el bloque final con el consumo total. [3]
La semántica de HTTP precisa el riesgo: no se debe reintentar automáticamente una operación no idempotente salvo que se conozca su semántica idempotente o se sepa que la primera no se aplicó; un proxy no debe hacerlo. Muchas generaciones se solicitan mediante POST, así que la forma del endpoint no basta para decidir. [1] Una política puede permitir reintentos antes del envío, usar una garantía de idempotencia ofrecida por el proveedor o exigir un intento nuevo y explícito tras un flujo ambiguo. Se intercambian rapidez y comodidad por riesgo de duplicación y coste incierto.
Decidir si se permite ejecutar antes de elegir dónde
El enrutamiento decide dónde ejecutar una solicitud apta; la política decide si puede ejecutarse y con qué límites. El trabajo puede exigir una modalidad, longitud de contexto, región, lista de proveedores autorizados, permisos de herramientas o techo de gasto. Si el proveedor preferido falla, una alternativa solo sirve si sigue cumpliendo esas condiciones. Cambiar sin aviso a una ruta no autorizada altera el acuerdo con la aplicación.
Un flujo ilustrativo sería: validar la solicitud → evaluar política y presupuesto → elegir una ruta apta → ejecutar con plazo → clasificar el resultado → registrar el consumo observado → emitir el evento de facturación en el sistema propio del producto. No describe componentes de RouterShift ya publicados. La ruta, la recuperación y la contabilidad deben poder explicarse por separado. Una regla determinista facilita la auditoría; la selección adaptativa puede ayudar con datos fiables, pero exige explicar cada elección.
Medir lo observado antes de convertirlo en dinero
Una solicitud, un intento y el registro final de consumo del proveedor son hechos distintos. Tras un flujo interrumpido puede faltar el dato final: contar solo el texto visible no justifica presentar una cifra como cargo definitivo. Conviene guardar el registro original, la identidad del intento y la base de cualquier estimación. Cuando llegue el dato autorizado, se puede conciliar; las correcciones deben dejar rastro. [3]
Las convenciones actuales de OpenTelemetry para IA generativa nombran tokens de entrada y salida, modelo, proveedor y tipos de error. Son un vocabulario de telemetría, no un sistema de facturación ni una garantía de unidades idénticas entre proveedores. También advierten que registrar mensajes puede revelar información sensible. [4] Precio y movimiento de saldo vienen después de la medición, con moneda, versión de tarifa y trazabilidad propios. Imagen, audio y vídeo pueden requerir unidades distintas de los tokens.
Hacer visible el contrato en la operación cotidiana
Ante un incidente, el equipo necesita responder: ¿qué solicitud se vio afectada?, ¿qué ruta se escogió y por qué?, ¿aceptó el proveedor el trabajo?, ¿la salida está completa?, ¿qué consumo está confirmado, estimado o desconocido?, ¿qué versión de política y precio se aplicó? Identificadores de solicitud e intento, estados y enlaces a trazas permiten responder sin registrar el contenido del prompt por defecto. La interfaz debe servir a quienes operan el producto, no solo a quienes lo programan.
Estas preguntas también prueban las promesas de una pasarela. Si el fallo ocurre antes del envío, otra ruta apta puede ser viable. Si el flujo se corta después de empezar, hay que indicar el resultado incompleto o incierto y las opciones siguientes. Si falta consumo, se debe mantener pendiente hasta conciliarlo. La compatibilidad reduce el coste inicial; el contrato de producción vuelve previsible la conducta fuera del caso ideal. RouterShift es el producto activo de SlateMoth para acceso a modelos. Este marco explica el problema de diseño; no afirma que cada mecanismo descrito ya forme parte de RouterShift.