Dolphin ai Production Checklist

1. ตรวจสอบความเข้ากันได้ของ Endpoint ที่เข้ากันได้กับ OpenAI

เริ่มโดยการยืนยันว่าโครงสร้างจุดปลายตรงกับรูปแบบ chat-completions มาตรฐานของ OpenAI API ของเราปฏิบัติตามสchemanี้อย่างเคร่งครัด ดังนั้นคุณจึงสามารถใช้ SDK ที่มีอยู่โดยไม่ต้องเขียนตัวห่อแบบกำหนดเอง URL พื้นฐานคือ HTTPS://api.dolphinmodelos.com/v1 และคุณต้องตั้งค่า id โมเดลเป็น "uncensored" ในทุกคำขอ สิ่งนี้ช่วยให้คุณเข้าถึงเครื่องยนต์อนุมานแบบไม่มีเซนเซอร์เฉพาะทางแทนที่จะเป็นตัวรวมที่กำหนดเส้นทาง

• ใช้ SDK ภาษา Python หรือ Node.js ทางการของ OpenAI
• แทนที่ URL พื้นฐานเพื่อชี้ไปยังเอนด์พอยต์ของเรา
• ส่งคีย์ API ของคุณในหัว Authorization

แนวทางนี้ขจัดความต้องการตรรกะเฉพาะของผู้ขาย คุณกำลังเชื่อมต่อโดยตรงกับ large language model uncensored การตอบสนองจะปฏิบัติตามโครงสร้าง JSON มาตรฐาน ไม่มีตรรกะการเปลี่ยนเส้นทางซ่อนหรือฟิลด์ที่เป็นกรรมสิทธิ์ที่จะทำลาย parser ของคุณ

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

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

ตรวจสอบจุดสิ้นสุด GET /v1/models เพื่อยืนยันว่า id ของโมเดลถูกจัดประเภทเป็น "uncensored" นี่คือจุดอ้างอิงหลักสำหรับการเรียกใช้ทั้งหมดในขั้นตอนถัดไป

2. นำการจัดการข้อผิดพลาดการสตรีมที่แข็งแกร่งไปใช้

ข้อผิดพลาดในการสตรีมเป็นจุดล้มเหลวที่พบบ่อยที่สุดในการผสานรวม LLM แบบผลิต คุณต้องจัดการสตรีม Server-Sent Events (SSE) อย่างระมัดระวัง ก้อนข้อมูลสุดท้ายมีข้อมูลการใช้โทเค็น แต่ข้อผิดพลาดอาจปรากฏในก้อนข้อมูลก่อนหน้าได้เช่นกัน

• ฟังประเภทเหตุการณ์ "error"
• แยกวิเคราะห์ชิ้นสุดท้ายเพื่อรับสถิติการใช้งาน
• จัดการเวลาหมดอายุของเครือข่ายอย่างสุภาพ

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

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

อย่าละเลยส่วนสุดท้าย มันนับจำนวนโทเค็นที่ต้องเสียเงิน

ตั้งค่าเวลาหมดอายุ (timeout) 30 วินาทีสำหรับแต่ละชิ้น หากชิ้นหนึ่งใช้เวลานานกว่านั้น ให้สันนิษฐานว่าการเชื่อมต่อตายแล้ว วิธีนี้ป้องกันไม่ให้แอปพลิเคชันของคุณค้าง indefinitely API ไม่รับประกันความล่าช้าเฉพาะเจาะจง ดังนั้นจงสร้างความยืดหยุ่น

ใช้ SDK ทางการซึ่งจัดการสิ่งนี้ส่วนใหญ่โดยอัตโนมัติ แต่หากคุณกำลังเขียนการเรียก HTTP โดยตรง ให้แยกวิเคราะห์รูปแบบ SSE ด้วยตนเอง มองหาส่วนนำหน้า "data:" และแยกวิเคราะห์ JSON

3. จัดการหน้าต่างบริบทและขีดจำกัดโทเค็น

หน้าต่างบริบทจำกัดอยู่ที่ 100,000 tokens สำหรับ prompt และ completion รวมกัน ซึ่งเป็นขีดจำกัดแข็งสำหรับโมเดล uncensored หาก input ของคุณเกินขีดจำกัดนี้ API จะส่ง error

• คำนวณจำนวนโทเค็นก่อนส่ง
• ติดตามความยาวของ prompt อย่างระมัดระวัง
• ตั้งค่าขีดจำกัด max_tokens สำหรับเอาต์พุต

การส่งออกสูงสุดต่อคำขอคือ 16,000 tokens หากคุณไม่ได้ตั้งค่า max_tokens ค่าเริ่มต้นคือ 2,048 tokens นี่เป็นค่าเริ่มต้นที่ปลอดภัยสำหรับกรณีการใช้งานส่วนใหญ่

อย่างไรก็ตาม สำหรับเนื้อหาแบบยาว คุณต้องเพิ่มขีดจำกัดนี้ โปรดทราบว่าผลลัพธ์ที่ยาวขึ้นจะใช้เครดิตมากขึ้น ราคาคือ $0.15 ต่อ 1M input tokens และ $0.50 ต่อ 1M output tokens การกำหนดราคานี้โปร่งใสและคาดการณ์ได้

