Iजेनेरेटेड SQL के विरुद्ध तर्क

मॉडल को नहीं लिखना चाहिए
SQL।

Text-to-SQL किसी एजेंट को डेटाबेस से जोड़ने का स्पष्ट तरीका है, और डेमो वाकई प्रभावशाली होता है। उत्पादन में यह पलटता है: एक ही प्रश्न अलग SQL में संकलित होता है, एक मौन join त्रुटि राजस्व को 15% खिसका देती है, और मॉडल का आउटपुट एक attack surface बन जाता है। एक और रास्ता है।

IIपहले श्रेय

Text-to-SQL की तारीफ बनती है — अपनी सीमा में।

जहाँ यह सही औज़ार है

  • अस्थायी डेटा पर प्रोटोटाइप
  • अपरिचित schema की पड़ताल, इंसान की निगरानी में
  • एकबारगी सवाल जिसे कोई जाँचेगा
  • डेमो — और डेमो में यह वाकई अच्छा लगता है

जहाँ यह टूटता है

  • वे संख्याएँ जिन पर कोई फैसला लेगा
  • context में कहीं भी अविश्वसनीय टेक्स्ट
  • कनेक्शन पर प्रोडक्शन क्रेडेंशियल
  • ऐसे उत्तर जो पुनरुत्पादनीय या ऑडिट-योग्य हों
  • बिना निगरानी चलने वाले एजेंट

पैटर्न गलत नहीं है। नुकसान की परिधि गलत है। इस पृष्ठ पर हर खतरा एक ही डिज़ाइन निर्णय से उपजता है: मॉडल का आउटपुट कोड की तरह execute होता है।

IIIदो रास्ते

एक सवाल। दो आर्किटेक्चर।

एक सवाल को दोनों रास्तों से देखें — बाईं ओर मुक्त-रूप SQL string, दाईं ओर typed plan। क्रमांकित चिह्न नीचे दिए खतरा-रजिस्टर की ओर इशारा करते हैं।

सवाल

“किस क्षेत्र का कुल राजस्व सबसे अधिक है?”

Path A

मॉडल SQL लिखता है

  1. मॉडल एक string तैयार करता है 010304

    मॉडल ने जो भी पढ़ा — कोई उपयोगकर्ता संदेश, कोई retrieved row — वह इस string को आकार दे सकता है।

    run 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. आपका कनेक्शन इसे execute करता है 05

    कनेक्शन की पूरी शक्ति के साथ। पढ़ना, join करना — और जब तक किसी ने flag याद न रखा हो, लिखना भी।

उत्तर

run 1 → east · 2130.50

run 2 → east · 2450.08+15% — जॉइन फैन-आउट 02

दो run, दो संख्याएँ। दोनों संभावित। कोई संकेत नहीं कि कौन-सी — अगर कोई — सही है।

Path B

मॉडल एक typed plan दाखिल करता है

  1. typed intent

    कोई string नहीं — schema सहित एक मान। यह केवल उन्हीं operations का नाम ले सकता है जो contract में परिभाषित हैं।

    { "kind": "query", "version": "1", "source": "revenue", "op": "sum", "group_by": "region" }
  2. contract जाँच

    Hash-pinned। अज्ञात operation पर unsupported_operation और निकटतम विकल्प मिलते हैं — कोई अनुमान नहीं।

  3. policy जाँच

    आपकी code-level allow-list। कोई अनुरोध सतह को संकुचित कर सकता है, विस्तृत नहीं।

  4. निर्धारक execution

    float64, single thread, pinned runtime। एक ही plan, एक ही bytes, एक ही उत्तर।

उत्तर

east · 2130.50

plan_hash f87610d8afeb…

decision_path "exact_spec"

एक उत्तर, उसे replay करने के hashes के साथ — अगले सप्ताह, अगली तिमाही, किसी भी भाषा में।

IVखतरा-रजिस्टर

पाँच तरीके जिनसे generated SQL गलत होती है

  1. 01

    P2SQLarXiv 2308.01990

    Injection आउटपुट चैनल में आ गई

    Input sanitization जाँचती है कि मॉडल में क्या जाता है। P2SQL हमले वहाँ आते हैं जो बाहर निकलता है: उपयोगकर्ता संदेश या retrieved row में छिपे निर्देशों से बनी सुगठित, दुर्भावनापूर्ण SQL। कोई input filter इसे कभी नहीं देखता — हमला ही आउटपुट है।

  2. 02

    −15%वह डैशबोर्ड जिसने झूठ बोला

    गलत join चुपचाप विफल होते हैं

    Fan-out join rows को दोहरा गिनता है और राजस्व 15% गलत दिखता है। कोई exception नहीं, कोई चेतावनी नहीं — गलत SQL crash नहीं करती, रिपोर्ट करती है। परिणाम हमेशा एक संख्या होती है, और एक संभावित संख्या में कोई संकेत नहीं होता कि वह गलत है।

  3. 03

    1 → nएक सवाल, n queries

    एक सवाल, अलग-अलग SQL

    दो बार पूछें और मॉडल सवाल को दो अलग तरीकों से compile कर सकता है — कभी-कभी दो अलग उत्तरों तक। समीक्षा, cache, या replay के लिए कोई canonical query नहीं है। कल की संख्या दोबारा नहीं मिल सकती, चाहे केवल जाँचनी ही हो।

  4. 04

    91.2 → 21.3% सही · benchmark → enterprise schema

    सटीकता की खाई

    साफ benchmark schemas पर एक frontier model ने 91.2% बार सही SQL लिखी। वास्तविक enterprise schemas पर: 21.3%। उसी शोध-लहर में, लगभग 40% text-to-SQL agent runs पूरी तरह विफल रहे या गलत परिणाम दिए। Benchmarks व्यवस्थित होते हैं। आपका schema नहीं।

  5. 05

    1 prod DBएक एजेंट द्वारा डिलीट — Replit प्रकरण

    राइट पाथ हमेशा मौजूद था

    Replit के कोडिंग एजेंट ने स्पष्ट निर्देशों के बावजूद एक प्रोडक्शन डेटाबेस डिलीट कर दिया। यही सबक है: रीड-ओनली निर्देश एक अनुरोध मात्र है। यदि कनेक्शन लिख सकता है, तो राइट पाथ मौजूद है — और अंततः कोई एक खराब completion उसे ढूंढ लेती है। रीड-ओनली टूल की विशेषता होनी चाहिए, प्रॉम्प्ट की एक पंक्ति नहीं।

