LLM आउटपुट के लिए JSON स्कीमा सत्यापन क्यों आवश्यक है

मानसिक मॉडल: सिंटैक्स बनाम स्कीमा

अविश्वसनीय LLM आउटपुट की समस्या को हल करने के लिए, व्यक्ति को सिंटैक्स और स्कीमा के बीच अंतर करना चाहिए। सिंटैक्स स्वयं JSON प्रारूप के नियमों को संदर्भित करता है: प्रत्येक खुलने वाले ब्रैकेट का एक बंद होने वाला ब्रैकेट होना चाहिए, और कुंजियाँ (keys) डबल कोट्स में होनी चाहिए। Python के json.loads() जैसा पार्सर केवल इन्हीं नियमों की जाँच करता है।

हालांकि, एक स्कीमा डेटा के अर्थपूर्ण अर्थ (semantic meaning) और संरचना को परिभाषित करता है। जबकि सिंटैक्स यह सुनिश्चित करता है कि फ़ाइल पठनीय है, स्कीमा यह सुनिश्चित करता है कि सामग्री उपयोग करने योग्य है। एक LLM आसानी से एक ऐसा JSON ऑब्जेक्ट बना सकता है जो सिंटैक्स के रूप में एकदम सही हो लेकिन तार्किक रूप से बेकार हो क्योंकि वह वह विशिष्ट जानकारी प्रदान करने में विफल रहता है जिसकी आपके एप्लिकेशन को आवश्यकता है।

उदाहरण: null, अनुपस्थित फ़ील्ड और मान्य स्ट्रिंग

एक ऐसे एप्लिकेशन पर विचार करें जो उपयोगकर्ता प्रोफ़ाइल की अपेक्षा करता है। सिस्टम को स्ट्रिंग के रूप में एक 'email' फ़ील्ड की आवश्यकता होती है। एक LLM निम्नलिखित JSON उत्पन्न कर सकता है:

इनपुट JSON: {"name": "John Doe", "email": null}

इस मामले में, JSON सिंटैक्स के रूप में एकदम सही है। पार्सर इसे सफलतापूर्वक एक Python डिक्शनरी में बदल देगा। हालांकि, यदि आपका कोड ईमेल फ़ील्ड पर.split('@') कॉल करने का प्रयास करता है, तो एप्लिकेशन AttributeError के साथ क्रैश हो जाएगा क्योंकि इसे स्ट्रिंग के बजाय NoneType प्राप्त हुआ है।

एक JSON स्कीमा लागू करके जो 'email' को एक आवश्यक स्ट्रिंग के रूप में परिभाषित करता है, सत्यापन चरण डेटा के आपके बिजनेस लॉजिक तक पहुँचने से पहले ही इस त्रुटि को पकड़ लेगा।

# Install in your environment: python -m pip install jsonschema
import json
from jsonschema import Draft202012Validator

schema = {
    "$schema": "https://json-schema.org/draft/2020-12/schema",
    "type": "object",
    "properties": {
        "name": {"type": "string"},
        "email": {"type": "string"}
    },
    "required": ["name", "email"],
    "additionalProperties": False
}
Draft202012Validator.check_schema(schema)
validator = Draft202012Validator(schema)
samples = [
    '{"name": "Ada", "email": null}',
    '{"name": "Ada"}',
    '{"name": "Ada", "email": "ada@example.com"}'
]
for text in samples:
    data = json.loads(text)
    print("accepted" if validator.is_valid(data) else "rejected")
# Expected illustrative output:
# rejected
# rejected
# accepted

अपेक्षित परिणाम

तीन इनपुट का अपेक्षित उदाहरणात्मक आउटपुट rejected, rejected, accepted है। पहले ऑब्जेक्ट में email मौजूद है, लेकिन JSON null Python में None बनता है और string प्रकार की शर्त पूरी नहीं करता। दूसरे में email नहीं है, इसलिए required उसे अस्वीकार करता है। तीसरा इस स्कीमा के अनुसार मान्य है। "not-an-email" भी मान्य होगा: उदाहरण केवल स्ट्रिंग प्रकार जाँचता है, ईमेल पता नहीं। Python jsonschema में केवल format लिखने से प्रारूप जाँच सक्रिय नहीं होती; जरूरत होने पर प्रारूप जाँचकर्ता कॉन्फ़िगर करें।

