ലാർജ്-ലാംഗ്വേജ്-മോഡൽ (LLM) ഏജന്റുകൾ തയ്യാറാക്കുന്ന Oracle SQL സ്ക്രിപ്റ്റുകൾ പേപ്പറിൽ നോക്കുമ്പോൾ തികഞ്ഞവയായി തോന്നാമെങ്കിലും പ്രൊഡക്ഷനിൽ വലിയ പ്രശ്നങ്ങൾ ഉണ്ടാക്കിയേക്കാം. 2.3 മില്യൺ വരികളുള്ള ഒരു ലെഗസി കോഡ്ബേസിൽ, ഒരു AI-ഡ്രൈവൻ ഏജന്റ് നിലവിലില്ലാത്ത ഐഡന്റിഫയറുകൾ പതിവായി ഉൾപ്പെടുത്തുന്നുണ്ടായിരുന്നു - ഉദാഹരണത്തിന്, യഥാർത്ഥ STATUS_CD കോളത്തിന് പകരം POLICY_STATUS ഉപയോഗിക്കുകയോ, CUSTOMER എന്നതിന് പകരം നിലവിലില്ലാത്ത CUSTOMERS എന്ന ടേബിളിനെ പരാമർശിക്കുകയോ ചെയ്യുന്നു.

ടൈപ്പോകൾ (typos) കണ്ടെത്താനായി സ്ക്രിപ്റ്റ് റൺ ചെയ്യുന്നത് UPDATE അല്ലെങ്കിൽ DELETE സ്റ്റേറ്റ്‌മെന്റുകളുടെ കാര്യത്തിൽ ഒരു ഓപ്ഷനല്ല. പ്രൊഡക്ഷൻ പോലുള്ള ഒരു ഡാറ്റാസെറ്റിൽ അവ പ്രവർത്തിപ്പിക്കുന്നത് ലോക്കുകൾ (locks) ഉണ്ടാക്കാനും, സീക്വൻസ് നമ്പറുകൾ ഉപയോഗിച്ചു തീർക്കാനും, മറ്റ് പാർശ്വഫലങ്ങൾ (cascading side-effects) ഉണ്ടാക്കാനും കാരണമാകും. ഡാറ്റയിൽ മാറ്റം വരുത്താതെ തന്നെ പേരുകളും സിന്റാക്സും (syntax) പരിശോധിക്കാൻ ഡെവലപ്പർമാർക്ക് ഒരു മാർഗ്ഗമുണ്ട്. അതിന് ലളിതമായ ഒരു പരിഹാരമാണ് Oracle-ന്റെ EXPLAIN PLAN കമാൻഡ് - ഇതിനെ ഒരു ലിന്റിംഗ് (linting) ഘട്ടമായി ഉപയോഗിക്കാം.

ഒരു വേഗത്തിലുള്ള വാലിഡേറ്ററായി EXPLAIN PLAN എങ്ങനെ പ്രവർത്തിക്കുന്നു

Oracle ഒരു സ്റ്റേറ്റ്‌മെന്റ് സ്വീകരിക്കുമ്പോൾ, അത് ആദ്യം പാഴ്സ് (parse) ചെയ്യുന്നു. പാഴ്സിംഗ് പ്രക്രിയയിലൂടെ പരാമർശിച്ചിരിക്കുന്ന എല്ലാ ടേബിളുകളും കോളങ്ങളും പ്രിവിലേജുകളും (privileges) നിലവിലുണ്ടോ എന്ന് പരിശോധിക്കുന്നു, തുടർന്ന് ഒരു എക്സിക്യൂഷൻ പ്ലാൻ (execution plan) നിർമ്മിക്കുകയും ആ പ്ലാൻ ഒരു സിസ്റ്റം ടേബിളിൽ എഴുതുകയും ചെയ്യുന്നു. ഈ കമാൻഡ് ഒരിക്കലും സ്റ്റേറ്റ്‌മെന്റ് പ്രവർത്തിപ്പിക്കില്ല: റോകൾ (rows) മാറ്റപ്പെടില്ല, ട്രിഗറുകൾ (triggers) പ്രവർത്തിക്കില്ല, ലോക്കുകൾ എടുക്കപ്പെടുകയുമില്ല. പാഴ്സറിന് അറിയപ്പെടാത്ത ഒരു ഒബ്‌ജക്റ്റ് ലഭിച്ചാൽ, ഏതാനും മില്ലിസെക്കൻഡുകൾക്കുള്ളിൽ അത് ഒരു എറർ (error) കാണിക്കുന്നു.

