हमने ChatGPT के लिए नया ऐड्स सिस्टम कैसे बनाया, जो यूज़र्स का भरोसा बनाए रखता है और सही ऐड दिखाता है

सामान्य ऐडवर्टाइज़िंग सिस्टम्स को यूज़र की अलग-अलग, साफ़ तौर पर पहचानी जा सकने वाली ज़रूरतों के आधार पर काम करने के लिए बनाया जाता है. जब कोई यूज़र ऑनलाइन कुछ सर्च करता है या कोई पेज देखता है, तो ऐड्स सिस्टम इन सर्च क्वेरीज़ और पेज व्यूज़ को इवेंट्स के तौर पर रिकॉर्ड करता है. फिर इनके आधार पर मैच करने वाले ऐड्स ढूँढता है. लेकिन ChatGPT के लिए ऐड्स सिस्टम बनाना अलग था. यहाँ यूज़र की ज़रूरत अलग-अलग बातचीत में डेवलप होती है और एक ही बातचीत के कई मोड़ में बदल सकती है. कभी-कभी बातचीत में ऐड दिखाने का सही मौका भी नहीं होता. इस नए तरीके को सपोर्ट करने के लिए हमने खास तौर पर एक ऐड डिलीवरी सिस्टम बनाया. यह नए तरह का ऐड्स सिस्टम एक कस्टम, पोस्ट-ट्रेंड फ़्रंटियर LLM पर आधारित है. यह LLM रिट्रीवल (सबसे सही संभावित ऑप्शन्स पहचानना), रैंकिंग (यूज़र के ऐड के साथ इंटरैक्ट करने की संभावना का अनुमान लगाना), रेलेवेंस (ऐड कितना काम का है, यह तय करना) और फ़ाइनल ऐड चुनने व उसकी कीमत तय करने के लिए ऑक्शन चलाने जैसे कामों के लिए टूल्स कॉल करता है.

यूज़र्स के बदलते लक्ष्यों और उनकी बारीकियों को समझने के लिए हमने अपने ऐड्स सिस्टम के डिज़ाइन में तीन अहम फ़ैसले लिए: 1) स्टेटफ़ुल ऐड्स सेशन्स लागू करना, ताकि बातचीत के अलग-अलग टर्न्स और कई बातचीत के दौरान मिली जानकारी याद रखी जा सके. 2) कस्टम, पोस्ट-ट्रेंड LLM इस्तेमाल करना, जो टूल कॉल आर्किटेक्चर की मदद से बातचीत का कॉन्टेक्स्ट और यूज़र की असली ज़रूरत समझता है. फिर सही ऐड्स चुनता है, उनकी रैंकिंग करता है और उन्हें डिलीवर करता है. 3) ऐड्स चुनने के प्रोसेस को ChatGPT के जवाब तैयार करने के प्रोसेस से अलग, अपनी अलग सर्विस में चलाना, ताकि ऐड्स का जवाबों पर असर न पड़े और ChatGPT का टोन न्यूट्रल बना रहे. हम अपने पोस्ट-ट्रेंड LLM से ऐड्स का पूरा प्रोसेस मैनेज करवाते हैं. यह यूज़र के मौजूदा चैट टर्न और पिछली बातचीत, दोनों के आधार पर तय करता है कि सही समय पर कौन-सा ऐड दिखाना चाहिए. पहले ऐसा ऐड्स सिस्टम शुरुआत से बनाने में कई साल लगते थे, जो अपने नतीजों से सीखकर खुद को बेहतर बना सके. लेकिन ChatGPT ऐड्स ने लॉन्च के 200 दिनों से भी कम समय में $1 अरब का सालाना रेवेन्यू रन रेट हासिल कर लिया. अब तक लॉन्च के बाद से 1 लाख से ज़्यादा एडवर्टाइज़र्स ChatGPT पर ऐड्स चला चुके हैं.

सामान्य ऐडवर्टाइज़िंग रिक्वेस्ट आम तौर पर किसी साफ़ तौर पर तय इवेंट से शुरू होती है. जैसे, यूज़र कोई सर्च क्वेरी सबमिट करता है या वेबपेज खोलता है और ऐड्स सिस्टम को रिक्वेस्ट मिलती है. इस तरह का सिस्टम काफ़ी सीधा होता है. यह संभावित ऐड्स ढूँढता है, उनकी रैंकिंग करता है, ऐड दिखाने के मौके की सही कीमत तय करने के लिए ऑक्शन चलाता है और चुना गया ऐड यूज़र को दिखाता है. लेकिन ChatGPT में इस तरह का कोई साफ़ तौर पर तय पल अपने आप नहीं आता.

