Imagine joining a video call with a supplier in Seoul or a customer in São Paulo and speaking exactly as you would to a

કલ્પના કરો કે તમે સિઓલમાં કોઈ સપ્લાયર અથવા સાઓ પાઉલોમાં કોઈ ગ્રાહક સાથે વિડિયો કોલ જોઈન કરી રહ્યા છો અને બરાબર એ જ રીતે વાત કરી રહ્યા છો જે રીતે તમે તમારી બાજુના રૂમમાં બેઠેલા સહકર્મી સાથે વાત કરો છો. કોઈ મ્યૂટ પર રાહ જોતો અનુવાદક નથી. ચેટ બોક્સમાં ટાઈપ કરવા માટે કીબોર્ડ પર ઝૂકેલા લોકો નથી. રિયલ-ટાઇમ AI વોઇસ ટ્રાન્સલેશન અત્યારે આ શક્ય બનાવી રહ્યું છે. માનવીય જોડાણને બદલે, તે લોકો વચ્ચેના અવરોધોને દૂર કરે છે. પરંતુ ખરેખર કુદરતી વાતચીત જેવું લાગે તેવી સિસ્ટમ બનાવવી ખરેખર અઘરી છે. તમે ફક્ત શબ્દોનું રૂપાંતર નથી કરી રહ્યા. તમે સોફ્ટવેરની અંદર માનવીય સંવાદના પ્રવાહનું પુનઃનિર્માણ કરી રહ્યા છો.

પાઇપલાઇનના પાંચ સ્તરો

એક કાર્યરત સિસ્ટમ પાંચ અલગ-અલગ ભાગોમાં વહેંચાયેલી હોય છે. જો તમે એકને પણ છોડી દો અથવા નબળું પાડો, તો આખું ભ્રમણ (illusion) તૂટી જાય છે.

Voice Communication Layer એ પાયો છે. તે માઇક્રોફોન કેપ્ચર, નોઈઝ સપ્રેશન, ઇકો કેન્સલેશન અને ઇન્ટરનેટ પર પેકેટ ટ્રાન્સમિશન સંભાળે છે. તેને ડિજિટલ ફોન લાઇન તરીકે વિચારો. જો આ સ્તર પેકેટ્સ ગુમાવે અથવા જિટર (jitter) લાવે, તો બાકીની પાઇપલાઇન નકામા ડેટા સાથે કામ કરશે. મોટાભાગની ટીમો અહીં WebRTC નો ઉપયોગ કરે છે કારણ કે તે પીઅર-ટુ-પીઅર કનેક્શન સંભાળે છે અને તેમાં ઇન-બિલ્ટ એક્યુસ્ટિક સેફગાર્ડ્સ સામેલ છે.

હવે આવે છે Speech-to-Text (STT). તમારે આવતા અવાજને શક્ય તેટલી ઝડપથી લખેલા શબ્દોમાં રૂપાંતરિત કરવાની જરૂર છે. સ્ટ્રીમિંગ STT એન્જિન શાંતિની રાહ જોતા નથી. તેઓ સિલેબલ્સ (syllables) આવતાની સાથે જ આંશિક ટ્રાન્સક્રિપ્ટ્સ બહાર પાડે છે. આ વર્તણૂક આવશ્યક છે. જો તમારું STT મોડ્યુલ વિરામ સાંભળવા સુધી બફર કરે, તો તમે પહેલેથી જ કિંમતી મિલિસેકન્ડ્સ ગુમાવી દીધી છે. આધુનિક સ્ટ્રીમિંગ અમલીકરણો આવતા ઓડિયોને સતત પ્રોસેસ કરે છે અને વધુ સંદર્ભ (context) મળતા તેમની ધારણાઓમાં સુધારો કરે છે.

Machine Translation (MT) વચ્ચેના ભાગમાં આવે છે. તે કાચા ટેક્સ્ટને લે છે અને તેને લક્ષ્ય ભાષામાં ફરીથી લખે છે. શરૂઆતની સિસ્ટમો વાક્યના શબ્દો બદલવા સિવાય બહુ ઓછું કરતી હતી. વર્તમાન ટ્રાન્સફોર્મર-આધારિત મોડલ્સ સિન્ટેક્સ અને લાંબા અંતરના નિર્ભરતાઓને (long-range dependencies) વધુ સારી રીતે સંભાળે છે, પરંતુ તેમને હજુ પણ સાવચેતીપૂર્વક એકીકરણની જરૂર છે. તમારે એવું MT મોડ્યુલ જોઈએ છે જે સ્ટ્રીમિંગ ઇનપુટ સ્વીકારે જેથી વક્તા વિચાર પૂરો કરે તે પહેલાં તે વાક્યના ટુકડાઓનું ભાષાંતર કરવાનું શરૂ કરી શકે.

