LLM प्रेक्षणीयता: Datadog के CTO से 6 सीखें

पाठ 1: एआई ने कोड रिव्यू का पुराना तरीका तोड़ दिया

शुरू करते हैं उस दबाव से जो बाक़ी सबको जन्म देता है: कोड इतना है कि कोई भी सब नहीं पढ़ सकता।

Lê-Quôc साफ़ कहते हैं कि पुराना मॉडल—एक मनुष्य द्वारा पुल रिक्वेस्ट को लाइन दर लाइन पढ़ना—एआई-सहायता प्राप्त विकास के संपर्क में टिकता नहीं। उद्योग भर में वे जिस चिंता को सुनते हैं, वह यह है कि रिव्यू असंभव होते जा रहे हैं, क्योंकि PRs पढ़कर साथ रहना मुमकिन नहीं रहा।

उनका उत्तर लोगों से तेज़ पढ़ने को कहना नहीं, बल्कि रिव्यू को कहीं और ले जाना है।

आख़िरी बात आसानी से छूट सकती है। जब आप एक एजेंट को प्लान करने, दूसरे को लिखने, और तीसरे को टेस्ट करने के लिए ऑर्केस्ट्रेट करते हैं, तो आपको राइटर को ऑटोमेटेड टेस्ट्स को गेम करने से भी रोकना होता है, वरना वह समस्या सुलझाने के बजाय टेस्ट पास करने लगेगा।

वे टेस्ट्स से आगे जाते हैं। Datadog अब अर्ध-औपचारिक और औपचारिक प्रूफ़ जोड़ता है कि स्पेक वही करता है जो उसे करना चाहिए—कुछ ऐसा जो एजेंट्स के भारी काम सँभालने से पहले व्यापक रूप से करने के लिए बहुत थकाऊ था। यह बैकएंड और कोऑर्डिनेशन सिस्टम्स पर सबसे बेहतर काम करता है, जहाँ व्यवहार काफ़ी गणितीय होता है जिसे सटीकता से समझा जा सके।

पाठ 2: प्रोडक्शन ही एकमात्र मायने रखने वाला टेस्ट है

CI में हर टेस्ट पास करना ज़रूरी है—और कहीं से पर्याप्त नहीं। असली नाकामियाँ बाद में होती हैं।

हर रिलीज़ कुछ ऐसी मान्यताओं पर टिकी होती है जिन्हें पहले से पूरी तरह जाँचा नहीं जा सकता—डेटा की बनावट और यूज़र्स के व्यवहार के बारे में। उन मान्यताओं को पर्याप्त वास्तविक ट्रैफ़िक के सामने रखें, और दुर्लभ केस दुर्लभ नहीं रहते; वे डेटा और मॉडल ड्रिफ्ट की रोज़मर्रा की सुस्ती और त्रुटियाँ बन जाते हैं।

LLMs इसे और कठिन बनाते हैं: साधारण कोड में आप कम-से-कम हर ब्रांच पर तर्क कर सकते हैं, पर कोई भी यांत्रिक रूप से नहीं समझा सकता कि एक मॉडल जो लौटाता है, क्यों लौटाता है—इसलिए वही इनपुट हमेशा वही आउटपुट देगा, इसकी गारंटी नहीं। कभी-कभार आने वाले अजीब नतीजों को आप इंजीनियरिंग से पूरी तरह हटा नहीं सकते।

तो आप शिप होने से पहले सिस्टम को सही साबित करने की कोशिश छोड़ देते हैं। इसके बजाय, आप

• वांछित व्यवहार के लिए इवैल्युएशंस लिखते हैं
• उसे प्रोडक्शन में मॉनिटर करते हैं
• ऐसे रोलआउट के लिए स्टॉप कंट्रोल रखते हैं जो बिगड़ जाए।

सवाल अब यह नहीं रहता कि यह पास हुआ या नहीं, बल्कि यह कि कोई समस्या एक बार की है या किसी रुझान की शुरुआत।

यह लाइव सिग्नल सिर्फ़ मनुष्यों के लिए डैशबोर्ड नहीं है। डिप्लॉयमेंट सिस्टम में जुड़े होने पर, यह किसी एजेंट को बदलाव उसी तरह रोलआउट करने देता है जैसे कोई सतर्क इंजीनियर करता—पहले एक प्रतिशत यूज़र्स, फिर पाँच—और वास्तविक डेटा से आँकता है कि बदलाव इच्छित असर दे रहा है या नहीं।

पाठ 3: टॉइल एजेंट्स को सौंपें

Lê-Quôc का एजेंट्स के पक्ष में तर्क यह नहीं है कि वे इंजीनियरों की जगह लेते हैं, बल्कि यह कि वे काम के वे हिस्से ले लेते हैं जो लोगों को थका देते हैं।

