اعتبارسنجی SQL بدون هزینه‌های مدل زبانی؛ رویکردی قاعده‌مند با TypeScript

اگر اکنون برای هر خطای کوچک در کوئری‌های SQL منتظر پاسخ یک مدل زبانی می‌مانید، باید بدانید که می‌توان این فرآیند را با هزینه صفر و سرعت لحظه‌ای جایگزین کرد. تصور کنید سیستمی داشته باشید که پیش از اجرای هر دستور، مانند یک ویراستار سخت‌گیر، هرگونه غلط املایی یا دستور ناایمن را بگیرد و اصلاح کند. برخلاف اکثر عامل‌های هوش مصنوعی که به توکن‌های گران‌قیمت و مهندسی پرامپت‌های پیچیده متکی هستند، یک عامل بازبینی SQL در مقیاس کامل اکنون می‌تواند بدون هیچ‌کدام از این موارد پیاده‌سازی شود.

به گزارش وب‌سایت dev.to در ۲ ژوئیه ۲۰۲۶، معماری یک پروژه به نام sql-ai-validator-agent منتشر شده است؛ یک API مبتنی بر Node.js و TypeScript که رفتار هوشمند را نه با شبکه عصبی، بلکه از طریق قوانین قطعی (Deterministic Rules) شبیه‌سازی می‌کند. همان‌طور که در تحلیل‌های قبلی ما درباره امنیت مدل‌های بازمتن اشاره کردیم، حذف لایه‌های احتمالی در نقاط حساس امنیتی، همیشه اولویت دارد.

بسیاری از ابزارهای هوش مصنوعی بر تبدیل متن به SQL تمرکز دارند، جایی که کاربر سؤالی به زبان طبیعی می‌پرسد و اپلیکیشن یک دستور SQL تولید می‌کند. اما بزرگ‌ترین نیاز و شکاف موجود برای برنامه‌نویسان، تأیید این نکته است که آیا SQL موجود صحیح، ایمن و با موتور دیتابیس خاص آن‌ها سازگار است یا خیر. پیام‌های خطای سنتی پایگاه‌داده دقیق هستند اما اغلب بیش از حد مبهم و رمزگونه‌اند که مفید باشند. برای مثال، یک غلط املایی ساده مانند SELECT * FORM users ممکن است یک خطای کلی پارسر در نزدیکی کلمه FORM ایجاد کند. اما این عامل (Agent) — مانند یک دستیار دقیق که دفترچه راهنمای دستورات را حفظ است — دقیقاً تشخیص می‌دهد که کلمه FORM احتمالاً اشتباهی در نوشتن FROM است و پیشنهاد اصلاح می‌دهد.

این رویکرد، مرز اعتبارسنجی را تغییر می‌دهد. به جای اینکه اجازه دهیم کوئری در سطح پایگاه‌داده شکست بخورد، عامل آن را به عنوان ورودی غیرقابل‌اعتماد متوقف می‌کند. این لایه حفاظتی از رسیدن دستورات خطرناک به موتور اجرا جلوگیری می‌کند و برای جریان‌های کاری «فقط-خواندنی» یا خط لوله‌های CI/CD حیاتی است. این پروژه عمداً از استفاده از ORM، اتصال به یک دیتابیس واقعی یا فراخوانی OpenAI دوری کرده است تا اجرا، تست و توسعه آن بسیار ساده باشد.

زمینه پروژه و راه‌اندازی

این ابزار آموزشی شامل یک بسته کامل است که یک API مبتنی بر Node.js، یک موتور قاعده‌مند و یک مهارت کدکس (Codex Skill) قابل استفاده مجدد را در اختیار کاربر قرار می‌دهد. این سیستم برای استقرار سریع و تست‌های محلی طراحی شده است. برای راه‌اندازی پروژه، توسعه‌دهندگان می‌توانند مخزن را با دستور git clone https://github.com/cs2026086510-a11y/sql-ai-validator-agent.git دریافت کرده، به پوشه مربوطه بروند و با اجرای npm install پیش‌نیازها را نصب کنند.

پس از نصب وابستگی‌ها، سرور توسعه با دستور npm run dev اجرا می‌شود. API بر روی آدرس http://localhost:3000 میزبانی می‌گردد. برای اطمینان از سلامت سیستم، می‌توان یک بررسی ساده با دستور curl http://localhost:3000/api/health انجام داد که باید یک پاسخ JSON به صورت { "status": "ok" } برگرداند.

