Note: Vertex AI Search is being renamed to Agent Search. We are in the process of updating content to reflect the new branding.

‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

הגדרת שדות

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

הגדרות השדות עוזרות לקבוע איך התכונה 'חיפוש מבוסס סוכנים' משתמשת בשדות בתוצאות שלה. אפשר להשתמש בכרטיסייה Schema במסוףGoogle Cloud כדי להגדיר את הגדרות השדות.

אפשר להגדיר את הגדרות השדות רק באפליקציות עם מאגרי נתונים שמכילים נתונים מובְנים או נתונים לא מובְנים עם מטא-נתונים.

הגדרות שדה

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

הגדרה	הגדרה	מטרה	דוגמה לתרחיש שימוש
ניתן להוספה לאינדקס	הגדרת שדות כניתנים לאינדוקס מאפשרת לבצע פעולות כמו סינון, קידום ופילוח בשדות מובנים במסמך. אי אפשר להגדיר את הערך `Indexable` לשדות מהסוג `Object`.	סימון שדה כ`Indexable` מאפשר חיפושים מהירים יותר. שימו לב: סימון שדה כ`Indexable` מגדיל את הגודל של אינדקס החיפוש ויכול להאט את ההוספה לאינדקס.	במאגר נתוני מלונות, אפשר להגדיר שדה, כמו `hotel_chain`, כניתן לאינדוקס. כך אפשר להחיל פעולות של דירוג, סינון והדגשה על `hotel_chain`. לדוגמה, אפשר להחיל מסנן כך שהחיפוש יציג רק תוצאות חיפוש שמכילות את רשת המלונות שסוננה.
זמין בחיפוש	שדות שיש סיכוי גבוה שקשורים לחיפושים מסומנים בסמל `Searchable`. אפשר לחפש בשדה מסוים גם אם אי אפשר להוסיף אותו לאינדקס או לאחזר אותו. אפשר לסמן כשדות שניתן לחפש בהם רק שדות עם ערכי טקסט. לכן, אפשר להוסיף לאינדקס שדה מחיר מספרי (לסינון או ליצירת פילוח), אבל אי אפשר לבצע בו חיפוש כטקסט מלא.	הגדרת שדה כניתן לחיפוש משפרת את היכולת לאחזר מידע בשדה הזה בשאילתות חיפוש, ומאפשרת למשתמשים למצוא תוכן, כמו דפי אינטרנט, על ידי שאילתת הטקסט בשדות האלה. סימון שדה כזמין לחיפוש מאפשר להחיל דירוג. לכן, סימון של מספר רב מדי של שדות כניתנים לחיפוש עלול להשפיע לרעה על דיוק החיפוש, כי האלגוריתם של הדירוג יקבל יותר מדי נתונים ויחזיר יותר מדי תוצאות. זה עלול להוביל לתוצאות חיפוש לא רלוונטיות. אפשר להחיל משקל יחסי על שדות שאפשר לחפש בהם, אבל בגלל הגדרות ברירת המחדל החזקות, זה כמעט אף פעם לא נדרש. בהמשך מפורטים שדות המשקל שאפשר לחפש.	מערכת הכרטיסים של ספק אינטרנט מאחסנת כל כרטיס כמסמך מובנה. אם המסמכים האלה מכילים שדות טקסט שאפשר לחפש בהם, כמו `issue_description` או `resolution_notes`, נציג תמיכה יכול להריץ שאילתה שקשורה לתוכן בשדות האלה, כמו איך אפשר לתקן מהירויות אינטרנט איטיות אחרי איפוס המודם. המערכת תציג את המסמכים שמכילים את אחד ממונחי החיפוש האלה, כולל מודם, אינטרנט, מהירות, באחד מהשדות `issue_description` או `resolution_notes` או בשניהם.
התאמה לפי קידומת (תצוגה מקדימה)	מאפשרת התאמה של תחיליות בשדות טקסט באמצעות האופרטור `STARTS_WITH` בביטויי סינון. אפשר להגדיר רק שדות מסוג `String` או `String Array` כמתאימים להתאמה לפי קידומת. מידע נוסף זמין בקטע הפיכת שדות לזמינים להתאמה לפי קידומת ולהתאמה חלקית בהמשך המאמר.	הגדרת שדה כמתאים להתאמה לפי קידומת מאפשרת למנוע החיפוש להתאים מחרוזות של שאילתות שהן קידומות של ערך השדה. האפשרות הזו שימושית במיוחד להתאמת מזהים היררכיים, נתיבים או קודים שבהם ידוע מה ההתחלה של המחרוזת. התאמה לפי קידומת מוגבלת ל-12 התווים הראשונים של הערך המנורמל בשדה, ומגדילה את הגודל של אינדקס החיפוש. אי אפשר להגדיר יותר מ-10 שדות ככאלה שאפשר להתאים להם תחילית.	יש לכם שדה, `ticket_id`, שמשתמש בפורמט כמו `<country-code><city-code><number>`. דוגמאות: `UKLON100`, `UKMAN100`, `UKMAN101` ו-`USNY200`. כדי למצוא את כל הכרטיסים ממנצ'סטר (בריטניה), אפשר להגדיר את השדה `ticket_id` כמתאים לחיפוש לפי קידומת ואז להשתמש במסנן `ticket_id: STARTS_WITH("UKMAN")`, שמחזיר את `UKMAN100` ו-`UKMAN101`.
ניתן להתאמה חלקית (תצוגה מקדימה)	מאפשרת התאמה חלקית של מחרוזות בשדות טקסט באמצעות האופרטור `CONTAINS` בביטויי סינון. אפשר להגדיר התאמה חלקית רק לשדות מסוג `String` או `String Array`. מידע נוסף זמין בקטע הפיכת שדות לזמינים להתאמה לפי קידומת ולהתאמה חלקית בהמשך המאמר.	הגדרה של שדה כניתן להתאמה חלקית מאפשרת התאמה מבוססת-טוקנים בתוך שדה, וכך המשתמשים יכולים למצוא תוכן גם אם הם יודעים רק חלק מערך השדה. מנוע החיפוש משווה בין טוקנים של שאילתות לבין טוקנים בשדה value, ללא קשר לסדר שלהם. שימו לב: סימון שדה כמתאים להתאמה חלקית מגדיל את גודל אינדקס החיפוש. אי אפשר להגדיר יותר מ-10 שדות ככאלה שאפשר להתאים באופן חלקי.	רוצים לסנן לפי אזורים באירופה. השמות `region` כוללים את `Central Europe` ואת `Eastern Europe`. אם המסנן הוא `region: ANY("Europe")`, לא יתקבלו התאמות. עם זאת, אם השדה `region` מוגדר כניתן להתאמה חלקית, אפשר לסנן לפי `region: CONTAINS("Europe")` ולקבל התאמות ל-`Central Europe` ול-`Eastern Europe`.
מסננים דינמיים	מספק מסננים שמודעים להקשר כדי לטרגט טוב יותר חיפושים של משתמשים. הגדרת שדה כ-`Dynamic Facetable` מאפשרת למערכת ליצור באופן אוטומטי מסננים אינטראקטיביים (מאפיינים) על סמך הערכים הייחודיים שמופיעים בשדה.	הגדרת שדה ל-`Dynamic facetable` מאפשרת למשתמשים לשפר באופן דינמי את תוצאות החיפוש על ידי בחירת קטגוריות או מאפיינים שנגזרים ישירות מהנתונים שהועברו, בלי להגדיר מראש באופן ידני כל אפשרות סינון אפשרית. כך המשתמש יכול לצמצם את החיפוש לתוכן אינטרנט ספציפי מאוד. כדאי להשתמש במסננים דינמיים עם אפשרות חיפוש כדי לשפר את התוצאות, וכך לשפר גם את ההיזכרות בחיפוש וגם את איכות המסננים שמוצעים למשתמש.	דפים במאגר מידע פנימי של החברה, כמו מדיניות משאבי אנוש, מוזנים עם נתונים כמו `department`,‏ `document_type` או `last_modified_date`. אם השדות האלה מתויגים כ-`dynamic facetable`, חיפוש של עובד אחר מונח כמו החזר הוצאות יוצר באופן דינמי מסננים אינטראקטיביים על סמך התוצאות הרלוונטיות שנמצאו. במקרה כזה, בממשק האינטרנט יוצגו היבטים כמו מחלקות: כספים, נסיעות, סוג המסמך: מדיניות, שאלות נפוצות או תאריך השינוי האחרון: הרבעון הנוכחי, השנה שעברה.
ניתן לאחזור	כששאילתת חיפוש מתאימה לתוכן, מנוע החיפוש יכול לשלוף את הערכים של השדות שאפשר לאחזר כדי להציג אותם או להשתמש בהם באפליקציה. כלומר, מידע מהמסמך המקורי מוצג כחלק מתוצאות החיפוש. שדות מפתח (מזהים ייחודיים של מסמכים) מוגדרים כשדות שאפשר לאחזר.	שדות שאפשר לאחזר מספקים הקשר לחיפוש על ידי הבחנה בין שדות שהערכים שלהם יכולים להיות מוצגים לבין שדות שנועדו לשימוש רק בלוגיקה של החיפוש, אבל הערכים הגולמיים שלהם לא אמורים להיות מוצגים למשתמש הקצה.	בחיפוש מוצר באתר של מוֹכר, השדות `product_id`,‏ `name`,‏ `price` וגם `image_url` הם שדות טיפוסיים שכדאי להגדיר כניתנים לאחזור. לעומת זאת, אפשר להוסיף את `internal_tracking_code` לאינדקס ולסנן אותו למטרות ניהול בלבד, אבל אי אפשר לאחזר אותו בתוצאות חיפוש ציבוריות.
Completable	מאפשרת להשתמש בתוכן של שדה מסוים כדי להציע הצעות לשאילתות חיפוש. מידע נוסף זמין במאמר בנושא הגדרת השלמה אוטומטית.	ההגדרה הזו מאפשרת להשתמש בערכים בשדה הזה כדי לספק הצעות לשאילתות בזמן אמת בזמן שהמשתמשים מקלידים. התכונה הזו עוזרת למשתמשים למצוא תוכן רלוונטי ומזרזת את תהליך החיפוש. גורמים מסוימים, כמו שימוש בסינון בשפה טבעית, יכולים להשפיע על הביצועים האלה.	אם השדה `completable` מוגדר לערכים `product_name`,‏ `brand` ו-`category`, כשמשתמש מקליד Tech, ההצעות להשלמה אוטומטית יכולות להיות: ‫TechCo (מהשדה `brand`) ‫TechCo UltraBook X1 (מהשדה `product_name` ) ‫Technology GameMaster Pro (another product from the `category` field)
ניתן לסינון	מאפשר להשתמש בשדה כדי לסנן את התוצאות המומלצות, ולקבוע אילו תוצאות חיפוש יוצגו למשתמשים. מידע על סינון המלצות זמין במאמר סינון המלצות.	הגדרת שדה לערך `Filterable` עוזרת להתאים אישית את ההמלצות למשתמשים. חשוב לזכור שחלות מגבלות על סינון.	הגדרת מסנן לפי שפה ודרמה יכולה להיראות כך: `language_code: ANY("en", "fr") OR categories: ANY("drama")`.

