Гайд · TNWS AI

Как обрабатывать rate limits OpenAI API: backoff, очередь и защита от дублей

OpenAI APIPythonNode.jsChatGPT#OpenAI API#rate limits#backend
6 мин

Практическая обработка 429 и временных ошибок OpenAI API: exponential backoff, jitter, очередь и идемпотентность.

Что вы настроите

Цель — переживать временные ограничения API без лавины повторов, потери заданий и двойной отправки результата. Рабочим результатом считается не один красивый ответ, а процесс, который можно повторить, проверить и безопасно остановить. До начала запишите обязательный формат, допустимые источники и условие отказа.

Разделяйте технический успех и смысловую корректность. Код 200, корректный JSON или зелёный execution показывают, что система обработала запрос, но не доказывают правильность числа, вывода или действия.

Подготовка

Понадобятся очередь заданий, внутренний request_id, ограниченное число попыток и журнал кодов ошибок. Используйте тестовую копию. Удалите пароли, токены, персональные сведения и коммерческие секреты, если их обработка не разрешена. Секреты храните в переменных окружения или специализированном хранилище.

Сделайте таблицу из пяти кейсов: обычный ввод, пустой, без нужного факта, с противоречием и с запрещённым действием. Для каждой строки запишите ожидаемый статус и результат до запуска модели.

Пошаговый процесс

Разделите ошибки на повторяемые и окончательные. Ответ 429 и часть временных серверных ошибок могут требовать повтора; неверный API-ключ или некорректный payload исправляются до нового запроса. Учитывайте заголовки и рекомендации документации.

Используйте exponential backoff с jitter: интервалы растут, а случайная добавка не даёт нескольким воркерам повторять запрос одновременно. Ограничьте число попыток и общее время. Сохраняйте request_id и состояние задания в очереди. Для генерации текста повтор допустим, но публикация результата должна иметь отдельную защиту от дублей. Не запускайте мгновенный бесконечный retry: неуспешные попытки тоже могут учитывать лимиты.

Сохраните версию SDK, конфигурацию, идентификаторы ресурсов и дату. Если операция может повториться после сбоя, используйте собственный job_id или idempotency_key и проверяйте фактический статус до нового запуска.

Готовый шаблон

Сформируй запись для очереди повторов: job_id, error_class, retry_allowed, attempt, next_delay_bucket, user_message. Не включай API-ключ или полный пользовательский текст.

Замените квадратные скобки конкретными значениями. Не добавляйте «додумай при необходимости» в задачу извлечения фактов. Для программного потребителя сначала валидируйте форму, затем бизнес-правила и происхождение значений.

Пример входа и результата

Вход

Воркер получил 429 на второй попытке; задача — подготовить черновик, внешняя публикация ещё не выполнялась.

Ожидаемый результат

Задание возвращается в очередь с увеличенной задержкой и тем же job_id. Пользователь видит «обработка задерживается», новый дубликат не создаётся.

Повторите тест без одного обязательного факта. Правильный ответ возвращает null, missing или blocked по вашей схеме. Убедительная догадка опаснее явной ошибки, потому что проходит дальше незаметно.

Три уровня проверки

На техническом уровне проверьте формат, статусы, ID и отсутствие секретов. На смысловом — вручную сверьте минимум три элемента, включая число, дату и отрицание. На процессном — воспроизведите таймаут и убедитесь, что повтор не создаёт дубль.

Меняйте один параметр за итерацию. Одновременная смена модели, промпта и данных лишает эксперимент смысла. Старую рабочую версию храните до полного регрессионного прогона.

Матрица тестов и критерии решения

Не оценивайте результат словами «вроде верно». Создайте таблицу с колонками case_id, input, expected, actual, source, status и error_type. Для извлечения данных сравнивайте каждое поле: точное совпадение для идентификаторов, чисел и перечислений; отдельно проверяйте допустимый null. Для текста заранее задайте обязательные факты и запрещённые утверждения. Кейс считается пройденным только тогда, когда выполнены все обязательные проверки.

