איכות החיפוש מתייחסת לאיכות של תוצאות החיפוש מבחינת הדירוג וההחזקה בזיכרון, כפי שהמשתמש שמבצע את שאילתה החיפוש תופס אותה.
דירוג מתייחס לסדר הפריטים, והחזרה מתייחסת למספר הפריטים הרלוונטיים שאוחזרו. פריט (נקרא גם מסמך) הוא כל פיסת תוכן דיגיטלי שאפשר להוסיף לאינדקס של Google Cloud Search. סוגי הפריטים כוללים מסמכי Microsoft Office, קובצי PDF, שורה במסד נתונים, כתובות URL ייחודיות וכו'. פריט מורכב מהפרטים הבאים:
- מטא-נתונים מובְנים
- תוכן שאפשר להוסיף לאינדקס
- ACLs (רשימות בקרת גישה)
Cloud Search משתמש במגוון אותות כדי לאחזר ולדרג את התוצאות של שאילתות החיפוש – הפריטים שמתקבלים משאילתת חיפוש. אתם יכולים להשפיע על האותות של Cloud Search באמצעות הגדרות בסכימה, התוכן והמטא-נתונים של הפריט (במהלך ההוספה לאינדקס) ואפליקציית החיפוש. המטרה של המסמך הזה היא לעזור לכם לשפר את איכות החיפוש באמצעות שינוי הגורמים האלה שמשפיעים על האותות.
תוכלו לקרוא סיכום של ההגדרות המומלצות והאופציונליות במאמר סיכום של הגדרות מומלצות ואופציונליות של איכות החיפוש.
השפעה על הציון של הרלוונטיות לנושא
רלוונטיות לנושא מתייחסת לרלוונטיות של תוצאת חיפוש למונחי השאילתה המקוריים. רלוונטיות הנושא של פריט מסוים מחושבת על סמך הקריטריונים הבאים:
- מידת החשיבות של כל מונח שאילתה.
- מספר ההיטים (מספר הפעמים שמונח השאילתה מופיע בתוכן או במטא-נתונים של הפריט).
- סוג ההתאמות של מונח השאילתה והווריאציות שלו לפריט שנוסף לאינדקס של Cloud Search.
כדי להשפיע על דירוג הרלוונטיות לנושא של נכס טקסט, צריך להגדיר את הפרמטר RetrievalImportance
בנכס הטקסט בסכימה. התאמה לנכס עם ערך RetrievalImportance
גבוה מניבה ציון גבוה יותר בהשוואה להתאמה לנכס עם ערך RetrievalImportance
נמוך.
לדוגמה, נניח שיש לכם מקור נתונים עם המאפיינים הבאים:
- מקור הנתונים משמש לאחסון היסטוריה של באגים בתוכנה.
- לכל באג יש שם, תיאור ורמת עדיפות.
רוב המשתמשים ישלימו שאילתה למקור הנתונים הזה באמצעות שם הבאג, לכן צריך להגדיר את RetrievalImportance
בשם כ-HIGHEST
בסכימה.
לעומת זאת, רוב המשתמשים לא יכולים לשלוח שאילתה למקור הנתונים הזה באמצעות תיאור הבאג, לכן צריך להגדיר את הערך של RetrievalImportance
בתיאור כ-DEFAULT
.
בהמשך מופיעה סכימה לדוגמה שמכילה הגדרות של RetrievalImportance
.
{
"objectDefinitions": [
{
"name": "issues",
"propertyDefinitions": [
{
"name": "summary",
"textPropertyOptions": {
"retrievalImportance": {
"importance": HIGHEST
}
}
},
{
"name": "description",
"textPropertyOptions": {
"retrievalImportance": {
"importance": DEFAULT
}
}
},
{
"name": "label",
"isRepeatable": true,
"textPropertyOptions": {
"retrievalImportance": {
"importance": DEFAULT
}
}
},
{
"name": "comments",
"textPropertyOptions": {
"retrievalImportance": {
"importance": DEFAULT
}
}
},
{
"name": "project",
"textPropertyOptions": {
"retrievalImportance": {
"importance": HIGH
}
}
},
{
"name": "duedate",
"datePropertyOptions": {
}
},
...
]
}
]
}
במסמכי HTML, תגים כמו <title>
ו-<h1>
, יחד עם הגדרות עיצוב כמו גודל הגופן והדגשה מודגשת, משמשים לקביעת מידת החשיבות של מונחים שונים. אם הערך של ContentFormat
הוא TEXT
, הערך של ItemContent
הוא DEFAULT
. אם הערך הוא HTML, הערך של 'חשיבות אחזור' נקבע על סמך מאפייני ה-HTML.
השפעה על עדכניות הנתונים
עדכניות היא מדד של הזמן שחלף מאז שהפריט השתנה, והיא נקבעת לפי המאפיינים createTime
ו-updateTime
ב-ItemMetadata
.
פריטים ישנים יותר יורדים למיקומים נמוכים יותר בתוצאות החיפוש.
אפשר להשפיע על אופן החישוב של רמת העדכניות של אובייקט על ידי שינוי הערכים של freshnessProperty
ו-freshnessDuration
ב-FreshnessOptions
בסכימה.
בעזרת freshnessProperty
אפשר להשתמש במאפייני תאריך או חותמת זמן כדי לחשב את רמת העדכניות במקום updateTime
שמוגדר כברירת מחדל.
בדוגמה הקודמת שלנו של מערכת למעקב אחר באגים בתוכנה, אפשר להשתמש בתאריך היעד בתור freshnessProperty
, כך שהפריטים עם תאריך היעד הקרוב ביותר לתאריך הנוכחי ייחשבו לפריטים 'עדכניים יותר' ויקבלו שיפור בדירוג. סכימה לדוגמה עם הגדרות freshnessProperty
:
{
"objectDefinitions": [
{
"name": "issues",
"options": {
"freshnessOptions": {
"freshnessProperty": "duedate"
}
},
"propertyDefinitions": [
{
"name": "summary",
"textPropertyOptions": {
"retrievalImportance": {
"importance": HIGHEST
}
}
},
{
"name": "duedate",
"datePropertyOptions": {
}
},
...
]
}
]
}
אפשר להשתמש ב-freshnessDuration
כדי לציין מתי פריט נחשב לא עדכני.
לדוגמה, יכול להיות שיש לכם מקור נתונים שלא מתווסף לאינדקס באופן קבוע, או שאתם לא רוצים שהעדכניות שלו תשפיע על הדירוג. כדי להשיג את היעד הזה, צריך לציין ערך גבוה ל-freshnessDuration
.
נניח שיש לכם מקור נתונים עם פרטי פרופיל של עובדים. בתרחיש הזה, כדאי להגדיר ערך גבוה ל-freshnessDuration
כי שינויים בפרטים של העובדים בדרך כלל לא רלוונטיים לדירוג שלהם. בהמשך מופיעה סכימה לדוגמה שמכילה את ההגדרה freshnessDuration
:
{
"objectDefinitions": [
{
"name": "people",
"options": {
"freshnessOptions": {
"freshnessDuration": "315360000s", # 100 years
}
},
}
]
}
אפשר גם להגדיר את freshnessDuration
לערך קטן מאוד במקורות נתונים שהתוכן שלהם משתנה במהירות, כמו מקור נתונים שמכיל כתבות חדשותיות.
בתרחיש כזה, המסמכים שנוצרו או שונו לאחרונה הם הרלוונטיים ביותר.
בהמשך מופיעה סכימה לדוגמה עם ההגדרה freshnessDuration
למקור נתונים שמכיל תוכן שמשתנה במהירות:
{
"objectDefinitions": [
{
"name": "news",
"options": {
"freshnessOptions": {
"freshnessDuration": "259200s", # 3 days
}
},
}
]
}
השפעה על האיכות
איכות היא מדד של הדיוק והשימושיות של פריט. מקור נתונים יכול להכיל כמה מסמכים דומים מבחינה סמנטית, לכל אחד מהם רמת איכות שונה. אפשר לציין ערך איכות בין 0 ל-1 באמצעות SearchQualityMetadata
.
פריטים עם ערכים גבוהים יותר מקבלים שיפור בדירוג בהשוואה לפריטים עם ערכים נמוכים יותר. השתמשו בהגדרה הזו רק אם אתם צריכים להשפיע על האיכות של פריט או לשפר אותה מעבר למידע שסופק לחיפוש ב-Cloud.
לדוגמה, נניח שיש לכם מקור נתונים שמכיל מסמכים של הטבות לעובדים. אפשר להשתמש ב-SearchQualityMetadata
כדי לשפר את הדירוג של מסמכים שנכתבו על ידי עובדים משאבי אנוש, בהשוואה למסמכים שנכתבו על ידי עובדים אחרים.
בהמשך מופיעה סכימה לדוגמה שמכילה הגדרות של SearchQualityMetadata
לבעיות במערכת למעקב אחר באגים:
{
"name": "datasources/.../items/issue1",
"acl": {
...
},
"metadata": {
"title": "Issue 1"
"objectType": "issues"
},
...
}
{
"name": "datasources/.../items/issue2",
"acl": {
...
},
"metadata": {
"title": "Issue 2"
"objectType": "issues"
"searchQualityMetadata": {
"quality": 0.5
}
},
...
}
{
"name": "datasources/.../items/issue3",
"acl": {
...
},
"metadata": {
"title": "Issue 3"
"objectType": "issues"
"searchQualityMetadata": {
"quality": 1
}
},
...
}
לפי הסכימה הזו, כשמשתמש מחפש באמצעות מונח החיפוש 'בעיה', הבעיה השלישית בהסכימה (איכות 1) מדורגת גבוה יותר מהבעיה השנייה (איכות 0 .5) ומהבעיה הראשונה (אם לא צוין דבר, איכות ברירת המחדל היא 0).
השפעה באמצעות סוג השדה
Cloud Search מאפשר לכם להשפיע על הדירוג על סמך הערך של מאפייני enum או של מספרים שלמים. לכל מאפיין של מספר שלם או מאפיין enum, אפשר לציין OrderedRanking
. ההגדרה הזו כוללת את הערכים הבאים:
NO_ORDER
(ברירת המחדל): הנכס לא משפיע על הדירוג.ASCENDING
: פריטים עם ערכים גבוהים יותר של המאפיין הזה מסוג מספר שלם או קבוצת ערכים מקבלים שיפור בדירוג בהשוואה לפריטים עם ערכים נמוכים יותר.DESCENDING
: פריטים עם ערכים נמוכים יותר של המאפיין של המספר המלא או המאפיין של המניין מקבלים שיפור בדירוג בהשוואה לפריטים עם ערכים גבוהים יותר.
לדוגמה, נניח שלכל באג במערכת למעקב אחר באגים יש מאפיין enum לאחסון העדיפות של הבאג בתור HIGH
(1), MEDIUM
(2) או LOW
(3). בתרחיש הזה, הגדרת OrderedRanking
של DESCENDING
מובילה לשיפור הדירוג של באגים בעדיפות HIGH
בהשוואה לבאגים בעדיפות LOW
.
בהמשך מופיעה סכימה לדוגמה שמכילה הגדרות OrderedRanking
לבעיות במערכת למעקב אחר באגים:
{
"objectDefinitions": [
{
"name": "issues",
"options": {
"freshnessOptions": {
"freshnessProperty": "duedate",
}
},
"propertyDefinitions": [
{
"name": "summary",
"textPropertyOptions": {
"retrievalImportance": {
"importance": HIGHEST
}
}
},
{
"name": "duedate",
"datePropertyOptions": {
}
},
{
"name": "priority",
"enumPropertyOptions": {
"possibleValues": [
{
"stringValue": "HIGH",
"integerValue": 1
},
{
"stringValue": "MEDIUM",
"integerValue": 2
},
{
"stringValue": "LOW",
"integerValue": 3
}
],
"orderedRanking": DESCENDING,
}
},
...
]
}
]
}
מערכת למעקב אחר באגים יכולה לכלול גם מאפיין של מספר שלם שנקרא votes
, שמשמשים לאיסוף משוב ממשתמשים לגבי החשיבות היחסית של באג. אפשר להשתמש בנכס votes
כדי להשפיע על הדירוג על ידי מתן חשיבות גבוהה יותר לבאגים עם מספר ההצבעות הגבוה ביותר. במקרה כזה, אפשר לציין את הערך OrderedRanking
בתור ASCENDING
לנכס votes
, כדי שהבעיות עם מספר ההצבעות הגבוה ביותר יקבלו שיפור בדירוג. בהמשך מופיעה סכימה לדוגמה שמכילה הגדרות OrderedRanking
לבעיות במערכת למעקב אחר באגים:
{
"objectDefinitions": [
{
"name": "issues",
"propertyDefinitions": [
{
"name": "summary",
"textPropertyOptions": {
"retrievalImportance": {
"importance": HIGHEST
}
}
},
{
"name": "description",
"textPropertyOptions": {
"retrievalImportance": {
"importance": DEFAULT
}
}
},
{
"name": "votes",
"integerPropertyOptions": {
"orderedRanking": ASCENDING,
"minimumValue": 0,
"maximumValue": 1000,
}
},
...
]
}
]
}
השפעה על הדירוג באמצעות הרחבת שאילתה
הרחבת שאילתות היא הרחבה של המונחים בשאילתה באמצעות מילים נרדפות ואיות, כדי לאחזר תוצאות טובות יותר.
שימוש במילים נרדפות כדי להשפיע על תוצאות החיפוש
כדי להרחיב את מונחי השאילתה, Cloud Search משתמש במילים נרדפות שנגזרות מתוכן אינטרנט ציבורי. אפשר גם להגדיר מילים נרדפות בהתאמה אישית כדי לתעד מונחים ספציפיים לארגון, כמו ראשי תיבות נפוצים בארגון או מונחים ספציפיים לתחום.
אפשר להגדיר מילים נרדפות בהתאמה אישית במקור נתונים או כמקור נתונים נפרד. כברירת מחדל, שמות נרדפים חלים על כל מקורות הנתונים בכל אפליקציות החיפוש. עם זאת, אפשר לקבץ מילים נרדפות לפי מקור נתונים ואפליקציית חיפוש. מידע נוסף על הגדרת מילים נרדפות בהתאמה אישית, כולל קיבוץ לפי אפליקציית חיפוש, זמין במאמר הגדרת מילים נרדפות.
איך משפיעים על תוצאות החיפוש באמצעות איות
Cloud Search מספק הצעות לאיות על סמך מודלים שנוצרו באמצעות הנתונים הציבוריים של חיפוש Google. אם מערכת Cloud Search מזהה שגיאת איות בהקשר של שאילתה, היא מחזירה את ההצעה לשאילתה ב-SpellResult
.
אפשר להציג את ההצעה לאיות למשתמש כאפשרות. לדוגמה, יכול להיות שהמשתמש ידפיס שגיאה במילה 'employe' בשאילתה, ויכול להיות שהוא יקבל את ההצעה 'התכוונתם ל-employee?'
חיפוש ב-Cloud משתמש גם בתיקוני איות כמילים נרדפות כדי לאחזר מסמכים שלא היו מתגלים אחרת בגלל שגיאת איות.
השפעה על הדירוג באמצעות הגדרות של אפליקציות חיפוש
כפי שצוין במבוא ל-Google Cloud Search, אפליקציית חיפוש היא קבוצה של הגדרות שמשויכות לממשק חיפוש ומספקות מידע לפי הקשר על חיפושים. ההגדרות הבאות מאפשרות לכם להשפיע על הדירוג דרך אפליקציית החיפוש:
- הגדרת ניקוד
- הגדרת המקור
בקטעים הבאים מוסבר איך ההגדרות האלה יכולות להשפיע על הדירוג.
שינוי ההגדרות של מערכת הדירוג
לכל אפליקציית חיפוש אפשר לציין ScoringConfig שמשמש לשליטה בהפעלה של אותות מסוימים במהלך הדירוג. בשלב זה, אפשר להשבית את האפשרויות עדכניות והתאמה אישית.
אם העדכון יושבת, הוא יושבת בכל מקורות הנתונים שמפורטים באפליקציית החיפוש, ללא קשר לאפשרויות העדכון שצוינו בסכימה של מקור הנתונים. באופן דומה, אם ההתאמה האישית מושבתת, הבונוס לבעלים והבונוס על אינטראקציה לא משפיעים על הדירוג.
הוראות מפורטות להגדרת ההגדרה הזו מפורטות במאמר התאמה אישית של חוויית החיפוש ב-Cloud Search.
שינוי ההגדרה של המקור
הגדרת המקור מאפשרת לציין הגדרות ברמת מקור הנתונים באפליקציית חיפוש. יש תמיכה בהגדרות הבאות:
- חשיבות המקור
- קיבוץ באשכולות
הגדרת חשיבות המקור
חשיבות המקור מתייחסת לחשיבות היחסית של מקור נתונים באפליקציית חיפוש. אפשר לציין את ההגדרה הזו בשדה SourceImportance
בתוך SourceScoringConfig
.
פריטים ממקור נתונים עם מידת חשיבות מקור של HIGH
מקבלים שיפור בדירוג בהשוואה לפריטים ממקור נתונים עם מידת חשיבות מקור של DEFAULT
או LOW
. אפשר להשתמש בהגדרה הזו כדי להשפיע על הדירוג אם לדעתכם המשתמשים יעדיפו תוצאות ממקורות נתונים מסוימים.
לדוגמה, נניח שיש לכם פורטל תמיכה במוצר שמכיל נתונים חיצוניים ופנימיים לפתרון בעיות. בתרחיש כזה, מומלץ להגדיר את אפליקציית החיפוש כך שתעדוף תוצאות ממקור הנתונים הפנימי.
הוראות מפורטות להגדרת ההגדרה הזו מפורטות במאמר התאמה אישית של חוויית החיפוש ב-Cloud Search.
הגדרת עומס
צפיפות מתייחסת למספר התוצאות המקסימלי שאפשר להחזיר ממקור נתונים באפליקציית חיפוש. אפשר לשלוט בערך הזה באמצעות השדה numResults
בקובץ SourceCrowdingConfig
.
ערך ברירת המחדל של הערך הזה הוא 3, כלומר אם הצגנו 3 תוצאות ממקור נתונים, Cloud Search יתחיל להציג תוצאות ממקורות נתונים אחרים. המערכת תבחן מחדש פריטים ממקור הנתונים הראשון רק אם כל מקורות הנתונים הגיעו למגבלת הצפיפות שלהם או שאין יותר תוצאות ממקורות נתונים אחרים.
ההגדרה הזו עוזרת להבטיח מגוון בתוצאות החיפוש ולמנוע ממקור נתונים אחד לשלוט בדף תוצאות החיפוש.
הוראות מפורטות להגדרת ההגדרה הזו מפורטות במאמר התאמה אישית של חוויית החיפוש ב-Cloud Search.
השפעה על הדירוג באמצעות התאמה אישית
התאמה אישית היא הצגה של תוצאות חיפוש בהתאמה אישית על סמך המשתמש הספציפי שמקבל גישה לתוצאה. אתם יכולים להשפיע על הדירוג על ידי מתן עדיפות לפריטים על סמך הקריטריונים הבאים:
- הבעלות על הפריט
- אינטראקציה בדפים של פריטים
- קליקים של משתמשים
- שפת הפריט
בשלוש הקטעים הבאים מוסבר איך להשפיע על איכות החיפוש על סמך הקריטריונים האלה.
השפעה על הדירוג על סמך הבעלות על הפריט
בעלות על פריט מתייחסת לשיפור הדירוג של פריטים שנמצאים בבעלות המשתמש שמבצע את שאילתת החיפוש. לכל פריט יש ItemAcl
עם שדה owners
. אם המשתמש שמריץ שאילתה הוא הבעלים של פריט, הפריט מקבל שיפור דירוג כברירת מחדל. אתם יכולים להשבית את ההתאמה האישית באפליקציית החיפוש.
שיפור הדירוג על סמך אינטראקציה עם פריט
אינטראקציה עם פריט מתייחסת לשיפור הדירוג של פריטים שהמשתמש ביצע איתם אינטראקציה באמצעות שאילתה לחיפוש (צפייה, הוספת תגובה, עריכה וכו').
אותות של אינטראקציה עם פריטים מתקבלים באופן אוטומטי במוצרי Google Workspace, כמו Drive ו-Gmail. במוצרים אחרים, אפשר לספק נתוני אינטראקציה ברמת הפריט, כולל סוג האינטראקציה (צפייה, עריכה), חותמת הזמן של האינטראקציה והחשבון המשתמש (המשתמש שהיה באינטראקציה עם הפריט). חשוב לזכור שפריטים עם אינטראקציות מהזמן האחרון מקבלים שיפור גבוה יותר בדירוג.
שיפור הדירוג על סמך קליקים של משתמשים
מערכת Cloud Search אוספת את הלחיצות על תוצאות החיפוש הנוכחיות ומשתמשת בהן כדי לשפר את הדירוג של חיפושים עתידיים. לשם כך, היא מקדמת פריטים שאותו משתמש לחץ עליהם בעבר.
השפעה על הדירוג באמצעות פרשנות של שאילתות
התכונה פרשנות שאילתות ב-Cloud Search מפרשת באופן אוטומטי את האופרטורים והמסננים בשאילתה של המשתמש, וממירה את הרכיבים האלה לשאילתה מובנית שמבוססת על אופרטורים. כדי לפרש את השאילתה, נעשה שימוש באופרטורים שמוגדרים בסכימה, יחד עם המסמכים שנוספו לאינדקס, כדי להסיק מה המשמעות של השאילתה של המשתמש. התכונה הזו מאפשרת למשתמש לבצע חיפוש עם מספר מצומצם של מילות מפתח, ועדיין לקבל תוצאות מדויקות. למידע נוסף, ראו מבנה סכימה לפירוש אופטימלי של שאילתות.
שיפור הדירוג על סמך שפת הפריט
שפה: המערכת מורידה את דירוג הפריטים שהשפה שלהם לא תואמת לשפה של השאילתה. הגורמים הבאים משפיעים על הדירוג של פריטים לפי שפה:
שפת השאילתה. השפה שזוהתה באופן אוטומטי של שאילתת החיפוש, או הערך של
languageCode
שצוין ב-RequestOptions
.אם אתם יוצרים ממשק חיפוש מותאם אישית, צריך להגדיר את
languageCode
לשפת הממשק או להעדפת השפה של המשתמש (לדוגמה, השפה של דפדפן האינטרנט או של דף ממשק החיפוש). שפת השאילתה שזוהתה באופן אוטומטי מקבלת עדיפות על פניlanguageCode
, כדי שלא תהיה פגיעה באיכות החיפוש כשמשתמש מקלידים שאילתה בשפה ששונה מהממשק שלו.שפת הפריט. הערך של
contentLanguage
שמוגדר ב-ItemMetadata
בזמן ההוספה לאינדקס, או שפת התוכן שזוהתה באופן אוטומטי על ידי Cloud Search.אם השדה
contentLanguage
של המסמך נשאר ריק בזמן ההוספה לאינדקס, והשדהItemContent
מאוכלס, מערכת Cloud Search תנסה לזהות את השפה שבה נעשה שימוש בשדהItemContent
ולאחסן אותה באופן פנימי. השפה שזוהתה באופן אוטומטי לא תתווסף לשדהcontentLanguage
.
אם השפה של השאילתה והפריט תואמת, לא תתבצע הדחה של השפה. אם ההגדרות האלה לא תואמות, המערכת מורידה את הסטטוס של הפריט. הורדת הדירוג של השפה לא חלה על מסמכים שבהם השדה contentLanguage
ריק ומערכת Cloud Search לא הצליחה לזהות את השפה באופן אוטומטי. כתוצאה מכך, הדירוג של מסמך לא מושפע אם Cloud Search לא מצליח לזהות את השפה שלו.
שיפור הדירוג על סמך הקשר הפריט
אתם יכולים לשפר את הדירוג של פריטים שרלוונטיים יותר להקשר של שאילתת החיפוש. ההקשר (contextAttributes
) הוא קבוצה של מאפיינים עם שמות שאפשר לציין במהלך ההוספה לאינדקס ובבקשת החיפוש, כדי לספק הקשר לשאילתת חיפוש ספציפית.
לדוגמה, נניח שפריט, כמו מסמך של הטבות לעובדים, רלוונטי יותר בהקשר של Location
ו-Department
, כמו עיר (San Francisco
), מדינה (California
), מדינה (USA
) ו-Department
(Engineering
). במקרה כזה, אפשר להוסיף את הפריט לאינדקס באמצעות המאפיינים הנקראים הבאים:
{
...
"metadata": {
"contextAttributes": [
{
name: "Location"
values: [
"San Francisco",
"California",
"USA"
],
},
{
name: "Department"
values: [
"Engineering"
],
}
],
},
...
}
כשהמשתמש מזין שאילתת חיפוש של 'הטבות' בממשק החיפוש, תוכלו לכלול את פרטי המיקום והמחלקה של המשתמש בבקשת החיפוש. לדוגמה, זוהי בקשת חיפוש שמכילה מידע על המיקום והמחלקה של מהנדס בשיקגו:
{
...
"contextAttributes": [
{
name: "Location"
values: [
"Chicago",
"Illinois",
"USA"
],
},
{
name: "Department"
values: [
"Engineering"
],
}
],
...
}
מכיוון שגם הפריט שנוסף לאינדקס וגם בקשת החיפוש מכילים את המאפיינים 'Department=Engineering' ו-'Location=USA', הפריט שנוסף לאינדקס (מסמך של הטבות לעובדים) מופיע גבוה יותר בתוצאות החיפוש.
עכשיו נניח שמשתמש אחר, מהנדס בהודו, מזין בממשק החיפוש את שאילתת החיפוש 'הטבות'. זוהי בקשת חיפוש שמכילה את המיקום ואת פרטי המחלקה שלהם:
{
...
"contextAttributes": [
{
name: "Location"
values: [
"Bengaluru",
"Karnataka",
"India"
],
},
{
name: "Department"
values: [
"Engineering"
],
}
],
...
}
מכיוון שגם הפריט שנוסף לאינדקס וגם בקשת החיפוש מכילים רק את המאפיין 'Department=Engineering', הפריט שנוסף לאינדקס מופיע מעט גבוה יותר בתוצאות החיפוש (בהשוואה לשאילתת החיפוש הראשונה 'benefits' שהוזנה על ידי מהנדס שנמצא בשיקגו, אילינוי, ארה"ב).
ריכזנו כאן כמה דוגמאות להקשרים שאפשר להשתמש בהם כדי לשפר את הדירוג:
- מיקום: פריטים יכולים להיות רלוונטיים יותר למשתמשים במיקום מסוים, כמו בניין, עיר, מדינה או אזור.
- תפקיד עבודה: פריטים יכולים להיות רלוונטיים יותר למשתמשים בתפקיד עבודה מסוים, כמו כותב טכני או מהנדס.
- מחלקה: פריטים יכולים להיות רלוונטיים יותר למחלקות מסוימות, כמו מכירות או שיווק.
- רמת התפקיד: פריטים יכולים להיות רלוונטיים יותר לרמות תפקידים מסוימות, כמו מנהל או מנכ"ל.
- סוג העובד: פריטים יכולים להיות רלוונטיים יותר לסוגים מסוימים של עובדים, כמו עובדים במשרה חלקית ועובדים במשרה מלאה.
- ותק: פריטים יכולים להיות רלוונטיים יותר לוותק של העובד, למשל עובד חדש.
השפעה על הדירוג באמצעות פופולריות הפריט
חיפוש ב-Cloud מעלה את הדירוג של פריטים פופולריים. כלומר, הוא מעלה את הדירוג של פריטים שקיבלו קליקים בשאילתות חיפוש מהזמן האחרון.
השפעה על הדירוג באמצעות Clickboost
Cloud Search אוסף את הקליקים על תוצאות החיפוש הנוכחיות ומשתמש בהם כדי לשפר את הדירוג בחיפושים עתידיים, על ידי הגדלת החשיפה של פריטים פופולריים לשאילתת חיפוש מסוימת.
סיכום של ההגדרות המומלצות והאופציונליות של איכות החיפוש
בטבלה הבאה מפורטים כל ההגדרות המומלצות והאופציונליות של איכות החיפוש. ההמלצות האלה יעזרו לכם להפיק את המקסימום מהמודלים של דירוג ב-Cloud Search.
הגדרה | מיקום | מומלץ/אופציונלי | פרטים |
---|---|---|---|
הגדרות הסכימה | |||
השדה ItemContent | ItemContent | מומלץ | כשיוצרים או מעדכנים את הסכימה, מאכלסים את התוכן הלא מובנה של פריט. השדה הזה משמש ליצירת קטעי קוד. |
השדה RetrievalImportance | RetrievalImportance | מומלץ | כשיוצרים או מעדכנים סכימת נתונים, מגדירים אותה לנכסי טקסט שחשובים או רלוונטיים באופן ברור. |
FreshnessOptions | FreshnessOptions | אופציונלי | כשיוצרים או מעדכנים סכימת, צריך להגדיר את ההגדרות כדי לוודא שפריטים לא יורדים בדרגה בגלל נתונים שגויים או במקרים שבהם חסרים נתונים. |
הגדרות ההוספה לאינדקס | |||
createTime /updateTime | ItemMetadata | מומלץ | אכלוס במהלך הוספת פריט לאינדקס. |
contentLanguage | ItemMetadata | מומלץ | אכלוס במהלך הוספת פריט לאינדקס. אם השדה הזה לא מופיע, Cloud Search ינסה לזהות את השפה שמופיעה ב-ItemContent . |
השדה owners | ItemAcl() | מומלץ | אכלוס במהלך הוספת פריט לאינדקס. |
מילים נרדפות בהתאמה אישית | הסכימה _dictionaryEntry | מומלץ | מגדירים ברמת מקור הנתונים או כמקור נתונים נפרד במהלך ההוספה לאינדקס. |
השדה quality | SearchQualityMetadata | אופציונלי | כדי לשפר את ציון האיכות הבסיסי בהשוואה לפריטים דומים מבחינה סמנטית, כדאי להגדיר את האיכות במהלך ההוספה לאינדקס. הגדרת השדה הזה לכל הפריטים במקור נתונים מבטלת את ההשפעה שלו. |
נתוני אינטראקציה ברמת הפריט | interaction | אופציונלי | אם מקור הנתונים מתעד את האינטראקציות של המשתמשים ומספק גישה אליהן, צריך לאכלס את האינטראקציות של כל פריט במהלך ההוספה לאינדקס. |
מאפייני integer/enum | OrderedRanking | אופציונלי | כשסדר הפריטים רלוונטי, צריך לציין את הדירוג המסודר של מאפייני המספרים השלמים ומאפייני המניין במהלך ההוספה לאינדקס. |
הגדרות של אפליקציית חיפוש | |||
Personalization=false | ScoringConfig או באמצעות ממשק המשתמש לניהול של CloudSearch | מומלץ | כשיוצרים או מעדכנים את אפליקציית החיפוש. חשוב לוודא שסיפקתם את פרטי הבעלים הנכונים, כפי שמתואר במאמר 'השפעה על הדירוג באמצעות התאמה אישית'. |
השדה SourceImportance | SourceCrowdingConfig | אופציונלי | כדי להטות את התוצאות ממקורות נתונים מסוימים, מגדירים את השדה הזה. |
השדה numResults | SourceCrowdingConfig | אופציונלי | כדי לשלוט בגיוון התוצאות, מגדירים את השדה הזה. |
השלבים הבאים
הנה כמה שלבים אפשריים:
איך משתמשים בסכימה
_dictionaryEntry
כדי להגדיר מילים נרדפות למונחים נפוצים בחברה כדי להשתמש בסכימה_dictionaryEntry
, אפשר לעיין במאמר הגדרת מילים נרדפות.