AlloyDB की नई वेक्टर सर्च सुविधाओं के साथ, क्वालिटी कंट्रोल वाला आरएजी!

1. खास जानकारी

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

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

अब हम तीन चीज़ों के बारे में बुनियादी जानकारी रखते हैं:

  1. आपके एजेंट के लिए, कॉन्टेक्स्ट के हिसाब से खोज का क्या मतलब है और वेक्टर सर्च का इस्तेमाल करके, इसे कैसे पूरा किया जा सकता है.
  2. हमने आपके डेटा के दायरे में वेक्टर सर्च को शामिल करने के लिए भी काम किया है. यह आपके डेटाबेस में ही मौजूद है. अगर आपको पहले से इसकी जानकारी नहीं है, तो बता दें कि Google Cloud के सभी डेटाबेस में यह सुविधा काम करती है!
  3. हमने दुनिया भर के अन्य लोगों की तुलना में एक कदम आगे बढ़कर, आपको यह बताने की कोशिश की है कि ScaNN इंडेक्स की मदद से, AlloyDB वेक्टर सर्च की सुविधा का इस्तेमाल करके, बेहतर परफ़ॉर्मेंस और क्वालिटी के साथ, वेक्टर सर्च आरएजी की सुविधा को कैसे हासिल किया जा सकता है.

अगर आपने आरएजी के बुनियादी, इंटरमीडिएट, और थोड़े बेहतर एक्सपेरिमेंट नहीं देखे हैं, तो हमारा सुझाव है कि आप इन तीनों को यहां, यहां, और यहां दिए गए क्रम में पढ़ें.

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

नीचे दी गई इमेज में, इस ऐप्लिकेशन में होने वाली प्रोसेस के बारे में पूरी जानकारी दी गई है.~ 1c871099f1fde825.png

मकसद

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

आपको क्या बनाना है

इस लैब में, आपको ये काम करने होंगे:

  1. AlloyDB इंस्टेंस बनाना और 'पेटेंट का सार्वजनिक डेटासेट' लोड करना
  2. मेटाडेटा इंडेक्स और ScaNN इंडेक्स बनाना
  3. ScaNN के इनलाइन फ़िल्टर करने के तरीके का इस्तेमाल करके, AlloyDB में बेहतर वेक्टर सर्च लागू करना
  4. रिकॉल की सुविधा का आकलन करने की सुविधा लागू करना
  5. क्वेरी के जवाब का आकलन करना

ज़रूरी शर्तें

  • कोई ब्राउज़र, जैसे कि Chrome या Firefox
  • बिलिंग की सुविधा वाला Google Cloud प्रोजेक्ट.

2. शुरू करने से पहले

प्रोजेक्ट बनाना

  1. Google Cloud Console में, प्रोजेक्ट चुनने वाले पेज पर, Google Cloud प्रोजेक्ट चुनें या बनाएं.
  2. पक्का करें कि आपके Cloud प्रोजेक्ट के लिए बिलिंग की सुविधा चालू हो. किसी प्रोजेक्ट के लिए बिलिंग की सुविधा चालू है या नहीं, यह देखने का तरीका जानें .
  3. इसके लिए, आपको Cloud Shell का इस्तेमाल करना होगा. यह Google Cloud में चलने वाला कमांड-लाइन एनवायरमेंट है. Google Cloud कंसोल में सबसे ऊपर, 'Cloud Shell चालू करें' पर क्लिक करें.

Cloud Shell चालू करने के लिए बटन की इमेज

  1. Cloud Shell से कनेक्ट होने के बाद, यह जांच करें कि आपकी पुष्टि पहले ही हो चुकी है या नहीं. साथ ही, यह भी देखें कि प्रोजेक्ट आपके प्रोजेक्ट आईडी पर सेट है या नहीं. इसके लिए, यह कमांड इस्तेमाल करें:
gcloud auth list
  1. Cloud Shell में यह कमांड चलाकर पुष्टि करें कि gcloud कमांड को आपके प्रोजेक्ट के बारे में पता है.
gcloud config list project
  1. अगर आपका प्रोजेक्ट सेट नहीं है, तो इसे सेट करने के लिए इस निर्देश का इस्तेमाल करें:
