Umetna inteligenca v realnem času, varna v brskalniku prek prehoda API: Efemerni žetoni, politika najemnikov in nadzor glasovnih sej

Brskalnik in mobilne aplikacije ne smejo prejemati dolgotrajnih ključev API ponudnika. Pri glasovni umetni inteligenci v realnem času pa pošiljanje vsakega zvočnega paketa prek prehoda lahko doda zakasnitev, stroške delovanja in načine napak. Boljši vzorec je, da prehod ostane v nadzorni ravnini: preverite pristnost uporabnika, uveljavite politiko najemnika, rezervirajte proračun, napišite ozko kratkotrajno poverilnico v realnem času in dovolite medijem, občutljivim na zakasnitev, da uporabljajo ponudnikov prenos v realnem času, kjer je to primerno.

Ta članek opisuje vzorec implementacije za ekipe, ki gradijo glasovne posrednike, pomočnike pri klicu, mobilne mentorje, podporne kopilote ali glasovne vmesnike v aplikaciji prek prehoda API-ja AI. Cilj je varnost brskalnika brez izgube upravljanja najemnika.

Težava: neposredne povezave v realnem času obidejo vaše kontrole

Navadni proxy na strani strežnika je privlačen, ker centralizira ključe in opazljivost. Za standardne besedilne zahteve je to pogosto pravi model. Zvok v realnem času je drugačen. Glasovna seja lahko vključuje neprekinjen vnos mikrofona, dvosmerni zvočni izhod, prekinitve, klice orodij in stroge pričakovane zakasnitve. Posredovanje vseh medijev prek vašega prehoda lahko spremeni prehod v medijski rele z veliko pasovno širino, namesto v storitev pravilnika in obračunavanja.

Neposredne povezave med brskalnikom in ponudnikom rešujejo zakasnitev, vendar ustvarjajo drugo težavo:

• Brskalnik ne more varno hraniti standardnega ključa API ponudnika.
• Preverjanje proračuna najemnika bo morda preskočeno, če se aplikacija poveže neposredno.
• Omejitve modela, regije, glasu, modalnosti in orodij postanejo obljube na strani odjemalca.
• Dodeljevanje uporabe postane nepopolno ali z zamudo.
• Varnostne ekipe izgubijo točko odločitve, ki jo je mogoče preveriti, preden se seja začne.

Praktična zasnova ni "posredovanje vsakega bajta." Je »posrednik vsake seje«.

Dejstva, priporočila in napovedi

Dejstva: Ponudniki umetne inteligence v realnem času vedno bolj podpirajo prenose z nizko zakasnitvijo, kot so WebRTC, WebSocket in SIP. Javna dokumentacija za OpenAI's Realtime API opisuje vmesnike z nizko zakasnitvijo v realnem času, vključno z WebRTC. Navodila za WebRTC v realnem času Azure OpenAI opisujejo brskalniško aplikacijo, ki uporablja storitev zalednega žetona za pridobitev efemernega žetona pred zagonom povezave WebRTC, in svari pred uporabo standardnega ključa API v odjemalski aplikaciji. Smernice SDK za agente OpenAI v realnem času priporočajo tudi potek, pri katerem zaledje ustvari kratkotrajni žeton odjemalca, brskalnik pa ga uporabi za vzpostavitev povezave WebRTC.

Priporočila: Obravnavajte prehod kot avtoriteto seje. Odločiti se mora, ali lahko obstaja seja v realnem času, s katerim modelom, v kateri regiji, za katerega najemnika, v okviru katerega proračuna in s katerimi orodji. Odjemalec bi moral prejeti samo minimalno kratkotrajno poverilnico, potrebno za začetek odobrene seje.

Napovedi: API-ji ponudnikov v realnem času bodo nekaj časa ostali neenakomerni. Življenjska doba žetonov, konfiguracijska polja seje, kontrolniki prekinitve povezave na strani strežnika, dogodki uporabe in podpora za regijo se bodo razlikovali. Prehodi bi morali izrecno modelirati zmogljivosti ponudnika, namesto da bi se pretvarjali, da so vsi API-ji v realnem času popolnoma prenosljivi.

Referenčna arhitektura: prehod kot nadzorna ravnina v realnem času

V brskalniku varen tok v realnem času ima pet delov:

