मान लें कि आपके पास एम्बेड करने का मॉडल है. एक उपयोगकर्ता को देखते हुए, आप यह कैसे तय करेंगे/करेंगी कि कौनसे आइटम के सुझाव दिए जाएं?
सेवा के समय, क्वेरी पूछे जाने पर आप इनमें से कोई एक काम शुरू करते हैं:
- किसी मैट्रिक्स फ़ैक्टर मॉडल के लिए, क्वेरी (या उपयोगकर्ता) को स्टैटिक तौर पर जोड़ा जाता है. सिस्टम, उपयोगकर्ता को जोड़े गए मैट्रिक्स से आसानी से खोज सकता है.
- DNN मॉडल के लिए, सिस्टम सुविधा वेक्टर \(x\)पर नेटवर्क चलाकर \(\psi(x)\)विज्ञापन दिखाते समय क्वेरी को एम्बेड करता है.
क्वेरी एम्बेड करने के बाद \(q\), आइटम एम्बेड करने की सुविधा खोजें \(V_j\) जो एम्बेड करने की जगह में \(q\) से मेल खाता है. यह समस्या आस-पास के लोगों की समस्या है. उदाहरण के लिए, आप मिलते-जुलते स्कोर के हिसाब से टॉप k आइटम लौटा सकते हैं \(s(q, V_j)\).
मिलते-जुलते आइटम के सुझावों के लिए, आप यही तरीका इस्तेमाल कर सकते हैं. उदाहरण के लिए, जब उपयोगकर्ता कोई YouTube वीडियो देख रहा होता है, तो सिस्टम सबसे पहले उस आइटम को एम्बेड करने की सुविधा को खोज सकता है. इसके बाद, वह एम्बेड किए गए कॉन्टेंट के आस-पास मौजूद उन दूसरे आइटम को\(V_j\) देख सकता है जो एम्बेड करने की जगह से बाहर होते हैं.
बड़े पैमाने पर डेटा वापस पाना
एम्बेड करने की जगह में आस-पास के पड़ोसियों की गिनती करने के लिए, सिस्टम हर संभावित उम्मीदवार को पूरी तरह से स्कोर दे सकता है. बहुत बड़े कॉर्पस के लिए महंगा स्कोरिंग महंगा हो सकता है, लेकिन इसे ज़्यादा कारगर बनाने के लिए, आप इनमें से किसी एक रणनीति का इस्तेमाल कर सकते हैं:
- अगर क्वेरी एम्बेड करना स्थायी तौर पर जाना जाता है, तो सिस्टम हर एक क्वेरी के लिए ऑफ़लाइन स्कोरिंग कर सकता है, पहले से तैयार, और उनकी सूची बना सकता है. यह, आइटम के सुझाव के लिए एक सामान्य तरीका है.
- आस-पास के नज़दीकी पड़ोसियों का इस्तेमाल करें.