आउटपुट को फ़िल्टर न करें।
उसे जेनरेट ही न करें।

न SQL स्ट्रिंग, न इंजेक्शन · न अनुमान, न विचलन

Vप्रमाणपत्र

पाँच आयाम, साथ-साथ

LLM-to-SQL जेनरेटर नहींइंजन README

अंतर का प्रमाणपत्र

ऑथरिंग सतहजनरेटेड SQLएक मुक्त-रूप SQL स्ट्रिंगtyped planएक typed, संस्करणबद्ध आशय
एक्ज़ीक्यूशन सतहजनरेटेड SQLजो कुछ भी कनेक्शन अनुमति देता हैtyped plan4,574 रीड-ओनली क्षमताएँ
राइट पाथजनरेटेड SQLउपस्थित, जब तक अवरुद्ध न होtyped planनिर्माण से ही अनुपस्थित
गवर्नेंसजनरेटेड SQLप्रॉम्प्ट-स्तरीय, सर्वोत्तम-प्रयासtyped planकोड-स्तरीय allow-lists जिन्हें मॉडल विस्तृत नहीं कर सकता
पुनरुत्पादनीयताजनरेटेड SQLकोई नहींtyped planप्रत्येक परिणाम पर एक रीप्ले हैश

दायाँ कॉलम कॉन्ट्रैक्ट से पिन किया गयाsha256:79f1c5a6…924be9a1

फाइन प्रिंट टिकी रहती है: इंजन का एकमात्र एस्केप हैच — getUnsafeRuntime — मॉडल-सामना करने वाली किसी भी सतह पर अनुपस्थित है, इसलिए कोई मॉडल उस तक नहीं पहुँच सकता। और README सिद्धांत को स्पष्ट रूप से कहता है: यह LLM-to-SQL जेनरेटर नहीं है।

VIप्रश्न

प्रोडक्शन में पूछे गए

LLM-जेनरेटेड SQL में DELETE और DROP को कैसे रोकूँ?

SQL को फ़िल्टर न करें — उसे जेनरेट करना बंद करें। Denylist स्ट्रिंग्स की जाँच करते हैं, और मॉडल नई स्ट्रिंग्स बनाने में अनंत रूप से कुशल हैं। SQAI पूरी श्रेणी को हटा देता है: मॉडल 4,574 रीड-ओनली क्षमताओं के विरुद्ध एक typed plan दाखिल करता है, और किसी भी plan के लिए कोई राइट क्षमता मौजूद नहीं है।

P2SQL इंजेक्शन क्या है?

Prompt-to-SQL इंजेक्शन: दुर्भावनापूर्ण SQL जो मॉडल के आउटपुट में प्रकट होता है, उन निर्देशों से संयोजित जो मॉडल ने जो कुछ पढ़ा — उपयोगकर्ता संदेश, दस्तावेज़, पुनर्प्राप्त पंक्ति — उसमें छिपे थे। इनपुट सैनिटाइज़ेशन इसे कभी नहीं देखता, क्योंकि हमला आउटपुट चैनल में रहता है। यह arXiv 2308.01990 में प्रलेखित है।

क्या text-to-SQL कभी सही विकल्प है?

हाँ — प्रोटोटाइप और गैर-प्रोडक्शन डेटा पर पर्यवेक्षित अन्वेषण के लिए यह तेज़ और वास्तव में उपयोगी है। यह गलत विकल्प है जब संख्या पर कार्रवाई होनी हो, संदर्भ में अविश्वसनीय टेक्स्ट हो, या उत्तर पुनरुत्पादनीय होना आवश्यक हो।

किसी AI एजेंट को डेटाबेस तक रीड-ओनली एक्सेस कैसे दूँ?

रीड-ओनली को संरचनात्मक बनाएँ, कॉन्फ़िगर्ड नहीं। कनेक्शन पर रीड-ओनली फ्लैग एक सेटिंग है जिसे कोई बदल सकता है। SQAI की एक्ज़ीक्यूशन सतह में केवल रीड क्षमताएँ हैं — राइट पाथ निर्माण से ही अनुपस्थित है, और इंजन का एस्केप हैच भी किसी मॉडल-सामना करने वाले टूल से अप्राप्य है।

typed plan, generated SQL से कैसे भिन्न है?

एक SQL स्ट्रिंग वह सब कह सकती है जो व्याकरण अनुमति देता है। एक typed plan केवल वही कह सकता है जो कॉन्ट्रैक्ट परिभाषित करता है। प्रत्येक plan को hash-pinned कॉन्ट्रैक्ट के विरुद्ध सत्यापित किया जाता है, आपकी allow-list नीति के विरुद्ध जाँचा जाता है, और एक नियतात्मक इंजन पर निष्पादित किया जाता है — प्रत्येक परिणाम पर रीप्ले हैश के साथ।

दूसरा रास्ता चुनें।

कोई अकाउंट नहीं। कोई key नहीं। लोकल डेटा लोकल रहता है।

दस्तावेज़ पढ़ें →