1. Odjemalska aplikacija: Brskalnik ali mobilna aplikacija, ki zahteva glasovno sejo.
2. Zaledje aplikacije: overi končnega uporabnika in pokliče prehod ali vdela logiko kovanja žetonov prehoda, če je prehod del sklada zaledja.
3. Prehod AI API: Uveljavlja politiko najemnika, razrešuje profil modela, rezervira proračun, beleži sejo in kuje efemerno skrivnost odjemalca ponudnika.
4. Ponudnik v realnem času: prekine WebRTC ali drug prenos v realnem času.
5. Knjiga in analitika: poravna porabo, ko so na voljo dogodki ponudnika, podatki o trajanju ali končna poročila o uporabi.

Prehodu ni treba posredovati vsakega zvočnega okvirja, da ostane verodostojen. Lastnik mora biti odločitev o ustvarjanju seje in pot usklajevanja.

Priporočen potek zahtev

1. Uporabnik odpre glasovno funkcijo v odjemalski aplikaciji.
2. Odjemalec pokliče vaše zaledje: POST /voice/sessions.
3. Zaledje preveri uporabniško sejo in prehodu posreduje zahtevo za mint z ID-jem najemnika, ID-jem uporabnika, predvideno funkcijo, metapodatki naprave in izvorom.
4. Prehod ocenjuje politiko in proračun.
5. Prehod ustvari lokalni zapis realtime_session, preden vzpostavi stik s ponudnikom.
6. Prehod pokliče ponudnika s svojo zaščiteno poverilnico izvajalnega časa in ustvari kratkotrajno sejo v realnem času z ozkim obsegom.
7. Prehod brskalniku vrne le kratkotrajno skrivnost odjemalca in odobrene metapodatke o seji.
8. Brskalnik vzpostavi povezavo WebRTC neposredno s ponudnikom.
9. Prehod zajema dogodke uporabe ponudnika, povratne klice, rezultate glasovanja ali konzervativne ocene na podlagi trajanja.
10. Knjiga poravna rezervirani proračun in zapiše revizijske dogodke.

Preverjanje pravilnika pred kovnico

Najpomembnejša točka uveljavljanja je pred kovanjem efemernega žetona. Ko ima brskalnik kratkotrajno poverilnico, je lahko uveljavljanje med sejo omejeno, razen če ponudnik podpira posodobitev seje, prekinitev povezave, opazovanje ali nadzor povratnega klica.

Prehod mora preveriti najmanj:

• Status najemnika: aktiven, začasno ustavljen, poskusni, predplačniški, z računom ali v karanteni.
• Upravičenost uporabnika: ali lahko ta uporabnik uporablja glasovni klepet v realnem času, ne samo besedilni klepet.
• Dovoljen profil modela: odobren model ali uvedba v realnem času, ne samovoljni ID-ji modela, ki jih zagotovi stranka.
• Politika regije in hrambe: ali se izbrana regija ponudnika in nabor funkcij ujemajo s pravili podatkov najemnika.
• Največje trajanje seje: na primer 5, 15 ali 30 minut po načrtu.
• Dovoljene modalitete: zvočni vhod, zvočni izhod, besedilo, slika ali klici orodij.
• Predloga za glas in navodila: določeno ali omejeno s pravilnikom.
• Razpoložljivi proračun: predplačniško stanje, rezervirano mesečno nadomestilo ali zgornja meja porabe za posamezno funkcijo.
• Sočasnost: aktivne glasovne seje na ravni najemnika in na ravni uporabnika.
• Nadzor zlorabe: oznake tveganja uporabnika, ugled izvora, nenavadna hitrost klica ali stikalo za izklop najemnika.

Varna privzeta vrednost je zavrnitev dvoumnih zahtev. Če odjemalec zahteva model, orodje, glas ali regijo, ki ni v najemnikovem pravilniku v realnem času, bi moral prehod namesto tihega razširitve dostopa vrniti jasno napako pravilnika.

Zasnova zapisa seje

Pred kovanjem poverilnice ponudnika ustvarite zapis seje na strani prehoda. To vam daje revizijsko sidro, tudi če ustvarjanje ponudnika uspe, vendar se brskalnik nikoli ne poveže.