คำนวณการใช้งานโทเค็นก่อนส่งคำขอขนาดใหญ่ คำขอขนาด 50k โทเค็นจะเหลือพื้นที่สำหรับเอาต์พุตเพียง 50k เท่านั้น

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

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

4. กำหนดค่า Function Calling สำหรับการใช้งานเครื่องมือ

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

• กำหนดสคีมาฟังก์ชันของคุณในคำขอ
• ตั้งค่า tool_choice เป็น "auto" หรือ "required"
• แยกวิเคราะห์อาร์กิวเมนต์การเรียกใช้ฟังก์ชันอย่างระมัดระวัง

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

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

ทดสอบการเรียกใช้ฟังก์ชันกับกรณีขอบเขต โมเดลอาจสร้างอาร์กิวเมนต์ขึ้นเองหากไม่มีการจำกัด

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

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

5. Validate JSON Mode Constraints

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

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

โมเดล uncensored เคารพข้อจำกัดนี้ดี มันจะไม่เพิ่ม markdown หรือข้อความเพิ่มเติมนอกเหนือจาก JSON ทำให้การ parse มีความน่าเชื่อถือและรวดเร็ว

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

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

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

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

6. ตรวจสอบขีดจำกัดอัตราและความพร้อมใช้งาน

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

• ตรวจสอบจำนวนคำขอของคุณต่อนาที
• 将并发请求限制为 8。
• จัดการข้อผิดพลาด 429 Too Many Requests

หากคุณเกินขีดจำกัดเหล่านี้ API จะส่งข้อผิดพลาด 429 กลับมา คุณควรใช้กลไกการลองใหม่แบบทวีคูณ (exponential backoff) ในตรรกะการลองซ้ำของคุณ

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

ใช้ Circuit Breaker สำหรับข้อจำกัดอัตรา (rate limit errors) เพื่อป้องกันความล้มเหลวแบบต่อเนื่อง

สิ่งนี้ช่วยให้แอปพลิเคชันของคุณมีความเสถียร API ไม่มีการอนุญาตให้ใช้งานแบบ burst ดังนั้นควรวางแผนปริมาณการจราจรของคุณ accordingly

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

7. ตรวจสอบความสอดคล้องของนโยบายเนื้อหา

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

• ตรวจสอบเนื้อหาที่เกี่ยวข้องกับเด็กใน prompts ของคุณ
• คาดหวังไม่มีการปฏิเสธสำหรับหัวข้อผู้ใหญ่อื่นๆ
• ตรวจสอบเอาต์พุตสำหรับกรณีการใช้งานเฉพาะของคุณ

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

อย่างไรก็ตาม คำว่า "uncensored" ไม่ได้หมายความว่า "ไม่มีการกรอง" โมเดลอาจยังคงสร้างเนื้อหาที่มีคุณภาพต่ำหรือไม่เกี่ยวข้อง คุณอาจต้องประมวลผลผลลัพธ์หลังการส่งมอบ

กำหนดขอบเขตเนื้อหาของคุณเอง API จะบังคับใช้ขีดจำกัดเล็กน้อยเท่านั้น

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

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

8. ปรับโครงสร้างพรอมต์ให้เหมาะสมกับความยาว

โครงสร้างของ prompt ส่งผลต่อทั้งประสิทธิภาพและต้นทุน Prompt ยาวใช้โทเค็นมากขึ้นและเพิ่มเวลาแฝง หากเป็นไปได้ ให้แบ่ง prompt ของคุณออกเป็นชิ้นเล็กๆ

• รักษาพรอมต์ระบบให้กระชับ
• ใช้ตัวอย่าง few-shot อย่างระมัดระวัง
• ลบช่องว่างที่ไม่จำเป็น

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

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

ทดสอบโครงสร้างพรอมต์ที่แตกต่างกัน การเปลี่ยนแปลงเล็กน้อยสามารถปรับปรุงคุณภาพผลลัพธ์ได้อย่างมีนัยสำคัญ

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

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

9. ทดสอบด้วยพรอมต์ Uncensored ที่เป็นตัวแทน

การทดสอบเป็นขั้นตอนสุดท้ายก่อนการปรับใช้ ใช้พรอมต์ที่สะท้อนกรณีการใช้งานจริงของคุณ ทดสอบทั้งกรณีมาตรฐานและกรณีขอบเขต

• ส่งประเภทของ prompt หลากหลายประเภท
• ตรวจสอบความสม่ำเสมอของการตอบกลับ
• ตรวจสอบการจัดการข้อผิดพลาด

โมเดล uncensored ควรจัดการหัวข้อที่หลากหลาย ทดสอบด้วยหัวข้อที่ถกเถกันหรือธีมผู้ใหญ่เพื่อให้แน่ใจว่าไม่มีการปฏิเสธ

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

ทดสอบด้วยข้อมูลจริงของคุณ ข้อมูลสังเคราะห์อาจไม่เผยปัญหาทั้งหมด

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

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