gcloud config set project <YOUR_PROJECT_ID>
  1. ज़रूरी एपीआई चालू करें. Cloud Shell टर्मिनल में gcloud कमांड का इस्तेमाल किया जा सकता है:
gcloud services enable alloydb.googleapis.com compute.googleapis.com cloudresourcemanager.googleapis.com servicenetworking.googleapis.com run.googleapis.com cloudbuild.googleapis.com cloudfunctions.googleapis.com aiplatform.googleapis.com

gcloud कमांड के बजाय, कंसोल में जाकर हर प्रॉडक्ट को खोजें या इस लिंक का इस्तेमाल करें.

gcloud के निर्देशों और इस्तेमाल के बारे में जानने के लिए, दस्तावेज़ देखें.

3. डेटाबेस सेटअप करना

इस लैब में, हम AlloyDB का इस्तेमाल, पेटेंट डेटा के डेटाबेस के तौर पर करेंगे. यह डेटाबेस और लॉग जैसे सभी संसाधनों को सेव करने के लिए, क्लस्टर का इस्तेमाल करता है. हर क्लस्टर में एक प्राइमरी इंस्टेंस होता है, जो डेटा का ऐक्सेस पॉइंट उपलब्ध कराता है. टेबल में असल डेटा सेव होगा.

आइए, एक ऐसा AlloyDB क्लस्टर, इंस्टेंस, और टेबल बनाएं जहां पेटेंट डेटासेट लोड किया जाएगा.

क्लस्टर और इंस्टेंस बनाना

  1. Cloud Console में, AlloyDB पेज पर जाएं. Cloud Console में ज़्यादातर पेजों को ढूंढने का आसान तरीका है, उन्हें कंसोल के खोज बार का इस्तेमाल करके खोजना.
  2. उस पेज से, क्लस्टर बनाएं चुनें:

f76ff480c8c889aa.png

  1. आपको नीचे दी गई स्क्रीन जैसी स्क्रीन दिखेगी. यहां दी गई वैल्यू का इस्तेमाल करके, क्लस्टर और इंस्टेंस बनाएं. अगर आपको रिपॉज़िटरी से ऐप्लिकेशन कोड को क्लोन करना है, तो पक्का करें कि वैल्यू मैच हों:
  • क्लस्टर आईडी: "vector-cluster"
  • password: "alloydb"
  • PostgreSQL 15 / नया वर्शन इस्तेमाल करने का सुझाव दिया जाता है
  • इलाका: "us-central1"
  • नेटवर्किंग: "default"

538dba58908162fb.png

  1. डिफ़ॉल्ट नेटवर्क चुनने पर, आपको नीचे दी गई स्क्रीन जैसी स्क्रीन दिखेगी.

कनेक्शन सेट अप करें को चुनें.

7939bbb6802a91bf.png

  1. इसके बाद, "अपने-आप असाइन की गई आईपी रेंज का इस्तेमाल करें" को चुनें और 'जारी रखें' पर क्लिक करें. जानकारी की समीक्षा करने के बाद, 'कनेक्शन बनाएं' चुनें. 768ff5210e79676f.png
  2. नेटवर्क सेट अप हो जाने के बाद, क्लस्टर बनाना जारी रखा जा सकता है. क्लस्टर सेट अप करने के लिए, क्लस्टर बनाएं पर क्लिक करें. इसके बाद, नीचे दिया गया तरीका अपनाएं:

e06623e55195e16e.png

इंस्टेंस आईडी को बदलना न भूलें. यह आईडी, क्लस्टर / इंस्टेंस के कॉन्फ़िगरेशन के समय मिलता है. इसे इससे बदलें

vector-instance. अगर इसे बदला नहीं जा सकता, तो आने वाले समय में सभी रेफ़रंस में अपने इंस्टेंस आईडी का इस्तेमाल करें.

ध्यान दें कि क्लस्टर बनाने में करीब 10 मिनट लगेंगे. क्लस्टर बनाने के बाद, आपको एक स्क्रीन दिखेगी. इसमें आपके बनाए गए क्लस्टर की खास जानकारी दिखेगी.

4. डेटा डालना

