Igenerated SQL کے خلاف دلیل

ماڈل کو نہیں چاہیے
SQL لکھنا۔

Text-to-SQL کسی ایجنٹ کو ڈیٹابیس سے جوڑنے کا واضح طریقہ ہے، اور demo واقعی متاثر کن ہوتا ہے۔ پروڈکشن میں معاملہ پلٹتا ہے: ایک ہی سوال مختلف SQL میں ڈھلتا ہے، ایک خاموش join کی غلطی آمدنی 15% بدل دیتی ہے، اور ماڈل کا آؤٹ پٹ ایک attack surface بن جاتا ہے۔ ایک اور راستہ موجود ہے۔

IIپہلے اعتراف

Text-to-SQL نے شہرت کمائی — اپنی حد میں۔

جہاں یہ صحیح ذریعہ ہے

  • عارضی ڈیٹا پر پروٹوٹائپ
  • انجان اسکیما کی تلاش، انسانی نگرانی میں
  • ایک بار کے سوالات جن کی تصدیق ہو سکے
  • ڈیمو — واقعی ڈیمو میں بہترین ہے

جہاں یہ ناکام ہوتا ہے

  • وہ اعداد جن پر عمل کیا جائے گا
  • سیاق میں کہیں بھی غیر بھروسہ مند متن
  • کنکشن پر پروڈکشن اسناد
  • وہ جوابات جو قابلِ تکرار یا قابلِ آڈٹ ہونے چاہئیں
  • ایجنٹ جو بغیر نگرانی کے چلتے ہیں

طریقہ غلط نہیں۔ نقصان کا دائرہ غلط ہے۔ اس صفحے کا ہر خطرہ ایک ڈیزائن انتخاب سے جنم لیتا ہے: ماڈل کا آؤٹ پٹ بطور کوڈ چلایا جاتا ہے۔

IIIدو راستے

ایک سوال۔ دو آرکیٹیکچر۔

ایک سوال کو دونوں راستوں پر دیکھیں — بائیں طرف آزاد SQL سٹرنگ، دائیں طرف ٹائپڈ پلان۔ نمبر والے نشان نیچے خطرے کے رجسٹر میں اشارہ کرتے ہیں۔

سوال

“کس علاقے کی کل آمدنی سب سے زیادہ ہے؟”

Path A

ماڈل SQL لکھتا ہے

  1. ماڈل ایک سٹرنگ بناتا ہے 010304

    ماڈل نے جو کچھ پڑھا — صارف کا پیغام، کوئی بازیافت شدہ قطار — یہ سب اس سٹرنگ کو متاثر کر سکتا ہے۔

    رن 1SELECT region, SUM(total) FROM orders GROUP BY region;رن 2 · وہی سوالSELECT o.region, SUM(i.amount) FROM orders o LEFT JOIN order_items i ON i.order_id = o.id GROUP BY 1;
  2. آپ کا کنکشن اسے چلاتا ہے 05

    کنکشن کے پوری اختیار کے ساتھ۔ پڑھنا، جوائن — اور جب تک کوئی فلیگ یاد نہ رکھے، لکھنا بھی۔

جواب

run 1 → east · 2130.50

run 2 → east · 2450.08+15% — جوائن فین-آؤٹ 02

دو رن، دو اعداد۔ دونوں قابلِ یقین۔ کوئی اشارہ نہیں کہ کون سا — اگر کوئی — درست ہے۔

Path B

ماڈل ٹائپڈ پلان جمع کرتا ہے

  1. ٹائپڈ ارادہ

    سٹرنگ نہیں — اسکیما کے ساتھ ایک قدر۔ یہ صرف وہی آپریشن نام لے سکتا ہے جو معاہدہ متعین کرتا ہے۔

    { "kind": "query", "version": "1", "source": "revenue", "op": "sum", "group_by": "region" }
  2. معاہدے کی جانچ

    ہیش سے پن کردہ۔ نامعلوم آپریشن unsupported_operation اور قریب ترین متبادل لوٹاتا ہے — کبھی اندازہ نہیں۔

  3. پالیسی جانچ

    آپ کی کوڈ سطح کی اجازت فہرست۔ درخواست دائرہ تنگ کر سکتی ہے، کبھی وسیع نہیں۔

  4. قطعی عمل

    float64، سنگل تھریڈ، پن کردہ رن ٹائم۔ ایک پلان، ایک بائٹس، ایک جواب۔

جواب

east · 2130.50