معماری فنی

طبق مستندات dev.to، سیستم از یک معماری مجزا (Decoupled) بهره می‌برد تا انعطاف‌پذیری کامل را تضمین کند. سازماندهی مخزن در دایرکتوری src/ بر اساس مسئولیت‌های مشخص به شرح زیر است:

• agent/: شامل explanationAgent.ts برای تولید بازخوردهای قابل درک برای انسان.
• api/: مدیریت درخواست‌ها در routes.ts و تعریف ساختارها در schema.ts.
• types/: تعریف امنیت تایپ‌ها در validation.ts.
• validation/: هسته منطقی اعتبارسنجی در rules.ts (قوانین)، utils.ts (ابزارها) و validator.ts (اعتبارسنج).
• tests/: مجموعه‌های آزمایشی جامع با استفاده از فریم‌ورک Vitest در validator.test.ts.
• docs/: شامل skill/SKILL.md برای ادغام با Codex.
• app.ts و server.ts: مدیریت اپلیکیشن Express و بوت‌استرپ سرور.

جریان درخواست در این سیستم از یک توالی سخت‌گیرانه پیروی می‌کند: درخواست HTTP $ o$ طرح‌واره Zod $ o$ تابع validateSql() $ o$ اجرای runValidationRules() $ o$ اجرای explainValidation() $ o$ پاسخ نهایی JSON.

• طرح‌واره Zod: شکل درخواست HTTP ورودی را اعتبارسنجی می‌کند تا اطمینان حاصل شود که موتور انتخابی (engine) یکی از گوهر-زبان‌های پشتیبانی شده است و کوئری یک رشته متنی Trim شده بین ۱ تا ۱۰,۰۰۰ کاراکتر است. این کار تضمین می‌کند که API پردازش داده‌های خالی یا بیش از حد حجیم را انجام ندهد.
• validateSql(): تابع ارکستراتور اصلی است که کوئری را نرمال‌سازی کرده و بین ماژول‌های قوانین و توضیحات هماهنگی ایجاد می‌کند. این تابع وضعیت نهایی valid را با بررسی اینکه آیا هر یک از خطاها شدت (severity) برابر با "error" دارند یا خیر، تعیین می‌کند.
• runValidationRules(): مجموعه‌ای از بررسی‌های قاعده‌مند را برای شناسایی مشکلات سینتکسی و امنیتی اجرا می‌کند.
• explainValidation(): کدهای خطا را به بازخوردهای دوستانه و قابل درک برای برنامه‌نویس تبدیل می‌کند.
• پاسخ JSON: وضعیت نهایی اعتبار، لیست خطاها و پیشنهادهای اصلاحی را برمی‌گرداند.

مکانیزم‌های تشخیص قاعده‌مند

این اعتبارسنج حدس نمی‌زند؛ بلکه از الگوهای مشخص برای شناسایی نقاط شکست استفاده می‌کند. سیستم با SQL به عنوان ورودی غیرقابل‌اعتماد برخورد کرده و بر چندین حوزه کلیدی تمرکز دارد:

شناسایی خطاهای نوشتاری و سینتکس

• غلط‌های رایج: استفاده از عبارت‌های منظم (Regular Expressions) برای یافتن FORM به جای FROM. سیستم از چک کردن دقیق (/\bFORM\b/i.test(literalSafeSql)) برای یافتن این خطا استفاده می‌کند.
• شکاف‌های سینتکسی: شناسایی ویرگول‌های فراموش‌شده در لیست‌های ساده SELECT، نقل‌قول‌های بسته نشده (unclosed quotes) و پرانتزهای باز.
• خطاهای ساختاری: تشخیص دستورات SELECT که به طور کامل فاقد ستون‌های مورد نیاز هستند.

حفاظ‌های امنیتی