अब स्टोर के डेटा वाली टेबल जोड़ने का समय आ गया है. AlloyDB पर जाएं. इसके बाद, प्राइमरी क्लस्टर और फिर AlloyDB Studio चुनें:

847e35f1bf8a8bd8.png

आपको इंस्टेंस बनने का इंतज़ार करना पड़ सकता है. इसके बाद, क्लस्टर बनाते समय बनाए गए क्रेडेंशियल का इस्तेमाल करके, AlloyDB में साइन इन करें. PostgreSQL की पुष्टि करने के लिए, यहां दिए गए डेटा का इस्तेमाल करें:

  • उपयोगकर्ता नाम : "postgres"
  • डेटाबेस : "postgres"
  • पासवर्ड : "alloydb"

AlloyDB Studio में पुष्टि करने के बाद, Editor में SQL निर्देश डाले जाते हैं. आखिरी विंडो की दाईं ओर मौजूद प्लस का इस्तेमाल करके, Editor की कई विंडो जोड़ी जा सकती हैं.

91a86d9469d499c4.png

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

एक्सटेंशन चालू करना

इस ऐप्लिकेशन को बनाने के लिए, हम एक्सटेंशन pgvector और google_ml_integration का इस्तेमाल करेंगे. pgvector एक्सटेंशन की मदद से, वेक्टर एम्बेडमेंट को सेव और खोजा जा सकता है. google_ml_integration एक्सटेंशन, ऐसे फ़ंक्शन उपलब्ध कराता है जिनका इस्तेमाल करके, Vertex AI के अनुमान वाले एंडपॉइंट को ऐक्सेस किया जा सकता है. इससे, एसक्यूएल में अनुमान पाने में मदद मिलती है. इन डीडीएल को चलाकर, इन एक्सटेंशन को चालू करें:

CREATE EXTENSION IF NOT EXISTS google_ml_integration CASCADE;
CREATE EXTENSION IF NOT EXISTS vector;

अगर आपको अपने डेटाबेस में चालू किए गए एक्सटेंशन की जांच करनी है, तो यह एसक्यूएल कमांड चलाएं:

select extname, extversion from pg_extension;

टेबल बनाना

AlloyDB Studio में, नीचे दिए गए डीडीएल स्टेटमेंट का इस्तेमाल करके टेबल बनाई जा सकती है:

CREATE TABLE patents_data ( id VARCHAR(25), type VARCHAR(25), number VARCHAR(20), country VARCHAR(2), date VARCHAR(20), abstract VARCHAR(300000), title VARCHAR(100000), kind VARCHAR(5), num_claims BIGINT, filename VARCHAR(100), withdrawn BIGINT, abstract_embeddings vector(768)) ;

abstract_embeddings कॉलम में, टेक्स्ट की वेक्टर वैल्यू को स्टोर किया जा सकेगा.

अनुमति दें

"एम्बेड करना" फ़ंक्शन पर 'कार्रवाई करें' की अनुमति देने के लिए, नीचे दिया गया स्टेटमेंट चलाएं:

GRANT EXECUTE ON FUNCTION embedding TO postgres;

AlloyDB सेवा खाते को Vertex AI उपयोगकर्ता की भूमिका असाइन करना

Google Cloud IAM Console में जाकर, AlloyDB सेवा खाते (यह इस तरह दिखता है: service-<<PROJECT_NUMBER>>@gcp-sa-alloydb.iam.gserviceaccount.com) को "Vertex AI उपयोगकर्ता" की भूमिका का ऐक्सेस दें. PROJECT_NUMBER में आपका प्रोजेक्ट नंबर होगा.

इसके अलावा, Cloud Shell टर्मिनल से यह कमांड भी चलाया जा सकता है:

PROJECT_ID=$(gcloud config get-value project)


gcloud projects add-iam-policy-binding $PROJECT_ID \
  --member="serviceAccount:service-$(gcloud projects describe $PROJECT_ID --format="value(projectNumber)")@gcp-sa-alloydb.iam.gserviceaccount.com" \
--role="roles/aiplatform.user"

डेटाबेस में पेटेंट का डेटा लोड करना

