University of Illinois Urbana-Champaign-ലെ ഒരു ഗവേഷണ സംഘം കണ്ടെത്തിയത്, വ്യാപകമായി ഉപയോഗിക്കപ്പെടുന്ന BIRD Text-to-SQL ബെഞ്ച്മാർക്കിലെ പകുതിയിലധികം അനോട്ടേഷനുകളും (annotations) തെറ്റാണെന്നാണ്. ഇത് അനേകം ഡെവലപ്പർമാർ വിശ്വസിക്കുന്ന കൃത്യത സ്കോറുകളുടെ (accuracy scores) പ്രസക്തിയെ ചോദ്യം ചെയ്യുന്നു.
ബെഞ്ച്മാർക്ക് എന്തിനാണ് പ്രസക്തമാകുന്നത്
ഒരു മോഡലിന് സ്വാഭാവിക ഭാഷയിലുള്ള (natural-language) ചോദ്യങ്ങളെ ഒരു SQL ക്വറിയിലേക്ക് എത്രത്തോളം നന്നായി മാറ്റാൻ കഴിയുമെന്ന് അളക്കുന്നതിനുള്ള മാനദണ്ഡമാണ് BIRD. പേപ്പറുകൾ, പ്രൊഡക്റ്റ് ഷീറ്റുകൾ, നിയമന പരീക്ഷകൾ എന്നിവയിൽ BIRD സ്കോറുകൾ ഉദ്ധരിക്കാറുണ്ട്. ശരിയാണെന്ന് നിർണ്ണയിക്കുന്ന "gold" SQL സ്റ്റേറ്റ്മെന്റുകൾ പിഴവുള്ളതാണെങ്കിൽ, മികച്ച ക്വറി എഴുതുന്ന ഒരു മോഡലിനെ ശിക്ഷിക്കപ്പെടാം, എന്നാൽ തെറ്റായ ഗോൾഡ് ഉത്തരം പകർത്തുന്ന ഒരു മോഡലിന് പ്രതിഫലം ലഭിച്ചേക്കാം.
പിശക് നിരക്ക് എങ്ങനെ കണ്ടെത്തി
UIUC സംഘം BIRD-dev സ്പ്ലിറ്റിൽ നിന്നുള്ള 238 പരാജയങ്ങൾ പരിശോധിച്ചു. ഓരോ മോഡൽ ഔട്ട്പുട്ടും എന്തുകൊണ്ട് തെറ്റായി അടയാളപ്പെടുത്തി എന്ന് ഊഹിക്കുന്നതിന് പകരം, മോഡൽ നിർമ്മിച്ച SQL-ഉം ഗോൾഡ് റെഫറൻസും തമ്മിലുള്ള എല്ലാ വ്യത്യാസങ്ങളും അവർ നേരിട്ട് (manually) ടാഗ് ചെയ്തു. അവരുടെ ഓഡിറ്റിൽ 52.8% കേസുകളിലും ഒരു അനോട്ടേഷൻ പിശക് ഉണ്ടെന്ന് കണ്ടെത്തി—തെറ്റായ SQL, പൊരുത്തപ്പെടാത്ത സ്കീമ (schema), അല്ലെങ്കിൽ തെറ്റായ സ്വാഭാവിക ഭാഷാ ചോദ്യം എന്നിവ ഇതിൽ ഉൾപ്പെടുന്നു.
തിരിച്ചറിയപ്പെട്ട തെറ്റുകളിൽ 19% ഒരു പ്രത്യേക രീതിയിലുള്ളതായിരുന്നു: ഗോൾഡ് ക്വറിയിൽ ഇല്ലാത്ത DISTINCT എന്ന വാക്ക് മോഡൽ ഉപയോഗിച്ചു. അസാധാരണമായ ലാബ് ഫലങ്ങളുള്ള രോഗികളുടെ എണ്ണം ചോദിക്കുന്ന ഒരു ഉപയോക്താവിനെ സങ്കൽപ്പിക്കുക. ഗോൾഡ് ഉത്തരം COUNT(ID) ഉപയോഗിച്ച് വരികൾ എണ്ണുന്നു. ഒരു രോഗിക്ക് അഞ്ച് അസാധാരണ ലാബ് ഫലങ്ങൾ ഉണ്ടെങ്കിൽ, ഗോൾഡ് ക്വറി ഒരു രോഗിക്ക് പകരം അഞ്ച് എന്ന് റിപ്പോർട്ട് ചെയ്യുന്നു. എന്നാൽ മോഡലിന്റെ COUNT(DISTINCT ID) ഓരോ രോഗിയെയും കൃത്യമായി ഒരു തവണ മാത്രം എണ്ണുന്നു. ഇത്തരം സന്ദർഭങ്ങളിൽ, മോഡലിന്റെ ഉത്തരം ഉദ്ദേശിച്ച അർത്ഥവുമായി കൂടുതൽ യോജിക്കുന്നുണ്ടെങ്കിലും ബെഞ്ച്മാർക്ക് ഒരു മോഡൽ പിശക്യായി ഇത് രേഖപ്പെടുത്തുന്നു.
മോഡൽ വികസനത്തിൽ ഉണ്ടാകുന്ന യഥാർത്ഥ പ്രത്യാഘാതങ്ങൾ
കുറഞ്ഞ BIRD സ്കോറുകൾ കണ്ട് ഡെവലപ്പർമാർ പലപ്പോഴും പ്രോംപ്റ്റുകളിൽ മാറ്റം വരുത്തുകയോ, “don’t use DISTINCT” പോലുള്ള നിയന്ത്രണങ്ങൾ ചേർക്കുകയോ, അല്ലെങ്കിൽ ബെഞ്ച്മാർക്ക് ഡാറ്റയിൽ വീണ്ടും പരിശീലിപ്പിക്കുകയോ (retraining) ചെയ്യുന്നു. ഈ ക്രമീകരണങ്ങൾ റിപ്പോർട്ട് ചെയ്യപ്പെടുന്ന സ്കോർ വർദ്ധിപ്പിക്കുകയും പുരോഗതിയുടെ ഒരു മിഥ്യാധാരണ സൃഷ്ടിക്കുകയും ചെയ്തേക്കാം. ഈ “മെച്ചപ്പെടുത്തൽ” തെറ്റായ ഉത്തരങ്ങളോട് അമിതമായി പൊരുത്തപ്പെടുന്നതാകാം (overfitting), ഇത് ശരിയായ ലോജിക് ആവശ്യമായ യഥാർത്ഥ ഡാറ്റാബേസുകളിൽ പ്രകടനം കുറയാൻ കാരണമായേക്കാം എന്ന് UIUC വിശകലനം കാണിക്കുന്നു.
ഗവേഷകർ ഇതിന് വിപരീതമായ ഒരു സാഹചര്യം തെളിയിച്ചു. മോഡലിന്റെയും ഗോൾഡ് ക്വറികളുടെയും വിശകലനത്തിന് ശേഷം, മോഡൽ രണ്ട് വ്യത്യസ്ത കോളങ്ങളെ തെറ്റായി ഒരൊറ്റ കോളമായി യോജിപ്പിച്ച ഏഴ് സന്ദർഭങ്ങൾ അവർ കണ്ടെത്തി. ഈ കേസുകളിൽ ഗോൾഡ് SQL ശരിയായിരുന്നു. പരിഷ്കരിച്ച പ്രോംപ്റ്റുകൾ ഉപയോഗിച്ച് ആ യഥാർത്ഥ പിശകുകൾ മാത്രം ലക്ഷ്യം വയ്ക്കുന്നതിലൂടെ, ബെഞ്ച്മാർക്ക് സ്കോർ കൃത്രിമമായി വർദ്ധിപ്പിക്കാതെ തന്നെ മോഡലിന്റെ പ്രകടനം അവർ മെച്ചപ്പെടുത്തി.
കണ്ടെത്തലുകൾ സ്റ്റേക്ക്ഹോൾഡർമാർക്ക് എന്ത് അർത്ഥമാക്കുന്നു
- ഗവേഷകർ (Researchers): BIRD സ്കോറുകളെ അടിസ്ഥാനമാക്കിയുള്ള പ്രസിദ്ധീകരണങ്ങളിൽ അനോട്ടേഷൻ ഗുണനിലവാരത്തെക്കുറിച്ച് ഒരു മുന്നറിയിപ്പ് നൽകേണ്ടതുണ്ട്. പേപ്പറുകൾ തമ്മിലുള്ള താരതമ്യങ്ങൾ യഥാർത്ഥ രീതിശാസ്ത്രപരമായ പുരോഗതിയെക്കാൾ ബെഞ്ച്മാർക്കിലെ പിശകുകളോടുള്ള വ്യത്യാസത്തെയാകാം പ്രതിഫലിപ്പിക്കുന്നത്.
- പ്രൊഡക്റ്റ് ടീമുകൾ (Product teams): മോഡലുകൾ പുറത്തിറക്കുന്നതിനുള്ള ഏക മാനദണ്ഡമായി BIRD-യെ മാത്രം ആശ്രയിക്കുന്നത് തെറ്റായ ക്വറികൾ പകർത്തിയെഴുതാൻ പഠിച്ച മോഡലുകൾ വിപണിയിലെത്താൻ കാരണമായേക്കാം. സ്വന്തം സ്കീമകളിൽ (proprietary schemas) യഥാർത്ഥ ലോക പരിശോധനകൾ നടത്തുന്നത് അത്യാവശ്യമാണ്.
- ബെഞ്ച്മാർക്ക് ക്യൂറേറ്റർമാർ (Benchmark curators): ഉയർന്ന പിശക് നിരക്ക് ഒരു വ്യവസ്ഥാപിതമായ പുനഃപരിശോധനയുടെ ആവശ്യകതയെ സൂചിപ്പിക്കുന്നു. ഗോൾഡ് സെറ്റ് വൃത്തിയാക്കുകയോ അല്ലെങ്കിൽ രണ്ടാമതൊരു “പരിശോധിക്കപ്പെട്ട” (verified) സ്പ്ലിറ്റ് നൽകുകയോ ചെയ്യുന്നത് വിശ്വാസ്യത വീണ്ടെടുക്കാൻ സഹായിക്കും.
ഒരു പ്രായോഗിക ഓഡിറ്റ് വർക്ക്ഫ്ലോ
ഏതൊരു Text-to-SQL ബെഞ്ച്മാർക്കിനും പ്രയോഗിക്കാവുന്ന ലളിതമായ ഒരു പ്രക്രിയ UIUC ടീം നിർദ്ദേശിക്കുന്നു:
- മോഡൽ നിർമ്മിച്ചതും ഗോൾഡ് SQL സ്റ്റേറ്റ്മെന്റുകളും abstract syntax trees ആയി Parse ചെയ്യുക.
- തിരഞ്ഞെടുത്ത കോളങ്ങൾ, ഫിൽട്ടറുകൾ, ജോയിനുകൾ (joins), അഗ്രഗേഷൻ ഫംഗ്ഷനുകൾ എന്നിവയിലെ വ്യത്യാസങ്ങൾ കണ്ടെത്താൻ അവയുടെ ഘടനകൾ Align ചെയ്യുക.
- ഓരോ വ്യത്യാസവും (ഉദാഹരണത്തിന്: അധിക കോളങ്ങൾ, വിട്ടുപോയ ഫിൽട്ടറുകൾ, തെറ്റായ അഗ്രഗേഷൻ) Tag ചെയ്യുക.
- പ്രധാനപ്പെട്ട പിശക് വിഭാഗങ്ങൾ തിരിച്ചറിയാൻ ടാഗുകൾ ഒരു ഹിസ്റ്റോഗ്രാമിൽ Summarize ചെയ്യുക.
- പ്രോംപ്റ്റ് എഞ്ചിനീയറിംഗിനായി ഉപയോഗിക്കുന്നതിന് മുമ്പ് ഓരോ ഉയർന്ന ഫ്രീക്വൻസി ടാഗിനും ഗോൾഡ് ക്വറി Validate ചെയ്യുക.
ഗോൾഡ് ഉത്തരം നിസംശയം ശരിയാണെന്ന് ഉറപ്പുള്ള കേസുകളിൽ മാത്രം പ്രോംപ്റ്റ് പരിഷ്കരിക്കുന്നതിലൂടെ, “തകരാറുള്ള ഒരു മെട്രിക്സിനായി ഒപ്റ്റിമൈസ് ചെയ്യുന്ന” കെണിയിൽ നിന്ന് ഡെവലപ്പർമാർക്ക് രക്ഷപ്പെടാം.
ചുരുക്കത്തിൽ
പകുതിയിലധികം ഉദാഹരണങ്ങളും തെറ്റായി അടയാളപ്പെടുത്തുന്ന ഒരു ബെഞ്ച്മാർക്കിന് വിശ്വസനീയമായ ഒരു മാനദണ്ഡമായി പ്രവർത്തിക്കാൻ കഴിയില്ല. BIRD അടയാളപ്പെടുത്തുന്ന പല “തെറ്റുകളും” യഥാർത്ഥത്തിൽ മോഡലിന്റെ വിജയങ്ങളാണെന്നും, എന്നാൽ യഥാർത്ഥ പിശകുകൾ ശരിയായ ഗോൾഡ് ഉത്തരങ്ങൾക്കിടയിൽ മറഞ്ഞിരിക്കുന്നുവെന്നും UIUC പഠനം കാണിക്കുന്നു. ഗോൾഡ് സെറ്റ് ഓഡിറ്റ് ചെയ്യുക, മൂല്യനിർണ്ണയ രീതികൾ (evaluation pipelines) പരിഷ്കരിക്കുക, ബെഞ്ച്മാർക്ക് സ്കോറുകളെ വിപുലമായ ഒരു പരിശോധനാ തന്ത്രത്തിന്റെ ഭാഗമായി മാത്രം കാണുക എന്നിവയിലൂടെ മാത്രമേ പേപ്പറിലെ പുരോഗതി യഥാർത്ഥ ലോകത്തെ വിശ്വാസ്യതയായി മാറ്റാൻ കഴിയൂ.