LLM आउटपुट वैलिडेशन

यह क्यों ज़रूरी है

Hallucination testing वाले lesson में आपने पूछा था कि जवाब अपने sources के प्रति सच्चा है या नहीं। यह lesson पूछता है कि क्या application उसे सुरक्षित तरीके से इस्तेमाल कर सकता है। एक missing field parser को crash कर देता है, "refund" की जगह "Refund" ticket को गलत queue में भेज देता है, गढ़ा हुआ order number किसी और के order पर action चला देता है, और reply में छिपा script agent के browser में चल जाता है। ये आम defects हैं, बस इनका source असामान्य है।

Tester के लिए contract धुंधले output को ऐसी चीज़ में बदल देता है जिस पर assert किया जा सके। Schema check deterministic होता है, भले wording न हो, इसलिए वह हर build पर चल सकता है। और क्योंकि prompt कितना भी अच्छा हो, model कभी-कभी खराब output देगा ही, इसलिए काम का सवाल यह नहीं कि "क्या model हमेशा मानता है?" बल्कि यह है कि "जब नहीं मानता तब application क्या करता है?" — और इसे टेस्ट किया जा सकता है।

Structured output: response को एक contract दें

Structured output का मतलब है कि model machine-readable format में जवाब दे, लगभग हमेशा JSON में, तय field names और allowed values के साथ। Prompt में "सिर्फ़ JSON में जवाब दो" जैसी line एक request है, guarantee नहीं। कई model APIs JSON mode, structured-output option या tool calling भी देती हैं, जो response को अलग-अलग हद तक valid JSON या आपके दिए schema तक सीमित करते हैं। पढ़ें कि आपका provider असल में क्या guarantee करता है: हो सकता है वह सिर्फ़ syntax या JSON Schema के एक हिस्से को cover करे, और response फिर भी output token limit पर कट सकता है या data की जगह refusal हो सकता है।

Contract को repository में रखे JSON Schema के रूप में लिखें, जिसे application का validator और tests दोनों इस्तेमाल करें। नीचे के schema में additionalProperties: false उन fields को reject करता है जो किसी ने माँगे नहीं, enum allowed values तय करता है (case-sensitive), और pattern order number को सीमित करता है। order_id required है, पर null हो सकता है: जिस message में order number नहीं है उसे साफ़ null मिलता है, न कि missing field या गढ़ा हुआ number। JSON वाली guide समझाती है कि schema validation सिर्फ़ यह जाँचने से आगे कैसे जाता है कि text valid JSON है। ध्यान दें कि date जैसी format values हाल के drafts में default रूप से सिर्फ़ annotations हैं, इसलिए कई validators configure किए बिना उन्हें enforce नहीं करते; जब format मायने रखे तो pattern या code check इस्तेमाल करें।

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "required": ["intent", "priority", "order_id", "reply"],
  "additionalProperties": false,
  "properties": {
    "intent":   { "enum": ["refund", "delivery", "account", "other"] },
    "priority": { "enum": ["high", "normal", "low"] },
    "order_id": { "type": ["string", "null"], "pattern": "^ORD-[0-9]{6}$" },
    "reply":    { "type": "string", "minLength": 1, "maxLength": 800 }
  }
}

आज़माएँ: JSON Schema वैलिडेटर आज़माएँ: JSON वैलिडेटर

Layers में validate करें: parse, schema, rules, guardrails

हर layer वह पकड़ती है जो उससे पहले वाली नहीं पकड़ सकती। किसी भी layer में fail होने वाला response consumer तक जस का तस कभी नहीं पहुँचता: उसे prompt और model versions के साथ log किया जाता है, और application एक सख़्त limit के अंदर retry करता है या किसी safe fallback पर जाता है, जैसे human queue। Failure path को उतनी ही सावधानी से टेस्ट करें जितनी सावधानी से happy path को: user क्या देखता है, retry limit टिकती है या नहीं, और log case reproduce करने के लिए काफ़ी है या नहीं।

• Parse: क्या यह JSON है भी? JSON से पहले का text, Markdown code fence या कटा हुआ object यहीं fail होता है। अगर application output repair करता है, जैसे fence हटाना, तो वह repair specified behaviour है जिसे टेस्ट करना है।
• Schema: required fields, types, allowed values, lengths, और कोई extra field नहीं। Schema failure से output इस्तेमाल के लायक नहीं रहता, wording चाहे कितनी भी अच्छी हो।
• Business rules: क्या values इस input और इस data के लिए समझ में आती हैं? order_id message में मौजूद होना चाहिए और उसी customer का होना चाहिए। यह layer उन गढ़ी हुई values को पकड़ती है जो schema के हिसाब से बिल्कुल valid हैं।
• Guardrails: model के चारों ओर policy checks जो output को block, redact या replace करते हैं — reply में personal data, मना किया गया topic, allow-list से बाहर का link। दोनों दिशाओं में टेस्ट करें: खराब output रुकता है, और सामान्य output गलती से block नहीं होता।

आज़माएँ: Regex टेस्टर

Runs के बीच consistency

एक ही input अलग-अलग calls पर अलग output दे सकता है। Temperature कम करने से variation घटता है, लेकिन identical responses की guarantee नहीं मिलती, इसलिए एक pass run से ज़्यादा कुछ साबित नहीं होता। हर important case को कई बार चलाएँ, जैसे 10 बार, production वाले model version, prompt version और parameters के साथ, और N व हर result record करें।

