แก้ไขข้อผิดพลาด API แชท AI ที่พบบ่อย

เข้าใจหน้าต่างบริบท

เหตุผลหนึ่งที่ทำให้ API ล้มเหลวที่พบบ่อยที่สุดคือการเกินหน้าต่างบริบท หน้าต่างบริบทกำหนดจำนวนโทเคนที่อนุญาตในคำขอเดียว รวมถึงพรอมต์อินพุตและการสร้างผลลัพธ์ที่สร้างขึ้น เมื่อถึงขีดจำกัดนี้ API จะปฏิเสธคำขอด้วยข้อผิดพลาด ซึ่งมักบ่งชี้ว่าลำดับยาวเกินไป

นักพัฒนาซอฟต์แวร์มักสับสนระหว่างจำนวนอักขระกับจำนวนโทเคน คำเดียวสามารถแทนโทเคนหลายตัวได้ขึ้นอยู่กับโทเคไนเซอร์ ตัวอย่างเช่น หน้าต่างบริบท 100,000 โทเคน เช่น ที่จัดเตรียมโดย Inference API ของเรา ช่วยให้มีประวัติการสนทนาหรือการประมวลผลเอกสารขนาดใหญ่ได้มาก แต่ไม่ได้ไม่มีที่สิ้นสุด

• ตรวจสอบการใช้งานโทเคน: ใช้โทเคไนเซอร์ทางการสำหรับโมเดลของคุณเพื่อนับโทเคนอย่างแม่นยำก่อนส่งคำขอ
• ตัดทอนอย่างชาญฉลาด: หากคุณเกินขีดจำกัด ให้ลบข้อความเก่าที่สุดออกจากประวัติการสนทนาแทนข้อความล่าสุด
• คำนวณโอเวอร์เฮด: จองโทเคนบางส่วนสำหรับการตอบสนองของโมเดล หากพรอมต์ของคุณใช้ 63,000 โทเคน คุณจะมีโทเคนเหลืออยู่เพียง 1,000 โทเคนสำหรับการสร้างข้อความ

การไม่จัดการขีดจำกัดนี้ส่งผลให้การเชื่อมต่อหลุดหรือการตอบสนองไม่สมบูรณ์ ตรวจสอบการนับโทเคนของคุณกับเอกสารประกอบของโมเดลก่อนนำไปใช้จริง

จัดการข้อผิดพลาดสตรีมมิง

การตอบสนองแบบสตรีมมิงผ่านเหตุการณ์ที่ส่งโดยเซิร์ฟเวอร์ (SSE) มีความสำคัญต่อประสบการณ์ผู้ใช้ที่ดี แต่สร้างความซับซ้อนในการจัดการข้อผิดพลาด ต่างจากการตอบสนอง JSON มาตรฐาน สตรีมสามารถแตกกลางทางได้ หากเกิดข้อผิดพลาดของเครือข่าย ไคลเอนต์ของคุณอาจได้รับข้อมูลบางส่วน ทำให้สตรีมอยู่ในสถานะที่ไม่กำหนด

เมื่อใช้งานผู้บริโภครายการสตรีม คุณต้องจัดการวงจรชีวิตของสตรีมอย่างระมัดระวัง ตรวจสอบรหัสสถานะ HTTP ก่อนพยายามแยกวิเคราะห์สตรีม หากการเชื่อมต่อขาด ให้บันทึกข้อผิดพลาดและตัดสินใจว่าจะลองใหม่หรือแสดงข้อความให้ผู้ใช้

นอกจากนี้ ตรวจสอบให้แน่ใจว่าไคลเอนต์ของคุณจัดการเครื่องหมายสิ้นสุดสตรีมได้อย่างถูกต้อง ไลบรารีบางรายการคาดหวังเหตุการณ์การปิดเฉพาะ ในขณะที่ไลบรารีอื่นพึ่งพาการปิดการเชื่อมต่อ ความเข้าใจผิดในเรื่องนี้สามารถนำไปสู่กระบวนการค้างหรือการรั่วไหลของหน่วยความจำ