ChatGPT में लोग सिर्फ़ एक सवाल का जवाब पाने के बजाय किसी मकसद के साथ बातचीत शुरू करते हैं. हो सकता है कि वे ट्रिप प्लान कर रहे हों, अपने बिज़नेस के लिए सॉफ़्टवेयर चुन रहे हों, घर के लिए फ़र्नीचर खरीद रहे हों या कोई नया शौक सीख रहे हों. ये सारे काम बातचीत के एक ही टर्न में पूरे नहीं होते. अक्सर ChatGPT बातचीत के दौरान यूज़र को यह समझने में मदद करता है कि उसके लिए सबसे ज़रूरी क्या है.

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

अपना ऐड्स सिस्टम बनाने के लिए हमें सामान्य रिक्वेस्ट-रिस्पॉन्स ऐडवर्टाइज़िंग आर्किटेक्चर से आगे बढ़ना पड़ा. हमने शुरुआत से एक नया ऐड्स सिस्टम बनाया, जो कमाई के संभावित मौके पहचान सके और साथ ही यूज़र्स के भरोसे और उन्हें मिलने वाले फ़ायदे को सबसे आगे रखे.

सामान्य ऐड्स सिस्टम की तरह हर मैसेज को एक अलग रिक्वेस्ट मानने से ChatGPT जैसे चैट प्रोडक्ट में कुछ रिस्क होते: 1) यूज़र के लक्ष्य को बहुत ज़्यादा आसान बनाकर समझने की कोशिश में उसका गलत मतलब निकालना, 2) यूज़र की असली ज़रूरत साफ़ होने से पहले ही ऐड्स का प्रोसेस शुरू कर देना, 3) ऐसे ऐड्स दिखाना जो यूज़र की मदद करने के बजाय उसके काम में रुकावट डालें और 4) हर बार रिक्वेस्ट बदलने पर ऐड्स का पूरा प्रोसेस बेवजह दोबारा चलाना, जिससे गैर-ज़रूरी नतीजे मिलें और खर्च बढ़े. इसलिए अलग-अलग इवेंट्स पर निर्भर रहने के बजाय, हमारा ऐड्स सिस्टम (जिसमें रिट्रीवल, रैंकिंग और डिलीवरी शामिल हैं) एक स्टेटफ़ुल सेशन बनाए रखता है. इसका मतलब है कि जिस चैट टर्न में ऐड दिखाने की शर्तें पूरी होती हैं, उस पूरे टर्न के दौरान ऐड्स सेशन चलता रहता है. इस बीच नई जानकारी आने पर वह उसे याद रखता है और अपडेट करता है. ChatGPT शुरुआती रिक्वेस्ट का कॉन्टेक्स्ट ऐड्स सर्वर को भेजता है. ऐड्स सिस्टम पूरी बातचीत को एक ही क्वेरी में समेटने के बजाय बातचीत के आगे बढ़ने के साथ उसके कॉन्टेक्स्ट को समझता है और उसी हिसाब से खुद को बदलता है.

ऐड्स चुनने का प्रोसेस, ChatGPT के सामान्य जवाब तैयार करने के प्रोसेस के साथ-साथ लेकिन अलग चलता है, ताकि ऐड्स का ChatGPT के जवाबों पर कोई असर न पड़े. ऐड्स को फ़िल्टर और सेलेक्ट करने वाला सिस्टम अलग होता है. यह बातचीत के कॉन्टेक्स्ट का इस्तेमाल करता है और ऐड दिखाने की अपनी एलिजिबिलिटी, क्वालिटी और डिलीवरी से जुड़ी शर्तों के आधार पर काम करता है. सिस्टम के डिज़ाइन में यह अलगाव बहुत अहम है. दोनों के लिए अलग सर्विसेज़, अलग मॉडल्स और अलग कोड इस्तेमाल होते हैं. इससे ChatGPT के मुख्य सर्वर्स सामान्य जवाब तैयार करने का काम संभालते हैं. वहीं, ऐड्स सिस्टम अलग से परखता है कि बातचीत में ऐड दिखाने का सही मौका है या नहीं. अगर ऐसा मौका मिलता है, तो वह अपनी अलग डिलीवरी प्रोसेस के ज़रिए स्पॉन्सर्ड ऐड तैयार करता है.

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

