เมื่อไหร่ควรใช้ Rivya API แทน Studio

ความผิดพลาดที่ง่ายที่สุดคือมอง Rivya API และ Rivya Studio เป็นเส้นทางที่แข่งกัน

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

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

หากยังทำความรู้จัก API ให้เริ่มจาก Rivya API คืออะไร ส่วนหน้านี้เจาะจงที่การตัดสินว่างานหนึ่งควรอยู่ใน Studio หรือ API

การตัดสินใจในตารางเดียว

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

ใช้ Studio เมื่องานยังเปลี่ยนอยู่

Studio คือที่ที่ถูกต้องเมื่อการตัดสินใจของมนุษย์ยังเป็นงานหลัก

รวมถึง:

• เลือกระหว่างโมเดล ภาพ, วิดีโอ, เสียง หรือ การสนทนา

• ทดสอบว่าทิศทางพรอมต์ควรเก็บไว้หรือไม่

• เปรียบเทียบผลลัพธ์ภาพแบบเคียงข้างกัน

• ตัดสินว่าสื่ออ้างอิงช่วยหรือทำให้แย่ลง

• ใช้ประวัติที่บันทึกไว้เพื่อทำต่อจากผลลัพธ์ก่อนหน้า

เรื่องนี้จริงเป็นพิเศษสำหรับงานครีเอทีฟ หากบรีฟยังไม่นิ่ง การทำคำขอให้เป็นอัตโนมัติมักทำให้ความสับสนเร็วขึ้น ไม่ได้ทำให้เล็กลง

ใช้ API เมื่อเวิร์กโฟลว์ทำซ้ำได้

API จะเป็นเส้นทางที่ดีกว่าเมื่ออินพุตและขั้นต่อไปคาดเดาได้พอ

สัญญาณที่ดี:

• ผลิตภัณฑ์ของคุณรู้อยู่แล้วว่าต้องใช้โมเดลหรือหมวดโมเดลใด

• อินพุตของผู้ใช้สามารถแปลงเป็นเนื้อหาคำขอที่มีโครงสร้างคงที่ได้

• งานฝั่งระบบสามารถตรวจสถานะซ้ำได้โดยไม่ต้องมีคนเฝ้าหน้าจอ

• เว็บฮุก ที่เปิดใช้งานสามารถอัปเดต บันทึก ที่ถูกต้องเมื่องานเสร็จ

• แอปอธิบายการใช้เครดิตให้ทีมหรือเจ้าของบัญชีเข้าใจได้

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

ขอบเขตที่ใช้ได้จริง: การค้นหา เทียบกับการเชื่อมต่อ

ใช้ Studio สำหรับ การสำรวจ

ใช้ API สำหรับ การเชื่อมต่อ

การสำรวจ หมายถึง:

• "ควรใช้โมเดลไหน?"

• "รูปทรงพรอมต์แบบไหนใช้ได้?"

• "สื่ออ้างอิงช่วยงานนี้หรือไม่?"

• "คุณภาพผลลัพธ์ดีพอสำหรับกรณีใช้งานนี้หรือยัง?"

การเชื่อมต่อ หมายถึง:

• "การกระทำของผู้ใช้นี้ควรสร้าง การสร้าง งาน หนึ่งงาน"

• "งานนี้ควรลองใหม่ได้อย่างปลอดภัยโดยไม่เกิดรายการซ้ำ"

• "ไฟล์นี้ควรถูกอัปโหลดและแนบกับ คำขอ ของโมเดล"

• "งานที่เสร็จแล้วนี้ควรอัปเดต ผลิตภัณฑ์ บันทึก ของเรา"

ขอบเขตนี้ช่วยกันไม่ให้ API กลายเป็นพื้นผิวทดลองที่ซ่อนอยู่

เครดิตควรมีผลต่อการตัดสินใจอย่างไร

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

นั่นหมายความว่าพฤติกรรมเครดิตควรเป็นส่วนหนึ่งของการออกแบบผลิตภัณฑ์ ไม่ใช่สิ่งที่ค่อยอธิบายทีหลัง

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

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

จุดที่ไฟล์เปลี่ยนการเลือก

สื่ออ้างอิงมักเป็นจุดที่ การเชื่อมต่อ จริงจังขึ้น

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

ใช้ Studio เมื่อ:

• ภาพ วิดีโอ หรือเสียงอ้างอิงยังต้องให้คนทำความสะอาด

• ทีมยังไม่แน่ใจว่า ข้อมูลอ้างอิง ใดควรนำทางโมเดล

• กฎเรื่องไฟล์ยังอธิบายให้ผู้ใช้ชัดเจนไม่ได้

ใช้ API เมื่อ:

• แอปเก็บไฟล์ได้อย่างปลอดภัย

• ข้อกำหนดด้านข้อมูลอ้างอิงของโมเดลชัดเจนแล้ว