{
  "session_id": "rt_01j...",
  "tenant_id": "najemnik_123",
  "end_user_id": "user_hash_456",
  "ponudnik": "ponudnik_a",
  "provider_session_id": nič,
  "model_profile": "standard-glasovne podpore",
  "upstream_model_or_deployment": "realtime-model-x",
  "regija": "eastus",
  "session_config_hash": "sha256:...",
  "allowed_modalities": ["avdio_vhod", "avdio_izhod"],
  "allowed_tools": ["lookup_order_status"],
  "tool_approval_policy": "odobri stranske_učinke",
  "budget_reservation_id": "resv_789",
  "max_duration_seconds": 900,
  "issued_at": "2026-08-21T10:00:00Z",
  "expires_at": "2026-08-21T10:01:00Z",
  "client_origin": "https://app.example.com",
  "device_id_hash": "sha256:...",
  "status": "kovanje"
}

Privzeto ne shranjuj neobdelanega zvoka mikrofona ali celotnih pozivov. Shranite konfiguracijske zgoščene vrednosti, ID-je, odločitve o pravilnikih in minimalne količine metapodatkov, ki zadostujejo za revizijo, podporo in zaračunavanje. Če je snemanje potrebno, naj bo eksplicitno, upoštevajoč privolitev in temelji na pravilniku najemnika.

Končna točka kovanja efemernih žetonov

Končna točka, obrnjena proti prehodu, je lahko videti takole:

POST /v1/realtime/sessions
Avtorizacija: nosilec 
Vrsta vsebine: aplikacija/json
{
  "tenant_id": "najemnik_123",
  "end_user_id": "user_hash_456",
  "feature": "support_voice_agent",
  "izvor": "https://app.example.com",
  "device_nonce": "8f3b ...",
  "requested_profile": "standard-glasovne podpore"
}

Odziv ne sme razkriti vašega ključa izvajalnega okolja navzgor:

{
  "session_id": "rt_01j...",
  "ponudnik": "ponudnik_a",
  "transport": "webrtc",
  "client_secret": "efemerna_skrivnost_tukaj",
  "expires_at": "2026-08-21T10:01:00Z",
  "odobreno": {
    "model_profile": "standard-glasovne podpore",
    "max_duration_seconds": 900,
    "modalitete": ["avdio_vhod", "avdio_izhod"],
    "tools": ["lookup_order_status"]
  }
}

Povežite izdajo z izvorom, sejo preverjenega uporabnika, najemnikom in nonce. Ponudnik morda izvorno ne podpira vseh teh vezav, zato na prehodu uveljavljajte, kar lahko: omejite hitrost poskusov kovanja, zavrnite nepričakovane izvore, snemajte metapodatke naprave in ohranite kratko življenjsko dobo žetona.

Predloge sej: privzeto ozke

Predloga seje v realnem času bi morala biti bolj restriktivna kot splošna zahteva za dokončanje klepeta. Glasovne seje so interaktivne, težje jih je pregledati v realnem času in lahko trajajo dlje, kot je pričakovano.

Priporočena polja predloge vključujejo:

• Fiksni model ali uvedba: izbran s profilom modela na strani prehoda.
• Navodila: predloga poziva, ki jo nadzoruje strežnik, s spremenljivkami, ki jih odobri najemnik.
• Glas: izbran s seznama dovoljenih.
• Modalitete: onemogočite besedilne, slikovne ali orodne načine, razen če jih izdelek potrebuje.
• Nastavitve vhodnega zvoka: zaznavanje obračanja, obnašanje prepisa ali upravljanje tišine, kjer je podprto.
• Omejitve izhoda: največja dolžina odziva ali obnašanje odziva, kjer je podprto.
• Seznam dovoljenih orodij: samo orodja, potrebna za funkcijo.
• Življenjska doba seje: kratek potek poverilnice in največje trajanje klica.

Stroge predloge zmanjšujejo prilagodljivost, vendar olajšajo stroške, skladnost in podporo. Če produktne ekipe potrebujejo dinamične glasove ali navodila, izpostavite nadzorovane različice profila, namesto da posredujete poljubno konfiguracijo odjemalca ponudniku.

Kontrole proračuna za glas v realnem času

Uporabo v realnem času je težje določiti, preden prispe končna poraba ponudnika. Seja lahko traja pet sekund ali dvajset minut. Vključuje lahko zvočni vhod, zvočni izhod, prepis, klice orodij in besedilne žetone. Prehod mora torej združevati rezervacije, zgornje meje in usklajevanje.