BigQuery पर मौजूद Google के सार्वजनिक डेटासेट का इस्तेमाल, हमारे डेटासेट के तौर पर किया जाएगा. हम अपनी क्वेरी चलाने के लिए, AlloyDB Studio का इस्तेमाल करेंगे. डेटा को इस insert_scripts.sql फ़ाइल में सोर्स किया जाता है. साथ ही, हम इसे पेटेंट डेटा लोड करने के लिए चलाएंगे.

  1. Google Cloud Console में, AlloyDB पेज खोलें.
  2. अपना नया क्लस्टर चुनें और इंस्टेंस पर क्लिक करें.
  3. AlloyDB के नेविगेशन मेन्यू में, AlloyDB Studio पर क्लिक करें. अपने क्रेडेंशियल से साइन इन करें.
  4. दाईं ओर मौजूद, नया टैब आइकॉन पर क्लिक करके नया टैब खोलें.
  5. ऊपर दी गई insert_scripts.sql स्क्रिप्ट से, insert क्वेरी स्टेटमेंट को एडिटर में कॉपी करें. इस इस्तेमाल के उदाहरण का तुरंत डेमो देखने के लिए, 10 से 50 इंसर्ट स्टेटमेंट कॉपी किए जा सकते हैं.
  6. चलाएं पर क्लिक करें. आपकी क्वेरी के नतीजे, नतीजे टेबल में दिखते हैं.

ध्यान दें: आपको लग सकता है कि इंसर्ट स्क्रिप्ट में बहुत सारा डेटा है. ऐसा इसलिए है, क्योंकि हमने इंसर्ट स्क्रिप्ट में एम्बेड शामिल किए हैं. अगर आपको GitHub में फ़ाइल लोड करने में समस्या आ रही है, तो "रॉ फ़ाइल देखें" पर क्लिक करें. ऐसा इसलिए किया जाता है, ताकि अगर Google Cloud के लिए ट्रायल क्रेडिट वाले बिलिंग खाते का इस्तेमाल किया जा रहा है, तो आपको आने वाले चरणों में कुछ से ज़्यादा (जैसे, ज़्यादा से ज़्यादा 20-25) एम्बेड जनरेट करने में परेशानी न हो.

5. पेटेंट डेटा के लिए एम्बेडिंग बनाएं

सबसे पहले, एम्बेड करने की सुविधा की जांच करने के लिए, यहां दी गई सैंपल क्वेरी चलाएं:

SELECT embedding('text-embedding-005', 'AlloyDB is a managed, cloud-hosted SQL database service.');

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

25a1d7ef0e49e91e.png

abstract_embeddings वेक्टर फ़ील्ड को अपडेट करना

अगर आपने इंसर्ट स्क्रिप्ट के हिस्से के तौर पर abstract_embeddings डेटा नहीं डाला है, तो टेबल में मौजूद पेटेंट के एब्सट्रैक्ट को उनसे जुड़े एम्बेड किए गए टेक्स्ट से अपडेट करने के लिए, नीचे दिया गया डीएमएल चलाएं:

UPDATE patents_data set abstract_embeddings = embedding( 'text-embedding-005', abstract);

अगर Google Cloud के लिए, मुफ़्त में आज़माने के लिए मिले क्रेडिट वाले बिलिंग खाते का इस्तेमाल किया जा रहा है, तो आपको कुछ से ज़्यादा एम्बेड (जैसे, ज़्यादा से ज़्यादा 20-25) जनरेट करने में समस्या आ सकती है. इसलिए, मैंने पहले से ही डालने की स्क्रिप्ट में एम्बेड शामिल कर लिए हैं. अगर आपने "डेटाबेस में पेटेंट डेटा लोड करें" चरण पूरा कर लिया है, तो यह आपकी टेबल में लोड हो जाना चाहिए.

6. AlloyDB की नई सुविधाओं की मदद से बेहतर आरएजी (रिस्क एलिमेंट की पहचान) करना

अब टेबल, डेटा, और एम्बेड किए गए डेटा को तैयार कर लिया गया है. अब उपयोगकर्ता के खोजे गए टेक्स्ट के लिए, रीयल टाइम वेक्टर सर्च की सुविधा का इस्तेमाल करके देखें. इसकी जांच करने के लिए, नीचे दी गई क्वेरी चलाएं:

SELECT id || ' - ' || title as title FROM patents_data ORDER BY abstract_embeddings <=> embedding('text-embedding-005', 'Sentiment Analysis')::vector LIMIT 10;

इस क्वेरी में,

  1. उपयोगकर्ता ने जो टेक्स्ट खोजा है वह यह है: "भावनाओं का विश्लेषण".
  2. हम इसे embedding() तरीके में एम्बेड में बदल रहे हैं. इसके लिए, हमने text-embedding-005 मॉडल का इस्तेमाल किया है.
  3. "<=>", कोसाइन सिमिलैरिटी डिस्टेंस का इस्तेमाल दिखाता है.
  4. हम एम्बेड करने के तरीके के नतीजे को वेक्टर टाइप में बदल रहे हैं, ताकि इसे डेटाबेस में सेव किए गए वेक्टर के साथ काम किया जा सके.
  5. LIMIT 10 से पता चलता है कि हम खोज के लिए इस्तेमाल हुए टेक्स्ट से सबसे ज़्यादा मिलते-जुलते 10 मैच चुन रहे हैं.

AlloyDB, वेक्टर सर्च आरएजी को अगले लेवल पर ले जाता है:

इसमें कई नई सुविधाएं जोड़ी गई हैं. डेवलपर के लिए उपलब्ध दो सुविधाएं ये हैं:

  1. इनलाइन फ़िल्टरिंग
  2. रीकॉल एवल्यूएटर

इनलाइन फ़िल्टरिंग

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

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

  1. pgvector एक्सटेंशन इंस्टॉल या अपडेट करना
CREATE EXTENSION IF NOT EXISTS vector WITH VERSION '0.8.0.google-3';

अगर pgvector एक्सटेंशन पहले से इंस्टॉल है, तो रीकॉल एवल्यूएटर की सुविधाएं पाने के लिए, वेक्टर एक्सटेंशन को 0.8.0.google-3 या इसके बाद के वर्शन पर अपग्रेड करें.

ALTER EXTENSION vector UPDATE TO '0.8.0.google-3';

यह चरण सिर्फ़ तब पूरा करना होगा, जब आपका वेक्टर एक्सटेंशन <0.8.0.google-3> हो.

अहम जानकारी: अगर आपकी पंक्ति की संख्या 100 से कम है, तो आपको ScaNN इंडेक्स बनाने की ज़रूरत नहीं है. ऐसा इसलिए, क्योंकि यह कम लाइनों पर लागू नहीं होता. ऐसे में, कृपया नीचे दिया गया तरीका न अपनाएं.

  1. ScaNN इंडेक्स बनाने के लिए, alloydb_scann एक्सटेंशन इंस्टॉल करें.
CREATE EXTENSION IF NOT EXISTS alloydb_scann;
  1. सबसे पहले, इंडेक्स और इनलाइन फ़िल्टर चालू किए बिना वेक्टर सर्च क्वेरी चलाएं:
SELECT id || ' - ' || title as title FROM patents_data 
WHERE num_claims >= 15 
ORDER BY abstract_embeddings <=> embedding('text-embedding-005', 'Sentiment Analysis')::vector LIMIT 10;

नतीजा कुछ ऐसा दिखना चाहिए:

6989de0fc3f0f753.png

  1. इस पर 'एक्सप्लेन ऐनलिज' चलाएं: (बिना इंडेक्स या इनलाइन फ़िल्टरिंग के)

908dcf87c7f00ed4.png

कार्रवाई पूरी होने में 2.4 मिलीसेकंड लगते हैं

  1. चलिए, num_claims फ़ील्ड पर रेगुलर इंडेक्स बनाते हैं, ताकि हम इस फ़ील्ड के हिसाब से फ़िल्टर कर सकें:
CREATE INDEX idx_patents_data_num_claims ON patents_data (num_claims);
  1. चलिए, अपने 'पेटेंट सर्च' ऐप्लिकेशन के लिए ScaNN इंडेक्स बनाते हैं. अपने AlloyDB Studio से, नीचे दिया गया कोड चलाएं:
CREATE INDEX patent_index ON patents_data 
USING scann (abstract_embeddings cosine)
WITH (num_leaves=32);

