നിങ്ങളുടെ ഏജന്റ് ഡെമോ പ്രവർത്തിക്കുന്നു. അതാണ് കെണി.
ഞാൻ കമ്പനികൾക്കായി AI ഏജന്റുകൾ നിർമ്മിക്കുന്നു. ഞാൻ പലപ്പോഴും ഒരേ രീതി ആവർത്തിക്കുന്നത് കാണാറുണ്ട്. ഒരു ഡെമോയിൽ മോഡൽ കൃത്യമായി പ്രവർത്തിക്കുന്നു. നിങ്ങൾ ഉൽപ്പന്നം പുറത്തിറക്കുന്നു. എന്നാൽ പ്രൊഡക്ഷനിൽ മൂന്ന് തവണകളിൽ ഒന്ന് അത് പരാജയപ്പെടുന്നു. എന്തുകൊണ്ടാണെന്ന് ആർക്കും അറിയില്ല.
ഒരു ഡെമോയും പ്രൊഡക്ഷനും തമ്മിലുള്ള വ്യത്യാസം ഗണിതശാസ്ത്രമാണ്. ആ ഗണിതം മനസ്സിലാക്കിയാൽ, നിങ്ങൾ വ്യത്യസ്തമായ രീതിയിൽ നിർമ്മാണം നടത്തും.
നിങ്ങളുടെ ഏജന്റിലെ ഓരോ ഘട്ടവും 95% വിശ്വസനീയമാണെങ്കിൽ അത് കേൾക്കാൻ നല്ലതാണ്. എന്നാൽ ഏജന്റുകൾ ഘട്ടങ്ങളുടെ ഒരു ശൃംഖലയാണ് (chains of steps) ഉപയോഗിക്കുന്നത്. നിങ്ങൾ പത്ത് ഘട്ടങ്ങൾ ഒരുമിച്ച് ചേർത്താൽ, നിങ്ങളുടെ വിജയശതമാനം 60% ആയി കുറയും. നിങ്ങൾ ഇരുപത് ഘട്ടങ്ങൾ ഉപയോഗിച്ചാൽ, വിജയശതമാനം 36% ആയി താഴും.
യഥാർത്ഥ പ്രവർത്തനങ്ങളിൽ, ഘട്ടങ്ങളിൽ പലപ്പോഴും 10% മുതൽ 20% വരെ പിശക് നിരക്ക് (error rates) ഉണ്ടാകാറുണ്ട്. ഒരു ഏജന്റിന് 85% വിശ്വസനീയതയുള്ള എട്ട് ഘട്ടങ്ങൾ ഉണ്ടെങ്കിൽ, അത് 75% സമയത്തും പരാജയപ്പെടുന്നു.
മോഡലല്ല പ്രശ്നം. സങ്കീർണ്ണമാകുന്ന പ്രോബബിലിറ്റിയാണ് (Compounding probability) പ്രശ്നം.
ഒരു ഡെമോ കാണിക്കുന്നത് ഒരു സിംഗിൾ ഹാപ്പി പാത്ത് (happy path) മാത്രമാണ്. അത് വൃത്തിയുള്ള ഇൻപുട്ടുകളും ചെറിയ ശൃംഖലകളും ഉപയോഗിക്കുന്നു. എന്നാൽ പ്രൊഡക്ഷൻ നൂറുകണക്കിന് ഉപയോക്താക്കളിൽ നിന്നുള്ള ക്രമരഹിതമായ ഡാറ്റയാണ് ഉപയോഗിക്കുന്നത്. ഇതിൽ മറഞ്ഞിരിക്കുന്ന ഘട്ടങ്ങളുള്ള നീളമേറിയ ശൃംഖലകൾ ഉൾപ്പെടുന്നു.
ഏജന്റുകളിലെ പരാജയം ഒരു ക്രാഷ് (crash) പോലെ ആയിരിക്കില്ല കാണപ്പെടുന്നത്. അത് ഒരു നിശബ്ദമായ പിശക് പോലെയാണ്.
മൂന്നാമത്തെ ഘട്ടം ഒരു ഫീൽഡ് തെറ്റായി വായിക്കുന്നു. ഔട്ട്പുട്ട് ഇപ്പോഴും ശരിയായ JSON പോലെ തോന്നും. നാലാമത്തെ ഘട്ടം ആ തെറ്റായ ഡാറ്റ ഉപയോഗിച്ച് യുക്തിപരമായ തീരുമാനങ്ങൾ എടുക്കുന്നു. 5 മുതൽ 8 വരെയുള്ള ഘട്ടങ്ങൾ ആ തെറ്റിന്മേൽ നിർമ്മിക്കപ്പെടുന്നു. അന്തിമ ഉത്തരം തെറ്റായിരിക്കും, പക്ഷേ അത് ശരിയാണെന്ന് തോന്നും. എവിടെയാണ് തെറ്റ് സംഭവിച്ചതെന്ന് കാണിക്കാൻ ഒരു എറർ ലോഗും (error log) ഉണ്ടാകില്ല.
മോഡൽ 'ഹാലൂസിനേറ്റ്' (hallucinated) ചെയ്തു എന്ന് പറയുന്നത് നിർത്തുക. മോഡൽ ലഭിച്ച തെറ്റായ ഡാറ്റ കൈമാറുകയായിരുന്നു ചെയ്തത്. മൂന്നാമത്തെ ഘട്ടത്തിലെ പിശക് കണ്ടെത്താൻ നിങ്ങളുടെ സിസ്റ്റത്തിൽ ഒരു ചെക്ക്പോയിന്റ് (checkpoint) ഇല്ലായിരുന്നു.
ഏജന്റിനെ ഒരു പ്രോംപ്റ്റ് ആയി കാണുന്നത് നിർത്തുക. അതിനെ ഒരു സിസ്റ്റമായി കാണാൻ തുടങ്ങുക.
വിശ്വസനീയമായ ഏജന്റുകളെ നിർമ്മിക്കാൻ ഈ നിയമങ്ങൾ പാലിക്കുക:
ഏജന്റിന് പുറത്ത് സ്റ്റേറ്റ് (state) സേവ് ചെയ്യുക. സ്റ്റേറ്റ് സംഭാഷണത്തിലല്ല, ഒരു ഡാറ്റാബേസിൽ സൂക്ഷിക്കുക. ഒരു പ്രക്രിയ ആറാം ഘട്ടത്തിൽ പരാജയപ്പെട്ടാൽ, നിങ്ങൾക്ക് ആറാം ഘട്ടത്തിൽ നിന്ന് തന്നെ തുടരാം. മുഴുവൻ ശൃംഖലയും വീണ്ടും തുടങ്ങേണ്ടതില്ല.
അതിരുകളിൽ (boundaries) പരിശോധന നടത്തുക. ഓരോ ഇൻപുട്ടും ഔട്ട്പുട്ടും ഒരു സ്കീമയുമായി (schema) ഒത്തുനോക്കുക. പിശക് സംഭവിക്കുന്ന ഘട്ടത്തിൽ തന്നെ അത് കണ്ടെത്തുക. ഇത് ഒരു നിഗൂഢതയെ തിരുത്താൻ കഴിയുന്ന ഒരു പിശക്കായി മാറ്റുന്നു.
സൈഡ് ഇഫക്റ്റുകൾ (side effects) ഐഡെംപോട്ടന്റ് (idempotent) ആക്കുക. ഘട്ടങ്ങൾ പരാജയപ്പെടുമ്പോൾ നിങ്ങൾ അവ വീണ്ടും ശ്രമിക്കേണ്ടതുണ്ട് (retry). ഒരു ഘട്ടം ഇമെയിൽ അയക്കുകയോ കാർഡ് ചാർജ് ചെയ്യുകയോ ചെയ്യുന്നുണ്ടെങ്കിൽ, ഒരു ഐഡെംപോട്ടൻസി കീ (idempotency key) ഉപയോഗിക്കുക. ഇത് റീട്രൈ ചെയ്യുമ്പോൾ ഒരേ പ്രവർത്തനം ആവർത്തിക്കുന്നത് തടയുന്നു.
നിങ്ങളുടെ CI-യിൽ ഇവാൽസ് (evals) ഉപയോഗിക്കുക. ഓരോ മാറ്റത്തിലും ഏജന്റിന്റെ പെരുമാറ്റം മാറുന്നു. ഒരു പ്രോംപ്റ്റ് മാറ്റം ഒരു പ്രശ്നം പരിഹരിച്ചേക്കാം, എന്നാൽ മറ്റ് അഞ്ച് പ്രശ്നങ്ങൾ ഉണ്ടാക്കിയേക്കാം. ഇത്തരം മാറ്റങ്ങൾ (regressions) സ്വയമേവ കണ്ടെത്താൻ ഒരു ടെസ്റ്റ് സെറ്റ് ഉപയോഗിക്കുക.
ഒരു ഡെമോയിൽ നിന്ന് യഥാർത്ഥ ഉൽപ്പന്നത്തിലേക്കുള്ള മാറ്റം എൻജിനീയറിംഗിനെക്കുറിച്ചാണ്. അത് എറർ ഹാൻഡ്ലിംഗ് (error handling), സ്റ്റേറ്റ് മാനേജ്മെന്റ് (state management), ഒബ്സർവബിലിറ്റി (observability) എന്നിവയെക്കുറിച്ചാണ്. അത് മികച്ച പ്രോംപ്റ്റുകളെക്കുറിച്ചല്ല.
പ്രൊഡക്ഷനിൽ നിങ്ങളുടെ ഏജന്റ് പരാജയപ്പെട്ടാൽ, വലിയൊരു മോഡലിനായി തിരയരുത്. ശൃംഖല എവിടെയാണ് തെറ്റായ ദിശയിലേക്ക് പോയതെന്ന് നോക്കുക. അവിടെ പിശക് കണ്ടെത്താൻ നിങ്ങളുടെ സിസ്റ്റത്തിന് കഴിയാത്തത് എന്തുകൊണ്ടാണെന്ന് ചോദിക്കുക.
Source: https://dev.to/sagar_jain4010/your-agent-demo-works-thats-the-trap-4joc
Optional learning community: https://t.me/GyaanSetuAi