हमारे ऐड्स सिस्टम का एक और अहम हिस्सा पोस्ट-ट्रेंड LLM है. यह बातचीत को समझता है और एजेंटिक लूप में ऐड्स दिखाने की पूरी प्रोसेस चलाता है—इसके लिए यह ऐड्स सिस्टम के मुख्य टूल्स इस्तेमाल करता है, जिनमें संभावित ऐड्स ढूँढना, उनकी रैंकिंग करना, ऑक्शन चलाना और आखिर में ऐड दिखाना शामिल है. हम इस LLM को ऑर्केस्ट्रेटर कहते हैं.

ऐड्स की प्रोसेस का पहला स्टेप यूज़र की ज़रूरत समझना है. इसके बाद संभावित ऐड्स ढूँढने का प्रोसेस शुरू होता है, जिसमें तेज़ी से कई तरह के ऐड्स ढूँढे जाते हैं, ताकि बाद में उनमें से सही ऐड चुना जा सके. जैसे-जैसे बातचीत आगे बढ़ती है, सिस्टम को ज़्यादा जानकारी मिलती है, लेकिन सही ऐड ढूँढना मुश्किल भी हो सकता है. ऐसा इसलिए, क्योंकि ऐड्स सिस्टम को यूज़र की मौजूदा ज़रूरत और बातचीत के पुराने कॉन्टेक्स्ट के बीच फ़र्क समझना होता है. ऑर्केस्ट्रेटर को पहले के मैसेज के रेफ़रेंस समझने होते हैं, यह पहचानना होता है कि यूज़र किसी काल्पनिक स्थिति की बात कर रहा है या नहीं, और किसी प्रोडक्ट या सर्विस के हर ज़िक्र को खरीदने की इच्छा नहीं मानना होता.

ऐड्स ऑर्केस्ट्रेटर उपलब्ध बातचीत और यूज़र के कॉन्टेक्स्ट का इस्तेमाल करके सही ऐड ढूँढने के लिए बार-बार अलग-अलग टूल्स चलाता है. यह खुद तय करता है कि कौन-सा टूल कब इस्तेमाल करना है. इसका मकसद बातचीत और कॉन्टेक्स्ट के हिसाब से सबसे सही ऐड ढूँढना है, जिससे यूज़र और एडवर्टाइज़र, दोनों को अच्छा फ़ायदा मिले. अगर कोई यूज़र पर्सनलाइज़्ड ऐड्स चुनते हैं, तो ऑर्केस्ट्रेटर उनकी पिछली बातचीत से उपलब्ध नॉन-सेंसिटिव जानकारी भी ध्यान में रखता है, ताकि उससे मैच करने वाले बेहतर ऐड्स मिल सकें.

जैसे-जैसे बातचीत आगे बढ़ती है और ऐड्स ऑर्केस्ट्रेटर को नई जानकारी मिलती है, वह अपडेट किए गए कॉन्टेक्स्ट के आधार पर टूल्स दोबारा चला सकता है. इससे वह ज़्यादा सही ऐड्स ढूँढकर क्लाइंट ऐप को भेज सकता है. अगर ये नए ऐड्स समय पर पहुँच जाते हैं, तो ऐप इन्हें इस्तेमाल कर सकता है.

ऑर्केस्ट्रेटर को यूज़र्स और एडवर्टाइज़र्स, दोनों को मिलने वाले फ़ायदे के बीच बैलेंस बनाने के लिए डिज़ाइन किया गया है. इसमें यूज़र्स को हमेशा पहली प्रायोरिटी दी जाती है.

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

ऑर्केस्ट्रेटर LLM सबसे पहले एक या उससे ज़्यादा क्वेरीज़ तैयार करता है, जो बातचीत में खरीदारी या बिज़नेस से जुड़ी ज़रूरत को दिखाती हैं. इसके लिए वह बातचीत के कॉन्टेक्स्ट को नए तरीके से लिख सकता है, ताकि सिर्फ़ यूज़र के शब्दों से सीधे मैच करने वाली सर्च क्वेरीज़ तक सीमित न रहकर ज़्यादा संभावित ऑप्शन्स ढूँढे जा सकें. इसके बाद वह बातचीत के मतलब को सिमैंटिक फ़ॉर्मैट में बदलता है. इसमें कई मैसेजेज़ वाली बातचीत की समरी तैयार की जाती है, ताकि रिट्रीवल सिस्टम हमारे डेटाबेस से उससे जुड़े ऐड्स बेहतर तरीके से ढूँढ सके.

