# จะย้ายงานแบตช์ของ Together AI โดยไม่ทำ ID คำขอสูญหายได้อย่างไร > รักษา custom_id ที่แอปพลิเคชันเป็นเจ้าของไว้ตามเดิม และเก็บ ID ไฟล์ แบตช์ และการตอบกลับของผู้ให้บริการแต่ละรายแยกกัน ตรวจสอบชุด ID ก่อนส่ง จับคู่ผลลัพธ์และข้อผิดพลาดด้วย ID และบันทึกครั้งที่ลองโดยไม่เปลี่ยนคีย์ธุรกิจ ย้ายงานแบตช์ของ Together AI โดยถือว่า `custom_id` จากต้นทางทุกค่าเป็นข้อมูลแอปพลิเคชันที่เปลี่ยนไม่ได้ คัดลอกค่าเดิมไปยังคำขอแบตช์ของปลายทาง เก็บ ID แบตช์และการตอบกลับของผู้ให้บริการปลายทางในฟิลด์แยก และกระทบยอดผลลัพธ์ด้วย `custom_id` แทนลำดับไฟล์ ความแตกต่างสำคัญอยู่ระหว่างตัวระบุที่แอปพลิเคชันเป็นเจ้าของกับตัวระบุที่ผู้ให้บริการแต่ละรายออกให้ การย้ายต้องรักษาประเภทแรกและแมปประเภทหลังแยกกัน ## สำรวจตัวระบุทั้งหมด อินพุตแบตช์ของ Together เป็น JSONL แต่ละบรรทัดมี `custom_id` ที่ไม่ซ้ำและส่วนเนื้อหาคำขอ ตัวแบตช์ ไฟล์อินพุตที่อัปโหลด ไฟล์เอาต์พุต และการตอบกลับแต่ละรายการอาจมี ID ผู้ให้บริการคนละค่า | ตัวระบุ | เจ้าของ | กฎการย้าย | |---|---|---| | `custom_id` | แอปพลิเคชันของคุณ | คงไว้เหมือนเดิมทุกประการ | | ID แบตช์ต้นทาง | Together | เก็บเป็นข้อมูลเมตาต้นทาง | | ID แบตช์ปลายทาง | ผู้ให้บริการปลายทาง | เก็บแยกต่างหาก | | ID ไฟล์อินพุตและเอาต์พุต | ผู้ให้บริการแต่ละราย | ห้ามใช้เป็นคีย์ธุรกิจ | | ID การตอบกลับ | API โมเดล | เก็บไว้เพื่อการสนับสนุนและการเรียกเก็บเงิน | อย่าแทน `custom_id` ด้วยหมายเลขบรรทัด เว้นแต่หมายเลขนั้นเป็นคีย์ถาวรอยู่แล้ว ลำดับเอาต์พุตอาจต่างจากอินพุต และคำขอที่ล้มเหลวอาจถูกเขียนลงไฟล์ข้อผิดพลาดแยก ## สร้างสมุดบัญชีการย้าย ก่อนส่งสิ่งใดไปยัง API ปลายทาง ให้สร้างหนึ่งแถวต่อคำขอเชิงตรรกะ: ```json { "custom_id": "invoice-2026-00421", "source_batch_id": "batch_source", "target_batch_id": null, "payload_sha256": "...", "state": "prepared" } ``` ทำให้ `custom_id` ไม่ซ้ำภายในชุดการย้าย และเพิ่มแฮชของเนื้อหาคำขอที่ทำให้เป็นมาตรฐาน แฮชช่วยตรวจจับการแก้ไขโดยไม่ตั้งใจโดยไม่ต้องเก็บสำเนาข้อมูล prompt ที่อ่อนไหวอีกชุดในสมุดบัญชี ## แปลง envelope ไม่ใช่ตัวตน ผู้ให้บริการอาจใช้ envelope แบตช์ต่างกัน ตัวอย่างของ Together วาง `custom_id` ไว้ข้าง `body` ส่วน API แบตช์ที่เข้ากันได้กับ OpenAI อาจต้องการ `method` และ `url` ด้วย ```json {"custom_id":"invoice-2026-00421","method":"POST","url":"/v1/chat/completions","body":{"model":"target-model","messages":[{"role":"user","content":"Classify this record"}]}} ``` เปลี่ยน endpoint, model ID และพารามิเตอร์ที่ไม่รองรับผ่านตัวแปลง ส่งต่อ `custom_id` ต้นทางเป็นสตริงทึบ ห้ามตัดช่องว่าง เปลี่ยนเป็นตัวพิมพ์เล็ก แปล หรือสร้างใหม่ ## ตรวจสอบก่อนส่ง ตรวจสอบไฟล์ JSONL ที่สร้างขึ้นสี่ข้อ: * ทุกบรรทัดแยกวิเคราะห์ได้อย่างอิสระ; * ทุก `custom_id` มีอยู่และไม่ซ้ำ; * ชุด ID ตรงกับ manifest ต้นทาง; * ทุกเนื้อหาผ่าน schema ของ endpoint ปลายทาง บันทึกแฮชและจำนวนบรรทัดของไฟล์สุดท้าย อัปโหลด artifact นั้นโดยตรง แล้วแนบ ID ไฟล์และแบตช์ที่ปลายทางส่งคืนไปยังสมุดบัญชีการย้าย ## กระทบยอดผลลัพธ์และข้อผิดพลาดร่วมกัน เมื่อแบตช์ปลายทางเสร็จ ให้ดาวน์โหลดทั้ง artifact ผลลัพธ์และข้อผิดพลาด ทำดัชนีทุกแถวด้วย `custom_id` แล้วเปรียบเทียบผลรวมกับชุดที่ส่ง จัดประเภทแต่ละ ID เป็นสำเร็จ ล้มเหลว ขาด หรือซ้ำ แบตช์ที่เสร็จแล้วไม่ได้หมายความว่ากระทบยอดครบ อย่าปิดการย้ายจนกว่า ID ทุกค่าที่ส่งจะมีสถานะปลายทางเพียงหนึ่งรายการ ## ลองใหม่โดยไม่เปลี่ยนตัวตน สร้างแบตช์ลองใหม่ที่มีเฉพาะคำขอที่ล้มเหลวหรือขาด คง `custom_id` เดิมเพื่อให้การ join ปลายทางยังทำงาน และเพิ่มฟิลด์ `attempt` ในสมุดบัญชีแทนการเปลี่ยนคีย์ธุรกิจ หากปลายทางห้ามใช้ ID ซ้ำข้ามแบตช์ ให้เก็บค่าต้นฉบับในฟิลด์แอปพลิเคชันเฉพาะ และสร้าง ID สำหรับขนส่งพร้อมการแมปที่ย้อนกลับได้ ห้ามทิ้งตัวระบุต้นฉบับ ## เปลี่ยนระบบอย่างปลอดภัย เริ่มด้วยแบตช์ขนาดเล็กที่เป็นตัวแทน เปรียบเทียบอัตราความสำเร็จ เวลาแฝง การใช้โทเค็น ผลลัพธ์โมเดล หมวดข้อผิดพลาด และต้นทุน เก็บตารางผลลัพธ์ต้นทางและปลายทางคู่กันจนกว่าการกระทบยอดจะกำหนดผลได้ เมื่อกระบวนการทำงาน ให้ทำ assertion สามข้ออัตโนมัติ: ไม่มี ID ที่ไม่รู้จัก ไม่มีผลลัพธ์ปลายทางซ้ำ และไม่มี ID ขาด การตรวจเหล่านี้สำคัญกว่าการให้ลำดับผลลัพธ์ตรงกัน ## สรุป รักษา `custom_id` ที่แอปพลิเคชันเป็นเจ้าของ แปลงเฉพาะ envelope ของผู้ให้บริการ และใช้สมุดบัญชีแมป artifact แบตช์ต้นทางกับปลายทาง กระทบยอดไฟล์สำเร็จและผิดพลาดด้วย ID บันทึกครั้งที่ลอง และเปลี่ยนระบบเมื่อทุกคำขอมีผลลัพธ์ปลายทางแล้วเท่านั้น ## FAQ ### ID ใดต้องคงที่เมื่อย้ายแบตช์ของ Together ให้คง custom_id ที่แอปพลิเคชันกำหนดไว้ ส่วน ID แบตช์ ไฟล์ และการตอบกลับของผู้ให้บริการแต่ละรายควรเป็นข้อมูลเมตาแยกต่างหาก ไม่ใช่คีย์ธุรกิจ ### กระทบยอดผลลัพธ์ด้วยหมายเลขบรรทัดได้หรือไม่ ไม่ได้ ลำดับผลลัพธ์อาจเปลี่ยนและคำขอที่ล้มเหลวอาจอยู่ในไฟล์อื่น ให้กระทบยอดผลรวมของผลลัพธ์และข้อผิดพลาดด้วย custom_id ### สมุดบัญชีการย้ายควรเก็บอะไร เก็บ custom_id แฮชของเพย์โหลดที่ทำให้เป็นมาตรฐาน ID แบตช์และไฟล์ต้นทางกับปลายทาง หมายเลขครั้งที่ลอง เวลา และสถานะปลายทางหนึ่งรายการต่อคำขอ ### การลองใหม่ต้องใช้ custom_id ใหม่หรือไม่ โดยทั่วไปไม่ต้อง ให้คงตัวระบุธุรกิจและเพิ่ม attempt หาก ID สำหรับส่งต้องไม่ซ้ำ ให้เก็บการแมปที่ย้อนกลับไปยัง custom_id เดิมได้ ### จะตรวจพบคำขอที่หายไปได้อย่างไร เปรียบเทียบชุด ID ที่ส่งกับผลรวมของ ID ที่สำเร็จและผิดพลาด แล้วทำเครื่องหมาย ID ที่ขาด ไม่รู้จัก หรือซ้ำก่อนปิดการกระทบยอด ### ใช้ไฟล์อินพุตของ Together เดิมได้เลยหรือไม่ ได้เฉพาะเมื่อปลายทางยอมรับ envelope, endpoint, model ID และพารามิเตอร์แบบเดียวกัน โดยทั่วไปต้องมีตัวแปลงที่คง custom_id ไว้