ત્યારબાદ Text-to-Speech (TTS) આવે છે. અહીં તમારી સિસ્ટમ પોતાનો અવાજ શોધે છે. જૂના કન્કેટેનેટિવ TTS સાંભળવામાં હાઇવે એક્ઝિટ જાહેર કરતા GPS જેવા લાગતા હતા. ન્યુરલ TTS મોડલ્સ ડાયરેક્ટ સ્પેક્ટ્રોગ્રામ્સ અથવા રૉ વેવફોર્મ્સની આગાહી કરીને રમત બદલી નાખી છે. તેઓ એવા અવાજો ઉત્પન્ન કરે છે જે ઉતાર-ચઢાવ અને શ્વાસ લેતા હોય તેવા લાગે છે. તેઓ કેટલીક ભાવનાત્મક રંગત પણ જાળવી શકે છે, જે મહત્વપૂર્ણ છે કારણ કે રોબોટિક મોનોટોનમાં આપવામાં આવેલી સપાટ માફી અજાણતામાં કટાક્ષ જેવી લાગી શકે છે.

અંતે, Audio Streaming લેયર અનુવાદિત સ્પીચને સાંભળનાર સુધી પહોંચાડે છે. અહીં ટાઇમિંગ પણ મહત્વનું છે. સિન્થેસાઇઝ્ડ ઓડિયો નેટવર્ક ટાઇમિંગ સાથે સુસંગત હોવો જોઈએ જેથી તે વહેલો આવીને ઇકો પેદા ન કરે, અથવા મોડો આવીને સાંભળનારને મૌનમાં મૂકી ન દે.

લેટન્સી (Latency) ની સમસ્યા

લેટન્સી તમારો સૌથી મોટો દુશ્મન છે. માનવીય સંવાદ માત્ર ટૂંકા અંતરાલ જ સહન કરી શકે છે. જો સિસ્ટમ અનુવાદ શરૂ કરતા પહેલા વપરાશકર્તાને આખું વાક્ય પૂરું કરવાની રાહ જુએ, તો વાતચીત ધીમી અને તૂટેલી લાગે છે. લોકો એકબીજાના બોલતી વખતે વચ્ચે બોલવા લાગે છે, અથવા તેનાથી પણ ખરાબ, તેઓ વોકી-ટોકી સ્પીચના અટકી-અટકીને બોલવાના લયમાં આવી જાય છે. તમારો લક્ષ્ય એન્ડ-ટુ-એન્ડ એક સેકન્ડથી ઓછી લેટન્સી રાખવાનો હોવો જોઈએ.

આ લક્ષ્ય સુધી પહોંચવા માટે, તમારે ઓડિયોને નાના ટુકડાઓમાં (chunks) પ્રોસેસ કરવો જોઈએ. ચંક સાઈઝ 20 મિલિસેકન્ડ અને 100 મિલિસેકન્ડની વચ્ચે રાખો. વીસ મિલિસેકન્ડમાં અંદાજે એક સિંગલ કોન્સોનન્ટ અવાજની અવધિ પકડાય છે. સો મિલિસેકન્ડમાં લગભગ દોઢ સિલેબલ પકડાય છે. આ ચંક્સને સ્ટ્રીમિંગ પાઇપલાઇનમાં ફીડ કરો જેથી STT, ટ્રાન્સલેશન અને TTS ત્રણેય આંશિક માહિતી પર કામ કરી શકે. કંઈપણ વાક્યના અંતની રાહ જોવું જોઈએ નહીં.

દરેક તબક્કે સ્ટ્રીમિંગ ઓડિયો પ્રોસેસિંગનો ઉપયોગ કરો. તેનો અર્થ એ છે કે STT એન્જિન સતત આંશિક ટ્રાન્સક્રિપ્ટ્સ બહાર પાડે છે, MT એન્જિન એક સુસંગત ક્લોઝ (clause) બનાવવા માટે પૂરતા શબ્દો મળતાની સાથે જ ટુકડાઓનું ભાષાંતર કરે છે, અને TTS એન્જિન વાક્યનો બીજો ભાગ હજુ ડિકોડ થઈ રહ્યો હોય ત્યારે જ વાક્યનો પહેલો ભાગ બોલવાનું શરૂ કરે છે.