किसी घटना की ट्रबलशूटिंग का मतलब है लक्षण पर परिकल्पनाएँ फेंकना, और लंबी घटनाओं में अक्सर वही दूर की परिकल्पना सही निकलती है। Datadog का Bits AI एजेंट उन्हें इंजीनियर से पहले समानांतर में जाँचता है, जबकि व्यक्ति उसे उस सूझ की ओर मोड़ता है जो कोई डैशबोर्ड कभी नहीं दिखाएगा।

गहरी बात है थकान। ऑन-कॉल रोलआउट में अचानक तीव्र चौकसी आती है, फिर घंटों कुछ नहीं—यह सिलसिला तब तक दोहरता है जब तक आपका निर्णय कमजोर न पड़ने लगे।

एजेंट को फ़र्क़ नहीं पड़ता—और चार घंटे नंबरों को घूरने के बाद वह और ख़राब नहीं हो जाता। तनाव और थकान मानव प्रदर्शन को बिगाड़ते हैं—इसीलिए टीमें लोगों को ऑन-कॉल में घुमाती हैं।

यह बिन-थके देखना मशीन को सौंप दें, और लोग उन कॉल्स के लिए तरोताज़ा लौटें जिनमें उनकी ज़रूरत है। यही तर्क सिक्योरिटी ट्रायेज़ पर भी लागू होता है, जहाँ विश्लेषक फ़ॉल्स पॉज़िटिव्स और असली खतरों को छाँटते-छाँटते थक जाते हैं।

पाठ 4: काम को दो लूप्स में बाँटें

Lê-Quôc Datadog के एजेंट कार्य को दो लूप्स के आसपास व्यवस्थित करते हैं।

डेवलपमेंट लूप

अधिकांश इंजीनियर पहले लूप को पहचानेंगे:

1. कोड लिखें
2. शिप करें
3. देखें, यह काम करता है या नहीं
4. ठीक करें
5. दोहराएँ

Datadog का नज़रिया यह है कि जो समस्या कोड में जन्म लेती है, उसका समाधान भी आम तौर पर कोड में होता है—इसलिए प्लेटफ़ॉर्म वही समाधान आपको थमाने की कोशिश करता है, उस ज्ञान से सूचित होकर जो उसे एप्लिकेशन के बारे में है: स्वामित्व, हालिया बदलाव, और फेंकी गई त्रुटियाँ।

वे डेटाबेस क्वेरी ऑप्टिमाइज़ेशन का उदाहरण देते हैं। कोई भी मॉडल धीमी क्वेरी को फिर से लिख सकता है; कठिन भाग यह साबित करना है कि री-राइट तेज़ और सुरक्षित है—प्रोडक्शन तक पहुँचने से पहले। इसलिए Datadog पहले उसे प्रोडक्शन डेटा की यथार्थवादी कॉपी पर टेस्ट करता है और सबूत संलग्न करके एक पुल रिक्वेस्ट सौंप देता है।

ऑपरेशंस और सिक्योरिटी लूप

दूसरा लूप समानांतर में चलता है—या तो वही लोग या दूसरी टीम:

1. डिटेक्ट
2. इन्वेस्टिगेट
3. फिक्स
4. दोहराएँ

यहीं Datadog का AI Guard सिक्योरिटी इवेंट्स का ट्रायेज़ करता है और हमलों को एक विश्लेषक की तुलना में तेज़ी से ब्लॉक करता है। एजेंट्स वे रूटीन ऑपरेशनल काम भी सँभाल सकते हैं जो इंजीनियर रोज़ कम उत्साह से करते हैं—जैसे उस एक Kubernetes पॉड का रिसाइज़ करना।

दोनों लूप्स में, Lê-Quôc ऑपरेशंस के क्रम पर सख़्त हैं। Datadog "यह रहा एआई, यह कौन सी समस्या सुलझा सकता है?" से शुरुआत नहीं करता। वह उसी समस्या से शुरू करता है जिसकी शिकायत ग्राहक पहले से करते हैं—अक्सर "मैं यह दोहराव वाला काम नहीं करना चाहता" के किसी संस्करण से—और फिर पीछे जाकर देखता है कि क्या एजेंट उस पर भरोसे लायक़ है।

पाठ 5: एआई खर्च पर नियंत्रण रखें

लागत सुरक्षा के साथ बैठी बाधा है—और बड़े भाषा मॉडलों को ऑपरेशनलाइज़ करते समय कीमत को काबू में रखना अपने आप में एक विधा बन रहा है। DASH में Lê-Quôc का उत्तर है Datadog का Agent Console।