• مسدود کردن دستورات چندگانه: برای جلوگیری از حملات تزریق (Injection)، هرگونه تلاش برای اجرای چند دستور SQL در یک فراخوانی (مثلاً SELECT * FROM users; DROP TABLE users;) صراحتاً مسدود می‌شود. سیستم مرز نقطه-ویرگول (semicolon) را تشخیص داده و ورودی را پیش از رسیدن به موتور اجرا رد می‌کند.
• فرمان‌های ممنوعه: این اعتبارسنج برای بازبینی آموزشی «فقط-خواندنی» طراحی شده است. بنابراین دستورات خواندن-نوشتن و تغییر ساختار شامل DROP, DELETE, UPDATE, INSERT, ALTER و TRUNCATE ممنوع هستند. این امر تضمین می‌کند که ابزار صرفاً به عنوان یک لایه بازبینی ایمن باقی بماند.

سازگاری با گوهر-زبان‌ها (Dialects)

• سیستم از پنج موتور مشخص پشتیبانی می‌کند: ANSI, MySQL, PostgreSQL, Oracle و SQL Server.
• مثال‌های خاص هر موتور: اگر کاربر دستور SELECT TOP 5 * FROM users; را برای PostgreSQL ارسال کند، سیستم آن را نامعتبر اعلام کرده و اشاره می‌کند که TOP در سینتکس PostgreSQL معتبر نیست و پیشنهاد می‌دهد از LIMIT 5 استفاده شود. این موضوع اصطکاک رایج بین سینتکس SQL Server و PostgreSQL را برجسته می‌کند.

برای جلوگیری از مثبت‌های کاذب (False Positives)، موتور ابتدا رشته‌های متنی (String Literals) را پیش از تحلیل حذف می‌کند. این کار تضمین می‌کند که کوئری‌هایی مانند SELECT 'FORM is a word' AS note; به اشتباه به عنوان غلط املایی شناسایی نشوند. این سطح از دقت بدون نیاز به ماهیت احتمالی (stochastic) مدل‌های زبانی بزرگ به دست آمده است.

ماژول توضیحات AI

بخش «هوشمند» این عامل در واقع یک سیستم نگاشت (Mapping) قطعی است. به جای تولید متن لحظه‌ای توسط هوش مصنوعی زاینده، از یک دستور switch در تابع explainError برای نگاشت کدهای خطا به توضیحات ساختاریافته استفاده می‌کند:

• TYPO_FORM: «کلمه کلیدی FORM در این موقعیت معتبر نیست. احتمالاً منظور شما FROM بوده است.»
• MISSING_COMMA: «لیست SELECT دارای شناسه‌های مجاور بدون ویرگول است. SQL انتظار دارد هر عبارت ستون انتخابی به وضوح جدا شود.»
• ENGINE_SPECIFIC: یک رشته پویا برمی‌گرداند: «این SQL از سینتکسی استفاده می‌کند که با [نام موتور] مطابقت ندارد.»

اصلاحات SQL تنها زمانی پیشنهاد می‌شوند که اصلاح قطعی باشد. برای مثال، اگر عامل خطای TYPO_FORM را تشخیص دهد، به طور خودکار کلمه را در فیلد correctedSql با استفاده از ابزار replaceWord جایگزین می‌کند. سیستم عمداً از حدس زدن نام جداول، اختراع ستون‌های گم‌شده یا تغییر منطق تجاری (Business Logic) برای جلوگیری از معرفی باگ‌های جدید دوری می‌کند.

طراحی API و پیاده‌سازی

این پروژه به عنوان یک API مبتنی بر Node.js با نقطه اتصال اصلی POST /api/validate عرضه شده است. بدنه درخواست نیازمند یک engine (مانند "postgresql") و یک query است.

پاسخ سیستم برای هر دو مصرف‌کننده انسانی و ماشینی ساختار یافته است:

{
  "valid": false,
  "engine": "postgresql",
  "errors": [
    {
      "code": "TYPO_FORM",
      "message": "Possible typo detected.",
      "suggestion": "FROM",
      "severity": "error"
    }
  ],
  "explanation": "The keyword FORM is not valid SQL in this position. It looks like you meant FROM.",
  "correctedSql": "SELECT * FROM users;"
}

این ساختار اجازه می‌دهد یک افزونه IDE پیام message را نمایش دهد، یک Job در CI در صورت false بودن valid متوقف شود، یا یک بات در Pull Request، فیلد explanation را به عنوان کامنت بازبینی ارسال کند. مسیر Express به دلیل تفویض تمام منطق به تابع validateSql پس از پارس کردن توسط Zod، بسیار سبک باقی مانده است.