plan_hash f87610d8afeb…

decision_path "exact_spec"

ایک جواب، ہیش کے ساتھ جو اسے دوبارہ چلانے دیں — اگلے ہفتے، اگلی سہ ماہی، کسی بھی زبان میں۔

IVخطرے کا رجسٹر

پانچ طریقے جن سے SQL غلط ہوتی ہے

  1. 01

    P2SQLarXiv 2308.01990

    انجیکشن آؤٹ پٹ چینل میں منتقل ہو گئی

    ان پٹ سینیٹائزیشن وہ دیکھتی ہے جو ماڈل میں جاتا ہے۔ P2SQL حملے وہاں سے آتے ہیں جو باہر آتا ہے: درست شکل کی، نقصان دہ SQL جو صارف کے پیغام یا بازیافت شدہ قطار میں چھپی ہدایات سے بنتی ہے۔ کوئی ان پٹ فلٹر اسے کبھی نہیں دیکھتا — حملہ خود آؤٹ پٹ ہے۔

  2. 02

    −15%وہ ڈیش بورڈ جس نے جھوٹ بولا

    غلط جوائن خاموشی سے ناکام ہوتے ہیں

    فین آؤٹ جوائن قطاریں دوہری گنتا ہے، اور آمدنی 15% غلط دکھتی ہے۔ کوئی استثنا نہیں، کوئی انتباہ نہیں — غلط SQL کریش نہیں کرتی، رپورٹ کرتی ہے۔ نتیجہ ہمیشہ ایک عدد ہوتا ہے، اور قابلِ یقین عدد میں کوئی اشارہ نہیں کہ وہ غلط ہے۔

  3. 03

    1 → nایک سوال، n کوئریاں

    ایک سوال، مختلف SQL

    دو بار پوچھیں اور ماڈل سوال کو دو مختلف طریقوں سے مرتب کر سکتا ہے — کبھی کبھی دو مختلف جوابوں تک۔ جائزے، کیشنگ، یا دوبارہ چلانے کے لیے کوئی معیاری کوئری نہیں۔ کل کا عدد دوبارہ حاصل نہیں کیا جا سکتا، چاہے صرف جانچنا ہو۔

  4. 04

    91.2 → 21.3% درست · بینچ مارک → انٹرپرائز اسکیما

    درستگی کی کھائی

    صاف بینچ مارک اسکیموں پر، ایک فرنٹیئر ماڈل نے 91.2% وقت درست SQL لکھی۔ حقیقی انٹرپرائز اسکیموں پر: 21.3%۔ اسی تحقیقی لہر میں، text-to-SQL ایجنٹ رنز کا تقریباً 40% یا تو مکمل ناکام ہوا یا غلط نتائج دیے۔ بینچ مارک صاف ستھرے ہوتے ہیں۔ آپ کا اسکیما نہیں۔

  5. 05

    1 prod DBایک ایجنٹ نے حذف کی — Replit واقعہ

    لکھنے کا راستہ ہمیشہ موجود تھا

    Replit کے کوڈنگ ایجنٹ نے صریح ہدایات کے باوجود پروڈکشن ڈیٹابیس حذف کر دی۔ سبق یہ ہے: صرف پڑھنے کی ہدایت ایک گزارش ہے۔ اگر کنکشن لکھ سکتا ہے تو لکھنے کا راستہ موجود ہے، اور بالآخر کوئی نہ کوئی خراب تکمیل اسے ڈھونڈ لیتی ہے۔ صرف پڑھنا ٹول کی خاصیت ہونی چاہیے، پرامپٹ کی سطر نہیں۔

آؤٹ پٹ کو فلٹر نہ کریں۔
اسے تخلیق ہی نہ کریں۔

نہ SQL سٹرنگ، نہ انجیکشن · نہ اندازہ، نہ انحراف

Vسرٹیفکیٹ

پانچ جہات، پہلو بہ پہلو

LLM-to-SQL جنریٹر نہیںانجن README

فرق کا سرٹیفکیٹ

