നിങ്ങൾ ആദ്യമായി ആർട്ടിഫിഷ്യൽ ഇന്റലിജൻസ് ഉപയോഗിച്ച് നിർമ്മാണം തുടങ്ങുമ്പോൾ, ഏറ്റവും കൂടുതൽ കേൾക്കുന്ന അഭിപ്രായങ്ങൾ ഒരേ ഒരു കാര്യത്തിലേക്കാണ് വിരൽ ചൂണ്ടുന്നത്: മോഡൽ. ശരിയായ മോഡൽ തിരഞ്ഞെടുക്കുകയാണെങ്കിൽ ബാക്കിയെല്ലാം തനിയെ ശരിയാകും എന്ന് അവർ പറയുന്നു. എന്റെ സ്വന്തം പരീക്ഷണങ്ങൾ തുടങ്ങിയിട്ട് ഏതാനും ആഴ്ചകൾ പിന്നിടുമ്പോൾ, അത് അത്ര ലളിതമല്ലെന്ന് എനിക്ക് പറയാൻ കഴിയും. ലഭ്യമായ ലാർജ് ലാംഗ്വേജ് മോഡലുകൾക്കിടയിൽ നിന്ന് അനുയോജ്യമായത് തിരഞ്ഞെടുക്കുന്നത് പ്രധാനമാണ്, പക്ഷേ അത് ജോലിയുടെ ഇരുപത് ശതമാനം മാത്രമാണ്. ബാക്കിയുള്ളത് സിസ്റ്റം വർക്കുകളാണ് (systems work). അത് പ്ലംബിംഗ്, കരകൗശലം, നിരന്തരമായ പരിശോധനകൾ എന്നിവയാണ്. ഈ തിരിച്ചറിവ് എനിക്ക് നേരത്തെ ലഭിച്ചു, അതിനുശേഷം ഓരോ പ്രോജക്റ്റിലും എന്റെ സമീപനം തന്നെ അത് മാറ്റിമറിച്ചു.
മോഡൽ എന്നത് വെറുമൊരു തുടക്കം മാത്രമാണ്
തുടക്കക്കാർ എന്തിനാണ് മോഡലുകളിൽ മാത്രം ശ്രദ്ധ കേന്ദ്രീകരിക്കുന്നത് എന്ന് മനസ്സിലാക്കാൻ എളുപ്പമാണ്. പുതിയ റിലീസ് നോട്ടുകൾ മെച്ചപ്പെട്ട റീസണിംഗ് (reasoning), വലിയ കോൺടെക്സ്റ്റ് വിൻഡോകൾ (context windows), കൂടുതൽ വ്യക്തമായ ഔട്ട്പുട്ടുകൾ എന്നിവ വാഗ്ദാനം ചെയ്യുന്നു. ആ മെച്ചപ്പെടുത്തലുകൾ യഥാർത്ഥമാണ്, എന്നാൽ അവ പൊതുവായ ആവശ്യങ്ങൾക്കുള്ളതാണ് (general-purpose). അത്യാധുനികമായ ഒരു മോഡലിന് നിങ്ങളുടെ കമ്പനിയുടെ റീഫണ്ട് പോളിസി തനിയെ അറിയാൻ കഴിയില്ല. എങ്ങനെ ചെയ്യണമെന്ന് നിങ്ങൾ പറഞ്ഞു കൊടുത്തില്ലെങ്കിൽ, നിങ്ങളുടെ മൊബൈൽ ആപ്പിന് അനുയോജ്യമായ രീതിയിൽ മറുപടികൾ നൽകാൻ അതിന് കഴിയില്ല. വെറുതെയിരുന്നുകൊണ്ട് അതിന് തത്സമയ ഇൻവെന്ററി ഡാറ്റ (live inventory data) കണ്ടെത്താൻ കഴിയില്ല.
ഞാൻ ഇത് കഠിനമായ അനുഭവത്തിലൂടെയാണ് പഠിച്ചത്. എന്റെ ആദ്യത്തെ പ്രോട്ടോടൈപ്പ് മികച്ച ഒരു മോഡൽ ഉപയോഗിച്ചിരുന്നു, അത് മനോഹരവും ആത്മവിശ്വാസമുള്ളതുമായ ഖണ്ഡികകൾ നിർമ്മിച്ചു, എന്നാൽ അവ ഇടയ്ക്കിടെ തികച്ചും തെറ്റായിരുന്നു. മോഡൽ ശരിയായ ശൈലി (tone) കൈകാര്യം ചെയ്തതുകൊണ്ട് ടെക്സ്റ്റ് പ്രൊഫഷണലായി തോന്നി, എന്നാൽ അതിന് പുതിയ വിവരങ്ങൾ ലഭ്യമായിരുന്നില്ല. ഡാറ്റാ പൈപ്പ്ലൈനുകളെക്കുറിച്ചും (data pipelines) കോൺടെക്സ്റ്റ് ഇൻജക്ഷനെക്കുറിച്ചും (context injection) ചിന്തിക്കേണ്ടതിന് പകരം, മോഡൽ ബെഞ്ച്മാർക്കുകൾ താരതമ്യം ചെയ്യാൻ ഞാൻ ദിവസങ്ങൾ ചിലവഴിച്ചു. മോഡൽ തകരാറിലായിരുന്നില്ല. അതിന് ചുറ്റുമുള്ള സിസ്റ്റം അപൂർണ്ണമായിരുന്നു. വെറും ഡെമോകളിൽ നിന്ന് ആളുകൾ യഥാർത്ഥത്തിൽ വിശ്വസിക്കുന്ന സോഫ്റ്റ്വെയറുകളിലേക്ക് മാറുമ്പോൾ ഈ വ്യത്യാസം വളരെ പ്രധാനമാണ്.
പ്രോംപ്റ്റുകൾ നിർദ്ദേശങ്ങളല്ല, അവ കോഡാണ്
ഏതൊരു വിശ്വസനീയമായ AI ആപ്ലിക്കേഷന്റെയും ഹൃദയഭാഗം ഉയർന്ന നിലവാരമുള്ള പ്രോംപ്റ്റുകളാണ്. തുടക്കത്തിൽ, ഞാൻ പ്രോംപ്റ്റുകളെ സെർച്ച് ക്വറികൾ പോലെയാണ് കണ്ടിരുന്നത്—ചെറുതും, സാധാരണ രീതിയിലുള്ളതും, പ്രതീക്ഷാനിരക്ഷകളില്ലാത്തതും. "ഇത് സംഗ്രഹിക്കുക" എന്നോ "സഹായിക്കുക" എന്നോ ഞാൻ മോഡലിനോട് ആവശ്യപ്പെടുകയും നല്ല ഫലം ലഭിക്കുമെന്ന് പ്രതീക്ഷിക്കുകയും ചെയ്യുമായിരുന്നു. ഫലങ്ങൾ ഉപയോഗപ്രദമായതും അപ്രസക്തമായതും എന്നിങ്ങനെ വലിയ വ്യത്യാസങ്ങൾ കാണിച്ചു, എന്തുകൊണ്ടെന്ന് എനിക്ക് അറിയില്ലായിരുന്നു.
ഇപ്പോൾ ഞാൻ പ്രോംപ്റ്റുകളെ ലഘുവായ പ്രോഗ്രാമുകൾ പോലെയാണ് കാണുന്നത്. ഒരു നല്ല പ്രോംപ്റ്റ് റോൾ നിർവചിക്കുന്നു, ഔട്ട്പുട്ട് ഫോർമാറ്റ് വ്യക്തമാക്കുന്നു, ആവശ്യമുള്ളപ്പോൾ ഉദാഹരണങ്ങൾ ഉൾപ്പെടുത്തുന്നു, കൂടാതെ പരിധികൾ നിശ്ചയിക്കുകയും ചെയ്യുന്നു. എനിക്ക് JSON വേണമെങ്കിൽ, ഞാൻ JSON ആവശ്യപ്പെടുകയും അതിന്റെ സ്കീമ (schema) കാണിക്കുകയും ചെയ്യുന്നു. എനിക്ക് ചുരുങ്ങിയ മറുപടി വേണമെങ്കിൽ, ഞാൻ അതിന്റെ ദൈർഘ്യം കൃത്യമായി നിശ്ചയിക്കുകയും ആമുഖങ്ങൾ ഒഴിവാക്കുകയും ചെയ്യുന്നു. ആവർത്തിച്ചുള്ള പരീക്ഷണങ്ങൾ (Iteration) പ്രധാനമാണ്. ഞാൻ പ്രോംപ്റ്റുകളുടെയും അവയുടെ ഔട്ട്പുട്ടുകളുടെയും ഒരു ലോഗ് സൂക്ഷിക്കുന്നു, ഓരോ തവണയും ഓരോ വേരിയബിൾ വീതം മാറ്റുന്നു. ഒരു പ്രോംപ്റ്റിലെ ഒരു അവ്യക്തമായ വിശേഷണം പോലും ഒരു മുഴുവൻ വർക്ക്ഫ്ലോയുടെയും (workflow) സ്വഭാവം മാറ്റിയേക്കാം. ആ സൂക്ഷ്മതയ്ക്ക് കൃത്യത ആവശ്യമാണ്, ഊഹങ്ങളല്ല.
തെറ്റായ വിവരങ്ങൾ നൽകിയാൽ തെറ്റായ ഫലമേ ലഭിക്കൂ (Garbage In, Garbage Out)
വിശ്വസനീയമായ ഡാറ്റാ റിട്രീവൽ (data retrieval) ഇല്ലാത്തതുകൊണ്ട് പല AI പ്രോജക്റ്റുകളും പരാജയപ്പെടുന്നു. മോഡലുകൾക്ക് സ്വകാര്യമായതോ പുതിയതോ ആയ വിവരങ്ങൾ നൽകുന്നതിനുള്ള സ്റ്റാൻഡേർഡ് രീതിയായി Retrieval-Augmented Generation അഥവാ RAG മാറിയിരിക്കുന്നു. ഇതിന്റെ ആശയം ലളിതമാണ്: പ്രസക്തമായ രേഖകൾ ശേഖരിക്കുക, അവ മോഡലിന്റെ കോൺടെക്സ്റ്റ് വിൻഡോയിലേക്ക് നൽകുക, വസ്തുതകളുടെ അടിസ്ഥാനത്തിൽ മോഡലിനെ ചിന്തിപ്പിക്കുക. എന്നാൽ പ്രായോഗികമായി ഇത് അത്ര എളുപ്പമല്ല.
ബന്ധമില്ലാത്ത ഫലങ്ങൾ നൽകിക്കൊണ്ടിരുന്ന ഒരു സിമ്പിൾ നോളജ് ബേസ് (knowledge base) ശരിയാക്കാൻ ഞാൻ ഒരുപാട് സമയം ചിലവഴിച്ചു. മോഡൽ ശരിയായിരുന്നു. റിട്രീവൽ ലെയർ (retrieval layer) ആണ് പരാജയപ്പെട്ടത്. എന്റെ ചങ്ക്സ് (chunks) വളരെ ചെറുതായിരുന്നു, അവയ്ക്ക് കോൺടെക്സ്റ്റ് ഉണ്ടായിരുന്നില്ല. ഡ്യൂപ്ലിക്കേറ്റ് ഹെഡറുകൾ നീക്കം ചെയ്യാതെയാണ് എന്റെ എംബെഡിംഗുകൾ (embeddings) തയ്യാറാക്കിയത്. സിമിലാരിറ്റി സെർച്ച് (similarity search) സാങ്കേതികമായി അടുത്തുള്ള എന്നാൽ തെറ്റായ ചോദ്യത്തിന് ഉത്തരം നൽകുന്ന ടെക്സ്റ്റുകൾ കണ്ടെത്തി. ഇത് പരിഹരിക്കാൻ ചങ്കിംഗ് സ്ട്രാറ്റജി (chunking strategy) വീണ്ടും ചിന്തിക്കേണ്ടി വന്നു, മെറ്റാഡാറ്റ ഫിൽട്ടറുകൾ (metadata filters) ചേർക്കേണ്ടി വന്നു, കൂടാതെ ഒരു റീ-റാങ്കിംഗ് ഘട്ടം (re-ranking step) കൂടി കൊണ്ടുവന്നു. റിട്രീവൽ സ്ഥിരപ്പെട്ടതോടെ, മോഡലിന്റെ ഉത്തരങ്ങൾ പെട്ടെന്ന് മെച്ചപ്പെട്ടു. പാഠം വ്യക്തമായിരുന്നു: മോശം ഡാറ്റാ റിട്രീവൽ ഒരു മികച്ച മോഡൽ ഉപയോഗിച്ച് മാത്രം പരിഹരിക്കാൻ കഴിയില്ല. നിങ്ങൾ പൈപ്പ്ലൈൻ (pipeline) ശരിയായി നിർമ്മിക്കണം.
അളക്കാൻ കഴിയാത്തതിനെ മെച്ചപ്പെടുത്താൻ കഴിയില്ല
നിരന്തരമായ മൂല്യനിർണ്ണയം (evaluation) ആണ് പരീക്ഷണങ്ങളെ ഉൽപ്പന്നങ്ങളിൽ നിന്ന് വേർതിരിക്കുന്ന ശീലം. ഞാൻ തുടങ്ങിയപ്പോൾ, ഒരു തോന്നലിന്റെ (vibe) അടിസ്ഥാനത്തിലാണ് മൂല്യനിർണ്ണയം നടത്തിയിരുന്നത്. അഞ്ച് ഔട്ട്പുട്ടുകൾ വായിച്ച്, അത് ശരിയാണെന്ന് കരുതി ഞാൻ മുന്നോട്ട് പോകുമായിരുന്നു. ഒരു ഉപയോക്താവ് ആറാമത്തെ ചോദ്യം ചോദിക്കുമ്പോൾ വിചിത്രമായ മറുപടി ലഭിക്കുന്നത് വരെ ഇത് പ്രവർത്തിക്കും.
ഇപ്പോൾ ഓരോ ഫീച്ചറിനും വേണ്ടി ഞാൻ ചെറിയ ഇവാലുവേഷൻ സെറ്റുകൾ (evaluation sets) നിർമ്മിക്കുന്നു. യഥാർത്ഥ ഉപയോക്താക്കളുടെ ചോദ്യങ്ങൾ ശേഖരിക്കുകയും, പ്രതീക്ഷിക്കുന്ന രീതി അടയാളപ്പെടുത്തുകയും, അവയ്ക്കെതിരെ ഓട്ടോമേറ്റഡ് പരിശോധനകൾ നടത്തുകയും ചെയ്യുന്നു. ഡ്രിഫ്റ്റ് (drift) ഞാൻ ശ്രദ്ധിക്കാറുണ്ട്: കഴിഞ്ഞ മാസം പ്രവർത്തിച്ച ഒരു പ്രോംപ്റ്റ്, ഒരു മോഡൽ അപ്ഡേറ്റിന് ശേഷമോ അല്ലെങ്കിൽ അടിസ്ഥാന ഡാറ്റ മാറുമ്പോഴോ അതിന്റെ ഗുണനിലവാരം കുറഞ്ഞേക്കാം. ശൈലിയിലുള്ള മൂല്യനിർണ്ണയത്തെ വസ്തുതകളുടെ കൃത്യതയിൽ നിന്ന് ഞാൻ വേർതിരിക്കുന്നു. പ്രൊഫഷണലായി തോന്നുന്നത് നല്ലതാണ്; എന്നാൽ കൃത്യതയാകണം നിർബന്ധം. ഈ പ്രക്രിയയില്ലാതെ, നിങ്ങൾ വെറും പ്രതീക്ഷയുടെ അടിസ്ഥാനത്തിലാണ് ഉൽപ്പന്നങ്ങൾ പുറത്തിറക്കുന്നത്, എന്നാൽ പ്രതീക്ഷ ഒരു ടെസ്റ്റിംഗ് സ്ട്രാറ്റജി (testing strategy) അല്ല.
മെഷീന്റെ പരിമിതികൾ അറിയുക
മോഡലുകളുടെ പരിമിതികൾ മനസ്സിലാക്കിയത് അമിതമായി വാഗ്ദാനം നൽകുന്നതിൽ നിന്നും പ്രതീക്ഷിച്ചതിലും കുറഞ്ഞ ഫലം നൽകുന്നതിൽ നിന്നും എന്നെ രക്ഷിച്ചു. ഈ സിസ്റ്റങ്ങൾക്ക് യഥാർത്ഥമായ നിയന്ത്രണങ്ങളുണ്ട്. കോൺടെക്സ്റ്റ് വിൻഡോകൾ (Context windows) പഴയതിനേക്കാൾ വലുതാണെങ്കിലും അവയ്ക്ക് ഇപ്പോഴും പരിധികളുണ്ട്, അവ പൂർണ്ണമായും നിറയ്ക്കുന്നത് പ്രവർത്തനക്ഷമതയെ ബാധിച്ചേക്കാം. മോഡലുകൾ ഹാലുസിനേഷൻ (hallucinate) നടത്താറുണ്ട്, പ്രത്യേകിച്ച് പരിശീലന ഡാറ്റ കുറഞ്ഞ അപൂർവ്വ വിഷയങ്ങളിൽ. കൃത്യമായ ഗണിതക്രിയകളിലും ചിലതരം മൾട്ടി-സ്റ്റെപ്പ് ലോജിക്കുകളിലും അവ ബുദ്ധിമുട്ടുന്നു. അവ വാചകഘടനയോട് (phrasing) വളരെ സെൻസിറ്റീവ് ആണ്.
ചെലവും വേഗതയും പരിമിതികളാണ്. പത്ത് സെക്കൻഡിനുള്ളിൽ മികച്ച ഗദ്യരൂപം നിർമ്മിക്കുന്ന ഒരു മോഡൽ ഒരു റിയൽ-ടൈം ചാറ്റ് ഇന്റർഫേസിൽ ഉപയോഗിക്കാൻ കഴിയാത്തതാകാം. ഞാൻ ഇപ്പോൾ ഫീച്ചറുകളെ ലേറ്റൻസി ബജറ്റുകളുമായി (latency budgets) നേരത്തെ തന്നെ ബന്ധിപ്പിക്കുന്നു. ഒരു ടാസ്കിന് ഒരു സെക്കൻഡിൽ താഴെ പ്രതികരണം ആവശ്യമാണെങ്കിൽ, ഞാൻ ഉത്തരങ്ങൾ മുൻകൂട്ടി കണക്കാക്കുകയോ (precompute), കാഷിംഗ് (caching) ശക്തമാക്കുകയോ, അല്ലെങ്കിൽ ആദ്യ ഡ്രാഫ്റ്റിനായി ഒരു ചെറിയ മോഡലും അത് പരിഷ്കരിക്കുന്നതിനായി മാത്രം ഒരു വലിയ മോഡലും ഉപയോഗിക്കുകയോ ചെയ്തേക്കാം. പരിമിതികൾക്കുള്ളിൽ നിന്നുകൊണ്ട് പ്രവർത്തിക്കുന്നത് സാധാരണ എഞ്ചിനീയറിംഗ് രീതിയാണ്. AI ഇതിൽ നിന്നും വ്യത്യസ്തമല്ല.
യഥാർത്ഥ മനുഷ്യർക്കായി നിർമ്മിക്കുമ്പോൾ
ലളിതമായ ഒരു ലക്ഷ്യത്തോടെയാണ് ഞാൻ നിലവിൽ LLM ആപ്ലിക്കേഷനുകളെക്കുറിച്ചും സോഫ്റ്റ്വെയർ എഞ്ചിനീയറിംഗിനെക്കുറിച്ചും പഠിച്ചുകൊണ്ടിരിക്കുന്നത്: ആളുകൾ ദിവസവും ഉപയോഗിക്കുന്ന ടൂളുകൾ നിർമ്മിക്കുക. ഇത് കേൾക്കുമ്പോൾ വളരെ ലളിതമായി തോന്നാം, എന്നാൽ ഒരു മികച്ച പ്രോട്ടോടൈപ്പും ദിവസേന ഉപയോഗിക്കുന്ന ഒരു ടൂളും തമ്മിലുള്ള വ്യത്യാസം വളരെ വലുതാണ്. ഒരു ഡെമോയിൽ നാൽപ്പത് സെക്കൻഡ് ഇടവേളയോ അമിതമായ വിവരണങ്ങളോ സഹിക്കാവുന്നതാണ്. എന്നാൽ ഒരു മീറ്റിംഗിന് മുമ്പ് ഒരു ജോലി തീർക്കാൻ ശ്രമിക്കുന്ന ഒരാൾക്ക് അത് സാധ്യമല്ല.
ദൈനംദിന ഉപയോഗത്തിനുള്ള ടൂളുകൾക്ക് എറർ ഹാൻഡ്ലിംഗ് (error handling), ഫാള