સબ-સેકન્ડ લેટન્સી હાંસલ કરવા માટે દરેક તબક્કે શિસ્તની જરૂર છે: કેપ્ચર, એન્કોડ, ટ્રાન્સમિટ, ક્યૂ, પ્રોસેસ, સિન્થેસાઇઝ અને પ્લેબેક. દરેક પગલે બિનજરૂરી બફરિંગ દૂર કરો. ઉદાહરણ તરીકે, જ્યાં સુધી અત્યંત જરૂરી ન હોય ત્યાં સુધી અડધી સેકન્ડના લુકઅહેડની જરૂર હોય તેવા નોઈઝ-રિમૂવલ અલ્ગોરિધમ્સ ચલાવવાનું ટાળો. રૉ PCM ને બદલે Opus જેવા કાર્યક્ષમ કમ્પ્રેશન પ્રોટોકોલ્સનો ઉપયોગ કરો. નેટવર્ક રાઉન્ડ ટ્રિપ્સ ટૂંકા રહે તે માટે બંને કોલર્સની ભૌગોલિક રીતે નજીક આવેલા એજ સર્વર્સ પર ઇન્ફરન્સ ચલાવો.

જ્યાં AI મોડલ્સ હજુ પણ સંઘર્ષ કરે છે

AI એવા ચોક્કસ અવરોધો લાવે છે જેનો ક્લિપબોર્ડ ટ્રાન્સલેટર્સને ક્યારેય સામનો કરવો પડ્યો નથી.

સંદર્ભ (Context) ખરેખર મુશ્કેલ હોય છે. અંગ્રેજીમાં, 'duck' શબ્દ એક પ્રાણી હોઈ શકે છે, માથું નીચું રાખવાનો ક્રિયાપદ હોઈ શકે છે, અથવા અમુક બોલીઓમાં પ્રેમથી બોલાવવામાં આવતો શબ્દ પણ હોઈ શકે છે. જે એન્જિન આ શબ્દને અલગથી જુએ છે તે ખોટો અંદાજ લગાવી શકે છે. સ્ટ્રીમિંગ એમ્પ્લીફિકેશન આને વધુ મુશ્કેલ બનાવે છે કારણ કે સિસ્ટમે આખું વાક્ય તેનો અર્થ સ્પષ્ટ કરે તે પહેલાં જ શબ્દ નક્કી કરવો પડે છે. કેટલાક ટીમો આ સમસ્યાને ઉકેલવા માટે STT એન્જિનમાં નાની 'રોલબેક વિન્ડોઝ' બનાવે છે, જે તેને ટ્રાન્સક્રિપ્ટ સુધારવાની મંજૂરી આપે છે જો પછીનો ઓડિયો તેના અર્થમાં ફેરફાર કરે.

અવાજની કુદરતીતા એન્જિનિયરો જે અપેક્ષા રાખે છે તેના કરતા વધુ મહત્વની છે. લોકોને રોબોટિક અવાજો ગમતા નથી. ન્યુરલ TTS મોડલ્સ માનવ સ્પીચમાંથી લયના નમૂનાઓ (prosody patterns) ક્લોન કરીને અવાજમાં લાગણીઓ જાળવી રાખે છે. જો મૂળ વક્તા ઉત્સાહિત અથવા ચિંતિત લાગે છે, તો અનુવાદિત આઉટપુટમાં પણ તે ઉર્જા હોવી જોઈએ, નહીં કે દરેક લાઇન હવામાન અહેવાલની જેમ બોલવી જોઈએ. સોર્સ ઓડિયોમાંથી વિરામચિહ્નોના સંકેતો અથવા સ્વરના ઉતાર-ચઢાવના સંકેતો (intonation markers) TTS મોડ્યુલમાં પસાર કરવાથી તે માનવીય સ્પર્શ જાળવી રાખવામાં મદદ મળે છે.

