Nagbibigay ang realtime voice ng ibang-ibang paraan upang makipag-ugnayan ang mga tao sa mga application na pinapagana ng AI. Sa halip na mag-type o mag-navigate sa mga menu, natural na nagsasalita ang mga user at tumatanggap ng mga tugong may real-time na pacing at emosyonal na konteksto.
Ang pagbuo ng mahusay na realtime voice experience ay tungkol sa pag-uugnay ng isang live na interaksiyon. Dito nagsisimula ang tunay na paggawa ng produkto. Agad at natural ang realtime na karanasan; isang natatanging hamon sa engineering ang pagbuo ng application na nagpapanatili nito.
Bahagi lamang ng system ang modelo. Kailangan ng mga production application ng voice-native na infrastructure, malinaw na paghihiwalay ng daloy ng usapan at mas malalim na pangangatwiran, at event-driven na kontrol upang pamahalaan ang session habang nagaganap ito.
Nasa mga guardrail at pagsusuri ang karamihan sa natitirang hamon. Kailangang makasabay sa live na audio ang mga pagsusuri sa kaligtasan, at mahirap tasahin gamit ang mga tradisyonal na paraan ang mga panandaliang katangian ng usapan gaya ng timing, tono, at daloy.
Pareho pa rin ang paraan ng paggana ng karamihan sa mga voice-enabled AI application ngayon: pumapasok ang pagsasalita, lumalabas ang text, nag-iisip ang isang modelo, at binabasa ng synthesized na boses ang sagot. Gumagana ito. Ngunit halatang pipeline ang interaksiyon, hindi tunay na pag-uusap.
Binabago iyon ng realtime voice. Natural na nagsasalita ang mga user at tumatanggap ng mga tugong may pacing, tono, at emosyonal na konteksto. Mas mabilis at mas tuloy-tuloy ang karanasan kaysa sa mga chained speech-to-text pipeline—mas parang pakikipag-usap sa tao kaysa pagpapatakbo ng system.
Nakita naming nagbubukas ito ng mga posibilidad sa produkto na mahirap tugunan ng mga pipeline architecture. Kayang pangasiwaan ng mga realtime voice agent ang mga interaksiyon sa customer service na kung hindi ay mangangailangan ng mahahaba at mahihigpit na IVR menu at paglilipat sa iba't ibang departamento. Maaari silang mag-coach, mag-onboard, tumulong sa accessibility sa iba't ibang medium, at marami pang iba. Saanman mas kapaki-pakinabang ang pasalitang pag-uusap kaysa sa text-based na interface, sulit buuin ang realtime voice.
Ginagamit ng karamihan sa mga voice-enabled application ang tinatawag na “chained approach”: isang pipeline ng magkakahiwalay na modelo para sa speech-to-text, pagproseso ng wika, at text-to-speech. Mahusay gumana ang mga system na ito at nagbubukas ng maraming oportunidad, ngunit nasa magkabilang dulo lamang ang audio. Nagdaragdag ng mahigpit na istruktura at latency ang magkakahiwalay na hakbang, kaya hindi kasingnatural ng tunay na pag-uusap ang interaksiyon.
Iba ang paraan ng realtime voice. Sa halip na umasa sa magkakahiwalay na modelo para sa pakikinig, pag-iisip, at pagsasalita, iisang modelo ang likas na gumagawa sa tatlo—sabay nitong inuunawa at binubuo ang audio at mga transcript. Tuloy-tuloy ang input at output, kaya nakakatugon ang system nang may natural na timing at emosyon habang pinananatili ang makatotohanang ritmo ng live na usapan. Dahil dito, nagiging pangunahing bahagi ng produkto ang timing, tono, at paghawak sa mga pagsingit.
Kaakit-akit ang realtime na karanasan dahil agaran ito; mahirap ito dahil walang naghihintay ng sariling pagkakataon. Higit pa sa mabilis at tumpak na pagbuo ng audio ang kailangan upang masuportahan ito. Ang mahirap ay ang lahat ng iba pa. Gumagana ang modelo sa loob ng live session; kailangang tumakbo ang lahat ng nakapaligid dito—state, kaligtasan, orchestration, at kontrol—kasabay ng usapan at sa parehong live na bilis.
Sa chained voice application, nagbibigay ang salitang pag-uusap ng malinaw na pabalik-balik na istruktura. Nagsasalita ang user, tumutugon ang system, at nagsisimula ang susunod na hakbang. Hindi ibinibigay ng realtime voice ang istrukturang iyon. Maaaring sabay magsalita ang dalawang panig, o walang magsalita at manatiling tahimik. Maaaring sumingit ang user sa kalagitnaan ng tugon o magtanong muli bago matapos magsalita ang system. Hindi na pambihirang sitwasyon ang mga pagsingit; nagiging pangunahing pattern ng interaksiyon ang mga ito.
Dahil sa pattern na ito, ang mga realtime application ay pangunahing problema sa koordinasyon, at kasinghalaga ng mismong modelo ang system sa paligid nito.
Upang masuportahan nang malawakan ang ganitong system, kailangang idisenyo ito para mismo sa live na interaksiyon. May tatlong bahaging paulit-ulit na makikita sa mga system na umaabot sa production.
Kailangang pangasiwaan ng mga realtime voice session ang audio streaming, pagsasalitan, mga pagsingit, lifecycle ng koneksiyon, at pagpapatakbo ng agent. Depende sa deployment ng application, maaaring kailanganin din ang suporta sa telephony. Mga pundamental na bahagi ito ng karanasan at mahalaga sa pagpapalawak ng application.
Ang unang kailangan ay isang voice-native na session layer. Nagbibigay ang mga Realtime Communication (RTC) framework ng lugar kung saan mapapamahalaan ng application ang mga kalahok, makakapag-stream ng audio, at makakapagpatakbo ng mga agent sa isang telephony environment. Sa aming karanasan, partikular na nakakatulong ang Livekit. Nagbibigay ito ng low-latency na WebRTC stack na may de-kalidad na noise cancellation at built-in na jitter reduction. Bihirang sulit ang dagdag na komplikasyon ng sariling pagpapatupad ng layer na ito.
Ang multi-agent architecture para sa realtime voice ay pangunahing nakatuon sa paghihiwalay ng mga responsibilidad.
Napakahusay ng mga realtime voice modelo sa streaming ng audio para sa usapan, ngunit hindi na-optimize ang mga ito para sa mas malalim na pangangatwiran. Mas mainam na ibang modelo ang magsagawa ng mga gawain gaya ng pagtawag sa tool, retrieval, o nakabalangkas na pagpapasya.
Isang kapaki-pakinabang na pattern ang responder–thinker architecture.
Ang responder ang realtime voice agent. Responsibilidad nitong panatilihin ang live na interaksiyon: makinig, magsalita, humawak ng mga pagsingit, at panatilihin ang daloy ng usapan. Inuuna ng disenyo nito ang mabilis na pagtugon, kalinawan, at tuloy-tuloy na emosyon.
Ang thinker ay isang hiwalay na agent na pinapagana ng modelong may kakayahang mangatwiran. Gumagana ito sa labas ng pangunahing channel at pinangangasiwaan ang paggamit ng tool, retrieval, pagpaplano, at iba pang gawain. Maaaring tawagin ito ng responder kapag kailangan at isama ang mga resulta sa pag-uusap.
Sa ilang sitwasyon, maaaring direktang pangasiwaan ng thinker ang pangangatwiran. Sa iba naman, maaari itong maging orchestrator para sa isang hanay ng mga espesyalistang agent. Ang mahalagang ideya ay gawin ang gawaing ito ng modelong mas angkop sa mga gawain sa pangangatwiran.
Simple ang pakinabang: nananatiling mabilis, natural kausap, at nakatuon ang responder, habang inaasikaso ng thinker ang gawaing nangangailangan ng mas maraming oras, konteksto, o istruktura.
Maaaring hindi na kailanganin ang paraang ito dahil sa mga pag-unlad sa mga frontier na modelo sa hinaharap, ngunit sa ngayon, palagi naming nakikitang mas mahusay ang pattern na ito kaysa sa mga paraang gumagamit ng iisang agent.
Likas na gumagawa ang mga realtime voice system ng tuloy-tuloy na stream ng mga event.
Nagsisimulang magsalita, humihinto sandali, at sumisingit ang mga user. Paunti-unting naa-update ang mga transcript. Binubuo at sini-stream ang mga tugon. Dumarating ang mga resulta mula sa labas. Nagbabago ang mga kondisyon sa loob ng session. Maaaring kunin, i-stream, at i-store ang lahat ng ito bilang mahahalagang event na bumuo sa partikular na kasalukuyang estado ng pag-uusap. Kung wala ang mga ito, mawawala ang kakayahan nating gumawa ng detalyado at tiyak na mga interbensiyon.
Nagbibigay ang event-driven na paraan ng malinaw na sistema para pamahalaan ito. Kinukuha ng system ang mga event habang nagaganap ang mga ito, ina-update ang session state, at tini-trigger ang naaangkop na mga susunod na pagkilos.
Pinananatiling mabilis tumugon ng mga magagaang handler ang realtime path, habang tini-trigger bilang mga asynchronous na background task ang mas masalimuot na gawain—gaya ng pag-update ng mga state machine, pag-log ng mga metric, pag-aalis ng sensitibong impormasyon, pag-update ng mga database, at paglabas sa session.
Habang nagdaragdag ng mga feature, maaaring mabilis na dumami ang mga background task na ito. Kahit maliliit na pagbabago sa produkto ay maaaring magdagdag ng mga bagong daloy ng event at dependency. Mahalaga ang maayos na architecture para sa concurrency na ito upang manatiling nauunawaan at maaasahan ang system habang nagbabago ito.
Sinusuportahan din ng event-driven na paraang ito ang isang mahalagang usapin sa produkto: ang paghubog sa mismong pag-uusap. Hindi lamang gumagawa ng mga tugon ang realtime audio system; pinamamahalaan din nito ang pacing, katahimikan, at mga pagsingit, at nagpapasya kung paano at kailan dapat tapusin ang session. Bahagi ng karanasan sa produkto ang mga gawing ito at mas napapahusay ng malinaw na disenyo.
Habang nagbabago ang session state batay sa bilang ng salitan, lumipas na oras, o gawi ng user, makakapagbigay ang system ng tiyak na gabay sa responder. Maaari nitong i-prompt ang agent na tulungan ang user na magtapos habang papalapit sa limitasyon ng session, o magbigay ng paglilinaw kapag natigil ang interaksiyon. Magagaan ang mga interbensiyong ito, ngunit ginagawa nilang mas sinadya at magkakaugnay ang karanasan.
Pinananatili ng mahusay na idinisenyong system ang malinaw na larawan ng session state: sino ang nagsasalita, paano umuusad ang pag-uusap, at aling mga kondisyon ang natugunan na. Ang state na ito, na tuloy-tuloy na ina-update ng event stream, ang nagbibigay-daan sa tamang gabay sa tamang oras.
Hindi opsyonal ang mga guardrail sa AI na direktang ginagamit ng mga user. Pinangangasiwaan ng mga ito ang kaligtasan, pagsunod sa mga patakaran, maling paggamit, at pagiging maaasahan. Sa sistemang salitan, may malinaw na mga pagkakataon para patakbuhin ang mga ito: pagkatapos magsalita ng user o bago ihatid ang tugon.
Inaalis ng realtime voice ang karamihan sa mga maginhawang checkpoint na iyon. Tuloy-tuloy na dumarating ang input ng user. Maaaring sini-stream na ang audio output. Kadalasang nahuhuli sa tunog ang mga nakumpletong transcript. Kung hihintayin ng system ang mga kumpletong mensahe bago suriin ang mga ito, hindi na magiging realtime ang pakiramdam ng pag-uusap.
Sa halip, kailangang tumakbo ang mga guardrail kasabay ng pag-uusap upang mapanatiling natural ang interaksiyon. Isang paraan ang pag-stream ng audio sa isang buffer habang asynchronous na sinusuri ang mga bahagi ng transcript habang nagiging available ang mga ito. Dahil dito, halos real time na naisasagawa ang mga pagsusuri sa kaligtasan nang hindi hinaharangan ang interaksiyon.
Kapag na-trigger ang isang guardrail, makakatugon ang system ayon sa konteksto sa pamamagitan ng pag-iba ng direksiyon ng usapan, pag-aayos ng gawi, o pagtatapos ng session kung naaangkop. Tinitiyak nitong gumagana nang real time ang mga guardrail nang hindi pinapahina ang karanasan ng user.
Ang pinakamahirap sa pagsusuri ng isang realtime na sistemang pang-usapan ay hindi masusukat sa pagsubok na transcript lang ang ilan sa pinakamahahalagang katangian nito—timing, mga pagsingit, daloy, at tono.
Naglalagay ang mga karaniwang eval pipeline ng makatotohanang sitwasyon sa system, inoobserbahan ang mga output, at binibigyan ang mga ito ng score. Diretso lang ito para sa mga text-based o chained-audio system: magpadala ng text at suriin ang lumabas na text. Sa realtime, live na audio ang input, at nasa dimensiyon ng oras ang pinakamahahalagang dinamika ng usapan: kung paano hinahawakan ng agent ang sabayang pagsasalita, kung gaano ito kabilis tumugon, at kung paano ito bumabawi matapos maputol.
Nasasaklaw ng manual na pagsubok—ang direktang pakikipag-usap sa agent—ang mga katangiang ito, ngunit hindi ito nasusukat nang malawakan. Nasusukat nang malawakan ang automation na nakabatay sa transcript, ngunit inaalis nito ang signal na naghihiwalay sa maganda at pangit na realtime na karanasan.
Hindi sapat ang iisang paraan. Ang praktikal na sagot ay isang stack:
Mga pagsusuring agent-to-agent: nakikipag-usap sa sinusubukang system ang isa pang realtime agent na inutusang gumanap bilang isang partikular na uri ng user. Binibigyan ng ikatlong LLM-as-a-judge ng score ang interaksiyon. Nasusubukan nito nang maramihan ang buong audio path, kabilang ang timing at paghawak sa mga pagsingit.
Mga non-functional metric: nagbibigay ang time-to-first-audio at sentiment analysis ng transcript ng mga kantitatibong pamalit na panukat sa kalidad ng pag-uusap.
Manual na kwalitatibong pagsusuri: mahalaga pa rin upang matukoy ang mga problemang hindi nakikita ng mga awtomatikong metric, lalo na sa tono at pagiging natural.
Walang iisang paraang sumasaklaw sa lahat. Kailangang pagsama-samahin ang tatlo kapag nagde-deploy ng mga realtime agent sa production. Gayunman, hindi pa rin kasing-husay ng tooling para sa text-based AI ang tooling para sa realtime audio evaluation.
Binabago ng realtime voice ang anyo ng produkto. Kasinghalaga ng mga salita sa karanasan ng mga user ang timing, pagsingit, katahimikan, at pagbawi.
Ibig sabihin, bahagi lamang ng system ang modelo. Kailangan ng production realtime voice ng voice-native na session layer, malinaw na paghihiwalay ng pagsasalita at pangangatwiran, at event-driven na kontrol sa live session. Mga guardrail pa rin ang bottleneck sa latency, ngunit mapapanatili ng mga malikhaing paraan ang malaking bahagi ng realtime na karanasan.
Pagsusuri pa rin ang pinakamahinang bahagi ng stack. Wala pang kinikilalang paraan upang subukan ang mga katangiang nagpapaganda sa realtime voice: timing, tono, paghawak sa mga pagsingit, at daloy ng usapan. Hangga't wala pa nito, kailangang pagsamahin ng mga team na gumagawa gamit ang teknolohiyang ito ang mga awtomatikong pagsubok, agent-to-agent run, at manual na pagsusuri.