<!-- Canonical URL: https://ask.atlascloud.ai/zh-TW/migrate-together-ai-batch-job-without-losing-request-ids -->

# 如何在不遺失請求 ID 的情況下遷移 Together AI 批次處理工作？

> 保持應用程式擁有的 custom_id 不變，把 Together 與目標服務商的檔案、批次和回應 ID 存入獨立欄位。提交前驗證完整 ID 集合，按 ID 合併成功與錯誤輸出，並透過嘗試次數帳本重試而不改變業務主鍵。

遷移 Together AI 批次處理工作時，應把每個來源 `custom_id` 當作不可變的應用程式資料。將它原樣寫入目標批次處理請求，把目標服務商的批次 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` 在遷移集合中唯一，並記錄標準化請求正文的雜湊。雜湊可發現意外修改，又不必在帳本裡保存第二份敏感提示詞。

## 轉換封裝，不改變身分

不同服務商的批次處理封裝可能不同。Together 範例把 `custom_id` 與 `body` 並列，另一個 OpenAI 相容批次處理 API 還可能要求 `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"}]}}
```

透過轉換器修改端點、模型 ID 和不支援的參數，但應把來源 `custom_id` 當作不透明字串原樣傳遞，不要裁剪、改小寫、翻譯或重新生成。

## 提交前驗證

對生成的 JSONL 執行四項檢查：

* 每行都能獨立解析；
* 每個 `custom_id` 都存在且唯一；
* ID 集合與來源清單一致；
* 每個正文都符合目標端點的 schema。

記錄最終檔案雜湊和行數，只上傳該成品，再把返回的目標檔案 ID 與批次 ID 寫入遷移帳本。

## 同時核對輸出與錯誤

目標批次結束後，下載輸出成品和錯誤成品。以 `custom_id` 為每行建立索引，並將兩者聯集與已提交集合比較。

把每個 ID 標記為成功、失敗、遺失或重複。批次狀態為完成，並不代表已經完全核對。只有每個已提交 ID 都恰好有一個終態，遷移才算完成。

## 重試時不要改變身分

僅用失敗或遺失請求建立新重試批次。保留相同 `custom_id`，讓下游關聯繼續有效，並在帳本中增加 `attempt`，而不是修改業務主鍵。

如果目標服務商禁止跨批次重複傳輸 ID，應把原值保存在專用應用程式欄位，並生成具有可逆對應的傳輸 ID，絕不能丟棄原始識別碼。

## 安全切換

先使用一個小而有代表性的批次，比較成功率、延遲、權杖用量、模型輸出、錯誤類別與成本。在核對過程穩定前，並排保留來源與目標結果表。

隨後自動執行三項斷言：沒有未知 ID、沒有重複終態、沒有遺失 ID。這些檢查比比對輸出順序更重要。

## 總結

保留應用程式擁有的 `custom_id`，只轉換服務商封裝，並用帳本對應來源端和目標端的批次處理成品。按 ID 合併成功與失敗結果，以嘗試次數記錄重試，且只有所有請求都有終態後才切換。

## FAQ

### 遷移 Together 批次處理時，哪個 ID 必須保持不變？

保留應用程式分配的 custom_id。Together 和目標服務商的批次、檔案與回應 ID 應作為獨立中繼資料保存，不能取代業務主鍵。

### 可以按行號核對批次處理結果嗎？

不可以。輸出順序可能與輸入不同，失敗請求也可能出現在單獨檔案中。應按 custom_id 核對輸出與錯誤記錄的聯集。

### 遷移帳本應包含什麼？

應保存 custom_id、標準化承載內容雜湊、來源端與目標端的批次和檔案 ID、嘗試次數、時間戳記，以及每個請求唯一的終態。

### 重試是否需要新的 custom_id？

通常不需要。保持業務識別碼穩定並增加 attempt 欄位。如果傳輸 ID 必須跨批次唯一，則保留到原 custom_id 的可逆對應。

### 如何發現遺失的請求？

把已提交 ID 集合與成功及錯誤 ID 的聯集比較。在核對完成前，標記所有遺失、未知或重複 ID。

### Together 輸入檔案能否原樣重複使用？

只有目標端接受相同封裝、端點、模型 ID 和參數時才可以。多數遷移需要轉換封裝，但轉換器應原樣傳遞 custom_id。