अहम जानकारी: (num_leaves=32), 1,000 से ज़्यादा लाइनों वाले हमारे पूरे डेटासेट पर लागू होता है. अगर आपकी पंक्ति की संख्या 100 से कम है, तो आपको इंडेक्स बनाने की ज़रूरत नहीं है, क्योंकि यह कम लाइनों पर लागू नहीं होगा.

  1. ScaNN Index पर इनलाइन फ़िल्टर करने की सुविधा चालू करने के लिए:
SET scann.enable_inline_filtering = on
  1. अब, फ़िल्टर और वेक्टर सर्च के साथ एक ही क्वेरी चलाएं:
SELECT id || ' - ' || title as title FROM patents_data 
WHERE num_claims >= 15 
ORDER BY abstract_embeddings <=> embedding('text-embedding-005', 'Sentiment Analysis')::vector LIMIT 10;

aa54cba2b2ada2cb.png

जैसा कि आप देख सकते हैं, एक ही वेक्टर सर्च के लिए, लागू होने में लगने वाला समय काफ़ी कम हो गया है. वेक्टर सर्च पर इनलाइन फ़िल्टरिंग के साथ ScaNN इंडेक्स की मदद से, ऐसा किया जा सकता है!!!

इसके बाद, ScaNN की सुविधा वाली वेक्टर सर्च के लिए रीकॉल का आकलन करते हैं.

रीकॉल एवल्यूएटर

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

खोज के नतीजों को फिर से दिखाने का लॉजिक क्या है?

वेक्टर सर्च के संदर्भ में, रीकॉल से उन वेक्टर का प्रतिशत पता चलता है जो इंडेक्स में सबसे नज़दीक के तौर पर दिखते हैं. उदाहरण के लिए, अगर सबसे नज़दीकी 20 पॉइंट की क्वेरी से, असल में सबसे नज़दीक के 19 पॉइंट मिलते हैं, तो रीकॉल 19/20x100 = 95% होगा. रीकॉल, खोज क्वालिटी के लिए इस्तेमाल की जाने वाली मेट्रिक है. इसे, खोज के नतीजों में क्वेरी वेक्टर से सबसे ज़्यादा मिलते-जुलते नतीजों के प्रतिशत के तौर पर परिभाषित किया जाता है.

evaluate_query_recall फ़ंक्शन का इस्तेमाल करके, किसी कॉन्फ़िगरेशन के लिए वेक्टर इंडेक्स पर वेक्टर क्वेरी का रीकॉल पता लगाया जा सकता है. इस फ़ंक्शन की मदद से, वेक्टर क्वेरी रीकॉल के अपने मनमुताबिक नतीजे पाने के लिए, पैरामीटर में बदलाव किया जा सकता है.

अहम जानकारी:

अगर आपको यहां दिए गए चरणों में, HNSW इंडेक्स पर अनुमति अस्वीकार होने की गड़बड़ी का सामना करना पड़ रहा है, तो फ़िलहाल रिकॉल की जांच वाले इस पूरे सेक्शन को छोड़ दें. ऐसा हो सकता है कि इस समय ऐक्सेस से जुड़ी पाबंदियों की वजह से ऐसा हो रहा हो. ऐसा इसलिए, क्योंकि इस कोडलैब को रिलीज़ किए जाने के समय ही यह सुविधा रिलीज़ हुई थी.

  1. ScaNN इंडेक्स और HNSW इंडेक्स पर, इंडेक्स स्कैन करने की सुविधा चालू करने का फ़्लैग सेट करें:
SET scann.enable_indexscan = on
SET hnsw.enable_index_scan = on
  1. AlloyDB Studio में यह क्वेरी चलाएं:
SELECT
  *
FROM
  evaluate_query_recall($$
  SELECT
    id || ' - ' || title AS title,
    abstract
  FROM
    patents_data
    where num_claims >= 15
  ORDER BY
    abstract_embeddings <=> embedding('text-embedding-005',
      'sentiment analysis')::vector
  LIMIT 25 $$,
    '{"scann.num_leaves_to_search":1, "scann.pre_reordering_num_neighbors":10}',
    ARRAY['scann']);

