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

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

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

אפשר להגדיר את תוצאות החיפוש במאגר הנתונים באמצעות המסוף,‏ API או שילוב של Dialogflow CX Messenger.

קלט של תנאי חיפוש

תוצאות החיפוש מוגדרות באמצעות השדות boost specification (BoostSpec) ו-filter specification (FilterSpec) באובייקט SearchConfig. ההגדרות האלה חלות על כל מאגר נתונים בכלי, ומאפשרות לכם לשלוט באופן פרטני בהתנהגות של כל מאגר נתונים שמקושר.

אפשר להגדיר תנאי חיפוש באחת משתי דרכים: באמצעות המסוף או באמצעות שליחת קריאה ישירה ל-API. יש הבדלים חשובים בין השניים.

• קריאה ל-API: הערכים BoostSpec ו-FilterSpec נשלחים ב-SearchConfig באמצעות קריאה ל-API של DetectIntent. בבקשה צריך לציין אובייקט SearchConfig מלא. הודעת SearchConfig שנשלחת באמצעות קריאה ישירה ל-API תמיד מבטלת הודעת SearchConfig שנשלחת באמצעות המסוף. המערכת לא תומכת בביטויים דינמיים ובהפניות לפרמטרים.

• ‫Console: ההגדרות של BoostSpec ושל FilterSpec משמשות ליצירת אובייקט SearchConfig שנשלח עם בקשת החיפוש. אם רוצים, אפשר לכלול הפניות לפרמטרים וביטויים דינמיים כדי להתאים את התוצאות לנתוני ההקשר שנרשמו מהשיחה. אתם נדרשים לספק רק ConditionBoostSpec אובייקטים ורשימה של מחרוזות מסננים כדי ליצור FilterSpecs, ולא אובייקט SearchConfig מלא.

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

מפרטים של הגברה (מפרטי הגברה)

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

כל מפרט של הגברה מוזן כמחרוזת JSON. מחרוזת ה-JSON הזו צריכה לייצג אובייקט ConditionBoostSpec יחיד.

שדות עיקריים:

• ‫condition: (מחרוזת) ביטוי שמציין מתי צריך להחיל את ההגברה. השימוש הוא בתחביר הרגיל של ביטויי מסננים. אתם יכולים להשתמש בביטויים של Dialogflow CX כדי להפוך את התוצאות לדינמיות, כמו $session.params.YOUR_PARAM_NAME או $request.end-user-metadata.YOUR_KEY.
• ‫boost: (מספר) ערך בין ‎-1.0 ל-1.0 שקובע את עוצמת ההגברה.
  • ערך חיובי מקדם התאמה בין מסמכים. ערך של 1.0 מציין מבצע משתלם.
  • ערך שלילי מוריד את הדירוג של מסמכים תואמים. ערך של -1.0 יגרום להורדה משמעותית בדירוג.
  • הערך 0.0 לא מוסיף שום תוספת ולא מותר.
• ‫boostControlSpec: מספק יותר אמצעי בקרה לדירוג בהתאמה אישית מאשר השילוב הבסיסי של תנאי ושיפור. מידע נוסף על הגדרת השדה הזה מופיע במאמרי העזרה.

קלט לדוגמה במסוף:

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

בדוגמה הזו, מסמכים עם URI שתואם לערך של הפרמטר $session.params.doc_id session יקבלו דירוג גבוה יותר בעוצמה של 0.5. ‫JSON בפורמט הזה

{
  "condition": "uri: ANY(\"http://www.example.com/docs/$session.params.doc_id\")",
  "boost": 0.5
}

דוגמה לקלט של API:

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

‫

"searchConfig": {
  "boostSpecs": [
    {
      "dataStores": [ "DATASTORE_ID" ],
      "spec": [
        {
          "conditionBoostSpecs": {
            "condition": "CONDITION",
            "boost": "1.0"
          }
        }
      ]
    }
  ]
}

הערה: DATASTORE_ID הוא השם המלא של מאגר הנתונים: projects/your_project_id/locations/your_location/collections/your_collection_name/dataStores/your_datastore_name,
‫CONDITION צריך להיות בהתאם לתחביר של ביטוי המסנן של Agent Search,
וערך ההגברה צריך להיות בין ‎-1.0 ל-1.0.

מפרטי מסננים

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