تصنیف کی سطحتخلیق شدہ SQLایک آزاد SQL سٹرنگٹائپڈ پلانایک ٹائپڈ، ورژن شدہ ارادہ
اجرا کی سطحتخلیق شدہ SQLجو کچھ کنکشن اجازت دےٹائپڈ پلان4,574 صرف پڑھنے کی صلاحیتیں
لکھنے کا راستہتخلیق شدہ SQLموجود، جب تک بلاک نہ ہوٹائپڈ پلانساخت کے اعتبار سے ناموجود
گورننستخلیق شدہ SQLپرامپٹ سطح، بہترین کوششٹائپڈ پلانکوڈ سطح کی اجازت فہرستیں جنہیں ماڈل وسیع نہیں کر سکتا
دوبارہ پیداواریتتخلیق شدہ SQLکوئی نہیںٹائپڈ پلانہر نتیجے پر ایک ری پلے ہیش

دایاں کالم معاہدے سے منسلکsha256:79f1c5a6…924be9a1

باریک حروف بھی قائم رہتے ہیں: انجن کا واحد فرار راستہ — getUnsafeRuntime — ماڈل کے سامنے آنے والی کسی بھی سطح پر موجود نہیں، لہٰذا ماڈل اس تک نہیں پہنچ سکتا۔ اور README اصول کو صاف بیان کرتا ہے: یہ LLM-to-SQL جنریٹر نہیں ہے۔

VIسوالات

پروڈکشن میں پوچھے گئے

LLM سے تخلیق شدہ SQL میں DELETE اور DROP کو کیسے روکوں؟

SQL کو فلٹر نہ کریں — اسے تخلیق کرنا بند کریں۔ ڈینی لسٹیں سٹرنگز کا معائنہ کرتی ہیں، اور ماڈل نئی سٹرنگز بنانے میں لامحدود تخلیقی ہیں۔ SQAI پوری کلاس کو ہٹا دیتا ہے: ماڈل 4,574 صرف پڑھنے کی صلاحیتوں کے خلاف ایک ٹائپڈ پلان داخل کرتا ہے، اور کسی بھی پلان کے لیے کوئی لکھنے کی صلاحیت موجود نہیں۔

P2SQL انجیکشن کیا ہے؟

Prompt-to-SQL انجیکشن: نقصاندہ SQL جو ماڈل کے آؤٹ پٹ میں ظاہر ہوتی ہے، ان ہدایات سے مرتب ہو کر جو ماڈل نے پڑھی — صارف کا پیغام، کوئی دستاویز، یا کوئی بازیافت شدہ قطار۔ ان پٹ صفائی اسے کبھی نہیں دیکھتی، کیونکہ حملہ آؤٹ پٹ چینل میں رہتا ہے۔ یہ arXiv 2308.01990 میں درج ہے۔

کیا text-to-SQL کبھی درست انتخاب ہے؟

ہاں — پروٹوٹائپس اور غیر پروڈکشن ڈیٹا پر نگرانی شدہ تحقیق کے لیے یہ تیز اور واقعی مفید ہے۔ غلط انتخاب تب ہوتا ہے جب نتیجے پر عمل کیا جانا ہو، سیاق میں غیر بھروسہ مند متن ہو، یا جواب قابل تکرار ہونا ضروری ہو۔

AI ایجنٹ کو ڈیٹابیس تک صرف پڑھنے کی رسائی کیسے دوں؟

صرف پڑھنے کو ساختی بنائیں، محض ترتیب شدہ نہیں۔ کنکشن پر صرف پڑھنے کا جھنڈا ایک ایسی ترتیب ہے جسے کوئی بدل سکتا ہے۔ SQAI کی اجرا کی سطح میں صرف پڑھنے کی صلاحیتیں ہیں — لکھنے کا راستہ ساخت کے اعتبار سے غائب ہے، اور انجن کا فرار راستہ بھی کسی ماڈل کے سامنے آنے والے ٹول سے ناقابل رسائی ہے۔

ٹائپڈ پلان تخلیق شدہ SQL سے کیسے مختلف ہے؟

SQL سٹرنگ وہ سب کچھ کہہ سکتی ہے جو گرامر اجازت دے۔ ٹائپڈ پلان صرف وہی کہہ سکتا ہے جو معاہدہ متعین کرے۔ ہر پلان کو ہیش سے منسلک معاہدے کے خلاف تصدیق کیا جاتا ہے، آپ کی اجازت فہرست پالیسی کے خلاف جانچا جاتا ہے، اور ایک تعین پذیر انجن پر چلایا جاتا ہے — ہر نتیجے پر ری پلے ہیش کے ساتھ۔

دوسرا راستہ اختیار کریں۔

کوئی اکاؤنٹ نہیں۔ کوئی کلید نہیں۔ مقامی ڈیٹا مقامی رہتا ہے۔

دستاویزات پڑھیں →