പുതിയ മോഡൽ ബെഞ്ച്മാർക്കുകൾ നടത്തുന്നത് നിർത്തിയിട്ട്, നിങ്ങളുടെ ഏജന്റ് ഒരു സബ്സ്ക്രിപ്ഷൻ റദ്ദാക്കാൻ ശ്രമിക്കുന്നത് ശ്രദ്ധിച്ചു തുടങ്ങുക. ഈ രണ്ട് പ്രവർത്തനങ്ങൾ തമ്മിലുള്ള വ്യത്യാസമാണ് പ്രൊഡക്ഷൻ സിസ്റ്റങ്ങൾ പരാജയപ്പെടുന്നത്. ഒരു സിംഗിൾ-ടേൺ ടെസ്റ്റിന് (single-turn test) ഒരു മറുപടി കേൾക്കാൻ സുഖകരമാണോ എന്ന് പറയാൻ കഴിയും. എന്നാൽ ഏജന്റ് തെറ്റായ ഉപഭോക്താവിന് റീഫണ്ട് നൽകിയോ, ഒരു കലണ്ടർ API-ൽ പതിനാല് തവണ ലൂപ്പ് ചെയ്തോ, അല്ലെങ്കിൽ ഫ്രോഡ് ചെക്ക് (fraud check) പൂർണ്ണമായും ഒഴിവാക്കാൻ തീരുമാനിച്ചോ എന്ന് അതിന് പറയാൻ കഴിയില്ല. ഒരു ഏജന്റ് ഉൽപ്പാദിപ്പിക്കുന്നതിൽ ഏറ്റവും അപകടകരമല്ലാത്തത് ടെക്സ്റ്റ് ആണ്. യഥാർത്ഥ അപകടങ്ങൾ ഒളിഞ്ഞിരിക്കുന്നത് അത് ഉപയോഗിക്കുന്ന ടൂളുകളിലും, അത് മാറ്റം വരുത്തുന്ന ഡാറ്റയിലും, സഹായം ചോദിക്കേണ്ട സമയത്ത് അത് സഹായം ചോദിക്കാതെ മുന്നോട്ട് പോകുന്നതിലുമാണ്.
പ്രൊഡക്ഷനിൽ ടെക്സ്റ്റ് ബെഞ്ച്മാർക്കുകൾ പരാജയപ്പെടുന്നത് എന്തുകൊണ്ട്?
സ്റ്റാൻഡേർഡ് ബെഞ്ച്മാർക്കുകളിലെ ഉയർന്ന സ്കോറുകൾ തെറ്റായ ഒരു ആശ്വാസമായി മാറിയിരിക്കുന്നു. മനോഹരമായ വരികൾ എഴുതുന്ന ഒരു ഏജന്റ് ഇപ്പോഴും പ്രവർത്തനപരമായ അപകടസാധ്യതയുള്ളതാകാം. നിങ്ങളുടെ സിസ്റ്റം അപ്പോയിന്റ്മെന്റുകൾ ബുക്ക് ചെയ്യുകയോ, ഡാറ്റാബേസ് റെക്കോർഡുകൾ എഡിറ്റ് ചെയ്യുകയോ, സപ്പോർട്ട് ടിക്കറ്റുകൾ ഫയൽ ചെയ്യുകയോ ചെയ്യുമ്പോൾ, ജനറേറ്റ് ചെയ്യപ്പെട്ട ടെക്സ്റ്റ് ആ വർക്ക്ഫ്ലോയുടെ പുറമെ കാണുന്ന ഭാഗം മാത്രമാണ്. അതിനു താഴെ, ഏത് എൻഡ്പോയിന്റ് (endpoint) ഉപയോഗിക്കണം, എന്ത് പേലോഡ് (payload) അയക്കണം, എപ്പോൾ നിർത്തണം എന്നിവയെക്കുറിച്ച് ഏജന്റ് വ്യക്തമായ തീരുമാനങ്ങൾ എടുക്കുന്നുണ്ട്. റീഡിംഗ്-കോംപ്രിഹെൻഷൻ (reading-comprehension) ലീഡർബോർഡിൽ ഒന്നാമതെത്താൻ ഇതിന് സാധിച്ചേക്കാം, എന്നാൽ റിസോഴ്സുകൾ ഡബിൾ ബുക്ക് ചെയ്തുകൊണ്ടോ, തെറ്റായ റോ (row) മാറ്റം വരുത്തിയുകൊണ്ടോ, സെൻസിറ്റീവ് ആയ വിവരങ്ങൾ ലോഗ് ഫയലുകളിലേക്ക് ചോർത്തിക്കൊണ്ടോ അത് നിങ്ങൾക്ക് പണനഷ്ടം വരുത്തിയേക്കാം. നിങ്ങൾ ഔട്ട്പുട്ടിന്റെ മിനുക്കുപണികൾ മാത്രമല്ല, ജോലിയുടെ മെക്കാനിക്സ് കൂടി പരിശോധിക്കേണ്ടതുണ്ട്. ഒരു ഏജന്റിന് ഓഫ്ലൈൻ QA ടെസ്റ്റിൽ നല്ല സ്കോർ നേടാനും എന്നാൽ ലൂപ്പുകളിലൂടെയോ ടൂളുകൾ തെറ്റായി ഉപയോഗിച്ചോ നിങ്ങളുടെ വർക്ക്ഫ്ലോ പരാജയപ്പെടുത്താനും കഴിയുന്നുണ്ടെങ്കിൽ, നിങ്ങളുടെ മൂല്യനിർണ്ണയം തെറ്റായ സിഗ്നലുകളെയാണ് നോക്കുന്നത്.
അഞ്ച് ഡിപെൻഡൻസികൾ (Dependencies) മാപ്പ് ചെയ്യുക
Van Data Team-ലെ ടീം ഓരോ മൂല്യനിർണ്ണയവും ആരംഭിക്കുന്നത് അഞ്ച് പ്രത്യേക കൺട്രോൾ പോയിന്റുകൾ മാപ്പ് ചെയ്തുകൊണ്ടാണ്. ഇത് ചോദ്യത്തെ പാടെ മാറ്റുന്നു. ഒരു മോഡൽ മറ്റൊന്നിനേക്കാൾ ബുദ്ധിയുള്ളതാണോ എന്ന് നിങ്ങൾ ചോദിക്കുന്നത് നിർത്തുന്നു. പകരം, നിങ്ങളുടെ യഥാർത്ഥ നിയന്ത്രണങ്ങൾക്കുള്ളിൽ (constraints) ഒരു പ്രൊഡക്ഷൻ ടാസ്ക് ഏജന്റിന് യഥാർത്ഥത്തിൽ പൂർത്തിയാക്കാൻ കഴിയുമോ എന്നാണ് നിങ്ങൾ ചോദിച്ചു തുടങ്ങുന്നത്.
ബിസിനസ് ഔട്ട്കമുകൾ (Business outcomes). ഡോളറുകളുടെയും ഉപഭോക്തൃ സ്വാധീനത്തിന്റെയും അടിസ്ഥാനത്തിൽ "പൂർത്തിയായി" എന്നാൽ എന്താണെന്ന് നിർവചിക്കുക. ഏജന്റ് ഒരു സംഗ്രഹം (summary) നൽകി എന്നതുകൊണ്ട് മാത്രം ഒരു ടാസ്ക് പൂർത്തിയായി എന്ന് പറയാനാവില്ല. ഇൻവെന്ററി റെക്കോർഡ് കൃത്യമാകുമ്പോഴും, അപ്പോയിന്റ്മെന്റ് സ്ഥിരീകരിക്കപ്പെടുമ്പോഴും, ഉപഭോക്താവിന് സാധുവായ ഒരു ട്രാക്കിംഗ് നമ്പർ ലഭിക്കുമ്പോഴും മാത്രമാണ് അത് പൂർത്തിയായി എന്ന് പറയുന്നത്.
മാറ്റാൻ കഴിയുന്ന അവസ്ഥ (Mutable state). ഏജന്റിന് എന്തൊക്കെ മാറ്റാൻ അനുവാദമുണ്ടെന്ന് കൃത്യമായി അറിയുക. ഏത് ടേബിളുകൾ, ഏത് സ്റ്റാറ്റസുകൾ, ഏത് അക്കൗണ്ട് ഫ്ലാഗുകൾ? ഏജന്റിന് റീഫണ്ട് നൽകാനോ, ജോലികൾ പുനഃക്രമീകരിക്കാനോ, ബില്ലിംഗ് വിലാസങ്ങൾ പുതുക്കാനോ കഴിയുമെങ്കിൽ, അത് സ്പർശിക്കുന്ന ഓരോ ഫീൽഡും നിങ്ങൾ ലിസ്റ്റ് ചെയ്യേണ്ടതുണ്ട്.
ടൂൾ പെർമിഷനുകൾ (Tool permissions). ഏത് API എൻഡ്പോയിന്റുകളും ഫംഗ്ഷനുകളും പരിധിയിൽ (scope) വരുന്നതെന്ന് വ്യക്തമാക്കുക. സെർച്ച് ടൂൾ, റൈറ്റ് ടൂൾ (write tool), നോട്ടിഫിക്കേഷൻ ടൂൾ എന്നിവ ഉപയോഗിക്കാൻ അനുവാദമുള്ള ഒരു ഏജന്റിന് അതിരുകൾ വ്യക്തമല്ലെങ്കിൽ അവ തമ്മിൽ മാറിപ്പോകാൻ സാധ്യതയുണ്ട്. ഓരോ പെർമിഷനെയും ഒരു പ്രത്യേക പ്രവർത്തന ആവശ്യവുമായി ബന്ധിപ്പിക്കുക.
പരാജയ വീണ്ടെടുക്കൽ (Failure recovery). കലണ്ടർ API ടൈം ഔട്ട് ആകുമ്പോഴോ, 500 എറർ കാണിക്കുമ്പോഴോ, അല്ലെങ്കിൽ തെറ്റായ JSON നൽകുന്നതിനോ എന്താണ് സംഭവിക്കേണ്ടതെന്ന് തീരുമാനിക്കുക. ഏജന്റ് പരിഭ്രമിക്കുകയോ, വിജയിച്ചുവെന്ന് തെറ്റായ സന്ദേശം നൽകുകയോ, അല്ലെങ്കിൽ അനന്തമായി ശ്രമിച്ചുകൊണ്ടിരിക്കുകയോ ചെയ്യരുത്. അതിന് വ്യക്തമായ ഒരു ഫോൾബാക്ക് പാത്ത് (fallback path) ആവശ്യമാണ്.
മനുഷ്യ പരിശോധനകൾ (Human review gates). ഏജന്റ് മുന്നോട്ട് പോകുന്നതിന് മുമ്പ് ഒരു വ്യക്തി അംഗീകാരം നൽകേണ്ട നിമിഷങ്ങൾ തിരിച്ചറിയുക. ഇത് ഓട്ടോമേഷനിലെ ഒരു ബലഹീനതയല്ല. ഉയർന്ന സ്വാധീനമുള്ള മാറ്റങ്ങൾക്കുള്ള ഒരു സുരക്ഷാ വാൽവും നിങ്ങളുടെ മാനദണ്ഡങ്ങൾക്കായുള്ള ഗ്രൗണ്ട്-ട്രൂത്ത് ലേബലുകളുടെ (ground-truth labels) സ്രോതസ്സുമാണ് ഇത്.
ഒരു യഥാർത്ഥ മൂല്യനിർണ്ണയ പ്ലാൻ എങ്ങനെയായിരിക്കണം?
ഡിപെൻഡൻസികൾ മാപ്പ് ചെയ്തുകഴിഞ്ഞാൽ, പ്രൊഡക്ഷനിലെ സങ്കീർണ്ണതകളോട് യോജിക്കുന്ന ഒരു മൂല്യനിർണ്ണയ പ്ലാൻ നിങ്ങൾക്ക് ആവശ്യമാണ്. സ്ലൈഡ്-ഡെക്ക് മെട്രിക്സ് (Slide-deck metrics) ഇവിടെ നിങ്ങളെ സഹായിക്കില്ല.
സിന്തറ്റിക് ചോദ്യശേഖരങ്ങളിൽ നിന്നല്ല, മറിച്ച് യഥാർത്ഥ പ്രൊഡക്ഷൻ പരാജയങ്ങളിൽ നിന്ന് ടെസ്റ്റ് സെറ്റുകൾ നിർമ്മിക്കുക. നിങ്ങളുടെ ഏജന്റ് കഴിഞ്ഞ ചൊവ്വാഴ്ച രണ്ട് സമാനമായ SKU-കൾ തമ്മിൽ മാറിപ്പോയി പരാജയപ്പെട്ടുവെങ്കിൽ, ആ കൃത്യമായ പിശക് ഒരു സ്ഥിരമായ ടെസ്റ്റ് കേസ് ആയിരിക്കണം. ഓരോ സംഭവവും നിങ്ങൾക്ക് പുതിയ എന്തെങ്കിലും പഠിപ്പിക്കുമ്പോൾ നിങ്ങളുടെ മൂല്യനിർണ്ണയ സംവിധാനം വളർന്നുകൊണ്ടിരിക്കണം.
പ്രവർത്തനപരമായ രീതിയിൽ വിജയകരമായ പൂർത്തീകരണം നിർവചിക്കുന്ന റൂബ്രിക്സ് (rubrics) എഴുതുക. "സഹായകരമായത്" അല്ലെങ്കിൽ "കൃത്യമായത്" തുടങ്ങിയ അവ്യക്തമായ മാനദണ്ഡങ്ങൾ ഉപയോഗശൂന്യമാണ്. ഒരു റീഫണ്ട് ടാസ്ക് വിജയകരമാകണമെങ്കിൽ യഥാർത്ഥ പേയ്മെന്റ് ഐഡി ഉപയോഗിച്ചിരിക്കണം, തുക അഭ്യർത്ഥനയുമായി പൊരുത്തപ്പെടണം, ഒരു കൺഫർമേഷൻ ഇമെയിൽ ക്യൂ ചെയ്യണം, ട്രാൻസാക്ഷൻ ഐഡി ലോഗ് ചെയ്യണം എന്നിങ്ങനെ വ്യക്തമായ ഒരു റൂബ്രിക് ആവശ്യമാണ്.
ടൂൾ കോളുകൾക്കും റീട്രികൾക്കുമായി (retries) ട്രേസ് സ്പെക്സ് (trace specs) നിർവചിക്കുക. ഏജന്റ് എന്താണ് പ്ലാൻ ചെയ്തത്, യഥാർത്ഥത്തിൽ എന്താണ് വിളിച്ചത്, എത്ര തവണ റീട്രൈ ചെയ്തു, റീട്രൈ സ്ട്രാറ്റജി അനുയോജ്യമായിരുന്നോ എന്നിവയെക്കുറിച്ച് നിങ്ങൾക്ക് നിരീക്ഷണം (observability) ആവശ്യമാണ്. ടൂൾ തലത്തിലുള്ള കൃത്യതയില്ലാത്ത ഒരു ട്രേസ് വെറുമൊരു കഥ മാത്രമാണ്.
എപ്പോഴാണ് ഒരു മനുഷ്യനെ അറിയിക്കേണ്ടത് എന്നതിനെക്കുറിച്ച് പോളിസികൾ നിശ്ചയിക്കുക. ഏജന്റിന് അതിന്റെ പരിധികൾ അറിയണം. ഒരു അഭ്യർത്ഥന നിശ്ചിത തുകയേക്കാൾ കൂടുതലാണെങ്കിലോ, ഒരു VIP അക്കൗണ്ടിനെ സംബന്ധിച്ചാണെങ്കിലോ, അല്ലെങ്കിൽ മുമ്പ് കണ്ടിട്ടില്ലാത്ത ഒരു അവസ്ഥ നേരിടുകയാണെങ്കിലോ, അത് ഊഹിച്ചു പോകുന്നതിന് പകരം വിവരം മേലധികാരികളെ അറിയിക്കണം (escalate).
മോശം മോഡൽ അപ്ഗ്രേഡുകൾ തടയാൻ റിലീസ് ഗേറ്റുകൾ (release gates) ഇൻസ്റ്റാൾ ചെയ്യുക. നിങ്ങളുടെ നിശ്ചിത ഫലങ്ങളിൽ മെച്ചം വരുത്തിയാൽ മാത്രമേ ഒരു പുതിയ മോഡൽ അപ്ഗ്രേഡ് ആയി കണക്കാക്കൂ. അത് ടൂൾ ആർഗ്യുമെന്റുകൾ (tool arguments) കൂടുതൽ തവണ തെറ്റായി നൽകുകയോ (hallucinate), ലേറ്റൻസി (latency) വർദ്ധിപ്പിക്കുകയോ, പുതിയ സുരക്ഷാ ഭീഷണികൾ ഉണ്ടാക്കുകയോ ചെയ്യുന്നുണ്ടെങ്കിൽ, അത് ഉപയോഗത്തിലേക്ക് എത്തിക്കരുത്. ബേസ് മോഡൽ വെണ്ടർ പുതിയ പതിപ്പ് പുറത്തിറക്കുമ്പോഴും പ്രൊഡക്ഷൻ സ്റ്റേബിൾ ആയി നിലനിർത്താൻ ഈ ഗേറ്റ് സഹായിക്കുന്നു.
റൺടൈം ഗ്രേഡിംഗ് (Runtime Grading): ഏജന്റ് പ്രവർത്തിക്കുന്നത് നിരീക്ഷിക്കുക
ഓഫ്ലൈൻ ടെസ്റ്റുകൾക്ക് അപ്പുറം റൺടൈം ഗ്രേഡിംഗിലേക്ക് (runtime grading) മാറാൻ ആന്ത്രോപിക് (Anthropic) വ്യവസായത്തെ പ്രേരിപ്പിച്ചുകൊണ്ടിരിക്കുകയാണ്. ഒരു കാര്യം സംഭവിച്ചു കഴിഞ്ഞു അതിന്റെ ട്രാൻസ്ക്രിപ്റ്റ് പരിശോധിക്കുന്നതിന് പകരം, ഒരു ടാസ്ക് നടന്നുകൊണ്ടിരിക്കുമ്പോൾ തന്നെ ഏജന്റിന്റെ പ്രവർത്തനം വിലയിരുത്താൻ റൺടൈം ഗ്രേഡിംഗ് ഒരു സിസ്റ്റത്തെ അനുവദിക്കുന്നു. ഇത് പിശകുകൾ വലിയ പ്രശ്നങ്ങളായി മാറുന്നതിന് മുമ്പ് തന്നെ കണ്ടെത്താൻ അവസരം നൽകുന്നു.
ഒരു ഗ്രേഡർ ചേർക്കുന്നത് ടോക്കണുകളും ലേറ്റൻസിയും വർദ്ധിപ്പിക്കും. അതിനാൽ ഓരോ ചെറിയ ഘട്ടവും ഗ്രേഡ് ചെയ്യാൻ നിങ്ങൾക്ക് കഴിയില്ല. ഓരോ ഗ്രേഡറും എവിടെ വെക്കണം എന്നത് ഒരു ഡിസൈൻ തീരുമാനമാണ്. പിശകുകൾ വലിയ നഷ്ടമുണ്ടാക്കുന്ന ഇടങ്ങളിൽ അവ സ്ഥാപിക്കുക. ഒരു ഡാറ്റാബേസിലേക്ക് സ്റ്റേറ്റ് ചേഞ്ച് (state change) ചെയ്യുന്നതിന് തൊട്ടുമുൻപും, പേയ്മെന്റ് സ്വീകരിക്കുന്നതിന് തൊട്ടുമുൻപും, ഒരു ഉപഭോക്താവിന് സന്ദേശം അയക്കുന്നതിന് തൊട്ടുമുൻപും ഉള്ള ചെക്ക്പോയിന്റുകളാണ് ഏറ്റവും മൂല്യമുള്ളത്. ഒരു തെറ്റായ തീരുമാനം തിരുത്താനാവാത്ത പ്രവൃത്തിയായി മാറുന്ന നിമിഷങ്ങളാണിവ.
ഒരു പ്രത്യേക പോരായ്മ ശ്രദ്ധിക്കുക. ഒരേ മോഡൽ തന്നെ ജോലി ചെയ്യുകയും അത് ഗ്രേഡ് ചെയ്യുകയും ചെയ്താൽ, അത് ഒരേ തെറ്റുകൾ തന്നെ കണ്ടില്ലെന്ന് നടിച്ചേക്കാം. ഒരു പിശക് ഉണ്ടാക്കിയ അതേ യുക്തി (reasoning), റിവ്യൂ സമയത്ത് ആ തെറ്റിനെ ന്യായീകരിക്കാൻ സാധ്യതയുണ്ട്. വലിയ സ്വാധീനമുള്ള ജോലികൾക്കായി, മനുഷ്യന്റെ മേൽനോട്ടം (human review) ഉറപ്പാക്കുക. പണമോ ഉപഭോക്താവിന്റെ വിശ്വാസമോ പണയമായിരിക്കുന്ന സാഹചര്യങ്ങളിൽ, ഗ്രേഡറുടെ തീരുമാനങ്ങൾ മനുഷ്യർ പരിശോധിക്കുന്നുണ്ടെന്ന് ഉറപ്പാക്കുക.
ഇതിന്റെ ലക്ഷ്യം ഓപ്പറേഷണൽ കൺട്രോൾ (operational control) ആണ്. നിങ്ങളുടെ ഇൻസിഡന്റ് ഡാറ്റ, ടാസ്ക് റൂബ്രിക്സ് (task rubrics), റൺടൈം ട്രേസുകൾ (runtime traces) എന്നിവയെ ഒരു ഫീഡ്ബാക്ക് സൈക്കിളിലേക്ക് ബന്ധിപ്പിക്കുക. പ്ലാൻ, ടൂൾ ഉപയോഗം, റിക്കവറി ബിഹേവിയർ, ഫൈനൽ റിസൾട്ട് എന്നിങ്ങനെ മുഴുവൻ പാതയും വിലയിരുത്തുക. റിലീസിന് മുമ്പ് അറിയപ്പെടുന്ന പിശകുകൾ കണ്ടെത്താൻ ഓഫ്ലൈൻ ടെസ്റ്റുകൾ ഉപയോഗിക്കുക. നിങ്ങൾ പ്രതീക്ഷിക്കാത്ത പുതിയ പരാജയങ്ങൾ കണ്ടെത്താൻ റൺടൈം ട്രേസുകൾ ഉപയോഗിക്കുക. നിങ്ങളുടെ റൂബ്രിക്സുകളിൽ എവിടെയാണ് മാറ്റങ്ങൾ വരുത്തേണ്ടതെന്ന് കണ്ടെത്താൻ ഹ്യൂമൻ റിവ്യൂ ഉപയോഗിക്കുക.
അതിനാൽ സ്വയം ചോദിക്കുക: നിങ്ങളുടെ വർക്ക്ഫ്ലോയിൽ എവിടെയാണ് ഒരു റൺടൈം ഗ്രേഡർ വെക്കേണ്ടത്? ഒരു ടൂൾ കോളിന് മുമ്പാണോ, ശേഷമാണോ, അതോ റിസ്കുള്ള മാറ്റങ്ങൾക്ക് മുമ്പ് മാത്രമാണോ? മിക്ക ടീമുകളും എല്ലാം ഗ്രേഡ് ചെയ്യാൻ ശ്രമിച്ചുകൊണ്ട് വളരെ വിപുലമായി തുടങ്ങുകയും പിന്നീട് ചിലവ് കാരണം തടസ്സപ്പെടുകയും ചെയ്യുന്നു. വളരെ കൃത്യമായ ഇടങ്ങളിൽ നിന്ന് തുടങ്ങുക. തെറ്റായിപ്പോയാൽ ഏറ്റവും കൂടുതൽ ആഘാതം ഉണ്ടാക്കുന്ന ഒരു കാര്യം മാത്രം തിരഞ്ഞെടുക്കുക. ആദ്യം അവിടെ ഒരു ഗ്രേഡർ സ്ഥാപിക്കുക.
ഒരു വലിയ പിശകിൽ നിന്ന് തുടങ്ങുക
ഓപ്പറേഷണൽ ഇവാലുവേഷൻ എന്നത് വെറുമൊരു ഗവേഷണ പ്രക്രിയയല്ല. ഏജന്റ് ലൈവ് ആയതിന് ശേഷം സമാധാനമായി ഉറങ്ങാൻ സഹായിക്കുന്ന ഒരു മാർഗ്ഗമാണിത്. ഒന്നാം ദിവസം തന്നെ നിങ്ങൾക്ക് ഒരു പെർഫെക്റ്റ് ഫ്രെയിംവർക്ക് ആവശ്യമില്ല. കൃത്യമായി നിർവചിച്ച ഒരു വർക്ക്ഫ്ലോ, ലളിതമായ ബിസിനസ് പദങ്ങളിൽ എഴുതിയ ഒരു റൂബ്രിക്, ഒരു പിശക് വലിയ നഷ്ടമുണ്ടാക്കുന്ന കൃത്യമായ നിമിഷത്തിൽ സ്ഥാപിച്ച ഒരു ഗ്രേഡർ എന്നിവ മാത്രം മതിയാകും. അത് ശരിയായി ചെയ്താൽ, നിങ്ങൾക്ക് വിശ്വസിക്കാവുന്ന ഒരു അടിത്തറ ലഭിക്കും.
ഏജന്റ് ഇവാലുവേഷനെക്കുറിച്ചും റൺടൈം ഗ്രേഡിംഗിനെക്കുറിച്ചും കൂടുതൽ പഠിക്കാൻ ഒരു കമ്മ്യൂണിറ്റിയുടെ സഹായം തേടുന്നുണ്ടെങ്കിൽ, GyaanSetu ലേണിംഗ് കമ്മ്യൂണിറ്റിയിൽ https://t.me/GyaanSetuAi നിങ്ങൾക്ക് ചേരാം.