# Bagaimana Memigrasikan Batch Job Together AI Tanpa Kehilangan ID Permintaan? > Pertahankan setiap custom_id milik aplikasi dan simpan ID file, batch, serta respons dari kedua penyedia secara terpisah. Validasi seluruh himpunan ID sebelum pengiriman, gabungkan hasil dan kesalahan berdasarkan ID, serta catat percobaan tanpa mengubah kunci bisnis. Migrasikan batch job Together AI dengan memperlakukan setiap `custom_id` sumber sebagai data aplikasi yang tidak boleh berubah. Salin nilainya tanpa perubahan ke permintaan batch target, simpan ID batch dan respons dari penyedia target dalam field terpisah, lalu rekonsiliasikan hasil berdasarkan `custom_id`, bukan urutan file. Perbedaan pentingnya adalah antara pengenal milik aplikasi dan pengenal yang diterbitkan penyedia. Migrasi harus mempertahankan yang pertama dan memetakan yang kedua. ## Inventarisasi setiap pengenal Input batch Together berbentuk JSONL. Setiap baris memiliki `custom_id` unik dan body permintaan. Batch, file input, file output, dan respons individual dapat memiliki ID penyedia yang berbeda. | Pengenal | Pemilik | Aturan migrasi | |---|---|---| | `custom_id` | Aplikasi Anda | Pertahankan persis | | ID batch sumber | Together | Simpan sebagai metadata sumber | | ID batch target | Penyedia target | Simpan terpisah | | ID file input dan output | Setiap penyedia | Jangan gunakan sebagai kunci bisnis | | ID respons | API model | Simpan untuk dukungan dan penagihan | Jangan ganti `custom_id` dengan nomor baris kecuali nomor itu memang kunci persisten Anda. Urutan output dapat berbeda dan permintaan gagal dapat ditulis ke file kesalahan terpisah. ## Buat ledger migrasi Sebelum mengirim ke API target, buat satu baris ledger untuk setiap permintaan logis: ```json { "custom_id": "invoice-2026-00421", "source_batch_id": "batch_source", "target_batch_id": null, "payload_sha256": "...", "state": "prepared" } ``` Pastikan `custom_id` unik dalam set migrasi dan tambahkan hash body yang dinormalisasi. Hash mendeteksi perubahan tak disengaja tanpa menyimpan salinan data prompt sensitif di ledger. ## Konversikan envelope, bukan identitas Penyedia dapat memakai envelope batch berbeda. Together menempatkan `custom_id` di samping `body`; API batch kompatibel OpenAI lain mungkin juga memerlukan `method` dan `url`. ```json {"custom_id":"invoice-2026-00421","method":"POST","url":"/v1/chat/completions","body":{"model":"target-model","messages":[{"role":"user","content":"Classify this record"}]}} ``` Ubah endpoint, model ID, dan parameter yang tidak didukung melalui konverter. Teruskan `custom_id` sebagai string opak. Jangan memangkas, mengubah huruf, menerjemahkan, atau membuatnya ulang. ## Validasi sebelum pengiriman Jalankan empat pemeriksaan pada JSONL yang dihasilkan: * setiap baris dapat diurai sendiri; * setiap `custom_id` ada dan unik; * himpunan ID sama dengan manifest sumber; * setiap body lolos schema endpoint target. Catat hash dan jumlah baris file akhir. Unggah artefak itu, lalu hubungkan ID file dan batch target ke ledger. ## Rekonsiliasikan output dan kesalahan bersama Setelah batch target selesai, unduh artefak output dan kesalahan. Indeks setiap baris dengan `custom_id`, lalu bandingkan gabungannya dengan set yang dikirim. Klasifikasikan ID sebagai berhasil, gagal, hilang, atau duplikat. Batch selesai belum tentu telah direkonsiliasi. Jangan tutup migrasi sampai setiap ID memiliki tepat satu disposisi terminal. ## Coba ulang tanpa mengubah identitas Buat batch percobaan ulang yang hanya memuat permintaan gagal atau hilang. Pertahankan `custom_id` agar join tetap berfungsi, dan tambahkan `attempt` ke ledger alih-alih mengubah kunci bisnis. Jika target melarang ID digunakan ulang antarbatch, simpan nilai asli di field aplikasi dan buat ID transport dengan pemetaan reversibel. Jangan membuang pengenal asli. ## Lakukan cutover dengan aman Mulai dengan batch kecil yang representatif. Bandingkan keberhasilan, latensi, token, output model, kategori kesalahan, dan biaya. Simpan hasil sumber dan target berdampingan hingga rekonsiliasi deterministik. Otomatiskan tiga assertion: tidak ada ID asing, tidak ada hasil terminal duplikat, dan tidak ada ID hilang. Pemeriksaan ini lebih penting daripada urutan output. ## Intinya Pertahankan `custom_id` milik aplikasi, terjemahkan hanya envelope penyedia, dan gunakan ledger untuk memetakan artefak sumber dan target. Rekonsiliasikan file sukses dan gagal berdasarkan ID, catat percobaan, dan lakukan cutover hanya setelah semua permintaan memiliki hasil terminal. ## FAQ ### ID mana yang harus tetap stabil saat memigrasikan batch Together? Pertahankan custom_id yang ditetapkan aplikasi. ID batch, file, dan respons setiap penyedia harus menjadi metadata terpisah, bukan kunci bisnis. ### Bisakah hasil direkonsiliasi berdasarkan nomor baris? Tidak. Urutan keluaran dapat berubah dan permintaan gagal mungkin berada di file lain. Rekonsiliasikan gabungan hasil dan kesalahan menggunakan custom_id. ### Apa yang perlu disimpan dalam ledger migrasi? Simpan custom_id, hash payload ternormalisasi, ID batch dan file sumber serta target, nomor percobaan, waktu, dan tepat satu status terminal untuk setiap permintaan. ### Apakah percobaan ulang memerlukan custom_id baru? Biasanya tidak. Pertahankan pengenal bisnis dan naikkan attempt. Jika ID transport harus unik, simpan pemetaan yang dapat dikembalikan ke custom_id asli. ### Bagaimana mendeteksi permintaan yang hilang? Bandingkan himpunan ID yang dikirim dengan gabungan ID sukses dan gagal. Tandai ID yang hilang, asing, atau duplikat sebelum menutup rekonsiliasi. ### Bisakah file input Together digunakan tanpa perubahan? Hanya jika target menerima envelope, endpoint, model ID, dan parameter yang sama. Biasanya diperlukan konverter yang mempertahankan custom_id.