# ¿Cómo se migra un trabajo por lotes de Together AI sin perder los ID de solicitud? > Conserva sin cambios cada custom_id propiedad de la aplicación y guarda por separado los ID de archivos, lotes y respuestas de ambos proveedores. Valida el conjunto completo antes de enviar, une resultados y errores por ID y registra los reintentos sin cambiar la clave de negocio. Migra un trabajo por lotes de Together AI tratando cada `custom_id` de origen como un dato inmutable de la aplicación. Cópialo sin cambios en la solicitud de destino, guarda los ID de lote y respuesta del nuevo proveedor en campos separados y concilia los resultados por `custom_id`, no por el orden del archivo. La distinción importante es la que existe entre el identificador que controla tu aplicación y los identificadores emitidos por cada proveedor. La migración debe conservar el primero y asignar los demás. ## Haz un inventario de los identificadores La entrada por lotes de Together utiliza JSONL. Cada línea contiene un `custom_id` único y el cuerpo de la solicitud. El lote, el archivo de entrada, el archivo de salida y cada respuesta generada pueden tener ID de proveedor distintos. | Identificador | Propietario | Regla de migración | |---|---|---| | `custom_id` | Tu aplicación | Conservar exactamente | | ID del lote de origen | Together | Guardar como metadato de origen | | ID del lote de destino | Proveedor de destino | Guardar por separado | | ID de archivos de entrada y salida | Cada proveedor | No usar como claves de negocio | | ID de respuesta | API del modelo | Conservar para soporte y facturación | No sustituyas `custom_id` por el número de línea salvo que ese número ya fuese una clave duradera. El orden de salida puede cambiar y las solicitudes fallidas pueden escribirse en otro archivo. ## Crea un registro de migración Antes de enviar nada a la API de destino, crea una fila por solicitud lógica: ```json { "custom_id": "invoice-2026-00421", "source_batch_id": "batch_source", "target_batch_id": null, "payload_sha256": "...", "state": "prepared" } ``` Haz que `custom_id` sea único dentro del conjunto y añade un hash del cuerpo normalizado. El hash detecta cambios accidentales sin guardar otra copia de datos sensibles en el registro. ## Convierte el sobre, no la identidad Los proveedores pueden usar sobres distintos. Los ejemplos de Together colocan `custom_id` junto a `body`, mientras que otra API por lotes compatible con OpenAI también puede exigir `method` y `url`. ```json {"custom_id":"invoice-2026-00421","method":"POST","url":"/v1/chat/completions","body":{"model":"target-model","messages":[{"role":"user","content":"Classify this record"}]}} ``` Cambia el endpoint, el modelo y los parámetros no admitidos mediante un conversor. Transmite el `custom_id` de origen como cadena opaca: no lo recortes, cambies de mayúsculas, traduzcas ni regeneres. ## Valida antes de enviar Ejecuta cuatro comprobaciones sobre el JSONL generado: * cada línea se analiza de forma independiente; * todos los `custom_id` existen y son únicos; * el conjunto de ID coincide con el manifiesto de origen; * cada cuerpo cumple el schema del endpoint de destino. Registra el hash y el número de líneas del archivo final. Sube exactamente ese artefacto y vincula los ID de archivo y lote devueltos al registro de migración. ## Concilia conjuntamente salidas y errores Cuando finalice el lote, descarga tanto la salida como los errores. Indexa cada fila por `custom_id` y compara su unión con el conjunto enviado. Clasifica cada ID como correcto, fallido, ausente o duplicado. Que un lote esté completado no implica que esté conciliado. No cierres la migración hasta que cada ID tenga exactamente una disposición terminal. ## Reintenta sin cambiar la identidad Crea un lote nuevo solo con las solicitudes fallidas o ausentes. Conserva el mismo `custom_id` para que las uniones posteriores sigan funcionando y añade un campo `attempt` al registro, en lugar de cambiar la clave de negocio. Si el destino prohíbe reutilizar ID entre lotes, conserva el valor original en un campo propio y genera un ID de transporte con una asignación reversible. Nunca descartes el identificador original. ## Cambia el tráfico de forma segura Empieza con un lote pequeño y representativo. Compara éxito, latencia, uso de tokens, resultados, errores y coste. Mantén las tablas de origen y destino en paralelo hasta que la conciliación sea determinista. Automatiza tres aserciones: ningún ID desconocido, ningún resultado terminal duplicado y ningún ID ausente. Son más importantes que conservar el orden de salida. ## En resumen Conserva el `custom_id` de la aplicación, convierte únicamente el sobre del proveedor y mantén un registro que asigne los artefactos de origen y destino. Concilia resultados y errores por ID, registra los reintentos como intentos y cambia el tráfico solo cuando todas las solicitudes tengan estado terminal. ## FAQ ### ¿Qué ID debe mantenerse estable durante una migración por lotes de Together? Conserva el custom_id asignado por tu aplicación. Los ID de lote, archivo y respuesta de cada proveedor deben almacenarse como metadatos separados, no como clave de negocio. ### ¿Puedo conciliar los resultados por número de línea? No. El orden de salida puede ser distinto y las solicitudes fallidas pueden aparecer en otro archivo. Concilia la unión de resultados y errores mediante custom_id. ### ¿Qué debe contener el registro de migración? Guarda custom_id, un hash de la carga normalizada, los ID de lote y archivo de origen y destino, el número de intento, marcas de tiempo y un único estado terminal por solicitud. ### ¿Un reintento debe recibir un custom_id nuevo? Normalmente no. Mantén estable el identificador de negocio e incrementa el intento. Si el ID de transporte debe ser único, conserva una asignación reversible al custom_id original. ### ¿Cómo detecto solicitudes perdidas? Compara los ID enviados con la unión de los ID de éxito y error. Marca cualquier ID ausente, desconocido o duplicado antes de completar la conciliación. ### ¿Puedo reutilizar sin cambios un archivo de entrada de Together? Solo si el destino acepta el mismo sobre, endpoint, modelo y parámetros. La mayoría de migraciones necesita un conversor que mantenga intacto custom_id.