किसी डेवलपर से पूछें कि उन्हें कौन सा मॉडल चाहिए, तो अक्सर वे सबसे शक्तिशाली (और महँगा) मॉडल बताएँगे। कई बार वही सही होता है—पर बहुत-सा काम बायलरप्लेट होता है जिसे सस्ता, तेज़ मॉडल भी उतनी ही अच्छी तरह कर लेता है। दोनों को अलग बताने का मतलब है किसी संगठन के एजेंट्स की ट्रैजेक्टरी पढ़ना—वे कौन से टूल्स बुलाते हैं, और कितनी बार सफल होते हैं—जब तक पैटर्न उभर न आएँ।

वे पैटर्न नियम नहीं, ह्यूरिस्टिक्स बनते हैं: प्लानिंग के लिए नवीनतम Claude Opus या GPT जैसे फ्रंटियर मॉडल, और टेस्ट जनरेट करने के लिए Claude Haiku जैसा सस्ता मॉडल।

नीचे का सिद्धांत इस बारे में है कि निर्णय का स्वामित्व किसके पास है। लागत को एक ही संख्या में समेट दें, तो Lê-Quôc के शब्दों में "बहुत कम कार्रवारिता" मिलती है: या तो सभी खर्च रोक दें—जो उपयोगी काम मार देता है—या सभी खर्च जारी रखें—जो व्यवसाय नहीं झेल सकता। वे डेटा को उन्हीं डेवलपर्स और SREs के सामने रखना चाहेंगे जो मॉडल चुनते हैं।

पाठ 6: सीखना कैसे सीखें

जब पूछा गया कि नए इंजीनियरों को क्या पढ़ना चाहिए, Lê-Quôc एक ऐसा जवाब देते हैं जो पुराना लगता है—पर है नहीं।

मॉडल अब तक के सबसे धैर्यवान ट्यूटर हैं—कुछ भी, किसी भी रफ़्तार से समझाने में सक्षम—ऐसी पहुँच जो पहले निजी गुरुओं वाले राजाओं को हासिल थी। लेकिन ट्यूटर तभी उपयोगी है जब आप उससे सवाल-जवाब करें। कौशल है—क्या पूछना है और उत्तर कैसे जाँचना है।

वे कंप्यूटर्स को परत-दर-परत समझने की सलाह देते हैं—जादू की तरह नहीं। एक शेड्यूलर, एक लोड बैलेंसर, एक सैंडबॉक्स लें—और किसी मॉडल से पूछें कि यह कैसे काम करता है—फिर आगे बढ़ते रहें:

• यह शब्द क्या मतलब रखता है?
• इसे कैसे मापा जाता है?
• इसके पीछे गणित क्या है?
• आप कैसे जानेंगे कि यह अच्छी तरह काम कर रहा है?

इस तरह क्लासिक्स पढ़ना जान-बूझकर धीमा है। वे इसकी तुलना किसी वाद्य सीखने से करते हैं: आप दिन भर संगीत सुन सकते हैं, पर पियानो बजाने के लिए उँगलियाँ कीज़ पर रखनी पड़ती हैं।

एआई-लिखित कोड पर भी यही लागू होता है। Vibe coding ठीक है, वे कहते हैं—जब तक आप लौटकर नहीं पूछते कि यह क्यों काम किया: इसे ऐसे क्यों बनाया गया, क्या बेहतर तरीके हैं, यह किस पर मॉडल किया गया था। लक्ष्य एआई से कम कोड लिखना नहीं है। लक्ष्य है उस कोड को समझना—जिसका अब आप कहीं अधिक उत्पादन करते हैं।

अंतिम विचार

Lê-Quôc का केंद्रीय संदेश है कि लूप नहीं बदला, गति बदली है। फर्क यह है कि एआई की रफ़्तार पर अब कोई इंसान काफ़ी क़रीब से नहीं देख सकता—तो देखना, और धीरे-धीरे बनाना भी, उन एजेंट्स को सौंपा जाता है जो न थकते हैं, न घबराते हैं।

वे प्रेक्षणीयता को चार्ट्स के सेट के बजाय कंट्रोल प्लेन की तरह मानने की वकालत करते हैं। अगर एजेंट्स सॉफ़्टवेयर लिखने, टेस्ट करने, शिप करने और चलाने वाले हैं, तो उन्हें वही वास्तविक प्रोडक्शन डेटा पर टिकाव चाहिए जिस पर अच्छे इंजीनियर निर्भर करते हैं—साथ में एक व्यक्ति, जो निर्णय और स्टॉप बटन संभाले। Datadog प्रेक्षणीयता को उसी लेयर के रूप में पेश कर रहा है जो इस सौदे को सुरक्षित बनाती है।

इस रूपरेखा का इंजीनियरों से माँगा कौशल साफ़ है: सिस्टम्स को उनके प्रोडक्शन व्यवहार से पढ़ें—सिर्फ़ सोर्स से नहीं। अगर आप यह आदत बनाना चाहते हैं, तो हमारा Machine Learning in Production स्किल ट्रैक एक अच्छी शुरुआत है।