Pred kovanjem

• Ocenite najslabši možni ali konzervativni strošek seje na podlagi največjega trajanja, modela, modalitet in načrta najemnika.
• Rezervirajte proračun, preden izdate skrivnost stranke.
• Zavrni nove seje, če najemnik nima dovolj sredstev ali je dosegel dnevne glasovne omejitve.

Med sejo

• Sledite aktivnim sejam in pričakovani stopnji izgorevanja.
• Uporabite omejitve sočasnosti najemnikov in uporabnikov.
• Uporabite funkcije prekinitve ali posodobitve seje, ki jih podpira ponudnik, če so na voljo.
• Sproži opozorila za neobičajno trajanje seje, ponavljajoče se vnovične povezave ali nenavadno uporabo glasu.

Po seji

• Vnesite dogodke uporabe ponudnika ali končna poročila o uporabi, kjer so na voljo.
• Poravnajte rezervirani proračun z dejanskimi stroški.
• Če natančna uporaba zamuja ali je nepopolna, ohranite konzervativno rezervacijo do uskladitve.
• Pripišite uporabo najemniku, uporabniku, funkciji, profilu modela in ID-ju seje.

To je manj natančno kot sinhrono besedilno zaračunavanje v trenutku odgovora, vendar je operativno varnejše od izdajanja neposrednih poverilnic brez rezervacije.

Klici orodij znotraj sej v realnem času

Glasovni posredniki v realnem času pogosto postanejo bolj uporabni, ko lahko pokličejo orodja: poiščejo račun, rezervirajo sestanek, posodobijo vstopnico ali sprožijo potek dela. Izvajanje orodja obravnavajte ločeno od prenosa zvoka.

Medijska povezava brskalnika ne sme pomeniti dovoljenja za izvajanje stranskih učinkov. Prehod ali zaledje mora uveljaviti:

• Register orodij: vsako orodje ima lastnika, shemo, obsege in raven tveganja.
• Seznami dovoljenih: predloge sej natančno navajajo, katera orodja so na voljo.
• Prehodi za odobritev: dejanja s stranskimi učinki zahtevajo potrditev uporabnika, človeško odobritev ali odobritev pravilnika.
• Ločene poverilnice: poverilnice orodja niso nikoli vdelane v sejo brskalnika.
• Združena revizijska sled: vsak klic orodja se sklicuje na ID seje v realnem času.

Glasovnemu agentu podpore je na primer morda dovoljeno, da samodejno pokliče lookup_order_status, vendar refund_payment morda zahteva izrecno potrditev in dogodek odobritve zaledja. Ponudnik v realnem času lahko organizira pogovor, vendar bi moral vaš prehod urejati mejo dovoljenj.

Vidnost brez posredovanja vsakega bajta

Neposredni medijski tok WebRTC zmanjša zakasnitev prehoda in obremenitev pasovne širine, vendar postane vidnost bolj odvisna od dogodkov ponudnika in vaših lastnih metapodatkov seje. Oblikujte analitiko okoli več virov dokazov:

• Zapisi o ustvarjanju seje iz prehoda.
• Dogodki življenjskega cikla na strani odjemalca, kot so vzpostavljena, prekinjena povezava, poskus ponovne povezave, zavrnjen mikrofon ali končan klic.
• ID-ji seje ponudnika, dogodki uporabe ali končni zapisi uporabe.
• Ocene na podlagi trajanja, ko uporaba ponudnika zamuja.
• Dnevniki klicev orodij, združeni z ID-jem seje.
• Rezervacija proračuna in evidenca poravnave.

Ne čakajte na popolno telemetrijo ponudnika, preden zaženete kontrole. Začnite s konzervativnimi rezervacijami in jasnim pripisovanjem, nato pa izboljšajte natančnost poravnave, ko poročanje o uporabi ponudnika dozoreva.

Varnostni kontrolni seznam

