Helpoin virhe on kohdella Rivya APIa ja Rivya Studiota kilpailevina polkuina.
Ne on parempi ymmärtää saman tuotteen kahtena vaiheena. Studio on paikka, jossa ihmiset tutkivat, valitsevat, arvioivat ja jatkavat työtä visuaalisesti. API on paikka, jossa vakaa työnkulku muuttuu osaksi toista tuotetta, skriptiä tai backend-prosessia.
Jos opettelet vielä API-pintaa, aloita artikkelista mikä Rivya API on?. Tämä sivu on kapeampi: miten päätät, kuuluuko tietty tehtävä Studioon vai APIin.
Päätös yhdessä taulukossa
| Kysymys | Käytä Studiota, kun... | Käytä APIa, kun... |
|---|---|---|
| Onko tuotos yhä tutkiva? | kyllä | ei, työnkulku on jo toistettava |
| Täytyykö ihmisen vertailla tuloksia? | kyllä | vain sen jälkeen, kun sovelluksesi vastaanottaa tulokset |
| Onko mallivalinta vakaa? | ei vielä | kyllä, tai se valitaan API-mallilistasta |
| Tarvitseeko tehtävä referenssimediaa? | ihminen valmistelee sitä vielä | sovelluksesi voi ladata sen Files APIlla |
| Pitääkö tuloksen päivittää toinen järjestelmä? | ei vielä | kyllä, pollingilla tai webhookeilla |
| Pitääkö credit-käytön pysyä näkyvissä? | kyllä, testauksen aikana | kyllä, mutta tilitason API-kontrollien kautta |
Kyse ei ole siitä, kumpi pinta on edistyneempi. Kyse on siitä, onko tehtävä valmis automatisoitavaksi.
Käytä Studiota, kun työ muuttuu vielä
Studio on oikea paikka, kun ihmisen päätös on vielä päätyö.
Se sisältää:
- valinnan kuva-, video-, audio- tai chat-mallien välillä
- testauksen siitä, kannattaako prompt-suunta säilyttää
- visuaalisten tulosten rinnakkaisen vertailun
- päätöksen siitä, auttaako vai haittaako referenssimedia
- tallennetun historian käyttämisen edellisestä tuloksesta jatkamiseen
Tämä pitää erityisesti paikkansa luovassa työssä. Jos brief ei ole vakaa, pyynnön automatisointi yleensä tekee sekaannuksesta nopeampaa eikä pienempää.
Käytä APIa, kun työnkulku on toistettava
APIsta tulee parempi polku, kun syötteet ja seuraavat vaiheet ovat riittävän ennustettavia.
Hyviä merkkejä:
- tuotteesi tietää jo tarvitsemansa mallin tai mallikategorian
- käyttäjän syöte voidaan mapata vakaaseen request bodyyn
- backend-työ voi pollata statusta ilman, että joku katsoo näyttöä
- webhook voi päivittää oikean tietueen, kun tehtävä valmistuu
- sovellus voi selittää credit-käytön tiimille tai tilin omistajalle
Siinä vaiheessa Studion käyttäminen jokaiseen ajoon voi muuttua hitaammaksi poluksi. API antaa tuotteesi aloittaa tehtävän suoraan.
Käytännön raja: discovery vastaan integration
Käytä Studiota discoveryyn.
Käytä APIa integrationiin.
Discovery tarkoittaa:
- "Mitä mallia meidän pitäisi käyttää?"
- "Minkälainen prompt-muoto toimii?"
- "Parantaako referenssimedia tätä tehtävää?"
- "Onko tuotoksen laatu tarpeeksi hyvä tähän käyttötapaukseen?"
Integration tarkoittaa:
- "Tämän käyttäjätoiminnon pitäisi luoda yksi generation job."
- "Tämä job pitäisi yrittää uudelleen idempotentisti."
- "Tämä tiedosto pitäisi ladata ja liittää mallipyyntöön."
- "Tämän valmistuneen tehtävän pitäisi päivittää tuotetietueemme."
Tuo raja estää APIa muuttumasta piilotetuksi kokeilupinnaksi.
Miten creditsien pitäisi vaikuttaa päätökseen
Sekä Studio- että API-käyttö kuluttaa saman Rivya-tilin creditsejä.
Siksi credit-käyttäytymisen pitäisi olla osa tuotesuunnittelua, ei jälkiajatus.
Käytä ensin Studiota, kun tiimin täytyy vielä oppia kustannusmuoto. Käytä APIa, kun tehtävä on tarpeeksi vakaa, jotta tuote voi selittää, milloin credits voidaan varata tai kuluttaa.
Nykyiset julkiset säännöt löydät sivulta API Credits. Jos työnkulku on liian kallis selitettäväksi tilin omistajalle, se ei ole vielä valmis API-automaatioon.
Missä tiedostot muuttavat valintaa
Referenssimedia on usein kohta, jossa integraatiosta tulee vakavampi.
Studiossa ihminen voi ladata, tarkastaa, yrittää uudelleen ja päättää, onko tiedosto riittävän hyvä. APIssa tuotteesi täytyy käsitellä tiedostopolku tarkoituksella Files API:n kautta.
Käytä Studiota, kun:
- referenssikuva, video tai audio tarvitsee vielä ihmisen cleanupia
- tiimi ei ole varma, minkä referenssin pitäisi ohjata mallia
- tiedostosäännöt eivät ole vielä käyttäjälle selviä
Käytä APIa, kun:
- sovellus voi kerätä tiedoston turvallisesti
- mallin referenssivaatimukset tunnetaan
- tiedosto voidaan ladata ennen generation- tai chat-pyyntöä
- virheet voidaan näyttää omassa tuotteessasi peittämättä, mitä tapahtui
Files API on hyödyllinen silta, mutta se ei poista tarvetta suunnitella tiedostokokemusta.
Missä chat muuttaa valintaa
Chat voi kuulua kummalle tahansa puolelle.
Käytä Rivya Chatia suoraan, kun ihminen tutkii, kirjoittaa, arvioi tai päättää.
Käytä Chat API:a, kun chat-vuoron täytyy elää omassa tuotteessasi tai palvelintyönkulussasi. Tämä voi sisältää non-streaming-vuoroja, valinnaisen SSE-streamingin, APIlla luodut sessiot ja tuetut tiedostoliitteet.
Avainkysymys on, missä keskustelun pitäisi elää. Jos keskustelu on osa Rivya-työtä, käytä Rivyaa. Jos keskustelu on osa oman tuotteesi kokemusta, käytä APIa.
Milloin webhooks ovat signaali
Jos työnkulku tarvitsee API Webhooks, se on todennäköisesti manuaalista Studio-vaihetta pidemmällä.
Webhooks ovat hyödyllisiä, kun toisen järjestelmän täytyy reagoida valmistuneisiin generointitehtäviin:
- merkitse assetti valmiiksi
- ilmoita käyttäjälle
- siirrä arviointivaihetta eteenpäin
- siirrä epäonnistunut tehtävä tukeen tai retry-logiikkaan
Tämä on integraatiotyötä. Studio voi yhä olla hyödyllinen mallipolun testaamiseen, mutta tuotantolooppi kuuluu APIin.
Turvallinen migraatiokaava
Älä siirrä koko työnkulkua APIin kerralla.
Käytä tätä järjestystä:
- testaa tehtävä manuaalisesti Studiossa
- kirjoita ylös vakaa malli, prompt-muoto, syötetiedostot ja odotettu tulos
- lue API Models ja malliviite
- lähetä yksi generointi API Quickstart:in kautta
- lisää Files API vain, jos malli vaatii referenssimediaa
- lisää Webhooks vasta, kun polling toimii
- lisää Chat API vain, jos tuote tarvitsee chat-vuoroja Studion ulkopuolella
Jokaisen vaiheen pitäisi tehdä työnkulusta helpompi operoida, ei vain automaattisempi.
Milloin pysyä Studiossa
Pysy Studiossa, kun tehtävä tarvitsee vielä:
- subjektiivista arviointia
- promptin muotoilua
- visuaalista vertailua
- mallien tutkimista
- tallennettua luovaa historiaa
- ihmisen päätöstä siitä, onko seuraava askel image, video, audio vai chat
Se ei ole heikkous. Studio on suunniteltu juuri siihen vaiheeseen.
Milloin siirtyä APIin
Siirry APIin, kun:
- sama tehtävä toistuu usein
- syöte voidaan strukturoida
- malli tunnetaan
- sovelluksen täytyy luoda tehtäviä omasta UI:staan
- status, virheet ja credits voidaan käsitellä selvästi
- polling tai webhooks sopivat tuotteen backendiin
API on vahvimmillaan, kun se muuttaa jo ymmärretyn Rivya-työnkulun luotettavaksi tuotetoiminnoksi.
Seuraava askel Rivyassa
- Käytä Developers API-pinnan esikatseluun.
- Lue Rivya API Quickstart ennen tuotantokoodin kirjoittamista.
- Lue API Authentication ennen API-avaimen tallentamista.
- Lue miten rakentaa multimodaalinen AI-työnkulku Rivya APIlla, jos seuraava kysymys on, miten mallit, tiedostot, chat ja webhooks yhdistetään.
- Käytä työn siirtämistä Rivya Chat-, Image-, Video- ja Audio-pintojen välillä, jos projekti kuuluu yhä ihmisen johtamaan Studio-työhön.
