നിങ്ങൾ ഒരു ഇന്റേണൽ ടൂൾ നിർമ്മിച്ചു; ഇത് ഒരു LLM-ഡ്രൈവൻ ഫീച്ചറിൽ (LLM-driven feature) മോഡലിന്റെ API ഒരിക്കൽ പോലും വിളിക്കാതെ തന്നെ 28 യൂണിറ്റ് ടെസ്റ്റുകൾ പ്രവർത്തിപ്പിക്കാൻ ഒരു ടീമിനെ സഹായിക്കുന്നു. മോഡലിനെ ഒരു fakeable interface-ൽ ഉൾപ്പെടുത്തിയും, ഡിറ്റമിനിസ്റ്റിക് (deterministic), ഹ്യൂറിസ്റ്റിക് (heuristic), LLM അധിഷ്ഠിത മൂല്യനിർണ്ണയം (evaluation) എന്നിങ്ങനെ മൂന്ന് പാളികൾ ചേർത്തുവെച്ചും ആണ് നിങ്ങൾ ഇത് ചെയ്തത്.

ഒരു LLM വാചകങ്ങൾ നിർമ്മിക്കുന്ന നിമിഷം തന്നെ സാധാരണ അസെർഷനുകൾ (assertions) പരാജയപ്പെടുന്നു. ഒരേ പ്രോംപ്റ്റ് തന്നെ ഓരോ തവണയും വ്യത്യസ്തമായ വാചകങ്ങൾ നൽകിയേക്കാം, അതിനാൽ assertEqual(output, expected) എന്നത് മോഡൽ ശരിയായി പ്രവർത്തിച്ചിട്ടുണ്ടെങ്കിൽ പോലും ഒരു പരാജയമായി കാണിക്കുന്നു. മിക്ക എഞ്ചിനീയറിംഗ് ഗ്രൂപ്പുകളും ഒന്നുകിൽ പരിശോധനകളില്ലാതെ ഫീച്ചർ പുറത്തിറക്കുന്നു, അല്ലെങ്കിൽ ഒരു സ്റ്റാറ്റിക് ലൈബ്രറിയെപ്പോലെ മാറിക്കൊണ്ടിരിക്കുന്ന ഒരു ലക്ഷ്യത്തെ (target) ടെസ്റ്റ് ചെയ്യാൻ ശ്രമിക്കുന്നു.

എന്തുകൊണ്ടാണ് ഈ പ്രശ്നം പ്രധാനമാകുന്നത്

ഇമെയിൽ ഔട്ട്‌റീച്ച്, സപ്പോർട്ട് മറുപടികൾ, കണ്ടന്റ് ജനറേഷൻ എന്നിങ്ങനെ ഉപഭോക്താക്കളുമായി നേരിട്ട് ബന്ധപ്പെട്ട പ്രവർത്തനങ്ങളിൽ (customer-facing workflows) ഇപ്പോൾ LLM-കൾ പ്രവർത്തിക്കുന്നുണ്ട്. ഒരു തെറ്റായ വിവരമോ (hallucinated fact) അല്ലെങ്കിൽ ചോർന്നുവരുന്ന ഐഡന്റിഫയറുകളോ ബ്രാൻഡ് സൽപ്പേരിനെ തകർക്കുകയോ, സ്വകാര്യ ഡാറ്റ വെളിപ്പെടുത്തുകയോ, നിയമപരമായ ലംഘനങ്ങൾ ഉണ്ടാക്കുകയോ ചെയ്തേക്കാം. വിശ്വസനീയമായ ഒരു ടെസ്റ്റ് സ്ട്രാറ്റജി ഇല്ലാതെ, ടീമുകൾ നിരന്തരം പരാജയപ്പെടുന്ന ടെസ്റ്റുകൾക്ക് പിന്നാലെ സമയം കളയുകയോ അല്ലെങ്കിൽ പ്രൊഡക്ഷനിൽ മാത്രം പ്രശ്നങ്ങൾ ഉണ്ടാക്കുന്ന ബഗുകൾ പുറത്തിറക്കുകയോ ചെയ്യുന്നു.