رفتارهای واقعی API

برای تجسم بهتر سیستم، این مثال‌های تعاملی API را در نظر بگیرید:

• سناریوی غلط املایی: درخواستی با SELECT * FORM users; منجر به کد TYPO_FORM و رشته اصلاح‌شده SELECT * FROM users; می‌شود.
• سناریوی فقدان ویرگول: درخواستی برای SELECT id name email FROM users; تحت موتور ansi باعث ایجاد خطای MISSING_COMMA می‌شود و توضیح می‌دهد که شناسه‌های مجاور به جداکننده ویرگول نیاز دارند.
• سناریوی دستور ممنوعه: درخواستی حاوی DROP TABLE users; مقدار valid: false را با کد FORBIDDEN_STATEMENT برمی‌گرداند و صراحتاً اعلام می‌کند که دستورات تغییر ساختار و نوشتن مسدود شده‌اند.
• سناریوی عدم تطابق گوهر-زبانی: استفاده از SELECT TOP 5 * FROM users; با موتور postgresql باعث خطای ENGINE_SPECIFIC شده و پیشنهاد می‌دهد به جای TOP از LIMIT استفاده شود.
• سناریوی کوئری معتبر: یک کوئری استاندارد مانند SELECT id, name FROM users WHERE active = true; مقدار valid: true را با یک آرایه خطای خالی و تایید اعتبار دستور برمی‌گرداند.

ادغام و مقیاس‌دهی

پروژه شامل یک مهارت کدکس (Codex Skill) قابل استفاده مجدد (skill/SKILL.md) است که دستورالعمل‌های عملیاتی برای نحوه تعامل یک هوش مصنوعی مانند Codex با این اعتبارسنج را فراهم می‌کند. این مهارت، گردش کار اعتبارسنجی را در ۸ گام مستند کرده است:

1. نرمال‌سازی فضای خالی بدون تغییر در معنای SQL.
2. اعتبارسنجی شکل درخواست پیش از تحلیل SQL.
3. رد کردن دستورات اجرایی چندگانه.
4. رد کردن دستورات ممنوعه نوشتن یا تغییر ساختار برای جریان‌های کاری فقط-خواندنی.
5. بررسی مشکلات مکانیکی سینتکس.
6. اجرای بررسی‌های خاص هر موتور برای گوهر-زبان انتخاب شده.
7. تولید توضیح بر اساس خطاهای شناسایی شده.
8. پیشنهاد SQL اصلاح‌شده تنها زمانی که اصلاح قطعی باشد.

برای تضمین کیفیت، از Vitest استفاده شده است. گردش کار توسعه‌دهنده شامل این مراحل است: افزودن یک تست شکست‌خورده برای یک مشکل SQL خاص (مانند جریان TYPO_FORM) $ o$ پیاده‌سازی کوچک‌ترین قانون ممکن برای شکار آن $ o$ افزودن یک تست «منفی» برای اطمینان از اینکه قانون بیش از حد سخت‌گیر نیست. یک تست خاص تأیید می‌کند که SELECT * FORM users; منجر به valid: false و کد TYPO_FORM و رشته correctedSql صحیح شود.

این معماری می‌تواند در چندین محیط حرفه‌ای ادغام شود:

• IDEها: یک افزونه می‌تواند هنگام ذخیره فایل، API را فراخوانی کرده و تشخیص‌های لحظه‌ای ارائه دهد.
• خط لوله‌های CI: یک اسکریپت می‌تواند فایل‌های SQL را اسکن کرده و Buildهایی که حاوی دستورات ممنوعه یا خطاهای سینتکسی هستند را مسدود کند.
• بات‌های Pull Request: یک بات می‌تواند فیلدهای explanation و suggestion را به عنوان کامنت ارسال کند تا توسعه‌دهنده را در اصلاح کد راهنمایی کند.
• ابزارهای LLM: یک مدل AI بزرگ‌تر می‌تواند از این اعتبارسنج به عنوان یک ابزار (Tool) برای تأیید ایمنی و صحت SQL تولید شده پیش از ارائه آن به کاربر استفاده کند. مدل پاسخ ساختاریافته را می‌خواند و آن را به کاربر نهایی منتقل می‌کند.