ควรตั้งค่าเวลาหมดอายุสำหรับคำขอสตรีมของคุณเสมอ หาก API ไม่ส่งการตอบสนองภายในเวลาที่สมเหตุสมผล ให้ยกเลิกคำขอเพื่อปล่อยทรัพยากร สิ่งนี้สำคัญมากสำหรับการรักษาความเสถียรในสภาพแวดล้อมที่มีความพร้อมใช้งานสูง

การนับโทเคนและขีดจำกัด

การนับโทเคนไม่ใช่แค่การอยู่ในหน้าต่างบริบทเท่านั้น แต่ยังเกี่ยวกับการจัดการต้นทุนอีกด้วย แต่ละโทเคนมีราคาเฉพาะ และการคำนวณการใช้งานผิดพลาดสามารถนำไปสู่บิลที่ไม่คาดคิด แม้ว่าการกำหนดราคาของเราจะโปร่งใส โดยมีอัตราต่อโทเคนสำหรับอินพุตและเอาต์พุต คุณยังคงต้องติดตามการใช้งานอย่างแม่นยำ

นักพัฒนาส่วนใหญ่ใช้ไลบรารีเพื่อนับโทเคน แต่สิ่งสำคัญคือต้องใช้ตัวแยกโทเคนที่ถูกต้องสำหรับโมเดลที่คุณใช้ โมเดลต่างกันใช้ตัวแยกโทเคนต่างกัน และการใช้ตัวที่ไม่ถูกต้องสามารถนำไปสู่ความแตกต่างที่สำคัญในโทเคนที่นับได้ ตัวอย่างเช่น ตัวแยกโทเคนที่ฝึกด้วยข้อความภาษาอังกฤษอาจจัดการเครื่องหมายวรรคตอนต่างจากตัวที่ฝึกด้วยโค้ด

ติดตามขีดจำกัดการใช้งานของคุณ API ของเราอนุญาต 300 คำขอต่อนาทีต่อคีย์ หากคุณเกินสิ่งนี้ คุณจะได้รับข้อผิดพลาด 429 Too Many Requests การใช้ตัวนับง่ายๆ ในแอปพลิเคชันของคุณสามารถช่วยให้คุณอยู่ในขีดจำกัดเหล่านี้และหลีกเลี่ยงการหยุดให้บริการ

สุดท้าย โปรดจำไว้ว่าจำนวนโทเคนอาจแตกต่างกันเล็กน้อยระหว่างการใช้งานตัวแบ่งคำ (tokenizer) แบบเดียวกันเสมอ ควรทดสอบตรรกะการนับโทเคนของคุณด้วยข้อมูลทดสอบที่ทราบค่าล่วงหน้าเพื่อให้มั่นใจในความสอดคล้อง

กับดักการกำหนดค่าส่วนหัว

ส่วนหัวคือชั้นการกำหนดค่าของคำขอ API ของคุณ การกำหนดค่าที่ไม่ถูกต้องเป็นแหล่งที่มาทั่วไปของข้อผิดพลาด 400 Bad Request หรือ 401 Unauthorized ส่วนหัวที่สำคัญที่สุดสองส่วนคือ Content-Type และ Authorization

ส่วนหัว Content-Type ต้องตั้งค่าเป็น application/json หากขาดหรือไม่ถูกต้อง API อาจไม่สามารถแยกวิเคราะห์เนื้อหาคำขอของคุณได้อย่างถูกต้อง ส่วนหัว Authorization ต้องรวมคีย์ API ของคุณในรูปแบบ Bearer YOUR_API_KEY ข้อผิดพลาดทั่วไปอย่างหนึ่งคือการลืมส่วนนำหน้า Bearer ซึ่งส่งผลให้เกิดข้อผิดพลาดการตรวจสอบสิทธิ์

• ตรวจสอบคำผิด: ตรวจสอบให้แน่ใจว่าคัดลอกคีย์ API ของคุณอย่างถูกต้อง รวมถึงช่องว่างหรือบรรทัดใหม่ท้าย
• ตรวจสอบหัวเรื่อง: ใช้เครื่องมือเช่น curl หรือ Postman เพื่อตรวจสอบหัวเรื่องที่กำลังส่ง
• จัดการความไวต่อตัวพิมพ์ใหญ่: API บางรายการไวต่อตัวพิมพ์ใหญ่สำหรับชื่อหัวเรื่อง แม้ว่าจะไม่ใช่ API สมัยใหม่มากนัก

