Sai lầm dễ gặp nhất là xem Rivya API và Rivya Studio như hai đường cạnh tranh.
Cách hiểu tốt hơn là xem chúng như hai giai đoạn của cùng một sản phẩm. Studio là nơi con người khám phá, chọn, rà soát và tiếp tục công việc một cách trực quan. API là nơi một quy trình ổn định trở thành một phần của sản phẩm khác, script hoặc quy trình backend.
Nếu bạn vẫn đang học bề mặt API, hãy bắt đầu với Rivya API là gì?. Trang này hẹp hơn: cách quyết định một nhiệm vụ cụ thể thuộc về Studio hay API.
Quyết định trong một bảng
| Câu hỏi | Dùng Studio khi... | Dùng API khi... |
|---|---|---|
| Đầu ra vẫn đang khám phá? | có | không, quy trình đã lặp lại được |
| Có cần người so sánh kết quả? | có | chỉ sau khi ứng dụng của bạn nhận kết quả |
| Lựa chọn mô hình đã ổn định? | chưa | có, hoặc được chọn từ danh sách mô hình API |
| Nhiệm vụ cần media tham chiếu? | người dùng vẫn đang chuẩn bị | ứng dụng có thể tải lên qua Files API |
| Kết quả cần cập nhật hệ thống khác? | chưa | có, thông qua polling hoặc webhooks |
| Việc dùng credits cần hiển thị? | có, khi thử nghiệm | có, nhưng qua điều khiển API cấp tài khoản |
Đây không phải chuyện bề mặt nào cao cấp hơn. Đây là chuyện nhiệm vụ đã sẵn sàng tự động hóa chưa.
Dùng Studio khi công việc vẫn đang thay đổi
Studio là nơi đúng khi quyết định của con người vẫn là phần việc chính.
Bao gồm:
- chọn giữa các mô hình image, video, audio hoặc chat
- kiểm tra một hướng prompt có đáng giữ không
- so sánh trực quan nhiều kết quả cạnh nhau
- quyết định media tham chiếu đang giúp hay đang gây hại
- dùng lịch sử đã lưu để tiếp tục từ kết quả trước
Điều này đặc biệt đúng với công việc sáng tạo. Nếu brief chưa ổn định, tự động hóa yêu cầu thường chỉ làm sự rối rắm diễn ra nhanh hơn, không làm nó nhỏ lại.
Dùng API khi quy trình có thể lặp lại
API trở thành đường tốt hơn khi đầu vào và bước tiếp theo đủ dự đoán được.
Dấu hiệu tốt:
- sản phẩm của bạn đã biết mô hình hoặc nhóm mô hình cần dùng
- đầu vào người dùng có thể ánh xạ thành request body ổn định
- một job backend có thể poll trạng thái mà không cần người nhìn màn hình
- webhook có thể cập nhật đúng bản ghi khi nhiệm vụ hoàn tất
- ứng dụng có thể giải thích việc dùng credits cho đội hoặc chủ tài khoản
Đến lúc đó, dùng Studio cho mọi lượt chạy có thể trở thành đường chậm hơn. API cho phép sản phẩm của bạn bắt đầu nhiệm vụ trực tiếp.
Một ranh giới thực tế: discovery so với integration
Dùng Studio cho discovery.
Dùng API cho integration.
Discovery nghĩa là:
- "Chúng ta nên dùng mô hình nào?"
- "Dạng prompt nào hiệu quả?"
- "Media tham chiếu có cải thiện nhiệm vụ này không?"
- "Chất lượng đầu ra đã đủ tốt cho use case này chưa?"
Integration nghĩa là:
- "Hành động người dùng này nên tạo một generation job."
- "Job này nên được retry một cách idempotent."
- "Tệp này nên được tải lên và gắn với yêu cầu mô hình."
- "Nhiệm vụ hoàn tất này nên cập nhật bản ghi sản phẩm của chúng tôi."
Ranh giới đó giữ API không biến thành bề mặt thí nghiệm bị giấu trong nền.
Credits nên ảnh hưởng quyết định thế nào
Cả Studio và API đều dùng cùng credits của tài khoản Rivya.
Điều đó nghĩa là hành vi credits nên là một phần của thiết kế sản phẩm, không phải phần nghĩ sau.
Dùng Studio trước khi đội vẫn cần học hình dạng chi phí. Dùng API khi nhiệm vụ đủ ổn định để sản phẩm có thể giải thích khi nào credits có thể được giữ hoặc tiêu thụ.
Với các quy tắc công khai hiện tại, hãy đọc API Credits. Nếu một quy trình quá đắt để giải thích cho chủ tài khoản, nó chưa sẵn sàng tự động hóa bằng API.
Files thay đổi lựa chọn ở đâu
Media tham chiếu thường là nơi một tích hợp trở nên nghiêm túc hơn.
Trong Studio, một người có thể tải lên, xem xét, thử lại và quyết định tệp có đủ tốt không. Trong API, sản phẩm của bạn cần xử lý đường đi tệp một cách có chủ ý qua Files API.
Dùng Studio khi:
- ảnh, video hoặc audio tham chiếu vẫn cần người làm sạch
- đội chưa chắc tham chiếu nào nên dẫn hướng mô hình
- quy tắc tệp chưa rõ với người dùng
Dùng API khi:
- ứng dụng có thể thu thập tệp an toàn
- yêu cầu tham chiếu của mô hình đã biết
- tệp có thể được tải lên trước yêu cầu tạo sinh hoặc chat
- lỗi có thể được hiển thị trong chính sản phẩm của bạn mà không che giấu điều đã xảy ra
Files API là một cầu nối hữu ích, nhưng nó không loại bỏ nhu cầu thiết kế trải nghiệm tệp.
Chat thay đổi lựa chọn ở đâu
Chat có thể thuộc về cả hai phía.
Dùng trực tiếp Rivya Chat khi một người đang khám phá, viết, rà soát hoặc quyết định.
Dùng Chat API khi lượt chat cần sống bên trong sản phẩm hoặc quy trình server của bạn. Điều đó có thể gồm lượt không streaming, SSE streaming tùy chọn, session do API tạo và tệp đính kèm được hỗ trợ.
Câu hỏi chính là cuộc trò chuyện nên sống ở đâu. Nếu cuộc trò chuyện là một phần công việc Rivya, hãy dùng Rivya. Nếu cuộc trò chuyện là một phần trải nghiệm sản phẩm của bạn, hãy dùng API.
Khi Webhooks là một tín hiệu
Nếu quy trình của bạn cần API Webhooks, có lẽ nó đã vượt qua giai đoạn Studio thủ công.
Webhooks hữu ích khi hệ thống khác cần phản hồi các nhiệm vụ tạo sinh đã hoàn tất:
- đánh dấu tài sản đã sẵn sàng
- thông báo cho người dùng
- đẩy bước rà soát tiến lên
- đưa nhiệm vụ thất bại vào hỗ trợ hoặc logic retry
Đó là công việc integration. Studio vẫn có thể hữu ích để kiểm thử đường mô hình, nhưng vòng production thuộc về API.
Một mẫu di chuyển an toàn
Đừng chuyển cả quy trình sang API trong một lần.
Dùng trình tự này:
- kiểm thử nhiệm vụ thủ công trong Studio
- ghi lại mô hình ổn định, dạng prompt, tệp đầu vào và kết quả kỳ vọng
- đọc API Models và model reference
- gửi một lượt tạo sinh qua Bắt đầu nhanh với Rivya API
- chỉ thêm Files API nếu mô hình cần media tham chiếu
- chỉ thêm Webhooks sau khi polling hoạt động
- chỉ thêm Chat API nếu sản phẩm cần lượt chat bên ngoài Studio
Mỗi bước nên làm quy trình dễ vận hành hơn, không chỉ tự động hóa nhiều hơn.
Khi nào nên ở lại Studio
Ở lại Studio khi nhiệm vụ vẫn cần:
- rà soát chủ quan
- định hình prompt
- so sánh hình ảnh
- khám phá mô hình
- lịch sử sáng tạo đã lưu
- một người quyết định bước tiếp theo là image, video, audio hay chat
Đó không phải điểm yếu. Studio được thiết kế cho giai đoạn đó.
Khi nào nên chuyển sang API
Chuyển sang API khi:
- cùng nhiệm vụ lặp lại thường xuyên
- đầu vào có thể được cấu trúc
- mô hình đã biết
- ứng dụng cần tạo nhiệm vụ từ UI riêng
- trạng thái, lỗi và credits có thể được xử lý rõ ràng
- polling hoặc webhooks khớp với backend của sản phẩm
API mạnh nhất khi nó biến một quy trình Rivya đã được hiểu rõ thành một hành động sản phẩm đáng tin cậy.
Bước tiếp theo trong Rivya
- Dùng Developers để xem trước bề mặt API.
- Đọc Bắt đầu nhanh với Rivya API trước khi viết code production.
- Đọc Xác thực API trước khi lưu API key.
- Đọc Cách xây quy trình AI đa phương thức với Rivya API nếu câu hỏi tiếp theo là cách nối mô hình, files, chat và webhooks.
- Dùng Chuyển công việc giữa Rivya Chat, Image, Video, Audio nếu dự án vẫn thuộc về công việc Studio do con người dẫn dắt.
