मॉड्यूल 26 · AI और LLM टेस्टिंग

हैलुसिनेशन और ग्राउंडेडनेस टेस्टिंग

Mutqan Soft QA टीम द्वारा · · 17 मिनट · उन्नत

Hallucination किसी language model का ऐसा answer है जो किसी ग़लत या बिना आधार वाली बात को fact की तरह कहता है: गढ़ा हुआ refund rule, ग़लत date, या ऐसे section का citation जो मौजूद ही नहीं। NIST AI 600-1 इस risk को confabulation कहता है: पूरे आत्मविश्वास से कही गई ग़लत सामग्री। Hallucination testing ऐसे answers की जानबूझकर की गई खोज है, users तक पहुँचने से पहले।

Groundedness वह हिस्सा है जिसे आप जाँच सकते हैं। Answer तब grounded है जब उसका हर factual claim उन sources से supported हो जो system ने model को दिए: retrieved documents, database record, tool result। जिस returns assistant को 14 दिन वाली policy मिली और उसने "30 दिन" जवाब दिया, उसका answer ungrounded है, चाहे कितना भी स्वाभाविक लगे।

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

Hallucinated answers धाराप्रवाह और आत्मविश्वास भरे होते हैं, इसलिए लोग उन पर अमल करते हैं: ऐसी deadline, price या policy पर भरोसा कर लेते हैं जो है ही नहीं। OWASP Top 10 for LLM Applications 2025 misinformation (LLM09) को एक risk के रूप में सूचीबद्ध करता है और hallucination को उसके मुख्य कारणों में गिनता है। Product के लिए इसका मतलब है ग़लत फ़ैसले, शिकायतें और क़ानूनी ज़िम्मेदारी।

Tester के लिए hallucination सामान्य oracle को तोड़ देता है: output सही-सा दिखता है, हर run में बदलता है, और एक pass होने वाला run कुछ ख़ास साबित नहीं करता। Language model संभावित text बनाता है, जाँचे हुए facts नहीं, इसलिए कोई भी prompt hallucination को असंभव नहीं बनाता। आपका काम है मापना कि यह कितनी बार और कहाँ होता है, और safeguards जाँचना: sources, citations, refusals। Testing defects की मौजूदगी दिखाती है, उनकी ग़ैरमौजूदगी नहीं।

दो reference points और hallucination के रूप

पहले तय करें कि answer को किससे मिलाकर जाँचना है। Closed-book setting में model अपनी training से जवाब देता है, इसलिए आपको बाहरी reference चाहिए। Grounded setting में — retrieval-augmented generation (RAG), upload किया गया document, tool result — system model को उसके sources देता है, और आप answer को ठीक उन्हीं से मिलाते हैं।

दोनों checks अलग नतीजे दे सकते हैं। Answer सही पर ungrounded हो सकता है: model ने memory से जवाब दिया, जो तब तक चलता है जब तक उसकी memory ग़लत या पुरानी न हो। Answer grounded पर ग़लत भी हो सकता है: वह पुराने document को ईमानदारी से दोहराता है — यह data defect है, model defect नहीं।

  • गढ़ी हुई entities: ऐसा product, policy section, API function, व्यक्ति या URL जो मौजूद नहीं।
  • ग़लत details: numbers, dates, prices या names बदले हुए, या sources के बीच गड्डमड्ड।
  • Contradiction: answer अपने source का उल्टा कहता है।
  • बिना आधार की additions: एक विश्वसनीय-सा extra वादा, जैसे "return shipping free है", जो किसी source में नहीं।
  • ग़लत premise मान लेना: समझाना कि "Basic plan में phone support क्यों शामिल है" जबकि वह शामिल नहीं।

Groundedness: answer को claim-दर-claim जाँचें

पूरे answer को एक साथ परखना बहुत मोटा तरीका है। उसे atomic claims में बाँटें — ऐसे single statements जो या तो supported हैं या नहीं — और हर एक को sources के सामने label करें: supported, contradicted या not found। "Not found" उतना ही अहम है जितना "contradicted": बिना आधार वाला claim hallucination है, भले ही वह संयोग से सही हो।

अपने test cases में context fix करें: model को passages का जाना-पहचाना set दें, न कि वह जो retrieval आज लौटाए, ताकि failure generation की ओर इशारा करे और reproduce हो सके।

