एक तेज़ LLM ने मुझे धारणाओं (assumptions) के बारे में क्या सिखाया

मैंने एक घंटे तक एक जटिल कार्य के लिए एक सस्ते, तेज़ LLM का उपयोग किया। वह विफल नहीं हुआ।

अधिकांश लोगों को लगता है कि कमज़ोर मॉडल लंबे कार्यों में विफल हो जाते हैं। वे भटक जाते हैं या बीच में ही हार मान लेते हैं। लेकिन यह मॉडल ट्रैक पर बना रहा। ऐसा इसलिए हुआ क्योंकि मैंने इसे डिलिवरेबल्स (deliverables) की एक सूची दी थी।

मुझे लगा कि ये डिलिवरेबल्स सटीकता (correctness) में मदद करते हैं। मैं गलत था।

एक अध्ययन से पता चलता है कि डिलिवरेबल्स किसी मॉडल को अधिक सटीक नहीं बनाते हैं। वे मॉडल को अधिक सत्यापन योग्य (verifiable) बनाते हैं। मॉडल अपने काम का बेहतर दस्तावेज़ीकरण करता है। यह आपके जाँचने के लिए प्रमाण छोड़ता है।

सॉफ्टवेयर में दो प्रकार की त्रुटियाँ (errors) होती हैं:

  • एक्जीक्यूशन एरर्स (Execution errors): एक बदला हुआ कॉमा या कोई छूटा हुआ एज केस (edge case)। आप इन्हें टेस्ट और लिंटिंग (linting) के ज़रिए ठीक करते हैं।
  • असमप्शन एरर्स (Assumption errors): गलत जगह पर सीमा (boundary) निर्धारित करना। इसे ठीक करना बहुत कठिन होता है।

प्रक्रिया (Process) एक्जीक्यूशन एरर्स में मदद करती है। यह असमप्शन एरर्स को हल नहीं करती है। यदि आपकी और मॉडल की ब्लाइंड स्पॉट (blind spot) एक ही है, तो आपकी समीक्षा भी विफल हो जाएगी।

AI इन त्रुटियों के गणित को बदल देता है।

अतीत में, इंसान धीरे-धीरे गलतियाँ करते थे। इससे आपको ध्यान देने का समय मिल जाता था। अब, AI तेज़ी से गलतियाँ करता है। आपके ध्यान देने से पहले ही एक मॉडल एक गलत धारणा के आधार पर तीन घंटे का सटीक कोड बना सकता है।

एक मॉडल जितना अधिक सक्षम दिखता है, आप उस पर उतना ही अधिक भरोसा करते हैं। आप उसे लंबे समय तक चलने देते हैं। आप बार-बार जाँच करना बंद कर देते हैं। यह एक जाल है। एक गलत धारणा चेतावनी की लाइट नहीं जलाती। यह तब तक प्रगति की तरह दिखती है जब तक कि बहुत देर न हो जाए।

उद्योग इसे अधिक प्रक्रिया के साथ ठीक करने की कोशिश करता है। हम अधिक स्पेसिफिकेशन (specs) और अधिक योजनाएं जोड़ते हैं। यह केवल अतिरिक्त ओवरहेड (overhead) है। यह एक धारणा की समस्या के लिए एक्जीक्यूशन टूल है।

हमें यह मापना बंद करना होगा कि एक मॉडल कितनी बार सही होता है। हमें यह मापना होगा कि हमारे पकड़ने से पहले एक गलत धारणा कितने समय तक टिकी रहती है।

प्रोडक्शन में, हम इसे MTTD कहते हैं: मीन टाइम टू डिटेक्ट (Mean Time To Detect)।

हम हर त्रुटि को नहीं रोक सकते। हम केवल त्रुटियों को ठीक करना सस्ता बना सकते हैं। आप ऐसा उन्हें जल्दी पकड़कर कर सकते हैं।

लक्ष्य केवल एक स्मार्ट मॉडल खोजना नहीं है। लक्ष्य यह तय करना है कि आपको कहाँ अभी भी नियंत्रण में रहने की आवश्यकता है।

स्रोत: https://dev.to/g_correa/what-a-fast-llm-taught-me-about-assumptions-oe

वैकल्पिक लर्निंग कम्युनिटी: https://t.me/GyaanSetuAi