OpenAI में FDE का क्या मतलब है
जानें कि हम क्या करते हैं, कैसे काम करते हैं और एंटरप्राइज़ की सबसे मुश्किल समस्याओं को हल करके असल फ़ायदा कैसे पहुँचाते हैं.
लेखक: कॉलिन जार्विस, हेड ऑफ़ फ़ॉरवर्ड डिप्लॉयड इंजीनियरिंग, OpenAI
जब Codex लॉन्च हुआ, तो टीम के एक सदस्य ने मुझसे पूछा, "जिन यूज़ केसेज़ को बनाने में हमने पिछले कई महीने लगाए हैं, अगर Codex उन्हें एक ही कोशिश में पूरा कर सकता है, तो हम क्या करेंगे?"
यही सवाल बताता है कि OpenAI में FDE का असल मतलब क्या है. हम कस्टमर्स के साथ मिलकर उनकी सबसे मुश्किल समस्याओं को समझते हैं और ऐसे सॉल्यूशन्स बनाते हैं, जिन पर वे भरोसा कर सकें. इस काम से हमें जो सीख मिलती है, उससे हमारे प्रोडक्ट्स बेहतर बनते हैं और रिसर्च टीम को हल करने के लिए असल समस्याएँ मिलती हैं.
यही तरक्की है. अगर हर कुछ महीनों में हमारे किए गए काम की ज़रूरत खत्म हो जाती है, तो इसका मतलब है कि हमारी FDE टीम अपना काम अच्छी तरह कर रही है.
मैंने 2025 की शुरुआत में यह टीम बनाई थी, ताकि हम उस अंतर को कम कर सकें जिसे हम "डिप्लॉयमेंट गैप" कहते हैं. यानी मॉडल्स जो काम कर सकते हैं और लोग अपने रोज़मर्रा के काम में उनका भरोसे के साथ जितना इस्तेमाल कर पाते हैं, उनके बीच का अंतर.
मॉडल्स की क्षमताएँ तेज़ी से बढ़ी हैं, लेकिन उन्हें इस्तेमाल करने के लिए ज़रूरी सिस्टम और प्रोसेस उतनी तेज़ी से डेवलप नहीं हुए हैं. कभी कमी किसी प्रोडक्ट की होती है. तो कभी मॉडल किसी बेंचमार्क पर अच्छा परफ़ॉर्म करता है, लेकिन असल दुनिया की बदलती परिस्थितियों और सीमाओं के बीच वही काम नहीं कर पाता.
हमारा फ़ोकस कस्टमर्स की सबसे मुश्किल समस्याओं पर होता है. जहाँ हमारे मॉडल्स आज ही काम कर सकते हैं, वहाँ हम प्रोडक्ट टीम और कस्टमर के साथ मिलकर ऐसा सॉल्यूशन बनाते हैं, जिसे बार-बार इस्तेमाल किया जा सके. जहाँ मॉडल्स की क्षमताएँ कम पड़ती हैं, वहाँ हम कस्टमर्स और रिसर्च टीम के साथ मिलकर कमियों को समझते हैं और सुधार करते हैं. हमारा मकसद है कि हर प्रोजेक्ट के बाद अगले कस्टमर के लिए शुरुआत करना आसान हो—अगर हम टेक्नोलॉजी को इतना बेहतर बना दें कि अगली बार वैसी ही समस्या हल करने के लिए कस्टमर्स को FDE की ज़रूरत न पड़े, तो समझिए हमने अपना काम अच्छी तरह किया है.
लगभग 200 साल पुरानी एग्रीकल्चर कंपनी John Deere के सामने चुनौती थी कि किसानों को उनकी ज़रूरतों के हिसाब से बड़े पैमाने पर सलाह कैसे दी जाए.
इसका एक उदाहरण See & Spray है. यह खरपतवार हटाने की टेक्नोलॉजी है, जो कैमरों और मशीन लर्निंग की मदद से खरपतवार की पहचान करके सिर्फ़ उन्हीं पर स्प्रे करती है. इससे पूरे खेत में केमिकल छिड़कने की ज़रूरत नहीं पड़ती और केमिकल का इस्तेमाल 70% तक कम हो सकता है.
लेकिन इन फ़ायदों का पूरा लाभ तभी मिल सकता है, जब किसानों को पता हो कि इस टेक्नोलॉजी को कैसे कॉन्फ़िगर करना है, फ़सल के सीज़न की प्लानिंग कैसे करनी है और हालात बदलने पर खेती के तरीके कैसे बदलने हैं.
John Deere ने किसानों को उनकी ज़रूरतों के हिसाब से बड़े पैमाने पर मदद देने के लिए OpenAI की API का इस्तेमाल शुरू किया.
AI किसानों के सवालों के जवाब आम बोलचाल की भाषा में दे सकता है. यह उनकी ज़रूरतों के हिसाब से सेटअप करने के तरीके और सुझाव दे सकता है. साथ ही, यह पहचान सकता है कि कब कोई मशीन अपनी पूरी क्षमता से काम नहीं कर रही है और किसानों को यह समझने में मदद कर सकता है कि उन्हें इस टेक्नोलॉजी से कितना फ़ायदा मिल रहा है.
इसका फ़ायदा सिर्फ़ एक बार की बातचीत तक सीमित नहीं है. इसका मकसद पूरे कस्टमर एक्सपीरियंस के दौरान सही समय पर काम की सलाह देना है. इससे किसान अपने इक्विपमेंट्स का बेहतर इस्तेमाल कर सकते हैं, काम की एफ़िशिएंसी बढ़ा सकते हैं और पर्यावरण पर पड़ने वाले असर को कम कर सकते हैं.
OpenAI के FDE इसी तरह के चैलेंज सुलझाने पर काम करते हैं. वे ऑर्गेनाइज़ेशन्स को AI की क्षमताओं से आगे बढ़कर ऐसे सिस्टम बनाने में मदद करते हैं, जो असल दुनिया की मुश्किल परिस्थितियों में भी काम आएँ और बिज़नेस को फ़ायदा पहुँचाएँ.
लेकिन अक्सर ये समस्याएँ ऐसी होती हैं, जिनका हल पहले से तय नहीं होता. कई बार सही जवाब भी मालूम नहीं होता और काम करने का कोई बना-बनाया तरीका भी नहीं होता. हर कोई कुछ ऐसा बनाना चाहता है, जो पहले कभी नहीं बना. लेकिन वहाँ तक पहुँचने के लिए जो मेहनत करनी पड़ती है, उसे करने के लिए कम ही लोग तैयार होते हैं.
काबिल FDE ढूँढने के साथ-साथ अच्छे काम के स्टैंडर्ड्स लगातार बेहतर बनाने के लिए हमें नए तरीके आज़माने और उन्हें असल काम में लागू करने की ज़रूरत पड़ी है.
हर FDE टीम सेशन की शुरुआत में मैं एक स्लाइड दिखाता हूँ, जिसमें हमारी एक अहम सोच लिखी होती है: "पहले नतीजे पर फ़ोकस करें, कामयाबी के लिए जो ज़रूरी हो वह करें और फिर उसे बड़े पैमाने पर ले जाएँ."
कोई शानदार डेमो लोगों को लंबे समय तक प्रभावित कर सकता है, इससे पहले कि कोई पूछे कि क्या वह असल में भी काम करता है.
हमारा काम कस्टमर की समस्या को इस तरह हल करना है कि प्रोडक्शन में भी हमारा सॉल्यूशन भरोसेमंद तरीके से काम करे.
2025 के बीच में हमारे लगभग 15 FDE एक बड़ी सेमीकंडक्टर कंपनी के साथ 10 से ज़्यादा यूज़ केसेज़ पर काम कर रहे थे. हमारा मकसद उनके वेरिफ़िकेशन प्रोसेस को AI-नेटिव बनाना था. इसमें ये काम शामिल थे:
डायरेक्टेड टेस्ट जेनरेशन
कर्नेल ऑप्टिमाइज़ेशन से मीडियन परफ़ॉर्मेंस में 22% का सुधार
एक आर्किटेक्चर असिस्टेंट
इस इंडस्ट्री में किसी प्रोजेक्ट की कुल मेहनत का लगभग 70% हिस्सा वेरिफ़िकेशन में लग सकता है. इसलिए AI से इसमें सुधार करने की काफ़ी गुंजाइश थी और शुरुआत करने के लिए कई ऑप्शन मौजूद थे.
कुछ FDE ने कुछ दिन पहले ही OpenAI से जुड़े थे और उन्हें सेमीकंडक्टर इंडस्ट्री में काम करने का कोई अनुभव नहीं था. वे कस्टमर की वेरिफ़िकेशन टीम के साथ मिलकर काम करने लगे. अपने खाली समय में उन्होंने चिप डिज़ाइन के बारे में सीखा और इंजीनियर्स के साथ मिलकर इवैल्स बनाए. इनकी मदद से उन्होंने देखा कि AI काम के टेस्ट बना सकता है या नहीं और चिप में आने वाली खराबियों की सही वजह पहचान सकता है या नहीं.
इस दौरान सीखने के साथ-साथ हमने हर यूज़ केस के लिए कस्टम टेस्टिंग हार्नेस भी बनाए. पहले 3 से 6 महीनों में ये सभी प्रोडक्शन तक पहुँच गए और यूज़र्स ने भी इनका इस्तेमाल शुरू कर दिया. इसके नतीजे आँकड़ों में साफ़ दिखे:
AI-बेस्ड डायरेक्टेड टेस्ट जेनरेशन से लगभग 48% समय की बचत.
कर्नेल ऑप्टिमाइज़ेशन से मीडियन परफ़ॉर्मेंस में 22% का सुधार.
कई हफ़्तों की डीबगिंग का काम कुछ घंटों में पूरा हुआ
जब हमने ये सभी नतीजे चीफ़ हार्डवेयर ऑफ़िसर को दिखाए, तो उन्होंने पूछा, "क्या आप लोग यहाँ आने से पहले चिप डिज़ाइनर्स के तौर पर काम करते थे?"
हमारे FDE के लिए पहले दिन से इंडस्ट्री की पूरी जानकारी होना ज़रूरी नहीं है. लेकिन उसके बारे में सीखना उनकी ज़िम्मेदारी है.
कोडिंग असिस्टेंट्स की मदद से सॉफ़्टवेयर बनाना तेज़ हो रहा है. ऐसे में कस्टमर के बिज़नेस को समझना और भी ज़रूरी हो जाता है. इसलिए हम ऐसी टीमें बनाते हैं, जिनमें अलग-अलग तरह के काम करने वाले लोग और किसी खास फ़ील्ड के एक्सपर्ट्स, दोनों शामिल होते हैं.
आपके पास इतनी जानकारी होनी चाहिए कि आप सोच-समझकर सही फ़ैसले ले सकें. साथ ही, इतनी जिज्ञासा भी होनी चाहिए कि आप मौजूदा तरीकों पर सवाल उठा सकें.
उदाहरण के लिए, लाइफ़ साइंसेज़ में हमारे FDE का साइंस बैकग्राउंड उन्हें रिसर्चर्स का भरोसा जीतने में मदद करता है. ये रिसर्चर्स प्री-क्लिनिकल ड्रग डिस्कवरी से जुड़े काम करते हैं, जैसे ड्रग टारगेट्स की जाँच करके उनकी प्रायोरिटी तय करना, जीन एक्सप्रेशन का एनालिसिस करना और केमिकल सिंथेसिस के तरीकों को दोबारा तैयार करना. अपनी एक्सपर्टीज़ की मदद से FDE बेहतर समझ पाते हैं कि इन वर्कफ़्लो में कैसे सुधार किया जा सकता है.
हम दिखा चुके थे कि इन वर्कफ़्लो से फ़ायदा मिल सकता है. लेकिन इन्हें दूसरी टीमों तक पहुँचाने के लिए अब भी काफ़ी कस्टम इंटीग्रेशन करना पड़ता था. अगली चुनौती थी इन फ़ायदों को बनाए रखते हुए सॉफ़्टवेयर को डिप्लॉय और मेंटेन करना आसान बनाना.
तब तक Codex की क्षमताएँ काफ़ी बेहतर हो चुकी थीं. एक FDE ने Codex को आधार बनाकर अपनी ऐप्लिकेशन दोबारा बनाने का टेस्ट किया. इसके बाद उसने टीम के साथ मिलकर सभी यूज़ केसेज़ को एक कॉमन हार्नेस पर शिफ़्ट किया, जिसका आधार Codex था.
कस्टम ऐप्लिकेशन्स की जगह कॉमन Codex प्रिमिटिव्स पर बने प्लगइन्स और स्किल्स ने ले ली. Codex ही मुख्य इंटरफ़ेस भी बन गया. इससे हम अलग-अलग यूज़ केसेज़ के लिए बनाए गए टर्मिनल UI और CLI का इस्तेमाल बंद कर पाए.
हम हर प्रोजेक्ट से लगभग 90% कस्टम कोड हटा पाए. इससे इन वर्कफ़्लो को बनाने, मेंटेन करने और बड़े पैमाने पर इस्तेमाल करने का हमारा तरीका बदल गया:
Codex में एक ही जगह किए गए सुधारों का फ़ायदा सभी यूज़ केसेज़ को मिलने लगा, जिससे हर यूज़ केस में अलग-अलग कम्पोनेंट्स को जोड़ने के लिए कम ग्लू कोड लिखना पड़ता था
अहम फ़ीचर्स को स्किल्स और प्लगइन्स के रूप में पैकेज किया गया. इससे टीमों के बीच इन्हें शेयर करना और AI CoE के लिए एक ही जगह से इन्हें मैनेज करना आसान हो गया. अब किसी सॉल्यूशन को एक टीम से दूसरी टीम तक ले जाने के लिए बस नए कनेक्टर्स या MCP सर्वर्स जोड़ने, नए इवैल्स बनाने और सिस्टम शुरू करने की ज़रूरत पड़ सकती थी. इवैल्स बनाने के लिए भी हमारे पास एक स्किल थी.
अगस्त 2026 के एक उदाहरण में, शुरुआती डिप्लॉयमेंट में दो महीने लगे. लेकिन उसी सॉल्यूशन को दूसरी टीम तक पहुँचाने में सिर्फ़ एक दिन लगा. जैसे-जैसे हमने इसे बड़े पैमाने पर इस्तेमाल करना शुरू किया, अगली टीमों की ऑनबोर्डिंग और तेज़ होती गई. अगस्त 2026 में भी एक यूज़ केस में शुरुआती डिप्लॉयमेंट के दो महीने के मुकाबले दूसरी टीम को जोड़ने में सिर्फ़ एक दिन लगा.
एक तरह से इसका मतलब है कि हमने अपने ही कुछ कामों की ज़रूरत खत्म कर दी. प्रोडक्शन तक पहुँचने के दौरान किए गए काम से हमें समझ आया कि सबसे ज़रूरी क्या है. फिर जैसे-जैसे असली प्रोडक्ट बेहतर हुआ, हम अपने ज़्यादातर कस्टम सॉल्यूशन्स की जगह नए फ़ीचर्स इस्तेमाल कर पाए, बिना उनके फ़ायदों को खोए.
इसलिए काम करने का क्रम मायने रखता है. LLM की मदद से हम तेज़ी से चीज़ें बना सकते हैं. इस तेज़ी का इस्तेमाल करके पहले यूज़र्स तक कोई काम की चीज़ पहुँचाएँ. फिर असल इस्तेमाल से सीखें कि क्या अच्छा काम करता है और उसके बाद उसे बड़े पैमाने पर ले जाएँ.
यही तरीका हमारे सभी कस्टमर प्रोजेक्ट्स पर लागू होता है.
हमारा एंटरप्राइज़ वॉइस और चैट एजेंट्स वाला प्रोडक्ट OpenAI Presence, कस्टमर्स के साथ असल डिप्लॉयमेंट्स पर काम करने के अनुभव से तैयार हुआ है. इस काम की शुरुआत स्वार्म(एक नई विंडो में खुलेगा) से हुई और फिर यह Agents API के साथ आगे बढ़ा. आज हमारा एक कस्टमर अपनी आधे से ज़्यादा कॉल्स AI की मदद से सँभाल रहा है.
इन डिप्लॉयमेंट्स को प्रोडक्शन तक पहुँचाने से हमें समझ आया कि किन समस्याओं के लिए कस्टम सॉल्यूशन चाहिए और कौन-से बिल्डिंग ब्लॉक्स दूसरी टीमें भी इस्तेमाल कर सकती हैं. हमने इन बिल्डिंग ब्लॉक्स को Presence में शामिल किया. इससे डेवलपर्स के लिए नियमों के दायरे में आने वाले वर्कफ़्लो को ऑटोमेट करना आसान हो गया. अब उन्हें हर बार पूरा इंफ़्रास्ट्रक्चर दोबारा बनाने की ज़रूरत नहीं है. हर डिप्लॉयमेंट से प्रोडक्ट को बेहतर बनाने में मदद मिली और अगले कस्टमर के लिए शुरुआत करना आसान हुआ.
OpenAI के FDE और रिसर्चर्स ने Thrive Holdings के साथ मिलकर इंजीनियर्स और अकाउंटेंट्स की मदद से Crete की अकाउंटिंग फ़र्म्स के लिए Tax AI बनाया. पायलट के दौरान Tax AI ने 7,000 टैक्स रिटर्न्स प्रोसेस किए और उतने ही रिसोर्सेज़ से लगभग 50% ज़्यादा काम पूरा करना मुमकिन बनाया.
सबसे मुश्किल कामों में से एक था किराए पर दी गई प्रॉपर्टी से जुड़े टैक्स रिटर्न्स को ऑटोमेट करना. इसमें 90% प्रिसिज़न और रिकॉल हासिल करने के लिए छह हफ़्तों तक इंजीनियरिंग टीम और टैक्स एक्सपर्ट्स को काम की जाँच करनी पड़ी. इस काम से ऐसे तरीके तैयार हुए, जिन्हें दोबारा इस्तेमाल किया जा सकता है. इससे Tax AI को दूसरे मुश्किल टैक्स शेड्यूल्स के लिए भी इस्तेमाल करना आसान हो गया.
अब टीमें इसी तरीके का इस्तेमाल बुककीपिंग, ऑडिट और IT सपोर्ट में कर रही हैं. वे ऐसे सिस्टम बना रही हैं, जो एक्सपर्ट्स के फ़ीडबैक और असल काम में इस्तेमाल होने के साथ लगातार बेहतर होते जाते हैं.
कभी-कभी बेहतर प्रोडक्ट की मदद से हम अपने बनाए सिस्टम को आसान बना सकते हैं. लेकिन कई बार मॉडल खुद वह काम नहीं कर पाता.
अगर हम सिर्फ़ वही बनाएँ जो आज के मॉडल्स पहले से कर सकते हैं, तो हमें उनकी उन कमियों का पता नहीं चलेगा, जिन्हें रिसर्च टीम को आगे दूर करना है. इसलिए हमारे कई अहम कस्टमर प्रोजेक्ट्स मॉडल की मौजूदा सीमाओं से ही शुरू होते हैं. इनमें कस्टमर, FDE और रिसर्च टीम मिलकर उन सीमाओं को पार करने के लिए काम करते हैं.
हमने एक बड़ी टेलीकॉम कंपनी के साथ मिलकर पहले ही कस्टमर सर्विस प्लेटफ़ॉर्म बना चुके थे. अब वे उसमें वॉइस सपोर्ट भी जोड़ना चाहते थे.
उनकी कस्टमर सर्विस से जुड़े लगभग 90% मामले वॉइस के ज़रिए आते थे. चैट के मुकाबले इन मामलों को बिना किसी इंसान की मदद के सँभालने में ज़्यादा खर्च आता था. साथ ही, अलग-अलग लहज़े, बोलने के अंदाज़, रिस्पॉन्स टाइम और जवाबों की क्वालिटी को प्रोडक्शन के लायक बनाना भी एक बड़ी टेक्निकल चुनौती थी. अगर यह काम अच्छी तरह हो जाता, तो उनके बिज़नेस को काफ़ी फ़ायदा हो सकता था.
प्रोजेक्ट का स्कोप तय करते समय हमने कुछ अहम इवैल्स के ज़रिए जाँचा कि हमारा मॉडल प्रोडक्शन में यह काम कर पाएगा या नहीं. इन इवैल्स में मॉडल का स्कोर लगभग 60% था. मॉडल अपनी मौजूदा क्षमताओं की सीमा तक पहुँच चुका था. कस्टमर सर्विस से जुड़े मामलों में फ़ंक्शन कॉलिंग और इंस्ट्रक्शन्स फ़ॉलो करने की इसकी क्षमता बेहतर बनाने की ज़रूरत थी.
हमने कस्टमर को यह बात समझाई और रिसर्च टीम को भी इस काम में शामिल किया. FDE टीम ने कस्टमर के साथ मिलकर प्लेटफ़ॉर्म बनाया और तय किया कि मॉडल को कौन-कौन से काम करने चाहिए. रिसर्च टीम ने मॉडल की कमियों को दूर करने पर काम किया. मॉडल के लगातार आने वाले नए स्नैपशॉट्स की मदद से हम टेस्ट करते रहे कि वह कस्टमर की ज़रूरतों के हिसाब से कितना बेहतर हो रहा है.
छह महीनों में अहम इवैल्स पर मॉडल की परफ़ॉर्मेंस लगभग 60% से बढ़कर पहले 80% और फिर 90% से ज़्यादा हो गई. इस तरह मॉडल ने प्रोडक्शन में इस्तेमाल के लिए ज़रूरी परफ़ॉर्मेंस हासिल कर ली.
इस काम से तैयार हुआ वॉइस मॉडल अब उस कस्टमर के डिप्लॉयमेंट के साथ-साथ दूसरे कस्टम कस्टमर-सर्विस डिप्लॉयमेंट्स और Presence के ज़रिए मैनेज्ड डिप्लॉयमेंट्स को भी सपोर्ट करता है. एक कस्टमर के बिज़नेस में आई समस्या से ऐसे सुधारों का पता चला, जिनका फ़ायदा कई दूसरे कस्टमर्स को भी मिल सकता है.
इसमें हर किसी की अहम भूमिका थी. हमारे कस्टमर ऐसी समस्या पर काम करने के लिए तैयार थे, जिसे मॉडल अभी हल नहीं कर सकता था. FDE ने कस्टमर के साथ मिलकर समस्या को अच्छी तरह समझा, प्लेटफ़ॉर्म बनाया और पूरे प्रोजेक्ट को शुरू से आख़िर तक आगे बढ़ाया. वहीं, रिसर्च टीम ने मॉडल की मौजूदा क्षमताओं को बेहतर बनाया.
यह अपने कुछ कामों की ज़रूरत खत्म करने का एक और तरीका है. हम ऐसी समस्याओं को हल करने पर काम करते हैं, जिन्हें आज के मॉडल्स नहीं सुलझा सकते, ताकि आने वाले मॉडल्स उन्हें हल कर सकें. हमारे काम का फ़ायदा किसी एक कस्टमर के साथ बिताए गए समय से कहीं आगे तक जाता है.
मैंने OpenAI इसलिए जॉइन किया था, ताकि AI को लोगों के रोज़मर्रा के काम में मदद कर सकूँ. आज भी हमारी टीम इसी मकसद से काम करती है. मैं अक्सर टीम से कहता हूँ कि LLM डेवलपमेंट के ज़्यादातर मामलों में ऑकम्स रेज़र का सिद्धांत लागू होता है—सबसे आसान सॉल्यूशन ही सबसे अच्छा होता है. हमारी कंपनी की पहचान उसकी सबसे एडवांस्ड रिसर्च से है. वहीं, AI इंडस्ट्री में अक्सर बढ़ा-चढ़ाकर दावे किए जाते हैं. ऐसे में हम ऐसी टेक्नोलॉजी बनाना चाहते हैं, जो भरोसेमंद तरीके से काम करे और जिस पर फ़ील्ड में काम करने वाले लोग यकीन कर सकें.
हमारा मकसद है कि हर कस्टमर प्रोजेक्ट से अगला काम और आसान हो. चाहे वह ऐसा प्रोडक्ट हो जिसे डिप्लॉय करना आसान हो, ऐसा मॉडल हो जो ज़्यादा मुश्किल काम कर सके या फिर अगले कस्टमर के लिए कम अलग काम करने की ज़रूरत पड़े.
अगर आपके पास कोई मुश्किल समस्या है जिसे आप हल करना चाहते हैं, तो हमें आपके साथ काम करके खुशी होगी. और अगर आप ऐसी समस्याओं को सुलझाने में मदद करना चाहते हैं, तो हमें आपको अपनी टीम में शामिल करके खुशी होगी.
तो जब Codex वह काम कर सकता है, जिसे तैयार करने में हमने महीनों लगाए थे, तब फिर हम क्या करते हैं?
उससे भी मुश्किल समस्या ढूँढते हैं.