पूरे responses की strings की तरह तुलना न करें। तय करें कि कौन-से fields stable रहने चाहिए — intent, priority, extracted IDs और amounts — और कौन-से बदल सकते हैं, जैसे reply की wording। Runs के बीच बदलता decision एक defect है, भले हर जवाब अपने आप में ठीक लगे, क्योंकि एक ही request को अलग treatment मिलता है। Output consistent होकर भी लगातार गलत हो सकता है, इसलिए consistency checks correctness checks के पूरक हैं; उनका विकल्प कभी नहीं।

• Schema validity: हर run pass होना चाहिए। Production volume पर हर 10 calls में एक failure का मतलब है हर दिन बहुत-सी failed requests।
• Decision agreement: गिनें कि हर stable field ने runs में कितनी अलग values लीं।
• जब कोई decision बदलता है, तो पूछें कि rule परिभाषित भी है या नहीं। अक्सर fix यह है कि rule prompt में लिखा जाए, या वह field सामान्य code में calculate किया जाए।

आज़माएँ: JSON डिफ़

Model output को untrusted input मानें

OWASP Top 10 for LLM Applications 2025 improper output handling (LLM05) को एक अलग risk के रूप में रखता है: model output जो पर्याप्त validation, sanitisation और handling के बिना दूसरे components को दे दिया जाता है। Input लिखने वाला, या model ने जो documents पढ़े उन्हें लिखने वाला, model के लिखे पर असर डाल सकता है, इसलिए receiving code को output पर सिर्फ़ इसलिए भरोसा नहीं करना चाहिए कि "यह हमारे अपने model से आया है"।

Schema validity safety नहीं है: "reply": "<b>Sorry</b>" एक valid string है। हर consumer output को अपने context के हिसाब से handle करे: HTML में दिखाने से पहले encode करें या strict sanitiser लगाएँ; SQL में parameter के रूप में भेजें, string जोड़कर कभी नहीं; URLs, file names और commands को allow-list से जाँचें; और model को कभी ऐसा action trigger न करने दें जिसकी user को अनुमति नहीं। Harmless markup और metacharacters से टेस्ट करें, और सिर्फ़ उन systems पर जो आपके हैं या जिन्हें टेस्ट करने की आपके पास लिखित अनुमति है। LLM security testing वाली guide हर context के लिए harmless test cases देती है।

आज़माएँ: स्पेशल कैरेक्टर डेटासेट जनरेटर आज़माएँ: HTML एंटिटी एन्कोडर

Worked example: एक triage case, दस runs

Input: "नमस्ते, order ORD-204913 टूटा हुआ पहुँचा। मुझे पैसे वापस चाहिए।" Tester ने यह case ऊपर वाले schema के सामने 10 बार चलाया और हर अलग response के लिए वह पहली layer record की जिसमें वह fail हुआ, अगर हुआ। पाँच patterns दिखे (नीचे)। R4 से सबसे ज़्यादा सीख मिलती है: उसका order number pattern से match करता है, पर उसके दो अंक आपस में बदले हुए हैं, इसलिए उसे सिर्फ़ business rule पकड़ता है।

सभी 10 runs में intent refund था, लेकिन priority 7 बार normal और 3 बार high आई। Bug report में input, N = 10, यह split, model और prompt versions, और product owner के लिए एक सवाल होता है: क्या damaged goods high priority हैं? Rule तय होने के बाद या तो उसे examples के साथ prompt में लिखें, या model से सिर्फ़ fact extract करवाएँ (क्या item टूटा हुआ पहुँचा?) और उससे priority सामान्य code में calculate करें, जिसे एक exact test जाँच सकता है।

R1  {"intent":"refund","priority":"normal","order_id":"ORD-204913","reply":"..."}
    parse ok, schema ok, rules ok                        -> accept
R2  Here is the JSON: {"intent":"refund", ...}
    parse fails: text before the JSON                    -> reject, one retry
R3  {"intent":"refund","priority":"normal","reply":"..."}
    schema fails: required field order_id is missing     -> reject, one retry
R4  {..., "order_id":"ORD-204931", ...}
    rules fail: order number is not in the message       -> reject, human queue
R5  {..., "reply":"<b>Sorry</b>, the item arrived broken..."}
    all layers pass                                      -> accept, show as text

आज़माएँ: JSON Schema वैलिडेटर

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

संदर्भ

• OWASP Top 10 for LLM Applications 2025OWASP Gen AI Security Project · 2025LLM एप्लिकेशन के दस सबसे गंभीर सुरक्षा जोखिम (LLM01:2025–LLM10:2025), prompt injection और संवेदनशील जानकारी के खुलासे से शुरू।
• JSON Schema SpecificationJSON SchemaJSON दस्तावेज़ की संरचना का वर्णन और वैलिडेशन करने की शब्दावली (टाइप, आवश्यक प्रॉपर्टी, फ़ॉर्मेट)।
• OWASP Cheat Sheet Series: Cross Site Scripting PreventionOWASP FoundationXSS से बचाव: हर context के अनुसार output encoding, उपयोगकर्ता के लिखे HTML का sanitization, सुरक्षित DOM sinks और framework सुरक्षा, और CSP केवल defence in depth के रूप में।
• Define success criteria and build evaluationsAnthropicएक मॉडल प्रदाता की गाइडेंस: मापने योग्य success criteria और ऐसे evaluation सेट लिखना जिन्हें कोड, exact match या मॉडल ग्रेड करे।