ההבדלים בין ההגדרות הנפוצות

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

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

בפועל, הרבה שדות שחשובים לחוויית המשתמש (כמו שמות, תיאורים ופרטי זיהוי) מוגדרים לעיתים קרובות כ-indexable, ‏searchable ו-retrievable.

מגבלות

יש מגבלות על הגדרות השדות:

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

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

עדכון הגדרות השדה

כדי לעדכן את הגדרות השדה:

נכנסים לדף AI Applications במסוף Google Cloud .

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

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

שדות שניתן לחפש בהם משקל (תצוגה מקדימה)

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

עם זאת, יש כמה מצבים שבהם צריך לשנות את המשקלים, למשל:

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

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

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

רמות משקל

המשקלים מחולקים לרמות הבאות:

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

עדכון סכימה ואינדוקס מחדש

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

הגדרת רמות משקל בשדות

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

אפשר להגדיר את המשקל של שדה החיפוש רק דרך ה-API. התכונה הזו לא זמינה ב- Google Cloud Console.

כדי להגדיר משקלים, צריך לעדכן את הסכימה של מאגר הנתונים באמצעות השיטה projects.locations.dataStores.schemas.patch של API.

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

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

"summary": {
   "type": "string",
   "searchable": true,
   "weight": "high"
 },
 "uri": {
   "type": "string",
   "searchable": true,
   "weight": "low"
 },

