RAG מבוקר איכות עם התכונות החדשות של AlloyDB לחיפוש באמצעות וקטורים!

1. סקירה כללית

בחיפוש לפי הקשר יש פונקציונליות קריטית שמהווה את הליבה של האפליקציות בתחומים שונים. כבר זמן מה, הדור הבא של אחזור (RAG) הוא אחד מהגורמים העיקריים להתפתחות הטכנולוגית החשובה הזו, באמצעות מנגנוני אחזור שמבוססים על AI גנרטיבי. מודלים גנרטיביים, עם חלונות ההקשר הגדולים שלהם ואיכות הפלט המרשימה, משנים את פני ה-AI. RAG מספק דרך שיטתית להחדרת הקשר לאפליקציות ולסוכנים של AI, על ידי התבססות על מסדי נתונים מובְנים או על מידע ממקורות מדיה שונים. נתוני ההקשר האלה חיוניים להבהרת האמת ולדיוק הפלט, אבל עד כמה התוצאות האלה מדויקות? האם העסק שלכם תלוי במידה רבה בדיוק ההתאמות והרלוונטיות לפי הקשר? אם זה המצב, הפרויקט הזה יעשה לכם את זה!

הסוד הגדול של חיפוש וקטורי הוא לא רק בניית החיפוש, אלא גם היכולת לדעת אם ההתאמות הווקטוריות טובות. כולנו היינו שם, מביטים בעיניים חלולות ברשימת תוצאות ומתלבטים: "המכשיר הזה בכלל עובד?" עכשיו נראה איך בודקים את האיכות של ההתאמות של הווקטורים. "אז מה השתנה ב-RAG?", אתם שואלים. הכל! במשך שנים, הרגשנו שהטכנולוגיה של יצירת מודלים משופרים לאחזור (RAG) היא מטרה מבטיחה אבל לא מושגת. עכשיו, סוף סוף, יש לנו את הכלים לפתח אפליקציות RAG עם הביצועים והאמינות הנדרשים למשימות קריטיות.

עכשיו כבר יש לנו הבנה בסיסית של 3 דברים:

1. מהו חיפוש לפי הקשר עבור הנציגים שלכם ואיך משיגים אותו באמצעות חיפוש וקטורי.
2. כמו כן, התעמקנו בשימוש בחיפוש וקטורים בהיקף הנתונים שלכם, כלומר בתוך מסד הנתונים עצמו (אם עדיין לא ידעתם, כל מסדי הנתונים של Google Cloud תומכים בכך).
3. הגענו צעד אחד קדימה מכל שאר העולם, והסברנו איך להשיג יכולת RAG של חיפוש וקטורים קל משקל עם ביצועים ואיכות גבוהים באמצעות יכולת החיפוש של AlloyDB Vector שמבוססת על האינדקס ScaNN.

אם עדיין לא קראת את הניסויים הבסיסיים, הבינוניים והמתקדמים של RAG, מומלץ לקרוא את 3 המאמרים האלה כאן, כאן וכאן לפי הסדר שמופיע.

חיפוש פטנטים עוזר למשתמש למצוא פטנטים שרלוונטיים להקשר של טקסט החיפוש שלו, וכבר פיתחנו גרסה של התכונה הזו בעבר. עכשיו נבנה אותו עם תכונות RAG חדשות ומתקדמות שמאפשרות לבצע חיפוש לפי הקשר לאפליקציה הזו עם בקרה על האיכות. קדימה, מתחילים!

בתמונה הבאה מוצג התהליך הכולל של מה שקורה באפליקציה הזו.~

מטרה

מאפשרים למשתמש לחפש פטנטים על סמך תיאור טקסטואלי, עם ביצועים משופרים ואיכות טובה יותר, תוך יכולת להעריך את האיכות של ההתאמות שנוצרו באמצעות התכונות העדכניות ביותר של RAG ב-AlloyDB.

מה תפַתחו

במסגרת שיעור ה-Lab הזה תלמדו:

1. יצירת מכונה של AlloyDB וטעינה של מערך הנתונים הציבורי של פטנטים
2. יצירת אינדקס מטא-נתונים ואינדקס ScaNN
3. הטמעת חיפוש מתקדם של וקטורים ב-AlloyDB באמצעות שיטת הסינון בתוך השורה של ScaNN
4. הטמעת התכונה 'בדיקת זכרון'
5. בדיקת התשובה לשאילתה

דרישות

• דפדפן, כמו Chrome או Firefox
• פרויקט ב-Google Cloud שבו החיוב מופעל.

2. לפני שמתחילים

יצירת פרויקט

1. בדף לבחירת הפרויקט במסוף Google Cloud, בוחרים פרויקט קיים או יוצרים פרויקט חדש ב-Google Cloud.
2. הקפידו לוודא שהחיוב מופעל בפרויקט שלכם ב-Cloud. כך בודקים אם החיוב מופעל בפרויקט
3. תשתמשו ב-Cloud Shell, סביבת שורת פקודה שפועלת ב-Google Cloud. לוחצים על Activate Cloud Shell בחלק העליון של מסוף Google Cloud.

4. אחרי שמתחברים ל-Cloud Shell, בודקים שכבר בוצע אימות ושהמזהה של הפרויקט מוגדר כפרויקט באמצעות הפקודה הבאה:

gcloud auth list

5. מריצים את הפקודה הבאה ב-Cloud Shell כדי לוודא שהפקודה gcloud מכירה את הפרויקט.

gcloud config list project

6. אם הפרויקט לא מוגדר, משתמשים בפקודה הבאה כדי להגדיר אותו:

gcloud config set project <YOUR_PROJECT_ID>

7. מפעילים את ממשקי ה-API הנדרשים. אפשר להשתמש בפקודת gcloud בטרמינל של Cloud Shell:

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. הגדרת מסד נתונים

בשיעור ה-Lab הזה נשתמש ב-AlloyDB כמסד הנתונים של נתוני הפטנטים. הוא משתמש באשכולות כדי לאחסן את כל המשאבים, כמו מסדי נתונים יומנים. לכל אשכול יש מכונה ראשית שמספקת נקודת גישה לנתונים. הטבלאות יכללו את הנתונים בפועל.

נלמד איך יוצרים אשכול, מכונה וטבלה ב-AlloyDB שבהם ייטען מערך הנתונים של הפטנטים.

יצירת אשכול ומכונה

1. נכנסים לדף AlloyDB במסוף Cloud. דרך קלה למצוא את רוב הדפים במסוף Cloud היא לחפש אותם באמצעות סרגל החיפוש במסוף.
2. בדף הזה, בוחרים באפשרות CREATE CLUSTER (יצירת אשכול):

3. יוצג מסך כמו זה שבהמשך. יוצרים אשכול ומכונה עם הערכים הבאים (חשוב לוודא שהערכים תואמים במקרה שמשכפלים את קוד האפליקציה מהמאגר):

• cluster id:‏ "vector-cluster"
• password: "alloydb"
• PostgreSQL 15 / הגרסה האחרונה המומלצת
• אזור: "us-central1"
• Networking:‏ "default"

4. כשבוחרים את רשת ברירת המחדל, מופיע מסך כמו זה שבהמשך.

בוחרים באפשרות הגדרת חיבור.

5. לאחר מכן, בוחרים באפשרות Use an automatically allocated IP range (שימוש בטווח כתובות IP שהוקצה באופן אוטומטי) וממשיכים. אחרי שבודקים את המידע, בוחרים באפשרות 'יצירת חיבור'.
6. אחרי שמגדירים את הרשת, אפשר להמשיך ליצור את האשכולות. לוחצים על CREATE CLUSTER (יצירת אשכול) כדי להשלים את הגדרת האשכול, כפי שמתואר בהמשך:

חשוב לשנות את מזהה המכונה (שאפשר למצוא בזמן ההגדרה של האשכולות או המכונות) ל

vector-instance. אם אין לכם אפשרות לשנות אותו, חשוב לזכור להשתמש במזהה המכונה בכל ההפניות הבאות.