സമീപനം: മോഡലിന്റെ ഉത്തരവാദിത്തം കുറയ്ക്കുക

ആദ്യപടി LLM യഥാർത്ഥത്തിൽ ചെയ്യുന്ന കാര്യങ്ങൾ പരിമിതപ്പെടുത്തുക എന്നതായിരുന്നു. ഈ സിസ്റ്റത്തിൽ മോഡൽ ഔട്ട്‌റീച്ച് സന്ദേശങ്ങൾ തയ്യാറാക്കുക മാത്രമാണ് ചെയ്യുന്നത്. എല്ലാ റൂട്ടിംഗ് ലോജിക്, സ്റ്റേറ്റ് മാനേജ്‌മെന്റ്, സേഫ്റ്റി ചെക്കുകൾ എന്നിവ സാധാരണ കോഡിൽ തന്നെ നിലനിർത്തുന്നു. മോഡലിനെ കൃത്യമായി നിർവചിക്കപ്പെട്ട ഒരു ഔട്ട്‌പുട്ടിലേക്ക് മാത്രമായി പരിമിതപ്പെടുത്തുന്നതിലൂടെ, ചുറ്റുമുള്ള സിസ്റ്റം ഡിറ്റമിനിസ്റ്റിക്കും (deterministic) ടെസ്റ്റ് ചെയ്യാൻ സാധിക്കുന്നതുമായി മാറുന്നു.

ഇത് സാധ്യമാക്കുന്നതിനായി, LLM ഒരു പ്രൊവൈഡർ ഇന്റർഫേസിന് (provider interface) പിന്നിലായി പ്രവർത്തിക്കുന്നു, ഇത് ടെസ്റ്റുകളിൽ ഒരു 'fake' വേർഷൻ ഉപയോഗിക്കാൻ അനുവദിക്കുന്നു. പ്രൊഡക്ഷനിൽ ഈ ഇംപ്ലിമെന്റേഷൻ എക്സ്റ്റേണൽ API വിളിക്കുന്നു; എന്നാൽ ടെസ്റ്റ് സ്യൂട്ടിൽ ഒരു ലൈറ്റ് വെയ്റ്റ് 'fake' ഒരു മുൻകൂട്ടി തയ്യാറാക്കിയ മറുപടി നൽകുന്നു. ബാക്കിയുള്ള കോഡ് ഇന്റർഫേസുമായി മാത്രം ഇടപഴകുന്നതിനാൽ, നെറ്റ്‌വർക്ക് ഉപയോഗിക്കാതെ തന്നെ മുഴുവൻ വർക്ക്ഫ്ലോയും യൂണിറ്റ് ടെസ്റ്റുകൾ വഴി പരിശോധിക്കാൻ കഴിയും. ഇതിന്റെ ഫലമായി 28 ടെസ്റ്റുകൾക്ക് പരിശോധിക്കാവുന്ന ഒരു പ്രെഡിക്റ്റബിൾ കോർ (predictable core) ലഭിക്കുന്നു.

കൃത്യമായ ഒരു ഇവാലുവേഷൻ ഹാർനെസ് (evaluation harness)