בדוגמה הזו, השדה summary מוגדר למשקל גבוה מהרגיל והשדה uri מוגדר למשקל נמוך. אם רוצים להחזיר משקל לערך ברירת המחדל, מגדירים אותו ל-default.

הערכים המותרים לפרמטר המשקל הם:

very_low
low
default
high
very_high

דוגמה לפקודה ולתוצאה

curl -X PATCH \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json" \
"https://discoveryengine.googleapis.com/v1beta/projects/my-project-123/locations/global/collections/default_collection/dataStores/my-data-store/schemas/default_schema" \
-d '{
"structSchema": { "$schema": "https://json-schema.org/draft/2020-12/schema", "properties": { "amenities": { "items": { "completable": true, "dynamicFacetable": true, "indexable": true, "retrievable": true, "searchable": true, "type": "string", "weight": "high" }, "type": "array" }, "available_date": { "indexable": true, "retrievable": true, "type": "datetime" }, "id": { "dynamicFacetable": false, "indexable": true, "retrievable": true, "type": "number" }, "location": { "indexable": true, "retrievable": true, "type": "geolocation" }, "non_smoking": { "dynamicFacetable": true, "indexable": true, "type": "boolean" }, "price_per_night": { "indexable": true, "retrievable": true, "type": "number" }, "rating": { "dynamicFacetable": true, "indexable": true, "retrievable": true, "type": "number" }, "room_types": { "items": { "dynamicFacetable": true, "indexable": true, "retrievable": true, "searchable": true, "type": "string", "weight": "low" }, "type": "array" }, "title": { "keyPropertyMapping": "title", "retrievable": true, "type": "string" } }, "type": "object" }
}'