यूज़र और एडवर्टाइज़र, दोनों के लिए ऐड्स तभी ज़्यादा काम के होंगे, जब सिस्टम यूज़र की ज़रूरत अच्छी तरह समझने के बाद ही उन्हें दिखाए. कई क्वेरीज़ इस्तेमाल करने से यूज़र की अलग-अलग ज़रूरतों को ध्यान में रखा जा सकता है. उदाहरण के लिए, किसी ट्रिप की प्लानिंग से जुड़ी बातचीत में आने-जाने, ठहरने और वहाँ की ऐक्टिविटीज़ से जुड़ी अलग-अलग ज़रूरतें हो सकती हैं. रिट्रीवल सिस्टम पूरी बातचीत को सिर्फ़ एक टेक्स्ट स्ट्रिंग में बदलने के बजाय इन ज़रूरतों के बीच फ़र्क बनाए रख सकता है.

उदाहरण के लिए, हाइकिंग के जूतों से जुड़ी एक संभावित बातचीत देखें:

1. योसेमिटी की दो दिन की ट्रिप में मुझे कौन-कौन सी जगहें देखनी चाहिए?

2. क्या अगले हफ़्ते ठंड होगी?

3. [ब्रैंड का नाम डालें] की नई प्रोडक्ट लाइन्स कौन-सी हैं?

हालाँकि, यूज़र ने जूतों के ब्रैंड से जुड़े सवाल को योसेमिटी की ट्रिप से नहीं जोड़ा है, फिर भी हमारा ऐड्स सिस्टम इस बातचीत को दो क्वेरीज़ के ज़रिए समझ सकता है. जैसे, [हाइकिंग ट्रिप के लिए सही जूते] और [ट्रैवल के लिए सही [ब्रैंड] की नई प्रोडक्ट लाइन्स]. यह सिर्फ़ शुरुआती कोशिश हो सकती है. ऑर्केस्ट्रेटर इन क्वेरीज़ को बार-बार बेहतर बनाने के लिए डिज़ाइन किया गया है, जब तक कि उसे हमारे उपलब्ध ऐड्स में से यूज़र के लिए सबसे काम के ऐड्स न मिल जाएँ.

रिट्रीवल वह प्रोसेस है, जिसमें जानबूझकर कई तरह के संभावित ऐड्स का एक बड़ा ग्रुप तैयार किया जाता है. ये ऐड्स अलग-अलग रिट्रीवल तरीकों से मिल सकते हैं और बाद में ऐड दिखाने की एक जैसी शर्तों के तहत एक-दूसरे से मुकाबला कर सकते हैं. हम कई इंडेक्स बनाते हैं, जिन्हें सिस्टम और प्रोडक्ट की अलग-अलग ज़रूरतों के हिसाब से ऑप्टिमाइज़ किया जाता है (उदाहरण के लिए, प्रोडक्ट फ़ीड ऐड्स का इंडेक्स इस तरह डिज़ाइन किया गया है कि सबसे सही ऐड्स ढूँढते समय वह प्रोडक्ट के पॉज़िटिव और नेगेटिव रिव्यूज़ को भी ध्यान में रखे. लेकिन यह बात उन दूसरे ऐड्स पर लागू नहीं होती, जिनके साथ रिव्यूज़ नहीं जुड़े होते). हर इंडेक्स को यूज़र की ज़रूरत दिखाने वाली एम्बेडिंग्स के आधार पर अप्रॉक्सिमेट नियरेस्ट नेबर (ANN) सर्च के किसी वर्ज़न के लिए ऑप्टिमाइज़ किया जाता है. यह बड़े सिमैंटिक इंडेक्स में ऐड्स तेज़ी से ढूँढने का एक तरीका है. इसमें बिल्कुल "सही नतीजा" ढूँढने के बजाय उसके काफ़ी करीब पहुँचने की कोशिश की जाती है. इससे ज़्यादातर काम के ऐड्स भी मिल जाते हैं और सर्च बहुत तेज़ होती है.

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