പരിധി കുറച്ചാലും, മോഡലിന്റെ ഔട്ട്‌പുട്ട് ഇപ്പോഴും നോൺ-ഡിറ്റമിനിസ്റ്റിക് (nondeterministic) ആണ്. അതിനാൽ, ഓരോ പാളിയും വ്യത്യസ്ത തരം റിസ്ക്കുകൾ കൈകാര്യം ചെയ്യുന്ന രീതിയിൽ മൂന്ന് പാളികളുള്ള ഒരു ഇവാലുവേഷൻ ഹാർനെസ് ആണ് ഇതിനായി നിർമ്മിച്ചത്.

  • ലെയർ 1 – ഡിറ്റമിനിസ്റ്റിക് ചെക്കുകൾ (Deterministic checks) സിമ്പിൾ റെഗുലർ എക്സ്പ്രഷൻ നിയമങ്ങൾ ഉപയോഗിച്ച് തെറ്റായ ബിൽഡിംഗ് ഐഡി അല്ലെങ്കിൽ നിരോധിത ടോക്കണുകൾ പോലുള്ള കൃത്യമായ പിശകുകൾ കണ്ടെത്തുന്നു. ഈ ചെക്കുകൾ വേഗതയേറിയതും ബൈനറി പാസ്/ഫെയിൽ (pass/fail) രീതിയിലുള്ളതുമാണ്.

  • ലെയർ 2 – ഹ്യൂറിസ്റ്റിക് ചെക്കുകൾ (Heuristic checks) സ്ക്രിപ്റ്റുകൾ തെറ്റായ നമ്പറുകളോ തീയതികളോ കണ്ടെത്തുന്നു, ഇത് വ്യക്തമായ വസ്തുതാപരമായ തെറ്റുകളെ അടയാളപ്പെടുത്തുന്നു. എന്നാൽ സംഖ്യകൾ ഇല്ലാത്ത തെറ്റായ അവകാശവാദങ്ങൾ കണ്ടെത്താൻ ഇവയ്ക്ക് കഴിയില്ലെന്ന് ഇതിന്റെ നിർമ്മാതാവ് സമ്മതിക്കുന്നു.

  • ലെയർ 3 – LLM ജഡ്ജ് (LLM judge) ഒരു സെക്കൻഡറി മോഡൽ ടോണും പ്രൊഫഷണലിസവും വിലയിരുത്തുന്നു. ഈ ഘട്ടം മറ്റൊരു പ്രോബബിലിസ്റ്റിക് സിസ്റ്റത്തെ ആശ്രയിക്കുന്നതിനാൽ, ഡിറ്റമിനിസ്റ്റിക് നിയമങ്ങൾ ഉപയോഗിക്കാൻ കഴിയാത്ത സബ്ജക്റ്റീവ് ആയ കാര്യങ്ങൾക്കായി ഇത് മാത്രം ഉപയോഗിക്കുന്നു.

ഈ ഹാർനെസിന്റെ പ്രധാന ഘടകം മൂല്യനിർണ്ണയത്തിനായി ഉപയോഗിക്കുന്ന ഡാറ്റാസെറ്റാണ്. മുൻപ് കണ്ടിട്ടുള്ള പരാജയ രീതികൾ—പ്രത്യേക കെണികളും ഡൊമെയ്ൻ അറിവുകളും—ഇതിൽ ഉൾപ്പെടുത്തിയിട്ടുണ്ട്, അതിനാൽ പ്രായോഗികമായി കണ്ടിട്ടുള്ള തെറ്റുകൾ തന്നെ ഹാർനെസ് പരിശോധിക്കുന്നു. ഇതൊരു മാന്ത്രികമായ പരിഹാരമല്ല, മറിച്ച് ലക്ഷ്യബോധമുള്ള ഒരു സുരക്ഷാ വലയാണ്.

ടീമുകൾക്ക് ഇതിന്റെ അർത്ഥമെന്താണ്

  • LLM-ന്റെ ജോലി ചെറുതാക്കി നിർത്തുക. ഉത്തരവാദിത്തങ്ങൾ കുറയുന്നത് ഐസൊലേഷനും ടെസ്റ്റിംഗും എളുപ്പമാക്കുന്നു.
  • റൂട്ടിംഗ്, സ്റ്റേറ്റ്, സേഫ്റ്റി എന്നിവ കോഡിൽ ഉൾപ്പെടുത്തുക. പരമ്പരാഗത ലോജിക് ഡിറ്റമിനിസ്റ്റിക്കും പൂർണ്ണമായും ടെസ്റ്റ് ചെയ്യാൻ സാധിക്കുന്നതുമായി നിലനിൽക്കുന്നു.
  • ഒരു fakeable interface വഴി മോഡലിനെ ലഭ്യമാക്കുക. യൂണിറ്റ് ടെസ്റ്റുകൾ എക്സ്റ്റേണൽ കോളുകൾ ഇല്ലാതെ തന്നെ പ്രവർത്തിക്കുന്നു, ഇത് ടെസ്റ്റ് സ്യൂട്ടിനെ വേഗതയുള്ളതും വിശ്വസനീയവുമാക്കുന്നു.
  • മൂല്യനിർണ്ണയം പാളികളായി തിരിക്കുക. ഡിറ്റമിനിസ്റ്റിക് നിയമങ്ങളിൽ നിന്ന് തുടങ്ങുക, അറിയപ്പെടുന്ന ഹാലൂസിനേഷനുകൾക്കായി ഹ്യൂറിസ്റ്റിക്സ് ചേർക്കുക, സബ്ജക്റ്റീവ് ആയ ഗുണനിലവാര പരിശോധനകൾക്കായി LLM ജഡ്ജിനെ ഉപയോഗിക്കുക.
  • പരിമിതികൾ വ്യക്തമാക്കുക. ഒരു പാളിയും പൂർണ്ണത ഉറപ്പുനൽകുന്നില്ല; നിങ്ങൾ എന്തിനെ കണ്ടെത്താൻ പ്രോഗ്രാം ചെയ്തിട്ടുണ്ടോ അത് മാത്രമേ ഹാർനെസ് കണ്ടെത്തുകയുള്ളൂ.