כל Filter Spec צריך להיות מוזן כביטוי מחרוזת. המחרוזת צריכה להיות בהתאם לתחביר הרגיל של ביטויי סינון. אפשר להשתמש בביטויים של Dialogflow CX בתוך המחרוזת הזו כדי שהתוצאות יהיו דינמיות, כמו $session.params.YOUR_PARAM_NAME או $request.end-user-metadata.YOUR_KEY.

מחרוזת לדוגמה של מפרט מסנן ב-Console:

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

בדוגמה הזו, המסנן מחזיר רק מסמכים שבהם הערך של numeric_field גדול או שווה לערך של $session.params.min_value וגם שבהם stock_availability הוא "IN_STOCK".

"numeric_field >= $session.params.min_value AND stock_availability: ANY(\"IN_STOCK\")"

דוגמה להגדרת מסנן API:

אם אתם שולחים קריאה ישירה ל-API, אתם צריכים לספק מחרוזות של filter באובייקט SearchConfig מלא:

‫

"searchConfig": {
  "filterSpecs": [
    {
      "dataStores": [ "DATASTORE_ID" ],
      "filter": "CONDITION"
    }
  ]
}

הערה: DATASTORE_ID הוא השם המלא של מאגר הנתונים: projects/your_project_id/locations/your_location/collections/your_collection_name/dataStores/your_datastore_name,
ו-CONDITION חייבים להיות בהתאם לתחביר של ביטוי המסנן של Agent Search.

ביטויים דינמיים ב-Dialogflow CX

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

גם BoostSpec תנאים וגם מחרוזות FilterSpec יכולים לכלול ביטויים של Dialogflow CX כדי להפוך אותם לדינמיים. כך תוכלו להתאים את התנהגות החיפוש על סמך נתוני הקשר שנשלפים משיחה מתמשכת. אי אפשר להשתמש בביטויים דינמיים בקריאות ישירות ל-API, והם רלוונטיים רק אם מבצעים את ההגדרה באמצעות המסוף.

יש שתי דרכים לגשת לנתוני ההקשר של השיחה:

• פרמטרים של סשן: ערכים שנאספים במהלך השיחה באמצעות $session.params.YOUR_PARAMETER_ID.
• מטא-נתונים של משתמשי קצה: מטא-נתונים על משתמש הקצה שמועברים ב-DetectIntentRequest באמצעות $request.end-user-metadata.YOUR_KEY. כדי שהאפשרות הזו תהיה זמינה, צריך לוודא ש-end_user_metadata כלול ב-QueryParameters של שיחות DetectIntent. מידע נוסף זמין במאמר בנושא endUserMetadata.

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

תנאי החיפוש שחלים בזמן הריצה

כשכלי מאגר הנתונים מבצע חיפוש:

1. מחרוזות ה-JSON שסיפקתם לנתוני ההגברה נבדקות. כל מחרוזת JSON תקינה מומרת לאובייקט ConditionBoostSpec. הם מקובצים לאובייקט BoostSpecs של חיבור מאגר הנתונים הספציפי, שנוסף לאובייקט SearchConfig הכולל.
2. המחרוזות שסיפקתם במפרטי המסננים מוערכות כביטויים של Dialogflow CX. כל מחרוזת מסנן שמתקבלת משמשת ליצירת אובייקט FilterSpecs למאגר הנתונים, שנוסף גם ל-SearchConfig.
3. ה-SearchConfig שנוצר באופן דינמי נכלל ב-QueryParameters של בקשת החיפוש שנשלחת למאגר הנתונים.

הגדרת תנאי חיפוש

לפני שמגדירים תנאי חיפוש, צריך לוודא שיש לכם:

• סוכן קיים ב-Dialogflow CX.
• כלי למאגר נתונים שהוגדר לסוכן עם מאגר נתונים אחד או יותר שמופעלים.

הגדרת המסוף

