1. शुरुआत — AI ने लिखा “639”। वास्तविक संख्या थी 0 #

कुछ समय पहले, हमारे लोकल LLM ने एक ऑटो-जेनरेटेड मॉनिटरिंग रिपोर्ट में “639 authentication failures” लिखा। जब हमने वास्तव में लॉग जाँचे, तो उस समय-अवधि में ऑथेंटिकेशन फेल्योर की संख्या 0 थी। LLM ने बस हवा से एक विश्वसनीय-सा दिखने वाला नंबर गढ़ दिया था (इस घटना के बारे में हमने “लोकल LLM द्वारा मॉनिटरिंग-रिपोर्ट के नंबर गढ़ने की कहानी, और उसके उपाय” में लिखा था)।

यह LLM का कोई दोष नहीं है; यह उसका स्वभाव है। LLM “संदर्भ के अनुसार विश्वसनीय लगने वाला टेक्स्ट” जेनरेट करने में माहिर है, और उसमें ऐसा कोई अंतर्निहित तंत्र नहीं है जो “तथ्यात्मक रूप से सटीक नंबरों” की गारंटी दे। वह अक्सर सही नंबर लिखता है, लेकिन इसलिए नहीं कि सहीपन की गारंटी है — वह बस संयोग से सही निकलता है।

AI Ops में इसे नज़रअंदाज़ नहीं किया जा सकता। जिस मॉनिटरिंग रिपोर्ट पर भरोसा न किया जा सके, वह न होने के बराबर है, बल्कि उससे भी बदतर — खतरनाक है। यदि कोई “639 authentication failures” पर विश्वास करके कार्रवाई करे, तो वह ऐसी समस्या पर समय खर्च करता है जो मौजूद ही नहीं है। इसके विपरीत, कोई वास्तविक विसंगति दब सकती है।

इसलिए हमने एक ऐसा तंत्र बनाया जो LLM द्वारा लिखे नंबरों पर आँख मूँदकर भरोसा नहीं करता — हैलुसिनेशन ऑडिटिंग। यह लेख इसके कार्यान्वयन के पीछे की सोच का वर्णन करता है।

2. सिद्धांत — तथ्य LLM नहीं बनाता। लॉग बनाते हैं #

ऑडिटिंग का प्रारंभिक बिंदु है भूमिकाओं का पृथक्करण।

मॉनिटरिंग रिपोर्ट में आने वाले “तथ्य” — नंबर, काउंट, IP एड्रेस, टाइमस्टैम्प — LLM के टेक्स्ट जेनरेशन से नहीं, बल्कि वास्तविक डिवाइस लॉग पर चलाई गई डिटर्मिनिस्टिक क्वेरीज़ से प्राप्त होते हैं। LLM की भूमिका केवल पुष्टि किए गए तथ्यों को ऐसे टेक्स्ट में ढालने तक सीमित है जिसे इंसान आसानी से पढ़ सकें।

• तथ्य (नंबर, टारगेट, टाइमस्टैम्प) → लॉग पर क्वेरीज़ से बनते हैं (ground truth)
• वर्णन (सारांश, व्याख्या, गद्य) → LLM बनाता है

अकेला यह पृथक्करण ही गढ़ने की गुंजाइश को बहुत कम कर देता है। LLM से “लॉग पढ़कर गिनने” को कहना गलत गिनती (= गढ़ाई) को आमंत्रण देता है; लेकिन यदि आप पहले काउंट एग्रीगेट कर लें, पुष्टि किए गए मान सौंप दें, और कहें कि “इन नंबरों का उपयोग करके स्थिति समझाओ,” तो नंबर फिर हिलते नहीं।

3. जो गढ़ाई फिर भी बचती है, उसे “ऑडिट” से पकड़ना #

भूमिकाएँ अलग करने के बाद भी, LLM लिखते-लिखते ऐसे नंबर घुसा सकता है जो उसे कभी दिए ही नहीं गए, या टारगेट में गलती कर सकता है। इसलिए हम एक ऑडिट स्टेप रखते हैं जो, आउटपुट बनने के बाद, LLM-जेनरेटेड रिपोर्ट को सोर्स लॉग से एक बार फिर क्रॉस-चेक करता है।

मोटा फ्लो इस प्रकार है।

1. Aggregate logs to build the "confirmed facts"       <- ground truth
2. Hand the confirmed values to the LLM to generate the report text
3. Extract the quantitative claims from the generated report
   (e.g., "N authentication failures on host A")
4. Cross-check each claim against the source logs (the confirmed facts in step 1)
5. If an unsupported or contradictory claim is found,
   replace it with the confirmed value, or regenerate the report
6. Record every detected mismatch (when, where, what was fabricated)

दो मुख्य बिंदु हैं।

क्रॉस-चेक डिटर्मिनिस्टिक है। हम मिलान का काम किसी दूसरे LLM को नहीं करने देते। हैलुसिनेशन का ऑडिट ऐसी चीज़ से कराना जो खुद हैलुसिनेट कर सकती है, निरर्थक है। क्रॉस-चेक एक अटल तथ्य — सोर्स लॉग — के विरुद्ध एक यांत्रिक जाँच है।

वेरिफिकेशन की इकाई "claim" है। बाद में फ्री टेक्स्ट से नंबर छानने के बजाय, LLM का आउटपुट शुरू से ही आसानी से सत्यापन योग्य संरचना (एक "target / metric / value" ट्यूपल) में लेना मिलान को कहीं अधिक मजबूत बनाता है। हम गद्य के रूप को नहीं, बल्कि यह देखते हैं कि हर एक claim को ground truth का समर्थन प्राप्त है या नहीं।