• อัปโหลดไฟล์ก่อน การสร้าง หรือ การสนทนา คำขอ ได้

• แสดง ข้อผิดพลาด ในผลิตภัณฑ์ของคุณเองได้โดยไม่ซ่อนสิ่งที่เกิดขึ้น

ไฟล์ API เป็นสะพานที่มีประโยชน์ แต่มันไม่ได้ตัดความจำเป็นในการออกแบบประสบการณ์ไฟล์ออกไป

จุดที่ การสนทนา เปลี่ยนการเลือก

การสนทนา อาจอยู่ได้ทั้งสองฝั่ง

ใช้ Rivya การสนทนา โดยตรงเมื่อคนกำลังสำรวจ เขียน รีวิว หรือตัดสินใจ

ใช้ การสนทนา API เมื่อ การสนทนา รอบสนทนา ต้องอยู่ในผลิตภัณฑ์ของคุณเองหรือ ขั้นตอนการทำงาน ฝั่ง เซิร์ฟเวอร์ ซึ่งอาจรวมถึง รอบสนทนา แบบ แบบไม่สตรีม, SSE การสตรีม ที่เลือกใช้ได้, เซสชัน ที่สร้างผ่าน API และไฟล์แนบที่รองรับ

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

เมื่อ เว็บฮุก เป็นสัญญาณ

หากเวิร์กโฟลว์ต้องใช้ เว็บฮุก API งานก็น่าจะผ่านช่วงทดลองด้วยตนเองใน Studio แล้ว แต่ก่อนนำไปใช้จริง ต้องยืนยันว่าระบบที่นำไปใช้เปิดใช้งานเว็บฮุก

เว็บฮุก มีประโยชน์เมื่อระบบอื่นต้องตอบสนองต่องาน การสร้าง ที่เสร็จแล้ว:

• ทำเครื่องหมายว่าชิ้นงานพร้อมใช้

• แจ้งผู้ใช้

• ขยับขั้นรีวิวไปข้างหน้า

• ส่งงานที่ล้มเหลวเข้าสู่กระบวนการช่วยเหลือหรือตรรกะการลองใหม่

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

รูปแบบย้ายงานที่ปลอดภัย

อย่าย้ายทั้งเวิร์กโฟลว์เข้า API ทีเดียว

ใช้ลำดับนี้:

1. ทดสอบงานด้วยมือใน Studio

2. จดโมเดลที่นิ่ง รูปทรงพรอมต์ ไฟล์อินพุต และผลลัพธ์ที่คาดหวัง

3. อ่าน API โมเดล และ โมเดล ข้อมูลอ้างอิง

4. ส่งงานสร้างหนึ่งงานตาม คู่มือเริ่มต้น API

5. เพิ่ม ไฟล์ API เฉพาะเมื่อโมเดลต้องใช้สื่ออ้างอิง

6. เพิ่ม เว็บฮุก หลัง การตรวจสถานะซ้ำ ใช้งานได้และเปิดสิทธิ์ใช้ เว็บฮุก แล้วเท่านั้น

7. เพิ่ม การสนทนา API เฉพาะเมื่อผลิตภัณฑ์ต้องใช้ การสนทนา รอบสนทนา นอก Studio

แต่ละขั้นควรทำให้เวิร์กโฟลว์ปฏิบัติการง่ายขึ้น ไม่ใช่แค่อัตโนมัติมากขึ้น

เมื่อไหร่ควรอยู่ใน Studio ต่อ

อยู่ใน Studio ต่อเมื่องานยังต้องใช้:

• การรีวิวเชิงความรู้สึก

• การจัดรูปพรอมต์

• การเปรียบเทียบภาพ

• การสำรวจโมเดล

• ประวัติครีเอทีฟที่บันทึกไว้

• คนตัดสินว่าขั้นต่อไปควรเป็น ภาพ, วิดีโอ, เสียง หรือ การสนทนา

นี่ไม่ใช่จุดอ่อน Studio ถูกออกแบบมาสำหรับช่วงนี้

เมื่อไหร่ควรย้ายไป API

ย้ายไป API เมื่อ:

• งานเดิมเกิดซ้ำบ่อย

• อินพุตจัดโครงสร้างได้

• โมเดลชัดเจนแล้ว

• แอปต้องสร้างงานจาก UI ของตัวเอง

• สถานะ, ข้อผิดพลาด และ เครดิต จัดการได้ชัดเจน

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

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

ขั้นต่อไปใน Rivya

• ใช้ หน้าสำหรับนักพัฒนา เพื่อดูตัวอย่างพื้นผิว API

• อ่าน คู่มือเริ่มต้น Rivya API ก่อนเขียนโค้ดสำหรับระบบจริง

• อ่าน API การยืนยันตัวตน ก่อนเก็บ API คีย์

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

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