Tencent இந்த வாரம் WeMM-Embedding மாதிரியை அறிமுகப்படுத்தியுள்ளது, இது 2 பில்லியன் அளவுருக்களைக் (parameters) கொண்ட ஒரு மல்டிமாடல் (multimodal) அமைப்பாகும். இது ஏற்கனவே WeChat-ன் தேடல், பரிந்துரை மற்றும் மின்-வணிக (e-commerce) வழிமுறைகளில் இணைக்கப்பட்டுள்ளது. இந்த வெளியீடு முக்கியமானது, ஏனெனில் இது நிஜ உலகத் தேடல் தரத்தை (retrieval quality), குறைந்த தாமதத்தையும் (low latency) மற்றும் சிறிய குறியீட்டு அளவுகளையும் (small index sizes) வழங்கும் ஒரு மாதிரியை வெளிப்படுத்துகிறது.
ஒரு "செயல்படுத்தும் கதை" (deployment story) ஏன் இவ்வளவு முக்கியத்துவம் பெறுகிறது
பெரும்பாலான புதிய AI மாதிரிகள், தேர்ந்தெடுக்கப்பட்ட தரவுத்தொகுப்புகளில் (curated datasets) மதிப்பெண்களை ஒப்பிடும் பளபளப்பான பெஞ்ச்மார்க் (benchmark) அட்டவணைகளுடன் வருகின்றன. அந்த எண்கள் ஆராய்ச்சியாளர்கள் ஒரு கருத்தை நிரூபிக்க உதவுகின்றன, ஆனால் அவை தயாரிப்புகளை இயக்கும் அளவீடுகளாக (metrics) அரிதாகவே மாறுகின்றன: ஒரு வினவல் (query) எவ்வளவு வேகமாகத் திரும்புகிறது, ஒரு குறியீடு (index) எவ்வளவு நினைவகத்தை (memory) பயன்படுத்துகிறது மற்றும் பயனர்கள் உருவாக்கும் சத்தமான/குழப்பமான உள்ளடக்கங்களை (noisy, user-generated content) மாதிரி எவ்வளவு சிறப்பாகக் கையாள்கிறது என்பது போன்றவை. WeMM முதல் நாளிலிருந்தே ஒரு உற்பத்தித் தரத்திலான (production-grade) அங்கமாக இருப்பதன் மூலம் இந்த வழக்கத்தை மாற்றுகிறது. இது ஒரு கீழ்நிலை குழு அதை ஏற்றுக்கொள்வதற்காகக் காத்திருக்கும் ஆய்வகச் சோதனை அல்ல; இது ஏற்கனவே Channels, Moments மற்றும் மின்-வணிகத்தில் இயங்குகிறது.
டெவலப்பர்கள் கவனிக்க வேண்டிய தொழில்நுட்ப அம்சங்கள்
உண்மையான மல்டிமாடல் கையாளுதல் (True multimodal handling) – இந்த மாதிரி உரை (text), படங்கள், வீடியோ பிரேம்கள் மற்றும் ஆவணத் தம்ப்நெயில்களை (document thumbnails) ஒரே உட்பொதிவு இடத்திற்குள் (embedding space) உள்ளிடுகிறது. ஒரு பயனர் “sunset” என்று தட்டச்சு செய்து, தனித்தனி உரை மற்றும் பார்வை சார்ந்த வழிமுறைகளை இணைக்காமலேயே, அதற்குப் பொருத்தமான வீடியோ கிளிப், ஒரு புகைப்படம் அல்லது ஒரு செய்தித் தொகுப்பைப் பெற முடியும்.
அளவு முக்கியமானது, ஆனால் நீங்கள் நினைப்பது போல அல்ல – 2 பில்லியன் அளவுருக்களுடன், லீடர்போர்டுகளில் ஆதிக்கம் செலுத்தும் 9 பில்லியனுக்கும் அதிகமான மாதிரிகளுடன் ஒப்பிடும்போது இந்த மாதிரி “சிறியது”. இருப்பினும், இது ஊடாடும் சேவைகளுக்குத் (interactive services) தேவையான தாமத வரம்புகளை (latency budgets) பூர்த்தி செய்கிறது. உங்கள் வன்பொருளுக்கு (hardware) பொருந்தக்கூடிய ஒரு மாதிரி, நேரடி அமைப்பில் (live system) பெரிய மற்றும் மெதுவான மாதிரியை விடச் சிறப்பாகச் செயல்பட முடியும்.
Matryoshka உட்பொதிவுகள் பரிமாண நெகிழ்வுத்தன்மையைத் தருகின்றன – WeMM “Matryoshka” உட்பொதிவுகளை ஆதரிக்கிறது, அதாவது ஒரே நெட்வொர்க் 256 அல்லது 512 பரிமாணங்கள் போன்ற வெவ்வேறு நீளங்களைக் கொண்ட வெக்டர்களை (vectors) வெளியீடாக வழங்க முடியும். 512-லிருந்து 256 பரிமாணங்களுக்குக் குறைப்பது, நினைவகப் பயன்பாட்டை பாதியாகக் குறைக்கும் அதே வேளையில், தேடல் செயல்திறனை (retrieval performance) கிட்டத்தட்ட முழுமையாகத் தக்கவைத்துக் கொள்கிறது என்று சோதனைகள் காட்டுகின்றன. இது சேமிப்புச் செலவைக் குறைப்பதோடு, அருகிலுள்ள அண்டை தேடல்களையும் (nearest-neighbor searches) வேகப்படுத்துகிறது.
தேடல் அமைப்புகளை (retrieval systems) உருவாக்குவதற்கான மூன்று நடைமுறை விதிகள்
உங்கள் சொந்தத் தரவில் சரிபார்க்கவும் – பெஞ்ச்மார்க்குகள் சுத்தமானவை; ஆனால் உற்பத்தித் தரவு (production data) குழப்பமானது. உங்கள் பயனர்கள் ஸ்கிரீன்ஷாட்டுகள், கையால் எழுதப்பட்ட குறிப்புகள் அல்லது குறைந்த தெளிவுத்திறன் கொண்ட வீடியோக்களைப் பதிவேற்றினால், அது உங்களுக்குப் பொருந்துமா என்பதைத் தீர்மானிப்பதற்கு முன், அந்தத் தரவு கலவையின் மூலம் மாதிரியை இயக்கிப் பார்க்கவும்.
வெக்டர் நீளத்தை ஒரு செலவுக் காரணியாகக் கருதவும் – பெரிய வெக்டர்கள் ஒற்றுமைத் தேடலுக்கு (similarity search)த் தேவையான கணக்கீடுகளையும் (compute), குறியீட்டிற்கான வட்டு இடத்தையும் (disk space) அதிகரிக்கின்றன. உங்கள் தரக் இலக்கை எட்டும் மிகச்சிறிய பரிமாணத்துடன் தொடங்கவும். recall அல்லது precision ஆகியவற்றில் தெளிவான சரிவு ஏற்படும் போது மட்டுமே அளவை அதிகரிக்கவும்.
தனித்தனி வழிமுறைகளைத் (siloed pipelines) தவிர்க்கவும் – ஒவ்வொரு வகைகளுக்கும் (modality) தனித்தனி என்கோடர்களை (encoders) உருவாக்குவது, இறுதி தரவரிசை நிலைக்கு (ranking stage) நீங்கள் கைமுறையாக எடை போடும் முறைகளை (weighting schemes) உருவாக்க வேண்டிய கட்டாயத்தை ஏற்படுத்துகிறது. ஒரு உலகளாவிய உட்பொதிவு அடுக்கு (universal embedding layer) அந்த இணைப்புக் குறியீட்டை (glue code) நீக்குகிறது, பொறியியல் சுமையைக் குறைக்கிறது மற்றும் A/B சோதனையை எளிதாக்குகிறது.
பரந்த தாக்கங்கள்
தேடல் அல்லது பரிந்துரைகளைச் சார்ந்திருக்கும் நிறுவனங்களுக்கு, உட்பொதிவு மாதிரியின் (embedding model) தேர்வு உள்கட்டமைப்புச் செலவைத் தீர்மானிக்கலாம். பயனர்களின் எதிர்பார்ப்புகள் அதிகரிக்கும் போது தாமத வரம்புகள் (latency budgets) குறைகின்றன; ஒரு வினாவிற்கு சில மில்லி விநாடிகள் கூட கூடுதல் நேரத்தைச் சேர்த்தால், அது சேவையின் செயல்திறனைப் பாதித்து, பயனர்கள் வெளியேற வழிவகுக்கும்.
Apache 2.0 உரிமத்தின் கீழ் எடைகளை (weights) ஓப்பன் சோர்ஸாக வெளியிடும் டென்சென்ட்டின் (Tencent) முடிவு டெவலப்பர்களுக்கான செலவுச் சுமையையும் மாற்றுகிறது. உரிமம் பெற்ற ஒப்பந்தங்களை (proprietary contracts) பேச்சுவார்த்தை நடத்துவதற்குப் பதிலாக அல்லது ஒரு மாதிரியைத் தொடக்கத்திலிருந்து உருவாக்குவதற்குப் பதிலாக, குழுக்கள் செக்பாயிண்ட்டை (checkpoint) பதிவிறக்கம் செய்து, குறிப்பிட்ட துறை சார்ந்த தரவுகளில் அதைச் செம்மைப்படுத்தவும் (fine-tune), சில தோல்வி நிகழ்வுகளுடன் அதை மதிப்பீடு செய்யவும் முடியும்.
மாதிரி எங்கு பின்தங்கலாம்
இந்த மாதிரி உரை, படங்கள், வீடியோ மற்றும் ஆவணங்கள் ஆகிய நான்கு வகைகளைக் கையாள்கிறது, ஆனால் அனைத்து வகையான உள்ளீடுகளையும் இது கவரவில்லை.
அடுத்து கவனிக்க வேண்டியவை
முடிவுரை
உற்பத்தித் தடைகளை (production constraints) மனதில் கொண்டு உருவாக்கப்பட்டால், ஒரு மிதமான அளவுள்ள, மல்டிமாடல் உட்பொதிவு மாதிரி தினசரி வினவல்களைக் கையாள முடியும் என்பதை WeMM நிரூபிக்கிறது. டெவலப்பர்களுக்கு செய்தி தெளிவானது: நிஜ உலகத் தேடல் தரத்திற்கு முன்னுரிமை அளிக்கவும், வெக்டர் பரிமாணங்களைச் சாத்தியமான அளவு சிறியதாக வைத்திருக்கவும் மற்றும் அனைத்து வகைகளையும் ஒரே உட்பொதிவு அடுக்கில் ஒருங்கிணைக்கவும். இந்தத் தெரிவுகள் தாமதத்தைக் குறைக்கவும், சேமிப்புச் செலவைக் குறைக்கவும் மற்றும் இறுதியில் இறுதிப் பயனர்களுக்குச் சிறந்த அனுபவத்தை வழங்கவும் உதவும்.