לתשומת ליבכם: יצירת האשכולות תימשך כ-10 דקות. לאחר השלמת הפעולה, אמור להופיע מסך עם סקירה כללית של האשכולות שיצרתם.

4. הטמעת נתונים

עכשיו הגיע הזמן להוסיף טבלה עם הנתונים על החנות. עוברים אל AlloyDB, בוחרים את האשכול הראשי ואז את AlloyDB Studio:

יכול להיות שתצטרכו להמתין עד לסיום יצירת המכונה. לאחר מכן, נכנסים ל-AlloyDB באמצעות פרטי הכניסה שיצרתם כשיצרתם את האשכולות. משתמשים בנתונים הבאים כדי לבצע אימות ב-PostgreSQL:

• שם משתמש : "postgres"
• מסד נתונים : 'postgres'
• סיסמה : "alloydb"

אחרי שתבצעו אימות ב-AlloyDB Studio, תוכלו להזין פקודות SQL בעורך. אפשר להוסיף כמה חלונות של הכלי באמצעות סמל הפלוס שמשמאל לחלון האחרון.

מזינים פקודות ל-AlloyDB בחלונות העריכה, באמצעות האפשרויות Run (הפעלה), Format (פורמט) ו-Clear (מחיקה) לפי הצורך.

הפעלת תוספים

כדי ליצור את האפליקציה הזו, נשתמש בתוספים pgvector ו-google_ml_integration. התוסף pgvector מאפשר לאחסן ולחפש הטמעות של וקטורים. התוסף google_ml_integration מספק פונקציות שמאפשרות לגשת לנקודות קצה של חיזוי ב-Vertex AI כדי לקבל חיזויים ב-SQL. מפעילים את התוספים האלה על ידי הפעלת שאילתות ה-DDL הבאות:

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

כדי לבדוק את התוספים שהופעלו במסד הנתונים, מריצים את פקודת ה-SQL הבאה:

select extname, extversion from pg_extension;

צור טבלה

אפשר ליצור טבלה באמצעות משפט ה-DDL הבא ב-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;

הקצאת התפקיד Vertex AI User לחשבון השירות של AlloyDB

במסוף IAM של Google Cloud, מעניקים לחשבון השירות של 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"

טעינת נתוני הפטנטים במסד הנתונים

מערכי הנתונים הציבוריים של Google Patents ב-BigQuery ישמשו כמערך הנתונים שלנו. נשתמש ב-AlloyDB Studio כדי להריץ את השאילתות שלנו. הנתונים מגיעים מהקובץ insert_scripts.sql, ואנחנו מריצים אותו כדי לטעון את נתוני הפטנטים.

1. במסוף Google Cloud, פותחים את הדף AlloyDB.
2. בוחרים את האשכולות החדשים שנוצרו ולוחצים על המכונה.
3. בתפריט הניווט של AlloyDB, לוחצים על AlloyDB Studio. נכנסים באמצעות פרטי הכניסה.
4. לוחצים על הסמל כרטיסייה חדשה בצד שמאל כדי לפתוח כרטיסייה חדשה.
5. מעתיקים את ביטוי השאילתה insert מהסקריפט insert_scripts.sql שצוין למעלה לעורך. אפשר להעתיק 10 עד 50 משפטי insert כדי להציג הדגמה מהירה של תרחיש לדוגמה הזה.
6. לוחצים על Run. התוצאות של השאילתה מופיעות בטבלה Results.

הערה: יכול להיות שתבחינו שסקריפט ההוספה מכיל הרבה נתונים. הסיבה לכך היא שכללנו הטמעות בסקריפטים להוספה. אם נתקלת בבעיות בטעינה של הקובץ ב-GitHub, אפשר ללחוץ על 'הצגת קובץ גלם'. הסיבה לכך היא כדי לחסוך לכם את הטרחה (בשלבים הבאים) של יצירת יותר מכמה הטמעות (כ-20-25 לכל היותר) אם אתם משתמשים בחשבון לחיוב ב-Google Cloud שמחויב באמצעות קרדיט לניסיון.

5. יצירת הטמעות (embeddings) לנתוני פטנטים