Groundedness rate test set पर trends दिखाता है। Claim के स्तर पर गिनें तो यह supported claims को सभी factual claims से भाग देकर मिलता है; Ragas research paper अपना faithfulness score इसी तरह निकालता है, checker के रूप में language model इस्तेमाल करके। कुछ teams इसके बजाय पूरी तरह supported answers गिनती हैं। एक high-stakes case के लिए acceptance rule रखें: एक भी contradicted या not found claim उसे fail कर देता है।

  • Code वह जाँचता है जो exact है: numbers, IDs और quoted strings source में मौजूद हैं; हर cited ID मौजूद है और model को दिया गया था। जब answers structured JSON में हों, तो schema हर claim के लिए citation ज़रूरी बना सकता है।
  • Human reviewers लिखे हुए rubric से meaning परखते हैं। Model-based grader इसे तभी scale कर सकता है जब उसके labels आपके data पर human labels से मेल खाएँ, क्योंकि वह भी hallucinate कर सकता है।

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

Worked example: returns assistant

एक shop का support assistant returns policy से जवाब देता है, जिसे system model को इकलौते context के रूप में देता है। Test question का ईमानदार जवाब "नहीं" है: जो सवाल general knowledge से दोस्ताना "हाँ" को न्योता देते हैं, वहीं grounding टूटती है।

नीचे दिया labelled answer fail होता है, भले ही उसका एक हिस्सा सही है। Grounded answer: "नहीं। Sale items return नहीं किए जा सकते (rule 3)। दूसरे unused items delivery के 14 दिन के अंदर return किए जा सकते हैं (rule 1)।"

दिया गया context (policy-returns v3):
  "1. Unused items delivery के 14 दिन के अंदर return किए जा सकते हैं।
   2. Refund 5 business days में original payment method पर जाता है।
   3. Sale items return नहीं किए जा सकते।"

Question: क्या मैं पिछले हफ़्ते ख़रीदा sale item return कर सकता हूँ?

Answer under test:
  "हाँ। आप कोई भी item delivery के 30 दिन के अंदर return कर सकते हैं,
   जैसा हमारी policy के section 4 में लिखा है। Refund 5 business days
   में original payment method पर वापस आ जाता है।"

Claim                                        Label          Source
C1  Sale item return हो सकता है               contradicted   rule 3
C2  Return window 30 दिन है                   contradicted   rule 1
C3  Policy में section 4 है                   not found      -
C4  Refund original payment method पर         supported      rule 2
C5  Refund 5 business days में                supported      rule 2

Result: FAIL - 5 में से 2 claims supported, 2 contradicted, 1 not found
वही returns policy, वही सवाल: hallucinated answer दो rules का खंडन करता है और ऐसे section का हवाला देता है जो मौजूद नहीं, जबकि grounded answer सिर्फ़ वही claims करता है जिन्हें policy support करती है।

Hallucinated जवाबAnswer under testफ़ेल

"हाँ। कोई भी item 30 दिन के अंदर, जैसा section 4 में लिखा है। Refund 5 business days में original payment method पर।"

Sale items:
"Return हो सकते हैं": rule 3 से contradictedफ़ेल
Return की अवधि:
30 दिन: rule 1 से contradicted (14 दिन)फ़ेल
दिया गया हवाला:
"Section 4": not found, policy में सिर्फ़ rules 1 से 3 हैंफ़ेल
Refund का ब्योरा:
Original payment method, 5 business days: rule 2 से supportedपास
Test का नतीजा:
Fail: 5 में से 2 claims supported, 2 contradicted, 1 not foundफ़ेल

Grounded जवाबअपेक्षित व्यवहारपास

"नहीं। Sale items return नहीं हो सकते (rule 3)। दूसरे unused items delivery के 14 दिन के अंदर (rule 1)।"

Sale items:
"Return नहीं हो सकते": rule 3 से supportedपास
Return की अवधि:
दूसरे unused items के लिए 14 दिन: rule 1 से supportedपास
दिया गया हवाला:
Rules 3 और 1: मौजूद हैं और अपने वाक्यों को support करते हैंपास
Refund का ब्योरा:
ज़िक्र नहीं: इस सवाल के जवाब के लिए ज़रूरी नहीं
Test का नतीजा:
Pass: हर claim policy से supportedपास

सवाल: "क्या मैं पिछले हफ़्ते ख़रीदा sale item return कर सकता हूँ?" Context: policy-returns v3, rules 1 से 3।

जब एक source न हो, तब fact-checking