{
"name": "projects/123456/locations/global/collections/default_collection/dataStores/my-data-store/schemas/default_schema/operations/update-schema-123456",
"metadata": {
"@type": "type.googleapis.com/google.cloud.discoveryengine.v1beta.UpdateSchemaMetadata"
}
}

בדוגמה הזו, לשדה amentities ניתן משקל גבוה מהרגיל, ולשדה room_types ניתן משקל נמוך יותר.

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

הפיכת שדות לזמינים להתאמה לפי קידומת ולהתאמה חלקית (גרסת Preview)

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

עדכון סכימה ואינדוקס מחדש

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

עדכון הסכימה להתאמה של קידומות והתאמה חלקית

כדי לציין שדות שזמינים להתאמה לפי קידומת או להתאמה חלקית, צריך לעדכן את הסכימה של מאגר הנתונים באמצעות השיטה projects.locations.dataStores.schemas.patch של API.

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

פועלים לפי ההוראות כדי לעדכן את הסכימה באופן פרוגרמטי. בסכימה, מגדירים את הפרמטרים שאפשר להתאים ל-true, כמו בדוגמאות האלה:

"zone": {
   "type": "string",
   "searchable": true,
   "prefixMatchable": true
 },
 "region": {
   "type": "string",
   "searchable": true,
   "partialMatchable": true
 },
 "model": {
   "type": "string",
   "searchable": true,
   "prefixMatchable": true,
   "partialMatchable": true
 },

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