ഒരു എതിർവാദം: നിങ്ങൾക്ക് ഇപ്പോഴും മോഡലിനെ തന്നെ നേരിട്ട് യൂണിറ്റ് ടെസ്റ്റ് ചെയ്യാൻ കഴിയില്ല

ഒരു മോഡൽ മാറിക്കൊണ്ടിരിക്കുന്ന ഒരു ലക്ഷ്യമാണെന്ന് (moving target) ഇതിന്റെ രചയിതാവ് സമ്മതിക്കുന്നു. LLM ജഡ്ജ് പാളി പോലും അത് വിലയിരുത്താൻ ശ്രമിക്കുന്ന അതേ നോൺ-ഡിറ്റമിനിസം തന്നെ ഉൾക്കൊള്ളുന്നു. തൽഫലമായി, ഓരോ ഹാലൂസിനേഷനും അല്ലെങ്കിൽ പോളിസി ലംഘനവും റിലീസ് ചെയ്യുന്നതിന് മുമ്പ് തന്നെ കണ്ടെത്തുമെന്ന് ഈ സിസ്റ്റത്തിന് ഒരിക്കലും ഉറപ്പുനൽകാൻ കഴിയില്ല. ഈ സമീപനം റിസ്ക് കുറയ്ക്കുന്നുണ്ടോ, അല്ലാതെ അത് ഇല്ലാതാക്കുന്നില്ല. പുതിയ പരാജയ രീതികൾ വരുമ്പോൾ മൂല്യനിർണ്ണയ ഡാറ്റ പുതുക്കാനുള്ള ടീമിന്റെ കഴിവിനെ ഇത് ആശ്രയിച്ചിരിക്കുന്നു.

സംഗ്രഹം

ഒരു LLM-ന്റെ കൃത്യമായ ഔട്ട്‌പുട്ട് ഉറപ്പുവരുത്തുന്ന രീതിയിൽ ഒരു ക്ലാസിക് യൂണിറ്റ് ടെസ്റ്റ് എഴുതാൻ നിങ്ങൾക്ക് കഴിയില്ല, എന്നാൽ മോഡലിന്റെ സ്വാധീനം പരിമിതപ്പെടുത്തുകയും, അതിന്റെ ഇന്റർഫേസ് മാറ്റാൻ സാധിക്കുന്നതാക്കുകയും, അതിന്റെ ഔട്ട്‌പുട്ട് പാളികളായുള്ള സുതാര്യമായ പരിശോധനകളിലൂടെ കടത്തിവിടുകയും ചെയ്യുന്ന ഒരു സിസ്റ്റം നിങ്ങൾക്ക് നിർമ്മിക്കാം. ആ കോമ്പിനേഷൻ ഒരു അസ്ഥിരമായ ഘടകത്തെ ഒരു വലിയ, ടെസ്റ്റ് ചെയ്യാവുന്ന ആപ്ലിക്കേഷന്റെ പ്രെഡിക്റ്റബിൾ ആയ ഭാഗമാക്കി മാറ്റുന്നു.