נבדק לאחרונה: יוני 2026
מדריך מקוצר ובר-סריקה לדפוסי ארכיטקטורה שמבחן C1000-180 בודק. קראו מלמעלה למטה, או דלגו לסעיף.
עוזר חדש; בחירת פרדיגמת הכתיבה.
בנה באמצעות עורך ה-Actions, לא באמצעות מיומנות ה-Dialog הישנה. Actions מדגמים שיחות ממוקדות משימות כצעדים, תנאים ומשתנים ללא צורך בניהול עץ צמתים.
למה: Actions הם מודל הכתיבה הנוכחי והמומלץ של IBM; Dialog הוא מיושן וקשה יותר לתחזוקה. בחינות מקצועיות מניחות עיצוב מבוסס actions תחילה.
החלטה כיצד לפרק תחום תמיכה גדול ליחידות.
קבע scope של פעולה אחת לכל מטרה נפרדת של המשתמש (איפוס סיסמה, בדיקת יתרה, קביעת פגישה). שמור על פעולות בעלות מטרה יחידה וניתנות לשימוש חוזר.
למה: פעולות צרות וממוקדות משימה קלות יותר לבדיקה, ניתוח ושיפור מאשר זרימות מונוליטיות המנסות לטפל בהכל.
קלט המשתמש יכול להפעיל מספר פעולות דומות.
הפעל ביטול עמימות כך שהעוזר יציג תפריט הבהרה של פעולות מועמדות במקום לנחש.
למה: ביטול עמימות מפחית שגיאות של פעולות שגויות ומבליט את כוונת המשתמש האמיתית, ובכך משפר את שיעור ההשלמה.
העוזר אינו מבין את המשתמש לאחר ניסיונות חוזרים ונשנים.
תכנן נתיב "אין התאמה לפעולה" / "כל דבר אחר" עם תגובה מבהירה, ולאחר N כשלים, הסלמה לסוכן אנושי.
למה: נתיב חלופי מוגדר מונע לולאות ללא מוצא ומגן על CSAT; אי-התאמה שלא נתפסה היא הגורם העיקרי לנטישה.
השיחה חורגת מיכולות העוזר או שהמשתמש מתוסכל.
הוסף שלב "התחבר לסוכן" שמעביר את השיחה לשולחן שירות (לדוגמה: Zendesk, Genesys, Salesforce) עם הקשר השיחה מצורף.
למה: העברת תמלול ומשתנים שנאספו לסוכן מונעת מהמשתמש לחזור על עצמו.
בעלי עניין רוצים קול מותג עקבי בתגובות.
הגדר פרסונה ומדריך טון מראש; כתוב את טקסט התגובה בעקביות ועשה שימוש חוזר בווריאציות כדי למנוע חזרות רובוטיות.
למה: טון עקבי בונה אמון; ערבוב ניסוחים רשמיים ויומיומיים בין פעולות יוצר תחושה של חוסר חיבור.
פרט נדרש אינו ברור או חסר בניסוח המשתמש.
שאל שאלת הבהרה ממוקדת באמצעות slot במקום להניח ערך ברירת מחדל.
למה: אישור מפורש של פרמטרים בעלי חשיבות גבוהה (סכום, חשבון, תאריך) מונע פעולות שגויות יקרות.
תכנון זרימה חדשה עם מקרי קצה רבים.
כתוב את ה-happy path מקצה לקצה תחילה, ולאחר מכן הוסף אימות, דיגרסיות וענפי שגיאות.
למה: בניית מקרי קצה לפני זרימת הליבה מובילה לפעולות מורכבות יתר על המידה וקשות לבדיקה.
פעולה זקוקה למספר פיסות מידע לפני שהיא יכולה להסתיים.
אסוף כל ערך בשלב נפרד כ-slot; העוזר מבקש כל ערך שעדיין לא סופק ומדלג על אלה שכבר סופקו.
למה: מילוי slots מבוסס צעדים מטפל בקלטים לא מסודרים ובעלי ערכים מרובים ללא צורך בפיצול ידני.
ערך חייב להתקיים גם לאחר שהפעולה הנוכחית מסתיימת.
אחסן אותו במשתנה session, לא במשתנה step/action. משתני action מוגבלים לפעולה; משתני session קיימים לכל אורך השיחה.
למה: בחירת היקף שגוי היא באג קלאסי: הערך נעלם כשהפעולה מסתיימת או לא מצליח לשתף בין פעולות.
שלב מבקש מהמשתמש לבחור מתוך סט ידוע וקבוע.
השתמש בסוג תגובה "options" עם אפשרויות מוגדרות במקום טקסט חופשי, ומפה כל אפשרות לערך.
למה: אפשרויות מגבילות את הקלט, מבטלות עמימות בניתוח, ומוצגות ככפתורים בערוצים נתמכים.
ערך שנאסף (אימייל, תאריך, סכום) עשוי להיות בפורמט שגוי.
הוסף תנאי אימות על השלב; אם לא חוקי, השאר את המשתמש בשלב עם הנחיה מתקנת.
למה: אימות בזמן הלכידה מונע העברת נתונים שגויים להרחבות ולצעדים הבאים.
שלבים מאוחרים יותר צריכים לרוץ רק עבור משתמשים או ערכים מסוימים.
הגדר תנאי שלב על משתנים שכבר נאספו כך ששלבים ידלגו כאשר התנאי שלהם שגוי.
למה: תנאים מבטאים פיצול ללא שכפול פעולות; העורך מעריך אותם מלמעלה למטה.
מספר פעולות זקוקות לאותו תת-זרימה (לדוגמה, אימות זהות).
פרק את הלוגיקה המשותפת ל-subaction וקרא לה מכל פעולת אב.
למה: Subactions שומרות על לוגיקת אימות DRY ועקבית; שכפול צעדים מוביל לחוסר סינכרון.
המשתמש שואל שאלה לא קשורה באמצע הזרימה ("מה השעות שלכם?").
אפשר דיגרסיה כך שהעוזר יענה על שאלת הצד, ואז יחזור לפעולה שהופסקה.
למה: חסימת דיגרסיות כופה סקריפט נוקשה שמתסכל משתמשים עם בקשות צד לגיטימיות.
צורך לחשב או לשנות ערך בתוך שלב.
השתמש בשפת הביטויים המובנית (לדוגמה, פונקציות מחרוזת ומתמטיקה על משתנים) בשלב או בתגובה.
למה: טרנספורמציות קלות שייכות לביטויים; שימוש ב-webhook למתמטיקה טריוויאלית הוא מוגזם.
פעולת המשך זקוקה לערך שהמשתמש נתן קודם לכן.
הפנה למשתנה session הקיים במקום לבקש מחדש.
למה: בקשה חוזרת על נתונים ידועים מרגישה שגויה; העברת הקשר קדימה היא סימן היכר של זרימה טובה.
זרימה צריכה לעצור או לקפוץ לפעולה אחרת תחת תנאי.
השתמש במעבר "סיים את הפעולה" או "עבור לשלב בפעולה אחרת" כדי לשלוט בזרימה באופן מפורש.
למה: מעברים מפורשים מונעים מעבר בלתי צפוי לשלב הבא לאחר תנאי סופי.
העוזר חייב לקרוא ל-API של REST מתועד כדי לאחזר נתונים חיים.
ייבא את מפרט ה-OpenAPI של ה-API כהרחבה מותאמת אישית, ולאחר מכן הוסף שלב "התקשר להרחבה" שממפה משתנים לפרמטרים.
למה: הרחבות מותאמות אישית הן הדרך הנתמכת, ללא קוד, לקרוא ל-API חיצוניים משלב עם קלטים/פלטים מטיפוסים.
בחירה בין webhook לבין הרחבה מותאמת אישית.
השתמש בהרחבה מותאמת אישית כדי לקרוא ל-API חיצוני מתוך שלב ספציפי; השתמש ב-webhook (לפני/אחרי הודעה) כדי להריץ לוגיקה על כל הודעה או לשנות את כל ה-payload.
למה: Webhooks מופעלים גלובלית לכל הודעה; הרחבות מוגבלות בהיקף וממופות פרמטרים לכל שלב. בחירה שגויה היא מלכודת נפוצה בבחינות.
ה-API היעד דורש אימות.
הגדר את האימות (מפתח API, OAuth, בסיסי) בעת הוספת ההרחבה המותאמת אישית; אחסן סודות בהגדרות ההרחבה, לא בטקסט הדיאלוג.
למה: הטמעת פרטי זיהוי במשתנים או בתגובות מדליפה אותם ללוגים ולתמלילים.
קריאה להרחבה מחזירה שגיאה או פגה זמן קצוב.
פצל את הזרימה על בסיס התגובה/סטטוס של ההרחבה בשלב הבא והצג הודעת חלופית או נתיב ניסיון חוזר.
למה: כשלים לא מטופלים בהרחבה משאירים את המשתמש תקוע; תמיד תכנן את הנתיב שאינו 200.
צורך להעשיר או למחוק מידע מכל הודעה לפני עיבוד או לפני שליחה.
השתמש ב-webhook לפני הודעה כדי לעבד קלט נכנס וב-webhook אחרי הודעה כדי לשנות את התגובה לפני מסירה.
למה: Webhooks לפני/אחרי מרכזים דאגות חוצות (מיסוך PII, רישום לוגים) ללא עריכה של כל פעולה.
משתמשים שואלים שאלות פתוחות שניתן לענות עליהן מקורפוס מסמכים.
הפעל חיפוש שיחתי (RAG): אחזר קטעים מאינטגרציית חיפוש ובקש ממודל בסיס של watsonx.ai ליצור תשובה מבוססת עם ציטוטים.
למה: חיפוש שיחתי מכסה את "הזנב הארוך" של שאלות שאינך יכול לכתוב כפעולות נפרדות.
בחירת מאגר האחזור מאחורי החיפוש השיחתי.
חבר את watsonx Discovery / Elasticsearch (או אינטגרציית חיפוש נתמכת אחרת) כאינדקס לאחזור.
למה: איכות ההתבססות תלויה באינדקס האחזור; קורפוס לא מאונדקס או מחולק בצורה גרועה יחזיר קטעים חלשים.
חיפוש שיחתי לא מוצא קטעים רלוונטיים.
הגדר את התגובה "אין תוצאת חיפוש" כך שהעוזר יגיד שהוא אינו יודע במקום לדמיין, והצע הסלמה.
למה: נתיב "אין תוצאה" מוגדר הוא מה ששומר על עוזר RAG הגון ומבוסס.
ציות דורש שתשובות גנרטיביות יהיו ניתנות למעקב.
הפעל ציטוטים למקורות כך שתשובות שנוצרו יציגו את המסמכים מהם נשלפו.
למה: ציטוטים מאפשרים למשתמשים לוודא תשובות ועונים לדרישות ביקורת בתעשיות מפוקחות.
כוונון איכות ועלות התשובה הגנרטיבית.
בחר את מודל הבסיס של watsonx.ai (לדוגמה, מודל Granite) לחיפוש שיחתי והתאם את הגדרות יצירת התוכן למקרה השימוש.
למה: בחירת מודל ופרמטרים היא trade-off בין איכות התשובה, חביון ועלות; ברירות מחדל אינן תמיד אופטימליות.
החלטה אם שאילתה מטופלת על ידי פעולה או על ידי חיפוש.
נתב משימות טרנסאקציונליות ופרמטריות לפעולות; נתב שאלות מידע פתוחות לחיפוש שיחתי.
למה: אילוץ שאלות בסגנון שאלות נפוצות לפעולות נוקשות, או עסקאות ל-RAG, פוגע בחוויה.
העוזר חייב לענות לשיחות טלפון נכנסות.
השתמש באינטגרציית הטלפון/קול (voice gateway מעל SIP) כדי לחבר ספק טלפוניה, עם STT לקלט ו-TTS לתגובות.
למה: שער הקול מגשר בין טלפוניית SIP לעוזר; בלעדיו אין ערוץ טלפון.
תגובות מדוברות נשמעות לא נכון או מזהות שגוי את המתקשר.
כייל את מודל ה-speech-to-text/שפה ואת קול ה-text-to-speech בהגדרות אינטגרציית הטלפון.
למה: קולות/מודלים ברירת מחדל עשויים שלא להתאים לשפה או לאוצר המילים של הדומיין, מה שפוגע בזיהוי ובבהירות.
זרימה שנבנתה לצ'אט מתפקדת בצורה גרועה בקול.
התאם זרימות קוליות: הימנע מכפתורים/רשימות ארוכות, שמור על הנחיות קצרות, ואשר ערכים מדוברים במפורש.
למה: קול אינו יכול להציג ממשק משתמש עשיר; זרימות אופטימליות לטקסט עם תפריטים נשברות כאשר הן נקראות בקול רם.
הגעה למשתמשים באמצעות SMS / הודעות טקסט.
הגדר את אינטגרציית ה-SMS (טלפון/טקסט); תכנן תגובות בטקסט רגיל ללא אלמנטים עשירים.
למה: SMS מסיר סוגי תגובה עשירים; תגובות חייבות לרדת בחינניות לטקסט.
צ'אט אינטרנט צריך להציג תמונות, כרטיסים או כפתורים.
השתמש בסוגי תגובה עשירים (תמונה, אפשרויות, כרטיס) בפעולה; הערוץ מציג סוגים נתמכים ונופל אחורה אחרת.
למה: תגובות עשירות משפרות את חווית המשתמש באינטרנט אך חייבות להיות בעלות גיבוי טקסט רגיל הגיוני לקול/SMS.
מדידת האם העוזר באמת עוזר.
השתמש בלוח המחוונים של Analytics כדי לעקוב אחר שיעור ההשלמה, הכיסוי וקלטים מזוהים לעומת לא מזוהים לאורך זמן.
למה: מדדי גיון כמו ספירת סשנים אינם משקפים הצלחת משימה; השלמה וכיסוי כן.
חיפוש אחר הסיבה מדוע משתמשים נוטשים זרימה.
קרא יומני שיחות/תמלילים, סנן לפי פעולה, ואתר שלבים של נטישה ואי-התאמות תכופות.
למה: תמלילים אמיתיים חושפים את הפערים שמדדים מצטברים רק רומזים עליהם.
הצעות ביטול העמימות לעיתים קרובות בסדר שגוי.
הפעל למידה אוטומטית כך שהעוזר יסדר מחדש הצעות על בסיס איזו אפשרות משתמשים בוחרים בפועל.
למה: למידה אוטומטית משפרת רלוונטיות מבחירות אמיתיות ללא אימון ידני.
קלטים רבים נופלים ל"אין התאמה לפעולה".
חפש קלטים לא מזוהים מנתוני אנליטיקה, קבץ אותם, וכתוב פעולות חדשות או הוסף דוגמאות לקיימות.
למה: פערי כיסוי הם השיפור בעל המינוף הגבוה ביותר; אלה השאילתות שאתה נכשל בהן לחלוטין.
בקשה תקינה אינה מפעילה את הפעולה שלה באופן אמין.
הוסף ניסוחים אמיתיים של משתמשים כדוגמאות אימון לשלב של אותה פעולה כדי לשפר את הזיהוי.
למה: הזיהוי מתחזק עם דוגמאות מייצגות שנלקחו מיומנים, לא ניסוחים שהומצאו.
אימות ששינוי שיפר תוצאות.
בצע שינוי אחד בכל פעם, פרסם, והשווה השלמה/כיסוי לפני ואחרי לאורך חלון זמן משמעותי.
למה: שינוי דברים רבים בבת אחת הופך את ייחוס תנועת המדדים לבלתי אפשרי.
כותבים עורכים בזמן שמשתמשי קצה מקיימים אינטראקציה עם העוזר.
כתוב בסביבת ה-draft; משתמשים מדברים עם סביבת ה-live. פרסם גרסה מ-draft ל-live כשהיא מוכנה.
למה: הפיצול בין draft ל-live מאפשר לך לבצע איטרציות בבטחה מבלי לחשוף עבודה לא גמורה לסביבת הייצור.
סט שינויים שנבדק מוכן לייצור.
צור גרסה (snapshot) ופרסם אותה לסביבת ה-live; גרסאות קודמות נשארות זמינות לשחזור.
למה: תיעוד גרסאות מספק היסטוריה ניתנת לביקורת ושחזור מהיר אם מהדורה נסוגה.
סביבות draft ו-live חייבות להצביע על נקודות קצה שונות בקצה האחורי (בדיקה לעומת ייצור).
הגדר הגדרות הרחבה/אינטגרציה ספציפיות לסביבה כך שכל סביבה תכוון למערכות הנכונות.
למה: שיתוף נקודת קצה אחת בין סביבות מסכן תעבורת בדיקה שתפגע במערכות ייצור.
השקת העוזר לצ'אט אינטרנט, טלפון, Slack ו-WhatsApp.
הוסף והגדר כל אינטגרציית ערוץ בסביבת היעד; ערוצים מצורפים לכל סביבה.
למה: ערוץ שמופעל רק ב-draft לא ישרת משתמשי ייצור עד שיוגדר ב-live.
חברי צוות שונים זקוקים לרמות גישה שונות.
השתמש ב-IBM Cloud IAM כדי להקצות גישה מבוססת תפקידים (לדוגמה, צופה, עורך, מפעיל, מנהל) לשירות watsonx Assistant או לקבוצת משאבים.
למה: גישת הפריבילגיה המינימלית באמצעות תפקידי IAM היא הדרך הנתמכת לשלוט מי יכול לכתוב לעומת מי יכול להפעיל.
ארגון שירותים וגבולות גישה בין צוותים או פרויקטים.
מקם את שירות העוזר בקבוצת משאבים והגדר מדיניות גישה של IAM לקבוצה זו.
למה: קבוצות משאבים מספקות גבולות חיוב וגישה נקיים; חשבונות שטוחים הופכים לבלתי ניתנים לניהול בקנה מידה.
אפליקציה חיצונית צריכה לקרוא לעוזר באמצעות API.
צור פרטי זיהוי שירות / מפתח API וכתובת URL של העוזר, וקרא ל-v2 runtime API איתם.
למה: גישה פרוגרמטית משתמשת בפרטי זיהוי מוגבלים בהיקף; שימוש חוזר בפרטי התחברות אישיים אינו מאובטח ואינו נתמך.
כללי מיקום נתונים או הפרדת רשת אוסרים ענן ציבורי.
פרוס את watsonx Assistant ב-Cloud Pak for Data (מקומי או ענן פרטי) במקום IBM Cloud SaaS.
למה: תעשיות מפוקחות דורשות לעיתים קרובות התקנה מקומית/CP4D לבידוד נתונים ועמידה בתקנות.
בחירת תוכנית עבור השקת ייצור עם נפח גבוה.
בחר את תוכנית השירות המתאימה (לדוגמה, Plus/Enterprise) עבור הנפח, התכונות ורמת השירות הנדרשים.
למה: תוכניות Lite/ניסיון מגבילות את השימוש וחסרות תכונות ייצור; התאם את גודל התוכנית לפני ההשקה.
נתונים רגישים מופיעים בשיחות ובלוגים.
השתמש בבידוד נתונים, מחיקת/הסתרת PII בלוגים (לדוגמה, באמצעות webhooks), והגדר הגדרות שמירת/אבטחת לוגים.
למה: מידע מזהה אישי (PII) לא ממוסך בתמלילים מהווה סיכון לציות; מסיכה בעת הקליטה ושלוט בשמירה.