דוגמה לפקודה ולתוצאה

curl -X PATCH \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json" \
"https://discoveryengine.googleapis.com/v1beta/projects/my-project-123/locations/global/collections/default_collection/dataStores/my-data-store/schemas/default_schema" \
-d '{
  "structSchema": { "$schema": "https://json-schema.org/draft/2020-12/schema",
  "properties": { "amenities": { "items": { "completable":
  true,"partialMatchable": true, "dynamicFacetable": true, "indexable": true,
  "retrievable": true, "searchable": true, "type": "string" },
  "type": "array" }, "available_date": { "indexable": true, "retrievable": true,
  "type": "datetime" }, "id": { "dynamicFacetable": false, "indexable": true,
  "retrievable": true, "type": "number" }, "location": { "indexable": true,
  "retrievable": true, "type": "geolocation" }, "non_smoking": {
  "dynamicFacetable": true, "indexable": true, "type": "boolean" },
  "price_per_night": { "indexable": true, "retrievable": true, "type": "number"
  }, "rating": { "dynamicFacetable": true, "indexable": true, "retrievable":
  true, "type": "number" }, "room_types": { "items": { "dynamicFacetable": true,
  "prefixMatchable": true, "indexable": true, "retrievable": true,
  "searchable": true, "type": "string" }, "type": "array" }, "title": {
  "keyPropertyMapping": "title", "retrievable": true, "type": "string" } },
  "type": "object" } }'

{
"name": "projects/123456/locations/global/collections/default_collection/dataStores/my-data-store/schemas/default_schema/operations/update-schema-123456",
  "metadata": {
    "@type": "type.googleapis.com/google.cloud.discoveryengine.v1beta.UpdateSchemaMetadata"
  }
}

בדוגמה הזו, אפשר להתאים חלקית את השדה amentities. המשמעות היא שהערך CONTAINS("outdoor pool") תואם לשירות עם הערך outdoor swimming pool. השדה room_type תומך בהתאמה לפי קידומת, כלומר מסנן של STARTS_WITH("lux") תואם לסוג חדר של Luxury Room אבל לא ל-Deluxe).

ממתינים לסיום יצירת האינדקס מחדש.

פרטים על התאמה לפי תחילית

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

נירמול ולוגיקה של התאמה

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

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

איך זה עובד

בזמן יצירת האינדקס, בשדה שמסומן ב-prefixMatchable, המערכת יוצרת טוקנים של קידומת ל-12 התווים הראשונים. לערך כמו asia-south1-c, האינדקס מאחסן אסימונים עבור a, as, asi, asia, asia- וכן הלאה, עד התו ה-12 (asia-south1-).

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

דוגמאות

בדוגמאות הבאות אפשר לראות איך הנורמליזציה של 12 התווים משפיעה על תוצאות החיפוש:

התאמות רחבות: STARTS_WITH("A") מתאים לכל ערך שמתחיל ב-a (לא תלוי רישיות), כמו asia,‏ australia או africa.
קידומות חלקיות: STARTS_WITH("asia-south") מתאים גם ל-asia-south1-a וגם ל-asia-southeast1-b כי שניהם מתחילים במחרוזת שצוינה באורך 10 תווים.
התנהגות החיתוך: מכיוון שהמערכת מתאימה רק את 12 התווים הראשונים, התבנית STARTS_WITH("asia-south1-a") מתאימה לערך השדה asia-south1-c. הסיבה לכך היא ששתי המחרוזות עוברות נורמליזציה לאותו קידומת של 12 תווים: asia-south1-.