ตรวจสอบหัวเรื่องของคุณก่อนส่งคำขอ ข้อผิดพลาดเล็กน้อยในหัวเรื่องสามารถทำให้คำขอทั้งหมดล้มเหลว นำไปสู่ความสับสนและเวลาแก้ไขข้อบกพร่องที่เสียไป

การจัดการขีดจำกัดอัตรา

ขีดจำกัดอัตรามีอยู่เพื่อให้แน่ใจการใช้งานที่เป็นธรรมและป้องกันการละเมิด API ของเราอนุญาต 300 คำขอต่อนาทีต่อคีย์ หากคุณเกินขีดจำกัดนี้ คุณจะได้รับข้อผิดพลาด 429 Too Many Requests ข้อผิดพลาดนี้รวมหัวเรื่อง Retry-After ซึ่งระบุระยะเวลาที่คุณควรรอก่อนส่งคำขออื่น

เพื่อจัดการขีดจำกัดอัตราอย่างมีประสิทธิภาพ ให้ใช้กลยุทธ์การถอยหลัง แทนที่จะลองใหม่ทันที ให้รอเป็นระยะเวลาที่เพิ่มขึ้นแบบทวีคูณกับการลองใหม่แต่ละครั้ง สิ่งนี้ป้องกันไม่ให้แอปพลิเคชันของคุณทำให้ API ล้นในช่วงเวลาที่มีความต้องการสูง

ติดตามเมตริกการใช้งานของคุณ API ส่วนใหญ่มีแดชบอร์ดหรือเอนด์พอยต์ API เพื่อติดตามปริมาณคำขอของคุณ ใช้ข้อมูลนี้เพื่อปรับรูปแบบคำขอของแอปพลิเคชันของคุณ หากคุณกำลังส่งคำขอขนาดเล็กจำนวนมาก ให้พิจารณาจัดกลุ่มเข้าด้วยกัน

จำไว้ว่าขีดจำกัดอัตราเป็นต่อคีย์ ไม่ใช่ต่อบัญชี หากคุณมีคีย์หลายรายการ แต่ละคีย์มีขีดจำกัดของตัวเอง วางแผนการกระจายคีย์ของคุณ accordingly เพื่อหลีกเลี่ยงการชนกับขีดจำกัดโดยไม่ได้ตั้งใจ

การตีความรหัสข้อผิดพลาด

ความเข้าใจรหัสข้อผิดพลาดมีความสำคัญต่อการแก้ไขข้อบกพร่อง ข้อผิดพลาดที่พบบ่อยที่สุดที่คุณจะพบคือ 400 Bad Request, 401 Unauthorized, 429 Too Many Requests และ 500 Internal Server Error

• 400 Bad Request: สิ่งนี้มักบ่งชี้ถึงปัญหาเกี่ยวกับร่างกายคำขอ เช่น ฟิลด์ที่ขาดหายไปหรือ JSON ไม่ถูกต้อง ตรวจสอบข้อความข้อผิดพลาดสำหรับรายละเอียดเกี่ยวกับฟิลด์ที่ไม่ถูกต้อง
• 401 Unauthorized: สิ่งนี้บ่งชี้ถึงปัญหาเกี่ยวกับคีย์ API ของคุณ ตรวจสอบให้แน่ใจว่าคีย์ถูกต้องและไม่ได้ถูกเพิกถอน
• 429 Too Many Requests: สิ่งนี้บ่งชี้ว่าคุณได้เกินขีดจำกัดอัตราแล้ว ใช้กลยุทธ์ backoff เพื่อจัดการกับสถานการณ์นี้ได้อย่างราบรื่น
• 500 Internal Server Error: สิ่งนี้บ่งชี้ว่ามีปัญหาที่ฝั่งเซิร์ฟเวอร์ ลองส่งคำขออีกครั้งหลังจากหน่วงเวลาสั้นๆ

