മിക്ക ആളുകൾക്കും ഒരു LLM-ന് പ്രോംപ്റ്റ് നൽകാൻ കഴിയും. എന്നാൽ യഥാർത്ഥ ട്രാഫിക് കൈകാര്യം ചെയ്യാൻ കഴിയുന്ന രീതിയിൽ ഒരു ഉൽപ്പന്നത്തിലേക്ക് ഇതിനെ ഉൾപ്പെടുത്തുക എന്നത് തികച്ചും വ്യത്യസ്തമായ ഒരു കാര്യമാണ്. ഒരു ചാറ്റ് വിൻഡോയിൽ ടൈപ്പ് ചെയ്യുന്നതിൽ നിന്ന് പ്രൊഡക്ഷൻ AI നിർമ്മിക്കുന്നതിലേക്ക് മാറണമെങ്കിൽ, ഈ സ്റ്റാക്ക് എങ്ങനെയാണ് യഥാർത്ഥത്തിൽ പ്രവർത്തിക്കുന്നത് എന്ന് നിങ്ങൾ മനസ്സിലാക്കേണ്ടതുണ്ട്. ഇതൊരു മാന്ത്രികവിദ്യയല്ല. ഇത് വ്യത്യസ്ത എഞ്ചിനീയറിംഗ് പ്രശ്നങ്ങളുടെ ഒരു പൈപ്പ്ലൈൻ ആണ്, ഓരോ പാളിക്കും (layer) അതിന്റേതായ പരാജയ സാധ്യതകളുണ്ട്.
നിങ്ങൾ ഒരു വാക്ക് ടൈപ്പ് ചെയ്യുന്ന നിമിഷം മുതൽ ഒരു ഏജന്റ് ഒരു ജോലി പൂർത്തിയാക്കുന്നത് വരെയുള്ള ഒരു ആധുനിക AI സിസ്റ്റം എങ്ങനെ പ്രവർത്തിക്കുന്നു എന്ന് ഞാൻ വിശദീകരിക്കാം.
അടിസ്ഥാനം: മോഡലുകൾ എങ്ങനെ ചിന്തിക്കുന്നു
അതിന്റെ കാതലായ കാര്യമെന്തെന്നാൽ, ഒരു ലാർജ് ലാംഗ്വേജ് മോഡൽ കൃത്യമായി ഒരു കാര്യം മാത്രമേ ചെയ്യുന്നുള്ളൂ: അത് അടുത്ത ടോക്കൺ (token) പ്രവചിക്കുന്നു. ആ ടോക്കൺ അടുത്ത വാക്കോ, ഒരു വാക്കിന്റെ ഭാഗമോ, അല്ലെങ്കിൽ ഒരു ചിഹ്നമോ ആകാം. കവിത, കോഡ്, യുക്തിചിന്ത (reasoning) എന്നിങ്ങനെ മറ്റെല്ലാ കാര്യങ്ങളും ഈ ഒരു ജോലി വലിയ തോതിൽ ചെയ്യുന്നതിലൂടെ ഉണ്ടാകുന്ന ഫലങ്ങളാണ്.
നിങ്ങളുടെ പ്രോംപ്റ്റിൽ നിന്ന് മോഡലിന്റെ മറുപടിയിലേക്കുള്ള യാത്ര ഇപ്രകാരമാണ്.
Tokenization ആണ് ആദ്യ ഘട്ടം. ഒരു ന്യൂറൽ നെറ്റ്വർക്കിന് അസംസ്കൃത ടെക്സ്റ്റ് (raw text) അർത്ഥശൂന്യമാണ്, അതിനാൽ മോഡൽ നിങ്ങളുടെ വാക്കുകളെ കഷണങ്ങളായി വിഭജിക്കുകയും ഓരോ കഷണത്തെയും ഒരു സംഖ്യയുമായി ബന്ധിപ്പിക്കുകയും ചെയ്യുന്നു. "tokenization" എന്ന വാക്ക് മൂന്ന് വ്യത്യസ്ത ടോക്കണുകളായി മാറാം. വൊക്കാബുലറി അനുസരിച്ച് "New York" എന്ന പ്രയോഗം ഒന്നോ രണ്ടോ ടോക്കണുകളാകാം. ഈ സംഖ്യകൾ വെറുതെ നൽകുന്നതല്ല; മോഡൽ പരിശീലന സമയത്ത് പഠിച്ചെടുത്ത ഒരു നിശ്ചിത ഡിക്ഷണറിയിൽ നിന്നാണ് ഇവ വരുന്നത്.
വാക്കുകൾ സംഖ്യകളായി മാറിയാൽ അവയ്ക്ക് അർത്ഥം ആവശ്യമാണ്. Embeddings ആ സംഖ്യകളെ വെക്റ്ററുകളാക്കി (vectors) മാറ്റുന്നു—സമാനമായ ആശയങ്ങളെ ഗണിതശാസ്ത്രപരമായ ഇടത്തിൽ (mathematical space) അടുത്തായി നിലനിർത്തുന്ന ഫ്ലോട്ടിംഗ് പോയിന്റ് മൂല്യങ്ങളുടെ നീണ്ട പട്ടികയാണിത്. "King", "Queen" എന്നിവ പരസ്പരം അടുത്താണ്. "Paris", "Berlin" എന്നിവ ഒരുമിച്ച് നിൽക്കുന്നുണ്ടെങ്കിലും "Python" അല്ലെങ്കിൽ "JavaScript" എന്നിവയിൽ നിന്ന് വ്യത്യസ്തമായ ഒരു മേഖലയിലാണ് അവ.
എന്നാൽ വെക്റ്ററുകൾക്ക് മാത്രം ക്രമം നിലനിർത്താൻ കഴിയില്ല. വാക്യത്തിൽ ഓരോ ടോക്കണും എവിടെയാണ് ഇരിക്കുന്നത് എന്ന് Positional encoding മോഡലിന് പറഞ്ഞുതരുന്നു. ഇത് ഇല്ലെങ്കിൽ, "The dog bit the man", "The man bit the dog" എന്നിവ ഒരേപോലെയായിരിക്കും കാണപ്പെടുക.
തുടർന്ന് attention mechanism വരുന്നു. ഇൻപുട്ടിലെ എല്ലാ ടോക്കണുകളിലും മോഡൽ ശ്രദ്ധിക്കുകയും അടുത്ത ടോക്കൺ പ്രവചിക്കാൻ ഏതെല്ലാം ടോക്കണുകളാണ് പ്രധാനമെന്ന് തീരുമാനിക്കുകയും ചെയ്യുന്നത് ഇവിടെയാണ്. "When was the company founded, and who leads it now?" എന്ന് നിങ്ങൾ ചോദിക്കുമ്പോൾ, "founded" എന്നതിനെ ഒരു തീയതിയുമായും "leads" എന്നതിനെ ഒരു CEO നാമവുമായും ബന്ധിപ്പിക്കാൻ മോഡലിന് ആവശ്യമാണ്. Attention ഈ ബന്ധങ്ങൾ സൃഷ്ടിക്കുന്നു.
ഈ പ്രവർത്തനങ്ങൾ പല layers ആയി അടുക്കിവെച്ചിരിക്കുന്നു—പലപ്പോഴും ഡസൻ കണക്കിന് പാളികൾ ഉണ്ടാകാം. ആദ്യ പാളികൾ സിന്റാക്സ് (syntax) കൈകാര്യം ചെയ്യുമ്പോൾ പിൽക്കാല പാളികൾ അബ്സ്ട്രാക്റ്റ് റീസണിംഗ് (abstract reasoning) നിർമ്മിക്കുന്നു. ഇതിനിടയിൽ എവിടെയോ, feed-forward networks വസ്തുതാപരമായ ബന്ധങ്ങൾ സൂക്ഷിക്കുന്നു. പാരീസ് ഫ്രാൻസിന്റെ തലസ്ഥാനമാണെന്നോ അല്ലെങ്കിൽ ഒരു പ്രത്യേക API ഒരു JSON payload പ്രതീക്ഷിക്കുന്നു എന്നോ ഉള്ള അറിവ് മോഡൽ സൂക്ഷിക്കുന്നത് ഇവിടെയാണ്. ഇതൊരു ഡാറ്റാബേസ് അല്ല, മറിച്ച് പാറ്റേണുകളെ ഉത്തേജിപ്പിക്കുന്ന വെയ്റ്റുകളുടെ (weights) ഒരു കംപ്രസ്ഡ് ശൃംഖലയാണ്.
ഒടുവിൽ, decoding ആന്തരിക വെക്റ്റർ രൂപങ്ങളെ മനുഷ്യന് വായിക്കാവുന്ന ടോക്കണുകളായി മാറ്റുന്നു. താൻ ഇംഗ്ലീഷിലാണ് എഴുതുന്നതെന്ന് മോഡലിന് "അറിവില്ല"; അത് കേവലം ആയിരക്കണക്കിന് സാധ്യമായ അടുത്ത ടോക്കണുകളെ റാങ്ക് ചെയ്യുകയും ഒരു സ്റ്റോപ്പ് കണ്ടീഷൻ (stop condition) ലഭിക്കുന്നത് വരെ ഏറ്റവും സാധ്യതയുള്ളത് വീണ്ടും വീണ്ടും തിരഞ്ഞെടുക്കുകയും ചെയ്യുന്നു.
RAG ലെയർ: മോഡലുകൾക്ക് ഓർമ്മ നൽകുന്നു
ഒരു ബേസ് മോഡൽ ഒരു നിശ്ചിത സമയത്ത് നിശ്ചലമാണ്. അതിന്റെ വെയ്റ്റുകൾ ഒരു നിശ്ചിത തീയതി വരെയുള്ള ഇന്റർനെറ്റ് വിവരങ്ങൾ ഉൾക്കൊള്ളുന്നു, നിങ്ങൾ അവ നൽകുന്നതുവരെ നിങ്ങളുടെ സ്വകാര്യ രേഖകൾ ഉപയോഗിക്കാൻ അതിന് കഴിയില്ല. ഇത് മിക്ക ബിസിനസ്സ് ആവശ്യങ്ങൾക്കും അതിനെ ഉപയോഗശൂന്യമാക്കുന്നു. Retrieval-Augmented Generation അഥവാ RAG, മറുപടി നൽകുന്നതിന് മുമ്പ് മോഡലിന് ഒരു ബാഹ്യ ലൈബ്രറി നൽകിക്കൊണ്ട് ഈ പ്രശ്നം പരിഹരിക്കുന്നു.
ഇതിന്റെ ആശയം ലളിതമാണെങ്കിലും പ്രായോഗികമായി അത് ശ്രദ്ധയോടെ ചെയ്യേണ്ട ഒന്നാണ്. ആദ്യം, നിങ്ങൾ നിങ്ങളുടെ രേഖകൾ എടുത്ത് chunking പ്രയോഗിക്കുന്നു. നൂറ് പേജുള്ള ഒരു PDF നേരിട്ട് പ്രോംപ്റ്റ് വിൻഡോയിലേക്ക് ഇടുന്നില്ല. പകരം, അർത്ഥം നഷ്ടപ്പെടാതെ തന്നെ മോഡലിന്റെ കോൺടെക്സ്റ്റ് ലിമിറ്റിനുള്ളിൽ (context limit) ഉൾക്കൊള്ളാൻ പാകത്തിൽ അവയെ ഖണ്ഡികകളായോ സെക്ഷനുകളായോ സെമാന്റിക് ബ്ലോക്കുകളായോ നിങ്ങൾ വിഭജിക്കുന്നു.
ഓരോ ചങ്ക് (chunk) ഒരു embedding model വഴി കടന്നുപോവുകയും LLM-നുള്ളിലെ ടോക്കണുകൾ പോലെ തന്നെ ഒരു വെക്റ്ററായി മാറുകയും ചെയ്യുന്നു. ഈ വെക്റ്ററുകൾ ഒരു vector database-ൽ സൂക്ഷിക്കുന്നു—കൃത്യമായ തിരച്ചിലിനേക്കാൾ (exact lookups) സാമ്യതകൾ കണ്ടെത്തുന്നതിനായി (similarity search) രൂപകൽപ്പന ചെയ്ത ഒരു പ്രത്യേക സംഭരണമാണിത്. ഒരു ഉപയോക്താവ് ചോദ്യം ചോദിക്കുമ്പോൾ, നിങ്ങൾ അവരുടെ ക്വറി (query) വെക്റ്ററാക്കി മാറ്റുകയും ഡാറ്റാബേസിനോട് ചോദിക്കുകയും ചെയ്യുന്നു: "ഈ വെക്റ്ററിനോട് അർത്ഥത്തിൽ ഏറ്റവും അടുത്ത് നിൽക്കുന്ന ചങ്കുകൾ ഏതാണ്?"
വെക്റ്റർ സെർച്ച് മാത്രം ഉപയോഗിക്കുമ്പോൾ പലപ്പോഴും കൃത്യമായ പൊരുത്തങ്ങൾ നഷ്ടപ്പെട്ടേക്കാം. നല്ലൊരു പ്രൊഡക്ഷൻ സിസ്റ്റം കീവേഡ് മാച്ചിംഗും (keyword matching) സെമാന്റിക് സമാനതയും (semantic similarity) സംയോജിപ്പിക്കുന്ന hybrid search ഉപയോഗിക്കുന്നു. ആരെങ്കിലും "SLA-99 compliance" എന്ന് ചോദിച്ചാൽ, സമാനമായ ഒന്നല്ല, മറിച്ച് ആ വാചകം കൃത്യമായി അടങ്ങിയ രേഖയാണ് നിങ്ങൾക്ക് വേണ്ടത്.
വിവരങ്ങൾ കണ്ടെത്തിക്കഴിഞ്ഞാൽ (retrieval), re-ranking അനാവശ്യ വിവരങ്ങളെ ഒഴിവാക്കുന്നു. ആദ്യത്തെ സെർച്ച് ഇരുപതോളം ചങ്കുകൾ നൽകിയേക്കാം, എന്നാൽ അവയിൽ മൂന്നോ നാലോ എണ്ണം മാത്രമേ യഥാർത്ഥത്തിൽ സഹായിക്കുകയുള്ളൂ. ഒരു റീ-റാങ്കർ (re-ranker) പ്രസക്തി പരിശോധിക്കുകയും LLM-ലേക്ക് എത്തുന്നതിന് മുമ്പ് ബാക്കിയുള്ളവ ഒഴിവാക്കുകയും ചെയ്യുന്നു, ഇത് ടോക്കണുകൾ ലാഭിക്കാനും ഹാലുസിനേഷനുകൾ (hallucinations) കുറയ്ക്കാനും സഹായിക്കുന്നു.
ഏജന്റ് ലെയർ: നടപടികൾ സ്വീകരിക്കുന്നു
RAG ഒരു മോഡലിനെ വായിക്കാൻ അനുവദിക്കുന്നു. ഏജന്റുകൾ അതിനെ പ്രവർത്തിക്കാൻ അനുവദിക്കുന്നു.
അടിസ്ഥാനപരമായി ഒരു ലൂപ്പിനുള്ളിൽ കുടുങ്ങിക്കിടക്കുന്ന ഒരു LLM ആണ് ഒരു ഏജന്റ്. അത് നിരീക്ഷിക്കുന്നു, ചിന്തിക്കുന്നു, പ്രവർത്തിക്കുന്നു, തുടർന്ന് വീണ്ടും നിരീക്ഷിക്കുന്നു. ഒരു വിമാനം ബുക്ക് ചെയ്യാൻ നിങ്ങൾ ഒരു ഏജന്റിനോട് ആവശ്യപ്പെട്ടാൽ, ബുക്കിംഗ് എങ്ങനെയാണ് പ്രവർത്തിക്കുന്നത് എന്ന് അത് വിവരിക്കുക മാത്രമല്ല ചെയ്യുന്നത്. അത് ജോലിയെ വിവിധ ഘട്ടങ്ങളായി തിരിക്കുന്നു, ശരിയായ ഫംഗ്ഷനുകൾ വിളിക്കുന്നു, മറുപടികൾ വായിക്കുന്നു, കൂടാതെ ആവശ്യാനുസരണം മാറ്റങ്ങൾ വരുത്തുകയും ചെയ്യുന്നു.
ആ ലൂപ്പ് ഇപ്രകാരമാണ്. Observe: ഏജന്റ് നിലവിലെ അവസ്ഥ—നിങ്ങളുടെ അഭ്യർത്ഥന, മുൻപത്തെ ടൂൾ കോളുകളുടെ ഫലങ്ങൾ, എന്തെങ്കിലും പിശകുകൾ എന്നിവ വായിക്കുന്നു. Reason: അടുത്തതായി എന്തുചെയ്യണമെന്ന് LLM തീരുമാനിക്കുന്നു, പലപ്പോഴും ഒരു ഘടനാപരമായ പ്ലാൻ തയ്യാറാക്കിയോ അല്ലെങ്കിൽ മുൻകൂട്ടി നിശ്ചയിച്ച ഓപ്ഷനുകളിൽ നിന്ന് തിരഞ്ഞെടുക്കുകയോ ചെയ്തുകൊണ്ട് ഇത് ചെയ്യുന്നു. Act: അത് ഒരു ടൂൾ വിളിക്കുന്നു.
ഏജന്റുകൾ യഥാർത്ഥ ലോകവുമായി ബന്ധപ്പെടുന്നത് ടൂളുകൾ വഴിയാണ്. ഒരു API-ക്ക് കൃത്യമായി എന്തൊക്കെ പാരാമീറ്ററുകൾ ആവശ്യമാണെന്ന് മോഡലിനോട് പറയുന്ന JSON schemas ഉപയോഗിച്ചാണ് അവ നിർവചിച്ചിരിക്കുന്നത്. LLM തനിയെ തോന്നുന്ന രീതിയിലുള്ള HTTP റിക്വസ്റ്റുകൾ അയക്കുകയല്ല ചെയ്യുന്നത്. പകരം അത് ഒരു സ്കീമ പൂരിപ്പിക്കുകയാണ് ചെയ്യുന്നത്. "city: London, units: metric എന്നീ പാരാമീറ്ററുകൾ ഉപയോഗിച്ച് weather API വിളിക്കുക." ടൂൾ ഒരു താപനില നൽകിയാൽ, ഏജന്റ് അത്...