คู่มือ References และ Uploads ของ Rivya

ใช้คู่มือ references และ uploads นี้ก่อนเลือก model ที่ต้องพึ่ง image references, video references หรือเสียงที่อัปโหลด

References และ uploads เป็นส่วนสำคัญของวิธีที่ task ใน Rivya ย้ายจากขั้นค้นหาและเลือกเส้นทาง ไปสู่การทำงานใน Studio หลังเข้าสู่ระบบ

สิ่งเหล่านี้ส่งผลต่อ:

• การเลือก model

• การเลือก workflow

• โครงสร้าง prompt

• ต้นทุนของ task

• ผู้ใช้ควรเริ่มจาก public start page, หน้ารายละเอียด model หรือ Studio

นี่คือเหตุผลที่ uploads ไม่ใช่แค่รายละเอียดของ UI แต่เป็นส่วนหนึ่งของตรรกะ workflow

รายละเอียดเชิงปฏิบัติที่ควรรู้ตั้งแต่ต้น:

• หน้าที่เข้าใจ references อาจเป็นหน้าสาธารณะได้

• การ upload ไฟล์จริงในตอนนี้ต้อง sign-in

ดังนั้น public start page ยังอาจเป็นจุดเริ่มต้นที่ถูกต้อง แต่ execution ที่อิง upload ยังไม่ใช่การใช้งานแบบ anonymous เต็มรูปแบบในผลิตภัณฑ์ปัจจุบัน

รูปแบบ Upload สามแบบ

วันนี้พฤติกรรมของ reference และ upload ใน Rivya แบ่งเป็นสามแบบหลัก:

• reference รูปภาพ

• reference วิดีโอ

• การอัปโหลดเสียง

ไม่ใช่ทุก model ที่รองรับทั้งสามแบบ

นั่นคือเหตุผลที่ต้องดู model page ก่อนเริ่ม task

Reference รูปภาพ

workflow รูปภาพและวิดีโอจำนวนมากรองรับ image references

ขีดจำกัดของ reference image อาจต่างกันมากตาม model

ตอนนี้ช่วงดังกล่าวเริ่มจาก:

• reference image เพียงภาพเดียว

• workflow หลายภาพที่ใหญ่ขึ้น

เรื่องนี้สำคัญ เพราะ "รองรับ references" และ "รองรับ references จำนวนมาก" ไม่ใช่ความสามารถเดียวกัน

Reference วิดีโอ

workflow วิดีโอบางตัวอาจรับ video references หรือ reference modes ที่ขยายมากขึ้นได้ด้วย

ความสามารถเหล่านี้ไม่ได้มีเหมือนกันทั้ง catalog

ดังนั้นผู้ใช้ไม่ควรสรุปว่า video model ทุกตัวรับ input ชนิดเดียวกันได้ เพียงเพราะอยู่ใน category เดียวกัน

การอัปโหลดเสียง

audio uploads สำคัญที่สุดใน workflow เช่น:

• การทำความสะอาดเสียง

• การแยกเสียง

• การแปลงเสียง

workflow เหล่านี้ต่างจากการสร้างเสียงที่เริ่มจาก prompt เป็นหลักในเชิงโครงสร้าง

หาก model คาดหวัง uploaded audio, form จะเปลี่ยนพฤติกรรมอย่างตั้งใจ

ทำไม Form จึงเปลี่ยนตาม Model

generation forms ของ Rivya ขับเคลื่อนตาม model

หมายความว่า input ที่มองเห็นขึ้นกับ:

• model ที่เลือกสนับสนุนอะไร

• รับ file kinds ใด

• รับได้กี่ files

นี่คือพฤติกรรมที่ถูกต้อง เพราะ prompt-only model และ upload-first model ไม่ใช่ workflow เดียวกัน

Upload Kinds ปัจจุบัน

upload kinds หลักที่ใช้ใน product flows ปัจจุบันคือ:

• image

• video

• audio

ค่ากลุ่มนี้จะถูก normalize ภายใน product ก่อนส่งเข้า final model request

Upload Limits ปัจจุบัน

upload path ตอนนี้บังคับใช้การตรวจ size และ type ตาม kind:

ภาพ

• JPEG

• PNG

• WebP

• ขนาดสูงสุดเริ่มต้นปัจจุบัน: 10 MB

• Nano Banana 2 และ Nano Banana Pro ตอนนี้อนุญาตได้สูงสุด 30 MB

วิดีโอ

• MP4

• MOV / QuickTime

• WebM

• ขนาดสูงสุดปัจจุบัน: 50 MB