קודם נבדוק את פונקציית ההטמעה על ידי הרצת השאילתה לדוגמה הבאה:

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

הפונקציה הזו אמורה להחזיר את וקטור הטמעת הטקסט, שנראה כמו מערך של מספרים שגופים (floats), עבור טקסט לדוגמה בשאילתה. כך זה נראה:

מעדכנים את שדה הווקטורים abstract_embeddings

מריצים את ה-DML הבא כדי לעדכן את תקצירי הפטנטים בטבלה באמצעות הטמעות התווים התואמות, רק אם לא הוספת את הנתונים של abstract_embeddings כחלק מסקריפט ההוספה:

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

אם אתם משתמשים בחשבון לחיוב ב-Google Cloud שמחויב באמצעות קרדיט לניסיון, יכול להיות שתתקשו ליצור יותר מכמה הטמעות (כ-20-25 לכל היותר). לכן, כבר כללתי את הטמעות הנתונים בסקריפטים להוספה, והם אמורים להיות טעונים בטבלה אם השלמתם את השלב 'טעינה של נתוני הפטנטים למסד הנתונים'.

6. ביצוע RAG מתקדם באמצעות התכונות החדשות של AlloyDB

עכשיו, כשהטבלה, הנתונים וההטמעות מוכנים, נבצע חיפוש וקטורים בזמן אמת של טקסט החיפוש של המשתמש. אפשר לבדוק את זה על ידי הרצת השאילתה הבאה:

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

בשאילתה הזו,

1. הטקסט שהמשתמש חיפש הוא: 'ניתוח רגשות'.
2. אנחנו ממירים אותו למיפויים (embeddings) בשיטה embedding() באמצעות המודל: text-embedding-005.
3. "<=>" מייצג את השימוש בשיטת המרחק COSINE SIMILARITY.
4. אנחנו ממירים את התוצאה של שיטת ההטמעה לסוג וקטור כדי שהיא תהיה תואמת לווקטורים שמאוחסנים במסד הנתונים.
5. LIMIT 10 מייצג את העובדה שאנחנו בוחרים את 10 ההתאמות הקרובות ביותר לטקסט החיפוש.

AlloyDB מעלה את ה-RAG של Vector Search לרמה הבאה:

יש הרבה דברים חדשים. שניים מהם מותאמים למפתחים:

1. סינון בקוד
2. כלי להערכת ריקול

סינון בקוד

בעבר, מפתחים היו צריכים לבצע את השאילתה של חיפוש וקטורים ולטפל בעצמם בסינון ובאחזור. הכלי של AlloyDB Query Optimizer מקבל החלטות לגבי אופן ביצוע השאילתה עם המסננים. סינון בקוד הוא טכניקה חדשה לאופטימיזציה של שאילתות שמאפשרת למטמיזטור השאילתות של 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 מלכתחילה כי הוא לא רלוונטי למספר שורות קטן יותר. במקרה כזה, אפשר לדלג על השלבים הבאים.

2. כדי ליצור אינדקסים של ScaNN, צריך להתקין את התוסף alloydb_scann.

CREATE EXTENSION IF NOT EXISTS alloydb_scann;

3. קודם כול, מריצים את שאילתת החיפוש של וקטורים ללא האינדקס וללא הפעלת המסנן בקוד:

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;

התוצאה אמורה להיראות כך:

4. מריצים עליו את Explain Analyze: (ללא אינדקס או סינון בקוד)

זמן הביצוע הוא 2.4 אלפיות השנייה

5. נוצר אינדקס רגיל בשדה num_claims כדי שנוכל לסנן לפיו:

CREATE INDEX idx_patents_data_num_claims ON patents_data (num_claims);

6. נתחיל ליצור את האינדקס 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, לא תצטרכו ליצור אינדקס מלכתחילה כי הוא לא רלוונטי למספר שורות קטן יותר.

7. מגדירים את סינון הטקסט בקוד כפעיל ב-ScaNN Index:

SET scann.enable_inline_filtering = on

8. עכשיו נריץ את אותה שאילתה עם מסנן וחיפוש וקטורים:

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;

