നിങ്ങളുടെ ഏജന്റധിഷ്ഠിത സിസ്റ്റത്തിൽ തീരുമാനങ്ങൾ എങ്ങനെ, എവിടെ എടുക്കുന്നു എന്ന് ശ്രദ്ധാപൂർവം പരിഗണിക്കേണ്ടത് പ്രധാനമാണ്.
കൂടുതൽ തീരുമാനങ്ങൾ LLM-ന് വിട്ടുകൊടുക്കുന്നത് കൂടുതൽ ജോലികളിലേക്ക് സിസ്റ്റത്തെ വ്യാപിപ്പിക്കാൻ സഹായിച്ചേക്കാം. എന്നാൽ വേഗം, വിശ്വാസ്യത, കരുത്ത് എന്നിവ കുറയാനിടയുണ്ട്.
സാധ്യമാകുന്നിടത്തോളം തീരുമാനമെടുക്കൽ പ്രക്രിയ LLM-ൽനിന്ന് മാറ്റി വ്യക്തമായി നിർവചിച്ച സോഫ്റ്റ്വെയർ കോഡിലാക്കാൻ ശ്രമിക്കുക. ഉയർന്ന അപകടസാധ്യതയുള്ളതും ഉൽപ്പാദനതലത്തിലുള്ളതുമായ പ്രവർത്തനക്രമങ്ങൾക്ക് ഇത് പ്രത്യേകിച്ചും ബാധകമാണ്.
LLM അടിസ്ഥാനമാക്കിയ ഏജന്റധിഷ്ഠിത സിസ്റ്റം രൂപകൽപ്പന ചെയ്യുമ്പോൾ, തീരുമാനമെടുക്കൽ എത്രത്തോളം LLM മോഡലിനുള്ളിലും എത്രത്തോളം വ്യക്തമായി നിർവചിച്ച സോഫ്റ്റ്വെയറിലുമായിരിക്കണം എന്നതാണ് ഏറ്റവും പ്രധാനപ്പെട്ട തിരഞ്ഞെടുപ്പുകളിലൊന്ന്.
ഇത് മനസ്സിലാക്കാൻ, ഇനിപ്പറയുന്ന സമീപനങ്ങൾക്കിടയിലുള്ള ഒരു തുടർച്ചയായി ഈ തിരഞ്ഞെടുപ്പിനെ കാണാം.
റൂട്ടർ അധിഷ്ഠിത ആർക്കിടെക്ചറുകൾ ക്രമവും യുക്തിയും കോഡിൽ വ്യക്തമായി നിർവചിക്കുന്നു. പരിമിതമായ മേഖലകളിലെ ജോലികൾക്ക് പരിശോധനാക്ഷമതയും പ്രവചനീയതയും കരുത്തും ഇത് ഉറപ്പാക്കുന്നു. ഇവയെ "പ്രവർത്തനക്രമ ഏജന്റുകൾ" എന്നും വിളിക്കുന്നു.
ഓർക്കസ്ട്രേറ്റർ ഏജന്റുകൾ സ്വാഭാവികഭാഷാ നിർദേശങ്ങൾ ഉപയോഗിച്ച് ജോലിയുടെ ഒഴുക്ക് ചലനാത്മകമായി തീരുമാനിക്കാൻ വലിയ ഭാഷാ മോഡലുകളെ (LLM-കളെ) ആശ്രയിക്കുന്നു. മുൻകൂട്ടി നിർവചിച്ച യുക്തി അപര്യാപ്തമോ അസാധ്യമോ ആയ തുറന്ന സംഭാഷണങ്ങൾക്ക് ഇവ അനുയോജ്യമാണ്.
ഉയർന്ന അപകടസാധ്യതയുള്ള ഉൽപ്പാദന പ്രവർത്തനക്രമങ്ങൾക്ക് കൂടുതൽ റൂട്ടർ അധിഷ്ഠിത സവിശേഷതകൾ ഉപയോഗിക്കാനും വഴക്കമുള്ള പൊതുവായ സംഭാഷണം ആവശ്യമായ പ്രയോഗങ്ങൾക്ക് ഓർക്കസ്ട്രേറ്ററുകൾ മാറ്റിവയ്ക്കാനുമാണ് ഞങ്ങൾ സാധാരണ ശുപാർശ ചെയ്യുന്നത്.
റൂട്ടർ അധിഷ്ഠിത ആർക്കിടെക്ചറുകൾ
റൂട്ടർ ഏജന്റധിഷ്ഠിത സിസ്റ്റങ്ങൾ.
തീരുമാനമെടുക്കൽ പ്രവാഹം കോഡിലൂടെയോ സോഫ്റ്റ്വെയറിലൂടെയോ വ്യക്തമായി നിർവചിക്കുകയും സോഫ്റ്റ്വെയർ ഏത് വഴി സ്വീകരിക്കണമെന്ന് നിർണയിക്കാൻ LLM ഉപയോഗിക്കുകയും ചെയ്യുന്നു.
വ്യക്തവും പ്രവചിക്കാവുന്നതുമായ പാതകളിലൂടെ കൂടുതൽ സ്ഥിരതയുള്ള ഫലങ്ങൾ നൽകുന്നതിനാൽ ഇവ പരമ്പരാഗത സോഫ്റ്റ്വെയർ സിസ്റ്റങ്ങളോട് കൂടുതൽ സാമ്യമുള്ളവയാണ്.
കർശനമായി നിർവചിക്കാവുന്ന ജോലികൾക്ക് അനുയോജ്യമാണ്.
"റൂട്ടർ സമീപനം" ഉപയോഗിക്കുന്ന ഒരു എയർലൈൻ ബുക്കിങ് ചാറ്റ്ബോട്ട് ഏജന്റിന്റെ ലളിതമായ ഉദാഹരണമാണ് താഴെ. സാധ്യമായ മൂന്ന് ഉദ്ദേശ്യങ്ങളിൽ ചോദ്യം ഏതിനാണെന്ന് തരംതിരിക്കാൻ LLM സഹായിക്കുന്നുണ്ടെങ്കിലും, ആ ഉദ്ദേശ്യത്തെ മാതൃകാപരമായ എഴുത്തുമറുപടിയുമായി ബന്ധിപ്പിക്കുന്നത് ഒടുവിൽ സോഫ്റ്റ്വെയറാണ്. LLM-ന് കർശനമായ നിയന്ത്രണങ്ങളുള്ളതിനാൽ ഉപയോക്താവിന് കൂടുതൽ സ്ഥിരതയുള്ള പെരുമാറ്റം അനുഭവപ്പെടും.
ഓർക്കസ്ട്രേറ്റർ ആർക്കിടെക്ചറുകൾ
റൂട്ടർ സിസ്റ്റങ്ങളിൽനിന്ന് വ്യത്യസ്തമായി, ഓർക്കസ്ട്രേറ്റർ ഏജന്റധിഷ്ഠിത സിസ്റ്റങ്ങൾ.
സോഫ്റ്റ്വെയറിനു പകരം സ്വാഭാവികഭാഷാ നിർദേശങ്ങളിലൂടെ യുക്തിപ്രവാഹങ്ങൾ നിർവചിക്കുന്നു. കുറിപ്പ്: പ്രോഗ്രാമിങ് ഭാഷയുമായി താരതമ്യപ്പെടുത്തുമ്പോൾ സ്വാഭാവികഭാഷ സ്വതവേ അവ്യക്തവും വഴക്കമുള്ളതുമാണ്. പിന്നീട് ചർച്ച ചെയ്യുന്നതുപോലെ, ഇത് ഗുണവും ദോഷവുമാണ്. ഇതിനെ "നിർദേശത്തേക്കാൾ ഉദ്ദേശ്യം" എന്നാണ് ഞങ്ങൾ കാണുന്നത്.
നിർവഹണക്രമവും രീതിയും LLM തീരുമാനിക്കുന്നവിധം ഒന്നിലധികം പ്രോസസ്സിങ് മാർഗങ്ങൾ നൽകാൻ കഴിയും.
സോഫ്റ്റ്വെയറിൽ വ്യക്തമായി നിർവചിക്കാൻ പ്രയാസമുള്ള പുതിയ യുക്തിപാതകൾ ചലനാത്മകമായി സൃഷ്ടിക്കാൻ കഴിയും.
ഈ അവ്യക്തത സ്ഥിരതയില്ലാത്ത ഫലങ്ങളിലേക്ക് നയിച്ചേക്കാം. എന്നാൽ ശരിയായി പ്രവർത്തിക്കുമ്പോൾ അത് "മാന്ത്രികം" പോലെ തോന്നാം.
അതേ ലളിതമായ എയർലൈൻ പ്രശ്നത്തിൽ ഓർക്കസ്ട്രേറ്റർ സമീപനം പ്രയോഗിക്കുന്ന ഉദാഹരണമാണ് താഴെ. ഉചിതമായ മറുപടി സോഫ്റ്റ്വെയർ തീരുമാനിക്കുന്നതിനുപകരം, ആ തീരുമാനം LLM പാളിക്ക് കൈമാറുന്നു. ഇവിടെ, ഒരു "മുഖ്യ" ഓർക്കസ്ട്രേറ്റർ ഏജന്റ് ഉപയോക്തൃചോദ്യം പ്രാഥമികമായി പരിശോധിച്ച് വിമാനം മാറ്റാൻ പ്രത്യേകം രൂപകൽപ്പന ചെയ്ത ഏജന്റിന് കൈമാറുന്ന ബഹു-ഏജന്റ് സിസ്റ്റമാണ് ഉള്ളത്. ആ ഏജന്റാണ് ഒടുവിൽ ഉപയോക്താവിന് മറുപടി നൽകുന്നത്.
ഈ ഉദാഹരണത്തിൽ LLM പാളി വർഗീകരണം, റൂട്ടിങ്, മറുപടി രചന എന്നീ ചുമതലകൾ നിർവഹിക്കുന്നു. റൂട്ടർ ഉദാഹരണത്തിൽ അത് വർഗീകരണം മാത്രമാണ് നിർവഹിച്ചത്. ശേഷിച്ചതെല്ലാം സോഫ്റ്റ്വെയറാണ് കൈകാര്യം ചെയ്തത്.
സാധ്യമാകുന്നിടത്ത് റൂട്ടർ അധിഷ്ഠിത സമീപനം ഉപയോഗിക്കാൻ ഞങ്ങൾ ശുപാർശ ചെയ്യുന്നു. അതിന്റെ ഗുണങ്ങൾ ഇവയാണ്.
വേഗവും കാര്യക്ഷമതയും: ബാഹ്യ API-കളെ ആശ്രയിക്കുന്ന ഓർക്കസ്ട്രേറ്ററുകളെക്കാൾ പ്രാദേശിക കണക്കുകൂട്ടലുകൾക്ക് മികച്ച വേഗമുണ്ട്. "IF/ELSE" യുക്തി 400 ബില്യൺ പരാമീറ്ററുകളുള്ള മോഡലിലൂടെ പ്രോസസ്സ് ചെയ്യാൻ LLM ദാതാവിന് പണം നൽകുന്നതിനേക്കാൾ Python-ൽ പ്രോസസ്സ് ചെയ്യുന്നത് വളരെ ചെലവുകുറഞ്ഞതുമാണ്.
പരിശോധനാക്ഷമതയും പ്രവചനീയതയും: സ്ഥാപിതമായ സോഫ്റ്റ്വെയർ രീതികളിലൂടെ പിഴവുകൾ കണ്ടെത്താനും പരിശോധിക്കാനും പരിപാലിക്കാനും ഗണ്യമായി എളുപ്പമാണ്.
സുതാര്യതയും വിശ്വാസ്യതയും: പെരുമാറ്റത്തിലെ വ്യതിയാനം കുറവായതിനാൽ പ്രശ്നപരിഹാരം ലളിതമാകുന്നു. പ്രയോഗത്തിന്റെ ഒഴുക്കിൽ കൂടുതൽ ഭാഗവും സുതാര്യവും പതിപ്പുകൾ നിയന്ത്രിക്കാവുന്നതുമായ സോഫ്റ്റ്വെയറിൽ രേഖപ്പെടുത്തപ്പെടുന്നു. മറിച്ച്, LLM-ന്റെ ഭാരങ്ങൾ അതാര്യവും വ്യാഖ്യാനിക്കാൻ കഴിയാത്തതുമാണ്.
റൂട്ടർ സമീപനങ്ങളുടെ ദോഷം അവ കർക്കശവും വഴക്കമില്ലാത്തതുമായിരിക്കാമെന്നും കൂടുതൽ തുറന്ന പ്രശ്നങ്ങൾ കൈകാര്യം ചെയ്യാൻ ബുദ്ധിമുട്ടാമെന്നുമാണ്. എപ്പോഴും ഒരേ മറുപടി തന്നെ നൽകുന്ന ചാറ്റ്ബോട്ട് വിരസമോ പുതുമയില്ലാത്തതോ ആണെന്ന് ഉപയോക്താക്കൾ കരുതിയേക്കാം.
ഓർക്കസ്ട്രേറ്റർ രൂപകൽപ്പനകൾക്ക് ശക്തമായ ശേഷികളുണ്ട്.
ആസൂത്രണം: മറുപടികൾ ചലനാത്മകമായി ആസൂത്രണം ചെയ്യാൻ കഴിയും.
ഉപകരണം തിരഞ്ഞെടുക്കൽ/ഏജന്റിന് കൈമാറൽ: അനുയോജ്യമായ ഉപകരണങ്ങൾ തിരഞ്ഞെടുക്കുകയോ ജോലികൾ ഏജന്റുകൾക്ക് കൈമാറുകയോ ചെയ്യുന്നു.
ഫലങ്ങളുടെ ആവർത്തിത സംയോജനം: ഫലങ്ങൾ ആവർത്തിച്ച് പരിശോധിച്ച് സർഗാത്മകമായി പുനഃസംയോജിപ്പിക്കുന്നു.
പൂർത്തിയായെന്ന് നിർണയിക്കൽ: മറുപടി അന്തിമമാക്കാൻ മതിയായ വിവരങ്ങൾ ശേഖരിച്ചിട്ടുണ്ടോ എന്ന് നിർണയിക്കുന്നു.
Pydantic-AI അല്ലെങ്കിൽ OpenAI-യുടെ Agents SDK പോലുള്ള ചട്ടക്കൂടുകൾ ഉപയോഗിച്ചാൽ ഓർക്കസ്ട്രേഷൻ ലളിതമായും വേഗത്തിലും നടപ്പാക്കാം. അതിനാൽ പ്രദർശനങ്ങൾക്കും ആശയസാധൂകരണ മാതൃകകൾക്കും ഇത് മികച്ചതാണ്.
ഈ സമീപനത്തിന്റെ ദോഷങ്ങൾ ഇവയാണ്.
LLM-ന്റെ ആസൂത്രണ ഘട്ടങ്ങളും തുടർന്നുള്ള പ്രവർത്തനങ്ങളും ശരിയോ ഉചിതമോ ആയിരിക്കുമെന്ന് യാതൊരു ഉറപ്പുമില്ല. റൂട്ടർ സിസ്റ്റത്തിനും ഇതേ പ്രശ്നമുണ്ട്. എന്നാൽ കൂടുതൽ നിയന്ത്രിതമായതിനാൽ അതിന്റെ പെരുമാറ്റം കൂടുതൽ പ്രവചനീയമാണ്.
ലളിതവും വ്യക്തമായി നിർവചിച്ചതുമായ ജോലികൾക്ക് ബഹു-ഏജന്റ് സിസ്റ്റത്തിന്റെ പൂർണശേഷി ആവശ്യമായി വരാൻ സാധ്യതയില്ല. ഉദാഹരണത്തിന്, ഞങ്ങളുടെ എയർലൈൻ ഏജന്റ് ഉദാഹരണത്തിൽ, എയർലൈൻ സഹായസിസ്റ്റവുമായി ഇടപഴകുന്ന ഒരാൾക്ക് ആവശ്യമായ ചോദ്യവിഭാഗങ്ങൾ പരിമിതമായിരിക്കും.
കൂടുതൽ യുക്തി LLM-നുള്ളിലായതിനാൽ ദുഷ്ടലക്ഷ്യമുള്ളവർക്ക് സുരക്ഷാ നിയന്ത്രണങ്ങൾ മറികടക്കാനോ സിസ്റ്റത്തെ ചൂഷണം ചെയ്യാനോ വളരെ എളുപ്പമാണ്.
ഇത് തീരുമാനമെടുക്കൽ LLM-നുള്ളിലേക്ക് മറയ്ക്കുന്നതിനാൽ സിസ്റ്റം മനസ്സിലാക്കുന്നത് കൂടുതൽ പ്രയാസമാക്കുന്നു. Langfuse, Braintrust പോലുള്ള നിരീക്ഷണ ഉപകരണങ്ങൾ ഇതിന് ഭാഗികമായി സഹായിച്ചേക്കാം.
വായനക്കാർക്കുള്ള കുറിപ്പ്: മോഡലിന്റെ ശേഷി അതിവേഗം മാറുന്നുണ്ടെങ്കിലും താഴെ പറയുന്ന കാര്യങ്ങൾ സമീപഭാവിയിൽ മാറാൻ സാധ്യതയില്ല.
നിങ്ങളുടെ പ്രശ്നത്തിന്റെ വ്യാപ്തി നിർണയിക്കുക.
നിങ്ങൾ ആഗ്രഹിക്കുന്ന തീരുമാനയുക്തി ഒരു രേഖാചിത്രത്തിൽ എളുപ്പത്തിൽ നിർവചിക്കാനാകുമോ?
നിങ്ങളുടെ പ്രയോഗത്തിലെ പരാജയമോ അപ്രതീക്ഷിത പെരുമാറ്റമോ അംഗീകരിക്കാനാകാത്തതാണോ?
മുകളിലെ ഏതെങ്കിലും ചോദ്യത്തിന് "അതെ" എന്നാണ് ഉത്തരമെങ്കിൽ റൂട്ടർ സവിശേഷതകളായിരിക്കും നല്ലത്.
സാധ്യമാകുന്നിടത്തോളം റൂട്ടർ സമീപനങ്ങൾ ഉപയോഗിക്കാൻ ഞങ്ങൾ ശുപാർശ ചെയ്യുന്നു. പൊതുതത്ത്വമെന്ന നിലയിൽ, സിസ്റ്റത്തിന്റെ ഒരു ഭാഗം കോഡിൽ രേഖപ്പെടുത്താനാകുമെങ്കിൽ അങ്ങനെ തന്നെ ചെയ്യുക. ആവശ്യമില്ലാത്തിടത്ത് LLM-കൾ അമിതമായി ഉപയോഗിക്കരുത്.
അവയുടെ പരിധിയിലെത്തുമ്പോൾ, ഓർക്കസ്ട്രേറ്ററിന്റെ ചില തുറന്ന സവിശേഷതകൾ നിയന്ത്രിതമായ രീതിയിൽ പുനഃസൃഷ്ടിക്കാം. ഉദാഹരണത്തിന്.
ഉപകരണം തിരഞ്ഞെടുക്കൽ/ഏജന്റിന് കൈമാറൽ: സോപാധിക ശാഖകളിലൂടെയോ LLM വർഗീകരണ സംവിധാനങ്ങളിലൂടെയോ എളുപ്പത്തിൽ നടപ്പാക്കാം.
പൂർത്തിയായെന്ന് നിർണയിക്കൽ: മറുപടി ഉപയോക്താവിന് നൽകുന്നതിനുമുമ്പ് അത് പൂർണമാണോ എന്ന് ലളിതമായ LLM വർഗീകരണ സംവിധാനങ്ങൾക്ക് പരിശോധിക്കാം.
എന്നാൽ കർക്കശമായ റൂട്ടർ സിസ്റ്റത്തിൽ "ആസൂത്രണവും" "ഫലങ്ങളുടെ ആവർത്തിത സംയോജനവും" കൈവരിക്കാൻ കൂടുതൽ പ്രയാസമാണെന്നതിൽ സംശയമില്ല. അതിനാൽ ഒരു ജോലിക്ക് ഇവ ആവശ്യമാണെന്ന് LLM വർഗീകരണ സംവിധാനമോ മറ്റേതെങ്കിലും യുക്തിയോ നിർണയിക്കുമ്പോൾ, നിങ്ങളുടെ സിസ്റ്റത്തിൽ നിയന്ത്രണങ്ങൾ കുറഞ്ഞ ഒരു ഓർക്കസ്ട്രേറ്റർ ശാഖ സൃഷ്ടിക്കാൻ ഞങ്ങൾ നിർദേശിക്കുന്നു.
റൂട്ടർ, ഓർക്കസ്ട്രേറ്റർ ആർക്കിടെക്ചറുകൾക്കിടയിലെ തിരഞ്ഞെടുപ്പ് നിങ്ങളുടെ പ്രയോഗത്തിന്റെ വ്യക്തത, സങ്കീർണത, ആശയവിനിമയരീതി എന്നിവയെ പ്രതിഫലിപ്പിക്കണം. വ്യക്തമായി നിർവചിച്ച ജോലികൾക്ക് റൂട്ടർ അധിഷ്ഠിത സമീപനങ്ങൾ നിലവിൽ വിശ്വാസ്യതയും കാര്യക്ഷമതയും പരിശോധനയുടെ എളുപ്പവും നൽകുന്നു. വിശാലവും സംഭാഷണാധിഷ്ഠിതവുമായ ഇടപെടലുകൾക്ക് ഓർക്കസ്ട്രേറ്ററുകൾ കൂടുതൽ വഴക്കം നൽകുന്നു.
LLM-കൾ പുരോഗമിച്ചുകൊണ്ടിരിക്കുമ്പോൾ ഈ സമീപനങ്ങൾ തമ്മിലുള്ള സന്തുലനം മാറിയേക്കാം. ഉൽപ്പാദന ജോലികൾക്ക് റൂട്ടർ അധിഷ്ഠിതമോ സങ്കരമോ ആയ ആർക്കിടെക്ചറുകളാണ് ഞങ്ങൾ തിരഞ്ഞെടുക്കുന്നത്. ചലനാത്മകവും മനുഷ്യസമാനവുമായ ആശയവിനിമയം ആവശ്യമായ തുറന്ന പ്രശ്നങ്ങൾക്കായി ഓർക്കസ്ട്രേറ്ററുകൾ മാറ്റിവയ്ക്കുന്നു.