• Nikoli ne pošiljajte standardnih ključev API ponudnika v brskalnik ali mobilne odjemalce.
• Uporabite kratkotrajne efemerne odjemalske skrivnosti za zagon seje v realnem času.
• Preverite pristnost končnega uporabnika pred kovanjem žetonov.
• Kjer je mogoče, povežite odločitve o kovanju z metapodatki najemnika, uporabnika, izvora, enkratnih podatkov in metapodatkov naprave.
• Hranite poverilnice izvajalnega okolja ponudnika v zalednem trezorju ali skrivni shrambi prehoda.
• Zabeležite vrstico revizije seje pred kovanjem ponudnika.
• Uporabite predloge sej, ki jih je odobril najemnik, namesto poljubne konfiguracije odjemalca.
• Uporabite omejitve sočasnosti, dnevne uporabe in največjega trajanja.
• Za stranske učinke uporabite sezname dovoljenih orodij in prehode za odobritev.
• Privzeto minimizirajte neobdelane pozive in zadrževanje zvoka.
• Vzdržujte matriko zmogljivosti ponudnika za življenjske dobe žetonov, regije, orodja, dogodke uporabe in kontrole prekinitev.

Matrika zmogljivosti ponudnika

Ker se API-ji v realnem času razlikujejo, modelirajte adapter prehoda glede na zmogljivosti in ne predpostavk. Preprosta matrika lahko vodi usmerjanje in odločitve o politiki:

{
  "ponudnik_a": {
    "transporti": ["webrtc", "websocket"],
    "ephemeral_client_tokens": drži,
    "token_ttl_seconds": 60,
    "server_side_disconnect": drži,
    "session_update": res,
    "usage_events": "končni_in_inkrementalni",
    "regije": ["nas", "eu"],
    "tool_approval_supported": res
  },
  "ponudnik_b": {
    "transporti": ["websocket"],
    "ephemeral_client_tokens": drži,
    "token_ttl_seconds": 120,
    "server_side_disconnect": false,
    "session_update": false,
    "usage_events": "samo končno",
    "regije": ["nas"],
    "tool_approval_supported": false
  }
}

Če najemnik zahteva stalno prebivališče v EU in prekinitev na strani strežnika, bi moral prehod usmerjati samo k ponudnikom in uvedbam, ki izpolnjujejo oboje. Če noben ponudnik ne izpolnjuje pravilnika, neuspešno zaprtje.

Pot selitve

Ni vam treba zgraditi vsake kontrole prvi dan. Praktična uvedba je:

1. Samo ustvarjanje seje posrednika: mediji naj bodo neposredni, vendar zahtevajo, da vse seje v realnem času kuje zaledje ali prehod.
2. Dodajte predloge pravilnika: zamenjajte polja z modelom in navodili, ki jih zagotovi stranka, z odobrenimi profili.
3. Dodaj proračunsko rezervacijo: rezerviraj konzervativne stroške seje pred izdajo žetona.
4. Dodajte analitiko življenjskega cikla: zberite začetek seje, povezavo, prekinitev povezave, trajanje, ID seje ponudnika in stanje poravnave.
5. Dodajte upravljanje orodij: zahtevajte sezname dovoljenih in odobritve za klice orodij v realnem času.
6. Dodajte usmerjanje zmogljivosti ponudnika: izberite ponudnike po regiji, modalnosti, podpori za dogodke in kontrolnikih za prekinitev.
7. Dodajte izbirne poteke dela opazovalca ali snemanja: samo tam, kjer je skladno, privoljeno in odobreno s strani najemnika.

Dejanski sklep

Za glasovni AI v realnem času prehod API-ja AI ne sme samodejno postati medijski rele. Varnejša arhitektura z nižjo zakasnitvijo je, da prehod nadzoruje nadzorno ravnino: preverja pristnost uporabnikov, uveljavlja politiko najemnikov, rezervira proračun, ustvarja revizijski zapis, kuje kratkotrajne poverilnice z ozkim obsegom in usklajuje uporabo po seji.

Osnovno pravilo implementacije je preprosto: brskalniki lahko prejmejo kratkotrajne skrivnosti seje, nikoli pa dolgotrajnih ključev ponudnika. Vse drugo izhaja iz te meje: stroge predloge, kovanje z upoštevanjem izvora, omejitve sočasnih sej, odobritve orodij, poravnava uporabe in matrike zmogljivosti ponudnika. To ekipam izdelkov omogoča glasovne izkušnje v realnem času, ne da bi se odrekli upravljanju ključev API-ja, nadzoru stroškov API-ja AI, upravljanju API-ja skupine ali analizi uporabe umetne inteligence.

Sorodno branje

• ponudnik shramba poverilnic za ključe med izvajanjem
• knjiga rezervacij proračuna in poravnave