Tài liệu Rivya AI

Hướng dẫn vòng đời tác vụ trong Rivya

Hiểu tác vụ trạng thái, điểm tín dụng reservation, nhà cung cấp submission, callbacks, polling, lịch sử, notifications, failures và điểm tín dụng trong Rivya.

Đánh giá lần cuối vào 2026/08/29

Dùng hướng dẫn này khi bạn cần hiểu điều gì xảy ra sau khi submit một tác vụ tạo nội dung hình ảnh, video hoặc âm thanh trong Rivya.

Nó giải thích tác vụ states, điểm tín dụng reservation, nhà cung cấp completion, lịch sử, notifications và failed-tác vụ handling ở một nơi.

Tác vụ states thật sự

Lifecycle tạo nội dung async hiện dùng bốn trạng thái hiển thị:

  • WAITING

  • GENERATING

  • SUCCESS

  • FAILED

Các trạng thái này được lưu trên ai_task và được tái sử dụng xuyên suốt Studio, lịch sử, dashboard và notifications flow.

Điều gì xảy ra khi bạn submit

1. Rivya validate yêu cầu

Trước khi bất kỳ thứ gì tới nhà cung cấp, Rivya kiểm tra:

  • mô hình có tồn tại không

  • mô hình hiện đang khả dụng

  • direct tạo nội dung có được bật cho mô hình đó không

  • runtime có dựa trên async-tác vụ không

  • câu lệnh length có hợp lệ không

  • biểu mẫu tham số đã được chuẩn hóa chưa

  • tệp tham chiếu có khớp với những gì mô hình chấp nhận không

Một số mô hình được ghi nhận có quy tắc riêng. Audio Isolation trước đây yêu cầu tệp âm thanh và xác minh thời lượng, nhưng hiện không khả dụng; Rivya phải từ chối ở cổng trạng thái thay vì tạo tác vụ, giữ điểm tín dụng hoặc thử quy trình tải tệp.

2. Rivya tạo tác vụ record

Rivya tạo một entry ai_task trước, với trạng thái WAITING.

Record đó lưu mô hình, danh mục, câu lệnh, params, reserved điểm tín dụng, thanh toán type và sau đó là kết quả hoặc failure state.

3. Điểm tín dụng được tiêu trước nhà cung cấp submission

Điều này quan trọng: với async tạo nội dung, Rivya tiêu tác vụ điểm tín dụng trước khi gửi job upstream.

Nếu điểm tín dụng quá thấp:

  • tác vụ được đánh dấu failed

  • upstream service không bao giờ được gọi

  • có thể tạo notification insufficient-điểm tín dụng

4. Tác vụ của nhà cung cấp xử lý được tạo

Nếu mô hình khả dụng, tạo trực tiếp được bật và đủ điểm tín dụng, Rivya gửi tác vụ đến dịch vụ upstream phù hợp rồi lưu ID tác vụ upstream.

Lúc đó trạng thái chuyển thành GENERATING.

Rivya biết kết quả như thế nào

Rivya hỗ trợ hai đường completion:

  • nhà cung cấp callback trong môi trường có callback enabled

  • trạng thái refresh và polling khi callback completion không khả dụng

Đường callback cũng verify webhook signature trước khi finalize một tác vụ.

Nếu callback đến trước khi nhà cung cấp kết quả hoàn toàn sẵn sàng, Rivya có thể defer và thử lại bằng cách kiểm tra upstream trạng thái.

Success path

Khi thành công, Rivya:

  • lưu kết quả URLs

  • đặt trạng thái thành SUCCESS

  • settle tác vụ

  • làm kết quả khả dụng trong lịch sử tạo nội dung

  • tạo tạo nội dung-success notification

Đó là lý do một hình ảnh hoặc video đã hoàn tất vẫn hiển thị sau khi bạn rời trang.

Failure path

Khi thất bại, Rivya:

  • lưu lỗi tin nhắn

  • đặt trạng thái thành FAILED

  • refund điểm tín dụng khi failure xảy ra sau reservation và nên được reverse

  • tạo tạo nội dung-failed notification để rà soát bền vững

Điều này khác với một toast tạm thời. Failure trở thành một phần trong record của tài khoản.

Bạn thấy tác vụ state ở đâu

Cùng một tác vụ có thể xuất hiện ở nhiều nơi:

Shared state đó là một trong những lý do sản phẩm có cảm giác coherent thay vì dùng một lần rồi mất.

Trò chuyện khác như thế nào

Chat cũng billable, nhưng không dùng cùng async tác vụ record. Chat turns được lưu dưới dạng:

  • phiên trò chuyện

  • tin nhắn trò chuyện

Với token-based trò chuyện models, Rivya có thể reserve điểm tín dụng trước rồi settle số tiền cuối sau khi usage quay lại. Nếu số cuối thấp hơn, phần chênh lệch được refund.

Vì vậy quy tắc rộng là:

  • hình ảnh, video và âm thanh tạo nội dung dùng ai_task

  • trò chuyện dùng saved phiêns và tin nhắn-level settlement

Đọc tiếp

Checklist tác vụ state

Khi một tạo nội dung gây nhầm lẫn, chậm, fail hoặc bị thiếu, hãy kiểm tra:

  • Xác định tác vụ type trước: trò chuyện settlement, hình ảnh, video, âm thanh hoặc công cụ-backed trò chuyện.

  • Xác nhận mô hình được chọn đang khả dụng; trang được ghi nhận không chứng minh tác vụ có thể bắt đầu.

  • Kiểm tra điểm tín dụng được reserved trước nhà cung cấp submission hay settled sau usage.

  • Tìm nhà cung cấp callback, polling kết quả, lịch sử item và notification trước khi giả định kết quả đã mất.

  • Tách user-correctable failures khỏi nhà cung cấp hoặc infrastructure failures.

  • Xác nhận failed tác vụ có nên reverse điểm tín dụng trước khi rerun cùng câu lệnh không.

Kiểm tra lại trước khi chạy lại

Hãy kiểm tra lại khi cùng câu lệnh liên tục fail, tác vụ ở trạng thái in progress quá lâu, điểm tín dụng trông như đã bị tiêu mà không có kết quả hoặc bạn sắp submit một duplicate run nặng hơn.