मिलान का एक उदाहरण (मान केवल व्याख्या के लिए हैं):

[AUDIT] report_id=████
  claim: host=A  metric=auth_fail  value=639
  truth: host=A  metric=auth_fail  value=0
  => MISMATCH  (replace with confirmed value / regenerate)

  claim: host=B  metric=port_scan  value=47
  truth: host=B  metric=port_scan  value=47
  => OK

4. यह "LLM को और स्मार्ट बनाने" की बात नहीं है #

डिज़ाइन दर्शन के रूप में यही निर्णायक बिंदु है। हैलुसिनेशन ऑडिटिंग कोई ऐसा तरीका नहीं है जो LLM को और स्मार्ट या अधिक सटीक बनाने की कोशिश करता हो। "LLM गलती करता है" — इस पूर्वधारणा को बदले बिना, यह आउटपुट को संरचना के स्तर पर (by construction) भरोसेमंद बनाता है।

LLM गलत नंबर लिख भी दे, तो ऑडिट में उसे ground truth से क्रॉस-चेक किया जाता है, इसलिए अंतिम रिपोर्ट के नंबरों की गारंटी रहती है। हम अपना भरोसा LLM की चतुराई पर नहीं, बल्कि वेरिफिकेशन तंत्र पर टिकाते हैं।

5. डिज़ाइन ट्रेडऑफ़ (ईमानदारी से) #

यह कोई रामबाण नहीं है।

1. लागत बढ़ती है। एग्रीगेशन, जेनरेशन और ऑडिटिंग अतिरिक्त पास जोड़ते हैं। फिर भी, हमारा आकलन है कि प्रोडक्शन मॉनिटरिंग रिपोर्ट के "भरोसेमंद होने" का मूल्य इस लागत के योग्य है।
2. यह "तथ्यों और मात्राओं" की गढ़ाई पकड़ता है। "ऑथेंटिकेशन फेल्योर की संख्या" जैसे सत्यापन योग्य claims को क्रॉस-चेक किया जा सकता है, लेकिन "यह ट्रेंड खतरनाक लगता है" जैसे व्यक्तिपरक वर्णन की वैधता को यांत्रिक रूप से सत्यापित करना कठिन है। ठीक इसीलिए हम LLM की भूमिका सारांश और फ़ॉर्मेटिंग तक सीमित रखते हैं, और उसे निर्णय न लेने देने के लिए डिज़ाइन करते हैं।
3. यह मानता है कि ground truth सही है। ऑडिट इस पूर्वधारणा पर टिका है कि "सोर्स लॉग तथ्य हैं।" लॉग संग्रह और डिवाइस-स्तरीय निर्धारण की सटीकता ही आधार है (संग्रह और स्वचालित-निर्धारण तंत्र अलग लेखों में कवर किए गए हैं)।

6. वही सिद्धांत जो BASTION की जड़ों में है #

"LLM द्वारा लिखे नंबरों पर भरोसा न करने" का यह रुख BASTION के समग्र डिज़ाइन की ही निरंतरता है।

जो निर्णय वास्तव में सिस्टम को चलाते हैं — हमलावर IP का अंतिम निर्धारण, firewall ब्लॉक का निष्पादन — वे LLM द्वारा नहीं, बल्कि वास्तविक डिवाइस लॉग पर आधारित डिटर्मिनिस्टिक निर्धारण से लिए जाते हैं (मल्टी-लेयर कोरिलेशन कैम्पेन डिटेक्शन कैसे काम करता है)। LLM जिसमें अच्छा है, वह है प्राकृतिक भाषा का सारांश और फ़ॉर्मेटिंग, प्रोडक्शन निर्णय-प्रक्रिया नहीं — यही रेखा ठीक वह वेरिफिकेशन अनुशासन है जिसका वर्णन हमने "डिज़ाइन जितना सुंदर हो, उतना ही उस पर वास्तविक डेटा से संदेह करें" में किया था।

हैलुसिनेशन ऑडिटिंग उसी सिद्धांत को रिपोर्टिंग लेयर पर लागू करती है। LLM हो, या (संभावित रूप से समझौता किया गया) Agent — दोनों ही हमारे लिए "अविश्वास करके सत्यापित करने" की चीज़ें हैं।

7. सारांश #

हम AI को जितना बड़ा दायरा सौंपते हैं, उतना ही "AI के आउटपुट को हम कैसे सत्यापित करते हैं" प्रोडक्ट की विश्वसनीयता तय करता है।

• तथ्य (नंबर) LLM नहीं बनाता; वे लॉग से लिए जाते हैं
• LLM द्वारा लिखे claims को आउटपुट के बाद ground truth से क्रॉस-चेक किया जाता है
• क्रॉस-चेक डिटर्मिनिस्टिक है। हैलुसिनेशन का ऑडिट हैलुसिनेशन से न कराएँ
• LLM की भूमिका सारांश और फ़ॉर्मेटिंग तक सीमित है; वह निर्णय नहीं लेता

LLM द्वारा लिखे नंबरों को ज्यों का त्यों न निगलें। यह चमक-दमक वाला काम नहीं है, लेकिन प्रोडक्शन में AI Ops को आत्मविश्वास के साथ चलाने की नींव यही है।