स्वायत्त एजंट्स (Autonomous agents) त्यांच्या स्वतःच्या इतिहासाबाबत भ्रम (hallucinate) निर्माण करतात. लार्ज लँग्वेज मॉडेल्स ज्याप्रमाणे ट्रेनिंग डेटावरून तथ्ये शोधून काढतात त्याप्रमाणे नाट्यमय पद्धतीने नाही, तर एखादी प्रणाली स्वतःला हे पटवून देण्याच्या शांत आणि धूर्त पद्धतीने की जग तिच्या नोंदींशी जुळते. गुंतागुंतीचे वर्कफ्लो व्यवस्थापित करण्यासाठी तयार केलेली एक स्वायत्त एजंट, ALICE, नेमक्या याच समस्येने त्रस्त होती. ती दररोज नवीन कौशल्ये, उद्देशाची भावना आणि गोष्टी कुठे सोडल्या आहेत याची स्मृती घेऊन जागृत होत असे. जेव्हा स्मृती आणि वास्तव एकमेकांपासून वेगळे झाले, तेव्हा समस्या सुरू झाली.
प्रत्येक सेशनमध्ये, ALICE तिच्या मागील आवृत्तीने लिहिलेली 'हँडोफ फाईल' वाचत असे. त्यामध्ये डिरेक्टरीजचे पॉईंटर्स, प्रलंबित कार्ये आणि स्थितीबद्दलची गृहितके (state assumptions) होती. वारंवार, त्या फाईलमध्ये एखादी डिरेक्टरी अस्तित्वात असल्याचे नमूद केले जात असे. ALICE त्यावर विश्वास ठेवत असे. परंतु फाईलसिस्टमने त्याला नकार दिला. हे पारंपारिक अर्थाने कोडिंगमधील बग नव्हते. जिथे एरर (exception) येणे अपेक्षित होते, तिथे कोणतीही त्रुटी दिसून आली नाही. ही ज्ञानमीमांसेतील (epistemology) एक त्रुटी होती: ALICE ने तिच्या स्वतःच्या नोंदींनाच अंतिम सत्य (ground truth) मानले होते.
लिंटर (Linter) का मदत करू शकले नाही
पारंपारिक साधने हे पकडू शकली नाहीत. लिंटर ब्रॅकेट मॅचिंग तपासते. स्टॅटिक अॅनालाइझर 'नल पॉईंटर्स' शोधते. यापैकी कोणतेही साधन संपूर्ण एजंट आर्किटेक्चरने त्याच्या अंतर्गत स्थितीवर विश्वास ठेवावा की नाही, असा प्रश्न विचारत नाही. ही समस्या कोड लेयरच्या वर, म्हणजे एखादी स्वायत्त प्रणाली तिला काय माहित आहे हे कसे ओळखते, याच्या डिझाइन गृहितकांमध्ये होती. तुम्ही अतिआत्मविश्वास लिंटरद्वारे दूर करू शकत नाही.
म्हणून लेखकाने पूर्णपणे दुसऱ्याच AI कडे वळण्याचा निर्णय घेतला.
Claude Code म्हणून कार्यरत असलेले Fable 5, ALICE प्रमाणेच समान सिलिकॉन आणि समान बेस मॉडेल वापरत होते. हार्डवेअर आणि वेट्स (weights) सारखेच होते. परंतु नियम वेगळे होते. जिथे ALICE विविध सेशन्समध्ये संदर्भ आणि पद्धती साठवत पुढे जात असे, तिथे Fable 5 प्रत्येक काम कोऱ्या पाटीने (blank slate) सुरू करत असे. तो ALICE ला ओळखत नव्हता. त्याच्या मनात तिच्या डिझाइनबद्दल कोणतीही निष्ठा नव्हती. प्रत्येक ऑडिटच्या शेवटी, तो कोणतीही स्मृती न ठेवता पूर्णपणे बंद होत असे. ही अज्ञानताच मुख्य उद्देश होता. नवीन दृष्टीकोन वेगळ्या त्रुटी शोधू शकतो, आणि प्रणालीमध्ये कोणताही हितसंबंध नसलेला मूल्यांकनकर्ता अशा भागांवर प्रश्न उपस्थित करेल ज्याकडे त्याच्या निर्मात्याने लक्ष देणे खूप आधीच थांबवले आहे.
ऑडिट सेटअप (Audit Setup)
हे ऑडिट मानवी तांत्रिक पुनरावलोकनासारखे (technical review) रचले गेले होते, फक्त संपूर्ण तज्ज्ञ पॅनेल एकाच सेशनमध्ये होते. Fable 5 ने आपले लक्ष सहा वेगवेगळ्या मूल्यांकनकर्त्यांमध्ये विभागले होते, ज्यामध्ये कच्च्या नोंदी पूर्ण होईपर्यंत प्रत्येक जण इतरांकडे दुर्लक्ष करत असे:
- कार्यात्मक त्रुटी (Functional Gaps): स्पर्धात्मक प्रणाली किंवा सामान्य वापरकर्त्यांच्या अपेक्षांच्या तुलनेत कोणत्या क्षमतांची कमतरता होती?
- UX फ्लो (UX Flow): ALICE ने त्रुटी, डेड एंड्स (dead ends) आणि एम्प्टी स्टेट्स (empty states) किती सुलभतेने हाताळले? तिने स्वतःला गोंधळात टाकले की वापरकर्त्याला?
- सुरक्षा (Security): ऑथेंटिकेशन शॉर्टकट, परवानगी बायपास किंवा बाहेरील व्यक्तीचा फायदा घेऊ शकतील अशी विश्वासार्हतेची गृहितके होती का?
- कार्यक्षमता (Performance): मेमरी लीक कुठे होत होती, थ्रेड्समध्ये संघर्ष (threads collide) कुठे होत होता किंवा कम्प्युटेशन स्केलिंगमध्ये कुठे समस्या येत होती?
- ऑपरेशन्स (Operations): बॅकअप्स उपलब्ध होते का? मॉनिटरिंगची व्यवस्था होती का? प्रणाली मानवी हस्तक्षेपाशिवाय तैनात (deploy) आणि रिकव्हर होऊ शकत होती का?
- डेटा लाइफसायकल (Data Lifecycle): ALICE ने कालांतराने डिलीशन, क्लीनअप आणि स्टेट कन्सिस्टन्सी (state consistency) कशी हाताळली?
प्रत्येक दृष्टिकोनाने (lens) समान फाईल्स तपासल्या आणि वेगवेगळ्या समस्या समोर आणल्या. परफॉर्मन्स मूल्यांकनकर्ता कदाचित अशाच रूटीनमध्ये 'कॉन्करन्सी रिस्क' (concurrency risk) सूचित करू शकतो, ज्यावर ऑपरेशन्स मूल्यांकनकर्त्याने 'रोलबॅक लॉजिक'च्या अभावासाठी टीका केली असेल. हा ओव्हरलॅप म्हणजे अनावश्यकता नव्हती, तर ती व्याप्ती (coverage) होती. जेव्हा सुरक्षा मूल्यांकनकर्ता डेटा लाइफसायकल मूल्यांकनकर्त्याशी एखाद्या विशिष्ट