Memecahkan Kesalahan Umum API Chat AI

Memahami Jendela Konteks

Salah satu alasan paling sering kegagalan API adalah melebihi jendela konteks. Jendela konteks menentukan jumlah total token yang diizinkan dalam satu permintaan, termasuk prompt input dan completion yang dihasilkan. Ketika batas ini tercapai, API akan menolak permintaan dengan kesalahan, sering kali menunjukkan bahwa urutannya terlalu panjang.

Pengembang sering salah mengira jumlah karakter sebagai jumlah token. Satu kata dapat mewakili beberapa token tergantung pada tokenizer. Sebagai contoh, jendela konteks 100.000 token, seperti yang disediakan oleh inference api kami, memungkinkan riwayat percakapan yang substansial atau pemrosesan dokumen besar, tetapi tidak tak terbatas.

• Pantau penggunaan token: Gunakan tokenizer resmi untuk model Anda untuk menghitung token secara akurat sebelum mengirim permintaan.
• Potong secara cerdas: Jika Anda melebihi batas, hapus pesan tertua dari riwayat percakapan, bukan pesan terbaru.
• Perhitungkan overhead: Cadangkan beberapa token untuk respons model. Jika prompt Anda menggunakan 63.000 token, Anda hanya memiliki 1.000 token tersisa untuk completion.

Gagal mengelola batas ini mengakibatkan koneksi terputus atau respons tidak lengkap. Selalu verifikasi jumlah token Anda terhadap dokumentasi model sebelum menerapkan ke produksi.

Menangani Kesalahan Streaming

Respons streaming melalui Server-Sent Events (SSE) sangat penting untuk pengalaman pengguna yang baik, tetapi memperkenalkan kompleksitas dalam penanganan kesalahan. Tidak seperti respons JSON standar, stream dapat terputus di tengah jalan. Jika terjadi kesalahan jaringan, klien Anda mungkin menerima data parsial, meninggalkan stream dalam keadaan tidak terdefinisi.

Saat mengimplementasikan konsumen stream, Anda harus menangani siklus hidup stream dengan hati-hati. Periksa kode status HTTP sebelum mencoba mengurai stream. Jika koneksi terputus, Anda harus mencatat kesalahan dan memutuskan apakah akan mencoba lagi atau menampilkan pesan kepada pengguna.

Selain itu, pastikan klien Anda menangani penanda akhir stream dengan benar. Beberapa pustaka mengharapkan peristiwa penutupan tertentu, sementara yang lain mengandalkan koneksi yang ditutup. Salah paham ini dapat menyebabkan proses menggantung atau kebocoran memori.

Selalu terapkan batas waktu untuk permintaan stream Anda. Jika API tidak mengirim respons dalam waktu yang wajar, batalkan permintaan untuk membebaskan sumber daya. Ini sangat penting untuk menjaga stabilitas di lingkungan dengan konkurensi tinggi.

Penghitungan dan Batas Token

Penghitungan token bukan hanya tentang tetap berada dalam jendela konteks; ini juga tentang manajemen biaya. Setiap token memiliki harga tertentu, dan kesalahan perhitungan penggunaan dapat menyebabkan tagihan yang tidak terduga. Meskipun harga kami transparan, dengan tarif per token untuk input dan output, Anda masih perlu melacak penggunaan secara akurat.

Sebagian besar pengembang menggunakan pustaka untuk menghitung token, tetapi sangat penting untuk menggunakan tokenizer yang benar untuk model yang Anda gunakan. Model yang berbeda menggunakan tokenizer yang berbeda, dan menggunakan yang salah dapat menyebabkan perbedaan signifikan dalam token yang dihitung. Sebagai contoh, tokenizer yang dilatih pada teks bahasa Inggris mungkin menangani tanda baca secara berbeda dibandingkan yang dilatih pada kode.

Pantau batas penggunaan Anda. API kami mengizinkan 300 permintaan per menit per kunci. Jika Anda melebihi ini, Anda akan menerima kesalahan 429 Too Many Requests. Mengimplementasikan penghitung sederhana di aplikasi Anda dapat membantu Anda tetap berada dalam batas ini dan menghindari gangguan layanan.

Akhirnya, ingat bahwa jumlah token dapat bervariasi sedikit antara implementasi tokenizer yang berbeda. Selalu uji logika penghitungan token Anda dengan beberapa input yang diketahui untuk memastikan konsistensi.

Jebakan Konfigurasi Header

Header adalah lapisan konfigurasi permintaan API Anda. Mengonfigurasinya secara salah adalah sumber umum kesalahan 400 Bad Request atau 401 Unauthorized. Dua header paling kritis adalah Content-Type dan Authorization.

Header Content-Type harus diatur ke application/json. Jika hilang atau salah, API mungkin tidak mengurai body permintaan Anda dengan benar. Header Authorization harus menyertakan kunci API Anda dalam format Bearer YOUR_API_KEY. Kesalahan umum adalah melupakan awalan Bearer, yang menghasilkan kesalahan autentikasi.

• Periksa salah ketik: Pastikan kunci API Anda disalin dengan benar, termasuk spasi atau baris baru apa pun di akhir.
• Verifikasi header: Gunakan alat seperti curl atau Postman untuk memeriksa header yang dikirim.
• Tangani sensitivitas huruf besar-kecil: Beberapa API sensitif huruf besar-kecil untuk nama header, meskipun sebagian besar API modern tidak.