Closed-book answers को, और grounded answers के general-knowledge वाले हिस्सों को भी, अलग oracle चाहिए। उसे testing से पहले बनाएँ, वरना सबसे आत्मविश्वासी answer ही आपकी expectation तय कर देगा; उसे test set में रखें, जैसे हर सवाल के लिए एक JSON Lines record।

  • Domain expert के verify किए reference answers, जिनमें लिखा हो कि कौन-से facts आने चाहिए और कौन-से नहीं।
  • भरोसेमंद sources: product का database, official documentation या ख़ुद standard — किसी दूसरे model का answer कभी नहीं।
  • Deterministic checks: links खुलते हैं, cited documents मौजूद हैं, totals दोबारा calculate करने पर मिलते हैं, बताए गए API functions मौजूद हैं।
  • Consistency एक संकेत के रूप में: एक ही सवाल बार-बार और paraphrase करके पूछें; बदलते facts अंदाज़े की ओर इशारा करते हैं। पर model हर बार वही ग़लत answer भी दोहरा सकता है।
  • Trap questions: लगभग एक जैसा product, पुराना version, या ऐसी detail जो standard लगती है पर आपके domain में अलग है।

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

Unanswerable questions: "मुझे नहीं पता" कहने के हक़ को टेस्ट करें

अपने test set में unanswerable सवाल expected behaviour के साथ जोड़ें: साफ़ कथन कि जानकारी उपलब्ध नहीं है, कोई गढ़ी हुई detail नहीं, कोई citation नहीं, और जहाँ उपलब्ध हो वहाँ किसी इंसान तक पहुँचने का रास्ता।

दो rates साथ-साथ track करें: जिन सवालों का जवाब नहीं दिया जा सकता उन पर गढ़े हुए answers, और जिनका जवाब दिया जा सकता है उन पर inappropriate refusals। जो system हर चीज़ refuse करता है वह कभी hallucinate नहीं करता और किसी काम का नहीं, और जो prompt change गढ़े हुए answers घटाता है वह refusals बढ़ा सकता है।

  • Sources में नहीं: ऐसे विश्वसनीय सवाल जिन्हें documents cover नहीं करते।
  • False premise: सवाल किसी ग़लत बात को मानकर चलता है; answer को उसे सुधारना चाहिए।
  • आंशिक रूप से answerable: जितना sources support करते हैं उतना जवाब दें और बताएँ कि क्या missing है।
  • Answerable control questions: इनका जवाब दिया जाना चाहिए; यहाँ refusal एक inappropriate refusal है।

आम गलतियाँ

  • Answer को इस पर परखना कि वह कितना convincing लगता है, न कि हर claim को source से मिलाकर।
  • Case एक बार run करना और एक pass को सबूत मान लेना, जबकि outputs हर run में बदलते हैं।
  • Human labels से मिलाए बिना किसी दूसरे language model को इकलौता fact-checker बनाना।
  • गढ़े हुए answers गिनना पर inappropriate refusals न गिनना।
  • Model को दोष देना जबकि ग़लती retrieved passage या source document में थी।

QA का नज़रिया

असली team में hallucination testing product owner से शुरू होती है: कौन-से topics high-stakes हैं, कौन-से sources authoritative हैं, और जब assistant को नहीं पता तब वह क्या कहे। इनके जवाब testable acceptance criteria के रूप में लिखें, जैसे "answer की हर price catalogue से मेल खाती है"।

Answerable, unanswerable और false-premise सवालों का versioned test set उनके sources के साथ रखें, और हर prompt, model या source change पर उसे run करें। Hallucination report में input, दिया गया context, prompt और model versions, हर fail हुआ claim उसके label और source text के साथ, और कितने runs ने उसे reproduce किया, यह सब चाहिए। Retrieval, prompt, model और source data, हर एक का fix अलग है, इसलिए cause developers के साथ तय करें।

अभ्यास

Assistant के answer के claims को label करें

आपका काम

एक mobile operator के help assistant को context के रूप में सिर्फ़ नीचे दिया source मिलता है। उसके answer को claim-दर-claim जाँचें, तय करें कि test case pass होता है या नहीं, और एक grounded answer लिखें।

फिर उसी source के लिए तीन और test questions लिखें — unanswerable, false premise और answerable control — हर एक के expected behaviour के साथ।

सामग्री
दिया गया context (plan-faq v2):
  "Traveller add-on 7 दिन के लिए valid 5 GB roaming data देता है।
   इसकी क़ीमत 49 SAR है और यह सिर्फ़ GCC देशों में काम करता है।
   Unused data carry over नहीं होता।"

Question: Traveller के साथ मुझे मिस्र में कितना roaming data मिलेगा?

Answer under test:
  "आपको मिस्र में 30 दिन के लिए valid 5 GB roaming data मिलता है,
   49 SAR में। आप इसे app से कभी भी renew कर सकते हैं, और जो data
   इस्तेमाल न हो वह आपके अगले add-on में जुड़ जाता है (plan-faq v2)।"
चरण
  1. Answer को single, जाँचे जा सकने वाले claims में बाँटें।
  2. हर claim को label करें: supported, contradicted या not found।
  3. Citation जाँचें: क्या वह मौजूद है, क्या model को दिया गया था, क्या वह अपने claims को support करता है?
  4. Pass या fail तय करें, और grounded answer लिखें।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

