Hallucination एक bug नहीं है जिसे अगले release में patch किया जाएगा — यह language मॉडलों के काम करने के तरीक़े का एक संरचनात्मक परिणाम है। एक मॉडल पहले से जो आया है उसे देखते हुए सबसे संभावित अगले token की भविष्यवाणी करके text उत्पन्न करता है। इसके पास कोई आंतरिक fact database नहीं है, वास्तविकता के विरुद्ध दावों को verify करने का कोई तरीक़ा नहीं है, और सत्य बनाम असत्य की कोई अवधारणा नहीं है। जब यह एक plausible-sounding लेकिन ग़लत बयान उत्पन्न करता है, तो यह ठीक वही कर रहा है जिसके लिए इसे प्रशिक्षित किया गया था: fluent, contextually appropriate text उत्पन्न करना। समस्या यह है कि "contextually appropriate" और "factually correct" एक ही चीज़ नहीं हैं, और मॉडल के पास उनके बीच भेद करने का कोई mechanism नहीं है।
सबसे ख़तरनाक hallucinations सूक्ष्म वाले हैं। एक मॉडल जो पूरी तरह से काल्पनिक व्यक्ति का आविष्कार करता है उसे पकड़ना आसान है। एक मॉडल जो एक वास्तविक quote को ग़लत व्यक्ति को attribute करता है, ग़लत वर्ष के साथ एक वास्तविक paper को cite करता है, या एक plausible-दिखने वाला API endpoint उत्पन्न करता है जो मौजूद नहीं है — वे कठिन हैं। Developers ने इसे hard way से सीखा है। ऐसे प्रसिद्ध मामले हैं जिनमें वकीलों ने fabricated case citations के साथ AI-उत्पन्न legal briefs जमा किए जो पूरी तरह से formatted दिखते थे लेकिन उन cases का संदर्भ देते थे जो कभी अस्तित्व में नहीं थे। Code hallucinations भी समान रूप से आम हैं: एक मॉडल एक library function को import करने का सुझाव दे सकता है जिसका तीन versions पहले नाम बदल दिया गया था, या एक method signature का संदर्भ दे सकता है जो लगभग-लेकिन-पूरी तरह नहीं वास्तविक से मेल खाता है।
कई कारक hallucination को अधिक या कम संभावित बनाते हैं। Higher temperature settings randomness बढ़ाते हैं, जो factual प्रश्नों पर hallucination दरों को बढ़ा सकता है। ऐसे obscure विषयों के बारे में पूछना जो प्रशिक्षण डेटा में infrequently प्रकट हुए, well-covered विषयों के बारे में पूछने की तुलना में अधिक hallucinations उत्पन्न करता है। लंबे, अधिक complex outputs में चीज़ों के ग़लत होने के अधिक अवसर होते हैं। और मॉडल विशेष रूप से तब hallucinating के लिए prone होते हैं जब वे एक उत्तर देने के लिए दबाव में होते हैं — यदि आप एक प्रश्न पूछते हैं और मॉडल नहीं जानता, तो इसका प्रशिक्षण इसे "मुझे पक्का नहीं" कहने के बजाय एक confident-sounding प्रतिक्रिया उत्पन्न करने की ओर bias करता है। यही कारण है कि एक मॉडल को स्पष्ट रूप से "मैं नहीं जानता" कहने की अनुमति देने से hallucination दरें measurably कम होती हैं।
उद्योग ने एक layered defense रणनीति विकसित की है। Grounding और RAG मॉडल को parametric memory पर निर्भर रहने के बजाय संदर्भ देने के लिए बाहरी sources प्रदान करते हैं। Lower temperature settings factual कार्यों के लिए randomness कम करती हैं। System prompts मॉडल को sources cite करने और uncertainty flag करने के लिए instruct कर सकते हैं। Post-generation checks — output को एक दूसरे मॉडल या एक fact-checking pipeline के माध्यम से चलाना — कुछ errors को users तक पहुँचने से पहले पकड़ते हैं। Anthropic, OpenAI, और Google सभी ने मॉडलों को अपनी स्वयं की uncertainty के बारे में बेहतर calibrated होने के लिए प्रशिक्षित करने में भारी निवेश किया है, ताकि वे confabulate करने के बजाय hedge या decline करने की अधिक संभावना रखें। लेकिन इनमें से कोई भी defense perfect नहीं है, और किसी भी AI output को verification के बिना ground truth के रूप में मानना किसी भी consequential चीज़ के लिए जोखिम भरा बना हुआ है।
एक ग़लतफ़हमी जिसे संबोधित करने योग्य है: hallucination दरें मॉडल पीढ़ियों के बीच नाटकीय रूप से सुधरी हैं, और कुछ लोग इसे extrapolate करके यह निष्कर्ष निकालते हैं कि समस्या जल्द ही "हल" हो जाएगी। यह संभवतः नहीं होगा, कम से कम पूरी तरह से नहीं, क्योंकि architecture स्वयं के पास truth-verification mechanism नहीं है। जो सुधर रहा है वह calibration है — आधुनिक मॉडल कम बार hallucinate करते हैं और uncertainty व्यक्त करने में बेहतर हैं। लेकिन "कम बार" "कभी नहीं" नहीं है, और medicine, law, या finance जैसे high-stakes डोमेन में, factual दावों पर 1% hallucination दर भी मानव verification के बिना अस्वीकार्य है। व्यावहारिक takeaway यह है कि अपने सिस्टम को यह मानते हुए design करें कि मॉडल कभी-कभी ग़लत होगा, और अगले मॉडल update के इसे अनावश्यक बनाने की उम्मीद करने के बजाय अपने workflow में verification बनाएँ।