உள்ளூர் AI இசை உருவாக்கம் படைப்பாற்றலில் உள்ள கட்டுப்பாடுகளை நீக்கிவிடுகிறது. ACE-Step 1.5 போன்ற கருவிகள் முழுமையாக ஒரு Mac-இல் இயங்கக்கூடியவை, இவை மேகக்கணிமை (cloud) கிரெடிட்கள் அல்லது பதிவேற்ற வரிசைகள் (upload queues) ஏதுமின்றி, சில நிமிடங்களில் உரைத் தூண்டுதல்களை (text prompts) முழுமையான பாடல்களாக மாற்றுகின்றன. அந்த சுதந்திரம் ஒரு புதிய சிக்கலை உருவாக்குகிறது: அளவு (volume). உருவாக்கம் மலிவாகவும் உடனடியாகவும் இருக்கும்போது, ஒரு பாடலை உருவாக்க முடியுமா என்று கேட்பதை நிறுத்திவிட்டு, உங்கள் டிரைவில் உள்ள ஐம்பது பதிப்புகளில் எது சேமிக்கத் தகுதியானது என்று யோசிக்கத் தொடங்குவீர்கள்.
இதை நான் கடினமான முறையில் கற்றுக்கொண்டேன். ஒரு சராசரி நாளில், ஒரு நல்ல பதிப்பைக் கண்டறிய ACE-Step 1.5 மூலம் நான்கு முயற்சிகள் (takes) தேவைப்படுகின்றன. ஆனால் சராசரிகள் பொய் சொல்லும். சமீபத்திய ஒரு அமர்வில், ஒரே ஒரு இசை அமைப்பிற்காக (arrangement) முப்பத்திரண்டு பதிப்புகளை உருவாக்கினேன். முப்பத்திரண்டு இரண்டு நிமிடப் பாடல்களைக் கேட்பது ஒரு மணி நேரத்திற்கும் மேலான தீவிரமான கவனிப்பு (critical listening). ஏழாவது பாடக்க到了, தெளிவற்ற உயிரெழுத்துக்களை என் காதுகள் சகித்துக் கொள்ளத் தொடங்கின. பதினைந்தாவது பாடக்க到了, வார்த்தைகள் விடுபட்டிருந்தாலும் இசையின் மெல்லிசைக்குத் தலை அசைத்துக் கொண்டிருந்தேன். கேட்பவர் சோர்வு (Listener fatigue) என்பது சோம்பேறித்தனம் அல்ல; அது புலன் உணர்தல் துல்லியத்தில் (perceptual accuracy) ஏற்படும் உண்மையான சரிவு. என் காதுகள் செயல்படுவதற்கு முன்னரே செயல்படக்கூடிய ஒரு வடிகட்டி (filter) எனக்குத் தேவைப்பட்டது.
எனவே, OpenAI-ன் பேச்சு அங்கீகார மாதிரியின் (speech-recognition model) Apple Silicon-க்கு உகந்த பதிப்பான mlx-whisper-ஐ அடிப்படையாகக் கொண்டு ஒரு உள்ளூர் QA pipeline-ஐ உருவாக்கினேன். யோசனை எளிமையானது: ஒவ்வொரு பதிப்பையும் தானாகவே எழுத்து வடிவில் மாற்றி (transcribe), அதை அசல் வரிகளுடன் ஒப்பிட்டுப் பார்த்தால், ஒரு புறநிலையான பாடல்-பொருத்தம் விகிதத்தை (objective lyric-match rate) என்னால் பெற முடியும். அந்த எண் முப்பத்திரண்டு பதிப்புகளையும் கையாளக்கூடிய ஒரு சிறிய எண்ணிக்கையாகக் குறைக்க உதவும்.
இந்த Pipeline எவ்வாறு செயல்படுகிறது
இந்த பணிப்பாய்வு (workflow) நான்கு நிலைகளைக் கொண்டது, மேலும் நான் ஒவ்வொன்றையும் தவிர்க்க முடியாததாகக் கருதுகிறேன்.
உருவாக்குதல் (Generate). நான் ACE-Step 1.5 மூலம் மூல ஆடியோவை (raw audio) உருவாக்குகிறேன். இந்த நிலையில் நான் எதையும் மதிப்பிடுவதில்லை. இலக்கு என்பது அதிக அளவு (volume) உருவாக்குவதே.
எழுத்து வடிவில் மாற்றுதல் (Transcribe). ஒவ்வொரு WAV கோப்பும் எனது Mac-இல் உள்ள mlx-whisper-க்கு அனுப்பப்படுகிறது. MLX என்பது Apple-ன் Metal மற்றும் neural engine-க்காக உருவாக்கப்பட்டுள்ளதால், இது முழுமையாக உள்ளூரிலேயே இயங்குகிறது. இதில் API செலவுகள் இல்லை, நெட்வொர்க் தாமதம் (latency) இல்லை, மேலும் மூல ஆடியோவை ஒரு தொலைதூரச் சேவையகத்திற்கு (remote server) அனுப்புவதில் தனியுரிமைச் சிக்கல்களும் இல்லை. நான் காபி தயாரிக்கும் நேரத்தில் முப்பத்திரண்டு கோப்புகள் கொண்ட தொகுப்பு எழுத்து வடிவில் மாற்றப்பட்டுவிடும்.
மதிப்பீடு செய்தல் (Score). Whisper-ன் எழுத்து வடிவத்தை அசல் பாடல் வரிகளுடன் ஒப்பிடுகிறேன். இந்த பொருத்தம் விகிதம் (match rate) நம்பகத்தன்மையை (fidelity) அளவிடுகிறது: பாடகர் ஒவ்வொரு வார்த்தையையும் சரியாகப் பாடினாரா அல்லது வரிகளைத் தவிர்த்தாரா, சொற்றொடர்களைத் தழுதழுக்கச் செய்தாரா அல்லது எழுத்துக்களைத் தவறாகக் கற்பனை செய்தாரா (hallucinate)? நான் ஒரு சதவீதப் பொருத்தத்தைக் கணக்கிடுகிறேன். இது ஒரு அழகியல் சார்ந்த மதிப்பீடு அல்ல; இது உரைத் துல்லியத்தின் (textual accuracy) ஒரு கடுமையான கணக்கீடு.
வடிகட்டுதல் (Filter). அந்தப் பொருத்தம் விகிதத்தின் அடிப்படையில் பதிப்புகளை நான் வரிசைப்படுத்துகிறேன். சிறந்த 20% (top quintile) பதிப்புகள் எனது தணிக்கை தொகுப்பாக (audition pool) மாறுகின்றன. மற்ற அனைத்தும் ஒரு இரண்டாம் நிலை கோப்புறைக்கு (secondary folder) மாற்றப்படுகின்றன. குறைந்த மதிப்பெண் பெற்றவற்றை நான் இன்னும் நீக்கவில்லை, ஆனால் அவற்றைக் கேட்பதில் எனது முக்கியமான நேரத்தை வீணடிக்க மாட்டேன்.
நடுவர் குழுவைத் தனித்து வைத்திருங்கள்
நான் ஒரு கடுமையான விதியைப் பின்பற்றுகிறேன்: உருவாக்கும் மாதிரி (generation model) தனது சொந்த வேலையைத் தானே மதிப்பிடுவதில்லை. ACE-Step 1.5 தனது சொந்த வெளியீட்டை (output) மதிப்பீடு செய்வதில்லை. நான் எழுத்து வடிவில் மாற்றுவதற்கு முற்றிலும் மாறுபட்ட ஒரு செயல்முறையைப் பயன்படுத்துகிறேன், ஏனெனில் தன்னைத் தானே சரிபார்க்கும் ஒரு மாதிரி எப்போதும் மிகவும் கனிவாகவே இருக்கும். அது அதே குறைகளையும் (blind spots) கொண்டிருக்கும். ஒருவேளை உருவாக்கும் கருவி பன்மை markers-களைத் தவிர்க்கவோ அல்லது கடினமான மெய்யெழுத்துக்களை மென்மையாக்கவோ செய்தால், சுய-மதிப்பீட்டுச் சுழற்சி (self-evaluation loop) அந்தத் தவறுகளைக் கண்டுகொள்ளாமல் இருக்கப் பழகிவிடும். ஒரு தனித்துவமான பேச்சு அங்கீகார மாதிரிக்கு இசையின் மீது எந்த விசுவாசமும் இல்லை. அது எதைக் கேட்கிறதோ அதை அப்படியே தெரிவிக்கும், அந்த அறிக்கை எவ்வளவு கடுமையானதாக இருந்தாலும் சரி.
எண்கள் எதைக் காட்டின
முப்பத்திரண்டு பதிப்புகள் கொண்ட தொகுப்பில், இந்த pipeline முக்கியமான கவனத்திற்குத் தகுதியான எட்டுப் பதிப்புகளை மட்டும் தேர்ந்தெடுத்தது. அந்த எட்டு பதிப்புகளின் சராசரி பாடல்-பொருத்தம் விகிதம் 83.9% ஆகும். நான் அவற்றைச் சரியாகக் கேட்டு, எனது சொந்தத் தரக் கட்டுப்பாட்டு விதிகளின்படி (quality rubric) மதிப்பிட்ட பிறகு, அவை 100-க்கு சராசரியாக 94.1 மதிப்பெண்களைப் பெற்றன. இந்த வேறுபாடு முழு கதையையும் சொல்கிறது. பாடல் வரிகள் விடுபடுதல், கால அளவு தவறுதல், குரல் குறைபாடுகள் போன்ற தெளிவான கட்டமைப்புத் தோல்விகளை இயந்திரக் கட்டுப்பாடு (machine gate) கண்டறிந்துவிட்டது, இதனால் எனது மனித மதிப்பீடு ஏற்கனவே சுத்திகரிக்கப்பட்ட ஒரு தொகுப்பின் மீது செயல்பட முடிந்தது. இந்தத் தானியங்கி முறை எனது முடிவெடுக்கும் திறனை மாற்றீடு செய்யவில்லை; மாறாக அதைச் சேமித்தது.
இயந்திரம் தவறான முடிவுகளைத் தரும்போது
குறைந்த மதிப்பெண் என்பது எப்போதும் ஒரு மோசமான பாடல் என்று அர்த்தமல்ல. எனக்குப் பிடித்த ஒரு பாடல் நிர்ணயிக்கப்பட்ட அளவை விடக் குறைவான மதிப்பெண் பெற்றபோது இதை நான் ஆரம்பத்திலேயே கண்டறிந்தேன். அந்தப் பாடலின் வரிகள் ஒரு எளிய அகரவரிசைப் பாடல் (alphabet chant): தனித்த ஒலிகளாகப் பாடப்பட்ட ஒற்றை எழுத்துக்கள். Whisper இயற்கையான வாக்கிய அமைப்பைக் கொண்டு பயிற்சியளிக்கப்பட்டது. அதற்கு "A B C D" என்று கொடுத்தால், அது பெரும்பாலும் வார்த்தைகளைக் கற்பனை செய்யும், சொற்களுக்கு இடையில் articles-களைச் சேர்க்கும் அல்லது எழுத்துக்களைக் குழப்பமான ஒலிகளாக (garbled phonemes) மாற்றும். அங்கு எழுத்து வடிவில் மாற்றுதல் தோல்வியடைந்தது, ஆனால் குரல் செயல்பாடு உண்மையில் மிகத் தெளிவாக இருந்தது.
அந்தச் சம்பவம் எனக்கு நடைமுறை வரம்பைக் கற்பித்தது. பொருத்தம் விகிதம் என்பது ஒரு முன்-வடிகட்டி (pre-filter) மட்டுமே, இறுதித் தீர்ப்பு அல்ல. குறைந்த மதிப்பெண் பெறும் எந்தப் பதிப்பையும் நான் நீக்குவதற்கு முன்பு, பத்து வினாடிகள் மனிதத் தணிக்கைக்கு (human audition) உட்படுத்துகிறேன். அந்த எண் உங்களுக்கு ஒரு சாத்தியக்கூறை (probability) மட்டுமே காட்டுகிறது, உறுதியை (certainty) அல்ல. நீங்கள் அந்த மதிப்பெண்ணை ஒரு திசைகாட்டியாகக் கருதாமல் ஒரு தீர்ப்பாகக் கருதினால், நல்ல இசையை நீங்கள் வீணடித்துவிடுவீர்கள்.
ஒரு தொழில்நுட்பத் தடை
நீங்கள் Apple Silicon-இல் MLX-ஐப் பயன்படுத்துகிறீர்கள் என்றால், பெரிய அளவிலான தொகுப்புகளை (batches) செயலாக்குவதற்கு முன் உங்கள் Python architecture-ஐச் சரிபார்க்கவும். Rosetta emulation மூலம் Python binary-ஐ இயக்குவது ஒரு பொதுவான அமைப்புக் பிழையாகும் (setup mistake). ஸ்கிரிப்ட் இயங்கும், ஆனால் உள்ளூர் டிரான்ஸ்கிரிப்ஷனை (local transcription) எளிதாக்கும் hardware acceleration-ஐ நீங்கள் இழப்பீர்கள்.
இதை உங்கள் terminal-இல் இயக்கவும்:
python3 -c "import platform; print(platform.machine())"
நீங்கள் arm64 என்பதைக் காண வேண்டும். அது x86_64 என்று காட்டினால், உங்கள் environment emulation முறையில் உள்ளது. ஒரு native Python build அல்லது native conda environment-க்கு மாறி, பின்னர் mlx-whisper-ஐ மீண்டும் நிறுவவும். நீண்ட தொகுப்புகளைச் செயலாக்கும்போது, emulated மற்றும் native execution ஆகியவற்றிற்கு இடையிலான வேறுபாடு, மதிய உணவிற்கு முன்பே முடிப்பதா அல்லது இரவு உணவிற்கு முன்பே முடிப்பதா என்பதைத் தீர்மானிக்கும்.
உண்மையான மதிப்பு
Generative audio விடாமுயற்சியைப் போற்றுகிறது, ஆனால் மனிதனின் கவனம் வரையறுக்கப்பட்டது. நீங்கள் மிகவும் நுணுக்கமானவர் என்பதை நிரூபிப்பதற்காக, முப்பத்திரண்டு சாதாரணமான பதிவுகளைக் கேட்பதில் எந்தப் பெருமையும் இல்லை. Generator-க்கும் எனது காதுகளுக்கும் இடையில் mlx-whisper-ஐப் பயன்படுத்துவதன் மூலம், நான் பல மணிநேரத் தீவிரமான படைப்பு நேரத்தைத் திரும்பப் பெற்றேன். எந்தப் பாடல் நிலைத்திருக்க வேண்டும், எது நீக்கப்பட வேண்டும் என்பதை நான் தான் இன்னும் தீர்மானிக்கிறேன். சிறந்த சாத்தியக்கூறுகளுக்கு எனதுத் தீர்ப்பை நான் பயன்படுத்துவதை இயந்திரம் உறுதி செய்கிறது, அவ்வளவுதான்.
இந்த pipeline குறித்த முழுமையான விவரம் இங்கே கிடைக்கிறது. நீங்கள் இதே போன்ற உள்ளூர் QA கருவிகளை உருவாக்குகிறீர்கள் என்றால், கருத்துக்களைப் பகிர்ந்து கொள்ள GyaanSetu community ஒரு சிறந்த இடமாகும்.