निदान: LLM सत्यापन में क्यों विफल होते हैं

LLM कई कारणों से सत्यापन में विफल हो जाते हैं। पहला, वे फ़ील्ड नामों की कल्पना (hallucinate) कर सकते हैं, अपेक्षित 'email' के बजाय 'user_email' का उपयोग कर सकते हैं। दूसरा, उन्हें जटिल प्रकारों के साथ संघर्ष करना पड़ सकता है, जैसे कि संख्या 10 के बजाय स्ट्रिंग '10' लौटाना। तीसरा, यदि प्रॉम्प्ट अस्पष्ट है तो वे फ़ील्ड को पूरी तरह से छोड़ सकते हैं। अंत में, वे NaN या Infinity जैसे गैर-मानक मान शामिल कर सकते हैं, जो हालांकि कभी-कभी विशिष्ट पार्सर द्वारा स्वीकार किए जाते हैं, लेकिन सख्त JSON विनिर्देश (RFC 7159) के अनुरूप नहीं हैं।

सामान्य गलतियाँ

एक सामान्य गलती यह मान लेना है कि चूंकि पार्सर ने कोई त्रुटि नहीं दी है, इसलिए डेटा उपयोग के लिए सुरक्षित है। एक अन्य गलती 'null' मान का हिसाब न रखना है; JSON में, एक कुंजी मौजूद हो सकती है लेकिन उसका मान null हो सकता है, जो कि कुंजी के अनुपस्थित होने से मौलिक रूप से भिन्न है। डेवलपर्स अक्सर गुणों की संख्या को सीमित करना भी भूल जाते हैं, जिससे LLM विशाल, फूले हुए ऑब्जेक्ट लौटाता है जो प्रोसेसिंग के दौरान अत्यधिक मेमोरी और CPU की खपत करते हैं।

सत्यापन के लिए निर्णय मानदंड

अनुप्रयोग के वास्तविक अनुबंध से शुरू करें: आवश्यक फ़ील्ड और स्पष्ट प्रकार। अनपेक्षित फ़ील्ड रोकने के लिए additionalProperties: false लगाएँ; केवल properties उन्हें नहीं रोकता। सीमाएँ या पैटर्न केवल ठोस आवश्यकताओं के लिए जोड़ें। पार्सिंग से पहले प्रतिक्रिया का आकार अलग से सीमित करें। Python json.loads सामान्यतः NaN और Infinity स्वीकार करता है; सख्त JSON के लिए parse_constant से त्रुटि उठाएँ। ये जाँच अनुमति नियंत्रण या व्यावसायिक सत्यापन का विकल्प नहीं हैं।

कार्यक्षेत्र सीमाएँ

JSON स्कीमा सत्यापन एक संरचनात्मक जाँच है, तार्किक नहीं। यह सुनिश्चित कर सकता है कि 'price' फ़ील्ड एक संख्या है, लेकिन यह सुनिश्चित नहीं कर सकता कि कीमत सही है या यह आपके डेटाबेस में कीमत से मेल खाती है। इसके अलावा, यदि LLM कई गीगाबाइट की JSON स्ट्रिंग बनाता है, तो स्कीमा सत्यापन संसाधन की कमी वाले हमलों (DoS) से सुरक्षा नहीं करता है; पार्सिंग शुरू होने से पहले आपको इनपुट स्ट्रिंग पर आकार सीमा लागू करनी चाहिए।

आवश्यकताओं का सारांश

इसे प्रभावी ढंग से लागू करने के लिए, सुनिश्चित करें कि आपके पास है: 1. प्रत्येक अपेक्षित LLM प्रतिक्रिया के लिए एक परिभाषित JSON स्कीमा। 2. एक सत्यापन लाइब्रेरी (जैसे Python के लिए jsonschema)। 3. सत्यापन त्रुटियों को संभालने की एक रणनीति (जैसे LLM प्रॉम्प्ट को फिर से प्रयास करना या उपयोगकर्ता को त्रुटि लौटाना)। 4. प्रारंभिक पार्सिंग चरण के दौरान मेमोरी की कमी को रोकने के लिए इनपुट आकार सीमाएँ।