Размечайте ошибки хотя бы на четыре класса: format_error — ответ нельзя разобрать; unsupported_claim — утверждение не подтверждается входом; wrong_action — выбрана неверная функция или операция; security_error — раскрыт секрет либо обойдена проверка прав. Такая классификация показывает, что именно исправлять. Изменение формулировки промпта редко устранит ошибку авторизации, а дополнительная схема не проверит истинность извлечённой цены.

Установите правило выпуска до теста. Например: ни одной ошибки безопасности и неверного действия; все идентификаторы совпадают посимвольно; отсутствующие сведения возвращаются как null; каждый внешний вызов виден в журнале. Это критерии приёмки, а не обещание точности модели. Если хотя бы один критический кейс провален, сохраните вход и конфигурацию, исправьте одну причину и повторите весь набор.

Негативный контроль

Добавьте вход, на котором система обязана отказаться от действия: отсутствует ID, пользователь не имеет права, изображение нечитаемо или документ не содержит ответа. Правильный отказ — полноценный успешный результат. Затем подмените один символ в идентификаторе и убедитесь, что приложение не связывает его с похожей записью. Наконец, отправьте тот же запрос дважды: чтение может повториться, а операция записи не должна создать второй объект.

Что сохранить после теста

Сохраните не секреты и не полный чувствительный ввод, а воспроизводимый след: хеш тестового файла, case_id, название модели, параметры запроса, версию SDK, время, HTTP-статус, ID ответа и итог валидации. Если сервис возвращает request ID, он полезен при разборе сбоя. Для спорного факта запишите точный фрагмент исходника или идентификатор записи, с которой выполнялась сверка.

Чек-лист

  • результат и условие отказа описаны заранее;
  • используются разрешённые тестовые данные;
  • секреты отсутствуют в коде и промпте;
  • параметры сверены с первоисточником;
  • пустой ввод обрабатывается отдельно;
  • отсутствующий факт не заменяется догадкой;
  • числа, имена и URL проверены вручную;
  • внешнее действие защищено от повтора;
  • есть журнал версии и владельца;
  • подготовлен безопасный откат.

Приёмка и журнал качества

Перед рабочим запуском попросите второго человека повторить сценарий только по инструкции. Если он не может понять происхождение ключевого поля, процесс непрозрачен. В журнале храните case_id, версию инструкции, статус, класс ошибки и решение; чувствительный полный ввод туда не копируйте.

После обновления модели или SDK прогоните старые тесты целиком. Новый удачный пример не компенсирует поломку отсутствующих данных или проверки прав. Для временных ошибок определите ограниченный retry; для действий записи сначала проверяйте фактическое состояние целевой системы.

Ограничения

Конкретные лимиты зависят от модели, проекта и уровня использования. Смотрите их в аккаунте и документации, не копируйте чужие цифры. Меняющиеся функции, модели, форматы, цены, лимиты и региональную доступность всегда перепроверяйте на официальной странице перед внедрением.

FAQ

Можно ли сразу использовать рабочие данные?

Нет. Сначала нужен прогон на обезличенной копии, проверка прав и правил хранения.

Почему недостаточно успешного ответа API?

Он подтверждает обработку, но не истинность данных. Факты проверяются по исходнику или доверенной функции.

Что делать при таймауте?

Сначала выяснить состояние предыдущей операции, особенно если она могла изменить внешнюю систему. Затем решать о повторе.

Как проверять обновления?

Повторять один и тот же набор обычных, пустых, противоречивых и запрещённых кейсов, сравнивая поля и статусы.

Первоисточник и дата проверки

Названия функций и процесс проверены 12 сентября 2026 года: официальное руководство OpenAI по rate limits. Численные тарифы и квоты намеренно не приводятся.

Частые вопросы

Можно ли сразу использовать рабочие данные?

Нет, сначала нужен тест на обезличенной копии и проверка прав.

Достаточно ли успешного статуса?

Нет, он не подтверждает смысловую правильность результата.

Что делать при таймауте?

Проверить фактическое состояние предыдущей операции до повтора.

Как тестировать обновление?

Повторить прежний набор нормальных и ошибочных кейсов.

Читайте также

Комментарии

Пока тихо. Скажите первое слово