RAG और सर्च इंजीनियरिंगएडवांस्डपाठ 2157 मिनट का पाठ

नॉलेज ग्राफ और स्ट्रक्चर्ड रिट्रीवल

कुछ सवाल गिनने, फ़िल्टर करने और तथ्यों को आपस में जोड़ने के बारे में होते हैं, न कि कोई पैराग्राफ़ ढूंढने के लिए। उनके लिए, SQL या ग्राफ वेक्टर सर्च से बेहतर साबित हो सकता है।

✦ ट्यूटर से पूछें🧪 लैब · 40 min📝 पाठ का टेस्ट
पाठ वीडियो में

60 सेकंड में

नॉलेज ग्राफ और स्ट्रक्चर्ड रिट्रीवल

कुछ सवाल गिनने, फ़िल्टर करने और तथ्यों को आपस में जोड़ने के बारे में होते हैं, न कि कोई पैराग्राफ़ ढूंढने के लिए। उनके लिए, SQL या ग्राफ वेक्टर सर्च से बेहतर साबित हो सकता है।

1/5
आसान शब्दों में
अगर आप जानना चाहते हैं कि 2016 में विराट कोहली ने कितने रन बनाए, तो आप हर मैच की रिपोर्ट नहीं पढ़ते। आप स्कोरकार्ड टेबल देखते हैं और संख्याओं को जोड़ते हैं। कुछ सवालों के लिए एक टेबल की ज़रूरत होती है, कहानी की नहीं।
वेक्टर और कीवर्ड सर्च पैराग्राफ़ लौटाते हैं। यह "छुट्टी की पॉलिसी क्या है?" जैसे सवालों के लिए सही है। पर यह "पिछले महीने पुणे से कितने ऑर्डर लेट हुए?" या "प्लांट A के कौन-से सप्लायर प्लांट B को भी सप्लाई करते हैं?" जैसे सवालों के लिए गलत है। इनका जवाब किसी एक पैराग्राफ़ में नहीं लिखा होता। इसे स्ट्रक्चर्ड डेटा से कैलकुलेट करना पड़ता है।

किस सवाल के लिए कौन-सा टूल

सवाल का प्रकारउदाहरणसबसे अच्छा टूल
समझाना या विवरण देना"मैं रिफ़ंड के लिए कैसे अप्लाई करूं?"टेक्स्ट रिट्रीवल (हाइब्रिड सर्च)
गिनती, जोड़, औसत, टॉप-N"मार्च में केरल में कुल बिक्री"डेटाबेस पर SQL
फ़ील्ड्स पर सटीक फ़िल्टर"कस्टमर 4412 के 7 दिन से पुराने ओपन टिकट"SQL या सर्च फ़िल्टर
कई स्टेप्स में फैले कनेक्शन"चेन्नई के जिस प्रोजेक्ट में देरी हुई, उसके वेंडर से जुड़े और कौन-से प्रोजेक्ट हैं?"एक नॉलेज ग्राफ, या SQL जॉइन्स
मिला-जुला"पिछले हफ्ते पुणे के ऑर्डर में देरी क्यों हुई थी?"संख्याओं के लिए SQL, वजहों के लिए टेक्स्ट सर्च

Text-to-SQL, सावधानी के साथ

Text-to-SQL का मतलब है कि एक मॉडल यूज़र के सवाल को एक SQL क्वेरी में बदलता है, आपका कोड उसे चलाता है, और मॉडल उसके रिज़ल्ट को समझाता है। यह बहुत उपयोगी हो सकता है, और यह खतरनाक तरीके से गलत भी हो सकता है। मॉडल द्वारा लिखा गया SQL अनट्रस्टेड इनपुट होता है, ठीक वैसे ही जैसे किसी अजनबी द्वारा टाइप किया गया SQL।
  1. 1

    एक छोटा और साफ़ स्कीमा दें

    सिर्फ़ वही टेबल और कॉलम जिनकी ज़रूरत है, साफ़ विवरण और उदाहरण वैल्यूज़ के साथ।
  2. 2

    क्वेरी जनरेट करें

    रो लिमिट के साथ केवल एक SELECT स्टेटमेंट मांगें।
  3. 3

    इसे रीड-ओनली कनेक्शन के साथ चलाएं

    डेटाबेस यूज़र सिर्फ़ पढ़ सकता है, और वह भी केवल मंज़ूर की गई टेबल या व्यूज़ को।
  4. 4

    सीमाएं लागू करें

    टाइमआउट, रो लिमिट और यूज़र का अपना डेटा स्कोप—यह सब कोड या डेटाबेस में तय करें।
  5. 5

    क्वेरी और रिज़ल्ट दिखाएं

    लोगों को SQL और संख्याएं देखने दें, सिर्फ़ मॉडल की समरी नहीं।