• Wan 2.6 ตอนนี้ใช้ cap ที่เข้มกว่า 10 MB และรับ MP4, MOV / QuickTime รวมถึง uploads วิดีโอสไตล์ MKV

เสียง

• MP3

• เสียง MP4

• WAV

• AAC

• OGG

• ขนาดสูงสุดเริ่มต้นปัจจุบัน: 10 MB

limits เหล่านี้เกี่ยวกับ safe ingestion และ routing ไม่ใช่แค่ความสะดวกของ UI

References และ Model Choice

reference support มักสำคัญกว่า hype

ตัวอย่าง:

• หาก workflow ต้องใช้ image references หลายภาพ model ที่ถูกต้องแทบไม่ควรถูกเลือกจากชื่อเสียงแบรนด์อย่างเดียว

• หาก workflow ต้องใช้ uploaded audio, model TTS มาตรฐานคือ entry point ที่ผิด

ดังนั้นลำดับการเลือก model ที่สะอาดที่สุดคือ:

1. ประเภท output

2. reference หรือ upload requirement

3. cost และ quality fit

4. จากนั้นจึงดู model preference

Public Pages เทียบกับ Studio

Public start pages เหมาะเมื่อคุณต้องการ:

• public landing page แรก

• entry เฉพาะ model โดยตรง

• path จาก search-driven เข้าสู่ workflow ที่ถูกต้อง

Studio เหมาะกว่าเมื่อ task ต้องใช้:

• signed-in upload และ execution

• การ iterate ซ้ำหลายรอบ

• continuity มากขึ้น

• working context ที่เต็มกว่า

สิ่งนี้จริงเป็นพิเศษเมื่อ upload เองกลายเป็นส่วนหนึ่งของ workflow ที่ยาวขึ้น

ข้อผิดพลาดที่พบบ่อย

ข้อผิดพลาด 1: คิดว่า models ใน category เดียวกันรับ file types เดียวกัน

ไม่ใช่

ข้อผิดพลาด 2: เลือก model ก่อนตรวจ upload support

สิ่งนี้มักสร้าง rework ที่หลีกเลี่ยงได้

ข้อผิดพลาด 3: มอง workflow ที่ใช้ uploaded-audio เหมือน workflow แบบ prompt-only

สองอย่างนี้เป็น paths ที่ต่างกันและควรถูกมองต่างกัน

workflow การใช้ reference

path ที่ใช้งานจริงใน Rivya มีลักษณะนี้:

1. ตรวจ model page สำหรับ reference support

2. เลือก public start page หรือ Studio path ที่ถูก

3. sign in ก่อนขั้น upload จริงหากต้องใช้ account context

4. upload เฉพาะ kinds ที่ model รองรับจริง

5. รักษา prompt ให้สอดคล้องกับ uploaded context

6. review result และ iterate ใน workflow เดียวกัน

อ่านต่อ

• Models

• เวิร์กโฟลว์รูปภาพใน Rivya

• เวิร์กโฟลว์วิดีโอใน Rivya

• เวิร์กโฟลว์เสียงใน Rivya

• เวิร์กโฟลว์สาธารณะและเวิร์กโฟลว์หลังเข้าสู่ระบบใน Rivya

• การแก้ไขปัญหาใน Rivya

• AI Image Generator พร้อม Reference Images

เช็กลิสต์ Reference Upload

ก่อน task ต้องพึ่ง reference file หรือ upload ให้ตรวจว่า:

• ยืนยันว่า task ต้องใช้ image reference, video reference, audio upload หรือไม่ต้องใช้ file เลย

• ตรวจ model page สำหรับ file kinds และ limits ที่รองรับก่อนเตรียม assets

• ตัดสินใจว่า task ควรอยู่บน public start page หรือ signed-in Studio

• ลบ file content ที่ sensitive หรือไม่จำเป็นก่อน upload

• รักษา prompt ให้ตรงกับสิ่งที่ uploaded file แต่ละไฟล์ควรควบคุม

เป้าหมายคือทำให้ file มีประโยชน์ อนุญาตได้ และเกี่ยวข้องก่อนใช้ credits

เมื่อใดควรตรวจ Upload Fit อีกครั้ง

ตรวจ upload fit อีกครั้งเมื่อ selected model เปลี่ยน, file ใหญ่เกินไป, reference role ไม่ชัดเจน หรือ asset มี people, logos, private data หรือ client-owned material

ในกรณีเหล่านั้น ให้ review Safe Upload Guidelines และหน้า reference ที่เกี่ยวข้องก่อนเริ่ม run อีกครั้ง