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

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

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

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

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

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

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

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

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

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

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

לוחצים על הגדרת קישור.

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

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

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

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

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

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

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

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

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

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

מתן הרשאה

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

GRANT EXECUTE ON FUNCTION embedding TO postgres;

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

במסוף IAM של Google Cloud, מעניקים לחשבון השירות של AlloyDB (שנראה כך: service-<<PROJECT_NUMBER>>@gcp-sa-alloydb.iam.gserviceaccount.com) גישה לתפקיד Vertex AI User. ‫PROJECT_NUMBER יכיל את מספר הפרויקט.

אפשר גם להריץ את הפקודה הבאה מ-Cloud Shell Terminal:

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 Public Datasets ב-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, לוחצים על View Raw (הצגת קובץ גולמי). הפעולה הזו מתבצעת כדי שלא תצטרכו (בשלבים הבאים) ליצור יותר מכמה הטמעות (נניח 20-25 לכל היותר) אם אתם משתמשים בחשבון לחיוב עם קרדיט לתקופת ניסיון ב-Google Cloud.

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

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

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

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

עדכון שדה הווקטור 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. אנחנו ממירים אותו להטמעות באמצעות השיטה 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 כבר מותקן, צריך לשדרג את התוסף vector לגרסה 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:

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 עם סינון מוטבע ב-Vector Search מאפשר זאת!!!

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

כלי להערכת זכירת המודעה

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

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

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

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

הערה חשובה:

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

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

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

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

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

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

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

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

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

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

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

[BEFORE] שאילתה שמשתמשת בפונקציית המרחק של דמיון קוסינוס:

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 לפונקציות של מרחק ב-Vector Search.

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

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

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

drop index patent_index;

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

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

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

[אחרי] שאילתה שמשתמשת בפונקציית המרחק של דמיון קוסינוס:

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

9. מזל טוב

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

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

אפשר להתחיל עוד היום!