ഒരു ലാംഗ്വേജ് മോഡൽ അധിഷ്ഠിത ട്രേഡിംഗ് ബോട്ടിന് ഓരോ അഞ്ചു ദിവസത്തിലും അതിന്റെ സ്വന്തം പ്രോംപ്റ്റ് (prompt) മാറ്റിയെഴുതാൻ അനുവദിച്ചാൽ, അതിന്റെ ഷാർപ്പ് റേഷ്യോ (Sharpe ratio) 2.94-ൽ നിന്ന് 4.00 ആയി ഉയരുമെന്നും 50 ദിവസത്തെ പരീക്ഷണത്തിൽ 50 ബേസിസ് പോയിന്റ് (basis-point) അധിക നേട്ടം ഉണ്ടാകുമെന്നും KAIST ഗവേഷകർ കാണിച്ചുതന്നു. എല്ലാ കണക്കുകൂട്ടലുകളും വിവരണാത്മകമായ എഴുത്തിൽ (prose) നിന്ന് പ്രവർത്തിപ്പിക്കാൻ കഴിയുന്ന പൈത്തൺ (Python) കോഡിലേക്ക് മാറ്റാൻ ബോട്ടിനെ നിർബന്ധിച്ചതാണ് ഈ നേട്ടത്തിന് കാരണം.
എന്തുകൊണ്ടാണ് സ്റ്റാറ്റിക് പ്രോംപ്റ്റുകൾ പരാജയപ്പെടുന്നത്
കോഡ് പ്രവർത്തിപ്പിക്കുന്ന മിക്ക LLM ഏജന്റുകളും ഒരു നിശ്ചിത സിസ്റ്റം പ്രോംപ്റ്റോടെയാണ് (system prompt) തുടങ്ങുന്നത് - അതായത് മോഡൽ എങ്ങനെ പെരുമാറണമെന്ന് നിർദ്ദേശിക്കുന്ന ഒരു ടെക്സ്റ്റ് ബ്ലോക്ക്. പലപ്പോഴും ഈ പ്രോംപ്റ്റുകൾ കോഡ് ടൂളിനെ ഒരു അധിക സൗകര്യം മാത്രമായാണ് കാണുന്നത്. മോഡൽ വോളറ്റിലിറ്റിയെക്കുറിച്ചോ (volatility) പ്രതീക്ഷിക്കുന്ന ലാഭത്തെക്കുറിച്ചോ (expected returns) "ചിന്തിച്ചേക്കാം", എന്നാൽ അത് സംഖ്യകൾ വെറും ടെക്സ്റ്റ് രൂപത്തിൽ എഴുതുകയും പിന്നീട് അവ്യക്തമായ ഊഹങ്ങളുടെ അടിസ്ഥാനത്തിൽ എത്ര നിക്ഷേപിക്കണമെന്ന് തീരുമാനിക്കുകയും ചെയ്യുന്നു. ഇതിന്റെ ഫലമായി ഒരു വിവേചനം സംഭവിക്കുന്നു: മോഡലിന് കൃത്യമായ കോഡ് നിർമ്മിക്കാൻ കഴിയുമെങ്കിലും, അന്തിമ ട്രേഡ് അളവ് (trade size) ആ കോഡിന് പുറത്താണ് തീരുമാനിക്കുന്നത്, ഇത് തീരുമാനങ്ങളെ തെറ്റായ വിവരങ്ങളിലേക്ക് (hallucination) നയിക്കാൻ സാധ്യതയുണ്ട്.
EvolveTrade രീതി
KAIST ടീം സ്റ്റാറ്റിക് പ്രോംപ്റ്റിന് പകരം ഒരു മെറ്റാ-ഏജന്റിനെ (meta-agent) ഉപയോഗിച്ചു. ഈ ഏജന്റ് ഓരോ അഞ്ചു ദിവസത്തെയും ബോട്ടിന്റെ പ്രകടനം വിലയിരുത്തുന്നു. ഓരോ പരിശോധനയ്ക്ക് ശേഷവും മെറ്റാ-ഏജന്റ് സിസ്റ്റം പ്രോംപ്റ്റ് മാറ്റിയെഴുതുകയും, ലാംഗ്വേജ് മോഡലും അതിന്റെ കോഡ് ഇന്റർപ്രെറ്ററും (code interpreter) തമ്മിലുള്ള ബന്ധം കൂടുതൽ ശക്തമാക്കുകയും ചെയ്യുന്നു. പുതിയ പ്രോംപ്റ്റ് മൂന്ന് വ്യക്തമായ ഘട്ടങ്ങൾ നിർദ്ദേശിക്കുന്നു:
- പൈത്തൺ ഉപയോഗിച്ച് ഓരോ അസറ്റിനും (asset) ആവശ്യമായ മെട്രിക്സുകളുടെ ഒരു പട്ടിക തയ്യാറാക്കുക.
- അസറ്റുകളെ സ്കോർ ചെയ്യാൻ വ്യക്തമായ ഗണിത സമവാക്യങ്ങൾ (mathematical formulas) ഉപയോഗിക്കുക.
- മാർക്ക്ഡൗൺ ടെക്സ്റ്റിന് പകരം കോഡിനുള്ളിൽ തന്നെ ടാർഗെറ്റ് പോർട്ട്ഫോളിയോ വെയ്റ്റുകൾ (portfolio weights) കണ്ടെത്തുക.
പ്രായോഗികമായി നോക്കിയാൽ, മെച്ചപ്പെടുത്തിയ ബോട്ട് ഓരോ ട്രേഡിംഗ് സൈക്കിളിലും 11 തവണ പൈത്തൺ ടൂൾ ഉപയോഗിച്ചു - മെട്രിക്സുകൾ കണക്കാക്കാനും, റിസ്ക് പരിധികൾ പരിശോധിക്കാനും, വെയ്റ്റുകൾ ക്രമീകരിക്കാനും ഇത് സഹായിച്ചു. എന്നാൽ അടിസ്ഥാന ഏജന്റ് (baseline agent) ഒരു തവണ മാത്രമേ ടൂൾ ഉപയോഗിച്ചിരുന്നുള്ളൂ, ബാക്കിയുള്ള കാര്യങ്ങൾ ടെക്സ്റ്റ് അടിസ്ഥാനമാക്കിയുള്ള ഊഹങ്ങളിൽ (textual heuristics) ആശ്രയിച്ചു.
പ്രധാനപ്പെട്ട കണക്കുകൾ
ഒരു സാധാരണ അസറ്റ് യൂണിവേഴ്സിൽ (asset universe) നടത്തിയ 50 ദിവസത്തെ ബാക്ക്-ടെസ്റ്റിനിടെ (back-test), മെച്ചപ്പെടുത്തിയ ഏജന്റ് താഴെ പറയുന്ന ഫലങ്ങൾ നേടി:
- ഷാർപ്പ് റേഷ്യോ (Sharpe ratio): 4.00 (സ്റ്റാറ്റിക് ഏജന്റിന്റെ 2.94-നെ അപേക്ഷിച്ച്).
- ക്യുമുലേറ്റീവ് റിട്ടേൺ (Cumulative return): 10.56% (സ്റ്റാറ്റിക് ഏജന്റിന്റെ 8.88%-നെ അപേക്ഷിച്ച്).
പ്രവർത്തനങ്ങളെ കൃത്യമായ ഗണിതശാസ്ത്രവുമായി (deterministic math) ബന്ധിപ്പിച്ചത് മൂലമാണ് ഈ 50 ബേസിസ് പോയിന്റ് അധിക നേട്ടം ഉണ്ടായത്. മോഡലിന്റെ തീരുമാനങ്ങൾ പൂർണ്ണമായും നിരീക്ഷിക്കാനും ആവർത്തിക്കാനും കഴിയുന്ന രീതിയിൽ മാറ്റിയതിലൂടെ, LLM അധിഷ്ഠിത ട്രേഡിംഗ് തന്ത്രങ്ങളുടെ പ്രകടനം കുറയ്ക്കുന്ന "ഊഹപ്രവർത്തനങ്ങൾ" (guesswork) ഗവേഷകർ ഒഴിവാക്കി.
ആര് ജയിക്കുന്നു, ആര് തോൽക്കുന്നു
ഫിനാൻഷ്യൽ ബോട്ടുകൾ നിർമ്മിക്കുന്ന ഡെവലപ്പർമാർക്ക് ഇതിൽ നിന്നുള്ള പാഠം വ്യക്തമാണ്: ഏജന്റിന് ഒരു റൺടൈം എൻവയോൺമെന്റിൽ (runtime environment) പ്രവേശനം ഉണ്ടെങ്കിൽ, ഓരോ പ്രായോഗിക ഉൾക്കാഴ്ചയും (actionable insight) കോഡ് രൂപത്തിൽ പ്രകടിപ്പിക്കാൻ പ്രോംപ്റ്റ് നിർബന്ധിക്കണം. ഈ തത്വം അവഗണിക്കുന്നത് മോഡൽ ടൂൾ ഔട്ട്പുട്ടുകളെ വെറും പശ്ചാത്തല വിവരങ്ങളായി മാത്രം കാണാൻ ഇടയാക്കും, ഇത് പ്രകടനം കുറയ്ക്കാനും റിസ്ക് വർദ്ധിപ്പിക്കാനും കാരണമാകും.
പരിമിതികളും എതിർവാദങ്ങളും
ഇനി ശ്രദ്ധിക്കേണ്ടവ
ചുരുക്കത്തിൽ: ഒരു LLM അതിന്റെ സ്വന്തം നിർദ്ദേശങ്ങൾ മാറ്റിയെഴുതാൻ അനുവദിക്കുന്നത് ഓരോ ട്രേഡ് തീരുമാനത്തെയും പരിശോധിക്കാവുന്ന കോഡിലേക്ക് മാറ്റുന്നു. ഇത് അവ്യക്തമായ ടെക്സ്റ്റ് അധിഷ്ഠിത ഏജന്റിനെ അച്ചടക്കമുള്ളതും ഉയർന്ന ലാഭം നൽകുന്നതുമായ ഒരു എൻജിനായി മാറ്റുന്നു. പ്രോംപ്റ്റ്-ടൂൾ കരാർ (prompt-tool contract) അവഗണിക്കുന്ന ഡെവലപ്പർമാർക്ക് വലിയ സാമ്പത്തിക നഷ്ടം സംഭവിക്കാൻ സാധ്യതയുണ്ട്.
