मैंने AWS अकाउंट पर रातों-रात $200 का बिल आते देखा।
सिस्टम क्रैश होने की वजह से नहीं।
एक एजेंट छह घंटे तक बिना किसी रुकने की शर्त के लूप में चला, हर इटरेशन पर OpenAI API को कॉल करता रहा।
हर मॉनिटरिंग डैशबोर्ड कह रहा था कि सब ठीक है।
सुबह इनवॉइस आने तक किसी को पता नहीं चला।
यही होता है जब आप AI सिस्टम बनाते हैं बिना यह समझे कि वे वास्तव में कैसे काम करते हैं।
ज़्यादातर लोग AI इंजीनियरिंग उल्टा सीखते हैं।
लाइब्रेरी इंस्टॉल करो। ट्यूटोरियल फॉलो करो। API कॉल करो। कुछ काम करवा लो। लगता है प्रोग्रेस हो रही है।
फिर कुछ ऐसे तरीके से टूटता है जिसका कोई मतलब नहीं बनता।
वे बेतरतीब ढंग से नंबर बदलते हैं जब तक कि वह काम करना बंद न कर दे।
यह इंजीनियरिंग नहीं है। यह कीबोर्ड के साथ उम्मीद है।
यहाँ 6 कॉन्सेप्ट हैं जो इसे ठीक करते हैं।
वह एक वाक्य जो सब कुछ समझा देता है
हर AI सिस्टम, चाहे कितना भी जटिल हो, बस यह है:
मेमोरी (RAG) + सोच (LLM + टोकन्स) + क्रियाएँ (एजेंट्स) + माप (इवैल्स)
… कॉन्टेक्स्ट इंजीनियरिंग के ज़रिए जोड़ा गया।
बस इतना ही पूरा फील्ड है।
नीचे सब कुछ सिर्फ इसका विस्तार है कि प्रत्येक भाग का वास्तव में क्या मतलब है।
1. टोकन्स और कॉन्टेक्स्ट विंडो
LLM शब्द नहीं पढ़ते। वे टोकन्स नामक टुकड़े पढ़ते हैं।
"engineering" → 1 टोकन
"unbelievable" → 2 टोकन्स स्पेस और पंक्चुएशन भी गिने जाते हैं।
हर मॉडल की एक कॉन्टेक्स्ट विंडो होती है — एक सख्त सीमा कि वह एक बार में कितने टोकन्स रख सकता है।
→ Claude: 200,000 टोकन्स
→ GPT-5: 400,000 टोकन्स
इसे एक मीटिंग रूम में व्हाइटबोर्ड की तरह समझें।
मॉडल सिर्फ उसी के साथ काम करता है जो उस समय बोर्ड पर है।
जब बोर्ड भर जाता है, पुराने नोट्स मिटा दिए जाते हैं ताकि नई जगह बने।
मॉडल सोचने की क्षमता नहीं खोता।
उसे पहले की जानकारी तक पहुँच खोनी पड़ती है।
यह प्रोडक्शन सिस्टम क्यों तोड़ता है:
→ टोकन्स की कीमत होती है — हर API कॉल इनपुट और आउटपुट टोकन के हिसाब से बिल करती है
→ लंबा चैट हिस्ट्री जल्दी विंडो भर देता है
→ जब कॉन्टेक्स्ट भर जाता है, पहले के निर्देश चुपचाप ड्रॉप हो जाते हैं
→ कॉन्टेक्स्ट में क्या जाए, यह एक इंजीनियरिंग निर्णय है, डिफॉल्ट नहीं
वह विफलता जो इसे साबित करती है:
एक टीम ने एक कस्टमर सपोर्ट एजेंट बनाया जिसमें हर रिक्वेस्ट पर पूरा 12 महीने का चैट हिस्ट्री कॉन्टेक्स्ट के रूप में दिया जाता था।
5 इंटरैक्शन के साथ टेस्टिंग में बढ़िया काम किया।
प्रोडक्शन में, 50 इंटरैक्शन के बाद, एजेंट ने अपने ही सिस्टम प्रॉम्प्ट को अनदेखा करना शुरू कर दिया।
निर्देश वहीं थे।
वे 80,000 टोकन्स की कन्वर्सेशन हिस्ट्री के नीचे दब गए थे।
मॉडल ने प्रभावी रूप से उन पर ध्यान देना बंद कर दिया था।
फिक्स कोई बेहतर मॉडल नहीं था।
यह पुरानी हिस्ट्री को सारांशित करना था ताकि विंडो फोकस्ड रहे।
असुविधाजनक सच्चाई:
अधिकांश "प्रॉम्प्ट इंजीनियरिंग विफलताएँ" वास्तव में टोकन और कॉन्टेक्स्ट विंडो की विफलताएँ होती हैं जो भेष बदलकर आई हैं।
इंजीनियर प्रॉम्प्ट को दोष देते हैं जबकि असली समस्या यह है कि महत्वपूर्ण निर्देश 500 लाइनों के कॉन्टेक्स्ट की लाइन 3 पर है, और मॉडल ने उसे वेट करना बंद कर दिया है।
2. एम्बेडिंग्स और वेक्टर सर्च
एम्बेडिंग्स अर्थ को संख्याओं में बदल देती हैं ताकि "समानता" की गणितीय गणना की जा सके।
वे जिस समस्या का समाधान करते हैं:
आपके पास 50,000 दस्तावेज़ हैं। एक उपयोगकर्ता एक प्रश्न पूछता है। आपको सबसे प्रासंगिक 3 चाहिए — हर बार सभी 50,000 पढ़े बिना।
कीवर्ड सर्च यहाँ विफल हो जाता है।
अगर दस्तावेज़ "automobile" कहता है और उपयोगकर्ता "cars" के बारे में पूछता है, तो कीवर्ड सर्च इसे मिस करता है।
इसलिए नहीं कि जवाब वहाँ नहीं है। इसलिए कि शब्द मेल नहीं खाए।
एम्बेडिंग्स इसे अलग तरीके से हल करते हैं।
एक एम्बेडिंग मॉडल टेक्स्ट को एक वेक्टर में बदल देता है — संख्याओं की एक सूची जो गणितीय स्थान में अर्थ का प्रतिनिधित्व करती है।
शब्दार्थ की दृष्टि से समान टेक्स्ट → संख्यात्मक रूप से समान वेक्टर।
"car" और "automobile" → एक-दूसरे के करीब
"car" और "photosynthesis" → बहुत दूर
वेक्टर सर्च वास्तव में कैसे काम करता है:
- हर दस्तावेज़ को एक वेक्टर में बदलकर संग्रहीत किया जाता है
- उपयोगकर्ता का प्रश्न भी एक वेक्टर बन जाता है
- सिस्टम प्रश्न वेक्टर के सबसे निकट संग्रहीत वेक्टर ढूँढता है
- वे आपके सबसे प्रासंगिक दस्तावेज़ हैं
यह अनुमानित जादू नहीं है। यह ज्यामिति है।
समानता एक वास्तविक गणितीय गुण है जिसकी गणना की जा सकती है।
यह प्रोडक्शन में कहाँ दिखाई देता है:
→ किसी भी दस्तावेज़ प्रणाली में सिमैंटिक सर्च
→ समान उत्पाद, लेख, उपयोगकर्ता प्रोफ़ाइल ढूँढना
→ RAG में रिट्रीवल स्टेप (अगला कॉन्सेप्ट)
→ AI एजेंट में मेमोरी
3. RAG (रिट्रीवल-ऑगमेंटेड जनरेशन)
अपने डेटा पर मॉडल को प्रशिक्षित करने के बजाय, आप क्वेरी के समय प्रासंगिक डेटा प्राप्त करते हैं और उसे कॉन्टेक्स्ट के रूप में मॉडल को देते हैं।
RAG जिस समस्या का समाधान करता है:
LLM बहुत कुछ जानते हैं। वे आपका डेटा नहीं जानते।
आपकी कंपनी के आंतरिक दस्तावेज़। आपका प्रोडक्ट डेटाबेस। आपका कस्टमर सपोर्ट हिस्ट्री।
इनमें से कुछ भी ट्रेनिंग सेट में नहीं था।
दो विकल्प: अपने डेटा पर मॉडल को प्रशिक्षित करें (महँगा, धीमा, तुरंत पुराना हो जाता है) या मॉडल को बिल्कुल उसी समय डेटा दें जब उसे ज़रूरत हो।
RAG दूसरा विकल्प है, व्यवस्थित रूप से किया गया।
3-चरणीय पाइपलाइन:
→ रिट्रीव:
प्रश्न एक वेक्टर बन जाता है → वेक्टर डेटाबेस सबसे समान संग्रहीत दस्तावेज़ ढूँढता है → शीर्ष 3-5 चंक प्राप्त होते हैं
→ ऑगमेंट:
प्राप्त दस्तावेज़ मॉडल के कॉन्टेक्स्ट में जोड़े जाते हैं → प्रॉम्प्ट बन जाता है "इस कॉन्टेक्स्ट का उपयोग करते हुए, इस प्रश्न का उत्तर दें"
→ जनरेट:
मॉडल आपके वास्तविक डेटा पर आधारित उत्तर देता है — न कि हेलुसिनेटेड
RAG कहाँ टूटता है:
→ खराब रिट्रीवल = खराब उत्तर। मॉडल केवल उसी के साथ काम कर सकता है जो उसे मिला
→ खराब चंकिंग उत्तर को उसके संदर्भ से अलग कर देती है
→ अगर रिट्रीवल को कुछ उपयोगी नहीं मिलता तो मॉडल फिर भी हेलुसिनेट कर सकता है
एक वास्तविक RAG विफलता:
एक टीम ने 500 पेज के तकनीकी मैनुअल के लिए एक आंतरिक ज्ञान सहायक बनाया।
डेमो में बिल्कुल सही काम किया। प्रोडक्शन में, उत्तर अस्पष्ट और कभी-कभी गलत थे।
समस्या: चंक साइज।
उन्होंने मैनुअल को कच्चे कैरेक्टर काउंट के आधार पर 1,000-टोकन के चंक में विभाजित किया था।
टेबल बीच की पंक्ति में विभाजित हो गए। स्टेप-बाय-स्टेप निर्देश बीच के चरण में विभाजित हो गए।
रिट्रीवल सही सामान्य क्षेत्र ढूँढ़ रहा था — लेकिन वास्तविक उत्तर गायब था।
चंक साइज को आधा करने और ओवरलैप जोड़ने ने रातोंरात 80% समस्याएँ ठीक कर दीं।
कठोर राय:
RAG तब ओवररेटेड है जब आपका रिट्रीवल खराब है।
LLM खराब रिट्रीवल को ठीक नहीं कर सकता। वह केवल उसके आसपास हेलुसिनेट कर सकता है।
यदि आप गलत उत्तर देख रहे हैं, तो अपने प्रॉम्प्ट को ट्वीक करना बंद करें।
अपनी रिट्रीवल सटीकता को मापना शुरू करें।
वहीं पर जवाब है।
4. एजेंटिक लूप
एजेंट बार-बार एक कार्रवाई चुनकर, उसे निष्पादित करके, परिणाम का निरीक्षण करके, और आगे क्या करना है यह तय करके काम करते हैं — जब तक कार्य पूरा न हो जाए।
एक नियमित LLM कॉल स्टेटलेस है। आप पूछते हैं, वह जवाब देता है, हो गया।
एक एजेंट स्टेटफुल है। वह कार्य करता है, निरीक्षण करता है, निर्णय लेता है, दोहराता है।
सरल भाषा में लूप:
- एक लक्ष्य प्राप्त करें
- अगली कार्रवाई तय करें
- उसे निष्पादित करें — सर्च, कोड, फ़ाइल पढ़ना
- परिणाम का निरीक्षण करें
- सीखी गई बातों के आधार पर अगली कार्रवाई तय करें
- तब तक दोहराएँ जब तक लक्ष्य पूरा न हो जाए
- अंतिम उत्तर लौटाएँ
टूल्स ही एजेंटों को शक्ति देते हैं।
टूल्स के बिना, LLM केवल टेक्स्ट के साथ प्रतिक्रिया करता है।
टूल्स के साथ, वह वेब सर्च कर सकता है, फ़ाइलें पढ़ सकता है, कोड लिख सकता है, API कॉल कर सकता है, आपके द्वारा परिभाषित किसी भी कार्रवाई को ट्रिगर कर सकता है।
तीन चीज़ें जो शुरुआती हमेशा गलत करते हैं:
→ बिना स्टॉप कंडीशन के एजेंट हमेशा चलते रहते हैं। आपको यह परिभाषित करना होगा कि कब रुकना है — स्टेप लिमिट, टाइम लिमिट, या गोल कंडीशन
→ अधिक टूल्स ≠ बेहतर प्रदर्शन। बहुत सारे टूल्स मॉडल को भ्रमित करते हैं कि किसका उपयोग करना है
→ टूल एरर को स्पष्ट रूप से हैंडल करने की आवश्यकता है। एक मूक विफलता एजेंट को आत्मविश्वास से कचरा उत्पन्न करने पर मजबूर करती है
$200 की रात भर की विफलता, विस्तार से:
एजेंट के पास कोई अधिकतम स्टेप काउंट नहीं था। उसका लक्ष्य: एक विषय पर शोध करें और एक सारांश तैयार करें।
उसके एक वेब सर्च टूल ने खाली परिणाम लौटाया।
एजेंट को रुकना नहीं आता था।
वह खोजता रहा, पुनः प्रयास करता रहा, मध्यवर्ती सारांश तैयार करता रहा — प्रत्येक दूसरी खोज को ट्रिगर करता रहा।
छह घंटे बाद: 847 LLM कॉल्स। 2.1 मिलियन टोकन्स खपत। एक सुसंगत दिखने वाला लेकिन पूरी तरह से चक्रीय सारांश। $200 का इनवॉइस।
फिक्स तीन लाइनें थीं: एक अधिकतम स्टेप काउंटर, खाली परिणामों के लिए एक स्पष्ट हैंडलर, और कम आत्मविश्वास होने पर एक एस्केलेशन पथ।
वही एजेंट अब औसतन 12 से कम कॉल्स में पूरा होता है।
वह राय जो आपको सुननी चाहिए:
अधिकांश एजेंट इसलिए विफल नहीं होते क्योंकि मॉडल खराब है — बल्कि इसलिए क्योंकि इंजीनियर लूप को स्व-प्रबंधन मानते हैं।
ऐसा नहीं है।
गार्डरेल्स, स्टॉप कंडीशन, एरर हैंडलर्स — शुरू से ही बनाएँ, पहली घटना के बाद नहीं जोड़ें।
5. इवैल्स (मूल्यांकन)
इवैल्स वह तरीका है जिससे आप जानते हैं कि आपका AI सिस्टम वास्तव में काम कर रहा है या नहीं — और क्या किसी बदलाव ने इसे बेहतर या बदतर बनाया।
यह वह अवधारणा है जिसे अधिकांश ट्यूटोरियल छोड़ देते हैं क्योंकि यह अनाकर्षक है।
यह वही है जो डेमो बनाने वाले इंजीनियरों को प्रोडक्शन सिस्टम बनाने वाले इंजीनियरों से अलग करता है।
इवैल्स के बिना समस्या:
आप अपना प्रॉम्प्ट बदलते हैं। अपनी रिट्रीवल लॉजिक अपडेट करते हैं। नए मॉडल पर स्विच करते हैं।
क्या यह बेहतर हुआ?
आप नहीं जानते। आप मैन्युअल रूप से कुछ उदाहरण चेक कर सकते हैं — लेकिन वह एक भावना है, सबूत नहीं।
इवैल्स वास्तव में कैसे दिखते हैं:
→ एक गोल्डन डेटासेट: 25-50 वास्तविक इनपुट जिनमें ज्ञात सही आउटपुट हों, मुख्य उपयोग मामलों को कवर करते हुए साथ ही 5 ज्ञात कठिन एज केस
→ जहाँ संभव हो बाइनरी मीट्रिक्स:
— क्या RAG सिस्टम ने सही दस्तावेज़ प्राप्त किया? हाँ/नहीं
— क्या एजेंट बिना त्रुटि के पूरा हुआ? हाँ/नहीं
— क्या प्रतिक्रिया में आवश्यक जानकारी थी? हाँ/नहीं
→ समय के साथ ट्रैक किए गए समग्र स्कोर:
— रिट्रीवल सटीकता: 89% → परिवर्तन किया → 84%। प्रतिगमन मिला।
— कार्य पूर्णता दर: 76% → नया एजेंट संस्करण → 81%। सुधार की पुष्टि हुई।
इवैल चक्र:
डिप्लॉय → इवैल से मापें → विफलताएँ खोजें → विफलताओं को गोल्डन डेटासेट में जोड़ें → ठीक करें → फिर से इवैल चलाएँ → स्कोर की तुलना करें → केवल तभी शिप करें जब संख्याओं में सुधार हुआ हो
ईमानदार सच्चाई:
"उपयोगिता: 3.7/5" आपको कुछ भी कार्रवाई योग्य नहीं बताता।
"सही दस्तावेज़ प्राप्त किया: 84% समय" आपको बिल्कुल बताता है कि समस्या कहाँ है और एक फिक्स ने इसे कितना सुधारा।
इवैल्स के बिना एक AI सिस्टम उत्पाद नहीं है।
यह एक डेमो है जिसे आप आत्मविश्वास से नहीं बदल सकते।
6. कॉन्टेक्स्ट इंजीनियरिंग
अनुशासन कि मॉडल के कॉन्टेक्स्ट विंडो में वास्तव में कौन सी जानकारी जाती है, इसे कैसे संरचित किया जाता है, और क्या छोड़ा जाता है, इसका सटीक निर्णय लेना।
यहाँ वह राय है जो लोगों को असहज करती है:
प्रॉम्प्ट इंजीनियरिंग से ज़्यादा महत्वपूर्ण कॉन्टेक्स्ट इंजीनियरिंग है।
एक अच्छी तरह से क्यूरेट किए गए कॉन्टेक्स्ट में एक औसत दर्जे का प्रॉम्प्ट, शोर में दबे एक शानदार प्रॉम्प्ट से हर बार बेहतर प्रदर्शन करता है।
अधिकांश टीमें अपने ऑप्टिमाइज़ेशन प्रयास का 80% प्रॉम्प्ट पर खर्च करती हैं और कॉन्टेक्स्ट पर लगभग कुछ नहीं।
परिणाम यही दर्शाते हैं।
भोला दृष्टिकोण विफल होता है:
सब कुछ शामिल करें। सारा इतिहास। सभी प्राप्त दस्तावेज़। हर टूल का विवरण। सिस्टम प्रॉम्प्ट। उपयोगकर्ता संदेश। सब कुछ।
यह एक सुसंगत कारण से विफल होता है: मॉडल भ्रमित हो जाता है कि सबसे महत्वपूर्ण क्या है।
एक प्रलेखित प्रभाव है जिसे "बीच में खो जाना" कहा जाता है — लंबे कॉन्टेक्स्ट में गहराई से दबी जानकारी के उपयोग की संभावना कम होती है।
कॉन्टेक्स्ट इंजीनियरिंग में वास्तव में क्या शामिल है:
→ चयन: इस विशिष्ट निर्णय के लिए किन दस्तावेज़ों, तथ्यों या इतिहास की आवश्यकता है?
→ संपीड़न: क्या वार्तालाप के पुराने हिस्सों को टोकन बचाने के लिए सारांशित किया जा सकता है?
→ क्रम: महत्वपूर्ण निर्देश शुरुआत और अंत में होने चाहिए — बीच में नहीं
→ छंटनी: आउटपुट गुणवत्ता को प्रभावित किए बिना क्या हटाया जा सकता है?
→ संरचना: हेडर, सेपरेटर, लेबल किए गए सेक्शन इस बात को प्रभावित करते हैं कि मॉडल जानकारी का कितनी विश्वसनीय रूप से उपयोग करता है
एक व्यावहारिक उदाहरण:
एक एजेंट 45 मिनट से चल रहा है। उसने 80,000 टोकन्स की कन्वर्सेशन हिस्ट्री जमा कर ली है। उसकी विंडो 128,000 है।
आप मूल लक्ष्य और बाधाओं को खोना नहीं चाहते, भले ही हिस्ट्री विंडो भर रही हो।
कॉन्टेक्स्ट इंजीनियरिंग: पुराने टूल आउटपुट को संपीड़ित करें, पहले के तर्क को सारांशित करें, सत्र भर में कार्य परिभाषा को प्रमुख रखें।
प्रॉम्प्ट इंजीनियरिंग अच्छे निर्देश लिखना है।
कॉन्टेक्स्ट इंजीनियरिंग वह वातावरण बनाना है जिसमें उन निर्देशों का वास्तव में पालन किया जाता है।
ये 6 कॉन्सेप्ट एक सिस्टम कैसे बनाते हैं
मेमोरी → RAG + एम्बेडिंग्स (सिस्टम क्या जानता है)
सोच → LLM + टोकन्स + कॉन्टेक्स्ट विंडो (यह अपने ज्ञान के साथ कैसे तर्क करता है)
क्रियाएँ → एजेंटिक लूप + टूल्स (यह दुनिया में क्या कर सकता है)
माप → इवैल्स (आप कैसे जानते हैं कि यह काम कर रहा है)
गोंद → कॉन्टेक्स्ट इंजीनियरिंग (यह तय करता है कि उपरोक्त सभी के बीच क्या प्रवाहित होता है)
एक साधारण चैटबॉट सिर्फ सोच है।
एक कस्टमर सपोर्ट एजेंट मेमोरी + सोच + क्रियाएँ है।
एक विश्वसनीय प्रोडक्शन सिस्टम माप जोड़ता है।
सोफिस्टिकेशन इस बात में है कि टुकड़े कितनी अच्छी तरह जुड़ते हैं।
किसी एक रिक्वेस्ट के लिए प्रवाह:
उपयोगकर्ता प्रश्न
→ कॉन्टेक्स्ट इंजीनियरिंग तय करती है कि क्या शामिल करना है
→ एम्बेडिंग्स प्रासंगिक मेमोरी प्राप्त करती हैं (RAG)
→ टोकन्स तय करते हैं कि विंडो में कितना फिट होगा
→ LLM संयोजित कॉन्टेक्स्ट पर तर्क करता है
→ एजेंटिक लूप तय करता है कि और जानकारी की आवश्यकता है या नहीं
→ इवैल्स मापते हैं कि आउटपुट वास्तव में सही था या नहीं
कहाँ से शुरू करें
आपको एक साथ सभी छह में महारत हासिल करने की आवश्यकता नहीं है।
→ टोकन्स और कॉन्टेक्स्ट विंडो से शुरू करें — वे आपके द्वारा बनाई गई हर चीज़ को प्रभावित करते हैं → जब आपको सिमैंटिक सर्च या मेमोरी की आवश्यकता हो तो एम्बेडिंग्स जोड़ें
→ जब आपको मॉडल को अपने डेटा में ग्राउंड करने की आवश्यकता हो तो RAG सीखें
→ जब आपको ऑटोमेशन की आवश्यकता हो तो एजेंटिक लूप सीखें
→ प्रोडक्शन में कुछ भी शिप करने से पहले इवैल्स जोड़ें
→ कॉन्टेक्स्ट इंजीनियरिंग तब लागू करें जब बाकी सब कुछ सहज हो जाए
यह क्रम मनमाना नहीं है।
प्रत्येक अवधारणा अगली को सीखने योग्य बनाती है।
ईमानदार अंतिम टिप्पणी
अधिकांश टीमें जो प्रोडक्शन में AI के साथ संघर्ष करती हैं, वे गलत मॉडल या गलत लाइब्रेरी के साथ संघर्ष नहीं कर रही हैं।
वे इसलिए संघर्ष कर रही हैं क्योंकि उन्होंने इन छह अवधारणाओं में से एक को छोड़ दिया।
एजेंट हमेशा लूप करता है क्योंकि किसी ने स्टॉप कंडीशन के बारे में नहीं सोचा।
RAG उत्तर गलत हैं क्योंकि किसी ने रिट्रीवल को मापा नहीं।
लंबे सत्रों में प्रॉम्प्ट काम करना बंद कर देता है क्योंकि किसी ने नहीं समझा कि कॉन्टेक्स्ट विंडो कैसे भरती है।
ये परिष्कृत समस्याएँ नहीं हैं।
ये बुनियादी हैं, तकनीकी शब्दावली में सजी हुई।
उपकरण हर छह महीने में बदलते हैं।
ये छह अवधारणाएँ हैं कि उपकरण कैसे काम करते हैं।
अवधारणाएँ सीखें, और आप कभी भी किसी नए उपकरण से भ्रमित नहीं होंगे।
इससे भी महत्वपूर्ण बात — आप कभी $200 खर्च करके एजेंट को पूरी रात लूप करते हुए नहीं देखेंगे, यह सोचते हुए कि क्या गलत हुआ।
अगर यह उपयोगी था:
→ इसे रिपोस्ट करें और इसे हर उस AI इंजीनियर तक पहुँचाएँ जिसे आप जानते हैं
→ @sairahul1 को फॉलो करें ऐसे और सिस्टम और ब्रेकडाउन के लिए
→ इसे बुकमार्क करें — अगली बार जब प्रोडक्शन में कुछ टूटेगा तो आप इसका संदर्भ लेंगे
मैं AI, उत्पाद निर्माण, और ऐसे सिस्टम के बारे में लिखता हूँ जो आपके सोते समय काम करते हैं।