વાતચીત અસ્તવ્યસ્ત હોય છે. લોકો એકબીજાને વચ્ચેથી રોકે છે, પાછા ફરે છે, "uh" જેવા શબ્દો બોલે છે, અને એવા વાક્યો શરૂ કરે છે જે તેઓ ક્યારેય પૂરા કરતા નથી. આ વિરામોને બુદ્ધિપૂર્વક હેન્ડલ કરવા માટે તમારી સિસ્ટમને Voice Activity Detection (VAD) ની જરૂર છે. સારું VAD વાસ્તવિક સ્પીચ અને બેકગ્રાઉન્ડ નોઈસ વચ્ચે તફાવત કરી શકે છે, પરંતુ તે વાક્યની અંદરના ટૂંકા વિરામ અને વાક્યના સાચા અંત વચ્ચે પણ તફાવત કરી શકે છે. જો VAD ખૂબ જ વધુ સક્રિય (trigger-happy) હોય, તો તે જવાબોની શરૂઆત કાપી નાખે છે. જો તે ખૂબ જ સાવધ હોય, તો તે ટ્રાન્સલેશન એન્જિનમાં મૌન મોકલે છે, જેનાથી કમ્પ્યુટિંગ ક્ષમતાનો બગાડ થાય છે અને પ્રવાહમાં વિચિત્ર ગેપ્સ ઊભા થાય છે.

સ્કેલ અને સુરક્ષા

પ્રથમ આર્કિટેક્ચરલ સ્કેચથી જ સ્કેલ માટે તૈયાર કરો. એક મોનોલિથ (monolith) જે એક કોલને સરળતાથી અનુવાદિત કરે છે તે હજારો એકસાથે ચાલતી વાતચીતોના ભાર હેઠળ તૂટી શકે છે. માઇક્રોસર્વિસિસનો ઉપયોગ કરો જેથી તમે દરેક તબક્કાને સ્વતંત્ર રીતે સ્કેલ કરી શકો. જો તમારી TTS ક્યુ (queue) માં વિલંબ થાય કારણ કે એક ભાષા બીજી ભાષા કરતા વધુ ફોનેટિક જટિલતા ધરાવે છે, તો તમે STT ક્લસ્ટરને અડક્યા વગર વધુ TTS વર્કર્સ શરૂ કરી શકો છો. જો તમારી MT સર્વિસ કોઈ ચોક્કસ ભાષાની જોડીમાં અટકી જાય, તો તમે તે ઘટકને અલગ કરીને તેને સ્કેલ કરી શકો છો.

સુરક્ષા અનિવાર્ય છે. અવાજનો ડેટા બાયોમેટ્રિક અને અત્યંત વ્યક્તિગત છે. ટ્રાન્ઝિટ દરમિયાન કાચા ઓડિયોને સુરક્ષિત રાખવા માટે એન્ડ-ટુ-એન્ડ એન્ક્રિપ્શનનો ઉપયોગ કરો. જ્યાં સુધી તમારી પાસે કોઈ ચોક્કસ, જાહેર કરેલ કારણ ન હોય, જેમ કે મોડલ સુધારણા માટે વપરાશકર્તાની સ્પષ્ટ સંમતિ, ત્યાં સુધી કાચો અવાજ ડેટા સંગ્રહિત કરશો નહીં. તેમ છતાં પણ, રેકોર્ડિંગ્સને એન્ક્રિપ્ટ કરીને સ્ટોર કરો અને તેને કડક શેડ્યૂલ મુજબ સાફ (purge) કરો. અવાજ અનુવાદ સિસ્ટમ જો કોલની સામગ્રી લીક કરે અથવા ગુપ્ત રીતે વાતચીત સાચવી રાખે તો તે વપરાશકર્તાનો વિશ્વાસ કાયમ માટે તોડી નાખે છે.

બનાવવાનું શરૂ કરો

ડેવલપર્સ પાસે હવે ઓપન-સોર્સ STT મોડલ્સ, ક્લાઉડ-આધારિત MT APIs અને પ્રી-ટ્રેઈન્ડ ન્યુરલ TTS ચેકપોઈન્ટ્સ ઉપલબ્ધ છે જે થોડા વર્ષો પહેલા શોધવા અશક્ય હતા. જરૂરી તમામ ભાગો અહીં છે. આર્કિટેક્ચર પણ સમજી શકાય તેવું છે.

નાની શરૂઆત કરો. માઇક્રોફોન ઓડિયોના બે સેકન્ડ સ્ટ્રીમિંગ STT એન્જિન દ્વારા પસાર કરો.