University of Illinois Urbana-Champaign ஆய்வுக் குழுவினர், பரவலாகப் பயன்படுத்தப்படும் BIRD Text-to-SQL benchmark-இல் உள்ள பாதிக்கும் மேற்பட்ட annotations தவறாக இருப்பதை கண்டறிந்துள்ளனர். இது பல டெவலப்பர்கள் நம்பியிருக்கும் துல்லியத்தன்மை மதிப்பெண்களின் (accuracy scores) நம்பகத்தன்மையையே கேள்விக்குறியாக்குகிறது.

இந்த benchmark ஏன் முக்கியமானது

ஒரு மாடல் இயற்கை மொழி கேள்வியை (natural-language question) எவ்வாறு SQL query-ஆக மாற்றுகிறது என்பதை அளவிடுவதற்கான தரநிலையாக (de-facto standard) BIRD உள்ளது. ஆய்வுக் கட்டுரைகள், தயாரிப்புத் தரவுகள் மற்றும் வேலைவாய்ப்புத் தேர்வுகள் BIRD மதிப்பெண்களைக் குறிப்பிடுகின்றன. சரியான தன்மையை வரையறுக்கும் "gold" SQL அறிக்கைகள் தவறாக இருந்தால், சிறந்த query-ஐ எழுதும் மாடலுக்குத் தண்டனை வழங்கப்படலாம், அதே சமயம் தவறான gold விடையை அப்படியே நகலெடுக்கும் மாடலுக்கு வெகுமதி அளிக்கப்படலாம்.

பிழை விகிதம் எவ்வாறு கண்டறியப்பட்டது

UIUC குழுவினர் BIRD-dev split-லிருந்து 238 தோல்விகளை ஆய்வு செய்தனர். ஒவ்வொரு மாடல் வெளியீடும் ஏன் தவறாகக் குறிக்கப்பட்டது என்று ஊகிப்பதற்குப் பதிலாக, மாடல் உருவாக்கிய SQL மற்றும் gold reference ஆகியவற்றிற்கு இடையே உள்ள ஒவ்வொரு முரண்பாட்டையும் அவர்கள் கைமுறையாக (manually) அடையாளப்படுத்தினர். அவர்களின் ஆய்வில், 52.8% நிகழ்வுகளில் annotation பிழை இருப்பதை கண்டறிந்தனர்—தவறான SQL, பொருந்தாத schema அல்லது தவறாக வடிவமைக்கப்பட்ட இயற்கை மொழி கேள்வி போன்றவை இதில் அடங்கும்.

ஒன்று முக்கியமான முறை (pattern) அடையாளம் காணப்பட்ட பிழைகளில் 19% பங்களித்தது: gold query-இல் இல்லாத DISTINCT என்பதை மாடல் பயன்படுத்தியது. உதாரணமாக, ஒரு பயனர் அசாதாரண ஆய்வக முடிவுகளைக் (abnormal lab results) கொண்ட நோயாளிகளின் எண்ணிக்கையைக் கேட்கிறார் என்று வைத்துக்கொள்வோம். Gold விடை COUNT(ID) மூலம் வரிசைகளை எண்ணுகிறது. ஒரு நோயாளிக்கு ஐந்து அசாதாரண ஆய்வக முடிவுகள் இருந்தால், gold query ஒருவருக்குப் பதிலாக ஐந்து என்று report செய்யும். ஆனால் மாடலின் COUNT(DISTINCT ID) ஒவ்வொரு நோயாளியையும் சரியாக ஒருமுறை மட்டுமே எண்ணும். இத்தகைய சந்தர்ப்பங்களில், மாடலின் விடை உண்மையான பொருத்துடன் (semantics) ஒத்துப்போயிருந்தாலும், benchmark அதை ஒரு மாடல் பிழையாகப் பதிவு செய்கிறது.

மாடல் மேம்பாட்டில் நிஜ உலகத் தாக்கம்

குறைந்த BIRD மதிப்பெண்களைக் காணும்போது, டெவலப்பர்கள் பெரும்பாலும் prompts-ஐ மாற்றுவது, “don’t use DISTINCT” போன்ற கட்டுப்பாடுகளைச் சேர்ப்பது அல்லது benchmark தரவுகளில் மறுபயிற்சி (retraining) அளிப்பது போன்ற நடவடிக்கைகளை எடுக்கின்றனர். இத்தகைய மாற்றங்கள் அறிக்கையிடப்படும் மதிப்பெண்ணை உயர்த்தலாம், இது முன்னேற்றத்தின் மாயையை உருவாக்குகிறது. UIUC-இன் இந்த ஆய்வு, இந்த "மேம்பாடு" என்பது தவறான விடைத் தாளுக்கு (answer key) ஏற்ப மாடலை overfitting செய்வதாக இருக்கலாம் என்பதைக் காட்டுகிறது. இது உண்மையில் சரியான தர்க்கம் (logic) தேவைப்படும் உண்மையான தரவுத்தளங்களில் (databases) செயல்திறனைப் பாதிக்கக்கூடும்.