Selalu verifikasi header Anda sebelum mengirim permintaan. Kesalahan kecil dalam header dapat menyebabkan seluruh permintaan gagal, menyebabkan kebingungan dan waktu debugging yang terbuang.

Manajemen Batas Laju

Batas laju ada untuk memastikan penggunaan yang adil dan mencegah penyalahgunaan. API kami mengizinkan 300 permintaan per menit per kunci. Jika Anda melebihi batas ini, Anda akan menerima kesalahan 429 Too Many Requests. Kesalahan ini menyertakan header Retry-After, yang menunjukkan berapa lama Anda harus menunggu sebelum membuat permintaan lain.

Untuk mengelola batas laju secara efektif, terapkan strategi backoff. Alih-alih mencoba lagi segera, tunggu periode yang meningkat secara eksponensial dengan setiap percobaan. Ini mencegah aplikasi Anda membanjiri API selama waktu puncak.

Pantau metrik penggunaan Anda. Sebagian besar API menyediakan dasbor atau endpoint API untuk melacak volume permintaan Anda. Gunakan data ini untuk mengoptimalkan pola permintaan aplikasi Anda. Jika Anda membuat terlalu banyak permintaan kecil, pertimbangkan untuk menggabungkannya.

Ingat bahwa batas laju adalah per kunci, bukan per akun. Jika Anda memiliki beberapa kunci, setiap kunci memiliki batasnya sendiri. Rencanakan distribusi kunci Anda sesuai untuk menghindari mencapai batas secara tidak terduga.

Interpretasi Kode Error

Memahami kode kesalahan sangat penting untuk debugging. Kesalahan paling umum yang akan Anda temui adalah 400 Bad Request, 401 Unauthorized, 429 Too Many Requests, dan 500 Internal Server Error.

• 400 Bad Request: Ini biasanya menunjukkan masalah dengan body permintaan, seperti bidang yang hilang atau JSON yang tidak valid. Periksa pesan kesalahan untuk detail tentang bidang mana yang salah.
• 401 Unauthorized: Ini menunjukkan masalah dengan kunci API Anda. Verifikasi bahwa kunci tersebut benar dan belum dicabut.
• 429 Too Many Requests: Ini menunjukkan Anda telah melebihi batas laju. Terapkan strategi backoff untuk menangani ini dengan baik.
• 500 Internal Server Error: Ini menunjukkan masalah di sisi server. Coba lagi permintaan setelah jeda singkat.

Selalu log body respons kesalahan. Sering kali berisi informasi berharga tentang apa yang salah, seperti bidang spesifik yang menyebabkan kesalahan. Ini dapat menghemat waktu debugging Anda selama berjam-jam.

Mengoptimalkan Body Permintaan

Body permintaan adalah inti dari interaksi API Anda. Mengoptimalkannya dapat meningkatkan kinerja dan mengurangi biaya. Kesalahan umum adalah mengirim terlalu banyak data dalam satu permintaan. Jika prompt Anda terlalu besar, Anda mungkin melebihi jendela konteks atau menimbulkan biaya yang lebih tinggi.

Strukturkan JSON Anda dengan hati-hati. Pastikan semua bidang yang diperlukan ada dan bahwa bidang opsional hanya disertakan jika diperlukan. Sebagai contoh, jika Anda tidak memerlukan streaming, jangan sertakan parameter stream. Hal ini mengurangi ukuran payload dan menyederhanakan respons.

Gunakan alat seperti curl atau Postman untuk menguji body permintaan Anda. Hal ini memungkinkan Anda memverifikasi bahwa JSON valid dan bahwa API menafsirkannya dengan benar. Ini juga membantu Anda mengidentifikasi data yang tidak perlu yang dikirim.

Akhirnya, pertimbangkan untuk melakukan caching respons untuk permintaan yang identik. Jika Anda mengirim prompt yang sama beberapa kali, Anda dapat menyimpan respons secara lokal dan menghindari melakukan panggilan API lagi. Ini dapat secara signifikan mengurangi latensi dan biaya untuk tugas-tugas yang berulang.

Men-debug Pemanggilan Fungsi

Pemanggilan fungsi memungkinkan model untuk mengeksekusi fungsi berdasarkan input pengguna. Men-debug pemanggilan fungsi bisa menjadi tantangan karena melibatkan beberapa langkah: mengirim permintaan, menerima panggilan fungsi, mengeksekusi fungsi, dan mengirim hasil kembali ke model.

Pastikan definisi fungsi Anda akurat. Skema harus sesuai dengan tanda tangan fungsi yang sebenarnya. Jika skema tidak benar, model mungkin menghasilkan argumen yang tidak valid, yang menyebabkan kesalahan saat Anda mencoba mengeksekusi fungsi.

Log argumen panggilan fungsi dan output fungsi. Hal ini memungkinkan Anda memverifikasi bahwa model menghasilkan argumen yang benar dan bahwa fungsi Anda berjalan sesuai harapan. Jika ada kesalahan, log akan membantu Anda mengidentifikasi masalahnya.

Tangani kesalahan dengan baik. Jika eksekusi fungsi gagal, kirimkan pesan kesalahan kembali ke model agar dapat menyesuaikan responsnya. Hal ini memberikan pengalaman pengguna yang lebih baik dan memungkinkan model untuk pulih dari kesalahan.