Головне
- Context windows combine prompt and completion, so long histories drain limits faster than expected.
- Під час потокової передачі необхідно обережно обробляти події SSE, щоб уникнути пошкодження JSON або втрати токенів.
- JSON mode demands strict schema adherence; malformed responses cause silent parsing failures.
- Попередня оплата криптовалютою означає, що помилки є безкоштовними, але підрахунок токенів має бути точним, щоб уникнути несподіванок.
Чому ваш API-ключ можуть відхилити
Ключі API відхиляються, коли клієнт надсилає некоректні заголовки або перевищує ліміти тіла запиту. Сервер перевіряє заголовок автентифікації перед обробкою будь-якої логіки. Якщо заголовок відсутній або містить зайві пробіли, запит одразу завершується невдало.
Іншою поширеною причиною є надсилання корисного навантаження, яке перевищує ліміт розміру тіла в 8 МБ. Великі контекстні вікна з багатьма повідомленнями легко можуть перевищити цей поріг. Перевірте довжину масиву повідомлень і кількість токенів перед надсиланням.
- Переконайтеся, що заголовок Authorization правильно використовує префікс 'Bearer'.
- Verify the request body size stays under 8 MB.
- Переконайтеся, що ключ API активний і не прострочений.
Розуміння обмежень контекстного вікна
Контекстне вікно включає як вхідний запит, так і згенероване завершення. Наша API підтримує вікно на 100,000 токенів, але ви повинні враховувати обидві сторони. Якщо ви надсилаєте 80,000 токенів контексту, у вас залишається лише 20,000 для відповіді.
Більшість моделей мають обмеження на обсяг виводу, якщо ви не вказали max_tokens. Це може призвести до несподіваного обрізання довгих відповідей. Встановіть max_tokens на бажану довжину лише тоді, коли хочете встановити ліміт. Пам'ятайте, що обмеження стосується всього запиту, а не лише промпту.
Правильне оброблення переривань потокової передачі
Потокова передача через події, що надсилаються сервером (SSE), вимагає надійної обробки помилок. Якщо з'єднання розривається, ви можете втратити останній токен або метадані про використання. Завжди буферизуйте отримані фрагменти та відновлюйте повну відповідь на стороні клієнта.
Дані про використання токенів зазвичай надсилаються в останньому чанку потоку. Якщо ви розриваєте з'єднання достроково, ви можете пропустити точну кількість токенів. Це впливає на точність розрахунків у системах передоплати. Реалізуйте механізм повторних спроб із експоненційним збільшенням затримки для обробки тимчасових проблем з мережею.
Використовуйте спеціалізований клієнт потокової передачі, який автоматично обробляє парсинг SSE. Це зменшує ризик помилок парсингу та гарантує, що ви отримаєте всі дані.
Помилки парсингу в режимі JSON
При використанні response_format: {"type": "json_object"} модель повинна повертати валідний JSON. Будь-яке відхилення призводить до помилок парсингу у вашій програмі. Переконайтеся, що ваш запит чітко вказує моделі виводити лише JSON.
Іноді модель додає блоки коду markdown навколо JSON, що порушує роботу суворих парсерів. Видаліть обгортки перед парсингом. Також перевірте структуру JSON на стороні клієнта перед використанням даних.
Використовуйте бібліотеку валідації схем для своєчасного виявлення помилок. Це запобігає збоям, коли модель повертає неочікувані ключі або типи даних.
Несподіванки підрахунку токенів та рахунків
Попередня оплата стягує кошти лише за фактичне використання токенів. Помилки та відмови є безкоштовними, що є значною перевагою перед підпискою. Однак підрахунок токенів може бути складним, якщо ви не враховуєте весь контекст.
Кожне повідомлення в історії розмови враховується в ліміт вхідних токенів. Довгі розмови витрачають ваш передоплачений кредит швидше, ніж ви можете очікувати. Регулярно моніторьте своє використання, щоб уникнути вичерпання кредитів під час сесії.
Налаштуйте сповіщення про низький баланс кредитів. Це дозволить вам поповнити рахунок до того, як ваші запити почнуть відхилятися. Пам'ятайте, що кредити не мають терміну придатності, тому поповнювати рахунок можна в будь-який зручний момент.
Уникнення м'яких відмов у промптах NSFW
М'які відмови виникають, коли модель вагається або надає часткову відповідь замість прямої. Це часто трапляється з суперечливими або дорослими темами. Навіть у моделі без цензури певні тригери можуть викликати вагання.
Налаштуйте параметр temperature, щоб зменшити випадковість. Нижча температура робить модель більш детермінованою та зменшує ймовірність того, що вона буде ухилятися від прямої відповіді. Також переконайтеся, що ваш запит є чітким і прямим. Уникайте неоднозначних формулювань, які можуть заплутати модель.
Якщо ви стикаєтеся з частими м'якими відмовами, спробуйте трохи перефразувати запит. Невеликі зміни в формулюваннях часто дозволяють обійти вагання та отримати пряму відповідь.
Скачки лімітів швидкості та стратегії експоненційного зменшення інтервалів
API дозволяє 300 запитів на хвилину та 8 одночасних запитів на ключ. Піки трафіку можуть швидко досягти цих лімітів. Реалізуйте експоненційне сповільнення для коректного оброблення помилок перевищення лімітів.
Якщо ви отримуєте код стану 429, зачекайте перед повторною спробою. Почніть із короткої затримки та збільшуйте її з кожною повторною спробою. Це запобігає перевантаженню сервера під час пікових навантажень.
Моніторьте частоту запитів і відповідно регулюйте рівень паралелізму. Якщо ви надсилаєте багато одночасних запитів, спробуйте розподілити їх у часі. Це забезпечує стабільну пропускну здатність без досягнення лімітів.
Структури корисного навантаження для виклику функцій
Виклик функцій вимагає специфічної структури корисного навантаження. Визначте свої функції в параметрі tools та вкажіть tool_choice. Модель поверне виклик функції, якщо визначить, що це є відповідною реакцією.
Переконайтеся, що ваші визначення функцій є точними та повними. Відсутність параметрів або неправильні типи можуть призвести до того, що модель згенерує некоректні виклики. Завжди перевіряйте аргументи виклику функції перед їх виконанням.
Використовуйте параметр tool_choice, щоб керувати тим, коли модель викликає функції. Ви можете примусово викликати функцію, надати моделі право на вибір або повністю вимкнути виклик функцій. Це забезпечує детальний контроль над поведінкою моделі.
Налагодження помилок 400 та 500
Помилки 400 вказують на проблеми на стороні клієнта, наприклад, невалідний JSON або відсутні параметри. Помилки 500 свідчать про проблеми на стороні сервера, такі як внутрішні помилки або таймаути. Розрізнення між ними допомагає швидше знаходити та виправляти помилки.
Для помилок 400 перевірте повідомлення про помилку, надане у відповіді. Зазвичай воно вказує на проблему. Для помилок 500 повторіть запит після короткої затримки. Якщо помилка не зникає, зверніться до служби підтримки з ідентифікатором запиту.
Логування деталей запиту та відповіді для кожної помилки. Це допомагає виявляти закономірності та повторювані проблеми. Використовуйте сервіс логування для відстеження помилок з часом та покращення інтеграції з API.