ஆய்வாளர்கள் இதற்கு நேர்மாறான சூழலை நிரூபித்தனர். மாடல் மற்றும் gold queries இரண்டையும் ஆய்வு செய்த பிறகு, மாடல் இரண்டு தனித்தனித் தூண்களை (columns) தவறாக ஒன்றாக இணைத்த ஏழு நிகழ்வுகளை அவர்கள் கண்டறிந்தனர். இந்தச் சந்தர்ப்பங்களில் gold SQL சரியாக இருந்தது. ஒரு செம்மைப்படுத்தப்பட்ட prompt மூலம் அந்த உண்மையான பிழைகளை மட்டும் சரிசெய்வதன் மூலம், benchmark மதிப்பெண்ணை செயற்கையாக உயர்த்தாமல் மாடலின் செயல்திறனை அவர்கள் உயர்த்தினர்.

இந்த கண்டுபிடிப்புகள் பங்குதாரர்களுக்கு எதைக் குறிக்கின்றன

  • ஆய்வாளர்கள் (Researchers): BIRD மதிப்பெண்களின் அடிப்படையில் வெளியிடும் ஆய்வறிக்கைகளில், annotation தரத்தைப் பற்றிய எச்சரிக்கை இருக்க வேண்டும். ஆய்வுக் கட்டுரைகளுக்கு இடையிலான ஒப்பீடுகள், உண்மையான முறையியல் முன்னேற்றங்களை விட, benchmark noise-ஐக் கையாளும் மாறுபட்ட அளவீடுகளைப் பிரதிபலிக்கலாம்.
  • தயாரிப்புக் குழுக்கள் (Product teams): தயாரிப்பு வெளியீட்டிற்கான ஒரே அளவுகோலாக BIRD-ஐ மட்டும் நம்பியிருப்பது, தவறான queries-களைப் பிரதிபலிக்கக் கற்றுக் கொண்ட மாடல்களை சந்தைக்குக் கொண்டு செல்லும் அபாயத்தைக் கொண்டுள்ளது. சொந்தமான schemas-களில் (proprietary schemas) நிஜ உலகச் சோதனைகளைச் செய்வது அவசியமாகும்.
  • Benchmark தொகுப்பாளர்கள் (Benchmark curators): இந்த அதிகப்படியான பிழை விகிதம், முறையான மறுஆய்வு (systematic review) அவசியத்தைக் காட்டுகிறது. Gold set-ஐச் சுத்தப்படுத்துவது அல்லது ஒரு இரண்டாம் நிலை "சரிபார்க்கப்பட்ட" (verified) split-ஐ வழங்குவது நம்பிக்கையை மீட்டெடுக்க உதவும்.

ஒரு நடைமுறை தணிக்கை பணிப்பாய்வு (audit workflow)

UIUC குழுவினர் எந்தவொரு Text-to-SQL benchmark-க்கும் பயன்படுத்தக்கூடிய ஒரு எளிய செயல்முறையை முன்மொழிகின்றனர்:

  1. மாடல் உருவாக்கிய மற்றும் gold SQL அறிக்கைகள் இரண்டையும் abstract syntax trees-ஆகப் பகுப்பாய்வு (Parse) செய்யவும்.
  2. தேர்ந்தெடுக்கப்பட்ட columns, filters, joins மற்றும் aggregation functions ஆகியவற்றில் உள்ள வேறுபாடுகளைக் கண்டறிய அவற்றின் கட்டமைப்புகளை ஒன்றிணைக்கவும் (Align).
  3. ஒவ்வொரு வேறுபாட்டையும் (எ.கா. கூடுதல் column, விடுபட்ட filter, தவறான aggregation) அடையாளம் காணவும் (Tag).
  4. ஆதிக்கம் செலுத்தும் பிழை வகைகளைக் கண்டறிய அந்த tags-களை ஒரு histogram-இல் சுருக்கவும் (Summarize).
  5. ஒரு tag-ஐ prompt engineering-க்கான இலக்காகப் பயன்படுத்துவதற்கு முன், அதிகப்படியான நிகழ்வுகள் உள்ள ஒவ்வொரு gold query-யையும் சரிபார்க்கவும் (Validate).

Gold விடை சந்தேகத்திற்கு இடமின்றிச் சரியாக இருக்கும் நிகழ்வுகளில் மட்டும் prompt மாற்றங்களைச் செய்வதன் மூலம், டெவலப்பர்கள் "சிதைந்த அளவுகோலுக்காக மேம்படுத்துதல்" (optimising for a broken metric) என்ற பொறியைத் தவிர்க்கலாம்.

சுருக்கம்

தனது உதாரணங்களில் பாதிக்கும் மேற்பட்டவற்றைத் தவறாகக் குறிக்கும் ஒரு benchmark, நம்பகமான அளவுகோலாகச் செயல்பட முடியாது. BIRD சுட்டிக்காட்டும் பல "பிழைகள்" உண்மையில் மாடலின் வெற்றிகளாக உள்ளன என்பதையும், உண்மையான பிழைகள் சரியான gold விடைக்கு பின்னால் மறைந்துள்ளன என்பதையும் UIUC ஆய்வு காட்டுகிறது. Gold set-ஐத் தணிக்கை செய்வது, evaluation pipelines-ஐச் செம்மைப்படுத்துவது மற்றும் benchmark மதிப்பெண்களை ஒரு விரிவான சரிபார்ப்பு உத்தியின் ஒரு பகுதியாகக் கருதுவது மட்டுமே, காகித அளவில் ஏற்படும் முன்னேற்றங்கள் நிஜ உலகில் நம்பகத்தன்மையை உறுதி செய்ய உதவும் வழிகளாகும்.