मी माझ्या वेबसाइटवर एक 'डिजिटल ट्विन' (digital twin) चालवतो. ते माझ्या जीवनाबद्दल आणि कौशल्यांबद्दल प्रश्नांची उत्तरे देते. मी त्याला एक कडक नियम दिला होता: कधीही गोष्टी बनवू नकोस. जर कोणी अशा कौशल्याबद्दल विचारले जे माझ्याकडे नाही, तर त्याने ते माहित नाही असे कबूल केले पाहिजे. कित्येक महिने मला वाटले की ही प्रणाली व्यवस्थित काम करत आहे. मी अधूनमधून स्वतःहून त्याची चाचणी घेतली आणि उत्तरे योग्य वाटत होती. मग मी एक योग्य 'इव्हॅल्युएशन हार्नेस' (evaluation harness) तयार केले. आकडेवारी पाहून धक्का बसला. ३५ प्रश्नांपैकी नऊ प्रश्नांमध्ये थेट खोट्या गोष्टी होत्या. उत्तर देता येणार नाहीत अशा पद्धतीने तयार केलेल्या आठ प्रश्नांपैकी मॉडेलने फक्त चार प्रश्नांना नकार दिला. माझा 'अँटी-हॅलुसिनेशन प्रॉम्प्ट' (anti-hallucination prompt) साधारणपणे पावथ्या वेळा अयशस्वी ठरला. मी असा उत्पादन (product) बाजारात आणत होतो जो आपल्या वापरकर्त्यांशी खोटे बोलत होता.

एक अत्यंत साधी रिट्रिव्हल सेटअप (Retrieval Setup)

मी Pinecone किंवा कोणतेही जड (heavyweight) वेक्टर डेटाबेस वापरले नाहीत. संपूर्ण सेटअप एका साध्या JSON फाईलवर आधारित आहे. माझा कोड माझ्या प्रोफाईलचे वेगवेगळ्या विभागांमध्ये विभाजन करतो. जेव्हा एखादा प्रश्न येतो, तेव्हा ही प्रणाली क्वेरी आणि मजकुराचा प्रत्येक भाग (chunk) यांच्यातील 'कोसाइन सिमिलॅरिटी' (cosine similarity) मोजते, सर्वात जवळचे जुळणारे भाग निवडते आणि त्यांना संदर्भासाठी (context) प्रॉम्प्टमध्ये समाविष्ट करते. त्यानंतर मॉडेल त्या विंडोमध्ये जे काही दिसते, त्यावर आधारित उत्तर तयार करते.

मर्यादित माहिती देणाऱ्या छोट्या वैयक्तिक साइटसाठी ही पद्धत जलद आहे आणि खर्चही नगण्य आहे. यामध्ये रिमोट वेक्टर स्टोअरसाठी नेटवर्क राउंड-ट्रिप, इंडेक्सिंगचा अतिरिक्त भार किंवा कोणतीही जटिल ऑर्केस्ट्रेशन (orchestration) करण्याची गरज नाही. तुम्ही फाईल वाचता, चंक्सना स्कोअर देता, प्रॉम्प्ट तयार करता आणि काम पूर्ण होते. परंतु बॅकएंडमधील साधेपणा आउटपुटमधील प्रामाणिकपणाची खात्री देत नाही. जेव्हा मॉडेल स्वतःच्या मनाने काहीतरी सांगण्याचा (improvise) निर्णय घेते, तेव्हा एक हलकी (lightweight) पाइपलाइन देखील गंभीर समस्या निर्माण करू शकते. "हा संदर्भ आहे" आणि "याबद्दल मी असे म्हणेन" यामधील अंतर म्हणजेच 'हॅलुसिनेशन' (hallucinations) घडण्याचे ठिकाण आहे. तुम्ही मॉडेलला तुमच्या कामाच्या इतिहासाबद्दल एक परिच्छेद देऊ शकता आणि तरीही तुम्ही कधीही स्पर्श न केलेल्या प्रोग्रामिंग लँग्वेजबद्दल ते आत्मविश्वासाने खोटे बोलू शकते.

माझ्या आत्मविश्वासाला तडा देणारी आकडेवारी

कित्येक महिने, मी मॅन्युअल स्पॉट-चेकिंगला पुरेसे मानले. मी चॅट उघडायचो, मला आधीच उत्तर माहित असलेला प्रश्न विचारायचो आणि उत्तर योग्य वाटले की मान डोलवायचो. हीच माझी टेस्टिंग स्ट्रॅटेजी होती. मला ते सखोल वाटत होते कारण मी स्वतः इंटरफेस वापरत होतो. पण ते तसे नव्हते.

जेव्हा मी अखेर एक पद्धतशीरपणे चालणारे इव्हॅल्युएशन हार्नेस (evaluation harness) लिहिले, तेव्हा चित्र बदलले. टेस्ट सुईटने (test suite) डिजिटल ट्विनला ३५ प्रश्न विचारले. नऊ उत्तरांमध्ये खोट्या गोष्टी होत्या. मी असे आठ प्रश्न देखील समाविष्ट केले ज्यांची उत्तरे माझ्या प्रोफाईलमध्ये कुठेही नव्हती. मॉडेलने त्या सर्व प्रश्नांना नकार द्यायला हवा होता. पण त्याने फक्त चार प्रश्नांना नकार दिला. माझा काळजीपूर्वक तयार केलेला 'अँटी-हॅलुसिनेशन प्रॉम्प्ट', ज्यामध्ये गोष्टी बनवू नका असे स्पष्टपणे सांगितले होते, तो साधारण २५ टक्के वेळा अयशस्वी ठरला. चारपैकी एक. ही केवळ एखादी छोटी चूक नाही. हे एक निकामी उत्पादन आहे.

