Heretic LLM: ข้อผิดพลาดทั่วไปในการผสานรวม

ทำไมการตอบสนองแบบสตรีมของคุณค้าง

การส่งแบบสตรีมมิ่งค้างเมื่อไคลเอนต์ไม่สามารถอ่านชิ้นส่วน Server-Sent Event (SSE) สุดท้ายที่มีข้อมูลการใช้โทเค็น API ของเราส่งโทเค็นเมื่อถูกสร้างขึ้น แต่การเชื่อมต่อจะปิดสมบูรณ์หลังจากชิ้นสุดท้ายมาถึง หากโค้ดไคลเอนต์ของคุณตัดการเชื่อมต่อเร็วเกินไปหรือละเลยชิ้นสุดท้าย คุณจะเสียจำนวนโทเค็นที่แน่นอนซึ่งจำเป็นสำหรับการตรวจสอบการเรียกเก็บเงิน

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

กับดักที่พบบ่อย

• การละเลยเหตุการณ์ SSE สุดท้าย
• ตั้งค่าเวลาหมด (Timeout) ต่ำเกินไปสำหรับการสร้างข้อความที่ยาว
• ไม่จัดการ JSON บางส่วนในโหมดสตรีม

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

Handling JSON Mode Errors in Production

ข้อผิดพลาดของโหมด JSON เกิดขึ้นเพราะโมเดลอาจสร้างข้อความหลังจากวงเล็บปีกกาปิด ซึ่งละเมิดกฎการแยกวิเคราะห์ JSON ที่เข้มงวด เมื่อคุณตั้งค่า response_format เพื่อ {"type": "json_object", โมเดลพยายามส่งออก JSON ที่ถูกต้อง แต่มักเพิ่มข้อความสนทนาเช่น 'นี่คือข้อมูล:' หลังวงเล็บปิด จากนั้น parser ของคุณจะล้มเหลวเนื่องจากข้อความส่วนเกิน

ตัดข้อความส่วนเกินหลังวงเล็บปีกกาปิดที่ถูกต้องสุดท้าย อย่าพึ่งพาโมเดลให้หยุดพอดีที่โครงสร้าง JSON คุณต้องดำเนินการประมวลผลหลังการรับข้อมูลเพื่อหา '}' หรือ ']' ตัวสุดท้ายแล้วตัดส่วนหลังออก สิ่งนี้สำคัญมากเมื่อทำการวิเคราะห์อาร์เรย์หรือวัตถุซ้อนกัน

แนวทางปฏิบัติที่ดีที่สุด

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

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

Understanding Context Window Limits

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

คำนวณพื้นที่เอาต์พุตที่เหลือของคุณโดยการลบจำนวนโทเค็นอินพุตออกจาก 100,000 หากคุณส่งระบบ prompt ขนาดใหญ่หรือประวัติข้อความที่ยาว พื้นที่เอาต์พุตที่เหลือของคุณจะลดลงตามลำดับ สิ่งนี้สำคัญมากสำหรับแอปพลิเคชันที่รักษาประวัติการสนทนาที่ยาวนาน

ตัวอย่างการคำนวณ

• หน้าต่างรวม: 100,000 โทเค็น
• Token Input: 20,000 tokens.
• เอาต์พุตสูงสุด: 80,000 โทเค็น

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

การนับโทเค็นและการประมาณการต้นทุน

การประมาณต้นทุนต้องคำนึงถึงความแตกต่างของราคาระหว่าง input tokens และ output tokens โดย input tokens มีราคา $0.15 ต่อ 1M tokens ในขณะที่ output tokens มีราคา $0.50 ต่อ 1M tokens ซึ่ง output tokens มีราคาสูงกว่ามาก ดังนั้นการสร้าง response ยาวจะเพิ่มต้นทุนของคุณเร็วกว่าการส่ง prompt ยาว

ประมาณการค่าใช้จ่ายของคุณโดยการคูณจำนวน tokens ที่คาดหวังกับราคาที่เกี่ยวข้อง ตัวอย่างเช่น 10,000 input tokens และ 5,000 output tokens จะมีค่าใช้จ่าย: (10,000/1,000,000 * $0.15) + (5,000/1,000,000 * $0.50) ซึ่งเท่ากับ $0.0015 + $0.0025 = $0.004 ต่อการเรียกใช้

ตารางราคา

ประเภทของโทเค็น	ราคาต่อ 1M โทเค็น
ข้อมูลนำเข้า	$0.15
ผลลัพธ์	$0.50

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

อัตราจำกัด: อธิบาย 300 RPM

อัตราการใช้งานจำกัดคำขอของคุณไว้ที่ 300 คำขอต่อนาทีต่อคีย์ API ครอบคลุมคำขอทั้งหมดโดยไม่คำนึงถึงขนาด payload หรือจำนวน tokens หากเกินขีดจำกัดนี้ API จะส่งกลับข้อผิดพลาด 429 คุณต้องนำไปใช้ exponential backoff เพื่อจัดการข้อผิดพลาดเหล่านี้อย่างราบรื่น

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

Handling 429 Errors

• เพิ่มการหน่วงเวลาแบบเอ็กซ์โพเนนเชียล
• บันทึกคำขอที่ล้มเหลวสำหรับการวิเคราะห์
• ลดความพร้อมใช้งานหากพบข้อจำกัดบ่อยครั้ง

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

การแก้ปัญหา Function Calling Failure

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

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

ขั้นตอนการแก้ไขข้อผิดพลาด

• ตรวจสอบไวยากรณ์ tool definition
• ตรวจสอบประเภทและค่าของอาร์กิวเมนต์
• ทบทวนผลลัพธ์ของโมเดลสำหรับฟิลด์ที่หายไป

การเรียกฟังก์ชันเป็นฟีเจอร์ที่มีประสิทธิภาพ แต่ต้องการการออกแบบสคีมาอย่างระมัดระวัง โมเดลแบบ uncensored อาจมีความสม่ำเสมอต่ำกว่ากับคำจำกัดเครื่องมือเมื่อเทียบกับโมเดลที่มีตัวกรอง ดังนั้นการตรวจสอบอย่างเข้มงวดจึงเป็นสิ่งจำเป็น

ทำไม 'แบบไม่มีเซนเซอร์' จึงไม่ได้หมายความว่าไม่มีขีดจำกัด

ป้ายกำกับ 'uncensored' หมายความว่าโมเดลจะไม่ปฏิเสธหัวข้อผู้ใหญ่ตามกฎหมาย นามธรรม หรือหัวข้อถกเถียง แต่ยังคงมีขีดจำกัดแข็งสำหรับเนื้อหาทางเพศที่เกี่ยวข้องกับเด็ก นี่คือข้อจำกัดเนื้อหาแข็งเดียวที่บังคับใช้เสมอ คำขอที่มีเนื้อหาดังกล่าวจะถูกปฏิเสธ แม้ส่วนที่เหลือของ prompt จะถูกต้องสมบูรณ์

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

ขีดจำกัดเนื้อหา

• ไม่มีเนื้อหาทางเพศที่เกี่ยวข้องกับเด็ก
• เนื้อหาผู้ใหญ่กฎหมายอนุญาต
• ข้อผิดพลาดทางเทคนิคยังคงทำให้เกิดการปฏิเสธได้

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

การแก้ไขข้อผิดพลาด 400 เทียบกับ 429

ข้อผิดพลาด 400 บ่งชี้ถึงปัญหาในตัวคำขอเอง เช่น JSON ไม่ถูกต้อง ช่องว่างที่จำเป็นขาดหาย หรือเกินขีดจำกัดขนาด body คำขอ 8 MB ข้อผิดพลาด 429 บ่งชี้ว่าคุณได้เกินอัตราจำกัด 300 คำขอต่อนาที การแยกแยะข้อผิดพลาดเหล่านี้ช่วยให้คุณแก้ไขปัญหาที่ถูกต้องได้รวดเร็ว

สำหรับข้อผิดพลาด 400 ตรวจสอบ payload และ schema ของคำขอของคุณ สำหรับข้อผิดพลาด 429 ให้ใช้ backoff และลดความพร้อมใช้งาน หากได้รับข้อผิดพลาด 400 พร้อมข้อความเกี่ยวกับขนาด body ของคำขอ ให้แน่ใจว่าคุณไม่ได้ส่งข้อมูลมากเกินไปในคำขอเดียว ขีดจำกัด 8 MB นั้นเข้มงวด

รหัสข้อผิดพลาด

รหัสข้อผิดพลาด	ความหมาย
400	คำขอผิดพลาด
429	เกินอัตราจำกัด

การบันทึกข้อผิดพลาดเหล่านี้พร้อมบริบท (payload, timestamp) ทำให้การแก้ไขข้อบกพร่องง่ายขึ้นมาก ใช้ข้อมูลนี้เพื่อปรับปรุงการผสานรวมของคุณและหลีกเลี่ยงความล้มเหลวซ้ำ

ขั้นตอนถัดไปสำหรับการปรับแต่ง Heretic LLM

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

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

เคล็ดลับการปรับประสิทธิภาพ

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

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