تحلیل: تغییر پارادایم هوش مصنوعی

این پروژه این فرض را به چالش می‌کشد که ویژگی‌های «سبک-AI» لزوماً به شبکه عصبی نیاز دارند. با استفاده از یک موتور قاعده‌مند، توسعه‌دهنده به قابلیت اطمینان ۱۰۰٪ و تأخیر صفر دست یافته است — دو موردی که مدل‌های زبانی بزرگ (LLMs) در محیط‌های عملیاتی SQL با آن‌ها مشکل دارند. برای متخصصان، این به معنای هزینه‌های کمتر و وضعیت امنیتی قابل پیش‌بینی است.

از منظر طراحی سیستم، ارزش واقعی در تفکیک مسئولیت‌هاست. لایه API چیزی از SQL نمی‌داند و موتور قوانین از Express بی‌خبر است. این ماژولار بودن اجازه می‌دهد در آینده، ماژول توضیحات قطعی با یک LLM واقعی جایگزین شود بدون اینکه نیاز به بازنویسی منطق اصلی اعتبارسنجی باشد.

برای توسعه‌دهندگان، این یعنی «عامل‌های هوش مصنوعی» آینده احتمالاً ترکیبی (Hybrid) خواهند بود: یک هسته قطعی برای ایمنی و سینتکس، پوشیده شده در یک پوسته مولد برای ارتباط با انسان. این کار مشکل توهم (Hallucination) — جایی که یک AI ممکن است نام ستونی را پیشنهاد دهد که در واقع در طرح‌واره (Schema) وجود ندارد — را به کلی حل می‌کند.

بهبودهای آتی

برای بهبود بیشتر سیستم، انتقال از عبارت‌های منظم (Regex) به یک پارسر کامل SQL گام منطقی بعدی خواهد بود. این کار عامل را قادر می‌سازد تا کوئری‌های تو در تو، توابع، Joinها و عبارت‌های پیچیده را با قابلیت اطمینان بیشتری مدیریت کند.

سایر بهبودهای پیشنهادی عبارتند از:

• ردیابی موقعیت (Position Tracking): افزودن شماره خط و ستون برای تعیین دقیق محل خطاها جهت استفاده در IDE.
• سیاست‌های پیکربندی‌پذیر: اجازه دادن به تیم‌ها برای سفارشی‌سازی دستورات مسدود شده (مثلاً اجازه INSERT در فایل‌های Migration اما مسدود کردن آن‌ها در داشبوردها).
• ادغام هیبریدی LMM: جایگزینی ماژول توضیحات با یک LLM واقعی در حالی که موتور قوانین به عنوان حفاظ اصلی (Guardrail) باقی بماند. این کار نیازمند حفاظت‌های سخت‌گیرانه در برابر تزریق پرامپت بر اساس «راهنمای پیشگیری از تزریق پرامپت LLM در OWASP» است؛ به گونه‌ای که SQL به عنوان ورودی غیرقابل‌اعتماد تلقی شده، دستورات از محتوای کاربر جدا شوند و خروجی مدل پیش از بازگشت به کاربر اعتبارسنجی شود.

نتیجه‌گیری: تبدیل متن به SQL محبوب است، اما اعتبارسنجی SQL به همان اندازه اهمیت دارد. این پروژه بنیادی برای یک دستیار IDE یا اعتبارسنج CI با استفاده از یک API ساده TypeScript فراهم می‌کند. توسعه‌دهندگان علاقه‌مند می‌توانند پیاده‌سازی کامل، شامل راهنمای Codex Skill را در مخزن گیت‌هاب بررسی کنند: https://github.com/cs2026086510-a11y/sql-ai-validator-agent.git.

گام بعدی شما

• اگر از ابزارهای تولید کد SQL استفاده می‌کنید، یک لایه اعتبارسنجی قطعی (مانند این پروژه) را پیش از اجرای کد قرار دهید.
• مخزن گیت‌هاب پروژه را بررسی کنید تا با نحوه پیاده‌سازی قوانین در TypeScript آشنا شوید.
• برای محیط‌های حساس (Read-only)، لیست دستورات ممنوعه (Forbidden Commands) را در پروژه خود تعریف کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره تراشه‌های Blackwell مراجعه کنید.