# Comment migrer un traitement par lot Together AI sans perdre les identifiants de requête ? > Conservez chaque custom_id applicatif à l'identique et stockez séparément les identifiants de fichier, de lot et de réponse des deux fournisseurs. Validez l'ensemble avant l'envoi, rapprochez sorties et erreurs par ID et consignez les reprises sans modifier la clé métier. Migrez un traitement par lot Together AI en considérant chaque `custom_id` source comme une donnée applicative immuable. Copiez-le sans modification dans la requête cible, stockez les ID de lot et de réponse du nouveau fournisseur dans des champs séparés et rapprochez les résultats par `custom_id`, jamais selon l'ordre du fichier. La distinction essentielle sépare l'identifiant détenu par l'application de ceux émis par les fournisseurs. Le premier doit être préservé et les autres mis en correspondance. ## Inventorier tous les identifiants L'entrée par lot Together utilise JSONL. Chaque ligne contient un `custom_id` unique et le corps de la requête. Le lot, le fichier d'entrée, le fichier de sortie et chaque réponse peuvent avoir des ID distincts. | Identifiant | Propriétaire | Règle de migration | |---|---|---| | `custom_id` | Votre application | Conserver exactement | | ID du lot source | Together | Stocker comme métadonnée source | | ID du lot cible | Fournisseur cible | Stocker séparément | | ID des fichiers | Chaque fournisseur | Ne jamais utiliser comme clé métier | | ID de réponse | API du modèle | Conserver pour le support et la facturation | Ne remplacez pas `custom_id` par le numéro de ligne, sauf si ce dernier est déjà votre clé durable. L'ordre de sortie peut changer et les échecs peuvent être écrits dans un fichier séparé. ## Créer un registre de migration Avant tout envoi vers la cible, créez une ligne par requête logique : ```json { "custom_id": "invoice-2026-00421", "source_batch_id": "batch_source", "target_batch_id": null, "payload_sha256": "...", "state": "prepared" } ``` Rendez `custom_id` unique dans le jeu et ajoutez un hachage du corps normalisé. Il détecte les modifications accidentelles sans stocker une seconde copie du contenu sensible. ## Convertir l'enveloppe, pas l'identité Les enveloppes peuvent différer. Les exemples Together placent `custom_id` à côté de `body`, alors qu'une autre API par lot compatible avec OpenAI peut aussi exiger `method` et `url`. ```json {"custom_id":"invoice-2026-00421","method":"POST","url":"/v1/chat/completions","body":{"model":"target-model","messages":[{"role":"user","content":"Classify this record"}]}} ``` Modifiez l'endpoint, le modèle et les paramètres incompatibles dans un convertisseur. Transmettez le `custom_id` source comme une chaîne opaque, sans le raccourcir, en changer la casse, le traduire ni le régénérer. ## Valider avant l'envoi Effectuez quatre contrôles sur le JSONL généré : * chaque ligne peut être analysée seule ; * tous les `custom_id` existent et sont uniques ; * l'ensemble des ID correspond au manifeste source ; * chaque corps respecte le schema de l'endpoint cible. Enregistrez le hachage et le nombre de lignes du fichier final. Envoyez exactement cet artefact et rattachez au registre les ID retournés. ## Rapprocher ensemble sorties et erreurs Une fois le lot terminé, téléchargez les sorties et les erreurs. Indexez chaque ligne par `custom_id` et comparez leur union à l'ensemble envoyé. Classez chaque ID comme réussi, en échec, absent ou dupliqué. Un lot terminé n'est pas nécessairement rapproché. Ne clôturez que lorsque chaque ID possède exactement un résultat terminal. ## Reprendre sans changer d'identité Créez un nouveau lot contenant uniquement les requêtes absentes ou en échec. Gardez le même `custom_id` et incrémentez `attempt` dans le registre au lieu de changer la clé métier. Si la cible interdit de réutiliser un ID, conservez l'original dans un champ applicatif et générez un ID de transport associé de façon réversible. ## Basculer en toute sécurité Commencez par un lot réduit et représentatif. Comparez réussite, latence, tokens, sorties, erreurs et coût. Conservez les résultats source et cible en parallèle jusqu'à obtenir un rapprochement déterministe. Automatisez trois assertions : aucun ID inconnu, aucun résultat terminal dupliqué et aucun ID absent. ## En résumé Préservez le `custom_id` applicatif, ne convertissez que l'enveloppe du fournisseur et maintenez un registre des artefacts. Rapprochez sorties et erreurs par ID, consignez les reprises comme tentatives et ne basculez que lorsque toutes les requêtes ont un résultat terminal. ## FAQ ### Quel identifiant doit rester stable pendant une migration de lot Together ? Conservez le custom_id attribué par l'application. Les identifiants de lot, de fichier et de réponse de chaque fournisseur restent des métadonnées séparées, pas la clé métier. ### Peut-on rapprocher les résultats par numéro de ligne ? Non. L'ordre de sortie peut changer et les échecs peuvent figurer dans un autre fichier. Rapprochez l'union des sorties et des erreurs avec custom_id. ### Que doit contenir le registre de migration ? Stockez custom_id, le hachage de la charge normalisée, les ID de lot et de fichier source et cible, le numéro de tentative, les horodatages et un état terminal unique. ### Une reprise doit-elle recevoir un nouveau custom_id ? En général, non. Gardez l'identifiant métier et incrémentez attempt. Si l'ID de transport doit être unique, conservez une correspondance réversible vers le custom_id d'origine. ### Comment détecter les requêtes perdues ? Comparez les ID envoyés avec l'union des ID réussis et en erreur. Signalez tout ID absent, inconnu ou en double avant de terminer le rapprochement. ### Peut-on réutiliser tel quel un fichier d'entrée Together ? Seulement si la cible accepte la même enveloppe, le même endpoint, le même modèle et les mêmes paramètres. Sinon, utilisez un convertisseur qui préserve custom_id.