Python: running model-written SQL in a read-only session (sqlite3)python
import sqlite3

conn = sqlite3.connect(":memory:")
conn.execute("CREATE TABLE orders (id INTEGER, city TEXT, status TEXT, amount REAL)")
conn.executemany("INSERT INTO orders VALUES (?, ?, ?, ?)", [
    (1, "Pune", "delayed", 450.0), (2, "Pune", "delivered", 1200.0),
    (3, "Kochi", "delayed", 300.0), (4, "Pune", "delayed", 800.0),
])
conn.execute("PRAGMA query_only = ON")  # from now on, writes are refused

def run_model_sql(sql: str, max_rows: int = 100):
    if ";" in sql.strip().rstrip(";"):
        raise ValueError("Only one statement is allowed")
    cur = conn.execute(sql)
    return cur.fetchmany(max_rows)

print(run_model_sql("SELECT city, COUNT(*) FROM orders WHERE status = 'delayed' GROUP BY city"))
try:
    run_model_sql("DELETE FROM orders")
except sqlite3.OperationalError as err:
    print("Blocked:", err)
यहाँ असली सुरक्षा यह है कि डेटाबेस कुछ भी लिखने से मना कर दे, न कि सिर्फ़ टेक्स्ट की जांच करना। प्रोडक्शन डेटाबेस में, एक अलग यूज़र का इस्तेमाल करें जिसके पास कुछ सुरक्षित व्यूज़ पर केवल रीड-ओनली राइट्स हों, और लॉग-इन किए गए यूज़र के डेटा के लिए रो-लेवल लिमिट्स हों। सिर्फ़ SQL टेक्स्ट की जांच को आसानी से चकमा दिया जा सकता है।
सावधान रहें
Text-to-SQL एक गलत लेकिन मान्य क्वेरी लौटा सकता है: गलत जॉइन, छूटा हुआ फ़िल्टर, या तारीख का दायरा एक दिन आगे-पीछे होना। संख्या एकदम सटीक और आधिकारिक लगती है। इसलिए SQL दिखाएं, ऐसे सवालों के सेट से टेस्ट करें जिनके सही जवाब आपको पता हों, और पैसों व पर्सनल डेटा के मामले में अतिरिक्त सावधानी बरतें।

नॉलेज ग्राफ

एक नॉलेज ग्राफ तथ्यों को एंटिटीज़ (लोग, कंपनियां, प्रोडक्ट्स, जगहें) और उनके बीच के रिश्तों के रूप में स्टोर करता है, जैसे "वेंडर X प्लांट A को सप्लाई करता है" या "सर्कुलर 14 सर्कुलर 9 की जगह लेता है"। यह उन सवालों के लिए बहुत अच्छा है जो कई कड़ियों को आपस में जोड़ते हैं, और दस्तावेज़ों में नामों की स्पेलिंग अलग होने पर भी हर एंटिटी का एक साफ़ रिकॉर्ड बनाए रखते हैं।
  • जब संभव हो, इसे स्ट्रक्चर्ड डेटा से बनाएं: आपके डेटाबेस में पहले से ही कई साफ़-सुथरे संबंध मौजूद होते हैं।
  • किसी मॉडल से टेक्स्ट से ग्राफ निकालना संभव है, लेकिन इसमें गलतियां होती हैं। हर तथ्य को उसके सोर्स पैराग्राफ़ से लिंक करके रखें, और ज़रूरी तथ्यों की समीक्षा करें।
  • टेक्स्ट सर्च के साथ मिलाएं: सही एंटिटीज़ ढूंढने के लिए ग्राफ का इस्तेमाल करें, फिर स्पष्टीकरण और साइटेशन के लिए उनके बारे में पैराग्राफ़ निकालें।