ഈ സ്വഭാവം AI-ജനറേറ്റഡ് SQL-ന് ഒരു മികച്ച പ്രീ-ഫ്ലൈറ്റ് ചെക്ക് (pre-flight check) ആയി EXPLAIN PLAN-നെ മാറ്റുന്നു. ഒരു ടേബിളോ കോളമോ വിട്ടുപോയിട്ടുണ്ടെങ്കിൽ അത് ഉടൻ തന്നെ റിപ്പോർട്ട് ചെയ്യപ്പെടുന്നു, ഇത് ഒരു മനുഷ്യൻ സ്ക്രിപ്റ്റ് കാണുന്നതിന് മുമ്പ് തന്നെ പിശക് തിരുത്താൻ ജനറേഷൻ ലൂപ്പിനെ സഹായിക്കുന്നു.

എന്റെ CI പൈപ്പ്‌ലൈനിൽ ഞാൻ ക്രമീകരിച്ച വർക്ക്ഫ്ലോ (workflow)

  1. വരുന്ന സ്ക്രിപ്റ്റിനെ ഓരോ സ്റ്റേറ്റ്‌മെന്റുകളായി വിഭജിക്കുക (Split).
  2. ഒരു ഡെവലപ്‌മെന്റ് സ്കീമയിൽ (development schema) EXPLAIN PLAN FOR <statement> പ്രവർത്തിപ്പിക്കുക (Run).
  3. Oracle നൽകുന്ന പാഴ്സിംഗ് എററുകൾ ശേഖരിക്കുക (Collect).
  4. ഈ എററുകൾ വീണ്ടും ശ്രമിക്കുന്നതിനായി (retry) LLM-ലേക്ക് നൽകുക (Feed).

പ്രായോഗികമായി പറഞ്ഞാൽ, ഒരു തവണ വീണ്ടും ശ്രമിക്കുന്നത് തന്നെ ഭൂരിഭാഗം പേരിംഗ് (naming) പിശകുകളും പരിഹരിക്കാൻ സഹായിക്കും. ശരിയായ സ്കീമ എന്താണെന്ന് AI പഠിക്കുകയും അതിന്റെ ഔട്ട്‌പുട്ട് സ്വയം ക്രമീകരിക്കുകയും ചെയ്യുന്നു. ഞാൻ ഏജന്റിനെ റീഡ്-ഓൺലി (read-only) മോഡിൽ ലോക്ക് ചെയ്തിട്ടുമുണ്ട്: അതിന് SELECT-കളും EXPLAIN PLAN കോളുകളും നൽകാൻ കഴിയും, എന്നാൽ DDL, DML, COMMIT എന്നിവ തടയപ്പെട്ടിരിക്കും. ഈ സാൻഡ്ബോക്സ് (sandbox) ഡാറ്റാബേസ് മാറ്റമില്ലാതെ നിലനിൽക്കുന്നുവെന്ന് ഉറപ്പാക്കുന്നു.

പേര് പരിശോധനകൾക്ക് പുറമെ, ജനറേറ്റ് ചെയ്ത പ്ലാൻ പെർഫോമൻസ് സംബന്ധമായ പ്രശ്നങ്ങളും (performance red flags) വെളിപ്പെടുത്തുന്നു. ഒരു വലിയ ടേബിളിൽ സ്റ്റേറ്റ്‌മെന്റ് ഒരു ഫുൾ-ടേബിൾ സ്കാൻ (full-table scan) ഉണ്ടാക്കുമെങ്കിൽ, ഡാറ്റയിൽ മാറ്റം വരുത്തുന്നതിന് മുമ്പ് തന്നെ പ്ലാൻ അത് കാണിച്ചുതരുന്നു. ഇത് ഇൻഡക്സുകൾ (indexes) നിർദ്ദേശിക്കാനോ പ്രെഡിക്കേറ്റ് (predicate) മാറ്റിയെഴുതാനോ ഡെവലപ്പർമാർക്ക് അവസരം നൽകുന്നു.