บันทึกร่างกายการตอบสนองข้อผิดพลาดเสมอ มักมีข้อมูลที่มีค่าเกี่ยวกับสิ่งที่ผิดพลาด เช่น ฟิลด์เฉพาะที่ทำให้เกิดข้อผิดพลาด สิ่งนี้สามารถประหยัดเวลาแก้ไขข้อบกพร่องของคุณได้หลายชั่วโมง

การปรับแต่ง Request Body

Request body เป็นหัวใจสำคัญของการใช้งาน API ของคุณ การปรับแต่งสามารถปรับปรุงประสิทธิภาพและลดต้นทุนได้ ข้อผิดพลาดที่พบบ่อยคือการส่งข้อมูลจำนวนมากเกินไปในคำขอเดียว หากพรอมต์ของคุณมีขนาดใหญ่เกินไป คุณอาจเกินหน้าต่างบริบทหรือ incur ค่าใช้จ่ายที่สูงขึ้น

จัดโครงสร้าง JSON อย่างระมัดระวัง ตรวจสอบให้แน่ใจว่าฟิลด์ที่จำเป็นทั้งหมดมีอยู่ และฟิลด์ที่ไม่บังคับจะถูกเพิ่มเฉพาะเมื่อจำเป็น ตัวอย่างเช่น หากคุณไม่ต้องการสตรีมมิง อย่ารวมพารามิเตอร์ stream นี้จะลดขนาด payload และทำให้การตอบสนองง่ายขึ้น

ใช้เครื่องมือเช่น curl หรือ Postman เพื่อทดสอบ request body ของคุณ สิ่งนี้ช่วยให้คุณตรวจสอบว่า JSON นั้นถูกต้องและ API กำลังตีความมันอย่างถูกต้อง นอกจากนี้ยังช่วยให้คุณระบุข้อมูลที่ไม่จำเป็นที่กำลังถูกส่งได้

สุดท้าย พิจารณาการแคชการตอบสนองสำหรับคำขอที่เหมือนกัน หากคุณกำลังส่งพรอมต์เดียวกันหลายครั้ง คุณสามารถเก็บการตอบสนองไว้ในเครื่องและหลีกเลี่ยงการทำ API call อีกครั้ง สิ่งนี้สามารถลด latency และต้นทุนสำหรับงานที่ทำซ้ำได้อย่างมีนัยสำคัญ

การดีบักการเรียกใช้ฟังก์ชัน

การเรียกใช้ฟังก์ชันช่วยให้โมเดลสามารถเรียกใช้ฟังก์ชันตามอินพุตของผู้ใช้ การดีบักการเรียกใช้ฟังก์ชันอาจเป็นเรื่องท้าทายเพราะเกี่ยวข้องกับหลายขั้นตอน: ส่งคำขอ รับการเรียกใช้ฟังก์ชัน เรียกใช้ฟังก์ชัน และส่งผลลัพธ์กลับไปยังโมเดล

ตรวจสอบให้แน่ใจว่าคำจำกัดความของฟังก์ชันของคุณถูกต้อง สคีมาต้องตรงกับลายเซ็นของฟังก์ชันจริง หากสคีมาไม่ถูกต้อง โมเดลอาจสร้างอาร์กิวเมนต์ที่ไม่ถูกต้อง นำไปสู่ข้อผิดพลาดเมื่อคุณพยายามเรียกใช้ฟังก์ชัน

บันทึกอาร์กิวเมนต์ของการเรียกใช้ฟังก์ชันและผลลัพธ์ของฟังก์ชัน สิ่งนี้ช่วยให้คุณตรวจสอบว่าโมเดลกำลังสร้างอาร์กิวเมนต์ที่ถูกต้องและฟังก์ชันของคุณกำลังทำงานตามที่คาดไว้ หากมีข้อผิดพลาด บันทึกจะช่วยคุณระบุปัญหา

จัดการข้อผิดพลาดอย่างสุภาพ หากการเรียกใช้ฟังก์ชันล้มเหลว ให้ส่งข้อความข้อผิดพลาดกลับไปยังโมเดลเพื่อให้มันปรับการตอบสนอง สิ่งนี้ให้ประสบการณ์ผู้ใช้ที่ดีขึ้นและช่วยให้โมเดลกู้คืนจากข้อผิดพลาดได้