जो ऐड्स शुरुआती शर्तें पूरी कर लेते हैं, वे स्कोरिंग स्टेज में पहुँचते हैं. यहाँ ऑर्केस्ट्रेटर अलग-अलग स्कोरिंग सिस्टम्स के टूल्स इस्तेमाल करता है. इनमें सिमैंटिक रेलेवेंस (क्या ऐड यूज़र के लक्ष्य से जुड़ा है?), प्रेडिक्टेड एंगेजमेंट (क्या यूज़र के ऐड देखने, उस पर क्लिक करने और एडवर्टाइज़र का मनचाहा नतीजा मिलने की संभावना है?) और पिछली परफ़ॉर्मेंस (अब तक यूज़र्स को दिखाए जाने पर ऐड की परफ़ॉर्मेंस कैसी रही है?) शामिल हैं. ऑर्केस्ट्रेटर ऑक्शन से पहले यह भी देखता है कि ऐड बातचीत के हिसाब से सही और सुरक्षित है या नहीं. इन जाँचों से संभावित ऐड्स की संख्या कम होकर ऑक्शन के लिए एक छोटा ग्रुप तैयार हो जाता है. लेकिन इस स्टेज पर भी यह तय नहीं होता कि आखिर में कौन-सा ऐड दिखाया जाएगा.

ऑर्केस्ट्रेटर बातचीत के कॉन्टेक्स्ट में तैयार किए गए ऐड्स की जाँच करता है और तय करता है कि कौन-से ऐड्स फ़ाइनल ऑक्शन में शामिल किए जा सकते हैं. ऑर्केस्ट्रेटर खुद यह तय नहीं करता कि कौन-सा ऐड दिखेगा और न ही उसकी कीमत तय करता है. यह सिर्फ़ बातचीत के हिसाब से सही लगने वाले ऐड्स को ऑक्शन टूल की जाँच के लिए चुनता है.

ऑक्शन में ऐड दिखाने से जुड़ा आखिरी प्रोसेस पूरा किया जाता है. इसमें ऑक्शन एडमिशन (रेलेवेंस और फ़ायदे की कम-से-कम तय शर्तें पूरी करना), पेसिंग (ऐड बजट को समय के साथ ज़्यादा समान रूप से खर्च करना), बिड और ऑक्शन फ़ीचर्स की कैलकुलेशन, क्वालिटी के हिसाब से रैंकिंग, प्राइसिंग और आखिरी ऐड का चुनाव शामिल हैं.

ऑक्शन के बाद भी दो वजहों से ऐड डिलीवर नहीं हो सकता. ये दोनों वजहें ChatGPT के बातचीत वाले फ़ॉर्मैट से जुड़ी हैं.

1. ऐड बातचीत के हिसाब से सही न लगे: इंटेग्रिटी मॉडल्स यह तय करते हैं कि किसी बातचीत में ऐड दिखाना सही है या नहीं. भले ही इन मॉडल्स ने बातचीत में ऐड दिखाना सुरक्षित माना हो और ऐड भी सभी पॉलिसी नियम पूरे करता हो, फिर भी कुछ बातचीत के कॉन्टेक्स्ट में वह ऐड सही नहीं लग सकता. ऐसे ऐड्स को ऑर्केस्ट्रेटर दिखाए जाने से रोक देता है.

2. ऐड की रिक्वेस्ट समय पर पूरी न हो: अगर ChatGPT मॉडल जवाब देने के लिए तैयार है, लेकिन ऐड अभी दिखाने के लिए तैयार नहीं है, तो ऐड की रिक्वेस्ट टाइम आउट हो जाती है और ऐड डिलीवर नहीं होता. इसलिए ऐड्स सिस्टम का एक लक्ष्य जितना हो सके, उतनी तेज़ी से काम करना है. ChatGPT मॉडल के जवाब देने में लगने वाला समय बदल सकता है और हम ऐड लोड होने का इंतज़ार करने के लिए चैट के जवाबों में देरी नहीं करते.

अगर ऊपर दी गई सभी जाँचों में ऐड सही पाया जाता है, तो हम उसे स्क्रीन पर दिखाने के लिए फ़्रंटएंड पर भेजते हैं. इसे हम सर्वर-साइड ऐड डिलीवरी मानते हैं. लेकिन इसके बाद भी हो सकता है कि यूज़र को ऐड न दिखे—सिस्टम को इसी तरह डिज़ाइन किया गया है.

