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

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

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

ถ้าคุณยังเรียนรู้พื้นผิวของ API อยู่ ให้เริ่มจาก What Is the Rivya API? หน้านี้แคบกว่า: วิธีตัดสินว่างานเฉพาะหนึ่งงานควรอยู่ใน Studio หรือใน API

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

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

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

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

รวมถึง:

• เลือกระหว่างโมเดล image, video, audio หรือ chat
• ทดสอบว่าทิศทางพรอมต์ควรเก็บไว้หรือไม่
• เปรียบเทียบผลลัพธ์ภาพแบบเคียงข้างกัน
• ตัดสินว่าสื่ออ้างอิงช่วยหรือทำให้แย่ลง
• ใช้ประวัติที่บันทึกไว้เพื่อทำต่อจากผลลัพธ์ก่อนหน้า

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

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

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

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

• ผลิตภัณฑ์ของคุณรู้อยู่แล้วว่าต้องใช้โมเดลหรือหมวดโมเดลใด
• อินพุตผู้ใช้สามารถ map เป็น request body ที่นิ่งได้
• งานฝั่ง backend สามารถ poll status ได้โดยไม่ต้องมีคนเฝ้าหน้าจอ
• webhook สามารถอัปเดต record ที่ถูกต้องเมื่องานเสร็จ
• แอปอธิบายการใช้เครดิตให้ทีมหรือเจ้าของบัญชีเข้าใจได้

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

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

ใช้ Studio สำหรับ discovery

ใช้ API สำหรับ integration

Discovery หมายถึง:

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

Integration หมายถึง:

• "การกระทำของผู้ใช้นี้ควรสร้าง generation job หนึ่งงาน"
• "job นี้ควรถูก retry แบบ idempotent"
• "ไฟล์นี้ควรถูกอัปโหลดและแนบกับ request ของโมเดล"
• "งานที่เสร็จแล้วนี้ควรอัปเดต product record ของเรา"

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

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

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

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

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

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

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

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

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

ใช้ Studio เมื่อ:

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

ใช้ API เมื่อ:

• แอปเก็บไฟล์ได้อย่างปลอดภัย
• requirements ด้าน reference ของโมเดลชัดเจนแล้ว
• อัปโหลดไฟล์ก่อน generation หรือ chat request ได้
• แสดง error ในผลิตภัณฑ์ของคุณเองได้โดยไม่ซ่อนสิ่งที่เกิดขึ้น

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

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

Chat อาจอยู่ได้ทั้งสองฝั่ง

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

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

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

เมื่อ Webhooks เป็นสัญญาณ

ถ้าเวิร์กโฟลว์ของคุณต้องใช้ API Webhooks ก็น่าจะผ่านช่วง Studio แบบ manual ไปแล้ว

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

• ทำเครื่องหมายว่าชิ้นงานพร้อมใช้
• แจ้งผู้ใช้
• ขยับขั้นรีวิวไปข้างหน้า
• ส่งงานที่ล้มเหลวเข้าสู่ support หรือ retry logic

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

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

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

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

1. ทดสอบงานด้วยมือใน Studio
2. จดโมเดลที่นิ่ง รูปทรงพรอมต์ ไฟล์อินพุต และผลลัพธ์ที่คาดหวัง
3. อ่าน API Models และ model reference
4. submit generation หนึ่งงานผ่าน API Quickstart
5. เพิ่ม Files API เฉพาะเมื่อโมเดลต้องใช้สื่ออ้างอิง
6. เพิ่ม Webhooks หลัง polling ใช้งานได้แล้วเท่านั้น
7. เพิ่ม Chat API เฉพาะเมื่อผลิตภัณฑ์ต้องใช้ chat turns นอก Studio

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

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

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

• การรีวิวเชิงความรู้สึก
• การจัดรูปพรอมต์
• การเปรียบเทียบภาพ
• การสำรวจโมเดล
• ประวัติครีเอทีฟที่บันทึกไว้
• คนตัดสินว่าขั้นต่อไปควรเป็น image, video, audio หรือ chat

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

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

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

• งานเดิมเกิดซ้ำบ่อย
• อินพุตจัดโครงสร้างได้
• โมเดลชัดเจนแล้ว
• แอปต้องสร้างงานจาก UI ของตัวเอง
• status, errors และ credits จัดการได้ชัดเจน
• polling หรือ webhooks เข้ากับ backend ของผลิตภัณฑ์

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

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

• ใช้ Developers เพื่อ preview พื้นผิว API
• อ่าน Rivya API Quickstart ก่อนเขียนโค้ด production
• อ่าน API Authentication ก่อนเก็บ API key
• อ่าน How to Build a Multimodal AI Workflow with Rivya API ถ้าคำถามถัดไปคือวิธีเชื่อมโมเดล ไฟล์ chat และ webhooks
• ใช้ Moving Work Across Rivya Chat, Image, Video, Audio ถ้าโปรเจกต์ยังควรอยู่ในงาน Studio ที่มนุษย์นำ