כפי שניתן לראות, זמן הביצוע של אותה חיפוש וקטור צומצם באופן משמעותי. האפשרות הזו התאפשרה בזכות סינון בקוד המוטמע באינדקס ScaNN בחיפוש וקטורים.

בשלב הבא נבדוק את רמת החזרה (recall) של חיפוש הוקטורים עם ScaNN מופעל.

כלי להערכת ריקול

החזרה (recall) בחיפוש לפי דמיון היא אחוז המופעים הרלוונטיים שאוחזרו מחיפוש, כלומר מספר התוצאות החיוביות האמיתיות. זהו המדד הנפוץ ביותר למדידת איכות החיפוש. מקור אחד של אובדן זיכרון נובע מההבדל בין חיפוש שכנים קרובים (approximate nearest neighbor) או aNN, לבין חיפוש שכנים קרובים (exact) או kNN. אינדקסים וקטוריים כמו ScaNN של AlloyDB מיישמים אלגוריתמים של רשתות נוירונליות עמוקות (ANN), ומאפשרים לכם לזרז את החיפוש של וקטורים במערכי נתונים גדולים, בתמורה לירידה קלה בזיהוי. עכשיו, AlloyDB מאפשרת למדוד את הפשרה הזו ישירות במסד הנתונים לשאילתות ספציפיות, ולוודא שהיא יציבה לאורך זמן. בהתאם למידע הזה, אפשר לעדכן את הפרמטרים של השאילתות והאינדקסים כדי לשפר את התוצאות והביצועים.

מהי הלוגיקה שמאחורי החזרת תוצאות חיפוש?

בהקשר של חיפוש וקטורים, החזרה מתייחסת לאחוז הווקטורים שהאינדקס מחזיר שהם באמת השכנים הקרובים ביותר. לדוגמה, אם שאילתת השכן הקרוב ביותר ל-20 השכנים הקרובים ביותר מחזירה 19 מהשכנים הקרובים ביותר של עובדת המציאות, אז ההחזר הוא 19/20x100 = 95%. החזקה היא המדד המשמש לאיכות החיפוש, והיא מוגדרת כאחוז התוצאות שהתקבלו שקרובות באופן אובייקטיבי לווקטורים של השאילתות.

אפשר למצוא את החזרה של שאילתה וקטורית במסד נתונים וקטוריים בהגדרה נתונה באמצעות הפונקציה evaluate_query_recall. הפונקציה הזו מאפשרת לכם לשנות את הפרמטרים כדי להשיג את תוצאות החזרה של שאילתות וקטוריות הרצויות.

הערה חשובה:

אם מופיעה שגיאה מסוג 'הרשאה נדחתה' באינדקס HNSW בשלבים הבאים, כדאי לדלג בינתיים על כל הקטע הערכת הרזולוציה. יכול להיות שזה קשור למגבלות גישה בשלב הזה, כי הספרייה הזו שוחררה רק בזמן תיעוד הקודלאב הזה.

1. מגדירים את הדגל Enable Index Scan ב-ScaNN Index וב-HNSW index:

SET scann.enable_indexscan = on
SET hnsw.enable_index_scan = on

2. מריצים את השאילתה הבאה ב-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 כשיטת האינדקס. אפשרויות נוספות של פרמטרים מפורטות במסמכי העזרה.

ביטול הקריאה לאחור של שאילתת החיפוש ב-Vector שבה השתמשנו:

אני רואה שהאחוז של הקריאה לאיסוף הוא 70%. עכשיו אוכל להשתמש במידע הזה כדי לשנות את הפרמטרים של המדד, השיטות ופרמטרי השאילתה, ולשפר את החזרה של החיפוש בעזרת וקטור.

7. בדיקה עם פרמטרים של שאילתה ושל אינדקס ששונו

עכשיו נבדוק את השאילתה על ידי שינוי הפרמטרים שלה על סמך ההודעה על הקריאה לאחזור.

1. שיניתי את מספר השורות בקבוצת התוצאות ל-7 (מ-25 קודם) וראיתי שיפור בזיכרון, כלומר 86%.