ChatGPT जैसे बातचीत वाले प्रोडक्ट में सर्वर की ओर से ऐड क्रिएटिव डिलीवर होने का मतलब यह नहीं है कि ऐड यूज़र को ज़रूर दिखेगा. मौजूदा चैट टर्न में ऐड दिखाने के लिए उसका समय पर पहुँचना भी ज़रूरी है. ऐड क्रिएटिव में टाइटल, डिस्क्रिप्शन, वह लिंक जिस पर क्लिक करके यूज़र पहुँचेगा और कोई कॉल टू ऐक्शन शामिल होता है. इसके अलावा, ऐड्स सिस्टम मॉडल से तैयार किया गया एक छोटा, न्यूट्रल इंट्रोडक्शन भी भेजता है, जिसे प्रीएम्बल कहते हैं. यह बताता है कि ऐड बातचीत से कैसे जुड़ा है. प्रीएम्बल को ऐड क्रिएटिव से अलग रखने से एडवर्टाइज़र का मैसेज वैसा ही रहता है और ChatGPT का टोन न्यूट्रल बना रहता है.

ChatGPT के फ़्रंटएंड को प्रीएम्बल और ऐड क्रिएटिव एक साथ मिलते हैं. अगर यह पैकेज ChatGPT का जवाब पूरी तरह तैयार होने से पहले पहुँच जाता है, तो फ़्रंटएंड जवाब के नीचे ऐड दिखाता है, जिस पर साफ़ तौर पर स्पॉन्सर्ड का लेबल होता है. अगर पैकेज बहुत देर से पहुँचता है, तो उस चैट टर्न में ऐड नहीं दिखाया जाता. यही सर्वर-साइड ऐड डिलीवरी और यूज़र को ऐड दिखाए जाने, यानी ऐड इम्प्रेशन, के बीच का फ़र्क है.

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

क्या हुआ, इसकी डिटेल्ड जानकारी से हमें ऐड्स सिस्टम के हर हिस्से को अलग-अलग समझने और बेहतर बनाने में मदद मिलती है. लॉग्स प्रोसेसिंग सिस्टम छोटे-से-छोटे नतीजों को भी रिकॉर्ड करता है, जैसे कि:

• उस चैट टर्न में ऐड दिखाने की शर्तें पूरी नहीं हुईं.

• ऐड्स का सेशन शुरू हुआ, लेकिन ऐड्स ढूँढने के लिए कोई रिट्रीवल रिक्वेस्ट नहीं की गई.

• रिट्रीवल में कोई संभावित ऐड नहीं मिला.

• संभावित ऐड्स मिले, लेकिन वे हाइड्रेशन या एलिजिबिलिटी में पास नहीं हुए.

• ऐड डिलीवर हुआ और बाद में यूज़र ने उसके साथ इंटरैक्ट किया.

ये डिटेल्ड नतीजे हमें ऐड्स दिखाने वाले सिस्टम के हर हिस्से को अलग-अलग बेहतर बनाने में मदद करते हैं. ऐड दिखाने का सही मौका पहचानने की क्षमता बेहतर बनाने के लिए जिस तरह के डेटा और सबूतों की ज़रूरत होती है, वे रिट्रीवल, संभावित ऐड्स की क्वालिटी, ऑक्शन में भागीदारी या भरोसेमंद डिलीवरी बेहतर बनाने के लिए ज़रूरी डेटा और सबूतों से अलग होते हैं.

मॉडल के हिसाब से इवैल्यूएशन के पीछे की सोच यह है कि हमारे सबसे पावरफ़ुल और सबसे बेहतर रीज़निंग वाले मॉडल्स सिस्टम के नतीजों पर नज़र रखें और उनका आकलन करें. फिर उस फ़ीडबैक के आधार पर पोस्ट-ट्रेंड LLM को बेहतर परफ़ॉर्म करने के लिए ट्रेन किया जाए. उदाहरण के लिए, हम ऑर्केस्ट्रेशन या रिट्रीवल के लिए छोटे, ज़्यादा एफ़िशिएंट या कम रीज़निंग क्षमता वाले मॉडल्स इस्तेमाल कर सकते हैं, बशर्ते हमारा सबसे पावरफ़ुल मॉडल फ़ीडबैक इकट्ठा करे और इन छोटे मॉडल्स को इस तरह ट्रेन करे कि वे अपना काम जितना हो सके, उतने अच्छे तरीके से कर सकें.