सबको एक साथ जोड़ना: एक राउटर

कई सिस्टम पहला कदम ऐसा जोड़ते हैं जो तय करता है कि हर सवाल कहाँ जाएगा: टेक्स्ट सर्च, SQL, ग्राफ, या इनमें से कई। यह राउटर साधारण नियम हो सकता है ("अगर कोई संख्या और तारीख की रेंज है: तो SQL आज़माएं") या कोई मॉडल कॉल जो एक तय लिस्ट में से चुनता है। लिस्ट को छोटा रखें और हर पसंद को लॉग करें, ताकि आप गलत रास्तों को देख सकें और ठीक कर सकें।
जोखिम भरा स्ट्रक्चर्ड रिट्रीवल
  • मॉडल द्वारा लिखा गया SQL एक एडमिन यूज़र के रूप में चलता है
  • कंपनी की हर टेबल प्रॉम्प्ट में मौजूद होती है
  • सिर्फ़ मॉडल की समरी दिखाई जाती है
  • मॉडल द्वारा निकाले गए ग्राफ तथ्य, जिनका सोर्स से कोई लिंक नहीं होता
सावधानीपूर्वक स्ट्रक्चर्ड रिट्रीवल
  • कुछ सुरक्षित व्यूज़ पर रीड-ओनली यूज़र, टाइमआउट और रो लिमिट्स के साथ
  • काम के लिए एक छोटा और स्पष्ट स्कीमा
  • SQL और ओरिजिनल रिज़ल्ट साफ़ दिखाई देते हैं
  • ग्राफ का हर तथ्य उस जगह से लिंक होता है जहाँ से वह आया है
इसे आज़माएं। ऐसे पांच सवाल लिखें जो लोग आपके काम या कॉलेज में पूछते हैं। हर एक पर निशान लगाएं: पैराग्राफ़, संख्या, फ़िल्टर, या कनेक्शन। सिर्फ़ वेक्टर सर्च इनमें से कितनों का गलत जवाब देगा?

और देखें और पढ़ें

लैब

एक छोटा राउटर जो सवालों को टेक्स्ट सर्च या सुरक्षित SQL पर भेजता है, जिसे आपके अपने सवालों पर टेस्ट किया गया हो।

~40 min

समस्या

Python 3 और स्टैंडर्ड लाइब्रेरी के sqlite3 का इस्तेमाल करें। किसी मॉडल की ज़रूरत नहीं है; जहाँ मॉडल SQL लिखता, वहाँ आप खुद हाथ से SQL लिखेंगे।

  1. city, status, date और amount के साथ 15–20 काल्पनिक ऑर्डर्स की एक टेबल बनाएं। PRAGMA query_only = ON चालू करें।
  2. 8 सवाल लिखें: 4 ऐसे जिनमें संख्याओं या फ़िल्टर की ज़रूरत हो, और 4 ऐसे जिनमें स्पष्टीकरण की ज़रूरत हो (उदाहरण के लिए "मैं कोई सामान कैसे वापस करूँ?")।
  3. एक नियम-आधारित route(question) लिखें जो "sql" या "text" लौटाए। "कितने", "कुल", "औसत", शहर का नाम, या तारीख जैसे आसान संकेतों का इस्तेमाल करें।
  4. हर "sql" सवाल के लिए, खुद हाथ से SQL लिखें, उसे चलाएं, और जांचें कि रिज़ल्ट सही है या नहीं।
  5. दिखाएं कि DELETE या UPDATE काम नहीं करता।

आपका काम तब पूरा होगा जब

कठिन सवाल

उत्तर देखने से पहले ख़ुद जवाब देने की कोशिश करें। अगर आप इनके जवाब दे सकते हैं, तो आप पाठ समझ गए हैं।

Q1DELETE या DROP जैसे शब्दों के लिए SQL टेक्स्ट की जांच करना ही काफ़ी सुरक्षा क्यों नहीं है?दिखाएं