המשמעות היא שאני יכול לשנות בזמן אמת את מספר ההתאמות שהמשתמשים שלי רואים כדי לשפר את הרלוונטיות של ההתאמות בהתאם להקשר החיפוש של המשתמשים.

2. ננסה שוב על ידי שינוי הפרמטרים של האינדקס:

בבדיקה הזו אשתמש בפונקציית המרחק L2 Distance במקום בפונקציית המרחק Cosine. אשנה גם את המגבלה של השאילתה ל-10 כדי להראות אם יש שיפור באיכות של תוצאות החיפוש גם כשמגדילים את מספר קבוצות תוצאות החיפוש.

[לפני] שאילתה שמשתמשת בפונקציית המרחק Cosine Similarity:

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']);

הערה חשובה מאוד: "איך אנחנו יודעים שהשאילתה הזו משתמשת ב-COSINE similarity?", אתם שואלים. אפשר לזהות את פונקציית המרחק באמצעות השימוש ב-"<=>" כדי לייצג את המרחק הקוסינוסי.

קישור ל-Docs לפונקציות המרחק של חיפוש וקטורים.

התוצאה של השאילתה שלמעלה היא:

כפי שניתן לראות, הערך של RECALL הוא 70% ללא שינוי בלוגיקה של האינדקס שלנו. זכור את מדד ScaNN שיצרנו בשלב 6 בקטע 'סינון בקוד', "patent_index "? אותו מדד עדיין בתוקף בזמן שהרצנו את השאילתה שלמעלה.

עכשיו נוצרים אינדקס עם שאילתה אחרת של פונקציית מרחק: L2 distance: <->

drop index patent_index;

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

משפט drop index נועד רק לוודא שאין בטבלה אינדקס מיותר.

עכשיו אפשר להריץ את השאילתה הבאה כדי להעריך את הערך של RECALL אחרי שינוי פונקציית המרחק של פונקציונליות החיפוש לפי וקטור.

שאילתה [AFTER] שמשתמשת בפונקציית המרחק Cosine Similarity:

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']);

התוצאה של השאילתה שלמעלה היא:

איזו טרנספורמציה בערך הזכירה, 90%!!!

יש פרמטרים אחרים שאפשר לשנות במדד, כמו num_leaves וכו', על סמך ערך החזרה הרצוי ומערך הנתונים שבו האפליקציה משתמשת.

8. הסרת המשאבים

כדי להימנע מצבירת חיובים בחשבון Google Cloud על המשאבים שבהם השתמשתם במאמר הזה, יש לפעול לפי השלבים הבאים:

1. נכנסים לדף resource manager במסוף Google Cloud.
2. ברשימת הפרויקטים, בוחרים את הפרויקט שרוצים למחוק ולוחצים על Delete.
3. כדי למחוק את הפרויקט, כותבים את מזהה הפרויקט בתיבת הדו-שיח ולוחצים על Shut down.
4. לחלופין, אפשר פשוט למחוק את אשכול AlloyDB (משנים את המיקום בהיפר-קישור הזה אם לא בחרתם ב-us-central1 לאשכול בזמן ההגדרה) שיצרנו עכשיו לפרויקט הזה, בלחיצה על הלחצן DELETE CLUSTER.

9. מזל טוב

מעולה! יצרתם בהצלחה שאילתה לפי הקשר לחיפוש פטנטים באמצעות החיפוש המתקדם של AlloyDB לפי וקטור, כדי לשפר את הביצועים ולאפשר לה להתמקד במשמעות. יצאתי עם אפליקציה של סוכנות עם כמה כלים מבוקרים לאיכות, שמשתמשת ב-ADK ובכל הדברים של AlloyDB שדיברנו עליהם כאן כדי ליצור סוכן חיפוש וניתוח של פטנטים עם ביצועים גבוהים ואיכות גבוהה. אפשר לצפות בו כאן: https://youtu.be/Y9fvVY0yZTY

כדי ללמוד איך ליצור את הסוכן הזה, אפשר לעיין בcodelab הזה.

מתחילים עוד היום!