हम लोगों के फ़ीडबैक को इकट्ठा करके उसके आधार पर कदम उठाते हैं. इसमें यूज़र्स के ऐड्स पर क्लिक करने या उन्हें छिपाने जैसे ऐक्शन्स, यूज़र सर्वे और ऐड्स मैनेजर के ज़रिए एडवर्टाइज़र्स से मिलने वाला सीधा फ़ीडबैक शामिल है. प्रोडक्ट बनाते समय हमारी टीम भी फ़ीडबैक लेने के लिए उपलब्ध रहती है. हम ChatGPT यूज़र्स और एडवर्टाइज़र्स, दोनों की ज़रूरतों को सीधे सुनते हैं. लोगों से मिलने वाला यह फ़ीडबैक हमारे लिए मॉडल की ओर से सिस्टम के नतीजों को देखकर दिए गए फ़ीडबैक से भी ज़्यादा अहम है. इसी की मदद से हम तेज़ी से बदलाव करते हुए प्रोडक्ट के लिए सही फ़ैसलों तक पहुँच पाए. मॉडल यूज़र की ज़रूरत समझ सकता है और अच्छी रीज़निंग करके काम का नतीजा दे सकता है, लेकिन क्या सही और अच्छा लगता है, यह लोग तय करते हैं.

एक साल पहले हमारे पास कोई ऐड्स सिस्टम नहीं था और सिर्फ़ कुछ लोग इस समस्या पर काम करने के बारे में सोच रहे थे. अब हमारे पास एक मज़बूत ऐड्स सिस्टम है, जिसका सालाना आधार पर कैलकुलेट किया गया रन रेट $1 अरब से ज़्यादा है. इसमें LLM-बेस्ड ऑर्केस्ट्रेटर ऐड्स का पूरा प्रोसेस चलाता है. Codex ने हमारी टीम की काम करने की क्षमता कई गुना बढ़ाने में अहम भूमिका निभाई. इसकी मदद से हमने शुरुआत से अपना सिस्टम तैयार किया और बहुत तेज़ी से इस्तेमाल के इस बड़े माइलस्टोन तक पहुँचे. शुरुआत से ही हमने अपनी टीम और डेवलपमेंट वर्कफ़्लोज़ को इस तरह सेट अप किया कि Codex की मदद से सिस्टम तेज़ी से बनाया जा सके और बड़े पैमाने पर बढ़ाया जा सके. हमने Codex के लिए ऐसे सेफ़्टी नियम और चेक्स भी बनाए, जिनसे कोड को भरोसेमंद और सुरक्षित तरीके से रिलीज़ किया जा सके. साथ ही, हमने Codex के लिए डेटा इंफ़्रास्ट्रक्चर प्लगइन्स सेट अप किए, ताकि इनसाइट्स इकट्ठा करने से लेकर सिस्टम में सुधार लागू करने तक का पूरा प्रोसेस काफ़ी तेज़ हो सके. इन सुधारों में नए प्रोडक्ट फ़ीचर्स, बेहतर क्वालिटी और सिस्टम की बेहतर परफ़ॉर्मेंस शामिल हैं.

हमारे सिस्टम की सीमाएँ (जो ऐडवर्टाइज़िंग से जुड़े हमारे सिद्धांतों⁠ पर आधारित हैं) और हमारा LLM-बेस्ड ऑर्केस्ट्रेटर मिलकर हमें ऐसे ऐड्स दिखाने में मदद करते हैं जो लोगों के काम आएँ. इसके लिए हर बातचीत को ऐड की रिक्वेस्ट नहीं माना जाता. आगे हम ऐसे नए और ज़्यादा डायनैमिक ऐड फ़ॉर्मैट्स के साथ एक्सपेरिमेंट करते रहेंगे, जो यूज़र्स और एडवर्टाइज़र्स, दोनों के लिए ज़्यादा फ़ायदेमंद हों (उदाहरण के लिए, ऐसे ऐड्स जिनके ज़रिए यूज़र्स सीधे बिज़नेस से बात कर सकें). हमारा ऐड्स सिस्टम OpenAI मॉडल्स और लगातार फ़ीडबैक लेकर खुद को बेहतर बनाने वाले आर्किटेक्चर पर बना है. इससे समय के साथ ऐड्स की रेलेवेंस और पर्सनलाइज़ेशन बेहतर करने की हमारी क्षमता तेज़ी से बढ़ेगी.