evaluate_query_recall फ़ंक्शन, क्वेरी को पैरामीटर के तौर पर लेता है और उसका रीकॉल दिखाता है. फ़ंक्शन के इनपुट के तौर पर, मैं उसी क्वेरी का इस्तेमाल कर रहा/रही हूं जिसका इस्तेमाल मैंने परफ़ॉर्मेंस की जांच करने के लिए किया था. मैंने इंडेक्स करने के तरीके के तौर पर SCaNN जोड़ा है. पैरामीटर के ज़्यादा विकल्पों के लिए, दस्तावेज़ देखें.

वेक्टर सर्च की इस क्वेरी के लिए रीकॉल:

c98f38fbe6a0b6c5.png

मुझे पता चला है कि रीकॉल 70% है. अब मैं इस जानकारी का इस्तेमाल, इंडेक्स पैरामीटर, तरीकों, और क्वेरी पैरामीटर को बदलने के लिए कर सकता हूं. साथ ही, इस वेक्टर सर्च के लिए रीकॉल को बेहतर बना सकता हूं!

7. बदली गई क्वेरी और इंडेक्स पैरामीटर की मदद से इसकी जांच करें

अब, मिले रीकॉल के आधार पर क्वेरी पैरामीटर में बदलाव करके, क्वेरी की जांच करते हैं.

  1. मैंने नतीजे के सेट में लाइनों की संख्या को 25 से बदलकर 7 कर दिया है. इससे मुझे बेहतर रीकॉल, यानी 86% दिख रहा है.

c12f7b92b8481ceb.png

इसका मतलब है कि रीयल-टाइम में, मैं अपने उपयोगकर्ताओं को दिखने वाले मैच की संख्या में बदलाव कर सकता हूं. इससे, उपयोगकर्ताओं के खोज के संदर्भ के हिसाब से मैच को ज़्यादा काम का बनाया जा सकता है.

  1. आइए, इंडेक्स पैरामीटर में बदलाव करके फिर से कोशिश करते हैं:

इस टेस्ट के लिए, मैं मिलती-जुलती वैल्यू के बीच की दूरी का पता लगाने वाले "कोसाइन" फ़ंक्शन के बजाय, "L2 दूरी" फ़ंक्शन का इस्तेमाल करने जा रहा हूं. हम क्वेरी की सीमा को 10 पर भी सेट करेंगे, ताकि यह पता चल सके कि खोज के नतीजों के सेट की संख्या बढ़ने के बावजूद, खोज के नतीजों की क्वालिटी में सुधार हुआ है या नहीं.

[पहले] कोसाइन मिलती-जुलती दूरी फ़ंक्शन का इस्तेमाल करने वाली क्वेरी:

SELECT
  *
FROM
  evaluate_query_recall($$
  SELECT
    id || ' - ' || title AS title,
    abstract
  FROM
    patents_data
    where num_claims >= 15
  ORDER BY
    abstract_embeddings <=> embedding('text-embedding-005',
      'sentiment analysis')::vector
  LIMIT 10 $$,
    '{"scann.num_leaves_to_search":1, "scann.pre_reordering_num_neighbors":10}',
    ARRAY['scann']);

अहम जानकारी: "हमें कैसे पता चलेगा कि यह क्वेरी, कोसाइन मिलते-जुलते शब्दों का इस्तेमाल करती है?" कोसाइन दूरी दिखाने के लिए, "<=>" का इस्तेमाल करके, दूरी फ़ंक्शन की पहचान की जा सकती है.

वेक्टर सर्च के लिए, दूरी के फ़ंक्शन का Docs लिंक.

ऊपर दी गई क्वेरी का नतीजा यह है:

c62ef8922d6bf0b2.png

जैसा कि आप देख सकते हैं, इंडेक्स लॉजिक में कोई बदलाव किए बिना, रीकॉल 70% है. इनलाइन फ़िल्टर करने वाले सेक्शन, "patent_index " के छठे चरण में, हमने जो ScaNN इंडेक्स बनाया था उसे याद है? ऊपर दी गई क्वेरी चलाने के दौरान, वही इंडेक्स अब भी काम कर रहा है.

अब दूरी के फ़ंक्शन की अलग क्वेरी के साथ एक इंडेक्स बनाएं: L2 दूरी: <->