1. פותחים את המסוף של Conversational Agents ובוחרים פרויקט ב- Google Cloud.
2. בוחרים סוכן מהתפריט הנפתח.
3. בתפריט הימני, לוחצים על כלים. בוחרים את הכלי של מאגר הנתונים שרוצים להגדיר.
4. בדף העריכה של הכלי, עוברים לקטע מאגרי נתונים. לוחצים על סמל ההגדרות (⚙️) לצד מאגר הנתונים שרוצים לשנות.
5. מופיע התפריט Configure Data Store (הגדרת מאגר נתונים). כאן אפשר להוסיף מפרטים של שיפורים ומפרטים של מסננים כדי לשנות את תוצאות החיפוש.
   • במקרה של מפרט לשיפור הביצועים, צריך לספק אובייקט JSON שמגדיר ConditionBoostSpec. פרטים נוספים זמינים במאמר בנושא מפרטים של Boost.
   • במפרט המסנן, מציינים מחרוזת שמגדירה את קריטריוני הסינון. פרטים נוספים זמינים במאמר בנושא מפרטי מסננים.
6. אחרי שמוסיפים את המפרטים ומגדירים אותם, לוחצים על אישור בתחתית החלונית הצדדית.
7. לוחצים על שמירה בדף העריכה של כלי מאגר הנתונים כדי לשמור את השינויים.

הגדרת API

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

צריך לספק את המידע הזה בשדה queryParams.searchConfig בשיטה Sessions.detectIntent.

מעבר להפניית Session API

בוחרים פרוטוקול וגרסה להפניה של הסשן:

פרוטוקול	V3	V3beta1
REST	Session resource	Session resource
RPC	ממשק הסשן	ממשק הסשן
C++‎	SessionsClient	לא זמין
C#‎	SessionsClient	לא זמין
המשך	SessionsClient	לא זמין
Java	SessionsClient	SessionsClient
Node.js	SessionsClient	SessionsClient
PHP	לא זמין	לא זמין
Python	SessionsClient	SessionsClient
Ruby	לא זמין	לא זמין

סגירה

הגדרת Dialogflow CX Messenger

אתם יכולים לספק נתוני הגדרות חיפוש לשילוב של Dialogflow CX Messenger. מידע נוסף מופיע בקטע על השיטה setContext.

כדי להחיל מפרט חיפוש או הגדרת חיפוש, צריך להוסיף את קטע הקוד הבא לקוד של Dialogflow CX Messenger כשמטמיעים אותו באתר:

<script>
  document.addEventListener('df-messenger-loaded', () => {
    const dfMessenger = document.querySelector('df-messenger');
    const searchConfig = { ... }
    dfMessenger.setQueryParameters(searchConfig);
  });
</script>

מידע נוסף על השיטה setQueryParameters

פתרון בעיות

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

ביטויים לא תקינים

אם תנאי של מפרט לשיפור או מחרוזת של מפרט לסינון מכילים ביטוי לא תקין של Dialogflow CX (לדוגמה, תחביר שגוי או הפניה לפרמטר שלא קיים), הידור הביטוי ייכשל. שגיאות שקשורות להידור של ביטויים מוחזרות בדרך כלל ב-DetectIntentResponse בשדה diagnostic_info בתור SystemFunctionResults.

‫JSON לא תקין ConditionBoostSpec

כששומרים את מחרוזת ה-JSON‏ ConditionBoostSpec, מתבצע אימות מסוים במסוף של הסוכנים לשיחה. המטרה היא לוודא שזהו קובץ JSON תקין ושהמבנה שלו יכול להיות ממופה לאובייקט ConditionBoostSpec. אם קובץ ה-JSON תקין אבל הוא מוביל ל-SearchConfig לא תקין בהתאם לשירות החיפוש הבסיסי (לדוגמה, מחרוזת תנאים לא תקינה אחרי החלפת פרמטרים), שירות החיפוש יחזיר שגיאה.

שגיאות החלפה בזמן ריצה

אם ConditionBoostSpec מחרוזת JSON תקינה וניתנת לניתוח, אבל מתרחשת שגיאה במהלך החלפת הביטויים של Dialogflow CX בשדות שלה (כמו מחרוזת התנאי) בזמן הריצה, השגיאות האלה ידווחו ב-diagnostic_info בתור SystemFunctionResults.

בודקים את SearchConfig

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

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

• מידע נוסף על המבנה של SearchConfig ועל הרכיבים שלו זמין במאמרי העזרה בנושא search_config.
• מידע נוסף על תחביר של ביטויים זמין במאמר הפניות לתנאים ולפונקציות מערכת ב-Dialogflow CX.
• מידע נוסף על תחביר של ביטויי סינון לחיפוש מופיע במאמר בנושא סינון ומיון תוצאות.