Rivya API คืออะไร?

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

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

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

ฉบับสั้น

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

สัญญา API ที่ระบบรองรับมี:

• การค้นหาโมเดลผ่านรายการโมเดลของ API

• งานสร้างภาพ วิดีโอ และเสียงแบบอะซิงโครนัส

• การอัปโหลดผ่าน ไฟล์ API สำหรับโมเดลที่ต้องใช้สื่ออ้างอิง

• การตรวจสถานะงานสร้างซ้ำด้วยรหัสงานสาธารณะ

• การตรวจเครดิตบัญชี

• การสนทนา API รอบสนทนา รวมถึง SSE การสตรีม ที่เลือกใช้ได้

• ที่ลงชื่อเข้าใช้ เว็บฮุก สำหรับ การสร้าง การทำงานเสร็จ เมื่อ ระบบที่นำไปใช้งาน เปิดใช้ เว็บฮุก

• TypeScript SDK รุ่นทดสอบสำหรับทีมที่ต้องการไคลเอนต์สำเร็จรูป

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

ทำไม Rivya ต้องมี API

Studio มีประโยชน์เมื่อคนยังเลือกโมเดล ปรับพรอมต์ รีวิวผลลัพธ์ และตัดสินใจว่าจะทำอะไรต่อ

API มีประโยชน์เมื่อการตัดสินใจนั้นกลายเป็นเวิร์กโฟลว์ของผลิตภัณฑ์หรือการปฏิบัติการที่ทำซ้ำได้

เมื่อเปิดสิทธิ์ใช้ API แล้ว ตัวอย่างที่พบบ่อยได้แก่:

• ผลิตภัณฑ์ต้องการสร้างรูปแบบ ภาพ หลังจากผู้ใช้ส่ง โจทย์

• เวิร์กโฟลว์การตลาดต้องสร้าง ภาพ ฉบับร่าง จาก แคมเปญ ข้อมูลนำเข้า ที่มีโครงสร้าง

• เครื่องมือภายในต้องส่งงานวิดีโอหรือเสียงโดยไม่ต้องให้ใครเปิดเบราว์เซอร์

• ระบบ รองรับ หรือ เนื้อหา ต้องการหนึ่ง การสนทนา โมเดล รอบสนทนา ภายใน ส่วนติดต่อ ของตัวเอง

• บริการฝั่งระบบต้องการการเรียกกลับแบบลงลายเซ็นเมื่องานสร้างเสร็จ

ในกรณีเหล่านี้ Rivya API ช่วยให้งานยังเชื่อมกับบัญชี Rivya เดียวกัน แทนที่จะต้องแยกระบบสำหรับการเรียกเก็บเงิน การเลือกโมเดล และสถานะงาน

API ไม่ได้แทนที่อะไร

API ไม่ได้แทนที่เหตุผลทั้งหมดในการใช้ Rivya โดยตรง

ใช้ Studio หรือพื้นผิวงานสาธารณะเมื่อ:

• พรอมต์ ยังต้องให้มนุษย์สำรวจ

• การเลือกโมเดลยังไม่นิ่ง

• ครีเอเตอร์ต้องเปรียบเทียบผลลัพธ์ด้วยสายตา

• โปรเจกต์ต้องอาศัยประวัติที่บันทึกไว้และการตรวจทานโดยมนุษย์

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

ใช้ API เมื่อเวิร์กโฟลว์ชัดพอที่จะทำให้เป็นอัตโนมัติ

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

ส่วนประกอบหลัก

ให้คิดว่า API เป็นชิ้นส่วนที่เชื่อมกัน 6 ส่วน

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

เครดิตทำงานอย่างไร

การใช้งาน API ดึงจากกระเป๋าเครดิตบัญชี Rivya เดียวกับ Studio

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

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

ไฟล์เข้ามาเกี่ยวข้องอย่างไร

บางโมเดลรันจากข้อความอย่างเดียวได้ บางโมเดลต้องใช้ ภาพอ้างอิง, วิดีโอ หรือ เสียง ไฟล์

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

กฎเชิงปฏิบัติง่าย ๆ คือ:

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

• ถ้าโมเดลต้องใช้ ข้อมูลอ้างอิง สื่อ ให้อัปโหลดไฟล์ก่อน

• หากโมเดลแชตต้องใช้ไฟล์ภาพแนบ ให้ใช้ Chat API และรหัสไฟล์

อย่าออกแบบการเชื่อมต่อโดยพึ่งขั้นตอนอัปโหลดที่ใช้ได้เฉพาะในเบราว์เซอร์หรือเซสชัน Studio ที่บันทึกไว้ API มีขอบเขตไฟล์สาธารณะของตัวเองเพื่อให้การเชื่อมต่อทำงานได้อย่างชัดเจน