सोप्या प्रश्नांनी टेस्टिंग करणे थांबवा

तुम्ही फक्त तुमचे स्वतःचे उत्पादन वापरून त्रुटी (bugs) शोधू शकत नाही. तुम्ही ते तोडण्याचा प्रयत्न करूनच त्रुटी शोधू शकता. माझ्या मॅन्युअल चाचण्या खूप सोप्या होत्या. मी फक्त असे प्रश्न विचारले ज्यांची मला अचूक उत्तरे माहित होती, याचा अर्थ असा की मी नकळत मॉडेलला सुरक्षित क्षेत्राकडे नेत होतो. मी कधीही कठीण किंवा सीमावर्ती भागांची चाचणी घेतली नाही. मी माझ्याकडे असावे असे वाटणाऱ्या कौशल्यांबद्दल किंवा कधीही न घडलेल्या अनुभवांबद्दल कधीही विचारले नाही.

खऱ्या टेस्टिंगसाठी 'ॲडव्हर्सरिअल इंटेंट' (adversarial intent) आवश्यक आहे. तुम्हाला AI ला अपयशी ठरवण्यासाठी प्रश्न तयार करावे लागतील. तुम्हाला ते प्रयोगशाळेत (lab) चुकलेले हवे आहे, जेणेकरून ते एखाद्या visitor च्या समोर चुकणार नाही. अशी टेस्ट सुईट जी फक्त तुमच्या विश्वासाची पुष्टी करते, ती केवळ एक सजवलेली डेमो (demo) आहे. जर तुम्ही सक्रियपणे 'एज केसेस' (edge cases) आणि 'ट्रॅप क्वेश्चन्स' (trap questions) तयार करत नसाल, तर तुम्ही टेस्टिंग करत नाही आहात. तुम्ही फक्त आशा करत आहात.

महत्त्वाच्या दोन चुका

प्रॉम्प्टिंग (Prompting) ही कोणतीही खात्री नाही. AI ला हॅलुसिनेट करू नका असे सांगणारी मोठी आणि तपशीलवार सूचना ही केवळ आज्ञेच्या वेषातील एक सूचना आहे. मॉडेल बहुतांश वेळा त्याचे पालन करू शकते, परंतु ज्या क्षणी सांख्यिकीय दबाव (statistical pressure) त्याला दुसऱ्या दिशेला ढकलतो, तेव्हा ते सूचनांकडे दुर्लक्ष करेल. टेम्परेचर (Temperature), टोकन प्रोबॅबिलिटी (token probability) आणि ट्रेनिंग डेटाचे स्वरूप या सर्व गोष्टी तुमच्या सिस्टम प्रॉम्प्टमधील एका वाक्यापेक्षा जास्त प्रभावी ठरतात. तुम्हाला आज्ञाधारकपणा डेटाने मोजला पाहिजे, आशेने नाही. एक मजबूत सूचना म्हणजे पडताळलेली वस्तुस्थिती नाही. ती एक विनंती आहे, आणि विनंत्या नाकारल्या जाऊ शकतात. जर तुमची संपूर्ण सुरक्षा रणनीती केवळ प्रॉम्प्टमधील शब्दांवर अवलंबून असेल, तर तुम्ही टिश्यू पेपरपासून सुरक्षा भिंत (guardrail) तयार केली आहे. तुम्हाला अशा 'इव्हॅल हार्नेस'ची (eval harness) गरज आहे जो मॉडेल किती वेळा आज्ञा पाळते, कोणत्या परिस्थितीत आणि जेव्हा ते अपयशी ठरते तेव्हा का ठरते, याची मोजणी करेल. आकडेवारीला तुमच्या बोलण्याच्या पद्धतीशी (tone of voice) काहीही देणेघेणे नसते.

मूल्यांकन प्रक्रिया दोषपूर्ण होती. येथे एक सूक्ष्म सापळा आहे ज्याने मला जवळजवळ फसवले असते. माझे मूळ टेस्टिंग टूल रिट्रिव्हल प्रक्रिया दोनदा चालवत असे. पहिल्या वेळी, 'ग्राउंड ट्रुथ'शी पडताळणी करण्यासाठी संदर्भ मिळवला जात असे. दुसऱ्या वेळी, प्रत्यक्ष उत्तर निर्मितीसाठी संदर्भ मिळवला जात असे. व्यवहारात, याचा अर्थ असा होता की जजने पाहिलेले चंक्स आणि मॉडेलने पाहिलेले चंक्स यामध्ये फरक असू शकत होता. जज अशा डेटाच्या आधारे उत्तराचे मूल्यांकन करत होता, जो कदाचित AI ला कधी मिळालाच नसेल. चुकीच्या इनपुटवर आधारित मूल्यांकन करणे हे मूल्यांकन न करण्यापेक्षाही वाईट आहे. यामुळे तुम्हाला सुरक्षेचा एक खोटा आभास होतो. तुम्ही स्कोअर पाहता, उच्च पास रेट पाहता आणि निश्चिंत होता. दरम्यान तुमचे वापरकर्ते