
Rivya-journalen

Forfatter
Kategorier
Innholdsfortegnelse
Fortsett å utforske
Fortsett med relaterte guider, produktnotater og arbeidsflytgjennomganger fra Rivya-teamet.
Den enkleste feilen er å behandle Rivya API og Rivya Studio som konkurrerende stier.
De forstås bedre som to faser av samme produkt. Studio er der mennesker utforsker, velger, gjennomgår og fortsetter arbeidet visuelt. Med API-et kan en stabil arbeidsflyt bli del av et annet produkt, et skript eller en prosess på serversiden.
Denne sammenligningen beskriver den implementerte API-kontrakten. API-siden gjelder bare når Public API-tilgang og eventuelle nevnte funksjoner, som webhooks, er aktivert for distribusjonen og tilgjengelige for kontoen.
Hvis du fortsatt lærer API-flaten, start med Hva er Rivya API?. Denne siden er smalere: hvordan du avgjør om en konkret oppgave hører hjemme i Studio eller i API-et.
| Spørsmål | Bruk Studio når... | Bruk API-et når... |
|---|---|---|
| Er outputen fortsatt utforskende? | ja | nei, arbeidsflyten er allerede repeterbar |
| Må en person sammenligne resultater? | ja | bare etter at appen din mottar resultater |
| Er modellvalget stabilt? | ikke ennå | ja, eller valgt fra API-modellisten |
| Trenger oppgaven referansemedier? | en person forbereder dem fortsatt | appen din kan laste dem opp gjennom Fil-API |
| Må resultatet oppdatere et annet system? | ikke ennå | ja, gjennom statusspørring eller aktiverte webhooker |
| Må kredittbruken være synlig? | ja, mens dere tester | ja, men gjennom API-kontroller på kontonivå |
Dette handler ikke om hvilken flate som er mer avansert. Det handler om hvorvidt oppgaven er klar for automatisering.
Studio er riktig sted når den menneskelige beslutningen fortsatt er hovedarbeidet.
Det omfatter:
å velge mellom bilde-, video-, lyd- eller chatmodeller
å teste om en promptretning er verdt å beholde
å sammenligne visuelle resultater side om side
å avgjøre om referansemedier hjelper eller skader
å bruke lagret historikk til å fortsette fra et tidligere resultat
Dette gjelder spesielt kreativt arbeid. Hvis briefen ikke er stabil, gjør automatisering av forespørselen vanligvis forvirringen raskere i stedet for mindre.
API-et blir den bedre stien når inputene og de neste stegene er forutsigbare nok.
Gode tegn:
produktet ditt vet allerede hvilken modell eller modellkategori det trenger
brukerinndata kan tilordnes en stabil forespørselskropp
en jobb på serversiden kan kontrollere status jevnlig uten at noen følger med på en skjerm
en aktivert webhook kan oppdatere riktig oppføring når en oppgave er ferdig
appen kan forklare kredittbruk for teamet eller kontoeieren
På det tidspunktet kan det bli den tregere stien å bruke Studio for hver kjøring. API-et lar produktet ditt starte oppgaven direkte.
Bruk Studio til oppdagelse.
Bruk API-et til integrasjon.
Oppdagelse betyr:
"Hvilken modell bør vi bruke?"
"Hvilken promptform fungerer?"
"Forbedrer referansemedier denne oppgaven?"
"Er outputkvaliteten god nok for denne bruken?"
Integrasjon betyr:
"Denne brukerhandlingen skal opprette én genereringsjobb."
"Denne jobben skal kunne prøves igjen idempotent."
"Denne filen skal lastes opp og knyttes til en modellforespørsel."
"Denne fullførte oppgaven skal oppdatere produktets oppføring."
Den grensen hindrer API-et i å bli en skjult eksperimentflate.
Både Studio- og API-bruk trekker fra de samme Rivya-kontocreditsene.
Det betyr at kredittatferd bør være en del av produktdesignet, ikke noe som legges til i etterkant.
Bruk Studio først når teamet fortsatt må lære kostnadsformen. Bruk API-et når oppgaven er stabil nok til at produktet kan forklare når kreditter kan reserveres eller brukes.
For de gjeldende offentlige reglene, les API-kreditter. Hvis en arbeidsflyt er for dyr til å forklare for kontoeieren, er den ikke klar for API-automatisering ennå.
Referansemedier er ofte der en integrasjon blir mer seriøs.
I Studio kan en person laste opp, inspisere, prøve på nytt og avgjøre om filen er god nok. I API-et må produktet ditt håndtere filstien bevisst gjennom Fil-API.
Bruk Studio når:
referansebildet, videoen eller lyden fortsatt trenger menneskelig opprydding
teamet er usikkert på hvilken referanse som bør styre modellen
filreglene ennå ikke er tydelige for brukeren
Bruk API-et når:
appen kan samle inn filen trygt
modellens referansekrav er kjent
filen kan lastes opp før genererings- eller chatforespørselen
feil kan vises i ditt eget produkt uten å skjule hva som skjedde
Fil-API er en nyttig bro, men fjerner ikke behovet for å utforme filopplevelsen.
Chat kan høre hjemme på begge sider.
Bruk Rivya Chat direkte når en person utforsker, skriver, gjennomgår eller bestemmer.
Bruk Chat API når chatrunden må leve inne i ditt eget produkt eller serverarbeidsflyt. Det kan omfatte ikke-strømmende runder, valgfri SSE-strømming, API-opprettede sesjoner og støttede filvedlegg.
Nøkkelspørsmålet er hvor samtalen skal leve. Hvis samtalen er del av Rivya-arbeid, bruk Rivya. Hvis samtalen er del av produktopplevelsen din, bruk API-et.
Hvis arbeidsflyten trenger API Webhooks, har den sannsynligvis passert det manuelle Studio-stadiet. Bekreft at webhooks er aktivert for distribusjonen før du gjør dem til en del av produksjonsdesignet.
Webhooks er nyttige når et annet system må reagere på fullførte genereringsoppgaver:
merke en ressurs som klar
varsle en bruker
flytte et gjennomgangssteg videre
flytte en mislykket oppgave inn i støtte- eller gjenforsøkslogikk
Det er integrasjonsarbeid. Studio kan fortsatt være nyttig for å teste modellstien, men produksjonsloopen hører hjemme i API-et.
Ikke flytt en hel arbeidsflyt inn i API-et på én gang.
Bruk denne rekkefølgen:
test oppgaven manuelt i Studio
skriv ned stabil modell, promptform, inputfiler og forventet resultat
les API-modeller og modellreferansen
send én generering gjennom API Quickstart
legg til Fil-API bare hvis modellen krever referansemedier
legg først til webhooker etter at statusspørringen fungerer og webhooktilgangen er aktivert
legg til Chat API bare hvis produktet trenger chatrunder utenfor Studio
Hvert steg bør gjøre arbeidsflyten enklere å drive, ikke bare mer automatisert.
Bli i Studio når oppgaven fortsatt trenger:
subjektiv gjennomgang
promptforming
visuell sammenligning
modellutforsking
lagret kreativ historikk
en person som avgjør om neste steg er bilde, video, lyd eller chat
Det er ikke en svakhet. Studio er designet for den fasen.
Flytt til API når:
samme oppgave gjentas ofte
inputen kan struktureres
modellen er kjent
appen må opprette oppgaver fra sitt eget UI
status, feil og kreditter kan håndteres tydelig
statusspørring, eller webhooker når de er aktivert, passer til produktets serverside
API-et er sterkest når det gjør en allerede forstått Rivya-arbeidsflyt til en pålitelig produkthandling.
Bruk Developers til å forhåndsvise API-flaten.
Les Rivya API Quickstart før du skriver produksjonskode.
Les API Authentication før du lagrer en API-nøkkel.
Les Slik bygger du en multimodal AI-arbeidsflyt med Rivya API hvis neste spørsmål er hvordan du kobler modeller, filer, chat og webhooks.
Bruk Slik flytter du arbeid mellom chat, bilde, video og lyd i Rivya hvis prosjektet fortsatt hører hjemme i menneskestyrt Studio-arbeid.