drop index patent_index;

CREATE INDEX patent_index_L2 ON patents_data 
USING scann (abstract_embeddings L2)
WITH (num_leaves=32);

ड्रॉप इंडेक्स स्टेटमेंट सिर्फ़ यह पक्का करने के लिए है कि टेबल में कोई ग़ैर-ज़रूरी इंडेक्स न हो.

अब, वेक्टर सर्च की सुविधा के लिए, दूरी के फ़ंक्शन में बदलाव करने के बाद, रीकॉल का आकलन करने के लिए, नीचे दी गई क्वेरी को चलाया जा सकता है.

[AFTER] क्वेरी, जो कोसाइन मिलती-जुलती दूरी फ़ंक्शन का इस्तेमाल करती है:

SELECT
  *
FROM
  evaluate_query_recall($$
  SELECT
    id || ' - ' || title AS title,
    abstract
  FROM
    patents_data
    where num_claims >= 15
  ORDER BY
    abstract_embeddings <-> embedding('text-embedding-005',
      'sentiment analysis')::vector
  LIMIT 10 $$,
    '{"scann.num_leaves_to_search":1, "scann.pre_reordering_num_neighbors":10}',
    ARRAY['scann']);

ऊपर दी गई क्वेरी का नतीजा यह है:

6c163dd08cf4d693.png

याद रखने की वैल्यू में 90% की बढ़ोतरी हुई है!!!

इंडेक्स में ऐसे अन्य पैरामीटर भी हैं जिन्हें अपनी पसंद के मुताबिक बदला जा सकता है. जैसे, num_leaves वगैरह. ये बदलाव, रीकॉल वैल्यू और आपके ऐप्लिकेशन के इस्तेमाल किए जाने वाले डेटासेट के आधार पर किए जाते हैं.

8. व्यवस्थित करें

इस पोस्ट में इस्तेमाल किए गए संसाधनों के लिए, अपने Google Cloud खाते से शुल्क न लिए जाएं, इसके लिए यह तरीका अपनाएं:

  1. Google Cloud Console में, रिसॉर्स मैनेजर पेज पर जाएं.
  2. प्रोजेक्ट की सूची में, वह प्रोजेक्ट चुनें जिसे मिटाना है. इसके बाद, मिटाएं पर क्लिक करें.
  3. डायलॉग बॉक्स में, प्रोजेक्ट आईडी टाइप करें. इसके बाद, प्रोजेक्ट मिटाने के लिए बंद करें पर क्लिक करें.
  4. इसके अलावा, AlloyDB क्लस्टर को मिटाया जा सकता है. अगर आपने कॉन्फ़िगरेशन के समय क्लस्टर के लिए us-central1 को नहीं चुना है, तो इस हाइपरलिंक में जगह बदलें. हमने इस प्रोजेक्ट के लिए अभी-अभी यह क्लस्टर बनाया है. क्लस्टर मिटाने के लिए, 'क्लस्टर मिटाएं' बटन पर क्लिक करें.

9. बधाई हो

बधाई हो! आपने बेहतर परफ़ॉर्मेंस के लिए, AlloyDB की बेहतर वेक्टर सर्च की मदद से, संदर्भ के हिसाब से पेटेंट खोजने की क्वेरी बनाई है. साथ ही, इसे ज़्यादा काम का बनाने के लिए भी ऐसा किया है. मैंने क्वालिटी कंट्रोल वाला एक मल्टी-टूल एजेंटिक ऐप्लिकेशन बनाया है. इसमें ADK और AlloyDB के सभी टूल का इस्तेमाल किया गया है. इन टूल के बारे में हमने यहां बात की थी. इस ऐप्लिकेशन की मदद से, बेहतर परफ़ॉर्म करने वाला और अच्छी क्वालिटी वाला पेटेंट वेक्टर सर्च और ऐनालाइज़र एजेंट बनाया जा सकता है. इस ऐप्लिकेशन को यहां देखा जा सकता है: https://youtu.be/Y9fvVY0yZTY

अगर आपको यह एजेंट बनाने का तरीका जानना है, तो कृपया यह codelab देखें.

आज ही शुरू करें!