اسکریپت‌های Oracle SQL که توسط عوامل مدل‌های زبانی بزرگ (LLM) تولید می‌شوند، ممکن است روی کاغذ بی‌نقص به نظر برسند اما در محیط عملیاتی باعث بروز مشکل‌های جدی شوند. در یک کد پایه قدیمی با ۲.۳ میلیون خط، یک عامل مبتنی بر هوش مصنوعی به‌طور مکرر شناسه‌هایی را وارد می‌کرد که وجود نداشتند – برای مثال، استفاده از ستون POLICY_STATUS به جای ستون واقعی STATUS_CD یا ارجاع به جدول غیرموجود CUSTOMERS به جای CUSTOMER.

اجرای اسکریپت برای یافتن غلط‌های تایپی در دستورات UPDATE یا DELETE گزینه‌ی مناسبی نیست. اجرای آن‌ها روی یک مجموعه داده مشابه محیط عملیاتی باعث ایجاد قفل (lock)، مصرف شماره‌های توالی (sequence numbers) و می‌تواند اثرات جانبی زنجیره‌ای به همراه داشته باشد. توسعه‌دهندگان به راهی نیاز دارند تا نام‌ها و نحو (syntax) را بدون دستکاری داده‌ها اعتبارسنجی کنند. پاسخ، که به طرز شگفت‌آوری ساده است، دستور EXPLAIN PLAN اوراکل است که در اینجا به عنوان یک مرحله‌ی لینتینگ (linting) بازتعریف شده است.

نحوه عملکرد EXPLAIN PLAN به عنوان یک اعتبارسنج سریع

وقتی اوراکل یک دستور را دریافت می‌کند، ابتدا آن را تجزیه (parse) می‌کند. فرآیند تجزیه بررسی می‌کند که آیا هر جدول، ستون و سطح دسترسیِ ارجاع‌شده وجود دارد یا خیر، سپس یک طرح اجرا (execution plan) می‌سازد و آن طرح را در یک جدول سیستمی می‌نویسد. این دستور هرگز دستور را اجرا نمی‌کند: هیچ ردیفی تغییر نمی‌کند، هیچ تریگری (trigger) اجرا نمی‌شود و هیچ قفلی ایجاد نمی‌گردد. اگر تجزیه‌کننده به یک شیء ناشناخته برخورد کند، در عرض چند میلی‌ثانیه خطا صادر می‌کند.

این رفتار، EXPLAIN PLAN را به یک بررسی پیش‌پرواز (pre-flight check) عالی برای SQL تولید شده توسط هوش مصنوعی تبدیل می‌کند. اگر جدول یا ستونی وجود نداشته باشد، بلافاصله گزارش می‌شود و به حلقه‌ی تولید دستور اجازه می‌دهد تا قبل از اینکه اسکریپت به دست انسان برسد، خطا را اصلاح کند.

گردش کاری که من در خط لوله CI خود پیاده کردم

  1. تجزیه (Split) اسکریپت ورودی به دستورات مجزا.
  2. اجرای EXPLAIN PLAN FOR <statement> روی یک شمای توسعه (development schema).
  3. جمع‌آوری هرگونه خطای تجزیه‌ای که اوراکل برمی‌گرداند.
  4. بازگرداندن خطاها به LLM برای تلاش مجدد.

در عمل، تنها یک تلاش مجدد اکثر خطاهای نام‌گذاری را برطرف می‌کند. هوش مصنوعی شمای صحیح را یاد می‌گیرد و خروجی خود را به‌طور خودکار تنظیم می‌کند. من همچنین عامل را در حالت فقط‌خواندنی (read-only) محدود می‌کنم: عامل می‌تواند دستورات SELECT و فراخوانی‌های EXPLAIN PLAN را صادر کند، اما دستورات DDL ،DML و COMMIT مسدود هستند. این محیط ایزوله (sandbox) تضمین می‌کند که در حالی که هوش مصنوعی ساختار پایگاه داده را بررسی می‌کند، داده‌ها دست‌نخورده باقی بمانند.

فراتر از بررسی نام‌ها، طرح تولید شده، هشدارهای عملکردی (performance red flags) آشکاری را نیز نشان می‌دهد. اگر یک دستور باعث اسکن کامل جدول (full-table scan) روی یک جدول بسیار بزرگ شود، این طرح قبل از اینکه با هر ردیفی برخورد شود آن را نشان می‌دهد و به توسعه‌دهندگان فرصت می‌دهد تا پیشنهاد ایجاد ایندکس یا بازنویسی شرط (predicate) را بدهند.

محدودیت‌های این رویکرد

  • درستی منطقی تأیید نمی‌شود. دستوری که به ستون‌های درست ارجاع می‌دهد اما فیلتر اشتباهی را اعمال می‌کند، همچنان از مرحله لینتینگ عبور می‌کند.
  • بلاک‌های PL/SQL خارج از محدوده هستند. تجزیه‌کننده فقط دستورات مجزای SQL را مدیریت می‌کند؛ کدهای رویه‌ای (procedural code) به یک مسیر اعتبارسنجی جداگانه نیاز دارند.
  • اعتبارسنجی در سطح داده‌ها وجود ندارد. لینت نمی‌تواند به شما بگوید که آیا یک مقدار ثابت (literal value) با دامنه یک ستون مطابقت دارد یا اینکه آیا یک ارجاع کلید خارجی (foreign-key) واقعاً وجود دارد یا خیر.
  • فقط شمای توسعه. خطاهایی که فقط در محیط عملیاتی ظاهر می‌شوند – برای مثال، جدولی که در محیط توسعه وجود دارد اما در محیط عملیاتی تغییر نام یافته است – تا زمان‌های بعدی نامرئی باقی می‌مانند.

این شکاف‌ها از کاربردی بودن این روش نمی‌کاهند؛ آن‌ها صرفاً مرزهای آن را تعریف می‌کنند. برای اکثر اسکریپت‌های DML تولید شده توسط LLM، رایج‌ترین حالت شکست، یک غلط تایپی یا نام اشتباه یک شیء است و این دقیقاً همان چیزی است که EXPLAIN PLAN آن را شناسایی می‌کند.

قابلیت انتقال به سایر موتورهای پایگاه داده

همین اصل فراتر از اوراکل نیز صدق می‌کند. دستور PREPARE یا EXPLAIN در PostgreSQL می‌تواند یک پرس‌وجو (query) را بدون اجرا تجزیه کند. SQL Server دستور SET PARSEONLY ON را ارائه می‌دهد که موتور را مجبور می‌کند نحو و نام اشیاء را تأیید کند در حالی که از پردازش واقعی صرف‌نظر می‌کند. هر RDBMS که تجزیه را از اجرا جدا می‌کند، می‌تواند به یک دروازه‌ی لینتینگ سبک تبدیل شود.

نتیجه‌گیری

اجرای EXPLAIN PLAN (یا معادل آن) روی هر دستور SQL تولید شده توسط هوش مصنوعی، یک تجزیه‌کننده پایگاه داده را به یک دروازه‌ی لینتینگ ارزان و بدون ریسک تبدیل می‌کند. این کار رایج‌ترین خطاهای نام‌گذاری و نحو را قبل از هرگونه جابجایی داده‌ها شناسایی می‌کند، سیستم‌های قدیمی را پایدار نگه می‌دارد و در عین حال به توسعه‌دهندگان اجازه می‌دهد از افزایش بهره‌وری کدنویسی با کمک LLM بهره‌مند شوند.