# Làm thế nào để di chuyển tác vụ batch Together AI mà không mất ID yêu cầu? > Giữ nguyên mọi custom_id thuộc ứng dụng và lưu riêng ID tệp, batch và phản hồi của hai nhà cung cấp. Xác thực toàn bộ tập ID trước khi gửi, ghép kết quả và lỗi theo ID, đồng thời ghi nhận lần thử mà không đổi khóa nghiệp vụ. Hãy di chuyển tác vụ batch Together AI bằng cách coi mọi `custom_id` nguồn là dữ liệu bất biến thuộc ứng dụng. Sao chép nguyên giá trị đó vào yêu cầu batch của đích, lưu ID batch và ID phản hồi do nhà cung cấp đích cấp trong các trường riêng, rồi đối soát kết quả bằng `custom_id` thay vì thứ tự dòng. Điểm quan trọng là phân biệt định danh do ứng dụng sở hữu với định danh do từng nhà cung cấp cấp. Quá trình di chuyển phải giữ nguyên loại thứ nhất và ánh xạ riêng loại thứ hai. ## Kiểm kê mọi định danh Đầu vào batch của Together là JSONL. Mỗi dòng có một `custom_id` duy nhất và một phần thân yêu cầu. Bản thân batch, tệp đầu vào đã tải lên, tệp đầu ra và từng phản hồi được tạo có thể đều có ID nhà cung cấp riêng. | Định danh | Chủ sở hữu | Quy tắc di chuyển | |---|---|---| | `custom_id` | Ứng dụng của bạn | Giữ nguyên tuyệt đối | | ID batch nguồn | Together | Lưu dưới dạng siêu dữ liệu nguồn | | ID batch đích | Nhà cung cấp đích | Lưu riêng | | ID tệp đầu vào và đầu ra | Từng nhà cung cấp | Không bao giờ dùng làm khóa nghiệp vụ | | ID phản hồi | API mô hình | Giữ lại để hỗ trợ và đối chiếu chi phí | Không thay `custom_id` bằng số dòng trừ khi số dòng vốn đã là khóa bền vững của bạn. Thứ tự đầu ra có thể khác đầu vào và yêu cầu thất bại có thể được ghi vào một tệp lỗi riêng. ## Tạo sổ cái di chuyển Trước khi gửi dữ liệu đến API đích, hãy tạo một dòng sổ cái cho mỗi yêu cầu logic: ```json { "custom_id": "invoice-2026-00421", "source_batch_id": "batch_source", "target_batch_id": null, "payload_sha256": "...", "state": "prepared" } ``` Bảo đảm `custom_id` là duy nhất trong tập di chuyển và thêm hash của phần thân yêu cầu đã chuẩn hóa. Hash giúp phát hiện chỉnh sửa ngoài ý muốn mà không cần lưu thêm một bản sao dữ liệu prompt nhạy cảm trong sổ cái. ## Chuyển đổi envelope, không đổi định danh Các nhà cung cấp có thể dùng envelope batch khác nhau. Ví dụ của Together đặt `custom_id` cạnh `body`; một API batch tương thích OpenAI khác còn có thể yêu cầu `method` và `url`. ```json {"custom_id":"invoice-2026-00421","method":"POST","url":"/v1/chat/completions","body":{"model":"target-model","messages":[{"role":"user","content":"Classify this record"}]}} ``` Dùng bộ chuyển đổi để thay endpoint, model ID và tham số không được hỗ trợ. Chuyển nguyên `custom_id` nguồn như một chuỗi bất khả tri. Không cắt khoảng trắng, đổi chữ thường, dịch hoặc tạo lại giá trị này. ## Xác thực trước khi gửi Chạy bốn kiểm tra trên tệp JSONL đã tạo: * mỗi dòng được phân tích độc lập thành công; * mọi `custom_id` đều có mặt và duy nhất; * tập ID khớp với manifest nguồn; * mọi phần thân đều đạt schema của endpoint đích. Ghi lại hash và số dòng của tệp cuối. Tải lên đúng artifact đó, rồi gắn ID tệp và batch mà đích trả về vào sổ cái di chuyển. ## Đối soát chung đầu ra và lỗi Khi batch đích hoàn tất, hãy tải cả artifact đầu ra lẫn artifact lỗi. Lập chỉ mục từng dòng theo `custom_id`, rồi so sánh hợp của chúng với tập đã gửi. Phân loại từng ID thành thành công, thất bại, thiếu hoặc trùng. Một batch đã hoàn tất chưa chắc đã được đối soát đầy đủ. Không đánh dấu di chuyển hoàn tất cho đến khi mọi ID đã gửi có đúng một trạng thái cuối. ## Thử lại mà không đổi định danh Tạo một batch thử lại mới chỉ gồm các yêu cầu thất bại hoặc thiếu. Giữ nguyên `custom_id` để các phép nối phía sau vẫn hoạt động, đồng thời thêm trường `attempt` vào sổ cái thay vì thay khóa nghiệp vụ. Nếu đích cấm dùng lại ID giữa các batch, hãy giữ giá trị gốc trong một trường ứng dụng riêng và tạo ID vận chuyển với ánh xạ có thể đảo. Không bao giờ bỏ định danh gốc. ## Chuyển lưu lượng an toàn Bắt đầu với một batch nhỏ nhưng đại diện. So sánh tỷ lệ thành công, độ trễ, mức dùng token, đầu ra mô hình, loại lỗi và chi phí. Giữ bảng kết quả nguồn và đích cạnh nhau cho đến khi việc đối soát có tính xác định. Khi quy trình hoạt động, hãy tự động hóa ba assertion: không có ID lạ, không có kết quả cuối trùng và không thiếu ID. Các kiểm tra này quan trọng hơn việc khớp thứ tự đầu ra. ## Kết luận Giữ nguyên `custom_id` thuộc ứng dụng, chỉ chuyển đổi envelope của nhà cung cấp và duy trì sổ cái ánh xạ artifact batch nguồn và đích. Đối soát cả tệp thành công lẫn tệp lỗi theo ID, ghi nhận lần thử và chỉ chuyển hoàn toàn khi mọi yêu cầu đã gửi đều có trạng thái cuối. ## FAQ ### ID nào phải giữ ổn định khi di chuyển batch Together? Giữ custom_id do ứng dụng cấp. ID batch, tệp và phản hồi của từng nhà cung cấp phải là siêu dữ liệu riêng, không phải khóa nghiệp vụ. ### Có thể đối soát kết quả theo số dòng không? Không. Thứ tự đầu ra có thể đổi và yêu cầu lỗi có thể nằm trong tệp khác. Hãy đối soát hợp của kết quả và lỗi bằng custom_id. ### Sổ cái di chuyển cần chứa gì? Lưu custom_id, hash payload chuẩn hóa, ID batch và tệp nguồn cùng đích, số lần thử, thời gian và đúng một trạng thái cuối cho mỗi yêu cầu. ### Lần thử lại có cần custom_id mới không? Thường là không. Giữ định danh nghiệp vụ và tăng attempt. Nếu ID vận chuyển phải duy nhất, hãy lưu ánh xạ có thể đảo về custom_id gốc. ### Làm sao phát hiện yêu cầu bị mất? So sánh tập ID đã gửi với hợp các ID thành công và lỗi. Đánh dấu ID thiếu, lạ hoặc trùng trước khi hoàn tất đối soát. ### Có thể dùng lại nguyên tệp đầu vào Together không? Chỉ khi đích chấp nhận cùng envelope, endpoint, model ID và tham số. Thường cần bộ chuyển đổi giữ nguyên custom_id.