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

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

הגדרת שדות

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

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

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

הגדרות שדה

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

הגדרה	הגדרה	מטרה	דוגמה לתרחיש שימוש
ניתן להוספה לאינדקס	הגדרת שדות כניתנים לאינדוקס מאפשרת לבצע פעולות כמו סינון, שיפור ופילוח בשדות מובנים במסמך. אי אפשר להגדיר את השדות מסוג `Object` כ-`Indexable`.	סימון שדה כ`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`.
התאמה חלקית (גרסת Preview)	מאפשרת התאמה חלקית של מחרוזות בשדות טקסט באמצעות האופרטור `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` מאפשרת למערכת ליצור באופן אוטומטי מסננים אינטראקטיביים (היבטים) על סמך הערכים הייחודיים שמופיעים בשדה.	הגדרת שדה לערך `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`, כשמשתמש מקליד טכנולוגיה, יכולות להופיע ההצעות הבאות להשלמה אוטומטית: ‫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 ניתן משקל נמוך יותר.

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

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

בשדות מהסוג 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") יתאימו בהצלחה בגלל הטוקניזציה המיוחדת של הסמל @.

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

הגדרות שדה

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

מגבלות

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

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

רמות משקל

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

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

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

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

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

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

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

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

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

איך זה עובד

דוגמאות

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

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

איך זה עובד

דוגמאות

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

הגדרת שדות