פרטים על התאמה חלקית

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

הלוגיקה של הנירמול והטוקניזציה

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

המרת אותיות קטנות: חיפוש מבוסס סוכנים ממיר את התווים לאותיות קטנות. כך ההתאמה לא תלוית-רישיות.
טוקניזציה: חיפוש מבוסס סוכנים מפצל את המחרוזת לטוקנים (מילים) נפרדים באמצעות רווחים ותווים אחרים כמפרידים.
- תווים סטנדרטיים להפרדה: רווחים וסימני פיסוק נפוצים משמשים כתווים להפרדה, כולל מקפים (-), לוכסנים (/), פסיקים (,), נקודות (.), כוכביות (*), סוגריים מסולסלים ({ }), סוגריים מרובעים ([ ]), סוגריים עגולים (( )) וגרשיים (').
- תווים שלא משמשים כתווים להפרדה: אמפרסנד (&) וקו תחתון (_) לא משמשים כתווים להפרדה. המערכת מתייחסת לתווים שמחוברים באמצעות הסמלים האלה כאל טוקן יחיד.
- תו מפריד לכתובות אימייל (@): הסמל @ משמש כתו מפריד מיוחד כדי לעזור בזיהוי כתובות אימייל. המערכת יוצרת טוקנים לרכיבים בודדים וגם לטפסים משולבים. לדוגמה, הוא יוצר טוקנים מ-support+tier1@example.com ל-support, tier1, example, com, support+tier1@example.com ו-support@example.com.

איך זה עובד

בזמן יצירת האינדקס, בשדה שמסומן כ-partialMatchable, המערכת מבצעת נורמליזציה וטוקניזציה של ערך השדה ושומרת את הטוקנים שמתקבלים באינדקס. לדוגמה, הוא מבצע טוקניזציה של ערך השדה 25-meter, outdoor, swimming pool ל-[25, meter, outdoor, swimming, pool].

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

דוגמאות

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

התאמה בסיסית של טוקנים: אם ערך השדה הוא 25-meter, outdoor, swimming pool, מסנן של CONTAINS("Outdoor pool") יתאים. המערכת מבצעת טוקניזציה של השאילתה ל-[outdoor, pool], שניהם קיימים בטוקנים של השדה.
סדר לא משנה: מסנן של CONTAINS("pool outdoor") יתאים גם לערך השדה 25-meter, outdoor, swimming pool כי המערכת בודקת את הנוכחות של כל טוקן בנפרד, בלי קשר לסדר שלהם.
התאמה של כתובות אימייל: אם שדה מסוים מאחסן את כתובת האימייל support+tier1@example.com, מסננים כמו CONTAINS("support"), CONTAINS("example.com") או CONTAINS("support@example.com") יתאימו בהצלחה בגלל הטוקניזציה המיוחדת של הסמל @.

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

הגדרות שדה

ההבדלים בין ההגדרות הנפוצות

מגבלות

עדכון הגדרות השדה

שדות שניתן לחפש בהם משקל (תצוגה מקדימה)

רמות משקל

עדכון סכימה ואינדוקס מחדש

הגדרת רמות משקל בשדות

דוגמה לפקודה ולתוצאה

הפיכת שדות לזמינים להתאמה לפי קידומת ולהתאמה חלקית (גרסת Preview)

עדכון סכימה ואינדוקס מחדש

עדכון הסכימה להתאמה של קידומות והתאמה חלקית

דוגמה לפקודה ולתוצאה

פרטים על התאמה לפי תחילית

נירמול ולוגיקה של התאמה

איך זה עובד

דוגמאות

פרטים על התאמה חלקית

הלוגיקה של הנירמול והטוקניזציה

איך זה עובד

דוגמאות

המאמרים הבאים

הגדרת שדות