# Как перенести пакетное задание Together AI, не потеряв идентификаторы запросов? > Оставляйте принадлежащий приложению custom_id без изменений, а идентификаторы файлов, пакетов и ответов обоих провайдеров храните отдельно. До отправки проверяйте полный набор ID, сопоставляйте результаты и ошибки по ID и учитывайте повторы, не меняя бизнес-ключ. При переносе пакетного задания Together AI считайте каждый исходный `custom_id` неизменяемыми данными приложения. Копируйте его в целевой запрос без изменений, храните ID пакета и ответа нового провайдера в отдельных полях и сопоставляйте результаты по `custom_id`, а не по порядку строк. Важно разделять идентификатор, принадлежащий приложению, и 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"}]}} ``` Меняйте endpoint, модель и неподдерживаемые параметры в адаптере. Передавайте `custom_id` как непрозрачную строку, не обрезая, не переводя и не создавая заново. ## Проверить до отправки Проверьте созданный JSONL: * каждая строка разбирается отдельно; * каждый `custom_id` присутствует и уникален; * набор ID совпадает с исходным манифестом; * каждое тело соответствует schema целевого endpoint. Запишите хеш и число строк итогового файла. Загрузите именно этот артефакт и свяжите возвращенные ID с журналом. ## Сопоставить результаты и ошибки вместе После завершения пакета скачайте результаты и ошибки. Индексируйте строки по `custom_id` и сравните их объединение с отправленным набором. Отнесите каждый ID к успешным, ошибочным, отсутствующим или повторным. Завершенный пакет еще не обязательно сопоставлен. Для каждого ID должно быть ровно одно конечное состояние. ## Повторить без изменения идентификатора Создайте новый пакет только из отсутствующих и ошибочных запросов. Сохраняйте тот же `custom_id` и увеличивайте `attempt` в журнале. Если цель запрещает повторное использование транспортного ID, сохраните оригинал в поле приложения и создайте обратимое соответствие. ## Безопасно переключиться Начните с небольшого репрезентативного пакета. Сравните успех, задержку, токены, результаты, ошибки и стоимость. Храните таблицы источника и цели параллельно до детерминированной сверки. Автоматизируйте три проверки: нет неизвестных ID, нет повторных конечных результатов и нет пропущенных ID. ## Итог Сохраняйте принадлежащий приложению `custom_id`, преобразуйте только конверт провайдера и ведите журнал соответствий. Сверяйте результаты и ошибки по ID, учитывайте попытки и переключайтесь только после получения конечного состояния для каждого запроса. ## FAQ ### Какой ID должен оставаться неизменным при переносе пакета Together? Сохраняйте custom_id, назначенный приложением. ID пакетов, файлов и ответов провайдеров должны быть отдельными метаданными, а не бизнес-ключом. ### Можно ли сопоставлять результаты по номеру строки? Нет. Порядок результатов может измениться, а ошибки могут попасть в отдельный файл. Сопоставляйте объединение результатов и ошибок по custom_id. ### Что хранить в журнале переноса? Храните custom_id, хеш нормализованной нагрузки, ID пакетов и файлов источника и цели, номер попытки, временные метки и одно конечное состояние для каждого запроса. ### Нужен ли новый custom_id при повторе? Обычно нет. Сохраняйте бизнес-идентификатор и увеличивайте attempt. Если транспортный ID должен быть уникальным, храните обратимое соответствие исходному custom_id. ### Как обнаружить потерянные запросы? Сравните множество отправленных ID с объединением ID успешных и ошибочных результатов. До завершения сверки отмечайте отсутствующие, неизвестные и повторяющиеся ID. ### Можно ли повторно использовать входной файл Together без изменений? Только если целевой API принимает тот же конверт, endpoint, модель и параметры. Обычно требуется преобразователь, который сохраняет custom_id.