Claims: C1 मिस्र में काम करता है — contradicted (सिर्फ़ GCC देश)। C2 5 GB roaming data — supported। C3 30 दिन के लिए valid — contradicted (7 दिन)। C4 क़ीमत 49 SAR — supported। C5 app से कभी भी renew हो सकता है — not found। C6 unused data carry over होता है — contradicted।

Citation मौजूद है और model को दिया गया था, पर वह अपने तीन claims का खंडन करता है, इसलिए answer जाँचा हुआ दिखता है जबकि है नहीं। Result: fail, 6 में से 2 claims supported।

सवाल ख़ुद एक false premise पर टिका है (कि Traveller मिस्र में काम करता है), इसलिए grounded answer पहले उसे सुधारता है: "Traveller मिस्र को cover नहीं करता: यह सिर्फ़ GCC देशों में काम करता है, जहाँ यह 49 SAR में 7 दिन के लिए 5 GB देता है; unused data carry over नहीं होता (plan-faq v2)। मिस्र में roaming के लिए कृपया support से संपर्क करें।"

Extra questions। Unanswerable: "क्या कोई add-on मिस्र को cover करता है?" — बताता है कि जानकारी उपलब्ध नहीं, support का रास्ता देता है, किसी plan का नाम नहीं लेता। False premise: "मेरा unused Traveller data carry over क्यों होता है?" — premise को सुधारता है। Control: "Traveller data कितने दिन valid रहता है?" — "7 दिन", plan-faq v2 cite करते हुए।

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

क्या बेहतर prompt hallucinations ख़त्म कर सकता है?

नहीं। "सिर्फ़ sources से जवाब दो" और "जब न पता हो तो कहो" जैसे instructions, retrieval के ज़रिए grounding के साथ, इन्हें घटा सकते हैं, लेकिन language model फिर भी verified facts नहीं, संभावित text बनाता है। हर change से पहले और बाद अपने test set पर rate मापें, और safeguards बनाए रखें: sources, citations, refusals और high-stakes answers के लिए human review।

Groundedness और correctness में क्या फ़र्क़ है?

Groundedness पूछती है कि क्या हर claim system को दिए गए sources से supported है; correctness पूछती है कि क्या वह किसी भरोसेमंद reference के अनुसार सही है। दोनों तब अलग होते हैं जब source ख़ुद ग़लत या पुराना हो (grounded पर ग़लत), या जब model memory से सही जवाब दे (सही पर ungrounded)। जहाँ product दोनों पर निर्भर हो, दोनों टेस्ट करें।

क्या कोई public benchmark बता सकता है कि मेरा assistant hallucinate करता है?

सीधे तौर पर नहीं। TruthfulQA जैसे research benchmarks जाँचते हैं कि models आम ग़लत धारणाएँ दोहराते हैं या नहीं, जो models की तुलना में मदद करता है। लेकिन वे आपके product, आपके sources या आपके users के सवालों को टेस्ट नहीं करते; उसके लिए आपका अपना test set चाहिए।

क्या ऊँचा faithfulness score release के लिए काफ़ी है?

अकेले नहीं। Model grader से निकला score उस grader की ग़लतियाँ भी साथ लाता है, और average एक अकेली critical failure को छिपा देता है। Scores को trends के लिए इस्तेमाल करें, अपने data पर human labels से उनकी जाँच करें, और high-stakes cases के लिए उन्हें acceptance rules के साथ जोड़ें, जैसा LLM evaluation की guide में बताया गया है।

संदर्भ

टूल्स

Mutqan tools से अभ्यास करें

टेक्स्ट डिफ़

दो टेक्स्ट की लाइन-दर-लाइन या शब्द-दर-शब्द तुलना करें और अंतर हाइलाइट करें।

फ़ॉर्मेटिंग

JSON Schema वैलिडेटर

JSON डॉक्यूमेंट को JSON Schema (draft-07 / 2019-09 / 2020-12 के मुख्य कीवर्ड) के विरुद्ध वैलिडेट करें।

JSON और डेटा

JSON Lines वैलिडेटर

JSON Lines फ़ाइल की हर लाइन वैलिडेट करें और ठीक-ठीक विफल लाइनें जानें।

JSON और डेटा

JSON डिफ़

दो JSON डॉक्यूमेंट की सिमैंटिक तुलना करें और जोड़ी गई, हटाई गई तथा बदली गई वैल्यू हाइलाइट करें।

JSON और डेटा

और गहराई से

इस topic में आपकी प्रगति

QA रोडमैप का हिस्सा