ความผิดพลาดที่ง่ายที่สุดคือมอง Rivya API และ Rivya Studio เป็นเส้นทางที่แข่งกัน
ควรมองสองอย่างนี้เป็นสองช่วงของผลิตภัณฑ์เดียวกันมากกว่า Studio คือที่ที่คนสำรวจ เลือก รีวิว และทำงานต่อแบบมองเห็นได้ ส่วน API คือที่ที่เวิร์กโฟลว์ที่นิ่งแล้วกลายเป็นส่วนหนึ่งของผลิตภัณฑ์ สคริปต์ หรือกระบวนการฝั่ง backend อื่น
ถ้าคุณยังเรียนรู้พื้นผิวของ API อยู่ ให้เริ่มจาก What Is the Rivya API? หน้านี้แคบกว่า: วิธีตัดสินว่างานเฉพาะหนึ่งงานควรอยู่ใน Studio หรือใน API
การตัดสินใจในตารางเดียว
| คำถาม | ใช้ Studio เมื่อ... | ใช้ API เมื่อ... |
|---|---|---|
| ผลลัพธ์ยังเป็นการสำรวจอยู่หรือไม่? | ใช่ | ไม่ใช่ เวิร์กโฟลว์ทำซ้ำได้แล้ว |
| คนต้องเปรียบเทียบผลลัพธ์หรือไม่? | ใช่ | เฉพาะหลังจากแอปของคุณได้รับผลลัพธ์แล้ว |
| การเลือกโมเดลนิ่งแล้วหรือยัง? | ยัง | ใช่ หรือเลือกจากรายการโมเดลของ API |
| งานต้องใช้สื่ออ้างอิงหรือไม่? | คนยังเตรียมอยู่ | แอปของคุณอัปโหลดผ่าน Files API ได้ |
| ผลลัพธ์ต้องอัปเดตระบบอื่นหรือไม่? | ยังไม่ต้อง | ใช่ ผ่าน polling หรือ webhooks |
| การใช้เครดิตต้องมองเห็นได้หรือไม่? | ใช่ ระหว่างทดสอบ | ใช่ แต่ผ่านการควบคุม 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 ทีเดียว
ใช้ลำดับนี้:
ทดสอบงานด้วยมือใน Studio
จดโมเดลที่นิ่ง รูปทรงพรอมต์ ไฟล์อินพุต และผลลัพธ์ที่คาดหวัง
อ่าน API Models และ model reference
submit generation หนึ่งงานผ่าน API Quickstart
เพิ่ม Files API เฉพาะเมื่อโมเดลต้องใช้สื่ออ้างอิง
เพิ่ม Webhooks หลัง polling ใช้งานได้แล้วเท่านั้น
เพิ่ม 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 ที่มนุษย์นำ
