AI ഏജന്റുകളുടെ ഏറ്റവും പ്രയാസകരമായ കാര്യം കാര്യങ്ങൾ ചെയ്യുക എന്നതല്ല, മറിച്ച് അവ പ്ലാൻ ചെയ്യുക എന്നതാണ്.
ജോലികൾ ചെയ്യുന്ന ഒരു AI ഏജന്റിനെ നിർമ്മിക്കുന്നത് എളുപ്പമാണ്. എന്നാൽ അവ കൃത്യമായി പ്ലാൻ ചെയ്യുന്ന ഒന്ന് നിർമ്മിക്കുന്നത് പ്രയാസകരമാണ്.
നിങ്ങൾ ഒരു വാചകം ടൈപ്പ് ചെയ്യുമ്പോൾ ഒരു LLM നിങ്ങളുടെ യഥാർത്ഥ അക്കൗണ്ടുകളിൽ ആക്ഷനുകൾ നടപ്പിലാക്കുന്ന ഒരു CLI ഞാൻ നിർമ്മിച്ചിട്ടുണ്ട്. ഞാൻ രണ്ട് മോഡുകൾ ഉപയോഗിക്കുന്നു: Direct mode, Plan mode.
വേഗതയ്ക്കായിട്ടാണ് Direct mode ഉപയോഗിക്കുന്നത്. സുരക്ഷയ്ക്കായിട്ടാണ് Plan mode. Plan mode-ൽ, ഏജന്റ് നിങ്ങളുടെ ഡാറ്റയിൽ തൊടുന്നതിന് മുമ്പ് ഓരോ ഘട്ടവും നിങ്ങൾക്ക് കാണിച്ചുതരുന്നു.
വിശ്വസനീയമായ ഒരു പ്ലാനർ ഞാൻ എങ്ങനെ നിർമ്മിച്ചു എന്ന് ഇതാ:
• തലച്ചോറിനെ രണ്ടായി തിരിക്കുക (Split the brain) ഒരു ഏജന്റിന് പ്ലാനിംഗും എക്സിക്യൂഷനും (execution) ഒരേസമയം ചെയ്യാൻ കഴിയില്ല. ഒരു പ്ലാനിംഗ് ഏജന്റ് ചിന്തിക്കാൻ ആഗ്രഹിക്കുന്നു. ഒരു എക്സിക്യൂഷൻ ഏജന്റ് പ്രവർത്തിക്കാൻ ആഗ്രഹിക്കുന്നു. ഞാൻ അവയെ രണ്ട് വ്യത്യസ്ത സിസ്റ്റം പ്രോംപ്റ്റുകളുള്ള രണ്ട് വ്യത്യസ്ത ഏജന്റുകളായി വേർതിരിച്ചു. ഇത് അവ തമ്മിലുള്ള തർക്കം ഒഴിവാക്കുന്നു.
• ഏജന്റിന് കാഴ്ച നൽകുക (Give the agent eyes) ഊഹിച്ചുകൊണ്ട് പ്ലാൻ ചെയ്യുന്ന ഒരു പ്ലാനർ അപകടകാരിയാണ്. എന്റെ ആദ്യ പതിപ്പ് അനുമാനങ്ങളുടെ അടിസ്ഥാനത്തിൽ പ്ലാനുകൾ ഉണ്ടാക്കിയിരുന്നു. എന്നാൽ ഇപ്പോൾ, പ്ലാനർ നിങ്ങളുടെ ഡാറ്റ ഗവേഷണം ചെയ്യാൻ read-only ടൂളുകൾ ഉപയോഗിക്കുന്നു. ഒരു ഘട്ടം പോലും എഴുതുന്നതിന് മുമ്പ് അത് നിങ്ങളുടെ യഥാർത്ഥ Salesforce ഫീൽഡുകൾ പരിശോധിക്കുന്നു.
• ഉത്തരങ്ങൾ മുൻകൂട്ടി പൂരിപ്പിക്കുക (Prefill the answers) ഏജന്റുകൾ പലപ്പോഴും മോശം ചോദ്യങ്ങൾ ചോദിക്കാറുണ്ട്. അവ ഒരുപാട് ചോദ്യങ്ങൾ ചോദിച്ചാൽ, അവസാനം നിങ്ങൾ അവർക്ക് വേണ്ടി ജോലി ചെയ്യേണ്ടി വരും. ഞാൻ ഇത് മാറ്റി. പ്ലാനർ ഇപ്പോഴും ചോദ്യങ്ങൾ ചോദിക്കുന്നുണ്ടെങ്കിലും, അതോടൊപ്പം ഒരു ശുപാർശ ചെയ്ത ഉത്തരവും (recommended answer) നൽകുന്നു. നിങ്ങൾക്ക് അത് സ്ഥിരീകരിക്കുകയോ ചെറിയ മാറ്റങ്ങൾ വരുത്തുകയോ മാത്രം ചെയ്താൽ മതി. ഇത് മാനുവൽ ഡാറ്റ എൻട്രി ഇല്ലാതെ തന്നെ പ്ലാൻ കൃത്യമായി നിലനിർത്തുന്നു.
• ലിസ്റ്റ് മാത്രമല്ല, കോൺടെക്സ്റ്റും കൈമാറുക (Pass the context, not just the list) ഒരു എക്സിക്യൂട്ടറിന് ഘട്ടങ്ങളുടെ ഒരു ലിസ്റ്റ് മാത്രം നൽകിയാൽ, അതിന്റെ പിന്നിലെ യുക്തി (reasoning) നഷ്ടപ്പെടും. പ്ലാനർ ഘട്ടങ്ങൾക്കൊപ്പം അനുമാനങ്ങളും അപകടസാധ്യതകളും (risks) കൂടി കൈമാറുന്ന രീതിയിലാണ് ഞാൻ ഇത് ചെയ്തത്. ഓരോ ആക്ഷന്റെയും പിന്നിലെ "എന്തുകൊണ്ട്" എന്നത് ഇപ്പോൾ എക്സിക്യൂട്ടറിന് അറിയാം.
• അപകടസാധ്യതകൾ അടയാളപ്പെടുത്തുക (Label the danger) അപകടസാധ്യതകൾ കാണാൻ കഴിയുമെങ്കിൽ മാത്രമേ ഒരു പ്ലാൻ സുരക്ഷിതമാകൂ. ഡിലീറ്റ് ചെയ്യുകയോ പേര് മാറ്റുകയോ പോലുള്ള വിനാശകരമായ (destructive) ആക്ഷനുകൾ എന്റെ സിസ്റ്റം അടയാളപ്പെടുത്തുന്നു. ഏജന്റ് ഒരു വിനാശകരമായ ഘട്ടത്തിൽ എത്തുമ്പോൾ, അത് നിൽക്കുകയും നിങ്ങളോട് ചോദിക്കുകയും ചെയ്യുന്നു.
• ഡാറ്റയെ ഒരു തീരുമാനമെടുക്കാനുള്ള മാർഗമായി ഉപയോഗിക്കുക (Use data as the tiebreaker) ഒരു ഘട്ടം പരാജയപ്പെട്ടുവെന്ന് ഏജന്റ് കരുതുകയും നിങ്ങൾ അത് വീണ്ടും ചെയ്യാൻ ആവശ്യപ്പെടുകയും ചെയ്താൽ, അത് അന്ധമായി അനുസരിക്കില്ല. അത് യഥാർത്ഥ പ്ലാറ്റ്ഫോം ഡാറ്റ പരിശോധിക്കുന്നു. ടാസ്ക് ഇതിനകം പൂർത്തിയായെന്ന് ഡാറ്റ കാണിക്കുന്നുണ്ടെങ്കിൽ, നിങ്ങളുടെ വാക്കിനേക്കാൾ ഏജന്റ് ഡാറ്റയെ വിശ്വസിക്കുന്നു.
സുരക്ഷയെക്കുറിച്ചുള്ള സത്യം: Plan mode പ്രോംപ്റ്റ് ഇൻജക്ഷനോ (prompt injection), നോക്കാതെ "approve" ക്ലിക്ക് ചെയ്യുന്ന ഉപയോക്താവിനെയോ തടയുന്നില്ല. ഇത് ഉത്തരവാദിത്തം "മോഡലിനെ വിശ്വസിക്കുക" എന്നതിൽ നിന്ന് "പരിശോധിക്കാൻ മനുഷ്യനെ വിശ്വസിക്കുക" എന്നതിലേക്ക് മാറ്റുന്നു.
ഈ ഘടന സുരക്ഷാ കവചങ്ങൾ (guardrails) നൽകുന്നുണ്ടെങ്കിലും, നിങ്ങളുടെ പരിശോധനയാണ് അന്തിമ സുരക്ഷ നൽകുന്നത്.
Optional learning community: https://t.me/GyaanSetuAi
