𝗩𝗲𝗰𝘁𝗼𝗿 𝗦𝗲𝗮𝗿𝗰𝗵 𝗜𝘀 𝗡𝗼𝘁 𝗘𝗻𝗼𝘂𝗴𝗵 𝗳𝗼𝗿 𝗣𝗿𝗼𝗱𝘂𝗰𝘁𝗶𝗼𝗻 𝗔𝗜
സെമാന്റിക് റിട്രീവൽ (semantic retrieval) രീതിയിൽ വെക്റ്റർ സെർച്ച് വലിയ മാറ്റങ്ങൾ വരുത്തി. നിങ്ങൾ ഡാറ്റയെ എംബെഡ് ചെയ്യുകയും (embed), ഒരു ക്വറി എംബെഡ് ചെയ്യുകയും ചെയ്യുന്നു, തുടർന്ന് അടുത്തുള്ള ഡാറ്റാ പോയിന്റുകൾ (neighbors) കണ്ടെത്തുന്നു. ഇത് പഴയ കീവേഡ് മാച്ചിംഗ് രീതിക്ക് പകരമായി വന്നു.
എന്നാൽ പ്രൊഡക്ഷൻ AI-ക്ക് സമാനമായ എംബെഡിംഗുകൾ മാത്രം പോരാ. റിട്രീവൽ എന്നത് വെറുമൊരു 'നെൈബർ പ്രോബ്ലം' (neighbor problem) എന്നതിൽ നിന്നും റാങ്കിംഗും തീരുമാനങ്ങൾ എടുക്കലും (ranking and decision problem) ആവശ്യമായ ഒരു പ്രക്രിയയായി മാറിക്കൊണ്ടിരിക്കുകയാണ്.
ഒരു പ്രോട്ടോടൈപ്പിന് വെക്റ്ററുകൾ മതിയാകും. എന്നാൽ ഒരു പ്രൊഡക്ഷൻ സിസ്റ്റത്തിന് അതിൽ കൂടുതൽ ആവശ്യമാണ്.
ഒരു യഥാർത്ഥ യൂസർ ക്വറിക്ക് ഒരേസമയം ഇവ ആവശ്യമാണ്:
- സ്ട്രക്ചേർഡ് മെറ്റാഡാറ്റയും ഫിൽട്ടറുകളും (Structured metadata and filters)
- റിസൾട്ടുകൾ ഉയർത്താനോ താഴ്ത്താനോ ഉള്ള ബിസിനസ്സ് റൂളുകൾ (Business rules to boost or demote results)
- ഉപയോക്താവിന്റെ ഹിസ്റ്ററി അടിസ്ഥാനമാക്കിയുള്ള പേഴ്സണലൈസേഷൻ (Personalization based on user history)
- ഡാറ്റയുടെ പുതുമയും (data freshness) ആക്സസ് കൺട്രോളുകളും
- റാങ്കിംഗിനായുള്ള മെഷീൻ ലേണിംഗ് മോഡലുകൾ (Machine learning models for ranking)
മിക്ക ടീമുകളും വിവിധ ടൂളുകൾ കൂട്ടിച്ചേർത്ത് (stitching together) ആണ് ഇത് പരിഹരിക്കുന്നത്. നിങ്ങൾ ഒരു വെക്റ്റർ ഡാറ്റാബേസ്, ഒരു സെർച്ച് എഞ്ചിൻ, ഒരു റീറാങ്കർ (reranker), ഒരു ഫീച്ചർ സ്റ്റോർ എന്നിവ തമ്മിൽ ബന്ധിപ്പിക്കുന്നു.
ഇത് ചില പ്രശ്നങ്ങൾ സൃഷ്ടിക്കുന്നു:
- ഓരോ കണക്ഷനും ലേറ്റൻസി (latency) വർദ്ധിപ്പിക്കുന്നു
- ഓരോ ഭാഗത്തിനും പ്രത്യേകം ഓപ്പറേഷൻസ് ആവശ്യമാണ്
- ഡാറ്റ സിങ്ക് (sync) ആയി നിലനിർത്തുന്നത് പ്രയാസകരമാണ്
വെക്റ്ററുകൾ വൺ-ഡൈമൻഷണൽ അറേകളാണ് (one-dimensional arrays). ടെൻസറുകൾ (Tensors) മൾട്ടി-ഡൈമൻഷണൽ ഘടനകളാണ്.
ഡെൻസ് എംബെഡിംഗുകൾ (dense embeddings), സ്പാർസ് ഫീച്ചറുകൾ (sparse features), മെറ്റാഡാറ്റ എന്നിവയെ ഒരൊറ്റ പാസ്സിലൂടെ സംയോജിപ്പിക്കാൻ ടെൻസറുകൾ നിങ്ങളെ അനുവദിക്കുന്നു. ഇത് വിഘടിതമായ പൈപ്പ്ലൈനുകൾ (fragmented pipeline) ഒഴിവാക്കാൻ സഹായിക്കുന്നു.
ColBERT പോലുള്ള പുതിയ മോഡലുകൾ മൾട്ടി-വെക്റ്റർ സമീപനങ്ങളാണ് ഉപയോഗിക്കുന്നത്. അവ ഒരു ഡോക്യുമെന്റിനെ ഒരു പോയിന്റിലേക്ക് ചുരുക്കുന്നില്ല. പകരം അവ ടോക്കൺ തലത്തിലുള്ള (token-level) വിവരങ്ങൾ നിലനിർത്തുന്നു. ഇത് പ്രസക്തി (relevance) വർദ്ധിപ്പിക്കുമെങ്കിലും പഴയ വെക്റ്റർ ഡാറ്റാബേസുകൾക്ക് ഇത് താങ്ങാൻ കഴിയില്ല.
ടെൻസർ-നേറ്റീവ് ആർക്കിടെക്ചറുകൾ (Tensor-native architectures) ഇത്തരം ഘടനകൾക്ക് മുൻഗണന നൽകുന്നു. അവയെ വെറും വെക്റ്റർ രൂപങ്ങളിലേക്ക് മാറ്റാൻ നിർബന്ധിക്കുന്നില്ല.
നിങ്ങൾ RAG പൈപ്പ്ലൈനുകളോ റെക്കമെൻഡേഷൻ സിസ്റ്റങ്ങളോ നിർമ്മിക്കുകയാണെങ്കിൽ, ഈ വിഘടനം (fragmentation) നിങ്ങളുടെ വേഗത കുറയ്ക്കും. ബിസിനസ്സ് വളരുന്നതിനനുസരിച്ച് ഇത് കൂടുതൽ സങ്കീർണ്ണമാകും.
സ്വയം ഈ ചോദ്യങ്ങൾ ചോദിക്കുക:
- നിങ്ങളുടെ സ്റ്റാക്കിൽ (stack) എത്ര സിസ്റ്റങ്ങൾ കൂട്ടിച്ചേർത്തിരിക്കുന്നു?
- നിങ്ങളുടെ ആകെ ലേറ്റൻസി ബജറ്റ് (latency budget) എത്രയാണ്?
- നിങ്ങളുടെ ഇൻഫ്രാസ്ട്രക്ചറിന് മൾട്ടി-വെക്റ്റർ മോഡലുകളെ കൈകാര്യം ചെയ്യാൻ കഴിയുമോ?
നിങ്ങളുടെ ആർക്കിടെക്ചറൽ തീരുമാനങ്ങൾ എടുക്കാൻ സഹായിക്കുന്നതിനായി GigaOm ബ്രീഫിലെ പൂർണ്ണ വിവരങ്ങൾ വായിക്കുക.
Source: https://dev.to/thegatewayguy/vector-search-got-you-started-production-ai-needs-tensors-41dl
Optional learning community: https://t.me/GyaanSetuAi