टेक्स्ट चेक्स को चकमा देना और उनमें गलतियाँ होना आसान है: अजीब स्पेसिंग, कमेंट्स, अलग-अलग तरह के स्टेटमेंट्स, साइड इफेक्ट्स वाले डेटाबेस के खास फ़ंक्शंस, या एक सीधा-सादा दिखने वाला SELECT जो ऐसा डेटा पढ़ लेता है जिसे यूज़र को नहीं देखना चाहिए। असली सुरक्षा खुद डेटाबेस से आनी चाहिए: एक read-only यूज़र, सिर्फ सुरक्षित views का एक्सेस, लॉग-इन किए गए यूज़र से जुड़ी row-level लिमिट्स, और timeouts। टेक्स्ट चेक्स एक अतिरिक्त लेयर हो सकते हैं, कभी भी मुख्य सुरक्षा नहीं।

Q2एक सवाल है "पिछले हफ्ते पुणे में देरी क्यों बढ़ गई?" बताइए कि आप SQL और text retrieval दोनों का इस्तेमाल करके इसका जवाब कैसे देंगे।दिखाएं

सबसे पहले, SQL फैक्ट्स का हिसाब लगाता है: उससे पिछले हफ्ते की तुलना में पिछले हफ्ते पुणे के कितने ऑर्डर्स में देरी हुई, शायद कूरियर या इलाके के हिसाब से बाँटकर। फिर टेक्स्ट सर्च ऐसे हिस्से ढूँढकर निकालता है जो इसकी वजह समझा सकें, जैसे उन तारीखों के इंसिडेंट नोट्स, कूरियर अपडेट्स या मौसम से जुड़े नोटिस। मॉडल एक ऐसा जवाब लिखता है जो आँकड़े बताता है (क्वेरी दिखाते हुए) और citations के साथ संभावित कारण देता है, और उन्हें साबित हुई नहीं बल्कि सिर्फ संभावित वजहें बताता है।

जारी रखने के लिए कृपया साइन इन करें।

अक्सर पूछे जाने वाले सवाल

क्या मुझे नॉलेज ग्राफ के लिए ग्राफ डेटाबेस की ज़रूरत है?

ज़रूरी नहीं। एक छोटा ग्राफ आपके मौजूदा डेटाबेस की साधारण टेबल्स में एंटिटीज़ और रिलेशंस के रूप में रह सकता है। एक अलग ग्राफ डेटाबेस तभी चुनें जब आपके पास किसी बड़े ग्राफ पर कई मल्टी-स्टेप क्वेरीज़ हों।

क्या मॉडल निकाले गए टेक्स्ट से खुद गणित कर सकता है?

एक या दो संख्याओं के लिए, शायद हाँ। पर कई पंक्तियों के कुल जोड़ के लिए यह अक्सर कुछ छोड़ देता है या गलत गिनती करता है, क्योंकि हो सकता है कि सारी पंक्तियाँ निकाली ही न गई हों और मॉडल भरोसेमंद कैलकुलेटर नहीं होते। डेटाबेस को हिसाब लगाने दें, और मॉडल को समझाने दें।

क्या ग्राहकों के लिए text-to-SQL का सीधे इस्तेमाल करना सुरक्षित है?

सिर्फ़ सख्त सीमाओं के साथ: रीड-ओनली एक्सेस, डेटाबेस द्वारा केवल उनके अपने डेटा तक पहुंच, टाइमआउट और रो लिमिट्स। कई टीमें आंतरिक कर्मचारियों के इस्तेमाल और सुरक्षित व्यूज़ के एक तय सेट से शुरुआत करती हैं।

मैं text-to-SQL को कैसे टेस्ट करूं?

ऐसे सवाल लिखें जिनके सही जवाब आपको पता हों, जनरेट किए गए SQL को चलाएं, और रिज़ल्ट्स की तुलना करें, न कि SQL टेक्स्ट की, क्योंकि अलग-अलग तरह से लिखी गई क्वेरीज़ भी एक जैसी सही हो सकती हैं।

पाठ का टेस्ट

5 सवाल। पास होने और इस पाठ को पूरा करने के लिए 3 सही होने चाहिए (60%)।

टेस्ट देने और अपनी प्रोग्रेस सेव करने के लिए साइन इन करें