เว็บฮุก ช่วยตรงไหน

การตรวจสถานะซ้ำ คือเส้นทาง การเชื่อมต่อ แรกที่ง่ายที่สุด ส่ง การสร้าง งาน, บันทึก สาธารณะ งาน ID แล้ว ตรวจสถานะซ้ำ จนสำเร็จหรือล้มเหลว

เมื่อ ระบบที่นำไปใช้งาน เปิดใช้ เว็บฮุก ฟีเจอร์นี้จะมีประโยชน์ขึ้นเมื่อ การเชื่อมต่อ เข้าใกล้งาน การผลิต:

• คุณไม่ต้องการให้ตัวประมวลผลงานตรวจสถานะของทุกงานซ้ำๆ

• แอปต้องอัปเดต บันทึก เมื่อ การสร้าง เสร็จ

• คุณต้องการเหตุการณ์ที่ลงลายเซ็นและรองรับการลองใหม่อย่างปลอดภัย

• งาน ที่ล้มเหลวต้องเข้าสู่ การกู้คืน เส้นทาง ที่ชัดเจน

สำหรับสัญญาเชื่อมต่อด้วยเหตุการณ์แบบลงลายเซ็น ให้ใช้ เว็บฮุก API และยืนยันก่อนว่าฟีเจอร์พร้อมใช้งาน จากนั้นให้ตัวรับเว็บฮุกทำหน้าที่เฉพาะที่จำเป็น: ตรวจลายเซ็น รองรับเหตุการณ์ซ้ำ และไม่บันทึกค่าลับลงในบันทึกระบบ

โปรเจกต์ API แรกที่ดี

โปรเจกต์ API แรกที่ดีที่สุดมักเล็กและเป็นรูปธรรม

ตัวอย่าง:

1. ยืนยันว่า ระบบที่นำไปใช้งาน และบัญชีเปิดสิทธิ์ใช้ API

2. สร้าง API คีย์ ใน การตั้งค่า

3. เรียกรายการโมเดล

4. เลือกโมเดลที่พร้อมใช้ผ่าน API หนึ่งตัว

5. ส่ง การสร้าง งาน หนึ่งงานพร้อม idempotency คีย์

6. ตรวจสถานะซ้ำ จุดเชื่อมต่อ สถานะ

7. ตรวจเครดิตก่อนและหลัง

8. หลังจากนั้นค่อยเพิ่ม ไฟล์ API, การสนทนา API หรือ เว็บฮุก ที่ ระบบที่นำไปใช้งาน เปิดให้ใช้

เส้นทางนี้ให้ การเชื่อมต่อ ที่ใช้งานได้โดยไม่ต้องผสมทุกฟีเจอร์ API เข้าไปในการทดสอบแรก

เมื่อไหร่ API ไม่ใช่จุดเริ่มที่ถูกต้อง

API อาจไม่ใช่ขั้นแรกที่ถูกต้องเมื่อ:

• ทีมยังไม่ได้เลือก โมเดล ชุด

• ผลลัพธ์ ที่ต้องการยังเปลี่ยนทุกการรัน

• พรอมต์ พึ่งพารสนิยมและการรีวิวของมนุษย์มาก

• การเชื่อมต่อ จะซ่อนการใช้เครดิตจากคนที่ต้องเข้าใจมัน

• ผลิตภัณฑ์ต้องมีตัวอย่างใช้งานแบบสาธารณะก่อนทำระบบอัตโนมัติ

ในกรณีเหล่านี้ เริ่มจาก ภาพ, วิดีโอ, เสียง, การสนทนา หรือ AI โมเดล เมื่อเส้นทางทำซ้ำได้แล้ว ค่อยย้ายส่วนที่นิ่งไป API

ไปต่อที่ไหน

• เปิด นักพัฒนา เพื่อดูศูนย์รวม API และเครื่องมือตรวจสอบสาธารณะ

• อ่าน คู่มือเริ่มต้นใช้งาน Rivya API เพื่อส่งคำขอแรกอย่างปลอดภัย

• อ่าน API การยืนยันตัวตน ก่อนวาง คีย์ บน เซิร์ฟเวอร์

• อ่าน โมเดล API ก่อนเลือกรหัสโมเดล

• อ่าน ควรใช้ Rivya API หรือ Studio เมื่อใด หากขอบเขตผลิตภัณฑ์ยังไม่ชัด

• อ่าน วิธีสร้างเวิร์กโฟลว์ AI หลายรูปแบบด้วย Rivya API เมื่อวางแผนเชื่อมต่อระบบเต็มรูปแบบสำหรับภาพ วิดีโอ เสียง หรือแชต