ഞാൻ വികസിപ്പിച്ചെടുത്ത AI ഏജന്റ് 23 യൂണിറ്റ് ടെസ്റ്റുകളും വിജയിച്ചു, എന്നാൽ ലൈവ് ആയ ഒരു മണിക്കൂറിനുള്ളിൽ തന്നെ അത് ഒരു പുതിയ ഉൽപ്പന്ന ഫീച്ചർ സങ്കൽപ്പിക്കുകയും യഥാർത്ഥ വിലയുടെ മൂന്നിലൊന്ന് മാത്രം വില പറയുകയും ചെയ്തു. ഉപഭോക്താവ് അത് ചൂണ്ടിക്കാണിച്ചപ്പോൾ, ബോട്ട് തന്റെ വാദത്തിൽ ഉറച്ചുനിന്നു, സംഭാഷണം അവസാനിച്ചു, എനിക്ക് ഒരു ക്ലയന്റിനെ നഷ്ടമായി. യൂണിറ്റ് ടെസ്റ്റുകൾ കൊണ്ട് മാത്രം ഒരു ഏജന്റിന്റെ വിശ്വാസ്യത ഉറപ്പാക്കാൻ കഴിയില്ലെന്ന് ഈ തെറ്റ് തെളിയിച്ചു.
AI ഏജന്റുകൾക്ക് യൂണിറ്റ് ടെസ്റ്റുകൾ മാത്രം മതിയാകാത്തത് എന്തുകൊണ്ട്
പരമ്പരാഗത കോഡുകൾക്ക് യൂണിറ്റ് ടെസ്റ്റുകൾ ഫലപ്രദമാണ്, കാരണം ഒരേ ഇൻപുട്ട് എപ്പോഴും ഒരേ ഔട്ട്പുട്ട് നൽകുന്നു. “2 + 2 = 4” എന്നത് ഒരു ലളിതമായ പരിശോധനയിലൂടെ ഉറപ്പാക്കാവുന്ന കാര്യമാണ്. എന്നാൽ, ഒരു LLM-driven ഏജന്റ് അതിന്റെ പ്രോംപ്റ്റ് (prompt), ചുറ്റുമുള്ള സാഹചര്യങ്ങൾ (context), ഉപയോഗിക്കുന്ന ടൂളുകൾ എന്നിവയ്ക്കനുസരിച്ച് ഔട്ട്പുട്ടിൽ മാറ്റം വരുത്തുന്നു. ഒരു സ്ട്രിംഗിലെ കൃത്യത മാത്രം പരിശോധിക്കുന്ന ടെസ്റ്റുകൾക്ക് ഹാലൂസിനേഷനുകൾ (hallucinations), സ്വഭാവത്തിലുള്ള മാറ്റങ്ങൾ (tone shifts), അല്ലെങ്കിൽ ഗാർഡ്റെയിൽ ലംഘനങ്ങൾ (guardrail violations) എന്നിവ കണ്ടെത്താൻ കഴിയില്ല. ഒരു ക്ലയന്റിനെ നഷ്ടപ്പെടുത്തിയ ആ നിശബ്ദമായ പരാജയം കാണിക്കുന്നത്, ഒറ്റപ്പെട്ട ഫംഗ്ഷനുകൾ മാത്രമല്ല, മറിച്ച് മുഴുവൻ സംഭാഷണവും വിലയിരുത്തേണ്ടതുണ്ട് എന്നാണ്.
ഫീച്ചർ കോഡ് എഴുതുന്നതിന് മുമ്പ് ഒരു ഇവാലുവേഷൻ ഹാർനെസ് (evaluation harness) നിർമ്മിക്കുക
ഞാൻ വികസന രീതി മാറ്റി: ആദ്യം നാല് പാളികളുള്ള (four-layer) ഒരു ഇവാലുവേഷൻ ഹാർനെസ് രൂപകൽപ്പന ചെയ്തു, അതിനുശേഷം ഏജന്റ് എഴുതി. ഈ ഹാർനെസ് ഒറ്റ പാസ്സിൽ 131 ടെസ്റ്റുകൾ നടത്തുന്നു, ഒരു റണ്ണിന് ഏകദേശം മൂന്ന് സെന്റ് ചെലവ് വരുന്നു, പതിനൊന്ന് മിനിറ്റിനുള്ളിൽ ഇത് പൂർത്തിയാകുന്നു. ഓരോ ടെസ്റ്റിനും അത് കൈകാര്യം ചെയ്യാൻ കഴിയുന്ന ഏറ്റവും ചെറിയ മോഡലിനെ ഞാൻ ഏൽപ്പിക്കുന്നു; വലിയതും വിലകൂടിയതുമായ മോഡലുകൾ അവയ്ക്ക് ശരിക്കും ആവശ്യമായ ഘട്ടങ്ങളിൽ മാത്രം ഉപയോഗിക്കുന്നു.
പാളി 1 – ടൂൾ ഫംഗ്ഷണാലിറ്റി (Tool functionality)
ഏജന്റിന് അതിന്റെ ടൂളുകൾ ശരിയായി ഉപയോഗിക്കാൻ കഴിയുന്നുണ്ടോ എന്ന് പരിശോധിക്കുന്ന ആദ്യ പ്രതിരോധ പാളിയാണിത്. വിജയകരമായ സെർച്ചുകൾ, മനഃപൂർവ്വം തെറ്റായ രീതിയിൽ നൽകിയ ക്വറികൾ (queries), സിമുലേറ്റഡ് API പരാജയങ്ങൾ എന്നിവ ഈ ടെസ്റ്റുകൾ ഉൾക്കൊള്ളുന്നു. ടൂൾ ഉപയോഗം മിക്കവാറും നിശ്ചിത രീതിയിലായതുകൊണ്ട് (deterministic)—അതായത് റിക്വസ്റ്റ് ശരിയാണെങ്കിൽ മാത്രം API പ്രവർത്തിക്കും അല്ലെങ്കിൽ എറർ കാണിക്കും—ലളിതമായ Python assertions മതിയാകും. ഇവിടെ തെറ്റായ റിക്വസ്റ്റുകൾ കണ്ടെത്തുന്നത് തുടർന്നുള്ള ആശയക്കുഴപ്പങ്ങൾ ഒഴിവാക്കാൻ സഹായിക്കും.
പാളി 2 – ഇൻസ്ട്രക്ഷൻ ഫോളോയിംഗ് (Instruction following)
അടുത്തതായി, ഏജന്റ് ഗാർഡ്റെയിലുകൾ (guardrails) പാലിക്കുന്നുണ്ടോ എന്ന് ഹാർനെസ് പരിശോധിക്കുന്നു. ഒരു ചെറിയ LLM ഇവിടെ ഇവാലുവേറ്ററായി പ്രവർത്തിക്കുന്നു; ഏജന്റിന്റെ മറുപടി കൃത്യമാണോ എന്ന് ഇത് പരിശോധിക്കുന്നു: അതായത്, നിശ്ചയിച്ച സ്വഭാവം നിലനിർത്തുന്നുണ്ടോ, നിരോധിത വിഷയങ്ങൾ ഒഴിവാക്കുന്നുണ്ടോ, ആവശ്യമായ JSON schema നൽകുന്നുണ്ടോ എന്നിവ നോക്കുന്നു. യൂണിറ്റ് ടെസ്റ്റുകൾക്ക് കണ്ടെത്താൻ കഴിയാത്ത സെമാന്റിക് ഡ്രിഫ്റ്റ് (semantic drift) പോലുള്ള കാര്യങ്ങൾ—ഉദാഹരണത്തിന് അപ്രതീക്ഷിതമായ ഒരു വ്യക്തിത്വത്തിലേക്ക് മാറുന്നത് അല്ലെങ്കിൽ ഇന്റേണൽ പ്രോംപ്റ്റുകൾ പുറത്തുവിടുന്നത്—ഈ പാളിയിൽ കണ്ടെത്താനാകും.
പാളി 3 – ഗോൾ-ഓറിയന്റഡ് ബിഹേവിയർ (Goal-oriented behavior)
മൂന്നാമത്തെ പാളിയാണ് ഏറ്റവും നിർണ്ണായകം. ഏജന്റ് അതിന്റെ ലക്ഷ്യം യഥാർത്ഥത്തിൽ നിറവേറ്റുന്നുണ്ടോ എന്നാണ് ഇത് പരിശോധിക്കുന്നത്. ഒരു ലീഡ്-ജനറേഷൻ ബോട്ടിനെ സംബന്ധിച്ചിടത്തോളം, അത് ശരിയായ ചോദ്യങ്ങൾ ചോദിക്കുന്നുണ്ടെന്നും ആവശ്യമുള്ളപ്പോൾ ഒരു മനുഷ്യനെ ബന്ധപ്പെടാൻ നിർദ്ദേശിക്കുന്നുണ്ടെന്നും ഉറപ്പാക്കേണ്ടതുണ്ട്. ഇതിനായി ഞാൻ ഒരു റീസണിംഗ്-ഓറിയന്റഡ് മോഡൽ (reasoning-oriented model) ഉപയോഗിക്കുന്നു, കാരണം ഇത് ചെലവ് വർദ്ധിപ്പിക്കാതെ തന്നെ മൊത്തത്തിലുള്ള പ്രക്രിയ വിലയിരുത്താൻ സഹായിക്കുന്നു. ആദ്യ രണ്ട് പാളികൾ വിജയിച്ചാലും, ബോട്ട് അതിന്റെ ലക്ഷ്യം കൈവരിക്കുന്നതിൽ പരാജയപ്പെട്ടാൽ അത് പുനർരൂപകൽപ്പനയ്ക്കായി (redesign) അടയാളപ്പെടുത്തുന്നു.
പാളി 4 – പെർഫോമൻസ് (Performance)
അവസാനമായി, ഹാർനെസ് ലേറ്റൻസിയും (latency) ടോക്കൺ ജനറേഷൻ വേഗതയും രേഖപ്പെടുത്തുന്നു. മറുപടികൾ വൈകുന്നത് ഉപഭോക്താവിന്റെ അനുഭവം മോശമാക്കും, പ്രത്യേകിച്ച് റിയൽ ടൈം ചാറ്റുകളിൽ. ഫംഗ്ഷണൽ കൃത്യതയ്ക്കൊപ്പം ഈ അളവുകോലുകളും (metrics) ട്രാക്ക് ചെയ്യുന്നതിലൂടെ, ഏജന്റ് കൃത്യവും വേഗതയുള്ളതുമാണെന്ന് ഞാൻ ഉറപ്പാക്കുന്നു.
ചെലവ് കുറയ്ക്കാനുള്ള മാർഗങ്ങൾ
ഒരു റണ്ണിന് $0.03 എന്നത് വെറുമൊരു മാർക്കറ്റിംഗ് തന്ത്രമല്ല; ടെസ്റ്റിന്റെ സങ്കീർണ്ണതയ്ക്ക് അനുസരിച്ചുള്ള മോഡലുകൾ ഉപയോഗിക്കുന്നതിലൂടെയാണ് ഇത് സാധ്യമാകുന്നത്. ടൂൾ ചെക്കുകൾ ഏറ്റവും കുറഞ്ഞ ചെലവിലുള്ള റൺടൈമിലും, ഇൻസ്ട്രക്ഷൻ കംപ്ലയൻസ് ലഘുവായ മോഡലിലും, ലക്ഷ്യങ്ങൾ അടിസ്ഥാനമാക്കിയുള്ള വിലയിരുത്തലുകൾക്ക് മാത്രം ഉയർന്ന ശേഷിയുള്ള മോഡലുകളും ഉപയോഗിക്കുന്നു. ഈ രീതി പിന്തുടരുന്നതിലൂടെ ഓരോ കോഡ് മാറ്റത്തിലും മുഴുവൻ ടെസ്റ്റുകളും കുറഞ്ഞ ചെലവിൽ നടത്താൻ സാധിക്കുന്നു.
വിട്ടുവീഴ്ചകൾ: വേഗതയും സുരക്ഷയും തമ്മിലുള്ള പോരാട്ടം
ഒരു ഹാർനെസ് കൊണ്ടുവന്നത് വികസന പ്രക്രിയയിൽ തുടക്കത്തിൽ ചില തടസ്സങ്ങൾ ഉണ്ടാക്കി. വികസന ചക്രം (development cycles) നീണ്ടുപോവുകയും ലോഞ്ച് സമയം വൈകുകയും ചെയ്തു.
ശ്രദ്ധിക്കേണ്ട കാര്യങ്ങൾ
- Model-driven evaluators: LLM-കൾ മെച്ചപ്പെട്ടതോടെ, പാളി 2-ലെ ഇവാലുവേറ്റർ കൂടുതൽ സൂക്ഷ്മമായി പ്രവർത്തിക്കാൻ കഴിയും. ഇത് തെറ്റായ മുന്നറിയിപ്പുകൾ (false positives) കുറയ്ക്കാനും ചെറിയ നിയമലംഘനങ്ങൾ പോലും കണ്ടെത്താനും സഹായിക്കും.
ചുരുക്കത്തിൽ
നിങ്ങൾ പ്രൊഡക്ഷനായി AI ഏജന്റുകൾ നിർമ്മിക്കുന്നുണ്ടെങ്കിൽ, ഒരു ലെയേർഡ് ഇവാലുവേഷൻ ഹാർനെസ് എന്നത് ഒരു ഓപ്ഷനല്ല, മറിച്ച് അത് അത്യന്താപേക്ഷിതമാണ്. സമഗ്രമായ പരിശോധനയ്ക്കായി ചെലവ് മുൻകൂട്ടി മാറ്റിവെക്കുന്നതിലൂടെ—ഒരു റണ്ണിന് $0.03, ഒരു സ്യൂട്ടിന് പതിനൊന്ന് മിനിറ്റ്—യൂണിറ്റ് ടെസ്റ്റുകൾക്ക് കണ്ടെത്താൻ കഴിയാത്ത നിശബ്ദമായ പരാജയങ്ങളിൽ നിന്ന് നിങ്ങൾക്ക് രക്ഷനേടാം.