Rivya-guide for referanser og opplastinger

Bruk denne guiden for referanser og opplastinger før du velger en modell som avhenger av bildereferanser, videoreferanser eller opplastet lyd.

Referanser og opplastinger er en kjerne i hvordan Rivya-oppgaver beveger seg fra discovery til innlogget Studio-utføring.

De påvirker:

• modellvalg

• arbeidsflytvalg

• promptstruktur

• oppgavekostnad

• om brukeren bør starte på en offentlig startside, modelldetalj eller Studio

Derfor er opplastinger ikke bare en UI-detalj. De er del av arbeidsflytlogikken.

Én operativ detalj betyr noe tidlig:

• referansebevisste sider kan være offentlige

• faktisk filopplasting krever for tiden innlogging

En offentlig startside kan derfor fortsatt være riktig sted å begynne, men opplastingsbasert utføring er ikke fullstendig anonym i det nåværende produktet.

Tre opplastingsformer

I dag faller referanse- og opplastingsatferd i Rivya hovedsakelig i tre former:

• bildereferanser

• videoreferanser

• lydopplastinger

Ikke alle modeller støtter alle tre.

Derfor betyr modellsiden noe før oppgaven starter.

Bildereferanser

Mange bilde- og videoarbeidsflyter støtter bildereferanser.

Avhengig av modell kan grensene for referansebilder variere mye.

Akkurat nå går dette spennet fra:

• ett enkelt referansebilde

• større flerbildearbeidsflyter

Dette betyr noe fordi "støtter referanser" og "støtter mange referanser" ikke er det samme.

Videoreferanser

Noen videoarbeidsflyter kan også godta videoreferanser eller andre utvidede referansemoduser.

Dette er ikke universelt på tvers av katalogen.

Derfor bør brukere ikke anta at alle videomodeller kan ta samme type input bare fordi de hører til samme kategori.

Lydopplastinger

Lydopplastinger betyr mest i arbeidsflyter som:

• lydopprydding

• lydisolering

• lydtransformasjon

Disse er strukturelt forskjellige fra prompt-first-lydgenerering.

Hvis modellen forventer opplastet lyd, oppfører skjemaet seg annerledes med vilje.

Hvorfor skjemaet endrer seg etter modell

Rivyas genereringsskjemaer er modelldrevne.

Det betyr at synlige inndata avhenger av:

• hva den valgte modellen støtter

• hvilke filtyper den godtar

• hvor mange filer den kan ta

Dette er riktig atferd, fordi en prompt-only-modell og en upload-first-modell ikke er samme arbeidsflyt.

Gjeldende opplastingskinds

De viktigste opplastingskindene brukt i gjeldende produktflyter er:

• image

• video

• audio

Disse normaliseres inne i produktet før de sendes inn i den endelige modellforespørselen.

Gjeldende opplastingsgrenser

Opplastingsveien håndhever for tiden størrelse- og typesjekker etter kind:

Bilde

• JPEG

• PNG

• WebP

• gjeldende standard maks størrelse: 10 MB

• Nano Banana 2 og Nano Banana Pro tillater for tiden opptil 30 MB

Video

• MP4

• MOV / QuickTime

• WebM

• gjeldende maks størrelse: 50 MB

• Wan 2.6 bruker for tiden en strengere 10 MB-grense og godtar MP4, MOV / QuickTime og MKV-lignende videoopplastinger

Lyd

• MP3

• MP4 audio

• WAV

• AAC

• OGG

• gjeldende standard maks størrelse: 10 MB

Disse grensene handler om trygg ingest og ruting, ikke bare UI-bekvemmelighet.

Referanser og modellvalg

Referansestøtte betyr ofte mer enn hype.

For eksempel:

• hvis arbeidsflyten trenger mange bildereferanser, velges riktig modell sjelden bare etter merkevarerykte

• hvis arbeidsflyten trenger opplastet lyd, er en standard TTS-modell feil inngang

Derfor er den ryddigste rekkefølgen for modellvalg:

1. utdatatypen

2. referanse- eller opplastingskrav

3. kostnads- og kvalitetspassform

4. først deretter modellpreferanse

Offentlige sider kontra Studio

Offentlige startsider er gode når du vil ha:

• en første offentlig landingsside

• en direkte modellspesifikk inngang

• en søkedrevet vei inn i riktig arbeidsflyt

Studio er bedre når oppgaven trenger:

• innlogget opplasting og utføring

• gjentatt iterasjon

• mer kontinuitet

• en fyldigere arbeidskontekst

Dette gjelder særlig når selve opplastingen blir del av en lengre arbeidsflyt.

Vanlige feil

Feil 1: Å anta at alle modeller i en kategori godtar samme filtyper

Det gjør de ikke.

Feil 2: Å velge modell før du sjekker opplastingsstøtte

Dette skaper ofte unødvendig omarbeid.

Feil 3: Å behandle opplastet-lyd-arbeidsflyter som prompt-only-arbeidsflyter

Dette er ulike veier og bør behandles ulikt.

Referansearbeidsflyt

En praktisk vei i Rivya ser slik ut:

1. sjekk modellsiden for referansestøtte

2. velg riktig offentlig startside eller Studio-vei

3. logg inn før faktisk opplasting hvis kontokontekst kreves

4. last bare opp de kindene modellen faktisk støtter

5. hold prompten på linje med den opplastede konteksten

6. gjennomgå resultatet og iterer i samme arbeidsflyt

Les videre

• Modeller

• Bildearbeidsflyter i Rivya

• Videoarbeidsflyter i Rivya

• Lydarbeidsflyter i Rivya

• Offentlige og autentiserte arbeidsflyter i Rivya

• Feilsøking i Rivya

• AI-bildegenerator med referansebilder

Sjekkliste for referanseopplasting

Før en oppgave avhenger av en referansefil eller opplasting, bør du kontrollere:

• Bekreft om oppgaven trenger en bildereferanse, videoreferanse, lydopplasting eller ingen fil i det hele tatt.

• Sjekk modellsiden for støttede filkinds og grenser før du forbereder ressurser.

• Bestem om oppgaven hører hjemme på en offentlig startside eller innlogget Studio.

• Fjern sensitivt eller unødvendig filinnhold før opplasting.

• Hold prompten på linje med hva hver opplastede fil skal kontrollere.

Målet er å gjøre filen nyttig, tillatt og relevant før du bruker credits.

Når du bør kontrollere opplastingspassform på nytt

Kontroller opplastingspassform på nytt når valgt modell endres, en fil er for stor, en referanserolle er uklar, eller ressursen inneholder personer, logoer, private data eller klienteid materiale.

I slike tilfeller bør du lese Retningslinjer for trygg opplasting og den relevante referansesiden før du starter en ny kjøring.