# Jak przenieść zadanie wsadowe Together AI bez utraty identyfikatorów żądań? > Pozostaw każdy należący do aplikacji custom_id bez zmian, a identyfikatory plików, partii i odpowiedzi obu dostawców przechowuj osobno. Przed wysłaniem zweryfikuj pełny zbiór ID, łącz wyniki i błędy po ID oraz zapisuj próby bez zmiany klucza biznesowego. Traktuj każdy źródłowy `custom_id` jako niezmienne dane aplikacji. Skopiuj go bez zmian do żądania docelowego, ID partii i odpowiedzi celu zapisuj osobno i uzgadniaj wyniki po `custom_id`, a nie kolejności w pliku. Najważniejsze jest rozdzielenie identyfikatora aplikacji od ID nadanych przez dostawców. Pierwszy zachowaj, pozostałe mapuj. ## Zinwentaryzuj wszystkie identyfikatory Wejście wsadowe Together używa JSONL. Każdy wiersz zawiera unikalny `custom_id` i treść żądania. Partia, pliki wejścia i wyjścia oraz odpowiedź mogą mieć różne ID. | Identyfikator | Właściciel | Reguła migracji | |---|---|---| | `custom_id` | Aplikacja | Zachowaj dokładnie | | ID partii źródłowej | Together | Zapisz jako metadane źródła | | ID partii docelowej | Dostawca celu | Zapisz osobno | | ID plików wejścia i wyjścia | Każdy dostawca | Nie używaj jako klucza biznesowego | | ID odpowiedzi | API modelu | Zachowaj do wsparcia i rozliczeń | Nie zastępuj `custom_id` numerem wiersza, chyba że jest już trwałym kluczem. Kolejność może się zmienić, a błędy mogą być w osobnym pliku. ## Utwórz rejestr migracji Przed wysłaniem utwórz rekord dla każdego logicznego żądania: ```json { "custom_id": "invoice-2026-00421", "source_batch_id": "batch_source", "target_batch_id": null, "payload_sha256": "...", "state": "prepared" } ``` Zapewnij unikalność `custom_id` i dodaj hash znormalizowanej treści. Wykryje zmiany bez zapisywania drugiej kopii danych wrażliwych. ## Konwertuj otoczkę, nie tożsamość Otoczki wsadowe różnią się. Together umieszcza `custom_id` obok `body`; inne zgodne API może wymagać także `method` i `url`. ```json {"custom_id":"invoice-2026-00421","method":"POST","url":"/v1/chat/completions","body":{"model":"target-model","messages":[{"role":"user","content":"Classify this record"}]}} ``` Zmieniaj endpoint, model i nieobsługiwane parametry w konwerterze. Przekazuj `custom_id` jako nieprzezroczysty ciąg, bez skracania, tłumaczenia i regeneracji. ## Zweryfikuj przed wysłaniem Sprawdź wygenerowany JSONL: * każdy wiersz analizuje się samodzielnie; * każdy `custom_id` istnieje i jest unikalny; * zbiór ID odpowiada manifestowi źródła; * każda treść spełnia schema endpointu celu. Zapisz hash i liczbę wierszy pliku końcowego. Prześlij właśnie ten artefakt i połącz zwrócone ID z rejestrem. ## Uzgodnij razem wyniki i błędy Po zakończeniu pobierz wyniki i błędy. Indeksuj wiersze po `custom_id` i porównaj ich sumę z wysłanym zbiorem. Oznacz każdy ID jako sukces, błąd, brak lub duplikat. Zakończona partia nie oznacza pełnego uzgodnienia. Każdy ID potrzebuje jednego stanu końcowego. ## Ponawiaj bez zmiany tożsamości Utwórz nową partię tylko z żądań błędnych lub brakujących. Zachowaj `custom_id` i zwiększ `attempt` w rejestrze. Jeśli cel zakazuje ponownego użycia ID, zachowaj oryginał w polu aplikacji i utwórz odwracalne mapowanie transportowe. ## Przełączaj bezpiecznie Zacznij od małej reprezentatywnej partii. Porównaj sukces, opóźnienie, tokeny, wyniki, błędy i koszt. Trzymaj dane źródła i celu równolegle do deterministycznej zgodności. Automatyzuj trzy asercje: brak nieznanych ID, brak podwójnych wyników końcowych i brak brakujących ID. ## Podsumowanie Zachowaj aplikacyjny `custom_id`, konwertuj tylko otoczkę dostawcy i prowadź rejestr mapowań. Uzgadniaj wyniki i błędy po ID, zapisuj próby i przełączaj dopiero, gdy każde żądanie ma wynik końcowy. ## FAQ ### Który ID musi pozostać stały podczas migracji partii Together? Zachowaj custom_id nadany przez aplikację. ID partii, plików i odpowiedzi dostawców przechowuj jako osobne metadane, a nie klucz biznesowy. ### Czy można uzgadniać wyniki według numeru wiersza? Nie. Kolejność wyjścia może się zmienić, a błędy mogą znaleźć się w innym pliku. Uzgadniaj sumę wyników i błędów przez custom_id. ### Co powinien zawierać rejestr migracji? Zapisuj custom_id, hash znormalizowanego ładunku, ID partii i plików źródła oraz celu, numer próby, znaczniki czasu i jeden stan końcowy na żądanie. ### Czy ponowienie wymaga nowego custom_id? Zwykle nie. Zachowaj identyfikator biznesowy i zwiększ attempt. Jeśli ID transportowy musi być unikalny, zachowaj odwracalne mapowanie do oryginalnego custom_id. ### Jak wykryć utracone żądania? Porównaj wysłany zbiór ID z sumą ID sukcesów i błędów. Przed zakończeniem oznacz brakujące, nieznane i powtórzone ID. ### Czy można ponownie użyć pliku wejściowego Together bez zmian? Tylko jeśli cel akceptuje tę samą otoczkę, endpoint, model i parametry. Zwykle potrzebny jest konwerter zachowujący custom_id.