जेव्हा अनेक संस्था एजंटच्या वागणुकीबद्दल किंवा पायाभूत सुविधांबद्दल विचार करत नसत, तेव्हा Booking.com ने त्यांना त्यांच्या स्थानिक संभाषणात्मक शिफारस प्रणालीसह आधीच “सापडले” होते. या सुरुवातीच्या अनुभवामुळे कंपनीला एक पाऊल मागे घेण्याची आणि AI एजंट्सबद्दलच्या उन्मादी प्रचारात अडकणे टाळता आले. त्याऐवजी, मॉडेलच्या विकासासाठी मॉड्यूलर, शिस्तबद्ध, बहु-स्तरीय दृष्टीकोन घेते: जलद आणि स्वस्त अनुमानांसाठी लहान प्रवास-विशिष्ट मॉडेल; तर्क आणि समजून घेण्यासाठी मोठे मोठे भाषिक मॉडेल (LLMs); आणि जेव्हा अचूकता महत्त्वाची असते तेव्हा उद्योग-नियंत्रित, अंतर्गत व्युत्पन्न केलेले मूल्यांकन. या हायब्रीड स्ट्रॅटेजीबद्दल धन्यवाद – OpenAI सह निवडक सहकार्यासह – Booking.com ने मुख्य पुनर्प्राप्ती, वर्गीकरण आणि ग्राहक संवाद कार्यांमध्ये दुप्पट अचूकता पाहिली. प्रणव पाठक, Booking.com मधील AI उत्पादन विकासाचे संचालक, VentureBeat ला एका नवीन पॉडकास्टमध्ये म्हणाले: “तुम्ही ते अत्यंत खास आणि बेस्पोक बनवता का आणि नंतर शंभर एजंट्सची फौज आहे का? किंवा तुम्ही ते जेनेरिक ठेवता का आणि पाच एजंट आहेत जे सामान्यीकृत कामांमध्ये चांगले आहेत, परंतु नंतर तुम्हाला खूप समन्वय साधावा लागेल, जे मला वाटते की बाकीचे संतुलन राखण्याचा प्रयत्न आम्ही करतो? उद्योगाचे.” नवीन काय आहे ते तपासा पायलटच्या पलीकडे पॉडकास्ट येथे आहे आणि हायलाइट्ससाठी वाचत रहा.
“भयानक” न होता अंदाज बांधण्यापासून खोल सानुकूलनाकडे जा
Booking.com च्या ग्राहकाभिमुख प्लॅटफॉर्मसाठी शिफारस प्रणाली मध्यवर्ती आहेत; तथापि, पारंपारिक शिफारस करणारी साधने शिफारस करण्याबद्दल कमी आणि अंदाज लावण्याबद्दल अधिक होती, पाठक यांनी कबूल केले. म्हणून, सुरुवातीपासून, त्याने आणि त्याच्या टीमने जेनेरिक साधने टाळण्याचे वचन दिले: जसे तो म्हणतो, किंमत आणि शिफारस ग्राहकाच्या संदर्भावर आधारित असावी. प्रारंभिक AI टूल्स Booking.com ने हेतू आणि विषय शोधण्यासाठी वापरलेले एक लहान भाषेचे मॉडेल होते, ज्याचे वर्णन पाठक यांनी “BERT चा आकार आणि स्केल” असे केले. सेल्फ-सेवेद्वारे किंवा मानवी एजंटशी संप्रेषणाद्वारे निराकरण केले जाऊ शकते की नाही हे निर्धारित करण्यासाठी मॉडेलने त्यांच्या समस्येबद्दल ग्राहकांचे इनपुट अंतर्भूत केले. “आम्ही एक आर्किटेक्चरसह सुरुवात केली ‘तुम्हाला एखादे साधन चालवावे लागेल जर तुम्हाला हा हेतू आढळला असेल आणि अशा प्रकारे मी संरचनेचे विश्लेषण केले,'” पाटाक यांनी स्पष्ट केले. “ते पहिल्या काही अभिनेत्या आर्किटेक्चरसारखेच होते जे टूल कॉल का आणि परिभाषित करण्याच्या बाबतीत आले होते.” त्यानंतर त्याच्या टीमने LLM ऑर्केस्ट्रेटर समाविष्ट करण्यासाठी ते आर्किटेक्चर तयार केले आहे जे क्वेरीचे वर्गीकरण करते, रिट्रीव्हल ऑगमेंटेड जनरेशन (RAG) लाँच करते आणि API किंवा लहान, विशेष भाषा मॉडेल कॉल करते. “आम्ही ही प्रणाली खूप चांगल्या प्रकारे मोजण्यात सक्षम झालो आहोत कारण “ती आर्किटेक्चरमध्ये अगदी जवळ होती, आणि काही बदलांसह, आमच्याकडे आता एजंट्सचा संपूर्ण संच आहे.” परिणामी, Booking.com वर विषय शोधण्यात 2X वाढ दिसून येत आहे, ज्यामुळे मानवी एजंट्ससाठी बँडविड्थ 1.5 ते 1.7X पूर्वीच्या ध्वजांकित पेक्षा अधिक क्लिष्ट होते. प्लॅटफॉर्मवर नसलेल्या अनन्यपणे ओळखल्या जाणाऱ्या समस्यांसह ग्राहकांवर लक्ष केंद्रित करण्यासाठी, हे अधिक स्वयं-सेवेचे समर्थन करते – उदाहरणार्थ, जेव्हा फ्रंट डेस्क बंद असतो तेव्हा एक कुटुंब त्यांच्या हॉटेलच्या खोलीत जाऊ शकत नाही आम्ही पाहिलेल्या गोष्टींपैकी हे आहे की आम्ही ग्राहक सेवेत जितके चांगले आहोत तितके आमचे ग्राहक अधिक निष्ठावान आहेत,” पाटक यांनी नमूद केले. Booking.com च्या वेबसाइटवर 200 ते 250 शोध फिल्टर आहेत, त्यांनी नमूद केले. कोणत्याही माणसाला पाहण्यासाठी एक अवास्तव क्रमांक आहे. म्हणून, त्यांच्या टीमने एक विनामूल्य मजकूर बॉक्स सादर केला आहे जो वापरकर्ते वैयक्तिकृत फिल्टर प्राप्त करण्यासाठी टाइप करू शकतात. दुव्यावर क्लिक करण्याऐवजी स्वतःचे शब्द,” तो म्हणाला. “त्या बदल्यात, ते Booking.com ला ग्राहकांना प्रत्यक्षात काय हवे आहे ते निर्देशित करते. उदाहरणार्थ, जेव्हा फिल्टर कस्टमायझेशन पहिल्यांदा सादर केले गेले, तेव्हा ती सर्वात लोकप्रिय विनंती होती जी आता विचारातही घेतली जात नाही.” हे फिल्टर थेट आहे. “मला कल्पना नव्हती की मी माझ्या खोलीत हॉट टब शोधत नाही, प्रामाणिकपणे,” पाटाक यांनी नमूद केले. जेव्हा वैयक्तिकरणाचा विचार केला जातो, तेव्हा एक चांगली ओळ आहे; जरी ग्राहकांनी दीर्घकाळ वाचणे आणि वाचणे माझ्यासाठी महत्त्वाचे आहे. त्यांचे ठराविक बजेट, पसंतीचे हॉटेल स्टार रेटिंग किंवा त्यांना अपंग लोकांसाठी प्रवेश आवश्यक आहे की नाही – हे त्यांच्या अटींवर असणे आवश्यक आहे आणि Booking.com स्मरणशक्तीची काळजी घेते, आणि “मेमरी व्यवस्थापन करणे हे खरोखरच तांत्रिकदृष्ट्या तयार करण्यापेक्षा जास्त कठीण आहे,” असे सांगितले. आम्ही ग्राहकांच्या संमतीचा आदर करत नसलेली मेमरी ऑब्जेक्ट रिलीझ करत नाही आहोत याची आम्हाला खात्री करून घ्यायची आहे आणि ती अगदी नैसर्गिक वाटत नाही.”
इमारत आणि खरेदी दरम्यान संतुलन शोधा
एजंट परिपक्व होत असताना, Booking.com संपूर्ण उद्योगाला भेडसावणारा एक केंद्रीय प्रश्न हाताळत आहे: एजंट किती संकुचित आहेत? उच्च विशिष्ट एजंट्स किंवा काही सामान्यीकृत एजंट्सच्या संचाला वचनबद्ध करण्याऐवजी, कंपनीचे उद्दिष्ट उलट करता येण्याजोगे निर्णय घेणे आणि “एकमार्गी दरवाजे” टाळणे आहे जे तिच्या आर्किटेक्चरला दीर्घकालीन, महागड्या मार्गांमध्ये लॉक करते. पाठकची रणनीती अशी आहे: शक्य असेल तेथे सामान्यीकरण करणे, आवश्यक तेथे विशेषज्ञ करणे आणि लवचिकता सुनिश्चित करण्यात मदत करण्यासाठी एजंट डिझाइन लवचिक ठेवणे. पाठक आणि त्यांची टीम वापर प्रकरणांमध्ये “खूप स्वारस्य” आहे, अधिक सामान्य, पुन्हा वापरता येण्याजोगे ऑपरेटर किंवा अधिक कार्य-विशिष्ट ऑपरेटर कोठे तयार करायचे याचे मूल्यांकन करतात. ते शक्य तितके लहान मॉडेल, अचूकता आणि आउटपुट गुणवत्तेच्या उच्च पातळीसह, प्रत्येक वापरासाठी वापरण्याचा प्रयत्न करतात. सर्व सामान्यीकरण केले जाऊ शकते. विलंब हा आणखी एक महत्त्वाचा विचार आहे. जेव्हा वास्तववादी अचूकता आणि भ्रम टाळणे महत्त्वाचे असते, तेव्हा त्याची टीम खूप मोठे, हळू मॉडेल वापरेल; परंतु संशोधन आणि शिफारशींसह, वापरकर्त्याच्या अपेक्षांनी वेग सेट केला. (“कोणीही धीर धरत नाही,” पाठक यांनी नमूद केले.) “आम्ही, उदाहरणार्थ, केवळ विषय शोधण्यासाठी किंवा अस्तित्व काढण्यासाठी GPT-5 सारखे जड काहीतरी वापरणार नाही.” देखरेख आणि पुनरावलोकनांच्या बाबतीत Booking.com सारखाच लवचिक दृष्टीकोन घेते: जर निरीक्षण सामान्य हेतूचे असेल आणि कोणीतरी अधिक चांगले बांधकाम करत असेल आणि क्षैतिज क्षमता असेल तर ते ते खरेदी करतील. परंतु ब्रँड मार्गदर्शक तत्त्वे लागू करण्याची आवश्यकता असल्यास, ते त्यांचे स्वतःचे मूल्यांकन तयार करतील. सरतेशेवटी, Booking.com ने “अत्यंत सक्रिय”, सक्रिय आणि लवचिक असण्याची प्रवृत्ती ठेवली आहे. पाठक म्हणाले, “या टप्प्यावर, एआय सोबत सर्व काही चालू असताना, आम्ही एकेरी दरवाजातून जाण्यास थोडेसे प्रतिकूल आहोत. “आम्हाला आमचे बरेच निर्णय शक्य तितके मागे घेण्यासारखे हवे आहेत. आम्हाला अशा निर्णयाशी बांधून ठेवायचे नाही की आम्ही आतापासून दोन वर्षांनी पूर्ववत करू शकत नाही.”
Booking.com च्या AI प्रवासातून इतर बिल्डर काय शिकू शकतात
Booking.com चा AI प्रवास इतर संस्थांसाठी एक महत्त्वाचा ब्लूप्रिंट म्हणून काम करू शकतो. मागे वळून पाहताना, पाठक यांनी कबूल केले की त्यांनी “सुंदर जटिल” तंत्रज्ञान स्टॅकसह सुरुवात केली. ते आता चांगल्या स्थितीत आहेत, “परंतु कदाचित आम्ही आणखी सोप्या गोष्टीसह सुरुवात करू शकलो असतो आणि ग्राहक त्यावर कसा प्रतिसाद देतात ते पाहिले असते.” हे लक्षात घेता, त्याने हा मौल्यवान सल्ला दिला: जर तुम्ही LLM किंवा एजंट्ससह सुरुवात करत असाल, तर ऑफ-द-शेल्फ API उत्तम प्रकारे फिट होतील. “एपीआयमध्ये पुरेसे सानुकूलन आहे की आपण अधिक करू इच्छिता हे ठरविण्यापूर्वीच आपल्याला खूप प्रभाव मिळू शकेल.” दुसरीकडे, जर एखाद्या वापराच्या केसला कस्टमायझेशन आवश्यक असेल जे मानक API कॉलद्वारे उपलब्ध नसेल, तर ते अंतर्गत साधने वापरण्यासाठी एक केस आहे. तथापि, त्याने जोर दिला: क्लिष्ट गोष्टींपासून सुरुवात करू नका. “तुम्ही शोधू शकणारी सर्वात सोपी, सर्वात वेदनादायक समस्या आणि त्यावर सर्वात सोपा, सर्वात स्पष्ट उपाय” हाताळा. त्यांनी उत्पादन-मार्केट फिट ओळखण्याचा सल्ला दिला, नंतर इकोसिस्टमची तपासणी करा, परंतु केवळ लीगेसी इन्फ्रास्ट्रक्चर काढून टाकू नका कारण नवीन वापर प्रकरणात काहीतरी विशिष्ट आवश्यक आहे (जसे की फक्त OpenAI एंडपॉइंट वापरण्यासाठी संपूर्ण क्लाउड स्ट्रॅटेजी AWS वरून Azure वर हलवणे). शेवटी: “स्वतःला खूप लवकर बंद करू नका,” पाटाकने नमूद केले. “जोपर्यंत तुम्हाला पूर्ण विश्वास वाटत नाही तोपर्यंत एकतर्फी निर्णय घेऊ नका ज्याचा तुम्हाला पाठपुरावा करायचा आहे.”