ഈ രീതിയുടെ പരിമിതികൾ

  • ലോജിക്കൽ കൃത്യത (Logical correctness) പരിശോധിക്കപ്പെടുന്നില്ല. ശരിയായ കോളങ്ങൾ ഉപയോഗിക്കുന്നുണ്ടെങ്കിലും തെറ്റായ ഫിൽട്ടർ ഉപയോഗിക്കുന്ന ഒരു സ്റ്റേറ്റ്‌മെന്റ് ഈ പരിശോധനയിൽ വിജയിച്ചേക്കാം.
  • PL/SQL ബ്ലോക്കുകൾ ഇതിൽ ഉൾപ്പെടുന്നില്ല. പാഴ്സർ വ്യക്തിഗത SQL സ്റ്റേറ്റ്‌മെന്റുകൾ മാത്രമേ കൈകാര്യം ചെയ്യുകയുള്ളൂ; പ്രൊസീജറൽ കോഡിന് (procedural code) പ്രത്യേക പരിശോധന ആവശ്യമാണ്.
  • ഡാറ്റാ ലെവൽ വാലിഡേഷൻ ഇല്ല. ഒരു വാല്യൂ കോളത്തിന്റെ ഡൊമെയ്‌നുമായി (domain) യോജിക്കുന്നുണ്ടോ എന്നോ അല്ലെങ്കിൽ ഒരു ഫോറിൻ കീ (foreign-key) റഫറൻസ് നിലവിലുണ്ടോ എന്നോ ഈ പരിശോധനയ്ക്ക് പറയാൻ കഴിയില്ല.
  • ഡെവ സ്കീമ (Dev schema) മാത്രം. പ്രൊഡക്ഷനിൽ മാത്രം കാണുന്ന പിശകുകൾ - ഉദാഹരണത്തിന്, ഡെവൽപ്‌മെന്റിൽ ഉള്ള ഒരു ടേബിൾ പ്രൊഡക്ഷനിൽ മാറ്റം വരുത്തിയിട്ടുണ്ടെങ്കിൽ - പിന്നീട് പരിശോധിക്കുന്നത് വരെ കണ്ടെത്താൻ കഴിയില്ല.

ഈ കുറവുകൾ ഈ രീതിയുടെ ഉപയോഗക്ഷമത കുറയ്ക്കുന്നില്ല; അവ ഇതിന്റെ പരിധി നിർവചിക്കുക മാത്രമാണ് ചെയ്യുന്നത്. മിക്ക LLM-ജനറേറ്റഡ് DML സ്ക്രിപ്റ്റുകളിലും ഏറ്റവും സാധാരണമായ പരാജയം ടൈപ്പോകളോ തെറ്റായ ഒബ്‌ജക്റ്റ് പേരോ ആണ്, അത് EXPLAIN PLAN കൃത്യമായി കണ്ടെത്തുന്നു.

മറ്റ് ഡാറ്റാബേസ് എഞ്ചിനുകളിലേക്കുള്ള മാറ്റം (Portability)

ഇതേ തത്വം Oracle-ന് പുറമെ മറ്റ് ഡാറ്റാബേസുകൾക്കും ബാധകമാണ്. PostgreSQL-ലെ PREPARE സ്റ്റേറ്റ്‌മെന്റോ EXPLAIN-ഓ ഉപയോഗിച്ച് ഒരു ക്വറി പ്രവർത്തിപ്പിക്കാതെ തന്നെ പാഴ്സ് ചെയ്യാം. SQL Server-ൽ SET PARSEONLY ON എന്ന ഓപ്ഷനുണ്ട്, ഇത് യഥാർത്ഥ പ്രോസസ്സിംഗ് ഒഴിവാക്കി സിന്റാക്സും ഒബ്‌ജക്റ്റ് പേരുകളും പരിശോധിക്കാൻ എഞ്ചിനെ നിർബന്ധിക്കുന്നു. പാഴ്സിംഗും എക്സിക്യൂഷനും വേർതിരിക്കുന്ന ഏത് RDBMS-ഉം ഒരു ലഘുവായ ലിന്റിംഗ് ഗേറ്റായി (linting gate) ഉപയോഗിക്കാം.

ചുരുക്കത്തിൽ (Takeaway)

ഓരോ AI-ജനറേറ്റഡ് SQL സ്റ്റേറ്റ്‌മെന്റിലും EXPLAIN PLAN (അല്ലെങ്കിൽ അതിന് തുല്യമായവ) പ്രവർത്തിപ്പിക്കുന്നത് ഡാറ്റാബേസ് പാഴ്സറിനെ കുറഞ്ഞ ചിലവിലുള്ള, അപകടസാധ്യതയില്ലാത്ത ഒരു ലിന്റിംഗ് ഗേറ്റാക്കി മാറ്റുന്നു. ഡാറ്റയിൽ മാറ്റം വരുന്നതിന് മുമ്പ് തന്നെ ഏറ്റവും സാധാരണമായ പേരിംഗ്, സിന്റാക്സ് പിശകുകൾ ഇത് കണ്ടെത്തുന്നു. ഇത് ലെഗസി സിസ്റ്റങ്ങളെ സുരക്ഷിതമായി നിലനിർത്തുന്നതോടൊപ്പം, LLM സഹായത്തോടെയുള്ള കോഡിംഗിലൂടെ ഡെവലപ്പർമാർക്ക് ഉൽപ്പാദനക്ഷമത വർദ്ധിപ്പിക്കാനും സഹായിക്കുന്നു.